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
