Subject: I-D ACTION:draft-ietf-ipv6-deprecate-site-local-00.txt

From: [email-masked]
Date: Tue, 26 Aug 2003 15:17:49 -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		: Deprecating Site Local Addresses
	Author(s)	: C. Huitema, B. Carpenter
	Filename	: draft-ietf-ipv6-deprecate-site-local-00.txt
	Pages		: 8
	Date		: 2003-8-26
	
This document describes the issues surrounding the use of IPv6 site-
local unicast addresses in their original form, and formally
deprecates them. This deprecation does not prevent their continued
use until a replacement has been standardized and implemented.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-deprecate-site-local-00.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-deprecate-site-local-00.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.

---

From: Fred Templin <[email-masked]>
Date: Tue, 26 Aug 2003 13:33:15 -0700

Brian and Christian,

Very good draft, but in the first sentence of section 4 please
s/link-local/site-local.

I believe the same comment applies also to the first sentence
of section 5, but please check my thinking on that one.

Fred
[email-masked]

>implementation to automatically retrieve the ASCII version of the

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Alain Durand <[email-masked]>
Date: Tue, 26 Aug 2003 14:10:46 -0700

I was first happy to see this document coming. However, I'm a bit 
disappointed.
The section on the ambiguity of SL is good, still I'm not sure those
are the only problems with SL...
But, what is more worrisome is the notion that the ipng wg
has to find a replacement for SL:

"In its meeting in March 2003, the group reached a measure of agreement 
that these
issues were serious enough to warrant a replacement of site local
addresses in their original form"

 From the current discussion, this is not at all clear that this is waht 
we have to do.
As Margaret articulated very clearly:

 > There are a number of situations (disconnected sites,
 > intermittently connected sites, etc.) where provider-allocated
 > addressing is not a good method for address assignment.
 >
 > We need to figure out how these networks should be addressed.
 > Our solution(s) may (or may not) require various properties of
 > "local addressing":  a provider-independent address prefix,
 > addresses that are defined to have limited routability,
 > addresses with special autoconfiguration properties, etc.
 >
 > Margaret

Also worrisome is the implicit endorsement of the Hain/Templin and
Hinden/Haberman drafts as 'the' replacement solution:

"Obviously, site locals also have some benefits, without
 which they would have been removed from the specification long ago.
The perceived benefits of site local are that they are simple,
stable, and private [Hain/Templin]. However, it appears that these
benefits can be also obtained with an alternative architecture, for
example [Hinden/Haberman], in which addresses are not ambiguous and
do not have a simple explicit scope."

Hinting that there is work currently underway to provide solutions
where SL was useful and PA does not work is ok.
Taking side in the current raging debate over those two drafts in not ok.

    - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Aug 2003 13:50:40 +0200

Alain,

Thanks. It's clear that the wording in this draft has to be tuned to
intercept the WG's consensus, when there is a clear consensus. I think
the present wording is what the authors thought they heard in Vienna.
Obviously, the next version needs to be tuned to where the discussion
has gone since then. But let's not wordsmith until there is some clarity
in the WG.

As for the "replacement" sentence, I can agree that it is not yet
a WG consensus, although it is certainly the view of a substantial
number of people. Again, this can certainly be tuned.

What *really* matters is whether people are happy with
section 4, the actual deprecation text. That is the standards action
proposed by the draft.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Aug 2003 13:52:34 +0200

Fred, what an embarassing pair of typos you have discovered.
Thanks!

   Brian