RE: Aggregate Attributes

["Jason, Jamie" <jamie.jason@intel.com>]

Would it be helpful in the draft to either:

1.  Remove the word non-divisible from the description of attribute groups
and replace the description with something like "named, reusable set of
attributes that are meaningful together".
- or -
2.  Define what is exactly meant (#1 below) and not meant (#2 below) by
non-divisible, potentially by using an example.

Jamie

> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com] 
> Sent: Thursday, September 20, 2001 8:57 PM
> To: Joel M. Halpern
> Cc: sming@ops.ietf.org
> Subject: RE: Aggregate Attributes
> 
> 
> At 07:00 PM 9/20/2001 -0400, Joel M. Halpern wrote:
> >I don't know if this is Randy's problem, but I have noticed that
> >non-divisibility is being used by some people interchangeably with 
> >atomicity.  I think that these are two different concepts.
> >
> >1) Non-divisibility to me means that if I define an 
> attribute group A 
> >bade
> >up of attributes A1, A2, & A3 I can not declare that 
> attriubte group B 
> >contains attribute group A, but only contains A1 and A2.  If 
> I want to 
> >include A, I include A1, A2, and A3.  This is a sensible and 
> useful property.
> >2) Atomicity would mean that if I have something defined as having 
> >attribute group A, any time I wanted to reference it (get, 
> set, ...) I 
> >would have to reference the entire group and not its parts.  
> This seems to 
> >me to be a very different, much more protocol oriented 
> concept.  It also 
> >happens to be one I disagree with strongly.  If by atomicity we mean 
> >something different from this, then I would appreciate some betrer 
> >definitions of terms.
> 
> I agree SMIng can only talk about (1), because SMIng deals 
> with static, 
> compile-time
> data definitions.
> 
> Data retrieval or modification is a runtime (protocol) issue.
> I think it can be useful to use the non-divisibility 
> attributes conveyed in sming class definitions to also define 
> 'expected object groupings' for 
> set operations,
> independent of the management protocol.  But maybe that's 
> something for EOS to consider, not this WG.
> 
> 
> >Yours,
> >Joel M. Halpern
> 
> Andy
> 
> 
> >At 03:54 PM 9/20/01 -0700, Durham, David wrote:
> >>Hi Randy,
> >>I'm not sure I follow why you can't reconcile these two. 
> 4.1.27 says 
> >>non-divisible grouping, 4.1.28 says you can compose larger 
> constructs 
> >>out of them. It says nothing about dividing up their attributes. 
> >>Where's the conflict?
> >>
> >>C={a,b}
> >>D={C,e}={a,b,e}
> >>
> >>-Dave
> >>
> >> > -----Original Message-----
> >> > From: rpresuhn-lists@dorothy.bmc.com
> >> >
> >> >
> >> > Hi -
> >> >
> >> > > From: Frank Strauss <strauss@ibr.cs.tu-bs.de>
> >> > ..
> >> > > The descriptions of attribute groups and containment now say:
> >> > >
> >> > > 4.1.27:
> >> > >    Description: An attribute group is a non-divisible, 
> extensible
> >> > >       grouping of attributes that are meaningful together.
> >> > It can be
> >> > >       reused as the type of attributes in other attribute
> >> > groups (see
> >> > >       also Section 4.1.28).  This is similar to 
> `structs' in C or
> >> > >       `classes' in Java.
> >> > >
> >> > > 4.1.28:
> >> > >    Description: SMIng must provide support for the 
> creation of new
> >> > >       attribute groups from attributes of more basic types and
> >> > >       potentially other attribute groups.
> >> > ..
> >> >
> >> > These appear to be in conflict.  I can't reconcile the 
> >> > "non-divisble" in 4.1.27 with the process of composition 
> described 
> >> > in 4.1.28.
> >> >
> >> > (Also, it still bugs me that this definition of 
> "attribute group" 
> >> > bears little resemblance to the concept as defined in 
> X.720, which 
> >> > defines "attribute group" as "a group of attributes 
> which have been 
> >> > given a single identifier for ease of access.")
> >> >
> >> >  ------------------------------------------------------
> >> >  Randy Presuhn          BMC Software, Inc.  1-3141
> >> >  randy_presuhn@bmc.com  2141 North First Street
> >> >  Tel: +1 408 546-1006   San José, California 95131  USA
> >> >  ------------------------------------------------------
> >> >  My opinions and BMC's are independent variables.
> >> >  ------------------------------------------------------
> >> >
> >> >
> >
> 
>