Subject: Re: [RAI] Making RAI work better

From: Eric Burger <[email-masked]>
Date: Mon, 6 Oct 2008 16:02:34 -0400

Shoot me for being the messenger: Does this mean the IETF is just not  
the place for working on SIP? If SIP isn't really an Internet protocol  
and has been co-opted into being, for example, a telco protocol,  
should we move it to ITU-T? Or, is it something just beyond the  
capabilities of the IETF and we will need to create something akin to  
the W3C? I chose the W3C example, as one could say the W3C was birthed  
from the IETF from the then melt-down of the Applications Area, with  
much of the same issues then as we are seeing today in RAI.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of DRAGE,
> Keith (Keith)
> Sent: Monday, October 06, 2008 12:00 PM
> To: [email-masked]
> Subject: Re: [RAI] Making RAI work better
>
> Hanging on the last mail in the thread, and not specifically  
> replying to
> that rather than any other.
>
> I think people have missed the main issue. The IETF structure of  
> working
> groups and indeed the overall IETF architecture is built around  
> defining
> a relatively small protocol for each function, and then allocating  
> that
> protocol to a working group.
>
> SIP does not fulful that model, and therefore all talk of separating  
> out
> further working groups to discuss SIP is doomed to failure. All you do
> is divide the people that are attempting to work on that one protocol
> into multiple shared entities where they all try and work in these
> multiple working groups, with the downside that people fail to
> understand which group they should communicate with in order to  
> solve a
> particular problem.
>
> Examples of this include:
>
> -	the protocol is too big to reissue, so we seem unable to correct
> faults. Other protocols roll in changes and reissue every few years.
>
> -	we have no objective of following the IETF process to obtain
> draft, because people regard it as too big and therefore requiring too
> many resources to sucessfully achieve.
>
> Therefore we need to do one of two things:
>
> -	Rearchitect SIP so that it conforms to the IETF model. This
> means splitting it into multiple individual protocols, each fulfulling
> the rules of a protocol in their own right, e.g. coding rules,
> compatibility rules, state machines that act independently of each
> other, etc. Inherently this means a replacement for SIP that is not
> compatible with SIP 2.0. Given that, I think it stands very little
> chance of success at this point of time. Resources are fully committed
> to deploying existing SIP, and people will not thank us for doing what
> is essentially a U turn on the protocol.
>
> -	Change or modify the working procedures to deal with the
> elephant we have created. Again I suspect we have some fundamental
> problems here, but I would favour at least the following:
>
> 	a)	consolidation of WG rather than splitting, and give them
> more time. Note that part of the excuse of splitting the working  
> groups
> was to get over the rule that WG could have more than two sessions. We
> should scrap that rule. In some ways the last thing we want is more
> chairmen - what we need is potentially a single point of contact of  
> the
> documentation in progress, and then find some way of offloading some  
> of
> the chair tasks.
>
> 	b)	we need to find a way to get corrections and extensions
> into the protocol in a more flexible manner. Smaller protocols do this
> by republishing frequently - other SDOs republish their large
> specifications as often as every three months. They do this by meeting
> in a single session for up to a week. Frequently it takes an AD longer
> to even open the document after a publish request than three months.
>
> Note that I do accept many of the problems identified prior in this
> thread are valid. Particularly we do seem to have had a problem of
> consensus building, and then sticking to that consensus.
>
> Regards
>
> Keith
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Livingood, Jason
>> Sent: Friday, October 03, 2008 6:38 PM
>> To: Ben Campbell; Mary Barnes
>> Cc: [email-masked]
>> Subject: Re: [RAI] Making RAI work better
>>
>>
>>> If we _do_ add more groups, I suggest we focus on charters that can
>>> conceivably complete--and close down. We've developed a culture of
>>> open-ended work groups. That's not what work groups are for--that's
>>> what _areas_ are for.
>>
>> This is an excellent point I think.  It is difficut to apply
>> this in practice sometimes, however, due to document editors
>> having other priorities that delays I-D revisions.  In these
>> cases, WG chairs perhaps need to be more aggressive about
>> replacing editors to keep work moving.
>> We also can improve the distribution of workload by
>> encouraging and supporting document editors that are new to
>> the community or are less frequent contributors -- as an
>> effort to widen the pool of contributors overall.
>>
>> In my own (limited) experience trying to pull in people who
>> are not regular contributors, they often feel they lack the
>> knowledge of some of the more prodigious RAI doc authors and
>> just need support and encouragement.
>>
>> If we agree that getting more authors and editors that are
>> outside of the group of regulars, then we should actively
>> make this an RAI-wide priority, and we should talk about it a
>> great deal at IETF 73 so people understand why we're doing
>> it, support it, and it encourages people to start to step up.
>> I believe we will then be able to slowly gain more
>> contributors and, at the same time, those in my microphone
>> queue may be a bit more gentle with these less experienced
>> contributors*.
>>
>> Jason
>>
>> * Do not underestimate the fact that many potential
>> contributors find presenting and defending drafts for the
>> first time terribly intimidating
>> - many among our community are more comfortable spending time
>> with computers than with people.  ;-)
>> _______________________________________________
>> RAI mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rai
>>
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai

_______________________________________________
RAI mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rai

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 6 Oct 2008 22:23:51 +0200

I did not say SIP was not for the IETF, although my criteria for any
particular group discussing a particular subject area would probably be
substantially different to yours.

I would say that any organisation should discuss a particular subject
area if the particular experts in that particular subject are are
participating in that organisation. That is clearly the case with SIP
and IETF. The experts exist in the IETF. 

However IETF created a set of rules for discussion items based on
protocols being small elements of a much larger whole. If we allow large
(and unwieldy) protocols to exist, then we need to adjust or change the
rules to manage them.

Keith

> Behalf Of Eric Burger
> Sent: Monday, October 06, 2008 9:03 PM
> To: [email-masked]
> Shoot me for being the messenger: Does this mean the IETF is 
> just not the place for working on SIP? If SIP isn't really an 
> Internet protocol and has been co-opted into being, for 
> example, a telco protocol, should we move it to ITU-T? Or, is 
> it something just beyond the capabilities of the IETF and we 
> will need to create something akin to the W3C? I chose the 
> W3C example, as one could say the W3C was birthed from the 
> IETF from the then melt-down of the Applications Area, with 
> Behalf Of 
> > DRAGE, Keith (Keith)
> > Hanging on the last mail in the thread, and not 
> specifically replying 
> > to that rather than any other.
> >
> > working groups and indeed the overall IETF architecture is built 
> > around defining a relatively small protocol for each function, and 
> > then allocating that protocol to a working group.
> >
> > out further working groups to discuss SIP is doomed to failure. All 
> > you do is divide the people that are attempting to work on that one 
> > protocol into multiple shared entities where they all try 
> and work in 
> > these multiple working groups, with the downside that 
> people fail to 
> > understand which group they should communicate with in 
> order to solve 
> > a particular problem.
> >
> > groups was to get over the rule that WG could have more than two 
> > sessions. We should scrap that rule. In some ways the last thing we 
> > want is more chairmen - what we need is potentially a 
> single point of 
> > contact of the documentation in progress, and then find some way of 
> > offloading some of the chair tasks.
> >
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >> Livingood, Jason
> >> This is an excellent point I think.  It is difficut to 
> apply this in 
> >> practice sometimes, however, due to document editors having other 
> >> priorities that delays I-D revisions.  In these cases, WG chairs 
> >> perhaps need to be more aggressive about replacing editors to keep 
> >> work moving.
> encouraging and 
> >> supporting document editors that are new to the community 
> or are less 
> >> frequent contributors -- as an effort to widen the pool of 
> >> contributors overall.
> >>
> >> In my own (limited) experience trying to pull in people 
> who are not 
> >> regular contributors, they often feel they lack the 
> knowledge of some 
> >> of the more prodigious RAI doc authors and just need support and 
> >> encouragement.
> >>
> outside of 
> >> the group of regulars, then we should actively make this 
> an RAI-wide 
> >> priority, and we should talk about it a great deal at IETF 73 so 
> >> people understand why we're doing it, support it, and it 
> encourages 
> >> people to start to step up.
> contributors and, 
> >> at the same time, those in my microphone queue may be a bit more 
> >> gentle with these less experienced contributors*.
> >>
> >> Jason
> >>
> contributors find 
> >> presenting and defending drafts for the first time terribly 
> >> intimidating
> >> - many among our community are more comfortable spending time with 
> >> computers than with people.  ;-)

---

From: Eric Burger <[email-masked]>
Date: Mon, 6 Oct 2008 21:06:21 -0400

The subject matter experts are, for the most part, in the IETF.  
However, I would offer that for many of the participants, SIP is the  
only reason they participate in the IETF. Letting the IETF be free to  
pursue Internet protocols might be a win-win result of splitting SIP/ 
RAI into its own organization.

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 6 Oct 2008 21:14:52 -0400

Keith I'd personally to take this opportunity to sincerely thank you for
your thoughtful analysis of the current issues surrounding the RAI
directorate and the SIP protocol in general.

Along with Henry I agree there is a problem here and we need to come up with
a more comprehensive solution. 

We have seen this problem brewing for several years as the IETF process, as
you correctly point out, favors atomic solutions to the over all
architectural problems posed by SIP. 

See a issue, write a draft, fix problem etc. But that has not worked out in
practice.

For years now I have heard SIP implementers, whether they be service
providers or enterprise call control venders (PBX) complain. So what do we
do? They look at the number of SIP RFC's and the number of ID in the queue
and essentially throw up their hands in frustration. 

The IETF process has been successful in several areas, that is not in
dispute here, but given the enormous complexity that SIP ( don't get me
started on 3GPP etc) has become its self evident that a more comprehensive
and unitary approach is necessary which may require a different form of
standardization process that the IETF is not use to.

I might add the issues surrounding DNSSEC and IPv6 have similar problems.

When implementers see IEEE or ITU standards they see a single layer of
standards they know how to program to. It's a real target. 

You are correct in hinting to the fact that IEEE and ITU documents represent
a "profile" or "snapshot" of a standard that may be a work in progress but
not a bizarre collection of documents with no real boundaries on what do I
do today and what do I implement in products.

Eric Berger, Spencer Dawkins and I are struggling with these very issues as
part of the management team in the SIPforum trying to deliver a reasonable
approximation of a interface between a SIP-PBX and a SIP Service Provider
Network. It's not pretty. Often it seems there is a disconnect between the
IETF standards process, the SIPit work in interoperability and the real
desire of real companies to make some money.

The result is the SIP "liquidity" crisis that lies at the heart of this
entire discussion. The SIP standardization process is clogged up and we have
to do something fix the problem.

So what do you do .

A. Realize that there is a problem. ( we are there now ) 

B. I would propose a two hour RAI general meeting in Minneapolis to flush
out the problem we are documenting here and have people be prepared to
declare alternatives. Monday AM is usually good for this kind of meeting.
APPS always does this to great success. 

C. IMHO look at dealing with core SIP issues with the point of view that the
basic SIP-SIMPLE-SIPPING process is not working. Can SIP be reorganized into
..dare I say the word ..."levels" "versions" .

D. Instead of more SIP WG's can we discuss how to consolidate what we have.
Organize the SIP meetings in the IETF to whole day exercises in order to
force consensus.  Yes 9 to 6 etc. 

Ancillary RAI WG can continue as normal. From my perspective Patrik and I
are doing our best to kill off ENUM as fast we can and DRINKS is so narrowly
focused that it won't bother anyone.

>  From: [email-masked] [mailto:[email-masked]] On Behalf Of
>  DRAGE, Keith (Keith)
>  Sent: Monday, October 06, 2008 4:24 PM
>  To: Eric Burger; [email-masked]

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 6 Oct 2008 21:59:06 -0400

>  Eric Burger
>  Sent: Monday, October 06, 2008 9:06 PM
>  To: DRAGE, Keith (Keith)
>  Cc: [email-masked]

A interesting thought but that has huge risks. As it now stands the IETF
probably drives 40% of its revenue from RAI participants dealing with SIP.
That is a wild guess but could be confirmed from the lists in the hands of
the Secretariat. 

IMHO it may be possible to redefine IETF process rules to allow for
different "classes" of protocols that have more self governing rules. The
issue then would then be what would be the more reasonable and more cost
effective course of action. Have SIP go its own way independent of IETF or
within IETF with new rules. Both would require massive organizational issues
to be resolved. 

My guess is that ultimately "we are the IETF" and we can adapt to changing
realities. What we both clearly agree on is the current process is not
serving the larger Internet community wanting to implement SIP based
protocols.

What we both want is some form of predictability in the organization of the
current SIP protocol specifications that enhance and accelerate real
deployment.

And yes while I'm at it ... IMS sucXX.

>  > particular group discussing a particular subject area would probably
>  > be substantially different to yours.
>  >
>  > protocols being small elements of a much larger whole. If we allow
>  > large (and unwieldy) protocols to exist, then we need to adjust or
>  > change the rules to manage them.
>  >
>  > Keith
>  >
>  >
>  >

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 6 Oct 2008 22:03:43 -0400

Like Keith, I'm not so much interested in the question of where the SIP
work should live, but rather what is the proper structure for managing
the SIP work.

If we don't know that, we're not in any position to speculate about
venues.

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
DRAGE, Keith (Keith)
Sent: Monday, October 06, 2008 1:24 PM
To: Eric Burger; [email-masked]
Subject: Re: [RAI] Making RAI work better

Keith

---

From: Dan York <[email-masked]>
Date: Tue, 7 Oct 2008 11:20:54 -0400

I agree with Richard that splitting SIP out into a separate  
organization, while an interesting idea, isn't the right path. Two  
main reasons I see:

- The same people will be involved with the same different (and  
conflicting) agendas, the same requirements, needs, etc. so all we'd  
do is move the problem... and have the additional problems of needing  
to work out a new standards process, gain legitimacy for the new  
organization, figure out an administrative infrastructure to support  
meetings, etc., etc. A lot of work that gets in the way of getting the  
actual standards done.

- The reality is that in so many ways the future of the Internet *is*  
about real-time communication and so all these issues we're sorting  
through within the various SIP related groups do fit within the IETF  
in my view.

My 2 cents,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free