On 30/11/2012, at 7:55 AM, The IESG <iesg-secretary(_at_)ietf(_dot_)org> 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(_at_)ietf(_dot_)org mailing lists by 2013-01-02. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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