Hi Saverio, In general, the schema is a big improvement over the previous version, and easier to read.
My comment #1 (document would be much easier to read if there was e.g. some appendix with an example XML file matching the schema) still stands. 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. About #6: "...some of the values (e.g. unknown, ipv4, ipv6 and dns) excluding non-global IPv4/IPv6 addresses (e.g. ipv4z and ipv6z)" The document needs to unambiguously define what the values are, not just give examples. Suggested rephrasing: "The following values are imported from [RFC4001]: (list)". About #9: I still believe it should be possible to add new CtlTypes without making the XML file unparseable by existing software. My comment #23 (should have a reference about SO_DONTROUTE) is still valid. Additional comments for this version: 24) The informational model has changed quite a lot in this version. In particular, in version -08 each XML file contained results from a single traceroute measurement, while it seems in -09 several measurements (with their own TestName, target address, etc.) can be included, as long as they share the same parameters. Is this an intentional change that resulted from WG identifying a new requirement, or just an accident in schema editing? (Having just single measurement run makes this simpler, so unless this is really an important requirement, I'd suggest not adding features of this magnitude at this stage.) 25) _RequestMetadata has a number of elements with minOccurs="0", but the informational model doesn't describe the semantics of omitting the element. (Note that RFC 4560 does specify the default value for almost all of these.) 26) the definition of "inetAddress" type in XML schema doesn't match the information model in Section 5. 27) "UnsignedByte" is not right data type for CtlIfIndex. 28) "ProbeRoundTripTime" / "_roundTripTime" data type/restrictions is not aligned with RFC 4560. Best regards, Pasi > -----Original Message----- > From: ext Saverio Niccolini [mailto:[EMAIL PROTECTED] > Sent: 04 March, 2008 14:42 > To: Eronen Pasi (Nokia-NRC/Helsinki); [EMAIL PROTECTED]; Eggert > Lars (Nokia-NRC/Helsinki) > Cc: [email protected]; [EMAIL PROTECTED]; Sandra Tartarelli; > Juergen Quittek; [EMAIL PROTECTED]; Thomas Dietz > Subject: RE: Gen-ART review of > draft-ietf-ippm-storetraceroutes-07 (-08) > > Dear all, > > we hope to have addressed all the coments that were raised so far > in the attached version. > > Due to the comments on style issues raised by Pasi, we asked > Thomas to re-design the schema in a more XML-friendly and readable > way, the version -09 includes the new schema. > > If there are no further comment I will submit this when the IETF > submission open again, and I hope this version can go to IESG now ;-) > > Cheers, > Saverio > > ============================================================ > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: [EMAIL PROTECTED] <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, February 27, 2008 1:24 PM > > To: Saverio Niccolini; [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Cc: [email protected]; [EMAIL PROTECTED]; Sandra Tartarelli; > > Juergen Quittek; [EMAIL PROTECTED]; Thomas Dietz > > Subject: RE: Gen-ART review of > > draft-ietf-ippm-storetraceroutes-07 (-08) > > > > Dear Saverio, > > > > Please find comments and answers inline: > > > > > -----Original Message----- > > > From: ext Saverio Niccolini > [mailto:[EMAIL PROTECTED] > > > Sent: 27 February, 2008 10:37 > > > To: Eronen Pasi (Nokia-NRC/Helsinki); [EMAIL PROTECTED]; Eggert Lars > > > (Nokia-NRC/Helsinki) > > > Cc: [email protected]; [EMAIL PROTECTED]; Sandra > > Tartarelli; Juergen > > > Quittek; [EMAIL PROTECTED]; Thomas Dietz > > > Subject: RE: Gen-ART review of > > > draft-ietf-ippm-storetraceroutes-07 (-08) > > > > > > Dear all, > > > > > > please find attached a file where I kept track of the > issues raised > > > and how we addressed them. > > > > > > There are some clear open issues: > > > -- XML file example > > > -- style issues for the XML schema > > > that we are going to address soon (hopefully before IETF still), > > > Thomas offered to help. > > > > > > As for the other issues raised again by Pasi, please find > comments > > > inline since i have some questions. > > > > <snip> > > > > > > About #4: the document now uses the DHCP binary format for > > > > coordinate-based location; however, just saying "represented > > > > according to [RFC3825]" is not sufficient (e.g., the LCI > > format in > > > > RFC3825 Section 2 includes the DHCP option code -- I > > guess we don't > > > > want to include that here?) Also, it's a bit weird to use > > the binary > > > > DHCP format since XML formats for location information > > also exist; > > > > at least a short rationale (one or two sentences) > describing why > > > > they were not used would be helpful. (Also, if the binary > > format is > > > > used, it can't be "xs:string" for obvious reasons.) > > > > > > I feel confused now, you were suggesting using RFC3825 as a > > reference > > > and now you complain about this choice. Please tell us > > what you would > > > like ot see there and we will change accordingly. Also if > > you wnat to > > > see an XML format for location information please suggest a > > reference > > > to use. > > > > I suggested that this document should describe the contents > > of the HopGeoLocation element -- I assumed you would have > > better idea on what exactly the contents should be. For > > example, would a program generating this XML typically know > > the geospatial location > > (latitude/longitude) or civic location (country/state/city) > > of the hops? Or both? > > > > (I don't know what the answer is in this case -- but if you > > don't know the answer either, then maybe this information > > element doesn't belong in this document.) > > > > RFC 4119 (I had the number wrong in my earlier email) uses > > XML format for both types of location, but what's appropriate > > for them might not be right for your use case. > > > > <snip> > > > > > > About #9: Given that we already know about other types, CtlType > > > > really needs to be extensible (as it is in RFC 4560), > beyond just > > > > "others" (which is useless in e.g. requests). > > > > > > Can you suggest type? Otherwise in absence of suggestion I > > will leave > > > it as it is. traceRouteCtlType in RFC 4560 says: > > > "he value of this object may be selected from > > > traceRouteImplementationTypeDomains" > > > Can you please express better what you mean? > > > > To be precise, RFC 4560 says the value may be selected from > > traceRouteImplementationTypeDomains (which contains only > > UDP), or if it's not selected from there, it can be any other > > OID (not beneath traceRouteImplementationTypeDomains). In > > other words: if Example Inc. router would support traceroute > > based on SCTP packets, they would allocate an OID for that > > (under Example Inc. OID tree), and they could use that value > > for CtlType. > > > > In XML, one common mechanism for definining similar > > extensibility points is xs::anyURI. For example, RFC 3275 > > encodes digest algorithms like this: > > > > <DigestMethod > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> > > > > (instead of, say, "<DigestMethod>sha1</DigestMethod>"). In > > this schema, a similar approach would be: > > > > <CtlType Type="urn:ietf:params:xml:ns:traceroute-1.0#udp" /> > > > > Another approach, used in e.g. RFC 4119 for the 'method' > > element, is to define the schema element as simple xs:string, > > but require that the value is one of IANA-registered values. > > This would also allow defining new CtlTypes without failing > > schema validation on existing implementations. > > > > (This seems like a reasonable goal, given that the > > information in the XML file is useful even if the parsing > > implementation does not recognize the exact CtlType.) > > > > <snip> > > > > > > About #16: Section 5.2.1 now describes the "request" > concept, but > > > > it's not obvious what the semantics of some of the information > > > > elements are. For example, what does "OSVersion" > > > > mean when it's included in a request? (One plausible > > answer is "it > > > > can't be included in request", but that's not what the > > information > > > > model or XML schema currently > > > > says.) Other information elements where IMHO possible > ambiguity > > > > exists are OSName, ToolVersion, ToolName, and CtlIfIndex. > > > > > > Would you suggest to exclude those from the "request", we > > can do that. > > > > If you define what they mean in request, I don't have any > > problem with including them. (But if you can't define any > > meaning for them, they probably should be excluded.) > > > > <snip> > > > > About #21: There's still an inconsistency between the > information > > > > model and XML schema about what string is used to > > describe the case > > > > where roundtrip time is not available. > > > > > > Style comments are going to be addressed in -09 > > > > Note that #21 is not a style comment, but a simple bug (typo > > in schema). > > > > Best regards, > > Pasi > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
