Hi, Pasi, thanks for the re-review!
Authors, to me this sounds like another revision will be required, or do you disagree with the issues that remain? Lars On 2008-5-22, at 19:58, Eronen Pasi (Nokia-NRC/Helsinki) 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.) > > 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
