Re: Last Call: <draft-housley-implementer-obligations-01.txt> (Expectations of Implementers of IETF Protocols) to Informational RFC

Nikos Mavrogiannopoulos <nmav@gnutls.org> Sun, 11 May 2014 19:55 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E1D1A033D for <ietf@ietfa.amsl.com>; Sun, 11 May 2014 12:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48L0YLxRyj1k for <ietf@ietfa.amsl.com>; Sun, 11 May 2014 12:55:25 -0700 (PDT)
Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B0B0D1A033C for <ietf@ietf.org>; Sun, 11 May 2014 12:55:25 -0700 (PDT)
Received: by mail-ve0-f174.google.com with SMTP id jw12so7658061veb.5 for <ietf@ietf.org>; Sun, 11 May 2014 12:55:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=iaoBc1XKlk2J33Vj1v5aiI7RNecSID19uhd/vDkJUjY=; b=ByzYV3iPrpjar/qZVb4/CLUHYqKeQq041Otzp8PrJ5xPASQdnNx/BnWcaHTNf/asUg bOxx1xyzwjL+N02csDs4sBfz/8tbFABs5g5WE4UtE/6WyeTDPaSdolRezMWY6yZvMdwl rxMQZZvDjz44Ke38Ims1ALUEwMx2tEKUqChN5iUoe6i2BkUbzWfC5n6FkjSP12a1Si0n dAs4XR/BxyEd+gNAceZnjDjAW5sfDar8jH8x8gFKC2rV5y00aL9NmC/j8zOTWfUIOFCG UJ9j+S8/XpW3OZSu2vQUe7ROfsuv+nAazPRVm8DnYKQoFX46ITVyRCzaON2X2huieeEZ fZeg==
X-Received: by 10.58.23.6 with SMTP id i6mr18973261vef.12.1399838119861; Sun, 11 May 2014 12:55:19 -0700 (PDT)
Received: from [10.100.2.3] (ip-94-112-138-148.net.upcbroadband.cz. [94.112.138.148]) by mx.google.com with ESMTPSA id lt9sm11766270veb.17.2014.05.11.12.55.18 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 11 May 2014 12:55:19 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <1399838117.17297.12.camel@nomad.lan>
Subject: Re: Last Call: <draft-housley-implementer-obligations-01.txt> (Expectations of Implementers of IETF Protocols) to Informational RFC
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Date: Sun, 11 May 2014 21:55:17 +0200
In-Reply-To: <536E8CB1.7060802@gmail.com>
References: <20140509191841.18372.97889.idtracker@ietfa.amsl.com> <06a301cf6c7e$770e51e0$652af5a0$@olddog.co.uk> <536E8CB1.7060802@gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.8.5-2+b3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/Soh2BbFZHJIEqq7aK_Ri9k9ahlg
Cc: adrian@olddog.co.uk, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 11 May 2014 19:55:27 -0000

On Sun, 2014-05-11 at 08:31 +1200, Brian E Carpenter wrote:
> Hi Adrian,
> 
> On 11/05/2014 06:34, Adrian Farrel wrote:
> > While I appreciate the effort the author put in to resolve previous
> > discussions, I do not support the publication of this document.

I cannot see the purpose of this document. If it is published and an
implementor does not follow it, what does it happen? Does IETF revoke
his/her license to implement?

There are also phrases in the document that while they are
good-intentioned they make no sense, and an implementor will dismiss the
whole document because of it.

For example: "An implementer should plan to maintain their
implementation."

So if an implementor is under contract to implement RFCxxxx must he
continue updating his implementation even after the contract is
terminated? What does this phrase conveys? Will IETF take care of his
expenses?

At best I believe the document needs to re-purpose itself. 

> I like to think of somebody else: a young programmer working far,
> far away, who will probably never attend an IETF meeting or join
> an IETF mailing list. For this person, we need to state things that
> are obvious to us. For example:
> "It is not sufficient to do an initial implementation of the protocol.
>  Maintenance is needed to apply changes as the come out in the future,
>  especially to fix security issues that are found after the initial
>  publication of a protocol specification."

This document doesn't fill this purpose as it is written as a what-to-do
document rather than a document with advice to implementers. If somebody
has specific expectations from implementers then that should be
reflected in a contract with them.

If on the other hand this is written in purpose to introduce
IETF-certified or IETF-approved implementations it must be even more
precise than this document. As it is, it doesn't fill any obvious
purpose.

regards,
Nikos