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

["Black, David" <[e-mail]>]

Hi Martin,

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

That's fine, but something does have to be done about that RFC 5245 "MUST"
requirement, which is a "requirement" not just "advice" ;-).

I'd expect that even overriding RFC 5245 counts as an Update,
because the result would be that the original RFC 5245 "MUST" requirement
is no longer globally applicable to all uses of RFC 5245.  In other words,
overriding RFC 5245 effectively rewrites the "MUST" to become "MUST, except
as further specified by the consent RFC."

Sorry to put the emphasis on the "Update" process, but I've recently had a
*very* long discussion about whether or not it was ok for another draft to
modify an underlying RFC - the answer in that other case was "<bleep> NO!"
and some interesting text editing resulted.  In contrast, for the present
situation case, I would think that overriding RFC 5245 is ok, but that
change does need to be called out.

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

That new text looks good.

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

To the extent that my "editorial" suggestions aren't actually editorial,
the suggestions are probably wrong.  As they're intended to be editorial,
I'm ok with them being ignored or dealt with in some other fashion.

Thanks,
--David

> -----Original Message-----
> From: Martin Thomson [mailto:[e-mail]]
> Sent: Wednesday, May 27, 2015 7:42 PM
> To: Black, David
> Cc: Ram Mohan R (rmohanr); joel jaeggli; [e-mail]; Dan Wing
> (dwing); Tirumaleswar Reddy (tireddy); [e-mail]; [e-mail];
> [e-mail]; Alissa Cooper ([e-mail])
> Subject: Re: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
> 
> 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.