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

[Ben Campbell <[e-mail]>]

Hi,

This version addresses all of the concerns from my gen-art review.

Thanks,

Ben.

On Aug 21, 2014, at 5:26 PM, Haleplidis Evangelos <[e-mail]> wrote:

> 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:[e-mail]]
>> Sent: Thursday, August 21, 2014 1:22 AM
>> To: Haleplidis Evangelos
>> Cc: [e-mail]; gen-
>> [e-mail]; [e-mail]
>> Subject: Re: Gen-ART LC Review of draft-ietf-forces-model-extension-03
>> 
>> 
>> 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.=
>