RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt

"Eugene Nechamkin" <[email protected]> Mon, 12 Sep 2005 12:57:12 -0700
Newsgroups gmane.ietf.ipcdn
Message-ID <24CDBA67F085904999751B3C4F9E8C0B031231FB@NT-RMNA-0740.brcm.ad.broadcom.com>
To clarify: I recalled my response to the group as it was not complete at the
moment it was sent accidentaly. Please disregard it if somebody did not
receive the recall notification.
 
Thanks,
 
Eugene.

________________________________

From: Wijnen, Bert (Bert) [mailto:[email protected]] 
Sent: Monday, September 12, 2005 12:53 PM
To: Eugene Nechamkin; Wijnen, Bert (Bert); Jean-Francois Mule; Ipcdn (E-mail)
Cc: Richard Woundy @ Comcast
Subject: RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt


Inline

	-----Original Message-----
	From: Eugene Nechamkin [mailto:[email protected]]
	Sent: Monday, September 12, 2005 21:12
	To: Wijnen, Bert (Bert); Jean-Francois Mule; Ipcdn (E-mail)
	Cc: Richard Woundy @ Comcast
	Subject: RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt
	
	
	
	# Comment 13
	> bw: The issue is that if you use one single object for both the
admin's desire of the status and
	> at the same time for the actual operational status, then it gets
difficult. 
	> If you issue an SNMP SET to enable, then if you accept it, then
that means that the value
	> is to be changed to enabled. If however the value then later
changes, then I bet that the
	> management station is at least very surprised. It is not for
nothing that the IF-MIB (after a long
	> experience) has chosed to haev a Admin and Operational status in
two separate objects.
	 
	Let me put some more clarification on the issue which may address
your general concern with the Admin and Operational Status separation. One of
the reasons it would make sense to separate Admin and Operational status is
the potentail delay between the the SNMP SET changing the Admin Status and
actual Operational status of the device including the case when the device
might be not able to set the corresponding Admin status for some reasons
internal to the device. In case of EMTA Enabling/Disabling, the PacketCable
Provisioning spec does not allow such delays and requires the EMTA to
disable/enable the Telephony Services on the EMTA with very minimal delay (if
at all). Hence, from the operational prosective, the separation of the Admin
and Operational Statuses in PacketCable environment does not seem to be
required.
	 
	Hope this clarifies. Please elaborate further - otherwise.
	 
	bw: Answered in other email
	 
	
	# Comment 14
	
	> bw: See, it seems you do have a valid explanation. If so, then
fine. It would be best if some of
	> that explanation is added to the description clause or easily
available 
	> via the REFERENCE clause. Given the discussion on this topic so
far, it seems best to add some text to the 
	description clause.
	 
	 
	 
	       DESCRIPTION  
	           " This object provides the MTA device type identifier. The

	             value of this object must be a copy of the DHCP option
60 
	             value exchanged between the MTA and the DHCP server."  
	 
	And from that it seems most people do/did not understand exactly what
the content
	should be, right?
	 
	Berty

_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn