Information Model and XML Data Model for Traceroute Measurements
draft-ietf-ippm-storetraceroutes-12

[Ballot discuss]
DISCUSS DISCUSS

There is no mention of multicast traceroute. Should it be supported? What about "NANOG traceroute" and support of TOS change detection? It appears although I don't see how one gets the information that ASN can be stored (from NANOG traceroute).

Also, the appendix has default options for common "host" operating systems and not networking nodes (where traceroute is often run), should we broaden this?

[Ballot comment]
This revision was good enough to resolve my discuss.  But one nit that
I recommend correcting.  There is no "dateTime" defined in the [XML]
reference you provide (so you might be sending people looking in a
specification which doesn't have the information they're looking to
find).  The "dateType" XML Schema data type is defined
in this document (XML Schema 1.1 part 2):

  http://www.w3.org/TR/2008/WD-xmlschema11-2-20080620/#dateTime

restricting it to the syntax in RFC 3339, is good enough.  The primary
difference being that RFC 3339 mandates a timezone offset while XML
Schema does not (it permits local time with an unspecified zone offset).
If you point out the difference, it might be helpful to implementers.

[Ballot discuss]
Given the explanation of the use of this, I wonder if  this would be better published as Informational RFC instead of PS due to issues around setting precedence for XML usage and scope of WG. Is there any reason we need this to be PS or could this go as Informational?

[Ballot discuss]
Given the explanation of the use of this, I think this would be better published as Informational RFC instead of PS. Is there any reason we need this to be PS or could this go as Informational?

[Ballot comment]
1. In the definition at 5.2.2.8, I would add a separate reference to [RFC2460] for the definition of the IPv6TrafficClassOctet.

2. This document proposes an informational model and an XML data model for a number of information elements, and defines an InetAddress data type. Beyond specific problems with the approach being taken by the I-D (which I included in my own DISCUSS) this raises the issue whether such generic data types,  information elements and XML schema elements should be defined in a central place, or left to the individual WGs and areas and be distinguished by their scope and naming. As a parallel, a few of these generic data types are defined in RFC 4001 for SMIv2.

I do not think that this document should be stopped because of this generic IETF modelling issue. Maybe however a note should be inserted mentioning that InetAddress has no standard definition nowadays in the IETF, but may be within the scope of future work.

[Ballot discuss]
1. This document uses Unicode and UTF-8 without a normative reference.
I recommend adding the reference to STD 63 and noting that the security
considerations for STD 63 apply for these fields.  If any of the
strings can be multi-line, a reference to 5198 would be a good idea.

2. There is no "dateTime" data type defined in the XML base
specification that's referenced.  There is a "dateTime" XML Schema
data types (which you didn't reference), but that specification is
difficult for a human to read and would have to be profiled to
interoperate.  Your schema implies that's what you meant to use,
so you need a normative reference.  However, that format allows
non-interoperable partial specifications of a dateTime so it
requires further profiling.  You could reference RFC 3339 as
the subset of the XML schema 'dateTime' type that interoperates
(in particular, the timezone has to be mandatory and the year
should be fully qualified).  I suspect implementers will find
RFC 3339 simpler to read and use than:
  http://www.w3.org/TR/2008/WD-xmlschema11-2-20080620/#dateTime
and believe that's an objective statement despite my bias ;-)

3. This uses an XML schema without addressing the issues raised in
BCP 70, in particular section 4.7.  From the statement in section 6
"XML schema to be used as a template," I can make some guesses, but
you need to be a lot more precise about what sort of future
extensibility is permitted to this format.  Are processors interpreting
this format required to ignore unknown elements?  etc.

[Ballot discuss]
This is a DISCUSS DISCUSS that means I would like to talk to the ADs about it and will remove this when we get to the call. I'm having a hard time understanding why IPPM would need to standardize this so I went and read the charter and I'm not really sure this is in scope.

[Ballot comment]
A few minor nits:

Abstract

      s/results ones/results elements/

Section 8.2, paragraph 1 last sentence: the final clause ("that the operator a networks may
want to detect") is very confusing.  Perhaps "that operators of networks may want to protect"
would be clearer?

[Ballot comment]
Abstract

s/results ones/results elements/

Section 8.2, paragraph 1 last sentence: the final clause ("that the operator a networks may
want to detect") is very confusing.  Perhaps "that operators of networks may want to protect"
would be clearer?

[Ballot discuss]
1. In Section 6 the following text refers to the DISMAN-TRACEROUTE-MIB defined in RFC 4560:

  An already existing and closely related data model is the DISMAN-
  TRACEROUTE-MIB module [RFC4560], that specifies a BER encoding
  [RFC3417] used by the Simple Network Management Protocol (SNMP)
  [RFC3410] for transmitting traceroute measurement information
  (configuration and results). 

This is quite inaccurate. The text should rather refer not to 'BER encoding' but to SMIv2, and the reference should be [RFC2578], [RFC2579], and [RFC2580]. SMIv2 is supposed in theory to be used not only with SNMP so the reference to it and [RFC3410] can also be skipped.

2. I do not feel confortable with the usage of inetAddress as per RFC4001 without using inetAddressType. The following text is used in the definition of the information elements:

      The host address type can be
      determined by the examining the inetAddress type name and the
      corresponding element value.

This may work with the specific data model defined in this document, but an information model should be designed to work with multiple data models, which may not allow for the same heuristics on the type name.

3. CtlIfIndex defined in 5.2.2.8 is using value of 4294967295 in the "RequestMetadata" indicates that no specific interface is requested. I am wondering why is not zero used for this purpose, as is done for the equivalent object in RFC 4560 traceRouteCtlIfIndex (ifNumber = 0 has no significance as interface numbering and could be used for such 'special' purposes)

4. Is there not a need for an object to control frequency or interval between traceroute tests?

5. Where is defined the probesType data type used in %.2.2.16?

6. There are a number of objects defined in TraceRouteResultsTable in RFC4560 which seem to be useful, but are not present in the information model defined in this document. Specifically I am wondering why the following were not included:
- current probe count
- number of test attempts
- number of test successes

IANA Last Call comments:

Action 1:

Upon approval of this document, the IANA will make the following
assignment in the "ns" registry at
http://www.iana.org/assignments/xml-registry/ns.html

ID: traceroute-1.0
URI: urn:ietf:params:xml:ns:traceroute-1.0
Registration template: traceroute-1.0
Reference: [RFC-ippm-storetraceroutes-10]

Action 2:

Upon approval of this document, the IANA will make the following
assignment in the "schema" registry located at
http://www.iana.org/assignments/xml-registry/schema.html

ID: traceroute-1.0
URI: urn:ietf:params:xml:schema:traceroute-1.0
Filename: traceroute-1.0
Reference: [RFC-ippm-storetraceroutes-10]

We understand the above to be the only IANA Actions for this
document.

IANA Last Call comments:

Action 1:

Upon approval of this document, the IANA will make the following
assignment in the "ns" registry located at
http://www.iana.org/assignments/xml-registry/ns.html

ID URI Registration template
Reference
-- ---- --------------------
---------
traceroute-1.0 urn:ietf:params:xml:ns:traceroute-1.0 [traceroute-1.0]
[RFC-ippm-storetraceroutes-07]


Action 2:

Upon approval of this document, the IANA will make the following
assignment in the "schema" registry located at
http://www.iana.org/assignments/xml-registry/schema.html

ID URI Filename
Reference
-- ---- ---------- --
---------
traceroute-1.0 urn:ietf:params:xml:schema:traceroute-1.0 [traceroute-1.0]
[RFC-ippm-storetraceroutes-07]


We understand the above to be the only IANA Actions for this
document.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document?

Document sheperd is Henk Uijterwaal
He has reviewed the document and believes that it is ready for publication.

(1.b) Has the document had adequate review both from key WG members and from key
non-WG members?

The document has been thoroughly reviewed by Ron Bonica and Lars Eggert.
All issues raised by them have been fixed and put in the current version
of the document. They have confirmed this.

The document was sent to the XML directorate for review. Their comments
have been adressed as well.

Many members of the group contributed to the mailing list and face-to-face
discussions about this draft.

(1.c) Does the Document Shepherd have concerns that the document needs more
review from a particular or broader perspective, e.g., security,
operational complexity, someone familiar with AAA, internationalization
or XML?

No. The document is based on XML but it has already been reviewed by the
XML directorate.


(1.d) Does the Document Shepherd have any specific concerns or issues with
this document that the Responsible Area Director and/or the IESG should
be aware of?

No

(1.d2) Has an IPR disclosure related to this document been filed?

No IPR claims have been filed.


(1.e) How solid is the WG consensus behind this document?

Traceroutes are being used by many people doing network measurements
and there is support from them for storing traceroutes. This document
has their support. There has already been 1 posting suggesting further
work using this draft as a basis.

The XML hasn't been checked extensively inside the group due to a lack
of knowledge in the group.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent?

No

(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits?

The document has been checked with the ID nits tool. It does
generate a couple of warnings but these seem to be caused by the
fact that the tool mistakes XML code for references.

The XML code has been checked with xmllint.


(1.h) Has the document split its references into normative and informative?

Yes

(1.h2) Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear state?

No

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document?

The IANA section exists and makes the correct requests.


(1.j) Has the Document Shepherd
verified that sections of the document that are written in a formal language,
such as XML code, BNF rules, MIB definitions, etc., validate correctly in an
automated checker?

The XML code has been checked with xmllint by me and compiles fine.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document Announcement Write-Up?



Technical Summary

This document describes a standard way to store the configuration and
the results of traceroute measurements. This document first of all
describes the tool itself; afterwards, the common information model
is defined dividing the information elements in two semantically
separated groups (configuration elements and results ones). Moreover
an additional element is defined to relate configuration elements and
results ones by means of a common unique identifier. On the basis of
the information model a data model based on XML is defined to store
the results of traceroute measurements.



Working Group Summary

The working group has supported the document throughout its life
and it has been uncontroversial.


Document Quality
The document has been given thorough review by the group over its
revisions. The XML code has been reviewed by the XML directorate.


Personnel
Document Shepherd: Henk Uijterwaal
Responsible Area Director: Lars Eggert