Dear Pasi, We just submitted a new version (10) of this draft. I hope we now addressed all you comments. Changes are:
* Fixing number of ProbeResults per Measurement * Aligning description of draft and schema * Simplifying XML for InetAddress (improves readability) * Aligning default values with RFC4560 * Reviewing and updating Appendix C Please review the new version another time. Thank you for your effort. 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Donnerstag, 22. Mai 2008 18:58 > To: [EMAIL PROTECTED]; Thomas Dietz > Cc: 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) > > > 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 > > > -----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 > > > > > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
