On 30/11/2012, at 7:55 AM, The IESG <iesg-secretary@xxxxxxxx> wrote: > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Special-Purpose Address Registries' > <draft-bonica-special-purpose-03.txt> as Best Current Practice > > 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 2013-01-02. 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 > > > This memo instructs IANA to restructure its IPv4 and IPv6 Special- > Purpose Address Registries. Upon restructuring, the aforementioned > registries will record all special-purpose address blocks, > maintaining a common set of information regarding each address block. > > This memo updates RFC 5736 and RFC 4773, which define the current > structure of the IPv4 and IPv6 Special-Purpose Address Registries. > It also obsoletes RFC 5735 and RFC 5156 which document special- > purpose address blocks that are not currently, but will in the > future, be recorded in the IPv4 and IPv6 Special-Purpose Address > Registries. > I am not in favour of publication of this draft in its current form. The reasons for this are that I believe that the draft continues to promote a position that has been espoused in recent drafts it references that blurs the distinction between a special purpose address assignment and an address reservation. I believe that this distinction is a useful distinction and the number registries should explicitly preserve this distinction rather than blur it out. In my view reservations are an implicit part of the address plan for the protocol, and the expectation behind the reservation is that all implementations of the protocol will honour the same set of reservations in the same way. For example 0/8 is a reservation - all conformant implementations of the IPv4 would be expected to treat addresses drawn from 0/8 in the same fashion, namely as self identification. On the other hand I see 192.88.99.0/24 as an IANA special purpose assignment - its use is by a particular application or service, and conformant implementations of the IPv4 protocol stack are under no obligation to treat IP packets that include this address in any way that is different to any other general use IPv4 address. I see the proposal to push reservations and special purpose allocations into a single registry as being a source of potential confusion in so far as it a) blurs the distinction between what all conformant implementations of the protocol stack must respect in terms of reservation of addresses and the behaviour of the protocol stack if and when a reserved address is encountered and b) does not explicitly state the policies relating to the manner in which an address block is reserved and the policies relating to the manner in which an address block is assigned by virtue of a special purpose registry assignment. 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 can appreciate the "better housekeeping" motivation behind this draft, to group all IANA-held resources into a single registry, but I do not agree with this motivation given that the reason WHY resources are located in an IANA-maintained registry is then not explicit. Such addresses as listed in this draft can be delineated into reservations as part of the protocol's overall address plan, and special purpose address assignments that are undertaken by the IANA in support of particular applications and service operation that are not necessarily part of the protocol's underlying address plan and do not require reserved behaviours on the part of implementions of the protocol stack when such addresses are encountered. Geoff