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 think we're finishing up here ...

On Wed, Jun 24, 2015 at 8:10 AM, Benoit Claise <[e-mail]> wrote:

>  Dear all,
>
>
> On Jun 24, 2015 04:51, "Benoit Claise" < <[e-mail]>
> [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.
>
> Forgot to reply to this one.
> I believe the draft makes sense as done right now.
> People might want to extract all MIB modules from RFC and load them all.
> This way, they would directly see in their MIB browser that the MIB
> objects are deprecated.
>

So, that makes sense to me.

The related question was whether the syntax popping up SMILINT warnings was
OK for someone who did that - as I understand it, the syntax in the objects
being deprecated would generate the same warnings, without the changes Tom
had proposed.

Could you clue me in?

Thanks!

Spencer

p.s. Tom, when Benoit answets this question, the only other point I'm aware
of was 2014 copyright dates in the object definitions. I would be more
comfortable sending the RFC Editor a draft version that they don't have to
fix and we don't have to check in AUTH48. Could you spin a version with the
copyright date fix, plus whatever you and Benoit converge on re: syntax?



> Regards, Benoit
>
>  So, two questions -
>
> - is the issue that changing the definition while deprecating the objects
> is strange?
>
> - if the document just said "all objects are deprecated", would the
> resulting MIB modules still produce SMILINT warnings?
>
> 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.
>
> >> Regarding the Discuss: the Security Considerations section currently
> reads:
> >>
> >>   "All objects in this MIB module have been deprecated.  As a result,
> >>    security considerations in [I-D.ietf-behave-nat-mib-v2] apply
> >>    instead.  Amongst other matters, these considerations cover the case
> >>    where both this MIB module and NAT-MIB-V2 are present.  In fact, such
> >>    a situation is unlikely because [RFC4008], as a MIB module oriented
> >>    toward configuration, was overtaken by events and saw little
> >>    implementation."
> >>
> >> Was this too condensed?
> >
> > Not what I was expecting, but I guess it does the job to clear the
> DISCUSS. Clearing now.
>
> Thank you, of course.
>
> Spencer
>
> > Regards, Benoit
> >
> >
> >>
> >>
> >> Tom
> >>
> >> On 22/06/2015 12:39 PM, Spencer Dawkins at IETF wrote:
> >>>
> >>> Hi, Tom,
> >>>
> >>> Just keeping up ...
> >>>
> >>> On Mon, Jun 22, 2015 at 2:51 AM, Benoit Claise < <[e-mail]>
> [e-mail]> wrote:
> >>>
> >>>>   Thanks Tom,
> >>>> ...
> >>>>
> >>>>
> >>>> - This point above is in line with Jouni's feedback.
> >>>> * There is also no text about operational and management implications
> >>>>     related to deprecation process of the old MIB and migrating to the
> >>>>     new (to be approved) NAT-MIB-v2).
> >>>>
> >>>>
> >>>> [PTT] Covered in the v2 document.
> >>>>
> >>>> Can you please let me know which text addresses my DISCUSS.
> >>>>
> >>>>
> https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-02
> >>>>
> >>>> Also, for the copyright and date, I was referring to the MIB
> description:
> >>>>
> >>>>          DESCRIPTION
> >>>>                  "This MIB module defines the generic managed objects
> >>>>                   for NAT.
> >>>>
> >>>>                   Copyright (C) The Internet Society (2014). This
> >>>>                   version of this MIB module is part of RFC yyyy; see
> >>>>                   the RFC itself for full legal notices."
> >>>>
> >>>>
> >>>> Regards, Benoit
> >>>>
> >>>
> >>> These are the remaining points for Benoit's Discuss on this document,
> is
> >>> that correct?
> >>>
> >>> Thanks,
> >>>
> >>> Spencer
> >>>
> >>>
> >>>>
> >>>> I started to file a DISCUSS on that very point. However, I was so
> >>>> bothered by this difference that I actually compared the MIB modules
> >>>> extracted from this draft and from RFC4008.
> >>>> I see two occurences of this change: InetAddress (SIZE (4|16) versus
> >>>> InetAddress
> >>>> Why?
> >>>>
> >>>>
> >>>>
> >>>
> >> .
> >>
> >
>
>
>