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

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 03 Mar 2007 16:12:29 -0500

inline.

Jean-Francois Mule wrote:

> 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

I dont think thats needed. The reader needs to be familiar with 
offer/answer and if you are then you know what an offerer or answerer is.

> - 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.

ok

> - same for a check, priority, state, etc.

I don't follow that one; check, priority and state don't have 
properties. The meaning of the term 'priority' and 'state' is well 
known. I don't think the terminology section is the right place to 
enumerate their specific usages in ice.

> - define related address, term used in section 5.4

not needed. I was able to ditch this term and just refer to the 
grammatical components of the SDP when needed.

> - define ICE mode/role (passive, full)

Lite and full is now defined

> - 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".

well, candidate pair is defined as one of the earlier terms...

> 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

There aren't terms though, they are grammatical components. Again, I 
want to avoid the terminology section becoming an explanation of the 
protocl.

> - for check list, s/STUN check/check  (you evoke STUN as the protocol
> to perform the checks above)

ok

> - define each protocol timer clearly with its name in that section

This doesn't belong here either. For rfc3261 we did it in an appendix, 
but just because there were a lot of them. There are only a few here.

> - 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)

added a reference to those specs, also rfc4787

> - 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)

well this is actually fixed in my working copy of rfc3489bis-06 based on 
magnus's review. So I've copied that exact same definition here.

> - valid list: consider mentioning it is a subset of the check list
> 

ok.

Thanks for the comments!

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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