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...")
Best regards,
Pasi
> -----Original Message-----
> From: ext Henk Uijterwaal [mailto:[EMAIL PROTECTED]
> Sent: 25 February, 2008 16:09
> To: Eggert Lars (Nokia-NRC/Helsinki)
> Cc: Eronen Pasi (Nokia-NRC/Helsinki); [email protected];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Gen-ART review of draft-ietf-ippm-storetraceroutes-07
>
> Hi All,
>
> > Authors, please let us know how you're planning to address these
> > comments. I'm assuming that a revision will be required before this
> > document can enter IESG evaluation.
>
> I just noticed that a new version of the draft has been
> published. Can
> people please confirm that this addresses their issues? Thanks,
>
> Henk
>
>
>
> --
> --------------------------------------------------------------
> ----------------
> Henk Uijterwaal Email:
> henk.uijterwaal(at)ripe.net
> RIPE Network Coordination Centre
> http://www.amsterdamned.org/~henk
> P.O.Box 10096 Singel 258 Phone: +31.20.5354414
> 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445
> The Netherlands The Netherlands Mobile: +31.6.55861746
> --------------------------------------------------------------
> ----------------
>
> Is one of the choices leaving the office open?
> Alan Greenspan on the
> next elections
>
_______________________________________________
Gen-art mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/gen-art
