Re: [drinks] Updated Framework and SOAP documents

"Ben Campbell" <ben@nostrum.com> Fri, 07 August 2015 21:04 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: drinks@ietfa.amsl.com
Delivered-To: drinks@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EC51A1BCA for <drinks@ietfa.amsl.com>; Fri, 7 Aug 2015 14:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Js_hy2zIEOsB for <drinks@ietfa.amsl.com>; Fri, 7 Aug 2015 14:04:29 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867B51A1AB2 for <drinks@ietf.org>; Fri, 7 Aug 2015 14:04:29 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t77L4Ifh071901 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 7 Aug 2015 16:04:28 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: Ben Campbell <ben@nostrum.com>
To: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
Date: Fri, 07 Aug 2015 16:04:17 -0500
Message-ID: <23D14DE8-85E0-4B90-BB18-0BE144066E0A@nostrum.com>
In-Reply-To: <19F54F2956911544A32543B8A9BDE075468998BE@NICS-EXCH2.sbg.nic.at>
References: <19F54F2956911544A32543B8A9BDE075468998BE@NICS-EXCH2.sbg.nic.at>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.2r5107)
Archived-At: <http://mailarchive.ietf.org/arch/msg/drinks/OMf0ZtQZO3yPAhlpDyNzQ6jvteM>
Cc: drinks@ietf.org
Subject: Re: [drinks] Updated Framework and SOAP documents
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: Fri, 07 Aug 2015 21:04:31 -0000

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. I will look 
at the SOAP doc separately.

Thanks!

Ben.

-- 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 a former AD that usually gives wonderful advice on 2119 language 
suggested that, but in this case I think it's an error.)

-- 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)

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

-- 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"

-- 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")


*** nits ***

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

s/of/or

-- 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/





On 22 Jul 2015, at 4:21, Alexander Mayrhofer wrote:

> All,
>
> i've just submitted updated versions of the Framework and SOAP 
> documents (it might take a bit of time before they turn up in the 
> archives). These new versions should cover all Gen-ART comments and 
> IESG review comments that we received. Specifically, I performed the 
> following changes:
>
> ---
> - Framework+SOAP: Changed "Transport" to "Substrate" - where 
> applicable, in both framework and SOAP document.
> (Addressing part of Peter's Gen-ART review, and Martin's/Spencer's 
> "near-DISCUSS" IESG eval comments)
>
> - Framework: Made the "Man in the middle" case clearer in Section 9.7
> (Adressing part of Peter's Gen-ART review, and part of Jari's IESG 
> eval comment)
>
> - Framework: Clarified that Deletes MUST be atomic
> (Adressing part of Peter's Gen-ART review, and part of Jari's IESG 
> eval comment)
>
> - Framework: Addressed NITS of Peter's Gen-ART review (BIG thanks for 
> the thorough and detailed review!!)
>
> - Framework: Alissa's DISCUSSes and COMMENTs have been addressed in 
> revision -10 already.
>
> - Framework: Moved Section 4.11 to the beginning of Section 4, and 
> added reasoning paragraph
> (Based on Spencer's IESG eval comment)
>
> - Framework: Clarified in Introduction section that a "Registry" is an 
> SPPP Registry in this document
> (addresses part of Spencer's IESG eval comment)
>
> - Framework: Added "rant = Registrant" to Figure 2
> (addresses part of Stephen Farrell's COMMENT)
>
> - Framework: Changed "Public Identity" to "Public Identifier"
> (addresses part of Stephen Farrell's COMMENT)
>
> - Framework: Changed text of (now moved and renamed) "Mandatory 
> Substrate" section,
> added comment for RFC editors to create a reference to the SOAP RFC 
> once published.
> (Fixes part of Barry's IESG eval COMMENT)
>
> - Framework: Added text about when new OrgIDType namespaces would 
> protentially be requested
> (Fixes part of Barry's IESG eval COMMENT)
>
> - Framework: Slightly modified "LUF" description
> (Fixes part of Barry's IESG eval COMMENT)
>
> - Framework: Small text change in Terminology section
> (addresses part of Barry's IESG eval COMMENT)
>
> - Framework: Removed second sentence of "Server" definition
> (addresses part of Barry's IESG eval COMMENT)
>
> - Framework: Changed definition of "Registrant" to remove misleading 
> "well-known" part
> (addresses part of Barry's IESG eval COMMENT)
>
> - Framework: Changed text about identifier comparision, based on 
> Barry's suggestion
> (addresses part of Barry's IESG eval COMMENT)
>
> - Framework: Changes based on Pete's comments, see message to DRINKS 
> mailing list
> (addresses Pete Resnick's COMMENTs during IESG evaluation)
>
> - SOAP: minorVer - definition moved to dedicated section
> (addresses Roni's Gen-ART COMMENT)
>
> - SOAP: ResultCodeType - changed incorrect references 
> sppfb:ResultCodeType to sppfs:ResultCodeType
> ---
>
> I have also attached rfcdiffs for both documents.  These changes 
> should hopefully allow for the documents to proceed to the RFC Editor. 
> I'll talk to Ben (our responsible AD) for the next steps.
>
> Alex
>
>
>
>
> [diff-draft-ietf-drinks-spp-framework-10_vs_11.htm]
>
> [diff-draft-ietf-drinks-spp-protocol-over-soap-07_08.htm]