Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

Ramon Casellas <ramon.casellas@cttc.es> Thu, 21 May 2015 08:20 UTC

Return-Path: <ramon.casellas@cttc.es>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC26B1A8711 for <ccamp@ietfa.amsl.com>; Thu, 21 May 2015 01:20:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdpMYbsYY_5w for <ccamp@ietfa.amsl.com>; Thu, 21 May 2015 01:20:45 -0700 (PDT)
Received: from villa.puc.rediris.es (villa.puc.rediris.es [IPv6:2001:720:418:ca00::7]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 941501A86F5 for <ccamp@ietf.org>; Thu, 21 May 2015 01:20:44 -0700 (PDT)
Received: from [84.88.62.208] (helo=leo) by villa.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <ramon.casellas@cttc.es>) id 1YvLiS-0003t9-D8; Thu, 21 May 2015 10:20:36 +0200
Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 920191FD05; Thu, 21 May 2015 10:20:29 +0200 (CEST)
X-Envelope-From: ramon.casellas@cttc.es
Message-ID: <555D9543.7000608@cttc.es>
Date: Thu, 21 May 2015 10:20:19 +0200
From: Ramon Casellas <ramon.casellas@cttc.es>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Matt Hartley (mhartley)" <mhartley@cisco.com>, "ccamp@ietf.org" <ccamp@ietf.org>
References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <55564F37.7010203@labn.net> <5559A180.8090504@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0@xmb-rcd-x03.cisco.com> <555CBF29.3070305@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBE@xmb-rcd-x03.cisco.com> <4A1562797D64E44993C5CBF38CF1BE481291DBE5@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481291DBE5@ESESSMB301.ericsson.se>
Content-Type: multipart/alternative; boundary="------------040002020802050601050808"
X-Spamina-Bogosity: Unsure
X-Spamina-Spam-Score: -1.0 (-)
X-Spamina-Spam-Report: Content analysis details: (-1.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 BAYES_40 BODY: Bayes spam probability is 20 to 40% [score: 0.2370] 0.0 HTML_MESSAGE BODY: HTML included in message
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/O_pQox9-hj6kP0Ck-ma1BfX7qA4>
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 May 2015 08:20:47 -0000

El 21/05/2015 a las 9:57, Daniele Ceccarelli escribió:
>
> Hi Matt, Ramon,
>
> Since I found no clear statements on the usage of RFC2119 language 
> with respect to this situations, I had a look at existing framework 
> and requirement RFCs trying to find a common WoW. My take is:
>
> -Framework is always informational
>
> -Requirements are always informational
>
> -RFC2119 language is not homogeneous. Sometimes capital letters are 
> used and sometimes not.
>
> My preference is to use capital letters only when protocol behavior is 
> defined, not when requirements for the design of the protocol are 
> defined (this is in line with e.g. RFC7062 and RFC6163).
>
> As I said this is just a preference, but if there is no reasonable 
> objection I would suggest not to use any capital letter in the fwk+req 
> document.
>
>
Hi Daniele, all

  I was also checking existing RFCs, and IMHO:
- The document can stay informational, it is mainly fwk+reqs. We seem to 
agree on this.
- While RFC2119 states "In many standards track documents several words 
are used to signify the requirements in the specification", there seems 
to  be (some?) existing practice on using RFC2119 wording in reqs/info 
documents, including capitalization.
- Usage of RFC2119 keywords seems scoped to the section on requirements 
in the draft. It could be argued that defining requirements is to some 
extent defining high level protocol behavior :)

IIRC Adrian authored a significant part of the section, any views?

That said, -05 needs to be uploaded anyway to reflect the new info-model 
(thanks Jonas!) , it is not game-changing to change to acomodate what 
you suggest. We could remove RFC2119 reference, the boilerplate text and 
re-visit the sections, mainly using lowercase.

Thanks
R.