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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 12 Sep 2005 21:52:37 +0200

Inline

-----Original Message-----
From: Eugene Nechamkin [mailto:[email-masked]]
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-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Mon, 12 Sep 2005 13:18:40 -0700

> try and do it as soon as it can.
 
This example tells me where the disconnection might be. Let me try once more:
the PacketCable Provisioning Specification prohibits the conditions when "the
device seems unable to do so now". As soon as the EMTA receives the SNMP SET
with "pktcMtaDevEnabled" being set to true/false, the device must and is
always capable of enabling/disabling the telephony services on the EMTA. So,
there is no scenario which can make "the device to try and do it as soon as
it can" as the device would have executed all actions required by the
corresponding Admin state upon SNMP SET operation. The conditions of your
concern cannot happen in PacketCable environment with PacketCable compliant
EMTA device.
 
Please elaborate if this still does no cover your concerns on this subject.
 
Eugene.

________________________________

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

Inline

	-----Original Message-----
	From: Eugene Nechamkin [mailto:[email-masked]]
	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

	In general, we agree with the comment and our first reaction was,
yes,
	Our proposal, after reviewing your comment is still to leave it
as-is.
	 
	> 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.

	 
	Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 12 Sep 2005 23:02:45 +0200

Maybe add some of that explanation to teh DESCRIPTION clause then.
 
Bert

-----Original Message-----
From: Eugene Nechamkin [mailto:[email-masked]]
Sent: Monday, September 12, 2005 22:19
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 ( Comm ent 13)

> try and do it as soon as it can.
 
This example tells me where the disconnection might be. Let me try once more: the PacketCable Provisioning Specification prohibits the conditions when "the device seems unable to do so now". As soon as the EMTA receives the SNMP SET with "pktcMtaDevEnabled" being set to true/false, the device must and is always capable of enabling/disabling the telephony services on the EMTA. So, there is no scenario which can make "the device to try and do it as soon as it can" as the device would have executed all actions required by the corresponding Admin state upon SNMP SET operation. The conditions of your concern cannot happen in PacketCable environment with PacketCable compliant EMTA device.

Eugene.

  _____  

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

Inline

-----Original Message-----
From: Eugene Nechamkin [mailto:[email-masked]]
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)

 
# Comment 13

 

 

Bert

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Mon, 12 Sep 2005 15:05:01 -0700

> Maybe add some of that explanation to teh DESCRIPTION clause then.
 
PROPOSED: modify the description clause to the following (mods are in red):
 
       DESCRIPTION  
            " This object contains the MTA Admin Status of this device. 
              If this object is set to 'true', the MTA is  
              administratively enabled and the MTA MUST be able to  
              interact with the PacketCable entities such as CMS,  
              Provisioning Server, KDC, and other MTAs and MGs on all  
              PacketCable interfaces. 
              If this object is set to 'false', the MTA is  
              administratively disabled and the MTA MUST perform the  
              following actions for all endpoints: 
                  - shutdown all media sessions if present, 
                  - shutdown NCS signaling by following the Restart in 
                  Progress procedures in the PacketCable NCS 
                  specification. 
 
              MTA must execute all actions required to enable/disable the 
              telephony services for all endpoints immediately upon receipt
of 
              the SNMP SET operation. 
 
              Additionally, the MTA MUST maintain the SNMP Interface  
              For management and also SNMP Key management interface.  
              Also, the MTA MUST NOT continue Kerberized key management  
              with CMSes until this object is set to 'true'. 
              Note: MTAs MUST renew the CMS Kerberos tickets according  
              to the PacketCable Security or IPCablecom Specification."     

Would this modification address your concern ?
 
Eugene.

Sent: Monday, September 12, 2005 2:03 PM

Bert

	-----Original Message-----
	From: Eugene Nechamkin [mailto:[email-masked]]
	Sent: Monday, September 12, 2005 22:19
	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 (
Comm ent 13)

	> try and do it as soon as it can.
	 
	This example tells me where the disconnection might be. Let me try
once more: the PacketCable Provisioning Specification prohibits the
conditions when "the device seems unable to do so now". As soon as the EMTA
receives the SNMP SET with "pktcMtaDevEnabled" being set to true/false, the
device must and is always capable of enabling/disabling the telephony
services on the EMTA. So, there is no scenario which can make "the device to
try and do it as soon as it can" as the device would have executed all
actions required by the corresponding Admin state upon SNMP SET operation.
The conditions of your concern cannot happen in PacketCable environment with
PacketCable compliant EMTA device.
	 
	Please elaborate if this still does no cover your concerns on this
subject.
	 
	Eugene.

Comm ent 13)

	Inline

		-----Original Message-----
		From: Eugene Nechamkin [mailto:[email-masked]]
		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

		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?
		 
		> 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.

		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

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 13 Sep 2005 10:06:30 +0200

I personally still prefer two objects (AdminSTatus and OperStatus), but I can
live with your solution and so it is uo to the WG to speak up if they see
an isseu.
 
Bert

-----Original Message-----
From: Eugene Nechamkin [mailto:[email-masked]]
Sent: Tuesday, September 13, 2005 00:05
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 ( Comm ent 13)

 
 
       DESCRIPTION  

              MTA must execute all actions required to enable/disable the 
              telephony services for all endpoints immediately upon receipt of 
              the SNMP SET operation. 

 
Eugene.

  _____  

 
Bert

-----Original Message-----
From: Eugene Nechamkin [mailto:[email-masked]]
Sent: Monday, September 12, 2005 22:19
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 ( Comm ent 13)

 
 
Eugene.

  _____  

Inline

-----Original Message-----
From: Eugene Nechamkin [mailto:[email-masked]]
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)

 
# Comment 13

 

 

Bert

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Tue, 13 Sep 2005 10:12:28 -0700

The authors will keep the resolution proposed below for Comment #13 unless
there are other suggestions from the WG.
 
Eugene.

From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Tuesday, September 13, 2005 1:07 AM
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 ( Comm
ent 13)

Bert

	-----Original Message-----
	From: Eugene Nechamkin [mailto:[email-masked]]
	Sent: Tuesday, September 13, 2005 00:05
	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 (
Comm ent 13)

	 
	> Maybe add some of that explanation to teh DESCRIPTION clause then.
	 
	PROPOSED: modify the description clause to the following (mods are in
red):
	 
	       DESCRIPTION  
	            " This object contains the MTA Admin Status of this
device. 

	              PacketCable interfaces. 

	              following actions for all endpoints: 
	                  - shutdown all media sessions if present, 
	                  - shutdown NCS signaling by following the Restart
in 
	                  Progress procedures in the PacketCable NCS 
	                  specification. 

	              MTA must execute all actions required to enable/disable
the 
	              telephony services for all endpoints immediately upon
receipt of 
	              the SNMP SET operation. 

	              Also, the MTA MUST NOT continue Kerberized key
management  
	              with CMSes until this object is set to 'true'. 
	              Note: MTAs MUST renew the CMS Kerberos tickets
according  
	              to the PacketCable Security or IPCablecom
Specification."     

	Eugene.

	 
	Bert

		-----Original Message-----
		From: Eugene Nechamkin [mailto:[email-masked]]
		Sent: Monday, September 12, 2005 22:19
		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 ( Comm ent 13)

device
		> try and do it as soon as it can.
		 
		This example tells me where the disconnection might be. Let
me try once more: the PacketCable Provisioning Specification prohibits the
		 
		Please elaborate if this still does no cover your concerns on
this subject.
		 
		Eugene.

draft-ietf-ipcdn-pktc-mtamib-06.txt ( Comm ent 13)

		Inline

			-----Original Message-----
			From: Eugene Nechamkin
[mailto:[email-masked]]
			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

			>   And how is the!
			  NMS going to see what the real Operational status
is?
			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
			> If you issue an SNMP SET to enable, then if you
accept it, then that means that the value
			> 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
			 
			Hope this clarifies. Please elaborate further
otherwise.

			bw: nope it does not clarify (at least not for me).
			I always see a difference between what an operator
wan!
			 ts/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

---

From: "Kumar, Satish" <[email-masked]>
Date: Tue, 13 Sep 2005 15:21:19 -0500

To avoid confusion, I would recommend to have the red(new) text above
the sentence " If this object is set to 'false'..." 
 
Thx, Satish

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

 
 
       DESCRIPTION  

 
 
Eugene.

 
Bert

	-----Original Message-----
	From: Eugene Nechamkin [mailto:[email-masked]]
	Sent: Monday, September 12, 2005 22:19
	To: Wijnen, Bert (Bert); Jean-Francois Mule; Ipcdn (E-mail)
	Cc: Richard Woundy @ Comcast
	Subject: RE: AD Review: draft06

device
to
	> try and do it as soon as it can.
	 
	This example tells me where the disconnection might be. Let me
try once more: the PacketCable Provisioning Specification prohibits the
conditions when "the device seems unable to do so now". As soon as the
EMTA receives the SNMP SET with "pktcMtaDevEnabled" being set to
true/false, the device must and is always capable of enabling/disabling
the telephony services on the EMTA. So, there is no scenario which can
make "the device to try and do it as soon as it can" as the device would
have executed all actions required by the corresponding Admin state upon
SNMP SET operation. The conditions of your concern cannot happen in
PacketCable environment with PacketCable compliant EMTA device.

	Eugene.

	Inline

		-----Original Message-----
		From: Eugene Nechamkin [mailto:[email-masked]]
		Sent: Monday, September 12, 2005 21:24
		To: Wijnen, Bert (Bert); Jean-Francois Mule; Ipcdn
(E-mail)

		 
		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

		Our proposal, after reviewing your comment is still to
leave it as-is.
		 
		> bw: The issue is that if you use one single object for
both the admin's desire of the status and
		> management station is at least very surprised. It is
not for nothing that the IF-MIB (after a long
		 
		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.

		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

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Tue, 13 Sep 2005 14:01:52 -0700

Satish,
 
The current location of the proposed sentence is chosen to indicate that this
sentense is pertaining to both cases - setting the object to 'false' and
'true'. Hence - the location of the sentence after both of these cases are
described.
 
Can you elaborate which confusion you are pointing to ?
 
Eugene.

From: Kumar, Satish [mailto:[email-masked]] 
Sent: Tuesday, September 13, 2005 1:21 PM
To: Eugene Nechamkin; Wijnen, Bert (Bert); Jean-Francois Mule; Ipcdn (E-mail)
Cc: Richard Woundy @ Comcast
Subject: RE: [ipcdn] RE: AD Review: draft06
draft-ietf-ipcdn-pktc-mtamib-06.txt ( Comm ent 13)

To avoid confusion, I would recommend to have the red(new) text above the
sentence " If this object is set to 'false'..." 
 
Thx, Satish

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

 
 
       DESCRIPTION  

 
Eugene.

 
Bert

	-----Original Message-----
	From: Eugene Nechamkin [mailto:[email-masked]]
	Sent: Monday, September 12, 2005 22:19
	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 (
Comm ent 13)

	 
	 
	Eugene.

	Inline

		-----Original Message-----
		From: Eugene Nechamkin [mailto:[email-masked]]
		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

		 
		 
		# Comment 13

		 

		 
		Bert