On Wed, Apr 24, 2024 at 6:41 PM Brian E Carpenter < [email protected]> wrote:
> Re: > "The interface name MUST be represented in the UTF-8 charset [RFC3629] > using the Default Language [RFC2277]." > > draft-carpenter-6man-zone-ui is wending its way in 6man, and it's been > suggested that we should clarify the allowed character set for RFC4007 zone > identifiers, which are in practice interface names. At the moment, RFC4007 > simply says they are "strings" without signficant qualification. > > For example, "Ethernet1/1-George.sjc" would be a completely legal zone > identifier under RFC4007. As has also been observed, so would > "blåbærsyltetøy0/0/0". > > Opinions welcome, here or on 6man. Consistency of the two drafts seems > desirable. > One piece of input to thinking about interface names might be RFC8343, which defines the interface name as a yang string. RFC7950 says that a yang string is Unicode (including tab, carriage return, and line feed), but doesn't mention a language. I've seen some systems which use SNMP ifDescr values like "Interface adapter foo", and the yang interface name has a correspondence with the SNMP ifDescr (it doesn't *have* to be 1-1, but it can be). I imagine that specifying this kind of name as a zone ID is difficult both at the CLI and in a URI. The SNMP INET-ADDRESS-MIB contains a mapping between ifIndex value (corresponding to a specific interface, thus a specific interface name) and an RFC4007 zone ID (presumably with the use case that an ifDescr value might not be appropriate for a zone ID) - but for your purposes, this is a circular reference back to the RFC that you're asking about the semantics of. In my mind, the strong correlation between interface name and zone ID only works when the interface name is easy to use as a zone ID, and it's the responsibility of the system to create easy-to-use zone IDs (and supply the mapping) when the interface names are not easy to use. I don't know if this concept carried over from SNMP to yang, though. Given this, what do I think about talking about zone IDs in draft-carpenter-6man-zone-ui? Personally, I would say that a zone ID SHOULD be printable (non-control, non-space) Unicode - that's a restriction from what can be used for an interface name. I don't know what to think about specifying a language like RFC5837 does. BCP18 says, the default should be English unless you negotiate something else. There's no negotiation in zone IDs, so would we say, MUST be English, or, imagine that system configuration is a kind of implicit negotiation -- it's not unreasonable to imagine that a system that is configured in Norway could present its blueberry jam interface the way you describe. RFC8343 doesn't specify anything here, and I would lean towards that more-recent spec reflecting current thinking on this topic. Bill > On 25-Apr-24 12:16, Bill Fenner wrote: > > Hi all, > > > > I've updated the node ID ICMP extension draft that I presented in > intarea in Brisbane. The motivation for this work is that we got a request > from a customer to append the hostname to the interface name field in the > RFC5837 response, e.g., > > > > 2 10.2.2.3 <INC:99,10.10.2.3,"Ethernet1/1-George.sjc",mtu=1500> 11.322 > ms > > > > and I thought it was more productive to create a standard way to encode > the hostname in the message itself. > > > > The change from the -00 document is that on a suggestion from Reji > Thomas, I've made the packet format a strict subset of that in RFC5837. > Since this data is intended for presentation to users, this is useful since > one doesn't have to write a whole new TLV parser; one can reuse the one > that already exists for RFC5837 and just change the user-visible output. > > > > Sample hop output from traceroute with this additional info printed as > "NODE": > > > > 2 10.2.2.3 > <INC:99,10.10.2.3,"Ethernet1/1",mtu=1500;NODE:2001:db8::137f,"George.sjc"> > 11.322 > ms > > > > This represents an RFC5837 "incoming interface" info record with ifIndex > 99, incoming address 10.10.2.3, etc., and a node ID IP > address 2001:db8::137f. In this example the IPv4 addresses are private, > but the node ID IP address can be a global IPv6 address. > > > > The IANA has assigned Class-Num 5 to this document. > > > > Your feedback on this idea is most welcome. > > > > Name: draft-fenner-intarea-extended-icmp-hostid > > Revision: 01 > > Title: Extending ICMP for Node Identification > > Date: 2024-04-23 > > Group: Individual Submission > > Pages: 9 > > URL: > https://www.ietf.org/archive/id/draft-fenner-intarea-extended-icmp-hostid-01.txt > < > https://www.ietf.org/archive/id/draft-fenner-intarea-extended-icmp-hostid-01.txt > > > > Status: > https://datatracker.ietf.org/doc/draft-fenner-intarea-extended-icmp-hostid/ > < > https://datatracker.ietf.org/doc/draft-fenner-intarea-extended-icmp-hostid/ > > > > HTML: > https://www.ietf.org/archive/id/draft-fenner-intarea-extended-icmp-hostid-01.html > < > https://www.ietf.org/archive/id/draft-fenner-intarea-extended-icmp-hostid-01.html > > > > HTMLized: > https://datatracker.ietf.org/doc/html/draft-fenner-intarea-extended-icmp-hostid > < > https://datatracker.ietf.org/doc/html/draft-fenner-intarea-extended-icmp-hostid > > > > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-fenner-intarea-extended-icmp-hostid-01 > < > https://author-tools.ietf.org/iddiff?url2=draft-fenner-intarea-extended-icmp-hostid-01 > > > > > > Abstract: > > > > RFC5837 describes a mechanism for Extending ICMP for Interface and > > Next-Hop Identification, which allows providing additional > > information in an ICMP error that helps identify interfaces > > participating in the path. This is especially useful in environments > > where each interface may not have a unique IP address to respond to, > > e.g., a traceroute. > > > > This document introduces a similar ICMP extension for Node > > Identification. It allows providing a unique IP address and/or a > > textual name for the node, in the case where each node may not have a > > unique IP address (e.g., the IPv6 nexthop deployment case described > > in draft-chroboczek-intarea-v4-via-v6). > > > > Thanks, > > Bill > > > > > > _______________________________________________ > > Int-area mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/int-area >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
