Subject: RE: "Discuss" criteria

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 4 Jan 2007 14:09:02 -0800

> From: Brian E Carpenter [mailto:[email-masked]] 

> >    The proper cure for the disease Keith names has been agreed upon 
> > for years now: early cross-area expert review.
> 
> I fully agree.

The question is whether this necessarily works to the intended effect.

I think that it has to be possible for a WG to solicit cross-area review but after due consideration of the advice reject it.

For example lets take BEEP which is still nominally an IETF Draft Standard even though at this point a rational evaluation of its status would be to consider it HISTORIC or DEPRICATED*. BEEP is simply not a player in the Web Services world where the only platforms that are being discussed are SOAP or layering on raw HTTP.

So now lets imagine that someone brings a proposal to the IETF that is layered on SOAP and the WS-* stack. Are they to be required to rewrite it to support BEEP just because a few folk in the apps area don't recognize reality?

There has to be room here for "Your proposal adds nothing of value to our project and will only harm it".

In particular I think we really need to squash the mindset that goes "I do not have to think about how to persuade people to deploy my protocol because I can attach it to other protocols that people actually want to deploy".

BEEP is a case in point. It was rushed through in a few months so that the IETF could claim it had peed on the Web Services area first. The authors did not attempt the type of broad outreach that the proponents of SOAP engaged in.

If the authors had been forced to think about the problem of evangelising their platform it might have been more successful. Instead they rammed it through the IETF without any attempt at consensus building in the application developer community then tried to imply that IETF standards are expected to be based on BEEP, not SOAP.

This is particularly important in the security area and for any protocol with security issues - in other words always. Not so long ago we used to have a habit of insisting that everything work over everything and that agnostic support for HTTP, SMTP, NNTP, MIME, PGP, S/MIME. Now we recognize that the kitchen sink approach is terrible for security, we multiply the number of code paths for no good reason.

* There is actually a bug here in BCP 9. It should be possible to change the status of a platform specification so that no future standards track specifications are built on it without affecting the status of existing standards. For example IPv4 hould at this point be considered DEPRICATED since all new standards proposals are required to support IPv6. An interesting feature of the IETF process is that a majority of RFCs with 'STANDARD' status would be more appropriately considered DEPRICATED or HISTORIC (RFC 822, etc etc etc )
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 Jan 2007 17:31:37 -0500

-------- Original Message --------

> I think that it has to be possible for a WG to solicit cross-area
> review but after due consideration of the advice reject it.
> 
> For example lets take BEEP which is still nominally an IETF Draft
> Standard even though at this point a rational evaluation of its
> status would be to consider it HISTORIC or DEPRICATED*. BEEP is
> simply not a player in the Web Services world where the only
> platforms that are being discussed are SOAP or layering on raw HTTP.

You might want to reread RFC 2026.  BEEP met and continues to meet the 
requirements for Draft Standard.  Draft Standard is a measure of 
specification quality and protocol quality and implementor interest.  It 
is not a measure of market acceptance.

Also, I think you may have left out some part of your argument.  You 
cited this as an example of a WG rejecting cross-area review.  Even if 
the BEEP WG got external reviews claiming that SOAP was better, I hardly 
think that an NIH argument from an external party is a good 
justification on its face for abandoning an IETF effort.  SOAP is rather 
poorly designed, and using HTTP as a substrate for any kind of RPC 
protocol is generally a pretty poor idea, technically.  In general, the 
fact that lots of people out there do stupid things is not a reason for 
IETF to endorse that kind of stupidity.

> So now lets imagine that someone brings a proposal to the IETF that
> is layered on SOAP and the WS-* stack. Are they to be required to
> rewrite it to support BEEP just because a few folk in the apps area
> don't recognize reality?

Do you actually see such a requirement in an RFC?  Or are you just 
imagining it?  There are indeed rules for normative references in IETF 
specifications, but they don't preclude using SOAP or Web Services as 
long as there are stable specifications that can be referenced.

> our project and will only harm it".

People are certainly free to make such claims and have them evaluated. 
Of course it helps to have sound technical justification to back up 
those claims.

> In particular I think we really need to squash the mindset that goes
> "I do not have to think about how to persuade people to deploy my
> protocol because I can attach it to other protocols that people
> actually want to deploy".

Marketing is certainly something that we could do better.

> BEEP is a case in point. It was rushed through in a few months so
> that the IETF could claim it had peed on the Web Services area first.

or maybe because its proponents felt it was technically superior?
(which IMHO it is)

> The authors did not attempt the type of broad outreach that the
> proponents of SOAP engaged in.

Again, marketing is certainly something that we could do better.  But 
just because the market selected something different than IETF produced 
does not mean that IETF was wrong to try to do something technically 
better than SOAP.  Not everything IETF does will be successful in the 
market, but we should still try to do good technical work - else there 
is no purpose for IETF.

> If the authors had been forced to think about the problem of
> evangelising their platform it might have been more successful.
> Instead they rammed it through the IETF without any attempt at
> consensus building in the application developer community then tried
> to imply that IETF standards are expected to be based on BEEP, not
> SOAP.

Sometimes a good way to get a technology to be used is to get it blessed 
as a standard before its competitors.  It's not as if that approach 
never works.

> This is particularly important in the security area and for any
> protocol with security issues - in other words always. Not so long
> ago we used to have a habit of insisting that everything work over
> everything and that agnostic support for HTTP, SMTP, NNTP, MIME, PGP,
> S/MIME.

I'm sure there were people who believed that, but I don't recall any 
consensus to that effect in the last 15 years or so.

> * There is actually a bug here in BCP 9. It should be possible to
> change the status of a platform specification so that no future
> standards track specifications are built on it without affecting the
> status of existing standards. For example IPv4 hould at this point be
> considered DEPRICATED since all new standards proposals are required
> to support IPv6. 

That's ridiculous since it's still acceptable for new standards to 
support IPv4 (thus requiring a normative reference to IPv4 or something 
that uses IPv4) in addition to IPv6.

Keith