Greetings Ben,
Thank you for your response. Please see inline.
Regards,
Evangelos Haleplidis.
From: Ben Campbell [mailto:ben(_at_)nostrum(_dot_)com]
Hi, thanks for the response. Comments inline. I've removed sections
that don't seem to need further comment.
[ΕΗ] Same here! :)
-- 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.
[ΕΗ] 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?
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.
[ΕΗ] 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.
-- 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."
[ΕΗ] Text changed to your suggestion. Thank you.
-- 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.
[...]=
[ΕΗ] 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.