Subject: Re: [MIB-DOCTORS] configuration: writable MIB modules versus NETCONF/YANGmodules

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 14 Feb 2014 19:18:46 -0000

Hi Joan, 

[Reverting to the MIB Doctor Thread]

I will bow to your far (far, far) superior understanding of MIB-speak.

But I don't understand :-(

A row in a table that has RowStatus can have read-only objects and writeable
objects with Defaults as well as read-create objects.
When you use, for example, CreateAndGo the whole row gets created with
read-create objects as they are Set, with unSet writeable objects defaulting,
and with read-only objects filled with values from the implementation.

When I extend a table, surely I can extend with objects that are all only
read-only?
Furthermore, the whole row in the extension table could be automatically created
when the row in the extended table is created.

What am I missing?
 
Thanks,
Adrian

> -----Original Message-----
> From: OPS-AREA [mailto:[email-masked]] On Behalf Of Joan
> Cucchiara
> Sent: 14 February 2014 18:28
> To: 't.petch'; 'Benoit Claise'; [email-masked]
> Subject: Re: [OPS-AREA] configuration: writable MIB modules versus
> NETCONF/YANGmodules
> 
> Hi Tom,
> 
> As the MIB Dr. on this draft,  I have responded on the MIB Dr. thread that I
> do NOT see a way to make this draft (draft-ietf-mpls-tp-te-mib) read-only.
> This draft contains extension tables for tables in LSR and TE MIBS which are
> created by RowStatus (which is read-create).   Like it or not, RowStatus of
> those MIBs (i.e. LSR and TE MIBs) effect the rows in the extension tables of
> this draft (think the case of row creation or row deletion).   That is an
> SNMP Set operation which effects the draft.
> 
> I believe the statement that Benoit puts forth would allow for such a
> situation as this draft, specifically:
> 
> "... SNMP MIB modules modifying persistent configuration state
>  should only be produced by working groups in cases of clear utility
> and consensus to use SNMP write operations for configuration."
> 
> Perhaps, additional wording, such as "For example, in the case of proposed
> SNMP MIB modules which extend or augment rows that are created by
> configuration in a SNMP MIB module which is already a RFC, the proposed SNNP
> MIB modules will be grandfathered, if the working group finds consensus to
> do so."
> 
> However, I am okay with the statement as written.
> 
> Thanks,
>   -Joan
> 
> 
> -----Original Message-----
> From: OPS-AREA [mailto:[email-masked]] On Behalf Of t.petch
> Sent: Friday, February 14, 2014 10:02 AM
> To: Benoit Claise; [email-masked]
> Subject: Re: [OPS-AREA] configuration: writable MIB modules versus
> NETCONF/YANGmodules
> 
> ----- Original Message -----
> From: "Benoit Claise" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, February 14, 2014 12:39 AM
> > Dear all,
> >
> > We occasionally see read-write MIB module proposals within the IETF.
> > However, the write capabilities of those MIB modules are rarely
> implemented.
> >
> > While discussing this issue with the MIB doctors, we arrive to the
> > conclusion that it's now time to set the direction for future MIB
> > developments within the IETF. Basically, let's not specify read-write
> > MIB modules unless we have a good reason. Read-only MIB modules are
> > still fine though, as SNMP is clearly used for monitoring purposes.
> >
> > Here is the statement we came up with:
> >
> >     The OPS area recommends the use of NETCONF/YANG standards for
> >     configuration. IETF working groups are therefore encouraged to use
> >     the NETCONF/YANG standards for configuration, specifically in new
> >     charters. SNMP MIB modules modifying persistent configuration
> state
> >     should only be produced by working groups in cases of clear
> utility
> >     and consensus to use SNMP write operations for configuration.
> >
> > Ideally, this should become an IESG statement.
> > Your feedback is most welcome.
> 
> You probably know that there is currently a consensus call in progress over
> 
> "Please indicate Support or Oppose for this MIB
> (draft-ietf-mpls-tp-te-mib) to be read-only."
> 
> and I was pleasantly surprised to see opposition, albeit with one opponent
> later changing their mind (perhaps they were sat on from a height:-).  I
> don't see much sign of Netxxxx in the mpls arena but there is a need there
> for configuration, since there need not be a control plane to set things up.
> Perhaps writable MIB modules will still be with us in the distant future in
> some corners of the Internet..
> 
> Ideally, this idea would be fleshed out in an I-D.
> 
> Tom Petch
> 
> > Regards, the MIB doctors & Benoit
> 
> _______________________________________________
> OPS-AREA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-area
> 
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4259 / Virus Database: 3705/7092 - Release Date: 02/14/14
> 
> _______________________________________________
> OPS-AREA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-area

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 16 Feb 2014 11:55:14 +0000

Hi Adrian,

Even if the row you extend is composed only by objects with MAX-ACCESS read-only, creating a new row involves a write operation on the object with SYNTAX RowStatus. 

This is (I guess) what Joan meant. 

Creating a new row may mean a modification of configuration on the managed entity. You now have n+1 rows instead of n rows in the table. 

Regards,

Dan

> From: MIB-DOCTORS [mailto:[email-masked]] On Behalf Of
> Adrian Farrel
> Sent: Friday, February 14, 2014 9:19 PM
> To: 'Joan Cucchiara'; 't.petch'; 'Benoit Claise'; [email-masked]
> Subject: Re: [MIB-DOCTORS] configuration: writable MIB modules versus
> NETCONF/YANGmodules
> 
> Hi Joan,
> 
> When I extend a table, surely I can extend with objects that are all only read-
> only?
> Furthermore, the whole row in the extension table could be automatically
> created when the row in the extended table is created.
> 
> What am I missing?
> 
> Thanks,
> Adrian
> 
> > As the MIB Dr. on this draft,  I have responded on the MIB Dr. thread
> > that I do NOT see a way to make this draft (draft-ietf-mpls-tp-te-mib) read-
> only.
> > "... SNMP MIB modules modifying persistent configuration state  should
> > only be produced by working groups in cases of clear utility and
> > consensus to use SNMP write operations for configuration."
> >
> > Perhaps, additional wording, such as "For example, in the case of
> > proposed SNMP MIB modules which extend or augment rows that are
> > created by configuration in a SNMP MIB module which is already a RFC,
> > the proposed SNNP MIB modules will be grandfathered, if the working
> > group finds consensus to do so."
> >
> > > developments within the IETF. Basically, let's not specify
> > > read-write MIB modules unless we have a good reason. Read-only MIB
> > > modules are still fine though, as SNMP is clearly used for monitoring
> purposes.
> > >
> > and I was pleasantly surprised to see opposition, albeit with one
> > opponent later changing their mind (perhaps they were sat on from a
> > height:-).  I don't see much sign of Netxxxx in the mpls arena but
> > there is a need there for configuration, since there need not be a control
> plane to set things up.
> > Perhaps writable MIB modules will still be with us in the distant
> > future in some corners of the Internet..
> >
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Sun, 16 Feb 2014 07:55:20 -0500

What you describe here is one of the reasons why it has been pointed out repeatedly (Andy I think) why SNMP is not very good at configuration.  

	--Tom

> On Feb 16, 2014, at 6:55 AM, "Romascanu, Dan (Dan)" <[email-masked]> wrote:
> 
> Hi Adrian,
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 16 Feb 2014 18:02:45 -0000

I'm sorry if I am being thick.

The row in the old table has a RowStatus object which is, of course,
read-create.
The extension table entry has no object with SYNTAX rowStatus, but is created
automatically when the entry in the old table is created.

A

> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: 16 February 2014 11:55
> To: [email-masked]; 'Joan Cucchiara'; 't.petch'; 'Benoit Claise'; mib-
> [email-masked]
> Subject: RE: [MIB-DOCTORS] configuration: writable MIB modules versus
> NETCONF/YANGmodules
> 
> Hi Adrian,
> 
> Even if the row you extend is composed only by objects with MAX-ACCESS read-
> only, creating a new row involves a write operation on the object with SYNTAX
> RowStatus.
> 
> Creating a new row may mean a modification of configuration on the managed
> entity. You now have n+1 rows instead of n rows in the table.
> 
> Regards,
> 
> Dan
> 
> 
read-

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 16 Feb 2014 19:45:20 +0000

By using the already existing RowStatus object in the base table the creation of new rows in the base table leads to the creation of new rows in the extended table. Even if the objects that you defined are all read-only, the effect is the same as defining a new table with a RowStatus object. 

Dan

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Sunday, February 16, 2014 8:03 PM
> To: Romascanu, Dan (Dan); 'Joan Cucchiara'; 't.petch'; 'Benoit Claise'; mib-
> [email-masked]
> The row in the old table has a RowStatus object which is, of course, read-
> create.
> The extension table entry has no object with SYNTAX rowStatus, but is
> created automatically when the entry in the old table is created.
> 
> A
> 
> > To: [email-masked]; 'Joan Cucchiara'; 't.petch'; 'Benoit Claise';
> > mib- [email-masked]
> > Even if the row you extend is composed only by objects with MAX-ACCESS
> > read- only, creating a new row involves a write operation on the
> > object with SYNTAX RowStatus.
> >
> > Creating a new row may mean a modification of configuration on the
> > managed entity. You now have n+1 rows instead of n rows in the table.
> >
> > Regards,
> >
> > Dan
> >
> >
> > > Subject: Re: [MIB-DOCTORS] configuration: writable MIB modules
> > > versus NETCONF/YANGmodules
> > >
> > > Hi Joan,
> > >
> > > A row in a table that has RowStatus can have read-only objects and
> > > writeable objects with Defaults as well as read-create objects.
> > > When you use, for example, CreateAndGo the whole row gets created
> > > with read-create objects as they are Set, with unSet writeable
> > > objects
> defaulting,
> > > Furthermore, the whole row in the extension table could be
> > > automatically created when the row in the extended table is created.
> > >
> > > What am I missing?
> > >
> > > Thanks,
> > > Adrian
> > >
> > > > From: OPS-AREA [mailto:[email-masked]] On Behalf Of
> > > > Joan Cucchiara
> > > > As the MIB Dr. on this draft,  I have responded on the MIB Dr.
> > > > thread that I do NOT see a way to make this draft
> > > > (draft-ietf-mpls-tp-te-mib)
> read-
> > > only.
> > > > This draft contains extension tables for tables in LSR and TE MIBS
> > > > which
> are
> > > > those MIBs (i.e. LSR and TE MIBs) effect the rows in the extension
> > > > tables
> of
> > > > I believe the statement that Benoit puts forth would allow for
> > > > such a situation as this draft, specifically:
> > > >
> > > > utility and consensus to use SNMP write operations for configuration."
> > > >
> > > > created by configuration in a SNMP MIB module which is already a
> > > > RFC, the proposed SNNP MIB modules will be grandfathered, if the
> > > > working group finds consensus to do so."
> > > >
> > > > > While discussing this issue with the MIB doctors, we arrive to
> > > > > the conclusion that it's now time to set the direction for
> > > > > future MIB developments within the IETF. Basically, let's not
> > > > > specify read-write MIB modules unless we have a good reason.
> > > > > Read-only MIB modules are still fine though, as SNMP is clearly
> > > > > used for monitoring
> > > purposes.
> > > > >
> > > > opponent later changing their mind (perhaps they were sat on from
> > > > a height:-).  I don't see much sign of Netxxxx in the mpls arena
> > > > but there is a need there for configuration, since there need not
> > > > be a control
> > > plane to set things up.

---

From: "Joan Cucchiara" <[email-masked]>
Date: Sun, 16 Feb 2014 19:11:45 -0500

Hi Adrian,

Please see inline below prefaced with JEC >.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 2:19 PM
To: 'Joan Cucchiara'; 't.petch'; 'Benoit Claise'; [email-masked]
Subject: RE: configuration: writable MIB modules versus NETCONF/YANGmodules

Hi Joan, 

A row in a table that has RowStatus can have read-only objects and writeable
objects with Defaults as well as read-create objects.
When you use, for example, CreateAndGo the whole row gets created with
read-create objects as they are Set, with unSet writeable objects
defaulting, and with read-only objects filled with values from the
implementation.

JEC > But that is kind of beside the point.   The LSR and TE MIBs (rfc3813
and rfc3812, c. 2004) have two conformance statements, Full and Read-only. 
JEC >  Full Conformance allows for configuring with SNMP sets.   So this
discussion is focusing on only the Full Conformance. 
JEC >  The RowStatus objects in the TE and LSR MIB Modules (rfc3813 and
rfc3812) MUST be implemented as having  a MAX-ACCESS of read-create.   In
other words,
JEC > a row can be created or deleted, etc. because the agent processes an
SNMP set request to configure the RowStatus object (i.e. a set is issued 
JEC > for create-and-go, destroy, etc).    

JEC > The point is that RowStatus  creates the row because of an SNMP set
request.  (Certainly rows can be created other ways too.)
JEC >  There is only ONE RowStatus for the entire row, and 
JEC > if that row is extended or AUGMENTed in additional MIB Modules, as in
the case draft-ietf-mpls-tp-te-mib which extends rows in rfc3813 and
rfc3812, 
JEC > then these extended rows are controlled ALSO by that same RowStatus
object which was defined in the TE/LSR MIB Modules.    
JEC > There is only one RowStatus object which controls the entire row, even
if parts
JEC> of the row are in different MIB Modules (as with
draft-ietf-mpls-tp-te-mib).    If you think about the case of deleting a
row, this makes sense.
JEC > If the RowStatus object in the TE MIB is set to "destroy", then the
deletion of the entire row must happen, even if the objects of that row are
in 
JEC > other MIB modules.    

What am I missing?

JEC >  The agent  MUST "configure" (e.g. create the objects,  delete the
objects) in  these extended rows  in this draft because of an SNMP set
request.    
JEC >   I don't see any way around this, without redefining the RowStatus
TC, or rewriting the TE or LSR MIBs or (probably the simplest solution) the 
JEC> co-authors write the draft in such a way as to not extend tables in the
TE and LSR MIBs.

JEC > So to summarize, an SNMP agent that supports this draft MUST support
the SNMP set request for RowStatus for the rows which extend rows in
JEC> the LSR and TE MIBs.   

JEC> Since that is the case, and since this draft is tied to these RFCs that
are 10 years old now,  I don't have an issue 
JEC> with them configuring via SNMP for other objects also (but that is just
my opinion).

Thanks,
  -Joan

Thanks,
Adrian

> that I do NOT see a way to make this draft (draft-ietf-mpls-tp-te-mib)
read-only.
purposes.
plane to set things up.

-----

---

From: "Joan Cucchiara" <[email-masked]>
Date: Sun, 16 Feb 2014 20:28:24 -0500

Hi Adrian,

Yes.  Dan has correctly stated what I was trying to say.

The concept of a row is such that objects of a single row can be defined in
one or more MIB Modules.   For example,  Row A has 10 objects (one of them
being RowStatus).   5 objects (including the RowStatus object) are defined
in MIB-A and the other 5 are defined in draft-ietf-mpls-te-tp-mib.     

The managed entity which supports the draft, MUST be able to
create/delete/etc.  ALL the objects in  a row due to an SNMP set request to
RowStatus. 
The Row is an concept unto itself, and this row is impacted by SNMP sets to
RowStatus.   

If the goal (as I understand it) is to make this  draft read-only to prevent
configuration via SNMP sets, then that won't be the case with this draft
even if all the objects are made read-only.    Just the nature of Row and
RowStatus and Full Conformance.   In other words, the managed entity still
needs to create/delete all the objects in the row. This will be the same
managed entity that MUST support SNMP set requests to RowStatus, so the goal
of eliminating the processing of SNMP sets is not possible because of
RowStatus (or so I think).

Again, if you think about the deletion of a row, this makes sense.   You
don't want to delete only parts of a row, otherwise, the MIB tables would
end up with a partial rows that were not very helpful.  The entire row is
deleted.  It doesn't matter that the some of the objects in the row are
defined in MIB-A and some 
of the objects are defined in Draft-ietf-mpls-te-tp-mib.   The entire row is
deleted and there is one managed entity responsible for that.   

Thanks,
  -Joan

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Sunday, February 16, 2014 1:03 PM
To: 'Romascanu, Dan (Dan)'; 'Joan Cucchiara'; 't.petch'; 'Benoit Claise';
[email-masked]

A

defaulting,
read-
read-
are
> > > created by RowStatus (which is read-create).   Like it or not,
RowStatus
of
of
> > > t.petch

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

---

From: Andy Bierman <[email-masked]>
Date: Sun, 16 Feb 2014 18:06:18 -0800

Hi,

I guess I am confused as well, although I don't claim to know the details
;-)

Looking at RFC 3812, there are 2 conformance statements:

    mplsTeModuleFullCompliance
    mplsTeModuleReadOnlyCompliance

If an agent supports the "ReadOnly" MODULE-COMPLIANCE, then the RowStatus

object is implemented read-only, hard-wired to active (i.e., the agent
just populates

the read-only table with the entries via some external configuration).

         OBJECT      mplsTunnelRowStatus
         SYNTAX      RowStatus { active(1) }
         MIN-ACCESS  read-only
         DESCRIPTION "Write access is not required."

Why can't new objects added to the row also allow the server to only claim
conformance to the read-only MODULE-COMPLIANCE?  I don't see the
connection between RowStatus and a developer selecting which
compliance level it will support in an implementation.

It does not matter if the new objects are read-only or read-create.
A "read-only" agent will magically instantiate the new columns,
if it supports the extension. A "read-create" agent will allow
a manager to create new rows, and allow the new r/c columns if
it supports the extension.

Andy

On Sun, Feb 16, 2014 at 4:11 PM, Joan Cucchiara
<[email-masked]>wrote:

> writeable

---

From: "Joan Cucchiara" <[email-masked]>
Date: Mon, 17 Feb 2014 10:09:40 -0500

Hi Andy,

The discussion is wrt FullCompliance only, sorry if that wasn't clear.    

Even so, if RowStatus is defined as FullCompliance, doesn't that hold for
new extended table objects which are under the control of RowStatus with
FullCompliance?

Managed entity still needs to support the RowStatus  as defined originally.
Plus, I would think the "correct" Compliance for the draft should include
the 

support of Full Compliance for RowStatus of the relevant tables from TE MIB
and LSR MIB (i.e. the relevant tables meaning those which are extended in
the draft).

(Probably more info that you want to know but.)

Additionally, the TE and LSR MIBs have other MIBs (rfcs) in GMPLS and PWE
which also extend tables from LSR MIB/TE MIB.   So, for 10  years these MIBs
have been

around, and there is a lot of legacy even in other WGs.    

I agree that there needs to be some discussion and thought around migration
of MPLS management to NetConf for configuration.   The issue (as I see it)
is that

the LSR MIB contains a LIB (LSR table) and the TE MIB contains a Tunnel
Table and these have been extended/Augmented in various MIBs and in various
WGs for 10 years.

Either the WGs can keep going with MIBs, or rewrite in NetConf.   To me,
seems like everyone is focused on this draft, but not really focused on how
best to help MPLS migrate.   (Not sure the WG even wants to migrate, so may
have misspoken..)   Anyway, no matter what the decision is on the draft,
that is still not going to help

MPLS when new features are defined and folks still want to use the LIB and
Tunnel Tables in rfc3813 and rfc3812.

Thanks,

  -Joan

From: Andy Bierman [mailto:[email-masked]] 
Sent: Sunday, February 16, 2014 9:06 PM
To: Joan Cucchiara
Cc: Adrian Farrel; t.petch; Benoit Claise; MIB Doctors (E-mail)
Subject: Re: [MIB-DOCTORS] configuration: writable MIB modules versus
NETCONF/YANGmodules

Hi,

object is implemented read-only, hard-wired to active (i.e., the agent just
populates
the read-only table with the entries via some external configuration).

 

Andy

 

On Sun, Feb 16, 2014 at 4:11 PM, Joan Cucchiara <[email-masked]>
wrote:

Hi Adrian,

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Friday, February 14, 2014 2:19 PM
To: 'Joan Cucchiara'; 't.petch'; 'Benoit Claise'; [email-masked]
Subject: RE: configuration: writable MIB modules versus NETCONF/YANGmodules

Hi Joan,

What am I missing?

Thanks,
  -Joan

Thanks,
Adrian

read-only.
purposes.
plane to set things up.

-----

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

  _____  

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 17 Feb 2014 08:04:41 -0800

> new extended table objects which are under the control of RowStatus with

I think the OBJECT-TYPE and MODULE-COMPLIANCE macros are somewhat
independent.
You write the OBJECT-TYPE macros for full conformance, and the "ReadOnly"
MODULE-COMPLAINCE
changes the requirement for RowStatus from read-create to read-only.

The full compliance compliance macro should not add MIN-ACCESS clauses.

> Managed entity still needs to support the RowStatus  as defined
> originally.   Plus, I would think the "correct" Compliance for the draft
> should include the
>
> support of Full Compliance for RowStatus of the relevant tables from TE
> MIB and LSR MIB (i.e. the relevant tables meaning those which are extended
> in the draft).
>
>
>
> (Probably more info that you want to know but...)
>
> which also extend tables from LSR MIB/TE MIB.   So, for 10  years these
> MIBs have been
>
> I agree that there needs to be some discussion and thought around
> migration of MPLS management to NetConf for configuration.   The issue (as
> I see it) is that
>
> have misspoken....)   Anyway, no matter what the decision is on the draft,

After 10 years, any implementations of full read-create conformance?
If not, why bother publishing any new read-create objects at all?
Academic completeness?

I am not sure changing to NETCONF would help at this point.
CM is very intrusive to implement, unlike monitoring.  One can
add agent monitoring instrumentation on top of pre-existing instrumentation
anytime.  Adding new CM instrumentation on top of pre-existing CLI
can be complicated ( == expensive), especially if the data models are not
well aligned.

Thanks,

Andy

>
>
> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* Sunday, February 16, 2014 9:06 PM
> *To:* Joan Cucchiara
> *Cc:* Adrian Farrel; t.petch; Benoit Claise; MIB Doctors (E-mail)
> *Subject:* Re: [MIB-DOCTORS] configuration: writable MIB modules versus
> NETCONF/YANGmodules
>
>
>
> Hi,
>
>
>
> object is implemented read-only, hard-wired to active (i.e., the agent just populates
>
> ------------------------------
>

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 18 Feb 2014 09:11:52 -0500

I am not sure as you cannot create rows in the new MIB module (call it B); they're created in the existing one (call it A) and as a side-effect objects are created in B, which is normal agent behavior in an "all writable" situation today.  We should point out that this occurs in both cases of AUGMENTSs and "extends" rows.  I do not see any issue with this as the behavior is as expected:

	So if I "row create new row in A" -> the system creates an entry in A, and row is created in B that corresponds. When you query A or B, you get responses.  Row destruction happens consistently too since you cannot issue row destruction instructions to B, but only to A, and corresponding entries in B are removed.  Of course, if I try a row create on B it fails. 

	The other way to look at this is that this is the same situation as if we had the ability to configure A as read-write/create and B as read-only (where B contained read-write/create entries).  The exact same behavior should result.

	--tom

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 18 Feb 2014 09:15:08 -0500

> JEC> with them configuring via SNMP for other objects also (but that is just

	But why is that an issue?  This is how things work today.  If I create a row
in say the mplsTunnelTable, I get a tunnel. The agent internally signals the tunnel
and assigns an ingress FEC label mapping. I can then examine the LSR MIB's inSegmentTable
and find an entry there without having manually created one.  I can however, go and manually 
create entries and wire them back to the tunnelEntry too. 

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 18 Feb 2014 09:18:30 -0500

> The Row is an concept unto itself, and this row is impacted by SNMP sets to

	Yes, conceptually that is how I view things too.  But the reality is that
when you create a row in a table (i.e.: CreateAndGo) the agent will "create"
entries in extended or AUGMENTS tables for you using default values if they are
not specified in the request. To me, this is the same situation except that the
extended/AUGMENTS-ed MIB has %100 defaults. 

> deleted and there is one managed entity responsible for that.   

	I agree; its the same as I said above except in reverse. You delete from the
main table and the others are deleted as part of the same operation.  In
the case of AUGMENTS that is explicit, and in the case of extends, you have no
referring root indexes, so look-ups in the second table should fail anyways.

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 18 Feb 2014 09:21:23 -0500

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

> Hi,
> 
> I guess I am confused as well, although I don't claim to know the details ;-)
> 

	Precisely - this is what I said earlier in the thread.  Your last paragraph
hits the nail on the head.

	--Tom

> 
> 
> Andy
> 
> 
> 
> 
> On Sun, Feb 16, 2014 at 4:11 PM, Joan Cucchiara <[email-masked]> wrote:
> Hi Adrian,
>

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 18 Feb 2014 09:28:09 -0500

On Feb 17, 2014:10:09 AM, at 10:09 AM, Joan Cucchiara <[email-masked]> wrote:

> Hi Andy,
>  
> The discussion is wrt FullCompliance only, sorry if that wasn’t clear.    
>  
> Even so, if RowStatus is defined as FullCompliance, doesn’t that hold for new extended table objects which are under the control of RowStatus with FullCompliance?
>  
> Managed entity still needs to support the RowStatus  as defined originally.   Plus, I would think the “correct” Compliance for the draft should include the
> support of Full Compliance for RowStatus of the relevant tables from TE MIB and LSR MIB (i.e. the relevant tables meaning those which are extended in the draft).
> 

	I would think it would be ok to support any one of the compliance statements, whether full or one of the subsets.  I have never heard of any rules implicit or explicit, requiring conformance to the full compliance per se, but I might have missed something in the nuance of MIB creation. *)

> (Probably more info that you want to know but…)
> Additionally, the TE and LSR MIBs have other MIBs (rfcs) in GMPLS and PWE which also extend tables from LSR MIB/TE MIB.   So, for 10  years these MIBs have been
> I agree that there needs to be some discussion and thought around migration of MPLS management to NetConf for configuration.   The issue (as I see it) is that
> the LSR MIB contains a LIB (LSR table) and the TE MIB contains a Tunnel Table and these have been extended/Augmented in various MIBs and in various WGs for 10 years.
>  
> Either the WGs can keep going with MIBs, or rewrite in NetConf.   To me, seems like everyone is focused on this draft, but not really focused on how best to help MPLS migrate.   (Not sure the WG even wants to migrate, so may have misspoken….)   Anyway, no matter what the decision is on the draft, that is still not going to help
> MPLS when new features are defined and folks still want to use the LIB and Tunnel Tables in rfc3813 and rfc3812.

	It is worth discussing further, because as you say, there are a pile of MIBs for MPLS and derivative technologies.  However, I do not think configuration is really a big issue with those as there are scantly few read-write implementations that ever existed (and may not exist any further). Before we embark on any significant work here, we should poll the community to see if anyone cares (and if they do are will to help!). *) 

	--Tom

> Subject: Re: [MIB-DOCTORS] configuration: writable MIB modules versus NETCONF/YANGmodules
>  
> Hi,
>

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 18 Feb 2014 09:59:57 -0500

Hi,

Inline below, prefaced with JEC.

From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Tuesday, February 18, 2014 9:28 AM
To: Cucchiara Joan
Cc: Andy Bierman; Farrel Adrian; t.petch; MIB Doctors (E-mail)
Subject: Re: [MIB-DOCTORS] configuration: writable MIB modules versus
NETCONF/YANGmodules

On Feb 17, 2014:10:09 AM, at 10:09 AM, Joan Cucchiara
<[email-masked]> wrote:

Hi Andy,

 

            I would think it would be ok to support any one of the
compliance statements, whether full or one of the subsets.  I have never
heard of any rules implicit or explicit, requiring conformance to the full
compliance per se, but I might have missed something in the nuance of MIB
creation. *)

JEC:  Tom, I agree.   The issue as Dan so eloquently stated is that the
managed entity is responsible for RowStatus and if that was implemented via
SNMP Set, that

Software still is supported on the managed entity.   (I was just trying to
put out, that getting rid of read-create/read-write is not necessarily
getting rid of SNMP sets on the managed entity for these sets of MPLS MIBs.

            It is worth discussing further, because as you say, there are a
pile of MIBs for MPLS and derivative technologies.  However, I do not think
configuration is really a big issue with those as there are scantly few
read-write implementations that ever existed (and may not exist any
further). Before we embark on any significant work here, we should poll the
community to see if anyone cares (and if they do are will to help!). *) 

JEC:   I think a decent analogy is to say, that the Label Switching Table
(LIB) in the LSR MIB is to MPLS as the IP Routing Table is to IP (certainly
NOT the same scale).    The Tunnel Table in the TE MIB is added to for most
new tunnel types/features.   After 10 years of tacking on to these tables in
3 different WGs, and learning quite a bit in the process, I do think at a
minimum defining these in NetConf (or even redo them in SNMP if
monitoring-only (?)) maybe something to consider, or at least, discuss a
timeframe for.    I suppose that adding on to the same tables can continue
too, but that is getting more and more cumbersome.

Thanks,

-Joan 

            --Tom

Thanks,

  -Joan

From: Andy Bierman [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Sunday, February 16, 2014 9:06 PM
To: Joan Cucchiara
Cc: Adrian Farrel; t.petch; Benoit Claise; MIB Doctors (E-mail)
Subject: Re: [MIB-DOCTORS] configuration: writable MIB modules versus
NETCONF/YANGmodules

Hi,

 

Andy

 

On Sun, Feb 16, 2014 at 4:11 PM, Joan Cucchiara <
<mailto:[email-masked]> [email-masked]> wrote:

Hi Adrian,

-----Original Message-----
From: Adrian Farrel [mailto: <mailto:[email-masked]>
[email-masked]]
Sent: Friday, February 14, 2014 2:19 PM
To: 'Joan Cucchiara'; 't.petch'; 'Benoit Claise';
<mailto:[email-masked]> [email-masked]
Subject: RE: configuration: writable MIB modules versus NETCONF/YANGmodules

Hi Joan,

What am I missing?

Thanks,
  -Joan

Thanks,
Adrian

> From: OPS-AREA [mailto: <mailto:[email-masked]>
[email-masked]] On Behalf Of Joan
> To: 't.petch'; 'Benoit Claise';  <mailto:[email-masked]>
[email-masked]
read-only.
> From: OPS-AREA [mailto: <mailto:[email-masked]>
[email-masked]] On Behalf Of t.petch
> To: Benoit Claise;  <mailto:[email-masked]> [email-masked]
> From: "Benoit Claise" < <mailto:[email-masked]> [email-masked]>
> To: < <mailto:[email-masked]> [email-masked]>
purposes.
plane to set things up.
>  <mailto:[email-masked]> [email-masked]
>  <https://www.ietf.org/mailman/listinfo/ops-area>
> Checked by AVG -  <http://www.avg.com/> www.avg.com
>  <mailto:[email-masked]> [email-masked]
>  <https://www.ietf.org/mailman/listinfo/ops-area>

-----
No virus found in this message.
Checked by AVG -  <http://www.avg.com/> www.avg.com
Version: 2014.0.4259 / Virus Database: 3705/7092 - Release Date: 02/14/14

_______________________________________________
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

No virus found in this message.
Checked by AVG -  <http://www.avg.com/> www.avg.com
Version: 2014.0.4259 / Virus Database: 3705/7098 - Release Date: 02/16/14

  _____  

No virus found in this message.
Checked by AVG -  <http://www.avg.com/> www.avg.com
Version: 2014.0.4259 / Virus Database: 3697/7083 - Release Date: 02/11/14

_______________________________________________
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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 18 Feb 2014 15:02:43 +0000

Tom,

There is only one table. There is only one conceptual MIB. Objects in the table happen to be defined in two MIB modules (you call them A and B) - but the operations with rows apply to all objects.

If you wanted to define two separate tables you would have defined them separately using the same indexation, not use the AUGMENT construct. 

This is at least my understanding. 

Regards,

Dan

> Sent: Tuesday, February 18, 2014 4:12 PM
> To: Romascanu, Dan (Dan)
> Cc: Farrel Adrian; Cucchiara Joan; t.petch; Benoit Claise; [email-masked]
> 	I am not sure as you cannot create rows in the new MIB module (call
> it B); they're created in the existing one (call it A) and as a side-effect objects
> are created in B, which is normal agent behavior in an "all writable" situation
> today.  We should point out that this occurs in both cases of AUGMENTSs and
> "extends" rows.  I do not see any issue with this as the behavior is as
> expected:
> 
> 	So if I "row create new row in A" -> the system creates an entry in A,
> and row is created in B that corresponds. When you query A or B, you get
> responses.  Row destruction happens consistently too since you cannot issue
> row destruction instructions to B, but only to A, and corresponding entries in
> B are removed.  Of course, if I try a row create on B it fails.
> 
> 	The other way to look at this is that this is the same situation as if we
> had the ability to configure A as read-write/create and B as read-only (where
> B contained read-write/create entries).  The exact same behavior should
> result.
> 
> 	--tom
> 
> 
> 
> 
> > By using the already existing RowStatus object in the base table the
> creation of new rows in the base table leads to the creation of new rows in
> the extended table. Even if the objects that you defined are all read-only,
> the effect is the same as defining a new table with a RowStatus object.
> >
> > Dan
> >
> >
> >> To: Romascanu, Dan (Dan); 'Joan Cucchiara'; 't.petch'; 'Benoit
> >> Claise'; mib- [email-masked]
> >> read- create.
> >>> Subject: RE: [MIB-DOCTORS] configuration: writable MIB modules
> >>>>>> the conclusion that it's now time to set the direction for future
> >>>>>> MIB developments within the IETF. Basically, let's not specify
> >>>>>> read-write MIB modules unless we have a good reason.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 18 Feb 2014 07:15:54 -0800

On Tue, Feb 18, 2014 at 7:02 AM, Romascanu, Dan (Dan) <[email-masked]>wrote:

> Tom,
>
> There is only one table. There is only one conceptual MIB. Objects in the
> table happen to be defined in two MIB modules (you call them A and B) - but
> the operations with rows apply to all objects.
>
> If you wanted to define two separate tables you would have defined them
> separately using the same indexation, not use the AUGMENT construct.
>

OK -- you seem to be saying "If the agent supports read-create compliance
for the A columns, then it must support read-create for the new B columns".
Yes -- there is only 1 conceptual row and 1 RowStatus.  But an agent can
choose to implement the read-only compliance, so there is no real
requirement to support read-create for the B columns.  Making them read-only
instead of read-create is not necessary.

Regards,

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 18 Feb 2014 15:31:11 +0000

Sure - the agent can chose to implement the read-only compliance. But this is different from full compliance.

Regards,

Dan

From: Andy Bierman [mailto:[email-masked]]
Sent: Tuesday, February 18, 2014 5:16 PM
To: Romascanu, Dan (Dan)
Cc: Thomas Nadeau; Farrel Adrian; t.petch; [email-masked]
Subject: Re: [MIB-DOCTORS] configuration: writable MIB modules versus NETCONF/YANGmodules

On Tue, Feb 18, 2014 at 7:02 AM, Romascanu, Dan (Dan) <[email-masked]<mailto:[email-masked]>> wrote:
Tom,

Regards,

Dan

Andy

> From: Thomas Nadeau [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Farrel Adrian; Cucchiara Joan; t.petch; Benoit Claise; [email-masked]<mailto:[email-masked]>
> On Feb 16, 2014:2:45 PM, at 2:45 PM, Romascanu, Dan (Dan)
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> >> From: Adrian Farrel [mailto:[email-masked]<mailto:[email-masked]>]
> >> Claise'; mib- [email-masked]<mailto:[email-masked]>
> >>> From: Romascanu, Dan (Dan) [mailto:[email-masked]<mailto:[email-masked]>]
> >>> To: [email-masked]<mailto:[email-masked]>; 'Joan Cucchiara'; 't.petch'; 'Benoit
> >>> Claise';
> >>> mib- [email-masked]<mailto:[email-masked]>
> >>>> From: MIB-DOCTORS [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> >> Of
> >>>> Adrian Farrel
> >>>> [email-masked]<mailto:[email-masked]>
> >>>>> From: OPS-AREA [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> >>>>> Joan Cucchiara
> >>>>> To: 't.petch'; 'Benoit Claise'; [email-masked]<mailto:[email-masked]>
> >>>>> From: OPS-AREA [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> >>>>> t.petch
> >>>>> To: Benoit Claise; [email-masked]<mailto:[email-masked]>
> >>>>> From: "Benoit Claise" <[email-masked]<mailto:[email-masked]>>
> >>>>> To: <[email-masked]<mailto:[email-masked]>>
> >>>>> [email-masked]<mailto:[email-masked]>
> >>>>> Checked by AVG - www.avg.com<http://www.avg.com>
> >>>>> [email-masked]<mailto:[email-masked]>
> >>>> [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mib-doctors