draft-ietf-pilc-error-07.txt - some fixes requested by IESG

Allison Mankin <mankin@ISI.EDU> Fri, 18 May 2001 17:54 UTC

Posted-Date: Fri, 18 May 2001 13:54:51 -0400
Message-Id: <10105181754.AA15466@maia.east.isi.edu>
To: gabriel montenegro <gab@sun.com>, Markku Kojo <kojo@cs.Helsinki.FI>, aaron@PanAmSat.com, spencer.dawkins@fnc.fujitsu.com
Cc: sob@harvard.edu, pilc@grc.nasa.gov
Reply-To: mankin@ISI.EDU
Subject: draft-ietf-pilc-error-07.txt - some fixes requested by IESG
Date: Fri, 18 May 2001 13:54:51 -0400
From: Allison Mankin <mankin@ISI.EDU>
Sender: owner-pilc@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 2077
Lines: 47

ERROR authors and PILC chairs,

The IESG completed a discussion of ERROR yesterday and overall
would like it to advance, but we need two issues resolved. 
With the working group involved in resolving the issues, there
is very little chance that further last-calling will be needed.

Allison

Issues with draft-ietf-pilc-error-07.txt

1.
-----------
As the To: list heard last week, there was an oversight about 
updating the discussion of RFC 3042 (which, by the way, has been
implemented and exercised significantly in Linux recently).
The easiest course is to leave the recommendation about it in
Future Work (Section 4.0) with a text update.  The IESG accepted
this approach, i.e. replacing Section 4.0 first paragraph with:


   "Limited Transmit" [RFC3042] has been specified as an optimization
   extending Fast Retransmit/Fast Recovery for TCP connections with
   small congestion windows that won't generate three duplicate
   acknowledgements. This specification is deemed safe, and it also provides
   benefits for TCP connections with larger congestion windows when
   losses occur at or near the right edge of the window. Implementors
   should evaluate this standards track specification for TCP in
   loss environments.

2.
-----------
The Security Considerations section is very terse.  It is a good
comment as far as it goes, but it should say explicitly that
the fact recommended methods coexist with end-to-end IPSec use is
in contrast to PEP-based methods, which do not.  In addition, are
there additional insights about the security considerations of the
specs that ERROR recommends that either time or the special
conditions of highly errored links should cause you to add?  Please
consider and enhance this section.  

A new resource to help with enhancing your Security Considerations
is draft-rescorla-sec-cons-03.txt.  The IAB has worked with the
authors and hopes to issue this as an IAB-endorsed recommendation in
the near future.  IESG would like to see folks use it and also we
welcome you to review and comment on it to IAB and ourselves.

Allison