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

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

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.

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

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

Regards
    Brian

> 
> 
> Regards,
> Shang
>