Information Model and XML Data Model for Traceroute Measurements
draft-ietf-ippm-storetraceroutes-12
Discuss
Yes
(Lars Eggert)
No Objection
(Cullen Jennings)
(Pasi Eronen)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 12 and is now closed.
David Ward Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2008-10-28)
Unknown
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 Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
(was Discuss)
No Objection
No Objection
(2008-10-16)
Unknown
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.
Cullen Jennings Former IESG member
(was Discuss, No Record, Discuss)
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
(was Discuss)
No Objection
No Objection
(2008-08-14)
Unknown
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.
Jari Arkko Former IESG member
No Objection
No Objection
(2008-08-14)
Unknown
I support Dan's Discuss.
Pasi Eronen Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(2008-08-13)
Unknown
support dan's discuss
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2008-08-12)
Unknown
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?