Re: [eman] [MIB-DOCTORS] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt

["Romascanu, Dan (Dan)" <[e-mail]>]

Sure, there are 7 instances of 'MIBs' in the latest version of the document - we can replace them all by 'MIB modules'. 

Are there any other issues that need to be edited before submitting a revised version? We (the authors) believe that we fixed all issues raised by the MIB Doctor review, but mistakes are always possible. 

Regards,

Dan




> -----Original Message-----
> From: Benoit Claise [mailto:[e-mail]]
> Sent: Monday, January 28, 2013 3:17 PM
> To: Romascanu, Dan (Dan); [e-mail]; draft-ietf-eman-
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [MIB-DOCTORS] mib doctor review of draft-ietf-eman-
> rfc4133bis-05.txt
> 
> Dan,
> > On Tue, Jan 15, 2013 at 01:07:43PM +0000, Romascanu, Dan (Dan) wrote:
> >
> >>>>> f) In 2.12.2, can we find a better phrase than "SNMP ARCH
> [RFC3411]
> >>>>>     method of context identification"? For example, "an
> SnmpEngineID
> >>>>>     and ContextName pair [RFC3411] for context identification".
> >>>>>
> >>>> [[DR]] This is the verbiage used in RFC 4133. Unless we need to fix
> >>>> a
> >>> bug I suggest to avoid such changes.
> >>>
> >>> It is document clarity. But I won't insist on this, I just find the
> >>> current text unnecessarily confusing.
> >>>
> >>>>> g) Overall, replace MIBs with MIB modules.
> >>>>>
> >>>> [[DR]] Same as the previous point.
> >>> Again, it is document clarity. It is rather obvious that this change
> >>> does not break anything, no? Let Bert decide - he is the owner of
> >>> the one MIB many MIB modules song. ;-)
> >>>
> >> [[DR]] I also sing the song when I review new documents, but in this
> case we would interfere in the text of the document that is now at
> version 4.
> > So what? Time to fix this. Anyway, I will not fight for this if
> > editors believe it is best to not update vocabularity to current
> I agree with Juergen on the two points above.
> 
> Every single time I speak SNMP/MIB with someone, I try to use the right
> language, and correct my interlocutor if needed, with a little of
> education.
> I don't understand why we don't jump on the opportunity to correct this
> document.
> There are two types of audience for this new document:
> 1. The people who have not read the first 3 versions. So I guess not
> that familiar with the SNMP/MIB. They would benefit from the right
> terminology 2. The persons who need a diff with the previous version. So
> I guess familiar with SNMP/MIB. And the improvements would be obvious to
> them.
> 
> Therefore, there is no harm in improving the document. And I don't buy
> in the argument that we need to keep consistency with RFC 4133 ..; for
> something that is not clear.
> 
> Regards, Benoit
> > rules.
> >
> > /js
> >