ietf
[Top] [All Lists]

Re: Gen-ART LC Review of draft-ietf-forces-model-extension-03

2014-08-20 17:22:33

On Aug 20, 2014, at 5:00 PM, Haleplidis Evangelos 
<ehalep(_at_)ece(_dot_)upatras(_dot_)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.