Re: [IPv6] I-D Action: draft-ietf-6man-rfc6874bis-06.txt

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

On Fri, Apr 07, 2023 at 04:19:45PM +1200, Brian E Carpenter wrote:
> 
> Four points to note in particular:
> 
> 1. We have addressed Rob Wilton's DISCUSS by two changes: a new
> paragraph [1] that explains that infrastructure devices are out of
> scope, and a work-around described at [2].

I find this text not entirely convincing. Why not instead simply state
very clearly that the textual format does not apply to systems that
use characters that are not allowed? This text kind of says if you
have a device that names interfaces as "Foo/Bar", then you got an
infrastructure device for which this specification does not apply.
But see below for a possible way how we can avoid this...

> 2. We have addressed one part of Murray Kucherawy's DISCUSS by describing the parsing difficulties caused by the % sign [3]. Of course that will need discussion in the WG and in the URI/W3C community.
> 
> 3. We have addressed the other major part of Murray Kucherawy's DISCUSS, the cross-origin security issue, by citing the existing W3C community work on this topic [4]. Adding the zone ID to a link-local address doesn't change their analysis. It's unclear whether their model adequately covers link-local addresses [5] but that doesn't affect the current draft.
> 
> 4. During IETF 116 we became aware of a significant new and immediate use case - search for "NMEA" in the new draft.
> 

Quoting from the Introduction:

   The mapping between the human-readable zone identifier string and the
   numeric value is a host-specific function that varies between
   operating systems.  The present document is concerned only with the
   human-readable string.  However, in some operating systems it is
   possible to use the underlying interface number, represented as a
   decimal integer, as an alternative to the human-readable string.  For
   example, on Linux, a user can determine interface numbers simply by
   issuing the command "ip link show" and then, for example, use
   "fe80::1%5" instead of "fe80::1%Ethernet1/0/1", if the interface
   number happens to be 5.

RFC 3493 defines

       unsigned int if_nametoindex(const char *ifname);

and the Linux man pages claim that this function is also covered by
POSIX standards. Hence, for interface names used as zone names, we
should be reasonably covered. In other words, why not simply use the
following approach:

  extract ZoneID characters
  try to parse them as a numeric zone identifier
  if succcess, done
  otherwise try to parse them using if_nametoindex()
  if success, use the index
  otherwise report failure (or try any future zone name to index mapping function)

What is the rationale for limiting the focus on human readable
strings?  Why not generally support numeric zone indexes as they
should always work and accepting zone names (oops interface names used
as zone names) where this is feasible (i.e., the names use lowercase
unreserved characters)? If we generally support numeric zone indexes,
we would not have to exclude so called "infrastructure devices" since
they should be able to deal with numeric zone indexes as well.

/js

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