Appeal of IESG inaction, decisions of 13 Oct 1999 and 16 Feb 1999

William Allen Simpson <wsimpson@greendragon.com> Sat, 23 October 1999 09:04 UTC

Received: by ietf.org (8.9.1a/8.9.1a) id FAA29904 for ietf-outbound.10@ietf.org; Sat, 23 Oct 1999 05:04:46 -0400 (EDT)
Received: from watervalley.net (mail.WaterValley.Net [206.31.151.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29795; Sat, 23 Oct 1999 04:55:32 -0400 (EDT)
Received: from [198.110.21.18] (HELO greendragon.com) by watervalley.net (Stalker SMTP Server 1.7) with ESMTP id S.0002080236; Sat, 23 Oct 1999 03:56:23 -0500
Message-ID: <38117768.BCA29513@greendragon.com>
Date: Sat, 23 Oct 1999 04:53:15 -0400
From: William Allen Simpson <wsimpson@greendragon.com>
X-Mailer: Mozilla 4.7 (Macintosh; U; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: iab@ietf.org
CC: ietf@ietf.org
Subject: Appeal of IESG inaction, decisions of 13 Oct 1999 and 16 Feb 1999
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

This is a formal appeal of IESG inaction, and its decisions of 
13 Oct 1999 and 16 Feb 1999.  These matters had been raised in a 
previous appeal to the IAB, but remanded to the IESG for action on 
01 Oct 1999.

These documents were the subject of specific argument in the previous 
IAB appeal (see appended).

 1) The IESG response fails to specify any differences in IPsec 
    interoperation from RFC-2451.  In any case, the previous 
    formal position of the IESG was that RFC-2451 was not a "cipher" 
    document, and therefore not subject to the formal RFC-2411 
    "roadmap" requirements.

 2) The Triple DES document was the prototype for the "roadmap", shares 
    a co-author with the "roadmap", and is referenced in the "roadmap" 
    acknowledgements (unfortunately without attribution).

 3) Interoperation with RFC-2451 is not an issue.  While Triple DES is 
    described, the text was lifted directly from this Triple DES draft, 
    and this CBC draft, which was a subject of the previous IAB appeal.

 4) Interoperation with RFC-2451 is not an issue.  DES-XEX3-CBC is not 
    described therein.

 5) Interoperation with RFC-2451 is not an issue.  The IPsec marker for 
    different algorithms is called the Security Parameters Index (SPI). 
    There are other distinguishing markers used in generating SPIs, 
    such as specified in the IKE/ISAKMP DOI and Photuris Attributes.

 6) The division of the documents matches the IAB appeal determination 
    that "the general quality of the text of RFC 2451 is unsatisfactory",
    "it confuses two topics", and "may even be desirable to split the 
    document in two."

 7) The request for publication specifically states that should these 
    documents not be last called for Proposed Standard, then they be 
    published as Experimental, as required by RFC-2026: "... the IESG 
    considers that the document proposes something that conflicts with, 
    or is actually inimical to, an established IETF effort, the document 
    may still be published as an Experimental or Informational RFC."

 8) The earlier interim IESG response regarding "Enhancements" also 
    conflicts with the above specified requirements of RFC-2026.  As noted 
    in the earlier appeal, the IESG response is technically inaccurate.  
    Also, note that I have offered that "Enhancements" be published as 
    "Historic", should the usual "Experimental" be somehow confusing.

 9) The IESG has not acted upon "IP Authentication using Keyed SHA1 
    with Data Padding".

10) The IESG has not issued a Last Call for the "Applicability Statement", 
    which has been awaiting action since July 1998, was updated June 1999, 
    and thus is incorporated in this appeal against their failure to act 
    before the next IETF plenary.

====

Subject: Re: RFCs-to-be - B. Simpson Security Documents
Date: Wed, 13 Oct 1999 07:32:28 -0400 (Eastern Daylight Time)
From: Steve Coya <scoya@ietf.org>
Reply-To: Steve Coya <scoya@ietf.org>
To: rfc-ed@rfc-editor.org
CC: iesg@ietf.org, wsimpson@greendragon.com

The IESG has reviewed the documents draft-simpson-desx-02.txt,
draft-simpson-cbc-01.txt, and draft-simpson-esp-des3v2-03.txt, and
recommends that the RFC Editor not publish them as RFCs. Our reason for
this recommendation is that they describe and document procedures for
IPSEC interoperation which differs from that described in RFC 2451,
resulting in non-inoperability, and is indistinguishable by the usual
markers such as version number, IP Protocol number, and the like.

====

Subject: Re: draft-simpson-ipsec-enhancement-01.txt to Experimental
Date: Tue, 16 Feb 1999 17:07:50 -0500 (Eastern Standard Time)
From: Steve Coya <scoya@ietf.org>
Reply-To: Steve Coya <scoya@ietf.org>
To: RFC Editor <rfc-ed@ISI.EDU>
CC: iesg@ietf.org, wsimpson@greendragon.com

Greetings,

The IESG consensus requests that Internet Security Transform Enhancements
<draft-simpson-ipsec-enhancement-01.txt> NOT be published as an
Experimental RFC as this document adds sequence numbers to the old
and obsolete AH and ESP transforms.  In the case of ESP, it does so in an
incompatible way. Publication of these documents could easily confuse
implementors of IPSEC. 


The IESG will reconsider publication if this document is updated as needed
and resubmitted.

====

A8  "Internet Security Transform Enhancements" was submitted to the IESG
    for publication as Experimental in April 1996, and the RFC Editor in
    August 1996, and most recently updated in May 1997.

A8.a    This was an individual contribution, much of which had been
        written in 1994-1995, that "will not be considered by the Chairs".
        [Exhibit #4]

A8.b    The IESG did not review within a reasonable period of time, nor
        publish as originally submitted.

A8.c    After a June 5, 1997, appeal to the IETF Chair, the IESG
        refused to publish until after working group output.  This was
        especially detrimental, as the working group was already far
        behind its charter.  [Exhibits  #5, #6, #7, #8]

A8.d    On February 16, 1999, the IESG refused to publish after the
        working group had finished.  [Exhibit #9]  Note that the IESG
        decision is flawed and inaccurate, as the draft actually adds
        sequence numbers to AH in a manner incompatible with newer RFCs,
        but is entirely compatible with ESP.

A8.e    Many of the proposals in the paper were incorporated by the IP
        Security WG in later documents, but without attribution.  The
        document is an important archival record of the work.

A8.f    As an alternative, Appellant has proposed publication as Historic.
        [Exhibit #3]

A9  "IP Authentication using Keyed SHA1 with Data Padding" was
    submitted to the IESG for publication as Experimental in May 1996,
    and the RFC Editor in August 1996.

A9.a    This was an individual contribution, a minor modification of
        RFC-1952, that "will not be considered by the Chairs".
        [Exhibit #4]

A9.b    The IESG did not review within a reasonable period of time, nor
        publish as originally submitted.

A9.c    Many of the proposals in the paper were incorporated by the IP
        Security WG in later documents, but without attribution.  The
        document is an important archival record of the work.

A9.d    As an alternative, Appellant has proposed publication as Historic.
        [Exhibit #3]

A10 "The ESP Triple-DES Transform" was submitted to the IESG for
    publication as Experimental in May 1996, revised in form during
    meetings sponsored by ANX, and most recently updated in July 1998.

A10.a   This was an individual contribution, a major modification of
        RFC-1951, that "will not be considered by the Chairs".
        [Exhibit #4]

A10.b   The internet-draft was renamed circa 02 July 1997, submitted to
        the IP Security WG at the request of the new chairs.  [WG list]

A10.c   It was "released" to the authors on 19 Sep 1997.  [WG list]

A10.d   In July 1998, it was submitted to the IESG for publication as a
        Proposed Standard, or in the case it was not accepted, as
        Experimental.

A10.e   The IESG did not review within a reasonable period of time, nor
        publish as originally submitted.

A10.f   The document conforms with the roadmap developed in ANX.  In fact,
        it was one of the principal templates used to create the roadmap
        requirements.  [Exhibit #10]

A11 "The ESP DES-XEX3-CBC Transform" was developed during meetings
    sponsored by ANX, posted as an internet-draft in July 1997, and most
    recently updated in July 1998.

A11.a   This was an individual contribution, submitted to the IP
        Security WG at the request of the new chairs, based on one of the
        "Internet Security Transform Enhancements" (see section A8).

A11.b   It was "released" to the authors on 19 Sep 1997.  [WG list]

A11.c   In July 1998, it was submitted to the IESG for publication as a
        Proposed Standard, or in the case it was not accepted, as
        Experimental.

A11.d   The IESG did not review within a reasonable period of time, nor
        publish as originally submitted.

A11.e   The document conforms with the roadmap developed in ANX.

A12 "ESP with Cipher Block Chaining (CBC)" was developed during meetings
    sponsored by ANX, posted as an internet-draft in July 1997, and most
    recently updated in July 1998.

A12.a   This was an individual contribution, submitted to the IP
        Security WG at the request of the new chairs.

A12.b   It was "released" to the authors on 19 Sep 1997.  [WG list]

A12.c   In July 1998, it was submitted to the IESG for publication as
        Informational.

A12.d   The IESG did not review within a reasonable period of time, nor
        publish as originally submitted.

A12.e   The document is referenced by Triple-DES and DES-XEX3.

====

Date: Wed, 23 Dec 98 22:32:53 GMT
From: "William Allen Simpson" <wsimpson@greendragon.com>
To: rfc-editor@ietf.org
Subject: Security docs -- publication

The following documents have been awaiting IESG action, some of them for
years.  My reminders in July and September have not yielded any action.

Where two statuses are listed, the first is preferred, and the second is
the alternative.  The BCP needs a 4 week last call.

Here are the documents in order of publication.  When you tell me the
assigned RFC numbers, I will format them, update the references, and
send you the nroff and final text.

   o ICMP Security Failures Messages
        [PROPOSED/EXPERIMENTAL]
        <draft-simpson-icmp-ipsec-fail-02.txt>

   o Internet Security Transform Enhancements
        [HISTORIC/EXPERIMENTAL]
        <draft-simpson-ipsec-enhancement-01.txt>

   o IP Authentication using Keyed SHA1 with Data Padding
        [HISTORIC/EXPERIMENTAL]
        <draft-simpson-ah-sha-kdp-00.txt>

   * ESP with Cipher Block Chaining (CBC)
        [INFORMATIONAL]
        draft-simpson-cbc-01.txt

   * The ESP DES-XEX3-CBC Transform
        [PROPOSED/EXPERIMENTAL]
        draft-simpson-desx-02.txt

   o The ESP Triple DES Transform
        [PROPOSED/EXPERIMENTAL]
        <draft-simpson-des3v2-03.txt>

   * Photuris: Session-Key Management Protocol
        [PROPOSED/EXPERIMENTAL]
        <draft-simpson-photuris-18.txt>

   * Photuris: Extended Schemes and Attributes
        [PROPOSED/EXPERIMENTAL]
        <draft-simpson-photuris-schemes-05.txt>

   * DES Applicability Statement for Historic Status
        [BCP]
        draft-simpson-des-as-00.txt

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32