Hi, thanks for the response. Comments inline. I've removed sections that don't seem to need further comment. On Aug 15, 2014, at 5:43 PM, Haleplidis Evangelos <ehalep@xxxxxxxxxxxxxx> wrote: > Greetings Ben, > > I was slow to respond as I am currently on vacations. > > Thank you very much for your extended review on the document. Please see > inline. > > I have prepared all the necessary changes and the only thing that remains is > the boilerplate issue (and perhaps the security issues). When we resolve > this I can publish the new version. > > Regards, > Evangelos Haleplidis. > >> Summary: Nearly ready for publication as a proposed standard, but there >> are some issues that should be considered first, and some editorial >> issues that might also be worth consideration. >> >> Note 1: I am not an expert in xml schema specifications. I hope assume >> others have reviewed the schema, and mechanically verified them. > > [ΕΗ] I don't know if anyone else has verified the schema, but I have > verified it with verification tools and created sample xml libraries. Works for me! [...] >> >> -- IDNits points out that this draft may need the pre-RFC5378 >> boilerplate, due to content from RFC 5812. It does appear to include >> substantial amounts of XML schema from 5812. While the publication date >> of 5812 post-dates RFC5378, there were many revisions of the draft form >> that pre-date 5378 by some time. So unless the author has gotten >> permission from all 5812 authors (and I note that author list changed >> several times prior to publication), this draft and any resulting RFC >> may well need the boilerplate. >> > > [ΕΗ] Thank you for catching this as I have very little experience with this > kind of issues. > As I have not asked permission from the RFC5812 authors, what should be the > proper way to resolve this issue? > Ask for permission or use a previous boilerplate? Asking permission is the best choice, because it would allow you to publish this one with the "fully complies" boilerplate. That has the advantage of allowing any future IETF works incorporate content from it without having the same issue. But that may be a tricky thing to do. I note that the drafts leading up to the publication of RFC5812 rotate through a number of authors at different times. It may be a bit tricky to figure out the proper list of authors to ask permission from. Therefore I would not object if you went with the pre-5378 boilerplate. Details are in section 6.d.iii. of http://trustee.ietf.org/license-info/IETF-TLP-4.htm . If you are using xml2rfc, the tool can insert the boilerplate for you. For details, see http://xml2rfc.ietf.org and scroll down to the light-green box that talks about the IETF Trust Legal Provisions boilerplate. > >> Minor issues: >> >> -- section 2.3, 3rd paragraph: >> >> The 2119 language in this paragraph seems more like description of >> procedures. You really only need 2119 language when you want to >> constrain some choice an implementor might make. Also, in the two cases >> of "MUST be ignored", please consider using active voice? (That is, who >> or what must ignore it?) >> > > [ΕΗ] In this specific case (I will reword it) the MUST is a constraint that > the implementer has to conform for interoperability. Otherwise the model > would mean something different from one implementer to the other, e.g. for > A's implementation the struct's component may have an access type of > "read-write" but for B it may mean "read-only". The MUST there defines that > when you define a struct component's access type, it MUST override the whole > struct's access type. 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. > >> -- section 2.4, 2nd paragraph: >> >> This also seems like a description of general procedures that doesn't >> really need 2119 language. > > [ΕΗ] Again I think that the MUST is something that is needed for > interoperability issues. The BecomesEqualTo MUST generate only one event > when the component reaches that specific value and not while it is there. > >> >> -- section 2.4, bulleted paragraph: >> >> Is this similar to saying that eventBecomesEqualTo effectively becomes >> an eventChanged after achieving the target value? Once the value >> changes from the target by V or more, does it reset the becomesEqualTo >> trigger? >> > > [ΕΗ] No, it does not effectively become an eventChanged. The difference is > that it will only be triggered ONCE when the value is changed and not > continuously. You might consider something like: " The event is triggered only when the value of the targeted component becomes equal to the event condition value. Implementations MUST NOT generate subsequent events while the targeted componentʼs value remains equal to the event conditionʼs value." [...] > >> -- 2.6, 2nd paragraph: "... derivedFrom will always select the latest >> version." >> >> What if a newer version of the parent is created after the child is >> defined? Can it cause backwards compatibility issues if the parent >> class changes out from under the child? >> > > [ΕΗ] Thank you for catching this. You're right, this may create backwards > compatibility issues. > This was an error on my part while writing the update of the draft. My > initial response was to use the first version (see > http://www.ietf.org/mail-archive/web/forces/current/msg04838.html) so it > would have been "select the first version". > > I have made the necessary correction and made the text better. It now reads > as follows: > "However if the version is omitted then the derivedFrom will always specify > the first version of the parent LFB class, which usually is version 1.0." > > Using always the first will mean something that is always there, and > resolves any ambiguities. Okay. > >> -- section 6: >> >> The assertion that the changes in this draft have no effect on security >> is a bit of a red flag. This draft introduces new kinds of properties >> and events that can be expressed, as well as a change to the >> inheritance model. Are you sure none of those have a security impact? >> It would at least be good to mention, for each of these changes, why >> you think it does not affect the prior model security considerations. >> > > [ΕΗ] I am no security expert, but I agree with the security considerations > of RFC 5812 and have referred that the same applies to this document. > As we didn't make any major changes in the model, but simply added a few > more items, namely a new event, some new properties and a way to define > optional access types and complex metadata. > These are constructs and do not add anything controversial to the initial > model. Now in regards to the inheritance model, we didn't add something new, > we simply clarified an issue that existed by introducing the version of the > derived from class. > > However, as I said I'm no security expert (and I don't know if you're one), > if a security expert could comment on this, it could be helpful. > 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. [...]