Barry,
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.
Agree.
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.
Also agree.
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.
MEF has a defined process for updating (specially adding new sections) to a document. It would be somewhat easier for me to edit (and drop) reference to RFC 3406 than to add the two new sections. So unless someone feels a strong desire for adding the two sections, I will work to drop reference to RFC 3406.
Cheers. 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
|