[drinks] Kathleen Moriarty's No Objection on draft-ietf-drinks-spp-framework-09: (with COMMENT)

"Kathleen Moriarty" <Kathleen.Moriarty.ietf@gmail.com> Thu, 05 February 2015 13:58 UTC

Return-Path: <Kathleen.Moriarty.ietf@gmail.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 F39A71A88BB; Thu, 5 Feb 2015 05:58:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] 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 m36on0ZlTKnH; Thu, 5 Feb 2015 05:58:30 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 736F81A88B6; Thu, 5 Feb 2015 05:58:30 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.1.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150205135830.3400.56042.idtracker@ietfa.amsl.com>
Date: Thu, 05 Feb 2015 05:58:30 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/drinks/reDE0Cl0_1rpU1tP2xcvgX3av0Y>
X-Mailman-Approved-At: Thu, 19 Feb 2015 00:22:32 -0800
Cc: drinks@ietf.org, drinks-chairs@ietf.org, draft-ietf-drinks-spp-framework.all@tools.ietf.org
Subject: [drinks] Kathleen Moriarty's No Objection on draft-ietf-drinks-spp-framework-09: (with COMMENT)
X-BeenThere: drinks@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 05 Feb 2015 13:58:32 -0000

Kathleen Moriarty has entered the following ballot position for
draft-ietf-drinks-spp-framework-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing the SecDir review from 2 years ago.  I see that you
have added text to 9.1 to say integrity protection and confidentiality
protections are to be supported by the transport protocol.  This and the
other considerations look good.
http://www.ietf.org/mail-archive/web/secdir/current/msg03495.html

In section 8, would it be appropriate to require that the XML is well
formed and validated to prevent application and security issues?  I think
a simple statement to that effect would be helpful in this document. 
Barry says this isn't needed for apps and is assumed.  This surfaced as a
possible concern for me as a result of it being in the INCH/MILE schema
related drafts, so it may have been an apps request at the time or could
have been that the WGs were aware of a possible issue since they involve
incident responders.  In case there is an issue, I put a question out to
someone that can help, but suspect it may be a result of additional
processing requirements that we had on the schema in addition to general
conformance that could result in an issue.  I didn't see any that are out
of the ordinary in the subsequent draft, so this may not be needed. 
Hopefully I'll have a response later, but would say there is nothing to
do unless that comes in with a reason good enough.

Text in subsequent documents that tells you how to handle non-conformance
to the schema or other issues that might result in a validation problem
(if restrictions for this go beyond XML conformance) would be needed of
that were the case, not here.  This was a request for a simple statement,
that may not be needed.