IESG proposed statement on the IETF mission

graham.travers at bt.com graham.travers at bt.com
Wed Oct 15 12:47:09 CEST 2003


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



More information about the Problem-statement mailing list