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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
