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

Atompub,

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

HTTP-WG,

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

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.

thanks,

Robert Sayre



On 10/16/06, IESG Secretary <iesg-secretary@ietf.org> 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

Received on Monday, 16 October 2006 19:22:38 UTC