Subject: Re: Element Properties

From: "Deleganes, Ellen M" <[email-masked]>
Date: Thu, 5 May 2005 10:44:17 -0700

I have a few comments below:

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Wednesday, May 04, 2005 3:04 PM
To: [email-masked]
Subject: Re: Element Properties

Hi Joel,

On Wed, 2005-04-05 at 13:58 -0400, Joel M. Halpern wrote:
> I sent the message below to the list more than a month ago.
> There are a series of specific questions that I would really like
feedback on.

Apologies, I meant to respond (after reading it of course ;->).

Comments below:

> --------------------------------------------------------
> 
> As suggested on the list before the meeting, and discussed at the
meeting, 
> I think it may make sense to provide explicit mechanisms in the model
and 
> protocol for referencing the properties of any element of any LFB.
> 
> The basic approach would be to include in the core library a data 
> definition for the scalar for access (none, read-only, write-only, and

> read-write is what I would start with.)
> Then, we would define a structure to be returned for a properties
reference 
> to any element in the model.  A property reference would be indicated
by 
> setting a bit in the path flags that reference the element.
> 

Sounds sensible.

> At the moment, I can see two structure definitions.  One for most
elements 
> which only contains the access permissions, and one for arrays which 
> contains other array properties.  I have included the XML declarations
for 
> all of this at the end of this message.
> 

Access controls for elements and the array properties are the only
associated metadata i can think of at the moment; it doesnt seem that
you object to any other properties being added in the future, right?

> There are a number of open questions:
> 
> 1) What should we use for the properties of a structure?  We could
just 
> return the permissions, which would relate to the structure as a
whole.  We 
> could try to return a complex structure with the permissions for the
struct 
> and the permissions for every element within the structure.  I am
inclined 
> to keep this simple, but the result is that if one needs the element 
> properties one has to GET a number of pieces of information.
> 

The more fine grained the better, but its a lot of detail. 
I think that hierachies (example a struct X access control vs a
X.element1 access control with the former defining the default for the
struct  and the later overriding the default. Too complex)

<<Ellen: In general, I like the fine grained approach, but that might be
too much detail. Maybe we need to go through some examples to see how
burdensome this will become.>>

> 2) What should we use for the properties of an LFB?  (This would be 
> reference by a path with the properties flag set and 0 identifiers in
the 
> path ids.)  Should it reference just the LFB?  Should it try to return
the 
> properties for every top level element in the LFB?
> 

So example properties of an LFB would be its ID, where its derived from
etc? 
It sounds to me like what you describe is sufficient for the path at
least.
I think anything under LFBClassDefs is target-able via a path - so is it
would be simpler to access those properties just by pointing at them
appropriately, no?

> 3) What about Aliases?  All the other properties are read only.  It is
very 
> tempting to put the Alias target information into the alias properties

> structure (much as the array information is in the array properties 
> structure.)  The one aspect that gives me pause in doing that is that
we 
> would have to allow SET operations against Alias properties to make
this 
> work.  Is that a good idea?
> 

Shouldnt all properties be SETable anyways? In otherwise, shouldnt i
(CE) be able to change an attribute from read-only to read-write at
runtime? It depends on the attribute of course - some dont make sense to
do so. 

<<No - I don't think all properties are SETable. Some are where the FE
is informing the CE what its capabilities are. In this case, the
attribute would be read-only. It doesn't make sense for the CE to change
those types of attributes.>>

> 4) As a minor aspect, if we have nested path-data TLVs how should the 
> property flag be set and interpreted?  My inclination is to say that
the 
> flag only applies to paths which do not have nested path-data.
> 

Why this restriction? I would think that if i can formulate a GET to
some target with the properties bit set, theres a clear meaning as to
what i am trying to GET, no?

> 
>    <dataTypeDef>
>      <name> BasicElementProperties </name>
>      <synopsis> the structure for most element properties </name>
>      <struct>
>        <element>
>          <elementID> 1 </elementID>

Did you just go back to the old format of defining IDs?

Otherwise, the xml looks clear enough to me.

> Yours,
> Joel M. Halpern
> 
> PS: I have moved derived-from and element-ID to nested elements
instead of 
> attributes because that seems the most consistent with the advice I
could 
> get from the application folks.  I still should talk to Scott
Hollenbeck to 
> really understand this.

Duh, ok - this answers my question then. Are you going to change the
general grammar to match this?

cheers,
jamal

---

From: "Deleganes, Ellen M" <[email-masked]>
Date: Thu, 5 May 2005 15:27:11 -0700

I would prefer to only have to deal with cases #1 and #2. (I also think
these are different). Since FEs can have different capabilities, case #1
may be too limiting. For one FE, an attribute may only be readable,
where in another FE, the CE may be able to write the attribute.

I think the third case where the CE can decide to change the permissions
seems complicated. I assume that if within the CE, some processes have
limited permissions, the CE could manage this without requiring support
from the model. By the same token in the case where you have multiple
CEs controlling a single FE, they would need to coordinate and this too
would be outside of the model. I guess I don't see the value and it
would at least require some extra error notification in case the CE
tries to change a permission that is not allowed on the FE.

Regards,
Ellen
-----Original Message-----
Sent: Thursday, May 05, 2005 2:43 PM

On Wed, 2005-04-05 at 20:03 -0400, Joel M. Halpern wrote:
> I had assumed that if an FE said that an element was read-only, that
was 
> because the FE was not prepared to let the CE write to that element.
If 
> the FE is prepared to let the CE write the element, then it would be 
> read-write.
> So I could not come up with a case where the CE would write the
properties, 
> except for the alias situation.

Hopefully this will address Ellen's comment as well and lets pick access
control as an example.

Who is it that decides that an elememt is read-only?

1) Clearly one scheme is to make that call at LFB definition time.
And everybody knows. 

2) The FE makes that call. It does make sense; there are cases where
somethings (as an example something residing in ROM such as a serial
number) are read only.
However if we know #1, #2 is a noop.

3) The CE makes the call. This is the scenario i was referring to. 
Ok, granted it doesnt make sense for the CE to overwrite something
that is truly read-only at the FE, but assume the CE is smart enough to
know the difference.

Actually let me backtrack a little .. the model i had in mind for access
control was to infact to allow for for true ACLs and
different entities to access an FE's LFB. Some of them may have
read-only permission while some may have read-write ability. This will
fall under #3 where the CE sets these permissions - I realize i am
pushing the envelope a little here but do we wanna disallow that?

cheers,
jamal

---

From: "Deleganes, Ellen M" <[email-masked]>
Date: Thu, 5 May 2005 17:29:05 -0700

It took me awhile, but I think I get what you are trying to say in the
example. Since flag "a" specifies a property, but one of the inner flags
(flag "b") specifies data, there is an inconsistency. Thus, it is not
possible to satisfy the conditions of both flags. (Is this right?)

If this is the case, I agree with you that the outer flag should be
ignored (flag "a"). It seems to make more sense to report the
information as specified in the nested flags. It seems inefficient
otherwise. If you don't ignore the outer flag and you really want the
information as specified by the inner flags in a structure, you would
have to perform multiple individual GETs to get the information you
really wanted.

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, May 05, 2005 2:55 PM
To: [email-masked]
Subject: Re: Element Properties

I will be happy to capture the ambiguity in the text.
But we need to pick the behavior.  Is ignoring the outer flags
acceptable?

Does anyone other than Jamal and me understand this?

Thanks,
Joel

At 05:46 PM 5/5/2005, Jamal Hadi Salim wrote:
>Joel,
>
>Yes, I can see the ambiguity in this case.
>Can you please capture the text in your description in the draft as
well
>(maybe some appendix section)?. I am leaving the thread in its entirety
>below so people understand whats being said.
>
>
>cheers,
>jamal
>
>On Wed, 2005-04-05 at 20:11 -0400, Joel M. Halpern wrote:
> > Let me be more explicit about the case I thought was confusing:
> >
> > Path-Data:
> >     Flag(a) = properties, path = 1.2
> >        nested-path-data-1
> >             Flag(b) = 0, path = 3
> >        nested-path-data-2
> >             Flag(c) =properties, path=4
> >
> > (nested-path-1 and nested-path-2 are both nested in the main
path-data, 
> and
> > are siblings to each other.)
> >
> > Clearly, something about 1.2.3 and 1.2.4 is to be returned.
> > If we ignore flag a, then we return the data from 1.2.3, and the 
> properties
> > about 1.2.4.
> > If flag-a matters, then the only conclusion I can reach is that we
are to
> > return the properties information about 1.2.3 and 1.2.4, and the
flags b
> > and c don't matter.
> >
> > My suggestion is that flag-a should be ignored.
> >
> > Yours,
> > Joel
> >
> > At 06:04 PM 5/4/2005, Jamal Hadi Salim wrote:
> > > > property flag be set and interpreted?  My inclination is to say 
> that the

---

From: "Deleganes, Ellen M" <[email-masked]>
Date: Thu, 12 May 2005 16:36:49 -0700

Anybody else have an opinion on this topic??? (Is this list still
working?)

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Deleganes, Ellen M
Sent: Thursday, May 05, 2005 5:29 PM
To: [email-masked]
Subject: Re: Element Properties

Regards,
Ellen

-----Original Message-----

Thanks,
Joel

well
path-data, 
are to
flags b