Hi,
A few further comments on this I-D.
In general, a quick inspection of RFC4181 is advisable (especially section
3) as this I-D does not appear to be compliant in several cases.
===
The Abstract contains a citation. This should be avoided as the Abstract
should be able to stand alone. Better to include the RFC number and full
name.
===
The Introduction seems rather skimpy.
This would be a good place to present an overview of the content of the MIB
module and, in particular, a discussion of the text in the Description
clauses with some guidance on how to choose between the three TCs that are
defined.
Answers to the points raised by other reviewers might also go in this
section.
===
The comments in the Imports clause helpfully indicate the RFCs from which
the imports come, but the referenced RFCs should not appear in square
brackets, they are not citations since the MIB model may be extracted from
the document and stand alone.
===
All three Description clauses contain "...MUST be a normalized as
defined..."
This should read "...MUST be normalized as defined..."
===
All three Reference clauses are a bit lazy. It is normal to include the full
reference details (as extracted from section 7) since the MIB module may be
extracted from the document and stand alone.
===
The Description clauses for Uri255 and Uri1024 contain "...impose an
arbitrary length limit..."
Is the length limit here really arbitrary? An arbitrary length limit could,
in fact, be applied with the Uri TC.
In fact it seems that the imposition of the length limit will be far from
arbitrary, but will be designed so that the upper bound of the length of an
object with Syntax Uri255 or Uri1024 is well known.
Maybe just strike the word "arbitrary"?
Maybe give some additional explanation of why a length limit might be
applied (see my request for guidance on the choice between the TCs to be
included in the Introduction).
===
The reference to RFC3986 includes "..., Was Internet-Draft ...." It is
unusual to include reference to the I-D that has subsequently become an RFC.
Probably best just to leave this text out.
Ditto RFC3305, RFC3414, and RFC3415.
===
RFC3305 is included in the references but no reference is made to it. Either
delete it or include a reference. But I suspect a reference is needed so
that its use in Reference clauses can be matched. That usage would tend to
make this a Normative reference, which is a small problem for an
Informational RFC.
===
Adrian
----- Original Message -----
From: "The IESG" <iesg-secretary(_at_)ietf(_dot_)org>
To: "IETF-Announce" <ietf-announce(_at_)ietf(_dot_)org>
Cc: <uri-review(_at_)ietf(_dot_)org>; <uri(_at_)w3(_dot_)org>
Sent: Thursday, February 08, 2007 11:02 PM
Subject: Last Call: draft-mcwalter-uri-mib (Uniform Resource Identifier
(URI) MIB) to Proposed Standard
The IESG has received a request from an individual submitter to consider
the following document:
- 'Uniform Resource Identifier (URI) MIB '
<draft-mcwalter-uri-mib-02.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-03-08. 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-mcwalter-uri-mib-02.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15468&rfc_flag=0
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf