[ippm] AD review: draft-ietf-ippm-storetraceroutes-03

Summary: Not ready.

----------------------------------------------------------------------
MAJOR ISSUES:

Section 2., paragraph 0:
 >   2.  Definition of Traceroute

   This section needs to become more formal in describing how traceroute
   operates and needs to define some precise terminology, which the rest
   of the document should then refer to and be based on. Currently, the
   document uses various terms in different places, and it is unclear
   what they mean. Examples: traceroute probe, running traceroute,
   traceroute measurements, packets traceroute sends out, traceroute
   command, traceroute operation, traceroute test, traceroute request,
   etc.

Section 2.1., paragraph 1:
 >    In order to define an information model for storing  
traceroutes, we
 >    first investigated which configuration parameters are relevant  
when
 >    running traceroute.

   The remainder of this section doesn't discuss at all which
   configuration parameters are relevant; it only lists some defaults on
   various platforms. At best, it illustrates that the defaults vary
   widely. This should go into an appendix (if anywhere), and the  
missing
   discussion should be added.

Section 4., paragraph 4:
 >    It might happen that some probes do not receive a response  
within the
 >    configured time-out (for instance if the probe is filtered out  
by a
 >    firewall).  In this case, an "*" is displayed in place of the RTT.

   I think I remember that some implementations print the same line
   multiple times when a router decreases the TTL by more than one, and
   thus look like multiple hops. How does that impact the info model?

Section 7., paragraph 0:
 >  7.  XML Schema for traceroute Measurements

   XML doesn't validate.

   Make sure annotation text is identical to
   Section 5 info model description text.

Section 1., paragraph 0:
 >    1.  Registration request for the IPPM traceroute measurements
 >        namespace
 >        *  URI: urn:ietf:params:xml:ns:traceroute-1.0
 >        *  Registrant Contact: TBD.

   Registrant Contact needs to be specified.

Section 2., paragraph 0:
 >    2.  Registration request for the IPPM traceroute measurements  
schema
 >        *  URI: urn:ietf:params:xml:schema:traceroute-1.0
 >        *  Registrant Contact: TBD.

   Registrant Contact needs to be specified.

----------------------------------------------------------------------
COMMENTS:

Section 1., paragraph 2:
 >    The
 >    standard metrics defined by IPPM working group in matter of delay,
 >    connectivity and losses do not apply to the metrics returned by  
the
 >    traceroute tool; therefore, in order to compare results of  
traceroute
 >    measurements, the solution is to add to the stored results a
 >    specification of the operating system and version for the tool  
used.

   Adding this meta-data still doesn't make traceroute results  
comparable
   to the other IPPM metrics, so it's not a "solution".

Section 1., paragraph 3:
 >    These are
 >    the motivations that moved the authors to write this draft in the
 >    context of the IPPM working group even if other working groups  
(like
 >    DISMAN) have already addressed similar issues related to the
 >    definition of the MIB for configuring and retrieving traceroute
 >    measurements results.

   Author motivation is superfluous.

Section 2., paragraph 1:
 >    Traceroute can therefore be used to
 >    discover where and how a host is connected to the Internet and  
can be
 >    usefully employed to troubleshoot network connections.

   "Where a host is connected to the Internet" and especially "how a  
host
   is connected to the Internet" is inaccurate. What traceroute gives  
you
   is some information (hop count, delays) about the path between
   yourself and other hosts, i.e, the information depends on the
   initiator of the traceroute.

Section 3.1., paragraph 0:
 >   3.1.  Accuracy of Results

   Misleading title. Section is not about whether the results are
   accurate, it's about whether they are comparable between different
   traceroute versions and the IPPM metrics.

Section 3.1., paragraph 1:
 >    A known inconsistency exists between the round-trip delay metric
 >    defined by the IPPM working group and the results returned by the
 >    current traceroute implementations.  Unfortunately, it is unlikely
 >    that the traceroute implementations will implement the standard
 >    definition in the near future.  In order to compare results of
 >    different traceroute measurements, specifications both of the
 >    operating system (name and version) and of the traceroute tool
 >    version used are added to the metadata elements in order to  
help in
 >    comparing metrics.

   How does that meta-information help comparing? It seems that all it
   may let you do is avoid comparing results taken under different
   configurations.

Section 3.1., paragraph 2:
 >    Moreover, the traceroute has built-in
 >    configurable mechanisms like time-outs and can experience problems
 >    related to the crossing of firewalls; therefore some of the  
packets
 >    that traceroute sends out end up being time-out or filtered.  As a
 >    consequence, it might not be possible to trace the path to a  
node or
 >    there might not be a complete set of probes describing the RTT to
 >    reach it.

   How is that reflected in the info model?

Section 3.2., paragraph 0:
 >   3.2.  Alternative traceroute Implementations

   This section seems to belong logically to the content discussed at  
the
   end of Section 2, where traceroute flavors are discussed. Suggest to
   move it there.

Section 3.2., paragraph 4:
 >    traceroutes is outside the scope of this draft, therefore in the
 >    sequel, we will restrict our focus to the most commonly  
implemented
 >    UDP based traceroute.

   But the info model in Section 5 apparently covers TCP-based
   traceroutes?

Section 5.1., paragraph 4:
 >    o  Unsigned32 - The type "Unsigned32" represents a value in the  
range
 >       (0..4294967295).

   Various objects below are more accurately described by Unsigned16 or
   Unsigned8 types.

Section 5.2.1.1., paragraph 1:
 >    o  description - Specifies the type of host address used in the
 >       traceroute command.

   s/host/destination/ (the destination may be a router - check term
   throughout the document)

Section 5.2.1.4., paragraph 1:
 >    o  description - Specifies the size of the data portion of a
 >       traceroute operation in octets.

   inaccurate - s/data portion/probe payload/

Section 5.2.1.5., paragraph 1:
 >    o  description - Specifies the time-out value, in seconds, for the
 >       traceroute operation.

   Unclear what this timeout controls. One probe? The entire probing
   procedure?

Section 8., paragraph 0:
 >  8.  Differences to DISMAN-TRACEROUTE-MIB

   Tangential to the core of the document. Suggest to make this an
   appendix.

Section 11.2., paragraph 8:
 >    [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
 >               Schoenwaelder, Ed., "Textual Conventions for SMIv2",
 >               STD 58, RFC 2579, April 1999.

   Needs to become normative (data types being imported).

Section 11.2., paragraph 9:
 >    [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
 >               MIB", RFC 2863, June 2000.

   Needs to become normative (data types being imported).

Section 11.2., paragraph 14:
 >    [RFC4560]  Quittek, J. and K. White, "Definitions of Managed  
Objects
 >               for Remote Ping, Traceroute, and Lookup Operations",
 >               RFC 4560, June 2006.

   Needs to become normative (data types being imported).

----------------------------------------------------------------------
NITS:

INTRODUCTION, paragraph 13:
 >    To better address the traceroute measurements storing issue, the
 >    authors first of all give a definition of the traceroute tool,

   Nit: s/the authors/this document/ (other uses of first person
   elsewhere in the document)

Section 1., paragraph 1:
 >    Since traceroute
 >    is a tool that has built-in configurable mechanisms like time-outs
 >    and can experience problems related to the crossing of  
firewalls thus
 >    experiencing fake losses or incomplete delay information.

   Nit: incomplete sentence

Section 2., paragraph 2:
 >    Typically, traceroute attemps to discover the path to a  
destination

   Nit: s/attemps/attempts/

Section 2.1., paragraph 2:
 >    (SunOS 5.9) implemetations are based on UDP datagrams, while the

   Nit: s/implemetations/implementations/

Section 2.1., paragraph 4:
 >              | FreeBSD| -n   |simbolically.                  |     
-    |

   Nit: s/|simbolically./|symbolically./

Section 2.1., paragraph 5:
 >              | LINUX  |  -   |As optional last paramater,    | 
Depends  |

   Nit: s/paramater,/parameter,/

Section 3.2., paragraph 1:
 >    As stated above, the widespred use of firewalls might prevent  
UDP or

   Nit: s/widespred/widespread/

Section 3.2., paragraph 2:
 >    for connections on.  TCP based implementations use TCP SYN or FYN

   Nit: s/FYN/FIN/

Section 3.2., paragraph 3:
 >    are not known in adavance.  A detailed analysis of TCP based

   Nit: s/adavance./advance./

Section 4., paragraph 1:
 >       at the correponding host and that the option to display only

   Nit: s/correponding/corresponding/

Section 4., paragraph 2:
 >       numerical addresses was not set;

   Nit: "Symbolic address" - I assume what is meant is domain name?

Section 4., paragraph 5:
 >    (f.i.  UNIX and LINUX) while WINDOWS tracert reports "< 1 ms".

   Nit: What does "f.i." stand for?

Section 5.1., paragraph 2:
 >       also accomodates other Unicode multibyte characters.

   Nit: s/accomodates/accommodates/
   Nit: s/multibyte/multi-byte/

Section 5.1., paragraph 3:
 >    o  TruthValue - The type "TruthValue" represents a boolean value.

   Nit: s/boolean/Boolean/

Section 5.1., paragraph 5:
 >       the need to use a milli-second resolution instead a deci-second

   Nit: s/milli-second/millisecond/
   Nit: s/deci-second/decisecond/

Section 5.2.1.3., paragraph 0:
 >   5.2.1.3.  CtlByPassRouteTable

   Nit: s/CtlByPassRouteTable/CtlBypassRouteTable/g

Section 5.2.1.4., paragraph 2:
 >       this object was computed by substracting the smallest  
possible IP

   Nit: s/substracting/subtracting/

Section 5.2.1.4., paragraph 3:
 >    o  units - octects

   Nit: s/octects/octets/

Section 5.2.1.12., paragraph 0:
 >    o  description - Specifies the inferface index used in the  
traceroute

   Nit: s/inferface/interface/

Section 6., paragraph 3:
 >    disadvantages.  Textual representions are (with some limitations)

   Nit: s/representions/representations/

Section 6., paragraph 7:
 >    other data formats.  Its disadvantages is the resource comsumption

   Nit: s/comsumption/consumption/

Section 6., paragraph 8:
 >    maintenance is not expected to be extremly high, the inefficient

   Nit: s/extremly/extremely/

Section 6., paragraph 10:
 >    Global Grid Forum (GGF) is also using this approach

   Nit: Global Grid Forum (GGF) has renamed itself to Open Grid Forum
   (OGF)

Section 6., paragraph 11:
 >    it was designed in a way that both limits the unecessary  
redundancy

   Nit: s/unecessary/unnecessary/

Section 6., paragraph 12:
 >    and a simple one-to-one trasformation between the two exist.

   Nit: s/trasformation/transformation/

Section 7., paragraph 18:
 >          substracting the smallest possible IP header size of 20

   Nit: s/substracting/subtracting/

Section 7., paragraph 19:
 >          jumbograms). Units are: octects.

   Nit: s/octects./octets./

Section 7., paragraph 26:
 >          <xs:documentation>Specifies the inferface index used in the

   Nit: s/inferface/interface/

Section 7., paragraph 48:
 >          object means that source addres specification was disabled.

   Nit: s/addres/address/

Section 8., paragraph 2:
 >    o  configuring traceroute operations to be prformed,

   Nit: s/prformed,/performed,/

Section 8., paragraph 6:
 >    and delection, status retrieval) that are not required for the  
XML-

   Nit: s/delection,/deletion,/

Section 8.1., paragraph 2:
 >    traceRoute prefix that was removed to avoid unecessary  
redundancy in

   Nit: s/unecessary/unnecessary/

Section 8.2., paragraph 2:
 >    For the traceroute strorage format, a value of 0 for element

   Nit: s/strorage/storage/

Section 8.2., paragraph 4:
 >    This was translated to the traceroute strorage format, such that a

   Nit: s/strorage/storage/

Section 9.2., paragraph 1:
 >    Traceroute results are not considered highly sensible.  Still,  
they

   Nit: s/sensible/sensitive/ :-)   (also elsewhere)

Section 11.2., paragraph 1:
 >    [I-D.ietf-disman-remops-mib-v2]
 >               Quittek, J. and K. White, "Definitions of Managed  
Objects
 >               for Remote Ping, Traceroute, and Lookup  Operations",
 >               draft-ietf-disman-remops-mib-v2-09 (work in progress),
 >               February 2006.

   Nit: Unused Reference: 'I-D.ietf-disman-remops-mib-v2' is defined,  
but
   not referenced. Also, draft-ietf-disman-remops-mib-v2 has been
   published as RFC 4560.

[ippm] AD review: draft-ietf-ippm-storetraceroutes-03

Attachment: smime.p7s