On 08-Apr-24 05:37, Jürgen Schönwälder wrote:
Please see inline...

On 06.04.24 22:50, Brian E Carpenter wrote:

I am discovering your draft as I type, but I assume you are referring to
typedef uri {}. Assuming that RFC6874 is indeed obsoleted, you can just
forget about this issue until something changes.

I do see a quite different glitch in your typedef uri {}. If the host
part of a URI is a literal IPv6 address, normalizing to uppercase
contradicts Section 4.3 of RFC5952 which says:

'4.3.  Lowercase

     The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address
     MUST be represented in lowercase.'

Therefore, normalizing to uppercase would be an error. However, I think
your text is wrong anyway: section 6.2.2.1 of RFC3986 applies to hex
digits *within a percent-encoded triplet* and in fact hex digits in the
host part would be normalized to lowercase.

So where your draft reads "except for hexadecimal digits", it should
read "except for hexadecimal digits within a percent-encoded triplet",
for consistency with RFC3986 and RFC5952.

I will do the following change:

OLD

        [...] All unnecessary
        percent-encoding is removed, and all case-insensitive
        characters are set to lowercase except for hexadecimal
        digits, which are normalized to uppercase as described in
        Section 6.2.2.1.

NEW

        [...] All unnecessary
        percent-encoding is removed, and all case-insensitive
        characters are set to lowercase except for hexadecimal
        digits within a percent-encoded triplet, which are
        normalized to uppercase as described in Section 6.2.2.1
        of RFC 3986.

Yes, that's perfect.


While I'm here, I looked at typedef ipv6-address {}. Two comments:

1. "If the zone index is not present, the default zone of the device
will be used."
FYI, although RFC 4007 describes the default zone, it's optional. For
example, there is no default zone on Linux; if you execute a socket call
with a zero or null zone, it's a run-time error.

I am pretty optimistic that you can memset a sockaddr_in6 to zero and
then fill out the sin6_addr field and things will work.

I'm afraid not. If you call sendmsg() with a link-local destination and
a zero sin6_scope_id, you get "[Errno 22] Invalid argument". If you call
it with a non-existing positive value, you get "[Errno 101] Network is
unreachable".

Tested on my Linux machine with the attached Python script. And I knew
this anyway from testing with ping.

Perhaps the zero
is not what RFC 4007 calls the default zone, then we need to find
better wording. But then RFC 4007 also says:

     An implementation should also support the concept of a "default" zone
     for each scope.  And, when supported, the index value zero at each
     scope SHOULD be reserved to mean "use the default zone".

However, that "should" and "SHOULD" have not been implemented for Linux.


2. There seems to be a limited character set for the zone ID. RFC 4007
doesn't restrict the character set; it just says "non-null strings".
IMHO that's a bug, but if I want to name an interface
*%!@#$^&()_-+=:;'"?\|}{}{/.><, it's allowed by the RFC. (The text
doesn't even specify ASCII, and the remark about "conflict with the
delimiter" is meaningless, if you think about parsing.)

If you intend to limit the character set more than RFC 4007 does, that
should be stated, and probably discussed on the 6man list.

Yes, the zone ID is underspecified, and we can't really fix that. What
we had did not allow forward slashes, although they are used by some
vendors. So we are trying to improve but whatever we do is debatable
since the zone ID is underspecified. (On Linux, I am pretty sure an
interface name does not even have to be ASCII or UTF-8. Whatever we
end up doing, we will likely assume UTF-8.)

OK, I understand that choice. Maybe you should say in the description
that the zone ID is underspecified in the RFC?


This is why I suggested to write an ID that explains what happens if
people go creative with zone IDs so that people know that certain zone
IDs will not play nice with YANG modules, certain zone IDs will not play
nice with URLs and so on. People can than take an informed decision and
deal with the consequences.

Well, I think 6man really ought to clean up RFC 4007 in this respect.
But that is a battle for another day.

    Brian
import socket

def tryz(zone):
    try:
        print("Trying zone", zone)
        sock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
        sock.connect(("fe80::2e3a:fdff:fea4:dde7", 12345, 0, zone))
        result = sock.sendmsg([msg_bytes])
        print("Result:", result, "bytes sent")
        sock.close()
    except Exception as e:
        print(e)

msg_bytes = bytes(b"Test")

tryz(socket.if_nametoindex("wlp2s0"))
tryz(99)
tryz(0)



        




_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to