Re: [MIB-DOCTORS] Adrian Farrel's Discuss on draft-ietf-lisp-mib-11: (with DISCUSS and COMMENT)

["ietfdbh" <[e-mail]>]

Hi,

To be clear about the costs of subsequently moving the module to a different
subtree,

By my interpretation, 
If lispMib is assigned to  { experimental xxx }, you cannot subsequently
assign lispMib to { mib-2 xxx }.
Per rfc2578, section 3.6,
" the semantics associated with
     the OBJECT IDENTIFIER value is not allowed to change, and a
     descriptor assigned to a particular OBJECT IDENTIFIER value cannot
     subsequently be assigned to another."

If you change the OID for an object definition, you would also need to
change the associated descriptor.
Every descriptor under lispMib that is assigned an OID under experimental
would also need to be changed to move it under mib-2.

MIB Doctors, did I get that right?

The work of moving this may be justified in the long run, or not.
I'm not sure why rooting this under experimental is important.
I do understand that assigning it under mib-2, and then having the
experiment fail, would leave a MIB module "taking up space" in the mib-2
subtree. We have lots of MIB modules that never get implemented, so I don't
see that as a compelling argument for the work.
If you did move it later, the original assignment under experimental would
still exist, so you'd be taking up unnecessary space there, PLUS space under
mib-2; and if people don't implement the lispMib for whatever reasons, you
end up taking up double the space.
>From a standpoint of interoperability, which subtree this is assigned is
probably not that important from an NMS programming perspective.
An NMS typically doesn't care much whether a module falls under mib-2 or
experimental; it's just a slightly different OID to use.

I do understand the general principle of giving experimental technologies
experimental codepoints. The cost for other technologies to be reassigned a
codepoint might be less costly than it is for a MIB module.

This COULD affect industry adoption; it could be harder to sell the need for
an NMS to support an experimental module than a mib-2 module. Maybe that's a
good thing, if this module is really an experiment designed for
implementation only by those participating in the lisp experiment. Putting
this under experimental would hopefully be a red flag that says "think about
this before implementing this module."


David Harrington
[e-mail]
[phone]

> -----Original Message-----
> From: [e-mail] [mailto:mib-doctors-
> [e-mail]] On Behalf Of Benoit Claise
> Sent: Friday, July 19, 2013 4:37 AM
> To: Brian Haberman
> Cc: 'Luigi Iannone'; MIB Doctors (E-mail); 'The IESG';
[e-mail];
> [e-mail]
> Subject: Re: [MIB-DOCTORS] Adrian Farrel's Discuss on
draft-ietf-lisp-mib-11:
> (with DISCUSS and COMMENT)
> 
> 
> > Adrian and I chatted about this.  I agree with Adrian's point that
> > this MIB should be anchored under "experimental" rather than "mib-2".
> > If/When we get to the point of moving LISP to the Standards Track, we
> > can do the necessary work to move the MIB to "mib-2".
> For the record, I disagree but I will not fight that battle any longer (as
I
> expressed to Adrian)
> 
> Regards, Benoit
> >
> > Regards,
> > Brian
> >
> > On 7/15/13 2:21 PM, Adrian Farrel wrote:
> >> While I see where you are coming from, if we applied this philosophy
> >> more widely we would never use experimental codepoints because
> moving
> >> the work to Standards Track would require a change of codepoint
> >> value.
> >>
> >> I do not believe that changing the OID for a MIB module is a big deal.
> >> I think it improbable that the MIB would not be revised at the time
> >> that the protocol is moved to Standards Track because the protocol
> >> would probably receive a revision. Revising a MIB module usually
> >> involves a change of OID.
> >>
> >> Bottom line, I don't think anyone has made a substantial case for
> >> this being in mib2, and I stand by my previous email.
> >>
> >> I think I should discuss this with Brian to try to reach agreement.
> >>
> >> Adrian
> >>
> >>> -----Original Message-----
> >>> From: Joel M. Halpern [mailto:[e-mail]]
> >>> Sent: 11 July 2013 16:39
> >>> To: [e-mail]
> >>> Cc: 'Benoit Claise'; 'Brian Haberman'; 'Luigi Iannone'; 'The IESG';
> >>> lisp-
> >>> [e-mail]; [e-mail]
> >>> Subject: Re: Adrian Farrel's Discuss on draft-ietf-lisp-mib-11:
> >>> (with DISCUSS
> >> and
> >>> COMMENT)
> >>>
> >>> Adrian,
> >>>       I have to disagree with your reading.  The point I believe the
> >>> MIB advice is making is that history has show that when we move
> >>> something from experimetnal status to operational / staqndards track
> >>> status that we can't change the OIDs used for theetwork management.
> >>> In ligt of that, if there is a hope of making such a transition some
> >>> day then it recommends that the experiment use te mib2 branch.
> >>>
> >>>       f my reading is accurate then ti would seem that the LISP MIB
> >>> belongs in the mib2 branch.  We may or may not be able to move to
> >>> standards track, but there is certainly a hope of doing so in the
> >>> future.
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>> On 7/11/2013 5:39 AM, Adrian Farrel wrote:
> >>>> Hi,
> >>>>
> >>>> I read the MIB Doctor's response. I understand it to say that "4181
> >> indicates
> >>>> that assigning under experimental is recommended only for limited
> >>> experiments,
> >>>> with no predicted deployment in the Internet."
> >>>>
> >>>> I do not know what "no predicted deployment" means. Many people
> >>>> will make predictions about many things.
> >>>>
> >>>> In 4181 I see
> >>>>
> >>>>      the experimental subtree { iso 3 6 1 3 } is
> >>>>      used to identify objects that are under development in the
> >>>> IETF.  It
> >>>>      is REQUIRED that objects be moved from the experimental
> >>>> subtree to
> >>>>      the mgmt subtree when a MIB module enters the IETF standards
> >>>> track.
> >>>>
> >>>> and
> >>>>
> >>>>      Hence any object that is targeted for
> >>>>      deployment in an operational environment MUST NOT be
> >>>> registered under
> >>>>      the experimental subtree, irrespective of the standardization
> >>>> status
> >>>>      of that object.  The experimental subtree should be used only
for
> >>>>      objects that are intended for limited experimental deployment.
> >>>> Such
> >>>>      objects typically are defined in Experimental RFCs.
> >>>>
> >>>> Maybe "targeted for deployment" is causing a misunderstanding. But
> >>>> IMHO Standards Track equates to "targeted for deployment" while
> >>>> Experimental is
> >> for
> >>>> experimentation. Experimentation may well lead to deployment in the
> >>>> longer
> >>> term,
> >>>> but that is not where we are now.
> >>>>
> >>>> As far as I understand the definition of Experimental in the IETF
> >>>> stream of
> >> the
> >>>> RFC series, it is consistent with allocation under experimental .
> >> Furthermore,
> >>>> the LISP charter is very clear about the Experimental nature of the
> >>>> output
> >> of
> >>>> the working group.
> >>>>
> >>>> I think this discussion has clarified my view that this module
> >>>> should be positioned under experimental.
> >>>>
> >>>> Thanks,
> >>>> Adrian
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Benoit Claise [mailto:[e-mail]]
> >>>>> Sent: 10 July 2013 20:59
> >>>>> To: Brian Haberman
> >>>>> Cc: Adrian Farrel; Luigi Iannone; The IESG;
> >>>>> [e-mail];
> >>>> draft-ietf-
> >>>>> [e-mail]
> >>>>> Subject: Re: Adrian Farrel's Discuss on draft-ietf-lisp-mib-11:
> >>>>> (with
> >> DISCUSS
> >>>> and
> >>>>> COMMENT)
> >>>>>
> >>>>> On 8/07/2013 17:12, Brian Haberman wrote:
> >>>>>> Hi Adrian,
> >>>>>>
> >>>>>> On 7/7/13 5:55 PM, Adrian Farrel wrote:
> >>>>>>> Adrian Farrel has entered the following ballot position for
> >>>>>>> draft-ietf-lisp-mib-11: Discuss
> >>>>>>>
> >>>>>>> When responding, please keep the subject line intact and reply
> >>>>>>> to all email addresses included in the To and CC lines. (Feel
> >>>>>>> free to cut this introductory paragraph, however.)
> >>>>>>>
> >>>>>>>
> >>>>>>> Please refer to
> >>>>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html
> >>>>>>> for more information about IESG DISCUSS and COMMENT
> positions.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ----------------------------------------------------------------
> >>>>>>> ------
> >>>>>>>
> >>>>>>> DISCUSS:
> >>>>>>> ----------------------------------------------------------------
> >>>>>>> ------
> >>>>>>>
> >>>>>>>
> >>>>>>> Two relatively small and easy-to-fix Discuss points
> >>>>>>>
> >>>>>>> While it is not against the allocation policy to assign this
> >>>>>>> module under mib-2, I should have thought that given the
> >>>>>>> Experimental nature of this work, it would be better placed
> >>>>>>> under 1.3.6.1.3 experimental.
> >>>>>>>
> >>>>>>> Please let me know that this was considered and sicussed with
> >>>>>>> the MIB Doctor.
> >>>>>>
> >>>>>> I don't recall this being discussed.  I tend to agree that this
> >>>>>> MIB belongs under the experimental branch.
> >>>>> Talking with the MIB-doctors, this MIB module would be more
> >>>>> suitable under mib-2.
> >>>>> Note: The IESG was copied on the MIB-doctors message, but not the
> >>>>> authors. So here it is.
> >>>>>
> >>>>> Regards, Benoit
> >>>>>>
> >>>>>> The other issues I will leave to the authors and shepherd.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Brian
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >
> >
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mib-doctors