RE: WGLC on draft-ietf-ipcdn-pktc-signaling-11.txt to end July1st 2006

I did not perform a full MIB Doctor review, here are some comments from
a partial review:

1. The title of the document includes twice the word 'signaling' - is
this necessary?=20

2. idnits complains about un-used references:=20

 - Unused Reference: 'ETSI-TS-101-909-4' is defined on line 3335, but
not
    referenced
    '   [ETSI-TS-101-909-4] ETSI TS 101 909-4:"Access and Terminals
(AT);'

  - Unused Reference: 'ETSI-EN-300-324-1' is defined on line 3354, but
not
    referenced
    '   [ETSI-EN-300-324-1] ETSI EN 300 324-1 V2.1.1 (2000-04):"V
Interfaces'

3. No need for the second paragraph in the Abstract. Anyway, this is
repeated in a 'boilerplate standard' manner in the Introduction section.


4. I believe that the following statement is confusing:

   This MIB module also utilizes the syntax definition of the=20
   Differentiated Services Code Point (DSCP) from DIFFSERV-DSCP-TC=20
   [RFC3289] for signaling MIB objects to allow for differentiation=20
   between various types of traffic in the service provider network.=20

I would rather replace it with:

   This MIB module also utilizes the syntax definition of the=20
   Differentiated Services Code Point (DSCP) TC from DIFFSERV-DSCP-TC=20
   [RFC3289] for defining MIB objects that allow for differentiation=20
   between various types of traffic in the service provider network.=20

5. I could not understand what is meant by:

   This MIB module also utilizes SNMP management MIB architecture from=20
   SNMP-FRAMEWORK-MIB [RFC3411].=20

6.    pktcSigNotification=20
   =20
   pktcSigNotification - this object is used for signaling notification=20
   and reserved for future use.=20

This is not an object, but just an OID. Needs not any explanation

7. DESCRIPTION clause of pktcSigDevSilenceSuppression

            " This object specifies if the device is capable of=20
             silence suppression (Voice Activity Detection)." =20

Better say:=20

           " This object specifies if the device is capable of=20
             silence suppression (as result of Voice Activity
Detection)." =20

8. DESCRIPTION clause of    pktcSigDevCidSigProtocol =20

           "This object identifies the subscriber line protocol used=20
            for signaling on-hook caller id information. Different=20
            countries define different caller id signaling protocols to=20
            support caller identification. Frequency shift keying (FSK)=20
            is most commonly used. Dual tone multi-frequency (DTMF)=20
            is an alternative."=20

This object has a MAX-ACCESS clause of read-write. The DESCRIPTION
should rather say:

          "This object is used to configure the subscriber line protocol
used=20
            for signaling on-hook caller id information. Different=20
            countries define different caller id signaling protocols to=20
            support caller identification.=20
            - setting this object at a value fsk(1) sets the subscriber
line protocol=20
            to be Frequency Shift Keying (FSK)=20
            - setting this object at a value dtmf(2) sets the subscriber
line protocol=20
            to be Dual tone multi-frequency (DTMF)."=20

9. I believe that pktcSignalingVersion has a significance only for
pktcSignalingType ncs(3). If true, this needs to be mentioned in the
object DESCRIPTION clause.=20

10. It is not clear what value reserved(2) means in the PktcSigType TC.
'for future use' does not make too much sense, if this value will become
meaningful in the future you cannot change the semantics of this
enumerated value. I suggest to skip this value and use only other and
ncs

11. It is not clear what level of interoperability can the
pktcSignalingVendorExtension object offer if the encoded string is
vendor specific. I suggest to take this oibject out.=20

12. It does not make sense to specify DEFVAL clauses for read-only
objects (pktcSigDefNcsReceiveUdpPort, pktcSigPowerRingFrequency). If
configuration by SNMP is not allowed, setting the instrumentation at the
desired state has not any relation with the SNMP agent.=20

13. Inconsistent use of keywords in the DESCRIPTION clause of
pktcSigDevToneDbLevel. Actually I believe that there is no place here
for a MUST. Instead of 'This MIB Object MUST reflect the desired
level...' rather say 'This MIB object reflects ...'

14. In several places the term 'SNMP Management Station' is being used.
I prefer 'SNMP Manager application'.=20

Dan


> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email protected]]=20
> Sent: Friday, June 16, 2006 5:35 PM
> To: [email protected]
> Subject: [ipcdn] WGLC on=20
> draft-ietf-ipcdn-pktc-signaling-11.txt to end July1st 2006
>=20
> Folks,
>=20
>    Rich and I would like to start a final WGLC last call on=20
> this ID given that the initial WGLC was done in 2004 and the=20
> draft has evolved since then.
>=20
>    Please send your comments to the authors and the ipcdn=20
> list by July 1st 2006.
>=20
> Rich and Jean-Francois.
>  IPCDN co-chairs.
>=20
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > Sent: Wednesday, June 14, 2006 1:50 PM
> > To: [email protected]
> > Cc: [email protected]
> > Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-signaling-11.txt
> >=20
> > A New Internet-Draft is available from the on-line Internet-Drafts=20
> > directories.
> > This draft is a work item of the IP over Cable Data Network Working=20
> > Group of the IETF.
> >=20
> > 	Title		: Network-Based Call Signaling (NCS) Signaling
> >                           MIB for PacketCable and IPCablecom
> >                           Multimedia Terminal Adapters (MTAs)
> > 	Author(s)	: G. Beacham, et al.
> > 	Filename	: draft-ietf-ipcdn-pktc-signaling-11.txt
> > 	Pages		: 71
> > 	Date		: 2006-6-14
> >=20
> > This memo defines a portion of the Management Information=20
> Base (MIB)=20
> > for use with network management protocols in the Internet community.
> > In particular, it provides a common data and format=20
> representation for=20
> > PacketCable and IPCablecom compliant Multimedia Terminal Adapter=20
> > devices.
> >=20
> > This memo specifies a MIB module in a manner that is=20
> compliant to the=20
> > SNMP SMIv2.  The set of objects are consistent with the=20
> SNMP framework=20
> > and existing SNMP standards.
> >=20
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-
> > 11.txt
> >=20
> > To remove yourself from the I-D Announcement list, send a=20
> message to=20
> > [email protected] with the word unsubscribe in=20
> the body of=20
> > the message.
> > You can also visit=20
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >=20
> >=20
> > Internet-Drafts are also available by anonymous FTP. Login with the=20
> > username "anonymous" and a password of your e-mail address. After=20
> > logging in, type "cd internet-drafts" and then
> > 	"get draft-ietf-ipcdn-pktc-signaling-11.txt".
> >=20
> > A list of Internet-Drafts directories can be found in=20
> > http://www.ietf.org/shadow.html or=20
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >=20
> >=20
> > Internet-Drafts can also be obtained by e-mail.
> >=20
> > Send a message to:
> > 	[email protected].
> > In the body type:
> > 	"FILE /internet-drafts/draft-ietf-ipcdn-pktc-signaling-11.txt".
> >=20
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant=20
> mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> >=20
> >=20
> > Below is the data which will enable a MIME compliant mail reader=20
> > implementation to automatically retrieve the ASCII version of the=20
> > Internet-Draft.
>=20
>=20
> _______________________________________________
> IPCDN mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipcdn
>=20