Subject: RE: [Tsvwg] Last Call: draft-ietf-tsvwg-udplite-mib (MIB for the UDP-Lite protocol) to Proposed Standard

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 19 Sep 2007 21:42:52 +0200

Please find below the MIB review performed by MIB Doctor Dave Thaler. 

Dan

-------------------------------

I have completed my MIB doctor review of this document.
Comments below.

1) The RFC 2119 boilerplate is currently in section 2
   "The Internet-Standard Management Framework".  However it doesn't
   really belong there since it's not about the management framework.
   Suggest either
   a) moving it to the end of section 1, which is what RFCs 4711, 4747,
      4898, etc do, or
   b) add a terminology section, which is what RFCs 4750, 4780, 4807,
etc do

2) Normative references [RFC2578] and [RFC2579] don't match what's in
   rfc-ref.txt, rfc-index.txt, or
http://ops.ietf.org/mib-boilerplate.html
   (Specifically, the use of "Ed.,")

3) The IANA Considerations section (section 5) doesn't follow the
   boilerplate in RFC 4181 section 3.5.2, although it does contain
   the Editor's Note portion from there.  Instead, a slight variation
   of the rest appears up in section 2 ("The Internet-Standard
Management
   Framework") rather than the IANA Considerations section.  Not sure
   why this approach is being taken.

4) The INET-ADDRESS-MIB is IMPORTed but RFC 4001 is not listed as a
   normative reference.  (See RFC 4898 for an example of the preferred
   convention.)

5) The abbreviated copyright statement in the MODULE-IDENTITY still
   says "The Internet Society" rather than "The IETF Trust"

6) Terminology: the document should be referred to as a "MIB module"
   rather than a "MIB" in regular text.  Many occurrences.  For example:

   > This document specifies a Management Information Base (MIB) for the

   should be

   > This document specifies a Management Information Base (MIB) module
   > for the

7) Abstract contains references to RFC numbers enclosed in parens.  I
   am not sure whether this qualifies as "references" in the abstract.
   However, I believe they can be omitted without loss of clarity or
   information (the references are in the Introduction).

8) Technical nit:
   > The interface of UDP-Lite differs from that of UDP by the addition
of
   > a single (socket) option, which communicates a length value.  At
the

   The use of sockets (as opposed to some other paradigm) is a
particular
   implementation choice, not something required by UDP-Lite or the MIB.

   If someone chooses to implement UDP-Lite without sockets per se,
   this document should still apply.

9) Section 1.3 states:
   > On the sending side, OutDatagrams and OutPartialCov are observed.
If
   > both values are equal, no partial coverage is employed.

   However, OutPartialCov was defined as the number of datagrams with
   partial coverage.  Hence the above statement appears to be wrong.

10) Figure 1 is somewhat confusing since some labels are counter names
    and some are not, and they cannot be easily distinguished.
Furthermore
    it is unclear whether "InDatagrams" is a branch off the main line,
or
    a label on the + in the main line.  From reading the definition,
it's
    the former, but the diagram confuses this.

    Compare the table in RFC 3635 section 3.2.6 which is much more
clear.

11) DESCRIPTION of udpliteInBadChecksum says:
    > ... This includes illegal checksum
    > coverage values (as defined in RFC 3828), as their use
    > would lead to incorrect checksums.

    Would be good to replace the "(as defined in RFC 3838)" phrase
    with a REFERENCE clause that points specifically to RFC 3838 section
3.1.

12) Typo in DESCRIPTION of udpliteOutPartialCov:
    "udpliteOutdatagrams" should be "udpliteOutDatagrams"
                                               ^
13) Typo in DESCRIPTION of udpliteEndpointTable:
    "In all cases where the remote is a wildcard, the"

    Insert "address" after "remote".

14) Regarding the DESCRIPTION of udpliteEndpointInstance:

    > The object value should be obtained from a counter that
    > increments each time a new UDP-Lite endpoint is created.
    > Once the counter wraps around, care must be taken to
    > ensure that newly created indices are unique."

    The above text doesn't appear in the UDP MIB, and I believe this may
    be problematic.  Once it wraps, you have to use a mechanism other
than
    a simple counter.  Hence I don't see the value in suggesting a
counter.
    If an implementation has to have another mechanism then it may want
    to use that mechanism initially rather than using a counter and then
    switching to it after a wrap.  The existing text hence requires
    additional complexity in an implementation which does not appear to
    be warranted, especially since the use of this object is no
different
    from the equivalent UDP MIB object which has no such text.

15) Regarding the DESCRIPTION of udpliteEndpointProcess:

    > The system's process ID for the process associated with
    > this endpoint, or zero if there is no such process.

    As noted in
http://tools.ietf.org/html/draft-persson-v6ops-mib-issue-01
    there is no such thing in general as "the" process.
    The equivalent text in the UDP MIB is also broken, as it notes.
    _Which_ process should be reported in this object?

    Should the agent arbitrarily pick any one process from those that
    have the endpoint?  Some guidance is needed here for how the agent
    should implement this object (if the object is kept at all), since
    it doesn't match the normal sockets model.

16) Grammar in DESCRIPTION of udpliteEndpointMinCoverage:

    > "The minimum checksum coverage expected by this endpoint.
    > (as defined in RFC 3828).  If set to 0, only fully

    Delete period after "endpoint" or else move the parenthetical
statement
    to a REFERENCE clause.

17) The document is a WG document but does not follow the requirement
    in RFC 4181 section 4.5:

    > - If the module was developed by an IETF working group, then the
    >   ORGANIZATION clause MUST provide the full name of the working
    >   group, and the CONTACT-INFO clause MUST include working group
    >   mailing list information.  The CONTACT-INFO clause SHOULD also
    >   provide a pointer to the working group's web page.

-Dave

-------------------------------

> -----Original Message-----
> From: The IESG [mailto:[email-masked]] 
> Sent: Wednesday, September 12, 2007 10:16 PM
> To: IETF-Announce
> Cc: [email-masked]
> Subject: [Tsvwg] Last Call: draft-ietf-tsvwg-udplite-mib (MIB 
> for the UDP-Lite protocol) to Proposed Standard 
> 
> The IESG has received a request from the Transport Area 
> Working Group WG
> (tsvwg) to consider the following document:
> 
> - 'MIB for the UDP-Lite protocol '
>    <draft-ietf-tsvwg-udplite-mib-01.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and 
> solicits final comments on this action.  Please send 
> substantive comments to the [email-masked] mailing lists by 
> 2007-09-26. Exceptionally, comments may be sent to 
> [email-masked] instead. In either case, please retain the 
> beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udplite-m
> ib-01.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_id&dTag=16141&rfc_flag=0
> 
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf