Subject: [OPSAWG] ENTITY-MIB PhysicalClass extensions

From: Michael Thatcher <[email-masked]>
Date: Fri, 16 Jan 2009 10:59:51 -0800

I would like to add to the enumeration for PhysicalClass to include disk 
& memory.  What needs to happen?

mike thatcher
_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 18 Jan 2009 11:14:37 +0100

This looks like an update to RFC 4133. Such incremental updates are
within the scope of the OPSAWG. Probably the best thing to do is to
write an Internet-Draft and ask  the WG to consider it as part of the
charter. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Thatcher
> Sent: Friday, January 16, 2009 9:00 PM
> To: [email-masked]
> Subject: [OPSAWG] ENTITY-MIB PhysicalClass extensions
> 
> I would like to add to the enumeration for PhysicalClass to 
> include disk & memory.  What needs to happen?
> 
> mike thatcher

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 18 Jan 2009 11:45:18 +0100

> write an Internet-Draft and ask  the WG to consider it as part of the

It seems an appropriate solution would be to move the definition of
PhysicalClass to a separate MIB module and perhaps even make IANA
responsible for maintaining the MIB module (by using a suitable review
process).  Spinning a new revision of RFC 4133 is somewhat heavy to
add an enumeration to PhysicalClass and since this can take some time,
a temporary workaround is the value other(1) and a one column table
augmenting entPhysicalTable where the column provides additional
values.

/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/>
_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 18 Jan 2009 12:26:18 +0100

I agree that making the TC part of separate IANA-administered seems a
better and more flexible solution. We need to revise RFC 4133 for this
purpose, right? 

Dan

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Sunday, January 18, 2009 12:45 PM
> To: Romascanu, Dan (Dan)
> Cc: Michael Thatcher; [email-masked]
> Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions
> 
> It seems an appropriate solution would be to move the 
> definition of PhysicalClass to a separate MIB module and 
> perhaps even make IANA responsible for maintaining the MIB 
> module (by using a suitable review process).  Spinning a new 
> revision of RFC 4133 is somewhat heavy to add an enumeration 
> to PhysicalClass and since this can take some time, a 
> temporary workaround is the value other(1) and a one column 
> table augmenting entPhysicalTable where the column provides 
> additional values.
> 
> /js
> 
> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 18 Jan 2009 13:30:34 +0100

> better and more flexible solution. We need to revise RFC 4133 for this

When Bert Wijnen was AD, we had several meetings discussing simpler
processes for updating MIB modules. I am not sure we ever converged on
a solution that was actually implemented - but Bert might recall
better than I do.

/js

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Mon, 19 Jan 2009 00:26:18 +0100

I don't think we really ever converged.
In any event, if we want to transfer any such thing to IANA, it needs to
go in a separate MIB module (maintained by IANA) and we need to document
what the rules are for IANA to make dditions or changes. That could be a small
separate document which "updates 4133" or it could be a 4133bis with
just that small change.

I know... in theory this should be a very simple task.
In practice we get through all the WG LC, IETF LC, IESG approval, RFC-publication,
IANA picking up the MIB module, Determining who will be technical advisors/experts to IANA.
Oh well... you ge the gist

Bert

  ----- Original Message ----- 
  From: Juergen Schoenwaelder 
  To: Romascanu, Dan (Dan) 
  Cc: [email-masked] 
  Sent: Sunday, January 18, 2009 1:30 PM
  Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions

  /js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 19 Jan 2009 12:13:54 +0100

Unless I am missing something completely I fail to see how we can avoid
revising RFC 4133. The PhysicalClass TC is in the MIB module defined
there, in order to take it out and place it in a MIB module maintained
by IANA we need a new version of the MIB module. Otherwise I agree with
all that Bert says - it's not a technically complicated change but it
has a certain overhead. Also, as a participant, I believe that such a
revision of RFC 4133 is within the charter of OPSAWG and support doing
it here. 
 
Dan

________________________________

	From: Bert Wijnen (IETF) [mailto:[email-masked]] 
	Sent: Monday, January 19, 2009 1:26 AM
	To: [email-masked]; Romascanu, Dan (Dan)
	Cc: [email-masked]
	Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions

	I don't think we really ever converged.
	In any event, if we want to transfer any such thing to IANA, it
needs to
	go in a separate MIB module (maintained by IANA) and we need to
document
	what the rules are for IANA to make dditions or changes. That
could be a small
	separate document which "updates 4133" or it could be a 4133bis
with
	just that small change.
	 
	I know... in theory this should be a very simple task.
	In practice we get through all the WG LC, IETF LC, IESG
approval, RFC-publication,
	IANA picking up the MIB module, Determining who will be
technical advisors/experts to IANA.
	Oh well... you ge the gist
	 
	Bert

		----- Original Message ----- 
		From: Juergen Schoenwaelder
<mailto:[email-masked]>  
		To: Romascanu, Dan (Dan) <mailto:[email-masked]>  
		Cc: [email-masked] 
		Sent: Sunday, January 18, 2009 1:30 PM
		Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass
extensions

		On Sun, Jan 18, 2009 at 12:26:18PM +0100, Romascanu, Dan
		
		> better and more flexible solution. We need to revise
RFC 4133 for this
		
		When Bert Wijnen was AD, we had several meetings
discussing simpler
		processes for updating MIB modules. I am not sure we
ever converged on
		a solution that was actually implemented - but Bert
might recall
		better than I do.
		
		/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/>
		_______________________________________________
		OPSAWG mailing list
		[email-masked]
		https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Mon, 19 Jan 2009 12:51:54 +0100

An Update to RFC4133 would be 
- explain we are adding one enumeration to the TC
- explain we are splitting the TC off into an IANA MIB module
- Add IANA instructions for new assignments
- the 2 MIB modules.

All the other text would no need to be repeated.
It may be easier to just do a 4133bis. 
Depends on how you look at it.

I agree it would fiot in the charter of OPSAWG

Bert
  ----- Original Message ----- 
  From: Romascanu, Dan (Dan) 
  To: Bert Wijnen (IETF) ; [email-masked] 
  Cc: [email-masked] 
  Sent: Monday, January 19, 2009 12:13 PM
  Subject: RE: [OPSAWG] ENTITY-MIB PhysicalClass extensions

  Unless I am missing something completely I fail to see how we can avoid revising RFC 4133. The PhysicalClass TC is in the MIB module defined there, in order to take it out and place it in a MIB module maintained by IANA we need a new version of the MIB module. Otherwise I agree with all that Bert says - it's not a technically complicated change but it has a certain overhead. Also, as a participant, I believe that such a revision of RFC 4133 is within the charter of OPSAWG and support doing it here. 

  Dan

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

    Bert

      ----- Original Message ----- 
      From: Juergen Schoenwaelder 
      To: Romascanu, Dan (Dan) 
      Cc: [email-masked] 
      Sent: Sunday, January 18, 2009 1:30 PM
      Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions

      /js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 19 Jan 2009 12:59:36 +0100

Well, yes, but in RFC 4133 the MIB definition is already more than 50%
of the text, so if you add mandatory boilerplate and other text the
update document may end by being same or almost the same size as the
document itself, plus now we have the complexity of having two documents
to look at. 
 
Anyway, we can let the WG decide what path to take in case they agree to
adopt this as a WG item, of course. 
 
Dan

	From: Bert Wijnen (IETF) [mailto:[email-masked]] 
	Sent: Monday, January 19, 2009 1:52 PM
	To: Romascanu, Dan (Dan); [email-masked]
	Cc: [email-masked]
	Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions

	 
	 
	Bert

		----- Original Message ----- 
		From: Romascanu, Dan (Dan) <mailto:[email-masked]>  
		To: Bert Wijnen (IETF) <mailto:[email-masked]>  ;
[email-masked] 
		Cc: [email-masked] 
		Sent: Monday, January 19, 2009 12:13 PM
		Subject: RE: [OPSAWG] ENTITY-MIB PhysicalClass
extensions

		Unless I am missing something completely I fail to see
how we can avoid revising RFC 4133. The PhysicalClass TC is in the MIB
module defined there, in order to take it out and place it in a MIB
module maintained by IANA we need a new version of the MIB module.
Otherwise I agree with all that Bert says - it's not a technically
complicated change but it has a certain overhead. Also, as a
participant, I believe that such a revision of RFC 4133 is within the
charter of OPSAWG and support doing it here. 
		 
		Dan

			From: Bert Wijnen (IETF)
[mailto:[email-masked]] 
			Sent: Monday, January 19, 2009 1:26 AM
			To: [email-masked];
Romascanu, Dan (Dan)
			Cc: [email-masked]
			Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass
extensions

			I don't think we really ever converged.
			In any event, if we want to transfer any such
thing to IANA, it needs to
			go in a separate MIB module (maintained by IANA)
and we need to document
			what the rules are for IANA to make dditions or
changes. That could be a small
			separate document which "updates 4133" or it
could be a 4133bis with
			just that small change.
			 
			I know... in theory this should be a very simple
task.
			In practice we get through all the WG LC, IETF
LC, IESG approval, RFC-publication,
			IANA picking up the MIB module, Determining who
will be technical advisors/experts to IANA.
			Oh well... you ge the gist
			 
			Bert

				----- Original Message ----- 
				From: Juergen Schoenwaelder
<mailto:[email-masked]>  
				To: Romascanu, Dan (Dan)
<mailto:[email-masked]>  
				Cc: [email-masked] 
				Sent: Sunday, January 18, 2009 1:30 PM
				Subject: Re: [OPSAWG] ENTITY-MIB
PhysicalClass extensions

				On Sun, Jan 18, 2009 at 12:26:18PM
				
				> better and more flexible solution. We
need to revise RFC 4133 for this
				
				When Bert Wijnen was AD, we had several
meetings discussing simpler
				processes for updating MIB modules. I am
not sure we ever converged on
				a solution that was actually implemented
- but Bert might recall
				better than I do.
				
				/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/>