Subject: [dispatch] Fwd: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

From: Cullen Jennings <[email-masked]>
Date: Tue, 23 Mar 2010 10:03:54 -0700

As discussed at the SIP Forum lunch yesterday, there has been considerable work on a specification for configuration of SIP User Agents that is reflected in this document. I believe this document is appropriate for progression as AD Sponsored thought it may still need a few changes and discussion of community consensus. To initiate this, I have requests a  4 week last call. 

Please, do give this document a read, and as request in the Last Call, send the email to the [email-masked] list. 

Thanks, 
Cullen <RAI AD>

Begin forwarded message:

> From: The IESG <[email-masked]>
> Date: March 23, 2010 9:12:48 AM PDT
> To: IETF-Announce <[email-masked]>
> Subject: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
> Reply-To: [email-masked]
> 
> The IESG has received a request from an individual submitter to consider 
> the following document:
> 
> - 'Session Initiation Protocol (SIP) User Agent Configuration '
>   <draft-lawrence-sipforum-user-agent-config-00.txt> as an Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2010-04-20. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-lawrence-sipforum-user-agent-config-00.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19859&rfc_flag=0
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 24 Mar 2010 14:31:51 +0100

Also related to this is:
http://www.ietf.org/id/draft-lawrence-dispatch-sipforum-provider-alias-00.txt

"This document defines procedures for how a SIP User Agent can translate an identifier provided by a user into the SIP DNS domain name of a service provider.  The form of the user supplied identifier is constrained to values that can be entered using only a standard 12 key telephone keypad."

This draft, from the SIP Forum, is an extension to the draft Cullen just announced IETF last call on. It allows a SIP user agent to accept a provider alias number (PAN) entered by the user and translate it to the domain name at which the configuration service for configuring the UA can be found.

The SIP Forum would like DISPATCH to consider ways of progressing this draft.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: 23 March 2010 10:04
> To: [email-masked]; [email-masked]
> Subject: [dispatch] Fwd: Last Call: 
> draft-lawrence-sipforum-user-agent-config (Session Initiation 
> Protocol (SIP) User Agent Configuration) to Informational RFC
> 
> 
> As discussed at the SIP Forum lunch yesterday, there has been 
> considerable work on a specification for configuration of SIP 
> User Agents that is reflected in this document. I believe 
> this document is appropriate for progression as AD Sponsored 
> thought it may still need a few changes and discussion of 
> community consensus. To initiate this, I have requests a  4 
> week last call. 
> 
> Please, do give this document a read, and as request in the 
> Last Call, send the email to the [email-masked] list. 
> 
> Thanks, 
> Cullen <RAI AD>
> 
> 
> 
> Begin forwarded message:
> 
> > Subject: Last Call: 
> draft-lawrence-sipforum-user-agent-config (Session Initiation 
> Protocol (SIP) User Agent Configuration) to Informational RFC
> > Reply-To: [email-masked]
> > 
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 24 Mar 2010 13:10:46 -0500

Elwell, John wrote:
> "This document defines procedures for how a SIP User Agent can
> translate an identifier provided by a user into the SIP DNS domain
> name of a service provider.  The form of the user supplied identifier
> is constrained to values that can be entered using only a standard 12
> key telephone keypad."
> 
> This draft, from the SIP Forum, is an extension to the draft Cullen
> just announced IETF last call on. It allows a SIP user agent to
> accept a provider alias number (PAN) entered by the user and
> translate it to the domain name at which the configuration service
> for configuring the UA can be found.
> 

This Provider Alias Number sounds like an ITAD identifier which sounds
like a SPID.

One ought to be able to do an ENUM style query on this number and
retrieve a URI.

--
Dean

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 24 Mar 2010 15:41:04 -0400

> This Provider Alias Number sounds like an ITAD identifier which sounds

The idea was inspired by ITADs, but the task group felt that actually
using the ITAD name and registry would not meet the needs of the
intended use (that is, high reliability consumer-facing service
providers).

> One ought to be able to do an ENUM style query on this number and

Which is, roughly speaking, what the draft proposes: do a NAPTR lookup
to translate the PAN into a SIP domain name, which is then used as
specified in the UA Config spec to find the configuration service for
the provider.

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 24 Mar 2010 15:43:27 -0400

On Wed, 2010-03-24 at 14:31 +0100, Elwell, John wrote:
> just announced IETF last call on. It allows a SIP user agent to accept
> a provider alias number (PAN) entered by the user and translate it to
> the domain name at which the configuration service for configuring the
> UA can be found.

To be extra clear... the provider-alias draft is _not_ being last
called.   For various reasons, this part of what the SIP Forum Task
Group came up with has been separated from the rest to be progressed

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 24 Mar 2010 16:27:07 -0400

> intended use (that is, high reliability consumer-facing service

Could you expand on the reasoning? Do you see a problem with the accuracy of the data set, the ability to filter registrations to keep out riff-raff or more operational issues (e.g., operation of a DNS registry)?

Henning

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 24 Mar 2010 17:32:09 -0400

On Wed, 2010-03-24 at 16:27 -0400, Henning Schulzrinne wrote:

> Could you expand on the reasoning? Do you see a problem with the
> accuracy of the data set, the ability to filter registrations to keep
> out riff-raff or more operational issues (e.g., operation of a DNS
> registry)?

The attached is a problem statement I drafted for the SIP Forum Board
that summarized the issues raised in the task group and from some
external reviewers.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 24 Mar 2010 17:37:44 -0400

> that summarized the issues raised in the task group and from some

To quote:

The administrative and legal infrastructure of using the existing
     first-come first-served ITAD registry at IANA is not sufficient
     for the needs of commercial service providers.

* No reasons are given for this determination.

 Using the existing ITAD name and registry may create confusion
     regarding whether or not other parts of the protocols and
     procedures in the TRIP specification and/or the ISN/Freenum trial
     are also applicable (the intent is that no other part of these
     other specifications and procedures be used).

* I admit that I find this speculative. As long as the mechanism is clear, the users of the DNS record won't care.

The ITAD number is defined as a 32 bit number.

* This translates into (roughly) a 9-digit decimal integer. It seems rather unlikely that we would exceed 4 billion service providers or that we'd want longer identifiers than 9 digits.

In general, I agree that the ITAD registry would have to be expanded and the use clarified, but re-use of the same registry (say, enterprise numbers) for different purposes is not unusual.

Henning

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Mar 2010 10:35:40 -0500

I tend to agree with Henning on all the points he raises below, and want 
to expand just a little bit.

The use of ITADs has in no way confused people participating in the 
Freenum trial into thinking that TRIP was required or even an option. In 
fact, the separation of ITAD from TRIP in that experiment is so 
inherently clear that freenum.org doesn't even feel the need to discuss 
the hypothesized confusion in their FAQ (http://freenum.org/faq.html). 
Unless we expect a materially dimmer group of people to be consumers of 
the SIP Forum's output, there is historical information that TRIP 
conflation concerns are unfounded.

In addition to the points that Henning raised, I'm a bit confused by the 
assertion that the use of "freenum.org" does not scale, given that it is 
modeled on the general DNS delegation model, and is basically the same 
mechanism as ENUM uses. The current sipforum draft appears to 
counter-propose the use of a single, flat, non-delegated database at 
"sipforum.org." Could you clarify how trading a hierarchical, 
distributed database technology that provides domain naming services for 
approximately 400 million Internet hosts will have inferior scaling 
properties when compared against what is presumably a flat relational 
database hosted by SIPForum?

/a

On 3/24/10 4:37 PM, Henning Schulzrinne wrote:
> * I admit that I find this speculative. As long as the mechanism is 
> clear, the users of the DNS record won't care.
>
> * This translates into (roughly) a 9-digit decimal integer. It seems 
> rather unlikely that we would exceed 4 billion service providers or 
> that we'd want longer identifiers than 9 digits.
>
> In general, I agree that the ITAD registry would have to be expanded 
> and the use clarified, but re-use of the same registry (say, 
> enterprise numbers) for different purposes is not unusual.
>
> Henning
>
>

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 29 Mar 2010 16:51:18 -0400

(changed the subject line to accurately reflect the draft being
discussed)

On Mon, 2010-03-29 at 10:35 -0500, Adam Roach wrote:

> Freenum trial into thinking that TRIP was required or even an option.
> In fact, the separation of ITAD from TRIP in that experiment is so
> inherently clear that freenum.org doesn't even feel the need to
> discuss the hypothesized confusion in their FAQ
> (http://freenum.org/faq.html). Unless we expect a materially dimmer
> group of people to be consumers of the SIP Forum's output, there is
> historical information that TRIP conflation concerns are unfounded.

I don't personally think that this is the most important of the
problems, but we did get people asking questions about this - more were
about how the new usage related to what Freenum.org is doing than about
TRIP.  

Which serves to highlight that while the ITAD registry identifies
domains, that ISN does is _not_ the same as what this draft proposes.
The ISN dialing transform takes as input a dial string (usually carried
as the user part of a sip uri) into a full sip uri - the input has both
a domain identifier and a local part to be resolved in that domain.
This draft proposes a transform of one domain name into another, to be
used not for routing any sip request, but for subsequent resolution
(also through the DNS) into an http url.

When I was editing the SIP Forum task group draft, the difference was
brought home to me by the fact that there was no ISN 'standard' I could
claim to be profiling for this - we were doing an entirely different
operation for a significantly different purpose.  Of course, as it
turned out the Board decided we needed to take the whole thing elsewhere
to be made a standard anyway... 

> In addition to the points that Henning raised, I'm a bit confused by
> the assertion that the use of "freenum.org" does not scale, given that
> it is modeled on the general DNS delegation model, and is basically
> the same mechanism as ENUM uses.

I wasn't saying that DNS doesn't scale - I said that the _current_
freenum.org infrastructure was not appropriate to the needs of
commercial service providers.  Not a protocol issue at all.

Suppose that you are selling a small business or consumer phone service,
and you are relying on the (appropriately simple) instruction that the
customer set up a phone by entering '555' (your alias) when connecting a
new phone.   If it doesn't work because the translation can't be done,
do you think that the average small business person or consumer will
blame the operator of the DNS service or you?

The current freenum.org infrastructure is some non-profit research
institutions and universities; a fine thing and a great organization.
That doesn't make it appropriate as a key component in commercial
services (if there are significant commercial deployments of ISN I am
not aware of them, and if they are making money then I want to meet
their sales people).

 The current sipforum draft appears to counter-propose the use of a
single, flat, non-delegated database at "sipforum.org." 

If you read it as proposing any such thing, then I accept that editorial
work is needed (if you can divine how you got that idea, please point
out text).  It proposes the use of DNS NAPTR lookups with all the
marvelous scaling and redundancy properties you so justifiably admire.

As for 'sipforum.org', the draft says:

   The lookup key for the S-NAPTR request is the Provider Alias Number
   concatenated with a fixed root suffix (for the purposes of this
   initial draft, the value ".pan.sipforum.org." is used) to form a DNS
   domain name. 

... the key words here being 'a fixed suffix (for the purposes of this
initial draft'...  The actual value chosen can be anything, but it
seemed clearer to use a real example.  No one (most emphatically
including the SIP Forum itself) believes that the Forum is the
appropriate organization to actually operate the resolution
infrastructure regardless of the domain name chosen as the fixed suffix.

Personally, I think that the most important reason not to use ITADs or
freenum.org was the first one I listed:

   * The administrative and legal infrastructure of using the existing
     first-come first-served ITAD registry at IANA is not sufficient
     for the needs of commercial service providers.

If I were a service provider and was going to count on this to provide
me with that vital first connection service, I'd want to know that the
rules on how registrations were added to and modified in the registry
were subject to carefully spelled out contractual terms with enforceable
agreements as to service levels.  I'd want to know that that asset could
be transferred under well specified terms.  RFC 3219 has no such
infrastructure.