Subject: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB

From: Ross Callon <[email-masked]>
Date: Tue, 20 Sep 2011 15:43:59 -0400

There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a read-only MIB (it currently contains relatively few writeable objects). This is compatible with my understanding of how MIBs are often used. However, this also varies from normal IETF convention where MIBs contain both read and write objects.

We therefore are asking for comments from the WG regarding whether people are okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be read only.

Thanks, Ross
(for the MPLS WG co-chairs)

---

From: "Joan Cucchiara" <[email-masked]>
Date: Wed, 21 Sep 2011 08:31:23 -0400

I am good with changing this MIB to be read-only.

Thanks,
  -Joan

  ----- Original Message ----- 
  From: Ross Callon 
  To: [email-masked] 
  Sent: Tuesday, September 20, 2011 3:43 PM
  Subject: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB

  Thanks, Ross

------------------------------------------------------------------------------

  _______________________________________________
  mpls mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/mpls

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 20 Sep 2011 13:39:14 -0700

In message <[email-masked]>
Ross Callon writes:
 
> There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a
> read-only MIB (it currently contains relatively few writeable
> objects). This is compatible with my understanding of how MIBs are
> often used. However, this also varies from normal IETF convention
> where MIBs contain both read and write objects.
>  
> We therefore are asking for comments from the WG regarding whether
> people are okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be
> read only.
>  
> Thanks, Ross

No complaint here.

It should have been read-only in the first place IMO.  Most
implementations provide a rich superset of configuration options when
setting up the ingress of an RSVP-TE tunnel through CLI or netconf.
Configuring using the MIB was never practical.  The MIB is highly
useful for monitoring MPLS RSVP-TE tunnels from the ingress but was
never useful for configuration.

Curtis

---

From: Kannan KV Sampath <[email-masked]>
Date: Thu, 22 Sep 2011 11:50:20 +0530

Hi,
I have a different of opinion on this.
To the best of my knowledge, there are still OEMs/Vendors who use SNMP as the base for configuration. There are tons of automated testing that happens based on SNMP MIBs. Even few NMS systems use SNMP as the southbound interface with the NEs.

Having said this, I have few open questions.
1) What are the advantages that we get by making it as READ-ONLY, or, what are the disadvantages in retaining it as READ-WRITE? Can anyone elaborate on the compulsion behind making this as read-only?
2) Is this rule applicable for all other MIBs including the MIBs that are used for all other protocols? Or, is this applicable only for "draft-ietf-mpls-tp-te-mib-00.txt"?

If someone can explain more on this, it would be useful before making a decision.

Thanks & Regards,
Kannan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis Villamizar
Sent: Wednesday, September 21, 2011 2:09 AM
To: Ross Callon
Cc: [email-masked]
Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB

No complaint here.

Curtis

===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 22 Sep 2011 14:05:39 -0400

> To the best of my knowledge, there are still OEMs/Vendors who use SNMP as the base for configuration. There are tons of automated testing that happens based on SNMP MIBs. Even few NMS systems use S…

	They are truly in the minority.  Having worked on building the management for one of the "big 3" MPLS implementations in the past, I can safely say that we had a *tiny* fraction of customers that actually ever asked us for writable MIBs, and even in those cases we often refused to implement writable SNMP. As someone who has worked at a large tier-1 service provider, my experience there was that SNMP writes are basically disallowed for all but a few very tightly constrained cases because vendors do not implement a fully writable implementation (see case #1).   Finally, as someone who now works for a large NM software vendor, I can tell you that the latter situation is the majority case we encounter both in the enterprise and SP space.  Provisioning is definitely done using CLI or XML in a majority of cases these days, and is moving towards web services as a third alternative. 

> 1) What are the advantages that we get by making it as READ-ONLY, or, what are the disadvantages in retaining it as READ-WRITE? Can anyone elaborate on the compulsion behind making this as read-onl…

	The disadvantage is that you cannot provision the objects you find in this MIB using the SNMP protocol. However, that is not that big a deal if you ask me since most implementations will overlay %20-%40 more capabilities on top of the ones you will find in this MIB. Most of those implementations will not offer those objects as writable. Thus, you've got a patchwork quilt of things that are and are not writable; therefore you go use the vendor's interface that is %100 writable: generally the CLI, XML/netconf or web services. 

	The advantages are simple: Ease of design and time to RFC. Making a MIB configurable is a major drag on resources working on it with little return for that effort given that like %1 of users might want to use those capabilities. Making is read-only lets you avoid all sorts of things like object state locking, synchronization, etc... which are hard to get right (and are done better in things like Netconf anyway).  Making anything more than a very simple MIB truly configurable is something that I would reckon from past experience, easily quadruples the amount of time it takes to get a MIB done and in some cases has resulted in a 'wheel wrapped around the axle' situation when the IESG reviews the MIB. Given what I mentioned above regarding data points about the demand of writable functions actually being used, the effort required to make a MIB writable just isn't justified IMHO.

> 2) Is this rule applicable for all other MIBs including the MIBs that are used for all other protocols? Or, is this applicable only for "draft-ietf-mpls-tp-te-mib-00.txt"?

	As I understand it, the request Ross just posed was for draft-ietf-mpls-tp-te-mib only. If you want to open up the discussion to include all future MIBs this WG produces that is fine; however, I would like to conclude this call for consensus on this specific draft first so we don't get too distracted.

	--Tom

---

From: "t.petch" <[email-masked]>
Date: Tue, 27 Sep 2011 17:57:55 +0200

It seems to me that the work on a read-write MIB module has been done, and that
taking out the write capability is therefore more work and not less.  The work
that has been done could be used in future, for example as input to an SMI-Yang
converter to create a suitable module for use with Netconf.

>From an SMI perspective, Conformance clauses allow a read-only version to be
specified within the MIB module which most, if not all, implementers could then
select, as they wish.

So while I don't have a user view, as to whether or not read-write access is
useful - I take Tom's point that SNMP with a Standards Track MIB module is
rarely used for provisioning - I am unclear what the benefit is of making this
read-only.

Tom Petch

----- Original Message -----
From: "Ross Callon" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, September 20, 2011 9:43 PM
Subject: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB

There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a read-only MIB (it
currently contains relatively few writeable objects). This is compatible with my
understanding of how MIBs are often used. However, this also varies from normal
IETF convention where MIBs contain both read and write objects.

We therefore are asking for comments from the WG regarding whether people are
okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be read only.

Thanks, Ross

--------------------------------------------------------------------------------

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 27 Sep 2011 13:34:05 -0400

> converter to create a suitable module for use with Netconf.

	Speaking as one of the authors, I can safely say that what is there is incomplete.  
We have taken a short break until we can get consensus on the read-write situation.
Furthermore, you are not considering future items/tables that are added, their interrelation 
to existing ones, as well as other TP-related MIB modules that are not yet created. 

> rarely used for provisioning - I am unclear what the benefit is of making this

	The benefits are:

	The co-authors do not have to waste time on making sure the module is read-write

	The MIB Doctors and IESG do not have to waste time determining if the co-authors have done their job

	The WG gets an RFC version of this MIB about a year earlier. 

	--Tom

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Sep 2011 13:52:26 +0100

Tom (N) wrote... 

> 	The WG gets an RFC version of this MIB about a year earlier.

Which begs the question (speaking purely as an individual contributor) of why we
are bothering with a MIB module at all.

Adrian

---

From: "t.petch" <[email-masked]>
Date: Wed, 28 Sep 2011 14:08:18 +0200

----- Original Message -----
From: "Thomas Nadeau" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Ross Callon" <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 27, 2011 7:34 PM

> converter to create a suitable module for use with Netconf.

Speaking as one of the authors, I can safely say that what is there is
incomplete.
We have taken a short break until we can get consensus on the read-write
situation.
Furthermore, you are not considering future items/tables that are added, their
interrelation
to existing ones, as well as other TP-related MIB modules that are not yet
created.

<tp>
OK, I misunderstood the situation.

Tom Petch

</tp>

The benefits are:

The MIB Doctors and IESG do not have to waste time determining if the co-authors
have done their job

--Tom

--

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 28 Sep 2011 09:49:23 -0400

> are bothering with a MIB module at all.

	I am not sure how you made the leap from the current thread to that. Can you elaborate?

	--Tom

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Sep 2011 15:55:40 +0100

> > Which begs the question (speaking purely as an individual contributor) of
why
> we

Sure.
You said something that implies the WG would like the MIB [module] about a year
earlier.
So I wondered (aloud) whether the WG wants the MIB module at all.
If there is a rush to have a MIB module, that is fine. I don't really hear much
demand for a rapid, read-only MPLS-TP TE module.

So, rather than have folk say "we have no interest in a writeable MIB module" we
should ask people to comment on whether they "want a rapid-to-RFC read-only MIB
module".

A

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 28 Sep 2011 11:04:45 -0400

> should ask people to comment on whether they "want a rapid-to-RFC read-only MIB

	I suppose that is a fair enough question to ask, but one that I think was asked
when we asked the WG to adopt the draft as a WG document, no?

	--Tom