Subject: [forces] On optional ACL for structs

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 26 Sep 2013 12:26:35 -0400

Giving this some thought; i think we should make the choice
of ACL for the struct at the component level separate NOT
override the default defined value in the struct definition.
i.e We should, as we already do, allow the the children to
inherit the ACL of the parent when the childs ACL is not defined
but not when it is defined.

Example:
datatype def foobar  struct {
    uint32 foo read only;
    uint 32 bar;
}

.....
......

myfoobar component id 1, read-write {
      typeref foobar;
}

In such a case if i do:
 SET /FE/2/LFBX/InstanceY/myfoobar {1, 2}
I should fail with E_READ_ONLY

If i do:
SET /FE/2/LFBX/InstanceY/myfoobar/bar  {2}

it should succeed.

Otherwise you need to specify at myfoobar level
what the different fields ACLs should be which could
be very complex for deeply nested components.

Thoughts?

cheers,
jamal

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Fri, 27 Sep 2013 01:22:16 +0300

Greetings Jamal,

Unless I misunderstood you, I think that's what the document specifies as
well, albeit not that good as it appears. "When the optional access type for
a struct component is defined it MUST override the access type of the
struct."
I should have explained it better and provided an example as you did.
Additionally I should have explicitly defined what happens when the ACL is
not defined. 
Having it optional means that it's not mandatory to be present and as such
the component would follow the normal pattern defined by RFC5812.

The bottom line is that, when you define a component for a struct (instead
of a "struct component") if you define the access type it MUST override the
access type of the struct itself. If not it inherits.

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jamal Hadi Salim
> Sent: Thursday, September 26, 2013 7:27 PM
> To: Evangelos Haleplidis
> Cc: [email-masked]
> Subject: [forces] On optional ACL for structs
> 
> Giving this some thought; i think we should make the choice of ACL for
> the struct at the component level separate NOT override the default
> defined value in the struct definition.
> i.e We should, as we already do, allow the the children to inherit the
> ACL of the parent when the childs ACL is not defined but not when it is
> defined.
> 
> Example:
>  SET /FE/2/LFBX/InstanceY/myfoobar {1, 2} I should fail with
> E_READ_ONLY
> 
> If i do:
> Otherwise you need to specify at myfoobar level what the different
> fields ACLs should be which could be very complex for deeply nested
> components.
> 
> Thoughts?
> 
> cheers,
> jamal
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 28 Sep 2013 13:43:44 -0400

Greetings Evangelos,

Ok never mind.
Please provide illustrative examples (elsewhere as well per my
earlier email).

cheers,
jamal