Subject: Re: [martini] #36: Reg-event package and individual extension state(section 7.2.2)

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 3 May 2010 15:19:19 +0200

It is not clear what you are referring to as a shared understanding,
so it is hard to answer that question. I am not sure there exists such
shared understanding yet.

/Hans Erik van Elburg

On Tue, Apr 27, 2010 at 2:23 AM, Bernard Aboba
<[email-masked]> wrote:
> Spencer said:
>
> "Speaking as co-chair...
>
> Should that shared understanding go in the (various) solution drafts?"
>
> [BA] I would think that it should go somewhere, certainly.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 3 May 2010 09:13:46 -0500

Hi, Hans Erik,

This pointed back to 
http://www.ietf.org/mail-archive/web/martini/current/msg01418.html, which 
referenced 
http://www.ietf.org/mail-archive/web/martini/current/msg01410.html - either 
a bulk registration "acts exactly like" a whole bunch of individual 
registrations, or it doesn't. We've spent a fair amount of time cycling on 
this as a working group - that's what I'd like to close on and document.

Spencer

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 3 May 2010 16:30:07 +0200

It doesn't.

The question is, if it is a relevant criterion at all. Sure a
particular solution can document that it has that property, fine.

/Hans Erik van Elburg

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 3 May 2010 11:44:01 -0500

Hi, Hans Erik,

Speaking as a participant, I agree, and speaking as co-chair, I think that's 
where the working group is on this topic.

Again, speaking as co-chair, my concern (and I BELIEVE that Bernard shares 
this concern, although he can school me about this if I got it wrong), is 
that as long as we haven't documented that consensus, we'll continue to 
cycle on this question, probably at the most inconvenient time (like, for 
example, IETF Last Call time for a specific solution draft).

That's the reason for my question, which I think is starting to turn into a 
co-chair suggestion to the editor for the requirements document, unless the 
working group disagrees - but I want to ask the working group, before 
telling the editor anything.

Spencer

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 3 May 2010 15:07:22 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hans Erik van Elburg
> Sent: Monday, May 03, 2010 10:30 AM
> 
> It doesn't.

In what way doesn't it?

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 3 May 2010 21:33:22 +0200

> In what way doesn't it?
In the way that a bulk registration does not have to "act exactly
like" a whole bunch of individual registrations and most probably
won't.

/Hans Erik van Elburg

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 3 May 2010 16:22:25 -0400

> particular solution can document that it has that property, fine.

I think it's pretty important to know what the bulk REGISTER does from a logical perspective.  A case in point is the reg-event handling.  

We either say "it is exactly a compressed form of multiple distinct REGISTERs for each AoR", or else we have to define exactly what it does mean, so that any and all uses of it can be discerned - if any future work done in DISPATCH/whatever deals with registered UA's explicitly, then it would have to take this "Registration of AoRs which is sort-of but not really a Registration of AoRs" into account as well.  

There're pro's/con's for dealing with it as a compressed form vs. some hybrid, but we do need to decide what it really is and document it.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Mon, 03 May 2010 16:43:08 -0500

On 5/3/10 2:33 PM, Hans Erik van Elburg wrote:
> On Mon, May 3, 2010 at 9:07 PM, Hadriel Kaplan<[email-masked]>  wrote:
>    
>>> It doesn't.
>>>        
>> In what way doesn't it?
>>
>>      

This is becoming as clear as mud. What property are you proposing the 
solution should exhibit? Can you propose some text?

/a

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 3 May 2010 23:48:07 +0200

> solution should exhibit? Can you propose some text?
I was responding to Spencer's call for common understanding. I was not
proposing any specific change for gin. I agree that this is maybe not
the right thread.

---

From: Adam Roach <[email-masked]>
Date: Mon, 03 May 2010 16:55:43 -0500

On 5/3/10 4:48 PM, Hans Erik van Elburg wrote:
> On Mon, May 3, 2010 at 11:43 PM, Adam Roach<[email-masked]>  wrote:
>    

Okay, so, in a different thread now: do you have any actionable comments 
regarding Spencer's call for consensus, or are you simply being contrarian?

I believe that the relevant text in GIN is:

    After the PBX is authenticated, the
    registrar updates its location service with a unique AOR to Contact
    mapping for each of the phone numbers associated with the PBX.
    Semantically, each of these mappings will be treated as a unique row
    in the location service.  The actual implementation may, of course,
    perform internal optimizations to reduce the amount of memory used to
    store such information.

If you think this is incorrect, please propose a concrete change.

/a

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 4 May 2010 00:34:11 +0200

I was reacting to Spencers question if martini should agree on
a-bulk-registratiuon-is-the-same-as-a-bunch-of-single-registrations
criterion that every solution should fulfill.
I was saying no it is not a relevant criterion. (If that makes me a
contrarian in your world, then so be it.)

I also said: "Sure a particular solution can document that it has that
property, fine."
So if GIN is claiming to have this property then I am fine with that.
(Not sure it is true though.)

So why do you want me to propose a change to gin in this respect??

/Hans Erik

---

From: Adam Roach <[email-masked]>
Date: Mon, 03 May 2010 18:20:05 -0500

> So why do you want me to propose a change to gin in this respect??

The actual question he asked ("Should that shared understanding go in 
the (various) solution drafts?") was specifically asking about what 
should or should not go into the solution drafts. GIN is a solutions 
draft. It sounded to me like you were trying to raise a point on this 
call for consensus, which I would expect to either take the form of 
either "yes, we need to add X to the solutions draft" or "no, I don't 
think we need to make any changes to the solutions draft on this topic."

At this point, I think you read Spencer's question as meaning something 
very different than I did.

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 3 May 2010 20:22:14 -0500

So, a few points, speaking as co-chair...

- I apologize for not asking a well-formed question clearly.

- We've had a couple of terse exchanges on the mailing list, that I had to 
go back and re-read before I understood the point being made (to me), and I 
can imagine that others were losing context as well.

- I'm thinking that my biggest contribution to confusion was not starting a 
new thread for my question (thank you, Adam, for forking), and making it 
more clear that I was asking in a REQUIREMENTS context, and not in a 
GIN/FRIENDS/OLIVE/VERMOUTH/etc. context. If I'm reading today's threads 
clearly, that clearly threw Adam off - I wasn't asking about a change to 
GIN, and I don't think Hans Erik (the non-contrarian) was talking about a 
change to GIN, either, but I don't seem to have made that point clearly.

- (the reason why I'm posting this note as chair is) What I'm concerned 
about is us (and not just MARTINI, but the entire SIP community) getting 
into a metaphysical debate about whether a solution that is NOT just the 
moral equivalent of a compressed string of REGISTERs is acceptable. Earlier 
today, I mentioned that I would expect any such debate to arise at the worst 
possible time, and I'd like to document working group consensus - if we can 
arrive at that consensus, so that we can quickly respond "yeah, we thought 
about that".

- (again, posting this specific point as chair) It seems to me that having 
this text in a solutions draft is the wrong place, because solutions would 
either have this attribute, or they wouldn't, so we couldn't declare 
consensus on this point while we're still chatting up the solution draft 
itself.

It's possible that all this is misplaced concern, and that we'll never need 
to document that it's important that a solutions draft does have the 
"compression-equivalent" property, or not (as in, "if GIN has this property 
and another solutions draft does not, is that a meaningful advantage for 
GIN?").

So, for instance, is it an advantage for a specific solution that a SIP-PBX 
can remove a single AOR/contact mapping that was registered as part of a 
bulk registration? If MARTINI=compress(individual REGISTERs), you could do 
that to an individually-REGISTERed mapping, couldn't you?

Thanks for any enlightenment that you guys can pass along, of course.

Spencer

----- Original Message ----- 
From: "Adam Roach" <[email-masked]>
To: "Hans Erik van Elburg" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>; <[email-masked]>; 
"Hadriel Kaplan" <[email-masked]>
Sent: Monday, May 03, 2010 6:20 PM
Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event package 
and individual extension state(section 7.2.2))

> The actual question he asked ("Should that shared understanding go in the 
> (various) solution drafts?") was specifically asking about what should or 
> should not go into the solution drafts. GIN is a solutions draft. It 
> sounded to me like you were trying to raise a point on this call for 
> consensus, which I would expect to either take the form of either "yes, we 
> need to add X to the solutions draft" or "no, I don't think we need to 
> make any changes to the solutions draft on this topic."
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 03 May 2010 21:24:23 -0500

I'm composing a longer response to some of the other points in Spencer's 
email, but wanted to chime in on the easy one before it slips my attention.

On 5/3/10 20:22, May 3, Spencer Dawkins wrote:
> So, for instance, is it an advantage for a specific solution that a 
> SIP-PBX can remove a single AOR/contact mapping that was registered as 
> part of a bulk registration? If MARTINI=compress(individual 
> REGISTERs), you could do that to an individually-REGISTERed mapping, 
> couldn't you?

Not sensibly. The problem is that the extension would be re-registered 
whenever you refreshed the bulk registration. This isn't unique to GIN 
-- it's pretty much a property of any system like the one you describe. 
So, the best you could do is de-register it every time you refresh the 
registration on the range. Even then, you'll have a race if, for 
example, an INVITE for the excluded extension arrives between the two 
REGISTER messages.

That's why we added text to GIN in the most recent revision that 
explicitly disallows this behavior (or, really, makes it a no-op). It's 
not a requirement to be able to de-register a single number out of a 
range, and the complications that arise if you try to do so are more 
work than they are worth.

/a

---

From: "Brian Lindsay" <[email-masked]>
Date: Mon, 3 May 2010 22:24:49 -0400

Hi Spencer,

  To chime in (and agree with Hans I think), I don't believe that the
requirements document should include this constraint and hence restrict
the set of solutions.

  Also, I don't agree with necessarily treating the gin bnc solution as
100% equivalent to a set of individual registrations, to the extent of
your "for instance" below. I much prefer the existing text in the gin
draft on this particular topic for example:

   "Although the SSP treats this registration as a number of discrete
   rows for the purpose of retargeting incoming requests, the renewal,
   expiration, and removal of these rows is bound to the registered
   "bnc" contact.  In particular, this means that REGISTER requests that
   attempt to de-register a single phone number that has been implicitly
   registered MUST NOT remove that phone number from the bulk
   registration."

  Thanks
     Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Spencer Dawkins
Sent: Monday, May 03, 2010 9:22 PM
To: Adam Roach; Hans Erik van Elburg
Cc: Bernard Aboba; Hadriel Kaplan; [email-masked]
Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event
packageand individual extension state(section 7.2.2))

- We've had a couple of terse exchanges on the mailing list, that I had
to go back and re-read before I understood the point being made (to me),
and I can imagine that others were losing context as well.

- I'm thinking that my biggest contribution to confusion was not
starting a new thread for my question (thank you, Adam, for forking),
and making it more clear that I was asking in a REQUIREMENTS context,
and not in a GIN/FRIENDS/OLIVE/VERMOUTH/etc. context. If I'm reading
today's threads clearly, that clearly threw Adam off - I wasn't asking
about a change to GIN, and I don't think Hans Erik (the non-contrarian)
was talking about a change to GIN, either, but I don't seem to have made
that point clearly.

- (the reason why I'm posting this note as chair is) What I'm concerned
about is us (and not just MARTINI, but the entire SIP community) getting
into a metaphysical debate about whether a solution that is NOT just the
moral equivalent of a compressed string of REGISTERs is acceptable.
Earlier today, I mentioned that I would expect any such debate to arise
at the worst possible time, and I'd like to document working group
consensus - if we can arrive at that consensus, so that we can quickly
respond "yeah, we thought about that".

- (again, posting this specific point as chair) It seems to me that
having this text in a solutions draft is the wrong place, because
solutions would either have this attribute, or they wouldn't, so we
couldn't declare consensus on this point while we're still chatting up
the solution draft itself.

It's possible that all this is misplaced concern, and that we'll never
need to document that it's important that a solutions draft does have
the "compression-equivalent" property, or not (as in, "if GIN has this
property and another solutions draft does not, is that a meaningful
advantage for GIN?").

So, for instance, is it an advantage for a specific solution that a
SIP-PBX can remove a single AOR/contact mapping that was registered as
part of a bulk registration? If MARTINI=compress(individual REGISTERs),
you could do that to an individually-REGISTERed mapping, couldn't you?

Spencer

----- Original Message -----
From: "Adam Roach" <[email-masked]>
To: "Hans Erik van Elburg" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>; <[email-masked]>;
"Hadriel Kaplan" <[email-masked]>
Sent: Monday, May 03, 2010 6:20 PM
Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event
package and individual extension state(section 7.2.2))

>> I also said: "Sure a particular solution can document that it has 
>> that property, fine."
> the
> (various) solution drafts?") was specifically asking about what should

> or should not go into the solution drafts. GIN is a solutions draft. 
> It sounded to me like you were trying to raise a point on this call 
> for consensus, which I would expect to either take the form of either 
> "yes, we need to add X to the solutions draft" or "no, I don't think 
> we need to make any changes to the solutions draft on this topic."
>
> At this point, I think you read Spencer's question as meaning 
> something very different than I did.

_______________________________________________
martini mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/martini

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 3 May 2010 22:58:34 -0500

As co-chair,

I'm replying to Brian's note, but have seen Adam's note as well...

Thanks for the feedback here.

My concern has been thrashing around since Bernard's "violates the principle 
of least astonishment" note 
(http://www.ietf.org/mail-archive/web/martini/current/msg01406.html). I'm 
doing better now.

Thanks,

Spencer

----- Original Message ----- 
From: "Brian Lindsay" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Adam Roach" 
<[email-masked]>; "Hans Erik van Elburg" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>; "Hadriel Kaplan" 
<[email-masked]>; <[email-masked]>
Sent: Monday, May 03, 2010 9:24 PM
Subject: RE: [martini] Not the same thread (was Re: #36: Reg-event 
packageand individual extension state(section 7.2.2))

Hi Spencer,

  Thanks
     Brian

-----Original Message-----

Spencer

---

From: Martien Huysmans <[email-masked]>
Date: Tue, 4 May 2010 11:57:01 +0200

Spencer

I am trying to follow and understand the discussion around "bulk registration" 
and "single AoR registration" and the RFC3621 principles that people refer to. 

The "principle of least astonishment" that Spencers mentions, 
has resulted in describing my astonishment in this email.
I hope that people forgive me if my astonishment is due to lack of understanding 
of the ongoing discussion.

- An PBX user registers with it's PBX. Standard RFC3261, so no astonishment.

- An PBX registers with the SSP, to be able to send and receive calls. No astonishment

- Having a second "single AoR registration" for that PBX user at the SSP feels strange.
  It seems to be independant of the registration of the PBX user in the PBX domain.
  In the SSP domain an "AOR -> Contact" mapping exists,
  even when the PBX user is not registered at the PBX.

- A call can be made towards an service in the PBX domain. 
  That service would not have a registration in the PBX domain, but would
  have a "single AoR registration" at the SSP domain. 

- Why mandate that an SSP needs to know the individual users behind an PBX?
  This may be valid for certain cases, but why have it as a general rule? 

Thanks Martien 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Tuesday, May 04, 2010 5:59 AM
To: Brian Lindsay; Adam Roach; Hans Erik van Elburg
Cc: Bernard Aboba; [email-masked]; Hadriel Kaplan
Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2))

As co-chair,

My concern has been thrashing around since Bernard's "violates the principle of least astonishment" note (http://www.ietf.org/mail-archive/web/martini/current/msg01406.html). I'm doing better now.

Thanks,

Spencer

----- Original Message -----
From: "Brian Lindsay" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Adam Roach" 
Subject: RE: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2))

Hi Spencer,

  To chime in (and agree with Hans I think), I don't believe that the requirements document should include this constraint and hence restrict the set of solutions.

  Also, I don't agree with necessarily treating the gin bnc solution as 100% equivalent to a set of individual registrations, to the extent of your "for instance" below. I much prefer the existing text in the gin draft on this particular topic for example:

  Thanks
     Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Monday, May 03, 2010 9:22 PM
To: Adam Roach; Hans Erik van Elburg
Cc: Bernard Aboba; Hadriel Kaplan; [email-masked]
Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2))

- We've had a couple of terse exchanges on the mailing list, that I had to go back and re-read before I understood the point being made (to me), and I can imagine that others were losing context as well.

- I'm thinking that my biggest contribution to confusion was not starting a new thread for my question (thank you, Adam, for forking), and making it more clear that I was asking in a REQUIREMENTS context, and not in a GIN/FRIENDS/OLIVE/VERMOUTH/etc. context. If I'm reading today's threads clearly, that clearly threw Adam off - I wasn't asking about a change to GIN, and I don't think Hans Erik (the non-contrarian) was talking about a change to GIN, either, but I don't seem to have made that point clearly.

- (the reason why I'm posting this note as chair is) What I'm concerned about is us (and not just MARTINI, but the entire SIP community) getting into a metaphysical debate about whether a solution that is NOT just the moral equivalent of a compressed string of REGISTERs is acceptable.
Earlier today, I mentioned that I would expect any such debate to arise at the worst possible time, and I'd like to document working group consensus - if we can arrive at that consensus, so that we can quickly respond "yeah, we thought about that".

- (again, posting this specific point as chair) It seems to me that having this text in a solutions draft is the wrong place, because solutions would either have this attribute, or they wouldn't, so we couldn't declare consensus on this point while we're still chatting up the solution draft itself.

It's possible that all this is misplaced concern, and that we'll never need to document that it's important that a solutions draft does have the "compression-equivalent" property, or not (as in, "if GIN has this property and another solutions draft does not, is that a meaningful advantage for GIN?").

So, for instance, is it an advantage for a specific solution that a SIP-PBX can remove a single AOR/contact mapping that was registered as part of a bulk registration? If MARTINI=compress(individual REGISTERs), you could do that to an individually-REGISTERed mapping, couldn't you?

Spencer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 4 May 2010 07:56:00 -0500

Hi, Martien,

You might get a different (and smarter) answer from other working group 
participants, but if I'm understanding your question, here's my answer.

What we're talking about is the case where the SP knows every AOR that it 
will forward INVITEs for, to the SIP-PBX. If the SP is going to forward 
INVITEs for AORs that it knows nothing about (and by "AOR", I probably mean 
"left hand/userpart"), it's going to have to base that forwarding decision 
on the AOR domain name.

We talked about doing dynamic registration for domains (the IETF 76 DISPATCH 
ad hoc was called "DREGS", which stood for "Domain Registration"), and 
decided (these are my words) that maintaining a parallel forwarding 
mechanism for strings that looked like domain names was not helpful (it 
generated concerns about "alt.root", among other concerns), and that anyone 
who really wanted to do this could use DYN-DNS to create the DNS entries 
needed, and then use RFC 3263 call routing for these INVITEs.

Does this answer make sense?

Spencer

----- Original Message ----- 
From: "Martien Huysmans" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Brian Lindsay" 
<[email-masked]>; "Adam Roach" <[email-masked]>; "Hans Erik van 
Elburg" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>; <[email-masked]>; 
"Hadriel Kaplan" <[email-masked]>
Sent: Tuesday, May 04, 2010 4:57 AM
Subject: RE: [martini] Not the same thread (was Re: #36: Reg-eventpackageand 
individual extension state(section 7.2.2))

Spencer

I am trying to follow and understand the discussion around "bulk 
registration"
and "single AoR registration" and the RFC3621 principles that people refer 
to.

The "principle of least astonishment" that Spencers mentions,
has resulted in describing my astonishment in this email.
I hope that people forgive me if my astonishment is due to lack of 
understanding
of the ongoing discussion.

- An PBX registers with the SSP, to be able to send and receive calls. No 
astonishment

- Having a second "single AoR registration" for that PBX user at the SSP 
feels strange.
  It seems to be independant of the registration of the PBX user in the PBX 
domain.
  In the SSP domain an "AOR -> Contact" mapping exists,
  even when the PBX user is not registered at the PBX.

Thanks Martien

-----Original Message-----
Of Spencer Dawkins

As co-chair,

Thanks,

Spencer

----- Original Message -----
From: "Brian Lindsay" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Adam Roach"

Hi Spencer,

  To chime in (and agree with Hans I think), I don't believe that the 
requirements document should include this constraint and hence restrict the 
set of solutions.

  Also, I don't agree with necessarily treating the gin bnc solution as 100% 
equivalent to a set of individual registrations, to the extent of your "for 
instance" below. I much prefer the existing text in the gin draft on this 
particular topic for example:

  Thanks
     Brian

-----Original Message-----
Of Spencer Dawkins

- (the reason why I'm posting this note as chair is) What I'm concerned 
about is us (and not just MARTINI, but the entire SIP community) getting 
into a metaphysical debate about whether a solution that is NOT just the 
moral equivalent of a compressed string of REGISTERs is acceptable.
Earlier today, I mentioned that I would expect any such debate to arise at 
the worst possible time, and I'd like to document working group consensus - 
if we can arrive at that consensus, so that we can quickly respond "yeah, we 
thought about that".

Spencer

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 4 May 2010 09:39:26 -0400

It's not even just E.164 *ranges* - it's ANY AoR of the set, and the set may not even be a range.  

I had assumed you could not de-register a "number in the middle" or *any* single AoR of the set, because it's illogical - by *definition* a bulk REGISTER expands to its AoR set by the provisioning.  So if the provisioning says "expand pbx123's REGISTER to [email-masked] and [email-masked]", then de-Registering "[email-masked]" will de-register it only until the next re-Register of pbx123.

So basically what the PBX would be doing by de-registering one member of the set is conflicting with the provisioning - it's like there's a mis-provisioning error going on.  Clearly a de-REGISTER will not, and is not intended to, "fix" this provisioning error.

What *should* happen is the SSP should change it's provisioning to no longer include the specific AoR in the "expansion set".  If we had a reg-event model, for example, the SSP systems could even Notify the PBX of the change - but it still wouldn't need or expect or be right for the PBX to send a de-REGISTER.

-hadriel

> From: Adam Roach [mailto:[email-masked]]
> Sent: Monday, May 03, 2010 10:24 PM
> To: Spencer Dawkins
>

---

From: Martien Huysmans <[email-masked]>
Date: Tue, 4 May 2010 16:37:50 +0200

Spencer

Txs for replying to the email. Unfortunately it doesn't take away my astonishment.

The 2nd paragraph has more depth. I will have a look at DRGS to digest that.

/Martien 

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Tuesday, May 04, 2010 2:56 PM
To: Martien Huysmans; Brian Lindsay; Adam Roach; Hans Erik van Elburg
Cc: Bernard Aboba; [email-masked]; Hadriel Kaplan
Subject: Re: [martini] Not the same thread (was Re: #36: Reg-eventpackageand individual extension state(section 7.2.2))

Hi, Martien,

You might get a different (and smarter) answer from other working group participants, but if I'm understanding your question, here's my answer.

What we're talking about is the case where the SP knows every AOR that it will forward INVITEs for, to the SIP-PBX. If the SP is going to forward INVITEs for AORs that it knows nothing about (and by "AOR", I probably mean "left hand/userpart"), it's going to have to base that forwarding decision on the AOR domain name.

We talked about doing dynamic registration for domains (the IETF 76 DISPATCH ad hoc was called "DREGS", which stood for "Domain Registration"), and decided (these are my words) that maintaining a parallel forwarding mechanism for strings that looked like domain names was not helpful (it generated concerns about "alt.root", among other concerns), and that anyone who really wanted to do this could use DYN-DNS to create the DNS entries needed, and then use RFC 3263 call routing for these INVITEs.

Spencer

----- Original Message -----
From: "Martien Huysmans" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Brian Lindsay" 
<[email-masked]>; "Adam Roach" <[email-masked]>; "Hans Erik van Elburg" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>; <[email-masked]>; "Hadriel Kaplan" <[email-masked]>
Sent: Tuesday, May 04, 2010 4:57 AM
Subject: RE: [martini] Not the same thread (was Re: #36: Reg-eventpackageand individual extension state(section 7.2.2))

Spencer

The "principle of least astonishment" that Spencers mentions, has resulted in describing my astonishment in this email.
I hope that people forgive me if my astonishment is due to lack of understanding of the ongoing discussion.

Thanks Martien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Tuesday, May 04, 2010 5:59 AM
To: Brian Lindsay; Adam Roach; Hans Erik van Elburg
Cc: Bernard Aboba; [email-masked]; Hadriel Kaplan
Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2))

As co-chair,

Thanks,

Spencer

----- Original Message -----
From: "Brian Lindsay" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Adam Roach"

Hi Spencer,

  Thanks
     Brian

-----Original Message-----

Spencer

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 4 May 2010 11:03:17 -0400

Hi Martien,
Just to be clear - what we're talking about is whether the bulk REGISTER should be logically equivalent to multiple individual/single REGISTERs for each AoR in the set.  But we don't actually mean multiple individual REGISTERs would be sent to the SSP.  No "real" user behind the PBX would ever send a REGISTER to the SSP - we're only talking about the REGISTER from the PBX, and whether the rules we define for that should be exactly the same as for some other world where the PBX sends each REGISTER separately for each AoR - but still the PBX would be the one sending those REGISTERs by itself, not the users behind the PBX.  In other words, imagine a multi-line UA/MTA/gateway which sends individual REGISTERs - is the bulk REGISTER just a compressed form of that, or something different?

(I think you were on the same page already, but I couldn't tell from some of your questions)

Other comments inline...

> From: Martien Huysmans [mailto:[email-masked]]
> Sent: Tuesday, May 04, 2010 5:57 AM
> To: Spencer Dawkins; Brian Lindsay; Adam Roach; Hans Erik van Elburg
> 

Sure, but what AoR is that PBX user actually Registering for?  I.e., does the PBX user's REGISTER To-URI have something like "sip:[email-masked]" in it?  Or is it an AoR of the actual PBX, like "sip:[email-masked]" or "sip:[email-masked]"?
That makes a big difference.

> - An PBX registers with the SSP, to be able to send and receive calls. No

Right, but it's Registering for an AoR *belonging to the SSP*.  I.e., "sip:[email-masked]".

>   even when the PBX user is not registered at the PBX.

Yup, and it *should*.  The PBX *is* the user, from the SSP's perspective.  It knows nothing about any possible UA's behind the PBX, and it doesn't care.  The SSP's E.164 was allocated to the PBX, effectively on a static basis.  If a call comes into the SSP for that AoR, it needs to route it to the PBX no matter what - for example if the "real" UA for that number isn't Registered in the PBX, the PBX might have voicemail, or might forward it to a receptionist or whatever.

>   This may be valid for certain cases, but why have it as a general rule?

It doesn't know about "individual users behind the PBX" - it knows about AoRs. 

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 5 May 2010 16:31:21 +0200

> Right, but it's Registering for an AoR *belonging to the SSP*.  I.e., "sip:[email-masked]".
[HE] Think it is more correct to say that it is registering
reachability information for a bulk contact, which is then bound by
the SSP to a bunch of implicitly registered AOR's. These AOR's dop not
have to belong to the SSP, but they can. The SSP's proxy is
responsible for handling them and forwarding them applying rules that
apply to bulk contacts.

> Yup, and it *should*.  The PBX *is* the user, from the SSP's perspective.  It knows nothing about any possible UA's behind the PBX, and it doesn't care.  The SSP's E.164 was allocated to the PBX, e…
[HE] The SSP's proxy knows that this is a bulkcontact and hence that
it is not the last responsible entity for the AOR. In fact this is not
a normal "single AoR registration" it is really a special one. The
description that describes the semantics in terns of single location
service entries, is just a way of expressing it. We should not confuse
this to mean that the bulkregistration created entry is just like a
normal registration. Therefore the current semantics description might
be misleading, but I always thought  that it wasn't as it explicitly
says that you do not have to implement it like that.

> It doesn't know about "individual users behind the PBX" - it knows about AoRs.
[HE] Yes, for once I agree. This is no different then the IMS solution
where Wildcarded PUI's or Distinct PUI's are implicitly registered.
Those have to be provisioned in the HSS of the SSP. How you do that
and if you give companies a means to provision this themsleves using
some portal or so, is outside the scope of the martini discussion. But
it can be done.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 May 2010 19:03:52 -0400

> responsible for handling them and forwarding them applying rules that

We've been through this before :-(

If the domain of the request, when it arrives at the SSP, is not a 
domain it is responsible for, then it is bound to deliver it using 
3261/3263 rules. SSP.com has no business making side agreements on where 
to route requests for other domains.

Otherwise, I'm going to sign up my pbx with your SSP and ask to have 
sip:[email-masked] be one of my implicitly registered AORs.

This kind of routing *must* be restricted to domains the SSP is 
responsible for.

	Thanks,
	Paul

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 6 May 2010 08:08:38 +0200

> We've been through this before :-(
People still seem to misunderstand the implications though. Looking at
the conclusions that people draw from this.

> If the domain of the request, when it arrives at the SSP, is not a domain it
> is responsible for, then it is bound to deliver it using 3261/3263 rules.
> SSP.com has no business making side agreements on where to route requests
> for other domains.
>
Correct. The key phrasing is here "responsible for".  If the SSP has
an agreement with the owner of the domain "company.com" that it will
handle incoming traffic for that company, then the SSP's proxy is
configured to be "responsible" for that domain. And it would also need
to make this known into DNS so that traffic for that domain will be
delivered to the SSP.

> sip:[email-masked] be one of my implicitly registered AORs.
You can ask watever you want, but your SSP is not going to configure
that for you unless you own the domain whitehgouse.gov and are the
person that is allowed to make such requests under the agreement
between the SSP and company.com.

> This kind of routing *must* be restricted to domains the SSP is responsible
> for.
>
Yes, I agree. But if it is responsible for a domain it does not mean
that it owns the domain.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 May 2010 14:29:02 -0400

> to make this known into DNS so that traffic for that domain will be

I think this is not good enough.
If I come to the SSP and sign it up to forward incoming traffic for 
whitehouse.gov to me, how is it supposed to determine if I am the 
rightful owner of that domain? And if I am, now does it determine if I 
continue to be?

You might argue: what's the harm? If I'm not the owner of whitehouse.gov 
then I won't be able to update DNS to direct whitehouse.gov traffic to 
the SSP. But there is still harm, because even without that I can then 
snag any traffic for whitehouse.gov that is originated by another of the 
SSP's customers.

Its a different situation if the SSP acquires a domain name of my choice 
on my behalf. Then it clearly is responsible for the domain.

The fuzzy area is where I acquire rights to the domain name, and update 
DNS to direct sip traffic to the SSP. In that case, what you suggest 
should work, if there was a way to ensure that I own the rights to that 
domain, and thus have the right to delegate responsibility for it to the 
SSP. In principle that should be ok, but I don't know how the SSP learns 
this and also learns if/when the ownership changes.

	Thanks,
	Paul

---

From: Martien Huysmans <[email-masked]>
Date: Mon, 10 May 2010 12:41:13 +0200

Paul

The answer confuses me. You start by saying "I think this is not good enough'.
and then you email ends with "In principle that should be ok". And this for
a first and last paragraph that include similar questions.

Isn't the domain name ownership really a security related question?

/Martien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, May 07, 2010 8:29 PM
To: Hans Erik van Elburg
Cc: Bernard Aboba; [email-masked]; Hadriel Kaplan
Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2))

Hans Erik van Elburg wrote:
>>> On Tue, May 4, 2010 at 5:03 PM, Hadriel Kaplan 
>>> <[email-masked]>
>>> wrote:
>>>
>>> the SSP to a bunch of implicitly registered AOR's. These AOR's dop 
>>> not have to belong to the SSP, but they can. The SSP's proxy is 
>>> responsible for handling them and forwarding them applying rules 
>>> that apply to bulk contacts.
>> domain it is responsible for, then it is bound to deliver it using 3261/3263 rules.
>> SSP.com has no business making side agreements on where to route 
>> requests for other domains.
>>

I think this is not good enough.
If I come to the SSP and sign it up to forward incoming traffic for whitehouse.gov to me, how is it supposed to determine if I am the rightful owner of that domain? And if I am, now does it determine if I continue to be?

You might argue: what's the harm? If I'm not the owner of whitehouse.gov then I won't be able to update DNS to direct whitehouse.gov traffic to the SSP. But there is still harm, because even without that I can then snag any traffic for whitehouse.gov that is originated by another of the SSP's customers.

Its a different situation if the SSP acquires a domain name of my choice on my behalf. Then it clearly is responsible for the domain.

The fuzzy area is where I acquire rights to the domain name, and update DNS to direct sip traffic to the SSP. In that case, what you suggest should work, if there was a way to ensure that I own the rights to that domain, and thus have the right to delegate responsibility for it to the SSP. In principle that should be ok, but I don't know how the SSP learns this and also learns if/when the ownership changes.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 May 2010 07:29:18 -0700

> You can ask whatever you want, but your SSP is not going to configure 
> that for you unless you own the domain whitehouse.gov and are the 

Just to be clear -- this particular issue isn't unique to MARTINI.  It's also not confined to dynamic registration.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 May 2010 10:49:16 -0400

> a first and last paragraph that include similar questions.

My "is not good enough" statement was in regard to there simply being an 
agreement between pbx and SSP that the ssp will direct traffic for some 
AOR to the pbx. IMO there needs to be a stronger meaning to "is 
responsible for", that is consistent with 3263. That is, unfortunately, 
currently lacking from 3261 and 3263.

My latter statement was narrower:
- it assumes that there is indeed a DNS registration, owned by the owner 
of the pbx, but pointing to the SSP's servers

- that there is a way for the SSP to ascertain that DNS has been so 
provisioned

> Isn't the domain name ownership really a security related question?

I suppose so. At least, if strong e2e identity was in place then defects 
in routing would eventually be detected. But of course an e2e identity 
mechanism isn't widely in place. Having it would imply certs in place in 
the pbxes or phones behind them. That seems inconsistent with the 
assumptions of this work - that the pbx probably doesn't even have a 
domain name.

	Thanks,
	Paul