'Re: [IPv6] Murray Kucherawy's Discuss on draft-ietf-6man-rfc6874bis-05: (with DISCUSS and COMMENT)'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: [IPv6] Murray Kucherawy's Discuss on draft-ietf-6man-rfc6874bis-05: (with DISCUSS and COMMENT)
From:       Brian E Carpenter <brian.e.carpenter () gmail ! com>
Date:       2023-06-20 4:38:59
Message-ID: 75b2fabf-ac7e-4933-b1a7-d49e92c6326f () gmail ! com
[Download RAW message or body]

Oops, typo, the *current* version is draft-ietf-6man-rfc6874bis-08, the next one will \
be -09.

Regards
    Brian

On 20-Jun-23 16:29, Brian E Carpenter wrote:
> P.S. It seems that the W3C draft cited below has just been renamed, and so the URL \
> we cited is now invalid, with no redirect provided. 
> The new URL is https://wicg.github.io/private-network-access/
> 
> I will fix that in our draft, but I'd like to hear back about the other changes \
> before posting version -08. 
> Regards
> Brian
> 
> On 20-Jun-23 11:59, Brian E Carpenter wrote:
> > Murray,
> > 
> > I'm replying to your original DISCUSS for simplicity. We are now at version 08 of \
> > the draft, and waiting for the next step from the IESG. 
> > In summary, the changes since the IESG review are:
> > 
> > - Added NMEA use case.
> > - Clearly explained cut-and-paste requirement.
> > - Clarified character set restrictions and the applicability of numeric \
> >                 identifiers as a work-around.
> > - Updated ABNF to require lower case (due to host component case normalization)
> > - * Mentioned .local as another case of locally significant URIs.
> > - * Expanded text on handling of zone ID at server.
> > - * Added discussion of CORS.
> > - * Noted parsing fragility re % sign.
> > - Noted potential exposure of MAC addresses in zone IDs
> > 
> > The changes marked with an asterisk are particularly relevant to your DISCUSS. (I \
> > think we tackled your initial questions in the useful side meeting at IETF 117, \
> > so this is about the substantive technical comments received.) 
> > As far as the security-related concern about cross-origin URLs (CORS) is \
> > concerned, the draft introduces nothing new -- just one more form of locally \
> > significant URL -- and this is now reflected in the W3C community draft on the \
> > whole topic at https://wicg.github.io/local-network-access/ **, with mutual \
> > cross-references. See the table in section 2.1 of that document, and the 2nd NOTE \
> > below that table. 
> > If the web community adds any new features to mitigate CORS issues, they will \
> > apply here too. 
> > As far as parsing the % sign goes, the key point here is that if legacy code \
> > throws an error on this, it is not a new problem (that is exactly what happens \
> > today). Updated code can be deployed progressively as required, with no wider \
> > consequences. So while it is true that the new format will break unmodified \
> > parsers, this doesn't detract from parsers that *do* recognize it. 
> > At IETF 117, we also learned of an important new use case from the National \
> > Marine Electronics Association, now summarized in the draft. 
> > ** I've been getting bizarre 404's from that URL, but there is a copy at \
> > http://web.archive.org/web/20230522201104/https://wicg.github.io/local-network-access/
> >  
> > Regards
> > Brian Carpenter + co-authors
> > 
> > On 16-Mar-23 20:40, Murray Kucherawy via Datatracker wrote:
> > > Murray Kucherawy has entered the following ballot position for
> > > draft-ietf-6man-rfc6874bis-05: Discuss
> > > 
> > > When responding, please keep the subject line intact and reply to all
> > > email addresses included in the To and CC lines. (Feel free to cut this
> > > introductory paragraph, however.)
> > > 
> > > 
> > > Please refer to \
> > > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ \
> > > for more information about how to handle DISCUSS and COMMENT positions. 
> > > 
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/
> > > 
> > > 
> > > 
> > > ----------------------------------------------------------------------
> > > DISCUSS:
> > > ----------------------------------------------------------------------
> > > 
> > > 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?
> > > 
> > > 
> > > ----------------------------------------------------------------------
> > > COMMENT:
> > > ----------------------------------------------------------------------
> > > 
> > > 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.
> > > 
> > > 
> > > 
> > > .

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread] 