Re: [Gen-art] Gen-art LC review of draft-ietf-insipid-session-id-reqts-08.txt

[Gonzalo Camarillo <[e-mail]>]

Hi Elwyn,

Paul has just revised the draft in order to address your comments (he
sent a separate email about it). Could you please let us know whether
the new revision of the draft can be progressed at this point?

Thanks,

Gonzalo

On 26/09/2013 2:00 PM, Paul E. Jones wrote:
> If a B2BUA failed to pass a Session-ID, that's definitely a problem if
> that same device claims to support INSIPID.  I'm not sure we need a
> requirement for that, though, since being selective or inconsistent
> would violate REQ3.
> 
> Paul
> 
> ------ Original Message ------
> From: "DRAGE, Keith (Keith)" <[e-mail]>
> To: "Paul E. Jones" <[e-mail]>; "Elwyn Davies"
> <[e-mail]>
> Cc: "General Area Review Team" <[e-mail]>;
> "[e-mail]"
> <[e-mail]>
> Sent: 9/26/2013 5:42:10 AM
> Subject: RE: Gen-art LC review of
> draft-ietf-insipid-session-id-reqts-08.txt
>> I don't know whether it is worth mentioning that while the action of
>> the existing B2BUAs is not determinate, we do expect it to be
>> consistent, i.e. it would not pass on the header field on one request,
>> and fail to pass it on on another. Therefore session identifiers in
>> that have been created at the start of a dialog based on being passed
>> through should continue to work for the rest of the dialog, or other
>> related dialogs.
>>
>> Regards
>>
>> Keith
>>
>>>  -----Original Message-----
>>>  From: Paul E. Jones [mailto:[e-mail]]
>>>  Sent: 26 September 2013 04:04
>>>  To: Elwyn Davies
>>>  Cc: General Area Review Team; draft-ietf-insipid-session-id-
>>>  [e-mail]
>>>  Subject: Re: Gen-art LC review of draft-ietf-insipid-session-id-reqts-
>>>  08.txt
>>>
>>>  Elwyn,
>>>
>>>  Please see my comments below:
>>>
>>>  ------ Original Message ------
>>>  From: "Elwyn Davies" <[e-mail]>
>>>  To: "Paul E. Jones" <[e-mail]>
>>>  Cc: "General Area Review Team" <[e-mail]>;
>>>  [e-mail]
>>>  Sent: 9/25/2013 6:47:50 PM
>>>  Subject: Re: Gen-art LC review of
>>>  draft-ietf-insipid-session-id-reqts-08.txt
>>>  >Hi, Paul.
>>>  >[Resend to all addressees]
>>>  >
>>>  >We seem to be converging...
>>>  >
>>>  >On Wed, 2013-09-25 at 22:22 +0000, Paul E. Jones wrote:
>>>  >> Elwyn,
>>>  >>
>>>  >> Comments below:
>>>  >>
>>>  >> > >Minor issues:
>>>  >> >> >s4.3: I am not clear whether there needs to be any special
>>>  >> >> >consideration
>>>  >> >> >if the B2BUA doesn't support Session-ID. There could be a number
>>>  >of
>>>  >> >> >other cases to consider. In particular whether the B2BUA would
>>>  >> >>forward
>>>  >> >> >the Session-ID if it didn't understand it. Does this also affect
>>>  >> >> >SBCs?
>>>  >> >>
>>>  >> >> There will be special considerations for B2BUAs. REQ3 requires
>>>  >B2BUAs
>>>  >> >> to pass it unchanged. Of course, there is the possibility that
>>>  >> >>existing
>>>  >> >> devices will not; we cannot change that. However, devices
>>>  >compliant
>>>  >> >> with the spec should. The intent is that the solution document
>>>  >will
>>>  >> >> spell out what B2BUAs should do when they receive a Session-ID
>>>  >and
>>>  >> >>when
>>>  >> >> they do not. This will be fully covered in the solution
>>>  >specification
>>>  >> >> currently being progressed.
>>>  >> >Right.. Not being a deep SIP expert, I was not sure if a legacy
>>>  >>B2BUA
>>>  >> >would pass through a Session-ID added by a non-legacy UA (say, A)
>>>  >when
>>>  >> >it created the call to B, which might or might not be legacy. If it
>>>  >> >didn't, does it matter or does it give rise to any requirements?
>>>  >> >Presumably the legacy B2BUA would reflect the Session-ID - or if
>>> not
>>>  >A
>>>  >> >shouldn't complain if it doesn't come back
>>>  >>
>>>  >> What a deployed SBC will do varies. Some might pass the header value
>>>  >> through and some might not. We already know that some definitely
>>>  >would
>>>  >> not.
>>>  >OK.. that is what I suspected would be the case.
>>>  >
>>>  >It doesn't answer the question as to whether the SBC would always
>>>  >reflect the SID back to A, and if it didn't might A get upset. And
>>>  >hence is it a requirement that A should bite its lip rather than
>>>  >complaining if the SID doesn't come back?
>>>
>>>  What the group has requested is that INSIPID-aware SBCs would pass any
>>>  Session-ID header value through unmodified. However, aside from passing
>>>  it through, no other action is required of SBCs.
>>>
>>>  We will, however, allow an SBC to fabricate a value on behalf of a User
>>>  Agent that is not an INSIPID User Agent. The reason for this is to
>>>  allow inspection of call logs throughout a domain, for example. Imagine
>>>  a service provider edge where a customer's phone does not generate a
>>>  Session-ID, but the service provider wants one for use inside their
>>>  network.
>>>
>>>  In any case, the Session-ID is intended to be end-to-end. It originates
>>>  at each user agent and SBCs (or B2BUAs in general) just mindlessly
>>>  passing it along. If an endpoint does not receive it (or if it does not
>>>  traverse all nodes in the path), it only means we lose the ability
>>> to do
>>>  diagnostics, logging, signaling correlation, etc. using that value.
>>>
>>>  Paul
>>
> 
>