Re: Last Call: <draft-bonica-special-purpose-03.txt> (Special-Purpose Address Registries) to Best Current Practice

[Pete Resnick <[e-mail]>]

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. - [phone]