[ipcdn] MIB Doctor review: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-14.txt

["Wijnen, Bert \(Bert\)" <[e-mail]>]

[bcc: to MIB doctors list]

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:[e-mail]] 
> Sent: Thursday, June 21, 2007 1:11 AM
> To: Wijnen, Bert (Bert); [e-mail]; Satish 
> Kumar at Texas Instruments; [e-mail]
> 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


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