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
