Subject: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00

From: "Elwell, John" <[email-masked]>
Date: Tue, 19 Oct 2010 13:04:08 +0200

An interesting draft.

One particular point I noticed, in section 6:
"Furthermore, due to the proliferation of B2BUAs in the signaling 
   path, it's not very common that a Contact URI is not routable-to by 
   a UA."

The problem is out-of-dialog requests, when the contact URI supplied by a B2BUA does not have a lifetime beyond that of the original dialog. So you might be able to route back to the B2BUA, but whether it will be interpreted correctly when you get there is another matter.

Apart from call transfer, another problem might be the routing of a callback to a device that initiated an emergency call. The "Global Contacts" solution would work only if a global contact has a lifetime beyond a given dialog.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Oct 2010 09:42:25 -0400

I haven't seen the announcement for this draft yet, so this was my first 
introduction to it.

While there are some real problems identified in here, for the most part 
this is calling out cases where things have been done wrong or poorly, 
and blaming gruu.

I do think it will be useful to go through this point by point and 
discuss plausible remedies.

IMO it is the responsibility of those deploying B2BUAs to do so in a way 
that doesn't break things. I realize that in some cases the *purpose* of 
the B2BUA is to break things, and that can be a valid thing to do, as 
long as it only breaks the things that should be broken.

Also, ISTM that its about time to start doing something about access 
limited networks. Access limiting sip networks makes as little sense as 
access limiting email networks. In spite of spam problems, the world 
would not work if email was restricted the way sip is.

	Thanks,
	Paul

On 10/19/2010 7:04 AM, Elwell, John wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 19 Oct 2010 11:51:42 -0400

Sorry, I didn't announce it because it's not my final version - I just submitted what I had as a placeholder due to the deadline. (there's a loophole in the whole I-D submission thing that you can't submit draft-00 after yesterday, but you can submit a 00 yesterday as a placeholder and then a 01 next week, effectively letting you submit a brand new I-D a week late. :)

With regards to below, yes absolutely - if the Global Contact doesn't survive a dialog's lifetime, then by definition it wont' be usable later.  I don't know of any B2BUA's that generate Global Contacts that have only a lifetime of a dialog *on purpose*, but since the original Contact-URI they generated the Global based on may only have a lifetime of a dialog, the Global Contact would inherit that behavior as well in effect.  And I do know of some devices which generate Contact-URIs which only last a dialog (because they encode call-specific info in their contact).  So if their request goes through a B2BUA, the Global Contact created by the B2BUA for them only lasts that long too, from a usefulness perspective.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Tue, 19 Oct 2010 11:33:25 -0500

> Sorry, I didn't announce it because it's not my final version - I just submitted what I had as a placeholder due to the deadline. (there's a loophole in the whole I-D submission thing that you can'…

I don't think that's the intention. In fact, historically (prior to the 
tools), the i-d repository manager would reject such submissions as 
being in violation of the deadlines. You can see, for example, 
discussion of the "no placeholder" rule in this email exchange:

https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=21546&tid=1259394188

I can't find any current policy documents that outline this, and I'm not 
sure whether the tools allow you to bypass the deadlines the way you 
intend (I guess you'll find out). But I believe that omitting discussion 
of the "no placeholder" rule in the i-d author guidelines document is an 
oversight.

The idea, of course, is that people need additional time to digest new 
ideas than they do to process updates to existing documents. Submitting 
an unfinished placeholder to subvert this intention seems outside the 
spirit of the deadlines.

I'm copying Russ here as current author of the "Guidelines to Authors of 
Internet Drafts," and Henrik as an Important Person in the tools 
pantheon to see if they can comment on official policy and tools 
behavior on this matter.

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Oct 2010 10:40:50 -0600

On 10/19/10 10:33 AM, Adam Roach wrote:
>> Sorry, I didn't announce it because it's not my final version - I just
>> submitted what I had as a placeholder due to the deadline. (there's a
>> loophole in the whole I-D submission thing that you can't submit
>> draft-00 after yesterday, but you can submit a 00 yesterday as a
>> placeholder and then a 01 next week, effectively letting you submit a
>> brand new I-D a week late. :)
> 

However, the matter is not always clear-cut. Sometimes an author has
found the time to roughly sketch out a proposal (resulting in -00) and
wants to get that out for discussion, but hasn't yet had time to create
examples, track down all the references, etc. It's not always easy to
draw a sharp line between "placeholder", "stub", "rough draft", etc.

Do we have examples of true placeholders that were then replaced with
something totally different?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Adam Roach <[email-masked]>
Date: Tue, 19 Oct 2010 11:48:23 -0500

On 10/19/10 11:40, Oct 19, Peter Saint-Andre wrote:
>> >>  submitted what I had as a placeholder due to the deadline.
...
> wants to get that out for discussion, but hasn't yet had time to 
> create examples, track down all the references, etc. It's not always 
> easy to draw a sharp line between "placeholder", "stub", "rough 
> draft", etc.

Perhaps I'm being naïve, but I would suspect an author calling their own 
draft a "placeholder" actually puts a pretty bright line around it.

More to the point: if you have something together by the -00 deadline 
that is sufficient to foster discussion, there's no real rush to get the 
i's dotted and the t's crossed by the -01 deadline. Just hold off on the 
examples, references, and other polish until after the meeting. On the 
other hand, if it's not in good enough shape that people can use it as 
the basis of a technical conversation, it is exactly equivalent to an 
empty placeholder.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 19 Oct 2010 12:52:37 -0400

Hi Paul,
comments inline...

> this is calling out cases where things have been done wrong or poorly, 

I don't think I'm "blaming gruu" (well... except for the argument that the RFC should have made the UA insert a Record-Route of its real contact).  In general the draft isn't trying to blame gruu - it's trying to explain why gruu isn't a magic cure-all.

> discuss plausible remedies.

How would you like to do that?  Email in dispatch, or separate mailing list, or future IETF Dispatch meeting, or BOF?

> long as it only breaks the things that should be broken.

I think the hard part here is figuring out which behavior doesn't break things.  I've convinced myself that "passing on" the GRUU will break things more than replacing it, but I'm not sure whether replacing it with a self-made GRUU is actually good or bad.  I'm not sure that a B2BUA or any system ever really knows whether its Contact URI is globally routable to, or whether it actually matters or not.

> would not work if email was restricted the way sip is.

Good luck with that. :)
Email's spam level would destroy voip's viability, never-mind the regulatory, billing, and interop issues.  There are free SIP domains without access restrictions, but they're the minority afaict.
Over time this may well change, but I doubt it'll be soon.

-hadriel

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Oct 2010 10:53:30 -0600

> draft a "placeholder" actually puts a pretty bright line around it.

Given that we don't have a clear definition of "placeholder", I'm not so
sure. Is it a sketch, a stub, something that you submitted only to get
draft-smith-foobar-00 and then you're going to completely change the
meaning of "foobar" next week?

> examples, references, and other polish until after the meeting. 

Some people are perfectionists and it pains them to submit anything
that's merely a rough draft.

> On the

Ah, you didn't say "empty placeholder" before. That makes all the
difference. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 19 Oct 2010 13:04:40 -0400

Oh the tool will let you do it unless it's been changed recently - I've done it several times before.  Although in my defense the draft's weren't really "placeholders" in the sense of being empty boilerplates, but more like I hadn't completely finished them.

But I don't think the tool should be changed to prevent it - the real purpose as you say is to provide people with time to read, and if people feel a late draft is too late, then they won't read it and it wont' get time at the meeting anyway.  And in some of the RAI working groups in particular you couldn't expect meeting time for a draft submitted *before* the deadline, let alone after, because our agenda is fixed long before the submission deadline. (September 6th in Dispatch's case)  
I didn't submit this I-D for meeting time.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 19 Oct 2010 13:11:31 -0400

Ahh - sorry for the confusion - it's not a "placeholder" in the sense of empty boilerplate - more like I wanted to tidy it up a bit before announcing it because I'm a nit-picker.

I'm not asking for any meeting time for this topic - I just wanted to get it in before IETF-79 because I had promised I would submit such a draft at the face-to-face meeting of Martini in Maastricht.

-hadriel

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Oct 2010 11:18:22 -0600

On 10/19/10 11:11 AM, Hadriel Kaplan wrote:

> Ahh - sorry for the confusion - it's not a "placeholder" in the sense
> of empty boilerplate - more like I wanted to tidy it up a bit before
> announcing it because I'm a nit-picker.

Tempest, meet teapot. :)

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 19 Oct 2010 13:21:50 -0400

My first impression is "Don't *do* that!".

At the very least, the element that mints GRUUs, or rather the administrative structure that is responsible for it, is responsible for ensuring that the GRUUs are *globally routable*.  If the SIP domain is part of an access-limited network, then they need to construct proper globally-advertised and globally-accessible incoming gateways.

If they're minting URIs that claim to be GRUUs but are not, the problem isn't with GRUUs per se but rather that they're not minting GRUUs.  More subtly, the problem may be that there are situations where it is *not possible* to provide a globally-routable URI for a UA that has a indefinite lifetime.  We may need to provide alternative solutions for that problem.

Dale

---

From: Adam Roach <[email-masked]>
Date: Tue, 19 Oct 2010 12:30:56 -0500

On 10/19/10 12:21, Oct 19, Worley, Dale R (Dale) wrote:
> More subtly, the problem may be that there are situations where it is*not possible*  to provide a globally-routable URI for a UA that has a indefinite lifetime.

Huh?

Do you mean GRUU or temp GRUU?

/a

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 19 Oct 2010 13:33:07 -0400

________________________________________
From: Adam Roach [[email-masked]]

> More subtly, the problem may be that there are situations where it is *not possible*
> to provide a globally-routable URI for a UA that has a indefinite lifetime.

Huh?

Do you mean GRUU or temp GRUU?
________________________________________

If the only way for global access to a UA is through some sort of border SBC, and if the border SBC won't keep any information around much longer than the length of a call, then it is impossible to provide a globally-routable, long-term URI to the UA.  (Or at least, it appears so to me at this moment.  There may be tricks to avoid the problem.)  Which means that it is impossible to provide a GRUU for the UA.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 19 Oct 2010 14:17:38 -0400

> At the very least, the element that mints GRUUs, or rather the administrative structure that is responsible for it, is responsible for ensuring that the GRUUs are *globally routable*.  If the SIP d…

Then by definition they're *not* an access-restricted domain.  There's no debate that if everyone can successfully send a request into your domain, from anywhere on the public Internets (v4 and v6), you can use GRUUs.  The draft doesn't say otherwise.  What it says is that most domains don't fit that bill, so they shouldn't mint GRUUs.  

And before you say "well, duh!", I should point out 3GPP specs think they can use GRUUs, when they really can't.  There isn't a single 3GPP deployment I can think of that could really use a GRUU as intended.  
And at least one Enterprise-based vendor provides GRUUs by default, even though in every deployment I've seen them used in they shouldn't be.  

I just don't think it's clear to folks what the ramifications are of minting a GRUU.   At least if we assume UAs really would change behavior when getting a GRUU contact. (for example, if they switch to using out-of-dialog REFER, or a b2bua decides to pass the gruu contact on)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 19 Oct 2010 14:26:24 -0400

> If the only way for global access to a UA is through some sort of border SBC, and if the border SBC won't keep any information around much longer than the length of a call, then it is impossible to…

It's not the "SBC" that isn't keeping the info around - afaik most SBC's have the ability to generate "Global Contacts" which last exactly as long as the Contact they generated it based on. (which itself may or may not be past the duration of a call)  For example, they generate an encrypted version of the original.  The problem would be if the original contact they generated it based on didn't last long, which does happen in practice.  But that's not a "problem" the draft really focuses on, or is meant to. (and arguably it's not a "problem" to begin with)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Oct 2010 20:21:40 -0400

> I don't think I'm "blaming gruu" (well... except for the argument that the RFC should have made the UA insert a Record-Route of its real contact).  In general the draft isn't trying to blame gruu -…

Well, I *took* it as blame. :-)

I don't really want to end up as an apologist for gruu. Its not a 
wonderful thing. But its what we have, and I think we should try to make 
it work before giving up on it.

> How would you like to do that?  Email in dispatch, or separate mailing list, or future IETF Dispatch meeting, or BOF?

I don't think it warrants its own mailing list, or scheduled time at the 
meeting. So I think either discussion on some existing list (dispatch or 
sipcore would do), and/or informal time in Beijing.

> I think the hard part here is figuring out which behavior doesn't break things.  I've convinced myself that "passing on" the GRUU will break things more than replacing it, but I'm not sure whether…

I think the hard part here is understanding the environments where 
things will break. In every case it seems to come down to:

- operators of some system/domain want to restrict use in some way
- B2BUAs (or maybe just firewalls, NATs, etc.) are inserted to
   accomplish that

- are the restrictions reasonable, or simply wrong headed?
- which things *should* work given reasonable restrictions
- do GRUUs contribute to a solution, or just make it worse?
- how must GRUUs be managed so that they do work in the
   cases where they should?

This is in some sense a revisiting of the "what is an SBC" question.

>> would not work if email was restricted the way sip is.

I realize it seems like an impossible task.
But it also once seemed like an impossible task to federate all the 
disparate networks in the world. That pretty much got done.

> Email's spam level would destroy voip's viability,

Certainly. But if email were being deployed for the first time today it 
would have a lot of the things that have now been invented to address 
the problem but haven't been widely adopted.

> never-mind the regulatory, billing, and interop issues.  There are free SIP domains without access restrictions, but they're the minority afaict.

It'll change or else everybody will just use Skype and the PSTN will die.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Oct 2010 20:27:58 -0400

On the surface this seems something like the ICE problem. ICE assumes 
that the UA can't really know if it has a public address.

Its a bit different here in that we aren't talking about individual UAs 
- its really a domain administration problem. It should be possible for 
the administrator of a domain to know if it has publicly routable 
addresses or not, and then to provision those elements that will be 
minting GRUUs (or not) accordingly.

A registrar that doesn't have a public address should not support 
handing out GRUUs. That will limit the functionality of the devices it 
services.

The fits in with Martini - which potentially gives a registrar without 
its own public address a way to mint gruus for its devices.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Oct 2010 20:30:59 -0400

I think we need to separate out the ipv6 issue from the gruu issue.
If I have a publicly routable URI that is only v4, then I think it still 
can qualify as a GRUU, even though v6-only nodes cannot use it.

We need some sort of mechanism to solve the v4/v6 problem for such cases.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 20 Oct 2010 10:16:05 -0400

________________________________________
From: Hadriel Kaplan [[email-masked]]

I should point out 3GPP specs think they can use GRUUs, when they really can't.
________________________________________

That doesn't surprise me.  But is that a problem with GRUU or with 3GPP?  In a world where people consider it normal for a network to have *no* globally-accessible ingress points, it's not surprising that they have trouble implementing internet protocols.

________________________________________
From: Hadriel Kaplan [[email-masked]]

I don't think I'm "blaming gruu"
________________________________________

You have titled the I-D, "Problems with the SIP Globally Routable User Agent URIs (GRUUs)".

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 20 Oct 2010 10:19:16 -0400

I just don't think it's clear to folks what the ramifications are of minting a GRUU.
________________________________________

Strictly speaking, what you mean is "I don't think it's clear to folks what the requirements are on what constitutes a GRUU."  If something constructs a URI and it's not globally-routable, it's not a GRUU, regardless of whether it is claimed to be one.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 20 Oct 2010 11:29:59 -0400

So?  If I titled it "Problems with SDP", would it imply I'm blaming SDP for the problems?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 20 Oct 2010 11:35:09 -0400

> I just don't think it's clear to folks what the ramifications are of minting a GRUU.

Yup. 

Note, though, that global reachability is only one of the "problems" discussed in the draft (although a big section).

-hadriel

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Wed, 20 Oct 2010 14:18:42 -0500

Maybe you should title it:  "Best Common Practices for using GRUU
Correctly"

Then you could describe various problems:  X hurts, don't do that.  Or,
be sure you do this instead.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
Sent: Wednesday, October 20, 2010 11:30 AM
To: Worley, Dale R (Dale)
Cc: [email-masked]
Subject: Re: [dispatch] Comment on
draft-kaplan-dispatch-gruu-problematic-00

So?  If I titled it "Problems with SDP", would it imply I'm blaming SDP
for the problems?

-hadriel

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 20 Oct 2010 15:35:57 -0400

It sounds like that to me -- you're saying the problem is with the design of SDP.

If you said, "Problems using SDP", that would have a very different meaning.

Consider "Problems with Hadriel's work" vs. "Problems applying Hadriel's work".  Which would you rather have your boss say?

And the abstract doesn't make it clear that the core of the problem is systems attempting to create GRUUs that are not, in fact, globally routable.  A better description is "There are many SIP architectures in which GRUUs cannot be constructed.  Thus, alternative means need to be found to solve the problems for which GRUUs are commonly considered to be the solution."

Dale