Subject: [MIB-DOCTORS] Read-only MIB modules

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 4 Feb 2014 13:32:06 -0000

Hi,
 
The MPLS working group is testing the water to see whether one of its MIB
modules should be "reduced" to read-only. This is the document that triggered my
recent questions that led on to the draft advice you are working on. The WG took
the document back to make this decision.
 
You'll note below that we immediately have an implementation claim (not for this
doc, but for the modules it extends).
 
An interesting situation, I think.
 
A
 
From: mpls [mailto:[email-masked]] On Behalf Of GyeRok Gwun (???)
Sent: 04 February 2014 09:57
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: Re: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-
only
 
No/oppose to make as Read-only mib.
In our products we extensively use R/W object of TE mib. We also have NMS/EMS
that use TE read-write Objects
 
Best Regards
Gwun
 
-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Monday, February 03, 2014 10:55 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read- only
 
Working Group,
 
We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the working
group for more work. We have a series of comments that are mostly for
clarification. However the main reason for recalling the document is that there
is one point where we need to confirm working group consensus.
 
The IETF, the working group and the MIB Doctors are today very reluctant to
produce read-write MIB modules. The current draft is read-write for a few
objects, this is based on a consensus call for an earlier discussion, however
the consensus call was not clear. It can be taken to mean both that we want to
go with read-write objects and that we want to see read-only. Is it clear that
it has been interpreted differently by different individuals.
 
The authors and chairs have discussed the issue and we have a rough consensus
that we want the MIB module(s) to be read-only.
 
We therefore are asking the working group if this is OK for the MIB
module(s) in the current document. Please indicate Support or Oppose for this
MIB (draft-ietf-mpls-tp-te-mib) to be read-only.
 
Please send your comments to the working group mailing list before February 18,
2014.
 
Loa
for the MPLS wg chairs
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 4 Feb 2014 06:10:14 -0800

I will point out that there are and have been *many* implementations of r-w objects in the past; that is not at issue IMHO. What is at issue is to ask ourselves whether or not anyone in practice actually uses them. The evidence is pretty overwhelmingly in favor of netconf/json/or even the good old CLI.  For the IETF the question is then one of allocation of resources to work on something that is hardly if ever used in practice versus say pushing those few resources towards produce a yang mode that definitely is.

Tom 

> On Feb 4, 2014, at 5:32 AM, "Adrian Farrel" <[email-masked]> wrote:
> 
> Hi,
>  
> The MPLS working group is testing the water to see whether one of its MIB modules should be "reduced" to read-only. This is the document that triggered my recent questions that led on to the draft advice you are working on. The WG took the document back to make this decision.
>  
> You'll note below that we immediately have an implementation claim (not for this doc, but for the modules it extends).
>  
> Subject: Re: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read- only
>  
> In our products we extensively use R/W object of TE mib. We also have NMS/EMS that use TE read-write Objects
>  
> Best Regards
> Gwun
>  
> We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the working group for more work. We have a series of comments that are mostly for clarification. However the main reason for recalling the document is that there is one point where we need to confirm working group consensus.
>  
> The IETF, the working group and the MIB Doctors are today very reluctant to produce read-write MIB modules. The current draft is read-write for a few objects, this is based on a consensus call for an earlier discussion, however the consensus call was not clear. It can be taken to mean both that we want to go with read-write objects and that we want to see read-only. Is it clear that it has been interpreted differently by different individuals.
>  
> The authors and chairs have discussed the issue and we have a rough consensus that we want the MIB module(s) to be read-only.
>  
> module(s) in the current document. Please indicate Support or Oppose for this MIB (draft-ietf-mpls-tp-te-mib) to be read-only.
>  
> Please send your comments to the working group mailing list before February 18, 2014.
>  
> Loa
> for the MPLS wg chairs
> --
>  
>  
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 4 Feb 2014 10:39:19 -0500

Adrian,

My understanding of RowStatus is that rows created by TE MIB which have
tables extended in draft-ietf-mpls-tp-te-mib will still be "allowed" to be
created using the RowStatus of the TE MIB.   (In other words, the RowStatus
object controls the row and extensions to this row, even if those extensions
are in a different MIB Module.)  Consider ,for example, changing RowStatus
to delete a row.   That will impact the entire row, even if parts of the
row's objects are in various MIB Modules.

I don't understand how the draft could truly be made read-only, unless
RowStatus is going to be redefined.  

Please note also, that this draft extends rows  for tables in  LSR MIB as
well as the TE MIB.    

Thanks,

  -Joan

From: MIB-DOCTORS [mailto:[email-masked]] On Behalf Of Adrian
Farrel
Sent: Tuesday, February 04, 2014 8:32 AM
To: [email-masked]
Subject: [MIB-DOCTORS] Read-only MIB modules

Hi,

The MPLS working group is testing the water to see whether one of its MIB
modules should be "reduced" to read-only. This is the document that
triggered my recent questions that led on to the draft advice you are
working on. The WG took the document back to make this decision.

You'll note below that we immediately have an implementation claim (not for
this doc, but for the modules it extends).

A

From: mpls [mailto:[email-masked]] On Behalf Of GyeRok Gwun (???)
Sent: 04 February 2014 09:57
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: Re: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib
read- only

In our products we extensively use R/W object of TE mib. We also have
NMS/EMS that use TE read-write Objects

Best Regards

Gwun

-----Original Message-----

To: [email-masked]

Subject: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-
only

Working Group,

We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the working
group for more work. We have a series of comments that are mostly for
clarification. However the main reason for recalling the document is that
there is one point where we need to confirm working group consensus.

The IETF, the working group and the MIB Doctors are today very reluctant to
produce read-write MIB modules. The current draft is read-write for a few
objects, this is based on a consensus call for an earlier discussion,
however the consensus call was not clear. It can be taken to mean both that
we want to go with read-write objects and that we want to see read-only. Is
it clear that it has been interpreted differently by different individuals.

The authors and chairs have discussed the issue and we have a rough
consensus that we want the MIB module(s) to be read-only.

module(s) in the current document. Please indicate Support or Oppose for
this MIB (draft-ietf-mpls-tp-te-mib) to be read-only.

Please send your comments to the working group mailing list before February
18, 2014.

Loa

for the MPLS wg chairs

-- 

mpls mailing list

[email-masked]

mpls mailing list

[email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 4 Feb 2014 21:07:20 -0000

Hello,
 
I thought that a compliance statement for this MIB module would require only
read access for the extended tables, and that all objects in this module would
be read-only.
 
A
 
From: Joan Cucchiara [mailto:[email-masked]] 
Sent: 04 February 2014 15:39
To: [email-masked]; [email-masked]
Subject: RE: [MIB-DOCTORS] Read-only MIB modules
 
Adrian,
 
My understanding of RowStatus is that rows created by TE MIB which have tables
extended in draft-ietf-mpls-tp-te-mib will still be "allowed" to be created
using the RowStatus of the TE MIB.   (In other words, the RowStatus object
controls the row and extensions to this row, even if those extensions are in a
different MIB Module.)  Consider ,for example, changing RowStatus to delete a
row.   That will impact the entire row, even if parts of the row's objects are
in various MIB Modules.
 
I don't understand how the draft could truly be made read-only, unless RowStatus
is going to be redefined.  
 
Please note also, that this draft extends rows  for tables in  LSR MIB as well
as the TE MIB.    
 
Thanks,
  -Joan

 
Hi,

 
 
A

 
Best Regards
Gwun
 
-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Monday, February 03, 2014 10:55 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read- only
 
Working Group,

 

 
Loa
for the MPLS wg chairs
--

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 Feb 2014 23:42:22 +0100

On Tue, Feb 04, 2014 at 09:07:20PM +0000, Adrian Farrel wrote:
> Hello,
>  
> I thought that a compliance statement for this MIB module would
> require only read access for the extended tables, and that all
> objects in this module would be read-only.

Sounds backwards from the SMIv2's notion of MAX-ACCESS. If you set
MAX-ACCESS to read-only, then this thing can never be implemented
read-write or read-create. This is why at some time in the past we
started modeling MAX-ACCESS read-write with read-only conformance
statements if a WG decides to do so and everyone could implement
read-only and still claim compliance.

We learned that it is a good thing to separate configuration from
operational state and it used to be a WG decision whether the WG wants
to tackle configuration via SNMP or not. I believe WGs need to take
informed decisions and we should help them with that but be careful
with 'strongly discouraging' writable SNMP MIB modules for
configuration purposes (unless there is some evidence that WGs are
unable to take informed decisions).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 05 Feb 2014 06:28:34 -0800

Adrian,

The following text is basically a statement of direction for the IETF. 
Clearly, there will be a transition period.

    "The OPS Area henceforth strongly discourages the pursuit of
    writable SNMP MIB modules for complete features/services
    configuration purposes by IETF working groups, except in cases of
    clear utility and consensus to do so. Using SNMPSet to simple
    configuration, such as enable/disable notifications or initiating an
    action,  might be appropriate though.  In all other cases, we
    recommend the use of NETCONF/YANG IETF standards for configuration,
    specifically in new charters."

This is the reason why I stressed "specifically in new charters"
Note: we have a similar situation in an EMAN MIB module where some 
objects are read-write (RowStatus TC)

Regards, Benoit

> Hi,
>
> The MPLS working group is testing the water to see whether one of its 
> MIB modules should be "reduced" to read-only. This is the document 
> that triggered my recent questions that led on to the draft advice you 
> are working on. The WG took the document back to make this decision.
>
> You'll note below that we immediately have an implementation claim 
> (not for this doc, but for the modules it extends).
>
> *From:*mpls [mailto:[email-masked]] *On Behalf Of *GyeRok Gwun 
> (???)
> *Sent:* 04 February 2014 09:57
> *To:* [email-masked]'
> *Cc:* [email-masked]'; 
> [email-masked]'
> *Subject:* Re: [mpls] seeking consensus on making 
> draft-ietf-mpls-tp-te-mib read- only
>
> To: [email-masked] <mailto:[email-masked]>
>
> Cc: [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>
>
> We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the 
> working group for more work. We have a series of comments that are 
> mostly for clarification. However the main reason for recalling the 
> document is that there is one point where we need to confirm working 
> group consensus.
>
> The IETF, the working group and the MIB Doctors are today very 
> reluctant to produce read-write MIB modules. The current draft is 
> read-write for a few objects, this is based on a consensus call for an 
> earlier discussion, however the consensus call was not clear. It can 
> be taken to mean both that we want to go with read-write objects and 
> that we want to see read-only. Is it clear that it has been 
> interpreted differently by different individuals.
>
> module(s) in the current document. Please indicate Support or Oppose 
> for this MIB (draft-ietf-mpls-tp-te-mib) to be read-only.
>
> <mailto:[email-masked]>
>
> Senior MPLS Expert [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 05 Feb 2014 06:29:57 -0800

> unable to take informed decisions).
I have no problem to drop "strongly" in "strongly discourages"

Regards, Benoit

---

From: "Joan Cucchiara" <[email-masked]>
Date: Wed, 5 Feb 2014 10:08:29 -0500

So, it's sounds like there are 2 different discussions going on here:
specifically making this draft read-only and WG migration to using NetConf
for configuration.  

Wrt the draft, this should remain read-write as it is tied to 2 legacy MIBs
(LSR and TE MIBs).   Technically, I don't see how a purely read-only for the
draft is viable (and yes, maybe there is a way, but I don't see it.) 

For the migration issue, I tend to agree with Juergen.    It is really up to
the WGs in my opinion.    Vendors don't tend to migrate to a new technology
unless their customers want it.   Perhaps, reaching out to
customers/operators should be a focus (and maybe this is already being
done?) .   Also, I think a continuation of providing support in the way of
educational tutorials, web pages, etc. and other assistance to WGs is
crucial.  

Maybe some of you are having a different experience, but in the last 6
months, I've consulted for a startup that started with YANG and NetConf and
also did a proposal for another company where I recommended NetConf and Yang
and that was proposed since they didn't want to use SNMP for configuration.
I don't see such a resistance to adoption of using NetConf for configuration
and yes, my experience is somewhat limited, but just wanted to say, I've
seen some positive attitudes towards adoption of YANG and NetConf already.

Thanks,
  -Joan

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, February 04, 2014 5:42 PM
To: Adrian Farrel
Cc: 'Joan Cucchiara'; [email-masked]
Subject: Re: [MIB-DOCTORS] Read-only MIB modules

On Tue, Feb 04, 2014 at 09:07:20PM +0000, Adrian Farrel wrote:
> require only read access for the extended tables, and that all objects 
> in this module would be read-only.

Sounds backwards from the SMIv2's notion of MAX-ACCESS. If you set
MAX-ACCESS to read-only, then this thing can never be implemented read-write
or read-create. This is why at some time in the past we started modeling
MAX-ACCESS read-write with read-only conformance statements if a WG decides
to do so and everyone could implement read-only and still claim compliance.

We learned that it is a good thing to separate configuration from
operational state and it used to be a WG decision whether the WG wants to
tackle configuration via SNMP or not. I believe WGs need to take informed
decisions and we should help them with that but be careful with 'strongly
discouraging' writable SNMP MIB modules for configuration purposes (unless
there is some evidence that WGs are unable to take informed decisions).

/js

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3684/7061 - Release Date: 02/04/14

---

From: David Harrington <[email-masked]>
Date: Sat, 8 Feb 2014 23:28:02 -0500

Hi,

I object to this statement. (Should I say "strongly" object, to show I mean business?

There are many RW objects that can "adjust" a network configuration assuming SET is supported by the agent involved.
The NMS I used to work on, which helped determine and correct root cause for fault and performance problems, adjusted networks using writable MIB modules often.
To tell WGs they should not develop RW MIB modules I think is wrong.

I also have a concern with recommending Netconf/YANG at this point in time.
If we looked up the top ten router vendors using something like Gartner reports, how many of them really support configuration using Netconf with YANG in shipping products?
Ditto, the top ten switch vendors?
How many of them can be fully configured using YANG modules (not homegrown alternatives, but modules - standard or proprietary - written using the standards-compliant YANG language)?
I don't know the answer to that question, but would like to see some proof that YANG is at least as widely supported in currently shipping products as RW MIB objects.
I think Netconf/YANG should compete in an open market with RW MIB modules, not try to stack the deck in their favor by "strongly discouraging" RW MIB standards.

I have had discussions with vendors who are leaders in their particular networking niche, and they have told me they would not consider Netconf/YANG, because it has not been around long enough and been widely-enough deployed to prove stable for their production networks (whereas SNMP has enough track record to be known to be stable).
So I'm a bit concerned about telling WGs they should develop YANG modules rather than MIB modules.
And the current discussions of whether YANG 1.1 or 2.0 is needed to fix some problems with YANG 1.0, and it may not be backwards compatible, make me question the stability of YANG.

Don't get me wrong. I support Netconf/YANG going forward, but I think it is important to provide advice that non-MIB-Doctors/non-YANG-experts can interpret reasonably.
Any such statement should make a clear distinction between "configuration" - the complete configuration of a device by Netconf - versus RW objects in a MIB - which can be used by SNMP to adjust network parameters/configuration.
Telling people not to develop RW MIBs is throwing the baby out with the bathwater.
We should NOT recommend against RW MIBs, because these can be used for more than (full device) configuration.
That point is far from clear in the currently proposed statement.
Maybe the statement should be that, if a vendor wants to replace their CLI, they should replace it with Netconf/YANG, and not with SNMP/RW-MIBs. 
That's probably a closer approximation  of Netconf/YANG's applicability versus RW MIBs. 

In the past we have allowed implementations to make the conformance choice between supporting a MIB as RW, or implementing read-only.
If we advise WGs to not develop module with RW objects, then we take the choice away from the vendors.
I thick that would be a mistake.

In  addition, it is pointed out later in this thread that other SDOs use RW MIBs. 
Well, those MIBs produced by other SDOs (and for that matter, vendors) might require some support for specific RW objects in IETF MIB modules.
Therefore, I think it would be providing bad advice to say that IETF WGs should not produce MIB  modules with RW objects in them.

If Netconf/YANG becomes widely deployed, then NMS implementations and operators can choose whether to use YANG or SNMP (or their CLI) to adjust network configurations.
THat should not be a decision we make in the IETF, effectively forcing WGs to not develop MIBs with writable objects.

Providing RW objects in MIB modules lets implementers and operators make the appropriate choice for their environments. (See RFC 3365 for similar thinking vis-a-vis security.)

dbh

---

From: Andy Bierman <[email-masked]>
Date: Sat, 8 Feb 2014 22:25:10 -0800

Hi,

I do not really know if an official statement to avoid SNMP Set is needed.
IMO the verdict is in wrt/ SNMP for configuration.

It has been a long-held tradition in the IETF to let people flail in their
own
sandbox if that's what they really wanted to do.  Maybe that has been a
mistake. Maybe WGs should be forced to prove that they have enough
real stakeholders willing to implement a spec, so that every part of
every proposed standard gets sponsored.

We often presume that "some vendors", who have had no interest in the
work all along, will eventually come around and decide to implement.
Therefore there is no need to have strong interest in deployment during
the WG process.

Commitment to implementation should apply to everything -- protocols,
MIB modules, YANG modules --- it doesn't matter. No stakeholders,
no sandbox.  That would be a radical change ;-)

Andy

On Sat, Feb 8, 2014 at 8:28 PM, David Harrington <[email-masked]>wrote:

> There are many RW objects that can "adjust" a network configuration
> assuming SET is supported by the agent involved.
> The NMS I used to work on, which helped determine and correct root cause
> for fault and performance problems, adjusted networks using writable MIB
> modules often.
> If we looked up the top ten router vendors using something like Gartner
> reports, how many of them really support configuration using Netconf with
> YANG in shipping products?
> How many of them can be fully configured using YANG modules (not homegrown
> alternatives, but modules - standard or proprietary - written using the
> standards-compliant YANG language)?
> I don't know the answer to that question, but would like to see some proof
> that YANG is at least as widely supported in currently shipping products as
> RW MIB objects.
> I think Netconf/YANG should compete in an open market with RW MIB modules,
> not try to stack the deck in their favor by "strongly discouraging" RW MIB
> standards.
>
> I have had discussions with vendors who are leaders in their particular
> networking niche, and they have told me they would not consider
> Netconf/YANG, because it has not been around long enough and been
> widely-enough deployed to prove stable for their production networks
> (whereas SNMP has enough track record to be known to be stable).
> And the current discussions of whether YANG 1.1 or 2.0 is needed to fix
> some problems with YANG 1.0, and it may not be backwards compatible, make
> me question the stability of YANG.
>
> Don't get me wrong. I support Netconf/YANG going forward, but I think it
> is important to provide advice that non-MIB-Doctors/non-YANG-experts can
> interpret reasonably.
> Any such statement should make a clear distinction between "configuration"
> - the complete configuration of a device by Netconf - versus RW objects in
> a MIB - which can be used by SNMP to adjust network
> parameters/configuration.
> Maybe the statement should be that, if a vendor wants to replace their
> CLI, they should replace it with Netconf/YANG, and not with SNMP/RW-MIBs.
> In the past we have allowed implementations to make the conformance choice
> between supporting a MIB as RW, or implementing read-only.
> Well, those MIBs produced by other SDOs (and for that matter, vendors)
> might require some support for specific RW objects in IETF MIB modules.
> Therefore, I think it would be providing bad advice to say that IETF WGs
> should not produce MIB  modules with RW objects in them.
>
> If Netconf/YANG becomes widely deployed, then NMS implementations and
> operators can choose whether to use YANG or SNMP (or their CLI) to adjust
> network configurations.
> THat should not be a decision we make in the IETF, effectively forcing WGs
> to not develop MIBs with writable objects.
>
> Providing RW objects in MIB modules lets implementers and operators make
> the appropriate choice for their environments. (See RFC 3365 for similar
> thinking vis-a-vis security.)
>
> dbh
>
> You'll note below that we immediately have an implementation claim (not
> for this doc, but for the modules it extends).
>
> *From:* mpls [mailto:[email-masked]] *On Behalf Of *GyeRok Gwun
> (???)
> *Cc:* [email-masked]'; '
> [email-masked]'
> From: mpls [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Loa Andersson
> working group for more work. We have a series of comments that are mostly
> for clarification. However the main reason for recalling the document is
> that there is one point where we need to confirm working group consensus.
>
> The IETF, the working group and the MIB Doctors are today very reluctant
> to produce read-write MIB modules. The current draft is read-write for a
> few objects, this is based on a consensus call for an earlier discussion,

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 9 Feb 2014 16:23:04 -0000

Andy,
 
I am all in favour of flailing in sandboxes as a way to burn off that excess
energy caused by high-tartrazine diets.
 
However, I think SNMP Set is showing up because people are putting together MIB
modules sans clue. They genuinely want to be helpful in the construction of MIB
modules that might have value, but they don't know how to do it and no-one else
in their immediate circle does either.
 
The consequence, beyond a spec that might or might not get implemented in full,
is that the MIB doctors have to do reviews of function they don't believe has
value.
 
A

From: Andy Bierman [mailto:[email-masked]] 
Sent: 09 February 2014 06:25
To: David Harrington
Cc: Adrian Farrel; MIB Doctors (E-mail)
Subject: Re: [MIB-DOCTORS] Read-only MIB modules
 
Hi,

It has been a long-held tradition in the IETF to let people flail in their own

Andy

On Sat, Feb 8, 2014 at 8:28 PM, David Harrington <[email-masked]> wrote:
Hi,
 
I object to this statement. (Should I say "strongly" object, to show I mean
business?
 
There are many RW objects that can "adjust" a network configuration assuming SET
is supported by the agent involved.
The NMS I used to work on, which helped determine and correct root cause for
fault and performance problems, adjusted networks using writable MIB modules
often.
To tell WGs they should not develop RW MIB modules I think is wrong.
 
I also have a concern with recommending Netconf/YANG at this point in time.
If we looked up the top ten router vendors using something like Gartner reports,
how many of them really support configuration using Netconf with YANG in
shipping products?
Ditto, the top ten switch vendors?
How many of them can be fully configured using YANG modules (not homegrown
alternatives, but modules - standard or proprietary - written using the
standards-compliant YANG language)?
I don't know the answer to that question, but would like to see some proof that
YANG is at least as widely supported in currently shipping products as RW MIB
objects.
I think Netconf/YANG should compete in an open market with RW MIB modules, not
try to stack the deck in their favor by "strongly discouraging" RW MIB
standards.
 
I have had discussions with vendors who are leaders in their particular
networking niche, and they have told me they would not consider Netconf/YANG,
because it has not been around long enough and been widely-enough deployed to
prove stable for their production networks (whereas SNMP has enough track record
to be known to be stable).
So I'm a bit concerned about telling WGs they should develop YANG modules rather
than MIB modules.
And the current discussions of whether YANG 1.1 or 2.0 is needed to fix some
problems with YANG 1.0, and it may not be backwards compatible, make me question
the stability of YANG.
 
Don't get me wrong. I support Netconf/YANG going forward, but I think it is
important to provide advice that non-MIB-Doctors/non-YANG-experts can interpret
reasonably.
Any such statement should make a clear distinction between "configuration" - the
complete configuration of a device by Netconf - versus RW objects in a MIB -
which can be used by SNMP to adjust network parameters/configuration.
Telling people not to develop RW MIBs is throwing the baby out with the
bathwater.
We should NOT recommend against RW MIBs, because these can be used for more than
(full device) configuration.
That point is far from clear in the currently proposed statement.
Maybe the statement should be that, if a vendor wants to replace their CLI, they
should replace it with Netconf/YANG, and not with SNMP/RW-MIBs. 
That's probably a closer approximation  of Netconf/YANG's applicability versus
RW MIBs. 
 
In the past we have allowed implementations to make the conformance choice
between supporting a MIB as RW, or implementing read-only.
If we advise WGs to not develop module with RW objects, then we take the choice
away from the vendors.
I thick that would be a mistake.
 
In  addition, it is pointed out later in this thread that other SDOs use RW
MIBs. 
Well, those MIBs produced by other SDOs (and for that matter, vendors) might
require some support for specific RW objects in IETF MIB modules.
Therefore, I think it would be providing bad advice to say that IETF WGs should
not produce MIB  modules with RW objects in them.
 
If Netconf/YANG becomes widely deployed, then NMS implementations and operators
can choose whether to use YANG or SNMP (or their CLI) to adjust network
configurations.
THat should not be a decision we make in the IETF, effectively forcing WGs to
not develop MIBs with writable objects.
 
Providing RW objects in MIB modules lets implementers and operators make the
appropriate choice for their environments. (See RFC 3365 for similar thinking
vis-a-vis security.)
 
dbh

Hi,

 
 
A
 
From: mpls [mailto:mpls- <mailto:[email-masked]> [email-masked]] On Behalf
Of GyeRok Gwun (???)
Sent: 04 February 2014 09:57
To: ' <mailto:[email-masked]> [email-masked]'
Cc: ' <mailto:[email-masked]> [email-masked]'; '
<mailto:[email-masked]>
[email-masked]'
Subject: Re: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-
only

Best Regards
Gwun
 
-----Original Message-----
From: mpls [ <mailto:[email-masked]> mailto:[email-masked]] On
Behalf Of Loa Andersson
Sent: Monday, February 03, 2014 10:55 PM
To:  <mailto:[email-masked]> [email-masked]
Cc:  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]>
[email-masked]
Subject: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read- only
 
Working Group,

 

 
Loa
for the MPLS wg chairs
--

Loa Andersson                        email:  <mailto:[email-masked]>
[email-masked]
Senior MPLS Expert                           <mailto:[email-masked]> [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/mpls>
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/mpls>
https://www.ietf.org/mailman/listinfo/mpls
 
_______________________________________________
MIB-DOCTORS mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/mib-doctors>
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: Andy Bierman <[email-masked]>
Date: Sun, 9 Feb 2014 09:23:06 -0800

On Sun, Feb 9, 2014 at 8:23 AM, Adrian Farrel <[email-masked]> wrote:

> Andy,
>
>
>
> I am all in favour of flailing in sandboxes as a way to burn off that
> excess energy caused by high-tartrazine diets.
>
>
>
> However, I think SNMP Set is showing up because people are putting
> together MIB modules sans clue. They genuinely want to be helpful in the
> construction of MIB modules that might have value, but they don't know how
> to do it and no-one else in their immediate circle does either.
>
>
>
> The consequence, beyond a spec that might or might not get implemented in
> full, is that the MIB doctors have to do reviews of function they don't
> believe has value.
>
>
>

The IESG and IETF have to reviews these documents as well.
I think people writing MIB modules know how to do it, but they are
following a formula setup by the IESG and blessed by MIB Doctors.

MIB authors seem encouraged to use read-create objects, but then
add MIN-ACCESS read-only in the conformance statement,
just in case anybody ever wants to implement the MAX-ACCESS.

Time to face the fact that nobody is implementing the MAX-ACCESS.
In order to claim conformance to a MIB module, it should be
without this MIB-ACCESS loophole.  WG groups can then decide
if they have enough participants who plan on implementing read-create.
If not, then they can't have it.  The MIB gets rejected and sent back
to the WG if it contains any MIN-ACCESS clauses.

Andy

A
>
>
>
>
>
> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* 09 February 2014 06:25
> *To:* David Harrington
> *Cc:* Adrian Farrel; MIB Doctors (E-mail)
> *Subject:* Re: [MIB-DOCTORS] Read-only MIB modules
>
>
>
> Hi,
>
>
>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 10 Feb 2014 18:27:04 -0800

Hi,

What this statement tries to achieve is
1. Set the direction for new MIB modules development
2. Still leave the door open (SNMP MIB modules modifying persistent 
configuration state should only be produced by working groups in cases 
of clear utility and overwhelming consensus to use SNMP write operations 
for configuration.)

On a recent read-write example, I asked an author:
- can you tell which OS/platform are/will be implementing this 
read-write MIB module?
- can you tell which NMS will be using the read-write capabilities?
The answer were eloquent.

Regards, Benoit

> The NMS I used to work on, which helped determine and correct root 
> cause for fault and performance problems, adjusted networks using 
> writable MIB modules often.
> If we looked up the top ten router vendors using something like 
> Gartner reports, how many of them really support configuration using 
> Netconf with YANG in shipping products?
> How many of them can be fully configured using YANG modules (not 
> homegrown alternatives, but modules - standard or proprietary - 
> written using the standards-compliant YANG language)?
> I don't know the answer to that question, but would like to see some 
> proof that YANG is at least as widely supported in currently shipping 
> products as RW MIB objects.
> I think Netconf/YANG should compete in an open market with RW MIB 
> modules, not try to stack the deck in their favor by "strongly 
> discouraging" RW MIB standards.
>
> I have had discussions with vendors who are leaders in their 
> particular networking niche, and they have told me they would not 
> consider Netconf/YANG, because it has not been around long enough and 
> been widely-enough deployed to prove stable for their production 
> networks (whereas SNMP has enough track record to be known to be stable).
> And the current discussions of whether YANG 1.1 or 2.0 is needed to 
> fix some problems with YANG 1.0, and it may not be backwards 
> compatible, make me question the stability of YANG.
>
> Don't get me wrong. I support Netconf/YANG going forward, but I think 
> it is important to provide advice that 
> non-MIB-Doctors/non-YANG-experts can interpret reasonably.
> Any such statement should make a clear distinction between 
> "configuration" - the complete configuration of a device by Netconf - 
> versus RW objects in a MIB - which can be used by SNMP to adjust 
> network parameters/configuration.
> In the past we have allowed implementations to make the conformance 
> choice between supporting a MIB as RW, or implementing read-only.
> Therefore, I think it would be providing bad advice to say that IETF 
> WGs should not produce MIB  modules with RW objects in them.
>
> operators can choose whether to use YANG or SNMP (or their CLI) to 
> adjust network configurations.
> THat should not be a decision we make in the IETF, effectively forcing 
> WGs to not develop MIBs with writable objects.
>
> Providing RW objects in MIB modules lets implementers and operators 
> make the appropriate choice for their environments. (See RFC 3365 for 
> similar thinking vis-a-vis security.)
>
> dbh
>
> On Feb 4, 2014, at 8:32 AM, Adrian Farrel <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Hi,
>> that triggered my recent questions that led on to the draft advice 
>> you are working on. The WG took the document back to make this decision.
>> *From:*mpls [mailto:[email-masked] 
>> <mailto:[email-masked]>]*On Behalf Of*GyeRok Gwun (???)
>> *Sent:*04 February 2014 09:57
>> *To:[email-masked] <mailto:[email-masked]>'
>> *Cc:[email-masked] 
>> <mailto:[email-masked]>'; 
>> [email-masked] 
>> <mailto:[email-masked]>'
>> *Subject:*Re: [mpls] seeking consensus on making 
>> To:[email-masked] <mailto:[email-masked]>
>> Cc:[email-masked] 
>> <mailto:[email-masked]>;[email-masked] 
>> read-write for a few objects, this is based on a consensus call for 
>> an earlier discussion, however the consensus call was not clear. It 
>> can be taken to mean both that we want to go with read-write objects 
>> and that we want to see read-only. Is it clear that it has been 
>> Loa Andersson                        email:[email-masked] 
>> [email-masked] <mailto:[email-masked]>

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 26 Feb 2014 17:40:38 -0500

On Feb 9, 2014:12:23 PM, at 12:23 PM, Andy Bierman <[email-masked]> wrote:

> I am all in favour of flailing in sandboxes as a way to burn off that excess energy caused by high-tartrazine diets.
> 
>  
> 
> However, I think SNMP Set is showing up because people are putting together MIB modules sans clue. They genuinely want to be helpful in the construction of MIB modules that might have value, but they don't know how to do it and no-one else in their immediate circle does either.
> 
>  
> 
> The consequence, beyond a spec that might or might not get implemented in full, is that the MIB doctors have to do reviews of function they don't believe has value.
> 
> 
> 
> 
> 

	And hence my point about wasting time of those resources writing those min-access statements (and conformance clauses). That stuff is non-trivial, nor is getting row construction ordering/etc... details right.  And then its all for nothing because as you rightly said, nearly no one is using it. 

	--Tom

---

From: "David Harrington" <[email-masked]>
Date: Thu, 27 Feb 2014 17:14:41 -0500

"WG groups can then decide

"

So why should rw mibs be held to a higher standard than other IETF proposed
standards?

David Harrington

 <mailto:[email-masked]> [email-masked]

+1-603-828-1401

From: MIB-DOCTORS [mailto:[email-masked]] On Behalf Of Thomas
Nadeau
Sent: Wednesday, February 26, 2014 5:41 PM
To: Andy Bierman
Cc: Farrel Adrian; MIB Doctors (E-mail)
Subject: Re: [MIB-DOCTORS] Read-only MIB modules

On Feb 9, 2014:12:23 PM, at 12:23 PM, Andy Bierman <[email-masked]>
wrote:

Andy,

However, I think SNMP Set is showing up because people are putting together
MIB modules sans clue. They genuinely want to be helpful in the construction
of MIB modules that might have value, but they don't know how to do it and
no-one else in their immediate circle does either.

 

          And hence my point about wasting time of those resources writing
those min-access statements (and conformance clauses). That stuff is
non-trivial, nor is getting row construction ordering/etc... details right.
And then its all for nothing because as you rightly said, nearly no one is
using it. 

          --Tom

Andy

 

A

Hi,

the WG process.

 

Andy

On Sat, Feb 8, 2014 at 8:28 PM, David Harrington <[email-masked]>
wrote:

Hi,

There are many RW objects that can "adjust" a network configuration assuming
SET is supported by the agent involved.

So I'm a bit concerned about telling WGs they should develop YANG modules
rather than MIB modules.

And the current discussions of whether YANG 1.1 or 2.0 is needed to fix some
problems with YANG 1.0, and it may not be backwards compatible, make me
question the stability of YANG.

Don't get me wrong. I support Netconf/YANG going forward, but I think it is
important to provide advice that non-MIB-Doctors/non-YANG-experts can
interpret reasonably.

Any such statement should make a clear distinction between "configuration" -
the complete configuration of a device by Netconf - versus RW objects in a
MIB - which can be used by SNMP to adjust network parameters/configuration.

We should NOT recommend against RW MIBs, because these can be used for more
than (full device) configuration.

Maybe the statement should be that, if a vendor wants to replace their CLI,
they should replace it with Netconf/YANG, and not with SNMP/RW-MIBs. 

That's probably a closer approximation  of Netconf/YANG's applicability
versus RW MIBs. 

If we advise WGs to not develop module with RW objects, then we take the
choice away from the vendors.

Providing RW objects in MIB modules lets implementers and operators make the
appropriate choice for their environments. (See RFC 3365 for similar
thinking vis-a-vis security.)

dbh

Hi,

A

From: mpls [mailto:mpls- <mailto:[email-masked]> [email-masked]] On
Behalf Of GyeRok Gwun (???)
Sent: 04 February 2014 09:57
To: ' <mailto:[email-masked]> [email-masked]'
Cc: ' <mailto:[email-masked]> [email-masked]'; '
<mailto:[email-masked]>
[email-masked]'
Subject: Re: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib
read- only

Best Regards

Gwun

-----Original Message-----

Working Group,

Loa

for the MPLS wg chairs

--

mpls mailing list

mpls mailing list

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Feb 2014 15:52:24 -0800

On Thu, Feb 27, 2014 at 2:14 PM, David Harrington
<[email-masked]>wrote:

> So why should rw mibs be held to a higher standard than other IETF
> proposed standards?
>
>
>

They should not, but if industry does not implement read-write MIB modules,
then the IETF should really ask itself why it is wasting so many volunteer
resources to produce these RFCs.

If the answer is "volunteers are free" so who cares if they do work
that nobody uses, then that is a valid answer I suppose, but not
one that will inspire more people to volunteer.

Andy

David Harrington
>
> [email-masked]
>
> +1-603-828-1401
>
> *From:* MIB-DOCTORS [mailto:[email-masked]] *On Behalf Of *Thomas
> Nadeau
> *Sent:* Wednesday, February 26, 2014 5:41 PM
> *To:* Andy Bierman
> *Cc:* Farrel Adrian; MIB Doctors (E-mail)
>           And hence my point about wasting time of those resources
> writing those min-access statements (and conformance clauses). That stuff
> is non-trivial, nor is getting row construction ordering/etc... details
> right.  And then its all for nothing because as you rightly said, nearly no
> one is using it.
>
>
>
>           --Tom
>
>
>
>
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
>
>
>
>
> A
>
>
>
>
>