Re: [IPv6] I-D Action: draft-ietf-6man-rfc6874bis-06.txt

[Shang Ye <[e-mail]>]

On 2023/04/08 06:08, Brian E Carpenter wrote:

> On 08-Apr-23 03:38, Shang Ye wrote:
>> Jürgen & Brian,
>>
>> On 2023/4/7 15:26, Jürgen Schönwälder wrote:
>>
>>> In other words, why not simply use the
>>> following approach:
>>>
>>>     extract ZoneID characters
>>>     try to parse them as a numeric zone identifier
>>>     if succcess, done
>>>     otherwise try to parse them using if_nametoindex()
>>>     if success, use the index
>>>     otherwise report failure (or try any future zone name to index 
>>> mapping function)
>>
>>   From my experience of writing a URI parser, I can tell that this is
>> indeed the right way of parsing a zone identifier. Should we probably
>> mention this process in the document?
>
> I'm not convinced. Eventually of course the socket API will parse
> and verify the zone ID, but I don't believe we should attempt to
> to specify exactly when that happens.
>
>>
>>> What is the rationale for limiting the focus on human readable
>>> strings?  Why not generally support numeric zone indexes as they
>>> should always work and accepting zone names (oops interface names used
>>> as zone names) where this is feasible (i.e., the names use lowercase
>>> unreserved characters)? If we generally support numeric zone indexes,
>>> we would not have to exclude so called "infrastructure devices" since
>>> they should be able to deal with numeric zone indexes as well.
>>
>> Aren't numeric zone indices already supported in the current format
>> because they are exactly human readable strings? Section 11.2 of RFC
>> 4007 also says:
>>
>>      An implementation SHOULD support at least numerical indices that 
>> are
>>      non-negative decimal integers as <zone_id>.
>>
>> So I don't understand why this sentence is necessary:
>>
>>      However, in some operating systems it is possible to use the
>>      underlying interface number, represented as a decimal integer, 
>> as an
>>      alternative to the human-readable string.
>
> Because it's only a SHOULD, so we cannot rely on it.
Of course we cannot rely on it, but this sentence is confusing because 
it says "use the interface number as an alternative to the 
human-readable string" while the interface number is exactly represented 
as a human-readable string in an IPv6 scoped address or a URI.
>
>>
>> On the other hand, the following sentence is mostly true:
>>
>>      For example, on Linux, a user can determine interface numbers 
>> simply
>>      by issuing the command "ip link show" and then, for example, use
>>      "fe80::1%5" instead of "fe80::1%Ethernet1/0/1", if the interface
>>      number happens to be 5.
>>
>> Except that we can't really make a network interface name on Linux
>> contain slashes, can we?
>
> Why not? Have you tried?

Tried as requested:

    [ye@ye-arch ~]$ sudo ip link add Test/1 type dummy
    Error: argument "Test/1" is wrong: "dev" not a valid ifname

>
>>
>> Now that users can work around their inability to use an unsupported
>> interface names in a URI by first converting them into numerical
>> indices, is it possible that we replace the ZoneID ABNF rule with
>>
>>      ZoneID = 1*( %x61-7A / DIGIT / "-" / "." / "_" / "~" )
>>
>> and thus avoid the case-sensitivity issue of zone identifiers 
>> altogether?
>
> The whole point is (for the normal caases) to allow straigthforward 
> cut and
> paste.

That's true.

I have a strong feeling that after this revision the statements about 
the case-sensitivity of zone IDs have become even more confusing. Is 
there a reason why my previous suggestion

    State that the zone ID in a URI is case-sensitive, that
    implementations MAY treat it as case-insensitive and normalize it to
    lower case, and that the use of uppercase letters in a zone ID is
    NOT RECOMMENDED.

wasn't accepted by the authors?

Specifically,

    If an operating system supports case-sensitive zone or interface
    identifiers, identifiers including upper case letters cannot be used
    in a URI.

In this case, why aren't upper case letters excluded from the ABNF rule 
like the characters outside the "unreserved" character set?

    RFC 3986 also states that the host subcomponent of a URI is
    case-insensitive and is normalized to lower case. Section 6.2.2.1 of
    RFC 3986 states unambiguously that "the scheme and host are
    case-insensitive and therefore should be normalized to lowercase".

I find this quote from RFC 3986 very ambiguous. The main reason is that 
the percent-encoded octets in a registered name is normalized to *upper 
case*. So, I feel that it isn't a good idea to define the 
case-sensitivity of zone IDs by using a mere quote. Either we do it 
explicitly, or we don't do it at all, IMHO.

    This specification therefore RECOMMENDS the use of lower case
    letters only when assigning zone identifiers to interfaces.

Here the word "only" is ambiguous before a "when". Recommending "the use 
of lower case letters only" "when ...", or recommending "the use of 
lower case letters" "only when ..."?

Regards,
Shang