I have reviewed draft-ietf-6man-rfc6874bis-02. I personally very much
appreciate this piece of work. The document is well written, it
clearly specifies the adopted solutions plus the alternatives that
were considered. I believe the implementation of this specification
will help to reduce operational surprises, being able to cut and paste
scoped IPv6 addresses between tools without having to edit them is
highly desirable.

That said, I do have a small technical comment. The introduction says:

   It should be noted that in contexts other than a user interface, a
   zone identifier is mapped into a numeric zone index or interface
   number. The MIB textual convention InetZoneIndex [RFC4001] and the
   socket interface [RFC3493] define this as a 32-bit unsigned integer.

The catch here is that the interface index is (for historic reasons) a
_signed_ 32-bit integer where only the positive numbers are used. This
goes back to the IF-MIB and its roots in the MIB-I designed 30+ years
ago. This interface number range has been carried forward into the
YANG world, the YANG module defined in RFC 8343 limits the range of an
interface index to 1..2147483647. The fact that the number ranges do
not fully line up may not really matter much in practice but it is one
of the subtle inconsistencies that we have curated over time.

The quoted text is not saying anything wrong, however, interface
numbers are effectively restricted to just the positive signed 32-bit
integers. Perhaps add to the end of the paragraph a small hint that
the number ranges do not really line up.

   (Note that interface numbers are limited to positive signed 32-bit
   integers (see InterfaceIndex defined in [RFC2863] and if-index
   defined in [RFC8343]) while the zone index allows for unsigned
   32-bit integers.)

/js