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

From: "Christian Huitema" <[email-masked]>
Date: Fri, 5 Dec 2003 09:43:34 -0800

> > It would actually be much simpler and less confusing to say only
> > "The special behavior of this prefix SHOULD no longer be supported"
> > and nothing about existing deployments.
> 
> This doesn't work operationally, because people use site-locals today.
> And as we've debated endlessly we don't do flag days anymore.
> 
> IMHO this text is good enough to ship.

I understand Alain's point, the possible confusion about what do in
service packs and other types of upgrades, but we went round and round
and eventually decided to just leave the text as is.

We had a very explicit discussion of this topic during the WG meeting in
Minneapolis, and the sense of the room was rather close to Eliot's
opinion. In fact, I proposed to change the text to Alain's wording, but
Brian Carpenter objected that this would cause more confusion, since we
really want to say "MUST not use" to prevent further usage, and "SHOULD"
does not achieve that. The sense of the room was clearly with Brian. I
guess this is one of the cases where the consensus is a bit rough.

-- Christian Huitema

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Alain Durand <[email-masked]>
Date: Fri, 05 Dec 2003 10:14:08 -0800

The whole story about deprecating Site Local has led to very complex 
discussions
that a lot of people had difficulties to follow, partly because the 
issues are complex
and partly because of the heat of the debate.
As we are coming near to a conclusion to this painful story, I believe 
we owe
implementors and network administrators very clear guidelines on what 
to do now
and confusion in this section of the document is IMHO not acceptable.

I think the key is to dissociate in this text what implementors and 
what network administrator
have to do.

To the implementors:
a) don't implement SL if you are designing a new product
b) don't rush removing SL support from your current products, this can
      be done in future releases.

To network administrators:
a) don't design new networks using SL
b) don't rush redesigning your existing network using SL
     however, don't expect them to work in the future as new 
implementations will not support SL.

If we explain it this way, maybe we can get rid of the MUST/SHOULD 
keywords in this section
as anyway they are inappropriate as the IETF cannot tell nor enforce 
what implementors
or network administrators do or don't.

	- Alain.

---

From: Keith Moore <[email-masked]>
Date: Fri, 5 Dec 2003 15:42:23 -0500

>       be done in future releases.

to application implementors:

a) avoid using SL addresses in applications that exchange addresses
b) don't special-case handling of SL addresses in other kinds of apps

> implementations will not support SL.

c) don't expect future apps to work with SL

to IETF and other standards organizations:

a) don't utilize SL in any future standards

---

From: Alain Durand <[email-masked]>
Date: Fri, 05 Dec 2003 15:15:48 -0800

Those are very good to mention as well.

    - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Dec 2003 15:51:11 +0100

> a) don't utilize SL in any future standards

I certainly agree with all those do's and don'ts and have no problem
with adding them as informative text. But we are writing a normative
document here, to update existing normative documents, so is there really
a problem with using normative words?

Which software release counts as "new" is indeed not a question for
the IETF, and each implementer will have to make his/her own judgement
about exactly when to remove the feature. But I don't think it's wrong to
say that they MUST remove it.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Sat, 6 Dec 2003 12:04:49 -0500

> a problem with using normative words?

It's often seemed to me like a significant part - probably the most 
significant part - of what it means to "deprecate" SL consists of 
things which are probably better stated in non-normative language, 
because the normative language is both too inflexible and too divisive. 
  If section 4 were to start with a non-normative explanation of what it 
means to deprecate SL, and then supply normative language for those 
parts where it makes sense, I think the picture would be clearer.

> say that they MUST remove it.

Well, it does beg the question of how to say whether a particular 
implementation is in conformance.  Many people feel that a MUST 
requirement should be testable, but a MUST requirement that exists at 
some undefined time in the future is not testable.

Personally I don't have a problem with this document saying MUST 
(provided the non-normative text is also there), but I think the text 
that says that future revisions of other specs will not support SL 
might be more important.

Keith

---

From: Eliot Lear <[email-masked]>
Date: Mon, 08 Dec 2003 03:30:37 -0800

Alain,

Your proposal below is fine.  Brian, what do you think?

Eliot

Alain Durand wrote:

> implementors and network administrators very clear guidelines on what to 
> do now
> I think the key is to dissociate in this text what implementors and what 
> network administrator
> have to do.
> 
> To the implementors:

---

From: Eliot Lear <[email-masked]>
Date: Mon, 08 Dec 2003 07:34:54 -0800

> say that they MUST remove it.

Sorry- I'm lost in pronouns here.  Who MUST remove it?  If you're 
referring to new implementations (for some value of new), I agree.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Dec 2003 10:14:35 +0100

The implementer is the only person who can remove it.

As I said in Minneapolis, the problem here is that we don't have
clear versioning in IETF standards. If we could say

"site local was standard in IPv6.1, is deprecated in IPv6.2, and will be
removed from IPv6.3" then the conformance issue is immediately clarified
and implementers know what it means to claim conformance to IPv6.3, i.e. no
site local support.

But I think Keith's suggestion is correct - add in the text descrription
prior to the normative statements. It's the best we can do, let's just
do it.

  Brian

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

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

---

From: Alain Durand <[email-masked]>
Date: Tue, 09 Dec 2003 08:32:39 -0800

> prior to the normative statements. It's the best we can do, let's just

I could live with that.

	- Alain.