Re: draft-ietf-dnsext-dnssec-gost

[Basil Dolmatov <[e-mail]>]

Martin Rex пишет:

Basil Dolmatov wrote:
  

Martin Rex пишет:
    

Whether and how much the -1994 version is
deprecated is also a complete mystery.  
      

It is written in the text of GOST -2001
    

Which document are you refering to when you say "text of GOST -2001" ?


This document:

  http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-08" rel="nofollow">http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-08

says

section 1.1:
   
   4. GOST R 34.10-2001 replaces GOST R 34.10-94.

section 1,2:

   GOST R 34.10-2001 is developed to replace GOST R 34.10-94.
  

Both statement are right.

 2. GOST R 34.10-2001 was accepted and activated by the Act 380-st of
      

    12.09.2001 issued by the Russian federal committee for standards.

    ...

    4. GOST R 34.10-2001 replaces GOST R 34.10-94.

So, GOST -1994 for digital signature _is_ deprecated and replaced from 
12.09.2001.

The transition period is not stated explicitly because it is obvious 
from standard procedure of certification in Russia.

No certificate can be issued for any hardware/software using -1994 
algorithm after 12.09.2001 and the certification period is 3 years.

So, after 12.09.2004 there can be no operating hardware/software using 
-1994 algorithm.
    

That information OUGHT to have been added to rfc-4357 and it ought to be
added to draft-dolmatov-cryptocom-gost34102001-08.


  

Why?
Now is 2010, and all implementations of -1994 standard have been completely phased out more than 5 years ago.

I just found the following paragraph in the Copyright Notice of

   http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-08" rel="nofollow">http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-08

on the title page which irritates me:

   This document may not be modified, and derivative works of it may
   not be created, except to format it for publication as an RFC or to
   translate it into languages other than English.


Is there a new trend to have the IETF rubber stamp documents as is?

To me, this statement precludes editorial changes/corrections,
which doesn't sound right.

I boldly assumed the original name of the IETF documents "RFC"
mean "Request For Comment", in the form that the community was
asked for feedback (request for clarifications, correction or
changes) before document was published.

At least this is how I understand "The Tao of the IETFhttp://tools.ietf.org/html/rfc4677#section-8.1AlthoughtheIETFmaynothave" rel="nofollow">"

http://tools.ietf.org/html/rfc4677#section-8.1


Although the IETF may not have "change control" for the technical
contents described in informational document, a complete absence
of change control of document structure, clarity, detail of
explanation and editorial issues would come as a suprise to me...

  

This statement was inserted following the advice of Russ Housley.

The main reason for that was that this text is a _translation_ of the text of official Russian state standard.
At the moment of its creation this text was thoroughly checked with authors of original standard for consistency.
Any editorial changes/corrections could diverge the translation from the original, which is undesirable.

I agreed with this Russ's reasoning.

I do understand that the structure and the style of these documents are unfamiliar to the significant part of community, but this is because of the fact it is _a_translation_ of official standard text.
It is not a retelliing or compilation, it is a _translation_.

And it is intended to exist as a reference to the  origin, when creating further IETF documents, which will be pure IETF documents and will be commented and edited when necessary.

-Martin

  

dol@