Hi, Dan, and thanks for the review. You're right about the two missing sections, and I missed that in my review. As the URN reviewers have accepted this document, and as the base RFCs in question are currently being revised by the urnbis working group, I think it's not necessary to add those sections to the document, though I'll leave that decision to the author -- it *would* be the cleanest thing to do. If we don't do that, I think it's reasonable to remove references to 3406 -- take out the phrase "in full conformance with the NID registration process specified in URN Namespace Definition Mechanism [RFC3406]", remove the citation of 3406 in the Security Considerations (there's really nothing there worth referencing), and remove 3406 from the Normative References section. Mahesh, if you do decide to add the two missing sections, they can be brief. Consider this path, and let us know what you prefer. Barry On Wed, Feb 3, 2016 at 10:17 AM, Romascanu, Dan (Dan) <dromasca@xxxxxxxxx> wrote: > Hi, > > This is a simple and useful document. I understand its need and I support its publication. > > There is however one aspect that I believe deserves some discussion. > > The second paragraph in the Introduction claims: > > > As part of these specifications efforts, there is a need to identify > identifiers in a managed namespace that are unique and persistent. > To ensure that this namespace's uniqueness is absolute, a > registration of a specific Unified Resource Name (URN) URN Syntax > [RFC2141] Namespace Identifier (NID) for use by MEF is being > specified in this document, in full conformance with the NID > registration process specified in URN Namespace Definition Mechanism > [RFC3406]. > > However, the NID registration process described in RFC 3406 (section 4.3) mentions a couple of mandatory sections that are not included in this RFC as such: > > > The RFC must include a "Namespace Considerations" section, which > outlines the perceived need for a new namespace (i.e., where existing > namespaces fall short of the proposer's requirements). > ... > > The RFC must also include a "Community Considerations" section, which > indicates the dimensions upon which the proposer expects its > community to be able to benefit by publication of this namespace as > well as how a general Internet user will be able to use the space if > they care to do so. > > Part of the information mentioned in RFC 3406 is present here, but there are no "Namespace Considerations" and "Community Considerations" sections. > > It seems to me that we should either drop the 'full conformance" claim, or reorganize the I-D to include the sections mentioned in 3406. > > I hope this helps. > > Regards, > > Dan > > > >> -----Original Message----- >> From: IETF-Announce [mailto:ietf-announce-bounces@xxxxxxxx] On Behalf Of >> The IESG >> Sent: Thursday, January 07, 2016 4:24 PM >> To: IETF-Announce >> Cc: draft-mahesh-mef-urn@xxxxxxxx; barryleiba@xxxxxxxxxxxx; >> barryleiba@xxxxxxxxx >> Subject: Last Call: <draft-mahesh-mef-urn-01.txt> (URN Namespace for MEF >> Documents) to Informational RFC >> >> >> The IESG has received a request from an individual submitter to consider the >> following document: >> - 'URN Namespace for MEF Documents' >> <draft-mahesh-mef-urn-01.txt> as 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@xxxxxxxx mailing lists by 2016-02-04. Exceptionally, comments may be >> sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of >> the Subject line to allow automated sorting. >> >> Abstract >> >> >