Subject: Re: Response to appeal by Robert Sayre dated 2006-08-29

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Oct 2006 20:50:58 +0200

Robert,

thanks for following up even though the outcome was as expected.

Robert Sayre schrieb:
> 
> Atompub,
> 
> Sorry, I guess you're stuck with the complete nonsense in your current 
> draft. Even though RFC2617 is already a draft standard.

Well, maybe the members of the working group want to consider to have 
the protocol published somewhere else (remember there was a big 
discussion about W3C vs IETF before this working group was formed?).

> HTTP-WG,
> 
> Which mechanism will become required to implement for all HTTP/1.1 
> implementations? You can't cycle at DS without picking one.

One potential outcome may be that there'll be no revision of the spec.

> IESG,
> 
> "It means what we want it to mean". Below, there are some brief 
> responses to the irrelevant citations that were included.
> 
> I guess I'll head over to Apache and write some client support for their 
> new HTTP security standards.

Sounds good. Any pointers to what's going on there? A good security 
mechanism implemented both in Apache httpd and Mozilla clearly would be 
A Good Thing.

Best regards, Julian

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Oct 2006 21:15:07 +0200

Julian Reschke schrieb:

> ...
> ...

Robert has a summary at 
<http://www.franklinmint.fm/blog/archives/000897.html>. (should have 
looked at his blog first...).

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Mon, 16 Oct 2006 12:26:14 -0700

Julian Reschke wrote:
> [snip]

-1. At this point switching venues would be positively ridiculous.

- James

---

From: Robert Sayre <[email-masked]>
Date: Mon, 16 Oct 2006 13:47:05 -0400

Atompub,

HTTP-WG,

IESG,

thanks,

Robert Sayre

On 10/16/06, IESG Secretary <[email-masked]> wrote:
 > 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.

Nonsense.  2616 and 2617 are already at 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 .ietf.org with esmtp (Exim 4.43)
	id 1Gc2lH-0000M9-F1; Mon, 23 Oct 2006 12:34:51 -0400
Date: Mon, 16 Oct 2006 13:47:05 -0400
From: Robert Sayre <[email-masked]>
To: [email-masked],  [email-masked], 
	HTTP Working Group <[email-masked]>
Cc: 
Subject: Re: Response to appeal by Robert Sayre dated 2006-08-29

Atompub,

HTTP-WG,

IESG,

thanks,

Robert Sayre

On 10/16/06, IESG Secretary <[email-masked]> wrote:
 > 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.

Nonsense.  2616 and 2617 are already at 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."
 >

HTTP authentication is specified by RFC2616/RFC2617. Furthermore, BCP 22 
describes decisions for Internet Standards Writers (read: WG), not 
Security Area Directors.

 > 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."
 >

Yes, you have to pick something, but not everyone will pick the same thing.

 > 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.
 >

Yes, you have to pick something, but not everyone will pick the same thing.

-- 

Robert Sayre

combination of options that are unable to interoperate
 > with each other."

HTTP authentication is specified by RFC2616/RFC2617. Furthermore, BCP 22 
describes decisions for Internet Standards Writers (read: WG), not 
Security Area Directors.

 > 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."
 >

Yes, you have to pick something, but not everyone will pick the same thing.

 > 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.
 >

Yes, you have to pick something, but not everyone will pick the same thing.

-- 

Robert Sayre