[IPv6]Re: Working Group Last Call draft-ietf-6man-zone-ui

["Martin J. Dürst" <[e-mail]>]

On 2024-09-26 02:32, David Schinazi wrote:
> I've followed this draft through its history, and just read through the
> latest version. I support publication.
> David

Same here. Like David, I also have been involved in trying to find a 
solution to the problem, although that was quite some time ago (see 
https://datatracker.ietf.org/doc/draft-fenner-literal-zone/)

I'm also happy to see this problem come to a conclusion after so many 
years, although it's probably not the conclusion we imagined at the start.


Looking at 
https://www.ietf.org/archive/id/draft-ietf-6man-zone-ui-03.html in detail:


On the open issue, unless this has already been settled, I'd be in favor 
of formally updating RFC 4007. That makes it easier for implementers to 
follow the breadcrumbs.


While I'm at it, a few suggestions for textual improvement (I'm 
perfectly okay even if none of these get taken up):


Section 1: I'm not happy about the fact that the Introduction is longer 
than all the rest of the document (including sections 2 and 5, which are 
only boilerplate). It's probably too late, but ideally, lots of Section 
1 would be moved back to a new section entitled "Use Cases" or some such.


Section 3: In the sentences "If this is impossible for practical 
reasons, the UI could support an alternative delimiter in place of "%"."
and "If this too is impossible for practical reasons, the UI could 
support two separate input fields...", I'm not sure about the 'could'.

It's somewhat confusing that we say SHOULD at the start but then only 
'could' later. It may make sense if we use 'could' for a number of 
equally advisable alternatives, but we have a strictly prioritized list.

So I'd either stay with the current prioritized list but use at least 
'should' and maybe even 'SHOULD' (and at the end of the list, add 
something like "If all of the above is impossible, use some other way to 
make it possible for the user to enter or select the desired zone 
identifier."), or convert to describing the alternatives as equally 
advisable and leave the 'could' (or better change to a 'can').


Section 4, "As explained in [RFC4007], zone identifiers are of local 
significance and must not be sent on the wire.": I'd add *only* to make 
things even clearer, resulting in "As explained in [RFC4007], zone 
identifiers are of local significance only and must not be sent on the 
wire."


Section 4, "For example, a limit to 16 ASCII characters would correspond 
to the existing limit on Linux interface names.": Besides what has 
already been discussed, I'd change "a limit to" to "a limit of". English 
is neither my mother tongue, nor do I know formal English grammar, but 
I'd say that while the very 'limit' goes together with the preposition 
'to' (to limit something to something), nouns don't take specific 
prepositions.


Regards,   Martin.

> On Tue, Sep 24, 2024 at 2:10 PM Jen Linkova <[e-mail]> wrote:
> 
>> This message starts a new 6MAN Working Group Last Call on
>>   the "Entering IPv6 Zone Identifiers in User Interfaces" document
>> (https://datatracker.ietf.org/doc/draft-ietf-6man-zone-ui/)
>>
>> Substantive comments and statements of support for publishing this
>> document should be directed to the [e-mail] mailing list.
>>
>> Editorial suggestions can be sent to the authors.  This last call will
>> end on Fri Oct 11 2024, 23:59:59 UTC.
>>
>> --
>> Cheers, Jen Linkova (with her 6MAN chair hat on)
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
>> --------------------------------------------------------------------
>>
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> --------------------------------------------------------------------

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan