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

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 17 Apr 2006 16:24:21 -0500

Paul Kyzivat wrote:
> I've been hoping some others would jump in here to give some other 
> perspectives on this. I don't pretend to be the last word on this.
> 
> Do you acknowledge that a consequence of intended use of this 
> p-header 
> is that "trusted" sources of early media may have their early media 
> delivered, while potential sources of early media *outside* of your 
> trust domain will have their early media dropped - not 
> delivered to the 
> other UA?

I acknowledge that that could be the result, depending on the policy implemented by the network using the P-header.

> 
> The question comes down to whether that is a valid use of a P-header 
> according to point 4 of RFC 3427:
> 
>     4.  The proposed header MUST be of a purely informational 
> nature, and
>         MUST NOT significantly change the behavior of SIP 
> entities which
>         support it.  Headers which merely provide additional 
> information
>         pertinent to a request or a response are acceptable.  If the
>         headers redefine or contradict normative behavior defined in
>         standards track SIP specifications, that is what is meant by
>         significantly different behavior.
> 
> Will this P-header "significantly change the behavior of SIP entities 
> which support it"? As best I can tell, that is the *intent* 
> of this header.

Since SIP allows local policy to be applied to early media, and this header just provides additional information to use in deciding how to apply local policy, I see no violation.  Local policy IS the normative behavior, so there is no way to redefine or contradict it with enhancements to local policy.
 
> 	Paul

Richard

_______________________________________________
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: Mon, 17 Apr 2006 17:36:14 -0400

Richard,

there is clearly nothing more for us to say to one another about this. 
Our positions are clearly different.

What we need is for some other people to join the discussion. I'm not 
sure how this is supposed to work procedurally for P-headers via RFC 
3427. But if there is dissagreement over whether a condition of that RFC 
is met or not, then I would think "rough concensus" would be the way it 
is resolved.

	Paul

---

From: "Dale R. Worley" <[email-masked]>
Date: Mon, 17 Apr 2006 23:53:02 -0400

> is met or not, then I would think "rough concensus" would be the way it 

As someone who has opinions on all subjects, I've tried to formulate one
on this subject, and it's difficult.  I just searched RFC 3261 for all
occurrences of the string "media" and there's very little about when and
how media are established.  There are placeholders telling where media
descriptions get sent, but it's really the nuances of the offer/answer
model that we're discussing.  I think I could even make a defense of the
idea that the P-header should be an added feature of SDP, not of SIP, as
it's really just another fact about the media (showing it has the right
to early transmission).

As for compatibility, how hard are we going to stand on the current
usages?  In a sense, an intermediate device that chops out all early
media packets is not standard-violating, as neither end is *required* to
send early media, and either end could think the other end is just not
sending -- Like a complex session border controller, such a device isn't
one described in RFC 3261, but no other agent in the dialog can prove
it.

The use of a header to enforce "walled garden" policies is annoying to
net-heads, yes, but similar headers will eventually be used for much
more sophisticated charging/authentication systems that will be much
less walled-garden.  If we want full-motion video calls to Timbuktu,
we're going to need some way to reserve and pay for the bandwidth, and
if the two ends don't live within the same walled garden, there's going
to have to be some reasonably standardized way for the UAs to negotiate
with the agents along the chain.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Apr 2006 09:23:59 -0400

Dale R. Worley wrote:
> As someone who has opinions on all subjects,

:-)

> I've tried to formulate one
> model that we're discussing. 

Yup. And the specifications of it are, not surprisingly, in 3264.

> I think I could even make a defense of the

Yeah, except then it couldn't be added by proxies.

> sending

In other words, view the header as just a way to alter the probabilities 
of random packet loss???

If this is ok, then what kind of behavior is *not* ok?

> -- Like a complex session border controller, such a device isn't

We are still trying to come to grips with the SBC issue. I think it is 
generally understood that SBCs can do some things that are acceptable, 
but they also sometimes do things that are not acceptable. Eventually 
the unacceptable things will be called out and ruled non-conforming.

We have the same situation here. I think we need to distinguish those 
things that are acceptable from those that are not. Things that harm 
interoperation are likely to fall into the "unacceptable" category.

> with the agents along the chain.

But isn't that the point?

We may be shooting ourselves in our feet by refusing to discuss charging 
if the result is that we end up accepting mechanisms for blocking 
interoperation instead.

	Paul