Subject: [martini] GIN and anonymous GRUUS

From: Cullen Jennings <[email-masked]>
Date: Tue, 18 May 2010 19:18:31 -0600

I think the anonymous public GRUUs need some work. Imagine that I have a small PBX at a women's shelter. Say they are 5 to 10 phones or so and this PBX connects to an SSP. I think this is one of the use cases we need anonymous calls to work for and when someone makes a call from one of these phones, it can not reveal they are at the women's shelter. Anonymizing which room they are in at the women's shelter is not enough. I'll ignore the self make GRUU section because if you could to that, well you would not need GIN in the first place. 

Moving on to the Approach 2 - it seem that the PBX needs to get an anonymous GRUU from the SSP then use that to fabricate it's anonymous GRUU. I think that if you modified what you have in the draft now to use anonymous GRUUs from the SSP, you could get this to work. 

I think it would be worth adding an example showing an anonymous call. I know lots of people goes "who cares, that's a corner case" but many of the environments where we want to deploy GIN, it will be a requirement to support anonymous call - not many people need them but governments are pretty adamant about making sure the people who do need them can have them. 

Could you put a Note telling the RFC Ed to remove section 9. If anyone ever needs to read that they can find the draft. 

Nice draft - can't say I like it but I can live with it and I suspect most people will come to the same conclusion after thinking about it for awhile. Something most people can live with I view as huge success for this topic. It will be infinitely better than the current situation of many things that sounds close but when you look at them in detail don't interoperate. 

Thanks, Cullen

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, 19 May 2010 10:29:08 +0200

Cullen makes a good point. In general, MARTINI is targeted at small PBXs, so often an "anonymous" GRUU that still reveals the name of the business will not be sufficient, since the number of users might be very small, they all might be located in the same office, and so on.

John 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: 19 May 2010 02:19
> To: [email-masked]
> Subject: [martini] GIN and anonymous GRUUS
> 
> 
> I think the anonymous public GRUUs need some work. Imagine 
> that I have a small PBX at a women's shelter. Say they are 5 
> to 10 phones or so and this PBX connects to an SSP. I think 
> this is one of the use cases we need anonymous calls to work 
> for and when someone makes a call from one of these phones, 
> it can not reveal they are at the women's shelter. 
> Anonymizing which room they are in at the women's shelter is 
> not enough. I'll ignore the self make GRUU section because if 
> you could to that, well you would not need GIN in the first place. 
> 
> Moving on to the Approach 2 - it seem that the PBX needs to 
> get an anonymous GRUU from the SSP then use that to fabricate 
> it's anonymous GRUU. I think that if you modified what you 
> have in the draft now to use anonymous GRUUs from the SSP, 
> you could get this to work. 
> 
> I think it would be worth adding an example showing an 
> anonymous call. I know lots of people goes "who cares, that's 
> a corner case" but many of the environments where we want to 
> deploy GIN, it will be a requirement to support anonymous 
> call - not many people need them but governments are pretty 
> adamant about making sure the people who do need them can have them. 
> 
> Could you put a Note telling the RFC Ed to remove section 9. 
> If anyone ever needs to read that they can find the draft. 
> 
> Nice draft - can't say I like it but I can live with it and I 
> suspect most people will come to the same conclusion after 
> thinking about it for awhile. Something most people can live 
> with I view as huge success for this topic. It will be 
> infinitely better than the current situation of many things 
> that sounds close but when you look at them in detail don't 
> interoperate. 
> 
> Thanks, Cullen
> 
> 
> 
> 
> Cullen Jennings
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 May 2010 09:17:32 -0500

I'm sympathetic to the point, but don't think it's something that 
MARTINI can appropriately solve. What's critical here is to realize that 
GIN does not make this problem any better or worse than the base GRUU 
mechanism.

For example, in a "normal" (i.e., 3263-routed, GIN-free) environment, 
imagine you came into possession of a temp GRUU 
"sip:[email-masked]". And, 
after a little research, you determine that the company does, in fact, 
consist of exactly two guys and their goat. You can be pretty certain 
that the call came from one of the two guys who comprise the company 
(unless the goat is really quite talented).

So, yeah, it's a shortcoming of GRUUs in general. If you want to solve 
this problem, what is really needed is for you to take an rfc5627bis to 
DISPATCH.

But I think it's a bit of a stretch to say "GRUUs as currently defined 
have this shortcoming. You mentioned GRUUs, and in doing so, inherited 
the shortcoming. Now fix it!"

/a

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 19 May 2010 16:32:18 +0200

Adam,

Although I was generalising the use case that Cullen put forward, doesn't the existing approach 2 satisfy this anyway?

John

> From: Adam Roach [mailto:[email-masked]] 
> Sent: 19 May 2010 15:18
> To: Elwell, John
> Cc: Cullen Jennings; [email-masked]
> Subject: Re: [martini] GIN and anonymous GRUUS
> 
> > Cullen makes a good point. In general, MARTINI is targeted 
> at small PBXs, so often an "anonymous" GRUU that still 
> reveals the name of the business will not be sufficient, 
> since the number of users might be very small, they all might 
> be located in the same office, and so on.
> >
> > John
> >
> >

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 May 2010 10:14:48 -0500

Actually, you're right. I just re-read the "anonymous public GRUU" 
section again, and it doesn't reveal the information that we're fretting 
about. (I also found a minor error in some of the examples, but I'm 
fixing that in -03).

The example that the document gives for one of these GRUUs looks like this:

sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=0UYYRV046P

Going to Cullen's concern: if I got one of these URIs, it's not clear 
what part of that I could mine to find out whether it was a Women's 
Shelter (unless example.com has precisely one customer, in which case I 
don't think there's anything we can do anyway).

Cullen: can you elaborate on your use case, providing specific examples 
of the URIs that you think leak information?

/a

On 5/19/10 9:32 AM, Elwell, John wrote:
>>>> adamant about making sure the people who do need them can
>>>>          
>> have them.
>>

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 May 2010 10:32:01 -0500

On 5/18/10 8:18 PM, Cullen Jennings wrote:
> I'll ignore the self make GRUU section because if you could to that, well you would not need GIN in the first place.

I'm not so certain that's true. The only thing that would preclude this 
use case in normal situations would the the presence of an intervening 
NAT. And, while that's actually pretty common, I would argue that it's 
not 100% universal in SOHO deployments. I can still pay my DSL provider 
for 5 public IP addresses if I so desire (it's actually a /29, but you 
lose three addresses to network, broadcast, and router). It's not 
far-fetched to imagine situations where I've done that, but still want 
to use an SSP for my VoIP needs. And, if the SSP is only willing to do 
SIP trunking using a dynamic registration scheme, then I'll have to use 
GIN or something similar.

Does this work everywhere? No, of course not. Some people will put their 
PBXes behind NATs. Will there be enough situations where this works to 
make it worthwhile mentioning? Yeah, I think so -- especially when we 
move to IPv6. (This isn't a pipe-dream anymore. Comcast is in trials, 
and plans system-wide roll-out by 2012. I've seen rumors that they're 
doing proper subnet delegation -- at least for one of three variations 
they're trialing -- meaning customers will have several thousand 
routable addresses instead of the 5 I mention.)

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 May 2010 10:44:23 -0500

> Could you put a Note telling the RFC Ed to remove section 9. If anyone ever needs to read that they can find the draft.

I'm indifferent as to whether it stays in. Does anyone object to 
removing it?

/a

---

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Wed, 19 May 2010 11:45:52 -0400

They can find it where? please

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adam Roach
Sent: Wednesday, May 19, 2010 11:44 AM
To: Cullen Jennings
Cc: [email-masked]
Subject: [martini] GIN: Removing Section 9 (Requirements Analysis)?

On 5/18/10 8:18 PM, Cullen Jennings wrote:
> Could you put a Note telling the RFC Ed to remove section 9. If anyone
ever needs to read that they can find the draft.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 May 2010 10:58:14 -0500

I'm not sure the question is whether the information can be found later, 
as much as whether it's useful as an artifact. Sure, we need to make 
sure the solution satisfies the requirements document -- but does it 
make sense to include that analysis in the RFC?

Like I said, I don't really care one way or another. But I do want to 
make sure we're focusing on the right question here: "is this 
information useful to retain?" Being able to find useless information at 
a future date is pretty inconsequential.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 May 2010 18:45:37 +0200

Hi,

I don't have any strong opinions regarding the actual analysis, but I think it at least should be indicated that the draft fulfills all requirements in the req draft.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Adam Roach [[email-masked]]
Sent: Wednesday, May 19, 2010 6:58 PM
To: DOLLY, MARTIN C (ATTLABS)
Cc: [email-masked]
Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)?

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 19 May 2010 12:10:05 -0500

Speaking as an individual:

OK, a couple of things ...

I'm seeing IETF-hosted web pages for RFCs that point back to all previous 
draft versions of the document, so it's not IMPOSSIBLE for someone to find 
section 9 in a draft, when they're looking at the RFC using those pages, but 
a lot of versions of RFC URLs don't have this attribute, so it's harder than 
it should be, and likely to stay harder than it should be for a few years at 
a minumum. I think if we pull section 9, there will be a lot more people who 
never see it, who are left to wonder how GIN meets the MARTINI requirements.

I would like to retain section 9, but if the working group doesn't have 
conensus to do that, I'd like to see Christers suggestion taken to heart, so 
we don't lose track of the discussion when looking back, but at a minimum, 
we need to say "yes, this matches the requirements - we checked".

Thanks,

Spencer

----- Original Message ----- 
From: "Christer Holmberg" <[email-masked]>
To: "Adam Roach" <[email-masked]>; "DOLLY, MARTIN C (ATTLABS)" 
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Wednesday, May 19, 2010 11:45 AM
Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)?

> Hi,
>
> I don't have any strong opinions regarding the actual analysis, but I 
> think it at least should be indicated that the draft fulfills all 
> requirements in the req draft.
>
> Regards,
>
> Christer
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 May 2010 13:11:56 -0400

> sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=0UYYRV046P 

The above doesn't sound right. A public gruu for the pbx ought to look like:

sip:[email-masked];gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

So anything derived off of it, for use as temp gruus, would also contain 
the identification of the pbx.

If the pbx also got a temp-gruu assigned by the ssp, then it could 
derive its own temp gruus off of that. But assigning temp gruus for a 
pbx registration is going to be problematic:

*Every* time a REGISTER (or re-REGISTER) request is processed, if the 
registrar supports temp-gruus and the registering UA supports gruu, then 
a new temp-gruu is assigned and returned. In principle that applies to 
implicitly registered AORs as well. There will be a new temp-gruu for 
*each* implicitly registered AOR. Those aren't returned, but if there is 
a subscription to the reg event package convering those AORs, then it 
will need to generate a notification containing all those temp-gruus. 
(See RFC 5628.) There is no good way to know if those are desired, so 
they are to be generated regardless. This works for the small numbers of 
implicit AORs used in IMS (ignoring the pbx stuff). But it could be a 
lot of work to generate, and a big notification to deliver all those 
temp gruus. And it will happen again every time the registration is 
refreshed.

So, till now we GIN says not to generate temp gruus.

If we need the SSP to generate a temp gruu for the pbx to use in 
generating its own temp gruus, but we don't want the ssp to generate 
temp gruus for all the implicitly registered AORs, then some added 
specification is required.

	Thanks,
	Paul

>> Although I was generalising the use case that Cullen put forward, 
>> doesn't the existing approach 2 satisfy this anyway?
>>
>> John
>>
>>
>>

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 May 2010 13:25:42 -0500

On 5/19/10 12:11 PM, Paul Kyzivat wrote:
>> section again, and it doesn't reveal the information that we're 
>> fretting about. (I also found a minor error in some of the examples, 
>> but I'm fixing that in -03).
>>

Not in this context.

Remember that what we're doing is semantically equivalent to registering 
multiple AORs, not a single AOR. And the public GRUU for each of those 
AORs needs to be the AOR itself, plus the gruu parameters. So, at least 
for a "bnc" contact, we need to get back a "bnc" public gruu. It is a 
username-free template, just like the "bnc" contact itself. (The PBX is 
responsible for "expanding" the template before handing it to its 
endpoints).

Now, if you included a non-"bnc" contact in a REGISTER request, it would 
be associated with a public gruu of the format you describe. But that's 
not what we're discussing here.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 May 2010 14:47:39 -0400

> responsible for "expanding" the template before handing it to its 

Hmm. That is different than what one would expect without the BNC but 
with implicit registration. But it is what you have in the draft. 
Assuming it works that way, the returned pub-gruu:

sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

is just a template for pub-gruus for each registered AOR. The *actual* 
pub-gruus are then:

sip:[email-masked];gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

etc. AFAIK there is no implication that
sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
is itself a valid gruu, since it doesn't correspond to any AOR.

Hence I think one must take one of the *actual* gruus to derive the temp 
gruus. And those would, in some sense, expose the identity of the pbx, 
which is Cullen's issue.

	Thanks
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 May 2010 17:41:13 -0600

On May 19, 2010, at 8:17 AM, Adam Roach wrote:

> MARTINI can appropriately solve.

I'm not asking martini to solve anything, just not break anything that's already in 3261 and 5627. 

> What's critical here is to realize that

So I really don't care that the people can track it down to the level of SSP. In the use cases most people are concerned with the SSP is large enough that it is OK.  If the goat running the SSP wants to protect it's privacy it could easily go and get a free domain from dyndsn such as really-im-a-dog.doesntexist.com and use that domain to form the GRUU. 

5627 put a ton of work into making sure this all works and was no worse than 3261 - it did this with the temp gruu. What I think you need to do here is use the temp gruu instead of the public gruu for anonymous call. It's really not much different than what the draft has now. 

> this problem, what is really needed is for you to take an rfc5627bis to

Luckily, 5627 already has a solution that solves the problem to the level I care about.

> the shortcoming. Now fix it!"

sure - I'm not asking for that. And when we did 5627, we did not try and deal with the parts that 3261 did not have a solution too ( that being the IP addresses the RTP packets might be going to) but we decided not to make the situation work as well as 3261. 

Cullen Jennings

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 May 2010 20:07:15 -0400

> 5627 put a ton of work into making sure this all works and was no worse than 3261 - it did this with the temp gruu. What I think you need to do here is use the temp gruu instead of the public gruu…

I commented on this approach in:

http://www.ietf.org/mail-archive/web/martini/current/msg01565.html

I think we would at least have to tweak the ssp temp gruu mechanism so 
that it doesn't have to generate a unique temp gruu for every phone on 
the pbx, and notify with them, every time the pbx refreshes its 
registration.

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 20 May 2010 07:41:12 -0600

I'd rather see the analysis of if the GIN draft meets the requirements done in the requirements draft and the GIN draft have an reference to the requirements draft. I don't really care much one way or the other but I am getting steadily more allergic to drafts that huge swaths of text that totally useless to people trying to implement the protocol. It just convinces implementors it is big and complicated and they don't want to do it. 

On May 19, 2010, at 11:10 AM, Spencer Dawkins wrote:

> I'm seeing IETF-hosted web pages for RFCs that point back to all previous draft versions of the document, so it's not IMPOSSIBLE for someone to find section 9 in a draft, when they're looking at the RFC using those pages, but a lot of versions of RFC URLs don't have this attribute, so it's harder than it should be, and likely to stay harder than it should be for a few years at a minumum. I think if we pull section 9, there will be a lot more people who never see it, who are left to wonder how GIN meets the MARTINI requirements.
> 
> I would like to retain section 9, but if the working group doesn't have conensus to do that, I'd like to see Christers suggestion taken to heart, so we don't lose track of the discussion when looking back, but at a minimum, we need to say "yes, this matches the requirements - we checked".
> 
> Thanks,
> 
> Spencer
> 
> ----- Original Message ----- From: "Christer Holmberg" <[email-masked]>
> To: "Adam Roach" <[email-masked]>; "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>

Cullen Jennings

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 20 May 2010 15:50:48 +0200

Cullen,

I think that is the wrong way round. A requirements document is generally written before solution documents. And suppose some requirements are not met until a later solutions document, e.g., olive. Does that mean we can't put the requirements document to bed before olive is finished?

On the other hand, I tend to agree with you that implementers don't like too much useless material. We had a pretty good evaluation of gin against requirements at IETF#77 on slides, and it is that that is captured in the latest gin draft. The analysis has changed very little, except that a couple of new requirements have been added. The IETF#77 MARTINI minutes, with pointer to the slides, goes a long way to showing that we have done due diligence in ensuring the solution meets the requirements. OR we could post updated text on the mailing list, so that it appears in the archive. Do we really need to encumber either draft with this lengthy text?

John

> Sent: 20 May 2010 14:41
> To: Spencer Dawkins
> I'd rather see the analysis of if the GIN draft meets the 
> requirements done in the requirements draft and the GIN draft 
> have an reference to the requirements draft. I don't really 
> care much one way or the other but I am getting steadily more 
> allergic to drafts that huge swaths of text that totally 
> useless to people trying to implement the protocol. It just 
> convinces implementors it is big and complicated and they 
> don't want to do it. 
> 
> 
> 
> > I'm seeing IETF-hosted web pages for RFCs that point back 
> to all previous draft versions of the document, so it's not 
> IMPOSSIBLE for someone to find section 9 in a draft, when 
> they're looking at the RFC using those pages, but a lot of 
> versions of RFC URLs don't have this attribute, so it's 
> harder than it should be, and likely to stay harder than it 
> should be for a few years at a minumum. I think if we pull 
> section 9, there will be a lot more people who never see it, 
> who are left to wonder how GIN meets the MARTINI requirements.
> > 
> > I would like to retain section 9, but if the working group 
> doesn't have conensus to do that, I'd like to see Christers 
> suggestion taken to heart, so we don't lose track of the 
> discussion when looking back, but at a minimum, we need to 
> say "yes, this matches the requirements - we checked".
> > 
> > Thanks,
> > 
> > Spencer
> > 
> >> I don't have any strong opinions regarding the actual 
> analysis, but I think it at least should be indicated that 
> the draft fulfills all requirements in the req draft.
> >> 
> >> Regards,
> >> 
> >> Christer
> >> 
> >> From: [email-masked] [[email-masked]] 
> On Behalf Of Adam Roach [[email-masked]]
> [mailto:[email-masked]] On
> >>> Behalf Of Adam Roach

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 20 May 2010 08:04:28 -0600

So I think this conversation is going a good way to find a solution to this. For a second, lets just consider the B2BUA style PBX. 

Lets say that the PBX has 10 phones that register with the PBX and the PBX does one registration with the SSP that uses GIN with GRUU. The phones may not even support GRUU and their registration have very little to do with the registration to the SSP. I realize that to get a temp GRUU to each of the phones, we would either need a way for the PBX to generate multiple temp GRUU based on some template it got from the SSP or the PBX would need to get multiple temp GRUU from the SSP. We should look at if there is a reasonable design to achieve either of those that does not require changes to GRUU. I suspect their might be. But even if there is not, I think there is a simple solution to this.

Keep in mind my issue is not the phones all all temp gruu, my issues is that anonymous calls need to not reveal which PBX it is. So one solution would be to have the PBX get a single temp GRUU and when the PBX makes an anonymous call  to the SSP use the temp gruu then get some more temp gruu for future use. This would probably work better if it had a small pool of available temp gruu for use when a temp gruu is need but you get the idea. 

Another option would be just to have the GIN draft request the number of temp GRUU that the PBX wants the SSP to return. 

There's a ton of way to skin this cat but I am strongly against depreciating anonymous call support of 3261 when using the GIN draft - I view that as GIN breaking SIP. It's a critical feature when using SIP for PSTN replacement and I believe it has very important value many types of SIP communication. 

On May 19, 2010, at 11:11 AM, Paul Kyzivat wrote:

> 
> 
> Adam Roach wrote:
>> Actually, you're right. I just re-read the "anonymous public GRUU" section again, and it doesn't reveal the information that we're fretting about. (I also found a minor error in some of the examples, but I'm fixing that in -03).
> So anything derived off of it, for use as temp gruus, would also contain the identification of the pbx.
> 
> If the pbx also got a temp-gruu assigned by the ssp, then it could derive its own temp gruus off of that. But assigning temp gruus for a pbx registration is going to be problematic:
> 
> *Every* time a REGISTER (or re-REGISTER) request is processed, if the registrar supports temp-gruus and the registering UA supports gruu, then a new temp-gruu is assigned and returned. In principle that applies to implicitly registered AORs as well. There will be a new temp-gruu for *each* implicitly registered AOR. Those aren't returned, but if there is a subscription to the reg event package convering those AORs, then it will need to generate a notification containing all those temp-gruus. (See RFC 5628.) There is no good way to know if those are desired, so they are to be generated regardless. This works for the small numbers of implicit AORs used in IMS (ignoring the pbx stuff). But it could be a lot of work to generate, and a big notification to deliver all those temp gruus. And it will happen again every time the registration is refreshed.
> 
> If we need the SSP to generate a temp gruu for the pbx to use in generating its own temp gruus, but we don't want the ssp to generate temp gruus for all the implicitly registered AORs, then some added specification is required.
> 
> 	Thanks,
> 	Paul
> 
>> Going to Cullen's concern: if I got one of these URIs, it's not clear what part of that I could mine to find out whether it was a Women's Shelter (unless example.com has precisely one customer, in which case I don't think there's anything we can do anyway).
>> Cullen: can you elaborate on your use case, providing specific examples of the URIs that you think leak information?
>> /a

Cullen Jennings

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 May 2010 10:21:43 -0400

Cullen,

Focusing on the B2BUA PBX case, the contact address that the outside 
world sees will be one inserted by the pbx b2bua, not the one inserted 
by the phone. In that case, there are two issues:
- how does the phone indicate it wants to make an anonymous call?
   (Privacy header?)
- how does the pbx get a supply of anonymous gruus?
There is in that case no need to convey anonymous gruus to the phones.

(The above assumes privacy only for calls to the outside world. Privacy 
on calls between phones connected to the same pbx is a *little* 
different. If there is still a b2bua in the path, its more or less the 
same, except that contact used probably won't be a gruu at all, just 
something cooked up by the b2bua for local use.)

So, in this case the hard part is to get a temp gruu for the pbx to use. 
Assuming the ssp registrar supports temp gruus, this is doable, but 
there are potential efficiency issues. I'm now wondering if those need 
to be investigated, or if they can be left as implementation issues.

We haven't spoken much about the pbx-as-proxy case. That is a bit more 
difficult, because it becomes necessary to convey temp gruus to the phones.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Thu, 20 May 2010 12:37:42 -0500

Okay, wait. Before we go trundling down the "let's re-engineer this" 
hole, I'd like someone to concisely state what's wrong with the 
currently proposed mechanism. There's a lot of back-to-the-drawing-board 
proposals implied by the last few messages, without any clear indication 
why. The one use "issue," raised by Cullen, appears to be based on a 
misunderstanding. Everything else looks like an "ooh, shiny!" race off 
to see if we can design something else just for the fun of it.

/a

On 5/20/10 9:21 AM, Paul Kyzivat wrote:
> (The above assumes privacy only for calls to the outside world. 
> Privacy on calls between phones connected to the same pbx is a 
> *little* different. If there is still a b2bua in the path, its more or 
> less the same, except that contact used probably won't be a gruu at 
> all, just something cooked up by the b2bua for local use.)
>
> So, in this case the hard part is to get a temp gruu for the pbx to 
> use. Assuming the ssp registrar supports temp gruus, this is doable, 
> but there are potential efficiency issues. I'm now wondering if those 
> need to be investigated, or if they can be left as implementation issues.
>
>> So I think this conversation is going a good way to find a solution 
>> to this. For a second, lets just consider the B2BUA style PBX.
>> Lets say that the PBX has 10 phones that register with the PBX and 
>> the PBX does one registration with the SSP that uses GIN with GRUU. 
>> The phones may not even support GRUU and their registration have very 
>> little to do with the registration to the SSP. I realize that to get 
>> a temp GRUU to each of the phones, we would either need a way for the 
>> PBX to generate multiple temp GRUU based on some template it got from 
>> the SSP or the PBX would need to get multiple temp GRUU from the SSP. 
>> We should look at if there is a reasonable design to achieve either 
>> of those that does not require changes to GRUU. I suspect their might 
>> be. But even if there is not, I think there is a simple solution to 
>> this.
>>
>> Keep in mind my issue is not the phones all all temp gruu, my issues 
>> is that anonymous calls need to not reveal which PBX it is. So one 
>> solution would be to have the PBX get a single temp GRUU and when the 
>> PBX makes an anonymous call  to the SSP use the temp gruu then get 
>> some more temp gruu for future use. This would probably work better 
>> if it had a small pool of available temp gruu for use when a temp 
>> gruu is need but you get the idea.
>> Another option would be just to have the GIN draft request the number 
>> of temp GRUU that the PBX wants the SSP to return.
>> There's a ton of way to skin this cat but I am strongly against 
>> depreciating anonymous call support of 3261 when using the GIN draft 
>> - I view that as GIN breaking SIP. It's a critical feature when using 
>> SIP for PSTN replacement and I believe it has very important value 
>> many types of SIP communication.
>>
>>
>>>> fretting about. (I also found a minor error in some of the 
>>>> examples, but I'm fixing that in -03).
>>> derive its own temp gruus off of that. But assigning temp gruus for 
>>> a pbx registration is going to be problematic:
>>>
>>> *Every* time a REGISTER (or re-REGISTER) request is processed, if 
>>> the registrar supports temp-gruus and the registering UA supports 
>>> gruu, then a new temp-gruu is assigned and returned. In principle 
>>> that applies to implicitly registered AORs as well. There will be a 
>>> new temp-gruu for *each* implicitly registered AOR. Those aren't 
>>> returned, but if there is a subscription to the reg event package 
>>> convering those AORs, then it will need to generate a notification 
>>> containing all those temp-gruus. (See RFC 5628.) There is no good 
>>> way to know if those are desired, so they are to be generated 
>>> regardless. This works for the small numbers of implicit AORs used 
>>> in IMS (ignoring the pbx stuff). But it could be a lot of work to 
>>> generate, and a big notification to deliver all those temp gruus. 
>>> And it will happen again every time the registration is refreshed.
>>>
>>>> Going to Cullen's concern: if I got one of these URIs, it's not 
>>>> clear what part of that I could mine to find out whether it was a 
>>>> Women's Shelter (unless example.com has precisely one customer, in 
>>>> which case I don't think there's anything we can do anyway).
>>>> Cullen: can you elaborate on your use case, providing specific 
>>>> examples of the URIs that you think leak information?
>>>> /a

---

From: Adam Roach <[email-masked]>
Date: Thu, 20 May 2010 16:25:21 -0500

So, I had a pretty long conversation with Cullen, and it turns out that 
the issue (and I think he's convinced me that it's a real issue) is that 
the "gr" portion of the anonymous public GRUUs is invariant across 
multiple temp-gruus.

So, using the "women's shelter" example, the issue is that someone 
receiving a call from a shelter could capture the inbound contact (a 
temp gruu), and then attempt to contact all the shelters in the area 
(not a difficult feat). Once he got a contact back with a matching "gr" 
parameter, he knows precisely which shelter the call originated from.

Assuming we need to address this situation, there are really only two 
watertight solutions that I can think of.

To Paul's point (below), I think it's critical that this solution works 
with phones in the same way that GRUUs do in general. In other words, 
the b2bua approach in which the phone is telling the PBX that it wants 
privacy, and the PBX is invoking GRUU procedures is pretty much a 
non-starter. It's not enabling GRUU procedures; it's enabling some 
hybrid approach that I don't think gets us to where we want to be.

So, the first kind of solution involves the SSP somehow minting a new 
temp GRUU for each extension, and communicating all the temp GRUUs to 
the PBX (in a confidential manner, of course). This approach also 
requires the ability for the PBX to request a new temp GRUU whenever a 
terminal registers (since a new registration causes creation of a new 
temp GRUU).

I don't think that's tenable, since you basically end up having to send 
a lot of per-extension state back and forth between the PBX and the SSP. 
It pretty much negates any benefit of using GIN. In other words, for all 
the traffic and complication, you'd probably be better off registering 
each extension individually instead.

So I'm not interested in pursuing that one.

The second approach involves a kind of distributed cookie factory. I 
know this sounds complicated at first blush, but I think it's actually 
pretty easy to do correctly, especially if we leverage the procedure in 
appendix A.2 of RFC 5627.  Go read that appendix now, since it's pretty 
important to understand what I'm talking about.

Effectively, what we would do is pass along some information from the 
SSP to the PBX that the PBX uses to mix into the temp-gruu when it 
generates it. This information could be sent in the REGISTER response. 
At that point, the PBX could generate temp-gruus that the SSP could 
correlate to the proper PBX; that the PBX could correlate to the proper 
terminal; and that outside parties would be unable to correlate to any 
other temp-gruus.

I'm about halfway done with the description of how this would be done, 
and will post a proposal to the MARTINI list when I think I have 
something that works.

/a

On 5/20/10 12:37 PM, Adam Roach wrote:
> currently proposed mechanism. There's a lot of 
> back-to-the-drawing-board proposals implied by the last few messages, 
> without any clear indication why. The one use "issue," raised by 
> Cullen, appears to be based on a misunderstanding. Everything else 
> looks like an "ooh, shiny!" race off to see if we can design something 
> else just for the fun of it.
>
> /a
>
>> world sees will be one inserted by the pbx b2bua, not the one 
>> inserted by the phone. In that case, there are two issues:
>> *little* different. If there is still a b2bua in the path, its more 
>> or less the same, except that contact used probably won't be a gruu 
>> at all, just something cooked up by the b2bua for local use.)
>>
>> We haven't spoken much about the pbx-as-proxy case. That is a bit 
>> more difficult, because it becomes necessary to convey temp gruus to 
>> the phones.
>>
>>     Thanks,
>>     Paul
>>
>> Cullen Jennings wrote:
>>> The phones may not even support GRUU and their registration have 
>>> very little to do with the registration to the SSP. I realize that 
>>> to get a temp GRUU to each of the phones, we would either need a way 
>>> for the PBX to generate multiple temp GRUU based on some template it 
>>> got from the SSP or the PBX would need to get multiple temp GRUU 
>>> from the SSP. We should look at if there is a reasonable design to 
>>> achieve either of those that does not require changes to GRUU. I 
>>> suspect their might be. But even if there is not, I think there is a 
>>> simple solution to this.
>>>
>>> solution would be to have the PBX get a single temp GRUU and when 
>>> the PBX makes an anonymous call  to the SSP use the temp gruu then 
>>> get some more temp gruu for future use. This would probably work 
>>> better if it had a small pool of available temp gruu for use when a 
>>> temp gruu is need but you get the idea.
>>> Another option would be just to have the GIN draft request the 
>>> number of temp GRUU that the PBX wants the SSP to return.
>>> - I view that as GIN breaking SIP. It's a critical feature when 
>>> using SIP for PSTN replacement and I believe it has very important 
>>> value many types of SIP communication.
>>>
>>>
>>>> generating its own temp gruus, but we don't want the ssp to 
>>>> generate temp gruus for all the implicitly registered AORs, then 
>>>> some added specification is required.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 May 2010 18:45:55 -0400

> hybrid approach that I don't think gets us to where we want to be.

AFAIK we have no documented approach to anonymity using gruus with 
b2buas, or even with using gruus at all with b2buas. Typically the b2bua 
is going to replace the contact address supplied by the phone with an 
address that terminates on the B2BUA. If that contact is a gruu, and the 
b2bua is the issuer of that gruu, then with luck it will recognize it. 
If its really clever, it will then decide that it doesn't need to 
replace it, because it already terminates on the b2bua.

If the b2bua is upstream of the proxy/registrar that assigned the gruu 
the phone is using, then the b2bua will probably not recognize it, and 
so will replace it with something of its own. When incoming requests 
reach that address, it will replace with the original (phone-gruu) and 
forward on. That will work. But it might lose anonymity if it was a temp 
gruu.

If the contact is a gruu assigned by the SSP which is downstream from 
the b2bua then things get messy. The b2bua may not recognize this, and 
so replace it. That will then result in a spiral through the SSP. If the 
b2bua recognizes this (it was an SSP assigned gruu with additions by the 
pbx to generate a gruu for the phone, then it could leave it alone and 
things will probably work ok.

So it probably can be made to work, but it will take some care, and the 
precise things that must be done may vary by topology. This needs 
further investigation.

> terminal registers (since a new registration causes creation of a new 

When temp gruus were introduced, there was consideration of ways to 
request new ones. That was discarded since it didn't fit in well with 
the registration approach to gruu assignment. Instead, the decision was 
to assign a new temp gruu at every registration, including refreshes. 
Hence a UA that wants a new temp gruu can get it by re-registering. The 
cost of this is assigning new temp gruus each registration even if the 
register was not for that purpose. (Might have been a mistake, but it is 
what it is.)

When I started looking into the gruu reg event extension, and the 
implications of implicit registrations, it turned out that we had to 
depend on the reg event package to get temp gruus for implicitly 
registered AORs. And it implied that every registration refresh had to 
generate a new temp gruu for every implicitly registered AOR. That 
wasn't so bad when there might be 1 or 2 implicit registrations per 
explicit registration. Its not nearly as acceptable when there might be 
100-200+ of them.

Also, every time this happens, you need to generate a NOTIFY containing 
all that stuff to any subscriber to any of the implicitly registered 
AORs. (At least thats how I think it works for IMS.)

> a lot of per-extension state back and forth between the PBX and the SSP. 

Yup, that's the bottom line.

> terminal; and that outside parties would be unable to correlate to any 

Note that if you can do this once, you can probably do it twice, so that 
the phone can generate *its* own gruus using a seed passed to it. Then 
you wouldn't need all the repetitive gruu generation on every register. 
But of course it would not be backward compatible.

> and will post a proposal to the MARTINI list when I think I have 

What I learned in several years of working, off and on, on gruu is that 
side effects keep popping up all over the place. For instance, does this 
require another extension to the reg event package? Or will it even be 
possible to discover gruus that way?

I don't consider this to be a small undertaking. If we are to do it, I 
think we should consider if it should apply more broadly than to 
martini. I'd prefer if we could see fit to postpone this part to a 
follow on effort. Until then, maybe those outfits that can't live with 
their pbx being identifiable might have to do something else.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Thu, 20 May 2010 19:28:33 -0500

On 5/20/10 17:45, May 20, Paul Kyzivat wrote:
> explicit registration. Its not nearly as acceptable when there might 
> be 100-200+ of them.
>
> Also, every time this happens, you need to generate a NOTIFY 
> containing all that stuff to any subscriber to any of the implicitly 
> registered AORs. (At least thats how I think it works for IMS.)

I think that's probably also why the IMS solution works only for 
pub-gruus. A registered user can have an unbounded set of temp-gruus, so 
communicating them in a reg event document simply isn't realistic. Keep 
in mind that any reasonable GRUU server implementation isn't going to 
keep track of all the temp GRUUs for a user -- it'll use something like 
the algorithm in appendix A.2.

Plus, publishing the temp-gruus right next to their associated AORs 
kinda defeats the purpose of their anonymity. :)

/a

---

From: Dean Willis <[email-masked]>
Date: Thu, 20 May 2010 21:01:44 -0500

> On the other hand, I tend to agree with you that implementers don't like too much useless material. We had a pretty good evaluation of gin against requirements at IETF#77 on slides, and it is that…

Easy solution.

Publish the requirements, informational track.

Publish gin, standards track, containing only that which is required to
implement the spec, tight and testable.

Make yet another draft, informational track, that shows how gin or gin
+olive meet the requirements, and that revises the requirements if
necessary.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Fri, 21 May 2010 08:05:23 -0500

On 5/21/10 07:31, May 21, Paul Kyzivat wrote:
>>> registered AORs. And it implied that every registration refresh had 
>>> to generate a new temp gruu for every implicitly registered AOR. 
>>> That wasn't so bad when there might be 1 or 2 implicit registrations 
>>> per explicit registration. Its not nearly as acceptable when there 
>>> might be 100-200+ of them.
>>>
>> pub-gruus. A registered user can have an unbounded set of temp-gruus, 
>> so communicating them in a reg event document simply isn't realistic. 
>> Keep in mind that any reasonable GRUU server implementation isn't 
>> going to keep track of all the temp GRUUs for a user -- it'll use 
>> something like the algorithm in appendix A.2.
>>
> Well, one would expect that the publication of the temp gruus would be 
> constrained by policy.

Okay. So what I said was "It's impossible. And, even if it were 
possible, it would be inadvisable." You spoke to the second half. I 
think we would need to address the first half also. :)

/a

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 May 2010 09:04:53 -0600

On May 21, 2010, at 8:52 AM, Elwell, John wrote:

> Cullen,
> 
> I agree with what you say, but the IETF (certainly RAI) has a history of producing requirements RFCs, e.g., SPEERMINT, identification (RFC 3324), e2m security (RFC 4189), trait-based authorisation (RFC 4484), overload (RFC 5390), media security (5479), floor control (RFC 4376), media control (RFC 5167), geopriv (RFC 3693), ecrit (RFC 5012)... In some cases the charter even calls for this, although that is not true for MARTINI. I think the decision was made at the start of the work to produce a requirements document. If we want to use a less formal means of publishing this, and include the write-up on how gin meets the requirements, I don't mind. I just thought the WG was expecting an RFC.

Yah - in this case the WG and the people doing the draft are expecting an RFC. Changing that now seems bad so I think on this one we should stay with publishing the the requirements as an RFC - I'm perfectly happy with whatever the chair can convince the AD to do on this which I assume will be more or less whatever the chairs want.  It's really not a big deal, I just have a slight preference for moving the analysis out of the solution RFC. 

> 
> And by the way, I could probably cite a bunch more where requirements and motivation are included in the solution RFC, but that is another matter.

Yep, and at some level the sipping process heavily encouraged this. 

> > From: Cullen Jennings [mailto:[email-masked]]
> > Sent: 21 May 2010 15:20
> > To: Dean Willis
> > Cc: Elwell, John; Spencer Dawkins; [email-masked]
> > So, I should start with I really don't feel strongly about
> > this and I can live with whatever happens ....
> >
> > Few points about Requirements - people always say they are
> > written before the solutions. In all the examples I have seen
> > at IETF this is farm more often not the case - certainly not
> > true in this case. The requirements and solutions were
> > evolved along in parallel over months or years starting in
> > SIP Forum and eventually ending up where - I will point the
> > requirements are still not done in the sense that they are
> > not an RFC and are still changing and the solution is very
> > close to WGLC.
> >
> > Next, I don't think there is any rule that the solution MUST
> > meet the requirements. The question I think the WG should ask
> > when it goes to publish the solution is basically "Are we
> > happy enough with this that we have rough consensus to
> > publish it". I very important piece of information for
> > everyone to try and decide if they can say yes to that is the
> > analysis of how well the solution meets the requirements but
> > from a procedural point of view, if the solution does not
> > meet all the requirements, the WG could still decide to pub
> > request the doc.
> >
> > So from my point of view, it's nice to have a draft that has
> > the requirements (could be same or different draft as the
> > solution), it's nice to have a draft with the analysis of how
> > well the solution meets the requirements. But once the work
> > is done, none of this text has much value as an RFC. It's
> > useful to have a pornier in the RFC to find this. The easiest
> > way to do that is the names of the draft and just use google
> > to find them. They really do last forever on the internet
> > unlike whatever the front of them says about 6 months. The
> > fundamental reasons we publish them as RFC is that people put
> > a bunch of work into them and publishing it as a RFC with the
> > person name on it is a way to say thanks for that work.
> >
> > But I do have a preference for moving text that is of no use
> > out of RFC implementors need to read. It can move to another
> > RFC, a draft, an email thread that is archived, whatever.
> > When considering moving it to an RFC, keep in mind that even
> > a simple information RFC takes a ton of time for the AD so
> > that means something else is getting dropped. Well worth
> > considering the load level on your AD based on reassured
> > response time and task drop rate before asking them to
> > publish something that would not have much more value as an
> > RFC than as a draft.
> >
> > Oh yah, and +1 to Deans comments below and John I agree with
> > your point we want to be able to put finished stuff to bead
> > and not have it wait on some future doc.
> >
> >
> > On May 20, 2010, at 8:01 PM, Dean Willis wrote:
> >
> > >> I think that is the wrong way round. A requirements
> > document is generally written before solution documents. And
> > suppose some requirements are not met until a later solutions
> > document, e.g., olive. Does that mean we can't put the
> > requirements document to bed before olive is finished?
> > >>
> > >> On the other hand, I tend to agree with you that
> > implementers don't like too much useless material. We had a
> > pretty good evaluation of gin against requirements at IETF#77
> > on slides, and it is that that is captured in the latest gin
> > draft. The analysis has changed very little, except that a
> > couple of new requirements have been added. The IETF#77
> > MARTINI minutes, with pointer to the slides, goes a long way
> > to showing that we have done due diligence in ensuring the
> > solution meets the requirements. OR we could post updated
> > text on the mailing list, so that it appears in the archive.
> > Do we really need to encumber either draft with this lengthy text?
> > >>
> > >
> > > Easy solution.
> > >

Cullen Jennings

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 May 2010 08:31:58 -0400

Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 May 2010 08:20:05 -0600

So, I should start with I really don't feel strongly about this and I can live with whatever happens ....

Few points about Requirements - people always say they are written before the solutions. In all the examples I have seen at IETF this is farm more often not the case - certainly not true in this case. The requirements and solutions were evolved along in parallel over months or years starting in SIP Forum and eventually ending up where - I will point the requirements are still not done in the sense that they are not an RFC and are still changing and the solution is very close to WGLC. 

Next, I don't think there is any rule that the solution MUST meet the requirements. The question I think the WG should ask when it goes to publish the solution is basically "Are we happy enough with this that we have rough consensus to publish it". I very important piece of information for everyone to try and decide if they can say yes to that is the analysis of how well the solution meets the requirements but from a procedural point of view, if the solution does not meet all the requirements, the WG could still decide to pub request the doc. 

So from my point of view, it's nice to have a draft that has the requirements (could be same or different draft as the solution), it's nice to have a draft with the analysis of how well the solution meets the requirements. But once the work is done, none of this text has much value as an RFC. It's useful to have a pornier in the RFC to find this. The easiest way to do that is the names of the draft and just use google to find them. They really do last forever on the internet unlike whatever the front of them says about 6 months. The fundamental reasons we publish them as RFC is that people put a bunch of work into them and publishing it as a RFC with the person name on it is a way to say thanks for that work. 

But I do have a preference for moving text that is of no use out of RFC implementors need to read. It can move to another RFC, a draft, an email thread that is archived, whatever. When considering moving it to an RFC, keep in mind that even a simple information RFC takes a ton of time for the AD so that means something else is getting dropped. Well worth considering the load level on your AD based on reassured response time and task drop rate before asking them to publish something that would not have much more value as an RFC than as a draft. 

Oh yah, and +1 to Deans comments below and John I agree with your point we want to be able to put finished stuff to bead and not have it wait on some future doc. 

Cullen Jennings

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 21 May 2010 16:52:18 +0200

Cullen,

John

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 May 2010 14:03:03 +0200

Hi,

One reason why I think it is important to have some kind of reference and tracking of the requirements is because, as we know, GIN does not solve all the requirements that some people need, and that MARTINI later might work on. We have accepted some limitations and restrictions for GIN.

So, if we later work with another solution, which solves requirements that we have chosen to not include for GIN, it is very useful to see what requirements the solutions solve, in order to evaluate them etc.

I think the simplest solution is to simply list the requirements in the GIN draft, but I have no strong preference how it's done.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: 21. toukokuuta 2010 17:52
To: Cullen Jennings; Dean Willis
Cc: [email-masked]
Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)?

Cullen,

John

> Few points about Requirements - people always say they are written 
> before the solutions. In all the examples I have seen at IETF this is 
> farm more often not the case - certainly not true in this case. The 
> requirements and solutions were evolved along in parallel over months 
> or years starting in SIP Forum and eventually ending up where - I will 
> point the requirements are still not done in the sense that they are 
> not an RFC and are still changing and the solution is very close to 
> WGLC.
> 
> Next, I don't think there is any rule that the solution MUST meet the 
> requirements. The question I think the WG should ask when it goes to 
> publish the solution is basically "Are we happy enough with this that 
> we have rough consensus to publish it". I very important piece of 
> information for everyone to try and decide if they can say yes to that 
> is the analysis of how well the solution meets the requirements but 
> from a procedural point of view, if the solution does not meet all the 
> requirements, the WG could still decide to pub request the doc.
> 
> So from my point of view, it's nice to have a draft that has the 
> requirements (could be same or different draft as the solution), it's 
> nice to have a draft with the analysis of how well the solution meets 
> the requirements. But once the work is done, none of this text has 
> much value as an RFC. It's useful to have a pornier in the RFC to find 
> this. The easiest way to do that is the names of the draft and just 
> use google to find them. They really do last forever on the internet 
> unlike whatever the front of them says about 6 months. The fundamental 
> reasons we publish them as RFC is that people put a bunch of work into 
> them and publishing it as a RFC with the person name on it is a way to 
> say thanks for that work.
> 
> But I do have a preference for moving text that is of no use out of 
> RFC implementors need to read. It can move to another RFC, a draft, an 
> email thread that is archived, whatever.
> When considering moving it to an RFC, keep in mind that even a simple 
> information RFC takes a ton of time for the AD so that means something 
> else is getting dropped. Well worth considering the load level on your 
> AD based on reassured response time and task drop rate before asking 
> them to publish something that would not have much more value as an 
> RFC than as a draft.
> 
> Oh yah, and +1 to Deans comments below and John I agree with your 
> point we want to be able to put finished stuff to bead and not have it 
> wait on some future doc.
> 
> 
> document is generally written before solution documents. And suppose 
> some requirements are not met until a later solutions document, e.g., 
> olive. Does that mean we can't put the requirements document to bed 
> before olive is finished?
> >> 
> implementers don't like too much useless material. We had a pretty 
> good evaluation of gin against requirements at IETF#77 on slides, and 
> it is that that is captured in the latest gin draft. The analysis has 
> changed very little, except that a couple of new requirements have 
> been added. The IETF#77 MARTINI minutes, with pointer to the slides, 
> goes a long way to showing that we have done due diligence in ensuring 
> the solution meets the requirements. OR we could post updated text on 
> the mailing list, so that it appears in the archive.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 26 May 2010 23:40:53 +0200

> There's a ton of way to skin this cat but I am strongly against depreciating anonymous call support of 3261 when using the GIN draft - I view that as GIN breaking SIP. It's a critical feature when…

[HE] I agree that anonymity is an important feature, but how would
this break anonymous call support in RFC3261? Does it not have a
similar weakness as RFC3261 that the goat shelter could be revealed by
the IP address in the contact header of messages coming out of the
shelter's pbx?

Or did you mean to refer to RFC3323? Which delegates the anonymization
of the Contact header to an intermediary providing a privacy service
(section 4.1).

/Hans Erik

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 27 May 2010 00:17:42 +0200

I propose to move the requirements analysis into an appendix. Don't
think it is needed in the main body of the document. But I agree the
information is usefull.

/Hans Erik van Elburg

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 27 May 2010 08:58:49 +0200

Works for me.

John 

> From: Hans Erik van Elburg [mailto:[email-masked]] 
> Sent: 26 May 2010 23:18
> To: Christer Holmberg
> Cc: Elwell, John; Cullen Jennings; Dean Willis; [email-masked]
> > One reason why I think it is important to have some kind of 
> reference and tracking of the requirements is because, as we 
> know, GIN does not solve all the requirements that some 
> people need, and that MARTINI later might work on. We have 
> accepted some limitations and restrictions for GIN.
> >
> > So, if we later work with another solution, which solves 
> requirements that we have chosen to not include for GIN, it 
> is very useful to see what requirements the solutions solve, 
> in order to evaluate them etc.
> >
> > I think the simplest solution is to simply list the 
> requirements in the GIN draft, but I have no strong 
> preference how it's done.
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> [mailto:[email-masked]] On Behalf Of Elwell, John
> > I agree with what you say, but the IETF (certainly RAI) has 
> a history of producing requirements RFCs, e.g., SPEERMINT, 
> identification (RFC 3324), e2m security (RFC 4189), 
> trait-based authorisation (RFC 4484), overload (RFC 5390), 
> media security (5479), floor control (RFC 4376), media 
> control (RFC 5167), geopriv (RFC 3693), ecrit (RFC 5012)... 
> In some cases the charter even calls for this, although that 
> is not true for MARTINI. I think the decision was made at the 
> start of the work to produce a requirements document. If we 
> want to use a less formal means of publishing this, and 
> include the write-up on how gin meets the requirements, I 
> don't mind. I just thought the WG was expecting an RFC.
> >
> > And by the way, I could probably cite a bunch more where 
> requirements and motivation are included in the solution RFC, 
> but that is another matter.
> >
> > John
> >
> >
> meet all the
> fundamental

---

From: Martien Huysmans <[email-masked]>
Date: Thu, 27 May 2010 10:07:15 +0200

Hi

If I understand you correctly, you are saying that RFC3323 provides an alternative for the "goat shelter" problem.
That problem resulted in the temp-gruu chapters that are now described in martini-gin-03.
In this alternative the SSP would provide a Privacy service, which ensures that caller remains anonymous. 
Sound good.

Side question: If there is a B2BUA in the network of the SSP, then my understanding is that the
contact of the caller will never reach the caller. I guess the Privacy service would be implemented as a B2BUA.

/Martien 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
Sent: Wednesday, May 26, 2010 11:41 PM
To: Cullen Jennings
Cc: [email-masked]
Subject: Re: [martini] GIN and anonymous GRUUS

> There's a ton of way to skin this cat but I am strongly against depreciating anonymous call support of 3261 when using the GIN draft - I view that as GIN breaking SIP. It's a critical feature when…

[HE] I agree that anonymity is an important feature, but how would this break anonymous call support in RFC3261? Does it not have a similar weakness as RFC3261 that the goat shelter could be revealed by the IP address in the contact header of messages coming out of the shelter's pbx?

Or did you mean to refer to RFC3323? Which delegates the anonymization of the Contact header to an intermediary providing a privacy service (section 4.1).

/Hans Erik

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 27 May 2010 14:59:53 +0200

I did not ment to state anything I was just raising questions for my
understanding to Cullen.

/Hans Erik van Elburg

---

From: Martien Huysmans <[email-masked]>
Date: Fri, 28 May 2010 13:36:49 +0200

Then the statement is from my side.

/Martien

-----Original Message-----
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Thursday, May 27, 2010 3:00 PM
To: Martien Huysmans
Cc: Cullen Jennings; [email-masked]
Subject: Re: [martini] GIN and anonymous GRUUS

I did not ment to state anything I was just raising questions for my understanding to Cullen.

/Hans Erik van Elburg

On Thu, May 27, 2010 at 10:07 AM, Martien Huysmans <[email-masked]> wrote:
> Side question: If there is a B2BUA in the network of the SSP, then my 
> understanding is that the contact of the caller will never reach the caller. I guess the Privacy service would be implemented as a B2BUA.
>
> /Martien
>
> Behalf Of Hans Erik van Elburg