[IPv6]Re: Mohamed Boucadair's Discuss on draft-ietf-6man-addr-assign-02: (with DISCUSS and COMMENT)

[David Farmer <[e-mail]>]

On Mon, Mar 24, 2025 at 3:01 PM Brian E Carpenter <
[e-mail]> wrote:

> Hi Med,
>
> Some comments in line...
>
> On 25-Mar-25 04:31, Mohamed Boucadair via Datatracker wrote:
> > Mohamed Boucadair has entered the following ballot position for
> > draft-ietf-6man-addr-assign-02: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> > for more information about how to handle DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-6man-addr-assign/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Hi Brian, Suresh, and David,
> >
> > Thank you for writing this document.
> >
> > Also, thanks to Giuseppe Fioccola (opsdir) for flagging that the
> “current IANA
> > review state is Not OK” and to the authors for the follow-up.
> >
> > I will be balloting “Yes” but I’m holding a DISCUSS to zoom into the name
> > inconsistency issue.
> >
> > # Rename (or not) the “Internet Protocol Version 6 Address Space” IANA
> registry
> >
> > After reading the appendix (which wasn’t actually introduced early in the
> > document), I think that we need to adopt a consistent approach: either
> we add a
> > new IANA action to update the name or use the name as currently
> maintained by
> > IANA when referring to the registry (and remove the appendix).
>
> The authors were certainly unsure of the best course of action here.
> Personally
> I agree with the need for consistency within the document, but we felt that
> changing the name on the IANA site might have implications that we couldn't
> see, so either the IESG or IANA should decide. If the IESG has a
> preference,
> we can of course tune the draft accordingly (and thanks for your other
> coments).
>
>     Brian
>

It was a nice idea to leave the issue of retitling the two registries to
the IESG or IANA to decide, but it doesn't seem that the IETF's processes
are designed to work that way.

I think I hear the IESG saying they don't have a properly formed question
to decide on.

So, I think we, the authors, should request the change in Section 4. Then,
we can ask for a new IANA review, particularly if IANA believes there are
any problems with retitling the two registries. Then, the IESG can make an
informed decision on whether to retitle the two Registries. If they decide
no, then we will remove it again.

Thanks

>
> > The main body of the document uses a mix of “Internet Protocol Version 6
> > Address Space” (Section 5) vs. “IPv6 Address Space” (abstract, Section
> 1).
> >
> > I don’t think this is critical per se but better to be consistent here.
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > # Introduction
> >
> > ## Avoid text that won’t age well: currently, recently, is currently,
> etc.
> > ## s/regional address registries/Regional Internet Registries (RIRs)
> > ## Consider the following:
> >
> > OLD:
> >     is currently shown as "IESG approval", whereas for major allocations
> >
> > NEW:
> >     was shown as "IESG approval" till the publication of this document,
> whereas for major allocations
> >
> > ## s/RFC 1881/[RFC1881]: Cite as reference. Idem for similar occurrences
> in the document.
> >
> > # Section 2
> >
> > (1) Cite the IANA registry:
> >
> > OLD: Portions of the IPv6 address space are shown in the registry
> > NEW: Portions of the IPv6 address space are shown in the registry [IANA1]
> >
> > (2) “recent” won’t age well. Consider the following change:
> >
> > OLD:
> >     It may be noted that the recent allocation for [RFC9602], which was
> >     processed as a working group document, did indeed follow the more
> >     stringent "IETF Review" process proposed by this document.
> >
> > NEW:
> >     The new stringent "IETF Review" process was followed for the
> >     allocation requested in [RFC9602], which was processed as a working
> >     group document.
> >
> > Thank you.
> >
> > Cheers,
> > Med
> >
> >
> >
>


-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================