On Dec 9, 2003, at 1:14 AM, Brian E Carpenter wrote:
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.
I could live with that.
- Alain.
-
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 im
Brian E Carpenter wrote:
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.
Sorry- I'm lost in pronouns
Alain,
Your proposal below is fine. Brian, what do you think?
Eliot
Alain Durand wrote:
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
Keith Moore wrote:
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 application implementors:
a) avoid using SL addresses in applications that exchange address
Keith Moore wrote:
>
> > 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 application implementors:
>
> a) avoid using SL addresses in applicat
Those are very good to mention as well.
- Alain.
Keith Moore wrote:
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 application implementors:
a) avoid
> 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 application implementors:
a) avoid using SL addresses in applications that exchange addresses
b) don't
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
impl
> > 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 d
Alain Durand wrote:
I have a last comment on section 4 deprecation.
The document says:
"The special behavior of this prefix MUST no longer be supported in new
implementations"
and later on it says:
"Existing implementations and deployments MAY continue to use this prefix."
I find those 2 state
[EMAIL PROTECTED] wrote:
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. Carp
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
13 matches
Mail list logo
