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

[Benoit Claise <[e-mail]>]

> 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
>>>>>>
>>>>>>
>>>>
>>>>
>
>