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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

I agree with that comment

Thanks,
Bert 

> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: zondag 29 december 2002 18:36
> To: Wijnen, Bert (Bert)
> Cc: C. M. Heard; Mreview (E-mail)
> Subject: RE: usage of "macro invocation" terminology in the MIB review
> gui delines document
> 
> 
> 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
> >> 
>