Re: [Gen-art] Review: draft-bbf-bbf-urn-02

"STARK, BARBARA H" <> Thu, 27 October 2016 16:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 09D321279EB; Thu, 27 Oct 2016 09:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G4cXKNoBu8vn; Thu, 27 Oct 2016 09:53:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9603129583; Thu, 27 Oct 2016 09:53:45 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u9RGiYTb024661; Thu, 27 Oct 2016 12:53:30 -0400
Received: from ( []) by with ESMTP id 26bmunth0v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Oct 2016 12:53:30 -0400
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id u9RGrSH4003819; Thu, 27 Oct 2016 12:53:29 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u9RGrMXl003712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Oct 2016 12:53:24 -0400
Received: from ( []) by (RSA Interceptor); Thu, 27 Oct 2016 16:53:08 GMT
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Thu, 27 Oct 2016 12:53:07 -0400
To: "Joel M. Halpern" <>, "A. Jean Mahoney" <>, General Area Review Team <>, "" <>
Thread-Topic: [Gen-art] Review: draft-bbf-bbf-urn-02
Thread-Index: AQHSJlx5kzEPijn+RUuEN5vR73fRX6C4DCfQ
Date: Thu, 27 Oct 2016 16:53:07 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-27_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610270274
Archived-At: <>
Subject: Re: [Gen-art] Review: draft-bbf-bbf-urn-02
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Oct 2016 16:53:47 -0000

Hi Joel,

> Major issues:
>      RFC 3406 states that the namespace considerations section should indicate
> why a new namespace is needed.  While this is pretty obvious, the text does
> not actually say anything in that section to explain it.
>      In particular, I would expect that section to explain why 3 NIDs are needed
> rather than just 1.

Thanks for the comments. I propose adding the following text at the end of Namespace Considerations (the mention of the name change is part of a proposal to resolve a separate comment asking how "dslforum-org" relates to BBF):
   Three NIDs are defined. The "broadband-forum-org" and "dslforum-org" 
   (Broadband Forum changed its name from DSL Forum in 2008) NIDs have 
   been used for many years by BBF without formal registration. As they are 
   referenced by multiple BBF specifications currently in common use, BBF is 
   requesting to formalize them. The new "bbf" NID will be used for new work efforts.

> Minor issues:
>      The template in RFC 3406 indicates the the section in each NID on the
> Process of identifier assignment should "detail the mechanism and or
> authorities for assigning URNs to resources."  The draft simply says that the
> BBF will provide procedures.  Do those procedures exist?  If not, there seems
> to be a minor problem.  If they do exist, it would seem sensible to include a
> pointer to the place where the BBF publicly documents those procedures, so
> that people using this information who might want to register something can
> understand what the rules and expectations are. (I realize that the RFC 6289
> example this is based on did not include such a pointer, which is why I am
> making this a minor comment instead of a major one.)

I'm struggling a bit with this one in trying to figure out what's the best thing to say here. At this point in time, URN assignments only happen through creation of a BBF document that identifies the URN. BBF processes for document creation are published on the members-only part of the website, and only BBF members can participate in creating a BBF document. There is currently no plan to allow non-members to register URNs. There is also no plan to allow BBF members to register URNs for their own use (creating a BBF document requires interest and participation from at least 3 different companies). Would it be appropriate to say "BBF procedures for URN assignment are noted at [BBF-RESOURCES] <>" and on that page explain that URN assignment requires BBF membership and going through the BBF project and document processes?

Thanks again,