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

"Haleplidis Evangelos" <ehalep@ece.upatras.gr> Fri, 05 September 2014 23:18 UTC

Return-Path: <ehalep@ece.upatras.gr>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA0C1A03E5; Fri, 5 Sep 2014 16:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.369
X-Spam-Level:
X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] 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 mY1Af8pWK3_B; Fri, 5 Sep 2014 16:18:26 -0700 (PDT)
Received: from mailgate.ece.upatras.gr (mailgate1.ece.upatras.gr [150.140.189.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D321A03E2; Fri, 5 Sep 2014 16:18:25 -0700 (PDT)
Received: from EhalepXPS (150.140.255.110) by mailgate1 (Axigen) with ESMTPA id 15649B; Sat, 6 Sep 2014 02:26:57 +0300
From: "Haleplidis Evangelos" <ehalep@ece.upatras.gr>
To: "'Tom Yu'" <tlyu@mit.edu>, <iesg@ietf.org>, <secdir@ietf.org>, <draft-ietf-forces-model-extension.all@tools.ietf.org>
References: <ldvlhq24qnn.fsf@sarnath.mit.edu>
In-Reply-To:
Date: Sat, 6 Sep 2014 02:18:10 +0300
Message-ID: <012f01cfc95f$ad1c1a90$07544fb0$@upatras.gr>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac/GY8XSQz/uPOmfTiizh2BbHqkahQC8jZCgAAJojjA=
Content-Language: el
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Fvx_t5yLBk2VQd2vkbGU6b0FhO8
X-Mailman-Approved-At: Fri, 05 Sep 2014 17:23:55 -0700
Subject: Re: [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: Fri, 05 Sep 2014 23:18:28 -0000

Greetings Tom,

Thank you for the review.

Please see inline.

With regards,
Evangelos

> -----Original Message-----
> From: Tom Yu [mailto:tlyu@mit.edu]
> Sent: Tuesday, September 02, 2014 7:01 AM
> To: iesg@ietf.org; secdir@ietf.org; draft-ietf-forces-model- 
> extension.all@tools.ietf.org
> Subject: secdir review of draft-ietf-forces-model-extension-04
> 
> 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).
> 

[ΕΗ] Actually that specific "DefaultValue" was redundant. I have verified
that and removed from the schema. Thank you for catching this. Now all
defaultValue are consistent.

> Editorial:
> 
> 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.
> 

[ΕΗ] Fixed figures 2 and 4.

> 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 fragments.
> 

[ΕΗ] Done.

> In Figure 4, the indentation seems incorrect and confusing.
> 

[ΕΗ] Fixed, thank you.

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

[ΕΗ] Ok. To avoid confusion, I removed the extension from the original
excerpt and changed the text to specify that the new excerpt includes both
extensions.

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

[ΕΗ] That's a very nice suggestion. I will add that. I will add: Extension
RFC XXXX and notify the RFC editor to change when appropriate.