Ballot for draft-ietf-6man-addr-assign

Yes

Éric Vyncke
Mohamed Boucadair
(Erik Kline)

No Objection

Andy Newton
Deb Cooley
Gorry Fairhurst
Gunter Van de Velde
Jim Guichard
Ketan Talaulikar
Mahesh Jethanandani
Mike Bishop
Roman Danyliw
(Orie Steele)
(Paul Wouters)

Note: This ballot was opened for revision 02 and is now closed.

Éric Vyncke
(was Discuss) Yes
Comment (2025-04-28 for -03) Sent
Thanks for addressing my DISCUSS issues (one by changing the text and one by email reply). I can only regret that my comments were ignored, but it is up to the authors.

I have kept below *FOR EASY RETRIEVAL ONLY* my previous ballot.

# Éric Vyncke, INT AD, comments for draft-ietf-6man-addr-assign-02
CC @evyncke

Thank you for the work put into this document.

Special thanks to Bob Hinden for the shepherd's  write-up including the WG consensus *but it lacks* the justification of the intended status.

Other thanks to Brian Haberman, the Internet directorate reviewer (at my request):
https://datatracker.ietf.org/doc/review-ietf-6man-addr-assign-02-intdir-telechat-haberman-2025-03-10/ (and I have read Brian's reply to Brian's question)

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS (blocking) ONLY FOR ARCHIVE

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 1

Easy to fix :-)

RFC 9602 did update "IANA IPv6 *Special-Purpose* Address Registry" and not "Internet Protocol Version 6 Address Space". I.e., either remove the reference to RFC 9602 (also in section 2) or include the "special-purpose address registry" in this section and the abstract.

OTOH the "special-purpose registry" is "IETF Review"...

### Sections 1 & 3

AFAIK the use of "legacy" only means that it is not coming out of an IETF WG but from the "legacy stream", it does not imply that it is not current, e.g., RFC 791 (IPv4) is also "legacy stream" (even if I wish that it is made historic :) )

I.e., why would RFC 1881 be treated differently than RFC 791 ?

## COMMENTS (non-blocking)

### "Internet Protocol Version 6 Address Space" FOR ARCHIVE

I support Mohamed Boucadair's DISCUSS about the use of "Internet Protocol Version 6 Address Space" (the official name of the IANA registry).

### Title

s/Assignment/Allocation/ ? This is the wording in the IANA registry and is also used in Section 1

### Section 4

Please use a reference for the registry to avoid any abmbiguities.

### Appendix A

While I agree that the problem described in this section is real, I wonder why this text appears in this document. If it should be fixed, then why not requesting the change ? Else, remove this section.
Mohamed Boucadair
(was Discuss) Yes
Comment (2025-04-24 for -03) Sent
Hi Brian, David, all,

Thank you for taking care of the DISCUSS and some of the comments [1].

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/ipv6/vWqiq6eE6zzJH8gaYcrs454B5XM/
Andy Newton
No Objection
Deb Cooley
No Objection
Comment (2025-04-08 for -02) Sent
Thank you to Scott Kelly for his secdir review.  His comment on Section 5 is repeated below to make it easier: 

     "The security considerations section says only this:

        'Carefully reviewed address allocation mechanisms are necessary for any form of
         address-based security.'

      I don't disagree with this, but I had 2 reactions: first, I expected this
      section to either state that this doc adds no new considerations over those in
      the doc(s) it updates (e.g. RFC 7249), or to state any new considerations.
      Second, the phrase 'address-based security' gave me pause. We don't recommend
      basing security on unauthenticated addresses, do we? I wonder if it would be
      better not to risk leaving the reader with the wrong impression. "

I agree with his assessment, especially the confusion as to what 'address-based security' means.  My recommendation would be to reference the security considerations in RFC 7249.  Either delete the current sentence, or clarify its meaning.

Appendix A:  I also agree that the opportunity to clarify IANA registry names should be taken unless it causes interoperability issues.
Gorry Fairhurst
No Objection
Comment (2025-03-23 for -02) Not sent
I understand that this concise document enables a set of changes for the IANA procedures. 

IANA may be content, but it would be helpful for IANA to confirm what action, if any, they think is needed to consider the issues raised in Appendix A.
Gunter Van de Velde
No Objection
Comment (2025-04-14 for -02) Not sent
Many thanks for this write up. It is well written and a pleasure to read. 
Similar as Med mentioned I agree that the usage of the word "recently" does not age well.
Jim Guichard
No Objection
Ketan Talaulikar
No Objection
Comment (2025-04-09 for -02) Sent
Thanks for the work done on this document. I have one comment below that is provided using the idnits output for v02 of the document.


91	   Occasionally, IPv6 address space allocations are performed outside
92	   the scope of routine allocations to regional address registries.  For

<minor> I believe the usage of term RIR is more prevalent these days and this is also what is being used in the concerned IANA registry description. Suggest to update the same in this document.

93	   example, recently a substantial allocation was requested by an IETF
94	   document approved by the IESG [RFC9602]
Mahesh Jethanandani
No Objection
Comment (2025-04-14 for -02) Sent
Section 5, paragraph 0
>    Carefully reviewed address allocation mechanisms are necessary for
>    any form of address-based security.

Thanks to Scott Kelly for his SECDIR review. I do support his comment and that of Deb. It is not clear to me what it means to have "address-based security". Could some text be added to clarify that term?
Mike Bishop
No Objection
Comment (2025-04-15 for -02) Sent
This document makes sensible changes, but in some ways still reads like an argument to the working group that these changes are needed. At this point in the process, it's declaring the new state of things and explaining why the changes *are being* made. Remove things about "recently" / "currently" and stick to statements of fact rather than opinion.

I would like to see Appendix A better incorporated into the text of the document -- IANA makes changes based on directives in appropriate documents. This "draw[s] attention to" an issue without actually directing IANA to do anything about it; that doesn't require an RFC. Either describe the motivation for the change in the body of the document and direct IANA to rename the registry in the IANA Considerations, or remove it and send them an e-mail if it's actually entirely in their control. (I presume they're already aware.)

I also support Mohammed's DISCUSS about the registry name. Let's be precise, especially in a document saying we should have been more precise in the past.
Roman Danyliw
No Objection
Erik Kline Former IESG member
Yes
Yes (for -02) Unknown

                            
Orie Steele Former IESG member
No Objection
No Objection (for -02) Not sent

                            
Paul Wouters Former IESG member
(was Discuss) No Objection
No Objection (2025-04-29 for -03) Sent
Thanks for addressing my concerns. I have updated my ballot to No Objection.