Re: [secdir] Secdir review of draft-ietf-aqm-eval-guidelines-11

[Kuhn Nicolas <[e-mail]>]

Dear Tero Kivinen, 

Thank you for your review and sorry for the delay of our answer. We will consider your comments as you can see inline.
We will push an updated version including the changes as soon as possible.
Please find attached to this email the diff between v11 and expected v12.

Kind regards, 

The authors

-----Message d'origine-----
De : Tero Kivinen [mailto:[e-mail]] 
Envoyé : jeudi 19 mai 2016 11:00
À : Kuhn Nicolas
Cc : [e-mail]; [e-mail]; [e-mail]; Mirja Kuehlewind (IETF)
Objet : RE: Secdir review of draft-ietf-aqm-eval-guidelines-11

Kuhn Nicolas writes:
> I agree with you: this format does not ease the reading.  This is 
> however how it is done in, e.g. RFC 7567. This is more readable for 
> someone aware of the activity in the working group (for someone 
> familiar with the mentioned RFCs, seeing [RFC7567] is easier than 
> [5]).

Yes, using "as specified in [RFC7567]" is better than using "as specified in [5]", but using "as specified in the AQM recommendations document [RFC7567]" is even better, and provides the RFC number for those who knows those, but also tells those who just read this document information what that document is without the need to go and check the document title.

[NK] Indeed. We have had a look at the references to RFC and tried to improve the way they are cited, when we thought that including details was interesting. 

Also you have several references ot the RFC7567 even in the same
sentence:

   Not all endpoints (or applications) using TCP use the same flavor of
   TCP.  Variety of senders generate different classes of traffic which
   may not react to congestion signals (aka non-responsive flows
   [RFC7567]) or may not reduce their sending rate as expected (aka
   Transport Flows that are less responsive than TCP[RFC7567], also
   called "aggressive flows").  In these cases, AQM schemes seek to
   control the queuing delay.

IF those refer to the specific recommendations in the RFC7567 then pointing the section number or similar would make this text much more useful than just pointing to the same document multiple times in same sentence. 

[NK] You are right. We have checked the references to that RFC and be more precised on the sections that are pointed when it makes sense.

> It depends who is targeted by the draft.

I have no idea who the intended audience for this draft is. I could not find that from the draft.

[NK] True. We have clarified in the abstract that the intended audience is lab tester.

> I think (hope?) that someone using these guidelines would have read
> RFC7567 first.

That hope is completely unjustified. There are always several people reading RFCs, who have no idea what the referenced document specifies.
Quite often it is someone pointing them out that the RFC xxxx in section yyy says zzz, do something, and then the person starts reading that RFC xxxx without any prior knowledge about the subject. He might end up reading relevant RFCs later, but he has to start from somewehere. I think it is better if we can make RFCs easier to understand for persons who just start reading them.

Also architecture, recommendations, and guidelines documents are quite often so that actual implementors are not that interested reading on them until they are forced to do so. They are important while we are writing the actual specifications, as that creates the base work for making protocol design, but when you are implementing the actual bits on the wire, implementors usually just go directly to the bits on wire and try to make them work, ignoring as much of other documents as they can.

[NK] We agree on that and believe that with the more specified pointers to e.g. RFC 7567 it is better.
Thanks, 

> Nico
> 
> -----Message d'origine-----
> De : Tero Kivinen [mailto:[e-mail]] Envoyé : mardi 17 mai 2016 
> 14:08 À : Kuhn Nicolas Cc : [e-mail]; [e-mail]; 
> [e-mail]; Mirja Kuehlewind 
> (IETF) Objet : RE: Secdir review of draft-ietf-aqm-eval-guidelines-11
> 
> Kuhn Nicolas writes:
> > Thanks a lot for your review. If you believe that your proposed 
> > changes on the references format should deserve changes in the 
> > document and a new ID, please let us know, we would try to integrate 
> > them ASAP.
> 
> > Current format makes the document hard to read, especially for those 
> > who do are not very familiar with the area, as it is hard to 
> > remember which rfc is which (7567, 5481, 2679 etc)
> 
> > My recommendation would be to fix that, but this is my personal preference on the matter.
> 
> 
> --
> [e-mail]

--
[e-mail]