Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt

[Brian E Carpenter <[e-mail]>]

I of course agree with Dave Conrad that current practice has changed
since 1996. FWIW I also fully agree with John. I think it is quite
possible to write a quite short update of BCP 12 that keeps the
technical points that are still valid and omits the policy points
that have been delegated to IANA. Maybe we should have done this
in 2000.

Regards
   Brian


On 12/01/2013 22:21, John C Klensin wrote:
> 
> --On Saturday, January 12, 2013 11:36 -0800 David Conrad
> <[e-mail]> wrote:
> 
>> ...
>> No, since addressing is _explicitly_ declared out of scope of
>> that MoU, see section 4.3 of RFC 2860:
>>
>>   "Two particular assigned spaces present policy issues in
>> addition    to the technical considerations specified by the
>> IETF: the assignment    of domain names, and the assignment of
>> IP address blocks. These    policy issues are outside the
>> scope of this MOU."
>>
>> I don't think it is particularly useful or helpful to try to
>> assert that the IETF did "formally hand over" address
>> allocation to IANA since, as you know, there are lots of folks
>> who have, do, and will claim address allocation, as an
>> operational matter, was never the IETF's to "hand over". What
>> might be useful/helpful is to try to identify the portions of
>> RFC 2050 that have any relevance to the IETF and verify that
>> those portions are covered elsewhere.
> 
> David (and Brian and Subramanian), 
> 
> There are cans of poisonous, vicious vipers (only superficially
> resembling cans of worms) that are, IMO, best not opened and
> this is, IMO, one of them.  The reasons for that are probably as
> obvious to you as they are to me and I certainly agree with most
> of your last paragraph above.  However, I don't think the
> section of 2860 that you cite helps very much because there is
> another way to read it.  That alternate reading, which I believe
> is actually the correct one, says that the addressing issues
> (and the domain ones) consist of two parts "technical
> considerations" which are specified by the IETF and "policy
> issues" that are someone else's problem.  Indeed, it says
> "policy issues in addition to...", which I think recognizes that
> those "technical considerations" may have policy implications
> and that it is within scope for the IETF to specify those too.
> The exclusion is for policy issues that are _not_ part of the
> technical considerations.
> 
> With the understanding that the boundary that posits is very
> fuzzy, I don't think that basic principle has changed
> significantly since the MOU and probably not much since RFC
> 2050.  The IETF still has responsibility for the technical
> specification of addresses and the policies that narrowly
> implies; other policy issues, including the models for
> allocations of addresses to those who will use them, belong to
> others.  
> 
> I think it unwise try to define the boundary more precisely than
> that.  You may recall that an attempt was made to do so more or
> less unilaterally at the time the NRO was formed; in my opinion,
> that didn't work out especially well for the Internet (YMMD).
> If Jon were participating in this conversation today, I'm quite
> sure that he would be saying that it is much more important for
> the RIRs and the IETF to work together to get the best result
> for the Internet rather than putting energy into trying to
> legislate or enforce a boundary (whether that effort started in
> the IETF or in the RIRs).
> 
> best,
>    john
> 
>