Subject: [dispatch] PLEASE NOTE (Fwd: IETF-76 DISPATCH WG deadlines)

From: Robert Sparks <[email-masked]>
Date: Wed, 2 Sep 2009 08:36:47 -0500

(apologies for cross-post: reply-to set to dispatch)

The first deadline below is next Monday. Please get in touch with Mary  
and Gonzalo if you are going to have trouble hitting that date.

RjS

Begin forwarded message:

> From: "Mary Barnes" <[email-masked]>
> Date: August 21, 2009 11:25:16 AM CDT
> To: <[email-masked]>
> Cc: [email-masked]
> Subject: [dispatch] IETF-76 DISPATCH WG deadlines
>
> Hi all,
>
> As was done for IETF-75, we are setting earlier deadlines for  
> discussing topics in DISPATCH prior to the WG session at IETF-76.
>
> We will again follow the deadlines for BoFs:
> http://www.ietf.org/meeting/cutoff-dates.html#76
>
> This provides enough time to dispatch topics prior to the meeting as  
> appropriate - e.g., mini-bofs, official bofs, other WGs, new WGs,   
> mailing lists, etc. Thus, allowing us to have more focused and  
> constructive discussions on a smaller set of topics prior to the WG  
> session.
>
> Please note that the dates are much sooner than you might expect as  
> the time between IETF-75 and IETF-76 is 3 weeks less than the time  
> between IETF-74 and IETF-75. The document deadlines are 9 and 10  
> weeks away from next Monday (August 24th).
>
>
> Thus, the following are the proposed deadlines:
>
> Sept 7th  - Cutoff date to notify the chairs and DISPATCH WG mailing  
> list of plans to submit a proposal.
> --------------------------------------------------------------------------------------------------------
>
> This will help folks with similar topics to work together before the  
> meeting. If a preliminary charter proposal is available at this  
> point, please include it.
>
>
> September 21st - Cutoff for charter proposals for topics.
> --------------------------------------------------------
>
> A charter proposal must consist of a minimum of a problem statement  
> and at least one milestone/deliverable. This deadline will allow  
> time for consideration of proposals that could potentially be  
> "dispatched" prior to the WG session.
>
>
> September 28th - Topics that are to be the focus of IETF-76 are  
> announced.
> ---------------------------------------------------------------------------
>
> The idea here is to focus the discussion over the weeks preceding  
> IETF-76 on these main topics, noting that any new or updates to any  
> documents are due 3-4 weeks later.  This will ensure we have  
> constructive discussions before the meeting and are actually able to  
> determine consensus as to where work should be progressed (e.g.,  
> separate BoF, a new WG, an existing WG, individual document, etc.)  
> at IETF-76. Note, that the exact disposition for a topic may (per  
> the usual process) require follow-up and confirmation by the ADS and/ 
> or IESG (e.g., for a new WG, Bof, individually sponsored document,  
> etc.) or with another WG to ensure agreement with the DISPATCH WG  
> consensus for the topic.
>
>
> As discussed previously, the intention is not necessarily to  
> preclude folks submitting documents on other topics, however, it is  
> very unlikely there would be agenda time allocated to documents/ 
> topics submitted after the deadlines. We can include one or two  
> slides on these topics in the DISPATCH WG chair charts so that the  
> authors can gather other interested parties to contribute to the work.
>
> Regards,
> Mary and Gonzalo
> DISPATCH WG co-chairs
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 03 Sep 2009 20:08:26 +0000

> list of plans to submit a proposal. 

I plan to respin and expand my draft problem statement on third party
authentication, and would like to plan time to discuss it.

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 4 Sep 2009 15:53:41 -0400

Dispatch Chairs:  We would like to reserve some time during DISPATCH to
discuss the topic of domain registration in SIP.

A draft from Hadriel Kaplan that fully describes the issue will be
forthcoming but the problem statement can be described in the following
excerpt:    

   In some environments, notably the Small-to-Medium Business (SMB) market,
SIP devices in the Enterprise are effectively IP-PBX's,receiving PRI-type
SIP trunk services from a SIP Service Provider (SSP).  The SIP IP-PBX device
is authoritative for its local domain of AoR's.   
    
   Even if the IP-PBX has its own Domain Name, not every small business
owner has a DNS, or has the technical capability to provision DNS entries
(e.g., SRV's) appropriately in their DNS, or has the ability to do so
through any third party which hosts their domain name(s),or may not wish to
make their SIP device address known publicly. Furthermore, the SMB may not
have its own Domain Name at all, and   instead merely has an IP Address. 
    
   Because a single SSP may support multiple thousands of such SMB IP-
PBX's, it is impractical and cost-prohibitive to manually provision  their
IP Addresses in every SIP node along the path which needs to   reach the SMB
IP-PBX customer.  Instead, a dynamic reachability mechanism is needed. 
    
   Such a mechanism already exists for SIP: the REGISTER transaction. A
REGISTER request transaction provides dynamic reachability information of an
AoR for its authoritative domain.   
    
   Since a REGISTER request mechanism is generally supported by most SIP
Service Providers' equipment, it has become common practice for  small
IP-PBX's to use the mechanism as a means of providing their   reachability
information.  In some cases interoperability problems have arisen, due to
differing expectations and implementations of how such a mechanism should
work in practice.  

Richard Shockey
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype/AIM: rshockey101 
LinkedIn : http://www.linkedin.com/in/rshockey101

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 07 Sep 2009 14:27:05 +0300

Hi,
 
We would like to propose a new DISPATCH topic on "Disaggregated media":

    the ability for a user to create a  multimedia session combining
    different media streams,
    coming from different devices under his or her control, so that they
    are treated
    by the far end of the session as a single media session.

The analysis of what types of disaggregated media can be implemented 
using existing protocol mechanisms,
the pros and cons of using each of those mechanisms and also the 
scenarios that are not covered by current mechanisms
are all described in :
http://tools.ietf.org/id/draft-loreto-dispatch-disaggregated-media-00.txt

This topic has been discussed on the mailing receiving quite high interest
So we would like to hear you thoughts on DISPATCH or a new "dispatched" 
mini-WG as the home for such work.

Charter proposal and problem statement is to follow.

best regards
Salvatore Loreto

Mary Barnes wrote:
> _http://www.ietf.org/meeting/cutoff-dates.html#76_
>
> between IETF-74 and IETF-75. The document deadlines are 9 and 10 weeks 
> away from next Monday (August 24th). 
>
>
> meeting. If a preliminary charter proposal is available at this point, 
> please include it.
>
>
> and at least one milestone/deliverable. This deadline will allow time 
> for consideration of proposals that could potentially be "dispatched" 
> prior to the WG session.
>
>
> separate BoF, a new WG, an existing WG, individual document, etc.) at 
> IETF-76. Note, that the exact disposition for a topic may (per the 
> usual process) require follow-up and confirmation by the ADS and/or 
> IESG (e.g., for a new WG, Bof, individually sponsored document, etc.) 
> or with another WG to ensure agreement with the DISPATCH WG consensus 
> for the topic.
>
>
> As discussed previously, the intention is not necessarily to preclude 
> folks submitting documents on other topics, however, it is very 
> unlikely there would be agenda time allocated to documents/topics 
> submitted after the deadlines. We can include one or two slides on 
> these topics in the DISPATCH WG chair charts so that the authors can 
> gather other interested parties to contribute to the work.
>
> Regards,
> Mary and Gonzalo
> DISPATCH WG co-chairs
>
> ------------------------------------------------------------------------
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 8 Sep 2009 21:49:02 -0500

> discuss the topic of domain registration in SIP.

It seems like you're proposing a deep and fundamental rewrite of the  
Internet's name architecture, replacing RFC 3263 and its use of DNS  
with some sort of SIP REGISTER technique.

Or maybe I'm missing it entirely, and what you're proposing is a way  
to use SIP REGISTER messages to populate a DNS SRV record within a  
registry?

This raises the question of delegation to that registry -- the  
registry has to be authoritative for all of  example.com in order to  
be able to host an srv record for example.com. So your mythical SMB is  
still going to require a DNS service provider that has to be  
meaningfully provisioned. It's just a question of the outsourcing  
contract, and I fail to see a need for protocol work here. After all,  
we have dynamic DNS, and it works pretty darned well for me today.

So what you talking 'bout, Shockey?

--
Dean

---

From: Alan Johnston <[email-masked]>
Date: Fri, 11 Sep 2009 09:20:08 -0500

Dean,

The plan is not to rewrite the Internet's name architecture nor replace 
RFC 3263.

The plan is to standardize a function that has been shown to be needed 
in the marketplace for the deployment of SIP in certain applications.

And yes, dynamic DNS is an alternative, it does work, but again, there 
are reasons why it is not being used in this certain application.

Anyway, lets start this conversation properly when we have a draft.

Thanks,
Alan

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 14 Sep 2009 10:58:36 +0200

Hi,
 
Some time ago I submitted a requirement draft for the OMA work on CBUS.
 
In short, the idea of CBUS is that a client provides a set of conditions (which can be related to presence, location etc etc) to a CBUS server. Based on the conditions, the CBUS server communicates with presence servers, locations servers etc in order to figure out which users fulfill the conditions. The CBUS server then provides the client with a list of the URIs which fulfilled the conditions. The CBUS can do that on a one-time bases, a time-based basis, or whenever the information changes (called evaluation parameters). In addition, the client can provide a set or URIs, or a reference to URIs, which the CBUS chooses from (called candidate URIs). 
 
The idea is to provide the URIs in a subscription event package, and the associated SUBSCRIBE would contain the conditions (most likely using an XML document).
 
Dean raised a question whether it would be enough to define the new event package, and re-use RFC4660/1 to provide the conditions.
 
Due to summer vacations etc it took a while to look into this, but me and some OMA people have now looked into this.
 
Our initial conclusion is that it is NOT very feasible to re-use RFC 4660/1. 
 
RFC4660/1 provides a filtering mechanism, where the client specifies what type of information he wants to receive. However, in CBUS the type of information is always the same: the URI list. Instead, the CLIENT provides the type of information (conditions) on which the URIs shall be selected (and, in addition to that, the evaluation parameter(s) and candidate URI(s)).
 
We did look at whether it would be possible to somehow re-use 4660/1, but we thought it would be rather hacky. Some of the 4660/1 XML elements would probably be unused, and there would be a need to define new extensions - so we thought it would be nicer to define a new XML schema instead.
 
So, I would like to request DISPATCH time to discuss this. We plan to provide an updated version of the draft, with clarifications and more details etc.
 
Regards,
 
Christer

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 22 Sep 2009 14:37:56 -0400

Alan is right ..the problem statement will be easier to explain once we have
a draft in hand. 

This is not really a proposal for a WG. There is only one draft here. 

What we need to explain is what is actually happening in the market with
certain classes of SIP-PBX deployments especially in Small and Medium
business markets.  

There are much larger issue here that should be addressed in the
provisioning of PBX to SSP networks but that is not the topic here.   

>  -----Original Message-----
>  From: Alan Johnston [mailto:[email-masked]]
>  Sent: Friday, September 11, 2009 10:20 AM
>  To: Dean Willis
>  Cc: Richard Shockey; [email-masked]; 'Hadriel Kaplan'; 'Gonzalo
>  Camarillo'
>  Subject: Re: [dispatch] IETF-76 DISPATCH WG deadlines : New Topic
>  Domain Registration
>  
>  Dean,
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 22 Sep 2009 22:35:41 -0500

On Sep 11, 2009, at 9:20 AM, Alan Johnston wrote:

> Dean,
>
> The plan is not to rewrite the Internet's name architecture nor  
> replace RFC 3263.
>
> The plan is to standardize a function that has been shown to be  
> needed in the marketplace for the deployment of SIP in certain  
> applications.
>
> And yes, dynamic DNS is an alternative, it does work, but again,  
> there are reasons why it is not being used in this certain  
> application.
>

Ah, so you're not really "registering a domain with the Internet using  
SIP", you're "registering a domain-wide set of AORs with a routing  
proxy".

So here's the use case I'm envisioning. The DNS SRV record for  
example.org points statically to a service provider's  routing proxy/ 
registrar. This gets provisioned into the DNS when example.org  
contracts with the service provider.

When the example.org PBX powers up, it needs to register with the   
proxy/registrar. But rather than running a separate REGISTER  
transaction for each user in example.org, you want to use a single  
transaction to tell the proxy/registrar "If it's for anybody at  
example.org, send it to this Contact". One way to approach this might  
be to use a to/from of "*.example.org" in the REGISTER method (which  
would be an extension to RFC 3261), along with appropriate  
authentication.

This is something like the bulk-registration problem for gateways,  
where people have hacked REGISTER to indicate a range of phone  
numbers. It has the advantage of being able to use qvalue  
prioritization to have some users at example.org register directly  
with the service provider, bypassing the PBX.

But I worry that it's still a serious misuse of the REGISTER model.  
We're not really registering a contact; what we're really doing is  
exchanging routing information for a whole bunch of contacts.

Where it breaks down is when example,org's node is not a PBX (a UA, or  
even B2BUA) but is instead a real proxy (I know, there's no such  
thing ...). The subtle distinction is in the identity presentation,  
and its coupling to TLS.

I shall try to construct an example for clarification.

Suppose Bob calls "[email-masked]", and the service provider issues  
a 302 with the previously registered Contact value. Bob's UA is now  
expecting to talk to Alice's UA, via SIPS/TLS. What certificate does  
the PBX present at the TLS level? is it the certificate of "[email-masked] 
", or is it the certificate of "pbx.example.org"? Does this induce an  
unanticipated respondent problem for Bob?

Alternatively suppose a 305 was used. Bob's UA now expects to be  
talking SIPS/TLS to a proxy that knows how to find Alice. How is the  
behavior different?

This brings in a whole raft of unclarities around TLS, domain usage,   
certificate/identity coupling, and 302 vs 305 behavior that combine to  
make me a very confused puppy. It might be that the Domain Certs draft  
has all this cleared up and I just missed it. It also relates to that  
long-running "what is an AOR" debate.

But it's certainly more useful if the service provider's proxy/ 
registrar knows it is getting a route towards an AOR instead of a  
contact for that AOR. Sure, we could extend REGISTER to convey this  
information. Once we've done that, can REGISTER be used as a general- 
purpose SIP route exchange mechanism? Or would we be better served by  
building a real routing protocol, ala TRIP?

So given this discussion: I know you like to jump directly to a  
solution, and "Domain Registration" with its similarity to that  
private PBX-club SIP specification hint at the solution you might be  
approaching. But I'd really like to take a step back here and get  
clarity on the problem we're trying to solve before leaping to a  
solution, because I have a strong suspicion that we're leading towards  
the wrong solution to a poorly-defined problem that is itself a subset  
of an interesting more-general problem.

The "domain registration" concept, as I understand it, seems to be a  
subset of the broader SIP routing-exchange problem. This broader  
problem I see as becoming increasingly critical in the era of P2P  
overlays, as it starts to address inter-overlay routing and might even  
address questions like "What happens if some users in example.org are  
in overlay A using CHORD and some are in overlay B using PASTRY". This  
might not be as tactical a solution as hacking REGISTER, but I think  
it's a real problem and that there are tractable solutions that would  
fit into the scope of a working group.

--
Dean

--
Dean

---

From: ggb <[email-masked]>
Date: Fri, 25 Sep 2009 12:13:03 +0200

Hi,

I've been reading the requirements draft, and I agree that it would be 
needed some work in the IETF in order to be able to provide this 
functionality making use of SIP events support.

Somehow this feature is closer to searching than to filtering, and I 
tend to agree that RFC4660 does not fit well in this space (although the 
concept of triggers in RFC4660 could be reused).  Defining other XML 
schema for expressing the query/conditions could be the simplest solution.

BR,

Gustavo García
Telefónica I+D

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 25 Sep 2009 12:17:26 +0200

Hi Gustavo,

Thanks you for your feeback!

We did look into using RFC4660, and we came to the same conclusion as you. Yes, perhaps it would be possible to use SOME part of 4660, but many things would not be needed, and there would be a need to define new things anyway. We thought that could become rather hacky and messy.

Regards,

Christer

> From: ggb [mailto:[email-masked]] 
> Sent: 25. syyskuuta 2009 13:13
> To: Christer Holmberg
> Cc: [email-masked]; Gonzalo Camarillo
> Subject: Re: [dispatch] IETF-76 DISPATCH WG deadlines : CBUS
> 
> Hi,
> 
> I've been reading the requirements draft, and I agree that it 
> would be needed some work in the IETF in order to be able to 
> provide this functionality making use of SIP events support.
> 
> Somehow this feature is closer to searching than to 
> filtering, and I tend to agree that RFC4660 does not fit well 
> in this space (although the concept of triggers in RFC4660 
> could be reused).  Defining other XML schema for expressing 
> the query/conditions could be the simplest solution.
> 
> BR,
> 
> Gustavo García
> Telefónica I+D
> 
> > In short, the idea of CBUS is that a client provides a set 
> of conditions (which can be related to presence, location etc 
> etc) to a CBUS server. Based on the conditions, the CBUS 
> server communicates with presence servers, locations servers 
> etc in order to figure out which users fulfill the 
> conditions. The CBUS server then provides the client with a 
> list of the URIs which fulfilled the conditions. The CBUS can 
> do that on a one-time bases, a time-based basis, or whenever 
> the information changes (called evaluation parameters). In 
> addition, the client can provide a set or URIs, or a 
> reference to URIs, which the CBUS chooses from (called 
> candidate URIs).
> >
> > The idea is to provide the URIs in a subscription event 
> package, and the associated SUBSCRIBE would contain the 
> conditions (most likely using an XML document).
> >
> > Dean raised a question whether it would be enough to define 
> the new event package, and re-use RFC4660/1 to provide the conditions.
> >
> > Due to summer vacations etc it took a while to look into 
> this, but me and some OMA people have now looked into this.
> >
> > RFC4660/1 provides a filtering mechanism, where the client 
> specifies what type of information he wants to receive. 
> However, in CBUS the type of information is always the same: 
> the URI list. Instead, the CLIENT provides the type of 
> information (conditions) on which the URIs shall be selected 
> (and, in addition to that, the evaluation parameter(s) and 
> candidate URI(s)).
> >
> > We did look at whether it would be possible to somehow 
> re-use 4660/1, but we thought it would be rather hacky. Some 
> of the 4660/1 XML elements would probably be unused, and 
> there would be a need to define new extensions - so we 
> thought it would be nicer to define a new XML schema instead.
> >
> > So, I would like to request DISPATCH time to discuss this. 
> We plan to provide an updated version of the draft, with 
> clarifications and more details etc.
> >
> > Regards,
> >
> > Christer

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 28 Sep 2009 16:37:28 -0400

The whole "problem" seems strange to me.  There is the question of
getting the SIP domain properly mapped to the IP address, but we have
dynamic DNS for that, and our prototypical PBX could coordinate that
with the service provider.  As for "it is impractical and
cost-prohibitive to manually provision their IP Addresses in every SIP
node along the path which needs to reach the SMB IP-PBX customer", of
course you don't manually provision that information:  The Domain Name
System automagically propagates the domain-to-IP-address mapping to the
entire Internet, and the various routing protocols automagically
propagate the IP routing information to "every node along the path".

> are reasons why it is not being used in this certain application.

Might you be able to reveal those reasons?  The techniques I've
described are the ones used by the people I know.

Dale

---

From: Dean Willis <[email-masked]>
Date: Mon, 28 Sep 2009 23:34:35 -0500

> propagate the IP routing information to "every node along the path".

I struggled with this as well. But now that I'm thinking about the  
problem as trying to dynamically construct a SIP route between the  
proxy-of-record (as indicated by DNS) and a local proxy or multi-user  
UA (read "PBX"), I'm finding the problem significantly more tractable.

The reason DDNS doesn't work for this is that there might be private  
topography between the proxy-of-record and the multiuser UA (think  
"outbound". Now think massively-shared outbound connections).

--
Dean