Some comments:
Substantive:
s4: Code 1 bullet point: The 'Supported Qtypes' query disappeared from
the rest of the memo some time ago.
s5: para 5: Is the intended effect of the last sentence (defaulting to
accepting all link-local multicast addresses that have been joined) that
sending a NOOP query to (for example) the all-nodes (or all routers)
link local multicast address will elicit a reply from *every* relevant
node on the link that isn't explicitly configured to ignore these
addresses? If this is the intended behaviour then I think it would be
useful to put the example in so that people understand what the
implication is. Presumably it is also a quick way of finding out which
nodes are admitting to listening to a given multicast address.
s5/References: The MD5 Hash ref [11] should be normative.
s6.1: '...and incidentally happens to reveal whether the Queried Address
was an anycast address.' With recent changes that allow anycast
addresses as sources is this comment any longer true?
s6.2: Notice that the compression algorithm is fractionally less useful
than the original because the pointer can't point to as many places in
the label because of the initial offset. I'm sure there must have been
a reason for doing it this way once ;-)
s6.4.1: [wish list] It occurs to me with the mention of tunnels that a
Qtype to find out about the addresses associated with (e.g.) configured
tunnels would be useful (v6 in v4 for example).
s7: I wonder if IETF concensus is a little strong for Codes and Qtypes
for an experimental protocol?
s7: Presumably IANA is being asked to establish a registry for the
Qtypes.. this isn't explicit currently.
Editorial nits:
s1/2: I would use 'mechanisms' instead of 'mechanics'.
s5: para 8: 'If an answer is refused, the Responder may send an NI Reply
with ICMPv6 Code = 1 and no Reply Data.'
This is a policy choice and I think this should be made clear: s/the
Responder may send/depending on local policy the Responder can elect to
silently discard the query or send/
s6.2: It would be useful to quote the section numbers in RFC1035 for the
DNS wire format (s3.1) and the compression algorithm (s4.1.4).
Regards,
Elwyn
Bob Hinden wrote:
This starts a two week IPv6 working group last call on advancing:
Title : IPv6 Node Information Queries
Author(s) : M. Crawford, B. Haberman
Filename : draft-ietf-ipngwg-icmp-name-lookups-12.txt
Pages : 14
Date : 2005-7-14
to Experimental. Please send substantive comments to the IPv6 mailing
list. Editorial comments can be sent to the authors.
This last call will end on July 29, 2005.
Regards,
Bob & Brian
IPv6 WG co-chairs
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
