[secdir] secdir review of draft-ietf-forces-model-extension-04

Tom Yu <tlyu@mit.edu> Tue, 02 September 2014 04:01 UTC

Return-Path: <tlyu@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3F0C81A0B17; Mon, 1 Sep 2014 21:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.169
X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ZuAqze8OlJ4Y; Mon, 1 Sep 2014 21:01:20 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67F5F1A6FD5; Mon, 1 Sep 2014 21:01:19 -0700 (PDT)
X-AuditID: 12074423-f799d6d00000337c-b8-5405410eec71
Received: from mailhub-auth-1.mit.edu ( []) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 64.CE.13180.E0145045; Tue, 2 Sep 2014 00:01:18 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s8241HKp032590; Tue, 2 Sep 2014 00:01:18 -0400
Received: from localhost (sarnath.mit.edu []) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s8241Gn6021403; Tue, 2 Sep 2014 00:01:17 -0400
From: Tom Yu <tlyu@mit.edu>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-forces-model-extension.all@tools.ietf.org
Date: Tue, 02 Sep 2014 00:01:16 -0400
Message-ID: <ldvlhq24qnn.fsf@sarnath.mit.edu>
Lines: 45
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUixCmqrMvnyBpisLtX3mLRw83sFjP+TGS2 +LDwIYsDs8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlfF1GVdBr2DFzfZ+lgbGL7xdjJwc EgImEnsXLmGHsMUkLtxbz9bFyMUhJDCbSaLpbz87hLOBUeLdsrNQmdeMEt/3T2YGaWETkJY4 fnkXE4gtIpAoMefeQhYQW1jATuLm3j1sIDaLgKrE46/bWEFsXgFdiS8n1oLFeQQ4JfpP3mSE iAtKnJz5BKyXWUBL4sa/l0wTGHlnIUnNQpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdM LzezRC81pXQTIyik2F2UdzD+Oah0iFGAg1GJh1fiB0uIEGtiWXFl7iFGSQ4mJVHeW2KsIUJ8 SfkplRmJxRnxRaU5qcWHGCU4mJVEeLvMgXK8KYmVValF+TApaQ4WJXHet9ZWwUIC6Yklqdmp qQWpRTBZGQ4OJQleCQegRsGi1PTUirTMnBKENBMHJ8hwHqDhjCA1vMUFibnFmekQ+VOMuhzr Or/1Mwmx5OXnpUqJ886zAyoSACnKKM2DmwNLBa8YxYHeEub9bQ9UxQNMI3CTXgEtYQJaUlHF CLKkJBEhJdXAuINJ3Cyo/FHEhm/pRuf1L61vVmQpXpvq1fFqldGmZR84b9nkvjF5vmJxk9P9 pQlfK3YWddoymG38u6t3K1t9Tp+8w6W58izeK8OuGmUt8Dr9Oy3j+JyTLpv0lj1iuO+/3+Tv 457nhXOiGBf7P2+stq/eXzhr3rPZ07qzVzHr1Ik/c2T2uLdQWomlOCPRUIu5qDgRAD/mJIPg AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Zy5MxHhg9c68BTBoC23Axk1uLE4
Subject: [secdir] secdir review of draft-ietf-forces-model-extension-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Sep 2014 04:01:22 -0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

Summary: ready with nits

I find the Security Considerations section of this document to be
reasonable.  I agree that there is negligible security impact from the
changes described in this document.

The capitalization is inconsistent for "DefaultValue" (in
typeDeclarationGroup) vs "defaultValue" (most other places).  I think
this poses no technical problem as written, but it could lead to
surprises if human-written XML is validated against the schema (assuming
I am correct in recalling that XML is case-sensitive).


I found it difficult to identify the before/after differences in the
schema fragments, especially when the quoted fragments are large.
Perhaps someone more familiar with XML schemas would not have this
difficulty.  I noticed that in some but not all of the schema fragments,
the "<!-- Extension -->" and <"!-- /Extension -->" comment annotations
are helpfully used to mark portions of the schema that have changed.
Notably, in Figures 2 and 4, these annotations are missing.  I would
prefer that changes be shown in a "unified diff" style, but I know that
is not idiomatic in the RFC format.

It would also be a good idea to describe the "<!-- Extension -->"
annotations in the text, to orient the reader to their use in the schema

In Figure 4, the indentation seems incorrect and confusing.

In Figure 5, I found the inclusion of extension annotations in the
"original" excerpt from the schema to be confusing.  The preceding
paragraph does provide an explanation, but I wonder if it could be more
clear.  Figure 1 lacks this issue.

In case future documents make further revisions to the schema, perhaps
the extension comment annotations should include the RFC number of this
document so that a reader may distinguish which changes took place in
which documents.