ietf
[Top] [All Lists]

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

2014-08-27 16:26:14
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 
<ehalep(_at_)ece(_dot_)upatras(_dot_)gr> 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:ben(_at_)nostrum(_dot_)com]
Sent: Thursday, August 21, 2014 1:22 AM
To: Haleplidis Evangelos
Cc: 
draft-ietf-forces-model-extension(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org; 
gen-
art(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: Gen-ART LC Review of draft-ietf-forces-model-extension-03


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.=