Subject: RE: [ipcdn] SigMIB Draft 10

From: "Freyman Phillip-FPF300" <[email-masked]>
Date: Thu, 30 Mar 2006 23:08:15 -0600

Richard, Randy,
 
per Randy's comment on text.  
 
In my proposal, I picked up the format and text from other elements in
the current proposed SigMIB Draft 10.  This text has been in WG
discussion for a long time.
 
I contacted Gordon Beacham of Motorola who was an earlier member of the
WG on this question.
 
although Gordon did not have specific email chain on the discussion in
this area, he remembers that this was the wording recommended by the
working group and was answered long ago on the ipcdn reflector. 
 
As Gordon recalled, "not used" meant the value is not applicable to a
particular object. Somebody wanted to know what happens if a get/set was
used, so the suggestion was to return inconsistent value. 
 
If you have an opinion for different wording that is clearer please post
it for discussion.
 
regards,
 
Phil

________________________________

From: Woundy, Richard [mailto:[email-masked]] 
Sent: Thursday, March 30, 2006 4:32 PM
To: Freyman Phillip-FPF300; [email-masked]
Subject: RE: [ipcdn] SigMIB Draft 10

Thanks, that makes sense to me.
 
I tend to agree with the direction of Randy Presuhn's comments (copied
below).
 
>What is meant by "not used" in the proposed DESCRIPTION clause?
Specifically, what happens when processing a get(next/bulk) request and
pktcSigDevCidMode is not rpAsETS?
 
Maybe what is implied is "The value of this object is ignored unless
pktcSigDevCidMode is rpAsETS."? I agree that the wording could be
clearer.
 
>Also, what is the motivation for requiring inconsistent value errors
for all set requests when pktcSigDevCidMode is not rpAsETS? If the value
is ignored under those circumstances, it would seem simpler to accept it
as long as it is within the SYNTAX range.
 
I tend to agree. If the value of the object is ignored when
"pktcSigDevCidMode is not rpAsETS", then it should be safe to set the
value of the object. Then this object value could be pre-populated (e.g.
in a config file), and pktcSigDevCidMode could be set to rpAsETS (e.g.
SNMP Set) independently. Although I think this makes sense in theory, I
don't know of a particular use case in practice.
 
Looking at the rest of the -10 draft, there are a *lot* of instances
where 'inconsistent value errors' are returned, just like this proposal:
 
pktcSigDevCidAfterRing: "An attempt to set this object while the value
of pktcSigDevCidMode is not duringringingETS will result in an
'inconsistent value' error."
 
pktcSigDevCidAfterDTAS: "An attempt to set this object while the value
of pktcSigDevCidMode is not dtAsETS or lrAsETS will result in an
'inconsistent value' error."
 
pktcSigDevCidAfterRPAS: "An attempt to set this object while the value
of pktcSigDevCidMode is not rpAsETS will result in an 'inconsistent
value' error."
 
And so forth. Does someone remember why this is specified in this
manner?
 
-- Rich

	-----Original Message-----
	From: Freyman Phillip-FPF300
[mailto:[email-masked]] 
	Sent: Thursday, March 30, 2006 12:17 PM
	To: Woundy, Richard; [email-masked]
	Subject: RE: [ipcdn] SigMIB Draft 10

	Richard,
	 
	thanks for the comment
	 
	Per the current Draft:
	 
	   pktcSigDevCidAfterRPAS - this international object sets the
delay 

	   between the ring pulse alert signal and the transmission of
caller 

	   id information. 

	where as
	 
	   pktcSigDevrpAsDtsDuration - this international object sets
the duration of  

	   the ring pulse alerting signal prior to CID signaling.
Variations in 

	   national standards cause CID failure if RP-AS is not defined
by local 

	   requirements.

	rpAsDtsDuration is how long the RP-AS is applied
	 
	CidAfterRPAS is the delay (pause) between the RP-AS and the CID
	 
	Hopefully this explains the differences?
	 
	Phil

________________________________

	From: Woundy, Richard [mailto:[email-masked]] 
	Sent: Thursday, March 30, 2006 11:00 AM
	To: Freyman Phillip-FPF300; [email-masked]
	Subject: RE: [ipcdn] SigMIB Draft 10

	Phillip,
	 
	Pardon my ignorance with this question. What is the difference
between the proposed object below ('pktcSigDevrpAsDtsDuration') and the
'pktcSigDevCidAfterRPAS' in the current -10 draft?
	 
	I am not so much opposed to this change, I just want to
understand the rationale better.
	 
	And since our WG only has two work items left, I would like to
finish this document and get it published.
	 
	-- Rich

		-----Original Message-----
		From: Freyman Phillip-FPF300
[mailto:[email-masked]] 
		Sent: Tuesday, March 28, 2006 4:53 PM
		To: [email-masked]
		Subject: [ipcdn] SigMIB Draft 10

		Colleagues,

		A situation has been raised in Belgium where the local
telephony requirements exceed the ETSI EN 300 369-1 definition for RP-AS

		In the ETSI document RP-AS is defined as 200 ms to 300
ms in duration.

		In the Belgium Belgacom document the RP-AS is implied as
being 340 ms and in field experience this as been verified. Some CPE
devices do not respond if the RP-AS is less than 340 ms.

		It does not appear that the maximum ETSI value of RP-AS
is adequate and it does not appear that placing CID during the normal
ring cadence is acceptable.

		We therefore have two standards which do not overlap and
therefore we must define a new SigMIB object to define the RP-AS
duration from the ETSI 200 ms min to something in excess of the Belgacom
nominal value of 340 ms.

		In the following text draft, I have defined a new object
(#41) with a range of 200-500 ms.

		Page 7 Add:

		   pktcSigDevrpAsDtsDuration - this international object
sets the duration of  

		   the ring pulse alerting signal prior to CID
signaling.  Variations in 

		   national standards cause CID failure if RP-AS is not
defined by local 

		   requirements.

		Page 44 Add:

		   pktcSigDevrpAsDtsDuration     OBJECT-TYPE 

		       SYNTAX       Unsigned32 (200..500) 

		       UNITS        "Milliseconds" 

		       MAX-ACCESS   read-write 

		       STATUS       current 

		       DESCRIPTION 

		           " This object specifies the duration of the
rpASDTS ring pulse prior

		             to the start of the transmission of the 

		             FSK or DTMF containing the Caller ID
information. It is  

		             only used when pktcSigDevCidMode is
rpAsETS. The  

		             following table defines the default values
for this object  

		             depending on the signal type: 

		             pktcSigDevCidMode     Default 

		             duringringingETS      not used 

		             dtAsETS               not used 

		             rpAsETS               250 

		             lrAsETS               not used 

		             lrETS                 not used 

		             An attempt to set this object while the
value of 

		             pktcSigDevCidMode is not rpAsETS will
result in 

		             an 'inconsistent value' error." 

		       REFERENCE  

		           "ETSI-EN-300-659-1 Specification and Belgacom

		            BGC_D_48_9811_30_09_EDOC version 3.3" 

		       DEFVAL { 250 } 

		       ::= {pktcSigDevConfigObjects 41 } 

		Page 60 Add last line

		   pktcInternationalGroup    OBJECT-GROUP  

		       OBJECTS {  

		       pktcNcsEndPntConfigMinHookFlash,  

		       pktcNcsEndPntConfigMaxHookFlash,  

		       pktcNcsEndPntConfigPulseDialInterdigitTime,  

		       pktcNcsEndPntConfigPulseDialMinMakeTime,  

		       pktcNcsEndPntConfigPulseDialMaxMakeTime,  

		       pktcNcsEndPntConfigPulseDialMinBreakTime,  

		       pktcNcsEndPntConfigPulseDialMaxBreakTime, 

		       pktcSigDevRingCadence,  

		       pktcSigDevCidSigProtocol,  

		       pktcSigDevCidDelayAfterLR, 

		       pktcSigDevCidDtmfStartCode, 

		       pktcSigDevCidDtmfEndCode, 

		       pktcSigDevVmwiSigProtocol, 

		       pktcSigDevVmwiDelayAfterLR, 

		       pktcSigDevVmwiDtmfStartCode, 

		       pktcSigDevVmwiDtmfEndCode, 

		       pktcSigDevrpAsDtsDuration,

		I understand it may delay Draft 10 but I think it is
necessary.

		Regards,

		Phillip Freyman
		Distinguished Member of the Technical Staff
		Science Advisory Board Associate
		Motorola, Inc.
		Connected Home Solutions IPS
		IP System Engineering
		21440 West Lake Cook Road
		Deer Park, IL 60010

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 30 Mar 2006 22:03:00 -0800

Hi -

> From: "Freyman Phillip-FPF300" <[email-masked]>
> To: "Woundy, Richard" <[email-masked]>; <[email-masked]>
> Sent: Thursday, March 30, 2006 9:08 PM
...
> used, so the suggestion was to return inconsistent value. 
...

Returning a "inconsistent value" in response to an SNMP get(next/bulk)
operation is simply wrong.  See RFC 3416 sections 4.2.1, 4.2.2,
and 4.2.3 respectively for the permitted responses.  So the question
still remains: how do these objects behave in the "not used" case?
The behaviour I'd expect would be for these objects to be present with
whatever value they had most recently been set to, which might be the
result of DEFVAL initialization.

In the case of a set request, "inconsistent value" would be a plausible
response, but it does mean that systems using SNMP to configure a
device will need to send the varbinds in separate PDUs to ensure consistent
results.  I don't see how this benefits anyone.

Randy