Subject: [Sipping] Moving forward with the inter-domain draft.

From: Edwin Aoki <[email-masked]>
Date: Wed, 03 Aug 2005 02:50:31 -0700

All,

Thanks for the opportunity to present a couple slides at today's SIPPING 
meeting.  Speaking on behalf of all of the authors, it's clear that 
there a lot of strong feelings and, we believe, misconceptions, around 
the draft. 

We appreciate all of you who've sent in specific comments on the draft 
(now in -03), but there's definitely a lot of debate about the scope and 
intent of this draft.

I think there are at least three fundamental questions/issues that 
people have raised in the context of this draft:

1) Is this draft applicable to just SIMPLE or to other SIP-based 
applications as well?

The draft reflects specific implementation experience that came from our 
collective work in implementing IM and presence, but it seems obvious 
that there would be applicability to other areas.  That's one of the 
reasons why the discussion of this draft was held in the SIPPING group.  
I don't think that we as authors hold any particular view on this, 
though it's clear that others believe there's overlap with work going on 
in VOIPEER.

Note that as Jon pointed out, the VOIPEER BOF is currently chartered 
only to the  VOIP space, so if there is overlap, we still need to do 
something to find the right scope for this work.

2) Does this draft apply specifically to walled gardens (or, as some 
have put even stronger, does this draft run counter to the Internet 
principles of openness?)

So this is an obvious and fair concern.  Our intent was not to mandate a 
walled garden approach or to require the use of bilateral agreements.  
There's at least one poorly worded statement in the TLS section of the 
document that might imply this, but that was an editing error on my part.

The overall concept here is that there are - and will be - a number of 
real-world scenarios where some administrative entity manages the 
overall namespace (and optionally some resource usage) for a set of 
individual users.  This lends to some interesting potential 
optimizations if it's well known in advance that these communities are 
talking to one another, as well as some new areas of interest (e.g.,  a 
way to indicate additional policy requirements, communicate TOSs, or to 
have some guidelines and BCPs for name recycling, etc.) above and beyond 
the work that the various SIP call flows contemplate today.  Most if not 
all of these are usage statements (i.e., a profile) for existing 
standards, not extensions or changes to standardized behavior.

As a set of BCPs, our intent is to be able to provide some guidance to 
operators that might be administering these sorts of environments 
(whether they're service providers, enterprises, etc.).  Also, where the 
specifications offer choices, we wanted to try to put a stake in the 
ground, based on our experience, for things that would be better, rather 
than worse, for the community and the Internet at large.

I can say without hestitation that it was NEVER the intent of the draft 
to deprecate other connection models, only to specify some behaviors and 
BCPs when the inter-community model is being used.

3) Some continuing controversy around the MESSAGE inside session section.

In the -03 draft, the amount of text in this section was dramtically 
reduced, in part because of the progress we've made towards MSRP.  When 
this draft was first conceived, MSRP was significantly less far along, 
and even now, we're not complete with the work.  Therefore, we wanted to 
be able to document the way in which several interoperable 
implementations implemented MESSAGEs inside of SESSIONS in advance of MSRP.

As is stated in the document, as MSRP becomes finalized, we expect that 
it will be the right way of accomplishing this task, but we felt it was 
important to document and unify existing practice.  If this is a real 
area of heartache for folks, we can use even stronger language steering 
people towards MSRP.

There are a number of other points that were raised on the list, but 
most of these are in reference to specific text.  We'll be going through 
those shortly and responding, but I wanted to hit some of the big ticket 
items above as we think about how to proceed with this work.

Obviously, we as authors think that this work is interesting, and we 
believe that there's some real value in documenting how this connection 
model should work.  I think that it's clear from the Paris meeting that 
there's at least some broader interest from the WG, and we're interested 
to have your help in guiding how we should proceed with it.

Thanks,
-Edwin

P.S.: the new rev of the draft, which still has the editorial error 
mentioned above, is at:
http://www.ietf.org/internet-drafts/draft-levin-simple-interdomain-reqs-03.txt

>Henry,
>
>
> I suggest that the chairs introduce this draft at the beginning of the 
> meeing (we will do this with a number of other drafts). We can then 
> have discussions on whether or not this is something we want to tackle 
> in SIPPING.
>
> We would appreciate if the authors could send the chairs one or 
> maximum two slides presenting the draft.
>
>Thanks,
>
>
>Gonzalo
>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Aug 2005 04:11:31 -0400

> BCPs when the inter-community model is being used.

I think you could go a long way towards relieving the concerns if you 
emphasized the use of 3263, perhaps with mutual TLS, for connecting to 
other domains/communities, and mentioned the use of bilateral agreements 
as MAY strength.

> area of heartache for folks, we can use even stronger language steering 

I don't think the "existing practice" should be enshrined in an IETF 
document at all, since this behavior has already been contra-indicated 
by the IETF. I think this falls either in the scope of bilateral 
agreements, or in the scope of some other organization.

	Paul