Subject: IPv6 WG Last Call: <draft-ietf-ipngwg-icmp-name-lookups-12.txt>

From: Bob Hinden <[email-masked]>
Date: Fri, 15 Jul 2005 11:39:55 -0700

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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 19 Jul 2005 11:11:55 +0100

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

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 19 Jul 2005 11:36:47 +0100

PS
s7: The IANA considerations should refer to the IANA considerations in 2463bis 
(draft-ietf-ipngwg-icmp-v3-07.txt).

Some comments:

Substantive:

Editorial nits:

Regards,
Elwyn

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 20 Jul 2005 16:25:28 +0900

>>>>> On Fri, 15 Jul 2005 11:39:55 -0700, 
>>>>> Bob Hinden <[email-masked]> said:

> list.  Editorial comments can be sent to the authors.

I've confirmed my previous comments were addressed in this version.
I'm okay with submitting this draft.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]