Re: Last Call: <draft-housley-rfc2050bis-01.txt> (The Internet Numbers Registry System) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/05/2013 03:17, SM wrote:
...
>> The fact that the IPv6 address pool is very large does not remove the
>> fact that it is a not an infinite resource and thus, constraints must
>> be applied to allocation policy.
> 
> The constraints are not set by the IETF.  It's up to other communities
> to see what constraints, if any, should be applied.

It's up to the IETF to set boundary conditions for the address space
that it created (in the case of IPv6) or inherited (in the case of
IPv4), in order to protect the long-term viability of the Internet.

...

> I'll suggest alternative text:
> 
>   1) Allocation Pool: IP addresses and AS numbers are fixed length numbers.
>      The allocation pools for these number resources are considered as
>      resources which are finite.

That doesn't set any boundary conditions beyond those imposed by
mathematics, and is therefore a no-op. The mention of "operational
needs" is a real boundary condition that makes it clear that
address space is not to be wasted. As has been pointed out from
time to time, it would be quite easy to design an allocation model,
fully respecting the hierarchical constraint in the following
guideline, that blows away galactic quantities of address space,
even for IPv6.

It is entirely appropriate for the IETF and IAB to write a goal
that avoids this.

> The principle for the above is to avoid set any constraint unless it is
> necessary for IETF protocols to work.

No IETF protocol will work if the address space is exhausted of
if BGP4 runs out of steam or otherwise fails. The goals listed in
Section 2 address that.

...
> Section 2 is about the goals for distributing number resources (re.
> first sentence).  I suggest removing the third goal as it might be a
> matter of global (or other) policy.  

No, it's a necessity in order for the two preceding goals to be
verifiably achieved, and to avoid accidental duplication of
addresses.

...

> In Section 5:
> 
>   "The discussions regarding Internet Numbers Registry evolution must
>    also continue to consider the overall Internet address architecture
>    and technical goals referenced in this document."
> 
> I'll wordsmith this:
> 
>   It is expected that discussions regarding Internet Numbers Registry
> evolution
>   will continue to consider the overall Internet address architecture and
>   goals mentioned in this document.
> 
> I removed the "must".

The "must" is necessary.

> 
> I noticed the following in Section 5:
> 
>   "In addition, in the cases where the IETF sets technical recommendations
>    for protocols, practices, or services which are directly related to
>    IP address space or AS numbers, such recommendations must be taken
>    into consideration in Internet Numbers Registry System policy
>    discussions regardless of venue."
> 
> The text does not add any value as "must be taken into consideration"
> does mean anything.  

Er, it means what it says. It is exactly as powerful as any other
"must" or even "MUST" written by the IETF. If you ignore it, your
network might break.

I think that the current wording of the draft is correct.

   Brian




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]