[Fwd: comments on draft-ietf-sming-reqs-02.txt: Arrays]

[David Harrington <dbh@enterasys.com>]

Whoops, replied only to DD.



David Harrington wrote:
> 
> Hi,
> 
> I agree that this is a nice to have new feature.
> 
> It is not a feature that has been found necessary in SMI and SPPI,
> although workarounds for the lack of this feature tend to be inefficient
> and complex.
> 
> dbh
> 
> "Durham, David" wrote:
> >
> > > -----Original Message-----
> > > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de]
> > > Subject: comments on draft-ietf-sming-reqs-02.txt
> > >
> > <snip>
> > >
> > > 33: We think that 4.1.25 is a nice to have requirement and belongs
> > >     into section 4.2. There are many issues associated with arrays and
> > >     I think they really belong into the category of things that SMIng
> > >     should support if we find a way to do it that is simple and easy
> > >     to use. Currently, there is not even agreement on the precise
> > >     access semantics of multi-valued attributes not how they could
> > >     potentially be mapped to SMIv2/SPPI constructs and SNMP/COPS-PR
> > >     protocol operations.
> > >
> > >     Note also that the last paragraph in the notes does not express a
> > >     clear requirement that arrays must be supported. (Despite that, we
> > >     do not understand what the "general problem" is.) The notes
> > >     already discuss issues with potential solutions - which we think
> > >     does not belong here.
> > >
> > [Dave] Looking back at the notes, it would appear that people were
> > interested in providing a "tables in tables" convention for generically
> > representing arrays. This would allow constructs such as (excuse my short
> > hand, it's a conceptual example):
> >
> > structure RMOM_Control {
> >         rowstatus   RMOM_Control_Status; // Applies to this construct and
> > all contained entities
> >         ownerString RMOM_Control_Owner;
> >         // ... other attributes ...
> >
> >         // Array of RMOMHistory
> >         RMOMHistory History_Array[RMOMHistory.ID]; // Indexed by
> > RMOMHistory.ID
> >
> > };
> >
> > structure RMOM_History {
> >         Integer ID;
> >         // ... Other attributes ...
> > };
> >
> > Conceptually it becomes simpler to explain that setting rowstatus in the
> > RMOM_Control structure applies to all "contained" RMOM history elements.
> > Seems like this maps to tables expanding tables, only from the opposite
> > perspective.
> >
> > Table1: ipRMOMControl INDEX{ipRMOMControlOwner}...
> > Table2: ipRMOMHistory INDEX{ipRMOMControl ipRMOMControlOwner, ID}...
> >
> > The motivation for this seems straightforward, so what specifically about
> > this proposed requirement does not easily map backwards? An example would
> > help.
> >
> >