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

[Brian E Carpenter <[e-mail]>]

Shang,

On 08-Apr-23 15:00, Shang Ye wrote:
> 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.

Yes, we'll update that text a bit.

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

Yes, my (rarely running) Linux box agrees. They allow most special
characters but not /. Will fix the example.

The actual rules on Linux are allegedly at
https://unix.stackexchange.com/questions/451368/allowed-chars-in-linux-network-interface-names

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

Because we got dozens of messages... I agree it's better to be more precise.

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

I agree. We didn't understand the impact of the case folding rule
until recently.

>      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*. 

Yes, I noticed that recently too. Strange, but that's what they wrote.

> 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 ..."?

Yes. That sentence will be rewritten anyway because RECOMMENDS is not
an RFC 2119 term.

Thanks
    Brian

> 
> Regards,
> Shang
> 
>