Hi Jürgen, Netmod, & rfc6874bis interested parties,
In my AD review of draft-ietf-netmod-rfc6991-bis-15, Jurgen has proposed a
change to definition of the zone-id in the ip-address, ipv4-address, and
ipv6-address types. These changes move the definition somewhat closer to what
is in rfc6874bis, but they are still different enough that we don't have wide
compatibility.
I think that it may be useful to have a discussion to see if we can find a
technical solution that works both for YANG models and that is compatible with
being used in URIs. Hence, I've separated my AD review comments for these two
specific issues into this separate thread to try and ensure that interested
parties can be involved in the discussion:
(2) In RFC 6991:
typedef ipv6-address {
type string {
pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
+ '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
+ '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
+ '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
+ '(%[\p{N}\p{L}]+)?';
In draft-ietf-netmod-rfc6991-bis-15, p 27, sec 4. Internet Protocol Suite Types
typedef ipv6-address {
type string {
pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
+ '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
+ '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
+ '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
+ '(%[A-Za-z0-9][A-Za-z0-9\-\._~/]*)?';
I'm not saying that this change is wrong, but this technically looks to be a
non-backwards-compatible change (depending on whether interface names could
ever use non-ASCII characters). Where is the set of allowed characters for
zone-ids defined? I couldn't find them in an RFC, RFC 4007 section 11.2 seems
to indicate that there is no restriction. draft-ietf-6man-rfc6874bis, which
I'm currently holding a 'discuss' ballot position on, effectively limits the
usable character set of zone-ids to the unreserved set in URIs, which seems to
match those above except for '/' that is allowed above (and used in many
interface names), but not in the URI's unreserved character set. A further
difference is that upper case characters are allowed in this typedef but are
not allowed when used in the host part of URIs.
Update - I've now seen the thread 'ipv6-address in RFC 6991 (and bis)', and
Jürgen has put together a useful blog post, thanks!
Given that "interface-name" in RFC 8343, and the text in RFC 4007 section 11.2,
then arguably the safest thing here would be to allow the zone-id to be
unrestricted, i.e., "(%.*)?" However, this would leave
draft-ietf-6man-rfc6874bis as only being able to support a small fraction of
interface names as zone-ids in URLs. The authors of draft-ietf-6man-rfc6874bis
seem to indicate that it works for all interface names that currently matter
for their use case.
An alternative solution could be to somewhere define the zone-ids in YANG to
match the restrictive set in draft-ietf-6man-rfc6874bis (i.e., lower case only,
and disallow '/'). I think that this would then require that we recommend a
conversion of interface names into draft-ietf-6man-rfc6874bis compatible
zone-ids interface-names. E.g., such a conversion could take the interface
name, and change any uppercase characters to lower case, and replace any symbol
that isn't in the allowed character set with '_'. This conversion is
effectively one way, and there is a theoretical risk that the converted
interface names could collide, but this may be unlikely in practice.
Obviously, this conversation doesn't handle non-ASCII interface names, but I'm
not sure how realistic it is that they would be used anyway.
This general comment also applies for the same change for 'ipv4-address'.
(3) draft-ietf-netmod-rfc6991-bis-15, p 28, sec 4. Internet Protocol Suite
Types
The canonical format of IPv6 addresses uses the textual
representation defined in Section 4 of RFC 5952. The
canonical format for the zone index is the numerical
format as described in Section 11.2 of RFC 4007.";
Would it make sense to also change the canonical format for the zone index to
be interface name (or converted interface name) rather than numeric id (when
used in YANG models)?
This comment also applies for the same change for 'ipv4-address'.
Thoughts and comments on these two issues are welcome.
Regards,
Rob
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
