A URN Namespace for ucode
draft-ishikawa-yrpunl-ucode-urn-03

[Ballot comment]
- If "Applications that use ucode take advantage of the Internet
extensively" is true, then what applications are those and why
are there no references to them? Adding some text from the
excellent mail from the authors would be good,

- What is a "small user"?

[Ballot discuss]
(updated discuss as per mail discussion)

- Is the the first occurrence of the "Internet of Things"
marketing/fund-raising buzzword in an RFC? If so, then maybe we
should discourage that? In any case, please add or reference
a definition that makes technical sense or avoid the
(ill-defined) term.

[Ballot comment]
I agree with the concern about the term "Internet of Things". I don't
think the use of that term is needed to justify this work, and I believe
the I-D would be easier to read and more compelling if the term was left
out. It is good enough to say "ucode exists and is use din many
applications. This document provides a URN namespace for ucode to
enable its use in Internet-related devices and software."

[Ballot comment]
I agree with the concern about the term "Internet of Thigs". I don't
think the use of that term is needed to justify this work, and I believe
the I-D would be easier to read and more compelling if the term was left
out. It is good enough to say "ucode exists and is use din many
applications. This document provides a URN namespace for ucode to
enable its use in Internet-related devices and software."

[Ballot comment]
I agree with Stephen's DISCUSS that the language on IoT could be tightened up.  IoT is more of a concept than something concrete, and there are different approaches to IoT, not all of which necessarily involve ucode.

[Ballot comment]
- Can someone tell me if uidcenter.org is ok as an SDO for a
normative reference or not? I've never heard of 'em but this
may be outside my normal sphere of operation.

- Even if uidcenter.org is ok, their normaive July 28 2009 document
(with a 2010 copyright?) or white paper or working draft doesn't
seem like a very stable document as a normative reference for an
RFC.

- Even if it were, then it appears that this I-D a) repeats the
text from the [UCODE] ref - if uidcenter.org are a bona-fide SDO
why is an RFC needed that says the same thing?) and b) has no
new substantive technical content, so I'm puzzled by that.

- If "Applications that use ucode take advantage of the Internet
extensively" is true, then what applications are those and why
are there no references to them?

- What is a "small user"?

[Ballot discuss]
(updated discuss as per mail discussion)

- Is the the first occurrence of the "Internet of Things"
marketing/fund-raising buzzword in an RFC? If so, then maybe we
should discourage that? In any case, please add or reference
a definition that makes technical sense or avoid the
(ill-defined) term.

[Ballot discuss]
This is all/mostly discuss-discuss material and so really
directed at first at the AD and not authors.

- Is the the first occurrence of the "Internet of Things"
marketing/fund-raising buzzword in an RFC? If so, then maybe we
should discourage that? In any case, please add or reference
a definition that makes technical sense.

- Can someone tell me if uidcenter.org is ok as an SDO for a
normative reference or not? I've never heard of 'em but this
may be outside my normal sphere of operation.

- Even if uidcenter.org is ok, their normaive July 28 2009 document
(with a 2010 copyright?) or white paper or working draft doesn't
seem like a very stable document as a normative reference for an
RFC.

- Even if it were, then it appears that this I-D a) repeats the
text from the [UCODE] ref - if uidcenter.org are a bona-fide SDO
why is an RFC needed that says the same thing?) and b) has no
new substantive technical content, so I'm puzzled by that.

- If "Applications that use ucode take advantage of the Internet
extensively" is true, then what applications are those and why
are there no references to them?

- What is a "small user"?

IANA understands that, upon approval of this document, there will be a
single action which IANA must complete.

In the Formal URN Namespaces registry of the Uniform Resource Names
(URN) Namespaces registry located at:

http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml

IANA will add a new URN as follows:

URN Namespace: ucode
Value [ tbd ]
Reference: [ RFC-to-be ]

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (A URN Namespace For The ucode) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'A URN Namespace For The ucode'
  as an Informational RFC

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@ietf.org mailing lists by 2012-02-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes a URN (Uniform Resource Name) namespace for
  ucode, an identifier system for objects and places,  used in various
  applications for the ubiquitous computing or the Internet of Things.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ishikawa-yrpunl-ucode-urn/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ishikawa-yrpunl-ucode-urn/


No IPR declarations have been submitted directly on this I-D.

The shepherd writeup follows.

###

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the document
        and, in particular, does he or she believe this version is ready
        for forwarding to the IESG for publication?

I, Peter Saint-Andre, am the Document Shepherd.

I have personally reviewed versions -00 and -01 (current) of this
document. The feedback from my AD evaluation were addressed in -01.

  (1.b) Has the document had adequate review both from key members of
        the interested community and others? Does the Document Shepherd
        have any concerns about the depth or breadth of the reviews that
        have been performed?

The document has received adequate review on the urn-nid@ietf.org list.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective, e.g.,
        security, operational complexity, someone familiar with AAA,
        internationalization or XML?

I have no such concerns.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he or
        she is uncomfortable with certain parts of the document, or has
        concerns whether there really is a need for it. In any event, if
        the interested community has discussed those issues and has
        indicated that it still wishes to advance the document, detail
        those concerns here.

I shared the concern, first raised by Ted Hardie, about restricting
the hexadecimal letters to uppercase. This concern was allayed after
discussion with the author on the urn-nid@ietf.org list.

  (1.e) How solid is the consensus of the interested community behind
        this document? Does it represent the strong concurrence of a few
        individuals, with others being silent, or does the interested
        community as a whole understand and agree with it?

It is difficult to gauge the consensus of the ucode community, but the
URN community at the IETF appears satisfied with this namespace
registration request (in general, they raise objections only if they
have concerns, to the consensus is more tacit than explicit).

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No appeals have been threatened, nor are there any areas of conflict
with regard to this registration.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
        enough; this check needs to be thorough. Has the document met all
        formal review criteria it needs to, such as the MIB Doctor, media
        type and URI type reviews?

I have checked the document using ID-nits. Version -01 passes.

The document has met all formal review criteria from RFC 3406.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that are
        not ready for advancement or are otherwise in an unclear state?
        If such normative references exist, what is the strategy for their
        completion? Are there normative references that are downward
        references, as described in [RFC3967]? If so, list these downward
        references to support the Area Director in the Last Call procedure
        for them [RFC3967].

This an informational document, but it has split its references into
normative and informative. Several of the normative references are to
UCODE-related specifications developed outside the IETF, but there is
no downward reference since this document is informational.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body of
        the document? If the document specifies protocol extensions, are
        reservations requested in appropriate IANA registries? Are the
        IANA registries clearly identified? If the document creates a new
        registry, does it define the proposed initial contents of the
        registry and an allocation procedure for future registrations?
        Does it suggested a reasonable name for the new registry? See
        [I-D.narten-iana-considerations-rfc2434bis]. If the document
        describes an Expert Review process has Shepherd conferred with the
        Responsible Area Director so that the IESG can appoint the needed
        Expert during the IESG Evaluation?

The IANA considerations section is consistent with RFC 5226 and RFC 3406.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML code,
        BNF rules, MIB definitions, etc., validate correctly in an
        automated checker?

I have verified the ABNF using the BAP parser at tools.ietf.org.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Writeup? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

Technical Summary

  This document describes a URN (Uniform Resource Name) namespace
  for ucode, an identifier system for objects and places, used in various
  applications for the ubiquitous computing or the Internet of Things.

Working Group Summary

  This document is not the product of an IETF working group.

  There was some discussion about whether it is appropriate to restrict
  ucode URNs to only uppercase hexadecimal letters.  The author noted
  that ucode string are used as XML elements in some applications, and
  that XML element names are case-sensitive, so the restriction is indeed
  appropriate.

Document Quality

  Review occurred on the urn-nid@ietf.org list, in accordance with
  RFC 3406.

Personnel

  The Document Shepherd / Responsible Area Director is
  Peter Saint-Andre.

###