[drinks] Your COMMENT on draft-ietf-drinks-spp-framework

Alexander Mayrhofer <alexander.mayrhofer@nic.at> Wed, 12 August 2015 14:49 UTC

Return-Path: <alexander.mayrhofer@nic.at>
X-Original-To: drinks@ietfa.amsl.com
Delivered-To: drinks@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 86FAE1A8999 for <drinks@ietfa.amsl.com>; Wed, 12 Aug 2015 07:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.741
X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ocJwZYHDGEly for <drinks@ietfa.amsl.com>; Wed, 12 Aug 2015 07:49:34 -0700 (PDT)
Received: from mail.sbg.nic.at (mail.sbg.nic.at []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F201A899F for <drinks@ietf.org>; Wed, 12 Aug 2015 07:49:33 -0700 (PDT)
Received: from nics-exch2.sbg.nic.at ([]) by mail.sbg.nic.at with XWall v3.50 ; Wed, 12 Aug 2015 16:49:31 +0200
Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0248.002; Wed, 12 Aug 2015 16:49:31 +0200
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: "Ben Campbell (ben@nostrum.com)" <ben@nostrum.com>, "drinks@ietf.org" <drinks@ietf.org>
Thread-Topic: Your COMMENT on draft-ietf-drinks-spp-framework
Thread-Index: AdDVDOt6USG+rqTuTpe4fxIy3OZTDw==
Date: Wed, 12 Aug 2015 14:49:30 +0000
Message-ID: <19F54F2956911544A32543B8A9BDE075468BCD98@NICS-EXCH2.sbg.nic.at>
Accept-Language: en-US, de-DE
Content-Language: de-DE
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/drinks/5x231zzLoZ3e5-o4BU44Qhs51fg>
Subject: [drinks] Your COMMENT on draft-ietf-drinks-spp-framework
X-BeenThere: drinks@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DRINKS WG <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/drinks>, <mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/drinks/>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Aug 2015 14:49:35 -0000

Hello Ben,

you made the following COMMENTs on draft-ietf-spp-framework - my responses inline, tagged with "ALEX-->". Generally, I'd like advice whether we should supply these changes as an RFC editor note, or roll a new version of the document? COMMENT discussion follows:

Hi, I've looked over the framework doc, and think it's almost ready to be approved. A have a few minor comments and questions first. 

-- 3.2, last paragraph:

That new "MUST NOT" is not appropriate.  The actual normative requirement was in the previous paragraph, and this paragraph is an example. I suggest "... is a valid UTC time, but not acceptable for use in SPPF messages".

(I know Pete suggested that, and normally I would not think to argue with him on 2119 matters. But in this case I think the change was an error.)

ALEX--> I'm happy to revert that. 

-- section 4, and subsequent:

Is there a real need to keep using the word "transport", even in quotes? 
I suggest changing the first sentence as follows, and then change all other mentions of "transport" to "substrate". (Except when referring to actual transport layer protocols)

   This section provides requirements for substrate protocols suitable
   as "transports" for SPPF.
   This section provides requirements for substrate protocols suitable
   to carry SPPF.

ALEX--> Sounds perfect to me, I can change that.

-- 8, 2nd paragraph: "XML specifications and _examples_ ... MUST be interpreted..."

Does this imply that the examples are normative?

Also I'm not sure what you mean by "interpreted in the character case presented"

ALEX--> The intention behind this is that casing of the XML must be preserved. The examples are not normative. Therefore, I propose to simply remove "and examples" from this sentence. Furthermore the word "interpreted" is maybe the culprit here, and I suggest to change that to "Unless stated otherwise, the character casing of XML specifications in this document MUST be preserved to develop a conforming specification" - would this work?

-- 9.7:

Jari and Peter had a comment on this section, where I think the MiTM terminology is getting in the way. I _think_ you are talking about a potentially compromised known intermediary that can see/modify data. I think he is talking about a MiTM attack on the protected substrate between the client and that intermediary, or that intermediary and a server. While MiTM is a fuzzy term, enough people think of it as an attack on crypto that it might be better to use a different term here. (e.g. "Compromised or Malicious Intermediary")

ALEX--> Agreed - our intention was to describe the case of a compromised intermediary. I will change the term.

*** nits ***

-- 4.1, '... in the IPv4 headers, of "Next Header" ... '


-- 4.1, 2nd paragraph:

s/that agree with/that support/  ; (or "that comply with")

-- 4.3
s/ensuring a response to be sent/ensuring a response is sent/

ALEX--> Thanks, will change that.

Please advice whether you would like to see a revised document, or an RFC Editor note writeup, and I can produce the respective text later tonight.

Thanks for the review!