Subject: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt

From: [email-masked]
Date: Mon, 12 Mar 2012 13:20:35 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF.

	Title           : Uniform Resource Name (URN) Namespace Definition Mechanisms
	Author(s)       : Alfred Hoenes
	Filename        : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt
	Pages           : 30
	Date            : 2012-03-12

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers.  To structure and
   organize their usage, the URN syntax (RFC 2141bis) specifies a
   hierarchy that divides the set of possible URNs into "URN Namespaces"
   that can be individually defined and managed.  URN Namespaces in
   particular serve to map existing identifier systems into the URN
   system and thereby make available generic, network-based resolution
   services for the identified documents, artifacts, and other objects
   (and metadata related to them).

   To achive these goals, URN Namespaces need to be specified in a
   comparable manner, and their Namespace Identifiers (NIDs) need to be
   registered with IANA, so that naming conflicts are avoided and
   implementers of services can follow a structured approach in support
   of various namespaces, guided by the registry to the related
   documents and the particularities of specific namespaces, as
   described in these Namespace registration documents.

   This RFC serves as a guideline for authors of URN Namespace
   definition and registration documents and the process to be followed
   to register a URN Namespace with IANA.  It describes the essential
   content of such documents and how they shall be structured to allow
   readers familar with the scheme to quickly assess the properties of a
   specific URN Namespace.

   This document is a companion document to the revised URN Syntax
   specification, RFC 2141bis; it supersedes and replaces RFC 3406.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt

---

From: Leslie Daigle <[email-masked]>
Date: Sun, 25 Mar 2012 08:58:32 -0400

Hi,

Following up the editorial notes in the current draft (copied below for 
ease of reference[*]

First, to the question of the bulleted lists:  these were merely 
suggestions of dimensions in which a proposed namespace might differ 
from existing namespaces of similar syntactic structure.

These 2 sections ("namespace" and "community" considerations) were meant 
to address the basic questions of "why do you need a new namespace 
anyway?" and "is your audience broad enough that this merits an 
Internet-wide identifier scheme?".

Mostly what I've seen is that registrants don't understand the 
questions, and first drafts often don't particularly address those 
questions.   That some of the registrations may duplicate text between 
their answers in each section is, I think, more a function of that than 
a reason to conflate the 2 into one section.

Perhaps a better path would be to more clearly articulate the 
question/section requirements in ways that will be compelling to people 
who haven't been privvy to this sort of discussion.  (And, I'd send 
text, but it's my text that is clearly the problem ;-) ).

[*]
> [[ Editorial Note:
>    It is acknowledged that, in many cases, the Namespace Considerations
>    and Community Considerations are closely intertwined.  Further, the
>    bulleted lists above (from RFC 3406) seems to be more related to the
>    items in the registration template entitled "Identifier uniqueness
>    considerations", "Identifier persistence considerations", "Process of
>    identifier assignment", and "Process for identifier resolution" than
>    to the primary objectives presented in the first paragraph above
>    (also from RFC 3406).
>    In fact, Namespace registration documents seen so far duplicate in
>    the registration template material from the "Community
>    Considerations" that addresses the above bullets.
>    Therefore: Should this specification now allow a combined section
>    "Namespace and Community Considerations" that focuses on the
>    (non-)utility of possible alternate namespace re-use and the
>    *benefits* of an independent new Namespace?
>    ]]

Leslie.

On 3/12/12 4:20 PM, [email-masked] wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Leslie Daigle <[email-masked]>
Date: Sun, 25 Mar 2012 08:58:49 -0400

Hi,

This document questions the 2-week mailing list review period for formal 
namespace registrations, suggestion 4 weeks (or possibly 8).

First, that process came from what was standard/accepted practice at the 
time of writing the first document (RFC2611).  That was over a decade 
ago -- and maybe we all read mail a little more regularly then ;-)

I sort of wonder if there isn't generally a better mechanism, overall. 
What gets experts' attention these days?  Do we need an RSS feed? 
Tweets? (!).

All in all, I agree that reviews don't generally happen within 2 weeks. 
  Some of that is because the current designated expert hasn't been 
paying adequate attention, and should be replaced.  But then, authors 
don't come back quickly with updates, either, so there wind up being 
iterations before things are actually signed off.  I don't actually know 
that 4 or 8 weeks would capture that whole phase.

What I've seen (as the designated expert that needs to be replaced):

+ namespace proposals that don't  get published as I-D's
  -- Step 0:  please publish this as an I-D

+ namespace proposals that don't follow the correct version of the RFC
  -- authors need guidance about current version

+ namespace proposals that need to be cleaned up in terms of having 
reasonable explanations in the Considerations sections
  -- offer guidance and repeat

+ namespace proposals that come in through *other* IETF wgs, and never 
get put on the urn-nid mailing list
  -- need AD help to get them to the URN reviewers

What I have *not* seen, surprisingly (but pleasantly):

+ a lot of discussion about whether something really should be a URN 
namespace.  Hurrah.

Leslie.

--

---

From: Leslie Daigle <[email-masked]>
Date: Sun, 25 Mar 2012 09:00:21 -0400

Hi,

This document says:

> IETF URNbis WG                                                 A. Hoenes
> Internet-Draft                                                    TR-Sys
> Obsoletes: 3406 (if approved)                             March 12, 2012
> Intended status: BCP
> Expires: September 13, 2012

and

> 7.  Acknowledgements
>
>    This document is heavily based on RFC 3406, the authors of which are
>    cordially acknowledged.
>

I don't think this is appropriate.  The bulk of the work was done by the 
original authors/editors/WG, this is not a complete rewrite.

I believe the appropriate thing is to list the original authors (unless 
they don't want to be!), and add the new author.

This is also true for the syntax document, but I'm mentioning it here 
because I'm clearly more implicated, as lead author on both previous 
iterations of this RFC.

Leslie.

--

---

From: Alfred Hönes <[email-masked]>
Date: Sun, 25 Mar 2012 22:15:07 +0200 (MESZ)

Leslie,
thanks for your review and comments.
I'll answer the various threads separately, slightly shortening
the Subject for convenience.

> Following up the editorial notes in the current draft (copied below for

For clarity to other readers on the list:
That's in Section 4.4.2 of the draft, and another, closely related
Editorial Note is present in Section 4.4.1 of the draft.

> Internet-wide identifier scheme?".

Yes.

And every now and then, it's properties of the interested community
that impact the need for a new namespace; so registration documents
have been seen to need to explain the community aspects first
in order to discuss the first question.

> questions.   [...]

That matches my observations.

>     [...]  That some of the registrations may duplicate text between
> their answers in each section is, I think, more a function of that
> than a reason to conflate the 2 into one section.

Maybe the situation is different for already well-established (e.g.
standards-based) "foreign" namespaces seeking integration into the
URN framework vs. for newly conceived conceptional namespaces that
are looking for the "proper" way to address the needs of their
community.

> question/section requirements in ways that will be compelling to
> people  who haven't been privvy to this sort of discussion.  (And,
> I'd send text, but it's my text that is clearly the problem ;-) ).

Well, we'd appreciate if years of experience might allow you to
anyway now suggest alternate text.   :-)

But I'm happy that you seem to agree that the original bulleted
lists might better be replaced by more elaborate explanations of
what should be provided, and that it is most essential that the
two primary questions you re-stated above are thought out and
answered convincingly in a registration document.

>>    *benefits* of an independent new Namespace?

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Alfred Hönes <[email-masked]>
Date: Sun, 25 Mar 2012 22:55:54 +0200 (MESZ)

Leslie,
please see my remarks inline below.

> Hi,
>
> This document questions the 2-week mailing list review period for
> formal namespace registrations, suggestion 4 weeks (or possibly 8).
>
> paying adequate attention, and should be replaced.  [...]

I think it's essential for the process to not appear to be too much
centered on the decision-forming by the "magic" expert -- community
review and feedback should help the expert and show the prospective
registrants (communities) that there isn't a high-handed single
authority (the magic Expert) at work but that some sort of community
(IETF) consensus is emerging on what is good or less good in proposals.
Third-party reviews and feedback on the urn-nid list IMO are needed in
support of the expert, and it usually needs more time than the
previous 2 weeks admit.
If the community is not able to help the Expert within the timeframe
expected by the procedural rules, it's not the fault of the Expert,
and not a priori an indication that the Expert needs to be replaced.
It's either a problem of the community or the procedural rules, or both.
:-)

>                                           [...]  But then, authors
> iterations before things are actually signed off.  I don't actually
> know that 4 or 8 weeks would capture that whole phase.

Well, one important aspect seems to me that most individuals
participating actively in the IETF are volunteers that have a day job
to perform with varying, but frequently very high priority, and that
the decreasing participation from acedemia (at least relative to the
entire IETF community) means that there are more folks out there that
cannot dedicate time to IETF purposes at their on will.

(For comparison: I assume that many of the subscribers to the URN list
read the messages from the list, but less than a tenth of them seem
to read the documents and provide feedback.)

>   -- need AD help to get them to the URN reviewers

Section 4.3 (2nd half) of the document already says:

|  Before publication can be requested, however, the draft Namespace
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|  specification document must undergo an Expert Review process
|  [RFC5226] pursuant to the guidelines written here (as well as
|  standard RFC publication guidelines).  [...]
|  [...]
|                                                       The proposed
|  template (including a pointer to a readily available copy of the
|  registration document) should be sent to the [email-masked] mailing
                          ^^^^^^^^^^^^^^
|  list for review.  [...]
|
|  Working groups generally SHOULD seek early expert review for a
|  Namespace definition document, before they hand it over to the IESG,
|  and individual applicants are also advised to seek expert comments
|  early enough.  The aforementioned list can be contacted for informal
|  advice at any stage.

Does that need more emphasis in the draft?
For instance, do we need "SHOULD" or even "MUST" in place of the
"should" in the second sentence quoted above ?

> + a lot of discussion about whether something really should be a URN

Maybe the perceived need for third parties to seek help from some
"guide" to the IETF processes helps, and writing an I-D seems to be
seen as a significant hurdle already these days ...

Nevertheless, IIRC, there _have_ been a few cases where
"URN Namespace" vs. "URI Scheme" vs. "not in the IETF at all"
in fact has been an issue.

> ... [snip]

Kind regards,
  Alfred.

--

---

From: Alfred Hönes <[email-masked]>
Date: Mon, 26 Mar 2012 01:24:35 +0200 (MESZ)

Leslie Daigle wrote:

> I don't think this is appropriate.  The bulk of the work was done by
> the original authors/editors/WG, this is not a complete rewrite.
>
> I believe the appropriate thing is to list the original authors
> (unless they don't want to be!), and add the new author.
>

Leslie,

I'm a bit surprised that you raise this argument now (and haven't
done so much earlier).

The delineation of who should appear as an "Author" or be listed
in the "Contributors" or Acknowledgements" section of an RFC, and
-- by induction -- of an I-D, seems to be a subject of recurring
debate.

Here is the background I'm aware of:

RFC 5378 and its predecessors admit -- notwithstanding specifically
indicating-so exceptions -- the unlimited right to prepare derived
work within the IETF.  Section 5.6 (a) of BCP 78 is rather terse
on what "properly acknowledge[ing] all Contributors" means in detail.

>From the perspective of the RFC Editor, being listed on the front
page of an RFC means active participation during the final RFC Editor
processing stages; according to my limited experience, the IESG also
expects listed authors to be available for interaction during their
evaluation process of a draft (once publication is requested).
The RFC Style and Policy documents indicate that people not listed
on the front page can be acknowledged in Contributors and/or
Acknowledgements sections, which are seen as almost equivalent --
the practical difference being that people listed in a Contributors
section optionally can be shown with full contact information like
in the Authors' Address section.

Working Groups in the IETF at present seem to have divergent
policies on whom to list on the front page of their WG documents
that revise previous work.  Some seem to be very strict in only
listing active authors/editors, and that also seems to be the essence
of the RFC Editor's policy.
The (vaguely) related elaborations in the "Tao" of the IETF also seem
to be compatible with this policy (in particular the Tao points out
that WG chairs decide who is going to be listed on the front page of
WG documents).
Until the advent of a related recent thread on the wgchairs list
I haven't even been aware of successful diverging practice in other
WGs of the IETF.

The first version of the rfc2141bis draft was submitted im March 2010
and the first version of the rfc3406bis draft in November 2010.
IIRC, you have been engaged in the process leading to the formation
of the URNbis WG (but haven't been able to attend the BoF in person)
and you have attended the WG's meeting at IETF 80.
If you had indicated interest in working on the documents, I would
have been honored to work with you and have your name listed on the
front page of the rfc3406bis draft, but absent such indication,
I simply followed the examples I've seen in the past in other WGs
I've been active in, where only individuals working actively on the
documents were being listed on the front page of "bis" documents.
I also do not recall participation of the author of RFC 2141 in
URNbis-related activities or any indication of desire to participate
in the work on the rfc2141bis draft -- which of course would have
been honored as well.

As long as the work distribution remains the same as up to now,
I'd like to defer the decision on the front page listing to the
RFC Editor or eventually emerging new consensus in the IETF that
might in fact invalidate the aforementioned strict practice.

If you can commit time to actually perform work on the rfc3406bis
draft, I'll readily agree, and you'll of course be listed on the
front page of the next draft version.  Otherwise, if you would prefer
being listed in a distinct "Contributors" section -- maybe including
contact information, then please let me know.

Kind regards,
  Alfred.

--

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Mar 2012 01:45:52 +0200

> contact information, then please let me know.

Alfred, this is not accepted practice at the IETF.

Please look at, say, RFC 2616 and RFC 3986, on which Tim Berners-Lee
didn't do significant work (as far as I know), yet he was still credited
as an author. Or draft-ietf-iri-3987bis (to choose a current example),
on which Michel Suignard has not contributed actively; here again he was
active in working on RFC 3987 but not the bis document, yet he is still
credited as an author.

In my opinion it is simply disrespectful to remove the old authors when
the new documents are very much progressions of the old documents, not
complete rewrites. (Notice how the new document in the HTTPBIS WG do in
fact remove original authors like Tim Berners-Lee, because they are very
significant rewrites, not minor updates.)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Mar 2012 01:49:29 +0200

> |  Before publication can be requested, however, the draft Namespace

Alfred, I like your emphasis on the community. However, we've also found
that it helps to have a few Designated Experts who are actively
responsible for reviewing registration requests, because sometimes the
amorphous "community" does not come together to review things at all.

I think a 2-week review period is fine. That means "someone will review
your request within 2 weeks (and raise issues or tell you it looks OK".
It does not mean "we promise that all issues raised during the review
period will be solved within 2 weeks".

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Mar 2012 01:52:43 +0200

On 3/25/12 10:15 PM, Alfred � wrote:
> Leslie, thanks for your review and comments. I'll answer the
> various threads separately, slightly shortening the Subject for
> convenience.
> 
> 
>> Hi,
>> 
>> Following up the editorial notes in the current draft (copied
>> below for ease of reference[*]
> 
> For clarity to other readers on the list: That's in Section 4.4.2
> of the draft, and another, closely related Editorial Note is
> present in Section 4.4.1 of the draft.
> 
>> 
>> suggestions of dimensions in which a proposed namespace might
>> differ from existing namespaces of similar syntactic structure.
>> 
>> These 2 sections ("namespace" and "community" considerations)
>> were meant to address the basic questions of "why do you need a
>> new namespace anyway?" and "is your audience broad enough that
>> this merits an Internet-wide identifier scheme?".
> 
> Yes.
> 
> And every now and then, it's properties of the interested
> community that impact the need for a new namespace; so registration
> documents have been seen to need to explain the community aspects
> first in order to discuss the first question.
> 
>> 
>> questions, and first drafts often don't particularly address
>> those questions.   [...]
> 
>> their answers in each section is, I think, more a function of
>> that than a reason to conflate the 2 into one section.
> 
> Maybe the situation is different for already well-established
> (e.g. standards-based) "foreign" namespaces seeking integration
> into the URN framework vs. for newly conceived conceptional
> namespaces that are looking for the "proper" way to address the
> needs of their community.

In my experience as sponsoring AD for several NID registrations, I
would say most of them are new. So the text in several places about
"existing" namespaces needs to be adjusted -- that is not the norm.

>> people  who haven't been privvy to this sort of discussion.
>> (And, I'd send text, but it's my text that is clearly the problem
>> ;-) ).
> 
> what should be provided, and that it is most essential that the two
> primary questions you re-stated above are thought out and answered
> convincingly in a registration document.

On the other hand, 10 pages of text is not friendly, either. Brevity
would be better here, if we can boil the essentials down to a few
points of paragraphs (and then point people to some of the recent
registration RFCs for examples).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/