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.
On 22.05.08 18:58 "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> 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.)
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 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).
Yes. We lost consistency. Also to be fixed.
> 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.
This will go a way when re-establishing consistency between
xs:documentation and the element descriptions in section 5.
> 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).
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
> match the schema.
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
> RFC 4560.
Will fix it.
> CtlMiscOptions should probably have either default="" or minOccurs="0",
> but not both.
Will fix it.
> Appendix C is most likely out-of-date.
We will update it.
Thanks,
Juergen
> Best regards,
> Pasi
>
>> -----Original Message-----
>> 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 PROTECTED]; [email protected]; [EMAIL PROTECTED]; Sandra
>> Tartarelli; Juergen Quittek; [EMAIL PROTECTED]
>> Subject: Re: Gen-ART review of
>> draft-ietf-ippm-storetraceroutes-07 (-08)
>>
>> Thomas,
>>
>> thanks for the quick turnaround on the revision!
>>
>> Pasi, can you check if you're OK with this version?
>>
>> Thanks,
>> Lars
>>
>>
>>
>> On 2008-5-20, at 10:52, ext Thomas Dietz wrote:
>>
>>> 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
>>>
>>> --
>>> Thomas Dietz E-mail: [EMAIL PROTECTED]
>>> 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: Lars Eggert [mailto:[EMAIL PROTECTED]
>>>> Sent: Dienstag, 13. Mai 2008 14:08
>>>> To: Thomas Dietz
>>>> Cc: [EMAIL PROTECTED]; Saverio Niccolini; [EMAIL PROTECTED]; gen-
>>>> [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sandra Tartarelli;
>> Juergen Quittek;
>>>> [EMAIL PROTECTED]
>>>> Subject: Re: Gen-ART review of
>> draft-ietf-ippm-storetraceroutes-07 (-
>>>> 08)
>>>>
>>>> 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 PROTECTED]
>>>>> 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 PROTECTED] [mailto:[EMAIL PROTECTED]
>>>>>> Sent: Montag, 14. April 2008 11:57
>>>>>> To: Thomas Dietz; Saverio Niccolini; [EMAIL PROTECTED];
>>>>>> [EMAIL PROTECTED]
>>>>>> Cc: [email protected]; [EMAIL PROTECTED]; Sandra Tartarelli;
>>>>>> Juergen
>>>>>> Quittek; [EMAIL PROTECTED]
>>>>>> 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 protected]
https://www.ietf.org/mailman/listinfo/gen-art
