Re: [netmod] Changes to IPv6 zone definition in draft-ietf-netmod-rfc6991-bis-15

[Jürgen Schönwälder <[e-mail]>]

Please see inline...

On 06.04.24 22:50, Brian E Carpenter wrote:

> I am discovering your draft as I type, but I assume you are referring to 
> typedef uri {}. Assuming that RFC6874 is indeed obsoleted, you can just 
> forget about this issue until something changes.
> 
> I do see a quite different glitch in your typedef uri {}. If the host 
> part of a URI is a literal IPv6 address, normalizing to uppercase 
> contradicts Section 4.3 of RFC5952 which says:
> 
> '4.3.  Lowercase
> 
>     The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address
>     MUST be represented in lowercase.'
> 
> Therefore, normalizing to uppercase would be an error. However, I think 
> your text is wrong anyway: section 6.2.2.1 of RFC3986 applies to hex 
> digits *within a percent-encoded triplet* and in fact hex digits in the 
> host part would be normalized to lowercase.
> 
> So where your draft reads "except for hexadecimal digits", it should 
> read "except for hexadecimal digits within a percent-encoded triplet", 
> for consistency with RFC3986 and RFC5952.

I will do the following change:

OLD

       [...] All unnecessary
       percent-encoding is removed, and all case-insensitive
       characters are set to lowercase except for hexadecimal
       digits, which are normalized to uppercase as described in
       Section 6.2.2.1.

NEW

       [...] All unnecessary
       percent-encoding is removed, and all case-insensitive
       characters are set to lowercase except for hexadecimal
       digits within a percent-encoded triplet, which are
       normalized to uppercase as described in Section 6.2.2.1
       of RFC 3986.

> While I'm here, I looked at typedef ipv6-address {}. Two comments:
> 
> 1. "If the zone index is not present, the default zone of the device 
> will be used."
> FYI, although RFC 4007 describes the default zone, it's optional. For 
> example, there is no default zone on Linux; if you execute a socket call 
> with a zero or null zone, it's a run-time error.

I am pretty optimistic that you can memset a sockaddr_in6 to zero and
then fill out the sin6_addr field and things will work. Perhaps the zero
is not what RFC 4007 calls the default zone, then we need to find
better wording. But then RFC 4007 also says:

    An implementation should also support the concept of a "default" zone
    for each scope.  And, when supported, the index value zero at each
    scope SHOULD be reserved to mean "use the default zone".

> 2. There seems to be a limited character set for the zone ID. RFC 4007 
> doesn't restrict the character set; it just says "non-null strings". 
> IMHO that's a bug, but if I want to name an interface 
> *%!@#$^&()_-+=:;'"?\|}{}{/.><, it's allowed by the RFC. (The text 
> doesn't even specify ASCII, and the remark about "conflict with the 
> delimiter" is meaningless, if you think about parsing.)

> If you intend to limit the character set more than RFC 4007 does, that 
> should be stated, and probably discussed on the 6man list.

Yes, the zone ID is underspecified, and we can't really fix that. What
we had did not allow forward slashes, although they are used by some
vendors. So we are trying to improve but whatever we do is debatable
since the zone ID is underspecified. (On Linux, I am pretty sure an 
interface name does not even have to be ASCII or UTF-8. Whatever we
end up doing, we will likely assume UTF-8.)

This is why I suggested to write an ID that explains what happens if
people go creative with zone IDs so that people know that certain zone
IDs will not play nice with YANG modules, certain zone IDs will not play
nice with URLs and so on. People can than take an informed decision and
deal with the consequences.

/js

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany