Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks
RFC 7206

Note: This ballot was opened for revision 09 and is now closed.

(Gonzalo Camarillo) Yes

(Spencer Dawkins) (was Discuss) Yes

Comment (2014-02-07 for -10)
No email
send info
Thanks for working through my discuss and comments.

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

Comment (2014-02-04 for -09)
No email
send info
It is expected that the ITU-T will define protocol elements for H.323
to make the end-to-end signaling possible.

This looks like the IETF making a demand on the ITU.
Perhaps "It is anticipated..."?

Are there any privacy considerations associated with this identifier?

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2014-02-10)
No email
send info
Thanks for addressing my discuss points in -11. I didn't check
the comments below, so they may also have been handled.

---- OLD COMMENTS

3.1 - as-is, the term session is so ill-defined in this section
that it could be considered to be ok for a session to last a
year. It might be worth just saying here its meant for what a
user would consider a call in most common cases.

3.1 - you confused me:-) 3rd para says "three parties" but
earlier you said "exactly two." I think what you mean is that
the term party might have different meanings in different
protocols? (It becomes clear later though.)

4.3 - if a privacy enhancing B2BUA is present, then I don't
think I buy the proposition that it won't mess with the session
id. 

4.4 - typo s/where/were/

4.6 - first use of "restrictive" seems wrong. I think you mean
lax or maybe expressive or permissive (as the secdir review
suggested).

5 - REQ9 could contradict what I'd like to see in REQ4. (Just
noting that.)

7 - saying you MUST NOT use MAC address etc is not right. You
could use those, so long as they cannot be derived from the
session ID, e.g. "AES(k,MAC||random)" could be used for a k
known only the the initiator perhaps. I'm not saying you 
should do that, but that the MUST NOT seems OTT.

7 - I don't get how the integrity requirements stated can be
independent of the n/w infrastructure etc. To me, that reads
like text added to just sound good, so I must be missing
something about it - can you explain the last paragraph a bit
more?

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Martin Stiemerling) No Objection