[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: terminology nit



David B Harrington wrote:

You are assuming that this lack of terminology precision indicates
that non-experts are unaware of the Inform PDU by using the term "trap".

I am assuming:
 (a) they are using the term "trap" to mean "notification"
 (b) SNMP agent toolkits don't require the developer to know
      the difference between trap and inform anyway

So what operational problem are we solving here?

Andy

Hi,

If this were the only issue for which we would be tormenting them,
then I agree it is a minor correction that could be overlooked. But
the document authors are likely to be tormented for months to come,
getting all the boilerplates and nits resolved before publication, so
the amount of torment to have them correct this terminology is minimal
in comparison.
Whether this matters or not is open to debate. In most cases, trap and
notification might be able to be used interchangeably. I think the
place where this can be done most safely is between SNMP experts,
because we recognize that there is a real difference between saying
trap or notification - in some circumstances, but not in other
circumstances. So while Andy expects Mib Doctors to disagree with him
because we are SNMP experts, I actually choose to disagree because
potential implementors are NOT SNMP experts, and might overlook very
important differences between the term "trap" and the term
"notification" when it comes to implementing. I don't want to torment
document authors, but I also don't want to get sloppy just because
that's easier, either.

Having, like Dan, worked as a MIB Doctor for IEEE, where SNMP
knowledge is less than commonly found in other IETF WGs or in
companies with MIB Police review teams, I agree that we should make
sure the document is clear and unambiguous to potential implementors,
to reduce the need to interpret unclear text, and to improve the
chances for interoperability between vendors. Those should always be
considered important goals for developers of standards specifications.

I don't mind pointing this out to the l3vpn WG, but I'm not currently
subscribed to their mailing list. Is there a Mib Doctor already
subscribed to l3vpn that is willing to request this minor change in
the document?

David Harrington
dbharrington@comcast.net

-----Original Message-----
From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org] On Behalf Of Romascanu, Dan
(Dan)
Sent: Thursday, December 08, 2005 3:48 AM
To: C. M. Heard; MIB Doctors
Subject: RE: terminology nit






-----Original Message-----
From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org] On Behalf Of C. M. Heard
Sent: Thursday, December 08, 2005 10:05 AM
To: MIB Doctors
Subject: Re: terminology nit

On Wed, 7 Dec 2005, Andy Bierman wrote:
I noticed in this MIB in IETF Last Call that the term
"trap" is used
instead of "notification" in several MIB objects. Is this
important
enough or can we officially accommodate this very common
mistake?
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-vr-mib-04.txt
I don't want to tell them "trap is wrong -- use
notification because
that means trap or inform".  They don't care about that.
I would rather let it slide and accept that "trap" is a
generic term
in the wider SNMP community.

I expect MIB Doctors to disagree, because you're all SNMP
experts.
(Then one of you can point it out to the L3VPN WG.  :-)
I'm not going to disagree.  I'm perfectly happy to interpret
"trap"
as a shorthand for "trap or inform". I think it's a good idea to stop tormenting document authors for stuff that does not matter.

//cmh


Having been involved in a number of discussions in which I had to
explain that it says 'trap', but what they really mean is 'trap or
inform' I would argue that I see no reason why we should not ask in our
reviews for the correct terminology to be used. This is not about
tormenting document authors, but about making the language of the
standards clear for people who implement them. The later are the
customers, their interest should come first.
Regards,

Dan