Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT): new (temp) draft?

[Benoit Claise <[e-mail]>]

Al, Wes

I want to review this draft before the IESG telechat tomorrow.
However, it's getting difficult to keep track of the all the changes between
     - the posted version 3
     - the diff-03-04 you sent
     - the extra proposal.

What is the best way to proceed?
     - Al, have you kept a temp version with all the changes?
     - Are we shooting for "revised-ID" at the telechat? I could start 
my review from there
     - Do we want to have a version 4 posted now?

What is the best way to proceed?

Regards, Benoit.
> Al,
>
> As always, a reasoned response from you.
>
> A
>
>> -----Original Message-----
>> From: Al Morton [mailto:[e-mail]]
>> Sent: 09 April 2012 14:45
>> To: [e-mail]; 'Samuel Weiler'; 'The IESG'
>> Cc: [e-mail]; 'Murphy, Sandra'; 'Dan Frost';
> [e-mail];
>> [e-mail]
>> Subject: RE: Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with
> DISCUSS
>> and COMMENT)
>>
>> Hi Adrian,
>>
>> Thanks for clearing your DISCUSS. As always, the memo reads better
>> owing to your efforts, and those of Dan and Sandra.
>>
>> Here's what I added in section 4.4, with supporting modifications
>> elsewhere:
>>
>> We add the following guidance regarding the responder process to
>> "send a Type-P packet back to the Src as quickly as possible".
>>
>> A response that was not generated within Tmax is inadequate for any
>> realistic test, and the Src will discard such responses. A responder
>> that serves typical round-trip loss testing (which is relevant to
>> higher-layer application performance) SHOULD produce a response in 1
>> second or less. A responder that is unable to satisfy this
>> requirement SHOULD log the fact so that an operator
>> can adjust the load and priorities as necessary. Analysis of
>> responder time-stamps [RFC5357] that finds responses are not
>> generated in a timely fashion SHOULD result in operator notification,
>> and the operator SHOULD suspend tests to the responder since it may
>> be overloaded. Additional measurement considerations are described in
>> Section 8, below.
>>
>> Ciao,
>> Al
>>
>>
>> At 02:04 PM 4/8/2012, Adrian Farrel wrote:
>>> Hello Al,
>>>
>>>>>> Although IPPM has never formalized a strategy, we have been repeating
>>>>>> security material in metrics RFCs. This allows new folks to read
>>>>>> and improve the text, rather than be referred to a fixed reference.
>>>>>> It seems to work.
>>>>> I can see how that would lead to the verbatim reproduction of
>>> text. I have no
>>>>> problem with that per se, but I worry that the process has
>>> become formulaic
>>>>> without any new consideration of security for the specific
>>> document in hand.
>>>>> If you tell me that this is adequate for this document and no
>>> refinement is
>>>>> needed in this case, I will clear and let the Security ADs and
>>>>> Directorate worry
>>>>> about the security details.
>>>> I think it is. We are essentially conducting a two-way version of RFC 2680
>>>> (one-way loss), so all the same considerations apply. We have exposure in
>>>> two (possibly different) paths, but the threats are the same.
>>> OK. I cleared my Discuss.
>>>
>>>>>>>> 1. The phrase "as immediately as possible" that appears a couple
> of
>>>>>>>> times in the text (and that seems to originate in RFC
>>> 5357) is a bit
>>>>>>>> unfortunate.  "Immediately" or "as quickly as possible" are
> better.
>>>>>> This odd turn of phrase resulted from many hours of discussion
>>>>>> dating back to TWAMP's development.  We wear the scar proudly.
>>>>> Well, this is only a Comment, and you do not have to address it, but "as
>>>>> immediately as possible" is hogwash. It is a butchery of the
>>>>> language and means
>>>>> nothing!
>>>>>
>>>>> In fact, and as a general principle of writing standards, even
>>> "as quickly as
>>>>> possible" would be poor. The English would be fine, but it is a
> subjective
>>>>> statement against which conformance cannot be measured.
>>>> Under typical protocol development circumstances, we could write a
>>>> real requirement:
>>>>           The response MUST be prepared and sent on the wire in<X seconds.
>>>>
>>>> But that's not the case here.  Instead we have desire that the response
>>>> will be sent immediately, yet we understand that measurement systems will:
>>>>
>>>>    - occasionally execute higher priority processes that delay the response
>>>>      (processing routing updates comes to mind)
>>>>    - carry 2 time stamps that allow the tester to determine if the response
>>>>      was generated fast enough for the intended purpose
>>>>    - serve purposes with greater or lesser need for immediacy
>>>>    - either meet the variable needs for measurement immediacy or not, and
>>>>      this is a judgement that can be made on each and every
>>> measurement packet
>>>> Is it useful to explain some/all of this in the memo?
>>> I don't think so. I would just fix the text to say what you mean!
>>>
>>> I found key text in your mail to be:
>>>
>>>>      allow the tester to determine if the response
>>>>      was generated fast enough for the intended purpose
>>> Surely it is not enough to have the tester discard all response because they
>>> were not fast enough. Surely it is a good idea to give *meaningful* advice to
>>> the responder about how to respond so that the response is "fast
>>> enough for the
>>> intended purpose."
>>>
>>> Clearly "immediately" is not what is meant since it is allowed for
>>> this to be a
>>> background process. So perhaps the correct thing to do is warn the
>> implementer
>>> of the responder about the expectations of the tester. Something like:
>>>
>>> A tester will normally find that a response that was not generated within 3
>>> weeks is inadequate for the purposes of a realistic test and will discard
> such
>>> responses. Therefore, a responder needs to ensure that at least 67.2% of
>>> responses are generated within 1 hour of receiving the request. A
>>> responder that
>>> is unable to satisfy this requirement SHOULD log the fact so that an operator
>>> can adjust the load and priorities as necessary. A tester that finds that
>>> responses regularly are not generated in a timely fashion SHOULD notify the
>>> operator that the responder is compromising the tests, and SHOULD suspend
>>> sending requests to the responder since it is clearly overloaded.
>>>
>>>
>>> Ciao,
>>> Adrian
>