Subject: Re: [MIB-DOCTORS] MIB question

From: "David Harrington" <[email-masked]>
Date: Sat, 21 Nov 2009 09:48:59 -0500

Hi David,

The rules for SMI changes are in RFC2578, and if this TC is an
enumeration or BITS type, then section 9 (2) seems to cover the case.
My impression is that deprecating one value from the TC enumeration
could be done by changing the description clause to say that the
particular enumeration is deprecated; I think the description of what
it means should still be there in case anybody anywhere implemented
that case (or implements it in the future) so the NMS can interpret
the received value, and the enumeration value doesn't get reused for a
different mode.

If they SHOULD NOT be implemented, and you are pretty sure that nobody
has, then you might want to go straight to "obsolete" for the mode 2
objects (and keep the object definitions in the new revision marked as
obsolete), while deprecating the enumeration value (in case the NMS
needs to interpret a mode 2 value sent from an implementation of the
original MIB definition). 

I have copied the MIB Doctors to make sure others agree.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, November 20, 2009 8:33 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: MIB question
> 
> David,
> 
> I'm working with an author on a revision of a MIB for
> the storm WG and have a question.
> 
> The protocol involved has two operating modes, let's call
> them mode 1 and mode 2.  Mode 2 was never implemented and
> will be deprecated by a separate I-D that explains why it
> SHOULD NOT be implemented or used, so the MIB update needs
> to deprecate management support for mode 2.
> 
> I have a MIB style question about how to do this.  The
> MIB contains a TC for the mode that takes on the values
> 1 and 2 and an object whose syntax is the TC.
> 
> Abstractly, there seem to be two possible approaches:
> 	- Deprecate the TC and the object.  Assume that
> 		the SNMP manager knows what the only mode is.
> 	- Deprecate just the value 2 in the TC (hence the
> 		object), so that the object always has the
> 		value 1 in new implementations.
> Which one is the "right" way to do this?  Also, if it's
> the latter, how does one go about deprecating a value
> in a TC and object?
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Sat, 21 Nov 2009 16:48:32 +0100

I think that this is correct.

One migth want to deprecate/obsolete the MODULE-COMPLAINCE as well, and then create a new one that
show that only mode 1 for that specirfic compiance is valid. Quite a bit more work though.

Bert

  ----- Original Message ----- 
  From: David Harrington 
  To: [email-masked] 
  Sent: Saturday, November 21, 2009 3:48 PM
  Subject: Re: [MIB-DOCTORS] MIB question

  Hi David,

  dbh

  > the latter, how does one go about deprecating a value

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

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

  Geen virus gevonden in het binnenkomende-bericht.
  Gecontroleerd door AVG - www.avg.com 
  Versie: 9.0.707 / Virusdatabase: 270.14.75/2516 - datum van uitgifte: 11/20/09 20:43:00

---

From: "David Harrington" <[email-masked]>
Date: Sat, 21 Nov 2009 11:55:56 -0500

Hi,
 
Good point.
more work, but not doing so means the only compliance level requires
support for obsoleted objects, right?
So it really needs to be done for the updated module.
 
dbh

  _____  

From: Bert Wijnen (IETF) [mailto:[email-masked]] 
Sent: Saturday, November 21, 2009 10:49 AM
To: David Harrington; [email-masked]
Cc: MIB Doctors (E-mail)
Subject: Re: [MIB-DOCTORS] MIB question

One migth want to deprecate/obsolete the MODULE-COMPLAINCE as well,
and then create a new one that
show that only mode 1 for that specirfic compiance is valid. Quite a
bit more work though.
 
Bert

----- Original Message ----- 
From: David  <mailto:[email-masked]> Harrington 
To: [email-masked] 
Sent: Saturday, November 21, 2009 3:48 PM
Subject: Re: [MIB-DOCTORS] MIB question

Hi David,

dbh

  _____  

Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com 
Versie: 9.0.707 / Virusdatabase: 270.14.75/2516 - datum van uitgifte:
11/20/09 20:43:00

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 23 Nov 2009 11:28:40 +0100

I also think that the updated module must include a new
MODULE-COMPLIANCE as well. 
 
Dan

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of David Harrington
	Sent: Saturday, November 21, 2009 6:56 PM
	To: 'Bert Wijnen (IETF)'; [email-masked]
	Cc: 'MIB Doctors (E-mail)'
	Subject: Re: [MIB-DOCTORS] MIB question

	Hi,
	 
	Good point.
	more work, but not doing so means the only compliance level
requires support for obsoleted objects, right?
	So it really needs to be done for the updated module.
	 
	dbh

________________________________

		 
		One migth want to deprecate/obsolete the
MODULE-COMPLAINCE as well, and then create a new one that
		show that only mode 1 for that specirfic compiance is
valid. Quite a bit more work though.
		 
		Bert

			----- Original Message ----- 
			From: David Harrington
<mailto:[email-masked]>  
			To: [email-masked] 
			Sent: Saturday, November 21, 2009 3:48 PM
			Subject: Re: [MIB-DOCTORS] MIB question

			Hi David,
			
			The rules for SMI changes are in RFC2578, and if
this TC is an
			enumeration or BITS type, then section 9 (2)
seems to cover the case.
			My impression is that deprecating one value from
the TC enumeration
			could be done by changing the description clause
to say that the
			particular enumeration is deprecated; I think
the description of what
			it means should still be there in case anybody
anywhere implemented
			that case (or implements it in the future) so
the NMS can interpret
			the received value, and the enumeration value
doesn't get reused for a
			different mode.
			
			If they SHOULD NOT be implemented, and you are
pretty sure that nobody
			has, then you might want to go straight to
"obsolete" for the mode 2
			objects (and keep the object definitions in the
new revision marked as
			obsolete), while deprecating the enumeration
value (in case the NMS
			needs to interpret a mode 2 value sent from an
implementation of the
			original MIB definition). 
			
			I have copied the MIB Doctors to make sure
others agree.
			
			dbh

	

________________________________

			Geen virus gevonden in het
binnenkomende-bericht.
			Gecontroleerd door AVG - www.avg.com 
			Versie: 9.0.707 / Virusdatabase: 270.14.75/2516
- datum van uitgifte: 11/20/09 20:43:00

---

From: <[email-masked]>
Date: Mon, 23 Nov 2009 09:41:13 -0500

Many thanks to all of you.  I just realized that this advice is
applicable to a second non-IETF MIB that I'm also involved with,
so it's doubly valuable.  In case anyone's curious, the IETF MIB
is a forthcoming revision of the iFCP MIB (RFC 4369) and the
second non-IETF MIB is for FCoE.

Thanks,
--David

	From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
	Sent: Monday, November 23, 2009 5:29 AM
	To: David Harrington; Bert Wijnen (IETF); Black, David
	Cc: MIB Doctors (E-mail)
	Subject: RE: [MIB-DOCTORS] MIB question

	Dan

		Hi,
		 
		Good point.
		more work, but not doing so means the only compliance
level requires support for obsoleted objects, right?
		So it really needs to be done for the updated module.
		 
		dbh

			From: Bert Wijnen (IETF)
[mailto:[email-masked]] 
			Sent: Saturday, November 21, 2009 10:49 AM
			To: David Harrington; [email-masked]
			Cc: MIB Doctors (E-mail)
			Subject: Re: [MIB-DOCTORS] MIB question

			One migth want to deprecate/obsolete the
MODULE-COMPLAINCE as well, and then create a new one that
			show that only mode 1 for that specirfic
compiance is valid. Quite a bit more work though.
			 
			Bert

				----- Original Message ----- 
				From: David Harrington
<mailto:[email-masked]>  
				To: [email-masked] 
				Sent: Saturday, November 21, 2009 3:48
PM
				Subject: Re: [MIB-DOCTORS] MIB question

				Hi David,
				
				The rules for SMI changes are in
RFC2578, and if this TC is an
				enumeration or BITS type, then section 9
(2) seems to cover the case.
				My impression is that deprecating one
value from the TC enumeration
				could be done by changing the
description clause to say that the
				particular enumeration is deprecated; I
think the description of what
				it means should still be there in case
anybody anywhere implemented
				that case (or implements it in the
future) so the NMS can interpret
				the received value, and the enumeration
value doesn't get reused for a
				different mode.
				
				If they SHOULD NOT be implemented, and
you are pretty sure that nobody
				has, then you might want to go straight
to "obsolete" for the mode 2
				objects (and keep the object definitions
in the new revision marked as
				obsolete), while deprecating the
enumeration value (in case the NMS
				needs to interpret a mode 2 value sent
from an implementation of the
				original MIB definition). 
				
				I have copied the MIB Doctors to make
sure others agree.
				
				dbh

	

				

				Geen virus gevonden in het
binnenkomende-bericht.
				Gecontroleerd door AVG - www.avg.com 
				Versie: 9.0.707 / Virusdatabase:
270.14.75/2516 - datum van uitgifte: 11/20/09 20:43:00