Subject: [MIB-DOCTORS] FW: DISCUSS: draft-ietf-mext-nemo-mib

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 29 Jan 2009 10:41:11 +0100

I believe that this DISCUSS from Chris Newman deserves the attention of
the MIB-Doctors. 

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chris Newman
Sent: Thursday, January 29, 2009 8:55 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: DISCUSS: draft-ietf-mext-nemo-mib 

Discuss:
The DateAndTime textual convention for SNMPv2 does not require the use
of an interoperable format that includes a timezone offset.  Some uses
of the DateAndTime textual convention remedy this problem with specific
language. For example, RFC 2591 states the following when using the
DateAndTime textual convention:

        DESCRIPTION
            "... An implementation MUST return all 11 bytes
             of the DateAndTime textual-convention so that a manager
             may retrieve the offset from GMT time."

Would such text be appropriate for this usage?  Or is this usage a case
where an up-to-25 hour skew between client and server interpretation of
the time will not be a problem?

I'll clear my discuss if such text is added or if the authors assert the
25-hour skew is not a problem for this usage.

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

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Thu, 29 Jan 2009 14:16:21 +0100

Well, if that is what we want, then we shoudl ALSO use a SIZE(11). which is also
what RFC2591 does, namely:
    schedLocalTime OBJECT-TYPE
        SYNTAX      DateAndTime (SIZE (11))
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The local time used by the scheduler. Schedules which
             refer to calendar time will use the local time indicated
             by this object. An implementation MUST return all 11 bytes
             of the DateAndTime textual-convention so that a manager
             may retrieve the offset from GMT time."
        ::= { schedObjects 1 }

The NEMO-MIB authors/WG should chime in. 
It seems to me though that the time they are recording in 
        nemoHaBCEntryCreationTime      DateAndTime,
        nemoHaBUAcceptedTime           DateAndTime,
        nemoHaBURejectionTime          DateAndTime,
are all local times on the same HomeAgent system. If that is indeed the case,
then I would think that a time without timezone info is OK. But this is just
my personal opinion. 
If those HA systems however can easily provide the timezone info, then
of course it does not hurt to do so, and so then one could
still consider it better to indeed provide it and make it a MUST (for
consistency and interoperability).

Just my thoughts

Bert
  ----- Original Message ----- 
  From: Romascanu, Dan (Dan) 
  To: MIB Doctors (E-mail) 
  Sent: Thursday, January 29, 2009 10:41 AM
  Subject: [MIB-DOCTORS] FW: DISCUSS: draft-ietf-mext-nemo-mib

  Dan

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]] On Behalf Of
  Chris Newman
  Sent: Thursday, January 29, 2009 8:55 AM
  To: [email-masked]
  Cc: [email-masked]; [email-masked]
  Subject: DISCUSS: draft-ietf-mext-nemo-mib 

  Discuss:

          DESCRIPTION

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 29 Jan 2009 12:18:27 -0500

Hi,
 
I have not looked closely at this MIB module, or what it is trying to
model, but ...
If an NMS is going to work with multiple devices, possibly in
different time zones, it would be good to have the times reported with
the timezone included so the NMS doesn't need to use other mechanisms
to determine timezone offsets for the device. 
 
The OPS area often discusses the need to make it easier to manage a
network rather than just individual devices; including the timezone in
the objects would make it easier to understand the network time
relationships of the devices. The DESCRIPTION clause leads me to
believe this is related to scheduling, and if the scheduling occurs
across multiple devices in different timezones, then the
time-zone-influenced times for synchronized scheduling could be very
important.
 
I support requiring the timezone information.
 
David Harrington
[email-masked]
[email-masked]
[email-masked]

  _____  

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bert Wijnen (IETF)
Sent: Thursday, January 29, 2009 8:16 AM
To: Romascanu, Dan (Dan); MIB Doctors (E-mail)
Subject: Re: [MIB-DOCTORS] FW: DISCUSS: draft-ietf-mext-nemo-mib

Well, if that is what we want, then we shoudl ALSO use a SIZE(11).
which is also
what RFC2591 does, namely:
    schedLocalTime OBJECT-TYPE
        SYNTAX      DateAndTime (SIZE (11))
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The local time used by the scheduler. Schedules which
             refer to calendar time will use the local time indicated
             by this object. An implementation MUST return all 11
bytes
             of the DateAndTime textual-convention so that a manager
             may retrieve the offset from GMT time."
        ::= { schedObjects 1 }
 
are all local times on the same HomeAgent system. If that is indeed
the case,
then I would think that a time without timezone info is OK. But this
is just
 
Just my thoughts
 
Bert

----- Original Message ----- 
From: Romascanu, Dan  <mailto:[email-masked]> (Dan) 
To: MIB Doctors (E-mail) <mailto:[email-masked]>  
Sent: Thursday, January 29, 2009 10:41 AM
Subject: [MIB-DOCTORS] FW: DISCUSS: draft-ietf-mext-nemo-mib

I believe that this DISCUSS from Chris Newman deserves the attention
of
the MIB-Doctors. 

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of
Chris Newman
Sent: Thursday, January 29, 2009 8:55 AM
To: [email-masked]
Cc: [email-masked];
[email-masked]
Subject: DISCUSS: draft-ietf-mext-nemo-mib 

Discuss:
of the DateAndTime textual convention remedy this problem with
specific

        DESCRIPTION

Would such text be appropriate for this usage?  Or is this usage a
case
where an up-to-25 hour skew between client and server interpretation
of
the time will not be a problem?

I'll clear my discuss if such text is added or if the authors assert
the
25-hour skew is not a problem for this usage.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 29 Jan 2009 18:20:36 +0100

This seemed to be also the direction preferred by the IESG in the
telechat discussion today. 
 
Thanks to Bert and David for looking into this. 
 
Dan

________________________________

	From: David B Harrington [mailto:[email-masked]] 
	Sent: Thursday, January 29, 2009 7:18 PM
	To: 'Bert Wijnen (IETF)'; Romascanu, Dan (Dan); 'MIB Doctors
(E-mail)'
	Subject: RE: [MIB-DOCTORS] FW: DISCUSS: draft-ietf-mext-nemo-mib

	Hi,
	 
	I have not looked closely at this MIB module, or what it is
trying to model, but ...
	If an NMS is going to work with multiple devices, possibly in
different time zones, it would be good to have the times reported with
the timezone included so the NMS doesn't need to use other mechanisms to
determine timezone offsets for the device. 
	 
	The OPS area often discusses the need to make it easier to
manage a network rather than just individual devices; including the
timezone in the objects would make it easier to understand the network
time relationships of the devices. The DESCRIPTION clause leads me to
believe this is related to scheduling, and if the scheduling occurs
across multiple devices in different timezones, then the
time-zone-influenced times for synchronized scheduling could be very
important.

	David Harrington
	[email-masked]
	[email-masked]
	[email-masked]

________________________________

		Subject: Re: [MIB-DOCTORS] FW: DISCUSS:
draft-ietf-mext-nemo-mib

		Well, if that is what we want, then we shoudl ALSO use a
SIZE(11). which is also
		what RFC2591 does, namely:
		    schedLocalTime OBJECT-TYPE
		        SYNTAX      DateAndTime (SIZE (11))
		        MAX-ACCESS  read-only
		        STATUS      current
		        DESCRIPTION
		            "The local time used by the scheduler.
Schedules which
		             refer to calendar time will use the local
time indicated
		             by this object. An implementation MUST
return all 11 bytes
		             of the DateAndTime textual-convention so
that a manager
		             may retrieve the offset from GMT time."
		        ::= { schedObjects 1 }
		 
		The NEMO-MIB authors/WG should chime in. 
		It seems to me though that the time they are recording
in 
		        nemoHaBCEntryCreationTime      DateAndTime,
		        nemoHaBUAcceptedTime           DateAndTime,
		        nemoHaBURejectionTime          DateAndTime,
		are all local times on the same HomeAgent system. If
that is indeed the case,
		then I would think that a time without timezone info is
OK. But this is just
		my personal opinion. 
		If those HA systems however can easily provide the
timezone info, then
		of course it does not hurt to do so, and so then one
could
		still consider it better to indeed provide it and make
it a MUST (for
		consistency and interoperability).
		 
		Just my thoughts
		 
		Bert

			----- Original Message ----- 
			From: Romascanu, Dan (Dan)
<mailto:[email-masked]>  
			To: MIB Doctors (E-mail)
<mailto:[email-masked]>  
			Sent: Thursday, January 29, 2009 10:41 AM
			Subject: [MIB-DOCTORS] FW: DISCUSS:
draft-ietf-mext-nemo-mib

			I believe that this DISCUSS from Chris Newman
deserves the attention of
			the MIB-Doctors. 
			
			Dan

			-----Original Message-----
			From: [email-masked]
[mailto:[email-masked]] On Behalf Of
			Chris Newman
			Sent: Thursday, January 29, 2009 8:55 AM
			To: [email-masked]
			Cc: [email-masked];
[email-masked]
			Subject: DISCUSS: draft-ietf-mext-nemo-mib 
			
			Discuss:
			The DateAndTime textual convention for SNMPv2
does not require the use
			of an interoperable format that includes a
timezone offset.  Some uses
			of the DateAndTime textual convention remedy
this problem with specific
			language. For example, RFC 2591 states the
following when using the
			DateAndTime textual convention:
			
			        DESCRIPTION
			            "... An implementation MUST return
all 11 bytes
			             of the DateAndTime
textual-convention so that a manager
			             may retrieve the offset from GMT
time."
			
			Would such text be appropriate for this usage?
Or is this usage a case
			where an up-to-25 hour skew between client and
server interpretation of
			the time will not be a problem?
			
			I'll clear my discuss if such text is added or
if the authors assert the
			25-hour skew is not a problem for this usage.