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

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

On Sat, Mar 25, 2023 at 08:31:28AM +1300, Brian E Carpenter wrote:
> On 25-Mar-23 02:29, Jürgen Schönwälder wrote:
> > Rob,
> > 
> > using '"(%.+)"' in the IP address types may be the most liberal answer
> > and in line with the interface YANG module. Applications using
> > draft-ietf-6man-rfc6874bis will have to resort to %-encodings to deal
> > with forward slashes and the like, which likely is OK in the web
> > context.
> 
> But they can't, under the ABNF proposed by rfc6874bis. It isn't obvious
> to me that percent-encoding is "legal" anywhere in the host part of a URI
> (although https://w%57w.ietf.org does appear to work, which demonstrates
> both percent-encoding and case-folding). Current practice for "%" inside
> an IPv6 literal varies between browsers.

Yes, you are right.
 
> > I do not think we can make the assumption that interface names are
> > case insensitive. On Linux, it seems very well possible to have
> > interfaces that only differ in case. But this would be more an issue
> > for draft-ietf-6man-rfc6874bis and not for YANG data models.
> 
> Agreed. But the case-insensitivity of the host part of a URI is
> 100% clear. So even if Linux allows this, it's never going to work
> in the URI context (and the draft already makes that clear).

Yes, but in the YANG context, we can support case-sensitive names.

For the URIs, we got IPvFuture but that there could be case-sensitive
elements in an address was likely not anticipated. Future-proofing is
hard.

> > I do not think that defining a new zone name type and then to have
> > mappings to this new type makes sense. Existing implementations and
> > APIs use interface names. Deploying a new indirection may take
> > forever.
> 
> Agreed. That's why the draft says what it now says, as a practical
> matter. Jürgen, have you checked this paragraph?
> https://www.cs.auckland.ac.nz/~brian/draft-ietf-6man-rfc6874bis-06X.html#section-1-5
> > Concerning your second question, I believe that changing the canonical
> > format of typedef is a backwards incompatible change and hence I kept
> > the numeric version. At the end, both, the zone name and the zone
> > number have only local significance. The main difference may be that
> > the name may be more stable than the number across device reboots.  If
> > I would start from scratch, I would prefer to use the name for this
> > reason.
> 
> I'm not sure why the name is intrinsically more stable than the number;
> in Linux (today) the name will change if the MAC address changes when
> a card is replaced, for example.

I was alluding to systemd, which tries to provide predictable
interface names. There is no 100% stability guarantee but apparently
some people do care about keeping interface names predictable.

/js

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://constructor.university/>