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 > > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
