Review of draft-yevstifeyev-ion-report-06

Harald Alvestrand <harald@alvestrand.no> Fri, 15 July 2011 15:18 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444CF21F8752 for <ietf@ietfa.amsl.com>; Fri, 15 Jul 2011 08:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.571
X-Spam-Level:
X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFmcDj3vOJFg for <ietf@ietfa.amsl.com>; Fri, 15 Jul 2011 08:18:55 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A113921F874A for <ietf@ietf.org>; Fri, 15 Jul 2011 08:18:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2295039E12B; Fri, 15 Jul 2011 17:17:50 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2V9upbnf31BF; Fri, 15 Jul 2011 17:17:49 +0200 (CEST)
Received: from [192.168.1.53] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 47FA239E03C; Fri, 15 Jul 2011 17:17:49 +0200 (CEST)
Message-ID: <4E205A5D.1020304@alvestrand.no>
Date: Fri, 15 Jul 2011 17:18:53 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
Subject: Review of draft-yevstifeyev-ion-report-06
References: <4D91EBDE.5070703@gmail.com>
In-Reply-To: <4D91EBDE.5070703@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jul 2011 15:18:56 -0000

My apologies for the lateness of this review.

I am not happy with this document.

I was unhappy with the IESG's decision to close the ION experiment, 
since I believe the mechanisms that were chosen to replace it failed to 
fulfil several of the requirements that were driving forces in the 
design of the ION mechanism (as an example, try to find out who, if 
anyone, approved http://iaoc.ietf.org/network_requirements.html, what 
the previous version was, and when this version was approved).

The document does not refer back to the aims of the experiment, which I 
tried to make explicit in section 5 of RFC 4693, which include:

- Easy updating
- Explicit approval
- Accessible history

The sum total of analysis in this document is two sentences:
The cited IESG statement

      It is clear that the IESG, IAB, and IAOC need the ability to
      publish documents that do not expire and are easily updated.
      Information published as web pages, including IESG Statements, are
      sufficient for this purpose.

The draft's statement

    Taking everything into account, it was considered that IONs added
    complications to the maintenance of documents but did not give a
    corresponding benefit to the IETF.

I would at least expect those three points to be explicitly addressed by 
analysis, such as:

- The IESG concluded that publication of IONs was more complex than 
publishing Web pages and IESG statements
- The IESG concluded that the IESG statement mechanism, which has no 
formal definition, was enough documentation of the IESG's decisions 
where decision documentation was reasonable, and that Web pages needed 
no explicit approval
- The IESG concluded that there was no need to provide an accessible 
history of versions of the documents for which the ION mechanism was 
intended

The document also needs a language check, but I feel that the lack of 
*any* explicit analysis with respect to the aims of the experiment, even 
an explicit statement that the issues involved were considered not 
important, is the most important shortcoming of the document.

                         Harald