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

"Haleplidis Evangelos" <> Fri, 05 September 2014 23:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6AA0C1A03E5; Fri, 5 Sep 2014 16:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.369
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mY1Af8pWK3_B; Fri, 5 Sep 2014 16:18:26 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61D321A03E2; Fri, 5 Sep 2014 16:18:25 -0700 (PDT)
Received: from EhalepXPS ( by mailgate1 (Axigen) with ESMTPA id 15649B; Sat, 6 Sep 2014 02:26:57 +0300
From: "Haleplidis Evangelos" <>
To: "'Tom Yu'" <>, <>, <>, <>
References: <>
Date: Sat, 6 Sep 2014 02:18:10 +0300
Message-ID: <012f01cfc95f$ad1c1a90$07544fb0$>
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
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-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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,

> -----Original Message-----
> From: Tom Yu []
> Sent: Tuesday, September 02, 2014 7:01 AM
> To:;; draft-ietf-forces-model- 
> 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

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