[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: terminology nit
Hi Andy,
Our job as standards developers isn't to solve operational problems,
but to solve one persistent problem that operators (and implementors)
face - having to use vendor-specific and non-interoperable
implementations of technologies to solve operational problems.
Our job as standards developers is to develop specifications that are
sufficiently unambiguous that compliant implementations will
interoperate, and implementors have clear specs to implement, so
operators can use standardized technologies to solve their operational
problems, regardless of which implementations they choose to employ.
If we produce specs that are not sufficiently unambiguous, then
implementations will vary, which will hinder operators from solving
their operational problems, and the non-interoperability of the
implementations may actually introduce additional operational problems
(e.g. security holes created by the variation in implementations).
Toolkits are a wonderful supplement to standards, but toolkits are
simply implementations that can also vary and be non-interoperable if
the specs are not clear and unambiguous. And not every operator or
vendor chooses to use one of the available toolkits.
David Harrington
dbharrington@comcast.net
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]
> Sent: Thursday, December 08, 2005 11:01 AM
> To: dbharrington@comcast.net
> Cc: 'Romascanu, Dan (Dan)'; 'C. M. Heard'; 'MIB Doctors'
> Subject: 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
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
>
>