IESG proposed statement on the IETF mission

Wed Oct 15 18:22:41 CEST 2003

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