Subject: [martini] Integration of problem-statement material into requirements draft

From: "Elwell, John" <[email-masked]>
Date: Wed, 10 Feb 2010 11:19:44 +0100

As discussed at the virtual meeting yesterday, there seems to be an intention to integrate relevant material from draft-kaplan-martini-mixing-problems-00 into the requirements draft, so that we only need the one deliverable to cover both aspects.

I have reviewed the mixing-problems document, and these are my proposals for the various sections.

Section 1 (Introduction). Section 1 of the martini-reqs contains text closely aligned with some of the text in the MARTINI charter, so I don't particularly want to change that. I don't think it is necessary to reference the SIP Forum SIPconnect or 3GPP/ETSI specifications and their issues in section 1. So I don't think we need anything from section 1 of mixing-problems.

Section 2 (Definitions). The need for additional definitions will depend on what other text we import.

Section 3 (Background on current mechanisms). Basically we should incorporate this, because it is background needed to understand the issues in sections 4 onwards. This would include explicit references to the ETSI/3GPP mechanism, as an example of current techniques.

Section 4.1 (No Explicit Indicator). Include.

Section 4.2 (Undefined behaviour on PAU mismatch). Include.

Section 4.3 (REGISTER response growth). I am not sure we should include this, because we never agreed a requirement that the mechanism must work over UDP.

Section 4.4 (Illegal wildcarding syntax). Include.

Section 5.1 (Loss of target information). Include.

Section 5.2 (Request-URI vs. loose-route mismatches). Include.

Section 5.3 (Request-URI mis-routing). Include.

Section 6.1 (Authorization policy mismatches). I am not sure about this. The problem is that the SSP is being too strict, i.e., it doesn't permit the Contact URI to identify the calling UA (the Route header field, on the other hand, might bear some resemblance to the registered contact URI). I guess MARTINI deliverables can at least make statements about practices in this area, but MARTINI will not provide a solution that allows such authorization policies to work. My inclination, nevertheless, is to include this section.

Section 6.2 (P-Asserted-Identity URI mismatches). This is a policy issue, and MARTINI will not provide a solution that allows such a policy to work in all cases. So is this really part of the problem statement? If not, I would suggest we could omit this.

Section 6.3 (Trust domain mismatches for privacy/identity). Is this straying outside the scope of MARTINI? The issue applies even if RFC 3263 is used, rather than registration, between the PBX and the SSP. I would suggest we could omit this.

So in summary, I think we can import most of sections 3, 4 and 5 of the mixing-problems draft into the requirements draft, and perhaps some of section 6 too. I would propose they all go into a new section, prior to the Requirements section.

Please comment.

John

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 10 Feb 2010 13:52:46 -0800

Speaking for myself (co-chair hat off), this looks like a reasonable
approach. 

Once you do the integration, it might make sense to post a pointer to a
strawman, so people can look it over and comment before you submit it. 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, February 10, 2010 2:20 AM
To: [email-masked]; Hadriel Kaplan
Subject: [martini] Integration of problem-statement material into
requirements draft

As discussed at the virtual meeting yesterday, there seems to be an
intention to integrate relevant material from
draft-kaplan-martini-mixing-problems-00 into the requirements draft, so that
we only need the one deliverable to cover both aspects.

I have reviewed the mixing-problems document, and these are my proposals for
the various sections.

Section 1 (Introduction). Section 1 of the martini-reqs contains text
closely aligned with some of the text in the MARTINI charter, so I don't
particularly want to change that. I don't think it is necessary to reference
the SIP Forum SIPconnect or 3GPP/ETSI specifications and their issues in
section 1. So I don't think we need anything from section 1 of
mixing-problems.

Section 2 (Definitions). The need for additional definitions will depend on
what other text we import.

Section 3 (Background on current mechanisms). Basically we should
incorporate this, because it is background needed to understand the issues
in sections 4 onwards. This would include explicit references to the
ETSI/3GPP mechanism, as an example of current techniques.

Section 4.3 (REGISTER response growth). I am not sure we should include
this, because we never agreed a requirement that the mechanism must work
over UDP.

Section 6.1 (Authorization policy mismatches). I am not sure about this. The
problem is that the SSP is being too strict, i.e., it doesn't permit the
Contact URI to identify the calling UA (the Route header field, on the other
hand, might bear some resemblance to the registered contact URI). I guess
MARTINI deliverables can at least make statements about practices in this
area, but MARTINI will not provide a solution that allows such authorization
policies to work. My inclination, nevertheless, is to include this section.

Section 6.2 (P-Asserted-Identity URI mismatches). This is a policy issue,
and MARTINI will not provide a solution that allows such a policy to work in
all cases. So is this really part of the problem statement? If not, I would
suggest we could omit this.

Section 6.3 (Trust domain mismatches for privacy/identity). Is this straying
outside the scope of MARTINI? The issue applies even if RFC 3263 is used,
rather than registration, between the PBX and the SSP. I would suggest we
could omit this.

So in summary, I think we can import most of sections 3, 4 and 5 of the
mixing-problems draft into the requirements draft, and perhaps some of
section 6 too. I would propose they all go into a new section, prior to the
Requirements section.

Please comment.

John

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 10 Feb 2010 15:59:57 -0600

Yet Another E-mail from Spencer about UDP ... it's been a long week already!

> this, because we never agreed a requirement that the mechanism must work

The best requirements are the ones that everyone thinks everyone agrees with 
and never asks, but ... if this is a requirement, I would like to see it 
mentioned in the requirements document. If it's not a requirement, a whole 
range of possibilities opens up (beneath our feet)...

Thanks,

Spencer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 11 Feb 2010 08:11:58 +0100

Spencer,

I proposed it before, but we didn't gain consensus. So I will ask again. Should we add:
"The solution MUST work over any existing transport specified for SIP, including UDP"?

John 

> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: 10 February 2010 22:00
> To: Bernard Aboba; Elwell, John; [email-masked]; 'Hadriel Kaplan'
> Subject: Re: [martini] Integration of problem-statement 
> material intorequirements draft
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 11 Feb 2010 07:17:33 -0600

Speaking only as a participant, if this is NOT a requirement, I would have a 
much harder time arguing against including explicit lists in at least one 
direction.

I understand Dean's concern that the SIP experience has been "implicit side 
effects = does not end well", and the only reason I'm not leaning that 
direction as a participant is that I'm assuming that "works over UDP" IS a 
requirement in the IETF, and I don't like what that does to our ability to 
support mid-sized PBXes (where "mid-sized" means "more than 20-30 AoRs").

If "works over UDP" is NOT a requirement, what other technical reasons do we 
have for not doing explicit signaling?

Thanks,

Spencer

----- Original Message ----- 
From: "Elwell, John" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Bernard Aboba" 
<[email-masked]>; <[email-masked]>; "'Hadriel Kaplan'" 
<[email-masked]>
Sent: Thursday, February 11, 2010 1:11 AM
Subject: RE: [martini] Integration of problem-statement material 
intorequirements draft

Spencer,

I proposed it before, but we didn't gain consensus. So I will ask again. 
Should we add:
"The solution MUST work over any existing transport specified for SIP, 
including UDP"?

John

> =

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 11 Feb 2010 16:31:35 +0100

First, I think the argument that UDP is not a requirement came from the fact that SIPconnect 1.1 does not specify UDP. I am not sure that is a valid argument, since SIPconnect 1.1 applies only between the PBX and the border element in the SSP, not all the way to the SSP's registrar. However, I do agree that avoiding UDP on any such hop would be a good thing.

Secondly, even if the ability to operate over UDP is not a requirement, this does not mean there is a requirement for an explicit indication of the set of registered numbers in the REGISTER request. It still adds extra complexity, which should be avoided unless there is a specific requirement or there are significant drawbacks to not doing so.

I understand a concern has been expressed that implicit has proved to be a bad thing in the past in other contexts. To me, that is a rather nebulous argument, so I would like to hear more concrete arguments relating to this particular situation. Also, as stated on another thread, I don't think the mobility scenario raised by Dean is a sufficient argument.

I would not necessarily oppose including a list of intended E.164 numbers in the REGISTER message if that is what others want, but I get the impression a lot of people don't want that. It would make messages potentially very big, even for TCP. As a desirable we stated several hundred numbers. If none of these are adjacent, this could mean, say, 5000 number times 15 characters per number, or 750000 bytes / 6M bits. Admittedly this would be an extreme case, and in most large PBX cases I would expect considerable compression arising from the use of blocks of numbers, but it's a pretty huge SIP message.

John

> Sent: 11 February 2010 13:18
> To: Elwell, John; Bernard Aboba; [email-masked]; 'Hadriel Kaplan'