Subject: Re: [Gen-art] Gen-ART review of draft-ietf-ippm-storetraceroutes-07

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 25 Feb 2008 15:09:16 +0100

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-masked]
http://www.ietf.org/mailman/listinfo/gen-art

---

From: <[email-masked]>
Date: Tue, 26 Feb 2008 11:22:43 +0200

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-masked]] 
> Sent: 25 February, 2008 16:09
> To: Eggert Lars (Nokia-NRC/Helsinki)
> Cc: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Gen-ART review of draft-ietf-ippm-storetraceroutes-07
> 
> Hi All,
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 26 Feb 2008 12:24:47 +0200

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

---

From: <[email-masked]>
Date: Wed, 27 Feb 2008 14:23:57 +0200

Dear Saverio, 

Please find comments and answers inline:

> From: ext Saverio Niccolini [mailto:[email-masked]] 
> Sent: 27 February, 2008 10:37
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]; Eggert 
> Lars (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; Sandra Tartarelli; 
> Juergen Quittek; [email-masked]; 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>

> > 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>

> 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-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Saverio Niccolini" <[email-masked]>
Date: Wed, 27 Feb 2008 09:37:10 +0100

Dear all,

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.

> 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.

Right, we know and we will address it in -09.

> 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 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.

I will add the suggested text:
"the method(s) used to determine the location of the hop are beyond
the scope of this specification, and not includedin the measurement
result"

> 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.

I will adapt the scope and the XML schema to be consistent to
the RFC4560.

> 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).

I will detail that more.

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?

> 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").

I will add a sentence.

 
> About #18: _CtlPort has now wrong restriction in XML schema

I will change it to UnsignedInt

> 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).
> 

> 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...") 

ok, will do that.

Best regards,
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-masked] <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014