Document: draft-ietf-ippm-storetraceroutes-08 Reviewer: Pasi Eronen Review Date: 2008-02-26 IETF LC End Date: 2008-01-15 IESG Telechat date: (not known yet) Summary: Almost ready; but still has open issues,described in the review. Comments: I've gone through version -08 of the document; many of my comments have been addressed, but not all. Details follow: 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 #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 also suggested that it might be useful to also specify the method that was used to get the location -- if that's not done, perhaps a sentence describing that "the method(s) used to determine the location of the hop are beyond the scope of this specification, and not includedin the measurement result" would be in order. About #5: the text was clarified to say that "[TestName] is locally unique, within the scope of a specific host, initiator of the traceroute measurement". This doesn't really solve the problem, since the XML file doesn't necessarily include the identity of the host (and TestName can occur in requests as well, so there's little chance of actually ensuring it's unique). Also, this complicates mapping of RFC4560 data to this format, since the MIB uses a different definition of scope. About #6: Section 5.1 now says for InetAddressType/InetAddress "The allowed values are to be intended as imported from [RFC4001] (where the intent was to import only some of the values)". This does not really describe what the allowed values are ("some" is too vague). 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). About #10: The information model (Section 5.1) now mentions the "noSpecification" InetAddressType, but its meaning is not described (in particular, it's not obvious what's the difference between "unknown" and "noSpecification"). 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. About #18: _CtlPort has now wrong restriction in XML schema About comments #19...#21: none of these has been addressed in any way. There were to some extent style issues, so it's not absolutely required to address them, but I hope at least some kind of discussion has occurred confirming that what's currently in the document is what we want it to be. About #20: The schema still duplicates the address type in two places, and does not enforce that they're consistent. If the duplication is really necessary, the schema should enforce consistency (with appropriate use of xs:choice/xs:group/xs:sequence). 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. Additional comments for -08: 23) CtlBypassRouteTable description now says "Please refer to SO_DONTROUTE for more explanations regarding this." A better reference would be helpful (i.e., "refer to description of SO_DONTROUTE in [something] for more...")