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

"Wijnen, Bert (Bert)" <[email protected]> Mon, 12 Sep 2005 21:52:38 +0200
Newsgroups gmane.ietf.ipcdn
Message-ID <7D5D48D2CAA3D84C813F5B154F43B1550808DA77@nl0006exch001u.nl.lucent.com>
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