[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ipcdn] comments on draft-ietf-ipcdn-pktc-signaling-08.txt

Sumanth and all,

   Knowing you are preparing a new draft, here are some (late) comments. Also please read Bert's AD comments on the MTA MIB ID as some of them apply to your mib module as well (especially persistency of read-write/read-create like objects).

   This is not a full review, just a quick random scan.

Jean-François

- run Idnits and check the output on both draft08 and before submitting draft09
  http://ietf.levkowetz.com/tools/idnits/idnits.pyht
  I pasted the verbose output below

- ID is missing some citations for the mib modules in the IMPORT clause (for e.g. RFC 2863).
Consider adding comments with the rfc number as in:
IMPORTS
    MODULE-IDENTITY, 
    OBJECT-TYPE,
    OBJECT-IDENTITY, 
    Unsigned32,
    Counter32,
    NOTIFICATION-TYPE,    
    mib-2 
          FROM SNMPv2-SMI                    -- [RFC2578]
    RowStatus, 
    TruthValue
          FROM SNMPv2-TC                     -- [RFC2579]
    OBJECT-GROUP, 
    MODULE-COMPLIANCE,
    NOTIFICATION-GROUP 
          FROM SNMPv2-CONF                   -- [RFC2580]
    InetAddressType, 
    InetAddress 
          FROM INET-ADDRESS-MIB              -- [RFC4001]
    sysDescr  
          FROM SNMPv2-MIB                    -- [RFC3418]
    SnmpAdminString 
          FROM SNMP-FRAMEWORK-MIB            -- [RFC3411]
    docsDevSoftwareGroupV2
          FROM DOCS-CABLE-DEVICE-MIB         -- [RFCxxxx]
    DocsX509ASN1DEREncodedCertificate,
    docsBpi2CodeDownloadGroup
          FROM DOCS-IETF-BPI2-MIB            -- [RFC4131]
    ifPhysAddress
          FROM IF-MIB;                       -- [RFC2863]

- CableLabs spec references should be in the form of:
[PKT-SP-PROV] Packetcable MTA Device Provisioning Specification,
                 Issued,PKT-SP-PROV-I11-050812, August 2005.
              http://www.packetcable.com/specifications/
              http://www.cablelabs.com/specifications/archives/

- consider removing spaces in ETSI TS 101 909-4, etc.
- consistency for endpoint | end point
- in   PktcCodecType, the line
             g729            ITU-T Recommendation G.722
             ^^^^                                 ^^^^^
  does seem to have a typo

- consider changing
<             ilbc            internet low bit rate codec
With 
>             ilbc            IETF internet low bit rate codec
(and may want to put an informative reference to RFC 3951

- in   PktcCodecType, add "Broadcom" in from of "Broadvoice 16" 

- in pktcSigDevToneType, enumerate userDefined1-4 as in userDefined1, userDefined2, userDefined3 and userDefined4"
- also in pktcSigDevToneType, would it be better to not use the currently defined max value in the DESCRIPTION clause for future extensibility?
  Remove "from 1 to 21" in 
           "Unique value ranging from 1 to 21 that will correspond   
            to the different tone types. These tones can be  ..."?

- s/a MTA/an MTA globally
- add ETSI in references to their docs:
        REFERENCE  
           "ETSI EN 300 659-1 Specification"
   You've done it elsewhere.
- pktcSigDevVmwiFskAfterRPAS and may be other objects:
 check mib doctor comments on the MTA MIB from Randy et al. on return values (use single quote):
xxx    return an 'inconsistentValue' in response to SNMP SET operations  
                 ^^^^^^^^^^^^^^^^^^^
- pktcSigDevCIDMode, and many other objects:
DESCRIPTION says "This object is required only for Euro-PacketCable."

First, this is too restrictive as this mib module applies to IPCablecom in general.
Second, I am strongly opposed to making such statements in the mib module, whether it CableLabs PacketCable or EuroCableLabs (ECL) Euro-PacketCable. It makes the mib def way to rigid and if one organization changes its mind, or another - say a country in Asia finds use for those objects, the description is not accurate.
To me this kind of "outside IETF" certification-related requirements should not be in the MIB module. At best, we have designed the compliance group to be meaningful to those "outside" organizations and the object is in the pktcInternationalGroup compliance group and if ECL chooses to, they can mandate the international group be implemented.
   GROUP pktcInternationalGroup  
       DESCRIPTION   
           " This group is mandatory for any MTA implementing 
             international telephony features.
If we have done so for any PacketCable-specific requirements, we must undo it.

- same for:
   pktcSigDevRingCadence    OBJECT-TYPE  
       SYNTAX       PktcRingCadence 
       MAX-ACCESS   read-write  
       STATUS       current  
       DESCRIPTION  
           "This is the Ring Cadence. This object is required for the 
            E line package."
            ^^^^^^^^^^^^^^ outside requirement.

- pktcNcsEndPntConfigMinHookFlash  and other objects
       MAX-ACCESS   read-only  
"This object MUST only be set via the configuration file during the provisioning process."
Given that is read-only, can you replace "set" by "provided"? this is to avoid any confusion with SET operations.
(not very important, feel free to ignore but reading through it, it popped up a question mark).

- in pktcNcsEndPntConfigRtoMax, consider
changing
           " This object contains the maximum number of seconds for the 
             retransmission timer. When this timer expires the MTA  
             retransmits the message."  
With
           " This object specifies the maximum number of seconds the MTA
             waits for a response to an NCS message before initiating 
             a retransmission."  

-  without reading the NCS spec, I am not sure the description for pktcNcsEndPntConfigRtoInit is clear: 
           " This object contains the initial number of seconds for the 
             retransmission timer." 
  Add more text to better define the timer?

- idnits 1.78 

tmp/draft-ietf-ipcdn-pktc-signaling-08.txt:

tmp/draft-ietf-ipcdn-pktc-signaling-08.txt(3164): Line contains a non-ascii character (') in position 10.
  -->    Editor's Note (to be removed prior to publication): the IANA is
               ^
tmp/draft-ietf-ipcdn-pktc-signaling-08.txt(3173): Line contains a non-ascii character ((tm)) in position 36.
  -->    [PKT-SP-MIB-SIG-1.0] PacketCable(tm) 1.0 Signaling MIB
                                         ^
tmp/draft-ietf-ipcdn-pktc-signaling-08.txt(3176): Line contains a non-ascii character ((tm)) in position 36.
  -->    [PKT-SP-MIB-SIG-1.5] PacketCable(tm) 1.5 Signaling MIB
                                         ^


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
    
    Checking conformance with RFC 3978/3979 boilerplate...

  * Found rfc3978 Section 5.4 paragraph 1 boilerplate (on line 2967), which
    is fine, but *also* found rfc2026 Section 10.4C paragraph 1 boilerplate on
    line 40. It should be removed.
  * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
    Acknowledgement -- however, there's a paragraph with a matching beginning.
    Boilerplate error?

  (Expected a match on the following text:
    "By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79."
  
   ... but found this:
    "By submitting this Internet-Draft, each author represents that any
    applicable patent or other Intellectual Property Rights (IPR) claims
................................^
    of which he or she is aware have been or will be disclosed, and any
    of which he or she becomes aware will be disclosed, in accordance
    with Section 6 of RFC 3668.")



  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
    Nothing found here (but these checks do not cover all of
    1id-guidelines.txt yet).

  Miscellaneous warnings:
    None.


_______________________________________________
IPCDN mailing list
IPCDN at ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn