On 11/1/11 3:28 PM, Vijay K. Gurbani wrote:
On 10/31/2011 06:10 PM, Ari Keränen wrote:
- S1: The draft says, "This specification does so by following the
outline of ICE itself, and calling out the additions and changes
necessary in each section of ICE to support TCP candidates."
Does this imply that this specification normatively updates
rfc5425 (the ICE RFC)? If so, this is not reflected in the
masthead for the document as "Updates: RFC 5425".
Actually no. These additions are specific to TCP so the (UDP) ICE RFC is
not updated. In an effort to keep this draft reasonably compact, only
the delta from the RFC5245 is defined. So, when something is not defined
here, the behavior defined in RFC5245 is assumed.
Ari: Thanks for the clarification. In that case, I would think that
inserting some text to the document fashioned along what you write
above will help those folks who would read your document and assume
normative changes to rfc5425.
A small change such as this will suffice (please feel free to edit):
OLD:
This specification does so by following the outline of ICE itself,
and calling out the additions and changes necessary in each section
of ICE to support TCP candidates.
NEW:
This specification does so by following the outline of ICE itself,
and calling out the additions and changes necessary to support TCP
candidates in ICE. The base behaviour of ICE [RFC5245] remains
unchanged except for the extensions in this document that define the
usage of ICE with TCP candidates.
Makes sense, we'll use that.
One more comments; please see below.
- S4.1, last paragraph. It says that, "TCP-based STUN transactions
are paced out at one every Ta seconds." However, rfc5245 Section
16 says that, "These transactions are paced at a rate of one
every Ta millisecond, ..."
I suspect that in your draft, Ta refers to the same Ta as in
rfc5245, so it seems to me that they should be paced one every
Ta milliseconds to conform to rfc5245, no?
This one is a bit tricky since even RFC5245 is not consistent with this
(e.g., section 5.8. of RFC5245 says "Ta seconds later", and section
16.1. is even more vague). We chose to use "seconds" so that the
formulas in 16.1. of 5245 would have right units, but actually in the
text 5245 does use "milliseconds" more often. I'm fine either way but
since you found this confusing, probably the milliseconds is a better
choice.
I believe that ms is what is intended (but the author of rfc5245 can
always be asked for a clarification). Here's my reasoning:
The formulas of Section 16.1 are stated in terms of ms; i.e.,
Ta = MAX(20ms, 1/sum_{i=1}^k (1/Ta_i)). To get an authoritative answer
from the MAX() function would require both parameters to be the
same units. That is, MAX(20, 3) is rather ambiguous if the first
parameter is in terms of ms and the second in terms of second.
On the other hand, MAX(20, 3000) is straightforward to evaluate
since both parameters are in terms of ms.
Yeah, probably it's more clear to use ms. We'll go with that.
Thanks,
Ari
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
