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:iesg-secretary(_at_)ietf(_dot_)org]
Sent: Wednesday, September 12, 2007 10:16 PM
To: IETF-Announce
Cc: tsvwg(_at_)ietf(_dot_)org
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 ietf(_at_)ietf(_dot_)org mailing lists by
2007-09-26. Exceptionally, comments may be sent to
iesg(_at_)ietf(_dot_)org 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf