Subject: [ipcdn] Review of draft-ietf-ipcdn-pktc-signaling-00

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 18 Mar 2003 11:32:52 -0700

Here are comments from my partial review of
draft-ietf-ipcdn-pktc-signaling-00.

We will also do a formal review of this draft tomorrow at the IPCDN wg
meeting in ietf 56.

Jean-Francois.
[email-masked]

# Review of draft-ietf-ipcdn-pktc-signaling-00
# ID location: 
# http://www.ipcdn.org/drafts/draft-ietf-ipcdn-pktc-signaling-00.txt
# March 18, 2003

--- General comments:
- align Signaling MIB with latest CableLabs published version:
   + update mib object defs & corrections made so far
   + update reference of PacketCable 1.0 Provisioning Specification
     to match the latest spec version
- update section 2 per current mib boilerplate
  http://www.ops.ietf.org/mib-boilerplate.html
- please read draft-ietf-ops-mib-review-guidelines-01.txt 
  and make the following corrections:
   + copyright inside the Description clause of module identity
   + split references into norm. & informative ref.
   + add clarification text in description clauses (See below)
   + remove oid 99992
     replace 
     <    ::=  { mib-2 99992 } -- to be assigned by IANA.
     with
     >    ::=  { mib-2 XXX }   
     > -- RFC Ed.: replace XXX with IANA-assigned number 
     > -- & remove this note
   + update revision as:
          REVISION    "<date>" 
          DESCRIPTION "Initial version, published as RFC yyyy."
   -- RFC Ed.: replace yyyy with actual RFC number & remove this note
   + add copyright statement
   + review all MIB comments, 72 chars max per line
- update Rich Woundy contact info
  see ipcdn charter page for latest email address
- descriptive mib text in section 3
  Add a paragraph that gives in one or 2 sentences the scope of this
  MIB. For example, explain the NCS endpoints/codec/ring cadence/etc.
  signaling functions of an MTA and how the mib objects defined in
  this draft help manage the MTA signaling piece.
- remove pktcDcsEndPntConfigObjects 
  >   3.1.1.4 pktcDcsEndPntConfigObjects 
  > 
  >   This object is reserved for future use 
  >   in Distributed Call Signaling (DCS). 
  I'm not sure this "for future use" objects belong in ipcdn.
  same "remove" comment applies to
  > pktcDcsEndPntConfigObjects   OBJECT IDENTIFIER ::= {
  > pktcSigMibObjects 4 } 
- revision date and last update:
Please correct this warning:
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (65,34) The first 
revision should match the last update for MODULE-IDENTITY pktcSigMib

--- Comments on mib definitions:
- PktcCodecType TEXTUAL-CONVENTION 
See IETF AVT draft-ietf-avt-profile-new-13.txt, section 4.5: this
draft is an update to rfc1890 and it defines the latest and greatest
encoding names for audio video codecs. The PktcCodecType object
definition should use the encoding names defined in AVT. In
particular, g711a/mu must be replaced by PCMA/PCMU, etc.
These changes were made in the latest PacketCable spec
PKT-SP-MIB-SIG-I05-021127 and should be reflected in the IETF ipcdn
ID.

- PktcSigType TEXTUAL-CONVENTION
 + Update the description clause to state that NCS is defined as the
 Network Call Signaling protocol, a profile of the MGCP protocol
 defined for PacketCable MTAs. 
 + Remove RFC references in the description, put the relevant ones in
 normative references (NCS) or informative references (SIP) -  (the
 sip rfc is now 3261 and who know how long it will last).
 + DCS: I don't think there is any normative reference for building
 DCS MTAs to date so shouldn't this option be removed? one concern
 here is if DCS is a derivation of SIP, where is it defined for MTA
 devices?
 + signaling protocol types and protocol versions: remove version
 numbers in the description clause - another object takes care of
 version numbers (pktcSignalingVersion) 
  + is unknown (2) a possible value given the TC usage? If it is
  unknown, how different is it from other(1)? 

- pktcSigDevCodecIndex
  are there any good reasons for choosing 16383 as the upper bound?

- pktcSigDevCodecMax
" The maximum number of simultaneous sessions of the specific codec
that the MTA can support"
The description clause should be more specific.
I'm not sure I understand how to read this object when you have
multiple codec entries. Does this means the max # of simultaneous
sessions of this codec the MTA can support when this codec is loaded
independently of any other active calls of different codec types? if
not, how useful is this - just asking.
For e.g., let's assume an MTA supports G.711, G.729e, G.728 and
pktcSigDevCodecMax entries are 2, 2, 2. What does this mean when you
mix/match codecs in simultaneous calls?

-     pktcSigDefCallSigTos  OBJECT-TYPE 
-     pktcSigDefMediaStreamTos  OBJECT-TYPE 
Both objects are: SYNTAX      Integer32 (0..63) and the descriptions
refer to TOS. See docsis qos mib discussion, our IPCDN MIBs need to
use explicit DSCP values. The current proposal for the related docsis
qos object is: 
 SYNTAX Dscp          -- 0..63    RFC 3289: DIFFSERV-DSCP-TC
The reference clause in both of these objects links to the PacketCable
NCS spec while the conformance statements put them in the generic
signaling group. I would hope that these are independent of the chosen
signaling protocol => remove the reference.

-     pktcSigDefCallSigTos  applicability
 Is this only applicable to NCS or to any or all signaling type(s)?
 Should this be an additional column of pktcSigCapabilityEntry?

- pktcSigTosFormatSelector
See docsis qos mib discussion. This object will likely have to be
removed.

- pktcSignalingType
  remove references to the TC labels ("this can be NCS, DCS, etc.")

- pktcSigServiceClassNameUS, pktcSigServiceClassNameDS,
  pktcSigServiceClassNameMask,  pktcSigNcsServiceFlowState
  These objects are applicable to the NCS signaling type only. Should
  this be an additional column of pktcSigCapabilityEntry?

- pktcSigNcsServiceFlowState
  align 'notactive  (1)' with 'not-active' 
  
- pktcSigPowerRingFrequency
         SYNTAX       INTEGER { 
                      twenty(1), 
                      twentyFive(2), 
                      thirtyThreePointThreeThree(3), 
                      fifty(4) 
         }
  Not sure what mib doctors would say about this?
  Remove reference to ETSI spec in the description clause and add it
  to a REFERENCE clause. Also should move this ETSI spec in the
  normative or informative ref section.

- pktcSigPCMCoding
  description uses EMTA as in embedded MTA - replace EMTA by MTA (this
  object also applies to standalone MTA)
  should there be a DEFVAL to express "The default will be aLaw(1)."?

- pktcSigPulseSignalTable
  Any references for the columnar objects of this table?
  
- pktcSigPulseSignalDbLevel
  if this object only applies for row with
  pktcSigPulseSignalType=meterPulse, what is the default value of all
  the other signal types (like initialRing, reversePolarity,
  noBattery)?

- pktcSigPulseSignalFrequency
  same comment as above

- pktcSigDevCIDFskAfterRing
  please specify in the description the value when pktcSigDevCIDMode
  == dtAsETS / rpAsETS / lrAsETS.

- pktcSigDevCIDFskAfterDTAS
 please specify the value when pktcSigDevCIDMode == northAmerican /
 duringRingingETS. 
 Also, those 2 previous objects seem to indicate a transmission delay
 for FSK depending on the CIDmode and they could be combined into 1
 object since there is no overlap between their values.

- pktcSigDevCIDRingAfterFSK
- pktcSigDevCIDDTASAfterLR
 again, if these objects are only applicable when the mode is X,
 indicate the value when mode != X

- PktcSigDevToneEntry
note that pktcSigDevToneWholeToneRepeatCount is 34 chars. See
draft-ietf-ops-mib-review-guidelines-01.txt, section 4.2

pktcSigDevToneType is an INTEGER starting with value dtmf0(0). See
draft-ietf-ops-mib-review-guidelines-01.txt, section 4.6.1.1.Note that
RFC 2578 recommends (but does not require) that integer-
   valued enumerations start at 1 and be numbered contiguously.  This
   recommendation SHOULD be followed unless there is a valid reason to
   do otherwise, e.g., to match values of external data or to indicate
   special cases, and any such special-case usage SHOULD be clearly
   documented.
 => in this case, I think it is valid to start with 0, just indicate a
 valid reason.

- pktcSigDevToneSecondFrequency
 type in "in a ultiple frequency tone." <- d in a multiple frequency
 tone.

- pktcSigEndPntConfigTable
  nit:   packet cable should be one word = PacketCable; other typos in
  the description clause.

- pktcSigEndPntConfigEntry
  nit: type in enpoint

- pktcNcsEndPntConfigCallAgentId
  makes a reference to pktcMtaDevCmsFqdn which is defined in another
  MIB. Explain where.

- pktcNcsEndPntConfigCallAgentId
  This is a call agent Inet address that is of fqdn type dns(16).
  Recommendation is to use InetAddress TC defined in 3291 and
  recommend the the InetAddressType be dns(16). 
  It is recommended to add some text to indicate when the call agent
  DNS name should be resolved (probably when the endpoint(s) initiate
  an NCS RSIP and/or each time a new call is initiated with NTFY ??).
  Indicate relationship wiht max1/max2 objects defined below in the
  mib.

- pktcNcsEndPntConfigCallAgentUdpPort
  replace "gateway" by endpoint in this MIB.

- pktcNcsEndPntConfigMWD
- pktcNcsEndPntConfigTdmax
  what happens after this delay timer expires? should this be made
  more clear in the object def?  same for all the max timer objects.

- pktcNcsEndPntConfigCallWaitingDelay 
  longuer than 32 chars; typo in description clause

- pktcNcsEndPntStatusError
  + operational: when is an MTA operational? could you be more
  precise? for e.g., does this mean when all the prov 1 thru 25 steps
  are complete, when all 1..25+1..12 prov-sec are complete or when the
  provisioning 1..25 is complete and the CMS DNS Id has been resolved,
  etc.
  + noSecurityAssociation: note that there may never be a Security
  Association when ipsec is disabled between MTA and NCS.
  + description: prepend NCS in front of RSIP: ... an NCS RSIP message
  exchange...
  
- compliance statement:
Should there be a module compliance including pktcInternationalGroup
for IPCableCom?

W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (2058,6) OBJECT-GROUP
"pktcInternationalGroup" is not used in a MODULE-COMPLIANCE in current
module

- smicng compilation results
fyi - no errors; some warning about object names longer than 32 chars:
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1250,6) Name of item
"pktcSigDevToneWholeToneRepeatCount" is longer than recommended max of
 32 
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1406,6) Name of item
"pktcNcsEndPntConfigCallAgentUdpPort" is longer than recommended max
of 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1433,6) Name of item
"pktcNcsEndPntConfigCriticalDialTO" is longer than recommended max of
 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1473,6) Name of item
"pktcNcsEndPntConfigMessageWaitingTO" is longer than recommended max
of 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1486,6) Name of item
"pktcNcsEndPntConfigOffHookWarnToneTO" is longer than recommended max
of 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1537,6) Name of item
"pktcNcsEndPntConfigStutterDialToneTO" is longer than recommended max
of 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1695,6) Name of item
"pktcNcsEndPntConfigLongDurationKeepAlive" is longer than recommended
max of 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1732,6) Name of item
"pktcNcsEndPntConfigCallWaitingMaxRep" is longer than recommended max
of 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1745,6) Name of item
"pktcNcsEndPntConfigCallWaitingDelay" is longer than recommended max
of 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1757,6) Name of item
"pktcNcsEndPntStatusCallIpAddressType" is longer than recommended max
of 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1822,6) Name of item
"pktcNcsEndPntConfigPulseDialInterdigitTime" is longer than
recommended max of 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1835,6) Name of item
"pktcNcsEndPntConfigPulseDialMinMakeTime" is longer than recommended
max of 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1845,6) Name of item
"pktcNcsEndPntConfigPulseDialMaxMakeTime" is longer than recommended
max of 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1855,6) Name of item
"pktcNcsEndPntConfigPulseDialMinBreakTime" is longer  than recommended
max of 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1865,6) Name of item
"pktcNcsEndPntConfigPulseDialMaxBreakTime" is longer  than recommended
max of 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1875,6) Name of item
"pktcNcsEndPntConfigNomJitterBufferSize" is longer than recommended
max of 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1888,6) Name of item
"pktcNcsEndPntConfigMaxJitterBufferSize" is longer than recommended
max of 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1898,6) Name of item
"pktcNcsEndPntConfigOnHookDebounce" is longer than recommended max of
 32
W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1908,6) Name of item
"pktcNcsEndPntConfigOffHookDebounce" is longer than recommended max of
 32

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