From ipcdn-bounces@ietf.org Wed Feb 01 09:55:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4JNy-0007jz-7J; Wed, 01 Feb 2006 09:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4JNt-0007fe-RU for ipcdn@megatron.ietf.org; Wed, 01 Feb 2006 09:55:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05329 for ; Wed, 1 Feb 2006 09:53:22 -0500 (EST) Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4JZ3-0000Ds-KR for ipcdn@ietf.org; Wed, 01 Feb 2006 10:06:34 -0500 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Feb 2006 09:52:57 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302D0938A@PACDCEXCMB01.cable.comcast.com> Thread-Topic: Request for publication and PROTO writeup for draft-ietf-ipcdn-docs-rfmibv2-14.txt on the standards track Thread-Index: AcYmepK/ToG1UhZpQraa5ecg4qp8LAAxJ2T4 From: "Woundy, Richard" To: "Wijnen, Bert \(Bert\)" X-OriginalArrivalTime: 01 Feb 2006 14:54:27.0446 (UTC) FILETIME=[6601E160:01C6273F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: quoted-printable Cc: Eduardo Cardona , "Ipcdn \(E-mail\)" Subject: [ipcdn] RE: Request for publication and PROTO writeup for draft-ietf-ipcdn-docs-rfmibv2-14.txt on the standards track 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: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org I got the following response from the iesg-secretary. =20 >The draft is already in the I-D Tracker in Stae AD Evaluation. =20 Can we still initiate an IETF Last Call? =20 -- Rich ________________________________ From: Woundy, Richard Sent: Tue 1/31/2006 10:25 AM To: Wijnen, Bert (Bert); iesg-secretary@ietf.org Cc: Eduardo Cardona; Ipcdn (E-mail) Subject: Request for publication and PROTO writeup for = draft-ietf-ipcdn-docs-rfmibv2-14.txt on the standards track Bert and all,=20 This note is the request for publication and proto write-up for the = IPCDN DOCSIS RFIv2 MIB internet-draft, = draft-ietf-ipcdn-docs-rfmibv2-14.txt, as a Proposed Standard. If you have any questions or concerns with the above, please send email = to the IPCDN list.=20 Thank you Eugene for your continued efforts and big thanks to Randy, = Bert et al. for the detailed and constructive MIB doctor and expert = reviews. Richard Woundy=20 IPCDN Co-Chair=20 The PROTO process (cf. draft-ietf-proto-wgchair-doc-shepherding-05.txt) = is being used for the IPCDN DOCSIS RFIv2 MIB internet-draft. Here is the proposed PROTO writeup for:=20 Radio Frequency (RF) Interface Management Information Base for DOCSIS = 2.0 compliant RF interfaces=20 (draft-ietf-ipcdn-docs-rfmibv2-14.txt)=20 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-14.txt = Requested Publication Status: Proposed Standard=20 Obsoletes: RFC 2670=20 PROTO shepherd: Richard Woundy (IPCDN WG Co-Chair)=20 ------------------------------------------------------------------------ = 1.a) Have the chairs personally reviewed this version of the Internet = Draft (ID), and in particular, do they believe this ID is ready=20 to forward to the IESG for publication?=20 Yes.=20 Both IPCDN co-chairs reviewed this version of the ID. Based on the WG = comments, MIB doctors & AD review comments, we believe the ID is ready = for publication. 1.b) Has the document had adequate review from both key WG members=20 and key non-WG members?=20 Yes, there have been reviews from both subject-matter experts that are = WG members and MIB doctors who provided valuable comments to improve the = quality of the MIB module. Do you have any concerns about the=20 depth or breadth of the reviews that have been performed?=20 No, given the time this ID has been in existence and the number of = revisions due to comments.=20 1.c) Do you have concerns that the document needs more review from a=20 particular (broader) perspective (e.g., security, operational=20 complexity, someone familiar with AAA, etc.)?=20 No.=20 1.d) Do you have any specific concerns/issues with this document that = you believe the ADs and/or IESG should be aware of? For=20 example, perhaps you are uncomfortable with certain parts of the = document, or have concerns whether there really is a need for=20 it. In any event, if your issues have been discussed in the WG=20 and the WG has indicated it that it still wishes to advance the=20 document, detail those concerns in the write-up.=20 No. The internet-draft was produced prior to the IETF 64 meeting, based = on comments from the AD review. No further issues were raised on this = internet-draft at the IETF 64 meeting, nor subsequently on the WG = mailing list. There are no other concerns from the PROTO shepherd. 1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it?=20 This document represents the WG consensus as a whole: the WG as a whole = understands and agrees with it.=20 1.f) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in=20 separate email to the Responsible Area Director.=20 No. An explicit request for intent to appeal was made on the list on = January 10 2006.=20 1.g) Have the chairs verified that the document adheres to all of the = ID nits? (see http://www.ietf.org/ID-Checklist.html).=20 There are no ID nits issues per the automated ID nits check (version = 1.82) at:=20 =20 1.h) Is the document split into normative and informative references? = Yes.=20 Are there normative references to IDs, where the IDs are not=20 also ready for advancement or are otherwise in an unclear state? = (note here that the RFC editor will not publish an RFC with=20 normative references to IDs, it will delay publication until all = such IDs are also ready for publication as RFCs.)=20 No.=20 1.i) For Standards Track and BCP documents, the IESG approval=20 announcement includes a write-up section with the following=20 sections:=20 * Technical Summary=20 * Working Group Summary=20 * Protocol Quality=20 1.j) Please provide such a write-up. Recent examples can be found in = the "protocol action" announcements for approved documents.=20 --- Technical Summary=20 This document is a revision of the standards track RFC 2670, and=20 defines a portion of the Management Information Base (MIB) for=20 use with network management protocols in the Internet community.=20 In particular, it defines a set of managed objects for SNMP-based=20 management of the Radio Frequency (RF) interfaces for systems=20 compliant with the Data Over Cable Service Interface Specifications=20 (DOCSIS).=20 --- Working Group Summary=20 The Working Group has consensus to publish this document as a=20 Proposed Standard.=20 --- Protocol Quality=20 =20 The MIB module has been reviewed by Randy Presuhn. The overall = quality=20 with respect to DOCSIS functionality has been reviewed by many=20 IPCDN technical experts. This document has been reviewed for the IESG = by=20 Bert Wijnen.=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Feb 07 11:10:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6VQJ-0001Xj-HM; Tue, 07 Feb 2006 11:10:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6VQE-0001W5-52 for ipcdn@megatron.ietf.org; Tue, 07 Feb 2006 11:10:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07084 for ; Tue, 7 Feb 2006 11:08:39 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6VcW-0005LS-95 for ipcdn@ietf.org; Tue, 07 Feb 2006 11:23:12 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k17GAAuR019682; Tue, 7 Feb 2006 10:10:11 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 7 Feb 2006 17:10:09 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509433794@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Woundy, Richard" Date: Tue, 7 Feb 2006 17:10:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: Eduardo Cardona , "Ipcdn \(E-mail\)" Subject: [ipcdn] RE: Request for publication and PROTO writeup for draft-ietf-ipcd n-docs-rfmibv2-14.txt on the standards track 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: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org I will try to get onto this one this week Bert > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Wednesday, February 01, 2006 15:53 > To: Wijnen, Bert (Bert) > Cc: Eduardo Cardona; Ipcdn (E-mail) > Subject: RE: Request for publication and PROTO writeup for > draft-ietf-ipcdn-docs-rfmibv2-14.txt on the standards track > > > I got the following response from the iesg-secretary. > > >The draft is already in the I-D Tracker in Stae AD Evaluation. > > Can we still initiate an IETF Last Call? > > -- Rich > > ________________________________ > > From: Woundy, Richard > Sent: Tue 1/31/2006 10:25 AM > To: Wijnen, Bert (Bert); iesg-secretary@ietf.org > Cc: Eduardo Cardona; Ipcdn (E-mail) > Subject: Request for publication and PROTO writeup for > draft-ietf-ipcdn-docs-rfmibv2-14.txt on the standards track > > > > Bert and all, > > This note is the request for publication and proto write-up > for the IPCDN DOCSIS RFIv2 MIB internet-draft, > draft-ietf-ipcdn-docs-rfmibv2-14.txt, as a Proposed Standard. > > If you have any questions or concerns with the above, please > send email to the IPCDN list. > > Thank you Eugene for your continued efforts and big thanks to > Randy, Bert et al. for the detailed and constructive MIB > doctor and expert reviews. > > Richard Woundy > IPCDN Co-Chair > > > The PROTO process (cf. > draft-ietf-proto-wgchair-doc-shepherding-05.txt) is being > used for the IPCDN DOCSIS RFIv2 MIB internet-draft. > > Here is the proposed PROTO writeup for: > > Radio Frequency (RF) Interface Management Information Base > for DOCSIS 2.0 compliant RF interfaces > (draft-ietf-ipcdn-docs-rfmibv2-14.txt) > > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmi > bv2-14.txt > > > Requested Publication Status: Proposed Standard > Obsoletes: RFC 2670 > PROTO shepherd: Richard Woundy (IPCDN WG Co-Chair) > -------------------------------------------------------------- > ---------- > > 1.a) Have the chairs personally reviewed this version of > the Internet > Draft (ID), and in particular, do they believe this > ID is ready > to forward to the IESG for publication? > > Yes. > > Both IPCDN co-chairs reviewed this version of the ID. Based > on the WG comments, MIB doctors & AD review comments, we > believe the ID is ready for publication. > > 1.b) Has the document had adequate review from both key WG members > and key non-WG members? > > Yes, there have been reviews from both subject-matter experts > that are WG members and MIB doctors who provided valuable > comments to improve the quality of the MIB module. > > Do you have any concerns about the > depth or breadth of the reviews that have been performed? > > No, given the time this ID has been in existence and the > number of revisions due to comments. > > 1.c) Do you have concerns that the document needs more > review from a > particular (broader) perspective (e.g., security, operational > complexity, someone familiar with AAA, etc.)? > > No. > > 1.d) Do you have any specific concerns/issues with this > document that > you believe the ADs and/or IESG should be aware of? For > example, perhaps you are uncomfortable with certain > parts of the > document, or have concerns whether there really is a need for > it. In any event, if your issues have been discussed > in the WG > and the WG has indicated it that it still wishes to > advance the > document, detail those concerns in the write-up. > > No. The internet-draft was produced prior to the IETF 64 > meeting, based on comments from the AD review. No further > issues were raised on this internet-draft at the IETF 64 > meeting, nor subsequently on the WG mailing list. There are > no other concerns from the PROTO shepherd. > > 1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? > > This document represents the WG consensus as a whole: the WG > as a whole understands and agrees with it. > > 1.f) Has anyone threatened an appeal or otherwise > indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email to the Responsible Area Director. > > No. An explicit request for intent to appeal was made on the > list on January 10 2006. > > 1.g) Have the chairs verified that the document adheres to > all of the > ID nits? (see http://www.ietf.org/ID-Checklist.html). > > There are no ID nits issues per the automated ID nits check > (version 1.82) at: > 1.h) Is the document split into normative and informative references? Yes. Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) No. 1.i) For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary * Working Group Summary * Protocol Quality 1.j) Please provide such a write-up. Recent examples can be found in the "protocol action" announcements for approved documents. --- Technical Summary This document is a revision of the standards track RFC 2670, and defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP-based management of the Radio Frequency (RF) interfaces for systems compliant with the Data Over Cable Service Interface Specifications (DOCSIS). --- Working Group Summary The Working Group has consensus to publish this document as a Proposed Standard. --- Protocol Quality The MIB module has been reviewed by Randy Presuhn. The overall quality with respect to DOCSIS functionality has been reviewed by many IPCDN technical experts. This document has been reviewed for the IESG by Bert Wijnen. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Feb 08 10:51:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ray-0000gW-Nn; Wed, 08 Feb 2006 10:51:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6rau-0000fn-IV; Wed, 08 Feb 2006 10:51:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02850; Wed, 8 Feb 2006 10:49:18 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6rnX-00012F-F6; Wed, 08 Feb 2006 11:04:03 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F6rat-00034k-UQ; Wed, 08 Feb 2006 10:50:59 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 08 Feb 2006 10:50:59 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipcdn@ietf.org Subject: [ipcdn] Last Call: 'Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces' to Proposed Standard X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org The IESG has received a request from the IP over Cable Data Network WG to consider the following document: - 'Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces ' as a Proposed Standard This document obsoletes RFC2670 (when approved). The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-14.txt _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Feb 10 10:32:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7aFx-0005il-OI; Fri, 10 Feb 2006 10:32:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7aFv-0005iH-OA for ipcdn@megatron.ietf.org; Fri, 10 Feb 2006 10:32:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28176 for ; Fri, 10 Feb 2006 10:30:26 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7aSl-0004Zz-Ot for ipcdn@ietf.org; Fri, 10 Feb 2006 10:45:37 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id k1AFVtKd022915 for ; Fri, 10 Feb 2006 08:31:56 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Feb 2006 08:31:55 -0700 Message-ID: Thread-Topic: Feedback: draft-ietf-ipcdn-pktc-signaling-09 Thread-Index: AcW4Oh5u5tc0GTuWR766dY3dv5P9mgAS0T+QHXPgu0A= From: "Sumanth Channabasappa" To: "Ipcdn (E-mail)" X-Approved: ondar X-Spam-Score: 0.5 (/) X-Scan-Signature: d273fad2623d4a35a7bb17d92c76f399 Subject: [ipcdn] Feedback: draft-ietf-ipcdn-pktc-signaling-09 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: , Content-Type: multipart/mixed; boundary="===============0402046833==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============0402046833== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62E57.1FCE5921" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62E57.1FCE5921 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 I am sending across this email to solicit feedback on "draft-ietf-ipcdn-pktc-signaling-09" (ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-09.t xt) =20 The comments I have received thus far include: =20 a) Proposal to modify the current draft to allow for DTMF to be used fo VMWI (it currently assumes FSK)
=20 b) Preservation of contiguous numbering (editorial?) Details can be found at: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01812.html =20 c) Offline comments on the need for distinction between CID v/s VMWI (Phil, can you post more details on that)? =20 If resolutions to the above issues are agreed upon, I plan to propose a new draft revision as early as next week. =20 =20 regards Sumanth =20 =20 --------------- Usage of DTMF and FSK for VMWI (source: Eugene Nechamkin, via email) There are currently four CallerID signalling methods defined in Telco specs. They are: =20 1. Class I with FSK 2. Class I with DTMF 3. VMWI with FSK 4. VMWI with DTMF =20 While the current draft-09 contains the means of defining the 1st two (via "pktcSigDevCallerIdSigProtocol" MIB Object), it does not allow to choose the protocol for VMWI. The draft always assumes that for VMWI, it's always FSK method which is used. =20 We found that in some countries (e.g. Denmark) the #4 method is required (as per "TDK-TS 900 301-5"). There are also other contries which require VMWI with DTMF (Brazil, Sweden, Netherlands). Here is the quotation from the document: =20 The MWI supplementary service enables the served user to receive an indication when a message has been delivered to the user's mailbox.=20 NOTE: The MWI supplementary service can currently only be used in conjunction with one of TDC Tele Danmark's public voice-mailbox services. The served user can receive a message waiting indication from the VMS in two different ways: a) Deferred mode: when the MWI supplementary service is activated and the served user makes an outgoing call attempt, the served user is notified by means of announcement; and/or; =20 b) Immediate mode: when the MWI supplementary service has been activated, the served user is notified by means of DTMF based signalling. The intention with this notification is to give the user's terminal the opportunity to visually indicate to the user (e.g. by means of an indication lamp) that a new message has been delivered to the VMS. Assuming that everybody agrees that this is a deficiency of the current draft-09, the following new MIB object is proposed to fix that: =20 pktcSigDevVmwiSigProtocol OBJECT-TYPE =20 SYNTAX INTEGER {=20 fsk (1),=20 dtmf (2)=20 }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 "This object identifies the subscriber line protocol used=20 for signalling the Information on Visual Message Waiting Indicator (VMWI).=20 Different countries define different VMWI signalling protocols to=20 support VMWI service. Frequency shift keying (FSK)=20 is most commonly used. Dual tone multi-frequency (DTMF)=20 is an alternative."=20 DEFVAL { fsk }=20 ::=3D { pktcSigDevConfigObjects X } =20 ------------------------------------------------------------------------ ---------------------------------------------------------- =20 =20 =20 ------_=_NextPart_001_01C62E57.1FCE5921 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks,
=
 
I am = sending=20 across this email to solicit feedback on = "draft-ietf-ipcdn-pktc-signaling-09"=20 (ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signal= ing-09.txt)
 
The comments I have received thus far=20 include:
 
a) Proposal to modify the current = draft to allow=20 for DTMF to be used fo VMWI (it currently assumes=20 FSK)
<Details=20 enclosed at the end of this=20 email>
<= /SPAN> 
b) Preservation of contiguous numbering=20 (editorial?)
Details can be found at: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01812.html
 
c) Offline comments on the need for = distinction between=20 CID v/s VMWI (Phil, can you post more details on=20 that)?<= /SPAN>
<= /SPAN> 
If=20 resolutions to the above issues are agreed upon, I plan to propose a new = draft=20 revision as early as next=20 week.  
<= /SPAN> 
 regards<= /SPAN>
Sumanth=
<= /SPAN> 
 
--------------- Usage = of DTMF and=20 FSK for VMWI  (source: Eugene Nechamkin, via=20 email)
There are currently four CallerID=20 signalling methods defined in Telco specs. They=20 are:
 
1. Class I with FSK
2. Class I with DTMF
3. VMWI with FSK
4. VMWI with DTMF
 
While the current = draft-09 contains=20 the means of defining the 1st two (via "pktcSigDevCallerIdSigProtocol" = MIB=20 Object), it does not allow to choose the protocol for VMWI. The draft = always=20 assumes that for VMWI, it's always FSK method which is=20 used.
 
We = found that in=20 some countries (e.g. Denmark) the #4 method is required (as per "TDK-TS 900 301-5"). There are also other contries which require = VMWI with=20 DTMF (Brazil, Sweden, Netherlands). Here is the quotation from the=20 document:
 

The MWI supplementary service = enables the served=20 user to receive an indication when a message has been delivered to the = user's=20 mailbox.

NOTE:        =20 The MWI supplementary service can currently only be used in = conjunction=20 with one of TDC Tele Danmark’s public voice-mailbox = services.

The served user can receive a = message waiting=20 indication from the VMS in two different ways:

a)       = Deferred mode: when the MWI=20 supplementary service is activated and the served user makes an outgoing = call=20 attempt, the served user is notified by means of announcement;=20 and/or;

 

b)       = Immediate mode: when the MWI=20 supplementary service has been activated, the = served user is=20 notified by means of DTMF based signalling. The intention with = this=20 notification is to give the user’s terminal the opportunity to = visually indicate=20 to the user (e.g. by means of an indication lamp) that a new message has = been=20 delivered to the VMS.

Assuming that = everybody=20 agrees that this is a deficiency of the current draft-09, the following = new MIB=20 object is proposed to fix that:
 
pktcSigDevVmwiSigProtocol  = OBJECT-TYPE =20
      =20 SYNTAX       INTEGER {=20
           &nb= sp;           &nbs= p;   =20 fsk  (1),=20
           &nb= sp;           &nbs= p;   =20 dtmf (2)
       }=20
       MAX-ACCESS   = read-write =20
      =20 STATUS       current =20
       DESCRIPTION =20
           "This = object=20 identifies the subscriber line protocol used=20
            = for=20 signalling the Information on = Visual Message Waiting Indicator=20 (VMWI). 
        &= nbsp;  =20 Different countries define different VMWI=20 signalling protocols to=20
            = support=20 VMWI service. Frequency shift = keying (FSK)=20
            = is most=20 commonly used. Dual tone multi-frequency (DTMF)=20
            = is an=20 alternative." 
        DEFVAL = { fsk }=20
   ::=3D { pktcSigDevConfigObjects X = }
&nbs= p;
----------------------------------------------= -------------------------------------------------------------------------= -----------
 
 
 
=
<= /SPAN> ------_=_NextPart_001_01C62E57.1FCE5921-- --===============0402046833== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0402046833==-- From ipcdn-bounces@ietf.org Fri Feb 10 10:38:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7aMC-0007TS-IG; Fri, 10 Feb 2006 10:38:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7aMB-0007S1-6d for ipcdn@megatron.ietf.org; Fri, 10 Feb 2006 10:38:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29137 for ; Fri, 10 Feb 2006 10:37:03 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7aZB-0004vE-Dx for ipcdn@ietf.org; Fri, 10 Feb 2006 10:52:14 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id k1AFcZ8b024021 for ; Fri, 10 Feb 2006 08:38:36 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Feb 2006 08:38:35 -0700 Message-ID: Thread-Topic: Feedback: draft-ietf-ipcdn-pktc-eventmess-05.txt Thread-Index: AcWh/HKIom44+HHgQGa23DAUEop9nw+NasHQE4lZg/A= From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Feedback: draft-ietf-ipcdn-pktc-eventmess-05.txt 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: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Folks, I have not received any comments on the "PacketCable/IPCablecom Management Event MIB" draft-05 (ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-05.t xt) I would request folks on this mailing list to review and bring to my attention any questions, comments or suggestions (apologies if I missed any comments, don't recall any on this mailing list). The last email on this topic was a summary of changes from draft-04 and can be found at: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01810.html (Nov 2, 2005) Thanks! Sumanth _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Feb 10 20:09:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7jGU-0001TU-Me; Fri, 10 Feb 2006 20:09:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7jGT-0001K1-96 for ipcdn@megatron.ietf.org; Fri, 10 Feb 2006 20:09:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26423 for ; Fri, 10 Feb 2006 20:07:39 -0500 (EST) Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7jTQ-0003FY-UE for ipcdn@ietf.org; Fri, 10 Feb 2006 20:22:55 -0500 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 10 Feb 2006 17:10:13 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 878242AF; Fri, 10 Feb 2006 17:08:48 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 7280E2AE for ; Fri, 10 Feb 2006 17:08:48 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id CXB76926; Fri, 10 Feb 2006 17:08:47 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 15F4420501 for ; Fri, 10 Feb 2006 17:08:47 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Feb 2006 17:08:39 -0800 Message-ID: <9C5C578DD43AFD4EA7A9F0BDB2F4856472C232@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: DEFVAL for pktcSigDevVmwiMode in draft--09 Thread-Index: AcW4Oh5u5tc0GTuWR766dY3dv5P9mgAS0T+QHXPgu0AAFAWAYA== From: "Eugene Nechamkin" To: "Ipcdn (E-mail)" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006021010; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230322E34334544333734302E303031352D452D53446B4565396F2B417A52344D4934777341474569673D3D; ENG=IBF; TS=20060211011014; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006021010_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FF3E6FF41W9092640-01-01 X-Spam-Score: 0.2 (/) X-Scan-Signature: 089da5e32269fece1072c9ff54523f20 Subject: [ipcdn] DEFVAL for pktcSigDevVmwiMode in draft--09 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: , Content-Type: multipart/mixed; boundary="===============0626459409==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============0626459409== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62EA7.B1E40A78" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62EA7.B1E40A78 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable There seems to be the following issue which draft's authors might want to also consider in the course of ongoing draft's review. =20 The default value for pktcSigDevVmwiMode MIB Object currently defines "dtAsETS" as the default alerting method. On the other hand, the default value for the pktcSigDevCIDMode MIB Object currently defines the "rpAsETS" as the default method for CallerID. =20 As Caller ID and VMWI functionality, in most cases, are embodied into a single device, and no country, in practice, uses different alerting methods for the two at the same time, it does not make much sense to require two different alerting methods as the default values for Caller ID and VMWI. =20 As a matter of fact, there are very few countries that deploy "dtas" alerting for VMWI (Denmark, Brazil) but they, anyway, require "dtmf" signaling protocol, rather than the "fsk" one currently defined as the default signaling method in draft-09. =20 To improve the consistency of the MIB and convenience for Operators in the field, the following is proposed: the default value of pktcSigDevVmwiMode MIB Object should be "rpAsETS", rather than "dtAsETS": =20 pktcSigDevVmwiMode OBJECT-TYPE=20 =20 SYNTAX INTEGER {=20 ..................................... DEFVAL { rpAsETS }=20 ::=3D {pktcSigDevConfigObjects 27 }=20 =20 =20 Regards, =20 Eugene. =20 ------_=_NextPart_001_01C62EA7.B1E40A78 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
There seems to be the following issue which = draft's=20 authors might want to also consider in the course of ongoing draft's=20 review.
 
The = default value for=20 pktcSigDevVmwiMode MIB Object currently defines "dtAsETS" as the default = alerting method. On the other hand, the default value for the = pktcSigDevCIDMode=20 MIB Object currently defines the "rpAsETS" as the default method for=20 CallerID.<= /o:!>
<= /o:!> 
As = Caller ID and VMWI=20 functionality, in most cases, are embodied into a single device, and no = country,=20 in practice, uses different alerting methods for the two at the same = time, it=20 does not make much sense to require two different alerting methods as = the=20 default values for Caller ID and=20 VMWI.=
<= /o:!> 
As a = matter of fact,=20 there are very few countries that deploy "dtas" alerting for VMWI = (Denmark,=20 Brazil) but they, anyway, require "dtmf" signaling protocol, rather than = the=20 "fsk" one currently defined as the default signaling method in=20 draft-09.<= /o:!>
 
To improve = the=20 consistency of the MIB and convenience for Operators in the field, the = following=20 is proposed: the=20 default = value of=20 pktcSigDevVmwiMode MIB Object should be "rpAsETS", rather than=20 "dtAsETS":= <= /o:p>
 
pktcSigDevVmwiMode=20 OBJECT-TYPE=20
<= /SPAN> 
   =20 SYNTAX INTEGER {=20
   =20 .....................................<= /SPAN><= /SPAN>
   =20 DEFVAL { rpAsETS }=20
    ::=3D=20 {pktcSigDevConfigObjects 27 }=20
<= /SPAN> 
<= /SPAN> 
Regards,= =
<= /SPAN> 
Eugene.<= /SPAN><= /o:p>
 
------_=_NextPart_001_01C62EA7.B1E40A78-- --===============0626459409== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0626459409==-- From ipcdn-bounces@ietf.org Mon Feb 20 12:51:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBFCA-0000Ls-5F; Mon, 20 Feb 2006 12:51:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBFC8-0000Lk-OG for ipcdn@ietf.org; Mon, 20 Feb 2006 12:51:32 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBFC1-0006lG-Kq for ipcdn@ietf.org; Mon, 20 Feb 2006 12:51:29 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id k1KHpOU3029884 for ; Mon, 20 Feb 2006 10:51:24 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 20 Feb 2006 10:51:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed changes: draft-ietf-ipcdn-pktc-signaling-09 Thread-Index: AcW4Oh5u5tc0GTuWR766dY3dv5P9mgAS0T+QHXPgu0AB/EOD4A== From: "Sumanth Channabasappa" To: "Ipcdn (E-mail)" X-Approved: ondar X-Spam-Score: 0.2 (/) X-Scan-Signature: 8500135f65d7c251ba11be3bcad20d45 Subject: [ipcdn] Proposed changes: draft-ietf-ipcdn-pktc-signaling-09 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: , Content-Type: multipart/mixed; boundary="===============0844257936==" Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============0844257936== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63646.44008D06" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63646.44008D06 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 Based on the findings of Eugene and Phil (earlier mail enclosed at the end of this email), the following changes have been proposed (by Phil - thanks!) to draft-09 of the IETF Signaling MIB draft. I plan to submit a new draft soon (with the proposed changes) and hence comments and concerns would be appreciated at the earliest (I have not received any feedback on the IPCDN reflector with reference to earlier emails resulting in this proposal). =20 =20 Thanks! Sumanth New objects: =20 pktcSigDevVmwiSigProtocol OBJECT-TYPE =20 SYNTAX INTEGER {=20 fsk (1),=20 dtmf (2)=20 }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 "This object identifies the subscriber line protocol used=20 for signaling the Information on Visual Message Waiting=20 Indicator(VMWI). Different countries define different VMWI=20 signaling protocols to support VMWI service. Frequency shift=20 keying (FSK) is most commonly used. Dual tone multi- frequency (DTMF) is an alternative."=20 DEFVAL { fsk }=20 ::=3D { pktcSigDevConfigObjects X } =20 pktcSigDevCIDModePreamble OBJECT-TYPE =20 SYNTAX INTEGER {=20 DTMFcodeA (1), DTMFcodeB (2), DTMFcodeC (3), DTMFcodeD (4) }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 " This object identifies the subscriber line protocol used=20 for signaling caller id information. Different countries=20 define different caller id signaling protocols to support=20 caller identification. When Dual tone multi-frequency (DTMF)=20 is used the CID digits are preceeded by a pre-amble digit =20 .........=20 the digit transmission sequence ... Digits (0 - 9) The DTMF code "B" may be sent by the network as start code=20 for the transfer of information values,through which special events can be indicated to the user."=20 DEFVAL { DTMFcodeA }=20 ::=3D { pktcSigDevConfigObjects X } =20 =20 pktcSigDevCIDModePostamble OBJECT-TYPE =20 SYNTAX INTEGER {=20 DTMFcodeA (1), DTMFcodeB (2), DTMFcodeC (3), DTMFcodeD (4) }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 " This object identifies the subscriber line protocol used=20 for signaling caller id information. Different countries=20 define different caller id signaling protocols to support=20 caller identification. When Dual tone multi-frequency (DTMF)=20 is used the CID digits are followed by a post amble digit .........=20 the digit transmission sequence ... Digits (0 - 9) The DTMF code "B" may be sent by the network as start code=20 for the transfer of information values,through which special=20 events can be indicated to the user."=20 DEFVAL { DTMFcodeC }=20 ::=3D { pktcSigDevConfigObjects X } =20 =20 pktcSigDevCPEDisplay OBJECT-TYPE =20 SYNTAX INTEGER {=20 SI(1),=20 SO(2),=20 }=20 MAX-ACCESS read-write=20 STATUS current =20 DESCRIPTION =20 "The display format varies in some locations from the normal=20 alphanumeric characters (SI) to Katakana graphics (SO)=20 display based on user preferences. This element sets a CPE=20 signaling protocol byte to indicate to the CPE device the=20 proper format for the display of CID or VMWI messages. =20 Reference ITU T.50 A.1.27 and A.1.28 point to ISO 2022=20 (refer to RFC 1468)"=20 DEFVAL {SI} =20 ::=3D {pktcSigDevConfigObjects x } =20 =20 =20 Additionally, it has been proposed that the name and/or description of the following MIB Objects be changed to incorporate usage of DTMF and FSK. - pktcSigDevCIDFskAfterRing to pktcSigDevCIDAfterRing; + description - pktcSigDevCIDFskAfterDTAS to pktcSigDevCIDAfterDTAS; + description - pktcSigDevCIDFskAfterRPAS to pktcSigDevCIDAfterRPAS; + description - pktcSigDevCIDRingAfterFsk to pktcSigDevCIDRingAfterCID; + description - pktcSigDevVmwiFskAfterDTAS to pktcSigDevVmwiAfterDTAS; + description - pktcSigDevVwmiFskAfterRPAS to pktcSigDevVwmiAfterRPAS;=20 + description - pktcSigDevVwmiFskDTASAfterLR to pktcSigDevVwmiDTASAfterLR; + description - pktcSigDevCIDMode (description) =20 - pktcSigDevVmwiMode (description) =20 _____ =20 From: Sumanth Channabasappa=20 Sent: Friday, February 10, 2006 8:32 AM To: Ipcdn (E-mail) Subject: [ipcdn] Feedback: draft-ietf-ipcdn-pktc-signaling-09 Folks, =20 I am sending across this email to solicit feedback on "draft-ietf-ipcdn-pktc-signaling-09" (ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-09.t xt) =20 The comments I have received thus far include: =20 a) Proposal to modify the current draft to allow for DTMF to be used fo VMWI (it currently assumes FSK)
=20 b) Preservation of contiguous numbering (editorial?) Details can be found at: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01812.html =20 c) Offline comments on the need for distinction between CID v/s VMWI (Phil, can you post more details on that)? =20 If resolutions to the above issues are agreed upon, I plan to propose a new draft revision as early as next week. =20 =20 regards Sumanth =20 =20 --------------- Usage of DTMF and FSK for VMWI (source: Eugene Nechamkin, via email) There are currently four CallerID signalling methods defined in Telco specs. They are: =20 1. Class I with FSK 2. Class I with DTMF 3. VMWI with FSK 4. VMWI with DTMF =20 While the current draft-09 contains the means of defining the 1st two (via "pktcSigDevCallerIdSigProtocol" MIB Object), it does not allow to choose the protocol for VMWI. The draft always assumes that for VMWI, it's always FSK method which is used. =20 We found that in some countries (e.g. Denmark) the #4 method is required (as per "TDK-TS 900 301-5"). There are also other contries which require VMWI with DTMF (Brazil, Sweden, Netherlands). Here is the quotation from the document: =20 The MWI supplementary service enables the served user to receive an indication when a message has been delivered to the user's mailbox.=20 NOTE: The MWI supplementary service can currently only be used in conjunction with one of TDC Tele Danmark's public voice-mailbox services. The served user can receive a message waiting indication from the VMS in two different ways: a) Deferred mode: when the MWI supplementary service is activated and the served user makes an outgoing call attempt, the served user is notified by means of announcement; and/or; =20 b) Immediate mode: when the MWI supplementary service has been activated, the served user is notified by means of DTMF based signalling. The intention with this notification is to give the user's terminal the opportunity to visually indicate to the user (e.g. by means of an indication lamp) that a new message has been delivered to the VMS. Assuming that everybody agrees that this is a deficiency of the current draft-09, the following new MIB object is proposed to fix that: =20 pktcSigDevVmwiSigProtocol OBJECT-TYPE =20 SYNTAX INTEGER {=20 fsk (1),=20 dtmf (2)=20 }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 "This object identifies the subscriber line protocol used=20 for signalling the Information on Visual Message Waiting Indicator (VMWI).=20 Different countries define different VMWI signalling protocols to=20 support VMWI service. Frequency shift keying (FSK)=20 is most commonly used. Dual tone multi-frequency (DTMF)=20 is an alternative."=20 DEFVAL { fsk }=20 ::=3D { pktcSigDevConfigObjects X } =20 ------------------------------------------------------------------------ ---------------------------------------------------------- =20 =20 =20 ------_=_NextPart_001_01C63646.44008D06 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Based on the = findings of=20 Eugene and Phil (earlier mail enclosed at the end of this email), the = following=20 changes have been proposed (by Phil -=20 thanks!) to draft-09 of = the IETF=20 Signaling MIB draft. I plan to submit a = new draft=20 soon (with the proposed changes) and hence comments and concerns would = be=20 appreciated at the earliest (I have not received any feedback on the = IPCDN=20 reflector with reference to earlier emails resulting in this=20 proposal).

 

 

Thanks!

Sumanth


New objects:

 

pktcSigDevVmwiSigProtocol  OBJECT-TYPE 

      =20 SYNTAX       = INTEGER {=20

           &n= bsp;           &nb= sp;   =20 fsk  (1),

           &n= bsp;           &nb= sp;   =20 dtmf (2)

       = }

      =20 MAX-ACCESS  =20 read-write 

      =20 STATUS      =20 current 

      =20 DESCRIPTION 

          =20 "This object identifies the subscriber line protocol used

          =20 for signaling the Information on Visual Message Waiting

          =20 Indicator(VMWI). Different countries define different VMWI

          =20 signaling protocols to support VMWI service. Frequency shift

          =20 keying (FSK) is most commonly used. Dual tone multi-

          =20 frequency (DTMF) is an alternative."

       =20 DEFVAL { fsk }

   ::=3D { = pktcSigDevConfigObjects X=20 }

 

   = pktcSigDevCIDModePreamble=20 OBJECT-TYPE 

      =20 SYNTAX       = INTEGER {=20

           &n= bsp;           &nb= sp;    =20 DTMFcodeA (1),

           &n= bsp;           &nb= sp;    =20 DTMFcodeB (2),

           &n= bsp;           &nb= sp;    =20 DTMFcodeC (3),

           &n= bsp;           &nb= sp;    =20 DTMFcodeD (4)

       = }

      =20 MAX-ACCESS  =20 read-write 

      =20 STATUS       current 

      =20 DESCRIPTION 

          =20 " This object identifies the subscriber line protocol used

          =20 for signaling caller id information. Different countries

          =20 define different caller id signaling protocols to support

         =20  caller = identification. When=20 Dual tone multi-frequency (DTMF)

          =20 is used the CID digits are preceeded by a pre-amble digit 

          =20 <A><S1>...<Sn><D><S1>...<Sn>&l= t;B><S1>...<Sn><C>=20

          =20 the digit transmission sequence <S1>...<Sn> Digits (0 = -=20 9)

          =20 The DTMF code "B" may be sent by the network as start code

          =20 for the transfer of information values,through which special =            

          =20 events can be indicated to the user."

       =20 DEFVAL { DTMFcodeA }

   ::=3D { = pktcSigDevConfigObjects X=20 }

 

 

   = pktcSigDevCIDModePostamble=20 OBJECT-TYPE 

      =20 SYNTAX       = INTEGER {=20

           &n= bsp;           &nb= sp;    =20 DTMFcodeA (1),

           &n= bsp;           &nb= sp;    =20 DTMFcodeB (2),

           &n= bsp;           &nb= sp;    =20 DTMFcodeC (3),

           &n= bsp;           &nb= sp;=20     DTMFcodeD=20 (4)

       = }

      =20 MAX-ACCESS  =20 read-write 

      =20 STATUS      =20 current 

      =20 DESCRIPTION 

          =20 " This object identifies the subscriber line protocol used

          =20 for signaling caller id information. Different countries

           define=20 different caller id signaling protocols to support

          =20 caller identification. When Dual tone multi-frequency (DTMF)

          =20 is used the CID digits are followed by a post amble digit             

          =20 <A><S1>...<Sn><D><S1>...<Sn>&l= t;B><S1>...<Sn><C>=20

          =20 the digit transmission sequence <S1>...<Sn> Digits (0 = -=20 9)

          =20 The DTMF code "B" may be sent by the network as start code

          =20 for the transfer of information values,through which special

          =20 events can be indicated to the user."

       =20 DEFVAL { DTMFcodeC }

   ::=3D { = pktcSigDevConfigObjects X=20 }

 

 

   = pktcSigDevCPEDisplay    OBJECT-TYPE 

      =20 SYNTAX       = INTEGER {=20

           &n= bsp;       =20 SI(1),

           &n= bsp;       =20 SO(2),

        =20            }=20

       = MAX-ACCESS=20 read-write

       = STATUS=20 current 

      =20 DESCRIPTION 

          =20 "The display format varies in some locations from the normal

          =20 alphanumeric characters (SI) to Katakana graphics (SO)

          =20 display based on user preferences. =20 This element sets a CPE

          =20 signaling protocol byte to indicate to the CPE device the

          =20 proper format for the display of CID or VMWI messages. 

          =20 Reference ITU T.50 A.1.27 and A.1.28 point to ISO 2022

           (refer = to RFC=20 1468)"

       = DEFVAL=20 {SI} 

       = ::=3D=20 {pktcSigDevConfigObjects x  = } 

 

 

Additionally, it = has been=20 proposed that the name and/or description of the following MIB Objects = be=20 changed to incorporate usage of DTMF and FSK.

-=20 pktcSigDevCIDFskAfterRing  = to=20 pktcSigDevCIDAfterRing; + description

- = pktcSigDevCIDFskAfterDTAS to=20 pktcSigDevCIDAfterDTAS; + description

- = pktcSigDevCIDFskAfterRPAS to=20 pktcSigDevCIDAfterRPAS; + description

- = pktcSigDevCIDRingAfterFsk to=20 pktcSigDevCIDRingAfterCID; + description

- = pktcSigDevVmwiFskAfterDTAS=20  to = pktcSigDevVmwiAfterDTAS; +=20 description

- = pktcSigDevVwmiFskAfterRPAS=20 to   = pktcSigDevVwmiAfterRPAS;=20

           &n= bsp;           &nb= sp;           &nbs= p;            = ;=20 + description

- = pktcSigDevVwmiFskDTASAfterLR=20 to pktcSigDevVwmiDTASAfterLR;

           &n= bsp;           &nb= sp;           &nbs= p;           =20  + description

- = pktcSigDevCIDMode=20 (description)    =

- = pktcSigDevVmwiMode=20 (description)

 


From: Sumanth Channabasappa =
Sent:=20 Friday, February 10, 2006 8:32 AM
To: Ipcdn=20 (E-mail)
Subject: [ipcdn] Feedback:=20 draft-ietf-ipcdn-pktc-signaling-09

Folks,
=
 
 
The comments I have received thus far=20 include:
 
a) Proposal to modify the current = draft to allow=20 for DTMF to be used fo VMWI (it currently assumes=20 FSK)
<Details=20 enclosed at the end of this=20 email>
<= /SPAN> 
b) Preservation of contiguous numbering=20 (editorial?)
Details can be found at: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01812.html
 
c) Offline comments on the need for = distinction between=20 CID v/s VMWI (Phil, can you post more details on=20 that)?<= /SPAN>
<= /SPAN> 
If=20 resolutions to the above issues are agreed upon, I plan to propose a new = draft=20 revision as early as next=20 week.  
<= /SPAN> 
 regards<= /SPAN>
Sumanth=
<= /SPAN> 
 
--------------- Usage = of DTMF and=20 FSK for VMWI  (source: Eugene Nechamkin, via=20 email)
There are currently four CallerID=20 signalling methods defined in Telco specs. They=20 are:
 
1. Class I with FSK
2. Class I with DTMF
3. VMWI with FSK
4. VMWI with DTMF
 
While the current = draft-09 contains=20 the means of defining the 1st two (via "pktcSigDevCallerIdSigProtocol" = MIB=20 Object), it does not allow to choose the protocol for VMWI. The draft = always=20 assumes that for VMWI, it's always FSK method which is=20 used.
 
We = found that in=20 some countries (e.g. Denmark) the #4 method is required (as per "TDK-TS 900 301-5"). There are also other contries which require = VMWI with=20 DTMF (Brazil, Sweden, Netherlands). Here is the quotation from the=20 document:
 

The MWI supplementary service = enables the served=20 user to receive an indication when a message has been delivered to the = user's=20 mailbox.

NOTE:        =20 The MWI supplementary service can currently only be used in = conjunction=20 with one of TDC Tele Danmark’s public voice-mailbox = services.

The served user can receive a = message waiting=20 indication from the VMS in two different ways:

a)       = Deferred mode: when the MWI=20 supplementary service is activated and the served user makes an outgoing = call=20 attempt, the served user is notified by means of announcement;=20 and/or;

 

b)       = Immediate mode: when the MWI=20 supplementary service has been activated, the = served user is=20 notified by means of DTMF based signalling. The intention with = this=20 notification is to give the user’s terminal the opportunity to = visually indicate=20 to the user (e.g. by means of an indication lamp) that a new message has = been=20 delivered to the VMS.

Assuming that = everybody=20 agrees that this is a deficiency of the current draft-09, the following = new MIB=20 object is proposed to fix that:
 
pktcSigDevVmwiSigProtocol  = OBJECT-TYPE =20
      =20 SYNTAX       INTEGER {=20
           &nb= sp;           &nbs= p;   =20 fsk  (1),=20
           &nb= sp;           &nbs= p;   =20 dtmf (2)
       }=20
       MAX-ACCESS   = read-write =20
      =20 STATUS       current =20
       DESCRIPTION =20
           "This = object=20 identifies the subscriber line protocol used=20
            = for=20 signalling the Information on = Visual Message Waiting Indicator=20 (VMWI). 
        &= nbsp;  =20 Different countries define different VMWI=20 signalling protocols to=20
            = support=20 VMWI service. Frequency shift = keying (FSK)=20
            = is most=20 commonly used. Dual tone multi-frequency (DTMF)=20
            = is an=20 alternative." 
        DEFVAL = { fsk }=20
   ::=3D { pktcSigDevConfigObjects X = }
&nbs= p;
----------------------------------------------= -------------------------------------------------------------------------= -----------
 
 
 
=
<= /SPAN> ------_=_NextPart_001_01C63646.44008D06-- --===============0844257936== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0844257936==-- From ipcdn-bounces@ietf.org Tue Feb 21 16:02:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBeeh-0000S2-PE; Tue, 21 Feb 2006 16:02:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBeeg-0000RO-HO for ipcdn@ietf.org; Tue, 21 Feb 2006 16:02:42 -0500 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBeef-0000lV-RN for ipcdn@ietf.org; Tue, 21 Feb 2006 16:02:42 -0500 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 21 Feb 2006 13:04:08 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id DEFC72AE; Tue, 21 Feb 2006 13:02:32 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id ABDE12AE for ; Tue, 21 Feb 2006 13:02:32 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id CYY02430; Tue, 21 Feb 2006 13:02:30 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id B3B7D20502 for ; Tue, 21 Feb 2006 13:02:30 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] Proposed changes: draft-ietf-ipcdn-pktc-signaling-09 Date: Tue, 21 Feb 2006 13:02:29 -0800 Message-ID: <9C5C578DD43AFD4EA7A9F0BDB2F485647C2A20@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] Proposed changes: draft-ietf-ipcdn-pktc-signaling-09 Thread-Index: AcWvDCZwmBnmdciwSWqLr965Sl83FyIHNbuQ From: "Eugene Nechamkin" To: "Ipcdn (E-mail)" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006022108; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230352E34334642374644322E303034312D412D; ENG=IBF; TS=20060221210410; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006022108_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FE55FC236W956311-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.8 (+) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 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 =20 The following are the commments on the proposed. =20 1. General comment: all new objects are introduced in such a way that it may change the OIDs of most of the previously existing objects in the "pktcSigDevConfigObjects" group. To minimize the potential negative impact, I would propose placing all new objects immediately after the last object in the "pktcSigDevConfigObjects" group (i.e. after pktcSigDevMultiFreqToneTable).=20 =20 2. pktcSigDevCIDModePreamble & pktcSigDevCIDModePostamble objects: =20 The object definitions have several issues which require some more clarifications: =20 - The line "This object identifies the subscriber line protocol used for signaling caller id information" is incorrect because there is already a MIB Object identifying the caller id signaling protocol - "pktcSigDevCallerIdSigProtocol". - The description should emphasize that the the new object is applicable only when pktcSigDevCallerIdSigProtocol =3D dtmf(2) - Object Naming is not aligned with ETSI EN 300 659-1 Spec's terminology. The latter one uses "start code" and "end code" for calling number instead of using "Preamble", and "Postamble". Proposed: change the name pktcSigDevCIDModePreamble to be "pktcSigDevCIDStartCode" and change the name pktcSigDevCIDModePostamble to be "pktcSigDevCIDEndCode". - the example in the description clause of the pktcSigDevCIDModePostable object is not correct: "The DTMF code "B" may be sent by the network as start code for the transfer of information values,through which special events can be indicated to the user" - as per ETSI spec, "B" is a start code (preamble) not end code (postamble). The description should have used "C" instead as an example of the end code. - reference clause for the objects would be helpfull at the implementatoin stage as a pointer for the particular details. =20 The following is proposed modifcations which will address these concerns: =20 pktcSigDevCIDModeDtmfStartCode OBJECT-TYPE =20 SYNTAX INTEGER {=20 DTMFcodeA (1), DTMFcodeB (2), DTMFcodeC (3), DTMFcodeD (4) }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 " This object identifies the 'start code' for the Dual Tone Multi-Frequency (DTMF)=20 based subscriber line protocol used for signalling caller id information.=20 Different countries define different caller id signalling protocols to support caller=20 identification. When DTMF is used, the CID digits are preceded by a start code digit =20 .........=20 the digit transmission sequence ... Digits (0 - 9) The start code for calling number delivery may be DTMF "A" or "D". The DTMF code "B" may be sent by the network as a start code for the=20 transfer of information values,through which special events can be =20 indicated to the user. The DTMF code "D" may be sent to indicate a=20 redirecting number. The MTA must use this object only when pktcSigDevCallerIdSigProtocol is=20 set to dtmf(2), and must not use it - otherwise." REFERENCE =20 " ETSI-EN-300-659-1 Specification, Annex B"=20 DEFVAL { DTMFcodeA } ::=3D { pktcSigDevConfigObjects X } pktcSigDevCIDDtmfEndCode OBJECT-TYPE =20 SYNTAX INTEGER {=20 DTMFcodeA (1), DTMFcodeB (2), DTMFcodeC (3), DTMFcodeD (4) }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 " This object identifies the 'end code' for the Dual Tone Multi-Frequency (DTMF)=20 based subscriber line protocol used for signalling caller id information.=20 Different countries define different caller id signalling protocols to=20 support caller identification. When DTMF is used the CID digits are followed=20 by an end code digit .........=20 the digit transmission sequence ... Digits (0 - 9) The DTMF code "C" may be sent by the network as an end code after the=20 transfer of information or calling line identity values.=20 The MTA must use this object only when pktcSigDevCallerIdSigProtocol =20 is set to dtmf(2), and must not use it - otherwise." DEFVAL { DTMFcodeC }=20 ::=3D { pktcSigDevConfigObjects X } 3. I agree with the idea to make the objects' names indpendent of the CID Signaling Method chosen (FSK or DTMF). However, there are some concerns on the consistency of the naming convention for the new names. The previous naming convention was that "pktcSigDevCID" was the "base name", and the rest represented the object's functionality (FskAfterRing, RingAfterFsk, etc.). If the same base is still in use, than some objects don't really reflect the actual functionality (AfterRing, AfterDTAS,...). If the base is now meant to be "pktcSigDev" than the last object has CID twice (CIDRingAfterCID). =20 I think if we accept that the new "name base" is "pktcSigDev", but use a new name for the "pktcSigDevCIDRingAfterCID" MIB Object to be "pktcSigDevRingAfterCID", then the new MIB objects names will be more consistant. =20 4. MAX-ACCESS method for the MIB Objects related to the CallerID and VMWI functionlity. Currently, its defined as "read-write" which essentially means that the Caller ID Siganling Protocol and its parameters can be changed "on-the-fly" by the Operator. Realistically, the caller id protocol and parameters are not modified on the fly (if at all) for the given country, and given conditions in the field. If so, then "read-write" access becomes unneccessary complication in the MTA implementation and configuration. Hence - the "read-only" access for MIB Objects controlling the CallerID parameters seems to be sufficient for such objects (e.g. pktcSigDevCallerIdSigProtocol, pktcSigDevVmwiSigProtocol, pktcSigDevCIDAfterRing, pktcSigDevCIDAfterDTAS, pktcSigDevVmwiAfterDTAS, pktcSigDevVwmiAfterRPAS, etc). Obvioulsy, the MTA must be able to configure these objects via the MTA Confguration File during MTA provisioning after the reset. Eugene. ------------------------------------------------------------------------ -------- From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com]=20 Sent: Monday, February 20, 2006 9:51 AM To: Ipcdn (E-mail) Subject: [ipcdn] Proposed changes: draft-ietf-ipcdn-pktc-signaling-09 Folks, Based on the findings of Eugene and Phil (earlier mail enclosed at the end of this email), the following changes have been proposed (by Phil - thanks!) to draft-09 of the IETF Signaling MIB draft. I plan to submit a new draft soon (with the proposed changes) and hence comments and concerns would be appreciated at the earliest (I have not received any feedback on the IPCDN reflector with reference to earlier emails resulting in this proposal). Thanks! Sumanth New objects: pktcSigDevVmwiSigProtocol OBJECT-TYPE =20 SYNTAX INTEGER {=20 fsk (1),=20 dtmf (2)=20 }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 "This object identifies the subscriber line protocol used=20 for signaling the Information on Visual Message Waiting=20 Indicator(VMWI). Different countries define different VMWI=20 signaling protocols to support VMWI service. Frequency shift=20 keying (FSK) is most commonly used. Dual tone multi- frequency (DTMF) is an alternative."=20 DEFVAL { fsk }=20 ::=3D { pktcSigDevConfigObjects X } pktcSigDevCIDModePreamble OBJECT-TYPE =20 SYNTAX INTEGER {=20 DTMFcodeA (1), DTMFcodeB (2), DTMFcodeC (3), DTMFcodeD (4) }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 " This object identifies the subscriber line protocol used=20 for signaling caller id information. Different countries=20 define different caller id signaling protocols to support=20 caller identification. When Dual tone multi-frequency (DTMF)=20 is used the CID digits are preceeded by a pre-amble digit =20 .........=20 the digit transmission sequence ... Digits (0 - 9) The DTMF code "B" may be sent by the network as start code=20 for the transfer of information values,through which special events can be indicated to the user."=20 DEFVAL { DTMFcodeA }=20 ::=3D { pktcSigDevConfigObjects X } =20 pktcSigDevCIDModePostamble OBJECT-TYPE =20 SYNTAX INTEGER {=20 DTMFcodeA (1), DTMFcodeB (2), DTMFcodeC (3), DTMFcodeD (4) }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 " This object identifies the subscriber line protocol used=20 for signaling caller id information. Different countries=20 define different caller id signaling protocols to support=20 caller identification. When Dual tone multi-frequency (DTMF)=20 is used the CID digits are followed by a post amble digit .........=20 the digit transmission sequence ... Digits (0 - 9) The DTMF code "B" may be sent by the network as start code=20 for the transfer of information values,through which special=20 events can be indicated to the user."=20 DEFVAL { DTMFcodeC }=20 ::=3D { pktcSigDevConfigObjects X } pktcSigDevCPEDisplay OBJECT-TYPE =20 SYNTAX INTEGER {=20 SI(1),=20 SO(2),=20 }=20 MAX-ACCESS read-write=20 STATUS current =20 DESCRIPTION =20 "The display format varies in some locations from the normal=20 alphanumeric characters (SI) to Katakana graphics (SO)=20 display based on user preferences. This element sets a CPE=20 signaling protocol byte to indicate to the CPE device the=20 proper format for the display of CID or VMWI messages. =20 Reference ITU T.50 A.1.27 and A.1.28 point to ISO 2022=20 (refer to RFC 1468)"=20 DEFVAL {SI} =20 ::=3D {pktcSigDevConfigObjects x } =20 Additionally, it has been proposed that the name and/or description of the following MIB Objects be changed to incorporate usage of DTMF and FSK. - pktcSigDevCIDFskAfterRing to pktcSigDevCIDAfterRing; + description - pktcSigDevCIDFskAfterDTAS to pktcSigDevCIDAfterDTAS; + description - pktcSigDevCIDFskAfterRPAS to pktcSigDevCIDAfterRPAS; + description - pktcSigDevCIDRingAfterFsk to pktcSigDevCIDRingAfterCID; + description - pktcSigDevVmwiFskAfterDTAS to pktcSigDevVmwiAfterDTAS; + description - pktcSigDevVwmiFskAfterRPAS to pktcSigDevVwmiAfterRPAS;=20 + description - pktcSigDevVwmiFskDTASAfterLR to pktcSigDevVwmiDTASAfterLR; + description - pktcSigDevCIDMode (description) =20 - pktcSigDevVmwiMode (description) =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Feb 21 18:50:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBhHQ-0003Bo-6L; Tue, 21 Feb 2006 18:50:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBhHP-0003Ah-82 for ipcdn@ietf.org; Tue, 21 Feb 2006 18:50:51 -0500 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBhHO-0008Ln-Bu for ipcdn@ietf.org; Tue, 21 Feb 2006 18:50:51 -0500 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 21 Feb 2006 15:50:46 -0800 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 09DDA2AF; Tue, 21 Feb 2006 15:50:32 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id BCA612B1 for ; Tue, 21 Feb 2006 15:50:31 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id CYY74017; Tue, 21 Feb 2006 15:50:29 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 3F20220506 for ; Tue, 21 Feb 2006 15:50:29 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] Proposed changes: draft-ietf-ipcdn-pktc-signaling-09 Date: Tue, 21 Feb 2006 15:50:27 -0800 Message-ID: <9C5C578DD43AFD4EA7A9F0BDB2F485647C2ADF@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] Proposed changes: draft-ietf-ipcdn-pktc-signaling-09 Thread-Index: AcWvDCZwmBnmdciwSWqLr965Sl83FyIHNbuQAAUm5TA= From: "Eugene Nechamkin" To: "Ipcdn (E-mail)" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006022109; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230352E34334642413733342E303032322D452D5046786C33494E497A33445631553653544639524F673D3D; ENG=IBF; TS=20060221235050; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006022109_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FE578DC36S1217256-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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 There is a new object proposed - pktcSigDevCPEDisplay - which would require some more clarification on its meaning and, potentially, on some use case scenarios. Based on the description, the primary purpose of this object is to address the ability of the MTA to deal with Katakana graphics (SO) display in countries like Japan. However, Japan's CallerID alerting sequence is quite complicated and cannot be described or controlled by any of the existing MIB Objects for CID modes in the current SigMIB draft (duringRinging, DTAS, RPAS, LRAS - none will work for Japan). The presense of the new pktcSigDevCPEDisplay object does not seem to help either. So, if the purpose of this object is to allow Management Station to control the CID display character set in such countries as Japan, then it does not seem to be sufficient as Sigaling MIB does currently cover the CID parameters for Japan. If the purpose of this object is just to allow the Management Station to control the CID display character set of the MTA in countries other than Japan and covered by the current draft, then it's not clear how practical such goal is, and some use case scenarios would help to clarify that. Regards, Eugene. ------------------------------------------------------------------------ -------- From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com] Sent: Monday, February 20, 2006 9:51 AM To: Ipcdn (E-mail) Subject: [ipcdn] Proposed changes: draft-ietf-ipcdn-pktc-signaling-09 Folks, Based on the findings of Eugene and Phil (earlier mail enclosed at the end of this email), the following changes have been proposed (by Phil - thanks!) to draft-09 of the IETF Signaling MIB draft. I plan to submit a new draft soon (with the proposed changes) and hence comments and concerns would be appreciated at the earliest (I have not received any feedback on the IPCDN reflector with reference to earlier emails resulting in this proposal). Thanks! Sumanth New objects: pktcSigDevVmwiSigProtocol OBJECT-TYPE =20 SYNTAX INTEGER {=20 fsk (1),=20 dtmf (2)=20 }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 "This object identifies the subscriber line protocol used=20 for signaling the Information on Visual Message Waiting=20 Indicator(VMWI). Different countries define different VMWI=20 signaling protocols to support VMWI service. Frequency shift=20 keying (FSK) is most commonly used. Dual tone multi- frequency (DTMF) is an alternative."=20 DEFVAL { fsk }=20 ::=3D { pktcSigDevConfigObjects X } pktcSigDevCIDModePreamble OBJECT-TYPE =20 SYNTAX INTEGER {=20 DTMFcodeA (1), DTMFcodeB (2), DTMFcodeC (3), DTMFcodeD (4) }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 " This object identifies the subscriber line protocol used=20 for signaling caller id information. Different countries=20 define different caller id signaling protocols to support=20 caller identification. When Dual tone multi-frequency (DTMF)=20 is used the CID digits are preceeded by a pre-amble digit =20 .........=20 the digit transmission sequence ... Digits (0 - 9) The DTMF code "B" may be sent by the network as start code=20 for the transfer of information values,through which special events can be indicated to the user."=20 DEFVAL { DTMFcodeA }=20 ::=3D { pktcSigDevConfigObjects X } =20 pktcSigDevCIDModePostamble OBJECT-TYPE =20 SYNTAX INTEGER {=20 DTMFcodeA (1), DTMFcodeB (2), DTMFcodeC (3), DTMFcodeD (4) }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 " This object identifies the subscriber line protocol used=20 for signaling caller id information. Different countries=20 define different caller id signaling protocols to support=20 caller identification. When Dual tone multi-frequency (DTMF)=20 is used the CID digits are followed by a post amble digit .........=20 the digit transmission sequence ... Digits (0 - 9) The DTMF code "B" may be sent by the network as start code=20 for the transfer of information values,through which special=20 events can be indicated to the user."=20 DEFVAL { DTMFcodeC }=20 ::=3D { pktcSigDevConfigObjects X } pktcSigDevCPEDisplay OBJECT-TYPE =20 SYNTAX INTEGER {=20 SI(1),=20 SO(2),=20 }=20 MAX-ACCESS read-write=20 STATUS current =20 DESCRIPTION =20 "The display format varies in some locations from the normal=20 alphanumeric characters (SI) to Katakana graphics (SO)=20 display based on user preferences. This element sets a CPE=20 signaling protocol byte to indicate to the CPE device the=20 proper format for the display of CID or VMWI messages. =20 Reference ITU T.50 A.1.27 and A.1.28 point to ISO 2022=20 (refer to RFC 1468)"=20 DEFVAL {SI} =20 ::=3D {pktcSigDevConfigObjects x } =20 Additionally, it has been proposed that the name and/or description of the following MIB Objects be changed to incorporate usage of DTMF and FSK. - pktcSigDevCIDFskAfterRing to pktcSigDevCIDAfterRing; + description - pktcSigDevCIDFskAfterDTAS to pktcSigDevCIDAfterDTAS; + description - pktcSigDevCIDFskAfterRPAS to pktcSigDevCIDAfterRPAS; + description - pktcSigDevCIDRingAfterFsk to pktcSigDevCIDRingAfterCID; + description - pktcSigDevVmwiFskAfterDTAS to pktcSigDevVmwiAfterDTAS; + description - pktcSigDevVwmiFskAfterRPAS to pktcSigDevVwmiAfterRPAS;=20 + description - pktcSigDevVwmiFskDTASAfterLR to pktcSigDevVwmiDTASAfterLR; + description - pktcSigDevCIDMode (description) =20 - pktcSigDevVmwiMode (description) =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 Wed Feb 22 09:06:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBudl-00067U-AD; Wed, 22 Feb 2006 09:06:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBdrH-0006CX-0P for ipcdn@ietf.org; Tue, 21 Feb 2006 15:11:39 -0500 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBdrF-0005dO-0x for ipcdn@ietf.org; Tue, 21 Feb 2006 15:11:38 -0500 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 21 Feb 2006 12:12:38 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 4F70F2AF; Tue, 21 Feb 2006 12:11:27 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 082992AE for ; Tue, 21 Feb 2006 12:11:27 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id CYX86948; Tue, 21 Feb 2006 12:11:25 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 4B1C420501 for ; Tue, 21 Feb 2006 12:11:25 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] Proposed changes: draft-ietf-ipcdn-pktc-signaling-09 Date: Tue, 21 Feb 2006 12:11:23 -0800 Message-ID: <9C5C578DD43AFD4EA7A9F0BDB2F485647C29F0@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] Proposed changes: draft-ietf-ipcdn-pktc-signaling-09 Thread-Index: AcW4Oh5u5tc0GTuWR766dY3dv5P9mgAS0T+QHXPgu0AB/EOD4AA2Ip4g From: "Eugene Nechamkin" To: "Ipcdn (E-mail)" X-WSS-ID: 6FE5ABBC36K1045204-01-01 X-Spam-Score: 0.8 (/) X-Scan-Signature: df14bcb7b5bf82cff4f7efcddc72c1c6 X-Mailman-Approved-At: Wed, 22 Feb 2006 09:06:47 -0500 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: , Content-Type: multipart/mixed; boundary="===============1425208082==" Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============1425208082== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63722.FDA8D1D3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63722.FDA8D1D3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =20 The following are the commments on the proposed. =20 1. General comment: all new objects are introduced in such a way that it may change the OIDs of most of the previously existing objects in the "pktcSigDevConfigObjects" group. To minimize the potential negative impact, I would propose placing all new objects immediately after the last object in the "pktcSigDevConfigObjects" group (i.e. after pktcSigDevMultiFreqToneTable).=20 =20 2. pktcSigDevCIDModePreamble & pktcSigDevCIDModePostamble objects: =20 The object definitions have several issues which require some more clarifications: =20 - The line "This object identifies the subscriber line protocol used for signaling caller id information" is incorrect because there is already a MIB Object identifying the caller id signaling protocol - "pktcSigDevCallerIdSigProtocol". - The description should emphasize that the the new object is applicable only when pktcSigDevCallerIdSigProtocol =3D dtmf(2) - Object Naming is not aligned with ETSI EN 300 659-1 Spec's terminology. The latter one uses "start code" and "end code" for calling number instead of using "Preamble", and "Postamble". Proposed: change the name pktcSigDevCIDModePreamble to be "pktcSigDevCIDStartCode" and change the name pktcSigDevCIDModePostamble to be "pktcSigDevCIDEndCode". - the example in the description clause of the pktcSigDevCIDModePostable object is not correct: "The DTMF code "B" may be sent by the network as start code for the transfer of information values,through which special events can be indicated to the user" - as per ETSI spec, "B" is a start code (preamble) not end code (postamble). The description should have used "C" instead as an example of the end code. - reference clause for the objects would be helpfull at the implementatoin stage as a pointer for the particular details. =20 The following is proposed modifcations which will address these concerns: =20 pktcSigDevCIDModeDtmfStartCode OBJECT-TYPE =20 SYNTAX INTEGER {=20 DTMFcodeA (1), DTMFcodeB (2), DTMFcodeC (3), DTMFcodeD (4) }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 " This object identifies the 'start code' for the Dual Tone Multi-Frequency (DTMF)=20 based subscriber line protocol used for signalling caller id information.=20 Different countries define different caller id signalling protocols to support caller=20 identification. When DTMF is used, the CID digits are preceded by a start code digit =20 .........=20 the digit transmission sequence ... Digits (0 - 9) The start code for calling number delivery may be DTMF "A" or "D". The DTMF code "B" may be sent by the network as a start code for the=20 transfer of information values,through which special events can be =20 indicated to the user. The DTMF code "D" may be sent to indicate a=20 redirecting number. The MTA must use this object only when pktcSigDevCallerIdSigProtocol is=20 set to dtmf(2), and must not use it - otherwise." REFERENCE =20 " ETSI-EN-300-659-1 Specification, Annex B"=20 DEFVAL { DTMFcodeA } ::=3D { pktcSigDevConfigObjects X } =20 pktcSigDevCIDDtmfEndCode OBJECT-TYPE =20 SYNTAX INTEGER {=20 DTMFcodeA (1), DTMFcodeB (2), DTMFcodeC (3), DTMFcodeD (4) }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 " This object identifies the 'end code' for the Dual Tone Multi-Frequency (DTMF)=20 based subscriber line protocol used for signalling caller id information.=20 Different countries define different caller id signalling protocols to=20 support caller identification. When DTMF is used the CID digits are followed=20 by an end code digit .........=20 the digit transmission sequence ... Digits (0 - 9) The DTMF code "C" may be sent by the network as an end code after the=20 transfer of information or calling line identity values.=20 The MTA must use this object only when pktcSigDevCallerIdSigProtocol =20 is set to dtmf(2), and must not use it - otherwise." DEFVAL { DTMFcodeC }=20 ::=3D { pktcSigDevConfigObjects X } =20 3. I agree with the idea to make the objects' names indpendent of the CID Signaling Method chosen (FSK or DTMF). However, there are some concerns on the consistency of the naming convention for the new names. The previous naming convention was that "pktcSigDevCID" was the "base name", and the rest represented the object's functionality (FskAfterRing, RingAfterFsk, etc.). If the same base is still in use, than some objects don't really reflect the actual functionality (AfterRing, AfterDTAS,...). If the base is now meant to be "pktcSigDev" than the last object has CID twice (CIDRingAfterCID). =20 I think if we accept that the new "name base" is "pktcSigDev", but use a new name for the "pktcSigDevCIDRingAfterCID" MIB Object to be "pktcSigDevRingAfterCID", then the MIB objects names will be more consistant. =20 4. MAX-ACCESS method for the MIB Objects related to the CallerID and VMWI functionlity. Currently, its defined as "read-write" which essentially means that the Caller ID Siganling Protocol and its parameters can be changed "on-the-fly" by the Operator. Realistically, the caller id protocol and parameters are not modified on the fly (if at all) for the given country, and given conditions in the field. If so, then "read-write" access becomes unneccessary complication in the MTA implementation and configuration. Hence - the "read-only" access for MIB Objects controlling the CallerID parameters seems to be sufficient for such objects (e.g. pktcSigDevCallerIdSigProtocol, pktcSigDevVmwiSigProtocol, pktcSigDevCIDAfterRing, pktcSigDevCIDAfterDTAS, pktcSigDevVmwiAfterDTAS, pktcSigDevVwmiAfterRPAS, etc). Obvioulsy, the MTA must be able to configure these objects via the MTA Confguration File during MTA provisioning after the reset. =20 =20 Eugene. =20 ________________________________ From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com]=20 Sent: Monday, February 20, 2006 9:51 AM To: Ipcdn (E-mail) Subject: [ipcdn] Proposed changes: draft-ietf-ipcdn-pktc-signaling-09 Folks, =20 Based on the findings of Eugene and Phil (earlier mail enclosed at the end of this email), the following changes have been proposed (by Phil - thanks!) to draft-09 of the IETF Signaling MIB draft. I plan to submit a new draft soon (with the proposed changes) and hence comments and concerns would be appreciated at the earliest (I have not received any feedback on the IPCDN reflector with reference to earlier emails resulting in this proposal). =20 =20 Thanks! Sumanth New objects: =20 pktcSigDevVmwiSigProtocol OBJECT-TYPE =20 SYNTAX INTEGER {=20 fsk (1),=20 dtmf (2)=20 }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 "This object identifies the subscriber line protocol used=20 for signaling the Information on Visual Message Waiting=20 Indicator(VMWI). Different countries define different VMWI=20 signaling protocols to support VMWI service. Frequency shift=20 keying (FSK) is most commonly used. Dual tone multi- frequency (DTMF) is an alternative."=20 DEFVAL { fsk }=20 ::=3D { pktcSigDevConfigObjects X } =20 pktcSigDevCIDModePreamble OBJECT-TYPE =20 SYNTAX INTEGER {=20 DTMFcodeA (1), DTMFcodeB (2), DTMFcodeC (3), DTMFcodeD (4) }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 " This object identifies the subscriber line protocol used=20 for signaling caller id information. Different countries=20 define different caller id signaling protocols to support=20 caller identification. When Dual tone multi-frequency (DTMF)=20 is used the CID digits are preceeded by a pre-amble digit =20 .........=20 the digit transmission sequence ... Digits (0 - 9) The DTMF code "B" may be sent by the network as start code=20 for the transfer of information values,through which special events can be indicated to the user."=20 DEFVAL { DTMFcodeA }=20 ::=3D { pktcSigDevConfigObjects X } =20 =20 pktcSigDevCIDModePostamble OBJECT-TYPE =20 SYNTAX INTEGER {=20 DTMFcodeA (1), DTMFcodeB (2), DTMFcodeC (3), DTMFcodeD (4) }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 " This object identifies the subscriber line protocol used=20 for signaling caller id information. Different countries=20 define different caller id signaling protocols to support=20 caller identification. When Dual tone multi-frequency (DTMF)=20 is used the CID digits are followed by a post amble digit .........=20 the digit transmission sequence ... Digits (0 - 9) The DTMF code "B" may be sent by the network as start code=20 for the transfer of information values,through which special=20 events can be indicated to the user."=20 DEFVAL { DTMFcodeC }=20 ::=3D { pktcSigDevConfigObjects X } =20 =20 pktcSigDevCPEDisplay OBJECT-TYPE =20 SYNTAX INTEGER {=20 SI(1),=20 SO(2),=20 }=20 MAX-ACCESS read-write=20 STATUS current =20 DESCRIPTION =20 "The display format varies in some locations from the normal=20 alphanumeric characters (SI) to Katakana graphics (SO)=20 display based on user preferences. This element sets a CPE=20 signaling protocol byte to indicate to the CPE device the=20 proper format for the display of CID or VMWI messages. =20 Reference ITU T.50 A.1.27 and A.1.28 point to ISO 2022=20 (refer to RFC 1468)"=20 DEFVAL {SI} =20 ::=3D {pktcSigDevConfigObjects x } =20 =20 =20 Additionally, it has been proposed that the name and/or description of the following MIB Objects be changed to incorporate usage of DTMF and FSK. - pktcSigDevCIDFskAfterRing to pktcSigDevCIDAfterRing; + description - pktcSigDevCIDFskAfterDTAS to pktcSigDevCIDAfterDTAS; + description - pktcSigDevCIDFskAfterRPAS to pktcSigDevCIDAfterRPAS; + description - pktcSigDevCIDRingAfterFsk to pktcSigDevCIDRingAfterCID; + description - pktcSigDevVmwiFskAfterDTAS to pktcSigDevVmwiAfterDTAS; + description - pktcSigDevVwmiFskAfterRPAS to pktcSigDevVwmiAfterRPAS;=20 + description - pktcSigDevVwmiFskDTASAfterLR to pktcSigDevVwmiDTASAfterLR; + description - pktcSigDevCIDMode (description) =20 - pktcSigDevVmwiMode (description) =20 ________________________________ From: Sumanth Channabasappa=20 Sent: Friday, February 10, 2006 8:32 AM To: Ipcdn (E-mail) Subject: [ipcdn] Feedback: draft-ietf-ipcdn-pktc-signaling-09 Folks, =20 I am sending across this email to solicit feedback on "draft-ietf-ipcdn-pktc-signaling-09" (ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-09.t xt) =20 The comments I have received thus far include: =20 a) Proposal to modify the current draft to allow for DTMF to be used fo VMWI (it currently assumes FSK)
=20 b) Preservation of contiguous numbering (editorial?) Details can be found at: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01812.html =20 c) Offline comments on the need for distinction between CID v/s VMWI (Phil, can you post more details on that)? =20 If resolutions to the above issues are agreed upon, I plan to propose a new draft revision as early as next week. =20 =20 regards Sumanth =20 =20 --------------- Usage of DTMF and FSK for VMWI (source: Eugene Nechamkin, via email) There are currently four CallerID signalling methods defined in Telco specs. They are: =20 1. Class I with FSK 2. Class I with DTMF 3. VMWI with FSK 4. VMWI with DTMF =20 While the current draft-09 contains the means of defining the 1st two (via "pktcSigDevCallerIdSigProtocol" MIB Object), it does not allow to choose the protocol for VMWI. The draft always assumes that for VMWI, it's always FSK method which is used. =20 We found that in some countries (e.g. Denmark) the #4 method is required (as per "TDK-TS 900 301-5"). There are also other contries which require VMWI with DTMF (Brazil, Sweden, Netherlands). Here is the quotation from the document: =20 The MWI supplementary service enables the served user to receive an indication when a message has been delivered to the user's mailbox.=20 NOTE: The MWI supplementary service can currently only be used in conjunction with one of TDC Tele Danmark's public voice-mailbox services. The served user can receive a message waiting indication from the VMS in two different ways: a) Deferred mode: when the MWI supplementary service is activated and the served user makes an outgoing call attempt, the served user is notified by means of announcement; and/or; =20 b) Immediate mode: when the MWI supplementary service has been activated, the served user is notified by means of DTMF based signalling. The intention with this notification is to give the user's terminal the opportunity to visually indicate to the user (e.g. by means of an indication lamp) that a new message has been delivered to the VMS. Assuming that everybody agrees that this is a deficiency of the current draft-09, the following new MIB object is proposed to fix that: =20 pktcSigDevVmwiSigProtocol OBJECT-TYPE =20 SYNTAX INTEGER {=20 fsk (1),=20 dtmf (2)=20 }=20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 "This object identifies the subscriber line protocol used=20 for signalling the Information on Visual Message Waiting Indicator (VMWI).=20 Different countries define different VMWI signalling protocols to=20 support VMWI service. Frequency shift keying (FSK)=20 is most commonly used. Dual tone multi-frequency (DTMF)=20 is an alternative."=20 DEFVAL { fsk }=20 ::=3D { pktcSigDevConfigObjects X } =20 ------------------------------------------------------------------------ ---------------------------------------------------------- =20 =20 =20 ------_=_NextPart_001_01C63722.FDA8D1D3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
 
The following are the commments on the=20 proposed.
 
1.=20 General comment: all new objects are=20 introduced in such a way that it may change the OIDs of most of the = previously existing objects in the "pktcSigDevConfigObjects" group. To = minimize=20 the potential negative impact, I would propose placing all new objects=20 immediately after the last object in the "pktcSigDevConfigObjects" group = (i.e.=20 after pktcSigDevMultiFreqToneTable).
 
2. pktcSigDevCIDModePreamble & pktcSigDevCIDModePostamble objects:
 
The object = definitions have=20 several issues which require some more = clarifications:
 
    - The=20 line "This object identifies the subscriber line protocol used for = signaling=20 caller id information" is incorrect because there is already a MIB = Object=20 identifying the caller id signaling protocol -=20 "pktcSigDevCallerIdSigProtocol".
    - The=20 description should emphasize that the the new object is applicable only = when=20 pktcSigDevCallerIdSigProtocol =3D dtmf(2)
    - Object=20 Naming is not aligned with ETSI EN 300 659-1 Spec's terminology. The = latter one=20 uses "start code" and "end code" for calling number instead of using = "Preamble",=20 and "Postamble". Proposed: change the name pktcSigDevCIDModePreamble to be = "pktcSigDevCIDStartCode" and change the name pktcSigDevCIDModePostamble to be = "pktcSigDevCIDEndCode".
   =20 - the example in the description clause of the pktcSigDevCIDModePostable object = is not=20 correct:=20 "The DTMF code "B" may be sent by the network = as start=20 code for the transfer of information values,through which special = events=20 can be indicated to the user" - as per ETSI spec, "B" is a start code (preamble) not end code=20 (postamble). The description should have used "C" instead as an example = of the=20 end=20 code.
    - reference clause for the = objects=20 would be helpfull at the implementatoin stage as a pointer for the = particular=20 details.
 <= /DIV>
The = following is=20 proposed modifcations which will address these=20 concerns:<= /SPAN>
 <= /DIV>

   pktcSigDevCIDModeDtmfStartCode OBJECT-TYPE  =
      =20 SYNTAX       INTEGER { =

           &n= bsp;           &nb= sp;    =20 DTMFcodeA (1),

           &n= bsp;           &nb= sp;    =20 DTMFcodeB (2),

           &n= bsp;           &nb= sp;    =20 DTMFcodeC (3),

           &n= bsp;           &nb= sp;    =20 DTMFcodeD (4)

       }=20
       MAX-ACCESS   = read-write =20
      =20 STATUS       current =20
      =20 DESCRIPTION  
       &nbs= p;    " = This=20 object identifies the 'start = code' for the Dual Tone Multi-Frequency (DTMF)=20

       &nbs= p;    based=20 subscriber line protocol used for signalling caller id=20 information.

       &nbs= p;   =20 Different countries define different caller id signalling = protocols=20 to support caller

           =20 identification. When DTMF is used,=20 the CID digits are = preceded by=20 a start=20 code digit  

           =20 <A><S1>...<Sn><D><S1>...<Sn>&l= t;B><S1>...<Sn><C>=20

           =20 the digit transmission sequence=20 <S1>...<Sn> Digits (0 - 9)

         &nb= sp; =20 The start code for calling number delivery may be DTMF "A" or=20 "D".

           =20 The DTMF code "B" may be sent by the network as a start code for the

           =20 transfer of information values,through which special events can = be           =20

           =20 indicated to the user. The DTMF code "D" may be = sent to=20 indicate=20 a 
          &n= bsp;=20 redirecting number.

       &nbs= p;    The MTA = must=20 use this object=20 only when pktcSigDevCallerIdSigProtocol is=20

       &nbs= p;  set=20 to dtmf(2),=20 and must not use it - otherwise."

        REFERENCE 

          "= ETSI-EN-300-659-1 Specification, Annex B" =

        = DEFVAL {=20 DTMFcodeA }
   ::=3D {=20 pktcSigDevConfigObjects X }

 

=

   pktcSigDevCIDDtmfEndCode OBJECT-TYPE  =
      =20 SYNTAX       INTEGER { =

           &n= bsp;           &nb= sp;    =20 DTMFcodeA (1),

           &n= bsp;           &nb= sp;    =20 DTMFcodeB (2),

           &n= bsp;           &nb= sp;    =20 DTMFcodeC (3),

           &n= bsp;           &nb= sp;    =20 DTMFcodeD (4)

       }=20
       MAX-ACCESS   = read-write =20
      =20 STATUS       current =20
       = DESCRIPTION  
         &nb= sp; "=20 This object identifies the 'end code'=20 for the Dual Tone Multi-Frequency (DTMF)=20

       &nbs= p;    based subscriber line=20 protocol used for signalling caller id information.=20

       &nbs= p;   =20 Different countries define  different caller id signalling = protocols=20 to

       &nbs= p;   =20 support caller identification. When DTMF is used the CID = digits are=20 followed

           =20 by an end=20 code digit

        =20    <A><S1>...<Sn><D>&l= t;S1>...<Sn><B><S1>...<Sn><C>=20

           =20 the digit transmission sequence=20 <S1>...<Sn> Digits (0 - 9)

           =20 The DTMF code "C" may be = sent by=20 the network as an end code after the=20

           =20 transfer of information or calling line identity values. 

       &nbs= p;    The MTA = must=20 use this object only = when=20 pktcSigDevCallerIdSigProtocol  

       &nbs= p;   =20 is set to dtmf(2), and must = not use=20 it - otherwise."

        DEFVAL = {=20 DTMFcodeC }
   ::=3D {=20 pktcSigDevConfigObjects X }

 

3. I agree with the idea to make the objects' = names=20 indpendent of the CID Signaling Method chosen (FSK or=20 DTMF).  However, there are some concerns on the consistency of the naming = convention=20 for the new names. The previous naming convention was that = "pktcSigDevCID"=20 was the "base name", and the rest represented the object's functionality = (FskAfterRing, RingAfterFsk, etc.). If the=20 same base is still in use, than some objects don't really reflect the = actual=20 functionality (AfterRing, AfterDTAS,...). If the base is now meant to be = "pktcSigDev" than the last object has CID twice=20 (CIDRingAfterCID).
 
I think if we = accept that the=20 new "name base" is "pktcSigDev", but use a new name for the=20 "pktcSigDevCIDRingAfterCID" MIB Object to be "pktcSigDevRingAfterCID", = then the=20 MIB objects names will be more consistant.
 
4. MAX-ACCESS method for the = MIB=20 Objects related to the CallerID and VMWI=20 functionlity. Currently, its defined as "read-write" which = essentially=20 means that the Caller ID Siganling Protocol and its parameters can be=20 changed "on-the-fly" by the Operator. Realistically, the=20 caller id protocol and parameters are not modified on the fly (if at=20 all) for the given country, = and=20 given conditions in the = field. If so, then "read-write" access = becomes=20 unneccessary complication in the MTA implementation and=20 configuration. Hence - the=20 "read-only" access for MIB Objects = controlling the CallerID parameters=20 seems to be sufficient for such = objects=20 (e.g. pktcSigDevCallerIdSigProtocol,=20 pktcSigDevVmwiSigProtocol,=20 pktcSigDevCIDAfterRing,=20 pktcSigDevCIDAfterDTAS,=20 pktcSigDevVmwiAfterDTAS, pktcSigDevVwmiAfterRPAS,=20 etc). Obvioulsy, the MTA must be able to configure these = objects=20 via the MTA Confguration File during MTA provisioning after the=20 reset.
 

=  

Eugene.


 
From: Sumanth Channabasappa=20 [mailto:sumanth@cablelabs.com]
Sent: Monday, February 20, = 2006 9:51=20 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] Proposed = changes:=20 draft-ietf-ipcdn-pktc-signaling-09

Folks,

 

Based on the = findings of=20 Eugene and Phil (earlier mail enclosed at the end of this email), the = following=20 changes have been proposed (by Phil -=20 thanks!) to draft-09 of = the IETF=20 Signaling MIB draft. I plan to submit a = new draft=20 soon (with the proposed changes) and hence comments and concerns would = be=20 appreciated at the earliest (I have not received any feedback on the = IPCDN=20 reflector with reference to earlier emails resulting in this=20 proposal).

 

 

Thanks!

Sumanth


New objects:

 

pktcSigDevVmwiSigProtocol  OBJECT-TYPE 

      =20 SYNTAX       = INTEGER {=20

           &n= bsp;           &nb= sp;   =20 fsk  (1),

           &n= bsp;           &nb= sp;   =20 dtmf (2)

       = }

      =20 MAX-ACCESS  =20 read-write 

      =20 STATUS      =20 current 

      =20 DESCRIPTION 

          =20 "This object identifies the subscriber line protocol used

          =20 for signaling the Information on Visual Message Waiting

          =20 Indicator(VMWI). Different countries define different VMWI

          =20 signaling protocols to support VMWI service. Frequency shift

          =20 keying (FSK) is most commonly used. Dual tone multi-

          =20 frequency (DTMF) is an alternative."

       =20 DEFVAL { fsk }

   ::=3D { = pktcSigDevConfigObjects X=20 }

 

   = pktcSigDevCIDModePreamble=20 OBJECT-TYPE 

      =20 SYNTAX       = INTEGER {=20

           &n= bsp;           &nb= sp;    =20 DTMFcodeA (1),

           &n= bsp;           &nb= sp;    =20 DTMFcodeB (2),

           &n= bsp;           &nb= sp;    =20 DTMFcodeC (3),

           &n= bsp;           &nb= sp;    =20 DTMFcodeD (4)

       = }

      =20 MAX-ACCESS  =20 read-write 

      =20 STATUS       current 

      =20 DESCRIPTION 

          =20 " This object identifies the subscriber line protocol used

          =20 for signaling caller id information. Different countries

          =20 define different caller id signaling protocols to support

         =20  caller = identification. When=20 Dual tone multi-frequency (DTMF)

          =20 is used the CID digits are preceeded by a pre-amble digit 

          =20 <A><S1>...<Sn><D><S1>...<Sn>&l= t;B><S1>...<Sn><C>=20

          =20 the digit transmission sequence <S1>...<Sn> Digits (0 = -=20 9)

          =20 The DTMF code "B" may be sent by the network as start code

          =20 for the transfer of information values,through which special =            

          =20 events can be indicated to the user."

       =20 DEFVAL { DTMFcodeA }

   ::=3D { = pktcSigDevConfigObjects X=20 }

 

 

   = pktcSigDevCIDModePostamble=20 OBJECT-TYPE 

      =20 SYNTAX       = INTEGER {=20

           &n= bsp;           &nb= sp;    =20 DTMFcodeA (1),

           &n= bsp;           &nb= sp;    =20 DTMFcodeB (2),

           &n= bsp;           &nb= sp;    =20 DTMFcodeC (3),

           &n= bsp;           &nb= sp;=20     DTMFcodeD=20 (4)

       = }

      =20 MAX-ACCESS  =20 read-write 

      =20 STATUS      =20 current 

      =20 DESCRIPTION 

          =20 " This object identifies the subscriber line protocol used

          =20 for signaling caller id information. Different countries

           define=20 different caller id signaling protocols to support

          =20 caller identification. When Dual tone multi-frequency (DTMF)

          =20 is used the CID digits are followed by a post amble digit             

          =20 <A><S1>...<Sn><D><S1>...<Sn>&l= t;B><S1>...<Sn><C>=20

          =20 the digit transmission sequence <S1>...<Sn> Digits (0 = -=20 9)

          =20 The DTMF code "B" may be sent by the network as start code

          =20 for the transfer of information values,through which special

          =20 events can be indicated to the user."

       =20 DEFVAL { DTMFcodeC }

   ::=3D { = pktcSigDevConfigObjects X=20 }

 

 

   = pktcSigDevCPEDisplay    OBJECT-TYPE 

      =20 SYNTAX       = INTEGER {=20

           &n= bsp;       =20 SI(1),

           &n= bsp;       =20 SO(2),

        =20            }=20

       = MAX-ACCESS=20 read-write

       = STATUS=20 current 

      =20 DESCRIPTION 

          =20 "The display format varies in some locations from the normal

          =20 alphanumeric characters (SI) to Katakana graphics (SO)

          =20 display based on user preferences. =20 This element sets a CPE

          =20 signaling protocol byte to indicate to the CPE device the

          =20 proper format for the display of CID or VMWI messages. 

          =20 Reference ITU T.50 A.1.27 and A.1.28 point to ISO 2022

           (refer = to RFC=20 1468)"

       = DEFVAL=20 {SI} 

       = ::=3D=20 {pktcSigDevConfigObjects x  = } 

 

 

Additionally, it = has been=20 proposed that the name and/or description of the following MIB Objects = be=20 changed to incorporate usage of DTMF and FSK.

-=20 pktcSigDevCIDFskAfterRing  = to=20 pktcSigDevCIDAfterRing; + description

- = pktcSigDevCIDFskAfterDTAS to=20 pktcSigDevCIDAfterDTAS; + description

- = pktcSigDevCIDFskAfterRPAS to=20 pktcSigDevCIDAfterRPAS; + description

- = pktcSigDevCIDRingAfterFsk to=20 pktcSigDevCIDRingAfterCID; + description

- = pktcSigDevVmwiFskAfterDTAS=20  to = pktcSigDevVmwiAfterDTAS; +=20 description

- = pktcSigDevVwmiFskAfterRPAS=20 to   = pktcSigDevVwmiAfterRPAS;=20

           &n= bsp;           &nb= sp;           &nbs= p;            = ;=20 + description

- = pktcSigDevVwmiFskDTASAfterLR=20 to pktcSigDevVwmiDTASAfterLR;

           &n= bsp;           &nb= sp;           &nbs= p;           =20  + description

- = pktcSigDevCIDMode=20 (description)    =

- = pktcSigDevVmwiMode=20 (description)

 


From: Sumanth Channabasappa =
Sent:=20 Friday, February 10, 2006 8:32 AM
To: Ipcdn=20 (E-mail)
Subject: [ipcdn] Feedback:=20 draft-ietf-ipcdn-pktc-signaling-09

Folks,
=
 
I am = sending=20 across this email to solicit feedback on = "draft-ietf-ipcdn-pktc-signaling-09"=20 (ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signal= ing-09.txt)
 
The comments I have received thus far=20 include:
 
a) Proposal to modify the current = draft to allow=20 for DTMF to be used fo VMWI (it currently assumes=20 FSK)
<Details=20 enclosed at the end of this=20 email>
<= /SPAN> 
b) Preservation of contiguous numbering=20 (editorial?)
Details can be found at: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01812.html
 
c) Offline comments on the need for = distinction between=20 CID v/s VMWI (Phil, can you post more details on=20 that)?<= /SPAN>
<= /SPAN> 
If=20 resolutions to the above issues are agreed upon, I plan to propose a new = draft=20 revision as early as next=20 week.  
<= /SPAN> 
 regards<= /SPAN>
Sumanth=
<= /SPAN> 
 
--------------- Usage = of DTMF and=20 FSK for VMWI  (source: Eugene Nechamkin, via=20 email)
There are currently four CallerID=20 signalling methods defined in Telco specs. They=20 are:
 
1. Class I with FSK
2. Class I with DTMF
3. VMWI with FSK
4. VMWI with DTMF
 
While the current = draft-09 contains=20 the means of defining the 1st two (via "pktcSigDevCallerIdSigProtocol" = MIB=20 Object), it does not allow to choose the protocol for VMWI. The draft = always=20 assumes that for VMWI, it's always FSK method which is=20 used.
 
We = found that in=20 some countries (e.g. Denmark) the #4 method is required (as per "TDK-TS 900 301-5"). There are also other contries which require = VMWI with=20 DTMF (Brazil, Sweden, Netherlands). Here is the quotation from the=20 document:
 

The MWI supplementary service = enables the served=20 user to receive an indication when a message has been delivered to the = user's=20 mailbox.

NOTE:        =20 The MWI supplementary service can currently only be used in = conjunction=20 with one of TDC Tele Danmark’s public voice-mailbox = services.

The served user can receive a = message waiting=20 indication from the VMS in two different ways:

a)       = Deferred mode: when the MWI=20 supplementary service is activated and the served user makes an outgoing = call=20 attempt, the served user is notified by means of announcement;=20 and/or;

 

b)       = Immediate mode: when the MWI=20 supplementary service has been activated, the = served user is=20 notified by means of DTMF based signalling. The intention with = this=20 notification is to give the user’s terminal the opportunity to = visually indicate=20 to the user (e.g. by means of an indication lamp) that a new message has = been=20 delivered to the VMS.

Assuming that = everybody=20 agrees that this is a deficiency of the current draft-09, the following = new MIB=20 object is proposed to fix that:
 
pktcSigDevVmwiSigProtocol  = OBJECT-TYPE =20
      =20 SYNTAX       INTEGER {=20
           &nb= sp;           &nbs= p;   =20 fsk  (1),=20
           &nb= sp;           &nbs= p;   =20 dtmf (2)
       }=20
       MAX-ACCESS   = read-write =20
      =20 STATUS       current =20
       DESCRIPTION =20
           "This = object=20 identifies the subscriber line protocol used=20
            = for=20 signalling the Information on = Visual Message Waiting Indicator=20 (VMWI). 
        &= nbsp;  =20 Different countries define different VMWI=20 signalling protocols to=20
            = support=20 VMWI service. Frequency shift = keying (FSK)=20
            = is most=20 commonly used. Dual tone multi-frequency (DTMF)=20
            = is an=20 alternative." 
        DEFVAL = { fsk }=20
   ::=3D { pktcSigDevConfigObjects X = }
&nbs= p;
----------------------------------------------= -------------------------------------------------------------------------= -----------
 
 
 
=
<= /SPAN> ------_=_NextPart_001_01C63722.FDA8D1D3-- --===============1425208082== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1425208082==-- From ipcdn-bounces@ietf.org Thu Feb 23 15:31:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCN7W-0006gj-9d; Thu, 23 Feb 2006 15:31:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCN7V-0006gL-21; Thu, 23 Feb 2006 15:31:25 -0500 Received: from [156.154.16.129] (helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCN7U-0003W4-Px; Thu, 23 Feb 2006 15:31:25 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k1NKVK0e027143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2006 20:31:20 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FCN7Q-0001pk-Do; Thu, 23 Feb 2006 15:31:20 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 23 Feb 2006 15:31:20 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ipcdn mailing list , Internet Architecture Board , ipcdn chair , ipcdn chair , RFC Editor Subject: [ipcdn] Protocol Action: 'Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable and IPCablecom compliant devices' to Proposed Standard 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 The IESG has approved the following document: - 'Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable and IPCablecom compliant devices ' as a Proposed Standard This document is the product of the IP over Cable Data Network Working Group. The IESG contact persons are Bert Wijnen and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-09.txt Technical Summary This document 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 SNMP-based management of PacketCable and IPCablecom compliant Multimedia Terminal Adapter devices. Working Group Summary The Working Group has consensus to publish this document as a Proposed Standard. Protocol Quality The MIB module has been reviewed by Dave Thaler and Randy Presuhn; an earlier version of this MIB module was reviewed by Mike Heard. The document has been reviewed by PacketCable/IPCablecom subject matter experts such as Thomas Anders, Sumanth Channabasappa, Satish Kumar, and Matt Osman. This document has been reviewed for the IESG by Bert Wijnen. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Feb 27 00:34:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDb1O-0006me-5m; Mon, 27 Feb 2006 00:34:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDb1M-0006mZ-GK for ipcdn@ietf.org; Mon, 27 Feb 2006 00:34:08 -0500 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDb1L-0003g2-3K for ipcdn@ietf.org; Mon, 27 Feb 2006 00:34:08 -0500 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [ipcdn] Last Call: 'Cable Device Management Information Base for Data-Over-Cable Service Interface Specification Compliant CableModem s and Cable Modem Termination Systems' to Proposed Standard Date: Mon, 27 Feb 2006 00:34:00 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73037CF725@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [ipcdn] Last Call: 'Cable Device Management Information Base for Data-Over-Cable Service Interface Specification Compliant CableModem s and Cable Modem Termination Systems' to Proposed Standard Thread-Index: AcY7PbXRjJhfQmHsQJKGP5hgCNawNA== From: "Woundy, Richard" To: X-OriginalArrivalTime: 27 Feb 2006 05:34:00.0649 (UTC) FILETIME=[699D5B90:01C63B5F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: "Wijnen, Bert \(Bert\)" , Jean-Francois Mule , "Woundy, Richard" , Brian Hedstrom , rdroms@cisco.com 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 Folks, This note summarizes the editor and WG chairs' response to the IETF Last = Call comment received on 12/19/2005 by the IESG from Brian Hedstrom = on the ID: = ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-10.txt. This email response has been previously shared with Brian Hedstrom and = we believe it addresses the comment raised by him, based on existing = product implementation and best common practices from DOCSIS cable = operators. In short, we propose to address Brian's comment by adding clarification = text in the current IPCDN MIB module to indicate: 1) CM implementations must report the *first* Syslog server from the = DHCP log server option value if the DHCP option received by the CM was = multi-valued, and 2) CM implementations must report the *active* time server from the DHCP = time server option value if the DHCP option received by the CM was = multi-valued. Let us know if there are any objections to this response by Friday March = 3rd 5pm Eastern Time (note that the draft submission cut-off is Monday = March 6th 9am ET). If there are no objections by this time, we will post = the revision to the draft including only these two modifications and = minimal editorial changes e.g. draft version, posting date, revision = date, etc. Then we believe the IETF Last Call process will be complete, = and we will assume the draft can proceed immediately to IESG evaluation = and approval. Rich and Jean-Fran=E7ois Mul=E9 --- Rich as Editor of the IPCDN ID and both as IPCDN co-chairs --- In introduction, the chairs would like to note the following: a) the IPCDN Internet-Draft in question is an update to RFC 2669 (the = original IPCDN Cable Device MIB) published in August 1999. The = multi-valued options in DHCP are specified in RFC 2132 which was = published prior to RFC2669 in March 1997, so the current MIB module = restrictions for a single time server and single log (Syslog) server = have been around for over six years, without any WG, vendor or cable = modem operator comments raised during the updating of the RFC based on = the inability for the MIB objects to reflect multi-value options; b) existing implementations and current DOCSIS cable modem compliance = indicate that most manufacturers do effectively treat the log server = options as single valued; c) most operators do rely on various, multiple mechanisms to provide = server redundancy for Syslog servers; and d) existing implementations and current DOCSIS (1.1 and 2.0) cable = modem compliance indicate that most manufacturers do effectively treat = the time server options as multi valued for the purpose of determining a = functional time server for a single boot-time time synchronization = event, per DOCSIS RFI 1.1 section 9.2.7 and DOCSIS RFI 2.0 section = 11.2.7. Furthermore, the Syslog server MIB object is read-writeable meaning = that, after the CM completes DHCP, the CM may download a configuration = file from the operator's OSS systems containing SNMP 'Set' commands for = that MIB object. This provides cable operators additional flexibility = and is yet another indicator that best common practice is to use a = single value to set that option in the CM configuration files. This being said, we thank Brian for his comment and we believe that the = comment should be taken into account to add clarification text in the 2 = relevant MIB objects so that new implementers faced with the same = questions know how to proceed for DOCSIS 1.x and 2.0. Even though we are = not aware of inconsistent implementations, or the practical needs to = address this concern, this may guarantee "more" consistency in the = future. As for future versions of DOCSIS, operator guidance should be = requested on these topics. --- Brian's comment: See full details at: = http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01837.html In summary, the comment raises a question on the support of multiple = Syslog servers in the CM due to the limitations of = docsDevEvSyslogAddress object when the CM is provided with multiple = server values in DHCP Option 7. As Rich pointed out in: = http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01838.html the latest DOCSIS RFI specification available at: = , in annex D.1.1, and RFC 2132, defines 5 DHCP options. Three of out the = five standard DHCP options specified are allowed to be multi-valued: * Option code 3 (Router Option) * Option code 4 (Time Server Option) -> docsDevServerTimeAddress * Option code 7 (Log Server Option) -> docsDevEvSyslogAddress Note that the Router Option is not referenced by any MIB object in this = MIB module. Based on the rationale explained above in introduction of this email, we = propose to add the following text to the following objects in ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-10.txt: - docsDevServerTimeAddress: NEW TEXT: docsDevServerTimeAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Internet address of the RFC 868 Time server as provided by DHCP option 4.=20 Note that if multiple values are provided to the=20 CM in DHCP option 4, the value of this MIB object MUST be the Time server address from which the Time of Day reference was acquired based on the DOCSIS=20 RFI specification. During the period of time where the Time of Day have not been acquired, the Time=20 server address reported by the CM may report the=20 first address value in the DHCP option value or the last server address the CM attempted to get the Time of day value. Returns the zero length octet string if the time server IP address is not provisioned." REFERENCE "DOCSIS RFI 1.1 Specification, Section 9.2.7. and DOCSIS RFI 2.0 Specification, Section 11.2.7." ::=3D { docsDevServer 9 } - docsDevEvSyslogAddress: NEW TEXT: docsDevEvSyslogAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The Internet address of the Syslog server as provided by DHCP option 7 or set via SNMP management. If the address of the server is set to any of the zero length string, the 0.0.0.0 IPv4 address or the 0: IPv6 address, Syslog transmission is inhibited. =20 Note that if multiple values are provided to the CM in DHCP option 7, the value of this MIB object MUST be the first Syslog server address received. By default at agent boot, this object returns the zero length string." ::=3D { docsDevEvent 10 } We believe this addresses the comment by indicating how current = implementations deal with this situation. ------------------------------------------------------------------ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Feb 27 10:46:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkaI-0004qY-R3; Mon, 27 Feb 2006 10:46:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkaH-0004qN-Uy for ipcdn@ietf.org; Mon, 27 Feb 2006 10:46:49 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDkaH-0007C9-CV for ipcdn@ietf.org; Mon, 27 Feb 2006 10:46:49 -0500 Received: from ([10.20.62.12]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.17255364; Mon, 27 Feb 2006 10:44:53 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Feb 2006 10:45:58 -0500 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Re: [ipcdn] Last Call: 'Cable Device Management Information Base for Data-Over-Cable Service Interface Specification Compliant CableModem s and Cable Modem Termination Systems' to Proposed Standard Date: Mon, 27 Feb 2006 10:44:52 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73037CF72F@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [ipcdn] Last Call: 'Cable Device Management Information Base for Data-Over-Cable Service Interface Specification Compliant CableModem s and Cable Modem Termination Systems' to Proposed Standard Thread-Index: AcY7PbXRjJhfQmHsQJKGP5hgCNawNAAdM13A From: "Woundy, Richard" To: X-OriginalArrivalTime: 27 Feb 2006 15:45:58.0097 (UTC) FILETIME=[E6EB4C10:01C63BB4] X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: "Wijnen, Bert \(Bert\)" , Jean-Francois Mule , "Woundy, Richard" , Brian Hedstrom , rdroms@cisco.com 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 Folks, I incorporated the changes mentioned below in a preliminary draft, = , with the XML version at = . Your comments are solicited and encouraged; this is the version I = currently plan to submit on March 3rd if all goes well. I performed all of the same checks (online idnits tool, xml2rfc = validator tool, and smilint) on this draft version, and got the same = results (basically clean) as performed in = . As I edited the current draft, I discovered we needed one more update. = We "anticipated" outbound LLC filters in the DOCSIS QoS MIB draft in = section 3.3.4; now that the DOCSIS QoS MIB is published as RFC 4323, the = text needed to be corrected. In addition, I needed to update the = reference to the permanent RFC number, of course. OLD TEXT Lastly, any outbound LLC filters are applied to the packet just prior to it being emitted on the appropriate interface. This MIB module does not specify any outbound LLC filters, but it is anticipated that the Quality of Service (QoS) additions to the DOCSIS standard [I-D.ietf-ipcdn-qos-mib] may include some outbound LLC filtering requirements. If so, those filters would be applied as described there. NEW TEXT Lastly, any outbound LLC filters are applied to the packet just prior to it being emitted on the appropriate interface. This MIB module does not specify any outbound LLC filters, but section 3 of the DOCSIS Quality of Service (QoS) MIB, [RFC4323], includes outbound LLC filtering requirements. -- Rich -----Original Message----- From: Woundy, Richard=20 Sent: Monday, February 27, 2006 12:34 AM To: ipcdn@ietf.org Cc: Brian Hedstrom; Wijnen, Bert (Bert); rdroms@cisco.com; Jean-Francois = Mule; Woundy, Richard Subject: Re: [ipcdn] Last Call: 'Cable Device Management Information = Base for Data-Over-Cable Service Interface Specification Compliant = CableModem s and Cable Modem Termination Systems' to Proposed Standard Folks, This note summarizes the editor and WG chairs' response to the IETF Last = Call comment received on 12/19/2005 by the IESG from Brian Hedstrom = on the ID: = ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-10.txt. This email response has been previously shared with Brian Hedstrom and = we believe it addresses the comment raised by him, based on existing = product implementation and best common practices from DOCSIS cable = operators. In short, we propose to address Brian's comment by adding clarification = text in the current IPCDN MIB module to indicate: 1) CM implementations must report the *first* Syslog server from the = DHCP log server option value if the DHCP option received by the CM was = multi-valued, and 2) CM implementations must report the *active* time server from the DHCP = time server option value if the DHCP option received by the CM was = multi-valued. Let us know if there are any objections to this response by Friday March = 3rd 5pm Eastern Time (note that the draft submission cut-off is Monday = March 6th 9am ET). If there are no objections by this time, we will post = the revision to the draft including only these two modifications and = minimal editorial changes e.g. draft version, posting date, revision = date, etc. Then we believe the IETF Last Call process will be complete, = and we will assume the draft can proceed immediately to IESG evaluation = and approval. Rich and Jean-Fran=E7ois Mul=E9 --- Rich as Editor of the IPCDN ID and both as IPCDN co-chairs --- In introduction, the chairs would like to note the following: a) the IPCDN Internet-Draft in question is an update to RFC 2669 (the = original IPCDN Cable Device MIB) published in August 1999. The = multi-valued options in DHCP are specified in RFC 2132 which was = published prior to RFC2669 in March 1997, so the current MIB module = restrictions for a single time server and single log (Syslog) server = have been around for over six years, without any WG, vendor or cable = modem operator comments raised during the updating of the RFC based on = the inability for the MIB objects to reflect multi-value options; b) existing implementations and current DOCSIS cable modem compliance = indicate that most manufacturers do effectively treat the log server = options as single valued; c) most operators do rely on various, multiple mechanisms to provide = server redundancy for Syslog servers; and d) existing implementations and current DOCSIS (1.1 and 2.0) cable = modem compliance indicate that most manufacturers do effectively treat = the time server options as multi valued for the purpose of determining a = functional time server for a single boot-time time synchronization = event, per DOCSIS RFI 1.1 section 9.2.7 and DOCSIS RFI 2.0 section = 11.2.7. Furthermore, the Syslog server MIB object is read-writeable meaning = that, after the CM completes DHCP, the CM may download a configuration = file from the operator's OSS systems containing SNMP 'Set' commands for = that MIB object. This provides cable operators additional flexibility = and is yet another indicator that best common practice is to use a = single value to set that option in the CM configuration files. This being said, we thank Brian for his comment and we believe that the = comment should be taken into account to add clarification text in the 2 = relevant MIB objects so that new implementers faced with the same = questions know how to proceed for DOCSIS 1.x and 2.0. Even though we are = not aware of inconsistent implementations, or the practical needs to = address this concern, this may guarantee "more" consistency in the = future. As for future versions of DOCSIS, operator guidance should be = requested on these topics. --- Brian's comment: See full details at: = http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01837.html In summary, the comment raises a question on the support of multiple = Syslog servers in the CM due to the limitations of = docsDevEvSyslogAddress object when the CM is provided with multiple = server values in DHCP Option 7. As Rich pointed out in: = http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01838.html the latest DOCSIS RFI specification available at: = , in annex D.1.1, and RFC 2132, defines 5 DHCP options. Three of out the = five standard DHCP options specified are allowed to be multi-valued: * Option code 3 (Router Option) * Option code 4 (Time Server Option) -> docsDevServerTimeAddress * Option code 7 (Log Server Option) -> docsDevEvSyslogAddress Note that the Router Option is not referenced by any MIB object in this = MIB module. Based on the rationale explained above in introduction of this email, we = propose to add the following text to the following objects in ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-10.txt: - docsDevServerTimeAddress: NEW TEXT: docsDevServerTimeAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Internet address of the RFC 868 Time server as provided by DHCP option 4.=20 Note that if multiple values are provided to the=20 CM in DHCP option 4, the value of this MIB object MUST be the Time server address from which the Time of Day reference was acquired based on the DOCSIS=20 RFI specification. During the period of time where the Time of Day have not been acquired, the Time=20 server address reported by the CM may report the=20 first address value in the DHCP option value or the last server address the CM attempted to get the Time of day value. Returns the zero length octet string if the time server IP address is not provisioned." REFERENCE "DOCSIS RFI 1.1 Specification, Section 9.2.7. and DOCSIS RFI 2.0 Specification, Section 11.2.7." ::=3D { docsDevServer 9 } - docsDevEvSyslogAddress: NEW TEXT: docsDevEvSyslogAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The Internet address of the Syslog server as provided by DHCP option 7 or set via SNMP management. If the address of the server is set to any of the zero length string, the 0.0.0.0 IPv4 address or the 0: IPv6 address, Syslog transmission is inhibited. =20 Note that if multiple values are provided to the CM in DHCP option 7, the value of this MIB object MUST be the first Syslog server address received. By default at agent boot, this object returns the zero length string." ::=3D { docsDevEvent 10 } We believe this addresses the comment by indicating how current = implementations deal with this situation. ------------------------------------------------------------------ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Feb 28 10:47:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE74B-0001qC-PJ; Tue, 28 Feb 2006 10:47:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE749-0001pc-Vg; Tue, 28 Feb 2006 10:47:09 -0500 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE748-00088B-My; Tue, 28 Feb 2006 10:47:09 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k1SFl5Eo014236; Tue, 28 Feb 2006 09:47:06 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Feb 2006 16:47:04 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550972162E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ted Hardie (E-mail)" Date: Tue, 28 Feb 2006 16:47:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: "Ipcdn \(E-mail\)" , "Iesg \(E-mail\)" Subject: [ipcdn] Evaluation of: draft-ietf-ipcdn-docs-rfmibv2-14.txt 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 Ted, I have added RFC-Editor note to to ensure your comment gets seen: Note to RFC Editor - In the abstract, pls change OLD: This document revises and obsoletes RFC 2670. Please see section 6 for a description of the changes from RFC 2670. NEW: This document revises and obsoletes RFC 2670. Please see section 5.3 for a description of the changes from RFC 2670. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Feb 28 15:37:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEBah-0002pc-6i; Tue, 28 Feb 2006 15:37:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEBag-0002pR-IO for ipcdn@ietf.org; Tue, 28 Feb 2006 15:37:02 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEBaf-0001M2-93 for ipcdn@ietf.org; Tue, 28 Feb 2006 15:37:02 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id k1SKb0UW028813; Tue, 28 Feb 2006 13:37:00 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Feb 2006 13:37:00 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: COMMENT: draft-ietf-ipcdn-docs-rfmibv2 Thread-Index: AcY8kSHgPCemnS1jQpuvZkgPZmxucAAFXOnw From: "Jean-Francois Mule" To: "Ipcdn (E-mail)" , "Russ Housley" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [ipcdn] FW: COMMENT: draft-ietf-ipcdn-docs-rfmibv2 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 fyi - this is valid for all references to ITU-T.=20 Thanks Russ. Jean-Francois -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: Tuesday, February 28, 2006 11:02 AM To: iesg@ietf.org Cc: Richard Woundy @ Comcast; RWoundy@broadband.att.com; Jean-Francois Mule; Randy_Presuhn@mindspring.com; david.raftus@terayon.com; Eduardo Cardona Subject: COMMENT: draft-ietf-ipcdn-docs-rfmibv2=20 Comment: Section 2.9: s/ITU-T J112/ITU-T Recommendation J.112/ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Feb 28 16:12:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEC95-0003jy-1g; Tue, 28 Feb 2006 16:12:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEC91-0003iz-IB for ipcdn@ietf.org; Tue, 28 Feb 2006 16:12:31 -0500 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEC90-0005M2-7m for ipcdn@ietf.org; Tue, 28 Feb 2006 16:12:31 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k1SLCRDL028588; Tue, 28 Feb 2006 15:12:27 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Feb 2006 22:12:26 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509721720@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Jean-Francois Mule , "Ipcdn (E-mail)" , Russ Housley Subject: RE: [ipcdn] FW: COMMENT: draft-ietf-ipcdn-docs-rfmibv2 Date: Tue, 28 Feb 2006 22:12:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 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 So may I ask the authors to keep this in mind for AUTH48? That is if there is not other reason to recycle, which we will only know by Thursday. Bert > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Tuesday, February 28, 2006 21:37 > To: Ipcdn (E-mail); Russ Housley > Subject: [ipcdn] FW: COMMENT: draft-ietf-ipcdn-docs-rfmibv2 > > > fyi - this is valid for all references to ITU-T. > Thanks Russ. > Jean-Francois > > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Tuesday, February 28, 2006 11:02 AM > To: iesg@ietf.org > Cc: Richard Woundy @ Comcast; RWoundy@broadband.att.com; Jean-Francois > Mule; Randy_Presuhn@mindspring.com; david.raftus@terayon.com; Eduardo > Cardona > Subject: COMMENT: draft-ietf-ipcdn-docs-rfmibv2 > > Comment: > > Section 2.9: s/ITU-T J112/ITU-T Recommendation J.112/ > > > > _______________________________________________ > 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