Subject: RE: When to DISCUSS?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 11 Jul 2005 09:32:01 -0700

My biggest concern here is not the IESG itself, it's the folk who
presume to speak on its behalf.

I think it is important to have the statement be explicit and
unambiguous. 

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Monday, July 11, 2005 9:42 AM
> To: Hallam-Baker, Phillip
> Cc: IETF Discussion
> Subject: Re: When to DISCUSS?
> 
> 
> Phill,
> 
> Just picking out the nub of your message:
> 
> > There is however one area that should be made very explicit 
> as a non 
> > issue for DISCUSS, failure to employ a specific technology platform.
> > 
> > I have been concerned on a number of occasions where it has 
> appeared 
> > that in order to get a specification approved by the IESG 
> it would be 
> > necessary to adopt a particular technology being promoted by IESG 
> > members.
> 
> I think the last phrase is unfair - if the IETF is putting a 
> lot of effort into technology Foo, then it's a legitimate 
> question to ask "Why aren't you re-using Foo?" But we do have 
> as a non-criterion:
> 
>     o  Disagreement with informed WG decisions that do not exhibit
>        problems outlined in Section 3.1.  In other words, 
> disagreement in
>        preferences among technically sound approaches.
> 
> As I read this, it would be legitimate for an AD to ask
> 
>    Did the WG consider Foo, and if so, have good reasons for
>    rejecting it in favour of Bar?
> 
> and illegitimate to say
> 
>    I like Foo more than Bar, so I'm blocking this.
> 
> If we agree on this, some wordsmithing may be needed.
> 
>      Brian
> 
> Hallam-Baker, Phillip wrote:
> >>draft-iesg-discuss-criteria-00.txt talks about this. Even
> >>within the IESG, we still have one or two points to resolve, 
> >>but we wanted to get this out before the cutoff date. This 
> >>isn't in any way intended to change any of the principles of 
> >>the standards process, but we'd welcome community comment.
> > 
> > 
> > This is actually quite good. In particular I think that it 
> does go a 
> > long way in returning to the original concept of the IETF 
> rather than 
> > what it had been turning into.
> > 
> > There is however one area that should be made very explicit 
> as a non 
> > issue for DISCUSS, failure to employ a specific technology platform.
> > 
> > I have been concerned on a number of occasions where it has 
> appeared 
> > that in order to get a specification approved by the IESG 
> it would be 
> > necessary to adopt a particular technology being promoted by IESG 
> > members. This issue is not unique to the IETF, at one point 
> there was 
> > a major issue in W3C when some members suspected that Semantic Web 
> > would be imposed in this manner. I believe that a similar dynamic 
> > played a major role in causing OSI to become what it became.
> > 
> > 
> > There are some cases where this is a good idea, it is clearly 
> > important that every IETF standard protocol is capable of 
> making the 
> > transition to IPv6. But there are other cases where this 
> really comes 
> > down to second guessing the WG or worst of all promoting a pet 
> > project.
> > 
> > For example when I submit a draft proposing a prefix for 
> use with SRV 
> > I do not expect to have to explain my reasons for using a 
> technology 
> > that is widely supported by existing infrastructure over NAPTR, a 
> > technology which is only partially supported, has yet to 
> gain a major 
> > constituency of users and may well end up being superceeded 
> before it 
> > is widely adopted.
> > 
> > 
> > Now some might say that the role of the IESG should be 
> precisely to do 
> > this sort of thing, to encourage the adoption of technology that 
> > deserves to be employed as a technology base. I disagree 
> because this 
> > leads working groups to think that its not their job to 
> promote their 
> > work product and drive its adoption, they can simply rely 
> on the IESG 
> > to do their work for them by forcing other groups who have killer 
> > applications to do the heavy lifting for them.
> > 
> > I spend a great deal of time working out how to get a protocol 
> > adopted, how to build the necessary coalitions of support to drive 
> > deployment. If I have a choice of technology platforms I am 
> not going 
> > to necessarily pic the one that is the newest, brightest 
> and shinyest. 
> > In the first place I have been caught out in the past several times 
> > following that route and finding that my spec is the only 
> system built 
> > on the new platform. But more importantly the more infrastructure 
> > innovations a proposal requires the harder it is to build a 
> coalition 
> > and the harder it is to keep it together.
> > 
> > 
> > The most worrying version of this approach is when a group is told 
> > that in order to gain approval of the IESG it MUST take a 
> particular 
> > technical approach. This is why I would like a very 
> concrete statement 
> > in the DISCUSS document saying that a WG is free to choose 
> an approach 
> > that uses deployed technology over another proposal without market 
> > traction.
> > 
> > I know of two cases where a group has been essentially forced to 
> > significantly compromise their design in order to support BEEP. At 
> > this point it should be clear to anyone who follows the Web 
> Services 
> > area that there is universal agreement amongst vendors and 
> developers 
> > that the SOAP stack is the only one that will be used. This outcome 
> > has been clear to anyone who has followed this area for at 
> least four 
> > years.
> > 
> > I watched the SACRED group being bullied into adopting BEEP as a 
> > substrate. This makes even less sense when you know that SACRED was 
> > intended to be a compliment to XKMS which is defined to be a Web 
> > Service running over SOAP. The only argument I saw made at 
> the meeting 
> > was that the IESG would expect BEEP to be supported so the 
> WG better 
> > get in line.
> > 
> > 
> > There is at this point a huge difference in the 
> capabilities of BEEP 
> > and the capabilities of Web Services based on the SOAP, 
> WSDL etc. It 
> > is a major imposition on a working group to require them to support 
> > BEEP because it then forces the group to re-invent the work 
> that has 
> > gone into WS-Security. Developers are then required to 
> implement the 
> > DIY security infrastructure developed by the group rather 
> than use the 
> > existing libraries in the Web Services development environments.
> > 
> > It would be much easier for me to get INCH/RID adopted as 
> an incident 
> > notification protocol in the anti-phishing world in its 
> original Web 
> > Services compliant form than in the current incarnation that was 
> > imposed on the group by an area director. If I am talking to 
> > Microsoft, IBM, Sun or any bank that uses their technology 
> it is much 
> > easier to get them to buy into a protocol that they can build in an 
> > afternoon using standard toolkits than something that will require 
> > bespoke work.
> > 
> > 
> > In summary, the DISCUSS draft is header in the right 
> direction and the 
> > above is implicit in its text but it should be made explicit.
> > 
> > 		Phill
> > 
> 
> 
> 

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

---

From: Thomas Narten <[email-masked]>
Date: Tue, 12 Jul 2005 10:52:46 +0200

> presume to speak on its behalf.

This is a valid concern, and one that has made me cringe multiple
times. I've too often heard of reports where someone says "but the
IESG will never accept this", or "that's not what AD foo says", etc.

Folks should not take such statements as gospel, but should do due
diligence to verify that such statements are actually true and make
sense (statements are often nuanced, and meaning gets significantly
changed when paraphrased, etc.).

Bottom line, folks should be skeptical about blanket assertions,
unless they are convinced  they really understand the issues and the
justification for an AD (or the IESG) saying something.  If in doubt,
ask and get additional opinions.

Thomas