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

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)

# É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` ?