Subject: I-D ACTION:draft-ietf-ipv6-scoping-arch-02.txt

From: [email-masked]
Date: Fri, 27 Aug 2004 10:40:05 -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 Scoped Address Architecture
	Author(s)	: S. Deering, et al.
	Filename	: draft-ietf-ipv6-scoping-arch-02.txt
	Pages		: 23
	Date		: 2004-8-20
	
This document specifies the architectural characteristics, expected
behavior, textual representation, and usage of IPv6 addresses of
different scopes.  According to a decision in the IPv6 working group,
this document intentionally avoids using the syntax and usage of
unicast site-local addresses.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-scoping-arch-02.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-ipv6-scoping-arch-02.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-ipv6-scoping-arch-02.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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 28 Aug 2004 14:44:39 +0900

Hi Margaret,

I think I've addressed all IESG comments on the scoping-arch draft in
this revision.  It would be nice if the IESG could check to see
whether this can be approved.

Thanks,

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

>>>>> On Fri, 27 Aug 2004 10:40:05 -0400, 
>>>>> [email-masked] said:

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 Aug 2004 10:02:32 +0200

In section 11.7:

>    The preferred format for literal IPv6 addresses in URL's are also
>    defined [12].  

However, reference [12] (RFC 2732) will be obsoleted by
draft-fielding-uri-rfc2396bis-06, which includes the material
from 2732, plus correct ABNF, and is in IETF Last Call.

>    ...When a user types the preferred format for an IPv6
>    non-global address whose zone should be explicitly specified, the
>    user could use the format for the non-global address combined with
>    the preferred format.
> 
>    However, the typed URL is often sent on the wire, and it would cause
>    confusion if an application did not strip the <zone_id> portion
>    before sending.  Note that the applications should not need to care
>    about which kind of addresses they're using, much less parse or strip
>    out the <zone_id> portion of the address.  Also, the format for
>    non-global addresses might conflict with the URI syntax [13], since
>    the syntax defines the delimiter character (`%') as the escape
>    character.

[13] is RFC 2396, which will be obsoleted by draft-fielding-uri-rfc2396bis

Actually there is no problem with the conflict, except that in a URI,
a percent sign has to be percent-encoded as %25. So zone_id 1 would
be represented in a URI as %251.

>    Hence, this document does not specify how the format for non-global
>    addresses should be combined with the preferred format for literal
>    IPv6 addresses.

I'd want a URI syntax expert to check, but I'm not sure that
there is any problem with %251, %252, etc. It's ugly, but using
literal addresses is always ugly. The real question is whether there
would ever be any *need* to specify a zone_id in a URI.

>    As for the conflict issue with the URI format, it
>    would be better to wait until the relationship between the preferred
>    format and the URI syntax is clarified.  

It is clarified by draft-fielding-uri-rfc2396bis.

>    ...In fact, the preferred
>    format for IPv6 literal addresses itself has the same kind of
>    conflict.  

No, it's a very different conflict. % is a global escape character
in URIs, which is why it has to be escaped itself as %25. The colons
in IPv6 addresses are simply delimiters. I think this sentence is
unnecessary.

>    ...In any case, it is recommended to use an FQDN instead of a
>    literal IPv6 address in a URL, whenever an FQDN is available.

Indeed.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 Aug 2004 10:05:33 +0200

P.S. I'm quite aware that this has already passed the IESG,
but it will obviously have to be updated one day, so please
keep these comments in a safe place.

    Brian

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 31 Aug 2004 22:21:42 +0900

>>>>> On Tue, 31 Aug 2004 10:05:33 +0200, 
>>>>> Brian E Carpenter <[email-masked]> said:

> keep these comments in a safe place.

I interpret this to mean that you are not requiring to revise the
draft addressing your comments.  But it seems we can reflect some of
your points during the editorial work with the RFC editor.

If my understanding is NOT correct, please say so explicitly.

>> be represented in a URI as %251.

Yes, but the point is that the escaped format would not be able to be
passed to, e.g., getaddrinfo() directly.  It would decrease the
benefit of the extended format with the "%" delimiter.  Also, we
then could not simply copy-n-paste a literal IPv6 address with a zone
identifier from output of some other command.  It would also decrease
the benefit of the format.

So, for example, does it help to revise this paragraph as follows?
(i.e., adding several sentences at the end of the paragraph)

   However, the typed URL is often sent on the wire, and it would cause
   confusion if an application did not strip the <zone_id> portion
   before sending.  Note that the applications should not need to care
   about which kind of addresses they're using, much less parse or strip
   out the <zone_id> portion of the address.  Also, the format for
   non-global addresses might conflict with the URI syntax [13], since
   the syntax defines the delimiter character (`%') as the escape
   character.  This conflict would require, for example, that the
   <zone_id> part for zone 1 with the delimiter be represented as
   '%251'.  But it also means that we could not simply copy a
   non-escaped format from other sources as input to the URI parser.
   Additionally, if the URI parser does not convert the escaped format
   before passing it to a name-to-address library, the conversion will
   fail.  All these issues would decrease the benefit of the textual
   representation described in this section.

>> would ever be any *need* to specify a zone_id in a URI.

Regarding %251 or %252, see above.

Regarding the "real question", I'd say it should at least be rare, so
we could simply remove the URI issues if it can be a blocking problem.
But I can imagine some usage similar to the example shown in Section
11.4, considering many today's leaf routers have web interface, and
thus I believe providing some notes might help.

>> in IPv6 addresses are simply delimiters. I think this sentence is

I would say those were the same problem before the clarification of
rfc2396bis.  But I understand that the conflict with colons is not an
issue any more with rfc2396bis.

So, perhaps we can just simply this paragraph to:

   Hence, this document does not specify how the format for non-global
   addresses should be combined with the preferred format for literal
   IPv6 addresses.  In any case, it is recommended to use an FQDN
   instead of a literal IPv6 address in a URL, whenever an FQDN is
   available.

Does this make sense to you?

					JINMEI, Tatuya