Subject: RE: IESG proposed statement on the IETF mission

From: <[email-masked]>
Date: Wed, 15 Oct 2003 11:47:09 +0100

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:   [email-masked]
	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:[email-masked]]
Sent: 15 October 2003 10:23
To: Travers,G,Graham,XVT TRAVERG R; [email-masked]
Cc: [email-masked]
Subject: RE: IESG proposed statement on the IETF mission 

--On 15. oktober 2003 09:56 +0100 [email-masked] 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

---

From: Eric Rosen <[email-masked]>
Date: Wed, 15 Oct 2003 09:50:34 -0400

This business about  there not being enough operator  participation is a lot
of baloney. 

The  reasons   some  operators  think  that  there   isn't  enough  operator
participation are (a) different sets of operators inhabit different WGs, and
(b) operators tend  to ignore the input of other  operators who may disagree
with them.  

If you look, e.g., at the main IETF list, at the routing-discussion list, at
the idr list,  etc., you'll see one  class of operator.  If you  look at the
PWE3 list,  the MPLS list, the CCAMP  list, the L3VPN list,  the L2VPN list,
etc., you'll see an entirely  different class.  And within the latter lists,
there are  large disagreements about very fundamental  principles.  For some
reason, each group denies the existence of the others.

Of course, when  any particular operator fails to  achieve consensus for his
preferred  solution,  the  problem  is  perceived as  "not  enough  operator
input".  

I think the set  of operators that Harald is thinking of  would be aghast at
the proposals of the set of operators that Graham is thinking of.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Oct 2003 16:35:26 +0200

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Oct 2003 12:50:58 -0300

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "graham" == graham travers <[email-masked]> writes:
    graham> BTW, when is an application not an application ?  What are the
    graham> characteristics that make "controlling street lights" less of an
    graham> application than (say) calendaring and scheduling?  I don't

  The critical difference is whether or not multiple *operators* will have
to communicate using the protocol. 
  So, in the case of controlling street lights, it is pretty unlikely that
the Chicago Municipal Street-Light Control Network (CMSLCN) will have to
control lights located in New York City. As long as all of the equipement in
the CMSLCN.net are owned by CMSLCN.net, then CMSLCN is in a position to:
    1) dictate to their vendor what the standard will be.
    2) provision the equipment (in advance) such that things interoperate
    3) buy from whatever vendor pleases it most.

  As soon as the lights in NYC (owned, provisioned and bought by NYC) have to
operate with the light controller in Chicago, then we need an IETF standard.

  Clearly, it is easiest for CMSLCN.net if they have a proven standard with
products from multiple vendors that are already proven to interoperate, but
the lack of such a thing does not affect the internet as a whole.

  This is one of the reasons why MPLS, and to a certain extent "PPVPN" gets
downtrodden at the IETF - both are in many ways designed to operate within an
AS, so it isn't clear that we should allocate lots of time to them. Vis
multicast or IPv6, where it has been successfully deployed by many 
operators, but still isn't universally available, because it requires that
all the operators between the n-locations cooperate and agree to some set of
standards. (Not to mention that there be some rational business plan. Not
that IPv4 had a rational business plan when it started either!)

] Collecting stories about my dad: http://www.sandelman.ca/cjr/ |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: "todd glassey" <[email-masked]>
Date: Wed, 15 Oct 2003 22:25:34 -0700

The issue is one of whether the participants represent their own interests
or those of the sponsor and how the sponsor itself becomes the focal point
for an initiative. The intent is not to build "Joe's protocol" and Joe was
sponsored by Widget Co, the intent is to have Widget Co's Protocol run
through the IETF and this is a core reversal of the focus of the
organization which was setup along the lines of an academic standards
process - it supported the individual researcher as an individual - and
there is nothing wrong with this, its just that the other side of the coin
needs representation too.

Todd

----- Original Message ----- 
From: "Eric Rosen" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, October 15, 2003 6:50 AM
Subject: Re: Operator participation

---

From: Eric Rosen <[email-masked]>
Date: Thu, 16 Oct 2003 10:33:02 -0400

> As soon as  the lights in NYC (owned, provisioned and  bought by NYC) have
> to operate  with the  light controller  in Chicago, then  we need  an IETF
> standard.

You  are   making  a  host  of  unwarranted   assumptions.   It's  perfectly
conceivable that NYC has, say, five  different networks, one for each of its
five boroughs, and that each network  is run in an autonomous fashion.  It's
equally  conceivable that  the  main  street light  control  facility is  in
Manhattan, and it needs to talk to the lights in each of the five boroughs.  

If  one thinks  of  street lights  in a  set  of smaller  towns, it's  quite
conceivable that  each town has its  own network, but that  light control is
done  from  a  regional center  jointly  funded  by  the towns.   It's  also
conceivable that  a bunch  of towns  in one state  might contract  out their
light control functions  to a company whose monitoring/control  center is in
another state entirely. 

So I don't think your criterion rules out the street light protocol. 

There are  some things which  are clearly ruled  out by your  criterion: for
example, OSPF would be ruled out, and  so would DHCP.  I think SNMP would be
ruled out as well (one operator managing another's routers?). 

I'd say then that your criterion  does not reflect any existing practice nor
does it reflect a desirable practice.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 20 Oct 2003 11:46:15 -0700

--On 15. oktober 2003 12:50 -0300 Michael Richardson 
<[email-masked]> wrote:

> control lights located in New York City. As long as all of the equipement
> in the CMSLCN.net are owned by CMSLCN.net, then CMSLCN is in a position
> to:     1) dictate to their vendor what the standard will be.
>   As soon as the lights in NYC (owned, provisioned and bought by NYC)
> have to operate with the light controller in Chicago, then we need an
> IETF standard.

Why an IETF standard, and not a Traffic Light Controllers Forum standard?

---

From: Eric Rosen <[email-masked]>
Date: Tue, 21 Oct 2003 11:32:13 -0400

> Why an IETF standard, and not a Traffic Light Controllers Forum standard? 

Here's the typical progression.

The "traffic  light controllers forum"  concludes that the  Internet doesn't
really  provide  adequate  service/qos/oam/security  or  whatever  and  that
controlling  traffic lights requires  an ATM/FrameRelay/DialUp/X.25/Ethernet
or whatever.  (Perhaps the rules for voting in the traffic light controllers
forum prevent the technical issues from being considered.)

A  few rebel  traffic light  providers  then get  together with  one or  two
networking vendors and  figure out how to do the  traffic light control over
the Internet.

In a short  time, this proprietary mechanism becomes  widely deployed, while
the "standard" produced by the forum  has no deployment.  The forum fails to
see  this,  and continues  to  work on  perfecting  the  standard by  adding
additional OAM to it. 

The rebels (who by now are  controlling most of the traffic lights) start to
worry about their  dependence on one or two vendors, and  decide they want a
published standard  with some sort of  imprimatur.  So they ask  for an IETF
WG.

Meantime,  the  IAB (whose  job  is  to fret  and  deplore)  issues a  paper
deploring the  inadequate congestion  control, security, and  scalability of
the proprietary mechanisms, fretting about the effect on the Internet.

Prominent IESG  members announce that  anyone who pays attention  to traffic
lights is  clueless, that no  one will ever  control them over  the Internet
anyway, and  that the whole  thing is just  a vendor scam.   Operators don't
care  whether  traffic  lights  work  or not,  controlling  them  just  adds
complexity.   Besides, traffic  light  control protocols  weren't needed  in
1990, so how can they be needed today? 

A WG is  formed, but the charter requires that  a requirements and framework
document be produced before any protocol specification work is done.

Four years later the IETF  standards for the application get approved.  They
are quite similar to the  proprietary mechanisms, which already dominate the
industry.  Prominent IESG members still  insist that no one will ever deploy
them.  Other IETF members ask why the standards have been rushed through.

The traffic light controller forum  then endorses the IETF standard, renames
themsevles to be the "IP-based  real time device control forum", and asserts
itself to be the proper standards body for all kinds of IP-based protocols.  

Seriously:

- A  considerable amount of time  could be saved  if the IETF just  does the
  work in the first place.  

- The very last thing we want is a proliferation of clueless forums claiming
  to be  producing standards  for IP-based protocols;  it's hard to  see how
  that is "good for the Internet".

- Traffic light control  was picked  as an  example in  order to  make IETF
  involvement look absurd; if a  more realistic example (providing some sort
  of network service or network  infrastructure) had been picked, the proper
  conclusions would be even more obvious.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Oct 2003 15:31:31 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Harald" == Harald Tveit Alvestrand <[email-masked]> writes:

    Harald> Why an IETF standard, and not a Traffic Light Controllers Forum
    Harald> standard? 

  a) Fora tend to include only people who pay to join them, and not the
     general public, or things like LEAs, or pedestrian and cycling 
     organizations (which in this case, might care)

  b) I'm not actually sure the answer to the above question for any of the
     things currently in Applications, and even some of things in Transport.
     Having said that, I'm not sure that they shouldn't be there.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 22 Oct 2003 18:18:44 -0500

--On 21. oktober 2003 15:31 -0400 Michael Richardson 
<[email-masked]> wrote:

>     Harald> Why an IETF standard, and not a Traffic Light Controllers
> Forum     Harald> standard?
>

That's an issue with the form of the forum. I think the Global Grid Forum 
has taken a number of ideas from the IETF in how they do their work, for 
instance. And the interests of pedestrian organizations aren't very well 
served by the current IETF constituency, for that matter....
>      things currently in Applications, and even some of things in
> Transport.      Having said that, I'm not sure that they shouldn't be
> there.

I don't think that it's necessary for the IETF mission to be consistent 
with every decision we've taken in the past. And some things (like LDAP) 
didn't turn out the way we thought they would five or ten years back - the 
global directory is as dead as the global PKI at the moment.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 23 Oct 2003 09:51:23 -0400

Harald> I  don't  think that  it's  necessary for  the  IETF  mission to  be
Harald> consistent with every decision we've taken in the past. 

If your "mission statement" is  inconsistent with MANY of the decisions that
have been taken  in the past, then  you should admit that you  are trying to
change the IETF's  mission to suit your own  preferences, rather than trying
to codify any existing practice. 

If we're  not trying for any  consistency, then I would  raise the following
questions: 

1. Why should the  IETF work on BGP?  Can't that be  done by a consortium of
   vendors and ISPs separate from the IETF?  

2. Why should the  IETF work on DNS?  Can't that be  done by a consortium of
   vendors and ISPs separate from the IETF? 

3. Why should  the IETF exist at  all?  Surely anything it does  can be done
   somewhere else by some other group.

We  should  either  aim  for  consistency  with  the  past,  or  else  do  a
"zero-based" mission statement in which everything is up for grabs and there
are no sacred cows.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 23 Oct 2003 11:40:32 -0500

--On 23. oktober 2003 09:51 -0400 Eric Rosen <[email-masked]> wrote:

>
> Harald> I  don't  think that  it's  necessary for  the  IETF  mission to
> be Harald> consistent with every decision we've taken in the past.
>
> If your "mission statement" is  inconsistent with MANY of the decisions
> that have been taken  in the past, then  you should admit that you  are
> trying to change the IETF's  mission to suit your own  preferences,
> rather than trying to codify any existing practice.

True. But I don't want to close out the option of admitting that adopting 
TRADE, FORCES, OPES or SPEECHSC was a mistake, or that we shouldn't have 
kicked HTML work out of the IETF and into the World Wide Web Consortium, if 
that's what the community thinks.
All of these were debated at the time the decisions were made. It would be 
a surprise if we, using 20/20 hindsight, were to conclude that we did the 
right thing every time.

Note: If I was trying to change the IETF's mission to suit my own 
preferences, this discussion would be shorter. I'm trying to change the 
IETF's mission to suit the *IETF*'s preferences.

               Harald

---

From: "todd glassey" <[email-masked]>
Date: Thu, 23 Oct 2003 16:13:21 -0700

Harald - perhaps the problem is that the IETF's preferences are the issue.

Todd