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

[Spencer Dawkins at IETF <[e-mail]>]

So, I was perhaps jumping a gun?

I sent the approval note for this draft earlier today.

Should I be asking the IESG Secretary to hold this document while I make
sure we're in sync?

Spencer

On Jun 24, 2015 18:30, "Tom Taylor" <[e-mail]> wrote:
>
> 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.
>>>>
>>> ...
>>
>>
>>