Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues)

From: Joel Jaeggli <[email-masked]>
Date: Fri, 15 Jul 2011 09:40:47 -0700

So the rational for the advice document not being combined with the standards action in it is that the later has some polarizing impact, the advice document does not. the advice document is through and done, historic is not.

On Jul 15, 2011, at 8:55 AM, John C Klensin wrote:

> Hi.
> 
> I've been thinking about this and having a few off-list
> conversations and want to make a suggestion that draws together
> a few others.  Since many people don't like my long notes with
> the conclusion at the end, this one is suggestion-first.  If the
> suggestion offends you sufficiently, you can just stop reading
> there.
> 
> Recommendation:
> 
> (1) Abandon the effort to classify the specifications as
> Historic.  It is at best a symbolic act that few people outside
> the IETF community will even notice, much less act differently
> because we have done it.  Instead, let's try to focus on what is
> actually important, not classification and name-called ("curse
> you, you Historic protocol" :-(  ).
> 
> (2) Pull the "-advice" document back from the RFC Editor queue
> and fold the actual substantive content of the "-historic"
> document into it, preferably as a very clear and very prominent
> Applicability Statement.  If this is what v6ops believes, the
> statement might reasonably say something like:
> 
> 	(2a) This protocol, if not used very carefully, leads to
> 	bad operational situations in which things get lost and
> 	the problems are hard to diagnose.   We strongly
> 	recommend that it not ever be a default and that it not
> 	be used except under special circumstances and with
> 	great care.
> 	
> 	(2b) Even then, we recommend that it not be used unless
> 	all of those configuring routing information and all the
> 	systems along the routing path are run by experts who
> 	both understanding the issues and are willing to accept
> 	responsibility.
> 	
> 	(2c) If you do decide to use the thing, the "advice"
> 	recommendations in the rest of this document are
> 	mandatory and MUST be followed to avoid serious
> 	operational problems.
> 
> I haven't included either Randy's colorful language or mine in
> the example above, but the intent should be clear.  Depending on
> how much detail the community thinks is useful, there is a good
> deal of potentially-useful text in draft-moore-6to4-experimental
> as well as in the "-historic" draft.
> 
> The resulting document should explicitly update RFC3056 and
> RFC3068.  Taking that action will send a much stronger "you need
> to read that document before doing anything with this one"
> message to most of the people who are familiar with how things
> work than a reclassification of the base documents.  For those
> who aren't familiar with how things work, all of these
> approaches, including moving 6to4 to Historic, are pointless.
> 
> That is all.  This can and should be made to sound like mature
> engineering advice, which it presumably is, and not like small
> children throwing mud at each other.
> 
> 
> Explanation and Rants:
> 
> (ii) I think moving _this_ protocol to Experimental is just
> silly.  We use Experimental for things that are
> pre-standardization or not sufficiently mature to be
> standardized.  Although the bar is higher, there are elements of
> "experiment" in every Proposed Standard --that is why we have a
> multiple-step standardization process.   If there is really
> something to be learned from 6to4 operated in a different way,
> then the right action to take would be to propose a 6to4bis that
> outlines the characteristics of the protocol, eliminates
> anything we have concluded should not be done, and outlines the
> desired experiment.  That document might reasonably be listed as
> updating RFC3056 and RFC3068 as well.  
> 
> (i) <rant> Presumably our goal is to get IPv6 deployed and
> provide advice useful to its deployment, independent of any
> particular piece of protocol or transition arrangement.  At
> least one of the many reasons we haven't seen more deployment is
> that we keep sending messages to the broader community that,
> however unintentionally, discourage that deployment.  In the
> early days of IPv6, we did that by advertising (or letting
> others who were presumed to be speaking for us advertise) that
> IPv6 was completely ready and that transition was going to be
> easy, cheap, and seamless.  For those who had to make decisions
> as to when to deploy IPv6, sufficient investigation tp discover
> that some of that story was untrue became sufficient motivation
> to back away from IPv6 entirely until we got our acts together.
> In more recent years, we have continued to deliver the message
> that the IETF (and, to a lesser extent the RIRs) are simply
> confused about what advice to give and therefore that IPv6 isn't
> ready for someone to deploy who suffers from limited resources
> and a strong desire to do it only when all of the ducks are
> lined up.  Every time we propose a new transition model or
> denounce an old one without what seems to be an
> externally-convincing analysis of the complete picture, we make
> things worse by distributing yet another chapter of "even the
> IETF has no real idea how to transition to IPv6".
> 
> If we are serious about encouraging deployment of IPv6 -- and I
> hope we are -- then it is time to stop the apparent war among
> transition strategies.  It seems to me that the document that is
> needed is a vastly strengthened (and probably standards-track)
> version of RFC 6180 (a rather nice document that I would
> encourage those who are engaged in the 6to4 debate on the IETF
> list to read), but one that goes beyond such statements as 
> 
> 	There are several types of tunneling mechanisms,
> 	including manually configured IPv6-over-IPv4 tunnels
> 	[RFC4213], 6to4 [RFC3056], automatic host-based tunnels
> 	[RFC4380], tunnel brokers [RFC3053], running IPv6 over
> 	MPLS with IPv6 Provider Edge Routers (6PE) [RFC4798],
> 	the use of Virtual Private Networks (VPNs) or mobility
> 	tunnels to carry both IPv4 and IPv6 [RFC4301] [RFC5454]
> 	[RFC5555] [RFC5844], and many others.
> 
> (from Section 4.2) and into a serious discussion of the
> scenarios that are the best match to different of these
> strategies (and others).  If we don't know, then let's say,
> explicitly, that we haven't had quite enough experience to
> provide a differential chart of when particular techniques can
> be used but that they are out their, with their strengths and
> weaknesses, for situations to which they seem well-adapted.  It
> is almost possible to infer from 6180's conclusions that almost
> all transition mechanisms are equivalent, at least within
> groups, and those that aren't are best dealt with by public
> burning.  Clearly we don't believe the first part of that; we
> should get away from the appearance of believing the second.
> 
> And, again and most important, if we want to see IPv6 deployed,
> we need a clear message that we actually understand what we are
> doing, that we have a coherent picture, and that our process is
> not one of lurching among solutions, hoping that each one will
> be the magic bullet, and then denouncing any that turn out to
> not have sufficient magical properties.  The marketplace knows
> how to deal with the message we are sending with debates about
> recategorization and we have already seen the answer: it isn't
> the universal deployment of IPv6 before now or any time soon.
> </rant>
> 
>    john
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Roger Jørgensen <[email-masked]>
Date: Fri, 15 Jul 2011 19:26:41 +0200

no point in removing v6ops@ for the to: list

---------- Forwarded message ----------
From: Roger Jørgensen <[email-masked]>
Date: Fri, Jul 15, 2011 at 7:25 PM
Subject: Re: Another look at 6to4 (and other IPv6 transition issues)
To: John C Klensin <[email-masked]>, Brian E Carpenter
<[email-masked]>
Cc: [email-masked]

+1 (as in G+) from me.

Get on with the work of rewriting/combining it into one document. It
is for me a much more sound strategy. I've read the -experimental
draft and I don't think it is the sort of document we should publish.

And with some hindsight, we should have combined -historic and
-advisory into one and not attempted to run them side-by-side through
the system :(

ps: thanks for, probably the first grown-up mail on this subject for
quite a while!

--- Roger J ---

--

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Jul 2011 13:53:18 -0400

> draft and I don't think it is the sort of document we should publish.

One of my goals in writing -experimental was to produce a set of statements which are reasonably objective, and thus, which could win community consensus.   If there are incorrect statements in there, or if there are obviously correct statements of relevance which are omitted, please let me know.   Of course, that's a separate question from whether Experimental status is appropriate for 6to4.

Trashing 6to4 was not a goal of -experimental.  Nor IMO is it an appropriate goal, especially when other available transition mechanisms in that space are as bad or worse in their own ways.  

Keith

---

From: Philip Homburg <[email-masked]>
Date: Fri, 15 Jul 2011 19:55:03 +0200

>-advisory into one and not attempted to run them side-by-side through

I think it is much better to keep them separate. 6to4 relies on third
parties running relays. It is important that they keep doing so. 
For that group you don't want a document tells them why not to use 6to4
and then still expect people make it work.

I agree that the -experimental draft could use some work. Independent of
whether marking 6to4 as experimental is a good idea or not.

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Jul 2011 14:33:55 -0400

> whether marking 6to4 as experimental is a good idea or not.

I've had some very useful feedback in private mail, including a couple of important points that need to be captured, e.g.:

- 6to4 was never intended (at least, I don't recall it being intended) to be used by access providers as a means of providing IPv6 service to their customers.  It's not especially well suited for this, especially given that there's really no good way for an access provider to ensure that the return traffic from native v6 networks is routed back to its customers.  6rd is a much better choice for that use case.

- Some routers are being shipped which claim to support IPv6 but which only support 6to4.  I don't think this is appropriate either, because 6to4 has inherently diminishing applicability and the reason a customer might want a v6-compatible router is so he can upgrade to v6 later.   Routers that advertise v6 support need to support native v6 in addition to whatever transition mechanisms they choose to support. 

(there's more detail than that - the above is just a summary)

I'll try to get a revision out right after Quebec.   

Keith

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 Jul 2011 11:55:18 -0400

Hi.

Recommendation:

	

Explanation and Rants:

    john

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 Jul 2011 14:29:28 -0400

Ack.

I removed it only because I'm not a participant in the WG (I
have enough aggravating problems at the applications layer) and
don't have posting privileges on that list.  But I'm certainly
willing to have anything I say on the subject copied to v6ops if
that is useful to the WG.

   john

--On Friday, July 15, 2011 19:26 +0200 Roger Jørgensen
<[email-masked]> wrote:

> Subject: Re: Another look at 6to4 (and other IPv6 transition
> issues) To: John C Klensin <[email-masked]>, Brian E
> Carpenter <[email-masked]>
> Cc: [email-masked]
> 
> 
> +1 (as in G+) from me.
> 
> Get on with the work of rewriting/combining it into one
> document. It is for me a much more sound strategy. I've read
> the -experimental draft and I don't think it is the sort of
> document we should publish.
>...

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 Jul 2011 14:52:32 -0400

--On Friday, July 15, 2011 09:40 -0700 Joel Jaeggli
<[email-masked]> wrote:

> So the rational for the advice document not being combined
> with the standards action in it is that the later has some
> polarizing impact, the advice document does not. the advice
> document is through and done, historic is not.

Joel (and others),

I understand the rationale.  At the risk of repeating myself, I
simply do not think it works or is appropriate.  Recategorizing
set of documents as "Historic" is an extremely blunt instrument.
If we do it in a consistent and logical fashion, the advice
document would have to go to Historic along with the base
documents because giving advice about a piece of ancient history
is meaningless.  That is not what most people who like the
advice document intended, at least as I understood the consensus
on that Last Call.

Worse, for those who are successfully operating 6to4 and finding
it useful, reclassifying the specifications to Historic sends a
clear message that, from their perspective at least, the IETF is
clueless (since "Historic" essentially says the thing is useless
and/or that no one is using it... and they know better because
they are a counterexample).   The consequence of that, in turn,
is that they either simply ignore the advice or conclude that
they should postpone IPv6 deployment until the IETF gives advice
that is both coherent and believable.

I think there are probably a dozen "right" ways to do this, with
the differences depending on issues that I haven't followed
v6ops or 6to4 deployment closely enough to have opinions about.
What they have in common is a real analysis of issues and some
meaningful recommendations ("-advice" seems to do much of that)
and the used of "updates" to effectively incorporate that advice
and guidance into the base spec.   If that is better done with a
standalone document that references the base spec and the advice
document, updating all of them, I'm fine with it (although,
under that scenario, I'd prefer to have the advice document on
standards track).   

Finally, if we had a wonderful transition model that would work
well in all situations, then it would make sense to recommend it
and depreciate everything else.   We don't.  What we have are a
bunch of mechanisms, each with advantages and disadvantages,
some much better adapted to particular situations than others.
It would be easier if we had a good single solution, but we
don't... that is life, or at least engineering.  Given that, we
serve the community much better with analyses and explanations
of tradeoffs (and RFC 6180 is, IMO, a really good start) than we
do by going through exercises of figuring out what to denounce.
IMO, the _only_ thing we should be categorically denouncing are
tactics and strategies that encourage people to put off getting
serious about IPv6.  Unfortunately, trying to slap a "Historic"
label on one particular transition strategy, or to rank
transition strategies that have proven useful to some actors on
the basis of how much various of us loathe them, are about
denunciation and, however unintentionally, with the risk of
encouraging people to sit and wait, not about progress or
network engineering.

back to lurking...
    john

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 15 Jul 2011 11:53:15 -0700

I added you to the approved list on as soon as I moderated the message.

On Jul 15, 2011, at 11:29 AM, John C Klensin wrote:

> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 15 Jul 2011 12:17:08 -0700

On Jul 15, 2011, at 11:52 AM, John C Klensin wrote:

> simply do not think it works or is appropriate.

And there are people that disagree with you on that.

>  Recategorizing

<SNIP>

> and depreciate everything else.

You missed the boat about a decade back I guess. Transition technologies (none of them) are a substitute for actual deployment. They should naturally decline in popularity and in fact in the portions of the internet where we can measure them they are. Right now if we try and fit a story to the evidence that is happening because of host changes, and  not because of deployment. ipv4 is becoming less usable and it's taking autotunnels with it, nobody here has a proposal that changes that.

>   We don't.  What we have are a

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Jul 2011 12:37:36 -0700

Hi Joel, 

> ipv4 is becoming less usable and it's 
> taking autotunnels with it, nobody here has a proposal that 
> changes that.

As far as I can tell, IPv4 is not becoming less
usable within my organization's network.

Thanks - Fred
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Jul 2011 15:43:12 -0400

> usable within my organization's network.

You realize that you have not contradicted what Joel said, right?     The IETF's business isn't making sure that Boeing's networks are functional, much as we might collectively wish you well in that regard.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 Jul 2011 08:34:22 +1200

On 2011-07-16 03:55, John C Klensin wrote:

> Applicability Statement.  

I am very strongly against this. The advisory document received extremely
strong support and excellent technical input from a wide cross section
of the IPv-anything operational community and has been fully approved
and is ready to go. I originally hoped it could be published for
World IPv6 Day, but having missed that date, it remains urgent to get
it out there, and to publicise it to operators who are not aware
of the issues.

We can spend another few months debating the exact form of words for
a normative document advising implementors to do what most of them
are now doing; I don't care and it basically doesn't matter except
in the IETF's tiny world. That isn't what's important. What's
important is to get as many operators as possible doing what they
can to ameliorate the situation.

   Brian

---

From: Mark Townsley <[email-masked]>
Date: Fri, 15 Jul 2011 22:57:01 +0200

> - Some routers are being shipped which claim to support IPv6 but which only support 6to4.  I don't think this is appropriate either, because 6to4 has inherently diminishing applicability and the re…

Sadly, the time to have made that point was around 2005 before 6to4 without any native support whatsoever made it into the most widely followed home router recommendations for IPv6 at the time. 

- Mark

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 Jul 2011 17:01:30 -0400

--On Saturday, July 16, 2011 08:34 +1200 Brian E Carpenter
<[email-masked]> wrote:

>...
> We can spend another few months debating the exact form of
> words for a normative document advising implementors to do
> what most of them are now doing; I don't care and it basically
> doesn't matter except in the IETF's tiny world. That isn't
> what's important. What's important is to get as many operators
> as possible doing what they can to ameliorate the situation.

Brian,

It seems to me that you can take two positions here, but not
both as the same time.

Position #1: What the IETF does, and how it classifies things,
actually make a difference.  If that is true then the advice
document should look a lot more mandatory and should certainly
be shown as updating the 6to4 base documents (I note that the
latter decision could be made without reopening the document in
any significant way).  Whether it is part of the advice document
or not, an applicability statement that discusses what is really
going on is important and reclassification to Historic would be
stupid.  If nothing else, unless it reclassifies your advice doc
to Historic as well, reclassification to Historic would be
appeal-bait.  And classifying your document as Historic also
would rather dilute the message.

Position #2: How the IETF classifies things makes very little
difference in this space because people will follow advice that
seems sensible and ignore everything else.  If so, it makes
little difference how your document is approved or where it is
published.  For example, it could have come through the
Independent Stream or been pushed into CCR.  No problem.  And
the "Historic" effort is a huge waste of the community's time,
no matter how it comes out.

Just my opinion -- you will probably continue to disagree.

best,
   john

---

From: "Keith Moore" <[email-masked]>
Date: Fri, 15 Jul 2011 17:18:06 -0400

-- 
  Keith Moore
  [email-masked]

On Fri, 15 Jul 2011 22:57 +0200, "Mark Townsley" <[email-masked]>
wrote:
> Sadly, the time to have made that point was around 2005 before 6to4
> without any native support whatsoever made it into the most widely
> followed home router recommendations for IPv6 at the time. 

Better late than never.  And better to say precisely what is meant than
to say something vague, loud, and likely to be misinterpreted.

Keith

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Jul 2011 16:10:04 -0700

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Friday, July 15, 2011 12:43 PM
> To: Templin, Fred L
> Cc: [email-masked] Operations; IETF Discussion
> Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 
> transition issues)
> 
> You realize that you have not contradicted what Joel said, 
> right?     The IETF's business isn't making sure that 
> Boeing's networks are functional, much as we might 
> collectively wish you well in that regard.

If the IETF wishes organizations such as ours well, then
they should be willing to provide operational guidance.
RFCs 4057 and 4852 were a small step in that direction,
while 'draft-templin-v6ops-isops' provides actionable
information.

Fred

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 15 Jul 2011 13:28:46 -0700

Joel's widget number 2

> usable within my organization's network.

Stasis is great if you can get it... There are two drafts proposing the use of shared address space space to be assigned by ARIN for LSN  that will probably turn up in opsawg.

Whether the get it or not the LSNs will be deployed.

And yeah I think Boeing probably has enough v4 addresses for a while.

Joel

---

From: Ronald Bonica <[email-masked]>
Date: Sat, 16 Jul 2011 16:03:55 -0400

Hi John,

I think that most of the rancor around RFCs 3056 and 3068 is due to RFC 2026's very terse definition of HISTORIC. According to RFC 2026, "A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the Historic level." That's the entire definition. Anything more is read into it.

Granted, the phrase "for any other reason considered to be obsolete" is pretty subjective. In this thread, I have seen people interpret that phrase as follows:

"the IETF thinks that there are no longer any valid use cases for this technology"
"the IETF recommends that you remove this technology from your network"
"the IETF believes that nobody is using this technology"

I doubt if any of these interpretations are valid, because the IETF is not in a good position to evaluate what is in use or tell an operator how to run a network. A more likely interpretation is as follows:

"the IETF is not likely to invest effort in the technology in the future"
"the IETF does not encourage (or discourage) new deployments of this technology.

                                                   Ron

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Joel Jaeggli
> Sent: Friday, July 15, 2011 3:17 PM
> To: John C Klensin
> Cc: [email-masked]; IETF Discussion
> You missed the boat about a decade back I guess. Transition
> technologies (none of them) are a substitute for actual deployment.
> They should naturally decline in popularity and in fact in the portions
> of the internet where we can measure them they are. Right now if we try
> and fit a story to the evidence that is happening because of host
> changes, and  not because of deployment. ipv4 is becoming less usable
> and it's taking autotunnels with it, nobody here has a proposal that
> changes that.
>

---

From: Keith Moore <[email-masked]>
Date: Sat, 16 Jul 2011 16:49:35 -0400

> "the IETF is not likely to invest effort in the technology in the future"

Such a determination seems premature.  There are some ideas floating around for protocol fixes to deal with some of the operational problems associated with 6to4.  It's too early to know whether there are significant flaws with them or whether they can get traction.  Admittedly, v4 address space exhaustion along with the introduction of LSN means that 6to4 has diminishing applicability.  But for those nets and hosts that still have access to the public IPv4 internet, it's conceivable that the reliability of 6to4 can be considerably improved.  (Though of course it will never be as good as be as a well-run native v6 service.)   At some point, some evaluation of cost vs. benefit needs to be made; and the "cost" of not fixing 6to4 needs to consider the consequences of using other tunneled transition mechanisms besides 6to4.   

Put another way:  Given that there are admittedly several operational issues associated with 6to4, there are at least four strategies that might be employed:

1. Encourage changes to the operational practices that are causing problems that are associated with 6to4.
2. Discourage all use of 6to4 in the strongest possible terms.
3. Discourage use of 6to4 except in the cases where it is believed it can work well.
4. Improve the 6to4 protocol to address some of the issues.

IMO, -advisory tries to do #1;  -historic tries to do #2; -experimental tries to do #3.  #4 is something I hope can be discussed, informally, in Quebec.  We should have a better idea after the meeting how workable this is.

Keith

---

From: John C Klensin <[email-masked]>
Date: Sat, 16 Jul 2011 18:52:38 -0400

--On Saturday, July 16, 2011 16:03 -0400 Ronald Bonica
<[email-masked]> wrote:

> Hi John,
> 
> I think that most of the rancor around RFCs 3056 and 3068 is
> due to RFC 2026's very terse definition of HISTORIC. According
> to RFC 2026, "A specification that has been superseded by a
> more recent specification or is for any other reason
> considered to be obsolete is assigned to the Historic level."
> That's the entire definition. Anything more is read into it.

If you include a certain amount of oral tradition that predates
and surrounds 2026 in "read into it", I agree.  It may be worth
remembering that 2026, like most similar documents, didn't
invent anything but was intended to reflect a community
consensus that existed about what should be done.  Documents
like 2026 never capture that consensus exactly or
comprehensively.  Whether that informal consensus means anything
once we write something down is a question that we rarely ask
ourselves, probably for good reason.

> Granted, the phrase "for any other reason considered to be
> obsolete" is pretty subjective. In this thread, I have seen
> people interpret that phrase as follows:
> 
> "the IETF thinks that there are no longer any valid use cases
> for this technology" "the IETF recommends that you remove this
> technology from your network" "the IETF believes that nobody
> is using this technology"
 
> I doubt if any of these interpretations are valid, because the
> IETF is not in a good position to evaluate what is in use or
> tell an operator how to run a network. 

I think the first interpretation can be valid although it must
be used with great caution.   For example, I think we might all
agree that there are no remaining valid use cases for NCP,
despite the fact that TCP/IP could be argued to have replaced it
rather than precisely superceding it.  Another, perhaps better,
example is that Novell IPX is almost certainly dead
("proprietary protocol abandoned by its owner" is a pretty good
predictor of "no valid use cases").  We wouldn't think using it
for anything in a contemporary network would be useful even if,
e.g., it has better scaling properties.  Interestingly, while
RFC 1234 and 1553 were were moved to Historic, we have one Full
Standard (RFC 1123, STD 49), an Informational document (RFC
1634), a Proposed Standard (RFC 1420), and a some Experimental
documents (RFC 1791, RFC 1792).  That pretty much covers the
whole range of possibilities.    

If I didn't have the view that housekeeping exercises that
require community review and consensus were usually a poor use
of resources (see other note today), getting this whole pack
swept into Historic on the "no valid remaining use cases"
principle would be entirely appropriate.  One could still not
prove that no one is using it: I have every reason to believe
that someone out there is still running Netware and happy about
it.

> A more likely interpretation is as follows:
 
> "the IETF is not likely to invest effort in the technology in
> the future" "the IETF does not encourage (or discourage) new
> deployments of this technology.

Noting in passing that these sorts of statements are quite close
to the uses 2026 prescribes for Applicability Statements (and
for which we have even more precedent and oral tradition), if
the first of those is an adequate reason for identifying
something as historic, I recommend that we immediately move RFC
791 to Historic.  Certainly we are likely to invest more effort
in the development of the technology.  Now, some people would
read such a move as either an indication, as you suggest above,
that the IETF thought no one was using it any more, or that
there were no remaining valid use cases, etc., immediately
turning us into a laughingstock.  But, by logic that suggests
moving 6to4 to Historic on the grounds that the IETF is not
going to invest effort in the technology.

So I think we disagree.

best,
   john

>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Joel Jaeggli
>> issues)
>> > I understand the rationale.  At the risk of repeating
>> > myself, I simply do not think it works or is appropriate.
>> 
>> > set of documents as "Historic" is an extremely blunt
>> > instrument. If we do it in a consistent and logical
>> > fashion, the advice document would have to go to Historic
>> > along with the base documents because giving advice about a
>> > piece of ancient history is meaningless.  That is not what
>> > most people who like the advice document intended, at least
>> > as I understood the consensus on that Last Call.
>> 
>> <SNIP>
>> 
>> > Finally, if we had a wonderful transition model that would
>> > work well in all situations, then it would make sense to
>> > recommend it and depreciate everything else.
>> 
>> technologies (none of them) are a substitute for actual
>> deployment. They should naturally decline in popularity and
>> in fact in the portions of the internet where we can measure
>> them they are. Right now if we try and fit a story to the
>> evidence that is happening because of host changes, and  not
>> because of deployment. ipv4 is becoming less usable and it's
>> > some much better adapted to particular situations than
>> > others. It would be easier if we had a good single
>> > solution, but we don't... that is life, or at least
>> > engineering.  Given that, we serve the community much
>> > better with analyses and explanations of tradeoffs (and RFC
>> > 6180 is, IMO, a really good start) than we do by going
>> > through exercises of figuring out what to denounce. IMO,
>> > the _only_ thing we should be categorically denouncing are
>> > tactics and strategies that encourage people to put off
>> > getting serious about IPv6.  Unfortunately, trying to slap
>> > a "Historic" label on one particular transition strategy,
>> > or to rank transition strategies that have proven useful to
>> > some actors on the basis of how much various of us loathe
>> > them, are about denunciation and, however unintentionally,
>> > with the risk of encouraging people to sit and wait, not
>> > about progress or network engineering.
>> > 
>> > back to lurking...
>> >    john
>> > 
>> > 
>>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 16 Jul 2011 20:27:39 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John C Klensin
> Sent: Friday, July 15, 2011 2:02 PM
> To: Brian E Carpenter

Well, if this is the prevailing opinion, we can certainly simplify our procedures substantially by eliminating about half of the document states we maintain now, including reducing the standards track down to a single state.

---

From: John C Klensin <[email-masked]>
Date: Sun, 17 Jul 2011 16:32:32 -0400

--On Saturday, July 16, 2011 20:27 -0700 "Murray S. Kucherawy"
<[email-masked]> wrote:

>> Behalf Of John C Klensin Sent: Friday, July 15, 2011 2:02 PM
>> To: Brian E Carpenter
>> difference in this space because people will follow advice
>> that seems sensible and ignore everything else.  If so, it
>> makes little difference how your document is approved or
>> where it is published.  For example, it could have come
>> through the Independent Stream or been pushed into CCR.  No
>> problem.  And the "Historic" effort is a huge waste of the
>> community's time, no matter how it comes out.
> 
> Well, if this is the prevailing opinion, we can certainly
> simplify our procedures substantially by eliminating about
> half of the document states we maintain now, including
> reducing the standards track down to a single state.

I certainly would not claim it is the prevailing opinion.  I
believe it is true and have seen it in action many times but,
beyond that, have no idea.   Also remember that the Standards
Track (including BCP or not), Experimmental, Informational,
Historic breakdown is somewhat orthogonal to the maturity levels
within Standards Track.

That said, I believe, based in part on consensus in at least one
WG that focused on the topic, that, as our standards have become
more complex, with more features, options, and interactions, the
embodiment of the "maturity level" idea as a single set of
category-identifiers has outlived its usefulness.  The reality
is that some features of a particular specification may be
well-tested and very mature while others may still be a bit
questionable and that some specifications may be more
appropriate to some environments and less appropriate to others.
>From that point of view, forcing entire protocols or
specifications into one category or another does both the IETF
community and the users of the specs a disservice: we should be
telling people what we think of a spec, how mature things are,
and what the issues are, if necessary on a
characteristic-by-characteristic basis, not pretending that
assignment of a label communicates significant information.
>From that point of view, reducing the number of categories
increases the odds of classifications being misleading and
communicating little real information, if only from "very
likely" to "near-certain".  But, again, that is just IMO.

    john