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
