Pasi,
thanks for the reply. Looking through your followup, it seems that
another revision is required before this can go before the IESG.
Authors, please respond in a followup email to each issue that Pasi's
review raises, and revise the draft in accordance with those issues
you agree with.
Thanks,
Lars
On 2008-2-26, at 11:22, Eronen Pasi (Nokia-NRC/Helsinki) wrote:
> 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
