Re: [RAI] Making RAI work better

[Henry Sinnreich <[e-mail]>]

> I do acknowledge
> (as the responsible AD for your document) that unresponsive management
> is a problem in RAI, and that AD sluggishness helps to perpetuate a
> cycle of delay.

The problems with RAI are not due to unresponsive AD, WG chairs or with the
process (discussed at great length - wrong target), but are IMO due to deep
seated technical problems with the content of the RAI work. In no particular
order:

* Adding protocol extensions to meet business plans is not scalable
* The resulting complexity cannot be mastered in ever more words
* It is impossible to know the 100s of RAI RFCs and 100s of RAI I-Ds
* SIP routing and rules "in the network" is just not practical
* There is no machine way of testing and fixing all these new protocols and
extensions "in the network".
(Building such tools would be an admirable charter item for RAI!)
Note that basic SIP works very well all over the world.

We can learn from and use basic software development techniques, if
"services in the network" are replaced with "applications in the endpoints".

* Use strong types of classes, variables, events, etc.
* Have the errors flagged at compile time
* Have the errors flagged at runtime
* Use Integrated Development Environments (IDE) to ease the work
* Even integrate SIP apps with web apps (write me in private if interested)

Conclusion: SIP development has to mimic normal software development and
normal engineering practice:

1. Running code 
2. Testing in the network
3. Report (ample) test results
4. Make the code available for discussion and improvements
5. Folow the e2e, transparency and simplicity principles of the Internet.
We work in the IETF for the Internet  and not for ITU-T networks that are
built on different principles.

There are excellent role models in such places as Columbia University (see
its SIP work) or the Helsinki Institute of Technology (see its P2PSIP/HIP
work). Actually why am I pointing out the obvious?

Because these fundamental changes are unlikely to be accepted.

My two cents anyway,

Henry


On 10/1/08 3:00 AM, "Peterson, Jon" <[e-mail]> wrote:

> 
> Henning,
> 
> Speaking to the portion of this about area management, I do acknowledge
> (as the responsible AD for your document) that unresponsive management
> is a problem in RAI, and that AD sluggishness helps to perpetuate a
> cycle of delay. This is indeed one of the reasons why I'm not seeking
> another term as an AD; some fresh blood and energy should definitely
> help with that.
> 
> At a higher level, I also agree that unnecessary normative dependencies
> are a problem. I actually wrote a draft about reducing normative
> dependencies not too long ago which, I'd say, was met with about equal
> parts of avid support and dismissive hostility. In that document I
> questioned what it even meant for Informational documents to hold
> normative dependencies, and what it meant for a particular piece of text
> in a document to constitute a normative reference. I believe that deep
> obscurities in this area cause us many process headaches.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Henning Schulzrinne
> Sent: Tuesday, September 30, 2008 6:46 PM
> To: Cullen Jennings
> Cc: [e-mail]
> Subject: Re: [RAI] Making RAI work better
> 
> <rant>
> Prioritizing drafts by dependency chains may help. To take an example
> that affects a draft which I'm co-authoring:
> 
> draft-shacham-sipping-session-mobility
> in RFC editor queue since 2008-01-02
> 
> depends on
> draft-ietf-sip-gruu
> in RFC editor queue since 2007-10-15, i.e., almost a year
> 
> depends on
> draft-ietf-sip-outbound
> NOT-RECEIVED
> 
> Unfortunately, the current area management has not responded to
> suggestions to remove incidental dependencies as a second-best option
> when certain documents seem stuck. For example, in our case, the GRUU
> reference is of no great significance (unless GRUU changes drastically
> in the RFC editor queue, none of the details could conceivably
> matter), even more so since the document is informational. The primary
> document has no dependencies on 'outbound', but is "punished" for
> whatever sins are holding up "outbound" in purgatory.
> 
> 3GPP wants to cite the document, but can't, and there's no way for the
> authors to resolve the issue, particularly since repeated requests
> have gone unanswered.
> 
> This is one example, but I suspect others have their own personal
> horror stories. Is it surprising that energy tends to flag given such
> interminable delays and non-responsiveness?
> </rant>
> 
> Henning
> 
> On Sep 30, 2008, at 11:37 AM, Cullen Jennings wrote:
> 
>> 
>> Over the past year or so, Jon and I have heard concerns about the
>> efficiency and organization of the RAI Area. We have both observed
>> that
>> the larger working groups, particularly SIP and SIPPING, continue to
>> have difficulty tackling some of their more complex projects. The more
>> critical a document seems to be from a dependency perspective, the
>> more
>> late surprises seem to emerge in its development and the longer it
>> takes
>> to escape from the working group process. A relatively small number of
>> the working groups in the RAI Area seem to encompass the lion's
>> share of
>> our documents in their scope, which may concentrate too much of our
>> work
>> in too few areas and cause distracting parallelization.
>> 
>> Ultimately, these problems might result from any number of causes.
>> There
>> might be structural problems with the manner the RAI Area is divided
>> into working groups, issues with chartering or focusing of the
>> efforts,
>> snarls intrinsic to the technology, personnel problems at any number
>> of levels, questions of participant energy, or any of a number of
>> combinations thereof.
>> 
>> What we'd like to do is kick off a discussion about ways that we can
>> make RAI work better. As a part of that discussion we are reserving
>> one
>> of our precious timeslots for a RAI Area open meeting in Minneapolis
>> (at
>> least the Friday afternoon experiment will give us one more slot than
>> usual). In order to help set an agenda for that meeting, we'd like to
>> invite any comments and discussion on this list ([e-mail]),
>> or if necessarily in private correspondence to Jon and I. We're
>> interested to learn to what degree people believe there are problems
>> that need to be addressed, and what sorts of problems and potential
>> solutions the community can identify.
>> 
>> Cullen Jennings
>> Jon Peterson
>> RAI Area Directors
>> _______________________________________________
>> RAI mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rai
> 
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai

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