Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks
RFC 7206
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
(Gonzalo Camarillo; former steering group member) Yes
(Spencer Dawkins; former steering group member) (was Discuss) Yes
Thanks for working through my discuss and comments.
(Adrian Farrel; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
(Stephen Farrell; former steering group member) (was Discuss) No Objection
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?
(Stewart Bryant; former steering group member) No Objection
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?