Subject: [RAI] Status: RAI Review Directorate

From: "Mary Barnes" <[email-masked]>
Date: Tue, 2 Oct 2007 14:49:13 -0500

Hi folks, 

I just wanted to let folks know that the review team is now active with
two assignments, one a cross area request from TSVWG and another which
is a new WG document in SIPPING. I'm tracking the assignments in this
simple spreadsheet format for now:
http://www.softarmor.com/rai/art/rai-art.html

I did tidy up some errors in links in the guidelines and updated the
reviewer list per suggestions.

Thanks,
Mary.

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Monday, September 24, 2007 2:41 PM
To: [email-masked]
Cc: Jon Peterson; Barnes, Mary (RICH2:AR00)
Subject: Announcement of RAI Review Directorate

Hi All,

After many discussions we have formed an RAI area review team. You can
read more about it at the links below but at a high level the goal of
this is to provide a resource that chairs can use when they feel
additional review would be beneficial - typically around the time a
document was adopted as a WG item. It does not change the process in any
way and it's not something that has to be done for every document - it's
just a resource to use when it can help.

Have a read of links provided and many thanks to Mary Barnes.

Guidelines at http://www.softarmor.com/rai/art/review-guidelines.html

FAQ at http://www.softarmor.com/rai/art/FAQ.html

Members at http://www.softarmor.com/rai/art/rai-reviewer-list.html

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 3 Oct 2007 09:06:12 -0700

The RAI review guidelines should IMHO be improved with an essential
ingredient:

Require the clear separation of concept papers from I-D based on running
code and deployment experience and give I-D based on running code
preference for promoting to WG items.

Lack of running code and deployment experience is probably the cause of
the failure of SIMPLE to compete effectively with XMPP and also why we
use the Jabber IM in the SIMPLE meetings! 

The paper here below should be a wake-up call for avoiding similar
mistakes: _Declaring concept papers as valid WG items or even valid
standards_ is a failure of the IETF process that can be avoided at least
in RAI. 
ICE and several I-D on P2PSIP are next in line I suppose. 

Please read this:

http://www.xmpp.org/internet-drafts/draft-saintandre-xmpp-presence-analy
sis-01.html  

"this analysis indicates that XMPP requires only about 1.5% of the
bandwidth required by SIMPLE"

If there is interest, I would be glad to contribute to editing the text
for RAI review guidelines.

The XMPP paper above should also be discussed on the SIMPLE WG list. If
the conclusions of this paper are accurate, SIMPLE has a big problem to
address.

I have taken therefore the liberty to copy the authors of the I-D on
Presence Scaling Analysis - a truly excellent paper and model for a
realistic I-D.

Thanks, Henry

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 3 Oct 2007 15:21:36 -0500

Henry,

I'm not sure I fully understand the issue you are trying to raise. Are
you saying that running code confers an extra level of verification that
the concept is sound and that's why it should get preference, or that
running code may indicate better interoperability testing having been
done or perhaps something else here that I'm just not catching?

My concern would be that such a guideline could be used to justify
adopting I-D's based off of legacy non-IETF architectures that have
insurmountable amounts of running code or deployment experience over
I-D's trying to create similar functionality using IETF protocols where
the author is simply ahead of the market in terms of finding someone who
is willing and able to put up resources to write code. 

For example, I can see advocates for reproducing the PSTN in SIP (where
we may have decades of experience and thousands of devices running code)
using such a guideline to justify why tunneling ISUP through SIP is
better than properly extending SIP to do the job more appropriately to
how SIP is intended to work.

I agree that deployment experience is extraordinarily valuable, but I'm
not sure it's the most important criteria in all cases. I understand
your point with respect to SIMPLE, but what about the above scenario?

Cheers,
Brian

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Wednesday, October 03, 2007 11:06 AM
> To: Barnes, Mary (RICH2:AR00); Cullen Jennings; 
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Edwin Aoki
> Subject: [RAI] RAI Review Guidelines and Presence Scaling Analysis
> 
> Require the clear separation of concept papers from I-D based 
> on running code and deployment experience and give I-D based 
> on running code preference for promoting to WG items.
> 
> Lack of running code and deployment experience is probably 
> the cause of the failure of SIMPLE to compete effectively 
> with XMPP and also why we use the Jabber IM in the SIMPLE meetings! 
> 
> mistakes: _Declaring concept papers as valid WG items or even 
> valid standards_ is a failure of the IETF process that can be 
> avoided at least in RAI. 
> "this analysis indicates that XMPP requires only about 1.5% 
> of the bandwidth required by SIMPLE"
> 
> If there is interest, I would be glad to contribute to 
> editing the text for RAI review guidelines.
> 
> The XMPP paper above should also be discussed on the SIMPLE 
> WG list. If the conclusions of this paper are accurate, 
> SIMPLE has a big problem to address.
> 
> I have taken therefore the liberty to copy the authors of the 
> I-D on Presence Scaling Analysis - a truly excellent paper 
> and model for a realistic I-D.
> 
> Thanks, Henry 
>

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 3 Oct 2007 14:39:19 -0600

Henry,

    It's sometimes harder to write good code than jotting down ideas on
papers for others to review and help improve but good protocol papers
make good code and doing code too early can be detrimental too. 
I'm not sure we could use 'running code' as an element to determine
whether an I-D should become a wg item or not.  There are examples both
ways and it should be up to the wg participants, chairs and ADs.

> > ICE and several I-D on P2PSIP are next in line I suppose.
    ^^^
Re: ICE, see the posting on sip-implementors today about running code.
We'll see more support for ICE as soon as it hits RFC status.

Jean-Francois.

> From: Brian Stucker [mailto:[email-masked]]
> Sent: Wednesday, October 03, 2007 2:22 PM
> To: Henry Sinnreich; Mary Barnes; Cullen Jennings;
> Cc: [email-masked]; [email-masked];
> [email-masked]; Edwin Aoki
> Subject: RE: [RAI] RAI Review Guidelines and Presence Scaling Analysis
> 
> Henry,
>

---

From: Joerg Ott <[email-masked]>
Date: Thu, 04 Oct 2007 15:26:42 +0300

I think one of the things we have observed is that I-Ds have
gotten too far away from implementation -- and once we get
to the implementation we may determine that the direction
was not what is finally needed (wrong, too little, too much).

Anything to keep the creep of stuff at a rate that people (inside
and outside the IETF) can keep track of is probably a useful
thing to think about.  This is not to say that we should demand
running code as a condition, but a couple of years between an
I-D heading for WGLC and a implementation is not acceptable
either.  If people don't implement stuff, they not be as
interested in this as they claim (or it may not be as urgent).
Great.  Then, such items can wait.

That said, I have been reasonably comfortable with ICE in that
respect, as there have been early implementations.

Joerg

>>>http://www.xmpp.org/internet-drafts/draft-saintandre-xmpp-pres
>>
>>ence-analy
>>
>>>sis-01.html
>>>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 4 Oct 2007 03:31:21 -0700

Jean-Francois,

> There are examples both ways and it should be up to the wg
participants, 
> chairs and ADs.

Physical reality and industry acceptance have their own criteria, which
are very different ("this analysis indicates that XMPP requires only
about 1.5%
of the bandwidth required by SIMPLE")

I am still interested in:

1. Is the comparison between XMPP and SIMPLE accurate?

2. If yes, would have running code AND deployment experience +
adjustments made SIMPLE more successful?

3. What do we do about SIMPLE?

4. Can we avoid such experience with ICE and P2PSIP?

Quite frankly, WG processes are not the answer, but rather the problem
here.

Thanks for your attention to my rant. Please just remember the 1.5%
figure and see if it can be addressed by any WG process.
 
If I can help it you will not hear any more from me on this :-) 

Henry

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2007 3:39 PM
To: Brian Stucker; Henry Sinnreich; Mary Barnes; Cullen Jennings;

Henry,

    ^^^

Jean-Francois.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 04 Oct 2007 09:00:44 -0700

> how SIP is intended to work.

Technologies that do not follow the end to end principle, even with tons
of experience and running code, should not be allowed at the IETF. I
think that it is time to have a mandatory section in all I-D/RFC that
explain how the protocol proposed follows the end to end principle.

The running code that is used to validate an I-D should be open.  Open
source mostly does not help for interoperability, but the companies that
push for protocols aimed to destroy the end to end principle generally
loath free/open source, so an I-D promoted by one of this companies will
have less support on the form of running code.

I would like to add also that implementing code for an I-D is difficult,
to say the least.  I just finished my server implementation and was
working on the open source client and Wireshark implementation of
turn-04 when Jonathan Rosenberg announced in the BEHAVE m-l a major
change in the protocol.  It is fine - after all this is the risk of
implementing an I-D - but there should be some kind of incentive for
code authors to do this.  Having a specific section in the I-D/RFC
acknowledging the heroic efforts of early implementers can be a solution.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]

---

From: Robert Sparks <[email-masked]>
Date: Thu, 4 Oct 2007 11:19:05 -0500

> acknowledging the heroic efforts of early implementers can be a  

This is a major point. It's _very_ hard to get early implementations of
the drafts we need them most on, because those are exactly the drafts
that tend to go through multiple _fundamental_ changes.

Once there was a motivation to implement early in order to be ahead
of the curve - first into the market if you will. The pattern we've  
shifted to,
at least in RAI, for spec development has burned the people who have
tried this - much lost time and much lost money. So now, many (most?)  
are
waiting until a spec is completely done to start even playing with  
it. This has
been particularly true for MSRP, TURN, and ICE.

If you believe in the value of the output of these implementations  
(and I do),
acknowledging early efforts might help. Focusing on fewer things at a  
time,
finishing them in a shorter window, and pushing back against fundamental
changes in the end game will help more.

RjS

(Frustrated from being reminded of my _own_ piles of code that had  
the rug
  pulled out from under them).

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 4 Oct 2007 19:38:18 +0200

I understood the RAI review process was to get review across multiple WG
groups in the RAI area where such documents required it, e.g. a document
that covered SIP, AVT, XCON and MMUSIC issues should go their to get
review by experts in all those groups.

Henry, can you tell me how your proposal falls into the RAI review,
rather than in the normal RFC 2026 process?

Regards

Keith

> Sent: Wednesday, October 03, 2007 9:22 PM
> I'm not sure I fully understand the issue you are trying to 
> raise. Are you saying that running code confers an extra 
> level of verification that the concept is sound and that's 
> why it should get preference, or that running code may 
> indicate better interoperability testing having been done or 
> perhaps something else here that I'm just not catching?
> 
> My concern would be that such a guideline could be used to 
> justify adopting I-D's based off of legacy non-IETF 
> architectures that have insurmountable amounts of running 
> code or deployment experience over I-D's trying to create 
> similar functionality using IETF protocols where the author 
> is simply ahead of the market in terms of finding someone who 
> For example, I can see advocates for reproducing the PSTN in 
> SIP (where we may have decades of experience and thousands of 
> devices running code) using such a guideline to justify why 
> tunneling ISUP through SIP is better than properly extending 
> SIP to do the job more appropriately to how SIP is intended to work.
> 
> I agree that deployment experience is extraordinarily 
> valuable, but I'm not sure it's the most important criteria 
> in all cases. I understand your point with respect to SIMPLE, 
> but what about the above scenario?
> 
> Cheers,
> Brian
> 
> 
> 
> > Require the clear separation of concept papers from I-D based on 
> > running code and deployment experience and give I-D based 
> on running 
> > code preference for promoting to WG items.
> > 
> the cause 
> > of the failure of SIMPLE to compete effectively with XMPP 
> and also why 
> > we use the Jabber IM in the SIMPLE meetings!
> > 
> > standards_ is a failure of the IETF process that can be avoided at 
> > least in RAI.
> > If there is interest, I would be glad to contribute to editing the 
> > text for RAI review guidelines.
> > 
> WG list. 
> > If the conclusions of this paper are accurate, SIMPLE has a big 
> > problem to address.
> >

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 4 Oct 2007 10:52:14 -0700

We are in a kind of never-ending cycle.  I would NOT quote chapter and
verse on the process, as we are just building the process.  If it would
be appropriate for RAI reviews to include a demonstration, then we can
fix the process.

It reminds me of the patent office 50+ years ago.  You HAD to bring a
prototype to show the examiner to prove you were not just on a fishing
expedition.

That said, I would not want to either require nor ignore
implementations.  I think the IESG shepherd write-up has it in a good
balance, when they ask, "does this draft have implementation
experience?"

My knee jerk reaction was to give a big, "hear, hear, let's do it
[require implementations]."  However, I, too had Brian's nightmare:
"Well, we have 8 independent implementations of Cisco INFO for DTMF, why
can't we publish?" 

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Thursday, October 04, 2007 1:38 PM
To: Henry Sinnreich; Mary Barnes; Cullen Jennings;

Regards

Keith

> you saying that running code confers an extra level of verification 
> that the concept is sound and that's why it should get preference, or 
> that running code may indicate better interoperability testing having 
> been done or perhaps something else here that I'm just not catching?
> 
> I-D's trying to create similar functionality using IETF protocols 
> where the author is simply ahead of the market in terms of finding 
> someone who is willing and able to put up resources to write code.
> 
> For example, I can see advocates for reproducing the PSTN in SIP 
> (where we may have decades of experience and thousands of devices 
> running code) using such a guideline to justify why tunneling ISUP 
> through SIP is better than properly extending SIP to do the job more 
> appropriately to how SIP is intended to work.
> 
> I agree that deployment experience is extraordinarily valuable, but 
> I'm not sure it's the most important criteria in all cases. I 
> understand your point with respect to SIMPLE, but what about the above

> scenario?

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 4 Oct 2007 12:55:41 -0500

I was going to send something similar, but Keith beat me to it.

While I agree with some points in this discussion in the general  
sense, is this an RAI area review team issue at all? Do we expect the  
review team to second guess the priorities of the various work groups  
after the fact? If the work groups want to emphasize running code, I  
am all for that, but I don't think it is our (the RAI review team)  
problem.

This is not to say that working code should not count towards the  
overall implementation experience that we (try to) bring to bear on  
such reviews

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 4 Oct 2007 14:02:19 -0700

> rather than in the normal RFC 2026 process?

(Since you asked me specifically) Sorry, I cannot, since the process is
broken IMHO, due to the mostly missing running code, measurements on the
network and tweaking of the protocols before accepting a RAI area work
item and then publishing a standard. This should be the basis for the
RAI process.

The present process is the problem, not the answer or substitute for
measurements from deployments.

I have nothing more to add to the RAI process discussion.

Ben and Keith, getting back to what started this discussion: Can we hope
to see the SIMPLE-XMPP (the 1.5% claim) questions addressed instead of
discussing the process? This is a real problem for SIMPLE and setting
the facts straight would help. 

http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-presence-analy
sis-01.txt 

There are other similar issues with NAT traversal and p2p, but please
help me avoid them :-)

Henry

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Thursday, October 04, 2007 12:56 PM
To: DRAGE, Keith (Keith)
Cc: Henry Sinnreich; Mary Barnes; Cullen Jennings;
[email-masked]; [email-masked]
Subject: Re: [RAI] RAI Review Guidelines and Presence Scaling Analysis

---

From: Eric Burger <[email-masked]>
Date: Thu, 04 Oct 2007 20:40:49 -0400

I would offer a discussion of the bloat, lack of traction, "made for SBC's
and Proxies and not end-to-end networks," and technical problems with SIMPLE
belongs on the SIMPLE list.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 4 Oct 2007 18:25:28 -0700

Eric,

You are right and your reminder about end-to-end should be on the RAI
process checklist as well, actually right on top. 
Otherwise the reincarnations of the IN and the AIN will permeate even
more the IETF RAI area work.

Henry

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Thursday, October 04, 2007 7:41 PM
To: Henry Sinnreich
Cc: [email-masked]
Subject: Re: [RAI] RAI Review Guidelines and Presence Scaling Analysis

I would offer a discussion of the bloat, lack of traction, "made for
SBC's
and Proxies and not end-to-end networks," and technical problems with
SIMPLE
belongs on the SIMPLE list.

>>>> Presence Scaling Analysis - a truly excellent paper and model for a

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 4 Oct 2007 22:00:36 -0400

Can you define what an "end" is, and where it is?
-hadriel

> Sent: Thursday, October 04, 2007 9:25 PM
> To: Eric Burger
> Cc: [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 04 Oct 2007 21:51:49 -0700

I'm finding this confusing as well.

Maybe some examples would help. Is DNS a violation of end-to-end?
How about RFC 2821/2822-style e-mail? XMPP?

Thanks,
-Ekr

At Thu, 4 Oct 2007 22:00:36 -0400,

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 4 Oct 2007 22:44:13 -0700

TURN?

-d

> From: Eric Rescorla [mailto:[email-masked]] 
> Sent: Thursday, October 04, 2007 9:52 PM
> To: Hadriel Kaplan
> Cc: Henry Sinnreich; [email-masked]

---

From: Avshalom Houri <[email-masked]>
Date: Fri, 5 Oct 2007 09:34:59 +0200

Henry,

Few points:

* The issue with SIMPLE  is more regarding large scale deployments that 
are
used by real users so we will be able to know how much of the RPID
attributes will be used, what will be the frequency of updates etc.
There are already several even commercial implementations of SIMPLE
but we still lack the big deployments.

* As I posted to the SIMPLE list see section 2.10 in
http://www.nostrum.com/~rjsparks/draft-ietf-simple-interdomain-scaling-analysis-02.txt
.
The section compares one use case of SIMPLE and an extremely bandwidth 
saving
protocol and it gets a saving of about a half. XMPP analysis is assuming
a very small presence document and hence the very small
bandwidth compared to SIMPLE.

* A lot of the complexity of SIP is coming from being end to
end, support of UDP etc. Are we willing to give that up?

* Note that the document that is published in the IETF is
http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-01.txt
that has a calculation error that was found by Wilkins.
More correct one is in:
http://www.nostrum.com/~rjsparks/draft-ietf-simple-interdomain-scaling-analysis-02.txt
.
I should have published a new version while ago but I was dragged
into other issues and was getting some real life numbers
from real life non SIP deployments that I will include in the -02
version of the document. I will also include some calculations
that will use the most minimal PIDF document and see what will be
the difference.

Thanks
--Avshalom

"Henry Sinnreich" <[email-masked]> wrote on 04/10/2007 12:31:21:

> > that
> > where
> > (where
> > I'm

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 5 Oct 2007 09:35:45 +0100

----- Original Message From: "Henry Sinnreich"

> item and then publishing a standard. This should be the basis for the

I think if you insisted on that much implementation (and by requiring 
measurements on the network you're almost asking for a deployed solution 
with real customers before it became a working group draft) then people will 
have committed so much to a solution, that they wouldn't be prepared to 
compromise when working towards an RFC.  You'd then end up in the same 
situation as one of the IEEE wireless solutions (Motorola camp vs. TI camp I 
think).

I also think another problem in the RAI area is that people outside suggest 
ideas, and then some one/some group within RAI say that's not the way to do 
it, it should be done like this.  However, rather than work with the 
original proposers, they produce a counter proposal (which is admittedly 
often better), so the original proposers lose any sense of control over the 
process and the motivation to push implementation fades.  After a few 
quarters, and often after seeing their work re-focussed into something 
that's not really addressing their needs, they probably end up just doing 
something proprietary.

my 2 cents.

Pete.
--
=============================================
Pete Cordell
Codalogic
for XML Schema to C++ data binding visit
 http://www.codalogic.com/lmx/
=============================================

----- Original Message ----- 
From: "Henry Sinnreich" <[email-masked]>
To: "Ben Campbell" <[email-masked]>; "DRAGE, Keith (Keith)" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 04, 2007 10:02 PM
Subject: RE: [RAI] RAI Review Guidelines and Presence Scaling Analysis

Henry

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 5 Oct 2007 04:38:10 -0700

Thanks Avshalom! 
This is very helpful.

➢ getting some real life numbers 
> that will use the most minimal PIDF document and see what will be 

This will be no doubt a very interesting and important document.

Henry

________________________________________
From: Avshalom Houri [mailto:[email-masked]] 
Sent: Friday, October 05, 2007 2:35 AM
To: Henry Sinnreich
Cc: Edwin Aoki; Brian Stucker; Cullen Jennings; [email-masked]; Jean-Francois Mule; [email-masked]; Mary Barnes; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [RAI] RAI Review Guidelines and Presence Scaling Analysis

Henry, 

Few points: 

* The issue with SIMPLE  is more regarding large scale deployments that are 

* As I posted to the SIMPLE list see section 2.10 in 
http://www.nostrum.com/~rjsparks/draft-ietf-simple-interdomain-scaling-analysis-02.txt. 
The section compares one use case of SIMPLE and an extremely bandwidth saving 
protocol and it gets a saving of about a half. XMPP analysis is assuming 
a very small presence document and hence the very small 
bandwidth compared to SIMPLE. 

http://www.nostrum.com/~rjsparks/draft-ietf-simple-interdomain-scaling-analysis-02.txt. 

Thanks 
--Avshalom

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 05 Oct 2007 08:32:29 -0700

It is annoying to see how quickly discussions about the end to end
principle degenerate.  It is the principle on which the Internet was
created, so I see it as the Constitution of the Internet.  Discussions
should be on how IETF protocols interpret and apply the e2e principle,
not if the e2e is relevant or not for the Internet. because it is, by
definition.

http://www.isoc.org/members/codeconduct.shtml
http://isoc.org/pubpolpillar/principles.shtml
http://www.reed.com/Papers/EndtoEnd.html
http://www.faqs.org/rfcs/rfc3724.html
ftp://ftp.rfc-editor.org/in-notes/rfc4924.txt

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 5 Oct 2007 13:20:44 -0700

I have changed the Subject here to e2e since this is a different topic
from developing protocols based on running code and measurements from
deployments.

> Maybe some examples would help.

It would be helpful to understand how work such as for example in
SPEERMINT, private ENUM or walled garden oriented SIPPING drafts (take
your pick from many) are aligned with the Internet Transparency, just
recently updated in RFC 4924 issued by the IAB.
ftp://ftp.rfc-editor.org/in-notes/rfc4924.txt 

ENUM is an especially interesting example of walled garden focus, since
besides the "private ENUM" topic and the legacy telephone numbering
system (as if the web would not exist), there are other Internet naming
and routing schemas such as HIP (as proposed in P2PSIP) and name based
routing such as NUTSS that is architecturally placed in at the
application level belonging to RAI. As for phone numbers, silly me,
thinking I can click on an Internet presence icon instead of fumbling
for phone numbers!

Since IETF folks even ask about it [Can you define what an "end" is, and
where it is?"] there is clearly an urgent requirement for the RAI to:

- Explain and uphold the e2e principle on the RAI web pages,
- Request I-D authors to explain how they support e2e, similar to
security,
- Recommend work benefiting walled gardens to be performed in the ITU-T
or other organizations that support this business.

IETF resources and expertise must not be spent for the benefit of walled
gardens but for the open, e2e based Internet.

Maybe I have missed it, but would like to be pointed to the RAI
guidelines in support of e2e. This discussion shows I am not the only
one to have missed RAI guidelines on support for e2e.

In conclusion: Can RAI have guidelines on e2e and review the papers
accordingly? Just yes/no can make it clear; maybe even a "how" to get it
right.

Thanks to all for contributing to this discussion on RAI support for
e2e.

Henry

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Friday, October 05, 2007 12:44 AM
To: 'Eric Rescorla'; 'Hadriel Kaplan'
Cc: Henry Sinnreich; [email-masked]
Subject: RE: [RAI] RAI Review Guidelines and Presence Scaling Analysis

TURN?

-d

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 5 Oct 2007 22:45:37 +0200

> explain how the protocol proposed follows the end to end principle.

<snark>

Ah, ideological purity ueber alles. You should get that put in the 
"Note Well" sheet: "I pledge fealty to the end-to-end principle and
will hold high its banner even in the most dire and absurd
circumstances. I will never succumb the temptations of the real word
such as applicability, chance of adoption, or complexity."

</snark>

Seriously: yes, it could be a good idea to have next to the mandatory
"IANA Considerations" sections also sections devoted to 

* End-to-end: How this draft fulfills it or a clear argument why it has
  to deviate from the lofty ideal.

* Implementation: Has the protocol described in the draft been
  implemented, and if yes, is the code available as open source?

Blanket statements are always a bad idea, though. 

/ol (who provided code for his drafts in speermint)
-- 
/ Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 5 Oct 2007 23:10:47 +0200

>"IANA Considerations" sections also sections devoted to
?
>  implemented, and if yes, is the code available as open source?

OK, I like the idea
 
this will reduce the amount of I-Ds from 3GPP and IMS
significantly
 
Richard

---

From: Eric Burger <[email-masked]>
Date: Fri, 05 Oct 2007 17:31:22 -0400

1. Has it been implemented: Awesome idea - proof point

2. Is it open source: that is nice, but absolutely, positively, NOT worth
the licensing issues.

What we care about is unencumbered by IPR, or protected by IPR with a
Royalty Free license.  Open source is worse than useless if it tramples on
someone else's IPR.

I'd also suggest moving this entire conversation to the IETF list.  For one
thing, the S/N ratio over there is already below 0.1, so this stuff will not
impact that list as much.  For another, none of this stuff is RAI specific.
It just happens that (IMHO) RAI produces more encumbered / research projects
with no reality / non-Internet protocols than the other area directorates.

Not a ding on our AD's: they inherited this mess.

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 5 Oct 2007 18:22:51 -0400

I think the RAI Area and its constituent groups have always been committed to the e2e model and to Internet transparency. Like any other part of the IETF, I think our groups also reflect a diverse marketplace in which there are many divergent ideas about how applications and services might be deployed. We have always tried to optimize for the specification of implementations that would, under all circumstances, be compatible with an open and unrestricted network, even if such implementations are additionally capable of detecting and operating in networks where less desirable conditions apply.

SPEERMINT exists because we believe it is possible to deploy the "edge" features desired by service providers in a non-intrusive manner, preserving the e2e properties of SIP. SPEERMINT attempts to demonstrate this to the marketplace, in the hopes that this will make SIP more robust, compatible, and secure in its use across the Internet. This does not, in my opinion, facilitate the rise of walled garden networks - instead it benefits both the users within walled gardens and those outside who hope to communication with them. In order to demonstrate this, SPEERMINT needs to explore and address requirements in a language likely to persuade service providers. If it cannot do this, then the work cannot complete its chartered goals.

While I do think it is necessary for RAI reviewers to be mindful of the e2e model and Internet transparency, I think a review of a SPEERMINT document along the lines of, "Well, this document talks about service providers and SBCs and edges, so it should be rewritten to describe voice as just an application running over an agnostic bit pipe" just isn't salient, even if it happens to be true. 

Nor do I think it is the place of every SPEERMINT document to defend SPEERMINT's charter in an "e2e considerations" section or what have you. I completely agree that if our specifications produce endpoints that no longer operate well on the public Internet, then we've lost sight of the big picture. But I don't think that specifications that talk about ways in which our endpoints could -also- work in non-transparent environments should be bounced by RAI reviewers on those grounds. If anyone would like to take a stab at guidelines that capture this, I'm sure it would be useful going forward.

Jon Peterson
NeuStar, Inc.

> Sent: Friday, October 05, 2007 1:21 PM
> To: Dan Wing; Eric Rescorla; Hadriel Kaplan
> Cc: [email-masked]
> Subject: [RAI] RAI guidelines for e2e
> 
>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 5 Oct 2007 15:26:07 -0700

Eric,

Moving the e2e discussion to the IETF list is a great idea, but someone
(you?) has to start there with a summary of the issues discussed here.

Still, RAI needs to give clear guidance on e2e.

I would leave OS and IP out for now, just for focus and clarity.

Henry

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Friday, October 05, 2007 4:31 PM
To: Richard Stastny; [email-masked]
Subject: Re: [RAI] RAI Review Guidelines and Presence Scaling Analysis

2. Is it open source: that is nice, but absolutely, positively, NOT
worth
the licensing issues.

What we care about is unencumbered by IPR, or protected by IPR with a
Royalty Free license.  Open source is worse than useless if it tramples
on
someone else's IPR.

I'd also suggest moving this entire conversation to the IETF list.  For
one
thing, the S/N ratio over there is already below 0.1, so this stuff will
not
impact that list as much.  For another, none of this stuff is RAI
specific.
It just happens that (IMHO) RAI produces more encumbered / research
projects
with no reality / non-Internet protocols than the other area
directorates.

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 5 Oct 2007 17:40:12 -0500

Henry,

The RAI review guidelines:
http://www.softarmor.com/rai/art/review-guidelines.html
do currently recommend reviewing for applicability some of the more
general Internet Architecture documents, such as 
http://www.ietf.org/rfc/rfc3439.txt
which does have a section on 2.1. entitled "The End-to-End Argument and
Simplicity".  

We can certainly add RFC4924 to the list of general recommendations to
consider when doing reviews.  It was not on the list for other review
teams since it's a new RFC.   However, I don't think one can suggest
that the guidelines have totally left out the concept because that
document is missing. 

I can't speak for SPEERMINT or ENUM, but your concern about SIPPING
seems to be targetted at ftp://ftp.rfc-editor.org/in-notes/rfc3427.txt
which does allow for this whole process of P-headers, which are
typically applicable to the walled garden situations you mention.  The
documents defining P-headers are not SIPPING WG documents nor are they
endorsed by the WG.  They are only ever published as Informational and
they are progressed as individual AD sponsored documents. We do require
an "expert" review of those documents to ensure that they don't violate
the guidelines set out in RFC 3427, which did follow the normal IETF
review process and went through IETF Last call in July of 2002.  So, you
are correct, in that there is some IETF effort to support these
activities, but the alternative of the other SDOs defining new SIP
headers without any guidance from IETF at all was not deemed desireable
at the time.   I don't think we have any SIPPING WG documents that are
explicitly for walled gardens. We do have documents that allow for
involvement of some elements in the network (beyond Proxies, which IMHO
can be viewed in the purest sense to break the e2e principle), but I
don't recall anyone raising concerns about those breaking the end-to-end
principle in the past - they are enablers for endpoints that don't
support some of the more complex functionality and they are required to
follow fundamental SIP protocol rules.  

So, can you please be more explicit about what work with RAI has
progressed or is underway (other than P-headers) that violates the e2e
guidelines?   Or, are you suggesting we should Obsolete RFC 3427 and let
the other SDOs define whatever they want in terms of SIP headers?  

Thanks,
Mary. 

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Friday, October 05, 2007 3:21 PM
To: Dan Wing; Eric Rescorla; Hadriel Kaplan
Cc: [email-masked]
Subject: [RAI] RAI guidelines for e2e

Henry

-----Original Message-----
From: Dan Wing [mailto:[email-masked]]
Sent: Friday, October 05, 2007 12:44 AM
To: 'Eric Rescorla'; 'Hadriel Kaplan'
Cc: Henry Sinnreich; [email-masked]
Subject: RE: [RAI] RAI Review Guidelines and Presence Scaling Analysis

TURN?

-d

---

From: Dean Willis <[email-masked]>
Date: Fri, 5 Oct 2007 21:24:37 -0500

> Royalty Free license.  Open source is worse than useless if it  

Folks, there's not a thing we've done in years that isn't totally  
encumbered by IPR. Witness the Verizon/Vonage and Sprint/Vonage cases  
for examples "close to home". If you think something is not  
encumbered and you haven't personally patented and declared every  
aspect of it, rest assured it's encumbered. And if you just THINK  
you've patented every aspect of it, chances are somebody else filed a  
divisional within seconds of your applications going public, so there  
are key bits of your invention that somebody has filed claims on. And  
it's about to get even harder to deal with when the US switches to a  
"first to file" system, as opposed to "first to invent". You could  
have had something in production for a year or more before somebody  
else patents it and shuts you down.

The US patent system is totally broken -- I swear I could take a  
picture of what my dog produces on our nightly walk and get it  
patented. Europe's only a little better.

I lost count at over 1,000 SIP-specific patent applications and  
stopped trying to track things. Now I just grind out patent  
applications (often, very good patent applications -- oddly enough,  
I'm pretty good at it) for people with money, because the only way to  
exist in this sort of system is to get paid for the insanity. There's  
no "opt out".

Write your congressman, chain yourself to the courthouse, but don't  
waste time trying to make standards that are IPR free. It just isn't  
going to be productive.

--
Dean

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 8 Oct 2007 11:39:55 +0100

> or other organizations that support this business.

My recommendation would be to keep your friends close and your enemies even
closer!

Pushing it away to somewhere else won't stop it happening, but will remove
the IETF's opportunity to influence the work.  The IETF would then miss out
on the chance to make it more general, and the SIP space would become more
fragmented.  (I agree that the IETF shouldn't just rubber stamp walled
garden solutions though.)

Let's face it, if there's enough demand from people interested in walled
garden solutions, they can just set up their own SDO.  The significance of a
standard is not which organisation specifies it, but how many people agree
to adopt it.

That makes 4 cents now!

Pete.
--
=============================================
Pete Cordell
Codalogic
XML Schema to C++ data binding
=============================================

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 8 Oct 2007 05:03:35 -0700

Mary and Jon,

Your attached comments show indeed the reflection in the RAI guidelines
of the architectural principles of the Internet and included there is
also e2e.

Some small but critical improvements are however suggested.

1. Updated list of IAB documents

Add to "The review may also consider the applicability of the following
generally agreed IETF criteria as appropriate:" the more recent RFC 4924
"Reflections on Internet Transparency"
ftp://ftp.rfc-editor.org/in-notes/rfc4924.txt 

2. Accurate labeling for "truth in advertising" and relevant RFCs

>But I don't think that specifications that talk about ways in which our
>endpoints could -also- work in non-transparent environments should be
>bounced by RAI reviewers on those grounds.

Fully agree, I-D reflecting non-transparent environment should not be
bounced but should be encouraged to support accurate labeling, such as
is recommended for example in RFC 4084 "Terminology for Describing
Internet Connectivity"
ftp://ftp.rfc-editor.org/in-notes/rfc4084.txt 

Besides accurate labeling, RAI documents should also discuss the
compliance with relevant RFCs. An excellent role model is the ICE I-D
where IAB considerations are discussed in detail in section 22;
including on how RFC 3424 on UNSAF is met.

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-mmusic-ice-
18.txt 

ENUM documents would be made more interesting by discussing the existing
and proposed new Internet and web naming and addressing schemas what the
benefit to RAI area applications may be (compare DNS usage, HIP, NUTSS,
p2p namespaces). Or just leave ENUM to IP-TDM gateway services (where I
think it belongs)? 

Why insisting on e2e?

The success of the Internet and many Internet businesses, including
endpoint application developers depend on it, as well as the whole
Internet economy. Accurate labeling and referral to relevant IAB and
other RFCs will improve the RAI review guidelines.

The discussions on this list have shown mixed opinions, so the
clarifications suggested here seem to be required indeed.

My two cents,

Henry

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Friday, October 05, 2007 5:40 PM
To: Henry Sinnreich; Dan Wing; Eric Rescorla; Hadriel Kaplan
Cc: [email-masked]
Subject: RE: [RAI] RAI guidelines for e2e

Henry,

Thanks,
Mary. 

From: Peterson, Jon [[email-masked]]
Sent: Friday, October 05, 2007 5:23 PM
To: Henry Sinnreich; Dan Wing; Eric Rescorla; Hadriel Kaplan
Cc: [email-masked]
Subject: RE: [RAI] RAI guidelines for e2e

I think the RAI Area and its constituent groups have always been
committed to the e2e model and to Internet transparency. Like any other
part of the IETF, I think our groups also reflect a diverse marketplace
in which there are many divergent ideas about how applications and
services might be deployed. We have always tried to optimize for the
specification of implementations that would, under all circumstances, be
compatible with an open and unrestricted network, even if such
implementations are additionally capable of detecting and operating in
networks where less desirable conditions apply.

SPEERMINT exists because we believe it is possible to deploy the "edge"
features desired by service providers in a non-intrusive manner,
preserving the e2e properties of SIP. SPEERMINT attempts to demonstrate
this to the marketplace, in the hopes that this will make SIP more
robust, compatible, and secure in its use across the Internet. This does
not, in my opinion, facilitate the rise of walled garden networks -
instead it benefits both the users within walled gardens and those
outside who hope to communication with them. In order to demonstrate
this, SPEERMINT needs to explore and address requirements in a language
likely to persuade service providers. If it cannot do this, then the
work cannot complete its chartered goals.

While I do think it is necessary for RAI reviewers to be mindful of the
e2e model and Internet transparency, I think a review of a SPEERMINT
document along the lines of, "Well, this document talks about service
providers and SBCs and edges, so it should be rewritten to describe
voice as just an application running over an agnostic bit pipe" just
isn't salient, even if it happens to be true. 

Nor do I think it is the place of every SPEERMINT document to defend
SPEERMINT's charter in an "e2e considerations" section or what have you.
I completely agree that if our specifications produce endpoints that no
longer operate well on the public Internet, then we've lost sight of the
big picture. But I don't think that specifications that talk about ways
in which our endpoints could -also- work in non-transparent environments
should be bounced by RAI reviewers on those grounds. If anyone would
like to take a stab at guidelines that capture this, I'm sure it would
be useful going forward.

Jon Peterson
NeuStar, Inc.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 9 Oct 2007 13:17:56 -0500

> 1. Has it been implemented: Awesome idea - proof point

This information is asked for in the document shepherding writeup  
and, if given, becomes part of the approval announcement of a draft.  
See the "document quality" section at the very bottom of http:// 
www.ietf.org/IESG/content/Doc-Writeup.html.

I do agree that shepherds should be more diligent about writing up  
implementation information though.

Lars

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 11 Oct 2007 06:12:18 +0200

Fine, but first we have to have the information.

For the documents I have shepherded, I have gone through the mail lists
and would have noted any information people have disclosed about
implementation. Sometimes I have even asked. I do check SIPIT output.

Usually I end up with very little to say - and that is what I report.

Keith 

> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Tuesday, October 09, 2007 7:18 PM
> To: ext Eric Burger
> Cc: Richard Stastny; [email-masked]
> This information is asked for in the document shepherding 
> writeup and, if given, becomes part of the approval 
> announcement of a draft.  
> See the "document quality" section at the very bottom of 
> http:// www.ietf.org/IESG/content/Doc-Writeup.html.
> 
> I do agree that shepherds should be more diligent about 
> writing up implementation information though.
> 
> Lars
>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 11 Oct 2007 06:52:01 -0700

There is still the open issue of clear labeling, as required of any
product:

- Internet e2e support or support for walled gardens?
- Concept paper or a tested protocol?

As discussed, both the authors and the reviewers can address this.

The lack of guidelines for stating these attributes indicates the need
of fixing the guidelines, not that such attributes can be glossed over. 

Thanks, Henry

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Wednesday, October 10, 2007 11:12 PM
To: Lars Eggert; ext Eric Burger
Cc: Richard Stastny; [email-masked]
Subject: RE: [RAI] RAI Review Guidelines and Presence Scaling Analysis

Keith

---

From: <[email-masked]>
Date: Thu, 11 Oct 2007 17:04:59 +0300

Hi,

I've followed the threads on the RAI list related to lack of
implementation and deployment feedback to the standards development.
Listening to folks inside Nokia who are trying to get our SIP clients
work in real deployments, I have also gotten a feeling that there are
indeed various challenges with lot of the standards that we have already
completed. For instance people are still complaning about basic things
such as SDP offer/answer, Record-Routing and so on. SBCs seem to cause
new problems at the same rate as they solve old ones. Also, having e.g.
video calls work between different vendors has not been demonstrated too
often. Then there are performance/feasibility issues like with SigComp.
With SIMPLE the dilemma seems to be that it is very hard to find any
standards-compliant implementations *at all* (there are some examples
like OpenXCAP, fortunately). With ICE there is a lot of implementation
activity, but at the moment people still support various different
(draft) versions, so in practice things don't yet work too well. 

I know that there are many organizations, most notably SIP Forum (SIPit)
who work on practical SIP interoperability issues. (OMA arranges their
own events but they are closed and the findings are confidential.)
However, I'm not sure if we really hear the real *deployment* feedback
in the IETF as much as we should. I wonder if it would make sense to
arrange a special session (formal/informal BOF) where people could share
their experiences with SIP deployments and the interoperability of
various features. Why not have the SIPit report by Robert in that
session as well. We could call it SIPREAL BOF :-) That could work as one
input channel from the deployment community to the IETF. We do have WGs
like BLISS and SPEERMINT that to some extent are operating in this area,
but with a narrow and pre-defined charter.

Any interest?

Markus

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 11 Oct 2007 07:50:00 -0700

I plan to attend the SIPREAL BOF.

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 11, 2007 9:05 AM
To: [email-masked]
Subject: [RAI] SIP interoperability experiences BOF

Hi,

Any interest?

Markus

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 11 Oct 2007 11:26:39 -0400

A student in my group (Archana Rao) has been doing systematic tests  
to discover SIP interoperability issues. Unfortunately, there are  
many and fairly basic ones. For example, digest authorization  
routinely fails and ACKs don't get send to the right place. We plan  
to put up a set of web pages soon that document these issues, trying  
a bit of public shaming, as these are shipping products. (SIPit  
intentionally addresses pre-GA products, so confidentiality makes  
sense there.)

I think a "common gotchas" document would be helpful as an outcome.

Henning

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 11 Oct 2007 11:41:18 -0500

Hi, Henning,

>A student in my group (Archana Rao) has been doing systematic tests  to 
>discover SIP interoperability issues. Unfortunately, there are  many and 
>fairly basic ones. For example, digest authorization  routinely fails and 
>ACKs don't get send to the right place. We plan  to put up a set of web 
>pages soon that document these issues, trying  a bit of public shaming, as 
>these are shipping products. (SIPit  intentionally addresses pre-GA 
>products, so confidentiality makes  sense there.)
>

FWIW, TSV did this for TCP with TCPIMPL ("TCP Implementation"), back in the 
day.

Details at http://www.ietf.org/html.charters/OLD/tcpimpl-charter.html, but 
especially

http://www.ietf.org/rfc/rfc2525.txt

and

http://www.ietf.org/rfc/rfc2923.txt

I saw TCPIMPL as a good thing, and could see doing the same for SIP as a 
good thing (especially if it did not detract from SIP/SIPPING work unless 
problems required specification changes).

Thanks,

Spencer, who would love to see a SIPSURREAL BOF, just for the comic relief. 
Or has that one already happened?

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 11 Oct 2007 13:43:54 -0500

Henning,

Not sure that public shaming is the best approach. It could have a
chilling effect on people to 'fess up' to their implementation
strategies in other forums such as BLISS.

If you were to publish such material you might wish to pre-notify the
parties involved to give them a chance at legitimate rebuttal: issue may
already be fixed in a newer software/firmware release, already aware of
it, configuration error, inconsistency may have been triggered by
customer request (this actually does happen) or due to common
interworking requirement with another broken implementation, etc.

After a reasonable period of time has passed, if folks haven't
responded, etc, then publishing the results could be useful. 

In either case, naming names isn't a prerequisite to creation of a
common problems document, so one activity need not gate the other.

I know forking and offer/answer really seem to confuse implementors
because you can get pretty far with a constrained implementation set
without realizing it, but we already have a document for the latter to
help clarify what has been said in the past.

Regards,
Brian

P.S. If you find something with one of our products in your testing let
me know and I'll do my best to convince the appropriate development
group to address the problem.

> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Thursday, October 11, 2007 10:27 AM
> To: Henry Sinnreich
> Cc: [email-masked]; [email-masked]
> Subject: Re: [RAI] SIP interoperability experiences BOF
> 
> A student in my group (Archana Rao) has been doing systematic 
> tests to discover SIP interoperability issues. Unfortunately, 
> there are many and fairly basic ones. For example, digest 
> authorization routinely fails and ACKs don't get send to the 
> right place. We plan to put up a set of web pages soon that 
> document these issues, trying a bit of public shaming, as 
> these are shipping products. (SIPit intentionally addresses 
> pre-GA products, so confidentiality makes sense there.)
> 
> > indeed various challenges with lot of the standards that we have 
> > already completed. For instance people are still complaning about 
> > basic things such as SDP offer/answer, Record-Routing and 
> so on. SBCs 
> > seem to cause new problems at the same rate as they solve old ones. 
> > Also, having e.g.
> > video calls work between different vendors has not been 
> demonstrated 
> > too often. Then there are performance/feasibility issues like with 
> > SigComp.
> > arrange a special session (formal/informal BOF) where people could 
> > share their experiences with SIP deployments and the 
> interoperability 
> > of various features. Why not have the SIPit report by 
> Robert in that 
> > session as well. We could call it SIPREAL BOF :-) That 
> could work as 
> > one input channel from the deployment community to the IETF. We do 
> > have WGs like BLISS and SPEERMINT that to some extent are 
> operating in 
> > this area, but with a narrow and pre-defined charter.
> >
> > Any interest?
> >
> > Markus
> >

---

From: <[email-masked]>
Date: Thu, 11 Oct 2007 22:39:28 +0300

Hi,

I appreciate Brian's concerns but personally I don't think there should
be a problem just publishing the results. Of course one should be
careful with providing the correct details such as correct model
information, software version etc., and exact description of the test
setup. Perhaps the web page should include the possibility for people
such as the vendor to comment the results, for instance indicating in
which future release the problem has been fixed :-)

Regarding BLISS: IMHO, it will succeed or fail depending on whether the
primary (SIP PBX) vendors really do want to get things interoperable, or
just "SIP based". Not much to do with e2e or any other principles...

Markus

>From: ext Brian Stucker [mailto:[email-masked]] 
>Sent: 11 October, 2007 21:44
>To: Henning Schulzrinne; Henry Sinnreich
>Cc: [email-masked]; Isomaki Markus (Nokia-SIR/Espoo)
>Subject: RE: [RAI] SIP interoperability experiences BOF
>
>Henning,
>
>Not sure that public shaming is the best approach. It could 
>have a chilling effect on people to 'fess up' to their 
>implementation strategies in other forums such as BLISS.
>
>If you were to publish such material you might wish to 
>pre-notify the parties involved to give them a chance at 
>legitimate rebuttal: issue may already be fixed in a newer 
>software/firmware release, already aware of it, configuration 
>error, inconsistency may have been triggered by customer 
>request (this actually does happen) or due to common 
>In either case, naming names isn't a prerequisite to creation 
>of a common problems document, so one activity need not gate the other.
>
>I know forking and offer/answer really seem to confuse 
>implementors because you can get pretty far with a constrained 
>implementation set without realizing it, but we already have a 
>document for the latter to help clarify what has been said in the past.
>
>Regards,
>Brian
>
>P.S. If you find something with one of our products in your 
>testing let me know and I'll do my best to convince the 
>appropriate development group to address the problem.
>
>> discover SIP interoperability issues. Unfortunately, there are many 
>> and fairly basic ones. For example, digest authorization routinely 
>> fails and ACKs don't get send to the right place. We plan to 
>put up a 
>> set of web pages soon that document these issues, trying a bit of 
>> public shaming, as these are shipping products. (SIPit intentionally 
>> addresses pre-GA products, so confidentiality makes sense there.)
>>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 11 Oct 2007 15:04:10 -0500

From http://www.ietf.org/meetings/70-cutoff_dates.html

September 4, Tuesday - Working Group and BOF scheduling begins. To 
request a Working Group session, use the 
<https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi>IETF 
Meeting Session Request Tool

October 1, Monday - Cutoff date for requests to schedule Working 
Group meetings and for preliminary BOF proposals to ADs at 17:00 ET 
(21:00 UTC/GMT).

October 22, Monday - Cutoff date for requests to schedule BOFs at 
17:00 ET (21:00 UTC/GMT). To request a BOF, please see instructions 
on <http://www.ietf.org/ietf/1bof-procedures.txt>Requesting a BOF

So, in theory, you'll have to get this done ASAFP and get special 
permission from a supportive RAI AD to get this "just thought of" BOF 
to be scheduled...

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 11 Oct 2007 18:07:43 -0700

Brian,

It is not a matter of shaming implementers or companies, but to get
measurable feedback from deployments on the net when developing a
standard. 
Good examples are SIMPLE and ICE that could be optimized based on
statistics, depending on protocol design and implementation choices.

Common mistakes to avoid are also of interest as well as features that
introduce brittleness.

There is the chance the proposed BOF may be oversubscribed, so make sure
we will have a big room :-)

Henry

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]] 
Sent: Thursday, October 11, 2007 1:44 PM
To: Henning Schulzrinne; Henry Sinnreich
Cc: [email-masked]; [email-masked]
Subject: RE: [RAI] SIP interoperability experiences BOF

Henning,

Regards,
Brian

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 12 Oct 2007 04:59:51 -0500

Don't get me wrong guys, I think this is a great idea overall and I
fully support the BOF. It's just a small tweak to the Henning's proposed
webpage that I was proposing.

Regards,
Brian 

> Sent: Thursday, October 11, 2007 8:08 PM
> To: Stucker, Brian (RICH1:AR00); Henning Schulzrinne
> It is not a matter of shaming implementers or companies, but 
> to get measurable feedback from deployments on the net when 
> developing a standard. 
> Good examples are SIMPLE and ICE that could be optimized 
> based on statistics, depending on protocol design and 
> implementation choices.
> 
> Common mistakes to avoid are also of interest as well as 
> features that introduce brittleness.
> 
> There is the chance the proposed BOF may be oversubscribed, 
> so make sure we will have a big room :-)
> 
> Henry
> 
> After a reasonable period of time has passed, if folks 
> haven't responded, etc, then publishing the results could be useful. 
> 
> implementors because you can get pretty far with a 
> constrained implementation set without realizing it, but we 
> already have a document for the latter to help clarify what 
> has been said in the past.
> 
> Regards,
> Brian
> 
> > fails and ACKs don't get send to the right place. We plan 
> to put up a

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 12 Oct 2007 07:56:56 -0500

From: "James M. Polk" <[email-masked]>

> October 1, Monday - Cutoff date for requests to schedule Working Group 
> meetings and for preliminary BOF proposals to ADs at 17:00 ET (21:00 
> UTC/GMT).
>
> October 22, Monday - Cutoff date for requests to schedule BOFs at 17:00 ET 
> (21:00 UTC/GMT). To request a BOF, please see instructions on 
> <http://www.ietf.org/ietf/1bof-procedures.txt>Requesting a BOF
>

(If this wasn't a misprint, I think I agree with "ASAFP" without asking what 
the "F" stands for, but that's not the point)

> permission from a supportive RAI AD to get this "just thought of" BOF to 
> be scheduled...

OK, just to take the next step...

I believe that it's a matter of public record that the IESG and IAB have not 
reviewed the Vancouver BOF requests yet, but the IESG is trying to make sure 
all the BOF requests for Vancouver have been entered into 
http://www3.tools.ietf.org/bof/trac/wiki (also a matter of public record), 
and when that has happened, the IESG and IAB will review the requests, very 
soon afterwards. It would be Really Good for a SIPREAL BOF request to be 
part of that review, if you think it should happen in Vancouver.

According to the Wiki, there is only one (expected hasn't arrived yet) RAI 
BOF request for IETF 70, and the only IETF 69 RAI BOF request was declined, 
so I would think we'd have headroom in RAI for SIPREAL in Vancouver - but we 
don't want to request late, because there are already a lot of BOF requests 
in other areas (including *5* requests in INT) - this is makes scheduling 
harder for a late request.

Since This is The IETF Where Nothing Happens By Accident, it would be really 
good for two or three people to self-identify and self-organize, to knock 
out a BOF request. If you're willing to work on this, please say so.

Since we are in the DMZ between "please tell us about your BOF request" and 
"sorry, your BOF request is too late for Vancouver", if you're willing to 
work on this, please say so really, really quickly - realistically, by 
Monday, the 16th.

A BOF request seems doable - if nothing else, starting with TCPIMPL's 
charter and s/TCP/SIP/g would give a first draft - but without a BOF 
request, no BOF.

Thanks,

Spencer

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Oct 2007 09:50:51 -0400

Brian,

I'm afraid you are being unreasonable. How do you suppose we should  
contact the vendors? We don't have a large staff and will likely just  
get to talk to some call center employee which will ask for our  
support contract number.  We've tried this once with a large vendor  
and just got the run-around. (We got a version of "We only  
interoperate with company X and Y, so your interoperability problem  
is not likely to be addressed any time soon." I wish I had known this  
before shelling out several tens of thousands of dollars for the  
product.) I have no sympathy for vendors selling defective products;  
the customers deserve to know what they are getting and not every  
customer can run an interoperability test lab. Naturally, we'll  
gladly correct wrong information or include information on when bugs  
will be fixed.

Henning

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 12 Oct 2007 10:36:33 -0500

If you get the run around then game on... Post it. Nothing more that can
be done. I wasn't expecting you to call the main number for the
companies involved anyhow. We've all been going to IETFs for many years
and built up networks of people we can contact work for various vendors,
people who can get past that filter (potentially). I'm just saying it'd
be nice if that network were utilized. 

It's a matter of perception and intent. I doubt people who coded this
stuff intended to produce broken code. SIP is complex, and not everyone
has the benefit of the years of experience with it that we do.

Just a thought.

Regards,
Brian

> Sent: Friday, October 12, 2007 8:51 AM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Henry Sinnreich; [email-masked]; [email-masked]
> I'm afraid you are being unreasonable. How do you suppose we 
> should contact the vendors? We don't have a large staff and 
> will likely just get to talk to some call center employee 
> which will ask for our support contract number.  We've tried 
> this once with a large vendor and just got the run-around. 
> (We got a version of "We only interoperate with company X and 
> Y, so your interoperability problem is not likely to be 
> addressed any time soon." I wish I had known this before 
> shelling out several tens of thousands of dollars for the
> product.) I have no sympathy for vendors selling defective 
> products; the customers deserve to know what they are getting 
> and not every customer can run an interoperability test lab. 
> Naturally, we'll gladly correct wrong information or include 
> information on when bugs will be fixed.
> 
> Henning
> 
> > fully support the BOF. It's just a small tweak to the Henning's 
> > proposed webpage that I was proposing.
> >
> > Regards,
> > Brian
> 
>

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 12 Oct 2007 18:35:10 +0100

Perhaps as part of the SIPREAL working group activity, the chairs could 
solicit contacts for who would be prepared to receive information about 
their company's implementations that were found to have problems.  I imagine 
that it wouldn't be appropriate to make the list too public!

(One concern I'd have about naming and shaming is that it might be easier 
for a vendor to try and sue you for defamation, rather than fix the problem. 
Especially if you had made a mistake!)

Just a thought,

Pete.
--
=============================================
Pete Cordell
Codalogic
XML Schema to C++ data binding
 http://www.codalogic.com/
=============================================

----- Original Message ----- 
From: "Brian Stucker" <[email-masked]>
To: "Henning Schulzrinne" <[email-masked]>
Cc: "Henry Sinnreich" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Friday, October 12, 2007 4:36 PM
Subject: RE: [RAI] SIP interoperability experiences BOF

Just a thought.

Regards,
Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Oct 2007 13:56:22 -0400

Such a list would indeed be very helpful in general. This sounds like  
a role for the SIP Forum, but I'm not sure we should wait for them.

On Oct 12, 2007, at 1:35 PM, Pete Cordell wrote:

> Perhaps as part of the SIPREAL working group activity, the chairs  
> could solicit contacts for who would be prepared to receive  
> information about their company's implementations that were found  
> to have problems.  I imagine that it wouldn't be appropriate to  
> make the list too public!
>
> (One concern I'd have about naming and shaming is that it might be  
> easier for a vendor to try and sue you for defamation, rather than  
> fix the problem. Especially if you had made a mistake!)
>

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 12 Oct 2007 14:06:24 -0500

Maybe I live on a happy planet, but the way this worked in TCPIMPL 
(http://www.ietf.org/html.charters/OLD/tcpimpl-charter.html) was that people 
published TCPDUMP traces that said (using 
http://www.ietf.org/rfc/rfc2525.txt, in Section 2.2)

2.2.

   Name of Problem
      No slow start after retransmission timeout

... deleted down to ....

   Trace file demonstrating it
      Made using tcpdump recording at the sending TCP (A).  No losses
      reported by the packet filter.

   10:40:59.090612 B > A: . ack 357125 win 33580 (DF) [tos 0x8]
   10:40:59.222025 A > B: . 357125:358585(1460) ack 1 win 32768
   10:40:59.868871 A > B: . 357125:358585(1460) ack 1 win 32768
   10:41:00.016641 B > A: . ack 364425 win 33580 (DF) [tos 0x8]
   10:41:00.036709 A > B: . 364425:365885(1460) ack 1 win 32768
   10:41:00.045231 A > B: . 365885:367345(1460) ack 1 win 32768
   10:41:00.053785 A > B: . 367345:368805(1460) ack 1 win 32768
   10:41:00.062426 A > B: . 368805:370265(1460) ack 1 win 32768
   10:41:00.071074 A > B: . 370265:371725(1460) ack 1 win 32768
   10:41:00.079794 A > B: . 371725:373185(1460) ack 1 win 32768
   10:41:00.089304 A > B: . 373185:374645(1460) ack 1 win 32768
   10:41:00.097738 A > B: . 374645:376105(1460) ack 1 win 32768
   10:41:00.106409 A > B: . 376105:377565(1460) ack 1 win 32768
   10:41:00.115024 A > B: . 377565:379025(1460) ack 1 win 32768
   10:41:00.123576 A > B: . 379025:380485(1460) ack 1 win 32768
   10:41:00.132016 A > B: . 380485:381945(1460) ack 1 win 32768
   10:41:00.141635 A > B: . 381945:383405(1460) ack 1 win 32768
   10:41:00.150094 A > B: . 383405:384865(1460) ack 1 win 32768
   10:41:00.158552 A > B: . 384865:386325(1460) ack 1 win 32768
   10:41:00.167053 A > B: . 386325:387785(1460) ack 1 win 32768
   10:41:00.175518 A > B: . 387785:389245(1460) ack 1 win 32768
   10:41:00.210835 A > B: . 389245:390705(1460) ack 1 win 32768
   10:41:00.226108 A > B: . 390705:392165(1460) ack 1 win 32768
   10:41:00.241524 B > A: . ack 389245 win 8760 (DF) [tos 0x8]

      The first packet indicates the ack point is 357125.  130 msec
      after receiving the ACK, A transmits the packet after the ACK
      point, 357125:358585.  640 msec after this transmission, it
      retransmits 357125:358585, in an apparent retransmission timeout.
      At this point, A's cwnd should be one MSS, or 1460 bytes, as A
      enters slow start.  The trace is consistent with this possibility.

      B replies with an ACK of 364425, indicating that A has filled a
      sequence hole.  At this point, A's cwnd should be 1460*2 = 2920
      bytes, since in slow start receiving an ACK advances cwnd by MSS.
      However, A then launches 19 consecutive packets, which is
      inconsistent with slow start.

There's a general template that structures each section of the draft, but 
you can check that out for yourself...

Did we need to do more than the SIP version of this, initially? Hunting down 
implementers in the streets with pitchforks may be appropriate later, but 
giving people a canonical list of known-broken implementation behaviors 
really is giving uses and operators power they don't have now.

Thanks,

Spencer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 15 Oct 2007 18:44:49 -0400

Weighing in a bit late here...

I fully agree it would be great to get more implementation feedback and 
deployment feedback. However, I don't think organizing a BoF is going to 
get us that. IMHO, the way it ought to work is, that the working group 
where a protocol got created, is the working group where folks doing 
implementations and deployments participate and provide feedback. The 
SIP working group is chartered to do maintenance of SIP. Indeed its 
working on fixes based on deployment experience. That would be the 
natural place for more feedback on problems and deployment experience.

It makes me wonder why we arent normally getting such feedback in the 
SIP working group, in fact. Its clear that the number of implementations 
and deployments of SIP far outweigh the participants in the group. My 
guess is that most folks don't want to invest the resources in providing 
participants to give input, feedback or get things fixed/adjusted to 
meet their needs.

-Jonathan R.

Spencer Dawkins wrote:
> (http://www.ietf.org/html.charters/OLD/tcpimpl-charter.html) was that 
> people published TCPDUMP traces that said (using 
> There's a general template that structures each section of the draft, 
> but you can check that out for yourself...
> 
> Did we need to do more than the SIP version of this, initially? Hunting 
> down implementers in the streets with pitchforks may be appropriate 
> later, but giving people a canonical list of known-broken implementation 
> behaviors really is giving uses and operators power they don't have now.
> 
> Thanks,
> 
> Spencer
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 15 Oct 2007 21:56:08 -0500

> From: Jonathan Rosenberg [mailto:[email-masked]] 
[SNIP]
> It makes me wonder why we arent normally getting such 
> feedback in the SIP working group, in fact. Its clear that 
> the number of implementations and deployments of SIP far 
> outweigh the participants in the group. My guess is that most 
> folks don't want to invest the resources in providing 
> participants to give input, feedback or get things 
> fixed/adjusted to meet their needs.

Ironic.

I did just exactly this with the early media drafts in SIPPING that
detailed the problems in the wild with early media. I'm not seeking to
reopen the issue here (or anywhere else for that matter) but the group
reaction was fairly muted to the report card of how people were breaking
SIP with their various implementations. I got a few, "wow, that's really
bad" responses and that was about it.

Very few people were interested in addressing this particular issue in
any capacity, which is a perfectly valid response. However, the group
*is* getting this feedback from time to time, and perhaps it's the
presentation that is lacking, but the response to such material can be
somewhat uneven depending upon how popular the particular area of
concern is viewed by the WG.

I think you're not getting this information normally because the people
who have it don't know how to get it to the IETF effectively or are not
otherwise motivated to provide such information.

Regards,
Brian

---

From: <[email-masked]>
Date: Tue, 16 Oct 2007 15:17:21 +0300

Hi Jonathan,

What you say makes sense in principle. However, as you point out, we
don't see enough practical feedback in our regular sessions or mailing
lists. Also, as Brian wrote, the feedback often does not lead to much.
Somehow we should encourage people with practical experience to become
more active. 

It's not clear what we should do to improve the situation. Perhaps we
should try out different things. Organizing a specific one-time BoF
dedicated to such issues might be one of the trials. SIP/SIPPING should
still do the "real" work, e.g. producing new documentation if necessary.
The thing that currently makes me uncomfortable with SIP is that the
reading from the field that I get is quite different from the reading I
get from IETF WGs. I'm afraind that many people think IETF has gone too
far ahead with the new stuff like session policies, consent framework,
sidebars etc. where it's not clear if anyone really has plans to
*implement* them. Of course the WGs are consensus and contribution
driven in what they do, so can't complain.  
 
Ultimately I believe there would be two different ways to get something
as large and complicated as SIP interoperable:
1. Strong open source projects that create the de facto for others to
use and follow. This has happened with a few protocols. For instance
XMPP, I think. 
2. Commercial forum similar to WiFi Alliance where the leading vendors
participate and who has a credible certification program. 

In both cases we need something beyond the IETF, but I think we should
also do in the IETF all we can to succeed. Of course it may be that some
things aren't happening because there is no real demand for them, in
which case engineering won't help. 

Regards,
	Markus

>From: ext Jonathan Rosenberg [mailto:[email-masked]] 
>Sent: 16 October, 2007 01:45
>To: Spencer Dawkins
>Cc: [email-masked]
>I fully agree it would be great to get more implementation 
>feedback and deployment feedback. However, I don't think 
>organizing a BoF is going to get us that. IMHO, the way it 
>ought to work is, that the working group where a protocol got 
>created, is the working group where folks doing 
>implementations and deployments participate and provide 
>feedback. The SIP working group is chartered to do maintenance 
>of SIP. Indeed its working on fixes based on deployment 
>experience. That would be the natural place for more feedback 
>on problems and deployment experience.
>
>It makes me wonder why we arent normally getting such feedback 
>in the SIP working group, in fact. Its clear that the number 
>of implementations and deployments of SIP far outweigh the 
>participants in the group. My guess is that most folks don't 
>want to invest the resources in providing participants to give 
>input, feedback or get things fixed/adjusted to meet their needs.
>
>-Jonathan R.
>
>
>
>Spencer Dawkins wrote:
>> Did we need to do more than the SIP version of this, initially? 
>> Hunting down implementers in the streets with pitchforks may be 
>> appropriate later, but giving people a canonical list of 
>known-broken 
>> implementation behaviors really is giving uses and operators 
>power they don't have now.
>> 
>> Thanks,
>> 
>> Spencer
>> 
>>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 16 Oct 2007 05:39:22 -0700

The difficulty in getting feedback from commercial entities is not due
to their lack of resources, but probably more to the prudence not to
scare off customers. PR approval will not be given, neither to share
good insight, nor to share failures.

This is another reason why it is essential to have R&D and academia be a
key part in developing Internet standards.

The BOF will be very useful since there are plenty to discuss, even if
no commercial deployment experience will be shared. Or maybe some folks
will share after all...

Henry

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Monday, October 15, 2007 3:45 PM
To: Spencer Dawkins
Cc: [email-masked]
Subject: Re: [RAI] SIP interoperability experiences BOF

-Jonathan R.

> Did we need to do more than the SIP version of this, initially?
Hunting

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 16 Oct 2007 14:04:34 +0100

Just some thoughts...

One thing such a group could do (whether it's a separate group or part of 
SIP) is maintain a list of reported issues in a publicly visible Bugzilla 
style database.  (I know there is one on Softarmor - although it seems to be 
broken at the moment - but I think it's tracking different things.)  The w3c 
does this to track some of their specs 
(http://www.w3.org/XML/2006/01/public-bugzilla for info).  Each product 
(e.g. RFC) is identifiable and the system automatically assigns the report 
to a human shepherd of some description.  They can then progress the report, 
be it update RFC, add to gotchas list, say its a duplicate etc.

The group could then sweep the database from time to time (every 6-12 
months) and produce a document of common gotchas.

The presence of the database could be mentioned in a particular section 
(Implementation feedback?) in each SIP RFC and ID so that people know where 
it is.

HTH,

Pete.

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 16, 2007 1:17 PM
Subject: RE: [RAI] SIP interoperability experiences BOF

Hi Jonathan,

Regards,
Markus

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Oct 2007 16:50:42 +0300

Hi Markus,
Hi Jonathan,

> participate and who has a credible certification program. 

I believe the first item is very important. For a number of items we 
only see commercial implementations and almost no usable open source code.
Example: SIP presence related stuff (since you mentioned XMPP)

There is potential for improvement!

Ciao
Hannes

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Oct 2007 10:58:51 -0500

Here is another thought.

They might be afraid that they'd get their head chewed off if they
came to IETF and explain what they did.  Especially if they can't really
explain why they are trying to do what they did for commercial reason.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 16 Oct 2007 09:58:11 -0700

> Here is another thought.

And here is one more :-)

The proponents and champions of standard protocols should bear the
responsibility to back up their proposal with (1) running code (MUST)
and (2) measurements from deployments (SHOULD).

Henry

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Tuesday, October 16, 2007 8:59 AM
To: Henry Sinnreich; Jonathan Rosenberg; Spencer Dawkins
Cc: [email-masked]
Subject: RE: [RAI] SIP interoperability experiences BOF

Here is another thought.

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Oct 2007 12:09:35 -0500

On Oct 16, 2007, at 8:04 AM, Pete Cordell wrote:

> Just some thoughts...
>
> One thing such a group could do (whether it's a separate group or  
> part of SIP) is maintain a list of reported issues in a publicly  
> visible Bugzilla style database.  (I know there is one on Softarmor  
> - although it seems to be broken at the moment - but I think it's  
> tracking different things.)  The w3c does this to track some of  
> their specs (http://www.w3.org/XML/2006/01/public-bugzilla for  
> info).  Each product (e.g. RFC) is identifiable and the system  
> automatically assigns the report to a human shepherd of some  
> description.  They can then progress the report, be it update RFC,  
> add to gotchas list, say its a duplicate etc.

Thanks for the headsup.

The cgi report generator on bugs.sipit.net seems to be broken, so  
I've repointed the links on the softarmor site to a higher-level  
entry point. You can construct your own report using the web interface.

If you want to go directly to the sipit tracker, it's at

http://bugs.sipit.net/

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 17 Oct 2007 20:10:11 -0700

Hi All,

Jon and I have been following this thread and have heard a few  
proposal including a BOF request. We are trying to figure out the  
best way to have some time for discussing this topic. It goes without  
saying that we are keen on anything that brings in experience from  
implementors and information about interoperability problems being  
encountered so that we can make better standards.

We have a phone call scheduled with the IAB and IESG to discuss the  
BOF proposals and will use that to try and sort out a plan. I expect  
to have a plan after next week.

Thanks, Cullen

<with my AD hat on>