[deepspace] Re: Outcome of WG Adoption Call for draft-li-tiptop-address-space

[John Curran <[e-mail]>]

Marc - 

I think you said the key phrase earlier - "These start with documenting by an RFC the engineering underlying the choice of allocation and what policies should be in place.”

The IETF does great engineering, and engineering can certainly address questions such as whether a dedicated block of address space is important and the appropriate structure of the allocation policies to be used for such a range.  

The important element is that such direction be the result of considered engineering - i.e. what are the expected conditions and drivers that require such structures.  Clear assumptions and reasoning is important because engineering guidance from the IETF will shape things for decades to come, and affected parties need to be able to look at the deliberative record and gain an understanding the engineering decisions made.  (The RIRs operate in a similar fashion, but have an advantage of being a step closer to the operators for feedback and having an ongoing policy evolution regime as a norm.)

Jorge’s point feeds into this question directly: in order to do any actual engineering here, it’s going to be important to hear from the constituencies with a direct interest in the outcome in order to validate the assumptions – and hopefully that will happen if the working group is going to undertake structural engineering decisions for an address allocation framework. 

Thanks, 
/John

p.s.  Disclaimers: my personal views alone; this email is composed of 100% recycled electrons; contents may be hot so use care when opening. 

> On Jun 11, 2026, at 9:12 AM, Marc Blanchet <[e-mail]> wrote:
> 
> 
>> Le 11 juin 2026 à 08:58, Jorge Amodio <[e-mail]> a écrit :
>> 
>> 
>> RFC6890 aka BCP153
> 
> 
> Ok. We don’t talk about the same thing.
> 
> -  you are referencing RFC6890/BCP153 which creates the registry: does not talk about allocation policies, ...
> - but if you look at the content of the registry, you will see a whole list of allocations and their referenced RFCs. Many of those RFCs (maybe all, but I just don’t have time to research this) were discussed and adopted in IETF working groups. That is my point. 
> 
> Marc.
> 
>> 
>> -J
>> 
>> On Thu, Jun 11, 2026 at 7:38 AM Marc Blanchet <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> 
>>>> Le 11 juin 2026 à 08:30, Jorge Amodio <[e-mail] <mailto:[e-mail]>> a écrit :
>>>> 
>>>> 
>>>> Comments in line ...
>>>> 
>>>> On Thu, Jun 11, 2026 at 7:02 AM Marc Blanchet <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>>>> Le 10 juin 2026 à 22:51, Jorge Amodio <[e-mail] <mailto:[e-mail]>> a écrit :
>>>>>> 
>>>>>> 
>>>>>>  I respectfully disagree.
>>>>>> 
>>>>>> This is trying to set an allocation policy, not just documenting the architectural aspects of IP addressing. 
>>>>> 
>>>>> There are multiple RFCs that define how a chunk of IP addresses will be allocated. See for example a good list of those: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml.  These start with documenting by an RFC the engineering underlying the choice of allocation and what policies should be in place. The IETF is the place to define how we will allocate IP addresses with specific instructions for how to allocate them on which criteria, .... , but it lets the RIR/IANA do the actual assignments to organizations.
>>>> 
>>>> True, but that BCP was not a product of a working group and has a long history until it was accepted for publishing as an RFC and tagged as BCP. 
>>> 
>>> I looked at a few referenced RFCs in that IANA table and found none are BCP. And I remember being involved in the IPv6 working group where we discussed many of these. So it has been discussed in IETF working groups.
>>> 
>>> 
>>>>>> That discussion belongs to a multi stakeholder organization which this WG is not.
>>>>> 
>>>>> IETF is clearly a multi stakeholder organization. But IETF is not an RIR.
>>>> 
>>>> By the nature of our individual participation the IETF can be considered a multi stakeholder organization, but there is no organization or constituencies representation like in ICANN.
>>> 
>>> Right IETF is not ICANN. 
>>> 
>>>> 
>>>> IMHO the WG is not representative nor has an authoritative voice for the multiple constituencies interested in this subject.
>>> 
>>> Again: IETF defines the engineering and the overall policies. Then the RIRs do their work for policies of assignments. It starts with IETF engineering. 
>>> 
>>> Marc.
>>> 
>>>> 
>>>> -J
>>>> 
>>> 
> 
> -- 
> deepspace mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]