RE: usage of "macro invocation" terminology in the MIB review gui delines document

[Andy Bierman <abierman@cisco.com>]

At 02:09 PM 12/29/2002 +0100, Wijnen, Bert (Bert) wrote:
>Inline

I just have one general comment.  I don't find it useful at all
to change established terminology for (IMO) pedantic reasons.
We should be asking "What problem are we attempting to solve by
avoiding the term 'macro invocation'?"  Terms that have been in
use for over a decade should not be changed.


>Bert 

Andy



>> -----Original Message-----
>> From: C. M. Heard [mailto:heard@pobox.com]
>> Sent: zaterdag 28 december 2002 22:54
>> To: Mreview (E-mail)
>> Subject: usage of "macro invocation" terminology in the MIB review
>> guidelines document
>> 
>> 
>> Colleagues,
>> 
>> In several places the draft "Guidelines for MIB Authors and Reviewers"
>> document that I posted last month uses "macro invocation" terminology
>> that was more-or-less copied from RFC 2578, RFC 2579, and RFC 2580.
>> The phrases where this usage appears are as follows:
>> 
>> "invocation of the MODULE-IDENTITY macro"
>
>I have certainly used that term in several places, for example
>it is used at:
>   http://www.ietf.org/IESG/STATEMENTS/MIB-COPYRIGHT.txt
>
>> "MODULE-IDENTITY invocation"
>> "MODULE-COMPLIANCE macro invocation"
>> "AGENT-CAPABILITIES macro invocation"
>> 
>> Dave Perkins, in an off-line e-mail exchange, has suggested that this
>
>I would really like Dave to send such discussions to the public list
>so we can all contribute to the discussion. Of course this posting
>does that... but nevertheless.
>The reason I bring this up is that we're on this MREVIEW list with 
>a set of people whom I consider to be MIB and SMI experts. Of course
>we all have some different views... but it would be best if we can
>try to get to consensus on uniform and consistent MIB reviews and
>recommendations. How else can we expect other WGs and new aothors
>and editors to ever come up with consistent MIB designs?
>
>> terminology is unhelpful and should be avoided.
>
>So can we hear some of the arguments as to why this is "unhelpful and 
>should be avoided"  please ??
>
>
>> Some replacements that have been kicked around are:
>> 
>> "invocation of the MODULE-IDENTITY construct"
>
>I have never heard of this before and I would hate to introduce such
>a new term.
>
>> "MODULE-IDENTITY specification"
>
>seems acceptable to me
>
>> "MODULE-COMPLIANCE definition"
>> "AGENT-CAPABILITIES definition"
>> 
>> Since the latter two are called compliance statements and capabilities
>> statements respectively, another thought would be to use instead:
>> 
>> "MODULE-COMPLIANCE statement"
>> "AGENT-CAPABILITIES statement"
>> 
>these latter two sound good to me.
>
>> I think these all sound just fine and don't much care one way or another
>> what terminology is used in the document.  What I'd like to get is a
>> sense from the group what would be most helpful to the document's
>> intended audience.  Note that the document already deviates from the
>> usage in the RFCs by using the term "MIB module" in place of 
>> "information module" in accordance with popular usage, as pointed 
>> out in Section 2.
>> 
>Mmm.... was "information module" not intended as shorthand for Management
>Information Base module". If so, then I can see "MIB module" as yet a
>shorter shorthand... Oh well.
>
>> Any thoughts?
>> 
>See above
>
>> //cmh
>> 
>> P.S.  One thing that I haven't mentioned is the first sentence in
>> Section 4.2, which says:
>> 
>>    RFC 2578, Sections 3.1, 7.1.1, and 7.1.4, and RFC 2579, Section 3
>>    recommend that descriptors associated with macro invocations and
>>    labels associated with enumerated INTEGER and BITS values be no
>>    longer than 32 characters, but require that they be no longer than 64
>>    characters.
>> 
>> Since I'm more or less quoting the RFCs, I'm inclined to leave this
>> as is, irrespective of what is done for the other stuff.  But I can
>> easily be persuaded otherwise.
>> 
>
>Seems fine to me.
>
>Bert
>>