RE: Comments on draft-ietf-hubmib-efm-mib-02.txt

I accept this as well.

My main concern was that there had been no discussion of the
additional complexity involved in having the NMS correlate entries
across devices using sysUpTime. However, to realize the benefits, the
agents would need to keep their clocks synchronized, which puts a
burden on the agents. Following basic SNMP philosphy, if there must be
complexity, it is better to have the manager suffer the complexity
than the agent.

I do agree with Dan's point, however. The MIB modules should be
consistent in how they address the problem.
 
David Harrington
[email protected]
________________________________

	From: [email protected] [mailto:[email protected]]
On Behalf Of Romascanu, Dan (Dan)
	Sent: Thursday, March 03, 2005 9:59 AM
	To: Matt Squire; [email protected]
	Subject: RE: [Hubmib] Comments on
draft-ietf-hubmib-efm-mib-02.txt
	
	
	I can live with this - this was a contributor opinion anyway,
if this was not clear. 
	 

	Regards,

	Dan

		-----Original Message-----
		From: Matt Squire
[mailto:[email protected]]
		Sent: 03 March, 2005 4:51 PM
		To: Romascanu, Dan (Dan); [email protected]
		Subject: RE: [Hubmib] Comments on
draft-ietf-hubmib-efm-mib-02.txt
		
		
		Back in Dec, multiple people weighed in that a
TimeStamp was preferred over a DateAndTime.  Additionally, multiple
people weighed in that they preferred one object over two.  I don't
think anyone weighed in with a preference for using both.  Even the
person that brought it up as a possibility (I think you know him!) had
reservations about using both.  
		 
		So unless I hear that multiple people have preference
for using both objects as time indicators for when events happened,
I'd suggest we use TimeStamp and settle with that.
		 
		- Matt

			-----Original Message-----
			From: Romascanu, Dan (Dan)
[mailto:[email protected]]
			Sent: Thursday, March 03, 2005 9:35 AM
			To: Matt Squire; [email protected]
			Subject: RE: [Hubmib] Comments on
draft-ietf-hubmib-efm-mib-02.txt
			
			
			I would suggest that we reach here a solution
consistent with the EFM Cu MIB. There we decided to keep both a
DateAndTime and a TimeStamp object. If DateAndTime cannot be filled
in, then a all-zeros value will be used. 
			 

			Regards,

			Dan

				-----Original Message-----
				From: Matt Squire
[mailto:[email protected]]
				Sent: 02 March, 2005 8:41 PM
				To: Romascanu, Dan (Dan);
[email protected]
				Subject: RE: [Hubmib] Comments on
draft-ietf-hubmib-efm-mib-02.txt
				
				
				 
				One other technical issue to close out
on (from a completely different thread) was related to whether the log
entries of OAM events should use DateAndTime or TimeStamp objects.
This thread was discussed in December (see archives) and the strong
consensus of the list was that a TimeStamp based on sysUpTime was much
more universal and therefore much better.  So I'm also making the
change to that object to use sysUpTime as a time indicator rather than
DateAndTime. 
				 
				- Matt
				 

					-----Original Message-----
					From: [email protected]
[mailto:[email protected]]On Behalf Of Matt Squire
					Sent: Wednesday, March 02,
2005 2:45 AM
					To: Romascanu, Dan (Dan);
[email protected]
					Subject: RE: [Hubmib] Comments
on draft-ietf-hubmib-efm-mib-02.txt
					
					
					A stab at the technical issues
below.  Thanks again.
					- Matt

	
Technical

					T1. I do not agree with the
assertion made in the Security Consideration section that the
read-write objects defined in this MIB module do not impact the users
traffic, because they are only controls of the OAM protocol. For
example the dot3OamLoopbackCommand object, puts the link on loopback
mode. Even if there is another object that allows for the remote
device to ignore the loopback commands, this does not help if the
loopback command objects are activated in an improper manner. Also, an
object like dot3OamAdminState if set to disabled(1) will cut-off the
OAM functionality of the device, which does have a negative impact on
the network behavior and can be considered as a possible source of
attack. I would suggest that the editor makes another pass through the
read-write objects and explicitly describes all the potential security
hazard resulting from inadequate write operations on these objects.  

					 We can break down the
read-write objects pretty easily.  There are: 

					1) AdminState & Mode.  I tried
to address these variables (without calling them out explicitly) in
the first 2 paragraphs of the security section by saying turning on
OAM doesn't take up a lot of BW but it opens up the possibility of
information access, and should be used in deployments where thats ok.
And that the mode can be used as a variable to control/limit that
access.  

					2) Loopback.  I have a
paragraph on the dangers of loopback already.  

					3) Event configuration.  I
left out these r-w objects because I'm not sure how dangerous they
are. Writes on these objects could result in more .3ah event
notifications, but the frequency is controlled by the OAM protocol, so
I didn't consider that a big threat.  They could also result in SNMP
notifications, but again the frequency is controlled.  Since the
frequency didn't seem a big deal, whats left seems to just be the
threat of the information getting out from the notifications or OAM
events.  But thats controlled by the adminState and mode, and didn't
appear to be any more/less of then the information access generally
available by enabling OAM in a mode that allows that access.  So I
didn't mention it any more than the earlier things.  

					So I should definitely mention
that disabling OAM can interfere with certain management capabilities.
I can walk thru the logic on the event r-w objects if you think they
deserve mentioning.  I'm not sure what to add beyond that.  

					T2. What is the DEFAULT value
of read-write objects like dot3OamAdminState and dot3OamMode? You need
to describe the desired behavior of the agent at initialization before
the first SetRequest command 

					dot3OamAdminState already had
some text on the default state being disabled.  But you're point is
well taken. I made another scan for all read-write objects,and ensured
each had at least a sentence reflecting the default state.  For most
objects, it was fairly easy.  The only one I'm not sure about is the
default dot3OamMode.  Its not clear that a default of passive or
active is universally acceptable. For that object, I'm suggesting the
following text on default value:  

					"       The default value of
dot3OamMode is dependent on the type of
					       system on which this
Ethernet like interface resides.  The
					       default value should be
'active(1)' unless it is known that
					       this system should take
on a subservient role to the other
					       device connected over
this interface.  An example would be a
					       modem or demarcation
device on a customer premise, connected to
					       carrier equipment at a
central office. 

					"

					T3 In the Security section:
'By default, OAM is disabled on Ethernet-likeEthernet like interfaces
and is therefore not a risk.' First there is an editorial problem
(repeated words). Second, there may be a technical issue. As far as I
remember from my participation in the EFM work, there is no
interdiction in the standard to apply OAM to a non-EFM Ethernet
interface. Did this change in the latest part of the work, when my
attendance became rare?   

					OAM can be applied to any
Ethernet interface, EFM or otherwise. Is that what you're asking?