Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)
draft-ietf-ipcdn-pktc-signaling-15

[Ballot comment]
1) Expand MGCP at first occurence in Section 3.3

2) Section 4: s/ where each index (ifIndex) refers to a unique enpoint/ where each index(ifIndex) value refers to a unique enpoint

3) Section 4.2 - the terminology 'international object' and 'international table' is not clear. I suggest to replace it with an explanation that this is about international IP telephony features

4) There are many instances of read-write and read-create objects where the text 'The value of this MIB Object MUST NOT persist accross MTA reboots'. I believe that the intention is that at reboot the objects would return to the default values where available. If this is the case I would suggest to include some text on this respect at the begining of the MIB module to make the desired procedure more clear for agents implementers.

5) REFERENCE clause of pktcSigDefNcsReceiveUdpPort - use full name of the PacketCable specification

6) The text in the REFERENCE clause of pktcSigPowerRingFrequency seems to better belong to the DESCRIPTION clause

7) Many REFERENCE clauses in the specification just provide the name of the specification (from ETSI for example). It would be useful if section or table numbers were provided.

6)

[Ballot comment]
The security considerations call out the sensitivity of only one readable object, the
pktcSigEndPntStatusCallIpAddress, as valuable to would-be attackers. 

I wondered if two others might merit an explicit mention:

  Wouldn't the information in pktcSigDevCodecMax be sueful when launching a denial
    of service attack?
  It also seems like pktcSigEndPntStaatus Error could be helpful in some attacks...

The following message was sent by the IETF Secretariat to the I-D editor:

Dear Gordon Beacham:

An IPR disclosure that pertains to your Internet-Draft entitled "Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)"
(draft-ietf-ipcdn-pktc-signaling) was submitted to the IETF Secretariat on
2007-09-07 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR disclosure is "Motorola's Statement about IPR claimed in draft-ietf-ipcdn-pktc-signaling-15."

The IETF Secretariat

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "NETWORK MANAGEMENT PARAMETERS" registry
located at

http://www.iana.org/assignments/smi-numbers
sub-registry "Prefix: iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)"

Decimal Name Description References
------- ---- ----------- ----------
[tbd] pktcSigMib PacketCable Management
[RFC-ipcdn-pktc-signaling-15]

We understand the above to be the only IANA Action for this
document.

MIB Doctor review of draft-14 by Bert Wijnen

Revision 14 has now been reviewed by me to see if my earlier comment during MIB doctor review of rev 13 have been  addressed.

Here are my findings:

- basically this document is OK now.

- I still have a few things that I would prefer to get fixed:

1.pktcSigPulseSignalTable    OBJECT-TYPE
    SYNTAX      SEQUENCE OF PktcSigPulseSignalEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        " The Pulse signal table defines the pulse signal operation.
          There are nine types of international pulse signals,
          with each signal having a set of provisionable parameters.
          The values of the MIB objects in this table take effect
          only if these parameters are not defined via signaling, in
          which case the latter determines the values of the
          parameters. This MIB table is required for the E line
          package.

  The "is required" is something that belongs in MODULE compliance and
  NOT in the DESCRIPTION clause of an OBJECT-TYPE. I see that the objects
  of this table have been included in the pktcELinePackageGroup and that
  such is an conditionally optional GROUP on the MODULE-COMPLIANCE. SO
  all that is needed is to remove the last sentence from the above
  DESCRIPTION clause.

2. pktcSigPulseSignalRepeatCount    OBJECT-TYPE
    SYNTAX      Unsigned32 (1..50)
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        " This object specifies how many times to repeat a pulse.
          This object is not used by the enableMeterPulse signal
          type and as such must have a value of zero. The following
          table defines the default values and the valid ranges for
          this object depending on the signal type.

          pktcSigPulseSignaltype  Default  Range

          initialRing                1      1-5
          pulseLoopClose            1      1-50
          pulseLoopOpen              1      1-50
          enableMeterPulse      (any value)(not used)
          meterPulseBurst            1      1-50
          pulseNoBattery            1      1-50
          pulseNormalPolarity        1      1-50
          pulseReducedBattery        1      1-50
          pulseReversePolarity      1      1-50


  I am confused with the 2nd sentence of the DESCRIPTION clause.
  I think the value zero is not valid (is it?) so better not speak of it.
  The (any value) would be in the range 1..50 I think, but as stated,
  it will not be used. So maybe, to avoid confusion, I would do:

    DESCRIPTION
        " This object specifies how many times to repeat a pulse.
          This object is not used by the enableMeterPulse signal
          type and in that case the value is irrelevant. The following
          table defines the default values and the valid ranges for
          this object depending on the signal type.

          pktcSigPulseSignaltype  Default  Range

          initialRing                1      1-5
          pulseLoopClose            1      1-50
          pulseLoopOpen              1      1-50
          enableMeterPulse      (any value)(not used)

  Maybe even also do
          enableMeterPulse          (1)    (1-1, but not used)

- If a new revision is done, then I would appreciate if you can change
  my affiliation from "Lucent Technologies" into "Alcatel-Lucent".
  But no need to just do a new rev for that.

Below are some inline responses from me to things that I can live with but that I would personally (still) do different. I have removed/deleted all the comments that have been address and that I am happy with.

Bert Wijnen 

> -----Original Message-----
> From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com]
> Sent: Thursday, June 21, 2007 1:11 AM
> To: Wijnen, Bert (Bert); gordon.beacham@motorola.com; Satish Kumar at
> Texas Instruments; ipcdn@ietf.org
> Cc: Jean-Francois Mule; Richard Woundy @ Comcast; Romascanu, Dan (Dan)
> Subject: RE: MIB Doctor review:
> http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-sign
aling-13.txt
>
> > Let me start to tell you that I am not a voice expert, so a lot of
> > the actual content of this MIB module is abacadabra for me. I am
> > assuming that other IPCDN WG members have evaluated (or will
> > evaluate) the actual content w.r.t. the technical details and
> > correctness.
> >

The above still holds.

> > Let me also say that I find this MIB module pretty wieldy,
>
> Thanks for the review and this opening comment. It is nice to hear and
> the credit goes to all the ipcdn participants & implementers who
> contributed to, and revised, the mib module over the years.
>

When I say "wieldy", I mean that I see extensive/many objects, and my motto has always been: less objects is better.

> > - I wonder if the SYNTAX of SnmpAdminString makes sense for the
> >  objects pktcSigCapabilityVersion and pktcSigCapabilityVendorExt.
> >  It will work. But, SnmpAdminString is intended to contain human
> >  readable (in any language/character set) strings. It seems that
the
> >  values that you allow are very restricted and certainly cannot
> >  be in any other language/character-set.
> >  I personally can live with it... but you might want to
> >  think of just an OCTET-STRING that you define exactly what it can
> >  contain.
>
> Can see your point; however, given the original intention to not be
> restrictive regarding the values and to restrict this to human
> readable strings only, we should probably let this be as-is.
>

As I said, I can live with it, but I think I would use an OCTET STRING
or use my own TC for this specific semantic.

>
> > - pktcSigPulseSignalTable DESCRIPTION clause speaks about the
> > mandatory
> >  nature of this table for E line package. This is MODULE-COMPLIANCE
> >  stuff and should be expressed in the OBJECT-GROUP grouping and
> >  MODULE-COMPLIANCE.
> >
> >  similar comment for pktcSigDevRingCadenceTable
> I propose we add another new object-group and make it
> conditionally mandatory as you suggested earlier.
>

So the above is the one that has not been fixed in the DESCRIPTION
clause
yet.

>
> > - Have seen a SYNTAX of
> >          SYNTAX      INTEGER {
> >                                fsk(1),
> >                                dtmf(2)
> >          }
> >  for the signaling protocol multiple times.
> >  Candidate for a TEXTUAL-CONVENTION?
>
> Yes, a TC will be created.
>

You did not do that. I can live with it though.

> > - For the read-create table, I wonder where the read-only objects
> >  pktcNcsEndPntStatusCallIpAddressType and
> > pktcNcsEndPntStatusCallIpAddress
> >  come from? How does the agent determine those addresses.?
>
> The DESCRIPTION needs to clarify this. To explain further,
> the agent determines the CMS FQDN from the MIB Object
> 'pktcNcsEndPntConfigCallAgentId'. It then uses DNS to resolve
> the IP address. This resolution can lead to multiple IP
> addresses and it picks one. It then populates
> 'pktcNcsEndPntStatusCallIpAddress' with this IP address.
>

So a DNS name in this object here is not valid.
And so a value of 'dns' for pktcNcsEndPntStatusCallIpAddressType
would not be valid either, right? That is not clear from the
SYNTAX. But since these are read-only objects I think it is OK.

> > Admin/Naming questions:
> >
> > - The title speaks about:
> >
> >      Network-Based Call Signaling (NCS) MIB for PacketCable and
> >
> >  while the MIB Module is named: PKTC-IETF-SIG-MIB and
pktcIetfSigMib
> >  Not that that is a bug... but it feels somewhat strange.
> >
> >  Later in the document, at various places the "NCS MIB" term comes
> >  back, and so people might expect to see IETF-NCS-MIB or ietfNcsMib
> >  as names?
>
> Let me check with the co-authors. I would leave it as-is, but
> I think we need to clean up the text accordingly.
>

I see some that cleanup.  The title of the doc still has NCS.
But it is not a fatal flaw.. so it is up to you to decide if more
needs to be done about it.

>
> >
> > - Section 4 states:
> >
> >    Terminal Adapter (MTA) devices. The IETF NCS MIB module
(PKTC-IETF-
> >    SIG-MIB) is intended to supersede various Signaling MIB modules
> >    from which it is partly derived:
> >      - the PacketCable 1.0 Signaling MIB Specification
> >        [PKT-SP-MIB-SIG-1.0],
> >      - the PacketCable 1.5 Signaling MIB Specification
> >        [PKT-SP-MIB-SIG-1.5],
> >      - the ITU-T IPCablecom Signaling MIB requirements [ITU-T-J169],
> >      - the ETSI Signaling MIB [ETSI-TS-101-909-9]. The ETSI
Signaling
> >        MIB requirements also refer to various signal characteristics
> >        defined in [ETSI-TS-101-909-4], [ETSI-EN-300-001],
> >        [ETSI-EN-300-659-1], [ETSI-EN-300-324-1] and
[ETSI-TR-101-183].
> >
> >  I know that many IPCDN WG members are all participating in
PackagetCable,
> >  so I assume that superseding (is that same as obsoleting in IETF
terms?)
> >  PacketCable documents is fine. But how about ITU-T and ETSI? Are
they
> >  OK with the above statements?
>
> Good point, unless we formally receive a liaison statement
> about this, we should be more careful. Let's replace
> "intended to supersede" with "intended to update" which gives
> these 2 SDOs more room & control to do what they think is right.
>

I am OK with the softened text.
Dan (your AD) may want to check this and see if he is OK with it.

> > - pktcNcsEndPntConfigTable and the objects in that table
> >  have a prefix of pktcNcs.... Why not pktcSigNcs....  ???
> >  Just to better avoid any future name clashes in other MIB
> >  modules .
>
> I would be fine with this.
>

But it has not been chganged.
I can live with it. It just would be better to make the change
so that there is more consistency in the naming and less risk for
any future clashes.


Bert

MIB Doctor Review of draft-13 by Bert Wijnen

Let me start to tell you that I am not a voice expert, so a lot of the actual content of this MIB module is abacadabra for me. I am assuming that other IPCDN WG members have evaluated (or will
evaluate) the actual content w.r.t. the technical details and correctness.

Let me also say that I find this MIB module pretty wieldy,

Nevertheless, here are my MIB Doctor review comments.

More or less serious issues/concerns:

- writable objects MUST specify (for example in their DESCRIPTION
  clause) the expected persistence behavior.

- I see various objects aka:
  pktcSigDevR0Cadence    OBJECT-TYPE
      SYNTAX      PktcRingCadence
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
          " This object specifies ring cadence 0 (a user defined
            field). This object is required for the L line package."
      ::= { pktcSigDevObjects 5 }

  The fact that an object is required" is normally expressed in the
  MODULE-COMPLIANCE. The above object (together with several others)
  seems conditionaly optional, which means you would group all such
  objects required for L line package in one OBJECT-GROUP and make
  that OBJECT-GROUP conditionaly mandatory.

- I wonder if the SYNTAX of SnmpAdminString makes sense for the
  objects pktcSigCapabilityVersion and pktcSigCapabilityVendorExt.
  It will work. But, SnmpAdminString is intended to contain human
  readable (in any language/character set) strings. It seems that the
  values that you allow are very restricted and certainly cannot
  be in any other language/character-set.
  I personally can live with it... but you might want to
  think of just an OCTET-STRING that you define exactly what it can
  contain.

- I find this strange:
  pktcSigPowerRingFrequency    OBJECT-TYPE
      SYNTAX      INTEGER {
                  f20Hz(1),
                  f25Hz(2),
                  f33Point33Hz(3),
                  f50Hz(4),
                  f15Hz(5),
                  f16Hz(6),
                  f22Hz(7),
                  f23Hz(8),
                  f45Hz(9)
      }
      UNITS "Hertz"

  Because tha value of the object is certainly not in "Hertz" units.
  A value of 1 doe not represent 1 UNIT of "Hertz", but it represents
  20 Hertz. and so on... I think I would remove the UNITS clause.

  Same for pktcSigPulseSignalFrequency

- pktcSigPulseSignalTable DESCRIPTION clause speaks about the mandatory
  nature of this table for E line package. This is MODULE-COMPLIANCE
  stuff and should be expressed in the OBJECT-GROUP grouping and
  MODULE-COMPLIANCE.

  similar comment for pktcSigDevRingCadenceTable

- I see:
  pktcSigPulseSignalDbLevel    OBJECT-TYPE
      SYNTAX      TenthdBm (-350..0)
      UNITS        "dBm"

  I thought that the units were "1/10 of a dBm" ??

  same for pktcSigDevToneDbLevel

- Given the DESCRIPTION clause for
  pktcSigPulseSignalRepeatCount    OBJECT-TYPE
      SYNTAX      Unsigned32
  You might consider to make the syntax
      SYNTAX      Unsigned32 (1..50)

- This DESCRIPTION clause has to be incorrect:

  pktcSigDevRingCadenceEntry    OBJECT-TYPE
      SYNTAX      PktcSigDevRingCadenceEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          " Unique value ranging from 0 to 127 that will correspond to
            the different ring cadences that are being supported by
            the device."

  After all, it is an "entry" or "row" definition and so it does not have a
  value from 0-127. The INDEX object does.
  The DESCRIPTION clause of the INDEX object seems to be describing what an
  Entry is all about.

- What sort of duration (UNITS?) must I assume for:
      pktcSigDevToneFreqOnDuration OBJECT-TYPE
          SYNTAX      Unsigned32(0..5000)

  same question for pktcSigDevToneFreqOffDuration,

- Have seen a SYNTAX of
          SYNTAX      INTEGER {
                              fsk(1),
                              dtmf(2)
          }
  for the signaling protocol multiple times.
  Candidate for a TEXTUAL-CONVENTION?

- For pktcNcsEndPntConfigPartialDialTO, what does a zero value mean?

  similar question for the other pktcNcs....TO objects

- I find it strange to see pktcNcsEndPntConfigStatus in the middle of the
  table. But... it is not an error.

- For the read-create table, I wonder where the read-only objects
  pktcNcsEndPntStatusCallIpAddressType and pktcNcsEndPntStatusCallIpAddress
  come from? How does the agent determine those addresses.?

- For pktcNcsGroup the DESCRIPTION clause talks about this group being
  mandatory for... That does NOT belong here. The fact if a group is
  mandatory or not is specified in the MODULE-COMPLIANCE statement.


Admin/Naming questions:

- The title speaks about:

      Network-Based Call Signaling (NCS) MIB for PacketCable and

  while the MIB Module is named: PKTC-IETF-SIG-MIB and pktcIetfSigMib
  Not that that is a bug... but it feels somewhat strange.

  Later in the document, at various places the "NCS MIB" term comes back,
  and so people might expect to see IETF-NCS-MIB or ietfNcsMib as names?

- Section 4 states:

  Terminal Adapter (MTA) devices. The IETF NCS MIB module (PKTC-IETF-
  SIG-MIB) is intended to supersede various Signaling MIB modules from
  which it is partly derived:
    - the PacketCable 1.0 Signaling MIB Specification
      [PKT-SP-MIB-SIG-1.0],
    - the PacketCable 1.5 Signaling MIB Specification
      [PKT-SP-MIB-SIG-1.5],
    - the ITU-T IPCablecom Signaling MIB requirements [ITU-T-J169],
    - the ETSI Signaling MIB [ETSI-TS-101-909-9]. The ETSI Signaling
      MIB requirements also refer to various signal characteristics
      defined in [ETSI-TS-101-909-4], [ETSI-EN-300-001],
      [ETSI-EN-300-659-1], [ETSI-EN-300-324-1] and [ETSI-TR-101-183].

  I know that many IPCDN WG members are all participating in PackagetCable,
  so I assume that superseding (is that same as obsoleting in IETF
terms?)
  PacketCable documents is fine. But how about ITU-T and ETSI? Are they
  OK with the above statements?

- In section 4.1 I would use "MIB module" instead of "MIB"

- The groups listed in section 4.1 are not the same as the groups
  defined with the OBJECT-GROUP macros.

- Sect 4.3 states:
    pktcSigCompliances - this table has one object that has compliance
    statements for devices that implement Signaling on the MTA.

    pktcSigGroups - this table contains group of objects for the common
    portion of the PacketCable NCS and Signaling MIB.

    pktcInternationalGroup - this table extends this MIB Module by
    establishing a set of objects designed to support operations over
    the widest possible range of markets.

  while none of these 3 are "tables" in MIB speak.

- IN de MODULE-IDENTITY DESCRIPTION clause it states:

          Copyright (C) The Internet Society (2007). This version of
          this MIB module is part of RFC yyyy; see the RFC itself for
          full legal notices."

  That should be the new IETF Trust Copyright statement:

          Copyright (C) The IETF Trust (2007).  This version of this
          MIB module is part of RFC yyyy; see the RFC itself for full
          legal notices." 

- pktcNcsEndPntConfigTable and the objects in that table have a prefix of
  pktcNcs.... Why not pktcSigNcs....  ???
  Just to better avoid any future name clashes in other MIB modules .


Nits:

- I see:
  pktcSigDevEchoCancellation  OBJECT-TYPE
      SYNTAX      TruthValue
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          " This object specifies if the device is capable of echo
            cancellation."
      ::= { pktcSigDevObjects 2 }

  And so I assume that the value true(1) means that the device is
  capable of echo cancellation. I think it would be clearer if that
  were explicitly stated.

  There are more of such objects of SYNTAX TruthValue that could
  be clarified in a similar way.

- there are some strange control characters in the document.
  Specifically in the section titles, for example:


    9. ^M  IANA Considerations

- Security Considerations:

  Even if the network itself is secure (for example by using IPSec),

  pls change IPSec into IPsec which is the proper spelling and part of the
  latest security template.

---------------------------

references issues (found by my own tool):

!! Missing citation for Informative reference:
  P072 L048:    [ITU-T-E.180] ITU-T E.180: "Various Tones Used in
National Networks,

---------------------------

IDnits tells me:

    (See RFC 3967 for information about using normative references to
    lower-maturity documents in RFCs)
  -- Possible downref: Non-RFC (?) normative reference: ref.
'ITU-T-J169'

  -- Possible downref: Non-RFC (?) normative reference: ref.
'PKT-SP-CODEC'

  -- Possible downref: Non-RFC (?) normative reference: ref.
'PKT-SP-MGCP'

  -- Possible downref: Non-RFC (?) normative reference: ref.
'PKT-SP-PROV'

probably OK, just listing it for completeness.

Bert Wijnen

State Change Notice email list have been change to Richard_Woundy@cable.comcast.com, RWoundy@broadband.att.com, jf.mule@cablelabs.com,Randy_Presuhn@mindspring.com, sumanth@cablelabs.com from Richard_Woundy@cable.comcast.com, RWoundy@broadband.att.com, jf.mule@cablelabs.com,Randy_Presuhn@mindspring.com