Subject: RE: Another look at 6to4 (and other IPv6 transition issues)

From: [email-masked] (Noel Chiappa)
Date: Mon, 18 Jul 2011 11:33:37 -0400 (EDT)

> From: Ronald Bonica <[email-masked]>

    > 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.
    > ...
    > 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.

But in giving other interpretations, are you thereby not comitting the
exact error you call out above: "Anything more is read into it."?

To me, "Historic" has always (including pre-2026) meant just what the
orginal meaning of the word is (caveat - see below) - something that is
now likely only of interest to people who are looking into the history of
networking. (The dictionary definition is "Based on or concerned with
events in history".) I think "obsolete" is probably the best one-word
description (and note that 'obsolete' != 'obsolescent').

(Caveat: technically, it probably should have been 'historical', not
"historic" - "historic" actually means 'in the past, but very noteworthy',
e.g.  'CYCLADES was a historic networking design', so not every historical
protocol is historic.)

	Noel

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 18 Jul 2011 16:20:57 -0400

Noel,

Given that each of us reads something different into the definition of HISTORIC, is there any hope that this thread will ever converge?

                                                                  Ron

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]]
> Sent: Monday, July 18, 2011 11:34 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Another look at 6to4 (and other IPv6 transition issues)
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jul 2011 11:42:25 +1200

On 2011-07-19 11:26, Erik Kline wrote:
> I don't see any "progress".
> 
> We may just have to blacklist any resolvers that have 6to4 clients
> behind them and leave it at that.

Why? How would that help anybody?

What would help is following the steps in the -advisory document.

(Discussing how many angels can dance on the head of an RFC certainly
won't help either. Could we all stop now please?)

   Brian

---

From: "t.petch" <[email-masked]>
Date: Tue, 19 Jul 2011 09:21:51 +0200

----- Original Message -----
From: "Ronald Bonica" <[email-masked]>
To: "Noel Chiappa" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 18, 2011 10:20 PM
> Noel,
>
> Given that each of us reads something different into the definition of
HISTORIC, is there any hope that this thread will ever converge?

No.

What is needed is some lateral thinking, such as the proposal that instead of
trying to shoehorn an RFC into an inappropriate, closed set of maturity levels,
we use a completely different option, namely an Appplicability Statement that
spells out that this magnificent standards track, non-historic piece of
technology now has an extremely limited applicability, and unless you really
know what you are doing, forget it.

Tom Petch.

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

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Jul 2011 08:29:36 -0400

> know what you are doing, forget it.

An Applicability Statement was my first suggestion for how to address the problem, and it's still acceptable to me.

Keith

---

From: Erik Kline <[email-masked]>
Date: Tue, 19 Jul 2011 08:26:26 +0900

---

From: Philip Homburg <[email-masked]>
Date: Tue, 19 Jul 2011 09:28:12 +0200

In your letter dated Tue, 19 Jul 2011 08:26:26 +0900 you wrote:
>> Given that each of us reads something different into the definition of HISTO
>RIC, is there any hope that this thread will ever converge?
>

I don't think there is any need to be overly dramatic about it.

I firmly belive that 6to4 should be moved to historic. But at the same time,
I was looking for a poorly performing IPv6 connection to test happy eyeballs
and didn't find it. 6to4 can just work.

So a less aggressive approach might be in order.

(If you look at the numbers, there are fewer and fewer 6to4 connections to
dual-stack sites because modern operating system releases will prefer IPv4
over 6to4. Of the users who didn't upgrade, there is about 20% with a
completely broken 6to4 setup. What remains is slightly higher latency due to
non-optimal placement of relays)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jul 2011 13:00:39 -0400

>>>>> "Erik" == Erik Kline <[email-masked]> writes:
    >> Given that each of us reads something different into the
    >> definition of HISTORIC, is there any hope that this thread will
    >> ever converge?

    Erik> I don't see any "progress".

    Erik> We may just have to blacklist any resolvers that have 6to4
    Erik> clients behind them and leave it at that.

I don't see how this can scale or possibly work well given 
that I'm allowed to cache DNS info on my mobile device.

I really wish Google had tried putting a 6to4 relay in your network.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Wed, 20 Jul 2011 01:23:28 +0300

> behind them and leave it at that.

Including Google's very own?

Cheers,
Sabahattin

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 22 Jul 2011 13:16:41 +0300

Noel and all,

The meaning of Historic has alway been a bit unclear.  Neither 2026 nor 
its predecessors say enough about this category for RFCs; particularly, 
it fails to describe what are the procedures for moving RFCs to 
Historic, whether one is allowed to publish documents directly to 
Historic, what RFCs may be historicized etc.  The current IESG statement 
clears up one of these issues, ie. how to move IETF Stream RFCs to 
Historic; but what does it actually means was limited to the following 
pieces of text from RFC 2026:

1)
>     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.  (Purists have suggested that the
>     word should be "Historical"; however, at this point the use of
>     "Historic" is historical.)
2)
>     A specification may have been superseded by a more recent
>     Internet Standard, or have otherwise fallen into disuse or disfavor.
(not explicitly stated; may be deduced from the meaning that Historic is 
described)
3)
>     Following each such review, the IESG
>     shall approve termination or continuation of the development effort,
>     at the same time the IESG shall decide to maintain the specification
>     at the same maturity level or to move it to Historic status.
(from Section 6.2)
4)
>     Once the new version has reached the
>     Standard level, it will usually replace the previous version, which
>     will be moved to Historic status.
5)
>     In this case, or when it is felt for some other
>     reason that an existing standards track specification should be
>     retired, the IESG shall approve a change of status of the old
>     specification(s) to Historic.
The cited extracts generally assume that Historic is mostly used to mark 
documents removed from Standards Track in order to denote that they are 
not Internet Standard at any maturity level any more and new 
implementations should not depend on Historic RFCs.  Currently Historic 
is considered in a bit an other way (see below); eg. Experimental and 
Informational documents are also moved to Historic freely (see eg. RFC 
6247), even though they have no relationship to Standards Track and it's 
fully up to the implementor to evaluate the protocol and decide whether 
to implement or not implement it (unlike Standards Track, which was 
intended as "IETF recommends to use this").

RFC 4844 does not mention clearly, but Historic documents may 
occasionally be published by IETF (I also saw 2 Historic RFCs published 
by IRTF and a number - by Independent Submissions Editor) directly.  
Procedures for moving non-IETF-stream RFCs to Historic are still unclear.

There were some proposals regarding Historic; eg. the NEWTRK WG document 
(http://tools.ietf.org/id/draft-ietf-newtrk-cruft-00.txt), which is 
expired but was partly incorporated in IESG Statement on Historic 
(http://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html), 
and my proposal 
(http://tools.ietf.org/html/draft-yevstifeyev-genarea-historic-03).  
None of them progressed further.

Some drafts registered by datatracker as "Internet Standards Process 
Rev. 4" (http://tools.ietf.org/id/draft-lear-ietf-rfc2026bis-00.txt and 
http://tools.ietf.org/id/draft-moonesamy-stds-process-00.txt) also say 
extremely little about Historic status compared with 2026. 
http://tools.ietf.org/id/draft-carpenter-rfc2026-changes-02.txt, Section 
3.12 proposed to change current Historic description to:
>     A specification that has been superseded by a more recent
>     may be assigned to the "Historic" level by the IESG.  (Purists have
>     suggested that the word should be "Historical"; however, at this
>     point the use of "Historic" is historical.)
assuming that any RFC may be moved to Historic by IESG, overlooking 
other streams' authorities (this draft was issued in 2008, long after 
RFC 4844).  This draft wasn't ultimately processed, even though it 
entered IESG review.

So what's the meaning of Historic?  As Ronald mentioned, the formulation 
"to be obsolete" in RFC 2026 may be understood differently; one may 
think that it means "nobody uses the protocol", which is impossible to 
determine and then say for sure.  The second person may think that "the 
protocol's possibilities may safely be provided by other protocol", 
which is easier to determine, but applying such definition might create 
problems with interoperability.  The third opinion may be "the protocol 
is known to have technical/security/other omissions and its use should 
be discouraged".   The others may also have other views on Historic, 
which does not facilitate the Internet Standards process.

And what could/should be done?  I think, IESG and the whole community, 
cooperating with IAB, IRSG and ISE, should determine the definition of 
Historic which will be fine enough to cover all existing issues with it, 
and then either publish such approach as BCP or incorporate when 
updating RFC 2026.  This will eliminate the problems with different 
issues with procedures for and understanding of Historic RFCs as well as 
clear up one of "dark places" in IETF process.

Of course, just my opinion.
Mykyta Yevstifeyev

18.07.2011 18:33, Noel Chiappa wrote:
>      >  From: Ronald Bonica<[email-masked]>
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 22 Jul 2011 08:53:21 -0700

Hi -

> From: "Mykyta Yevstifeyev" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, July 22, 2011 3:16 AM
> Subject: Historic status (was Another look at 6to4 (and other IPv6 transitionissues))
...
...

After universal IPv6 deployment has been achieved, after we have
workable standardized configuration management, after all significant
protocols have been properly secured, and after NAT has been
banished from this planet, I *might* be persuaded to support
spending time on this.

Randy

---

From: "t.petch" <[email-masked]>
Date: Sat, 23 Jul 2011 12:06:38 +0200

----- Original Message -----
From: "Randy Presuhn" <[email-masked]>
To: <[email-masked]>
Sent: Friday, July 22, 2011 5:53 PM

> banished from this planet, I *might* be persuaded to support

But Randy, you already have; you have spent time sending an e-mail; I was hoping
that this time there would be no response at all.

Tom Petch