RE: comments on draft-ietf-sming-reqs-02.txt: Arrays

["Durham, David" <david.durham@intel.com>]

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