Re: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-rfc5405bis-18: (with COMMENT)

[Stephen Farrell <[e-mail]>]

On 15/10/16 07:50, Eggert, Lars wrote:
> Hi,
> 
> On 2016-10-14, at 17:46, Stephen Farrell <[e-mail]>
> wrote:
>>> I'm happy to take out the references to GSS-API and/or AH, but
>>> note that they are only listed as options. I also note that they
>>> are not historic or obsolete, AFAICT.
>> 
>> They're not. But they're probably also not that useful as they're
>> not much used for UDP applications afaik. Text about how to
>> successfully use DTLS would be more useful these days I'd say. Or
>> maybe JOSE or COSE stuff. Sorry no to have good text.
>> 
>> If you want, I can ask on saag or you can just go ahead if you'd
>> prefer not wait.
> 
> if someone from saag can go over the current text by - say - the end
> of next week, *and* we can be sure that the resulting edits are such
> that they have obvious consensus in SAAG, TSVWG, the IETF and the
> IESG (such that we don't need to redo all the consensus calls) -
> sure. Feasible?

Seems unlikely, but I'll ask and we'll see if we get good
enough text in response. Default being to just stick with
current text.

Cheers,
S.

> 
>>>> - 3.1.1: "Latency samples MUST NOT be derived from ambiguous 
>>>> transactions" - I don't understand how that MUST NOT can be 
>>>> universally applied, maybe that's just a use of 2119 terms for 
>>>> emphasis?
>>> 
>>> I don't follow. Of course this can be universally applied?
>> 
>> Well, the MUST NOT assumes that there's an unambiguous definition
>> of "ambiguous transaction" and I'm not sure there is, is there?
> 
> If you define protocol with transactional semantics (i.e.,
> request/response) you *know* whether you can unambiguously relate
> request packets with response packets. If there can be ambiguity in
> some cases (as with TCP), then as long as you can identify those
> cases, you MUST NOT derive latency samples from them. If you can't
> relate request and response packets at all, you have designed a
> protocol that will make it very difficult to do any sort of
> congestion control for :-) including being able to compute an RTT.
> 
> Lars
>