Entering IPv6 Zone Identifiers in User Interfaces
draft-ietf-6man-zone-ui-08

[Ballot comment]
Thanks for the clear document.

My only concern is how to deal with the fact of modifying RFC 3986 so it is no longer updated by RFC 6874 (but ideally also leaving a breadcrumb as to not gaslight people who knew)

[Ballot discuss]
I would benefit from additional clarity on what interoperability this document is creating.

Despite the Use Cases defined in Section 2, the normative guidance in Section 5 appears to provide guidance for:

(a) “things” (my term) that provide a “a user interface (UI) that allows or requires the user to enter an IPv6 address” running on an operating system that support default zones.

(b) “things” (my term) that provide “a user interface (UI) that allows or requires the user to enter an IPv6 address” running on an “operating system that does not support a default zone as specified in RFC4007”.

(c) browsers

As far as I can tell, there is no mandatory conformance required for all “things” defined as category (a) above.  Any non-browser “thing” on an OS that supports default zones is conformant to this specification because all the normative statements appear to be SHOULDs or MAYs.  Does that mean they are free to use delimiters other than “%” or “-“?  If so, what is the interoperability being provided?
Browsers per category (c) above, are out of scope “the recommendations and normative statements in this document do not apply to URIs fetched by web browsers.”

This leaves one residual set of mandatory guidance – “This is REQUIRED in the case of an    operating system that does not support a default zone as specified in RFC4007.”  Interpreting the “This” of that sentence, I read it as:
“A user interface (UI) that allows or requires the user to enter an IPv6 address running on operating system that does not support a default zone as specified in RFC4007 MUST provide a means for entering a link-local address or a scoped multicast address and selecting a zone identifier as specified by [RFC4007].”

The summary of this text appears to be a set of recommendations on delimiters that are not required for conformance and a mandatory UI element on certain operating systems.  No interoperability is being created between the different types of operating systems (those that support zones or not).  As an implementer I can completely ignore this specification as long as my operating system supports default zones and still be complaint.

[Ballot comment]
* Section 5
  Note that an address string such as "fe80::1%eth0" cannot be
  converted to binary by the POSIX socket API function "inet_pton()".
  It must either be converted using "getaddrinfo()", or by splitting it
  into two strings and using "inet_pton()" and "if_nametoindex()"
  successively, in order to obtain the required interface index value.

Please provide a reference to the POSIX socket API being reference.

[Ballot comment]
Section 1, paragraph 3
>    Such addresses are directly supported by socket API calls including
>    "getaddrinfo()" [RFC3493].

That is not all. As indicated by Med, draft-ietf-netmod-rfc6991-bis has definitions for [ipv4|ipv6]-address-link-local addresses for use in YANG. It even calls out the difference between zone and no-zone identifiers. Therefore, an informative reference to the document would highlight another API use of zone identifiers.

This document uses the RFC2119 keywords "SHALL NOT", "SHOULD NOT",
"RECOMMENDED", "SHOULD", "NOT RECOMMENDED", "MAY", "MUST NOT", "SHALL", "MUST",
"REQUIRED", and "OPTIONAL", but does not contain the recommended RFC8174
boilerplate. (It contains some text with a similar beginning.)

The IANA review of this document seems not to have concluded yet.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3, paragraph 1
> m into a numeric interface index. Typically this mapping is performed by the
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Typically".

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-6man-zone-ui-08

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-6man-zone-ui-08.txt

# for your convenience, please find some non-blocking COMMENTS

# This document was an interesting read. Many thanks for composing this write-up

# The idnits tool spits up some observations

# comments
# ========

# 108 2.  Use Cases

GV> Lately i was involved with TWAMP/STAMP based unidirectional link delay measurement for Segment Routing. In such use-case there may be need for using IPv6 LL addresses in UIs and configs and state fields. Network using Segment Routing and deploying flex-algo will most likely use such type of link delay measurements. I did not see this use-case in the shortlist. Would it make sense to mention this?

110   Some examples of use cases for entering an address that includes a
111   zone identifier into a UI are as follows:

GV> an alternative would be to explicitly mention that the list is not exhaustive and that additional use-case examples exists, which are not directly mentioned within the provided list.

Gunter Van de Velde
RTG Area Director

[Ballot comment]
Hi Brian and Bob,

Thank you for the continuous work on this. Glad to see that you managed to find a path after I-D.ietf-6man-rfc6874bis.

Thanks to Sue Hares for her OPSDIR review.

I support this effort.

# Meta comments

## Zone index (4007) vs. identifier(6874/this I-D): Maybe worth to clarify early in the document the relationship between those.

## The use is not only for static configuration but also when programmatic means are involved. BTW, I don’t see any implication, but we may cite draft-ietf-netmod-rfc6991-bis for the support of scoped addresses.

## The clarification is useful independent of the implementation. I would remove “device” mentions as the clarification can be consumed (including when interacting) by NF/VNF, etc.

## The text uses UI but smells more like GUI in some parts (e.g., "separate field"). I would double check the use through the text and make this less about “graphic”.

## We don’t need to over-justify the need for the clarification or speculate about future use (text with IPv6-mostly thing).

## Guards not only for on the wire but also in referrals: The document is clear that the id is not intended to be used on the wire. Link-local addresses do not make sense in referral objects, but if this is leaked, the index information can reveal some information (interface, for example). Not sure if we need to remind this. 

## link-local & protocol discovery: There are a bunch of initiatives using link-local addresses, e.g., automatic discovery of BGP peers such as in draft-acee-idr-lldp-peer-discovery. I don’t think this is impacted by the clarification here, but I would appreciate if you can have a look and confirm my conclusion (best effort, though :-)). Thanks.

FYI, raised also the point with Sue Hares (IDR Chair); see the actions at https://mailarchive.ietf.org/arch/msg/ops-dir/WcBavaHUctg-y2wXXTm_Dq1d75E/

# Process/Datatracker

## Revert changes back to 3986

The document indicates that the publication of the document will revert the change that it made to the URI syntax defined by RFC3986. (Not to the authors) I wonder whether this change is supported by our tooling and no further action is needed to tag this.

## I think that we need a section to list the changes vs obsoleted spec.

# Minor edits/nits

## (through the document) Please use explicit RFC citations, instead of plain text: e.g., s/RFC 4007/[RFC4007]

## Please use explicit sections rather “below” and the like: e.g., s/described below/described in Section 5

## Introduction

(1) s/user interface/User Interface

(2) I would delete “, for purposes described in that specification”. No need to be too subtle here.

(3) s/Today/Typically

(4) s/"fe80::1234%eth0" on a Linux host, or "fe80::4321%7"/"fe80::1234%eth0" on a Linux host or "fe80::4321%7"

(5) s/Devices/Implementations

## Section 2

(1) s/Some examples of/A non-exhaustive list of sample

(2) s/configure or reconfigure/configure

(3) s/has recently/has

(4) s/IPv6 link local/IPv6 link-local

(5) “Desired improvements to the standard”: By whom?

(6) Better clarity for the example

OLD:
  Such requirements have already spawned hacks to work around current
  limitations, e.g., [LL-HACK], which is no longer maintained and has
  been archived.

NEW:
  Such requirements have already spawned hacks to work around current
  limitations (e.g., [LL-HACK], which is no longer maintained and has
  been archived).

# Section 3

(1) s/Typically this mapping/Typically, this mapping

(2) I would simply delete this part: no need to over-justify or speculate about future use:

CURRENT:
It will become critical as IPv6-only or IPv6-mostly
  networks [RFC8925] [I-D.link-v6ops-6mops], with nodes lacking native
  IPv4 support, appear.  For example, the NMEA use case mentioned above
  is an immediate requirement.  This is the principal reason for
  documenting this requirement now.

Note that I-D.link-v6ops-6mops  was replaced by draft-ietf-v6ops-6mops.

(3)

OLD:
  This document obsoletes [RFC6874], which implementors of web browsers
  have determined is impracticable to support
  [I-D.schinazi-httpbis-link-local-uri-bcp], and replaces it by a
  generic UI requirement described in Section 5. 

NEW:
  This document obsoletes [RFC6874], which implementors of web browsers
  have determined is impracticable to support
  (See, e.g., Section 3.2 of [I-D.schinazi-httpbis-link-local-uri-bcp]), and replaces it by a
  generic UI requirement described in Section 5. 

(4)

OLD:
  This document also updates [RFC7622] and [RFC8089] by deleting their
  references to RFC 6874.

  It also updates [RFC4007] by adding a new requirement that user
  interfaces support the zone identifier as described below.

NEW:
  This document updates [RFC7622] and [RFC8089] by deleting their
  references to RFC 6874.

  It also updates [RFC4007] by adding a new requirement that user
  interfaces support the zone identifier as described in Section 5.

## Section 5

(1) s/A User Interface (UI)/A UI

(2) s/zone identifer/zone identifier

(3) "or requires the user”: May mention including using programmatic means (not only manual configuration).

(4)

OLD:
  Ideally, the UI SHOULD support the complete format specified by RFC 4007 (e.g., "fe80::1%eth0").

NEW:
  The UI SHOULD support the complete format specified in Section 6 of [RFC4007] (e.g., "fe80::1%eth0").

(5) “two separate input fields”: This is drawn with the assumption of a graphical user interface. Consider “input parameters” or similar.

## Section 6

(1) s/identifier through a UI should therefore not/identifier through a UI should, therefore, not

Cheers,
Med

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-6man-zone-ui-08
CC @evyncke

Thank you for the work put into this document. This was not an easy ride for sure...

Please find below some non-blocking COMMENT points (and *I expect a reply for the first comment*, of course other replies would be appreciated even if only for my own education).

Special thanks to Jen Linkova for the shepherd's detailed write-up including the WG consensus (and its history) *but it lacks* the justification of the intended status (and this is important for this specific document).

Please note that Sheng Jiang is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-6man-zone-ui/reviewrequest/21702/

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Handling the RFC 3986

Section 3 includes `so RFC 3986 is no longer updated by RFC 6874` but the document does not contain any instruction (to the IESG ? or RFC Editor ?) on how to do this step. To be honest, I have never seen this case.

I am trusting the authors and the responsible AD to provide an answer on this point.

### No reference to RFC 3927

Should there be some text around the IPv4 LLA ? Cfr section 3 of RFC 3927 "Dynamic Configuration of IPv4 Link-Local Addresses"

### Section 1

`that a zone identifier may be concatenated to an address, for purposes described in that specification` isn't it rather a "must" ? Also "that specification" is rather unclear as the previous text refers to two RFCs.

Perhaps s/Windows host/*Microsoft* Windows host/ ?

### Section 2

s/the *remote* device is reachable/the device is reachable/ as 'remote' is not perfect for a link-local ;)

Rather than mentioning Wireshark and later writing 'not support yet', let's use "network sniffer" ?

### Section 3

s/without specifying a maximum length/without specifying a maximum length *or syntax*/ ?

### Section 5

Isn't the two boxes technique contradicting the section 2 `any solution except cut-and-paste is highly error prone`?

`this should be reported to the user` why not a "SHOULD" ? Also explain when the "should/SHOULD" can be bypassed.

### Section 6

I wonder why it is not a "MUST" in `Software that obtains a zone identifier through a UI should therefore not transmit it further` ?

[Ballot comment]
# Andy Newton, ART AD, comments for draft-ietf-6man-zone-ui-08
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-6man-zone-ui-08.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/


## Comments

Thanks for all your work on this and on the previous attempt at rfc6874bis.

### Updating RFC 3986

This maybe a question for the RFC Editor instead of the authors or wg.
Should this document also be marked as updating RFC 3986? Or should there
be a note to the RFC Editor to remove the update of 3986 by 6874?

193        This document obsoletes [RFC6874], which implementors of web browsers
194        have determined is impracticable to support
195        [I-D.schinazi-httpbis-link-local-uri-bcp], and replaces it by a
196        generic UI requirement described below.  Note that obsoleting RFC
197        6874 reverts the change that it made to the URI syntax defined by
198        [RFC3986], so RFC 3986 is no longer updated by RFC 6874.  As far as
199        is known, this change will have no significant impact on non-browser
200        deployments of URIs.

[Ballot comment]
Hi Brian and Bob,

Thank you for the continuous work on this. Glad to see that you managed to find a path after I-D.ietf-6man-rfc6874bis.

Thanks to Sue Hares for her OPSDIR review.

I support this effort.

# Meta comments

## Zone index (4007) vs. identifier(6874/this I-D): May be worth to clarify early the document the relationship between those.

## The use is not only for static configuration but also when programmatic means are involved. BTW, I don’t see any implication, but we may cite draft-ietf-netmod-rfc6991-bis for the support of scoped addresses.

## The clarification is useful independent of the implementation. I would remove “device” mentions as the clarification can be consumed (including when interacting) by NF/VNF, etc.

## The text uses UI but smells more like GUI in some parts (e.g., separate field). I would double check the use through the text and make this less about “graphic”.

## We don’t need to over-justify the need for the clarification or speculate about future use (text with IPv6-mostly thing).

## Guards not only for on the wire but also in referrals: The document is clear that the id is not intended to be used on the wire. Link-local addresses do not make sense in referral objects, but if this is leaked, the index information can reveal some information (interface, for example). Not sure if we need to remind this. 

## link-local & protocol discovery: There are a bunch of initiatives using link-local addresses, e.g., automatic discovery of BGP peers such as in draft-acee-idr-lldp-peer-discovery. I don’t think this is impacted by the clarification here, but I would appreciate if you can have a look and confirm my conclusion (best effort, though :-)). Thanks.

# Process/Datatracker

## Revert changes back to 3986

The document indicates that the publication of the document will revert the change that it made to the URI syntax defined by RFC3986. (Not to the authors) I wonder whether this change is supported by our tooling and no further action is needed to tag this.

## I think that we need a section to list the changes vs obsoleted spec.

# Minor edits/nits

## (through the document) Please use explicit RFC citations, instead of plain text: e.g., s/RFC 4007/[RFC4007]

## Please use explicit sections rather “below” and the like: e.g., s/described below/described in Section 5

## Introduction

(1) s/user interface/User Interface

(2) I would delete “, for purposes described in that specification”. No need to be too subtle here.

(3) s/Today/Typically

(4) s/"fe80::1234%eth0" on a Linux host, or "fe80::4321%7"/"fe80::1234%eth0" on a Linux host or "fe80::4321%7"

(5) s/Devices/Implementations

## Section 2

(1) s/Some examples of/A non-exhaustive list of sample

(2) s/configure or reconfigure/configure

(3) s/has recently/has

(4) s/IPv6 link local/IPv6 link-local

(5) “Desired improvements to the standard”: By whom?

(6) Better clarity for the example

OLD:
  Such requirements have already spawned hacks to work around current
  limitations, e.g., [LL-HACK], which is no longer maintained and has
  been archived.

NEW:
  Such requirements have already spawned hacks to work around current
  limitations (e.g., [LL-HACK], which is no longer maintained and has
  been archived).

# Section 3

(1) s/Typically this mapping/Typically, this mapping

(2) I would simply delete this part: no need to over-justify or speculate about future use:

CURRENT:
It will become critical as IPv6-only or IPv6-mostly
  networks [RFC8925] [I-D.link-v6ops-6mops], with nodes lacking native
  IPv4 support, appear.  For example, the NMEA use case mentioned above
  is an immediate requirement.  This is the principal reason for
  documenting this requirement now.

Note that I-D.link-v6ops-6mops  was replaced by draft-ietf-v6ops-6mops.

(3)

OLD:
  This document obsoletes [RFC6874], which implementors of web browsers
  have determined is impracticable to support
  [I-D.schinazi-httpbis-link-local-uri-bcp], and replaces it by a
  generic UI requirement described in Section 5. 

NEW:
  This document obsoletes [RFC6874], which implementors of web browsers
  have determined is impracticable to support
  (See, e.g., Section 3.2 of [I-D.schinazi-httpbis-link-local-uri-bcp]), and replaces it by a
  generic UI requirement described in Section 5. 

(4)

OLD:
  This document also updates [RFC7622] and [RFC8089] by deleting their
  references to RFC 6874.

  It also updates [RFC4007] by adding a new requirement that user
  interfaces support the zone identifier as described below.

NEW:
  This document updates [RFC7622] and [RFC8089] by deleting their
  references to RFC 6874.

  It also updates [RFC4007] by adding a new requirement that user
  interfaces support the zone identifier as described in Section 5.

## Section 5

(1) s/A User Interface (UI)/A UI

(2) s/zone identifer/zone identifier

(3) "or requires the user”: May mention including using programmatic means (not only manual configuration).

(4)

OLD:
  Ideally, the UI SHOULD support the complete format specified by RFC 4007 (e.g., "fe80::1%eth0").

NEW:
  The UI SHOULD support the complete format specified in Section 6 of [RFC4007] (e.g., "fe80::1%eth0").

(5) “two separate input fields”: This is drawn with the assumption of a graphical user interface. Consider “input parameters” or similar.

## Section 6

(1) s/identifier through a UI should therefore not/identifier through a UI should, therefore, not

Cheers,
Med

[Ballot comment]
Thank you for this work to improve the use of zone identifiers.

1. The document provides only a small number of RFC2119 requirements. It might be more clear to organise the normative list of items in section 5 in a bulleted list:
- Ideally, ...
- If ...
- If ...

2. Please consider adding text on the challenge for browser configuration. In particular, it could be useful to provide slightly more context on the problem with RFC6874. From draft-schinazi-httpbis-link-local-uri-bcp, I understand:

The solution in [RFC6874] requires the browser to treat the zone
identifier as part of the origin in some contexts (such as when
determining uniqueness of a name), but not in others (such as when
sending the Host header on the wire). This significantly increases
implementation complexity and security risks.

A version of this text might help alert people that a solution for a browser might require various considerations.

3. Please also consider the issues raised in the TSV ART review and SECDIR review to discuss whether anything more can be said about a browser method to specify a zone identifier.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-6man-zone-ui-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-01-13):

From: The IESG
To: IETF-Announce
CC: 6man-chairs@ietf.org, draft-ietf-6man-zone-ui@ietf.org, ek.ietf@gmail.com, furry13@gmail.com, ipv6@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Entering IPv6 Zone Identifiers in User Interfaces) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'Entering IPv6 Zone Identifiers in User
Interfaces'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-01-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes how the zone identifier of an IPv6 scoped
  address, defined in the IPv6 Scoped Address Architecture (RFC 4007),
  should be entered into a user interface.  It obsoletes RFC 6874 and
  updates RFC 4007, RFC 7622 and RFC 8089.

Discussion Venue

  This note is to be removed before publishing as an RFC.

  Discussion of this document takes place on the 6MAN mailing list
  (ipv6@ietf.org), which is archived at
  https://mailarchive.ietf.org/arch/browse/ipv6/
  (https://mailarchive.ietf.org/arch/browse/ipv6/).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-zone-ui/



No IPR declarations have been submitted directly on this I-D.

# Internet AD comments for draft-ietf-6man-zone-ui-05
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

## Comments

### S2

* The LL-HACK URL doesn't seem to work for me.  We might need to find
  something else as a reference.

  (I foundhttps://ungleich.ch/u/blog/ipv6-link-local-support-in-browsers/
  but I'm not sure if that's worth using or not.)

### S5

* I think it would be worth reiterating the RFC 4007 recommendation,
  mentioned in S3, that an OS (or application even) SHOULD apply a default
  zone identifier wherever practically determinable.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Entering IPv6 Zone Identifiers in User Interfaces
draft-ietf-6man-zone-ui-04
Authors: B. Carpenter, R. Hinden
Obsoletes: 6874 (if approved)
Updates: 4007, 7622, 8089
Intended status: Standards Track
Date: 14 October 2024


Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad
  agreement?

There is a strong concensus to advance this document in 6MAN.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This draft is a replacement for
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ that
progressed throught the 6MAN w.g., IETF last call, but was blocked by
Murray Kucherawy.  The authors and working group refocuesed and produced
this draft that focus on the UI aspect and does not make any URI/URL
changes.  This appears to have broad support.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals threatened.  Several people who objected in the IETF last call
of the previous approach (draft-ietf-6man-rfc6874bis) support this document.


4. For protocol documents, are there existing implementations of the
  contents of the document? Have a significant number of potential
  implementers indicated plans to implement? Are any existing
  implementations reported somewhere, either in the document itself (as
  [RFC 7942][3] recommends) or elsewhere (where)?

From Brian Carpenter:

  For the preferred option section 5: yes, many, starting with ping.

  For the second option (hyphen): I'm not aware of one.

  For the third option (a separate box): I'm not aware of one in
  released code. I did write a toy add-on for Firefox to input an
  interface ID, but that might be provocative.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document was reviewed by several people who objected to the earlier
approach in .  They were all supportive of this draft.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this
    intent?

Standards Track, proposed standard

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Only a few non-ascii characters and warnings.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Looks good.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All Normative references are RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is
    discussed.

It Updates: RFC4007, RFC7622, RFC8089.  Is shows this correctly in
header, Abstract, and in Section 3.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA action.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Entering IPv6 Zone Identifiers in User Interfaces
draft-ietf-6man-zone-ui-04
Authors: B. Carpenter, R. Hinden
Obsoletes: 6874 (if approved)
Updates: 4007, 7622, 8089
Intended status: Standards Track
Date: 14 October 2024


Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad
  agreement?

There is a strong concensus to advance this document in 6MAN.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This draft is a replacement for
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ that
progressed throught the 6MAN w.g., IETF last call, but was blocked by
Murray Kucherawy.  The authors and working group refocuesed and produced
this draft that focus on the UI aspect and does not make any URI/URL
changes.  This appears to have broad support.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals threatened.  Several people who objected in the IETF last call
of the previous approach (draft-ietf-6man-rfc6874bis) support this document.


4. For protocol documents, are there existing implementations of the
  contents of the document? Have a significant number of potential
  implementers indicated plans to implement? Are any existing
  implementations reported somewhere, either in the document itself (as
  [RFC 7942][3] recommends) or elsewhere (where)?

From Brian Carpenter:

  For the preferred option section 5: yes, many, starting with ping.

  For the second option (hyphen): I'm not aware of one.

  For the third option (a separate box): I'm not aware of one in
  released code. I did write a toy add-on for Firefox to input an
  interface ID, but that might be provocative.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document was reviewed by several people who objected to the earlier
approach in .  They were all supportive of this draft.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this
    intent?

Standards Track, proposed standard

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Only a few non-ascii characters and warnings.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Looks good.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All Normative references are RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is
    discussed.

It Updates: RFC4007, RFC7622, RFC8089.  Is shows this correctly in
header, Abstract, and in Section 3.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA action.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/