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:brc@xxxxxxxxxxxxxx] > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf