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

["Adrian Farrel" <[e-mail]>]

Ben,

Thanks for the time and effort.

Adrian

> -----Original Message-----
> From: ietf [mailto:[e-mail]] On Behalf Of Ben Campbell
> Sent: 27 August 2014 22:25
> To: Haleplidis Evangelos
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: Gen-ART LC Review of draft-ietf-forces-model-extension-03
> 
> 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.=
> >