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

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

Hi!

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

DD> [Dave] Looking back at the notes, it would appear that people were
DD> interested in providing a "tables in tables" convention for
DD> generically representing arrays. [...]

DD> The motivation for this seems straightforward, so what
DD> specifically about this proposed requirement does not easily map
DD> backwards? An example would help.

I really don't like to have an accepted (read: mandatory) requirement
that is not clearly defined. As we stated in comment #33, there is not
even a clear statement on the access semantics on arrays. I could
think about two solutions:

1. An array could be accessed atomically by protocol operations. This
   would be a win for many applications. However, this is not possible
   with the current SNMP. :-(

2. An array could be just a `macro': from the protocol point of view
   it would result in the same semantics as a table, but with a number
   of implicit limitations that you could only know if you are aware
   of the definition. I'm sure that this would cause confusion. I cannot
   see any benefit.

I think the array proponents should clearify their visions of arrays
or otherwise we should move this to the nice-to-have section.

 -frank