Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks
draft-ietf-insipid-session-id-reqts-11
Yes
(Gonzalo Camarillo)
No Objection
(Adrian Farrel)
(Barry Leiba)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Richard Barnes)
Note: This ballot was opened for revision 09 and is now closed.
Gonzalo Camarillo Former IESG member
Yes
Yes
(for -09)
Unknown
Spencer Dawkins Former IESG member
(was Discuss)
Yes
Yes
(2014-02-07 for -10)
Unknown
Thanks for working through my discuss and comments.
Adrian Farrel Former IESG member
No Objection
No Objection
(for -09)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -09)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -09)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -09)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -09)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -09)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2014-02-10)
Unknown
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 IESG member
No Objection
No Objection
(2014-02-04 for -09)
Unknown
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?