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

[Ben Campbell <[e-mail]>]

On Aug 20, 2014, at 5:00 PM, Haleplidis Evangelos <[e-mail]> 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.