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@xxxxxxxxxxx] > Sent: Thursday, August 21, 2014 1:22 AM > To: Haleplidis Evangelos > Cc: draft-ietf-forces-model-extension.all@xxxxxxxxxxxxxx; gen- > art@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: Gen-ART LC Review of draft-ietf-forces-model-extension-03 > > > On Aug 20, 2014, at 5:00 PM, Haleplidis Evangelos > <ehalep@xxxxxxxxxxxxxx> 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.=