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

From: Benoit Claise <[email-masked]>
Date: Fri, 19 Jul 2013 10:37:21 +0200

> 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:[email-masked]]
>>> Sent: 11 July 2013 16:39
>>> To: [email-masked]
>>> Cc: 'Benoit Claise'; 'Brian Haberman'; 'Luigi Iannone'; 'The IESG'; 
>>> lisp-
>>> [email-masked]; [email-masked]
>>> 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:[email-masked]]
>>>>> Sent: 10 July 2013 20:59
>>>>> To: Brian Haberman
>>>>> Cc: Adrian Farrel; Luigi Iannone; The IESG; 
>>>>> [email-masked];
>>>> draft-ietf-
>>>>> [email-masked]
>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>>
>
>

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 19 Jul 2013 10:34:47 -0400

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
[email-masked]
+1-603-828-1401

> From: [email-masked] [mailto:mib-doctors-
> [email-masked]] 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';
> [email-masked]
> Subject: Re: [MIB-DOCTORS] Adrian Farrel's Discuss on
draft-ietf-lisp-mib-11:
> (with DISCUSS and COMMENT)
> 
> 
> For the record, I disagree but I will not fight that battle any longer (as
I
> expressed to Adrian)
> >> more widely we would never use experimental codepoints because
> moving
> >> the work to Standards Track would require a change of codepoint
> >> value.
> >>
> >> 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.
> >>
> >> this being in mib2, and I stand by my previous email.
> >>
> >>> 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.
> >>>
> >>>> will make predictions about many things.
> >>>>
> >>>> In 4181 I see
> >>>>
> >>>>      objects that are intended for limited experimental deployment.
> >>>> Such
> >>>> IMHO Standards Track equates to "targeted for deployment" while
> >>>> Experimental is
> >> for
> >>>> should be positioned under experimental.
> >>>>
> >>>> Thanks,
> >>>> Adrian
> >>>>
> >>>>
> >>>>> (with
> >>>>>>> to all email addresses included in the To and CC lines. (Feel
> >>>>>>> free to cut this introductory paragraph, however.)
> >>>>>>>
> >>>>>>>
> >>>>>>> Please refer to
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> 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.
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 21 Jul 2013 09:51:03 +0000

Hi,

I am surprised by the argumentation. 

> >> this being in mib2, and I stand by my previous email.

I believe that substantial and argumented cases against locating the MIB under experimental were made in the initial MIB Doctor advice, and than substantial and later in the discussion by Joel and DBH.

> > can do the necessary work to move the MIB to "mib-2".

Is this clear to all IESG members participating in the discussion that there is no such thing like 'moving the MIB to "mib-2"? You cannot just change the OIDs, you also need to change all the associated descriptors (names of all objects) in the MIB module. In other words deprecate the MIB module under experimental and create a new MIB module under mib-2 which may look very similar but has different OIDs and descriptors (names). Plus the tools and applications already using the older MIB modules will need to be migrated to the new OIDs and object names and probably support both for a period of transition. 

Maybe this is the argumentation that was missing (although it was already said in other words)?

Regards,

Dan

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Benoit Claise
> Sent: Friday, July 19, 2013 11:37 AM
> To: Brian Haberman
> Cc: 'Luigi Iannone'; MIB Doctors (E-mail); 'The IESG'; lisp-
> Subject: Re: [MIB-DOCTORS] Adrian Farrel's Discuss on draft-ietf-lisp-
> mib-11: (with DISCUSS and COMMENT)
> 
> 
> >> more widely we would never use experimental codepoints because moving

---

From: Benoit Claise <[email-masked]>
Date: Sun, 21 Jul 2013 23:16:38 +0200

> Is this clear to all IESG members participating in the discussion that there is no such thing like 'moving the MIB to "mib-2"? You cannot just change the OIDs, you also need to change all the assoc…
"and support both for a period of transition" is a real drawback in my 
opinion.

Regards, Benoit