RE: Aggregate Attributes

[Andy Bierman <abierman@cisco.com>]

At 03:56 PM 9/27/2001 -0700, Jason, Jamie wrote:
>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.

None of the above?
Joel is talking about partial inheritance, and stating that we should not
support it. I.e. only complete attribute sets can be inherited by a derived 
type.
(I agree completely.)

I was making an unrelated observation that the mechanisms we use in SMIng
to convey non-divisibility can be used by a SW developer to determine
which related instances of certain attributes must be contained in the
same SetRequest, in order for a simplified agent to accept it.

Our canonical example is the InetAddressType/InetAddress pair.
There's nothing in the protocol that indicates that related instances
of these objects must be set in pairs. A developer needs to refer to
the SMIng definition to understand why the agent returns inconsistentValue
when the application sends only 1 of the 2 in a SetRequest.


>Jamie

Andy


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