Information Model and XML Data Model for Traceroute Measurements
RFC 5388

Note: This ballot was opened for revision 12 and is now closed.

(David Ward) Discuss

Discuss (2008-10-28)
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?

(Lars Eggert) Yes

(Jari Arkko) No Objection

Comment (2008-08-14 for -)
No email
send info
I support Dan's Discuss.

(Ron Bonica) No Objection

Comment (2008-08-13 for -)
No email
send info
support dan's discuss

(Ross Callon) No Objection

(Pasi Eronen) No Objection

(Russ Housley) No Objection

(Cullen Jennings) (was Discuss, No Record, Discuss) No Objection

(Chris Newman) (was Discuss) No Objection

Comment (2008-10-16)
No email
send info
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.

(Tim Polk) No Objection

Comment (2008-08-12 for -)
No email
send info
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?

(Dan Romascanu) (was Discuss) No Objection

Comment (2008-08-14)
No email
send info
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.