Re: [Last-Call] LC feedback on draft-ietf-6man-rfc6874bis

[Vasilenko Eduard <[e-mail]>]

> Well, yes, but it's a chicken/egg question, or perhaps it's fairer to call it an "after you", "no, after you" deadlock. Getting this draft approved is the way to break that deadlock.
+1
-----Original Message-----
From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E Carpenter
Sent: Tuesday, September 13, 2022 5:07 AM
To: Mark Nottingham <[e-mail]>
Cc: [e-mail]; 6man <[e-mail]>
Subject: Re: [Last-Call] LC feedback on draft-ietf-6man-rfc6874bis

Hi Mark,

On 13-Sep-22 13:44, Mark Nottingham wrote:
> Hi Brian,
> 
>> On 13 Sep 2022, at 11:34 am, Brian E Carpenter <[e-mail]> wrote:
>>
>> On 13-Sep-22 12:00, Mark Nottingham wrote:
>>> Hello,
>>> I appreciate the effort that the authors and WG have put into this document, and I don't have any substantial technical issues with the document as written (although I have not reviewed it deeply).
>>> That said, the IESG needs to consider this publication carefully. The targeted implementers (web browsers) have very clearly said they will not be implementing. From their issue of record:
>>
>> Mark, that was then. People are now beginning to wake up to the fact that this is actually wanted by quite a lot of ops and support staff. It will change (the status as a Firefox "defect" has recently changed to "enhancement", for example) and the reason we need this on record as an RFC is so that, as the need becomes compelling, there will be an unambiguous basis for all implementers.
> 
> Where do you see the Firefox status? The definitive place to find a Mozilla position on a specification is here:
>    https://mozilla.github.io/standards-positions/
> ... and I don't see this one there (nor is it in their issue queue).

I'm going by https://bugzilla.mozilla.org/show_bug.cgi?id=700999#c94 . If we get approved for RFC publication, maybe that would be the time for it to be on their list?

> 
>>>> Overall, our internal consensus is that <zone_id>'s are bonkers on many grounds - the technical ambiguity (and RFC 6874 doesn't really resolve the ambiguity as much as it fully owns it and just says #YOLOSWAG) - and supporting them would add a lot of complexity for what is explicitly and admittedly a limited value use case.
>>
>> That's OBE. And there isn't any technical ambiguity that I'm aware 
>> of. (What may be confusing is that the "zone identifiers" are utterly 
>> non-standardised beyond being an ASCII string, so there is no way for 
>> a parser to validate them; only the o/s can do that.)
> 
> I'd like to see them say that -- right now, this + the statement below is the browser position, as I understand it.

Well, yes, but it's a chicken/egg question, or perhaps it's fairer to call it an "after you", "no, after you" deadlock. Getting this draft approved is the way to break that deadlock.

> 
>>> -- <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27234#c2>
>>> And, in their URL specification:
>>>> Support for <zone_id> is intentionally omitted.
>>> -- <https://url.spec.whatwg.org/#host-representation>
>>> This is not just a question of getting them interested, nor one of resourcing. As their discussion points out, there are likely a number of additional security and user interface issues which would need to be addressed.
>>
>> It's unclear that any of those issues remain in the bis. There were certainly issues of that kind in RFC6874 itself.
>>
>>> The Shepherd Writeup says that has been circulated with the W3C TAG, the HTTP WG, and the ART area.
>>> The TAG review was requested less than an hour ago:
>>>    https://github.com/w3ctag/design-reviews/issues/774
>>> At a minimum, the IESG should allow that process to complete. Given the size of their queue, this may take some time.
>>> In the HTTP WG, I only see two relevant messages:
>>>    
>>> https://www.w3.org/mid/CAPxZtjHf29s-b8M68uAcphpznbqBhjgfw0EYZHi__0Di
>>> [e-mail] I wouldn't characterise this as a review.
>>> I couldn't find any relevant messages on the ART list in the last two years. If I've missed something in either case, pointers would be appreciated.
>>
>> It's been raised in DISPATCH more than once, most recently during the 6MAN adoption call in February 2022. I don't recall that anyone in DISPATCH suggested raising it on ART or HTTP. I thought that's what IETF Last Call was for, anyway.
> 
> The document's shepherd writeup claims that it had been discussed in those places.

It's written in the present tense. The authors will of course respond to all feedback that reaches us.

> 
>>> The questions that I think the IESG needs to address in evaluating this document are:
>>> 1. Should we be publishing a document where there is zero demonstrated implementation interest, and furthermore significant implementer concerns (as outlined above)?
>>
>> Those concerns are what prompted this bis document to be written. The whole point of specifying it now is to avoid divergent implementations when the need is recognised.
> 
> Yes, but let's be clear, this is hope-based standardisation.

Precisely. It's not exactly the first time the IETF has done that.

> 
>> If it had been as easy a fix for Firefox as it turned out to be for 
>> wget, I'd have implemented it myself. But in any case, it's now on 
>> for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=700999#c94
>>
>> (It's a two-line fix in wget. Sadly, the Firefox parsers (plural) are 
>> too complex for ordinary mortals to patch in a reasonably short 
>> time.)
>>
>>
>>> 2. Should lower-layer WGs be documenting how higher-layer protocols actually use the lower layer constructs, without buy-in or substantial review from those higher layer communities?
>>
>> Yes, because if we don't nobody else will. And we've exposed this work to review both via DISPATCH and over at WHATWG (https://github.com/whatwg/url/issues/392#issuecomment-873744002), not to mention on the issue trackers for both Firefox and Waterfox.
>>
>>> 3. If so, what precedent does that set for the network determining how applications use it? Here, I'm particularly concerned about the struggles regarding security and privacy between the layers.
>>
>> I don't see any kind of precedent here. The tail sometimes wags the dog, but I am at loss to see which is the tail and which is the dog in this case.
>>
>> As far as we're aware of any *new* security or privacy issues, they're discussed in the draft. Substantive comments are of course welcome.
> 
> In this case I'm not referring to security or privacy concerns in *this* draft. I'm alluding to what seem to be constant efforts by folks to expose application information and control at the network layer -- sometimes in the IETF, sometimes elsewhere.

It's more the opposite in this case: lower layer information intruding into the presentation layer.

> 
>>> 4. Given the above, will publishing this document impact the IETF's credibility/legitimacy in the eyes of browser implementers and other communities?
>>
>> Yes. It will show that we admit and fix our mistakes.
> 
> Another way of doing that would be to move 6874 to historic until the implementations actually agree to do this.

That would produce precisely no results. We (the lower layer people who need this) have been wating for 9 years already.

> 
> All of this said, I'm not strongly against publishing this -- I just want to make sure the IESG has considered these questions before doing so. It'd be extremely helpful to hear (one way or another) from browser implementers in this discussion.

Certainly, but they are busy people. We've contacted the names we have off-list several times.

      Brian

> 
> Cheers,
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------