Subject: [MMUSIC] some comments on ice-12, part two

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 21 Nov 2006 15:30:03 -0700

These comments are probably already on your list: comments on the terminology/definitions of draft ice-12, for you consideration.

Jean-Francois.

--- section 3, terminology
- define offerer/answerer as you use it in peers
- for the candidate definition, consider also just listing the properties or attributes of a candidate in its definition: type, priority, foundation, base, state, "in-use" status, etc. It may help folks trying to represent or visualize a candidate as an object.
- same for a check, priority, state, etc.
- define related address, term used in section 5.4
- define ICE mode/role (passive, full)
- in this section particularly, consider expanding things like "candidate pair" into "a pair of candidates" or "list of 2 candidates, one local candidate, one remote candidate". 
This comment may read very simplistic but it may help folks with the levels of encapsulation early on ({IP, port}, (IP,port)} 
- define ice-pword, ice-fragment
- for check list, s/STUN check/check  (you evoke STUN as the protocol to perform the checks above)
- define each protocol timer clearly with its name in that section
- add a sentence for the reader to also be familiar with terminology of 3489bis, and may be even point what terms are defined there like Binding requests (or indication given the proposed change on that one)
- transport address: consider having the exact same definition as in 3489bis (which seems to unnecessarily restrict the transport port to TCP|UDP in the definition)
- valid list: consider mentioning it is a subset of the check list 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic