Like Randy, I am completely agnostic on the question of dividing the
registries vs. adding an attribute to the registries to distinguish
between reservations and other special uses. But one comment on the
other item in your message:
On 11/29/12 4:26 PM, Geoff Huston wrote:
I also disagree with the approach to publish the intended contents of this special purpose registry as an RFC ans the registry itself is the intended mode of authoritatively describing those resources that have been assigned for special purposes. Obviously any RFC will age out and drift away from the registry, and the need to constantly publish updating RFCs to ensure that the latest RFC is reasonably close to the registry contents seems to me to be counter-productive at best.
I think (hope) you've misinterpreted this. The document serves two
purposes: To define the registries (section 2.1, which is really the
BCPish part of this document) and to populate the registries with
initial values (sections 2.2 and 2.3). 2.1 is the real content of the
documentthat will live on, get updated, etc., whereas 2.2 and 2.3 are
probably better as an appendix, and I don't think there's any
expectation that those sections ought to be kept up to date with future
RFCs to match the registry. (Indeed, it might be nice if 2.2 and 2.3
were removed before publication, but that's not been our practice.)
Does that allay your concern?
For the authors, one thing I did notice in section 2:
IANA will update the aforementioned registries as requested in the
"IANA Considerations" section of an IESG-reviewed document. The "
IANA Considerations" section must include all of the information
specified in Section 2.1 of this document.
It would probably be better to use the specific 5226 language of "IETF
Review", "IESG Approval" or "Standards Action" (whichever you really
mean) instead of "an IESG-reviewed document".
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478