Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT)

[Tom Taylor <[e-mail]>]

OK, if others accept this, I guess I have one more editing pass. And I 
should close out all the issues I set up inb the issue tracker.

Tom

On 24/06/2015 6:18 PM, ietfdbh wrote:
> I recommend leaving the object definitions unchanged, except for the status clause. I think some of the SMILINT rules were not set when RFC4008 was published. The consensus of the MIB Doctors wasn't "set" until RFC4181, and SMILINT both helped drive the consensus, pre-4181, and automates the consensus, post-4181.
>
> RFC2578 recommends explaining in each description clause why the object is deprecated.
> I personally feel that having one statement in the module-identity explaining the deprecation could suffice, this discussion is running parallel to the discussion of why we need to change the status in each object and re-publish. Given that the per-object deprecation is important so an NMS can import that information, it would be helpful to operators to look at the imported deprecated object and see the description of why it was deprecated (Some NMS's bring up the object definition/description as a sort of man-page for each object, so an operator doesn't need to hunt down the info in RFCs while fighting network fires. So I think it would be justified to put an explanation into each object description.
>
> I would be satisfied with a textual reference to the NAT-V2-MIB and a REFERENCE clause to the new RFC, in each deprecated object. This would make for a normative reference, I think.
>
> David Harrington
> [e-mail]
> [phone]
>> -----Original Message-----
>> From: Tom Taylor [mailto:[e-mail]]
>> Sent: Wednesday, June 24, 2015 11:17 AM
>> To: Spencer Dawkins at IETF; Benoit Claise
>> Cc: [e-mail]; [e-mail]; The IESG; Jouni Korhonen; ietfdbh;
>> Tina Tsou
>> Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-
>> deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT)
>>
>> Below with [PTT]
>>
>> On 24/06/2015 6:26 AM, Spencer Dawkins at IETF wrote:
>>> On Jun 24, 2015 04:51, "Benoit Claise" <[e-mail]> wrote:
>>>>
>>>> Hi Tom,
>>>>
>>>>> Yes, I believe so. If the RFC Ed. doesn't pick up the copyright thing,
>>> it can be fixed in AUTH48.
>>>>>
>>>>> Reviewing the IESG evaluation, I note the suggestion to leave out the
>>> MIB module definition itself and just have text saying (as Joel suggested)
>>> that all objects are deprecated. Would people agree to that? That would
>>> eliminate my fiddling with syntax to eliminate SMILINT warnings.
>>>
>>> So, two questions -
>>>
>>> - is the issue that changing the definition while deprecating the objects
>>> is strange?
>>
>> [PTT] Yes, per guidelines quoted by Benoit.
>>>
>>> - if the document just said "all objects are deprecated", would the
>>> resulting MIB modules still produce SMILINT warnings?
>>
>> [PTT] Yes. I just verified that RFC 4008 generates the following warnings
>> mibs/NAT-MIB:932: [5] {index-exceeds-too-large} warning: index of row
>> `natAddrBindEntry' can exceed OID size limit by 141 subidentifier(s)
>> mibs/NAT-MIB:1162: [5] {index-exceeds-too-large} warning: index of row
>> `natAddrPortBindEntry' can exceed OID size limit by 143 subidentifier(s)
>>>
>>> Obviously, I'm wondering if the right answer is to leave the syntax
>>> unchanged, and point out that the syntax generates SMILINT warnings
>> whether
>>> the objects are deprecated or not, but since all this document is doing is
>>> deprecating objects, the syntax is left unchanged, and anyone who
>>> implements the V1 MIB now will have bigger problems than the SMILINT
>>> warnings, but I don't know that's the right answer.
>>>
>> ...
>
>