Subject: Re: [Gen-art] Gen-ART review of draft-ietf-ippm-storetraceroutes-07 (-08)

From: Lars Eggert <[email-masked]>
Date: Tue, 13 May 2008 15:07:48 +0300

Hi,

it's been two weeks since the last emails, and it's been almost half a  
year since this document has been pub-requested. It needs to be  
updated, and then it needs to go back to the WG for a last call,  
followed by another IETF last call, before it can go to the IESG,  
because of the magnitude of thechanges (four revisions since the WGLC).

Do the authors and WG have enough energy to see this document to  
completion?

Lars

On 2008-4-29, at 18:03, ext Thomas Dietz wrote:

> Hello Pasi,
>
> Sorry for the late reply. Find my answers inline.
>
> -- 
> Thomas Dietz                 E-mail: [email-masked]
> NEC Europe Ltd.              Phone:  +49 6221 4342-128
> NEC Laboratories Europe      Fax:    +49 6221 4342-155
> Network Research Division
> Kurfuersten-Anlage 36
> 69115 Heidelberg, Germany    http://www.nw.neclab.eu
>
> NEC Europe Limited           Registered in England 2832014
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Montag, 14. April 2008 11:57
>> To: Thomas Dietz; Saverio Niccolini; [email-masked];
>> [email-masked]
>> Cc: [email-masked]; [email-masked]; Sandra Tartarelli; Juergen
>> Quittek; [email-masked]
>> Subject: RE: Gen-ART review of draft-ietf-ippm-storetraceroutes-07 (-
>> 08)
>>
>> Thomas,
>>
>> Thanks for taking the time to help with finishing this draft!
>> See my comments in-line:
>>
>> <snip>
>>>>>> About #5: TestName uniqueness/scope is still very different
>>>>>> from RFC 4560 (in RFC 4560, test name *alone* is not unique;
>>>>>> it's combined with traceRouteCtlOwnerIndex, contextEngineID,
>>>>>> and contextName).  However, if the results are not converted
>>>>>> from SNMP MIB, other methods of specifying the scope might be
>>>>>> useful (e.g. host name or IP/MAC address or something).
>>>>>>
>>>>>> The specification of testName scope is related to one *very*
>>>>>> important information element that is currently missing from
>>>>>> the schema: where the measurements were run. Note that
>>>>>> current semantics of CtlSourceAddress make it unusable for
>>>>>> this purpose. In RFC 4560, the scope is given by
>>>>>> contextEngineID and contextName (which can be used to look up
>>>>>> more information from  e.g. Interfaces, IP, or Entity MIBs)
>>>>>> -- here it needs to be explicit.
>>>>>
>>>>> We can not make the scope the same as RFC 4560, we can jsut
>> choose
>>>>> it as if it was chosen in accordance with RFC 4560 since the
>>>>> constructs contextEngineID and contextName are MIB-specific.  We
>>>>> discussed this and we think this is the best way of solving it,
>> if
>>>>> you have a concrete suggestion we are ready to implement it.
>>>>
>>>> Well... let me ask it this way: when you get an XML file containing
>>>> results from a traceroute run, do you think it's important to know
>>>> on which host the measurement was run on?
>>>>
>>>> (I think it would be -- but if the WG consensus is that this
>>>> information is unimportant, then at least the document needs to
>>>> explain this quite surprising omission, and Appendix C needs
>>>> to describe this big difference to RFC 4560.)
>>>>
>>>
>>> Well, I don't think that the current situation for the TestName is
>>> really different from what is defined in RFC 4560. RFC 4560
>>> specifies 2 indexes, which are traceRouteCtlOwnerIndex and
>>> traceRouteCtlTestName.  traceRouteCtlOwnerIndex is only used for
>>> simple access control to the elements in the traceRouteCtlTable and
>>> thus traceRouteCtlName is the only object that specifies the test.
>>>
>>> You can argue that the host is implicitly given since you query it
>>> by SNMP.  So we have 2 possibilities to solve this issue:
>>>
>>> 1 - Add a kind of scope element to the schema
>>> 2 - Or leave the schema as it is and state that the host (or similar
>>> information) is encoded in the filename
>>
>> Or simply say that TestName is not necessarily unique within any
>> well-defined scope?
>>
>> (BTW, the CtlSourceAddress annotation has slightly unclear sentence
>> "A zero length octet string value for this object means that source
>> address specification was disabled." The past tense suggests this
>> applies to MeasurementMetadata, but it seems it was intended
>> to apply to RequestMetadata only.)
>>
>
> OK, so we will change this.
>> <snip>
>>
>>>>>> About #9: I still believe it should be possible to add new
>>>>>> CtlTypes without making the XML file unparseable by
>>>>>> existing software.
>>>>>
>>>>> We think differently and that is why we added the following
>>>>> sentence: " It specifies if the traceroute is using TCP, UDP,
>>>>> ICMP or others type of probes.  If these needs to be extended
>>>>> then a new schema needs to be defined with re-definitions of
>>>>> CtlType and related response status."  We do not see other way
>>>>> out of it.
>>>>
>>>> Could you explain in more detail what you mean by "we do not see
>>>> other way of of it"?
>>>
>>> To make the CtlTypes extensible is really a difficult thing.
>>
>> This kind of situation (small set of predefined values, which needs  
>> to
>> be extensible later) occurs in many IETF-defined XML schemas, and
>> solving it has not been difficult before.  I'm trying to understand
>> what makes this particular situation more difficult than the others.
>>
>>> There are 2 possibilities I currently have in mind.
>>>
>>> One is to have a CtlTypes value of "other" (as it is now) and add an
>>> element called e.g. CtlTypeOther where you can specify which other
>>> type it is. This would make the schema more complicated.
>>>
>>> The other is to remove the CtlTypes value of "other" and require an
>>> updated schema (which can be really short by just including the
>>> original one, redefining the CtlTypes element and adding additional
>>> elements needed).
>>>
>>> I would prefer the second one because it corresponds to the method
>>> of RFC 4560. In RFC 4560 you require an OID for the
>>> traceRouteCtlType. Further on the RFC says:
>>>
>>>           Additional implementation types should be allocated as
>>>           required by implementers of the DISMAN-TRACEROUTE-MIB
>>>           under their enterprise specific registration point,
>>>           not beneath traceRouteImplementationTypeDomains.
>>>
>>> This means an enterprise specific MIB is needed to implement a new
>>> traceRouteCtlType. A similar approach would be to require an updated
>>> schema.
>>
>> This enterprise MIB would define just an OID; it would not move the
>> existing tables from their current location (1.3.6.1.2.1.81).
>>
>> The closest XML analogy would probably be defining a new CtlType  
>> value
>> (in enterprise specific schema, corresponding to enterprise specific
>> namespace), but keeping all the current elements in the same  
>> namespace
>> they're now.
>>
>> This sounds like one reasonable approach, and would be quite easy to
>> do. The resulting XML would then probably look something like this:
>>
>>  <CtlType><Tcp/><CtlType>
>>
>> or
>>
>>  <CtlType xmlns:foo="http://example.com/FooSchema">
>>    <foo:FooType/>
>> <CtlType>
>>
>> (the schema needs some kind '<xs:any namespace="##other">'
>> element).
>>
>> In my earlier emails, I also suggested two very simple approaches  
>> that
>> have been used in IETF XML schemas before. Could you comment on why
>> you believe neither of those is appropriate for this situation?
>>
>> (First approach, used in e.g. RFC 3275, is to base CtlType on
>> xs::anyURI, and specify three (non-resolvable) URIs for TCP, UDP, and
>> ICMP. Second approach, used in e.g. RFC 4119, is to base CtlType on
>> xs::token, and and let IANA manage the values, with initial values
>> being "TCP", "UDP", and "ICMP").
>>
>
> Sorry, I did not see those e-mails. Either they did not go to the  
> list or I
> missed them while reading the archive. Both approaches look fine. I  
> think I
> prefer the first one because then enterprises can define their own  
> CtlTypes.
>
> Best Regards,
>
> Thomas
>
>> Best regards,
>> Pasi

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 13 May 2008 10:47:31 +0200

Hi authors of this draft,

> Sorry for the late reply. Find my answers inline.

If I got this right, this mail settled the last two open issues.  If
so, can any of the authors tell me when we can expect a new draft?
If not, what still has to be done?

More general: I think we have to redo the WGLC for this draft as
quite a few things have changed.  When the next version is there,
can somebody summarize the changes?

Thanks,

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Is one of the choices leaving the office open?
                                       Alan Greenspan on the next elections

---

From: "Thomas Dietz" <[email-masked]>
Date: Fri, 16 May 2008 16:01:44 +0200

Dear all,

I already integrated all the changes discussed on the mailing list. And
since I expect the XML schema to be stable now I am writing up some examples
for traceroute measurements. I expect this to be finished beginning of next
week. I will then send an updated draft version.

Best Regards,

Thomas

> From: Henk Uijterwaal [mailto:[email-masked]]
> Sent: Dienstag, 13. Mai 2008 10:48
> To: Thomas Dietz
> Cc: [email-masked]; Saverio Niccolini; [email-masked];
> [email-masked]; [email-masked]; Sandra Tartarelli; Juergen
> Quittek; [email-masked]
> Subject: Re: Gen-ART review of draft-ietf-ippm-storetraceroutes-07 (-
> 08)
>

---

From: "Thomas Dietz" <[email-masked]>
Date: Tue, 20 May 2008 09:52:31 +0200

Dear all,

I just submitted version 09 of the storetraceroutes draft. I hope all major
issues are sorted out now. I did the following changes to the draft:

* Adjusted description of test name (because of relaxed uniqueness)
* Made the CtlTypes extendable as proposed by Pasi
* Added a reference for setsockopt (IEEE.1003.1G)
* Aligned ProbeResult history with RFC4560
* All Metadata elements are now required but have a default
* Adjusted the inetAddress XML types and their usage
* Aligned the _roundTripTime type with RFC4560
* Added HopAddress to store the DNS name of HopAdress if available
* Added a bunch of examples

Please review this version thoroughly and I hope it fits all its
requirements now.

Best Regards,

Thomas

> From: Lars Eggert [mailto:[email-masked]]
> Sent: Dienstag, 13. Mai 2008 14:08
> To: Thomas Dietz
> Cc: [email-masked]; Saverio Niccolini; [email-masked]; gen-
> [email-masked]; [email-masked]; Sandra Tartarelli; Juergen Quittek;
> [email-masked]

---

From: Lars Eggert <[email-masked]>
Date: Tue, 20 May 2008 10:54:08 +0300

Thomas,

thanks for the quick turnaround on the revision!

Pasi, can you check if you're OK with this version?

Thanks,
Lars

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 20 May 2008 14:00:23 +0200

Hi Thomas,

Thanks for all the work.  As soon as Pasi confirms that the issues
have been settled, can you please post this list of changes (with some
background, as most people aren't xml experts) to the ippm list?  Thanks,

Henk

---

From: <[email-masked]>
Date: Thu, 22 May 2008 19:58:00 +0300

Going over version -09...

I think the element nesting is still wrong: MeasurementResult should
contain exactly one (not 1...2550 as said in Section 5.2.1, or
1...4294967295 as said in the schema) ProbeResult element. (Otherwise,
you need to describe what semantics having multiple ProbeResults
inside one MeasurementResult would be -- but I think this was just
editorial mistake.)

In number of places, the information element description in Section 5
doesn't match the xs:documentation in the schema (earlier versions of
the draft used word-by-word identical text in both places). In some
cases, the differences look significant (and the newer text,
in the schema, is mostly the correct one).

The description of CtlSourceAddress still has conflicting text 
about what the element contains in MeasurementMetadata in case
RequestMetadata didn't request a specific source address.

The text and schema are still inconsistent about the InetAddress type
(in text, it's a single address; in schema, it's a list of addresses).

The description of what elements are optional in Section 5.1 doesn't
match the schema.

Default values for CtlProbeDataSize and CtlMaxFailures don't match 
RFC 4560.

CtlMiscOptions should probably have either default="" or minOccurs="0", 
but not both.

Appendix C is most likely out-of-date.

Best regards,
Pasi 

> From: Eggert Lars (Nokia-NRC/Helsinki) 
> Sent: 20 May, 2008 10:54
> To: ext Thomas Dietz
> Cc: Eronen Pasi (Nokia-NRC/Helsinki); Saverio Niccolini; 
> [email-masked]; [email-masked]; [email-masked]; Sandra 
> Tartarelli; Juergen Quittek; [email-masked]
> Subject: Re: Gen-ART review of 
> draft-ietf-ippm-storetraceroutes-07 (-08)
> 
> Thomas,
> 
> >>>> Subject: RE: Gen-ART review of 
> draft-ietf-ippm-storetraceroutes-07
> >> (-
> >>>> 08)
> >>>>
> >>>> Thomas,
> >>>>
> >>>>> simple access control to the elements in the 
> traceRouteCtlTable  
> >>>>> and
> >>>>> One is to have a CtlTypes value of "other" (as it is 
> now) and add
> >> an
> >>>>> The other is to remove the CtlTypes value of "other" 
> and require  
> >>>>> an
> >>>> This sounds like one reasonable approach, and would be 
> quite easy  
> >>>> to

---

From: Lars Eggert <[email-masked]>
Date: Mon, 26 May 2008 16:01:49 +0300

Hi, Pasi,

thanks for the re-review!

Authors, to me this sounds like another revision will be required, or  
do you disagree with the issues that remain?

Lars

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 27 May 2008 11:49:00 +0200

Dear Pasi,

Thank you very much for reviewing the draft again.
Please find replies to your individual issues below.
We will work on these issue an prepare a new version.
This may take a few days.

> inside one MeasurementResult would be -- but I think this was just

You are right. We have an inconsistency between the containment structure
described in section 5.2 and the actual specification in the schema.
We will fix this.

> in the schema, is mostly the correct one).

Yes. We lost consistency. Also to be fixed.

> RequestMetadata didn't request a specific source address.

This will go a way when re-establishing consistency between
xs:documentation and the element descriptions in section 5.

> (in text, it's a single address; in schema, it's a list of addresses).

Not really, but it can be improved in the schema.  We will do this.
 
> The description of what elements are optional in Section 5.1 doesn't

Yes and no. The construction we chose matches but we did not explain
it sufficiently.  Another work item for us.

> Default values for CtlProbeDataSize and CtlMaxFailures don't match

Will fix it.

> CtlMiscOptions should probably have either default="" or minOccurs="0",

Will fix it.

> Appendix C is most likely out-of-date.

We will update it.

Thanks,

    Juergen