Subject: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-11.txt

From: [email-masked]
Date: Fri, 06 May 2005 15:44:19 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.

	Title		: IPv6 Node Information Queries
	Author(s)	: M. Crawford, B. Haberman
	Filename	: draft-ietf-ipngwg-icmp-name-lookups-11.txt
	Pages		: 14
	Date		: 2005-5-6
	
This document describes a protocol for asking an IPv6 node to supply
   certain network information, such as its hostname or fully-qualified
   domain name.  IPv6 implementation experience has shown that direct
   queries for a hostname are useful, and a direct query mechanism for
   other information has been found useful in serverless environments
   and for debugging.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-11.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipngwg-icmp-name-lookups-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-11.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Mon, 9 May 2005 10:56:35 -0400

All,
      A refreshed version of the ICMP Name Lookups draft is available.
I would especially like WG members who have implementations to
review the draft and point out discrepancies between the spec and
their code (e.g. unimplemented features).

      There are several comments that I will be looking to resolve prior
to the publication of a new version.  Those are:

      1. Is there a need to delay the sending of a Query addressed to
          an anycast address?

      2. Clarification in the functionality of the NOOP

Please send comments to me or the mailing list.

Regards,
Brian

On May 6, 2005, at 15:44, [email-masked] wrote:

> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 19 May 2005 08:38:24 +0900

>>>>> On Mon, 9 May 2005 10:56:35 -0400, 
>>>>> Brian Haberman <[email-masked]> said:

> their code (e.g. unimplemented features).

Thanks for your effort of revising the document.  I've reviewed the
latest draft, and have some comments.  (I must confess in advance that
I don't fully remember the past discussions on this document, and that
I may be repeating points already discussed before.)

Regarding discrepancy with our (KAME/BSD) implementation, whereas I've
not done "line-by-line" checks between the spec and the implementation,
it seems the implementation supports all the features described in the
latest draft type/code/Qtype-wise.

However,
  - our implementation currently does NOT delay the response to an
    anycasted or multicasted query.
  - it does NOT support the proxy responder service.
  - it still supports the "Supported Qtypes" Qtype which is now marked
    as "unused" (as far as I know this is just because we've not fully
    followed recent changes of the spec).

Other general comments follow:

1. In section 2, this document is too specific about particular
   implementations:

     [...]  An example of a IPv6 debugging tool using IPv6 Node
     Information Queries is the ping6 program in the KAME, USAGI, and
     other IPv6 implementations <http://www.kame.net>.

   I'm afraid this is not very appropriate for a general specification
   document.  Instead, we might say:

     [...]  An example of an IPv6 debugging tool using IPv6 Node
     Information Queries is the ping6 program in some platforms.

2. it seems to me that the notion of "proxy" is suddenly introduced in
   Section 5.  I think it should be clearly defined beforehand, e.g.,
   in Section 3.

3. In Section 3, the draft reads:

     The Query concerns a "Subject Address" (which may
     differ from the Queried Address) or a "Subject Name".

   We may also want to note that the Subject Address is not even an
   IPv6 address (i.e., it can be an IPv4 address).

4. I'm afraid the reference to the MD5 spec (RFC1321) in Section 5
   should be a normative reference in this context.  (If
   icmp-name-lookups is expected to be published as a PS, this may
   cause a problem since RFC1321 is informational.)

5. I don't see why we need the TTL field for Node Name, Node
   Addresses, and IPv4 Addresses if it MUST be always 0.  Perhaps this
   is just for backward compatibility to existing implementations,
   though...(if so, I believe we should explicitly note that, since
   otherwise future readers will have the same question)

6. In section 5, the draft reads:

     [...]  If the
     Queried Address was anycast or multicast, the source address for the
     Reply SHOULD be one belonging to the interface on which the Query was
     received.

   I don't see the strong reason in this case for choosing the source
   address on the receiving interface.  If we need to give guidance
   about the source address in these cases, I think we can (or even
   should) just refer to RFC3484.

7. Should we still need the "S" and "C" flags for the Node Addresses
   Query even though site-local unicast addresses and IPv4-compatible
   IPv6 addresses are now deprecated?

8. RFC2535 (DNSSEC) was updated by RFC4033-4035.  We may want to
   update the reference as well.

And here are some editorial comments:

(throughout the document)
"a NI" should be "an NI"?  (depending on how we pronounce the acronym,
of course).

(section 2)
   [...]  An example of a IPv6 debugging tool using IPv6 Node
=> An example of an IPv6 debugging tool...

(section 5)
   Providing the infrastructure to authenticate NI Queries and Replies
   may be quote difficult outside of a well-defined community.
=>
   ... may be quite difficult(?)

(section 6.3)
   [...]  The Reply Data is a sequence of 128-bit IPv6
   addresses, each address preceded by separate a 32-bit TTL value, with
=> ... by a separate 32-bit TTL value (?)

(section 7)
   The IANA is requested to assign the IPv6 multicast prefix FF02:0:0:0:
   0:2::/96 for use in Node Information Queries as defined in section
   Section 5.
=> ... in Section 5.
  (i.e., remove the redundant "section")

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

---

From: Bob Hinden <[email-masked]>
Date: Wed, 18 May 2005 17:14:46 -0700

Jinmei,

>I may be repeating points already discussed before.)

I have a few thoughts on your comments based on my memory of the history 
:-)  I  was partially responsible for the previous version.

Bob

>     anycasted or multicasted query.

The question here is the delay useful.  To me this would seem useful for 
multicast queries, but I don't see the need for ones for anycast.

>    document.  Instead, we might say:

This was there purposely.  At one point there was a lot of push back on 
moving this forward and it was useful to be very specific about where this 
was implemented and being used.

>    cause a problem since RFC1321 is informational.)

I don't think that would be a problem.

>    otherwise future readers will have the same question)

It is left for backward compatibility.  I agree it would be good to explain 
this.

>    IPv6 addresses are now deprecated?

I think it is useful to leave them for backwards comparability.  We might 
want to add some text explaining this.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 20 May 2005 04:05:59 +0900

>>>>> On Wed, 18 May 2005 17:14:46 -0700, 
>>>>> Bob Hinden <[email-masked]> said:

> multicast queries, but I don't see the need for ones for anycast.

I don't see the need (for anycast), either.  In fact, in the case of
anycast, the query packet should be delivered to a single responder
only, and there should be no possibility of response collision which
the delay would try to avoid.  It should be noted that in the case of
Neighbor Discovery (referred from the name-lookups draft in this
context) a neighbor solicitation to an anycast address may be
delivered to multiple nodes and there may be multiple neighbor
advertisements.  This scenario is very special and totally different
from the name-lookups (or any other normal use of anycast) case.

> was implemented and being used.

Hmm, I do not necessarily oppose to keeping the specific
implementation names (actually, I'd be honoured with that:-), if
others (especially the IESG) accept this.

> I don't think that would be a problem.

Do you mean it's okay to keep the reference informational?  In any
cast, I was actually just wondering, and I'd not oppose to the
decision.

> It is left for backward compatibility.  I agree it would be good to explain 

Okay.

> want to add some text explaining this.

Would it cause compatibility problem if we "reserved" those flag bits
as "unused"?  If we reserve the bits and specify the responder to
ignore those bits, then the responder's behavior will be the same
regardless of the semantics of the flags, since new responders
wouldn't use these "deprecated" addresses in any event.  So I
personally think it's clearer to not include the now-deprecated notion
in a new specification.  But this is not a strong opinion.  Unless
others have particular opinions or preferences, I'll accept the
editor's decision.

					JINMEI, Tatuya

---

From: Bob Hinden <[email-masked]>
Date: Thu, 19 May 2005 14:05:52 -0700

Jinmei,

>from the name-lookups (or any other normal use of anycast) case.

I agree.

>others (especially the IESG) accept this.

Yes, I think it will help.

>cast, I was actually just wondering, and I'd not oppose to the

Sorry I wasn't clear.  I don't think referencing MD5 will be a problem even 
if it is Informational.

>others have particular opinions or preferences, I'll accept the

I have a slight leaning for keeping it as is because of the existing 
implementations, but am happy to leave to the editor's discretion.

Thanks,
Bob