Ben, Thanks for the time and effort.
Adrian > -----Original Message----- > From: ietf [mailto:[email protected]] On Behalf Of Ben Campbell > Sent: 27 August 2014 22:25 > To: Haleplidis Evangelos > Cc: [email protected]; [email protected]; > [email protected] > Subject: Re: Gen-ART LC Review of draft-ietf-forces-model-extension-03 > > 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 <[email protected]> > 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:[email protected]] > >> Sent: Thursday, August 21, 2014 1:22 AM > >> To: Haleplidis Evangelos > >> Cc: [email protected]; gen- > >> [email protected]; [email protected] > >> Subject: Re: Gen-ART LC Review of draft-ietf-forces-model-extension-03 > >> > >> > >> On Aug 20, 2014, at 5:00 PM, Haleplidis Evangelos > >> <[email protected]> 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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
