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

["Romascanu, Dan (Dan)" <[e-mail]>]

Jean-Francois (as PROTO shepherd) and editors,

There probably needs to be a revised version of the document, but this
could until after the IETF LC, to see if we get any more comments. What
path do you prefer - do a fast revision now and enter the IETF LC with a
revised version, or proceed to IETF LC with the current version and
consider Bert's comments as initial LC comments? 

Dan


 
 

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[e-mail]] 
> Sent: Monday, August 06, 2007 1:28 PM
> To: Sumanth Channabasappa; [e-mail]; 
> Satish Kumar at Texas Instruments; [e-mail]
> Cc: Jean-Francois Mule; Richard Woundy @ Comcast; Romascanu, Dan (Dan)
> Subject: MIB Doctor review: 
> http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-sign
> aling-14.txt
> 
> [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