Subject: Re: Moving forward on Site-Local and Local Addressing

From: Dan Lanciani <[email-masked]>
Date: Mon, 4 Aug 2003 15:52:22 -0400 (EDT)

|C) Deprecate Site-Local addresses after an alternative is defined, 
|standardized, and in operational practice.  This would mean not advancing a 
|deprecation document until there was operational evidence that the 
|alternative was working and shown to be an improvement over Site-Local 
|addresses.
|
|Note:  In the above choices "Deprecate Site-Local addresses" means 
|publishing an RFC that does the formal deprecation.
|
|Please respond to the list with your preference, or if there is an 
|alternative approach that is an improvement from the ones I outlined.  I 
|hope that many of you will respond.

I vote for C.  Given the disagreement on the "legitimate" uses of site local
addresses (and scoped addressing in general) it will be difficult to be sure
that a replacement actually solves all the problems that everyone concerned
expected site-locals to solve, and does so in a way that is not prohibitively
difficult/expensive to deploy.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
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: "Michel Py" <[email-masked]>
Date: Mon, 4 Aug 2003 15:02:12 -0700

> Dan Lanciani wrote:
> It occurs to me that if we are going to start actually
> counting again (picking the option with the most votes)
> the options offered will tend to skew the result towards
> A by splitting the site-local support between B & C.
> Therefore I wish to cast my vote against A more than
> for C...

Alike other opinion polls, the way the question is asked can make a big
difference indeed.

Michel.

---

From: Soliman Hesham <[email-masked]>
Date: Tue, 5 Aug 2003 02:11:37 -0400

C makes sense to me. 

Hesham

 > ----- Original Message -----
 > From: "Bob Hinden" <[email-masked]>
 > To: <[email-masked]>
 > Cc: <[email-masked]>
 > Sent: Monday, August 04, 2003 9:06 PM
 > Subject: Moving forward on Site-Local and Local Addressing
 > 
 > 
 > > [IPv6 working group chair hat on]
 > >
 > > I think the working group has been making good progress on 
 > replacing
 > > site-local addresses and wanted to get feed back from the 
 > working group on
 > > how we should move forward.  This is not intended to 
 > directly relate to
 > the
 > > ongoing appeal of the working groups decision to deprecate 
 > the usage
 > > site-local addresses, but to get feedback on how to 
 > proceed.  I think it
 > is
 > > very important that we move forward on this issue and not 
 > rehash what has
 > > happened in the past.
 > >
 > > We now have a combined local addressing requirements document
 > > <draft-hain-templin-ipv6-limitedrange-00.txt>, a specific 
 > alternative to
 > > site-local addresses draft 
 > <draft-hinden-ipv6-global-local-addr-02.txt>
 > > (accepted as a working group item at the Vienna IETF), and 
 > will soon have
 > a
 > > draft describing why site-local addresses are being 
 > deprecated and doing
 > > the formal deprecation (authors identified and outline 
 > discussed at the
 > > Vienna IETF).  Note that all of these documents will 
 > proceed through the
 > > normal working group and IETF processes of last calls and review.
 > >
 > > I think legitimate questions have been raised about how 
 > the working group
 > > should go about deprecating site-local addresses given 
 > their maturity in
 > > the current specifications and use in deployed products.  
 > Specifically
 > > should they be deprecated independently from having an alternative
 > solution
 > > available, at the same time an alternative is available, 
 > or sometime after
 > > an alternative is available.  A forth alternative is to not replace
 > > site-local addresses in any form, but I think the working 
 > group has made
 > it
 > > clear that this is not a reasonable alternative.
 > >
 > > I would like to hear from the working group on how we 
 > should proceed.  I
 > > think the choices are:
 > >
 > > A) Deprecate Site-Local addresses independently from 
 > having an alternative
 > > solution available.  This would mean that the working 
 > group should treat
 > > the deprecation, and requirements and solution documents 
 > outlined above
 > > independently from each other.  If there was no consensus on an
 > alternative
 > > a replacement would not happen.
 > >
 > > B) Deprecate Site-Local addresses at the same time as a alternative
 > > solution is agreed to.  This would mean advancing both 
 > documents at the
 > > same time and making them include normative references to 
 > each other to
 > > insure that they were published at the same time.  This 
 > would result in
 > the
 > > deprecation only happening if a consensus was reached on 
 > an alternative.
 > >
 > > C) Deprecate Site-Local addresses after an alternative is defined,
 > > standardized, and in operational practice.  This would 
 > mean not advancing
 > a
 > > deprecation document until there was operational evidence that the
 > > alternative was working and shown to be an improvement 
 > over Site-Local
 > > addresses.
 > >
 > > Note:  In the above choices "Deprecate Site-Local addresses" means
 > > publishing an RFC that does the formal deprecation.
 > >
 > > Please respond to the list with your preference, or if there is an
 > > alternative approach that is an improvement from the ones 
 > I outlined.  I
 > > hope that many of you will respond.
 > >
 > > Thanks,
 > > Bob
 > >
 > >

---

From: [email-masked]
Date: Tue, 5 Aug 2003 14:58:18 +0100

> A) Deprecate Site-Local addresses independently from having 
> an alternative 
> solution available.  This would mean that the working group 
> should treat 
> independently from each other.  If there was no consensus on 
> an alternative 

It is my understanding (and I am obviously not alone in this) that the
WG has already selected the course of action outlined above.

Mat

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 5 Aug 2003 15:39:08 +0100

B

A or C would be acceptable were they to happen but I think they will
not in a reasonable timescale (and as an engineer, I want something
that I can use:-)

In passing, I am one of the third, not the two thirds, and do accept
that we have rough consensus.

Tom Petch

-----Original Message-----
From: Bob Hinden <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: 04 August 2003 19:14
Subject: Moving forward on Site-Local and Local Addressing

>solution is agreed to.  This would mean advancing both documents at
the
>same time and making them include normative references to each other
to
>insure that they were published at the same time.  This would result
in the
>deprecation only happening if a consensus was reached on an
alternative.

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 5 Aug 2003 14:35:50 -0700

I think we should do alternative B, i.e. deprecate and at the same time propose a replacement. Barring that, C is also acceptable. Alternative A is likely to generate fisrt uncertainty, and then a free-for-all, and the risk of some "grass root RFC 1918".

-- Christian Huitema

---

From: "Michel Py" <[email-masked]>
Date: Wed, 6 Aug 2003 08:12:43 -0700

> Aidan Williams wrote
> The current drafts look like progress to me and
> remove the biggest wart of SL: ambiguity.

It's a distraction. The reason SLs are still ambiguous is because of the
deprecation process, not because ambiguity could not be removed. As a
matter of fact, this document is a direct descendant of drafts to remove
ambiguity in SLs.

Michel.

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 9 Aug 2003 10:18:39 -0400

> (accepted as a working group item at the Vienna IETF)

Why do we need both of these?  We just need the hinden work.  The
templin/hain work could be INFO or BCP with some fixing? 

Is that the thought?

> insure that they were published at the same time.  This would 
> result in the 

I will support this but we need to do it now and expediently.

thanks
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 9 Aug 2003 10:22:14 -0400

To support Ralph we do have a responsibility here for those deploying
"production Ipv6 now" (we are now not talking just tests) so I have
another suggestion from Ralp's mail.

If we do not have an agreed to alternative by next IETF Nov 03 we must
move to A.  It is unacceptable to permit users to use site-local and I
believe we do have consensus completely site-locals must be deprecated
and am convinced that those appealing will not win in the WG, with the
Chairs, or the IESG.  We have consensus in the IETF not just the WG that
these must be deprecated.

/jim

> From: Ralph Droms [mailto:[email-masked]] 
> Sent: Monday, August 04, 2003 2:54 PM
> To: [email-masked]
> Subject: Re: Moving forward on Site-Local and Local Addressing
> 
> 
> My understanding of the WG discussion is that deprecation of 
> site-local 
> addresses was discussed and consensus was reached independent of the 
> availability of any alternative solution.  Therefore, based on what I 
> understand to be WG consensus, A is the appropriate way to proceed.
> 
> That's not to say the WG can't change its collective 
> consensus at this 
> point.  But I don't think the previous discussion of 
> deprecation was in any 
> way dependent on devising an alternative solution.
> 
> - Ralph
> 
> At 11:06 AM 8/4/2003 -0700, Bob Hinden wrote:
> 
> >I would like to hear from the working group on how we should 
> proceed.  
> >I
> >think the choices are:
> >
> >A) Deprecate Site-Local addresses independently from having an 
> >alternative
> >alternative a replacement would not happen.
> >
> >the deprecation only happening if a consensus was reached on 
> an alternative.
> >
> >standardized, and in operational practice.  This would mean 
> not advancing 
> >a deprecation document until there was operational evidence that the 
> >alternative was working and shown to be an improvement over 
> Site-Local 
> >addresses.
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 9 Aug 2003 10:24:25 -0400

Implementing is a no brainer for hosts, PDAs, routers etc.
We could get this done with a patches for now and updated releases in 6
months from historical code changes I have seen done across the board
for IPV6 since 1995.  Users can begin to use them though that breaks the
hinden req to hear RAs with new option.  But they will use them.  SLs
are not going to be used in any form.
/jim

> From: Michel Py [mailto:[email-masked]] 
> Sent: Monday, August 04, 2003 3:17 PM
> To: Bob Hinden; [email-masked]
> Subject: RE: Moving forward on Site-Local and Local Addressing
> 
> 
> Bob,
> 
> > Bob Hinden wrote:
> > Please respond to the list with your preference
> 
> I would prefer C. "Rough consensus and running code". 
> Possibly I could live with B, but it greatly depends on how 
> difficult the new solution is to implement. If everyone 
> agrees that implementing the new solution is a no-brainer, 
> then B would be fine. 
> 
> However, if the new solution requires significant coding that 
> many people don't feel too good about it, C is required. We 
> don't want to deprecate for a solution that looked good on 
> paper but proved impossible to implement and be left with zip.
> 
> I have trouble understanding why the issues that applied to 
> site-locals would not apply as well to the new solution until 
> I have seen the new solution.
> 
> IMHO the choice between B and C is premature until we have a 
> clearer view of the alternatives.
> 
> Michel.
>  
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 9 Aug 2003 10:25:43 -0400

The hinden draft has no impact because of "scoping" at all technically
for implementation that was the point.  So the problem is far simpler
and why it is good solution.

What scoping issue do you see?

/jim

> From: Dan Lanciani [mailto:[email-masked]] 
> Sent: Monday, August 04, 2003 3:52 PM
> I vote for C.  Given the disagreement on the "legitimate" 
> uses of site local addresses (and scoped addressing in 
> general) it will be difficult to be sure that a replacement 
> actually solves all the problems that everyone concerned 
> expected site-locals to solve, and does so in a way that is 
> not prohibitively difficult/expensive to deploy.
> 
> 				Dan Lanciani
> 				ddl@danlan.*com

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 9 Aug 2003 10:30:14 -0400

Alain,

I see your point but this is political now.  Meaning several things.
One some IMO have an agenda and strategy for the market with SLs or like
addresses they are not going to let go here.  Two some simply believe
that they are important to the architecture.  Three some believe
link-locals and globals are enough (I am in this camp).  Four some don't
want to risk any NAT potential (I am also in this camp).  

I think we have this known.

1.  Consensus is SLs are not going to achieve consensus.
2.  hinden draft works IMO?

What don't you like about hinden draft "idea"?

Doing what you ask will further delay this very important time-to-market
decision in the IETF IPv6 WG.  We do not have time now for analysis by
paralysis.

/jim

> From: Alain Durand [mailto:[email-masked]] 
> Sent: Monday, August 04, 2003 5:12 PM
> To: Bob Hinden
> Cc: [email-masked]; [email-masked]
> > I think the working group has been making good progress on replacing
> > site-local addresses and wanted to get feed back from the working 
> > group on how we should move forward.  This is not intended 
> to directly 
> > relate to the ongoing appeal of the working groups decision to 
> > deprecate the usage site-local addresses, but to get 
> feedback on how 
> > to proceed.  I think it is very important that we move 
> forward on this 
> > issue and not rehash what has happened in the past.
> >
> > to site-local addresses draft 
> > <draft-hinden-ipv6-global-local-addr-02.txt> (accepted as a working 
> > group item at the Vienna IETF), and will soon have a draft 
> describing 
> > why site-local addresses are being deprecated and doing the formal 
> > deprecation (authors identified and outline discussed at the Vienna 
> > IETF).  Note that all of these documents will proceed through the 
> > I think legitimate questions have been raised about how the working
> > group should go about deprecating site-local addresses given their 
> > maturity in the current specifications and use in deployed 
> products.  
> > Specifically should they be deprecated independently from having an 
> > alternative solution available, at the same time an alternative is 
> > available, or sometime after an alternative is available.  A forth 
> > alternative is to not replace site-local addresses in any 
> form, but I 
> > think the working group has made it clear that this is not a 
> > reasonable alternative. 
> 
> I have a real problem here. As I commented in Vienna and is 
> mentioned in 
> the minutes,
> the entire process this wg is going through is wrong as it is 
> based on a 
> flawed logic.
> 
> We had site local addresses. After lengthy debates, the wg 
> realized that 
> there were
> a number of significant issues that outweighed the reported 
> benefits, so 
> there
> is an attempt to deprecate them. Until now, fine.
> 
> Now, some people convinced the wg that SL addresses were 
> having a role that is not fulfilled by provider aggregated 
> addresses. Fine again.
> 
> Then, we have a  'requirement' document that pretend to 
> explain why we need 'local' addresses. If you read it 
> carefully, and as acknowledged by one 
> of its main
> author in Vienna, almost all of those requirements (if not 
> all) would be 
> fulfilled
> by provider independent addresses. Actually, there is nothing 
> in it that explain why we need 'local range' addresses. The 
> essence of those requirements is in the need for stable 
> addresses that are independent from ISPs.
> 
> So using this document (I checked the new combined one, it is 
> the same 
> issue)
> to justify introducing "local" addresses and doing so without 
> clearly understanding the impact of those "ranged" addresses 
> on the architecture and the current implementation is a 
> flawed process. In particular, we need to understand the 
> impact on address selection, and the layer violation that 
> would be created by coupling DNS views & 
> routing.
> 
> IMHO, what need to happen is the following:
> 
> -1. Make an in-depth study of the consequences of introducing
>       addresses with different ranges.
> 
> -2. Realize that if the issue at stake here has more to do 
> with getting 
> addresses
>       than with their actual scope/range, something probably can be
>       done working with the registries. It might be a cheaper path
>       than changing the protocols. After all, IPv6 addresses 
> are plentiful,
>       we should have easy access to them!
> 
> What to do with Site Local addresses in the meantime is a non 
> issue for me.
> 
>     - Alain.
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 9 Aug 2003 10:38:34 -0400

Michael,

So you believe a disconnected network can simply use globals within a
site when no routers are present?  Note I do.  But I don't want
link-local used on multihomed or multisegment nodes as it won't work and
never will.  See attached diagram.  Either we tell all use globals or we
define some type of PI.  But what we cannot do is discuss it for the
next year leaving the market in limbo? 

I think that is why option A may be my vote if I keep seeing no
consensus to move with the two specs?

from templin/hain spec:

Link-local addresses in IPv6: "are designed to be used for addressing
   on a single link for purposes such as automatic address
   configuration, neighbor discovery, or when no routers are present"
   ([RFC3513], section 2.5.6). By definition, link-local addressing has
   a single link range of operation and will not meet this requirement.

This is so true in the document attached (pdf) duplicate link-locals
across L1 and L2 cause a real problem even if getaddinfo() interface %
command line option is used and creates security problem too.

/jim

> From: Michael Thomas [mailto:[email-masked]] 
> Sent: Monday, August 04, 2003 5:39 PM
> To: Alain Durand
> Cc: Bob Hinden; [email-masked]; [email-masked]
> FWIW, I wasn't there but I agree with Alain. I've
> never seen any compelling evidence that scope qua
> scope is what people actually need. And scope
> brings any number of architectural questions to
> the fore. I'd be much, much more comfortable
> having an up/down pronouncement on whether PI
> addressing is feasible before we march down this
> road. There are very wide implications of both and
> I think there's a tremendous amount of discomfort
> with the possibility that scope will result in a
> back door for NAT's to invade ipv6. I don't think
> that anybody wants that. Before we head that
> direction, I'd like to see PI addressing, in an
> RFC preferrably, pronounced a dead end.
> 
> 		 Mike
> 
> Alain Durand writes:
>  > 
>  > 
>  > Bob Hinden wrote:
>  > 
>  > > group on how we should move forward.  This is not 
> intended to directly 
>  > > <draft-hain-templin-ipv6-limitedrange-00.txt>, a 
> specific alternative 
>  > > group item at the Vienna IETF), and will soon have a 
> draft describing 
>  > > normal working group and IETF processes of last calls 
> and review.  > >  > > I think legitimate questions have been 
> raised about how the working 
>  > > maturity in the current specifications and use in 
> deployed products.  
>  > > alternative is to not replace site-local addresses in 
> any form, but I 
>  > I have a real problem here. As I commented in Vienna and 
> is mentioned in 
>  > the minutes,
>  > the entire process this wg is going through is wrong as it 
> is based on a 
>  > flawed logic.
>  > 
>  > a number of significant issues that outweighed the 
> reported benefits, so 
>  > there
> having a role  > that is not fulfilled by provider aggregated 
> addresses. Fine again.  > 
> explain why we need  > 'local' addresses. If you read it 
>  > by provider independent addresses. Actually, there is 
> nothing in it that  > explain why we need 'local range' 
> addresses. The essence of those  > requirements is in the 
> need for stable addresses that are  > independent from ISPs.  > 
>  > So using this document (I checked the new combined one, it 
> is the same 
>  > issue)
>  > to justify introducing "local" addresses and doing so 
> without clearly  > understanding the impact of those "ranged" 
> addresses on the architecture  > and the current 
> implementation is a flawed process.  > In particular, we need 
> to understand the impact on address selection,  > and the 
> layer violation that would be created by coupling DNS views & 
>  > routing.
>  > 
>  >       than changing the protocols. After all, IPv6 
> addresses are plentiful,
>  > What to do with Site Local addresses in the meantime is a 
> non issue for me.  > 
>  >     - Alain.
>  > 
>  > 
>  > 
>  > Direct all administrative requests to 
> [email-masked]  >

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 9 Aug 2003 10:40:02 -0400

Michel,

But you miss the point in logic that we do not want SLs as currently
defined and major bug in IPv6.

/jim

> Sent: Monday, August 04, 2003 6:14 PM
> To: Jordi Palet Martinez; [email-masked]
> Jordi,
> > Jordi wrote:
> > I see your point, but my feeling is that we can only go to the last 
> > step (of the IETF process) IF it make sense (running code, 
> and then it 
> > means no-brainer), that means that B is fine, but for the 
> same reason, 
> > I can live with C (in theory, B and C are then the same 
> solution) ;-).
> 
> I see your point too; however,
> 
> The difference between B and C is:
> - with B, if the solution proves impossible to develop, we 
> have a failure.
> - with C, if the solution proves possible to develop, we have 
> wasted time.
> 
> As many things, it's a matter of risk management, speed with 
> a risk or slowness without one. The reason I like C better is 
> because I have the feeling that if there was a no-brainer 
> solution that would make B worth the risk someone would have 
> invented it a long time ago. If we were not able to fix 
> site-locals I wonder where the silver bullet to replace them is.
> 
> As Tony pointed out, design engineers for large networks do 
> not design on vaporware. If I can't simulate a solution on a 
> 20-router lab, it ain't going in my network design and I 
> stick with site-locals. Which also means that once the design 
> goes to large-scale deployment there is no way back for at 
> least 5 years, which in turn means that router vendor "C" 
> (yes, the one you are thinking about) is going to keep 
> supporting site-locals because they want to keep my business.
> 
> The question is, do we want to define standards or to we want 
> to encourage the development of proprietary standards? For 
> the record, I use ISL, EIGRP and HSRP; I won't have a problem 
> using vendor "C" site-locals.
> 
> Michel.
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 9 Aug 2003 10:45:15 -0400

Exactly.  SLs are dead maybe the only alternative is A.
/jim

> From: Lars Erik Gullerud [mailto:[email-masked]] 
> Sent: Wednesday, August 06, 2003 9:03 AM
> To: Bob Hinden
> Cc: [email-masked]
> On Mon, 2003-08-04 at 20:06, Bob Hinden wrote:
> 
> should proceed.  
> I'd like to see A happen. Going for B, and even worse C, will 
> just prolong the current state of uncertainty where a lot of 
> people have heard that site-locals might be deprecated, but 
> are uncertain as to whether they need to concern themselves 
> with support for them or not in ongoing development etc.
> 
> Let's just get rid of the darn things and move on - please.
> 
> /leg
> 
>

---

From: Dan Lanciani <[email-masked]>
Date: Sat, 9 Aug 2003 14:59:09 -0400 (EDT)

"Bound, Jim" <[email-masked]> wrote:

|The hinden draft has no impact because of "scoping" at all technically
|for implementation that was the point.  So the problem is far simpler
|and why it is good solution.
|
|What scoping issue do you see?

I didn't say I see a "scoping issue."  I see an issue with removing
site-locals without first providing a replacement that offers the same
(or greater) capabilities.  This is particularly important because there
is no clear agreement on what capabilities site-locals currently offer.
Many site-local detractors argue that site-locals don't provide any
"legitimate" capabilities at all, presumably because scoped addressing
is not itself "legitimate."  If site-locals are removed before we see
their replacement, I have every expectation that some folks will argue
(loudly) that the correct replacement is no replacement.  In the less
extreme case, it seems that subtle combinations of the random restrictions
being suggested for replacements may thwart one or more of the uses that
I expected for site-locals.  Finally, I'm concerned that any solution might
be seen as necessary only for the mythical "enterprise" and thus be cost-
prohibitive for the small business and home user.  We really need so see the
replacement first...

				Dan Lanciani
				ddl@danlan.*com

|/jim
|
|> -----Original Message-----
|> From: Dan Lanciani [mailto:[email-masked]] 
|> Sent: Monday, August 04, 2003 3:52 PM
|> To: [email-masked]
|> Subject: Re: Moving forward on Site-Local and Local Addressing
|> 
|> 
|> |C) Deprecate Site-Local addresses after an alternative is defined,
|> |standardized, and in operational practice.  This would mean 
|> not advancing a 
|> |deprecation document until there was operational evidence that the 
|> |alternative was working and shown to be an improvement over 
|> Site-Local 
|> |addresses.
|> |
|> |Note:  In the above choices "Deprecate Site-Local addresses" means
|> |publishing an RFC that does the formal deprecation.
|> |
|> |Please respond to the list with your preference, or if there is an
|> |alternative approach that is an improvement from the ones I 
|> outlined.  I 
|> |hope that many of you will respond.
|> 
|> I vote for C.  Given the disagreement on the "legitimate" 
|> uses of site local addresses (and scoped addressing in 
|> general) it will be difficult to be sure that a replacement 
|> actually solves all the problems that everyone concerned 
|> expected site-locals to solve, and does so in a way that is 
|> not prohibitively difficult/expensive to deploy.
|> 
|> 				Dan Lanciani
|> 				ddl@danlan.*com
--------------------------------------------------------------------
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: "Michel Py" <[email-masked]>
Date: Sat, 9 Aug 2003 12:53:52 -0700

Jim,

> Jim Bound wrote:
> But what we cannot do is discuss it for the

The reason the market is in limbo in the first place is deprecation
without a replacement. If the market did not need SLs it would not have
gone in limbo over the issue.

Michel.

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 9 Aug 2003 22:41:35 -0400

Agreed.  But we had a bug and a big one.  I think we still have one with
link-locals too :--)
/jim

>Sent: Saturday, August 09, 2003 3:54 PM
>To: Bound, Jim
>The reason the market is in limbo in the first place is 
>deprecation without a replacement. If the market did not need 
>SLs it would not have gone in limbo over the issue.
>
>Michel.
> 
>
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 9 Aug 2003 22:40:49 -0400

OK thanks.  I believe we have a solution all of us should be able to
live with here in hinden and hain/templin works.  If we all really just
make sure they are technically accurate in Aug/Sept have discussion to
move them forward we can wrap them up at Minneapolis (why are we going
to such a cold place in November geeezzzzzzzzzzzz) we can annouce we
figured it out and move forward.  

Then we can deprecate SLs safely.

My input to all of you.  SLs are not even close to the usefulness of the
hinden + hain/templin work.  This stuff will actually be useful and SLs
are not currently.  To me as implementor and working with one of the
largest users/enterprise in the world to determine how to deploy Ipv6
this is going to work.

/jim

>Sent: Saturday, August 09, 2003 2:59 PM
>I didn't say I see a "scoping issue."  I see an issue with 
>removing site-locals without first providing a replacement 
>that offers the same (or greater) capabilities.  This is 
>particularly important because there is no clear agreement on 
>what capabilities site-locals currently offer. Many site-local 
>detractors argue that site-locals don't provide any 
>"legitimate" capabilities at all, presumably because scoped 
>addressing is not itself "legitimate."  If site-locals are 
>removed before we see their replacement, I have every 
>expectation that some folks will argue
>(loudly) that the correct replacement is no replacement.  In 
>the less extreme case, it seems that subtle combinations of 
>the random restrictions being suggested for replacements may 
>thwart one or more of the uses that I expected for 
>site-locals.  Finally, I'm concerned that any solution might 
>be seen as necessary only for the mythical "enterprise" and 
>thus be cost- prohibitive for the small business and home 
>user.  We really need so see the replacement first...
>
>				Dan Lanciani
>				ddl@danlan.*com
>
>|/jim
>|

---

From: Geoff Huston <[email-masked]>
Date: Sun, 10 Aug 2003 17:12:45 +1000

>What don't you like about hinden draft "idea"?

Well - to answer this question of Jims,  I'm not sure it (the Hinden/Haberman
draft) is finished yet - to my mind there are some further
considerations that are relevant here.  I've prepared a commentary
on the proposal as an Internet  draft.  The draft will be published this
week as draft-huston-ipv6-local-use-comments-00.txt

I've also put a copy online at:
http://www.potaroo.net/papers/2003/draft-huston-ipv6-local-use-comments-00.txt

regards,

     Geoff

---

From: "Michel Py" <[email-masked]>
Date: Sun, 10 Aug 2003 12:30:05 -0700

Jim,

>> The reason the market is in limbo in the first place
>> is deprecation without a replacement. If the market did
>> not need SLs it would not have gone in limbo over the
>> issue.

> Agreed.  But we had a bug and a big one.

You are awfully cavalier with taking such risks with the market. What if
the market does not like the replacement? The market will stay in limbo.

Michel.

---

From: Bob Hinden <[email-masked]>
Date: Mon, 11 Aug 2003 16:01:57 -0700

Jim,

>templin/hain work could be INFO or BCP with some fixing?

Yes, that is the plan.  The hain-templin document would be published as 
Informational.

Bob

---

From: Christian Hopps <[email-masked]>
Date: Fri, 29 Aug 2003 06:25:51 -0700

I vote for

> solution available.  This would mean that the working group should 
> treat
> the deprecation, and requirements and solution documents outlined above

Thanks,
Chris.