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

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 4 Mar 2008 13:41:33 +0100

Dear all,

we hope to have addressed all the coments that were raised so far
in the attached version.

Due to the comments on style issues raised by Pasi, we asked
Thomas to re-design the schema in a more XML-friendly and readable
way, the version -09 includes the new schema.

If there are no further comment I will submit this when the IETF
submission open again, and I hope this version can go to IESG now ;-)

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, February 27, 2008 1:24 PM
> To: Saverio Niccolini; [email-masked]; [email-masked]
> 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 Saverio, 
> 
> Please find comments and answers inline:
> 
> > -----Original Message-----
> > 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>
> 
> > > 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-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: <[email-masked]>
Date: Wed, 5 Mar 2008 12:41:38 +0200

Hi Saverio,

In general, the schema is a big improvement over the previous
version, and easier to read.

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 #5: TestName uniqueness/scope is still very different from RFC
4560 (in RFC 4560, test name *alone* is not unique; it's combined with
traceRouteCtlOwnerIndex, contextEngineID, and contextName).  However,
if the results are not converted from SNMP MIB, other methods
of specifying the scope might be useful (e.g. host name or IP/MAC
address or something). 

The specification of testName scope is related to one *very* 
important information element that is currently missing
from the schema: where the measurements were run. Note that
current semantics of CtlSourceAddress make it unusable for
this purpose. In RFC 4560, the scope is given by contextEngineID
and contextName (which can be used to look up more information 
from  e.g. Interfaces, IP, or Entity MIBs) -- here it needs
to be explicit.

About #6: "...some of the values (e.g. unknown, ipv4, ipv6 and dns)
excluding non-global IPv4/IPv6 addresses (e.g. ipv4z and ipv6z)" The
document needs to unambiguously define what the values are, not just
give examples. Suggested rephrasing: "The following values are
imported from [RFC4001]: (list)".

About #9: I still believe it should be possible to add new CtlTypes
without making the XML file unparseable by existing software.

My comment #23 (should have a reference about SO_DONTROUTE) 
is still valid.

Additional comments for this version:

24) The informational model has changed quite a lot in this version.
In particular, in version -08 each XML file contained results from 
a single traceroute measurement, while it seems in -09 several
measurements (with their own TestName, target address, etc.) can 
be included, as long as they share the same parameters.

Is this an intentional change that resulted from WG identifying a new
requirement, or just an accident in schema editing?  (Having just
single measurement run makes this simpler, so unless this is really 
an important requirement, I'd suggest not adding features of this
magnitude at this stage.)

25) _RequestMetadata has a number of elements with minOccurs="0", but
the informational model doesn't describe the semantics of omitting the
element. (Note that RFC 4560 does specify the default value for almost
all of these.)

26) the definition of "inetAddress" type in XML schema doesn't match
the information model in Section 5.

27) "UnsignedByte" is not right data type for CtlIfIndex.

28) "ProbeRoundTripTime" / "_roundTripTime" data type/restrictions
is not aligned with RFC 4560. 

Best regards,
Pasi

> Sent: 04 March, 2008 14:42
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]; Eggert 
> Lars (Nokia-NRC/Helsinki)
> >    <DigestMethod 
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> >

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 05 Mar 2008 12:08:06 +0100

Hi all,

Without going into the specifics.

Do you think that there would be mileage if we tried to set up a short
meeting with (some subset of) the authors of the draft, (some subset of)
the gen-art team and (some subset of) the IPPM chairs.  Goal would be to
get all the remaining issues on the table, discuss things that need to
be discussed and find solutions that are acceptable for everybody.  My
gut feeling is that trying to continue to do this by email isn't the
most efficient way to accomplish something.

If so, please indicate who is available (at all, or some days) and I'll
set something up.

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

---

From: "Saverio Niccolini" <[email-masked]>
Date: Wed, 5 Mar 2008 12:21:18 +0100

Hi Pasi,

for face to face meeting:
Thomas will be at the IETF, I will not attend this time.

In the meantime i have tried to answer your comments and provided an
updated version.

> 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 but I wanted to check if there are additional
comments on the schema before producing an XML file in the appendix
for it. And I was right, you have more :-)

> About #5: TestName uniqueness/scope is still very different 
> from RFC 4560 (in RFC 4560, test name *alone* is not unique; 
> it's combined with traceRouteCtlOwnerIndex, contextEngineID, 
> and contextName).  However, if the results are not converted 
> from SNMP MIB, other methods of specifying the scope might be 
> useful (e.g. host name or IP/MAC address or something). 
> 
> important information element that is currently missing from 
> the schema: where the measurements were run. Note that 
> this purpose. In RFC 4560, the scope is given by 
> contextEngineID and contextName (which can be used to look up 
> more information from  e.g. Interfaces, IP, or Entity MIBs) 
> -- here it needs to be explicit.

We can not make the scope the same as RFC 4560, we can jsut choose it
as if it was chosen in accordance with RFC 4560 since the constructs
contextEngineID and contextName are MIB-specific.
We discussed this and we think this is the best way of solving it, if
you have a concrete suggestion we are ready to implement it.

> About #6: "...some of the values (e.g. unknown, ipv4, ipv6 
> and dns) excluding non-global IPv4/IPv6 addresses (e.g. ipv4z 
> and ipv6z)" The document needs to unambiguously define what 
> the values are, not just give examples. Suggested rephrasing: 
> "The following values are imported from [RFC4001]: (list)".

Done. See attached.

> About #9: I still believe it should be possible to add new 
> CtlTypes without making the XML file unparseable by existing software.

We think differently and that is why we added the following sentence:
" It specifies if the traceroute is using TCP,
UDP, ICMP or others type of probes.
If these needs to be extended then a new
schema needs to be defined with re-definitions
of CtlType and related response status."
We do not see other way out of it.

> My comment #23 (should have a reference about SO_DONTROUTE) 

I have added the sentence:
"This object can be used when the setsockopt
SOL_SOCKET SO_DONTROUTE option is supported
and set."
I hope this is specific enough
 
> In particular, in version -08 each XML file contained results 
> from a single traceroute measurement, while it seems in -09 
> several measurements (with their own TestName, target 
> address, etc.) can be included, as long as they share the 
> same parameters.
> 
> Is this an intentional change that resulted from WG 
> identifying a new requirement, or just an accident in schema 
> editing?  (Having just single measurement run makes this 
> simpler, so unless this is really an important requirement, 
> I'd suggest not adding features of this magnitude at this stage.)

I think it is an important requirement and was an error not to
be included from the beginning, that is why we changed it now
that we re-designed the schema

> 25) _RequestMetadata has a number of elements with 
> minOccurs="0", but the informational model doesn't describe 
> the semantics of omitting the element. (Note that RFC 4560 
> does specify the default value for almost all of these.)

I have added a sentence:
"If the "RequestMetadata" element is omitted from an XML file then it means that the traceroute measurement
configuration parameters requested were all used and the "MeasurementMetadata" element list them in detail."

> 26) the definition of "inetAddress" type in XML schema 
> doesn't match the information model in Section 5.

Section 5 says:
"InetAddress - The type "InetAddress" denotes a generic Internet address.
The allowed values are imported from <xref target="RFC4001"/>
(the values imported are unknown, ipv4, ipv6 and dns), while non-global IPv4/IPv6
addresses (e.g. ipv4z and ipv6z)were ecluded; an additional allowed value is the
AS number to be indicated as the actual number plus the indication how the mapping
from IP address to AS number was performed. "unknown" is used to indicate an IP
address that is not in one of the formats defined."

and the schema defines:

inetAddressUnknown
inetAddressIpv4
inetAddressIpv6
inetAddressASNumber
inetAddressDns

I think it matches.

> 27) "UnsignedByte" is not right data type for CtlIfIndex.

changed to UnsignedInt

> 28) "ProbeRoundTripTime" / "_roundTripTime" data 
> type/restrictions is not aligned with RFC 4560. 

That does not mean it is wrong :-)

Attached the version for checking, once we get the ok we can write the XML example file
as requested.

Cheers,
Saverio

> > we hope to have addressed all the coments that were raised 
> so far in 
> > the attached version.
> > 
> > Due to the comments on style issues raised by Pasi, we 
> asked Thomas to 
> > re-design the schema in a more XML-friendly and readable way, the 
> > version -09 includes the new schema.
> > 
> > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
> > London W3 6BL Registered in England 2832014
> >  
> >   
> > 
> > > > -- style issues for the XML schema that we are going to address 
> > > > soon (hopefully before IETF still), Thomas offered to help.
> > > > 
> > > 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 
> > > 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 
> 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
> > > (instead of, say, "<DigestMethod>sha1</DigestMethod>"). In this 
> > > schema, a similar approach would be:
> > > 
> > > 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>
> > > 
> > > 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>
> > > Note that #21 is not a style comment, but a simple bug (typo in 
> > > schema).
> > > 
> > > Best regards,
> > > Pasi
> > > 
> > 
>

---

From: <[email-masked]>
Date: Wed, 5 Mar 2008 14:02:06 +0200

Saverio Niccolini wrote:

> We can not make the scope the same as RFC 4560, we can jsut choose
> it as if it was chosen in accordance with RFC 4560 since the
> constructs contextEngineID and contextName are MIB-specific.  We
> discussed this and we think this is the best way of solving it, if

Well... let me ask it this way: when you get an XML file containing
results from a traceroute run, do you think it's important to know 
on which host the measurement was run on?

(I think it would be -- but if the WG consensus is that this
information is unimportant, then at least the document needs to
explain this quite surprising omission, and Appendix C needs
to describe this big difference to RFC 4560.)

> " It specifies if the traceroute is using TCP, UDP, ICMP or others
> type of probes.  If these needs to be extended then a new schema
> needs to be defined with re-definitions of CtlType and related
> response status."

Could you explain in more detail what you mean by "we do not see 
other way of of it"?

> I have added the sentence: "This object can be used when the
> setsockopt SOL_SOCKET SO_DONTROUTE option is supported and set."  I
> hope this is specific enough

I was hoping for a reference to a document.

> that we re-designed the schema

I think you need to check this with your AD, as you need
to make sure you have WG consensus behind this change.

Also, are you quite sure that the contents of MeasurementResult
element (1..2550 ProbeResults elements and 0..255
ResultsHopRawOutputData 
elements) is correct? Or should this be exactly 1 ProbeResults element?
(Given that a single ProbeResults contains 1..255 hop elements, and 
each hop element can contain 1..10 probe elements?)

> I have added a sentence: "If the "RequestMetadata" element is
> omitted from an XML file then it means that the traceroute
> measurement configuration parameters requested were all used 
> and the "MeasurementMetadata" element list them in detail."

My concern was omitting child elements of RequestMetadata, such 
as CtlBypassRouteTable, CtlProbeDataSize, etc.

> Section 5 says: "InetAddress - The type "InetAddress" denotes a
> generic Internet address.  The allowed values are imported from
> <xref target="RFC4001"/> (the values imported are unknown, ipv4,
> ipv6 and dns), while non-global IPv4/IPv6 addresses (e.g. ipv4z and
> ipv6z)were ecluded; an additional allowed value is the AS number to
> be indicated as the actual number plus the indication how the
> mapping from IP address to AS number was performed. "unknown" is
> used to indicate an IP address that is not in one of the formats
> defined."
> 
> and the schema defines:
> 
> inetAddressUnknown
> inetAddressIpv4
> inetAddressIpv6
> inetAddressASNumber
> inetAddressDns
> 
> I think it matches.

No, it doesn't: in the information model, "InetAddress" is exactly 
one of (unknown, ipv4, ipv6, dns, asnumber, unknown). In the schema, 
it can contain *both* ipv4 address and dns name (since the 
inetAddressDns element is outside the xs:choice group). 

> That does not mean it is wrong :-)

No, but it means that RFC 4560 information can't be necessarily
converted to XML. If this is intentional, it should be mentioned
in Appendix C.

Best regards,
Pasi

---

From: Lars Eggert <[email-masked]>
Date: Wed, 5 Mar 2008 13:21:12 +0000

> to make sure you have WG consensus behind this change.

Let's wait until we have agreement on a set of changes before worrying  
about whether we need to rerun WG or IETF last call. (The magnitude of  
the changes currently makes me lean towards a rerun.)

Lars

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 05 Mar 2008 16:21:45 +0100

> the changes currently makes me lean towards a rerun.)

So do I, but I like to see a document that passes the gen-art first.

Henk

---

From: Lars Eggert <[email-masked]>
Date: Wed, 26 Mar 2008 14:42:46 +0200

> So do I, but I like to see a document that passes the gen-art first.

Agreed. Authors, please inform us of your timeline for having revises  
this document accordingly?

Lars

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 1 Apr 2008 06:50:59 +0200

Actually I thought there was going to be a meeting at the IETF
to clarify the issue that Pasi still has with the current version,
but I was not there and it seems nobody followed up on that :-(

I think I am not clear on some of the points still open since
on our side we think we addressed them and on his side there
are some request pending.

Can we make a summary of the open points that need to be addressed
for the GEN-Art review to be passed and we can try to find an 
agreement?

Saverio

> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Wednesday, March 26, 2008 1:43 PM
> To: ext Henk Uijterwaal
> Cc: Eronen Pasi (Nokia-NRC/Helsinki); Saverio Niccolini; 
> [email-masked]; [email-masked]; Sandra Tartarelli; 
> Subject: Re: Gen-ART review of 
> Agreed. Authors, please inform us of your timeline for having 
> revises this document accordingly?
> 
> Lars
>

---

From: Lars Eggert <[email-masked]>
Date: Mon, 31 Mar 2008 22:24:14 -0700

> for the GEN-Art review to be passed and we can try to find an

I think the ball is in your court. Pasi sent an email at March 5 that  
tried to clarify his concerns that hasn't been responded to.

(And I'm not saying that all points in the gen-art review need to be  
addressed for this draft to proceed, but the issues - to me at least -  
sounded valid, so I'd like to hear a good reason for not addressing  
some of them.)

Lars