Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
draft-ietf-6man-rfc6874bis-09

Discuss

Murray Kucherawy
(Robert Wilton)

Yes

Erik Kline
Warren Kumari
Éric Vyncke

No Objection

Francesca Palombini
John Scudder
Paul Wouters
Roman Danyliw
Zaheduzzaman Sarker
(Alvaro Retana)
(Andrew Alston)

No Record

Deb Cooley
Gunter Van de Velde
Jim Guichard
Mahesh Jethanandani
Orie Steele

Summary: Has a DISCUSS. Needs 2 more YES or NO OBJECTION positions to pass.

Murray Kucherawy
Discuss
Discuss (2023-03-16 for -05) Sent for earlier 
Thanks to Martin Thomson for his ARTART review.  It raises some serious concerns that I don't think have been resolved by the discussion that followed, either in 6MAN or on the Last Call list, so I'm balloting DISCUSS to figure out with the IESG how to proceed.

It appears some of these concerns were raised in early 2022 on the DISPATCH list and discussed then.  The ARTART review gives the impression that despite the work that's been done in the interim, it has not been sufficient to allay those concerns.  So it seems clear that we have WG consensus to proceed, but I'm not certain beyond that.

A few specific things I'd like to explore are:

1) If it's clear the browser community does not want (and maybe will not implement) this, what is our justification for proceeding?  In particular, that fact appears to me to eliminate half of the supporting use cases presented in Section 1.

2) Was the W3C TAG review completed?  What was the result?

3) Do any of the communities rejecting it have a preferred alternative for achieving the stated goal?

4) Is this within 6MAN's charter?
Comment (2023-03-16 for -05) Sent for earlier 
Kudos to Jen Linkova for a well done shepherd writeup.

In Appendix A, several solutions were discarded because they don't allow "simple cut and paste".  That seems to be something specific; is it defined anywhere?

It's unfortunate that this was indeed posted to the "uri-review" list, but it drew no meaningful replies.
Erik Kline
Yes
Warren Kumari
Yes
Comment (2023-03-15 for -05) Sent 
Thank you to the authors for this document -- it's a bit sad that it's needed / taken this long, but ¯\_(ツ)_/¯.

Also thanks to Jürgen Schönwälder for the helpful OpsDir review (https://datatracker.ietf.org/doc/review-ietf-6man-rfc6874bis-02-opsdir-lc-schoenwaelder-2022-09-22/) and the authors for addressing the comments.
Éric Vyncke
Yes
Comment (2023-03-13 for -05) Sent 
# Éric Vyncke, INT AD, comments for draft-ietf-6man-rfc6874bis-05
CC @evyncke

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Jen Linkova for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. 

Other thanks to Carlos Bernardos, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-6man-rfc6874bis-05-intdir-telechat-bernardos-2023-03-11/ (and I have seen that Brian has already replied to Carlos)

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 1

Readers would benefit from some examples in the introduction text.

### Section 4

There are also special use domains names like ".local" (for mDNS) that do not have global scope. Is it worth mentioning ? After all, one author of this doc is mDNS father ;-)

### RFC 3927

It would have been nice to also address the open issues of section 3 of RFC 3927 with a similar mechanism for 169.254/16 on a multi-interface host. I know that this is about the legacy IPv4 protocol and this draft comes out of the 6MAN WG, but anyway... Feel free to ignore as it is a little late in the process

## NITS

### Section 1

s/IPv6 Link Local URL/IPv6 Link-Local URL/ ?
s/link local addresses /link-local addresses / (possibly in other places as well)
same for /layer 2/layer-2/

### Section 4

s/orginates it/originates it/

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. 

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
Francesca Palombini
No Objection
Comment (2023-03-16 for -05) Not sent 
I support Murray's DISCUSS position.

Many thanks to Martin Thomson for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/jRD620uFObg9bnb_TUDYrlMtNoI/.
John Scudder
No Objection
Paul Wouters
No Objection
Comment (2023-03-14 for -05) Sent 
Thanks for this clear short document. Just a few minor comments:

   Unfortunately there is no formal limit on the length of the zone
   identifier string [RFC4007].  An implementation SHOULD apply a
   reasonable length limit when generating a URI, for example 64 ASCII
   characters, in order to minimize the risk of a buffer overrun.

If zone identifiers are interface names, a Linux restriction would
be the length of an interface name, IFNAMSIZ (or IF_NAMESIZE)
defined in <net/if.h>, which is 16. Perhaps using 16 as the
example instead of 64 would be more prudent ?


Should there be any mention of not allowing NULL characters in
zone identifiers for URI's ? Or would it be legal to have:

        https://[fd63:45eb:cd14:0:80b2:5c79:62ae:d341%foo\00bar] ?


Thanks for listing the rejected proposals, that was helpful to me.
Roman Danyliw
No Objection
Comment (2023-03-13 for -05) Sent 
Thank you to Leif Johansson for the SECDIR review.

** Section 5.

   URI parsers SHOULD accept a zone identifier according to the syntax
   defined in Section 3.

I’m trying to understanding how to implement this guidance.  What is the alternative to this format (since conformance to Section 3 is not required) – is it to fall back to Section 2 of RFC6874?

** Section 6.

   It is conceivable that this format could be misused to remotely probe
   a local network configuration.  

Perhaps fingerprinting a host as well.
Zaheduzzaman Sarker
No Objection
Comment (2023-03-15 for -05) Not sent 
Thanks for this update, I haven't notices TSV related issues in my review.
Deb Cooley
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
Mahesh Jethanandani
No Record
Orie Steele
No Record
Robert Wilton Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2023-03-15 for -05) Sent 
Hi,

I'm balloting discuss on this document because the encoding seems to exclude a large number of common port/interface name representation across many networking vendors that were allowed/supported by the previous RFC.  I think that it would be helpful to have a solution that accommodated these interface names, or to understand why they don't need to supported.

Specifically, the text in the introduction states:

   Zone identifiers are especially useful in contexts in
   which literal addresses are typically used, for example, during fault
   diagnosis, when it may be essential to specify which interface is
   used for sending to a link-local address.

and

   The mapping between the human-readable zone identifier string and the
   numeric value is a host-specific function that varies between
   operating systems.  The present document is concerned only with the
   human-readable string.

But unlike RFC 6874, which stated:

   If an operating system uses any other characters in zone or interface
   identifiers that are not in the "unreserved" character set, they MUST
   be represented using percent encoding [RFC3986].

The bis version of this document instead states:

   A zone identifier MUST contain only ASCII characters classified as
   "unreserved" for use in URIs [RFC3986].  This excludes characters
   such as "]" or even "%" that would complicate parsing.

   ...

   If an operating system uses any other characters in zone or interface
   identifiers that are not in the "unreserved" character set, they
   cannot be used in a URI.

Many (or even most) network devices across multiple vendors use interface names that all use characters that are not in the "unreserved" character set (specifically, '/' is a very common separator for linecards/ports/sub-ports/etc ...), and hence they would not be able to use the interface name (the obvious zone identifier) as part of this new encoding.

One could argue that the SNMP If-index or other internal numeric representation of the zone identifier (i.e., really an interface name) could be used instead, but the modern management APIs all use interface names (which in YANG allow for a large subset of unicode characters) rather than numerical indexes to identify interfaces.  I also think that we want to get away from numeric ids as zone identifiers in user facing uses.

Regards,
Rob
Alvaro Retana Former IESG member
No Objection
No Objection (for -05) Not sent 

                            

                        
                    

                
            
                
                    

                        

                            Andrew Alston Former IESG member
                        

                        

                            
                            No Objection
                            
                        

                    

                    

                        

                            

                                No Objection 
                                
                                    (2023-03-16 for -05)
                                
                                
                                    
                                         Sent
                                    
                                
                            

                        

                        
                            

                                
Thanks for this document.

I'd like to see the issues raised by Murray addressed and support his discuss