Subject: Request for review of draft-yevstifeyev-genarea-historic-03

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 02 Mar 2011 18:02:42 +0200

Hello all,

Please review and provide the feedback on 
/draft-yevstifeyev-genarea-historic-03/, that may be found at:

http://tools.ietf.org/html/draft-yevstifeyev-genarea-historic-03

The brief description of the document:

(Draft's abstract)  This document defined what the Historic RFC maturity 
level means, what are the criteria for Historic RFCs, describes 
procedures for republication and reclassification of RFCs in Historic 
maturity level and discusses other issues related to Historic RFCs.  It 
updates RFC 2026.

(Background)  RFC 1310 and its successors, including RFC 2026, have only 
few words about the Historic maturity level.  Absence of procedures for 
either reclassification or republication of RFCs in this maturity level 
caused misunderstandings regarding these issues.  This document is to 
clarify any issues regarding Historic docs.  It also updates RFC 2026.

(Why IETF Discussion mailing list - there is no any appropriate list for 
discussion of this document, except this one).

I'm also copying this to Scott Bradner as the author of RFC 2026.

Thank you for your time,
Mykyta Yevstifeyev

---

From: Eliot Lear <[email-masked]>
Date: Wed, 02 Mar 2011 17:40:46 +0100

Thank you for the opportunity to review this draft.  I do so merely as
an individual.  It might be a good idea to provide some additional
clarity on when to market something Historic, but your document requires
a bit of clarity on its own as to what your motivating logic is.  Why,
for instance, do you believe it is important to split "deprecated" and
"obsoleted"?  Also, Scott had to choose some language to describe
Historic.  He probably did not mean for us to get hung up on the word
"superceded", a problem from which this draft seems to suffer.

I bring to your attention RFC-4450, in which we made a bulk status
change of a bunch of PS to Historic precisely because we couldn't find
anyone using those protocols.  However, such observations are
imprecise.  For one, it is hard to observe what is going on on the
Internet, and those who do don't usually share their data (there is
some, but it is often regionally based, like the GINORMOUS store at
ETHZ).  Another issue is that a protocol that is not detectable on the
Internet might be in use on private networks.

Eliot

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 3 Mar 2011 11:27:21 +0200

Hello Eliot,

Thank you for reading the document.  Pleas efind some comments in-line.

2011/3/2, Eliot Lear <[email-masked]>:
> "obsoleted"?
In my opinion, the term 'obsoleted' means that it is out-of-use while
'deprected' means that it not recommended to be used and implemented
because of some reason.
>
> Also, Scott had to choose some language to describe
RFC 2026 says that Historic is for RFCs that has been superseded by a
more recent specification or is for any other reason considered to be
obsolete.  However some recent observations have shown that everyone
has their own thoughts on what the word 'obsolete' means.  Some think
that it is the synonym yo the word 'superseded' while other consider
it to be 'deprectaed' as well.  I propose to provide the clarity on
this terms.
> Internet might be in use on private networks.
When we say 'out-of-use' we consider the usage of something in the
overall Internet.  It is mostly not very difficault to find this out
via those people who take part in the IETF.

You've also given me the idea to mention the criterion for 'obsoleted'
documents such as it is the retired or revised Internet standard, per
RFC 2026.  I'll make this change in my working copy of the draft.

All the best,
Mykyta Yevstifeyev

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Mar 2011 06:56:25 -0500

> via those people who take part in the IETF.

If I read the above exchange correctly, Eliot Lear points out that it
is difficult to observe what's going on all over the Internet, on the
premise that the Internet is a bunch of interconnected networks and
you can't be sure that you've actually observed all of those networks
(some of which might be closed to you).

In response, Mykyta Yevstifeyev says, "Oh, that's not hard.  People at
the IETF know."  This has no supporting argument for it at all.

I would like to suggest that the former position is the better one to
take.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 03 Mar 2011 16:57:39 +0200

03.03.2011 13:56, Andrew Sullivan wrote:
>> 2011/3/2, Eliot Lear<[email-masked]>:
Andrew, in this case how do you propose to formulate this?  Mykyta

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 Mar 2011 10:11:26 -0500

There are, in my opinion, two problems with Mr. Yevstifeyev's assertion 
below that it is easy to determine when things are out of use.
The first point, to echo Andrew Sullivan, is that even if a protocol is 
in use on the public Internet, it is not always easy to detect.  It may 
be used in only some portions of the net.  It may be used inside some 
other protocol that makies detection ahrder.
The second point is that enterprise uses and other private network uses 
are still valid uses.  The fact that a protocol may be used only inside 
a virtual private network, or only inside a corporate data center, or in 
only within a military facility, does NOT mean that it is not used. 
Such limited use is still valid use and should not result in our 
declaring something obsolete.

Yours,
Joel

> 2011/3/2, Eliot Lear<[email-masked]>:
...
> via those people who take part in the IETF.
...

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 03 Mar 2011 07:18:13 -0800

On 3/3/2011 7:11 AM, Joel M. Halpern wrote:
> The first point, to echo Andrew Sullivan, is that even if a protocol is in use
> on the public Internet, it is not always easy to detect.
...
> The second point is that enterprise uses and other private network uses are
> still valid uses. The fact that a protocol may be used only inside a virtual
> private network, or only inside a corporate data center, or in only within a
> military facility, does NOT mean that it is not used. Such limited use is still
> valid use and should not result in our declaring something obsolete.

+1

Declaration of historic needs to be based on affirmative data.  The declaration 
is actually only important to make for protocols that are known to be problematic.

Issuing a declaration for mere non-use is a matter of convenience, not need, IMO.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Mar 2011 08:21:07 -0700

On 3/3/11 8:18 AM, Dave CROCKER wrote:
> Declaration of historic needs to be based on affirmative data.  The
> declaration is actually only important to make for protocols that are
> known to be problematic.
> 

And, further, probably it would not be worth the trouble to investigate
whether a protocol is not actually used (proving a negative is hard).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 03 Mar 2011 17:28:49 +0200

Joel,

I agree with you that it is really hard and even impossible to determine 
what is going on in the Internet regarding some technology, protocol, 
etc.   If we set the impossible criterion for the Historic documents, 
this will really make very few sense.  So, as I have been pointed out, I 
find removing the regulation about 'out-of-use' technology at all quite 
acceptable.  Do you agree?

And as for the comment from Dave.

> declaration is actually only important to make for protocols that are 
This is already covered by the 'deprecated' criteria in my draft.

All the best,
Mykyta Yevstifeyev

03.03.2011 17:11, Joel M. Halpern wrote:
> There are, in my opinion, two problems with Mr. Yevstifeyev's 
> assertion below that it is easy to determine when things are out of use.
> The first point, to echo Andrew Sullivan, is that even if a protocol 
> is in use on the public Internet, it is not always easy to detect.  It 
> may be used in only some portions of the net.  It may be used inside 
> some other protocol that makies detection ahrder.
> The second point is that enterprise uses and other private network 
> uses are still valid uses.  The fact that a protocol may be used only 
> inside a virtual private network, or only inside a corporate data 
> center, or in only within a military facility, does NOT mean that it 
> is not used. Such limited use is still valid use and should not result 
> in our declaring something obsolete.
>
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 Mar 2011 10:41:21 -0500

No, I do not agree with you.
Our current definition for historic, and our current choices for when to 
move things, have worked sufficiently well.
I have not seen any evidence that there is a problem that needs solving.
I have also not seen any evidence that the changes you propose to the 
definitions would help anything.

Yes, there are problems with our current definitions.
Those problems serve to keep us from declaring something historic when 
we shouldn't.
They do, as a side effect, make it harder to declare things historic 
even if they actually are?
I will even agree that there is a small cost to that.  Users of our 
standards may sometimes think some things are relevant that aren't.

But changing the definitions to make it easier to change the status does 
not actually change the problem.  The problem is that it is hard for 
anyone (the IETF, vendors, operators) to reliably know what is actually 
in use.

Yours,
Joel

PS: I have actually noticed with several specifications I worked with 
that it can easily take 5 or 10 years for the actual usage (often not 
the initially expected usage) for a standards track or experimental 
protocol to emerge.  So premature declaration taht something is historic 
can do actual damage.

On 3/3/2011 10:28 AM, Mykyta Yevstifeyev wrote:
> etc. If we set the impossible criterion for the Historic documents, this
> will really make very few sense. So, as I have been pointed out, I find
> removing the regulation about 'out-of-use' technology at all quite
>>> is in use
>>> uses are

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Mar 2011 11:32:56 -0500

--On Thursday, March 03, 2011 10:41 -0500 "Joel M. Halpern"
<[email-masked]> wrote:

> Our current definition for historic, and our current choices
> for when to move things, have worked sufficiently well.
> I have also not seen any evidence that the changes you propose
> to the definitions would help anything.
> 
> Those problems serve to keep us from declaring something
> historic when we shouldn't.
>...

I pretty much agree with Joel (and others), but suggest that
there is another, better, solution to this problem (or at least
the version of it I understand).

Ultimately, whether under 2026 or your proposal, there are
ultimately two reasons for making something historic (this is
different from your Section 2 list; more about that below):

	(i) No one is using the protocol and no one cares any
	more about it. 
	
	(ii) The protocol contains elements or defects that, in
	retrospect, make it dangerous.

With the exceptions that are already covered by the existing
"Obsoleted by" category, the first is, as Joel points out, hard
to identify and get agreement about.   As other have suggested,
"no one cares" means "no one cares", i.e., that putting
significant energy into trying to identify and classify those
documents is probably not a good use of community resources.
Reaching formal agreement about the second effectively requires
publication of an RFC that describes the problem, at which point
"Obsoletes" can be used and there is no reason to develop new
procedures.

For the few cases that are actually worth it, we do have the
ability to approve and publish documents that identify a
protocol as "not recommended".  We don't use stand-alone
Applicability Statements very often any more, especially for
that purpose, but, if a particular protocol deserved the effort,
it would be lots easier --and lots less wear and tear on the
community in review and the RFC Editor in publication-- to write
an I-D that said "the protocol described in RFC NNNN has turned
out to be a bad idea because... Its use is Not Recommended."
than to republish or "historicize" as you suggest.

Trying to turn Historic even more into an ambiguous synonym for
"old", "unused", "uninteresting", or "bad" just does not strike
me as a good idea, especially with the possibility of
applicability statements that are orthogonal to maturity level
classification on the books.

FWIW, your "republication as historic" approach is not feasible
for documents more than a few years old.  The rules about
information to be included in RFCs, how that information is
structured, IPR statements, etc., have evolved over the years.
Permitting republication of an old RFC in facsimile would often
break those rules.  Figuring out the mechanisms for getting
around that would cost far more in resources than the community
is, I believe, willing to invest.  If I thought that another
iteration would improve this proposal enough to make it
acceptable, I'd recommend that your Section 3.1 should be
required to address republication of new documents with
identical technical content with old ones in the light of those
rules.   But I don't think that is the case.

On a note of sadness rather than as a sales pitch, the community
has discussed several ways of dealing with what I think it the
underlying problem you are trying to address -- getting readers
of RFCs the most up to date information possible about those
documents and the status of the protocols they describe.   At
least some of them would have worked better than this, with less
load on the community.  For whatever reasons, none of them have
achieved sufficient consensus to move forward.  Against that
background, I can't imagine what would cause us to adopt a
weaker proposal that required more work.

regards,
    john

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Mar 2011 11:44:32 -0500

> Andrew, in this case how do you propose to formulate this?  Mykyta

"Not"?  The goal you appear to have in this is to make the RFC series
tidy.  As the co-chair of a WG with an old and decidedly messy set of
protocol documents, I understand and value that desire.  But as the
same co-chair, I have to tell you that any assertion that some feature
(even if you think it is a dumb one that nobody ever should have used
anywhere for any reason) is unused is the sort of thing that leads you
into discussions of angels and pin-heads, trees falling in forests
with no-one to hear, and so no.

Heck, over in DNS land, we are barely willing to rely on features of
the protocol if we know that there is a 10 year old but once
widely-deployed piece of software that violated or didn't implement
that feature.

Setting up criteria that are formally nice but for which it is
impossible to construct a test is a bad idea.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 4 Mar 2011 10:39:55 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Thursday, March 03, 2011 7:41 AM
> To: Mykyta Yevstifeyev
> Cc: IETF Discussion; Scott O. Bradner
> Subject: Re: Request for review of draft-yevstifeyev-genarea-historic-03
> 

+1

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Fri, 4 Mar 2011 16:26:42 -0500

> what is going on in the Internet regarding some technology, protocol, etc.
> If we set the impossible criterion for the Historic documents, this will
> really make very few sense.  So, as I have been pointed out, I find removing
> the regulation about 'out-of-use' technology at all quite acceptable.  Do
> you agree?

It strikes me that we are spending time debating this to little
result, and we're missing one aspect of "rough consensus", of which
Dave is always wont to remind me: someone has to agree with something
in order to make a start at moving to consensus.

So far, we've had several people chiming in to disagree with the need
for this document.  I propose this:

If anyone (other than the author) thinks this document *is* necessary,
please say so.  Until someone does, the rest of us may go about our
other work.  Lacking affirmative support, this document should go
away.

If support arrives, we can resume the debate.

Barry

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 05 Mar 2011 08:29:28 +0200

03.03.2011 17:41, Joel M. Halpern wrote:
> Our current definition for historic, and our current choices for when 
> to move things, have worked sufficiently well.
But I see.  IMO this is the absence of procedures either for 
reclassification of RFCs to Historic or bare publication of Historic 
RFCs (I mean such cases as RFC 6123 or RFC 6037, that is even an 
Independent Submission).
> But changing the definitions to make it easier to change the status 
> does not actually change the problem.  The problem is that it is hard 
> for anyone (the IETF, vendors, operators) to reliably know what is 
> actually in use.
I agree with this.  But this is what we can already find in RFC 2026 - I 
mean the word 'obsolete' that is a synonym to the word 'out-of-use'.  If 
we think that is is really impossible to track this, we should update 
this definition.
> protocol to emerge.  So premature declaration taht something is 
> historic can do actual damage.
Mykyta Yevstifeyev