[IPv6]Re: draft-carpenter-6man-zone-ui: Call for Adoption

[David Farmer <[e-mail]>]

Even with all its problems, and there are many, RFC4007 is remarkably
effective. The primary thing missing is a viable solution for IPv6
link-local literals in a URI, especially in a web browser. Earlier in this
thread, you said, "This approach does not resolve the issue of how browsers
should support link-local addresses." Where instead, I believe a properly
clarified and required "default" zone will resolve many of the issues of
how browsers should support link-local addresses.

So, I guess my question is: What use cases that don't currently work does
this actually fix? Most applications seem to get what they need out of
RFC4007, except for how browsers should support link-local addresses.

Thanks

On Tue, May 28, 2024 at 10:08 PM Brian E Carpenter <
[e-mail]> wrote:

> Strangely enough, I agree with all David's suggestions for improving RFC
> 4007 (which has other deficiencies that he doesn't mention).
>
> But I disagree that fixing RFC 4007 would obviate the need for the zone-ui
> draft. The two things are orthogonal. This draft is the easy part, and IMHO
> should be done first.
>
> Regards
>     Brian Carpenter
>
> On 29-May-24 12:52, David Farmer wrote:
> > I do not support the adoption of this draft. In my opinion, it doesn't
> fundamentally solve the problem. It provides only slightly more guidance
> than RFC4007 by adding the option of treating the Zone Identifier as a
> completely separate input field instead of connecting it with an IPv6
> literal using the "%" or other delimiters. While I agree this technique is
> implementable by many applications, including modern web browsers.
> Nevertheless, I prefer a different solution to the problem, which I think
> is more consistent with an unmodified IPv6 literal URI specification in
> RFC3986.
> >
> > I believe a better solution to the problem involves the "default" zone.
> First, the current definition of the "default" zone is confusing. It needs
> significant clarification and more details about how the "default" zone
> functions. Second, all implementations should be required to implement the
> "default" zone for at least the link-local unicast and link-local multicast
> scopes.
> >
> > Further, I would like to see a recommendation that the default zone
> should be associated with the interface that came online most recently for
> at least the link-local scope. This would allow a user to easily change the
> interface associated with the link-local default zone by simply bouncing
> the desired interface.
> >
> > Finally, since multicast DNS relies on the link-local multicast scope,
> clarifying the "default" zone behavior for the link-local multicast scope
> will also provide more consistent multicast DNS behavior when multiple
> link-local multicast scopes are present.
> >
> > Thanks
> >
> >
> >
> >
> >
> > On Tue, May 28, 2024 at 3:33 AM Jen Linkova <[e-mail] <mailto:
> [e-mail]>> wrote:
> >
> >     This email starts an adoption call for the following document:
> >
> >     Title : Entering IPv6 Zone Identifiers in User Interfaces
> >     Authors : B. Carpenter, R. Hinden
> >     Pages : 9
> >     Date : 2024-03-31
> >
> >     https://datatracker.ietf.org/doc/draft-carpenter-6man-zone-ui/ <
> https://datatracker.ietf.org/doc/draft-carpenter-6man-zone-ui/>
> >
> >     Please note that the draft in question is a continuation of the work
> >     done in draft-ietf-6man-rfc6874bis which was adopted by this WG
> >     previously.
> >
> >     Substantive comments, statements of support for adopting this
> >     document or objections to the adoption should be sent to the mailing
> >     list.  Editorial suggestions can be sent to the authors.
> >     .
> >     This adoption call will end on June 12th 2024.
> >
> >     Regards,
> >
> >     Ole & Jen
> >
> >     --------------------------------------------------------------------
> >     IETF IPv6 working group mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     Administrative Requests:
> >     --------------------------------------------------------------------
> >
> >
> >
> > --
> > ===============================================
> > David Farmer Email:[e-mail] <mailto:[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
> > ===============================================
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests:
> > --------------------------------------------------------------------
>


-- 
===============================================
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
===============================================