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

Dan,

Thanks for providing these comments. Do you have a projected date for a
full MIB doctor review?

My personal (non-WG chair) responses to your comments are marked below
with [RW].

-- Rich

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email protected]]=20
Sent: Thursday, June 29, 2006 7:52 AM
To: Jean-Francois Mule; [email protected]
Subject: RE: [ipcdn] WGLC on draft-ietf-ipcdn-pktc-signaling-11.txt to
endJuly1st 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

[RW] I agree it seems to be redundant. I think occasionally folks refer
to "NCS signaling", which is also a redundant term.

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'

[RW] These references do appear in the REFERENCE clauses of several
objects each, e.g. pktcSigPulseSignalTable and pktcSigPulseSignalType. I
suppose these two documents could be explicitly referenced in section 4,
to make the idnits issue go away.

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

[RW] I agree.

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

[RW] I agree.

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

[RW] I believe this refers to the fact that the MIB module imports
SnmpAdminString as a TC for several MIB objects. Maybe the draft should
just state that.

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

[RW] I agree.

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

[RW] I agree.

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

[RW] I agree.

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

[RW] Or alternatively, the pktcSignalingVersion is relevant only for a
particular pktcSignalingType value. As an example, the semantics of
pktcSignalingVersion "2.0" would depend on the value of
pktcSignalingType, say ncs(3) or sip(4) -- making up the latter
enumeration. :^)

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

[RW] I agree. For example, we could not decide after publication that
'reserved(2)' really meant 'sip'.

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

[RW] I agree with the concern, but I wonder if this object can be
salvaged. Authors: is the encoding of this object equivalent to the
encoding of the 'VendorExtensionParameter' on page 134 of the NCS
specification,
<http://www.packetcable.com/downloads/specs/PKT-SP-MGCP-I11-050812.pdf>?
That MGCP protocol syntax has a well-defined encoding, that could be
leveraged for the value of this MIB object as well.

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

[RW] I tend to agree, although this "overcommunication" approach has
been used in other drafts that have originated in this WG before. As one
specific example see 'pktcMtaDevDhcpServerAddressType' in
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-09.txt
> -- this draft is on the RFC Editor's Queue intended for proposed
standard; it was approved last February.

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 ...'

[RW] I agree.

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

[RW] I tend to agree, especially after reading sections 7.5 and 7.7 of
RFC 3410, and seeing RFC 3413 "Simple Network Management Protocol (SNMP)
Applications".

Dan


> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email protected]]
> 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
> 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
> 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
> > 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
> Base (MIB)
> > for use with network management protocols in the Internet community.

> > In particular, it provides a common data and format
> representation for
> > PacketCable and IPCablecom compliant Multimedia Terminal Adapter
> > devices.
> >=20
> > This memo specifies a MIB module in a manner that is
> compliant to the
> > SNMP SMIv2.  The set of objects are consistent with the
> SNMP framework
> > 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
> message to
> > [email protected] with the word unsubscribe in
> the body of
> > the message.
> > You can also visit
> 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
> > 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
> > 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
> 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
> > 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

_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn