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

From: Elwyn Davies <[email-masked]>
Date: Mon, 23 Sep 2013 14:17:42 +0100

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-insipid-session-id-reqts-08.txt
Reviewer: Elwyn Davies
Review Date: 23 September 2013
IETF LC End Date: 24 September 2013
IESG Telechat date: (if known) -

Summary:
Amost ready with very minor issues/nits.  The only issue that is of any
consequence to my mind is handling of legacy B2BUAs etc. 

Major issues:
None.

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?    

Nits/editorial comments:
s1: The purpose of the document is not explicitly set out in s1 -
although of course it is clear in the abstract.  s1 should contain a
near copy of the abstract which also states that the document proposes
requirements for a new SIP header (I assume) called "Session-ID". 

s1, para 2:
> This important fact makes it
>    impossible for call identifiers to be exchanged end-to-end when a
>    network uses one or more session protocols.
I would have thought that using just one session protocol didn't give problems.
Do you mean "... uses more than one session protocol."?

s1, last para: Expand acronym PBX.

s3.1, para 6: s/some constraint/some constraints/ [arguable!]

s3.2, Figure 1: [very nitty] Might be desirable to indicate the
existence of the middlebox(es) on the message arrows 
(e.g.,  .....()..... or some such). Also label A and B as user agents.

s3.2, 4th bullet: s/(e.g., Alice and Bob)/(e.g., between Alice and
Bob)/ 

s3.2, 5th bullet and sub-bullets:  The 2nd sub-bullet is a bit
confusing:  Maybe:
OLD:
     o A call between any two user agents wherein two or more user
       agents are engaged in a conference call via a conference focus

         o Each call between the user agent and the conference focus
           would be a communication session

         o Each communication session is a distinct communication
           session
NEW
     o A call between any two user agents wherein two or more user 
       agents are engaged in a conference call via a conference focus:

         o each call between the user agent and the conference focus
           would be a communication session, and

         o each of these is a distinct communication session.

s3.2, 6th bullets and sub-bullets: Add periods (full stops) at end of each.

s4.1: Acronyms UA, B2BUA and SBC need expansion (UA and B2BUA are
effectively used in s1.  SBC may need a reference (RFC 6135?)

s4.1: Desirable to specify that "(SIP) dialog" is defined in s12 of RFC
3261.

s4.2: Once you have expanded SBC in s4.1 you could use it in s4.2!

s4.3, para 1: s/SIP users, device or domain identity./SIP users, device
or domain identities./

s4.3, para 1: s/or when security issue arise (e.g./or when a security
issue arises (e.g.,/

s4.7, para 1: s/between two or more parties./between two or more parties
other than the one setting up the call./

s7, para 2: s/In adherence with/In adhering to/

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 Sep 2013 04:25:20 +0000

Elwyn,

Thanks for the review.  Please see my comments below:

------ Original Message ------
From: "Elwyn Davies" <[email-masked]>
To: "General Area Review Team" <[email-masked]>
Cc: [email-masked]
Sent: 9/23/2013 9:17:42 AM
Subject: Gen-art LC review of draft-ietf-insipid-session-id-reqts-08.txt
>the Session-ID if it didn't understand it. Does this also affect

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.

>requirements for a new SIP header (I assume) called "Session-ID".

You're right.  I struggled with placement.  Finally, I decided that it 
sounds best as the last paragraph of Section 1 (just copying the entire 
abstract).  Sound OK?

I could mention "Session-ID" as the name of the header, but this 
actually could be dangerous.  At present, we're struggling with 
interworking with an already-existing (and implemented) I-D that uses 
"Session-ID".  We hope to re-use the same header and provide 
interworking with that draft.  However, if we find we cannot, we may 
want to select a different header name.

>Do you mean "... uses more than one session protocol."?

Good catch.  I changed it to "uses both of these session protocols".

>s1, last para: Expand acronym PBX.

Done.

>s3.1, para 6: s/some constraint/some constraints/ [arguable!]

Sounds better.

>(e.g., .....()..... or some such). Also label A and B as user agents.

I changed it to show "UA-A" and "UA-B".  I'm not sure what to put in the 
lines going left/right to showcase a B2BUA.    Something like this?

        UA-A                                                  UA-B
        SIP message(s) ------- [ B2BUAs ] --------> SIP message(s)
        SIP message(s) <------ [ B2BUAs ] --------- SIP message(s)
I'm not sure that's more readable.  What did you have in mind?

>  s3.2, 4th bullet: s/(e.g., Alice and Bob)/(e.g., between Alice and

Done.

>          o each of these is a distinct communication session.

Done.

>s3.2, 6th bullets and sub-bullets: Add periods (full stops) at end of 

Periods just at the end of the two sub-bullets starting  with "The call 
between Alice..."?

>effectively used in s1. SBC may need a reference (RFC 6135?)

Did you mean RFC 5853?

>s4.1: Desirable to specify that "(SIP) dialog" is defined in s12 of RFC

Done.

>s4.2: Once you have expanded SBC in s4.1 you could use it in s4.2!

Done.

>s4.3, para 1: s/SIP users, device or domain identity./SIP users, device

Done.

>s4.3, para 1: s/or when security issue arise (e.g./or when a security

I think that should have been "security issues arise", so I changed it 
to that.

>other than the one setting up the call./

Done.

>  s7, para 2: s/In adherence with/In adhering to/

Done.

Thanks!
Paul

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 25 Sep 2013 10:29:04 +0100

Hi, Paul.

Thanks also for the speedy response.

Just two items to consider.. I've deleted all the items where there is
agreement.

Regards,
Elwyn
 
> 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
> want to select a different header name.
Your problem here is that Session-ID is used explicitly in the rest of
the document (starting with the title of Section 3 ;-) ).  So I guess
you have to find some form of weasel words like 'tentatively named
"Session-ID"' or '(NSIDIH - new session id identifying header)' and use
NSIDIH instead in the rest of the doc.  
<<snip>>

> I'm not sure that's more readable.  What did you have in mind?
Maybe just...
        UA-A                     B2BUAs                       UA-B
        SIP message(s) ------- [] --- [] ---------> SIP message(s)
        SIP message(s) <------ [] --- [] ---------- SIP message(s)

> Periods just at the end of the two sub-bullets starting  with "The call 
Yep.
<<snip>>
> >effectively used in s1. SBC may need a reference (RFC 6135?)
Looking at it probably yes!
I was (mindlessly) going on the ref in the RFC Editor's abbreviation
expansion list -
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
They probably ought to be told this is not the best ref.
<<snip>>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 Sep 2013 22:22:19 +0000

Elwyn,

>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.  If a deployed SBC does not pass the header through unmodified, 
then it "breaks" the end-to-end identifier.  We know that and it is one 
of the reasons for doing this work.  We want something that could be 
used end-to-end if domain owners will allow it.  Other values are not 
necessarily safe to use end-to-end (e.g., they might leak personal 
data).

>NSIDIH instead in the rest of the doc.

I can fix this rather easily.  I'll change "Session-ID" to "session 
identifier".  In no place are we explicitly referring to the header 
itself, but just the "identifier".

>         SIP message(s) <------ [] --- [] ---------- SIP message(s)

OK, done.

>They probably ought to be told this is not the best ref.

OK, I'll insert an informative reference to that spec.

Paul

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 25 Sep 2013 23:47:50 +0100

Hi, Paul.
[Resend to all addressees]

We seem to be converging...

On Wed, 2013-09-25 at 22:22 +0000, Paul E. Jones wrote:
> >>  spell out what B2BUAs should do when they receive a Session-ID
and 
> >>when
> 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?

> If a deployed SBC does not pass the header through unmodified, 
This is indeed an admirable aim.
> itself, but just the "identifier".
That also solves your problem. Excellent.
> >>  I changed it to show "UA-A" and "UA-B". I'm not sure what to put
in 
> >>the
Fine.

Cheers,
Elwyn

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 26 Sep 2013 03:03:54 +0000

Elwyn,

Please see my comments below:

------ Original Message ------
From: "Elwyn Davies" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: "General Area Review Team" <[email-masked]>; 
[email-masked]
Sent: 9/25/2013 6:47:50 PM
Subject: Re: Gen-art LC review of 
draft-ietf-insipid-session-id-reqts-08.txt
>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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 26 Sep 2013 09:42:10 +0000

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:[email-masked]]
> Sent: 26 September 2013 04:04
> To: Elwyn Davies
> Cc: General Area Review Team; draft-ietf-insipid-session-id-
> [email-masked]
> Subject: Re: Gen-art LC review of draft-ietf-insipid-session-id-reqts-
> 08.txt
> 
> Elwyn,
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 26 Sep 2013 21:00:14 +0000

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)" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>; "Elwyn Davies" 
<[email-masked]>
Cc: "General Area Review Team" <[email-masked]>; 
"[email-masked]" 
<[email-masked]>
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
>
>>  >> >> >if the B2BUA doesn't support Session-ID. There could be a 
>>number
>>  >of
>>  >> >Presumably the legacy B2BUA would reflect the Session-ID - or if 
>>not
>>  >A