[rfc-i] Request for Review - draft-yevstifeyev-genarea-historic-01

Mykyta Yevstifeyev evnikita2 at gmail.com
Sat Jan 29 22:27:19 PST 2011


29.01.2011 21:34, Brian E Carpenter wrote:
> Hi Mykyta,
>
> In a few words, I don't consider that we have a problem
> here that is significant enough to need fixing. There are
> many, many problems in RFC 2026 which are much more important
> and that the community has decided to ignore.
>
> If you want more details on my opinions on this, see
> http://tools.ietf.org/id/draft-carpenter-rfc2026-practice-00.txt
> and
> http://tools.ietf.org/id/draft-carpenter-rfc2026-changes-02.txt
Hello Brian,

Let me cite your -changes draft regarding Historic status.

> 3.12.  Changes to Section 4.2.4  Historic
>
>     "---------Begin Extract---------
>
>     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.)
>
>     -----------End Extract---------"
>
>     CHANGE: Replace this paragraph by:
>
>     A specification that has been superseded by a more recent
>     specification or is for any other reason considered to be obsolete
>     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.)
>
>     RATIONALE: Aligning with reality.
Comments to this extract:  1) Rationale saying 'Aligning with reality' 
does not seem to be appropriate here (see below).

2) The procedure you define does not match *current* practice.  This 
change does not define what is really used.  Unlike your document, my 
draft gives very detailed definition of what procedures are used (but 
even now not all cases are addressed in it).

3) This extract, and all proposed changes do not explain what the terms 
'obsoleted' and 'obsolete' mean.  This issue causes misunderstanding of 
the members of the community.  My draft addresses these issues clearly.

I consider the changes I propose really needed, since they are important 
for the community.   What caused me to propose them is the discussion on 
IETF Discussion mailing list about historicizing old transport-layer 
protocols.  Many people said that RFC 2026 in its current edition does 
not allow to move to Historic those RFCs that are actually deprecated, 
but has a regulation that this status is assigned to that RFCs that are 
replaced.

Therefore, RFC 2026, either in its current edition, or with changes 
proposed by your draft will not resolve this problem.  We need a complex 
document.  And I propose such.

All the best,
Mykyta Yevstifeyev
> (This includes a very minor change to the text about Historic RFCs,
> which I believe is sufficient to align it with reality.)
>
> For a more robust version of my opinions, see
> http://tools.ietf.org/id/draft-carpenter-rfc2026-critique-00.txt
>
> Regards
>     Brian Carpenter
>



More information about the rfc-interest mailing list