RE: dumb questions/comments regarding smi-ng

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

Fred,

thanks for taking the time to read the draft and provide valuable feedback.
Replies are in-line.

Jamie

> >4.1.5 ABNF Grammar
> >
> >    Type: new
> >
> >    From: NMRG
> >
> >    Description: A complete ABNF specification of the 
> grammar has to be
> >       supplied.
> >
> >    Motivation: A complete specification of the language 
> grammar in ABNF
> >       encourages the use of compiler toolkits to construct solid
> >       parsers.
> 
> dumb question of the month; while I understand that XML seems 
> to be the 
> latest in a long string of 
> solutions-to-the-world's-problems-looking-for-problems-to-solve, I 
> personally would not be bothered by finding SMIng to be an 
> adaptation of 
> XML. Is there a specific reason that an XML DTD or Schema is 
> excluded here, 
> other than that lex and yacc look for something similar to ABNF?

My understanding reading the meeting minutes from the London WG meeting are
that "ABNF Grammar" is to be replaced with something along the lines of
rigorously defined syntax.  This would allow an XML schema to be put forth
as a proposed SMIng language.

> A question for the assembled experts:
> 
> Many SNMP MIB Entries are in fact aggregate objects which are 
> accessed 
> attribute by attribute due to the limitations of SNMP. For 
> example, while I 
> might understand someone being interested in separately accessing an 
> interface's type, speed, name, counters, and so on,
> 
>   - an ARP entry is just that - the set of information that maps an
>     L2 Address <-> an L3 Address
>   - an IP Route is just that - the information that tells me 
> what happens
>     to a packet sent to a given IP Prefix under a certain set 
> of conditions
>   - an OSPF LSA is just that - the information, perhaps 
> digitally signed,
>     that says what a router is advertising regarding a given subject
>   - and so on
> 
> I alluded earlier to the fact that a vector entry might be 
> considered an 
> aggregate object; I assert that aggregate objects have 
> significant value 
> both in reducing the size of the data elements exchanged and 
> in organizing 
> information.
> 
> For example, one can readily argue that an ASN.1 CHOICE is a 
> variety of 
> aggregate object. It contains two bits of information: the 
> type of the 
> value, and the value. When looking at an IP Prefix, the authors of 
> draft-ietf-ops-rfc2851-update-02.txt chose to include the 
> prefix length as 
> well, and ask MIB designers to always include all three in a 
> certain order 
> because they view the three values as essential elements of 
> the concept of 
> an IP prefix. OK, why not make it an aggregate object and make the 
> implementation a no-brainer?
> 
> Why are aggregate objects not on the list, either as accepted 
> or rejected 
> for a reason?

If I understand your comment correctly, it appears to me that what you are
asking for is covered by requirements 4.1.28 (Attribute Groups) and 4.1.29
(Containment).  I think that the confusion could possibly stem from
different nomenclature.

Jamie