Re: Gen-ART LC Review of draft-ietf-forces-model-extension-03
Ben Campbell <ben@nostrum.com> Wed, 27 August 2014 21:25 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5BF1A02A3; Wed, 27 Aug 2014 14:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vgJkoLNjaL5d; Wed, 27 Aug 2014 14:25:38 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003601A0141; Wed, 27 Aug 2014 14:25:37 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7RLPT45056168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Aug 2014 16:25:31 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset="iso-8859-7"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Gen-ART LC Review of draft-ietf-forces-model-extension-03
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <008201cfbd8e$eb475500$c1d5ff00$@upatras.gr>
Date: Wed, 27 Aug 2014 16:25:27 -0500
X-Mao-Original-Outgoing-Id: 430867527.396418-30c4b4f4c75aa4518c34e176adc23177
Content-Transfer-Encoding: quoted-printable
Message-Id: <E4541E7C-CB8C-4F68-98C5-5B390E47089A@nostrum.com>
References: <0E5C3A14-617C-4B8D-AB47-1D1E519473D9@nostrum.com> <008e01cfb8da$52a8f6e0$f7fae4a0$@upatras.gr> <B665C955-BE41-486A-AAAE-C488153CF041@nostrum.com> <01a501cfbcc2$2ed1ea60$8c75bf20$@upatras.gr> <CB602895-17F2-4718-8863-908CBBF8F1B6@nostrum.com> <008201cfbd8e$eb475500$c1d5ff00$@upatras.gr>
To: Haleplidis Evangelos <ehalep@ece.upatras.gr>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/A4WqIrIl1SdulRIeVcJ6Ciw0wS8
Cc: draft-ietf-forces-model-extension.all@tools.ietf.org, gen-art@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 21:25:40 -0000
Hi, This version addresses all of the concerns from my gen-art review. Thanks, Ben. On Aug 21, 2014, at 5:26 PM, Haleplidis Evangelos <ehalep@ece.upatras.gr> wrote: > Greetings Ben, > > Thank you very much for the review and the discussion. > I have made all the relevant changes and have submitted (just in time it > seems) the new version. > > Regards, > Evangelos Haleplidis. > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Thursday, August 21, 2014 1:22 AM >> To: Haleplidis Evangelos >> Cc: draft-ietf-forces-model-extension.all@tools.ietf.org; gen- >> art@ietf.org; ietf@ietf.org >> Subject: Re: Gen-ART LC Review of draft-ietf-forces-model-extension-03 >> >> >> On Aug 20, 2014, at 5:00 PM, Haleplidis Evangelos >> <ehalep@ece.upatras.gr> wrote: >> >>> >>> [ΕΗ] I discussed with Joel with regards to the copyright issues. >>> The short answer is that this document draws directly from RFC5812 >> and >>> relies on RFC5812 for such issues (as it uses the same boilerplate). >>> >>> Is this satisfactory? >>> >> >> Hrmm. So it does. I somehow had it in my head it had the older >> boilerplate. I must have gotten that from one of the draft versions So, >> never mind :-) >> >> (It's interesting that IDNits apparently looked at the date of >> publication of the first 00 draft, not the RFC. I'm curious the history >> of what happened with RFCs that were in-process works and had changes >> in authorship at the time 5378 was published--but that's not this >> draft's problem and should probably happen in a bar discussion.) >> >> [...] >> >>>> >>>> In this particular case, it's not clear to me if the MUST actually >>>> constrains a choice vs being a statement of fact. If you believe it >>>> to be the former then I am okay with it. The rewording might help. >>>> >>> >>> [ΕΗ] I reworded it and provided also an example. The text now reads: >>> >>> "When optional access type for components within a struct are >> defined, >>> these components's access type MUST override the access type of the >>> struct. For example if a struct has an access type of read-write but >>> has a component that is a read-only counter, the counter's access >> type MUST be read-only." >>> >>> I believe that it is an implementation constraint as there are two >>> possibilities (override or not). With the "MUST" we constrain it to >>> one (override). >>> >>> I also changed the two "it MUST be ignored" to "the access type MUST >>> be ignored" to better specify what "it" is. >>> >> >> This helps. >> >> For the record, my suggestion on more active voice was to say what must >> do the ignoring. But I think what you've got is good enough. >> >> [...] >> >> >>>> >>>> No, I am not one. Hopefully this will get a SecDir review as well. >>>> But that sort of review usually goes better if the Security >>>> Consideration section shows your reasoning, along the lines of >>>> listing the high-level types of changes, and for each, why it has no >>>> new security impact. Your response contains more of that sort of >>>> thing; it might help to add it (or parts of it) to the draft. >>>> >>>> I was a bit concerned that the default version for inheritance could >>>> be an issue, but you addressed that elsewhere. >>>> >>>> [...]= >>> >>> [ΕΗ] Ok, added part of this. Now the security considerations read the >>> following: >>> >>> This document adds only a few constructs to the initial model defined >>> in RFC5812, namely namely a new event, some new properties and a way >>> to define optional access types and complex metadata. These >> constructs >>> do not change the nature of the the initial model. In addition this >>> document addresses and clarifies an issue with the inheritance model >>> by introducing the version of the derivedFrom LFB class. >>> Thus the security considerations defined in RFC5812 applies to this >>> document as well as the changes proposed here are simply constructs >> to >>> write XML library definitions, as where in RFC5812 and have no effect >>> on security semantics with the protocol. >>> >> >> You might consider adding something to say that the inheritance model >> change also does not change the security considerations. (Maybe it >> makes things better, by removing the potential for choosing a wrong >> parent class? Not sure if that's a security issue, unless there was >> some kind of parent-assertion attack.) >> >> It does seem like the inheritance change is a bona-fide extension, not >> just a clarification, since you added the version attribute.= >
- Gen-ART LC Review of draft-ietf-forces-model-exte… Ben Campbell
- RE: Gen-ART LC Review of draft-ietf-forces-model-… Haleplidis Evangelos
- Re: Gen-ART LC Review of draft-ietf-forces-model-… Ben Campbell
- Re: Gen-ART LC Review of draft-ietf-forces-model-… Ben Campbell
- RE: Gen-ART LC Review of draft-ietf-forces-model-… Haleplidis Evangelos
- RE: Gen-ART LC Review of draft-ietf-forces-model-… Haleplidis Evangelos
- Re: Gen-ART LC Review of draft-ietf-forces-model-… Ben Campbell