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

["Adrian Farrel" <[e-mail]>]

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