Response to appeal by Robert Sayre dated 2006-08-29

IESG Secretary <iesg-secretary@ietf.org> Mon, 16 October 2006 17:07 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVwM-0002Gg-63; Mon, 16 Oct 2006 13:07:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVwL-0002Gb-BA for ietf-announce@ietf.org; Mon, 16 Oct 2006 13:07:49 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVwL-0001A6-7L for ietf-announce@ietf.org; Mon, 16 Oct 2006 13:07:49 -0400
Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GZVwK-0001MS-SO for ietf-announce@ietf.org; Mon, 16 Oct 2006 13:07:49 -0400
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 91CFB175A0; Mon, 16 Oct 2006 17:07:18 +0000 (GMT)
Received: from mirror by ietf.org with local (Exim 4.43) id 1GZVvq-0006Ib-5K; Mon, 16 Oct 2006 13:07:18 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: Robert Sayre <sayrer@gmail.com>
From: IESG Secretary <iesg-secretary@ietf.org>
Message-Id: <E1GZVvq-0006Ib-5K@ietf.org>
Date: Mon, 16 Oct 2006 13:07:18 -0400
X-Spam-Score: -2.8 (--)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: atom-syntax@imc.org, ietf-announce@ietf.org
Subject: Response to appeal by Robert Sayre dated 2006-08-29
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Errors-To: ietf-announce-bounces@ietf.org

This is the IESG response to the appeal by Robert Sayre
posted at
http://www.ietf.org/IESG/APPEALS/appeal-from-robert-sayre-08-29-2006.txt.

The IESG has considered Mr. Sayre's concerns and believes that by
requiring mandatory to implement security mechanisms the IESG is
continuing a long established practice with strong IETF-wide
community support. Acting counter to that support would require
evidence of a new community consensus. Some sparse recent
discussion on the IETF-wide list has not yet shown a change in this
support.

Therefore, we reject the appeal and hold with our original advice
given to the atompub working group.

---------

Appendix: Summary of relevant IETF documents

RFC 3935 (BCP 95) states
"The benefit of a standard to the Internet is in interoperability - that
multiple products implementing a standard are able to work together in
order to deliver valuable functions to the Internet's users."

RFC 2026 (BCP9) requires demonstrated interoperability of all
features (mandatory or optional) prior to advancement to DS.

Although demonstrated interoperability is not required for
PS, it is clearly illogical to admit a spec to the standards
track that is by construction ineligible for DS.

Therefore, interoperability is the overall goal and all features
(mandatory or optional) must be designed to be interoperable.

RFC 2360 (BCP 22) points out the dangers of optional features:

"2.10 Handling of Protocol Options

Specifications with many optional features increase the complexity of
the implementation and the chance of non-interoperable
implementations. The danger is that different implementations may
specify some combination of options that are unable to interoperate
with each other."

RFC 3365 (BCP 61) requires strong security to be available for all
protocols.

"The solution is that we MUST implement strong security in all
protocols to provide for the all too frequent day when the protocol
comes into widespread use in the global Internet.
...
However security must be a MUST IMPLEMENT so that end users will have
the option of enabling it when the situation calls for it."

RFC 3631 (IAB document), section 2.2, discusses "Mandatory to implement"
security in more detail. The key sentence is

"To solve this problem, the IETF requires that *ALL* protocols provide
appropriate security mechanisms, even when their domain of
application is at first believed to be very limited."

This is an IAB document, not a BCP, but it is a document that was
discussed widely prior to publication. It describes the policy followed by
the IESG for many years and endorsed by the IAB, in tandem with BCP 61.

---

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce