RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt ( Comm ent 13)

Inline

-----Original Message-----
From: Eugene Nechamkin [mailto:[email protected]]
Sent: Monday, September 12, 2005 21:24
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)



 
Because the message is becoming too big I am separating the responses for each comment for better trackability (also modifying the title slightly).
 
# Comment 13
 


> - For pktcMtaDevEnabled a better name woul probably be
>       pktcMtaDevAdministrativelyEnabled
>   And how is the NMS going to see what the real Operational status is?
>   Is a AdminStatus and OperStatus (as in IF-MIB) not more appropriate?
Proposed resolution: no action
In general, we agree with the comment and our first reaction was, yes,
let's rename it and add an operStatus one.
But after looking at its definition in more details, syntax
(ThruthValue) and after c

onsidering a new operStatus object, we think
that:
        - pktcMtaDevEnabled is both an admin and operational status
          object, hence the name is probably ok,
        - it returns the operational status of the enable/disable
          switch when read.
Our proposal, after reviewing your comment is still to leave it as-is.
Is this ok? if not, can you elaborate?
 
> 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.
 
Jean-Francois and Eugene.
 

bw: nope it does not clarify (at least not for me).
I always see a difference between what an operator wants/intends
(i.e. AdminStatus) and what the device was actually able to do
or has done (i.e. OperStatus). The timing as to how fast the 
device/software has to do it has nothing to do with it it in my view.
For example, if I set AdminStatus to "enable", and if the device
seems unable to do so now, then I would still want the device to
try and do it as soon as it can.
 
Bert

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