[Sipping] Discussion on draft-vanelburg-sipping-private-network-indication-01

Having gone through the comments raised in the meeting, i have to
conclude that in some twisted way they tell me that what we are trying
to do has to be done as a P- header. (So we might have answered the
question on the final slide without having had the chance to present
it.)

Following observations might lead to that conclusion:
- This is not an end to end header to be inserted by end user devices. I
think that should address the "this smells like a service identifier"
comment. It is not a service identifier, period. It has nothing to do
with services provided to an end user. This is explained in the draft,
and is why the P-Asserted-Service header field can not be used.
- In setups that are using it, it shall never be accepted from an entity
outside the trustdomain. This in itself indicates that we are talking
about some form of closed network and hence a P- header seems more
appropriate.

Then there where concerns on the use of the term private network traffic
as being inappropriate or undefined, the draft does define the term
though:
   3.2.  Private network traffic

   Traffic sent to or received from a public telecommunication network
   for processing according to an agreed set of rules specific to an
   enterprise or a community of closely related enterprises.

My question is given this rather clear definition does this concern
still hold? Any suggestion as to what needs to be clarified/reworded?

Then there where questions on what makes an entity/proxy decide to
insert such an indication. We will add some examples. However noting
that we can not specify this behaviour in detail as it depends heavily
on the business agreements/arrangement in a particular deployment.

/Hans Erik