Skip to main content

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?