ietf
[Top] [All Lists]

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

2014-05-12 02:41:00
On Sun, May 11, 2014 at 10:23 PM, Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)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

<Prev in Thread] Current Thread [Next in Thread>