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

[Tero Kivinen <[e-mail]>]

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.

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. 

> 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.

> 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.

> 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]