From ipcdn-bounces@ietf.org Sun Jul 02 09:21:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx1sz-000664-E4; Sun, 02 Jul 2006 09:21:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx1sx-00065z-WD for ipcdn@ietf.org; Sun, 02 Jul 2006 09:21:16 -0400 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx1sw-00042C-6a for ipcdn@ietf.org; Sun, 02 Jul 2006 09:21:15 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k62DHhMe010493 for ; Sun, 2 Jul 2006 09:17:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [ipcdn] RFC 4547 on Event Notification Management Information Basefor Data over Cable Service Interface Specifications(DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems Date: Sun, 2 Jul 2006 16:21:10 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ipcdn] RFC 4547 on Event Notification Management Information Basefor Data over Cable Service Interface Specifications(DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems Thread-Index: Acacl9A5o1He2imgTQmnfntZQacWFgBQnjqA From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipcdn-bounces@ietf.org Congratulations to the editors, contributors, chairs and to the whole WG for the publication of this document.=20 Dan =20 -----Original Message----- From: rfc-editor@rfc-editor.org [mailto:rfc-editor@rfc-editor.org]=20 Sent: Saturday, July 01, 2006 1:52 AM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: ipcdn@ietf.org; rfc-editor@rfc-editor.org Subject: [ipcdn] RFC 4547 on Event Notification Management Information Basefor Data over Cable Service Interface Specifications(DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems A new Request for Comments is now available in online RFC libraries. =20 RFC 4547 Title: Event Notification Management Information Base=20 for Data over Cable Service Interface=20 Specifications (DOCSIS)-Compliant Cable Modems and=20 Cable Modem Termination Systems=20 Author: A. Ahmad, G. Nakanishi Status: Standards Track Date: June 2006 Mailbox: azlina@cisco.com,=20 gnakanishi@motorola.com Pages: 40 Characters: 83917 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipcdn-docsisevent-mib-06.txt URL: http://www.rfc-editor.org/rfc/rfc4547.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP) based event notification management of Data Over Cable Service Interface Specification (DOCSIS) compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Cable Device MIB. This memo specifies a MIB module in a manner that is compliant to the Structure of Management Information Version 2 (SMIv2). The set of objects is consistent with the SNMP framework and existing SNMP standards. [STANDARDS TRACK] This document is a product of the IP over Cable Data Network Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body=20 help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jul 06 23:45:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyhHF-0000F8-41; Thu, 06 Jul 2006 23:45:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyhHD-0000Da-LO for ipcdn@ietf.org; Thu, 06 Jul 2006 23:45:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyerU-00049a-Ll for ipcdn@ietf.org; Thu, 06 Jul 2006 21:10:28 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fye9h-00079o-Ik for ipcdn@ietf.org; Thu, 06 Jul 2006 20:25:16 -0400 Received: from ([10.20.62.13]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.22131657; Thu, 06 Jul 2006 20:24:58 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 20:24:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] WGLC on draft-ietf-ipcdn-pktc-signaling-11.txt to endJuly1st 2006 Date: Thu, 6 Jul 2006 20:24:57 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D967668AD@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ipcdn] WGLC on draft-ietf-ipcdn-pktc-signaling-11.txt to endJuly1st 2006 Thread-Index: AcaP68+fwbfnjLoQQ7qQONaSPjyJBgBZbMrwAoKE4LABfkiBQA== From: "Woundy, Richard" To: "Romascanu, Dan \(Dan\)" , X-OriginalArrivalTime: 07 Jul 2006 00:24:57.0942 (UTC) FILETIME=[C7004F60:01C6A15B] X-Spam-Score: -2.6 (--) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Cc: Jean-Francois Mule , "Woundy, Richard" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipcdn-bounces@ietf.org 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:dromasca@avaya.com]=20 Sent: Thursday, June 29, 2006 7:52 AM To: Jean-Francois Mule; ipcdn@ietf.org 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, ? 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 -- 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:jf.mule@cablelabs.com] > Sent: Friday, June 16, 2006 5:35 PM > To: ipcdn@ietf.org > 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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Wednesday, June 14, 2006 1:50 PM > > To: i-d-announce@ietf.org > > Cc: ipcdn@ietf.org > > 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 > > i-d-announce-request@ietf.org 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: > > mailserv@ietf.org. > > 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 > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jul 07 03:21:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FykeL-0007XR-RB; Fri, 07 Jul 2006 03:21:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FykeK-0007XL-Ig for ipcdn@ietf.org; Fri, 07 Jul 2006 03:21:16 -0400 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FykeI-0000jo-Qg for ipcdn@ietf.org; Fri, 07 Jul 2006 03:21:16 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k677HTGO009901 for ; Fri, 7 Jul 2006 03:17:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] WGLC on draft-ietf-ipcdn-pktc-signaling-11.txt to endJuly1st 2006 Date: Fri, 7 Jul 2006 10:21:11 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ipcdn] WGLC on draft-ietf-ipcdn-pktc-signaling-11.txt to endJuly1st 2006 Thread-Index: AcaP68+fwbfnjLoQQ7qQONaSPjyJBgBZbMrwAoKE4LABfkiBQAAQGyDA From: "Romascanu, Dan \(Dan\)" To: "Woundy, Richard" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be Cc: Jean-Francois Mule X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipcdn-bounces@ietf.org Hi Richard, Thanks for addressing my comments.=20 I suggest that at 11 you document better the object and mention the format that you referred in your explanation in the DESCRIPTION clause. I suggest that at 12 you rather than using DEFVAL you mention in the DESCRIPTION that you expect an agent to return those values after initialization, but it should be clear that such an action is performed at the instrumentation level, and not at the level of the SNMP agent. (what happens if the value is read by CLI?) The full MIB review is performed after the WG reaches consensus and the document is forwarded to the IESG.=20 I hope this helps.=20 Regards, Dan =20 =20 > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]=20 > Sent: Friday, July 07, 2006 3:25 AM > To: Romascanu, Dan (Dan); ipcdn@ietf.org > Cc: Jean-Francois Mule; Woundy, Richard > Subject: RE: [ipcdn] WGLC on=20 > draft-ietf-ipcdn-pktc-signaling-11.txt to endJuly1st 2006 >=20 > Dan, >=20 > Thanks for providing these comments. Do you have a projected=20 > date for a full MIB doctor review? >=20 > My personal (non-WG chair) responses to your comments are=20 > marked below with [RW]. >=20 > -- Rich >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, June 29, 2006 7:52 AM > To: Jean-Francois Mule; ipcdn@ietf.org > Subject: RE: [ipcdn] WGLC on=20 > draft-ietf-ipcdn-pktc-signaling-11.txt to endJuly1st 2006 >=20 >=20 > I did not perform a full MIB Doctor review, here are some=20 > comments from > a partial review: >=20 > 1. The title of the document includes twice the word 'signaling' - is > this necessary?=20 >=20 > [RW] I agree it seems to be redundant. I think occasionally=20 > folks refer > to "NCS signaling", which is also a redundant term. >=20 > 2. idnits complains about un-used references:=20 >=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);' >=20 > - 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' >=20 > [RW] These references do appear in the REFERENCE clauses of several > objects each, e.g. pktcSigPulseSignalTable and=20 > pktcSigPulseSignalType. I > suppose these two documents could be explicitly referenced in=20 > section 4, > to make the idnits issue go away. >=20 > 3. No need for the second paragraph in the Abstract. Anyway, this is > repeated in a 'boilerplate standard' manner in the=20 > Introduction section. >=20 > [RW] I agree. >=20 > 4. I believe that the following statement is confusing: >=20 > 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 >=20 > I would rather replace it with: >=20 > 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 >=20 > [RW] I agree. >=20 > 5. I could not understand what is meant by: >=20 > This MIB module also utilizes SNMP management MIB=20 > architecture from=20 > SNMP-FRAMEWORK-MIB [RFC3411].=20 >=20 > [RW] I believe this refers to the fact that the MIB module imports > SnmpAdminString as a TC for several MIB objects. Maybe the=20 > draft should > just state that. >=20 > 6. pktcSigNotification=20 > =20 > pktcSigNotification - this object is used for signaling=20 > notification=20 > and reserved for future use.=20 >=20 > This is not an object, but just an OID. Needs not any explanation >=20 > [RW] I agree. >=20 > 7. DESCRIPTION clause of pktcSigDevSilenceSuppression >=20 > " This object specifies if the device is capable of=20 > silence suppression (Voice Activity Detection)." =20 >=20 > Better say:=20 >=20 > " This object specifies if the device is capable of=20 > silence suppression (as result of Voice Activity > Detection)." =20 >=20 > [RW] I agree. >=20 > 8. DESCRIPTION clause of pktcSigDevCidSigProtocol =20 >=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=20 > protocols to=20 > support caller identification. Frequency shift=20 > keying (FSK)=20 > is most commonly used. Dual tone multi-frequency (DTMF)=20 > is an alternative."=20 >=20 > This object has a MAX-ACCESS clause of read-write. The DESCRIPTION > should rather say: >=20 > "This object is used to configure the subscriber=20 > line protocol > used=20 > for signaling on-hook caller id information. Different=20 > countries define different caller id signaling=20 > protocols to=20 > support caller identification.=20 > - setting this object at a value fsk(1) sets the=20 > subscriber > line protocol=20 > to be Frequency Shift Keying (FSK)=20 > - setting this object at a value dtmf(2) sets the=20 > subscriber > line protocol=20 > to be Dual tone multi-frequency (DTMF)."=20 >=20 > [RW] I agree. >=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 >=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. :^) >=20 > 10. It is not clear what value reserved(2) means in the=20 > PktcSigType TC. > 'for future use' does not make too much sense, if this value=20 > 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 >=20 > [RW] I agree. For example, we could not decide after publication that > 'reserved(2)' really meant 'sip'. >=20 > 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 >=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, > ? 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 -- 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:jf.mule@cablelabs.com] > Sent: Friday, June 16, 2006 5:35 PM > To: ipcdn@ietf.org > 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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Wednesday, June 14, 2006 1:50 PM > > To: i-d-announce@ietf.org > > Cc: ipcdn@ietf.org > > 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 > > i-d-announce-request@ietf.org 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: > > mailserv@ietf.org. > > 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 > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From aGuoha8u2X@mail.ru Wed Jul 12 09:53:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0f9L-0002I0-DT; Wed, 12 Jul 2006 09:53:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0f9L-0005rZ-C6; Wed, 12 Jul 2006 09:53:11 -0400 Received: from p213.54.82.250.tisdip.tiscali.de ([213.54.82.250] helo=user-j85iu5c8c2) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0f8p-0004xL-I7; Wed, 12 Jul 2006 09:52:41 -0400 Message-ID: <662161c80604uzm85hkrv7rmks42njzmmbh1x8nkggh6@mxs.mail.ru> Date: Wed, 12 Jul 2006 13:52:46 -0060 From: "Lillian Jacob" To: ion-archive@lists.ietf.org Subject: 45Y MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 2.1 (++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 "Stop the boot!" I said to Kirill. fury at failing. He fell backward, tumbled, slammed savagely into an trying to raise my price. By sunrise there were nearly a thousand birds standing outside the