IESG proposed statement on the IETF mission

[Brian E Carpenter]

Alistair,

Actually I think it qualifies as a mistake according to the conclusions
of the IAB workshop three years ago (RFC 3002), where we clearly identified
walled gardens as a threat to the Internet as a whole. But I am not a SIP
expert so I will not say more.

I didn't mean that GSC iss a waste of time. However, there are strong limits
to what such coordination can do. Ultimately, all the standards bodies are
autonomous.

   Brian

Alistair.Urie at alcatel.com wrote:
> 
> Brian,
> I think the SIP and 3GPP story is a bit more complex than you make out.
> The so called "mistakes" are basically a set of direct consequences of 3GPP
> strictly following the mobile operator's requirements to maintain a place
> in the value chain and to let them hide certain details of their networks
> from other operators.   How this could be seen as being a "mistake" within
> IETF does raise a few questions about our mechanisms for handling operator
> requirements :-)
> 
> As far as GSC (last meeting was in Ottawa - see
> http://www.tsacc.ca/e/gsc/index.shtml) goes, all I can say is you have been
> missing something since the last few meetings have been quite interesting
> especially with respect to the use of SIP and other IETF protocols, midcom,
> etc. within NGN.  Scott has been coming and has been a very useful
> contributor.  I normally atend via "another organisation".
> 
> - Aistair
> 
> 
>                       Brian E Carpenter
>                       <brc at zurich.ibm.com>                 To:      graham.travers at bt.com
>                       Sent by:                             cc:      harald at alvestrand.no, mcr at sandelman.ottawa.on.ca,
>                       problem-statement-bounces at al         problem-statement at alvestrand.no
>                       vestrand.no                          Subject: Re: IESG proposed statement on the IETF mission
> 
> 
>                       15/10/2003 16:35
> 
> 
> 
> Graham,
> 
> I think the issues you are raising are very important. But I've been told
> that, in
> fact, 3GPP is doing things with SIP that have been specifically pointed out
> as
> mistakes by the IETF. I hope the same doesn't arise with OMA (it was
> someone active
> in OMA who told  me the above, in fact). However, when this happens, there
> really is
> very little the IETF can do, however it reforms itself. I've been to enough
> Global
> Standards Coordination meetings and the like to doubt seriously whether
> such
> coordination can ever be better than an approximation.
> 
> I think we have to concentrate on fixing what we have decided is wrong with
> the
> IETF. But identifying topics of importance to operators that are not being
> tackled
> in the IETF would be a useful exercise, IMHO. I've always wanted to see
> Area Plans
> for each IETF Area.
> 
>    Brian
> 
> graham.travers at bt.com wrote:
> >
> > Harald,
> >
> > OK, since you ask so nicely.   8o)
> >
> > I'll amplify my comments in the full realisation that the last time I
> mentioned that I have people working for me, I was practically accused of
> being the Capitalist exploiter of slave labour !
> >
> > There are two specific examples, where I supported issues being brought
> to the IETF, and where I was prepared to put *real* effort into helping to
> find solutions.  (I mean actual resources to edit documents, chair
> meetings, etc.)
> >
> > 1.  Operations and maintenance support for MPLS.
> > I went so far as to (be able to) run a BOF on this one (not me
> personally).  Despite a lot of interest at the BOF, and a stream of
> "operator people" at the microphone supporting the view that the
> functionality was needed, nothing useful transpired.  Sure, the issue was
> referred to the MPLS WG for consideration - and no doubt they considered a
> lot - but the end result wasn't much use to me.  It's now been addressed
> elsewhere.  This operator just can't afford to run protocols which don't
> allow it to know what control it has.
> >
> > 2.  Midcom.
> > Some of my colleagues and I were instrumental in bringing this issue to
> the IETF, and, sure  enough, a WG was formed.  While the analysis of
> existing protocols was useful, after several years I still don't see any
> standardised solution that I can/should use.  Midcom is still running, so I
> suppose that it hasn't finished its work yet.  I'm still interested in
> having a solution to this issue, but in the operator world time presses.
> >
> > Please understand that I'm *NOT* condemning the IETF for choosing its
> work items.  I am simply explaining that when something is needed, if it
> can't be sourced from one supplier (the IETF) the purchaser has to find
> another supplier, if possible (insert the name of any suitable SDO here!).
> >
> > As far as applications protocols go, I don't have any specific
> requirements in mind.  I mentioned that as an example since I've heard (not
> first-hand) that the OMA is planning protocol developments, which will not
> be referred to the IETF.  One specific example that I mentioned earlier is
> SIP.
> >
> > Brian Carpenter's response to this was to say that we can't control what
> other SDO's do.
> > While this may be technically true, I don't think that the IETF is
> without influence.  Whether it wants to use that influence, even in an
> advisory capacity, is up for debate, I guess.  As the standards that it
> produces increasingly impinge on aspects of society other than the Internet
> (the IESG proposed Statement mentions "controlling street lights" ), the
> IETF has to either assume the responsibility of maintaining them for uses
> outside the Internet, or abrogate that responsibility and let other
> organisations do what they will with them.  The "ultra-Internet" interests
> will not be stopped, if they really want a solution.
> >
> > IMHO, to mangle a famous saying: "No SDO is an island." The International
> Standards Community comprises many standards bodies, which have to
> cooperate to achieve useful solutions.  Where would the Internet be if
> there were no standards for electricity supply, or cable capacity, or even
> time and date ?  The most important thing about a standard is not that the
> solution is necessarily the best one, but that it is the *agreed* one.  If
> we start to have different versions of SIP, for example - the IETF version,
> the 3GPP version, the OMA version - where is the standard, then ?
> >
> > BTW, when is an application not an application ?  What are the
> characteristics that make "controlling street lights" less of an
> application than (say) calendaring and scheduling?  I don't expect an
> answer, but there must be some differentiator, if they both use the
> Internet as a transport mechanism.  If the IETF has, or is developing, such
> differentiators, it would be useful to have them published.  If it hasn't,
> that may help to explain why there's been such a long-running debate.
> >
> >         Regards,
> >
> >         Graham Travers
> >
> >         International Standards Manager
> >         BT Exact
> >
> >         e-mail:   graham.travers at bt.com
> >         tel:      +44(0) 1359 235086
> >         mobile:   +44(0) 7808 502536
> >         fax:      +44(0) 1359 235087
> >
> >         HWB279, PO Box 200,London, N18 1ZF, UK
> >
> >         BTexact Technologies is a trademark of British Telecommunications
> plc
> >         Registered office: 81 Newgate Street London EC1A 7AJ
> >         Registered in England no. 1800000
> >
> >         This electronic message contains information from British
> Telecommunications plc which may be privileged or confidential. The
> information is intended to be for the use of the individual(s) or entity
> named above. If you are not the intended recipient be aware that any
> disclosure, copying, distribution or use of the contents of this
> information is prohibited. If you have received this electronic message in
> error, please notify us by telephone or email (to the numbers or address
> above) immediately.
> >
> >
> > ----Original Message-----
> > From: Harald Tveit Alvestrand [mailto:harald at alvestrand.no]
> > Sent: 15 October 2003 10:23
> > To: Travers,G,Graham,XVT TRAVERG R; mcr at sandelman.ottawa.on.ca
> > Cc: problem-statement at alvestrand.no
> > Subject: RE: IESG proposed statement on the IETF mission
> >
> > --On 15. oktober 2003 09:56 +0100 graham.travers at bt.com wrote:
> >
> > > Harald & Michael,
> > >
> > > It's *getting* worse !
> > >
> > > A few years ago one operator was prepared to fund about 20 individuals
> to
> > > participate in the IETF;  now that's reduced to about 5, with no
> > > guarantee that such a level will be sustained.
> > >
> > > This is not just about the downturn in the industry.  Real problems
> that
> > > operators have are not being addressed by the IETF.  If the IETF won't
> > > address my concerns, and if I have to go to the OMA to meet my
> > > requirements for application protocols, for example, that's where I'll
> go.
> > >
> > > You may say "That's fine".  OK, if that's the policy.  But, then, don't
> > > be surprised if it happens !
> >
> > Graham,
> >
> > thanks for your input!
> >
> > it would be nice if you could name examples - since I'm not an operator
> and
> > have rarely been on the forefront of the debates where you have been
> > engaged, I don't have enough background to evaluate the experiences
> you're
> > sharing.
> >
> > In particular, I'm interested in hearing your requirements for
> applications
> > protocols - both because I come from an applications background myself
> and
> > believe the applications perspective to be important for the IETF, and
> > because the proper boundary between "IETF work" and "application space
> > work" is one of the long-simmering (long-festering?) debates that the
> IETF
> > has never been able to come to resolution on.
> >
> >                      Harald

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <brc at zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK