Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13

[Martin Thomson <[e-mail]>]

I apologize for not catching these, but I think that you are
collectively headed toward changing the intent of the draft in ways
that might not be good.  Unfortunately, I'm not always able to consume
the amount of email that is produced in relation to this draft.

On 27 May 2015 at 15:05, Black, David <[e-mail]> wrote:
> However, the first sentence in section 10 of RFC 5245 says:
>
>    All endpoints MUST send keepalives for each media session.
>
> Therefore, this draft normatively modifies RFC 5245, but there was no
> indication of that modification during IETF Last Call, as the draft
> contains neither an Updates: header nor a summary description of changes
> to RFC 5245.

That's one interpretation.  Or, we could say - more explicitly - that
this is intentionally contrary to the advice in RFC 5245.  We're
overriding 5245, not patching it.  Other users of RFC 5245 can
continue to be bound by the restriction.

BTW, no ICE implementation I'm aware of follows the requirement to
send keep-alives (I'm certain that some compliant implementations
exist, just that my limited exposure hasn't included one).  That
reduces the risk that a recipient is checking and enforcing that peers
are sending keepalives to nil, in case you are concerned about the
interop risk.

>> >> [4] In Section 4.1, please explain or provide a reference for what "paced"
>> >> means in "paced STUN connectivity checks or responses."
>>
>> Pacing is explained in the same section below. Let us know if this is not
>> sufficient/not clear.

Actually, "paced" has a specific meaning in ICE and the word was used
intentionally: https://tools.ietf.org/html/rfc5245#section-16

The intent is to permit ICE connectivity checking, no more, no less.
Absolutely not consent maintenance.

Perhaps something like:

   An endpoint MUST NOT send data toward any transport address unless
the receiving endpoint has consented to receive data, unless the
messages are those that are used to establish consent.  Connectivity
checks that are paced as described in Section 16 of [RFC5245] and
responses to connectivity checks are permitted.


---
I disagree with David about the editorial nature of some of the
changes he suggests, but I'm prepared to wait for proposals and
discuss them.  I'd be very happy if those changes manifested in the
form of pull requests.