Subject: RE: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t xt

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 4 May 2006 09:56:17 -0500

Hi Spencer and others,
There is never a suggestion anywhere in the draft that the proposed P-header be used in any connected network without prior arrangement.  The P-header is for use primarily within the private network to help decide how to manage early media, which is clearly described in existing IETF standards as a matter of local policy.  It is not expected to be understood outside of the private network without prior arrangement.

In all the email on this subject it has been clear to me that the proposed draft can be made to conform to all existing guidelines with some editing and there is no consensus to refocus the draft into a standards track SIP extension.  I will prepare an update soon.

The issue appears to be that some individuals simply don't want private networks to have sufficient information to help decide when to enable early media (they already have the right, just not sufficient information to do what they need to do).  This appears to be much ado about little, since there are already many scenarios (in practice and due to features like forking, for example) in which early media will not work (thus impacting the user experience).  Some have suggested a standards track extension to allow a UAS to discover when its early media is enabled, but this proposal is way beyond the scope of the draft.  I look forward to drafts from others.

Regards,
Richard

>From Spencer Dawkins:
> From: "GARCIN Sebastien RD-CORE-ISS" 
> <[email-masked]>
> 
> "If I follow your definition P-headers should never be used by 3GPP,
> Cablecom, ETSI TISPAN"
> 
> If I'm following the discussion correctly, it's not that 
> P-headers shouldn't 
> be used within a network (or even class of network), but that 
> P-headers 
> shouldn't be used when leaving that network. The issue isn't 
> using P-headers 
> in 3GPP, it's using P-headers on a call from 3GPP to TISPAN, 
> or to any 
> network that doesn't clearly understand P-headers, when not 
> understanding 
> affects the experience of the participants at each end.
> 
> If I have missed the point, someone please explain more clearly.
> 
> Thanks,
> 
> Spencer 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 May 2006 18:33:21 -0400

Ejzak, Richard P (Richard) wrote:
> Hi Spencer and others,
> There is never a suggestion anywhere in the draft that
> the proposed P-header be used in any connected network
> without prior arrangement.  The P-header is for use
> primarily within the private network to help decide how
> to manage early media, which is clearly described in
> existing IETF standards as a matter of local policy. 
> It is not expected to be understood outside of the
> private network without prior arrangement.

I agree there is no suggestion that it be used outside its connected 
network.

One issue is that by using it to *manage* early media it is altering 
behavior, which seems to be out of scope for P-headers. (However exactly 
how these rules should be interpretted is subject to interpretation. 
Others may have a different opinion. We need to figure out what is right.)

When a call involves elements outside of the "connected network", the 
fact that it is not used by the outside elements prevents them from 
getting the behavior defined by the standards. The presence of the 
P-header is required to receive standard behavior.

> In all the email on this subject it has been clear to
> me that the proposed draft can be made to conform to all
> existing guidelines with some editing and there is no
> consensus to refocus the draft into a standards track
> SIP extension.  I will prepare an update soon.

I'm looking forward to it. I agree that there are things that can be 
done that won't be a problem. Anything whose *intent* is to help a proxy 
to block media without the permission of the UA won't be acceptable to 
*me*, but it might be acceptable to the WG. I suppose it is possible 
that something could be proposed with a less objectionable intent, yet 
could be used to achieve the same end. I wouldn't be happy about that, 
but I might have no justification to object.

> The issue appears to be that some individuals simply don't
> want private networks to have sufficient information to help
> decide when to enable early media (they already have the
> right, just not sufficient information to do what they need
> to do). 

There is a question in my mind about whether there is such a "right".

I suppose it is true that a network has the "right" to block any traffic 
it chooses to block. But if it does so it may be found to be in 
violation of various specifications. So can a proxy cause media to be 
blocked and still claim to be a conforming proxy?

I think it is clear that proxies can legally block requests by 
responding with a failure response. That is above board. Just making the 
call work poorly, without even informing the UAs of this is at least 
questionable in my mind. It certainly is a path that leads to difficult 
to diagnose interoperability problems.

> This appears to be much ado about little, since
> there are already many scenarios (in practice and due to
> features like forking, for example) in which early media
> will not work (thus impacting the user experience). 

At least it is the UAs that are in control of this.

> Some have suggested a standards track extension to allow a
> UAS to discover when its early media is enabled, but this
> proposal is way beyond the scope of the draft. 

I agree that is beyond the scope of this, but it is quite a different 
situation. It is not a matter of policy or control - it is merely a 
reflection of the limitations of the UA. It is little different than 
offering audio and video to a device that only supports audio, and being 
disappointed that the video cannot be presented.

I agree that enough has been said on this. The powers that be need to 
indicate how we decide whether the requirements for a P-header have been 
met.

	Paul

> I look forward to drafts from others.
> 
> Regards,
> Richard
> 
>>From Spencer Dawkins:
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 5 May 2006 15:56:41 -0500

On May 4, 2006, at 5:33 PM, Paul Kyzivat wrote:

>> existing IETF standards as a matter of local policy. It is not  
>> expected to be understood outside of the
> I agree there is no suggestion that it be used outside its  
> connected network.

One requirement is that we explain WHY the header cannot be used  
outside of its private network and what will go wrong if it is used  
outside. Every P-header RFC MUST provide this guidance (RFC 3427  
clause 7), and we need to add that to this draft.

But there's a further requirement:

If the header is such that when it "escapes its private network" it  
will cause a malfunction in operation when connecting to sip  
equipment that doesn't understand the header, then the header is not  
suitable for registration as a P-header.

I think we're debating whether this draft falls into this second trap.

This is what's meant by clause 4 in RFC 3427, "MUST NOT significantly  
change the behavior of SIP entities which support it".

If a device that is relying on this header interacts with a device  
that doesn't understand this header and the result is something that  
would be perceived by the user as a "communications failure", then we  
have a problem. If however, the communication proceeds normally, but  
whatever added behavior is granted by the header simply isn't  
present, we're ok.

Let's take a hypothetical P-SeeMyFace header that gives a pointer to  
a multicast camera focused on my sweaty face. This is only visible if  
you happen to be in my multicast domain (the applicability scope). If  
I send an INVITE to somebody who doesn't understand the header, they  
ignore it, don't see my face, and everything proceeds normally. If I  
send it to somebody who supports the header but isn't in my multicast  
domain, they may TRY to see my face, but their UI will tell them it  
isn't working, and the call will otherwise proceed normally.  If I  
don't include it in an INVITE to somebody who supports the extension,  
they're going to know not to try and join some multicast group to see  
my face. This would probably be a valid P-header.

Now, let's take another hypothetical header, P-GottaPortKnock, that  
instructs the recipient that they must perform a port-knocking  
exercise before I'm going to accept their media (you can read about  
port knocking at http://www.portknocking.org/). If they don't  
understand the extension and don't do the port knocking, my UA will  
discard their media, and the call isn't going to work right. This  
clearly is NOT a valid P-Header. While we could do a SIP extension  
header to enable this feature, it needs feature negotiation using an  
option tag to keep from failing in a surprising way.

So which category are we in with p-em-auth?

--
Dean