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

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

Hi Al,

Thanks for the response.

> >Adrian Farrel has entered the following ballot position for
> >draft-ietf-ippm-rt-loss-03: Discuss
> >
> > > General observation: It's not clear to me what the IPPM WG strategy
> > > is for security considerations sections in metric definition
> > > documents.  For example, the security section of this document more or
> > > less repeats the one in (for example) RFC 2681, which itself
> > > duplicates verbatim the one in RFC 2680, and the issues discussed are
> > > general ones with measurement protocols rather than specific ones with
> > > the metric that is the subject of the document.  There's probably a
> > > better way to organize this.
> 
> 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.

> > > 3. Section 9.3 mentions the use of cryptographic hashing "to
> > > discourage the kind of interference mentioned above"; while this
> > > would mitigate the second form of interference, it wouldn't help
> > > with the first.
> >
> >I would add that "discourage" might not be an appropriate word.
> 
> New paragraph addresses Sandy and Dan's points.

Thanks.

> >COMMENT:
> >
> >Other comments coming from Dan Frost's review
> >
> > > 1. Although it's probably obvious to most readers, it would be helpful
> > > to provide a brief informal definition of "round-trip loss" early in
> > > the introduction.  A mention of the venerable "ping" procedure would
> > > also not be amiss.
> 
> Did both.
> 
> > > 2. Most of the text seems to assume an "active" or test-based
> > > measurement approach, but Section 9.2 refers to passive measurement.
> > > It would be helpful to discuss the applicability of the latter
> > > approach.
>
> Clarified the scope for passive.
> 
> > > Nits:
> > >
> > > 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.

> > > 2. Section 5.4, second paragraph: s/affects/effects/
> > >
> > > 3. Section 8, second paragraph: s/Two key features ... is described/
> > >  Two key features ... are described/
> > >
> > > 4. Section 9.3, first paragraph:
> > > OLD
> > >  it is possible to change the processing of the packets (e.g.
> > >  increasing or decreasing delay) that may distort the measured
> > >  performance.
> > > NEW
> > >  it is possible to change the processing of the packets (e.g.
> > >  increasing or decreasing delay) in a way that may distort the
> > >  measured performance.
> > > END
> 
> thanks for pointing out the above.

Cheers,
Adrian