Hi Ron, I'm pleased to see the addition of this column and the recognition of this distinction between reservations in the protocol's address plan and special purpose assignments being made . This is a useful step forward. Personally, I think that the two sets of addresses belong in different registries, but I'm willing to recognise this as a matter of personal taste and not a fundamental objection to the further progress of the document per se (i.e. for me its more of a matter of registry management style - I would advocate the protocol's address plan should be recorded in a single registry, and special purpose assignments recorded in a special purpose assignment registry) So: "solved?" For me, it's a 51% solution: solved, but could do better :-) cheers, Geoff On 21/12/2012, at 9:45 AM, Ronald Bonica <rbonica@xxxxxxxxxxx> wrote: > Geoff, > > I have just posted a new version of the draft, adding a column that distinguishes between reservations and allocations. In this version, our goal is to preserve the distinction between reservations and allocations while providing a single compendium of special addresses. > > Please take a look and tell me if we have solved the problem. > > Ron > > >> -----Original Message----- >> From: Geoff Huston [mailto:gih@xxxxxxxxx] >> Sent: Monday, December 03, 2012 6:25 PM >> To: Ronald Bonica >> Cc: Randy Bush; IETF Discussion >> Subject: Re: Last Call: <draft-bonica-special-purpose-03.txt> (Special- >> Purpose Address Registries) to Best Current Practice >> >> >> On 04/12/2012, at 9:30 AM, Ronald Bonica <rbonica@xxxxxxxxxxx> wrote: >> >>> Geoff, Randy, >>> >>> Having reflected on your comments, I think that the two of you may be >> approaching the same problem from two directions. I will try my best to >> articulate the problem. When we agree that we have a common >> understanding of the problem, we can decide whether to fix draft-bonica >> or abandon it. >>> >>> Geoff points out that each of the entries mentioned in draft-bonica >> can be characterized as one of the following: >>> >>> - a special purpose address assignment >>> - a address reservation >>> >>> All compliant IP implementations must respect special purpose address >> assignments. As Randy puts it, special purpose address assignments >> should be baked into IP stacks. >>> >>> However, the same is not true of address reservations. While >> operators may afford special treatment to packets that are sourced from >> or destined to reserved addresses, these treatments should not be baked >> into IP implementations. They should be configurable. >>> >>> Currently, there is nothing in draft-bonica that distinguishes >> between special purpose address assignments and address reservations. >> If we were to continue with this draft, we would have to add a field >> that makes this distinction. Having added that field, we should also >> make clear that that field, and only that field, determines whether an >> address should be baked into IP stacks? >>> >>> Randy, Geoff, have I restated the problem accurately? >>> >> >> >> I'd use the opposite terminology. e.g.: >> >> - I regard 0.0.0.0/8 as a "reservation", and should be baked into IP >> stacks >> >> - I regard 192.88.99.0/24 as a "special purpose assignment" and is >> configurable by IP stacks. >> >> In IPv4 my understanding of the current set of "reservations" are: >> >> 0.0.0.0/8 >> 127.0.0.0/8 >> 169.254.0.0/16 >> 224.0.0.0/4 >> 240.0.0.0/4 >> >> All others I would see as being special purpose assignments, given that >> they do not require special baked-in treatment by IP stacks. >> >> My personal preference would be to: >> >> -- record all special purpose assignments in a special purpose >> assignment registry, such as http://www.iana.org/assignments/iana-ipv4- >> special-registry/iana-ipv4-special-registry.xml for Ipv4 >> >> >> -- record all reservations in the address protocol registry, such as >> http://www.iana.org/assignments/ipv4-address-space/ipv4-address- >> space.xml for Ipv4 >> >> >> regards, >> >> Geoff >> >> >> >> > > -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@xxxxxxxxx