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

From: Kuhn Nicolas <[email-masked]>
Date: Tue, 17 May 2016 08:31:05 +0000

Dear Tero, 

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. 

Kind regards,

The authors.

-----Message d'origine-----
De : Tero Kivinen [mailto:[email-masked]] 
Envoyé : mercredi 27 avril 2016 15:07
À : [email-masked]; [email-masked]; [email-masked]
Objet : Secdir review of draft-ietf-aqm-eval-guidelines-11

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Summary: ready with nits.

This document describes various criteria for doing characterizations of active queue management schemes. As this is not really a protocol document there is not that much of security issues that could raise from here. The security considerations section says

   Some security considerations for AQM are identified in [RFC7567].This
   document, by itself, presents no new privacy nor security issues.

and I agree with that.

As for nits, the document uses very heavily references in a format where it makes document very hard to read. The references are used in such way, that if they are removed or hidden, the whole document comes completely unreadable. I think the references should only provide extra information, and the document should be readable even if you remove everything between [], but in this case the text comes like
this:

   An AQM scheme SHOULD adhere to the recommendations outlined in
   [], and SHOULD NOT provide undue advantage to flows with
   smaller packets [].

Also references style (i.e. whether it is [RFCxxxx] or [1]) should not affect the document readability, but in this case it makes things very hard to read when text is like:

   [1] separately describes the AQM algorithm implemented in a
   router from the scheduling of packets sent by the router.

When you are reading the document and you do not remember what [1] (or
[RFC7567]) actually is it forces you to go and check the reference section to see what this document is.

It would be better if the text would be expanded so that the actual text is readable even if you remove all references, i.e. the first example would come:

   An AQM scheme SHOULD adhere to the recommendations outlined in Byte
   and Packet Congestion Notification document [RFC7141], and SHOULD
   NOT provide undue advantage to flows with smaller packets.

(I have no idea why the second reference was there at all, it might be useful if it provided section talking about that, but as the whole document is "IETF Recommendations Regarding Active Queue Management", I do not think it relates only to the smaller packets.
--
[email-masked]

---

From: Kuhn Nicolas <[email-masked]>
Date: Tue, 17 May 2016 10:53:25 +0000

Hi again, 

FYI, attached to this email is what could be a new ID for the document. 

Kind regards,

Nicolas

-----Message d'origine-----
De : Kuhn Nicolas 
Envoyé : mardi 17 mai 2016 10:31
À : 'Tero Kivinen'; [email-masked]; [email-masked]; [email-masked]
Cc : 'Mirja Kuehlewind (IETF)'
Objet : RE: Secdir review of draft-ietf-aqm-eval-guidelines-11

Dear Tero, 

Kind regards,

The authors.

-----Message d'origine-----
De : Tero Kivinen [mailto:[email-masked]] Envoyé : mercredi 27 avril 2016 15:07 À : [email-masked]; [email-masked]; [email-masked]
Objet : Secdir review of draft-ietf-aqm-eval-guidelines-11

and I agree with that.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 17 May 2016 15:07:59 +0300

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.
-- 
[email-masked]

---

From: Kuhn Nicolas <[email-masked]>
Date: Tue, 17 May 2016 15:23:42 +0000

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]). It depends who is targeted by the draft. I think (hope?) that someone using these guidelines would have read RFC7567 first.  

Nico

-----Message d'origine-----
De : Tero Kivinen [mailto:[email-masked]] 
Envoyé : mardi 17 mai 2016 14:08
À : Kuhn Nicolas
Cc : [email-masked]; [email-masked]; [email-masked]; Mirja Kuehlewind (IETF)
Objet : RE: Secdir review of draft-ietf-aqm-eval-guidelines-11

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

--
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 May 2016 11:59:34 +0300

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.

-- 
[email-masked]