Re: Last Call: <draft-housley-implementer-obligations-01.txt> (Expectations of Implementers of IETF Protocols) to Informational RFC
Nikos Mavrogiannopoulos <nmav@gnutls.org> Mon, 12 May 2014 07:40 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 549791A041D for <ietf@ietfa.amsl.com>; Mon, 12 May 2014 00:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.621
X-Spam-Level:
X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 Vd-RvaN-moc1 for <ietf@ietfa.amsl.com>; Mon, 12 May 2014 00:40:46 -0700 (PDT)
Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 321391A041C for <ietf@ietf.org>; Mon, 12 May 2014 00:40:46 -0700 (PDT)
Received: by mail-qa0-f52.google.com with SMTP id cm18so6559527qab.25 for <ietf@ietf.org>; Mon, 12 May 2014 00:40:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6QDYFZ4ulfBW2Tt7POXD/rglHtZMuclVnmK6slqyiJE=; b=Q6JHZcFG70JzhWACtH3H5h45eghj31JaQUKXGUkMIrHy+f/6vQtbxcdtR0LB8UEs1T B9cqC+N2hoUXp9U2e8j7/3oUFDkrks/RvcsnRfm4SYUc8YlT5FqQicVHbVsSUs4TvG8y 3kg+wOaLdRSjd7CM5wiq9bZnOiCsEO/ZRcln3AyrJTq5ze2Jqz3S9dVwl3KhjZ60dwAk dJhHlE0ctZS9EGD6nLNe3+DCcuI43uAl5163/uZbwNyXCWcyll58mbxNoGBYegRUyVvm L7ffEG85iC3SoGtMb1dGQfP2jYMDwI9Y+byMYvsEV7qe41k/M8VrfHRedEoI2gALGWfZ UYYg==
MIME-Version: 1.0
X-Received: by 10.140.49.208 with SMTP id q74mr25145220qga.103.1399880440100; Mon, 12 May 2014 00:40:40 -0700 (PDT)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.229.193.136 with HTTP; Mon, 12 May 2014 00:40:40 -0700 (PDT)
In-Reply-To: <536FDC3F.6000703@gmail.com>
References: <20140509191841.18372.97889.idtracker@ietfa.amsl.com> <06a301cf6c7e$770e51e0$652af5a0$@olddog.co.uk> <536E8CB1.7060802@gmail.com> <1399838117.17297.12.camel@nomad.lan> <536FDC3F.6000703@gmail.com>
Date: Mon, 12 May 2014 09:40:40 +0200
X-Google-Sender-Auth: 7mAcbGkVKdVXlaCl0t7h7MFjqkw
Message-ID: <CAJU7za+0C-Fwbau8r01uNBvpEAQZvWzXjT7TVi5Wfna7ZwqE=g@mail.gmail.com>
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>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/arPPb3Zw5OcbkO4CayVqrgra9Xo
Cc: IETF Discussion <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: Mon, 12 May 2014 07:40:47 -0000
On Sun, May 11, 2014 at 10:23 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > Nikos, >>> 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. > That's a straw man. You know very well that (precisely because IETF > standards are voluntary) there will never be such a contract between > the IETF and the implementer. I believe that's to the point of the document. Unless there is a contract between IETF and the implementer, such documents should be published as advisory to the implementer rather than listing expectations from the implementer. That's at minimum a matter of courtesy to implementers. >> 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. > > The document is aspirational, not contractual. It seems perfectly reasonable > to ask implementers (whether a profit-making company, an open-source > community, or an individual) to accept ongoing responsibility for their > code. Isn't that exactly what GnuTLS does, for example? The only expectations from an implementation are the ones you see in written in the contract you have with the implementer. If you don't have one, then you check the license of the implementation. On gnutls that you refer to, if you got without any contract, you see: 'BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. ' So do you really think that publishing a document in IETF that adds expectations to an implementation is going to change that? However, I agree that there may be expectations that one may infer from the activity of a community project, but that's orthogonal to the document at hand. regards, Nikos
- RE: Last Call: <draft-housley-implementer-obligat… Adrian Farrel
- Re: Last Call: <draft-housley-implementer-obligat… Brian E Carpenter
- Re: Last Call: <draft-housley-implementer-obligat… Abdussalam Baryun
- Re: Last Call: <draft-housley-implementer-obligat… S Moonesamy
- Re: Last Call: <draft-housley-implementer-obligat… Nikos Mavrogiannopoulos
- Re: Last Call: <draft-housley-implementer-obligat… Brian E Carpenter
- Re: Last Call: <draft-housley-implementer-obligat… Elwyn Davies
- RE: Last Call: <draft-housley-implementer-obligat… l.wood
- Re: Last Call: <draft-housley-implementer-obligat… Nikos Mavrogiannopoulos
- Re: Last Call: <draft-housley-implementer-obligat… Eliot Lear
- Re: Last Call: <draft-housley-implementer-obligat… John C Klensin
- Constructive suggestions/ alternatives (was: )e: … John C Klensin
- Re: Last Call: <draft-housley-implementer-obligat… Avri Doria
- Re: Last Call: <draft-housley-implementer-obligat… Brian E Carpenter
- Re: Last Call: <draft-housley-implementer-obligat… Eric Rosen