Subject: Re: Last Call: draft-mcwalter-uri-mib (Uniform Resource Identifier (URI) MIB) to Proposed Standard

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Feb 2007 10:43:50 -0500

The title of this document is very confusing and should be revised to
include the string textual convention.

Seeing this last call announcement I was very puzzled why anyone
thought it would be a good idea to hae a MIB for monitoring and
managing all the URIs on a managed system.  I was gratified to find
that this is not what the document was about.

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

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 9 Feb 2007 11:40:07 -0800 (PST)

> that this is not what the document was about.

I strongly agree with the above comments.  For the title I would 
recommend:

Textual Conventions for Representing Uniform Resource Identifiers 
(URIs)

In the same vein, I would recommend URI-TC-MIB for the module name 
and uriTcMIB for the descriptor representing the MODULE-IDENTITY 
value.  Note that these recommendations are consistent with the 
(non-binding) advice in Appendix C of RFC 4181 (the MIB review 
guidelines).

//cmh

---

From: Larry Masinter <[email-masked]>
Date: Thu, 8 Feb 2007 20:03:47 -0800

RFC 3986 contains a (brief) description of security considerations
for agents that produce or receive and interpret URIs. I would expect
this document to at the very least reference those security considerations
more explicitly, and at best to analyze how they apply in particular
to URIs used within SNMP.

It's not clear whether it makes sense for SNMP URIs to contain,
for example, 'data:' URIs or 'urn:' or any of a number of schemes,
and I would expect some discussion about the applicability of
URIs within a SNMP context.

URIs are defined as a sequence of characters, not a sequence of
octets. The mapping should be explicit (e.g., 'use US-ASCII') and not
implicit.

In practice, many systems allow and produce IRIs (RFC 3987)
and not URIs, to allow for accents and non-roman scripts. I wonder
if it would be more appropriate to define the MIB value as an IRI
encoded in UTF-8, for example.

Larry

> -----Original Message-----
> From: The IESG [mailto:[email-masked]] 
> Sent: Thursday, February 08, 2007 3:02 PM
> To: IETF-Announce
> Cc: [email-masked]; [email-masked]
> 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
> [email-masked] mailing lists by 2007-03-08. 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-mcwalter-uri-mib-02.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
w_id&dTag=15468&rfc_flag=0
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 23 Feb 2007 14:00:49 -0000

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" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
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:
>
> final comments on this action.  Please send substantive comments to the
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15468&rfc_flag=0
>
>

---

From: "Bill Fenner" <[email-masked]>
Date: Fri, 23 Feb 2007 14:31:06 -0800

> Ditto RFC3305, RFC3414, and RFC3415.

Sorry, this one is my fault - I generate a set of include files for
xml2rfc that has nearly all of the info that I know about a document,
which I built to try to help me notice (if I ever read the references
section of my own documents) when I've accidentally referred to an I-D
that's been published or obsoleted, etc etc.  David used them (I'm
actually a bit curious how, I do make them available for rsync but I
didn't think I had told anyone about that) and so got the extra info.

He's taken kind of a beating for it so I feel particularly bad.

  Bill