Re: [tcpm] tcp-security: Request for feedback on the outline of the document

Fernando Gont <fernando@gont.com.ar> Wed, 09 September 2009 05:35 UTC

Return-Path: <fernando@gont.com.ar>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF423A6804 for <tcpm@core3.amsl.com>; Tue, 8 Sep 2009 22:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvRWeB5EnMqZ for <tcpm@core3.amsl.com>; Tue, 8 Sep 2009 22:35:56 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 1D0343A672F for <tcpm@ietf.org>; Tue, 8 Sep 2009 22:35:55 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 8409B6B681C; Wed, 9 Sep 2009 02:36:32 -0300 (ART)
Received: from [192.168.0.167] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id n895aNsf027772; Wed, 9 Sep 2009 02:36:24 -0300
Message-ID: <4AA73ED5.6000806@gont.com.ar>
Date: Wed, 09 Sep 2009 02:36:21 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: toby.moncaster@bt.com
References: <200908262238.AAA06336@TR-Sys.de><4A9624CB.6040203@isi.edu> <4A9894C3.4020300@gont.com.ar><4A9AB5C2.4090209@isi.edu> <4A9CB254.7050802@gont.com.ar> <AEDCAF87EEC94F49BA92EBDD49854CC70CDCE9FF@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <AEDCAF87EEC94F49BA92EBDD49854CC70CDCE9FF@E03MVZ1-UKDY.domain1.systemhost.net>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Wed, 09 Sep 2009 02:36:31 -0300 (ART)
Cc: ah@tr-sys.de, tcpm@ietf.org, touch@ISI.EDU
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2009 05:35:57 -0000

Hello, Toby,

Comments in-line...

> I think there needs to be some form of hum relating to this. There seems
> to be a relatively small number of people expressing relatively strong
> opinions on this document that are clearly incompatible. One key thing,
> regardless of how we actually decide to split the work, Fernando's
> current ToC is too long... 3 pages of ToC is excessive. 

For the most part it's a three-page ToC because it's a 130+ page
document. So no matter how the sections are reorganized, I don't think
the ToC will get much shorter.....


> I think the
> sections aren't grouped at a high enough level (e.g. connection
> establishment and tear-down could be in one section on connection
> management, 

I have no problem with this. Probably the only drawback is that the
corresponding sections will have a depth of four sections (i.e. one more
level). But that shouldn't be a problem. Please let me know if you still
feel this would improve the document, and I'll apply this change.



> buffer management and re-assembly could probably be grouped
> into memory management, etc). 

If you are referring to Section 7 and Section 8, one might argue that
those are two different issues. Buffer management is memory management.
Segment reassembly algorithm (Section 8) is about e.g., what you do if
you get segments that overlap (which does not really have anything to do
with how you manage memory). Nevertheless, if you have any specific
proposal on how to merge these two sections, please let me know.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1