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

Elwyn Davies <elwynd@dial.pipex.com> Tue, 19 July 2005 10:36 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DupSH-0008Bq-6Q; Tue, 19 Jul 2005 06:36:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DupSE-0008Bd-Hu for ipv6@megatron.ietf.org; Tue, 19 Jul 2005 06:36:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29238 for <ipv6@ietf.org>; Tue, 19 Jul 2005 06:35:59 -0400 (EDT)
Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dupvl-00080U-7y for ipv6@ietf.org; Tue, 19 Jul 2005 07:06:38 -0400
Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DupRu-0006zr-M5 for ipv6@ietf.org; Tue, 19 Jul 2005 11:35:43 +0100
Message-ID: <42DCD7BF.1070603@dial.pipex.com>
Date: Tue, 19 Jul 2005 11:36:47 +0100
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IPv6 WG <ipv6@ietf.org>
References: <6.2.1.2.2.20050715113550.02ab8288@mailhost.iprg.nokia.com>
In-Reply-To: <6.2.1.2.2.20050715113550.02ab8288@mailhost.iprg.nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Content-Transfer-Encoding: 7bit
Subject: Re: IPv6 WG Last Call: <draft-ietf-ipngwg-icmp-name-lookups-12.txt> with PS
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

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

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
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------