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

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

Very well. I put the document in 'Revised ID Needed' and I am expecting
the new version. 

Thanks and Regards,

Dan


 
 

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

Dan,

   After consultation with Rich and Sumanth, we would prefer a revised
ID before IETF LC. Unless I hear otherwise, as a proto shepherd, I'll
assume a revised ID is to be submitted soon.

Jean-Francois.

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