There seems to be a general point lurking behind this case.
There are several types of document we see that automatically
get a specialist review - MIBs are the classic case, but URN
namespaces are another. Generally, on the specialist part, the
IESG trusts the specialists. Gen-ART seems to get into trouble when
it tries to second-guess the specialists.
However, the specialists miss generalist issues. In this case
they seem to have missed the obsolete ABNF reference. We've seen
MIBs where the MIB doctors have missed glaring errors in the
Introduction, etc. There's a clear role for Gen-ART here - looking
for things the specialists are blind to.
Brian
Brian E Carpenter wrote:
Tom,
I'm no expert in RFC 3406 practice, but I'm told that the IESG has
generally accepted a positive review by the URN-NID list as
sufficient indication that the RFC 3406 requirements have been met.
There's a subjective element there of course, but the French have
a saying about not being "more royalist than the king" which seems
to apply here.
As for the third point, it is the namespace's own authority that
manages its internal structure - that is fully delegated.
The ABNF reference should preferably be updated and I will note that
in the tracker.
Thanks for the review.
Brian
Tom-PT Taylor wrote:
I have been selected as General Area Review Team reviewer for this
draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Draft: draft-rushing-s1000d-urn-00.txt
Reviewer: Tom Taylor <[EMAIL PROTECTED]>
Review Date: 5 May 2006
IETF LC Date: open
IESG Telechat Date: 11 May 2006
Summary:
This draft meets most of the requirements for registration of a formal
URN as described in RFC 3406. I believe it is deficient in one area,
technically deficient in another, and I am unclear on the requirement
in a third. In addition, the ABNF reference should now be updated from
RFC 2234 to RFC 4234 (also affects a comment in the syntax description).
Deficiencies and potential deficiencies:
1. RFC 3406 requires that the Namespace Considerations section
demonstrate due diligence by indicating why an existing URN namespace
would not serve the intended purpose. I expect a fairly
straightforward statement would do here.
2. As a second point, I will note that the Community Considerations
section is supposed to indicate how the community will benefit from
assignment of the URN namespace. Technically the document does not
meet this requirement, but the required information is present in
section 1.
3. Section 4 of RFC 3406 mentions the possible description of a change
process for registrations in the IANA Considerations section. The body
of the draft suggests that the set of subnamespaces may be extensible.
I suspect a change at that level does not trigger a requirement for
reregistration, but this should be confirmed. In any event, it might
not hurt to state explicitly how extension occurs (presumably by
amendment of S1000D).
Tom Taylor
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
