[IPsec] RFC5996bis editorial change in section 1.6 Requirements Terminology (Was Editorial changes to RFC5996)

Tero Kivinen <kivinen@iki.fi> Tue, 12 November 2013 15:57 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E685721E827E for <ipsec@ietfa.amsl.com>; Tue, 12 Nov 2013 07:57:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.583
X-Spam-Level:
X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjAmZDX6F10Y for <ipsec@ietfa.amsl.com>; Tue, 12 Nov 2013 07:57:49 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id BECA521E8283 for <ipsec@ietf.org>; Tue, 12 Nov 2013 07:57:47 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id rACFviaD004794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Nov 2013 17:57:44 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACFvilX027994; Tue, 12 Nov 2013 17:57:44 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <21122.20472.654531.780862@fireball.kivinen.iki.fi>
Date: Tue, 12 Nov 2013 17:57:44 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Valery Smyslov <svanru@gmail.com>
In-Reply-To: <7C1EFED8998C4309B562F2224DD39AA2@buildpc>
References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 15 min
X-Total-Time: 43 min
Cc: ipsec@ietf.org
Subject: [IPsec] RFC5996bis editorial change in section 1.6 Requirements Terminology (Was Editorial changes to RFC5996)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2013 15:57:50 -0000

Valery Smyslov writes:
> 1. Section 1.6 Requirements Terminology is placed far from the begining
>     of the document and all the requirements words, along with terms
>     from RFC4301 etc. are used before they are formally introduced.
>     I don't think it is appropriate for standards track document.
>     I suggest to move this section before Introduction.

We had this discussion twice when we were making RFC5996 (
http://www.ietf.org/mail-archive/web/ipsec/current/msg03051.html and
http://www.ietf.org/mail-archive/web/ipsec/current/msg04526.html ).

The fist of this emails (Yaron's notes) caused ticket #51 to be
opened:

http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/51

And the resolution for that ticket #51 was closed as "wontfix" and
with comments:

> There is no other good place to do this without messing up the section
> numbering.
> 
> This is too difficult to do well, and it really isn't that important.

And I think that same thing holds still. The problem is that there are
lots of people who refer to the IKEv2 specification by section
numbers, and if we change those that will cause all those references
to be invalid, which might cause confusion.

For the second email there was much bigger reordering of the sections
suggested, and looking at the email exchange people were in favor of
it, but then nothing was changed. There is nothing on the list about
this, so it might be it was discussed in the IETF meeting. 

Anyways we decided against this last time, so I will not be doing this
change unless I get more support for this from the WG, and I agree
with #51 resoluton, that there is no other good place to do this
without messing up the section numbers.
-- 
kivinen@iki.fi