From mailman-bounces@ietf.org Mon Nov 1 06:44:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20017 for ; Mon, 1 Nov 2004 06:44:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COar5-00053X-GG for ipcdn-archive@ietf.org; Mon, 01 Nov 2004 07:00:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZRV-0001hD-D9 for ipcdn-archive@ietf.org; Mon, 01 Nov 2004 05:29:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ipcdn-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:11:04 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ipcdn-archive@ietf.org: List Password // URL ---- -------- ipcdn@ietf.org ichuas https://www1.ietf.org/mailman/options/ipcdn/ipcdn-archive%40ietf.org From ipcdn-bounces@ietf.org Mon Nov 1 17:30:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13888 for ; Mon, 1 Nov 2004 17:30:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COkwN-0006mp-S7 for ipcdn-archive@ietf.org; Mon, 01 Nov 2004 17:46:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COkMT-0007iK-2a; Mon, 01 Nov 2004 17:09:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COk3S-0002AT-BU for ipcdn@megatron.ietf.org; Mon, 01 Nov 2004 16:49:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01036 for ; Mon, 1 Nov 2004 16:01:41 -0500 (EST) Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COjY5-0003Dc-Nw for ipcdn@ietf.org; Mon, 01 Nov 2004 16:17:11 -0500 Message-ID: From: "Woundy, Richard" To: "'ipcdn@ietf.org'" Date: Mon, 1 Nov 2004 16:00:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [ipcdn] Updates to IPCDN internet-drafts 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="===============1439513246==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1439513246== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C055.D55F0DF8" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C055.D55F0DF8 Content-Type: text/plain Folks, See http://www.ipcdn.org/ipcdn-ids.html for updates about the current internet-drafts under development in the IPCDN WG. I have tried to update the status of all drafts, and have included a number of new useful per-draft links (i.e. "See current IESG status"). Please send any comments and corrections to me. -- Rich ------_=_NextPart_001_01C4C055.D55F0DF8 Content-Type: text/html Message
Folks,
 
See http://www.ipcdn.org/ipcdn-ids.html for updates about the current internet-drafts under development in the IPCDN WG. I have tried to update the status of all drafts, and have included a number of new useful per-draft links (i.e. "See current IESG status").
 
Please send any comments and corrections to me.
 
-- Rich
 
 
------_=_NextPart_001_01C4C055.D55F0DF8-- --===============1439513246== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1439513246==-- From ipcdn-bounces@ietf.org Wed Nov 3 14:21:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10327 for ; Wed, 3 Nov 2004 14:21:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPQwW-00053B-UV for ipcdn-archive@ietf.org; Wed, 03 Nov 2004 14:37:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQgT-0003CI-Ch; Wed, 03 Nov 2004 14:20:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQe4-0002ib-3V for ipcdn@megatron.ietf.org; Wed, 03 Nov 2004 14:18:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10024 for ; Wed, 3 Nov 2004 14:18:10 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPQtQ-0004x3-9G for ipcdn@ietf.org; Wed, 03 Nov 2004 14:34:05 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id iA3JHb1e016379 for ; Wed, 3 Nov 2004 12:17:37 -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 Subject: [ipcdn] Agenda for the IETF#61 IPCDN Nov 9 2004 meeting in Washington DC Date: Wed, 3 Nov 2004 12:17:37 -0700 Message-ID: Thread-Topic: [ipcdn] Agenda for the IETF#61 IPCDN Nov 9 2004 meeting in Washington DC Thread-Index: AcR4uuU8rfQDBRxZSKK+nsZFvvTiKRFMBYZQAPrgEoA= From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable =20 IP over Cable Data Network WG (ipcdn) IETF #61 =20 TUESDAY, November 9, 2004, from 1300 to 1400 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Chairs: Richard Woundy Jean-Francois Mule =20 AGENDA: =20 I. Agenda Bashing =20 II. Administration Review WG Charter & milestones update http://www.ietf.org/html.charters/ipcdn-charter.html=20 III. IPCDN DOCSIS mibs =20 Discuss latest status of all DOCSIS mibs Discuss IESG comments o DOCSIS BPI+ MIB http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-bpiplus-mib-14.txt o DOCSIS QoS MIB http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-10.txt o RF MIB v2 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-11.txt o DOCSIS Event Notification MIB=20 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docsisevent-mib-04. txt o DOCSIS Cable Device MIB version 2 http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-06.txt IV. IPCablecom/PacketCable Submissions o MTA MIB http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-05.txt o Signaling MIB http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-07.t xt=20 V. Next steps -- Richard Woundy and Jean-Francois Mule, IPCDN co-chairs _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Nov 3 14:37:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11812 for ; Wed, 3 Nov 2004 14:37:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPRCX-0005OX-KY for ipcdn-archive@ietf.org; Wed, 03 Nov 2004 14:53:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQre-0004QG-Uc; Wed, 03 Nov 2004 14:32:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQm7-0003Wh-2v for ipcdn@megatron.ietf.org; Wed, 03 Nov 2004 14:26:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10711 for ; Wed, 3 Nov 2004 14:26:29 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPR1R-00058A-Az for ipcdn@ietf.org; Wed, 03 Nov 2004 14:42:24 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id iA3JPs1e017727 for ; Wed, 3 Nov 2004 12:25:54 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Call for volunteer to be the editor of RFC 2669bis Date: Wed, 3 Nov 2004 12:25:54 -0700 Message-ID: Thread-Topic: [ipcdn] Call for volunteer to be the editor of RFC 2669bis Thread-Index: AcTB2u9I/PEzGxRyQteGcAX0eXySMg== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Folks, We are hitting a roadblock on the cable dev mib and need a new ID = editor. http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-06.txt is = expired. The current status is that numerous comments were received from mib = doctors and a new draft is needed. While some comments have been = addressed in an alpha version of draft 07, we need someone who can take = over the draft and complete the work. While Rich and I can offer = support, we cannot commit to being draft editors anymore on this one. = Rich and I can give more technical details on what's left to address in = draft 07 if needed. Anyone interested? Please let us know via email, or, if you are not = sure yet and want to chat live, ping us and we can organize a call or = chat live at the IETF meeting in Washington DC next week. Thanks, -- Rich and Jean-Fran=E7ois _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Nov 4 08:09:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17199 for ; Thu, 4 Nov 2004 08:09:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPhcB-0003TW-WD for ipcdn-archive@ietf.org; Thu, 04 Nov 2004 08:25:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPhKB-000560-UQ; Thu, 04 Nov 2004 08:06:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPhBb-0003iS-5l for ipcdn@megatron.ietf.org; Thu, 04 Nov 2004 07:57:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16075 for ; Thu, 4 Nov 2004 07:57:54 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPhR8-00038e-3p for ipcdn@ietf.org; Thu, 04 Nov 2004 08:13:58 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iA4CvMpi005759 for ; Thu, 4 Nov 2004 06:57:23 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <4M32R0F8>; Thu, 4 Nov 2004 13:57:21 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79F0C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Date: Thu, 4 Nov 2004 13:57:18 +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: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [ipcdn] FW: TOS byte and DSCP 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 FYI, and editor/author, pls take note of the nit, so we can fix that after IETF Last Call finishes. Bert -----Original Message----- From: Brian E Carpenter [mailto:brc@zurich.ibm.com] Sent: Thursday, November 04, 2004 13:33 To: Wijnen, Bert (Bert) Subject: Re: TOS byte and DSCP Quick after-lunch check: I think that what they have done is quite reasonable, to allow for DOCSIS backwards compatibility with diffserv. One nit though: both in the MIB and in the normative references they refer to RFC 3260. That's an Informational RFC on terminology. The correct normative reference is RFC 2474. Brian Wijnen, Bert (Bert) wrote: > Brian, the cable guys have a spec in which they still show > (for monitoring) a so called TOS Byte. > I have got them to (in my view) properly describe that that TOS byte > is no longer to be used and that DSCP is used instead. So at least > proper warnings are there (I think). > > Can you do a quick check on document > draft-ietf-ipcdn-qos-mib-10.txt > and see if the text w.r.t. TOS and DSCP is OK ?? > > I may be doing IETF Last Call while you are looking at this > (assuming your response is yes). So whatever feedback you have > can be picked up as IETF Last Call comments. > > Thanks, > Bert > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Nov 4 10:05:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27591 for ; Thu, 4 Nov 2004 10:05:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjQz-0006NI-HM for ipcdn-archive@ietf.org; Thu, 04 Nov 2004 10:21:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPj9w-00052h-GE; Thu, 04 Nov 2004 10:04:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPj3d-0001IL-K0 for ipcdn@megatron.ietf.org; Thu, 04 Nov 2004 09:57:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26758 for ; Thu, 4 Nov 2004 09:57:47 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjJ9-0006AM-Pl for ipcdn@ietf.org; Thu, 04 Nov 2004 10:13:53 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iA4EvidW000563 for ; Thu, 4 Nov 2004 08:57:45 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <4M32SDK7>; Thu, 4 Nov 2004 15:57:44 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79F10@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Date: Thu, 4 Nov 2004 15:57:42 +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: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [ipcdn] AD review: draft-ietf-ipcdn-docsisevent-mib-04.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Not a final review, just a question first that came up when I did a quick initial browse: I do not understand: MODULE -- docsDevNotif --mandatory groups GROUP docsDevCmNotifControlGroup DESCRIPTION "Mandatory in CM." GROUP docsDevCmNotificationGroup DESCRIPTION "Mandatory in CM." ::= { docsDevNotifCompliances 1 } Why would you not specify instead: docsDevCmNotifCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for CM Notifications and Control" MODULE --docsDevNotif MANDATORY-GROUPS { docsDevCmNotifControlGroup, docsDevCmNotificationGroup } After all, it is the compliance for CM, and for a CM, both groups are mandatory. So using my alternate method makes that a spec that is machine readable. Same for the Cmts compliance of course. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Nov 4 11:49:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08990 for ; Thu, 4 Nov 2004 11:49:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPl2u-0000Z5-B0 for ipcdn-archive@ietf.org; Thu, 04 Nov 2004 12:05:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPkgD-0001oR-5o; Thu, 04 Nov 2004 11:41:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPkXu-0003sc-S8 for ipcdn@megatron.ietf.org; Thu, 04 Nov 2004 11:33:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07288 for ; Thu, 4 Nov 2004 11:33:08 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPknQ-00005Z-5i for ipcdn@ietf.org; Thu, 04 Nov 2004 11:49:15 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iA4GYUnQ021186 for ; Thu, 4 Nov 2004 09:34:31 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id iA4GX3ZX018597 for ; Thu, 4 Nov 2004 10:33:03 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Thu, 4 Nov 2004 08:33:02 -0800 Message-ID: From: Nakanishi Greg-MGI8179 To: "'Wijnen, Bert (Bert)'" , "Ipcdn (E-mail)" Subject: RE: [ipcdn] AD review: draft-ietf-ipcdn-docsisevent-mib-04.txt Date: Thu, 4 Nov 2004 08:33:01 -0800 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: 7aafa0432175920a4b3e118e16c5cb64 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Burt, OK with me. I'll get the update into the next revision. Thanks, greg -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Thursday, November 04, 2004 6:58 AM To: Ipcdn (E-mail) Subject: [ipcdn] AD review: draft-ietf-ipcdn-docsisevent-mib-04.txt Not a final review, just a question first that came up when I did a quick initial browse: I do not understand: MODULE -- docsDevNotif --mandatory groups GROUP docsDevCmNotifControlGroup DESCRIPTION "Mandatory in CM." GROUP docsDevCmNotificationGroup DESCRIPTION "Mandatory in CM." ::= { docsDevNotifCompliances 1 } Why would you not specify instead: docsDevCmNotifCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for CM Notifications and Control" MODULE --docsDevNotif MANDATORY-GROUPS { docsDevCmNotifControlGroup, docsDevCmNotificationGroup } After all, it is the compliance for CM, and for a CM, both groups are mandatory. So using my alternate method makes that a spec that is machine readable. Same for the Cmts compliance of course. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Nov 4 16:48:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09872 for ; Thu, 4 Nov 2004 16:48:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPpjA-00087w-8U for ipcdn-archive@ietf.org; Thu, 04 Nov 2004 17:05:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpNQ-00035v-Rh; Thu, 04 Nov 2004 16:42:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpEa-000084-84; Thu, 04 Nov 2004 16:33:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08263; Thu, 4 Nov 2004 16:33:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPpUB-0007i4-HI; Thu, 04 Nov 2004 16:49:39 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CPp1C-0003Qv-NZ; Thu, 04 Nov 2004 16:19:42 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 04 Nov 2004 16:19:42 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ipcdn mailing list , Internet Architecture Board , ipcdn chair , ipcdn chair , ipcdn chair , RFC Editor Subject: [ipcdn] Protocol Action: 'Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management' 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: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 The IESG has approved the following document: - 'Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management ' 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. Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. The Differentiated Services MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification. Working Group Summary The working group has consensus on this document for publication on the standards track. Protocol Quality This document was reviewed for the IESG by Mike Heard, Harrie Hazewinkel and Bert Wijnen. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Nov 4 17:17:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13418 for ; Thu, 4 Nov 2004 17:17:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPqB6-0000gD-Km for ipcdn-archive@ietf.org; Thu, 04 Nov 2004 17:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpuE-0003CP-5B; Thu, 04 Nov 2004 17:16:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpmF-0000z6-Hv; Thu, 04 Nov 2004 17:08:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12283; Thu, 4 Nov 2004 17:08:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPq1r-0000Or-Fl; Thu, 04 Nov 2004 17:24:27 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CPpa7-0005SX-EC; Thu, 04 Nov 2004 16:55:47 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 04 Nov 2004 16:55:47 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipcdn@ietf.org Subject: [ipcdn] Last Call: 'Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QOS MIB)' 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 The IESG has received a request from the IP over Cable Data Network WG to consider the following document: - 'Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QOS MIB) ' as a Proposed Standard 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 2004-11-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-10.txt _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Nov 9 02:29:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23840 for ; Tue, 9 Nov 2004 02:29:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRQS2-0003JL-TL for ipcdn-archive@ietf.org; Tue, 09 Nov 2004 02:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRQPz-0002rb-Jm; Tue, 09 Nov 2004 02:27:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRQO7-0001zm-EZ for ipcdn@megatron.ietf.org; Tue, 09 Nov 2004 02:25:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23514 for ; Tue, 9 Nov 2004 02:25:57 -0500 (EST) Received: from hal-4.inet.it ([213.92.5.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRQOo-0003Ev-Dw for ipcdn@ietf.org; Tue, 09 Nov 2004 02:26:43 -0500 Received: from harrie2.inet.it [::ffff:213.92.1.196] by hal-4.inet.it via I-SMTP-5.1.13-51A id ::ffff:213.92.1.196+1rf6KITNGpSl; Tue, 09 Nov 2004 08:25:47 +0100 Message-ID: <41907101.9080604@inet.it> Date: Tue, 09 Nov 2004 08:25:53 +0100 From: Harrie Hazewinkel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipcdn@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [ipcdn] Expert review comments on draft-ietf-ipcdn-docsisevent-mib-04 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit HI all, becuase I had done the MIB review of the DOCSISEVENT-MIB I checked if all comments were inserted OK. The draft is OK with me except for a small thing. The IMPORT of DOCS-IF-MIB has a comment refering to the old internet draft version 10. This is currently draft 11. FROM DOCS-IF-MIB -- draft-ietf-ipcdn-docs-rfmibv2-10 I understand this will be replaced with the RFC, but would it not be a good idea to add a note that it is not the obsoleted RFC? I had the old one first and got loads of MIB checking errors and wondered for a some seeconds. The note would help others (maybe). regards, Harrie _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Nov 15 15:26:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29367 for ; Mon, 15 Nov 2004 15:26:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTnT6-0007GJ-KE for ipcdn-archive@ietf.org; Mon, 15 Nov 2004 15:28:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTnPU-0004U3-0Y; Mon, 15 Nov 2004 15:25:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTnNp-0003QS-ES for ipcdn@megatron.ietf.org; Mon, 15 Nov 2004 15:23:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28929 for ; Mon, 15 Nov 2004 15:23:27 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTnPq-0007Aq-9F for ipcdn@ietf.org; Mon, 15 Nov 2004 15:25:37 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id iAFKMf1e010693; Mon, 15 Nov 2004 13:22:41 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4CB50.DB5880A3" Date: Mon, 15 Nov 2004 13:22:41 -0700 Message-ID: <5259D0D7419C6149B347837A2E64F46F0749B5@srvxchg.cablelabs.com> X-MS-Has-Attach: yes Thread-Topic: Next release BPI+ MIB change notes Thread-Index: AcTAYqbPkf6wk9MwTc6OpXpcLklkAgK2wvwQ From: "Eduardo Cardona" To: X-Approved: ondar X-Spam-Score: 0.3 (/) X-Scan-Signature: 9361ae25efd9cff62e36f70ef966350e Cc: Jean-Francois Mule , "Richard Woundy @ Comcast" Subject: [ipcdn] Next release BPI+ MIB change notes 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 81ca0cebdb446e1ff4e2b634791f24a9 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4CB50.DB5880A3 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C4CB50.DB5880A3" ------_=_NextPart_002_01C4CB50.DB5880A3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Please find attached the MIB objects changes for the next revision of BPI+ MIB module. =20 IESG revised and made comments in the IPDN MIB module draft 14 =20 Here is a summary of the changes: We are adding additional enumerations for the MIB definitions of encryption and integrity algorithms of TEKs =20 For TEK Encryption: CBC mode for 3DES 128 bits key and AES 128 and 256 bit keys For TEK Integrity message also HMAC SHA1 is added to the corresponding enumeration =20 Currently BPI+ spec does not support such cipher suites, so the appropriate compliance statements are included.=20 The security considerations also will reflect the recommendation of using strong data encryption as outlined by the MIB. =20 =20 Changes Details: 4 Data Encryption objects (CM/CMTS) are in the MIB module 4 Data Authentication objects (CM/CMTS) are in the MIB module =20 Define two textual Convention for both cases : DocsBpkmSAType, DocsBpkmDataEncryptAlg =20 Added Compliance Statements to CM and CMTS compliances to indicate compliance based on current BPI+ spec requirements. =20 =20 The changes are quite straight and If we all agree in the proposed changes by Thursday Nov 18, the MIB will be posted Friday Nov 19. =20 =20 =20 Security Section=20 Removed the TEK lifetime shortening as a way to "improve" confidentiality. IESG comments in that respect were it will not stop non-real time data de-cryption : =20 BPI+ Encryption Algorithms: BPI+ Traffic Encryption Keys TEK (see [1]) uses DES=20 (Data Encryption Standard) 56 or 40 bits encryption ciphers and no=20 data Intergrity algorithms. Due DES cryptographic strength weakness, future revisions of BPI+=20 specification [1] should introduce advanced encryption algorithms=20 as described in DocsBpkmDataEncryptAlg textual convention to overcome the progress in cheaper and faster hardware that makes feasible=20 brute-force DES decryption. =20 To prevent data tampering BPI+ spcification [1] should adopt Message =20 integrity schemas as described in DocsBpkmDataAuthentAlg textual convention. =20 Let me know any comments.=20 Thanks =20 =20 Eduardo =20 =20 ---Original Message----- From: Richard Woundy @ Comcast=20 Sent: Monday, November 01, 2004 2:01 PM To: 'ipcdn@ietf.org' Subject: [ipcdn] Updates to IPCDN internet-drafts Folks, =20 See http://www.ipcdn.org/ipcdn-ids.html for updates about the current internet-drafts under development in the IPCDN WG. I have tried to update the status of all drafts, and have included a number of new useful per-draft links (i.e. "See current IESG status"). =20 Please send any comments and corrections to me. =20 -- Rich =20 =20 ------_=_NextPart_002_01C4CB50.DB5880A3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 all,
Please=20 find attached the MIB objects changes for the next revision of BPI+ MIB=20 module.
 
IESG=20 revised and made comments in the IPDN MIB module draft=20 14
 
Here=20 is a summary of the changes:
We are=20 adding additional enumerations for the MIB definitions = of encryption=20 and integrity algorithms of TEKs
 
For=20 TEK Encryption: CBC mode for  3DES 128 bits key and AES = 128 and=20 256 bit keys
For=20 TEK Integrity message also HMAC SHA1 is added to the corresponding=20 enumeration  
Currently BPI+ spec does not support such cipher suites, so the = appropriate compliance statements are included.
The=20 security considerations also will reflect the recommendation of using = strong=20 data encryption as outlined by the MIB.
 
 
Changes Details:
4 Data=20 Encryption objects (CM/CMTS) are in the MIB module
4 Data=20 Authentication objects (CM/CMTS) are in the MIB = module
 
Define=20 two textual Convention for both cases :
DocsBpkmSAType, DocsBpkmDataEncryptAlg
 
Added Compliance Statements to CM and CMTS = compliances=20 to indicate compliance based on current BPI+ spec=20 requirements.
   
 
The changes are quite straight and If we all agree=20 in the proposed changes by Thursday Nov 18, the MIB will be posted = Friday=20 Nov 19.  
 
 
Security Section
Removed the TEK lifetime shortening as a way = to=20 "improve" confidentiality.
IESG comments in that respect were it will = not stop=20 non-real time data=20 de-cryption :
 

BPI+ Encryption=20 Algorithms:

BPI+ Traffic=20 Encryption Keys TEK (see [1]) uses DES =

(Data Encryption=20 Standard) 56 or 40 bits encryption ciphers =20 and no 

data Intergrity=20 algorithms.

Due = DES=20 cryptographic strength weakness, future revisions of BPI+=20

specification [1]=20 should introduce advanced encryption algorithms 

as described in DocsBpkmDataEncryptAlg textual = convention to = overcome

the progress=20 in cheaper and faster  hardware that makes feasible=20

brute-force=20 DES = decryption.  

To prevent  data tampering BPI+ spcification = [1]=20 should adopt Message  

integrity schemas as described in DocsBpkmDataAuthentAlg textual=20 convention.

 
Let me know any comments. =
Thanks
 
 
Eduardo
 
 
 ---Original = Message-----
From:=20 Richard Woundy @ Comcast
Sent: Monday, November 01, 2004 2:01 = PM
To: 'ipcdn@ietf.org'
Subject: [ipcdn] Updates to = IPCDN=20 internet-drafts

Folks,
 
See = http://www.ipcdn.org/ipcdn-ids.html for updates about the current internet-drafts under = development in the=20 IPCDN WG. I have tried to update the status of all drafts, and have = included a=20 number of new useful per-draft links (i.e. "See current IESG=20 status").
 
Please send any=20 comments and corrections to me.
 
--=20 Rich
 
 
------_=_NextPart_002_01C4CB50.DB5880A3-- ------_=_NextPart_001_01C4CB50.DB5880A3 Content-Type: text/plain; name="MIB-object Changes for Draft 15.txt" Content-Transfer-Encoding: base64 Content-Description: MIB-object Changes for Draft 15.txt Content-Disposition: attachment; filename="MIB-object Changes for Draft 15.txt" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 LS0gVEVYVFVBTC1DT05WRU5USU9OUw0KDQoNCkRvY3NCcGttRGF0YUVuY3J5cHRBbGcgOjo9IFRF WFRVQUwtQ09OVkVOVElPTg0KICAgICAgICBTVEFUVVMgICAgY3VycmVudA0KICAgICAgICBERVND UklQVElPTg0KICAgICAgICAgICAgIlRoZSBsaXN0IG9mIGRhdGEgZW5jcnlwdGlvbiBhbGdvcml0 aG1zIGRlZmluZWQgZm9yIA0KICAgICAgICB0aGUgRE9DU0lTIGludGVyZmFjZSBpbiB0aGUgQlBL TSBjcnlwdG9ncmFwaGljLXN1aXRlIA0KICAgICAgICBwYXJhbWV0ZXIuICBUaGUgVmFsdWUgJ25v bmUnIGlzIGluZGljYXRlcyB0aGF0IHRoZSBTQUlEIA0KICAgICAgICBiZWluZyByZWZlcmVuY2Vk IGhhcyBubyBkYXRhIGVuY3J5cHRpb24uIg0KICAgICAgICBSRUZFUkVOQ0UNCiAgICAgICAgICAg ICAiRE9DU0lTIEJhc2VsaW5lIFByaXZhY3kgUGx1cyBJbnRlcmZhY2UgU3BlY2lmaWNhdGlvbiwN CiAgICAgICAgU2VjdGlvbiA0LjIuMi4yMC4iDQogICAgICAgIFNZTlRBWCAgICBJTlRFR0VSIHsN CiAgICAgICAgICAgICAgICAgICAgICAgbm9uZSgwKSwNCiAgICAgICAgICAgICAgICAgICAgICAg ZGVzNTZDYmNNb2RlKDEpLA0KICAgICAgICAgICAgICAgICAgICAgICBkZXM0MENiY01vZGUoMiks DQogICAgICAgICAgICAgICAgICAgICAgIHQzRGVzMTI4Q2JjTW9kZSgzKSwNCiAgICAgICAgICAg ICAgICAgICAgICAgYWVzMTI4Q2JjTW9kZSg0KSwNCiAgICAgICAgICAgICAgICAgICAgICAgYWVz MjU2Q2JjTW9kZSg1KQ0KICAgICAgICAgICAgICAgICAgfQ0KDQoNCkRvY3NCcGttRGF0YUF1dGhl bnRBbGcgOjo9IFRFWFRVQUwtQ09OVkVOVElPTg0KICAgICAgICBTVEFUVVMgICAgY3VycmVudA0K ICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIlRoZSBsaXN0IG9mIGRhdGEgaW50ZWdy aXR5IGFsZ29yaXRobXMgZGVmaW5lZCBmb3IgdGhlDQogICAgICAgIERPQ1NJUyBpbnRlcmZhY2Ug aW4gdGhlIEJQS00gY3J5cHRvZ3JhcGhpYy1zdWl0ZSBwYXJhbWV0ZXIuDQogICAgICAgIFRoZSB2 YWx1ZSAnbm9uZScgaW5kaWNhdGVzIG5vIGRhdGEgaW50ZWdyaXR5IGlzIHVzZWQgZm9yIA0KICAg ICAgICB0aGUgU0FJRCBiZWluZyByZWZlcmVuY2VkLiINCiAgICAgICAgUkVGRVJFTkNFDQogICAg ICAgICAgICAgIkRPQ1NJUyBCYXNlbGluZSBQcml2YWN5IFBsdXMgSW50ZXJmYWNlIFNwZWNpZmlj YXRpb24sDQogICAgICAgIFNlY3Rpb24gNC4yLjIuMjAuIg0KICAgICAgICBTWU5UQVggICAgSU5U RUdFUiB7DQogICAgICAgICAgICAgICAgICAgICAgIG5vbmUoMCksDQogICAgICAgICAgICAgICAg ICAgICAgIGhtYWNTaGExOTYoMSkNCiAgICAgICAgICAgICAgICAgIH0NCg0KDQoNCi0tIE1JQiBP QkpFQ1RTOg0KLS0gQ00NCg0KICAgZG9jc0JwaTJDbVRFS0RhdGFFbmNyeXB0QWxnICAgT0JKRUNU LVRZUEUNCiAgICAgICAgU1lOVEFYICAgIERvY3NCcGttRGF0YUVuY3J5cHRBbGcNCiAgICAgICAg TUFYLUFDQ0VTUyAgICAgcmVhZC1vbmx5DQogICAgICAgIFNUQVRVUyAgICAgICAgIGN1cnJlbnQN CiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAiVGhlIHZhbHVlIG9mIHRoaXMgb2Jq ZWN0IGlzIHRoZSBkYXRhIGVuY3J5cHRpb24NCiAgICAgICAgYWxnb3JpdGhtIGZvciB0aGlzIFNB SUQuIg0KICAgICAgICBSRUZFUkVOQ0UNCiAgICAgICAgICAgICAiRE9DU0lTIEJhc2VsaW5lIFBy aXZhY3kgUGx1cyBJbnRlcmZhY2UgU3BlY2lmaWNhdGlvbiwNCiAgICAgICAgU2VjdGlvbiA0LjIu Mi4yMC4iDQogICAgICAgIDo6PSB7IGRvY3NCcGkyQ21URUtFbnRyeSAzIH0NCg0KICAgZG9jc0Jw aTJDbVRFS0RhdGFBdXRoZW50QWxnICAgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgIERv Y3NCcGttRGF0YUF1dGhlbnRBbGcNCiAgICAgICAgTUFYLUFDQ0VTUyAgICAgcmVhZC1vbmx5DQog ICAgICAgIFNUQVRVUyAgICAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAg ICAgICAgICAiVGhlIHZhbHVlIG9mIHRoaXMgb2JqZWN0IGlzIHRoZSBkYXRhIGF1dGhlbnRpY2F0 aW9uDQogICAgICAgIGFsZ29yaXRobSBmb3IgdGhpcyBTQUlELg0KICAgICAgICBSRUZFUkVOQ0UN CiAgICAgICAgICAgICAiRE9DU0lTIEJhc2VsaW5lIFByaXZhY3kgUGx1cyBJbnRlcmZhY2UgU3Bl Y2lmaWNhdGlvbiwNCiAgICAgICAgU2VjdGlvbiA0LjIuMi4yMC4iDQogICAgICAgIDo6PSB7IGRv Y3NCcGkyQ21URUtFbnRyeSA0IH0NCg0KDQogICBkb2NzQnBpMkNtQ3J5cHRvU3VpdGVEYXRhRW5j cnlwdEFsZyAgICAgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgIERvY3NCcGttRGF0YUVu Y3J5cHRBbGcNCiAgICAgICAgTUFYLUFDQ0VTUyAgICAgcmVhZC1vbmx5DQogICAgICAgIFNUQVRV UyAgICAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAiVGhl IHZhbHVlIG9mIHRoaXMgb2JqZWN0IGlzIHRoZSBkYXRhIGVuY3J5cHRpb24NCiAgICAgICAgYWxn b3JpdGhtIGZvciB0aGlzIGNyeXB0b2dyYXBoaWMgc3VpdGUgY2FwYWJpbGl0eS4iDQogICAgICAg IFJFRkVSRU5DRQ0KICAgICAgICAgICAgICJET0NTSVMgQmFzZWxpbmUgUHJpdmFjeSBQbHVzIElu dGVyZmFjZSBTcGVjaWZpY2F0aW9uLA0KICAgICAgICBTZWN0aW9uIDQuMi4yLjIwLiINCiAgICAg ICAgOjo9IHsgZG9jc0JwaTJDbUNyeXB0b1N1aXRlRW50cnkgMiB9DQoNCiAgIGRvY3NCcGkyQ21D cnlwdG9TdWl0ZURhdGFBdXRoZW50QWxnICAgICBPQkpFQ1QtVFlQRQ0KICAgICAgICBTWU5UQVgg ICAgRG9jc0Jwa21EYXRhQXV0aGVudEFsZw0KICAgICAgICBNQVgtQUNDRVNTICAgICByZWFkLW9u bHkNCiAgICAgICAgU1RBVFVTICAgICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0K ICAgICAgICAgICAgICJUaGUgdmFsdWUgb2YgdGhpcyBvYmplY3QgaXMgdGhlIGRhdGEgYXV0aGVu dGljYXRpb24NCiAgICAgICAgYWxnb3JpdGhtIGZvciB0aGlzIGNyeXB0b2dyYXBoaWMgc3VpdGUg Y2FwYWJpbGl0eS4iDQogICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgICJET0NTSVMgQmFz ZWxpbmUgUHJpdmFjeSBQbHVzIEludGVyZmFjZSBTcGVjaWZpY2F0aW9uLA0KICAgICAgICBTZWN0 aW9uIDQuMi4yLjIwLiINCiAgICAgICAgOjo9IHsgZG9jc0JwaTJDbUNyeXB0b1N1aXRlRW50cnkg MyB9DQoNCg0KLS0gTUlCIE9CSkVDVFM6DQotLSBDTVRTDQoNCg0KICAgZG9jc0JwaTJDbXRzVEVL RGF0YUVuY3J5cHRBbGcgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgIERvY3NCcGttRGF0 YUVuY3J5cHRBbGcNCiAgICAgICAgTUFYLUFDQ0VTUyAgICAgcmVhZC1vbmx5DQogICAgICAgIFNU QVRVUyAgICAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAi VGhlIHZhbHVlIG9mIHRoaXMgb2JqZWN0IGlzIHRoZSBkYXRhIGVuY3J5cHRpb24NCiAgICAgICAg YWxnb3JpdGhtIGZvciB0aGlzIFNBSUQuIg0KICAgICAgICBSRUZFUkVOQ0UNCiAgICAgICAgICAg ICAiRE9DU0lTIEJhc2VsaW5lIFByaXZhY3kgUGx1cyBJbnRlcmZhY2UgU3BlY2lmaWNhdGlvbiwN CiAgICAgICAgU2VjdGlvbiA0LjIuMi4yMC4iDQogICAgICAgIDo6PSB7IGRvY3NCcGkyQ210c1RF S0VudHJ5IDMgfQ0KDQogICBkb2NzQnBpMkNtdHNURUtEYXRhQXV0aGVudEFsZyBPQkpFQ1QtVFlQ RQ0KICAgICAgICBTWU5UQVggICAgRG9jc0Jwa21EYXRhQXV0aGVudEFsZw0KICAgICAgICBNQVgt QUNDRVNTICAgICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgICAgY3VycmVudA0KICAg ICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICJUaGUgdmFsdWUgb2YgdGhpcyBvYmplY3Qg aXMgdGhlIGRhdGEgYXV0aGVudGljYXRpb24NCiAgICAgICAgYWxnb3JpdGhtIGZvciB0aGlzIFNB SUQuIg0KICAgICAgICBSRUZFUkVOQ0UNCiAgICAgICAgICAgICAiRE9DU0lTIEJhc2VsaW5lIFBy aXZhY3kgUGx1cyBJbnRlcmZhY2UgU3BlY2lmaWNhdGlvbiwNCiAgICAgICAgU2VjdGlvbiA0LjIu Mi4yMC4iDQogICAgICAgIDo6PSB7IGRvY3NCcGkyQ210c1RFS0VudHJ5IDQgfQ0KDQoNCiAgIGRv Y3NCcGkyQ210c0lwTXVsdGljYXN0RGF0YUVuY3J5cHRBbGcgICBPQkpFQ1QtVFlQRQ0KICAgICAg ICBTWU5UQVggICAgRG9jc0Jwa21EYXRhRW5jcnlwdEFsZw0KICAgICAgICBNQVgtQUNDRVNTICAg ICByZWFkLWNyZWF0ZQ0KICAgICAgICBTVEFUVVMgICAgICAgICBjdXJyZW50DQogICAgICAgIERF U0NSSVBUSU9ODQogICAgICAgICAgICAgIlRoZSB2YWx1ZSBvZiB0aGlzIG9iamVjdCBpcyB0aGUg ZGF0YSBlbmNyeXB0aW9uDQogICAgICAgIGFsZ29yaXRobSBmb3IgdGhpcyBJUC4iDQogICAgICAg IFJFRkVSRU5DRQ0KICAgICAgICAgICAgICJET0NTSVMgQmFzZWxpbmUgUHJpdmFjeSBQbHVzIElu dGVyZmFjZSBTcGVjaWZpY2F0aW9uLA0KICAgICAgICBTZWN0aW9uIDQuMi4yLjIwLiINCiAgICAg ICAgREVGVkFMIHsgZGVzNTZDYmNNb2RlIH0NCiAgICAgICAgOjo9IHsgZG9jc0JwaTJDbXRzSXBN dWx0aWNhc3RNYXBFbnRyeSA3IH0NCg0KICAgZG9jc0JwaTJDbXRzSXBNdWx0aWNhc3REYXRhQXV0 aGVudEFsZyAgIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICBEb2NzQnBrbURhdGFBdXRo ZW50QWxnDQogICAgICAgIE1BWC1BQ0NFU1MgICAgIHJlYWQtY3JlYXRlDQogICAgICAgIFNUQVRV UyAgICAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAiVGhl IHZhbHVlIG9mIHRoaXMgb2JqZWN0IGlzIHRoZSBkYXRhIGF1dGhlbnRpY2F0aW9uDQogICAgICAg IGFsZ29yaXRobSBmb3IgdGhpcyBJUC4iDQogICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAg ICJET0NTSVMgQmFzZWxpbmUgUHJpdmFjeSBQbHVzIEludGVyZmFjZSBTcGVjaWZpY2F0aW9uLA0K ICAgICAgICBTZWN0aW9uIDQuMi4yLjIwLiINCiAgICAgICAgREVGVkFMIHsgbm9uZSB9DQogICAg ICAgIDo6PSB7IGRvY3NCcGkyQ210c0lwTXVsdGljYXN0TWFwRW50cnkgOCB9DQoNCg0KLS0gQ09N UExJQU5DRSBTVEFURU1FTlRTIE9CSkVDVCBvdmVycmlkZQ0KDQotLSBJbiBkb2NzQnBpMkNtQ29t cGxpYW5jZSANCg0KICAgLS0gY29uc3RyYWluIG9uIEVuY3J5cHRpb24gYWxnb3JpdGhtcw0KICAg T0JKRUNUIGRvY3NCcGkyQ21URUtEYXRhRW5jcnlwdEFsZw0KICAgICAgICBTWU5UQVggICAgRG9j c0Jwa21EYXRhRW5jcnlwdEFsZyB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm9u ZSgwKSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZXM1NkNiY01vZGUoMSksDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVzNDBDYmNNb2RlKDIpDQogICAgICAgICAg ICAgICAgICB9DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAgIkl0IGlzIGNvbXBs aWFudCB0byBzdXBwb3J0ICdkZXM1NkNiY01vZGUnIGFuZA0KICAgICAgICAnZGVzNDBDYmNNb2Rl JyBmb3IgZGF0YSBlbmNyeXB0aW9uIGFsZ29yaXRobXMuIg0KDQogICAtLSBjb25zdHJhaW4gb24g SW50ZWdyaXR5IGFsZ29yaXRobXMNCiAgIE9CSkVDVCBkb2NzQnBpMkNtVEVLRGF0YUF1dGhlbnRB bGcNCiAgICAgICAgU1lOVEFYICAgIERvY3NCcGttRGF0YUF1dGhlbnRBbGcgew0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIG5vbmUoMCkNCiAgICAgICAgICAgICAgICAgIH0NCiAgICAg ICAgU1RBVFVTICAgICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAg ICAgICJJdCBpcyBjb21wbGlhbnQgdG8gbm90IHN1cHBvcnQgZGF0YSBtZXNzYWdlIA0KICAgICAg ICBhdXRoZW50aWNhdGlvbiBhbGdvcml0aG1zLiINCg0KICAgLS0gY29uc3RyYWluIG9uIEVuY3J5 cHRpb24gYWxnb3JpdGhtcw0KICAgT0JKRUNUIGRvY3NCcGkyQ21DcnlwdG9TdWl0ZURhdGFFbmNy eXB0QWxnDQogICAgICAgIFNZTlRBWCAgICBEb2NzQnBrbURhdGFFbmNyeXB0QWxnIHsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBub25lKDApLA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGRlczU2Q2JjTW9kZSgxKSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBkZXM0MENiY01vZGUoMikNCiAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgREVTQ1JJUFRJ T04NCiAgICAgICAgICAgICAiSXQgaXMgY29tcGxpYW50IHRvIG9ubHkgc3VwcG9ydCAnZGVzNTZD YmNNb2RlJyANCiAgICAgICAgYW5kICdkZXM0MENiY01vZGUnIGZvciBkYXRhIGVuY3J5cHRpb24g YWxnb3JpdGhtcy4iDQoNCiAgIC0tIGNvbnN0cmFpbiBvbiBJbnRlZ3JpdHkgYWxnb3JpdGhtcw0K ICAgT0JKRUNUIGRvY3NCcGkyQ21DcnlwdG9TdWl0ZURhdGFBdXRoZW50QWxnDQogICAgICAgIFNZ TlRBWCAgICBEb2NzQnBrbURhdGFBdXRoZW50QWxnIHsNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBub25lKDApDQogICAgICAgICAgICAgICAgICB9DQogICAgICAgIERFU0NSSVBUSU9O DQogICAgICAgICAgICAgIkl0IGlzIGNvbXBsaWFudCB0byBub3Qgc3VwcG9ydCBkYXRhIG1lc3Nh Z2UgDQogICAgICAgIGF1dGhlbnRpY2F0aW9uIGFsZ29yaXRobXMuIg0KDQoNCmluIGRvY3NCcGky Q210c0NvbXBsaWFuY2UgDQoNCiAgIC0tIGNvbnN0cmFpbiBvbiBFbmNyeXB0aW9uIGFsZ29yaXRo bXMNCk9CSkVDVCAgIGRvY3NCcGkyQ210c1RFS0RhdGFFbmNyeXB0QWxnDQogICAgICAgIFNZTlRB WCAgICBEb2NzQnBrbURhdGFFbmNyeXB0QWxnIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBub25lKDApLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlczU2Q2JjTW9k ZSgxKSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZXM0MENiY01vZGUoMikNCiAg ICAgICAgICAgICAgICAgIH0NCiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAiSXQg aXMgY29tcGxpYW50IHRvIG9ubHkgc3VwcG9ydCAnZGVzNTZDYmNNb2RlJyANCiAgICAgICAgYW5k ICdkZXM0MENiY01vZGUnIGZvciBkYXRhIGVuY3J5cHRpb24uIg0KDQogICAtLSBjb25zdHJhaW4g b24gSW50ZWdyaXR5IGFsZ29yaXRobXMNCk9CSkVDVCBkb2NzQnBpMkNtdHNURUtEYXRhQXV0aGVu dEFsZw0KICAgICAgICBTWU5UQVggICAgRG9jc0Jwa21EYXRhQXV0aGVudEFsZyB7DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgbm9uZSgwKQ0KICAgICAgICAgICAgICAgICAgfQ0KICAg ICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICJJdCBpcyBjb21wbGlhbnQgdG8gbm90IHN1 cHBvcnQgZGF0YSBtZXNzYWdlIA0KICAgICAgICBhdXRoZW50aWNhdGlvbiBhbGdvcml0aG1zLiIN Cg0KDQogICAtLSBjb25zdHJhaW4gb24gYWNjZXNzDQogICAtLSBjb25zdHJhaW4gb24gRW5jcnlw dGlvbiBhbGdvcml0aG1zDQoNCiAgIE9CSkVDVCAgICBkb2NzQnBpMkNtdHNJcE11bHRpY2FzdERh dGFFbmNyeXB0QWxnDQogICAgICAgIFNZTlRBWCAgICBEb2NzQnBrbURhdGFFbmNyeXB0QWxnIHsN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBub25lKDApLA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGRlczU2Q2JjTW9kZSgxKSwNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBkZXM0MENiY01vZGUoMikNCiAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgTUlO LUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiV3Jp dGUgYWNjZXNzIGlzIG5vdCByZXF1aXJlZC4NCiAgICAgICAgSXQgaXMgY29tcGxpYW50IHRvIG9u bHkgc3VwcG9ydCAnZGVzNTZDYmNNb2RlJyANCiAgICAgICAgYW5kIGRlczQwQ2JjTW9kZScyJyBm b3IgZGF0YSBlbmNyeXB0aW9uIg0KDQoNCiAgIC0tIGNvbnN0cmFpbiBvbiBhY2Nlc3MNCiAgIC0t IGNvbnN0cmFpbiBvbiBJbnRlZ3JpdHkgYWxnb3JpdGhtcw0KICAgT0JKRUNUICAgIGRvY3NCcGky Q210c0lwTXVsdGljYXN0RGF0YUF1dGhlbnRBbGcNCiAgICAgICAgU1lOVEFYICAgIERvY3NCcGtt RGF0YUF1dGhlbnRBbGcgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vbmUoMCkN CiAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgTUlOLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAg ICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiV3JpdGUgYWNjZXNzIGlzIG5vdCByZXF1aXJl ZC4NCiAgICAgICAgSXQgaXMgY29tcGxpYW50IHRvIG5vdCBzdXBwb3J0IGRhdGEgbWVzc2FnZSAN CiAgICAgICAgYXV0aGVudGljYXRpb24gYWxnb3JpdGhtcy4iDQoNCg0KDQoNCg0K ------_=_NextPart_001_01C4CB50.DB5880A3 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn ------_=_NextPart_001_01C4CB50.DB5880A3-- From ipcdn-bounces@ietf.org Tue Nov 16 13:33:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27727 for ; Tue, 16 Nov 2004 13:33:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8BH-0004LH-VV for ipcdn-archive@ietf.org; Tue, 16 Nov 2004 13:35:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU853-00036f-F6; Tue, 16 Nov 2004 13:29:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU7tK-000180-My for ipcdn@megatron.ietf.org; Tue, 16 Nov 2004 13:17:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26389 for ; Tue, 16 Nov 2004 13:17:19 -0500 (EST) Received: from go4.ext.ti.com ([192.91.75.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7vT-0003xz-Pr for ipcdn@ietf.org; Tue, 16 Nov 2004 13:19:42 -0500 Received: from dlep90.itg.ti.com ([157.170.152.54]) by go4.ext.ti.com (8.12.11/8.12.11) with ESMTP id iAGIGemN010022; Tue, 16 Nov 2004 12:16:41 -0600 (CST) Received: from dlee2k71.ent.ti.com (localhost [127.0.0.1]) by dlep90.itg.ti.com (8.12.11/8.12.11) with ESMTP id iAGIGerd020701; Tue, 16 Nov 2004 12:16:40 -0600 (CST) Received: from dlee2k05.ent.ti.com ([157.170.152.114]) by dlee2k71.ent.ti.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Nov 2004 12:16:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Nov 2004 12:16:40 -0600 Message-ID: Thread-Topic: pktcRingCadence explanation changed from sig-draft-5 to sig-draft-7 Thread-Index: AcTMACMSe5aH0zfvQB+oa1T7VQlcBQAB+7gA From: "Kumar, Satish" To: "Sumanth Channabasappa" , X-OriginalArrivalTime: 16 Nov 2004 18:16:40.0605 (UTC) FILETIME=[6B5984D0:01C4CC08] X-Spam-Score: 1.6 (+) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Subject: [ipcdn] pktcRingCadence explanation changed from sig-draft-5 to sig-draft-7 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="===============2004236754==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 1.6 (+) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 This is a multi-part message in MIME format. --===============2004236754== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CC08.6B1E46CC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4CC08.6B1E46CC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, I have a question on ring cadence repeatable characteristics. The IETF draft-5 has the description for pktcRingCadnece as below: PktcRingCadence ::=3D TEXTUAL-CONVENTION=20 STATUS current=20 DESCRIPTION=20 " =20 This object represents a ring cadence and repeatable=20 Characteristics in a bit string format. The first two=20 octets of the bit string represent the length in bits of=20 the duration of the cadence (i.e., the number of bits that=20 follow the third octet). The third octet is used to=20 represent repeatable characteristics. 00000000 means=20 repeatable, and 10000000 means non repeatable. Each bit=20 after the third octet represents 50 ms and 1 represents=20 ring and 0 represents silent. The first bit of the fourth=20 octet is the first bit of the ring cadence. All bits are=20 counted in network order such that the octet with only the=20 first bit set will look like 10000000 bit sequence. A=20 total of 264 bits can be set to represent 13200 ms of=20 total cadence cycle. There will be at most 3 on/off=20 transitions per cadence period."=20 SYNTAX OCTET STRING (SIZE(4..36))=20 But the draft-7 has=20 This object provides an encoding scheme for ring =20 cadences, including repeatability characteristics. All =20 fields in this object MUST be encoded in network-byte =20 order.=20 The first three higher order octets are reserved. The =20 octets that follow are used to encode a 'bit-string', with =20 each bit corresponding to 50 milliseconds. A bit value of =20 '1' indicates the presence of a ring-tone and a bit value =20 of '0' indicates the absence of a ring-tone, for that =20 duration (50 ms) (Note: A minimum number of octets =20 required to encode the bit-string MUST be used).=20 =20 The first two of the reserved octets MUST indicate the =20 length of the encoded cadence (in bits) and MUST range =20 between 1 and 264. (Note: The length in bits MUST also be =20 consistent with the number of octets that encode the =20 cadence). The MTA MUST ignore any unused bits in the last =20 octet, but MUST reflect the value as provided on =20 subsequent SNMP GETs.=20 =20 The third of the reserved octets indicates 'repeatability' =20 and MUST be either 0x80 or 0x00 - the former value =20 indicating 'repeatability' and the latter indicating 'non-=20 repeatability'.=20 =20 The MTA MUST reject attempts to set a value that violates =20 any of the above requirements"=20 SYNTAX OCTET STRING (SIZE(4..36))=20 =20 My question here is the item marked in RED is changed from draft-5 to draft-7. Is it a typo or the intended changes?? 0x80 is changed from non-repeatable(draft-5) to repeatable(draft-7)!!!! =20 Thx, =20 Satish Kumar, Texas Instruments=20 =20 ------_=_NextPart_001_01C4CC08.6B1E46CC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi,
 I have a = question on ring=20 cadence repeatable characteristics.
The IETF = draft-5 has=20 the description for pktcRingCadnece as below:

PktcRingCadence   ::=3D = TEXTUAL-CONVENTION=20
      =20 STATUS        current=20
       DESCRIPTION=20
           "  =
           &nb= sp;=20 This object represents a ring cadence and repeatable=20
           &nb= sp;=20 Characteristics in a bit string format. The first two=20
           &nb= sp;=20 octets of the bit string represent the length in bits of=20
           &nb= sp; the=20 duration of the cadence (i.e., the number of bits that=20
           &nb= sp;=20 follow the third octet). The third octet is used = to=20
           &nb= sp;=20 represent repeatable characteristics. 00000000 means=20
           &nb= sp;=20 repeatable, and 10000000 means non repeatable. Each bit=20
           &nb= sp;=20 after the third octet represents 50 ms and 1 represents=20
           &nb= sp;=20 ring and 0 represents silent. The first bit of the fourth=20
           &nb= sp;=20 octet is the first bit of the ring cadence. All bits are=20
           &nb= sp;=20 counted in network order such that the octet with only the=20
           &nb= sp;=20 first bit set will look like 10000000 bit sequence. A=20
           &nb= sp;=20 total of 264 bits can be set to represent 13200 ms of=20
           &nb= sp;=20 total cadence cycle. There will be at most 3 on/off=20
           &nb= sp;=20 transitions per cadence period." =
      =20 SYNTAX  OCTET STRING (SIZE(4..36))

But the=20 draft-7 has

          =  =20 This object provides an encoding scheme for ring =20
            = cadences,=20 including repeatability characteristics.=20 All  
         =   =20 fields in this object MUST be encoded in network-byte =20
            = order.=20

           = ; The=20 first three higher order octets are reserved. The =20
            = octets=20 that follow are used to encode a 'bit-string', with =20
            = each bit=20 corresponding to 50 milliseconds. A bit value of =20
            = '1'=20 indicates the presence of a ring-tone and a bit value =20
            = of '0'=20 indicates the absence of a ring-tone, for that =20
            = duration=20 (50 ms) (Note: A minimum number of octets =20
            = required=20 to encode the bit-string MUST be used).
  =20
            = The first=20 two of the reserved octets MUST indicate the =20
            = length of=20 the encoded cadence (in bits) and MUST range =20
            = between 1=20 and 264. (Note: The length in bits MUST also be =20
           =20 consistent with the number of octets that encode the =20
            = cadence).=20 The MTA MUST ignore any unused bits in the last =20
            = octet,=20 but MUST reflect the value as provided on =20
           =20 subsequent SNMP GETs.
  =20
            = The third of the reserved octets indicates = 'repeatability' =20
            = and MUST=20 be either 0x80 or 0x00 - the former value =20
           =20 indicating 'repeatability' and the latter indicating 'non-=20
           =20 repeatability'.
  =20
            = The MTA=20 MUST reject attempts to set a value that violates =20
            = any of=20 the above=20 requirements" 
        &n= bsp;=20 SYNTAX  OCTET STRING (SIZE(4..36)) 
    =
My=20 question here is the item marked in RED is changed from draft-5 to = draft-7. Is=20 it a typo or the intended changes?? 0x80 is = changed from=20 non-repeatable(draft-5) to repeatable(draft-7)!!!!
 
 Thx,  
 Satish  = Kumar,
Texas=20 Instruments 

 

------_=_NextPart_001_01C4CC08.6B1E46CC-- --===============2004236754== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============2004236754==-- From ipcdn-bounces@ietf.org Wed Nov 17 15:16:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08044 for ; Wed, 17 Nov 2004 15:16:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUWGh-0002JN-49 for ipcdn-archive@ietf.org; Wed, 17 Nov 2004 15:19:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUW2s-0002De-Fw; Wed, 17 Nov 2004 15:04:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUVqU-0003Xt-3D for ipcdn@megatron.ietf.org; Wed, 17 Nov 2004 14:52:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05307 for ; Wed, 17 Nov 2004 14:52:00 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUVsw-0001ie-VC for ipcdn@ietf.org; Wed, 17 Nov 2004 14:54:35 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id iAHJpR1e010903; Wed, 17 Nov 2004 12:51:27 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Nov 2004 12:51:27 -0700 Message-ID: Thread-Topic: pktcRingCadence explanation changed from sig-draft-5 to sig-draft-7 Thread-Index: AcTMACMSe5aH0zfvQB+oa1T7VQlcBQAB+7gAADWfLcA= From: "Sumanth Channabasappa" To: "Satish Kumar at Texas Instruments" , X-Approved: ondar X-Spam-Score: 0.7 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 Subject: [ipcdn] RE: pktcRingCadence explanation changed from sig-draft-5 to sig-draft-7 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="===============1606432230==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 9178bae9f85419fdc08e9f2c86e345d0 This is a multi-part message in MIME format. --===============1606432230== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CCDE.D37D0010" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4CCDE.D37D0010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Satish, =20 This was missed during the review period. For reasons of backward compatibility this should be reverrted as : =20 "The third of the reserved octets indicates 'repeatability' and MUST be either 0x80 or 0x00 - the former value =20 indicating 'non-repeatability' and the latter indicating=20 'repeatability'. " =20 This will taken care of in the next release of this draft - good catch. =20 Thanks! Sumanth -----Original Message----- From: Satish Kumar at Texas Instruments=20 Sent: Tuesday, November 16, 2004 11:17 AM To: Sumanth Channabasappa; ipcdn@ietf.org Subject: pktcRingCadence explanation changed from sig-draft-5 to sig-draft-7 =09 =09 Hi, I have a question on ring cadence repeatable characteristics. The IETF draft-5 has the description for pktcRingCadnece as below: PktcRingCadence ::=3D TEXTUAL-CONVENTION=20 STATUS current=20 DESCRIPTION=20 " =20 This object represents a ring cadence and repeatable=20 Characteristics in a bit string format. The first two=20 octets of the bit string represent the length in bits of=20 the duration of the cadence (i.e., the number of bits that=20 follow the third octet). The third octet is used to represent repeatable characteristics. 00000000 means=20 repeatable, and 10000000 means non repeatable. Each bit=20 after the third octet represents 50 ms and 1 represents=20 ring and 0 represents silent. The first bit of the fourth=20 octet is the first bit of the ring cadence. All bits are=20 counted in network order such that the octet with only the=20 first bit set will look like 10000000 bit sequence. A=20 total of 264 bits can be set to represent 13200 ms of=20 total cadence cycle. There will be at most 3 on/off transitions per cadence period."=20 SYNTAX OCTET STRING (SIZE(4..36))=20 =09 But the draft-7 has=20 =09 This object provides an encoding scheme for ring =20 cadences, including repeatability characteristics. All =20 fields in this object MUST be encoded in network-byte =20 order.=20 =09 The first three higher order octets are reserved. The =20 octets that follow are used to encode a 'bit-string', with =20 each bit corresponding to 50 milliseconds. A bit value of =20 '1' indicates the presence of a ring-tone and a bit value =20 of '0' indicates the absence of a ring-tone, for that =20 duration (50 ms) (Note: A minimum number of octets =20 required to encode the bit-string MUST be used).=20 =20 The first two of the reserved octets MUST indicate the =20 length of the encoded cadence (in bits) and MUST range =20 between 1 and 264. (Note: The length in bits MUST also be =20 consistent with the number of octets that encode the cadence). The MTA MUST ignore any unused bits in the last =20 octet, but MUST reflect the value as provided on =20 subsequent SNMP GETs.=20 =20 The third of the reserved octets indicates 'repeatability' =20 and MUST be either 0x80 or 0x00 - the former value =20 indicating 'repeatability' and the latter indicating 'non-=20 repeatability'.=20 =20 The MTA MUST reject attempts to set a value that violates =20 any of the above requirements"=20 SYNTAX OCTET STRING (SIZE(4..36))=20 =20 My question here is the item marked in RED is changed from draft-5 to draft-7. Is it a typo or the intended changes?? 0x80 is changed from non-repeatable(draft-5) to repeatable(draft-7)!!!! =20 Thx, =20 Satish Kumar, Texas Instruments=20 =20 ------_=_NextPart_001_01C4CCDE.D37D0010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Satish,
 
This=20 was missed during the review period. For reasons of backward = compatibility=20 this
should=20 be reverrted as :
 
         &nb= sp; =20 "The third of the = reserved=20 octets indicates 'repeatability' =20
            = and MUST=20 be either 0x80 or 0x00 - the former value =20
           =20 indicating 'non-repeatability' and the latter indicating=20
         &nb= sp; =20 'repeatability'.=20 "
 
This will taken = care of in=20 the next release of this draft - good catch.
 
Thanks!
Sumanth
-----Original Message-----
From: = Satish Kumar at=20 Texas Instruments
Sent: Tuesday, November 16, 2004 11:17=20 AM
To: Sumanth Channabasappa; = ipcdn@ietf.org
Subject:=20 pktcRingCadence explanation changed from sig-draft-5 to=20 sig-draft-7

Hi,
 I have a = question on ring=20 cadence repeatable characteristics.
The IETF = draft-5=20 has the description for pktcRingCadnece as below:

PktcRingCadence   ::=3D=20 TEXTUAL-CONVENTION
      =20 STATUS        current=20
       DESCRIPTION=20
           = " =20 =
           &nb= sp;=20 This object represents a ring cadence and repeatable=20 =
           &nb= sp;=20 Characteristics in a bit string format. The first two=20 =
           &nb= sp;=20 octets of the bit string represent the length in bits of=20 =
           &nb= sp;=20 the duration of the cadence (i.e., the number of bits that=20 =
           &nb= sp;=20 follow the third octet). The third octet is used = to=20 =
           &nb= sp;=20 represent repeatable characteristics. 00000000 means=20 =
           &nb= sp;=20 repeatable, and 10000000 means non repeatable. Each bit=20 =
           &nb= sp;=20 after the third octet represents 50 ms and 1 represents=20 =
           &nb= sp;=20 ring and 0 represents silent. The first bit of the fourth=20 =
           &nb= sp;=20 octet is the first bit of the ring cadence. All bits are=20 =
           &nb= sp;=20 counted in network order such that the octet with only the=20 =
           &nb= sp;=20 first bit set will look like 10000000 bit sequence. A=20 =
           &nb= sp;=20 total of 264 bits can be set to represent 13200 ms of=20 =
           &nb= sp;=20 total cadence cycle. There will be at most 3 on/off=20 =
           &nb= sp;=20 transitions per cadence period." =
      =20 SYNTAX  OCTET STRING (SIZE(4..36))

But=20 the draft-7 has

          =  =20 This object provides an encoding scheme for ring =20
            = cadences, including repeatability characteristics.=20 = All  
         =   =20 fields in this object MUST be encoded in network-byte =20
            = order.=20 =

           = ; The=20 first three higher order octets are reserved. The =20
            = octets=20 that follow are used to encode a 'bit-string', with =20
            = each=20 bit corresponding to 50 milliseconds. A bit value of =20
            = '1'=20 indicates the presence of a ring-tone and a bit value =20
            = of '0'=20 indicates the absence of a ring-tone, for that =20
            = duration (50 ms) (Note: A minimum number of octets =20
            = required to encode the bit-string MUST be used).
  =20
            = The=20 first two of the reserved octets MUST indicate the =20
            = length=20 of the encoded cadence (in bits) and MUST range =20
            = between=20 1 and 264. (Note: The length in bits MUST also be =20
            = consistent with the number of octets that encode the =20
            = cadence). The MTA MUST ignore any unused bits in the last =20
            = octet,=20 but MUST reflect the value as provided on =20
            = subsequent SNMP GETs.
  =20
            = The third of the reserved octets indicates = 'repeatability' =20
            = and=20 MUST be either 0x80 or 0x00 - the former value =20
            = indicating 'repeatability' and the latter indicating 'non-=20
            = repeatability'.
  =20
            = The MTA=20 MUST reject attempts to set a value that violates =20
            = any of=20 the above=20 = requirements" 
        &n= bsp;=20 SYNTAX  OCTET STRING (SIZE(4..36)) 
    =
My=20 question here is the item marked in RED is changed from draft-5 to = draft-7. Is=20 it a typo or the intended changes?? 0x80 is = changed from=20 non-repeatable(draft-5) to repeatable(draft-7)!!!!
 
 Thx,  
 Satish  = Kumar,
Texas=20 Instruments 

 

------_=_NextPart_001_01C4CCDE.D37D0010-- --===============1606432230== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1606432230==-- From ipcdn-bounces@ietf.org Wed Nov 17 17:42:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27536 for ; Wed, 17 Nov 2004 17:42:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUYXt-00084E-BK for ipcdn-archive@ietf.org; Wed, 17 Nov 2004 17:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUYHM-0000JE-FQ; Wed, 17 Nov 2004 17:27:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUY2S-00048t-SI for ipcdn@megatron.ietf.org; Wed, 17 Nov 2004 17:12:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24762 for ; Wed, 17 Nov 2004 17:12:30 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUY4x-0007HC-D0 for ipcdn@ietf.org; Wed, 17 Nov 2004 17:15:07 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAHME33B016114 for ; Wed, 17 Nov 2004 15:14:03 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id iAHMCTvH010339 for ; Wed, 17 Nov 2004 16:12:29 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Nov 2004 13:56:58 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" , "'sumanth@cablelabs.com'" , "'satish.kumar@ti.com'" Subject: re: [ipcdn] pktcRingCadence explanation changed from sig-draft-5 to sig-draft-7 Date: Wed, 17 Nov 2004 13:56:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.6 (++) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af 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="===============0985278335==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0985278335== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CCF0.5C1AF768" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4CCF0.5C1AF768 Content-Type: text/plain Draft 5, 6 and an early version of 7 stated: "00000000 means repeatable, and 10000000 means non repeatable. The value of the repeatable field MUST be 0x00 or 0x80." I think the original intent and wording should be retained and the description updated to: The third of the reserved octets indicates 'repeatability' and MUST be either 0x80 or 0x00 - the former value indicating 'non-repeatability' and the latter indicating ' repeatability'. Gordon > Hi, I have a question on ring cadence repeatable characteristics. The IETF draft-5 has the description for pktcRingCadnece as below: PktcRingCadence ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " This object represents a ring cadence and repeatable Characteristics in a bit string format. The first two octets of the bit string represent the length in bits of the duration of the cadence (i.e., the number of bits that follow the third octet). The third octet is used to represent repeatable characteristics. 00000000 means repeatable, and 10000000 means non repeatable. Each bit after the third octet represents 50 ms and 1 represents ring and 0 represents silent. The first bit of the fourth octet is the first bit of the ring cadence. All bits are counted in network order such that the octet with only the first bit set will look like 10000000 bit sequence. A total of 264 bits can be set to represent 13200 ms of total cadence cycle. There will be at most 3 on/off transitions per cadence period." SYNTAX OCTET STRING (SIZE(4..36)) But the draft-7 has This object provides an encoding scheme for ring cadences, including repeatability characteristics. All fields in this object MUST be encoded in network-byte order. The first three higher order octets are reserved. The octets that follow are used to encode a 'bit-string', with each bit corresponding to 50 milliseconds. A bit value of '1' indicates the presence of a ring-tone and a bit value of '0' indicates the absence of a ring-tone, for that duration (50 ms) (Note: A minimum number of octets required to encode the bit-string MUST be used). The first two of the reserved octets MUST indicate the length of the encoded cadence (in bits) and MUST range between 1 and 264. (Note: The length in bits MUST also be consistent with the number of octets that encode the cadence). The MTA MUST ignore any unused bits in the last octet, but MUST reflect the value as provided on subsequent SNMP GETs. The third of the reserved octets indicates 'repeatability' and MUST be either 0x80 or 0x00 - the former value indicating 'repeatability' and the latter indicating 'non- repeatability'. The MTA MUST reject attempts to set a value that violates any of the above requirements" SYNTAX OCTET STRING (SIZE(4..36)) My question here is the item marked in RED is changed from draft-5 to draft-7. Is it a typo or the intended changes?? 0x80 is changed from non-repeatable(draft-5) to repeatable(draft-7)!!!! Thx, Satish Kumar, Texas Instruments ------_=_NextPart_001_01C4CCF0.5C1AF768 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzYiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj4NCjxESVY+PFNQQU4gY2xhc3M9MTQwMzUyNjE3LTE2MTEy MDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj5EcmFmdCZuYnNwOzxT UEFOIGNsYXNzPTc5NzA4NTEyMS0xNzExMjAwND41LCA8L1NQQU4+NjxTUEFOIA0KY2xhc3M9Nzk3 MDg1MTIxLTE3MTEyMDA0PiA8L1NQQU4+YW5kJm5ic3A7PFNQQU4gY2xhc3M9Nzk3MDg1MTIxLTE3 MTEyMDA0PmFuIA0KPC9TUEFOPmVhcmx5IHZlcnNpb24gb2YgNyBzdGF0ZWQ6PC9GT05UPjwvU1BB Tj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MTQwMzUyNjE3LTE2MTEyMDA0PjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0K PERJVj48U1BBTiBjbGFzcz0xNDAzNTI2MTctMTYxMTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jMDAwMGZmIA0Kc2l6ZT0yPiIwMDAwMDAwMCBtZWFucyZuYnNwO3JlcGVhdGFibGUsIGFuZCAx MDAwMDAwMCBtZWFucyBub24gcmVwZWF0YWJsZS4gVGhlIA0KdmFsdWUgb2YgPEJSPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCnRoZSByZXBlYXRhYmxlIGZpZWxkIE1VU1QgYmUgMHgwMCBvciAweDgwLiI8L0ZPTlQ+PC9T UEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0xNDAzNTI2MTctMTYxMTIwMDQ+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+ DQo8RElWPjxTUEFOIGNsYXNzPTE0MDM1MjYxNy0xNjExMjAwND48Rk9OVCBmYWNlPUFyaWFsPjxG T05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgDQpzaXplPTI+PFNQQU4gY2xhc3M9Nzk3MDg1MTIxLTE3 MTEyMDA0PkkgdGhpbmsgPC9TUEFOPnRoZSZuYnNwOzxTUEFOIA0KY2xhc3M9Nzk3MDg1MTIxLTE3 MTEyMDA0Pm9yaWdpbmFsJm5ic3A7aW50ZW50IGFuZCA8L1NQQU4+PFNQQU4gDQpjbGFzcz03OTcw ODUxMjEtMTcxMTIwMDQ+d29yZGluZyA8L1NQQU4+PFNQQU4gY2xhc3M9Nzk3MDg1MTIxLTE3MTEy MDA0PnNob3VsZCBiZSANCnJldGFpbmVkIGFuZCB0aGUgZGVzY3JpcHRpb24gdXBkYXRlZCANCnRv OjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNs YXNzPTE0MDM1MjYxNy0xNjExMjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpz aXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MTQwMzUy NjE3LTE2MTEyMDA0PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxGT05UIA0KY29sb3I9 I2ZmMDAwMD5UaGUgdGhpcmQgb2YgdGhlIHJlc2VydmVkIG9jdGV0cyBpbmRpY2F0ZXMgJ3JlcGVh dGFiaWxpdHknJm5ic3A7IA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgTVVTVCANCmJlIGVpdGhlciAweDgw IG9yIDB4MDAgLSB0aGUgZm9ybWVyIHZhbHVlJm5ic3A7IA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmluZGlj YXRpbmcgJ25vbi1yZXBlYXRhYmlsaXR5JyBhbmQgdGhlIGxhdHRlciBpbmRpY2F0aW5nIA0KJzxC Uj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQpyZXBlYXRhYmlsaXR5JzwvRk9OVD4uIDxCUj48L0ZPTlQ+PC9GT05UPjwv U1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MTQwMzUyNjE3LTE2MTEyMDA0PjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj5Hb3Jkb248L0ZPTlQ+PC9ESVY+PC9TUEFO Pg0KPERJVj48U1BBTiBjbGFzcz0xNDAzNTI2MTctMTYxMTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxT UEFOIGNsYXNzPTE0MDM1MjYxNy0xNjExMjAwND48U1BBTiBjbGFzcz03OTcwODUxMjEtMTcxMTIw MDQ+PEZPTlQgDQpmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPiZndDs8Rk9OVCBzaXpl PTI+DQo8UD5IaSw8L1A+DQo8UD5JIGhhdmUgYSBxdWVzdGlvbiBvbiByaW5nIGNhZGVuY2UgcmVw ZWF0YWJsZSBjaGFyYWN0ZXJpc3RpY3MuIFRoZSBJRVRGIA0KZHJhZnQtNSBoYXMgdGhlIGRlc2Ny aXB0aW9uIGZvciBwa3RjUmluZ0NhZG5lY2UgYXMgYmVsb3c6PC9QPg0KPFA+UGt0Y1JpbmdDYWRl bmNlIDo6PSBURVhUVUFMLUNPTlZFTlRJT04gPC9QPg0KPFA+U1RBVFVTIGN1cnJlbnQgPC9QPg0K PFA+REVTQ1JJUFRJT04gPC9QPg0KPFA+IiA8L1A+DQo8UD5UaGlzIG9iamVjdCByZXByZXNlbnRz IGEgcmluZyBjYWRlbmNlIGFuZCByZXBlYXRhYmxlIDwvUD4NCjxQPkNoYXJhY3RlcmlzdGljcyBp biBhIGJpdCBzdHJpbmcgZm9ybWF0LiBUaGUgZmlyc3QgdHdvIDwvUD4NCjxQPm9jdGV0cyBvZiB0 aGUgYml0IHN0cmluZyByZXByZXNlbnQgdGhlIGxlbmd0aCBpbiBiaXRzIG9mIDwvUD4NCjxQPnRo ZSBkdXJhdGlvbiBvZiB0aGUgY2FkZW5jZSAoaS5lLiwgdGhlIG51bWJlciBvZiBiaXRzIHRoYXQg PC9QPg0KPFA+Zm9sbG93IHRoZSB0aGlyZCBvY3RldCkuIFRoZSB0aGlyZCBvY3RldCBpcyB1c2Vk IHRvIDwvUD4NCjxQPnJlcHJlc2VudCByZXBlYXRhYmxlIGNoYXJhY3RlcmlzdGljcy4gMDAwMDAw MDAgbWVhbnMgPC9QPg0KPFA+cmVwZWF0YWJsZSwgYW5kIDEwMDAwMDAwIG1lYW5zIG5vbiByZXBl YXRhYmxlLiBFYWNoIGJpdCA8L1A+DQo8UD5hZnRlciB0aGUgdGhpcmQgb2N0ZXQgcmVwcmVzZW50 cyA1MCBtcyBhbmQgMSByZXByZXNlbnRzIDwvUD4NCjxQPnJpbmcgYW5kIDAgcmVwcmVzZW50cyBz aWxlbnQuIFRoZSBmaXJzdCBiaXQgb2YgdGhlIGZvdXJ0aCA8L1A+DQo8UD5vY3RldCBpcyB0aGUg Zmlyc3QgYml0IG9mIHRoZSByaW5nIGNhZGVuY2UuIEFsbCBiaXRzIGFyZSA8L1A+DQo8UD5jb3Vu dGVkIGluIG5ldHdvcmsgb3JkZXIgc3VjaCB0aGF0IHRoZSBvY3RldCB3aXRoIG9ubHkgdGhlIDwv UD4NCjxQPmZpcnN0IGJpdCBzZXQgd2lsbCBsb29rIGxpa2UgMTAwMDAwMDAgYml0IHNlcXVlbmNl LiBBIDwvUD4NCjxQPnRvdGFsIG9mIDI2NCBiaXRzIGNhbiBiZSBzZXQgdG8gcmVwcmVzZW50IDEz MjAwIG1zIG9mIDwvUD4NCjxQPnRvdGFsIGNhZGVuY2UgY3ljbGUuIFRoZXJlIHdpbGwgYmUgYXQg bW9zdCAzIG9uL29mZiA8L1A+DQo8UD50cmFuc2l0aW9ucyBwZXIgY2FkZW5jZSBwZXJpb2QuIiA8 L1A+DQo8UD5TWU5UQVggT0NURVQgU1RSSU5HIChTSVpFKDQuLjM2KSkgPC9QPg0KPFA+QnV0IHRo ZSBkcmFmdC03IGhhcyA8L1A+DQo8UD4mbmJzcDs8L1A+DQo8UD5UaGlzIG9iamVjdCBwcm92aWRl cyBhbiBlbmNvZGluZyBzY2hlbWUgZm9yIHJpbmcgPC9QPg0KPFA+Y2FkZW5jZXMsIGluY2x1ZGlu ZyByZXBlYXRhYmlsaXR5IGNoYXJhY3RlcmlzdGljcy4gQWxsIDwvUD4NCjxQPmZpZWxkcyBpbiB0 aGlzIG9iamVjdCBNVVNUIGJlIGVuY29kZWQgaW4gbmV0d29yay1ieXRlIDwvUD4NCjxQPm9yZGVy LiA8L1A+DQo8UD5UaGUgZmlyc3QgdGhyZWUgaGlnaGVyIG9yZGVyIG9jdGV0cyBhcmUgcmVzZXJ2 ZWQuIFRoZSA8L1A+DQo8UD5vY3RldHMgdGhhdCBmb2xsb3cgYXJlIHVzZWQgdG8gZW5jb2RlIGEg J2JpdC1zdHJpbmcnLCB3aXRoIDwvUD4NCjxQPmVhY2ggYml0IGNvcnJlc3BvbmRpbmcgdG8gNTAg bWlsbGlzZWNvbmRzLiBBIGJpdCB2YWx1ZSBvZiA8L1A+DQo8UD4nMScgaW5kaWNhdGVzIHRoZSBw cmVzZW5jZSBvZiBhIHJpbmctdG9uZSBhbmQgYSBiaXQgdmFsdWUgPC9QPg0KPFA+b2YgJzAnIGlu ZGljYXRlcyB0aGUgYWJzZW5jZSBvZiBhIHJpbmctdG9uZSwgZm9yIHRoYXQgPC9QPg0KPFA+ZHVy YXRpb24gKDUwIG1zKSAoTm90ZTogQSBtaW5pbXVtIG51bWJlciBvZiBvY3RldHMgPC9QPg0KPFA+ cmVxdWlyZWQgdG8gZW5jb2RlIHRoZSBiaXQtc3RyaW5nIE1VU1QgYmUgdXNlZCkuIDwvUD4NCjxQ PjwvUD4NCjxQPlRoZSBmaXJzdCB0d28gb2YgdGhlIHJlc2VydmVkIG9jdGV0cyBNVVNUIGluZGlj YXRlIHRoZSA8L1A+DQo8UD5sZW5ndGggb2YgdGhlIGVuY29kZWQgY2FkZW5jZSAoaW4gYml0cykg YW5kIE1VU1QgcmFuZ2UgPC9QPg0KPFA+YmV0d2VlbiAxIGFuZCAyNjQuIChOb3RlOiBUaGUgbGVu Z3RoIGluIGJpdHMgTVVTVCBhbHNvIGJlIDwvUD4NCjxQPmNvbnNpc3RlbnQgd2l0aCB0aGUgbnVt YmVyIG9mIG9jdGV0cyB0aGF0IGVuY29kZSB0aGUgPC9QPg0KPFA+Y2FkZW5jZSkuIFRoZSBNVEEg TVVTVCBpZ25vcmUgYW55IHVudXNlZCBiaXRzIGluIHRoZSBsYXN0IDwvUD4NCjxQPm9jdGV0LCBi dXQgTVVTVCByZWZsZWN0IHRoZSB2YWx1ZSBhcyBwcm92aWRlZCBvbiA8L1A+DQo8UD5zdWJzZXF1 ZW50IFNOTVAgR0VUcy4gPC9QPg0KPFA+PC9QPg0KPFA+VGhlIHRoaXJkIG9mIHRoZSByZXNlcnZl ZCBvY3RldHMgaW5kaWNhdGVzICdyZXBlYXRhYmlsaXR5JyA8L1A+DQo8UD5hbmQgTVVTVCBiZSBl aXRoZXIgMHg4MCBvciAweDAwIC0gdGhlIGZvcm1lciB2YWx1ZSA8L1A+DQo8UD5pbmRpY2F0aW5n ICdyZXBlYXRhYmlsaXR5JyBhbmQgdGhlIGxhdHRlciBpbmRpY2F0aW5nICdub24tIDwvUD4NCjxQ PnJlcGVhdGFiaWxpdHknLiA8L1A+DQo8UD48L1A+DQo8UD5UaGUgTVRBIE1VU1QgcmVqZWN0IGF0 dGVtcHRzIHRvIHNldCBhIHZhbHVlIHRoYXQgdmlvbGF0ZXMgPC9QPg0KPFA+YW55IG9mIHRoZSBh Ym92ZSByZXF1aXJlbWVudHMiIDwvUD4NCjxQPlNZTlRBWCBPQ1RFVCBTVFJJTkcgKFNJWkUoNC4u MzYpKSA8L1A+DQo8UD48L1A+DQo8UD5NeSBxdWVzdGlvbiBoZXJlIGlzIHRoZSBpdGVtIG1hcmtl ZCBpbiBSRUQgaXMgY2hhbmdlZCBmcm9tIGRyYWZ0LTUgdG8gDQpkcmFmdC03LiBJcyBpdCBhIHR5 cG8gb3IgdGhlIGludGVuZGVkIGNoYW5nZXM/PyAweDgwIGlzIGNoYW5nZWQgZnJvbTwvUD4NCjxQ Pm5vbi1yZXBlYXRhYmxlKGRyYWZ0LTUpIHRvIHJlcGVhdGFibGUoZHJhZnQtNykhISEhPC9QPg0K PFA+PC9QPg0KPFA+VGh4LCA8L1A+DQo8UD5TYXRpc2ggS3VtYXIsPC9QPg0KPFA+VGV4YXMgSW5z dHJ1bWVudHMgPC9QPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L0RJVj48L0RJVj48L0JP RFk+PC9IVE1MPg0K ------_=_NextPart_001_01C4CCF0.5C1AF768-- --===============0985278335== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0985278335==-- From ipcdn-bounces@ietf.org Fri Nov 19 21:49:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21495 for ; Fri, 19 Nov 2004 21:49:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVLMS-0000nf-Cy for ipcdn-archive@ietf.org; Fri, 19 Nov 2004 21:52:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVLHZ-0004SW-Sb; Fri, 19 Nov 2004 21:47:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVLDU-0003Jk-8R for ipcdn@megatron.ietf.org; Fri, 19 Nov 2004 21:43:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21003 for ; Fri, 19 Nov 2004 21:43:09 -0500 (EST) Received: from mms1.broadcom.com ([63.70.210.58] helo=mms2.broadcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVLGQ-0000gA-0y for ipcdn@ietf.org; Fri, 19 Nov 2004 21:46:14 -0500 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Fri, 19 Nov 2004 18:40:06 -0800 X-Server-Uuid: 011F2A72-58F1-4BCE-832F-B0D661E896E8 Received: from nt-sjca-0740.brcm.ad.broadcom.com ( nt-sjca-0740.sj.broadcom.com [10.16.192.49]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA27495; Fri, 19 Nov 2004 18:40:14 -0800 (PST) Received: from nt-sjca-0741.brcm.ad.broadcom.com ([10.16.192.42]) by nt-sjca-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Nov 2004 18:40:05 -0800 Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-sjca-0741.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Nov 2004 18:40:04 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 19 Nov 2004 18:40:03 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E76801@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: Clarification for pktcMtaDevProvConfigHash in draft-05 Thread-Index: AcTM9s7XeIJZIQe8RIaS4ZxYnyc8KgBsLFhA From: "Eugene Nechamkin" To: ipcdn@ietf.org X-OriginalArrivalTime: 20 Nov 2004 02:40:04.0892 (UTC) FILETIME=[3DBF35C0:01C4CEAA] X-WSS-ID: 6D80710F1SO696269-01-01 X-Spam-Score: 0.7 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: satish.kumar@ti.com Subject: [ipcdn] Clarification for pktcMtaDevProvConfigHash in draft-05 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="===============0928975706==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f This is a multi-part message in MIME format. --===============0928975706== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CEAA.3CD2C21C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4CEAA.3CD2C21C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =20 The curent definition of the "pktcMtaDevProvConfigHash" MIB Object in the draft-05 is as follows: =20 pktcMtaDevProvConfigHash OBJECT-TYPE=20 SYNTAX OCTET STRING (SIZE(20))=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION=20 " This object contains the hash value of the contents of the=20 configuration file.=20 If the authentication algorithm is MD5, the length is 128=20 bits. If the authentication algorithm is SHA-1, the length=20 is 160 bits. The hash calculation MUST follow the=20 requirements defined in the PacketCable Security=20 Specification.=20 When the MTA SNMP Enrollment mechanism is used, this=20 hash value is calculated and sent to the MTA prior=20 to sending the config file. This object value is then=20 provided by the Provisioning server via an SNMP=20 SET operation.=20 When the MTA SNMP Enrollment mechanism is not in use, the=20 hash value is provided in the configuration file itself=20 and it is also calculated by the MTA. This object value=20 MUST represent the hash value calculated by the MTA.=20 When the MTA SNMP Enrollment mechanism is not in use, the=20 MTA must reject all SNMP SET operations on this object and=20 return an 'inconsistentValue' error."=20 REFERENCE=20 " PacketCable MTA Device Provisioning Specification;=20 PacketCable Security Specification."=20 ::=3D { pktcMtaDevServer 9 }=20 The description clause states that the authentication algorithm can be either SHA-1 or MD5, which is not compliant with the corresponding PacketCable security requirement. The PacketCable security requires the usage of the SHA-1 and does not allow MD-5. The following modifiation of the DESCRIPTION clause is proposed: =20 " This object contains the hash value of the contents of the=20 configuration file.=20 The authentication algorithm is SHA-1, the length=20 is 160 bits. The hash calculation MUST follow the=20 requirements defined in the PacketCable Security=20 Specification.=20 When the MTA SNMP Enrollment mechanism is used, this=20 hash value is calculated and sent to the MTA prior=20 to sending the config file. This object value is then=20 provided by the Provisioning server via an SNMP=20 SET operation.=20 When the MTA SNMP Enrollment mechanism is not in use, the=20 hash value is provided in the configuration file itself=20 and it is also calculated by the MTA. This object value=20 MUST represent the hash value calculated by the MTA.=20 When the MTA SNMP Enrollment mechanism is not in use, the=20 MTA must reject all SNMP SET operations on this object and=20 return an 'inconsistentValue' error."=20 =20 Eugene Nechamkin, =20 Broadcom Corp. tel: (604) 233-8500 =20 ------_=_NextPart_001_01C4CEAA.3CD2C21C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message
 
The curent definition of the = "pktcMtaDevProvConfigHash"=20 MIB Object in the draft-05 is as follows:
 
   pktcMtaDevProvConfigHash  = OBJECT-TYPE=20
       = SYNTAX     =20 OCTET STRING (SIZE(20))
      =20 MAX-ACCESS  read-write
      =20 STATUS      current=20
       DESCRIPTION=20
           " This = object=20 contains the hash value of the contents of the=20
           &nb= sp;=20 configuration file.=20
           &nb= sp;=20 If the authentication algorithm is MD5, the length = is 128=20
           &nb= sp;=20 bits. If the authentication algorithm is SHA-1, the length=20
           &nb= sp; is=20 160 bits. The hash calculation MUST follow the=20
           &nb= sp;=20 requirements defined in the PacketCable Security=20
           &nb= sp;=20 Specification.=20
           &nb= sp;=20 When the MTA SNMP Enrollment mechanism is used, this=20
           &nb= sp;=20 hash value is calculated and sent to the MTA prior=20
           &nb= sp; to=20 sending the config file. This object value is then=20
           &nb= sp;=20 provided by the Provisioning server via an SNMP=20
           &nb= sp; SET=20 operation.=20
           &nb= sp;=20 When the MTA SNMP Enrollment mechanism is not in use, the=20
           &nb= sp;=20 hash value is provided in the configuration file itself=20
           &nb= sp; and=20 it is also calculated by the MTA. This object value=20
           &nb= sp;=20 MUST represent the hash value calculated by the MTA.=20
           &nb= sp;=20 When the MTA SNMP Enrollment mechanism is not in use, the=20
           &nb= sp; MTA=20 must reject all SNMP SET operations on this object and=20
           &nb= sp;=20 return an 'inconsistentValue' error." =
      =20 REFERENCE =
           "=20 PacketCable MTA Device Provisioning Specification;=20
           &nb= sp;=20 PacketCable Security Specification." =
      =20 ::=3D { pktcMtaDevServer 9 }
The description clause states that the = authentication=20 algorithm can be either SHA-1 or MD5, which is not compliant with the=20 corresponding PacketCable security requirement. The PacketCable security = requires the usage of the SHA-1 and does not allow MD-5.  The = following=20 modifiation of the DESCRIPTION clause is proposed:
 
           " = This=20 object contains the hash value of the contents of the=20
           &nb= sp;=20 configuration=20 file. 
         &nbs= p;   The authentication algorithm is SHA-1, = the=20 length=20
           &nb= sp; is=20 160 bits. The hash calculation MUST follow the=20
           &nb= sp;=20 requirements defined in the PacketCable Security=20
           &nb= sp;=20 Specification.=20
           &nb= sp;=20 When the MTA SNMP Enrollment mechanism is used, this=20
           &nb= sp;=20 hash value is calculated and sent to the MTA prior=20
           &nb= sp; to=20 sending the config file. This object value is then=20
           &nb= sp;=20 provided by the Provisioning server via an SNMP=20
           &nb= sp; SET=20 operation.=20
           &nb= sp;=20 When the MTA SNMP Enrollment mechanism is not in use, the=20
           &nb= sp;=20 hash value is provided in the configuration file itself=20
           &nb= sp; and=20 it is also calculated by the MTA. This object value=20
           &nb= sp;=20 MUST represent the hash value calculated by the MTA.=20
           &nb= sp;=20 When the MTA SNMP Enrollment mechanism is not in use, the=20
           &nb= sp; MTA=20 must reject all SNMP SET operations on this object and=20
           &nb= sp;=20 return an 'inconsistentValue' error."
 
Eugene = Nechamkin,
 
Broadcom=20 Corp.
tel: (604)=20 233-8500

 
------_=_NextPart_001_01C4CEAA.3CD2C21C-- --===============0928975706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0928975706==-- From ipcdn-bounces@ietf.org Fri Nov 19 22:15:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23423 for ; Fri, 19 Nov 2004 22:15:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVLlV-0001K3-Vd for ipcdn-archive@ietf.org; Fri, 19 Nov 2004 22:18:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVLht-0002IZ-A4; Fri, 19 Nov 2004 22:14:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVLgG-0001rU-NX for ipcdn@megatron.ietf.org; Fri, 19 Nov 2004 22:12:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23059 for ; Fri, 19 Nov 2004 22:12:53 -0500 (EST) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVLjD-0001GF-7W for ipcdn@ietf.org; Fri, 19 Nov 2004 22:15:59 -0500 Received: from h-66-167-206-142.snvacaid.dynamic.covad.net ([66.167.206.142] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CVLgD-0004ng-00 for ipcdn@ietf.org; Fri, 19 Nov 2004 19:12:54 -0800 Message-ID: <004701c4ceaf$183bfe00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <24CDBA67F085904999751B3C4F9E8C0B01E76801@NT-RMNA-0740.brcm.ad.broadcom.com> Subject: Re: [ipcdn] Clarification for pktcMtaDevProvConfigHash in draft-05 Date: Fri, 19 Nov 2004 19:14:48 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi - > From: "Eugene Nechamkin" > To: > Cc: > Sent: Friday, November 19, 2004 6:40 PM > Subject: [ipcdn] Clarification for pktcMtaDevProvConfigHash in draft-05 > > > The curent definition of the "pktcMtaDevProvConfigHash" MIB Object in > the draft-05 is as follows: > > pktcMtaDevProvConfigHash OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(20)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > " This object contains the hash value of the contents of the > configuration file. > If the authentication algorithm is MD5, the length is 128 > bits. If the authentication algorithm is SHA-1, the length > is 160 bits. The hash calculation MUST follow the ... If Eugene's proposed change isn't adopted, it seems like a correction to the SYNTAX will be necessary, making it OCTET STRING (SIZE(16 | 20)) in order to support the behaviour required by the DESCRIPTION. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Nov 22 16:09:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17241 for ; Mon, 22 Nov 2004 16:09:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWLUN-0004LS-11 for ipcdn-archive@ietf.org; Mon, 22 Nov 2004 16:12:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWL2z-0004pp-BW; Mon, 22 Nov 2004 15:44:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWKx6-0001eJ-9A; Mon, 22 Nov 2004 15:38:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13017; Mon, 22 Nov 2004 15:38:22 -0500 (EST) Message-Id: <200411222038.PAA13017@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 22 Nov 2004 15:38:22 -0500 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-15.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 X-Spam-Score: 0.4 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus Author(s) : S. Green, et al. Filename : draft-ietf-ipcdn-bpiplus-mib-15.txt Pages : 88 Date : 2004-11-22 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP based management of the Baseline Privacy Plus features of DOCSIS 1.1 and DOCSIS 2.0 (Data-over-Cable Service Interface Specification) compliant Cable Modems and Cable Modem Termination Systems. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be Addressed to the working group's mailing list at ipcdn@ietf.org and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-bpiplus-mib-15.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-bpiplus-mib-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-bpiplus-mib-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-22160408.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-bpiplus-mib-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-bpiplus-mib-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-22160408.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart-- From ipcdn-bounces@ietf.org Mon Nov 22 16:09:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17261 for ; Mon, 22 Nov 2004 16:09:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWLUN-0004Lh-Qf for ipcdn-archive@ietf.org; Mon, 22 Nov 2004 16:12:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWL2z-0004pu-Hd; Mon, 22 Nov 2004 15:44:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWKxA-0001fn-Qn; Mon, 22 Nov 2004 15:38:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13024; Mon, 22 Nov 2004 15:38:27 -0500 (EST) Message-Id: <200411222038.PAA13024@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 22 Nov 2004 15:38:27 -0500 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-docs-rfmibv2-12.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 X-Spam-Score: 0.4 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces Author(s) : D. Raftus, et al. Filename : draft-ietf-ipcdn-docs-rfmibv2-12.txt Pages : 130 Date : 2004-11-22 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a 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). This document revises RFC 2670. Please see section 10 for a description of the changes from RFC 2670. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-docs-rfmibv2-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-22160422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-docs-rfmibv2-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-22160422.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart-- From ipcdn-bounces@ietf.org Mon Nov 22 17:51:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01713 for ; Mon, 22 Nov 2004 17:51:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWN58-0002jh-MD for ipcdn-archive@ietf.org; Mon, 22 Nov 2004 17:54:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMch-0000ft-R4; Mon, 22 Nov 2004 17:25:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMa4-0008Sy-Mf for ipcdn@megatron.ietf.org; Mon, 22 Nov 2004 17:22:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28409 for ; Mon, 22 Nov 2004 17:22:41 -0500 (EST) Received: from news.ti.com ([192.94.94.33] helo=dragon.ti.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMdY-0006ov-0a for ipcdn@ietf.org; Mon, 22 Nov 2004 17:26:23 -0500 Received: from dlep90.itg.ti.com ([157.170.152.54]) by dragon.ti.com (8.13.1/8.13.1) with ESMTP id iAMMM8g8015775; Mon, 22 Nov 2004 16:22:08 -0600 (CST) Received: from dlee2k71.ent.ti.com (localhost [127.0.0.1]) by dlep90.itg.ti.com (8.12.11/8.12.11) with ESMTP id iAMMM7iX017938; Mon, 22 Nov 2004 16:22:08 -0600 (CST) Received: from dlee2k05.ent.ti.com ([157.170.152.114]) by dlee2k71.ent.ti.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 22 Nov 2004 16:22:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Nov 2004 16:22:07 -0600 Message-ID: Thread-Topic: Ev MIB pktcDevEvEndpointName description Thread-Index: AcTOjD5R7QEJbv5YR3qUMWQ3E1Q7tACVTDXQ From: "Kumar, Satish" To: "Eugene Nechamkin" , X-OriginalArrivalTime: 22 Nov 2004 22:22:07.0526 (UTC) FILETIME=[B3C1D460:01C4D0E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Ev MIB pktcDevEvEndpointName description 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Hi, The current Ev MIB has below description. pktcDevEvEndpointName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This is the endpoint identifier followed by the FQDN/IP Address of the device. This is in the form - AALN/X:FQDN/IP Address. If the event is not specific to an endpoint, then the contents is just the FQDN/IP address." ::=3D { pktcDevEventEntry 8 } In Packetcable FQDN(only) is allowed for MTA during NCS message exchange. Why do we need IP address be referred here? Comments please.. Thx, Satish _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Nov 22 22:29:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06466 for ; Mon, 22 Nov 2004 22:29:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWRQH-00063Y-Ru for ipcdn-archive@ietf.org; Mon, 22 Nov 2004 22:32:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRL3-0003t7-EP; Mon, 22 Nov 2004 22:27:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRGT-0002kQ-Db for ipcdn@megatron.ietf.org; Mon, 22 Nov 2004 22:22:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03738 for ; Mon, 22 Nov 2004 22:22:47 -0500 (EST) Received: from mms1.broadcom.com ([63.70.210.58] helo=mms2.broadcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWRK2-0004ve-Pd for ipcdn@ietf.org; Mon, 22 Nov 2004 22:26:31 -0500 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Mon, 22 Nov 2004 19:22:11 -0800 X-Server-Uuid: 011F2A72-58F1-4BCE-832F-B0D661E896E8 Received: from nt-sjca-0740.brcm.ad.broadcom.com ( nt-sjca-0740.sj.broadcom.com [10.16.192.49]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id TAA22165; Mon, 22 Nov 2004 19:22:20 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-sjca-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Nov 2004 19:22:11 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 22 Nov 2004 19:22:09 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E7682C@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: Ev MIB pktcDevEvEndpointName description Thread-Index: AcTOjD5R7QEJbv5YR3qUMWQ3E1Q7tACVTDXQAAo/TCA= From: "Eugene Nechamkin" To: "Kumar, Satish" X-OriginalArrivalTime: 23 Nov 2004 03:22:11.0173 (UTC) FILETIME=[9EC45950:01C4D10B] X-WSS-ID: 6DBC736905841394-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: ipcdn@ietf.org Subject: [ipcdn] RE: Ev MIB pktcDevEvEndpointName description 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Satish, The IP format of the endpoint name is coming from the requirements of the PacketCable NCS Spec (section 4.1.1): "Endpoint names will be of the form local-endpoint-name@domain-name=20 where domain-name is an absolute domain-name as defined in [24] and includes a host portion, thus an example domain-name could be: MyEmbeddedClient.cablelabs.com Also, domain-name may be an IPv4 address in dotted decimal form represented as a text-string and surrounded by a left and a right square bracket ("[" and "]") as in "[128.96.41.1]" - please consult [22] for details. However, use of IP addresses is generally discouraged." Eugene. -----Original Message----- From: Kumar, Satish [mailto:satish.kumar@ti.com]=20 Sent: Monday, November 22, 2004 2:22 PM To: Eugene Nechamkin; ipcdn@ietf.org Subject: Ev MIB pktcDevEvEndpointName description Hi, The current Ev MIB has below description. pktcDevEvEndpointName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This is the endpoint identifier followed by the FQDN/IP Address of the device. This is in the form - AALN/X:FQDN/IP Address. If the event is not specific to an endpoint, then the contents is just the FQDN/IP address." ::=3D { pktcDevEventEntry 8 } In Packetcable FQDN(only) is allowed for MTA during NCS message exchange. Why do we need IP address be referred here? Comments please.. Thx, Satish _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Nov 23 01:53:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22057 for ; Tue, 23 Nov 2004 01:53:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWUbx-0007Kb-Nm for ipcdn-archive@ietf.org; Tue, 23 Nov 2004 01:57:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWUVY-0004g1-0z; Tue, 23 Nov 2004 01:50:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWUSv-00042r-CY for ipcdn@megatron.ietf.org; Tue, 23 Nov 2004 01:47:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21744 for ; Tue, 23 Nov 2004 01:47:51 -0500 (EST) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWUWV-0006Yp-I8 for ipcdn@ietf.org; Tue, 23 Nov 2004 01:51:36 -0500 Received: from h-69-3-25-238.snvacaid.dynamic.covad.net ([69.3.25.238] helo=oemcomputer) by pop-a065d10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CWUSr-0007c4-00 for ipcdn@ietf.org; Mon, 22 Nov 2004 22:47:49 -0800 Message-ID: <001a01c4d128$a3a038a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <24CDBA67F085904999751B3C4F9E8C0B01E7682C@NT-RMNA-0740.brcm.ad.broadcom.com> Subject: Re: [ipcdn] RE: Ev MIB pktcDevEvEndpointName description Date: Mon, 22 Nov 2004 22:49:54 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi - > From: "Eugene Nechamkin" > To: "Kumar, Satish" > Cc: > Sent: Monday, November 22, 2004 7:22 PM > Subject: [ipcdn] RE: Ev MIB pktcDevEvEndpointName description ... > The IP format of the endpoint name is coming from the requirements of > the PacketCable NCS Spec (section 4.1.1): ... > pktcDevEvEndpointName OBJECT-TYPE ... This would be a good place to use the REFERENCE construct. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn