From mailman-bounces@ietf.org Wed Sep 1 09:59:59 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 JAA07342 for ; Wed, 1 Sep 2004 09:35:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2T4n-00074U-OE for ipcdn-archive@ietf.org; Wed, 01 Sep 2004 07:14:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2RHO-0008Cu-NT for ipcdn-archive@ietf.org; Wed, 01 Sep 2004 05:19:46 -0400 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: Wed, 01 Sep 2004 05:04:40 -0400 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 Wed Sep 1 13:52: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 NAA15118 for ; Wed, 1 Sep 2004 13:52:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2ZJe-0000zh-93 for ipcdn-archive@ietf.org; Wed, 01 Sep 2004 13:54:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2YOH-00021s-38; Wed, 01 Sep 2004 12:55:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XQB-0000OV-Pc for ipcdn@megatron.ietf.org; Wed, 01 Sep 2004 11:53:16 -0400 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 LAA01703 for ; Wed, 1 Sep 2004 11:53:12 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2XSL-0007lQ-Vj for ipcdn@ietf.org; Wed, 01 Sep 2004 11:55:33 -0400 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 i81FqcPJ016117; Wed, 1 Sep 2004 09:52:38 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Sep 2004 09:52:38 -0600 Message-ID: Thread-Topic: Protocol Action: 'Definitions of Managed Objects for Network Address Translators (NAT)' to Proposed Standard Thread-Index: AcSMfd21XxPggLGGR4eGb2TE9yDQTADvV0Mg From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Content-Transfer-Encoding: quoted-printable Cc: bwijnen@lucent.com, Allison Mankin Subject: [ipcdn] FW: Protocol Action: 'Definitions of Managed Objects for Network Address Translators (NAT)' 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: 3be09dac38eaa50f02d21c7fcee1128c Content-Transfer-Encoding: quoted-printable Folks, Does this MIB for NAT devices Internet-Draft have any implications on the ipcdn CableHome MIBs? do we need some time to do a final review of this ID? If you have any comments, please send them asap (it may be too late... but I want to make sure the group has seen this protocol action notice). Jean-Francois. -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org]=20 Sent: Friday, August 27, 2004 3:20 PM To: IETF-Announce Cc: Internet Architecture Board; RFC Editor Subject: Protocol Action: 'Definitions of Managed Objects for Network Address Translators (NAT)' to Proposed Standard=20 The IESG has approved the following document: - 'Definitions of Managed Objects for Network Address Translators (NAT) ' as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group.=20 The IESG contact person is Allison Mankin. Technical Summary =20 This document defines a portion of the Management Information Base (MIB) for=20 devices implementing Network Address Translator (NAT) function. This MIB module may be used for configuration of specific aspects of the NAT function (but in particular, not to configure NAT bindings). Firewall configuration, in a NAT-firewall-combining device, is specifically outside the scope of this=20 document. Working Group Summary =20 Although this document is an individual submission (developed largely after=20 closure of IETF's NAT working group, it was reviewed by the MIDCOM working group. A good number of comments were received from MIDCOM participants. =20 Protocol Quality =20 This specification was reviewed for the IESG by Allison Mankin, Bert Wijnen,=20 and Juergen Schoenwaelder, of the MIB Doctors. RFC Editor Notes Section 3. Terminology OLD: Definitions for majority of the terms used throughout the document may be found in RFC 2663 [RFC2663]. Additional terms that further classify NAPT implementations are defined in RFC 3489 [RFC3489]. Listed below are terms used in this document NEW: =20 Definitions for majority of the terms used throughout the document may be found in RFC 2663 [RFC2663]. Additional terms that further classify NAPT implementations are defined in RFC 3489 [RFC3489]. Listed below are terms used in this document Address realm - An address realm is a realm of unique network addresses that are routable within the realm. For example, an enterprise address realm could be constituted of private IP addresses in the ranges specified in RFC 1918 [RFC1918], which are routable within the enterprise, but not across the Internet. A public realm is constituted of globally unique network addresses. [And add RFC 1918 to the Informative References] ----------- OLD: NAT Session - A NAT session is an association between a session as seen in the private realm and a session as seen in the public realm, by virtue of NAT translation. If a session in the private realm were to be represented as (PrivateSrcAddr, PrivateDstAddr, TransportProtocol, PrivateSrcPort, PrivateDstPort) and the same session in the public realm were to be represented as (PublicSrcAddr, PublicDstAddr, TransportProtocol, PublicSrcPort, PublicDstPort), the NAT session will provide the translation glue between the two session representations. NEW: NAT Session - A NAT session is an association between a session as seen in the private realm and a session as seen in the public realm, by virtue of NAT translation. If a session in the private realm were to be represented as (PrivateSrcAddr, PrivateDstAddr, TransportProtocol, PrivateSrcPort, PrivateDstPort) and the same session in the public realm were to be represented as (PublicSrcAddr, PublicDstAddr, TransportProtocol, PublicSrcPort, PublicDstPort), the NAT session will provide the translation glue between the two session representations. NAT sessions in the document are restricted to sessions based on TCP and UDP only . In the future, NAT sessions may be extended to be based on other transport protocols such as SCTP, UDP-lite and DCCP. ----------- Section 5. Definitions=20 OLD: natAddrBindEntry OBJECT-TYPE SYNTAX NatAddrBindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table holds information about an active address BIND. These entries are lost upon agent restart." INDEX { ifIndex, natAddrBindLocalAddrType, natAddrBindLocalAddr } ::=3D { natAddrBindTable 1 } NEW: natAddrBindEntry OBJECT-TYPE SYNTAX NatAddrBindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table holds information about an active address BIND. These entries are lost upon agent restart. This row has indexing which may create variables with more than 128 subidentifiers. Implementers of this table must be careful not to create entries that would result in OIDs which exceed the 128 subidentifier limit. Otherwise, the information cannot be accessed using SNMPv1, SNMPv2c or SNMPv3." INDEX { ifIndex, natAddrBindLocalAddrType, natAddrBindLocalAddr } ::=3D { natAddrBindTable 1 } ----- OLD: natAddrBindLocalAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the private-realm specific network layer address, which maps to the public-realm address represented by natAddrBindGlobalAddr. The type of this address is determined by the value of the natAddrBindLocalAddrType object. As this object is used in the index for the natAddrBindTable, implementers of this table should be careful not to create entries that would result in OIDs with more than 128 subidentifiers; else the information cannot be accessed using SNMPv1, SNMPv2c or SNMPv3." ::=3D { natAddrBindEntry 2 } NEW: natAddrBindLocalAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the private-realm specific network layer address, which maps to the public-realm address represented by natAddrBindGlobalAddr. The type of this address is determined by the value of the natAddrBindLocalAddrType object." =20 ::=3D { natAddrBindEntry 2 } ------ OLD: natAddrPortBindEntry OBJECT-TYPE SYNTAX NatAddrPortBindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in the this table holds information about a NAPT bind that is currently active. These entries are lost upon agent restart." INDEX { ifIndex, natAddrPortBindLocalAddrType, natAddrPortBindLocalAddr, natAddrPortBindLocalPort, natAddrPortBindProtocol } ::=3D { natAddrPortBindTable 1 } NEW: natAddrPortBindEntry OBJECT-TYPE SYNTAX NatAddrPortBindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in the this table holds information about a NAPT bind that is currently active. These entries are lost upon agent restart. This row has indexing which may create variables with more than 128 subidentifiers. Implementers of this table must be careful not to create entries which would result in OIDs that exceed the 128 subidentifier limit.=20 Otherwise, the information cannot be accessed using SNMPv1, SNMPv2c or SNMPv3." INDEX { ifIndex, natAddrPortBindLocalAddrType, natAddrPortBindLocalAddr, natAddrPortBindLocalPort, natAddrPortBindProtocol } ::=3D { natAddrPortBindTable 1 } ------ OLD: natAddrPortBindLocalAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the private-realm specific network layer address which, in conjunction with natAddrPortBindLocalPort, maps to the public-realm network layer address and transport id represented by natAddrPortBindGlobalAddr and natAddrPortBindGlobalPort respectively. The type of this address is determined by the value of the natAddrPortBindLocalAddrType object. As this object is used in the index for the natAddrPortBindTable, implementers of this table should be careful not to create entries that would result in OIDs with more than 128 subidentifiers; else the information cannot be accessed using SNMPv1, SNMPv2c or SNMPv3." ::=3D { natAddrPortBindEntry 2 } NEW: natAddrPortBindLocalAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the private-realm specific network layer address which, in conjunction with natAddrPortBindLocalPort, maps to the public-realm network layer address and transport id represented by natAddrPortBindGlobalAddr and natAddrPortBindGlobalPort respectively. The type of this address is determined by the value of the natAddrPortBindLocalAddrType object." ::=3D { natAddrPortBindEntry 2 } ----- OLD: natMIB MODULE-IDENTITY LAST-UPDATED "200404180000Z" ORGANIZATION "Individuals" NEW: natMIB MODULE-IDENTITY LAST-UPDATED "200404180000Z" ORGANIZATION "IETF Transport Area" _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Sep 1 14:08:38 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 OAA17076 for ; Wed, 1 Sep 2004 14:08:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2ZZV-0002UZ-1q for ipcdn-archive@ietf.org; Wed, 01 Sep 2004 14:11:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ZGr-0005DW-5j; Wed, 01 Sep 2004 13:51:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2YFL-0007Hs-Ed for ipcdn@megatron.ietf.org; Wed, 01 Sep 2004 12:46:07 -0400 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 MAA07631 for ; Wed, 1 Sep 2004 12:46:03 -0400 (EDT) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2YHY-0003i3-7W for ipcdn@ietf.org; Wed, 01 Sep 2004 12:48:25 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i81Gk41a001403 for ; Wed, 1 Sep 2004 09:46:04 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i81Gc8TQ024005 for ; Wed, 1 Sep 2004 11:38:08 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Wed, 1 Sep 2004 09:46:03 -0700 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Date: Wed, 1 Sep 2004 09:46:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.6 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [ipcdn] NCS Sig MIB draft 5 - PktcRingCadence constraints 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="===============0760126568==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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. --===============0760126568== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C49043.2AD08536" 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_01C49043.2AD08536 Content-Type: text/plain The following issue has been raised on PktcRingCadence during MIB Dr. review. Any comments on whether we need to introduce MUST requirements to enforce the constraints noted below? Thanks. Gordon >From Randy: >12) PktcRingCadence: are implementations required to enforce any constraints on the values of a) the bit count field, b) >the repeatable field, c) the 3 on-off transition limit, d) values for bits beyond the bit count, e) an octet-string length other >than the minimum required to encode whatever length is specified in the bit count field? ------_=_NextPart_001_01C49043.2AD08536 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NTgiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFz cz00MjUyOTMxMTYtMDEwOTIwMDQ+VGhlIGZvbGxvd2luZyBpc3N1ZSANCmhhcyBiZWVuIHJhaXNl ZCBvbiBQa3RjUmluZ0NhZGVuY2UgZHVyaW5nIE1JQiBEci4gcmV2aWV3LiBBbnkgY29tbWVudHMg b24gDQp3aGV0aGVyIHdlIG5lZWQgdG8gaW50cm9kdWNlIE1VU1QgcmVxdWlyZW1lbnRzIHRvIGVu Zm9yY2UgdGhlIGNvbnN0cmFpbnRzIG5vdGVkIA0KYmVsb3c/IFRoYW5rcy48L1NQQU4+PC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTQyNTI5 MzExNi0wMTA5MjAwND48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTQyNTI5MzExNi0wMTA5MjAwND5Hb3Jkb248L1NQ QU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFz cz00MjUyOTMxMTYtMDEwOTIwMDQ+PEZPTlQgDQpzaXplPTI+PC9GT05UPjwvU1BBTj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTQy NTI5MzExNi0wMTA5MjAwND5Gcm9tIA0KUmFuZHk6PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz00MjUyOTMxMTYtMDEwOTIwMDQ+ PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+ PFNQQU4gY2xhc3M9NDI1MjkzMTE2LTAxMDkyMDA0PjxGT05UIHNpemU9Mj4mZ3Q7MTIpIA0KUGt0 Y1JpbmdDYWRlbmNlOiBhcmUgaW1wbGVtZW50YXRpb25zIHJlcXVpcmVkIHRvIGVuZm9yY2UgYW55 IGNvbnN0cmFpbnRzIG9uIHRoZSANCnZhbHVlcyBvZiBhKSB0aGUgYml0IGNvdW50IGZpZWxkLCBi KSAmZ3Q7dGhlIHJlcGVhdGFibGUgZmllbGQsIGMpIHRoZSAzIG9uLW9mZiANCnRyYW5zaXRpb24g bGltaXQsIGQpIHZhbHVlcyBmb3IgYml0cyBiZXlvbmQgdGhlIGJpdCBjb3VudCwgZSkgYW4gb2N0 ZXQtc3RyaW5nIA0KbGVuZ3RoIG90aGVyICZndDt0aGFuIHRoZSBtaW5pbXVtIHJlcXVpcmVkIHRv IGVuY29kZSB3aGF0ZXZlciBsZW5ndGggaXMgDQpzcGVjaWZpZWQgaW4gdGhlIGJpdCBjb3VudCBm aWVsZD88L0RJVj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C49043.2AD08536-- --===============0760126568== 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 --===============0760126568==-- From ipcdn-bounces@ietf.org Wed Sep 1 15:38:26 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 PAA25271 for ; Wed, 1 Sep 2004 15:38:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2ayN-0001Ce-Su for ipcdn-archive@ietf.org; Wed, 01 Sep 2004 15:40:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ajj-0003Ge-JV; Wed, 01 Sep 2004 15:25:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2acl-0004NY-0D for ipcdn@megatron.ietf.org; Wed, 01 Sep 2004 15:18:28 -0400 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 PAA22972 for ; Wed, 1 Sep 2004 15:18:24 -0400 (EDT) Received: from mms1.broadcom.com ([63.70.210.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2aey-0008JS-Pe for ipcdn@ietf.org; Wed, 01 Sep 2004 15:20:46 -0400 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Wed, 01 Sep 2004 12:18:20 -0700 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from nt-sjca-0740.brcm.ad.broadcom.com ( nt-sjca-0740.sj.broadcom.com [10.16.192.49]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id MAA16513; Wed, 1 Sep 2004 12:17:43 -0700 (PDT) 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.0); Wed, 1 Sep 2004 12:18:18 -0700 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.0); Wed, 1 Sep 2004 12:18:17 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: [ipcdn] NCS Sig MIB draft 5 - PktcRingCadence constraints Date: Wed, 1 Sep 2004 12:18:15 -0700 Message-ID: <24CDBA67F085904999751B3C4F9E8C0BE2DD53@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] NCS Sig MIB draft 5 - PktcRingCadence constraints thread-index: AcSQTsyHyRsvByGDRhyjm5uSHwpoygABB0jw From: "Eugene Nechamkin" To: "Beacham Gordon-CGB005" , ipcdn@ietf.org X-OriginalArrivalTime: 01 Sep 2004 19:18:17.0110 (UTC) FILETIME=[6F3E6B60:01C49058] X-WSS-ID: 6D28FFF62N82636922-01-01 X-Spam-Score: 0.9 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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="===============0426954951==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 This is a multi-part message in MIME format. --===============0426954951== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C49058.6E5BC6B3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C49058.6E5BC6B3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =20 The "inforcement" of the PktcRingCadence TC is supposed to be provided by the fact that an EMTA will try to interpret the MIB Object's value in the SNMP SET in accordance with the rules of the TC. If the value cannot be interpreted correctly, the SNMP error flag should be raised and returned in the SNMP SET response message. This is a general SNMP protocol approach applicable to any MIB Object, and I don't see anything "special" in PktcRingCadence TC in this respect to be able to agree with the dedicated "inforcement" statement.=20 =20 Eugene. ________________________________ From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Beacham Gordon-CGB005 Sent: Wednesday, September 01, 2004 9:46 AM To: 'ipcdn@ietf.org' Subject: [ipcdn] NCS Sig MIB draft 5 - PktcRingCadence constraints The following issue has been raised on PktcRingCadence during MIB Dr. review. Any comments on whether we need to introduce MUST requirements to enforce the constraints noted below? Thanks. =20 Gordon =20 >From Randy: =20 >12) PktcRingCadence: are implementations required to enforce any constraints on the values of a) the bit count field, b) >the repeatable field, c) the 3 on-off transition limit, d) values for bits beyond the bit count, e) an octet-string length other >than the minimum required to encode whatever length is specified in the bit count field? ------_=_NextPart_001_01C49058.6E5BC6B3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message
 
The "inforcement" of the PktcRingCadence TC is = supposed to=20 be provided by the fact that an EMTA will try to interpret the MIB = Object's=20 value in the SNMP SET in accordance with the rules of the TC. If the = value=20 cannot be interpreted correctly, the SNMP error flag should be = raised and=20 returned in the SNMP SET response message. This is a general SNMP = protocol=20 approach applicable to any MIB Object, and I don't see anything = "special" in=20 PktcRingCadence TC in this respect to be able to agree with the = dedicated=20 "inforcement" statement.
 
Eugene.

From: ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org] On Behalf Of Beacham=20 Gordon-CGB005
Sent: Wednesday, September 01, 2004 9:46=20 AM
To: 'ipcdn@ietf.org'
Subject: [ipcdn] NCS Sig MIB = draft 5=20 - PktcRingCadence constraints

The = following issue=20 has been raised on PktcRingCadence during MIB Dr. review. Any comments = on=20 whether we need to introduce MUST requirements to enforce the = constraints noted=20 below? Thanks.
 
Gordon
 
From=20 Randy:
 
>12)=20 PktcRingCadence: are implementations required to enforce any constraints = on the=20 values of a) the bit count field, b) >the repeatable field, c) the 3 = on-off=20 transition limit, d) values for bits beyond the bit count, e) an = octet-string=20 length other >than the minimum required to encode whatever length is=20 specified in the bit count = field?
------_=_NextPart_001_01C49058.6E5BC6B3-- --===============0426954951== 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 --===============0426954951==-- From ipcdn-bounces@ietf.org Wed Sep 1 18:15:44 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 SAA11198 for ; Wed, 1 Sep 2004 18:15:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2dQe-0007OW-TU for ipcdn-archive@ietf.org; Wed, 01 Sep 2004 18:18:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2d8n-0001Qf-PS; Wed, 01 Sep 2004 17:59:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2cSe-0003ac-V3 for ipcdn@megatron.ietf.org; Wed, 01 Sep 2004 17:16:10 -0400 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 RAA05025 for ; Wed, 1 Sep 2004 17:16:05 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2cUu-0001xn-QU for ipcdn@ietf.org; Wed, 01 Sep 2004 17:18:29 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i81LFYVH015150 for ; Wed, 1 Sep 2004 16:15:35 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 1 Sep 2004 23:15:34 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550516F67D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Jean-Francois Mule , ipcdn@ietf.org Date: Wed, 1 Sep 2004 23:15:32 +0200 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: abda3837e791065a13ac6f11cf8e625a Cc: bwijnen@lucent.com, Allison Mankin Subject: [ipcdn] RE: Protocol Action: 'Definitions of Managed Objects for Network Address Translators (NAT)' 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: 9f79b8e383fd3af2b1b5b1d0910f6094 jean Francois writes: > > Folks, > > Does this MIB for NAT devices Internet-Draft have any implications on > the ipcdn CableHome MIBs? do we need some time to do a final review of > this ID? If you have any comments, please send them asap (it may be too > late... but I want to make sure the group has seen this protocol action > notice). > It would indeed be REALLY late. Went through a 4 week IETF Last Call quite a while back. But if you find any fatal flaws, we certainly want to hear about them. Bert > Jean-Francois. > > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Friday, August 27, 2004 3:20 PM > To: IETF-Announce > Cc: Internet Architecture Board; RFC Editor > Subject: Protocol Action: 'Definitions of Managed Objects for Network > Address Translators (NAT)' to Proposed Standard > > > The IESG has approved the following document: > > - 'Definitions of Managed Objects for Network Address > Translators (NAT) > ' > as a Proposed Standard > > This document has been reviewed in the IETF but is not the > product of an > IETF Working Group. > > The IESG contact person is Allison Mankin. > > Technical Summary > > This document defines a portion of the Management Information > Base (MIB) > for > devices implementing Network Address Translator (NAT) > function. This MIB > > module may be used for configuration of specific aspects of the NAT > function (but in particular, not to configure NAT bindings). Firewall > configuration, in a NAT-firewall-combining device, is specifically > outside the scope of this > document. > > Working Group Summary > > Although this document is an individual submission (developed largely > after > closure of IETF's NAT working group, it was reviewed by the MIDCOM > working group. A good number of comments were received from MIDCOM > participants. > > Protocol Quality > > This specification was reviewed for the IESG by Allison Mankin, Bert > Wijnen, > and Juergen Schoenwaelder, of the MIB Doctors. > > RFC Editor Notes > > Section 3. Terminology > > OLD: > > > Definitions for majority of the terms used throughout the document > may be found in RFC 2663 [RFC2663]. Additional terms that further > classify NAPT implementations are defined in RFC 3489 [RFC3489]. > Listed below are terms used in this document > > NEW: > > > Definitions for majority of the terms used throughout the document > may be found in RFC 2663 [RFC2663]. Additional terms that further > classify NAPT implementations are defined in RFC 3489 [RFC3489]. > Listed below are terms used in this document > > Address realm - An address realm is a realm of unique network > addresses that are routable within the realm. For example, an > enterprise address realm could be constituted of private IP > addresses in the ranges specified in RFC 1918 [RFC1918], which > are routable within the enterprise, but not across the Internet. > A public realm is constituted of globally unique network > addresses. > > [And add RFC 1918 to the Informative References] > > ----------- > > OLD: > > NAT Session - A NAT session is an association between a session > as seen in the private realm and a session as seen in the public > realm, by virtue of NAT translation. If a session in the private > realm were to be represented as (PrivateSrcAddr, PrivateDstAddr, > TransportProtocol, PrivateSrcPort, PrivateDstPort) and the > same session in the public realm were to be represented as > (PublicSrcAddr, PublicDstAddr, TransportProtocol, PublicSrcPort, > PublicDstPort), the NAT session will provide the translation > glue between the two session representations. > > NEW: > > > NAT Session - A NAT session is an association between a session > as seen in the private realm and a session as seen in the public > realm, by virtue of NAT translation. If a session in the private > realm were to be represented as (PrivateSrcAddr, PrivateDstAddr, > TransportProtocol, PrivateSrcPort, PrivateDstPort) and the > same session in the public realm were to be represented as > (PublicSrcAddr, PublicDstAddr, TransportProtocol, PublicSrcPort, > PublicDstPort), the NAT session will provide the translation > glue between the two session representations. NAT sessions in > the document are restricted to sessions based on TCP and UDP > only . In the future, NAT sessions may be extended to be based > on other transport protocols such as SCTP, UDP-lite and DCCP. > > > ----------- > Section 5. Definitions > > OLD: > natAddrBindEntry OBJECT-TYPE > SYNTAX NatAddrBindEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Each entry in this table holds information about > an active address BIND. These entries are lost > upon agent restart." > INDEX { ifIndex, natAddrBindLocalAddrType, > natAddrBindLocalAddr } > ::= { natAddrBindTable 1 } > > NEW: > natAddrBindEntry OBJECT-TYPE > SYNTAX NatAddrBindEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Each entry in this table holds information about > an active address BIND. These entries are lost > upon agent restart. > > This row has indexing which may create variables with > more than 128 subidentifiers. Implementers of this table > must be careful not to create entries that would result > in OIDs which exceed the 128 subidentifier limit. > Otherwise, the information cannot be accessed using > SNMPv1, SNMPv2c or SNMPv3." > > INDEX { ifIndex, natAddrBindLocalAddrType, > natAddrBindLocalAddr } > ::= { natAddrBindTable 1 } > > ----- > > OLD: > natAddrBindLocalAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This object represents the private-realm specific network > layer address, which maps to the public-realm address > represented by natAddrBindGlobalAddr. > > > The type of this address is determined by the value of > the natAddrBindLocalAddrType object. > > As this object is used in the index for the > natAddrBindTable, implementers of this table should be > careful not to create entries that would result in OIDs > with more than 128 subidentifiers; else the information > cannot be accessed using SNMPv1, SNMPv2c or SNMPv3." > > ::= { natAddrBindEntry 2 } > > NEW: > natAddrBindLocalAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This object represents the private-realm specific network > layer address, which maps to the public-realm address > represented by natAddrBindGlobalAddr. > > > The type of this address is determined by the value of > the natAddrBindLocalAddrType object." > > > ::= { natAddrBindEntry 2 } > > ------ > > OLD: > > natAddrPortBindEntry OBJECT-TYPE > SYNTAX NatAddrPortBindEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Each entry in the this table holds information > about a NAPT bind that is currently active. > These entries are lost upon agent restart." > INDEX { ifIndex, natAddrPortBindLocalAddrType, > natAddrPortBindLocalAddr, natAddrPortBindLocalPort, > natAddrPortBindProtocol } > ::= { natAddrPortBindTable 1 } > > NEW: > > natAddrPortBindEntry OBJECT-TYPE > SYNTAX NatAddrPortBindEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Each entry in the this table holds information > about a NAPT bind that is currently active. > These entries are lost upon agent restart. > > This row has indexing which may create variables with > more than 128 subidentifiers. Implementers of this table > must be careful not to create entries which would result > in OIDs that exceed the 128 subidentifier limit. > Otherwise, the information cannot be accessed using > SNMPv1, SNMPv2c or SNMPv3." > INDEX { ifIndex, natAddrPortBindLocalAddrType, > natAddrPortBindLocalAddr, natAddrPortBindLocalPort, > natAddrPortBindProtocol } > ::= { natAddrPortBindTable 1 } > > ------ > > OLD: > natAddrPortBindLocalAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This object represents the private-realm specific network > layer address which, in conjunction with > natAddrPortBindLocalPort, maps to the public-realm > network layer address and transport id represented by > natAddrPortBindGlobalAddr and natAddrPortBindGlobalPort > respectively. > > > The type of this address is determined by the value of > the natAddrPortBindLocalAddrType object. > > > As this object is used in the index for the > natAddrPortBindTable, implementers of this table should > be careful not to create entries that would result in > OIDs with more than 128 subidentifiers; else the > information cannot be accessed using SNMPv1, SNMPv2c or > SNMPv3." > ::= { natAddrPortBindEntry 2 } > > NEW: > natAddrPortBindLocalAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This object represents the private-realm specific network > layer address which, in conjunction with > natAddrPortBindLocalPort, maps to the public-realm > network layer address and transport id represented by > natAddrPortBindGlobalAddr and natAddrPortBindGlobalPort > respectively. > > > The type of this address is determined by the value of > the natAddrPortBindLocalAddrType object." > ::= { natAddrPortBindEntry 2 } > > ----- > > OLD: > natMIB MODULE-IDENTITY > LAST-UPDATED "200404180000Z" > ORGANIZATION "Individuals" > > NEW: > natMIB MODULE-IDENTITY > LAST-UPDATED "200404180000Z" > ORGANIZATION "IETF Transport Area" > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Sep 2 00:57:37 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 AAA17686 for ; Thu, 2 Sep 2004 00:57:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2jhd-0005A5-T8 for ipcdn-archive@ietf.org; Thu, 02 Sep 2004 01:00:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2jWM-0005eR-Br; Thu, 02 Sep 2004 00:48:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2jJp-00011f-8e for ipcdn@megatron.ietf.org; Thu, 02 Sep 2004 00:35:29 -0400 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 AAA16703 for ; Thu, 2 Sep 2004 00:35:25 -0400 (EDT) Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2jM8-0003Ko-1e for ipcdn@ietf.org; Thu, 02 Sep 2004 00:37:53 -0400 Received: from h-68-166-38-135.snvacaid.dynamic.covad.net ([68.166.38.135] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1C2jJf-0005Zv-00 for ipcdn@ietf.org; Wed, 01 Sep 2004 21:35:19 -0700 Message-ID: <002401c490a6$c2d004c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <24CDBA67F085904999751B3C4F9E8C0BE2DD53@NT-RMNA-0740.brcm.ad.broadcom.com> Subject: Re: [ipcdn] NCS Sig MIB draft 5 - PktcRingCadence constraints Date: Wed, 1 Sep 2004 21:38:20 -0700 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.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: 4adaf050708fb13be3316a9eee889caa Hi - > From: "Eugene Nechamkin" > To: "Beacham Gordon-CGB005" ; > Sent: Wednesday, September 01, 2004 12:18 PM > Subject: RE: [ipcdn] NCS Sig MIB draft 5 - PktcRingCadence constraints > > > The "inforcement" of the PktcRingCadence TC is supposed to be provided > by the fact that an EMTA will try to interpret the MIB Object's value in > the SNMP SET in accordance with the rules of the TC. If the value cannot > be interpreted correctly, the SNMP error flag should be raised and > returned in the SNMP SET response message. This is a general SNMP > protocol approach applicable to any MIB Object, and I don't see anything > "special" in PktcRingCadence TC in this respect to be able to agree with > the dedicated "inforcement" statement. .... So the intent is that implementations MUST perform the following checks: - the first two bytes MUST represent a value between 1 and 264; any other values MUST be rejected. - the bit count field needs to be consistent with the OCTET STRING's length. If there are unused octets, the set MUST be rejected. Likewise, if the length implied by the bit count field is greater than the OCTET STRING's length, the set MUST be rejected. - the value of the repeatable field MUST be 0x00 or 0x80 - If there are more than three on-to-off transitions, the set MUST be rejected. (So 01010101 would be legal, but 10101010 would not, right?) This still begs the question of what value should be in the "unused" bits. Ignored by receiver? What value SHOULD they be set to by the sender? Are they required to be the same on a GET as they were on the SET? Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sat Sep 4 22:40:33 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 WAA21323 for ; Sat, 4 Sep 2004 22:40:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3mze-0005F4-LM for ipcdn-archive@ietf.org; Sat, 04 Sep 2004 22:43:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3mt6-0005Y8-3S; Sat, 04 Sep 2004 22:36:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3K1f-0001ig-5Z for ipcdn@megatron.ietf.org; Fri, 03 Sep 2004 15:47:11 -0400 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 PAA10432 for ; Fri, 3 Sep 2004 15:47:08 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3K4I-0007pd-BF for ipcdn@ietf.org; Fri, 03 Sep 2004 15:49:56 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i83Jl71X025406 for ; Fri, 3 Sep 2004 12:47:07 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i83Jkoig007883 for ; Fri, 3 Sep 2004 14:46:50 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Fri, 3 Sep 2004 12:47:05 -0700 Message-ID: From: Beacham Gordon-CGB005 To: ipcdn@ietf.org Date: Fri, 3 Sep 2004 12:47:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.3 (++) X-Scan-Signature: 96f877a001288d1394c267f7fd902958 X-Mailman-Approved-At: Sat, 04 Sep 2004 22:36:15 -0400 Subject: [ipcdn] Responses to comments on IETF Sig MIB draft 5 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="===============1827062096==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: 3ab74996dadb62fefc8e35f80f79218e 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. --===============1827062096== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C491EE.C81B7C68" 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_01C491EE.C81B7C68 Content-Type: text/plain Responses to comments on IETF Sig MIB draft 5 **************************************************** Part 1: **************************************************** 1) lines limited to 72 characters: trailing blanks make line 26 too long (73 characters) trailing blanks make line 99 too long (73 characters) trailing blanks make line 2206 too long (73 characters) trailing blanks make line 2226 too long (73 characters) trailing blanks make line 2240 too long (73 characters) trailing blanks make line 2301 too long (73 characters) AI: Fix in final formating. 2) some pages have more than 58 lines AI: Fix in final formating. 3) pages not separated by FF character AI: Fix in final formating. 4) the words "INTERNET-DRAFT" should be in upper left corner of first page AI: Changed. 5) IPR Boilerplate: OK, but note that alternative wording for "plural" authors has been presented on the wgchairs list: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of RFC 3668. AI: Changed. 6) Internet-Draft boilerplate: text is OK, but formatting is strange. No change. Not clear what is "strange". 7) Filename: broken by strange formatting on first page AI: Changed. 8) author list: present, but mal-formatted AI: Fixed formatting. 9) Introduction: missing. (2.2 #5) AI: Added Introduction section. 10) IANA considerations: contradictory, (2.2 #7b) seems to apply, since an OID needs to be allocated. AI: Added the following per 8/4 IPCDN reflector message from Dave Thaler. The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER Value ---------- ----------------------- pktcSigMib { mib-2 XXX } Editor's Note (to be removed prior to publication): the IANA is requested to assign a value for XXX under the mib-2 subtree and to record the assignment in the SMI Numbers registry. When the assignment has been made, the RFC Editor is asked to replace XXX (here and in the MIB module) with the assigned value and to remove this note. 11) authors' addresses: need cleanup (e.g., the first in the list uses normal US postal address format, but the last in the list doesn't.) AI: Changed. 12) Keywords: text references RFC 2119, but it is missing from the list of normative references. AI: Added normative reference: [RFC2119]. 13) formal language use: MIB compilation: smilint objects to pktcSigDevCodecType (an index of pktcSigDevCodecEntry) being read-only. It should be not-accessible. AI: Changed. 14) References: [PKT-SP-MGCP-IO9-040113] is never cited. [PKT-SP-PROV-IO8-040113] is never cited. [PKT-SP-CODEC-IO5-040113] is never cited. [PKT-SP-MIB-MTA-I08-040113] is never cited. [ETSI TS 101 909-9] is never cited. [TR 101 183] is never cited. [RFC3289], while referenced in the MIB module, is not cited in the text of the document. [RFC3291], while referenced in the MIB module, is never cited. [RFC3261] is never cited. [RFC3435] is never cited. MIB module IMPORTS from SNMP-FRAMEWORK-MIB, but it's missing from the normative references and not cited in text. AI: Deleted: [RFC3261], added normative references: [ITU-T-J169], [RFC3411]. Cited reference in introduction and overview sections. **************************************************** Part 2: **************************************************** 1) abbreviations expanded on first use: need to add expansions for: IPR LCD CRCX MDCX DSP SDP DOCSIS CODEC (also shows up as "codec" and "Codec") RTP FSK MAP rg rs cr "Blvd" needs a "." "Inc" needs a "." "Corp" needs a "." PCMU PCMA FQDN MIBMTA RSIP LCD CMS RJ "frequences" should be "frequencies" "playout" should be "play out" (where it is a verb rather than a noun) "dBm" also appears as "dbm" AI: Expanded abbreviations on first use. Fixed spelling. 2) two spaces after end of sentence: document needs to be fixed so that TWO spaces occur after "." at the end of a sentence. (2223bis 3.1 (7) AI: Fix in final formating. 3) Table of contents / order of sections: the sections of the document are not in the order specified by 2223bis section 4. AI: Fixed. Added Introduction. Reordered references after IANA section. Moved IPR after author's addresses. 4) Authors' Addresses and IPR Boilerplate (Full Copyright Statement) sections are supposed to NOT have numbers. AI: Changed. 5) On title page, an Author's name should be on a single line, as should his/her affiliation. 2223bis section 4.1 AI: Changed. 6) Document is inconsistant in the use of "a"/"an" before acronyms pronounced beginning with a vowel. (E.g. "MTA".) Suggest using "An" consistently. AI: Changed. 7) Document uses both "endpoint" and "Endpoint". Is a distinction intended? AI: Changed to lower case except at the start of a sentence. 8) "the widest range of marketplaces as is possible" -> "the widest possible range of markets" AI: Changed. 10) format of references: a) Author lists need a "," before the "and" if there are more than two authors. See the reference sections in 2223 bis for examples. b) If there is more than one author, an "and" is needed c) if there is more than one author, the last author's name is written as "F. Lastname" rather than "Lastname, F." AI: Changed formatting. **************************************************** Part 3 (1-13), Part 4 (14-30) **************************************************** 1) guidelines 3.2 para 1: need to describe relationship to other modules. for example, interfaces MIB since ifIndex is part of indexing scheme. AI: Added descriptive text to overview section. 2) guidelines 3.2 para 2: need to document in narrative MIB modules (other than SMIv2 docs) from which things are imported AI: Duplicate, see above. 3) guidelines 3.7.2: IANA considerations section needs to note that the mib-2 oid assignment for the module identity is needed AI: Duplicate, see part 1 # 10 above. 4) the module name and the module-identity descriptor don't follow the recommended practices in guidelines appendix C (second bullet) and other descriptors don't follow the recommended practices in the third and fifth bullets) (I assume TenthdBm is intended for re-use by other MIB modules) AI: Changed module identity descriptor to pktcIetfSigMib per appendix C bullet 2. 5) TenthdBm: "This data type" -> "This textual convention" AI: Changed. 6) PktcCodecType: "Textual Convention defines " -> "This textual convention defines" AI: Changed. 7) PktcCodecType: the ASN.1 comments aren't technically part of the TC. The descriptions of what the various enumerations should be given in the DESCRIPTION clause. (The ASN.1 comments don't hurt, but they're not enough.) AI: Changed. 8) PktcCodecType: the "MUST" is inappropriate. It sounds like the intent is to mandate how a registry would operate. Is the likelihood of additional values being added to this enumeration high enough to justify creating an IANA registry, rather than keeping the TC in this MIB module? AI: Changed. 9) (general) What are "international objects"? Does this term need to be defined? AI: The use of "international" is a legacy issue dating from initial MIB creation. 10) PktcRingCadence: is a "cadence period" the same thing as a "cadence cycle"? AI: Changed period to cycle. 11) PktcRingCadence: the sentence "Each bit after the third octet represents 50 ms and 1 represents ring and 0 represents silent." might be clearer if the first "represents" were replaced with "corresponds to", and if the first "and" were "where". ("silent" -> "silence" wouldn't hurt.) AI: Changed. 12) PktcRingCadence: are implementations required to enforce any constraints on the values of a) the bit count field, b) the repeatable field, c) the 3 on-off transition limit, d) values for bits beyond the bit count, e) an octet-string length other than the minimum required to encode whatever length is specified in the bit count field? AI: Open. A separate reflector thread has been started to solicit comments from IPCDN members on adding normative requirements. 13) PktcSigType: is any guidance needed on when to use reserved(2) and when to use other(1)? AI: Changed description. 14) pktcSigDevCodecComboIndex: where does the range constraint (1..255) come from? There's nothing in the document to justify that particular upper bound. AI: No change. See reflector discussion. 15) pktcSigDevCallerIdSigProtocol: the DESCRIPTION needs to spell out what is meant by each enumeration AI: Changed description. 16) pktcSigDev*Cadence: wouldn't it be simpler to put these ten objects into a table? just a thought.... AI: No change. 17) pktcSigDefMediaStreamDscp: There's no antecedant for "the new connection". Is "new connections" intended? AI: Added the following before sentence starting with "When" to provide context for "new connections": Any currently active connections are not affected by updates to this object. 18) pktcSignalingIndex: where does the range constraint (1..255) come from? There's nothing in the document to justify that particular upper bound. AI: No change. See reflector discussion. 19) pktcSigDefNcsReceiveUdpPort: where does the lower range constraint come from? AI: No change. IANA registers ports 0-1023 and port 1024 is indicated as reserved. 20) pktcSigPowerRingFrequency: for each of the enumeration values, the DESCRIPTION clause should spell out what that value means. AI: Changed description. 21) pktcSigPulseSignalType: should spell out what each enumeration value means in the DESCRIPTION. AI: Changed description to list enumerations. 22) pktcSigPulseSignalFrequency: does the "must" mean "MUST" in the sense that an attempt to write a value incompatible with the instance's pktcSigPulseSignalType must be rejected? What value does it take / can it be set to for "inapplicable" signal types? AI: Changed must to MUST. Added description for returning inconsistent value for an inapplicable signal type. 23) pktcSigPulseSignalDbLevel: What value does it take / can it be set to an inapplicable signal types? AI: Added description for returning inconsistent value for an inapplicable signal type. 24) pktcSigPulseSignalDuration: what happens when something attempts to set this to a value that doesn't fall on one of the increment boundaries, or on the wrong increment boundary for the specific signal type? AI: Added description for returning inconsistent value for incorrect increment for a signal type. 25) pktcSigPulseSignalPulseInterval: same questions. AI: Added description for returning inconsistent value for incorrect increment for a signal type. 26) pktcSigPulseSignalRepeatCount: "must" means "MUST", right? Same questions as (24) and (25). AI: Change must to MUST. Added description for returning inconsistent value for incorrect range. 27) pktcSigDevCIDFskAfterRing: how does one know whether a system is "international" or not? Is the table supposed to be of defaults? When "not used", what happens when one tries to get/set this object? AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. 28) pktcSigDevCIDFskAfterDTAS: same questions as (27) AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. 29) pktcSigDevCIDFskAfterRPAS: same questions as (27) For example, what happens when a system is not international but the pktcSigDevCIDMode is rpAsETS? AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. 30) pktcSigDevCIDRingAfterFSK: same as (27) AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. **************************************************** Part 5 (31-71) **************************************************** 31) pktcSigDevCIDRingAfterFSK: what is the purpose of the table in the DESCRIPTION? AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. 32) pktcSigDevCIDDTASAfterLR: explain what is meant by international, specify how it behaves for get/set on "non-international" systems, explain what the table in the DESCRIPTION is for, and specify what the "not used" behaviour is. AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. 33) pktcSigDevVmwiFskAfterDTAS: same as (32) AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. 34) pktcSigDevVmwiFskAfterRPAS: same as (32) AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. 35) pktcSigDevVmwiDTASAfterLR: same as (32) AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. 36) pktcSigDevRingCadenceTable: what is V5.2? V5.1 is mentioned elsewhere, but those references don't match this one. AI: Deleted "In V5.2" since E line package contained in 101 909-4, which defines the ring cadences is already noted in the description and references. 37) pktcSigDevRingCadenceTable and pktcSigDevRingCadenceIndex: The indexing should probably be 0..127, since that's how its done in the protocol. Adding an offset of 1 doesn't add value in this case, and it appears to increase the likelihood of confusion for the user. AI: Changed to 0 to 127 to match ETSI spec and updated description in associated table objects. 38) pktcSigDevRingCadenceTable: what is the lifecycle of entries in this table? When/How are they created and deleted? Do they persist across reboots or power failures? AI: No change. The description already indicates the objects do not persist across reboots. 39) pktcSigDevRingCadenceEntry: the DESCRIPTION is the one that belongs on pktcSigDevRingCadenceIndex. AI: Moved description. 40) pktcSigDevToneTable: the structure of this table is a bit awkward. It *might* make more sense if it were broken into two tables. The first, indexed by pktcSigDevToneType, would hold pktcSigDevToneDbLevel, pktcSigDevToneFreqType, pktcSigDevToneNumFrequencies, pktcSigDevToneWholeToneRepeatCount, pktcSigDevToneNumOnOffTimes, and pktcSigDevToneSteady. The second would be indexed by pktSigDevToneType and an Unsigned32 (1..4), collapsing pktcSigDevToneFirstFrequency, pktcSigDevToneSecondFrequency, pktcSigDevToneThirdFrequency, and pktcSigDevToneFourthFrequency into pktSigDevTonesFrequency, collapsing pktcSigDevToneFirstToneOn, pktcSigDevToneSecondToneOn, pktcSigDevToneThirdToneOn, and pktcSigDevToneFourthToneOn into pktcSigDevTonesOn, and collapsing pktcSigDevToneFirstToneOff, pktcSigDevToneSecondToneOff, pktcSigDevToneThirdToneOff, and pktcSigDevToneFourthToneOff into pktSigDevTonesOff. This is only a suggestion. AI: No change. 41) pktcSigDevToneTable: The DESCRIPTION says "Any definition of the tones callWaiting1-4 in this table should just contain the audible tone itself and NOT contain the delay between tones or the tone repeat count." In those cases, how will pktcSigDevToneWholeToneRepeatCount behave on get/set? AI: Changed. Added the following text to the description: If the pktcSigDevToneType is callWaiting1-4, the pktcSigDevToneWholeToneRepeatCount does not apply and MUST be ignored on SNMP set/get operations. 42) pktcSigDevToneEntry: the DESCRIPTION has the text that should be on pktcSigDevToneType. The phrase "that are being supported" appears to be at odds with the language in pktcSigDevToneTable that says "for each possible index, an entry MUST be defined". AI: Moved description. 43) pktcSigDevToneType: what is meant by "triggered"? This sounds at odds with the language in pktcSigDevToneTable that says "for each possible index, an entry MUST be defined". AI: Changed "triggered" to "used in". 44) pktcSigDevTone*Frequency: "could" seems odd in these four. Is this intended to mean that the device might do something else? AI: Changed "could be" to "are". 45) pktcSigDevTone*ToneOn and pktcSigDevTone*ToneOff: the DESCRIPTIONS are unclear. For example, does pktcSigDevFirstToneOn represent the length of time that the tone will be on, or does it represent the amount of time that must pass before the tone is turned on? For pktSigDevFirstToneOff, for example, does its value represent the length of time that the tone will be off, or does is represent the amount of time that must elapse after the tone is turned on before it is turned off, or does it represent the amount of time from the beginning of the cadence that must elapse before the tone is turned off? AI: Changed description. ToneOn = length of time tone is on. ToneOff = length of time tone is off. 46) pktcNcsEndPntConfigTable: there is something wrong with this sentence in the DESCRIPTION: "Each endpoint can be assigned to a its own CMS." AI: Deleted "a". 47) pktcNcsEndPntConfigEntry: punctuation in DESCRIPTION: "Entries in pktcNcsEndPntConfigTable ? Each entry" AI: Changed. 48) pktcNcsEndPntConfigCallAgentId: "it is highly recommended not to change this object's value through management station during normal operations." Do you mean "during normal operation, using SNMP to change this object's value is NOT RECOMMENDED" or "during normal operation, the use of management operations to change this object's value is NOT RECOMMENDED"? AI: Changed "through management station" to "using SNMP". 49) pktcNcsEndPntConfigCallAgentUdpPort: why the limited port range? Where did 2727 come from? AI: No change. Duplicate, see above. 2727 is the IANA default for the MGCP CA port: mgcp-callagent 2727/tcp Media Gateway Control Protocol Call Agent mgcp-callagent 2727/udp Media Gateway Control Protocol Call Agent 50) pktcNcsEndPntConfigCallAgentUdpPort: "it is highly recommended not to change this object's value through management station during normal operations." Do you mean "during normal operation, using SNMP to change this object's value is NOT RECOMMENDED" or "during normal operation, the use of management operations to change this object's value is NOT RECOMMENDED"? AI: Changed "through management station" to "using SNMP". 51) pktcNcsEndPntConfigPartialDialTO: "contains maximum" -> "contains the maximum" (The description and the descriptor make it sound like the device may use any timeout value, as long as that timeout value is less than this object's value. Is that really the intent? Compare the DESCRIPTIONs of this, pktcNcsEndPntConfigBusyToneTO, and pktcNcsEndPntConfigCriticalDialTO. AI: Added "the". Remainder of comment is unclear. 52) pktcNcsEndPntConfigTSMax: "max" -> "maximum" It's not clear from the description what this object controls. It defines a period that is bounded on one end by "the sending of the initial datagram" (whatever that is) but does not say what event is at the other end of the interval. AI: Changed max to maximum. Changed description per PC NCS spec. 53) pktcNcsEndPntConfigMax1: the description says this is a threshold, but doesn't say what object or delta/interval it is compared to, and doesn't say what happens when the threshold is crossed. AI: Changed description. Max1 is defined in the PC MGCP spec. 54) pktcNcsEndPntConfigMax2: same as (53) AI: Changed description. Max2 is defined in the PC MGCP spec. 55) pktcNcsEndPntConfigMax1QEnable: the description is unclear. Where is timer Max1 defined? The only other Max1 in this document is a threshold, rather than a timer. Also, there is an ambiguity in the sentence. It can be read to mean "when Max1 expires, this object will enable or disable the query operation" as well as to mean "the query operation initiated whenever Max1 expires is enabled/disabled by this object." AI: Changed description to refer to thresholds. Max1 and Max2 are thresholds defined in the PC MGCP spec. 56) pktcNcsEndPntConfigMax2QEnable: same as (55) AI: Changed description to refer to thresholds. See above (55). 57) pktcNcsEndPntConfigMWD: the first and second sentences of the description don't work well together. Taken together, they say the MTA will restart every MWD seconds (or less). This is probably not what is intended. AI: Changed description to refer to initial power on and restart procedure per the PC NCS spec. 58) pktcNcsEndPntConfigTdinit: same problem as (57) Could be fixed by changing "after" to "before", but I'm not sure that's what was intended. AI: Changed description to refer to initiating the disconnect procedure with the call agent per PC NCS spec. 59) pktcNcsEndPntConfigTdmin, pktcNcsEndPntConfigTdmax, and pktcNcsEndPntConfigTdinit don't work well together. As currently written, the disconnected procedure will be initiated three times, once for each of these three timers. Furthermore, are there any constraints on their relative values? For example, is it OK to set pktcNcsEndPntConfigTdmin to a value larger than that of pktcNcsEndPntConfigTdmax? AI: No change. These values and their relationships are defined in detail in the PC NCS spec. 60) pktcNcsEndPntConfigRtoMax / pktcNcsEndPntConfigRtoInit: is there any relationship between these two objects? Why do they have different units? AI: No change. MGCP uses exponentially increasing timers for retransmission. RTO init is the configured initial retransmission timer value in milliseconds (per PC MGCP 4.4.2). 61) pktcNcsEndPntConfigStatus: RFC 2579 (page 8, "NOTE WELL") requires any use of RowStatus to specify whether columns may be modified when the row is active, and (page 17) under what circumstance it should/may be taken out of service. See MIB review guidelines section 4.6.4 for details. AI: Open. Issue posted to the PC NCS/PROV reflector for input. 63) pktcNcsEndPntStatusError: the DESCRIPTION says "Otherwise, the state is unused." Is "state" the same thing as "status" in the rest of the DESCRIPTION? What value does this object have when it is "unused"? AI: Replaced "Othewise the state is unused." with "If pktcMtaDevCmsIpsecCtrl is disabled for the associated Call Agent, the noSecurityAssociation status is not applicable and should not be used by the MTA." 64) pktcNcsEndPntStatusError: suggest changing "Otherwise, pktcMtaDevCmsIpsecCtrl is enabled," -> "Otherwise, when pktcMtaDevCmsIpsecCtrl is enabled," AI: Changed. 65) pktcNcsEndPntConfigMinHookFlash, pktcNcsEndPntConfigMaxHookFlash: are there any constraints on the relationship of the values of these two? AI: Changed description to indicate the max hook flash must be greater than min hook flash. 66) pktcNcsEndPntConfigMinHookFlash, pktcNcsEndPntConfigMaxHookFlash, etc.: "This object must only be set via the configuration file during the provisioning process." Is this intended to prohibit provisioning by means other than a configuration file? AI: Yes. 67) pktcNcsEndPntConfigPulseDialMinMakeTime, pktcNcsEndPntConfigPulseDialMaxMakeTime, pktcNcsEndPntConfigPulseDialMinBreakTime, pktcNcsEndPntConfigPulseDialMaxBreakTime, and pktcNcsEndPntConfigPulseDialInterdigitTime: constraints with respect to each other? with respect to Hook Flash? AI: Changed descriptions to indicate the max must be greater than min. No formal relationship between min/max make/break. Hook flash is generally longer duration than dial pulse but there is no formal spec. 68) Problems in object descriptors (review guidelines AI: No change. Comment about object descriptors is not clear. 69) MIB review guidelines appendix C. These are only *suggested* naming conventions, but they're worth considering, especially since the current draft is mostly consistant. Current aberrations that I noticed: PKTC-IETF-SIG-MIB DEFINITIONS ::= BEGIN but pktcSigMib MODULE-IDENTITY pktcSigMib MODULE-IDENTITY and PktcSigType ::= TEXTUAL-CONVENTION but PktcCodecType ::= TEXTUAL-CONVENTION PktcRingCadence ::= TEXTUAL-CONVENTION (Assuming TenthdBm ::= TEXTUAL-CONVENTION is intended for external use.) pktcSigMib MODULE-IDENTITY and pktcSigMibObjects OBJECT IDENTIFIER ::= { pktcSigMib 1 } pktcSigDevConfigObjects OBJECT IDENTIFIER ::= pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 0 } pktcSigConformance OBJECT IDENTIFIER ::= { pktcSigMib 2 } pktcSigCompliances OBJECT IDENTIFIER ::= { pktcSigConformance 1 } pktcSigGroups OBJECT IDENTIFIER ::= { pktcSigConformance 2 } but pktcNcsEndPntConfigObjects OBJECT IDENTIFIER ::= pktcSigCapabilityEntry OBJECT-TYPE but pktcSignalingIndex Unsigned32, pktcSignalingType PktcSigType, pktcSignalingVersion SnmpAdminString, pktcSignalingVendorExtension SnmpAdminString pktcSigMib MODULE-IDENTITY but pktcNcsEndPntConfigTable OBJECT-TYPE and pktcNcsEndPntConfigCallAgentId SnmpAdminString, pktcNcsEndPntConfigCallAgentUdpPort InetPortNumber, pktcNcsEndPntConfigPartialDialTO Unsigned32, pktcNcsEndPntConfigCriticalDialTO Unsigned32, pktcNcsEndPntConfigBusyToneTO Unsigned32, pktcNcsEndPntConfigDialToneTO Unsigned32, pktcNcsEndPntConfigMessageWaitingTO Unsigned32, pktcNcsEndPntConfigOffHookWarnToneTO Unsigned32, pktcNcsEndPntConfigRingingTO Unsigned32, pktcNcsEndPntConfigRingBackTO Unsigned32, pktcNcsEndPntConfigReorderToneTO Unsigned32, pktcNcsEndPntConfigStutterDialToneTO Unsigned32, pktcNcsEndPntConfigTSMax Unsigned32, pktcNcsEndPntConfigMax1 Unsigned32, pktcNcsEndPntConfigMax2 Unsigned32, pktcNcsEndPntConfigMax1QEnable TruthValue, pktcNcsEndPntConfigMax2QEnable TruthValue, pktcNcsEndPntConfigMWD Unsigned32, pktcNcsEndPntConfigTdinit Unsigned32, pktcNcsEndPntConfigTdmin Unsigned32, pktcNcsEndPntConfigTdmax Unsigned32, pktcNcsEndPntConfigRtoMax Unsigned32, pktcNcsEndPntConfigRtoInit Unsigned32, pktcNcsEndPntConfigLongDurationKeepAlive Unsigned32, pktcNcsEndPntConfigThist Unsigned32, pktcNcsEndPntConfigStatus RowStatus, pktcNcsEndPntConfigCallWaitingMaxRep Unsigned32, pktcNcsEndPntConfigCallWaitingDelay Unsigned32, pktcNcsEndPntStatusCallIpAddressType InetAddressType, pktcNcsEndPntStatusCallIpAddress InetAddress, pktcNcsEndPntStatusError INTEGER, pktcNcsEndPntConfigMinHookFlash Unsigned32, pktcNcsEndPntConfigMaxHookFlash Unsigned32, pktcNcsEndPntConfigPulseDialInterdigitTime Unsigned32, pktcNcsEndPntConfigPulseDialMinMakeTime Unsigned32, pktcNcsEndPntConfigPulseDialMaxMakeTime Unsigned32, pktcNcsEndPntConfigPulseDialMinBreakTime Unsigned32, pktcNcsEndPntConfigPulseDialMaxBreakTime Unsigned32 AI: Changed MIB module name to pktcIetfSigMib. No other name changes made. 70) MIB review guidelines section 3.2 second paragraph AI: Duplicate, see above. Overview section changed to include narrative on MIB modules. 71) MIB review guidelines section 3.7.2 AI: Duplicate, see above. IANA section added. **************************************************** Reflector Comments **************************************************** 1. Changed default value of pktcNcsEndPntConfigMaxHookFlash from 500 to 800. 2. Added text to description to indicate wholetonerepeatcount and pktcSigDevToneSteady do not override the duration in an associated timeout (TO) object. **************************************************** Other **************************************************** Added ilbc and bv16 to PktcCodecType. Gordon Beacham Motorola, Inc. ------_=_NextPart_001_01C491EE.C81B7C68 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NTgiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BB TiBjbGFzcz0yNDcyMTExMTktMDMwOTIwMDQ+UmVzcG9uc2VzIHRvIA0KY29tbWVudHMgb248L1NQ QU4+Jm5ic3A7PFNQQU4gY2xhc3M9MjQ3MjExMTE5LTAzMDkyMDA0PklFVEYgPC9TUEFOPlNpZyBN SUIgZHJhZnQgDQo1PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKjxCUj5QYXJ0IA0KMTo8QlI+KioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj4xKSBsaW5lcyBsaW1pdGVkIHRvIDcyIGNoYXJhY3RlcnM6PEJSPnRyYWls aW5nIA0KYmxhbmtzIG1ha2UgbGluZSAyNiB0b28gbG9uZyAoNzMgY2hhcmFjdGVycyk8QlI+dHJh aWxpbmcgYmxhbmtzIG1ha2UgbGluZSA5OSB0b28gDQpsb25nICg3MyBjaGFyYWN0ZXJzKTxCUj50 cmFpbGluZyBibGFua3MgbWFrZSBsaW5lIDIyMDYgdG9vIGxvbmcgKDczIGNoYXJhY3RlcnMpIA0K dHJhaWxpbmcgYmxhbmtzIG1ha2UgbGluZSAyMjI2IHRvbyBsb25nICg3MyBjaGFyYWN0ZXJzKSB0 cmFpbGluZyBibGFua3MgbWFrZSANCmxpbmUgMjI0MCB0b28gbG9uZyAoNzMgY2hhcmFjdGVycykg dHJhaWxpbmcgYmxhbmtzIG1ha2UgbGluZSAyMzAxIHRvbyBsb25nICg3MyANCmNoYXJhY3RlcnMp PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+QUk6IEZpeCBpbiBmaW5hbCBmb3JtYXRpbmcuPC9GT05UPjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Mikgc29tZSBwYWdlcyBoYXZl IG1vcmUgdGhhbiA1OCBsaW5lczwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBGaXggaW4gZmluYWwgZm9ybWF0aW5nLjwvRk9O VD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PjMpIHBhZ2VzIG5vdCBzZXBhcmF0ZWQgYnkgRkYgY2hhcmFjdGVyPC9GT05UPjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IEZpeCBpbiBm aW5hbCBmb3JtYXRpbmcuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+NCkgdGhlIHdvcmRzICJJTlRFUk5FVC1EUkFGVCIgc2hvdWxk IGJlIGluIHVwcGVyIA0KbGVmdDxCUj5jb3JuZXIgb2YgZmlyc3QgcGFnZTwvRk9OVD48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBDaGFu Z2VkLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPjUpIElQUiBCb2lsZXJwbGF0ZTogT0ssIGJ1dCBub3RlIHRoYXQgYWx0ZXJuYXRp dmUgDQp3b3JkaW5nIGZvciAicGx1cmFsIiBhdXRob3JzIGhhcyBiZWVuIHByZXNlbnRlZCBvbiB0 aGUgd2djaGFpcnMgDQpsaXN0OjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZuYnNwOyZuYnNwOyBCeSBzdWJtaXR0aW5nIHRoaXMg SW50ZXJuZXQtRHJhZnQsIA0KZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueTxCUj4mbmJz cDsmbmJzcDsgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIA0KY2xhaW1zIG9mIHdoaWNo IGhlIG9yIHNoZSBpcyBhd2FyZTxCUj4mbmJzcDsmbmJzcDsgaGF2ZSBiZWVuIG9yIHdpbGwgYmUg DQpkaXNjbG9zZWQsIGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXM8QlI+Jm5ic3A7 Jm5ic3A7IGF3YXJlIHdpbGwgYmUgDQpkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0 aW9uIDYgb2YgUkZDIDM2NjguPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IENoYW5nZWQuPC9GT05UPjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+NikgSW50ZXJuZXQtRHJh ZnQgYm9pbGVycGxhdGU6IHRleHQgaXMgT0ssIGJ1dCANCmZvcm1hdHRpbmcgaXMgc3RyYW5nZS48 L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj5ObyBjaGFuZ2UuIE5vdCBjbGVhciB3aGF0IGlzIA0KInN0cmFuZ2UiLjwvRk9OVD48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjcpIEZp bGVuYW1lOiBicm9rZW4gYnkgc3RyYW5nZSBmb3JtYXR0aW5nIG9uIGZpcnN0IA0KcGFnZTwvRk9O VD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PkFJOiBDaGFuZ2VkLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPjgpIGF1dGhvciBsaXN0OiBwcmVzZW50LCBidXQgDQptYWwtZm9y bWF0dGVkPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+QUk6IEZpeGVkIGZvcm1hdHRpbmcuPC9GT05UPjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+OSkgSW50cm9kdWN0aW9uOiBt aXNzaW5nLiZuYnNwOyAoMi4yIA0KIzUpPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IEFkZGVkIEludHJvZHVjdGlvbiBzZWN0 aW9uLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPjEwKSBJQU5BIGNvbnNpZGVyYXRpb25zOiZuYnNwOyBjb250cmFkaWN0b3J5LCAo Mi4yIA0KIzdiKSBzZWVtcyB0byBhcHBseSwgc2luY2UgYW4gT0lEIG5lZWRzIHRvIGJlIGFsbG9j YXRlZC48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj5BSTogQWRkZWQgdGhlIGZvbGxvd2luZyBwZXIgOC80IElQQ0ROIHJlZmxlY3Rv ciANCm1lc3NhZ2UgZnJvbSBEYXZlIFRoYWxlci48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5UaGUgTUlCIG1vZHVsZSBpbiB0aGlz IGRvY3VtZW50IHVzZXMgdGhlIGZvbGxvd2luZyANCklBTkEtYXNzaWduZWQgT0JKRUNUIElERU5U SUZJRVIgdmFsdWVzPEJSPnJlY29yZGVkIGluIHRoZSBTTUkgTnVtYmVycyANCnJlZ2lzdHJ5Ojwv Rk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPkRlc2NyaXB0b3ImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT0JKRUNUIA0KSURFTlRJRklF UiBWYWx1ZTxCUj4tLS0tLS0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08QlI+cGt0Y1NpZ01pYiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB7IG1p Yi0yIFhYWCANCn08L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj5FZGl0b3IncyBOb3RlICh0byBiZSByZW1vdmVkIHByaW9yIHRvIHB1 YmxpY2F0aW9uKTogDQp0aGUgSUFOQSBpcyByZXF1ZXN0ZWQgdG8gYXNzaWduIGEgdmFsdWU8QlI+ Zm9yIFhYWCB1bmRlciB0aGUgbWliLTIgc3VidHJlZSBhbmQgDQp0byByZWNvcmQgdGhlIGFzc2ln bm1lbnQgaW4gdGhlIFNNSSBOdW1iZXJzIHJlZ2lzdHJ5LjxCUj5XaGVuIHRoZSBhc3NpZ25tZW50 IGhhcyANCmJlZW4gbWFkZSwgdGhlIFJGQyBFZGl0b3IgaXMgYXNrZWQgdG8gcmVwbGFjZSBYWFgg KGhlcmUgYW5kIGluIHRoZTxCUj5NSUIgDQptb2R1bGUpIHdpdGggdGhlIGFzc2lnbmVkIHZhbHVl IGFuZCB0byByZW1vdmUgdGhpcyBub3RlLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjExKSBhdXRob3JzJyBhZGRyZXNzZXM6IG5l ZWQgY2xlYW51cDxCUj4oZS5nLiwgdGhlIA0KZmlyc3QgaW4gdGhlIGxpc3QgdXNlcyBub3JtYWwg VVMgcG9zdGFsPEJSPmFkZHJlc3MgZm9ybWF0LCBidXQgdGhlIGxhc3QgaW4gdGhlIA0KbGlzdCBk b2Vzbid0Lik8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj5BSTogQ2hhbmdlZC48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4xMikgS2V5d29yZHM6IHRleHQgcmVmZXJl bmNlcyBSRkMgMjExOSwgYnV0IGl0IGlzIA0KbWlzc2luZyBmcm9tIHRoZSBsaXN0IG9mIG5vcm1h dGl2ZSByZWZlcmVuY2VzLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBBZGRlZCBub3JtYXRpdmUgcmVmZXJlbmNlOiANCltS RkMyMTE5XS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj4xMykgZm9ybWFsIGxhbmd1YWdlIHVzZTogTUlCIGNvbXBpbGF0aW9uOiBz bWlsaW50IA0Kb2JqZWN0cyB0byBwa3RjU2lnRGV2Q29kZWNUeXBlIChhbiBpbmRleCBvZiBwa3Rj U2lnRGV2Q29kZWNFbnRyeSkgYmVpbmcgDQpyZWFkLW9ubHkuJm5ic3A7IEl0IHNob3VsZCBiZSBu b3QtYWNjZXNzaWJsZS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogQ2hhbmdlZC48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4xNCkgUmVmZXJlbmNlczo8QlI+ Jm5ic3A7Jm5ic3A7IA0KW1BLVC1TUC1NR0NQLUlPOS0wNDAxMTNdIGlzIG5ldmVyIGNpdGVkLiZu YnNwOyZuYnNwOyA8QlI+Jm5ic3A7Jm5ic3A7IA0KW1BLVC1TUC1QUk9WLUlPOC0wNDAxMTNdIGlz IG5ldmVyIGNpdGVkLiZuYnNwOyZuYnNwOyA8QlI+Jm5ic3A7Jm5ic3A7IA0KW1BLVC1TUC1DT0RF Qy1JTzUtMDQwMTEzXSBpcyBuZXZlciBjaXRlZC4mbmJzcDsgPEJSPiZuYnNwOyZuYnNwOyANCltQ S1QtU1AtTUlCLU1UQS1JMDgtMDQwMTEzXSBpcyBuZXZlciBjaXRlZC4mbmJzcDsgPEJSPiZuYnNw OyZuYnNwOyBbRVRTSSBUUyAxMDEgDQo5MDktOV0gaXMgbmV2ZXIgY2l0ZWQuJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPEJSPiZuYnNwOyZuYnNwOyBbVFIgMTAx IDE4M10gaXMgbmV2ZXIgDQpjaXRlZC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8QlI+ Jm5ic3A7Jm5ic3A7IFtSRkMzMjg5XSwgd2hpbGUgcmVmZXJlbmNlZCBpbiB0aGUgTUlCIG1vZHVs ZSwgaXMgDQpub3Q8QlI+Jm5ic3A7Jm5ic3A7IGNpdGVkIGluIHRoZSB0ZXh0IG9mIHRoZSANCmRv Y3VtZW50LiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8QlI+Jm5ic3A7Jm5ic3A7IA0KW1JGQzMyOTFdLCB3aGlsZSByZWZlcmVuY2VkIGluIHRo ZSBNSUIgbW9kdWxlLCBpcyBuZXZlciBjaXRlZC48QlI+Jm5ic3A7Jm5ic3A7IA0KW1JGQzMyNjFd IGlzIG5ldmVyIA0KY2l0ZWQuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KPEJSPiZuYnNwOyZuYnNwOyBbUkZDMzQzNV0gaXMgbmV2ZXIgDQpjaXRlZC4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8QlI+Jm5ic3A7Jm5i c3A7IE1JQiBtb2R1bGUgSU1QT1JUUyBmcm9tIFNOTVAtRlJBTUVXT1JLLU1JQiwgYnV0IA0KaXQn czxCUj4mbmJzcDsmbmJzcDsgbWlzc2luZyBmcm9tIHRoZSBub3JtYXRpdmUgcmVmZXJlbmNlcyBh bmQgbm90IGNpdGVkIGluIA0KdGV4dC4gPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IERlbGV0ZWQ6IFtSRkMzMjYxXSwgYWRk ZWQgbm9ybWF0aXZlIHJlZmVyZW5jZXM6IA0KW0lUVS1ULUoxNjldLCBbUkZDMzQxMV0uIENpdGVk IHJlZmVyZW5jZSBpbiBpbnRyb2R1Y3Rpb24gYW5kIG92ZXJ2aWV3IA0Kc2VjdGlvbnMuPC9GT05U PjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9 Mj4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPEJS PlBhcnQgDQoyOjxCUj4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbCBzaXplPTI+MSkgYWJicmV2aWF0aW9ucyBleHBhbmRlZCBvbiBmaXJzdCB1c2U6IG5l ZWQgdG8gYWRkIA0KZXhwYW5zaW9ucyBmb3I6PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBJUFI8QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KTENEPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBDUkNYPEJSPiZu YnNwOyZuYnNwOyZuYnNwOyBNRENYPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyANCkRTUDxCUj4mbmJz cDsmbmJzcDsmbmJzcDsgU0RQPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBET0NTSVM8QlI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0KQ09ERUMgKGFsc28gc2hvd3MgdXAgYXMgImNvZGVjIiBhbmQgIkNvZGVj Iik8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KUlRQPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBGU0s8 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1BUDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgDQpyZzxCUj4m bmJzcDsmbmJzcDsmbmJzcDsgcnM8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNyPEJSPiZuYnNwOyZu YnNwOyZuYnNwOyANCiJCbHZkIiBuZWVkcyBhICIuIjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgIklu YyIgbmVlZHMgYSAiLiIgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJDb3JwIiBuZWVkcyBhICIu IjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgDQpQQ01VPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBQQ01B PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBGUUROPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyANCk1JQk1U QTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgUlNJUDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgDQpMQ0Q8 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IENNUzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgUko8L0ZPTlQ+ PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4i ZnJlcXVlbmNlcyIgc2hvdWxkIGJlICJmcmVxdWVuY2llcyI8QlI+InBsYXlvdXQiIA0Kc2hvdWxk IGJlICJwbGF5IG91dCIgKHdoZXJlIGl0IGlzIGEgdmVyYiByYXRoZXIgdGhhbiBhIG5vdW4pICJk Qm0iIGFsc28gYXBwZWFycyANCmFzICJkYm0iPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IEV4cGFuZGVkIGFiYnJldmlhdGlv bnMgb24gZmlyc3QgdXNlLiBGaXhlZCANCnNwZWxsaW5nLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjIpIHR3byBzcGFjZXMgYWZ0 ZXIgZW5kIG9mIHNlbnRlbmNlOiBkb2N1bWVudCBuZWVkcyANCnRvIGJlIGZpeGVkIHNvIHRoYXQg VFdPIHNwYWNlcyBvY2N1ciBhZnRlciAiLiIgYXQgdGhlIGVuZCBvZiBhIHNlbnRlbmNlLiANCigy MjIzYmlzIDMuMSAoNyk8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogRml4IGluIGZpbmFsIGZvcm1hdGluZy48L0ZPTlQ+PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4zKSZu YnNwOyBUYWJsZSBvZiBjb250ZW50cyAvIG9yZGVyIG9mIA0Kc2VjdGlvbnM6Jm5ic3A7IHRoZSBz ZWN0aW9ucyBvZiB0aGUgZG9jdW1lbnQgYXJlIG5vdCBpbiB0aGUgb3JkZXIgc3BlY2lmaWVkIGJ5 IA0KMjIyM2JpcyBzZWN0aW9uIDQuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IEZpeGVkLiBBZGRlZCBJbnRyb2R1Y3Rpb24u IFJlb3JkZXJlZCByZWZlcmVuY2VzIA0KYWZ0ZXIgSUFOQSBzZWN0aW9uLiBNb3ZlZCBJUFIgYWZ0 ZXIgYXV0aG9yJ3MgYWRkcmVzc2VzLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjQpIEF1dGhvcnMnIEFkZHJlc3NlcyBhbmQgSVBS IEJvaWxlcnBsYXRlIChGdWxsIA0KQ29weXJpZ2h0IFN0YXRlbWVudCkgc2VjdGlvbnMgYXJlIHN1 cHBvc2VkIHRvIE5PVCBoYXZlIG51bWJlcnMuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IENoYW5nZWQuPC9GT05UPjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+NSkgT24g dGl0bGUgcGFnZSwgYW4gQXV0aG9yJ3MgbmFtZSBzaG91bGQgYmUgb24gYSANCnNpbmdsZSBsaW5l LCBhcyBzaG91bGQgaGlzL2hlciBhZmZpbGlhdGlvbi4mbmJzcDsgMjIyM2JpcyBzZWN0aW9uIA0K NC4xPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+QUk6IENoYW5nZWQuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+NikgRG9jdW1lbnQgaXMgaW5jb25zaXN0YW50IGlu IHRoZSB1c2Ugb2YgImEiLyJhbiIgDQpiZWZvcmUgYWNyb255bXMgcHJvbm91bmNlZCBiZWdpbm5p bmcgd2l0aCBhIHZvd2VsLiZuYnNwOyAoRS5nLiAiTVRBIi4pJm5ic3A7IA0KU3VnZ2VzdCB1c2lu ZyAiQW4iIGNvbnNpc3RlbnRseS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogQ2hhbmdlZC48L0ZPTlQ+PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj43KSBEb2N1bWVudCB1 c2VzIGJvdGggImVuZHBvaW50IiBhbmQgDQoiRW5kcG9pbnQiLiZuYnNwOyBJcyBhIGRpc3RpbmN0 aW9uIGludGVuZGVkPzwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBDaGFuZ2VkIHRvIGxvd2VyIGNhc2UgZXhjZXB0IGF0IHRo ZSBzdGFydCBvZiBhIA0Kc2VudGVuY2UuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+OCkgInRoZSB3aWRlc3QgcmFuZ2Ugb2YgbWFy a2V0cGxhY2VzIGFzIGlzIA0KcG9zc2libGUiJm5ic3A7IC0mZ3Q7PEJSPiZuYnNwOyZuYnNwOyZu YnNwOyAidGhlIHdpZGVzdCBwb3NzaWJsZSByYW5nZSBvZiANCm1hcmtldHMiPC9GT05UPjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IENo YW5nZWQuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+MTApIGZvcm1hdCBvZiByZWZlcmVuY2VzOiZuYnNwOyA8QlI+Jm5ic3A7Jm5i c3A7IGEpIA0KQXV0aG9yIGxpc3RzIG5lZWQgYSAiLCIgYmVmb3JlIHRoZSAiYW5kIiANCmlmPEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGVyZSBhcmUgbW9yZSB0aGFu IHR3byANCmF1dGhvcnMuJm5ic3A7IFNlZSB0aGUgcmVmZXJlbmNlIHNlY3Rpb25zIGluIDIyMjMg DQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJpcyBmb3IgZXhhbXBs ZXMuPEJSPiZuYnNwOyZuYnNwOyBiKSBJZiANCnRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgYXV0aG9y LCBhbiAiYW5kIiBpcyBuZWVkZWQ8QlI+Jm5ic3A7Jm5ic3A7IGMpIGlmIHRoZXJlIGlzIA0KbW9y ZSB0aGFuIG9uZSBhdXRob3IsIHRoZSBsYXN0IGF1dGhvcidzIG5hbWUgDQppczxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd3JpdHRlbiBhcyAiRi4gTGFzdG5hbWUiIHJh dGhlciB0aGFuIA0KIkxhc3RuYW1lLCBGLiI8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogQ2hhbmdlZCBmb3JtYXR0aW5nLjwv Rk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgDQpz aXplPTI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KjxCUj5QYXJ0IDMgKDEtMTMpLCANClBhcnQgNCANCigxNC0zMCk8QlI+KioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjEpIGd1aWRlbGluZXMg My4yIHBhcmEgMTogbmVlZCB0byBkZXNjcmliZSANCnJlbGF0aW9uc2hpcCB0byBvdGhlciBtb2R1 bGVzLiBmb3IgZXhhbXBsZSwgaW50ZXJmYWNlcyBNSUIgc2luY2UgaWZJbmRleCBpcyBwYXJ0IA0K b2YgaW5kZXhpbmcgc2NoZW1lLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBBZGRlZCBkZXNjcmlwdGl2ZSB0ZXh0IHRvIG92 ZXJ2aWV3IA0Kc2VjdGlvbi48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4yKSBndWlkZWxpbmVzIDMuMiBwYXJhIDI6IG5lZWQgdG8g ZG9jdW1lbnQgaW4gDQpuYXJyYXRpdmUgTUlCIG1vZHVsZXMgKG90aGVyIHRoYW4gU01JdjIgZG9j cykgZnJvbSB3aGljaCB0aGluZ3MgYXJlIA0KaW1wb3J0ZWQ8L0ZPTlQ+PC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogRHVwbGljYXRlLCBz ZWUgYWJvdmUuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbCBzaXplPTI+MykgZ3VpZGVsaW5lcyAzLjcuMjogSUFOQSBjb25zaWRlcmF0aW9ucyBz ZWN0aW9uIA0KbmVlZHMgdG8gbm90ZSB0aGF0IHRoZSBtaWItMiBvaWQgYXNzaWdubWVudCBmb3Ig dGhlIG1vZHVsZSBpZGVudGl0eSBpcyANCm5lZWRlZDwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBEdXBsaWNhdGUsIHNlZSBw YXJ0IDEgIyAxMCBhYm92ZS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj40KSB0aGUgbW9kdWxlIG5hbWUgYW5kIHRoZSBtb2R1bGUt aWRlbnRpdHkgDQpkZXNjcmlwdG9yIGRvbid0IGZvbGxvdyB0aGUgcmVjb21tZW5kZWQgcHJhY3Rp Y2VzIGluIGd1aWRlbGluZXMgYXBwZW5kaXggQyANCihzZWNvbmQgYnVsbGV0KSBhbmQgb3RoZXIg ZGVzY3JpcHRvcnMgZG9uJ3QgZm9sbG93IHRoZSByZWNvbW1lbmRlZCBwcmFjdGljZXMgaW4gDQp0 aGUgdGhpcmQgYW5kIGZpZnRoIGJ1bGxldHMpJm5ic3A7IChJIGFzc3VtZSBUZW50aGRCbSBpcyBp bnRlbmRlZCBmb3IgcmUtdXNlIGJ5IA0Kb3RoZXIgTUlCIG1vZHVsZXMpPC9GT05UPjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IENoYW5n ZWQgbW9kdWxlIGlkZW50aXR5IGRlc2NyaXB0b3IgdG8gDQpwa3RjSWV0ZlNpZ01pYiBwZXIgYXBw ZW5kaXggQyBidWxsZXQgMi48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj41KSBUZW50aGRCbTogIlRoaXMgZGF0YSB0eXBlIiAtJmd0 OyAiVGhpcyB0ZXh0dWFsIA0KY29udmVudGlvbiI8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogQ2hhbmdlZC48L0ZPTlQ+PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj42KSBQ a3RjQ29kZWNUeXBlOiAiVGV4dHVhbCBDb252ZW50aW9uIGRlZmluZXMgIiANCi0mZ3Q7ICJUaGlz IHRleHR1YWwgY29udmVudGlvbiBkZWZpbmVzIjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBDaGFuZ2VkLjwvRk9OVD48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjcpIFBr dGNDb2RlY1R5cGU6IHRoZSBBU04uMSBjb21tZW50cyBhcmVuJ3QgDQp0ZWNobmljYWxseSBwYXJ0 IG9mIHRoZSBUQy4mbmJzcDsgVGhlIGRlc2NyaXB0aW9ucyBvZiB3aGF0IHRoZSB2YXJpb3VzIA0K ZW51bWVyYXRpb25zIHNob3VsZCBiZSBnaXZlbiBpbiB0aGUgREVTQ1JJUFRJT04gY2xhdXNlLiZu YnNwOyAoVGhlIEFTTi4xIA0KY29tbWVudHMgZG9uJ3QgaHVydCwgYnV0IHRoZXkncmUgbm90IGVu b3VnaC4pPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+QUk6IENoYW5nZWQuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+OCkgUGt0Y0NvZGVjVHlwZTogdGhlICJNVVNU IiBpcyANCmluYXBwcm9wcmlhdGUuJm5ic3A7IEl0IHNvdW5kcyBsaWtlIHRoZSBpbnRlbnQgaXMg dG8gbWFuZGF0ZSBob3cgYSByZWdpc3RyeSANCndvdWxkIG9wZXJhdGUuJm5ic3A7IElzIHRoZSBs aWtlbGlob29kIG9mIGFkZGl0aW9uYWwgdmFsdWVzIGJlaW5nIGFkZGVkIHRvIHRoaXMgDQplbnVt ZXJhdGlvbiBoaWdoIGVub3VnaCB0byBqdXN0aWZ5IGNyZWF0aW5nIGFuIElBTkEgcmVnaXN0cnks IHJhdGhlciB0aGFuIA0Ka2VlcGluZyB0aGUgVEMgaW4gdGhpcyBNSUIgbW9kdWxlPzwvRk9OVD48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJ OiBDaGFuZ2VkLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPjkpIChnZW5lcmFsKSBXaGF0IGFyZSAiaW50ZXJuYXRpb25hbCBvYmpl Y3RzIj8gRG9lcyANCnRoaXMgdGVybSBuZWVkIHRvIGJlIGRlZmluZWQ/PC9GT05UPjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IFRoZSB1 c2Ugb2YgImludGVybmF0aW9uYWwiIGlzIGEgbGVnYWN5IGlzc3VlIA0KZGF0aW5nIGZyb20gaW5p dGlhbCBNSUIgY3JlYXRpb24uPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+MTApIFBrdGNSaW5nQ2FkZW5jZTogaXMgYSAiY2FkZW5j ZSBwZXJpb2QiIHRoZSBzYW1lIA0KdGhpbmcgYXMgYSAiY2FkZW5jZSBjeWNsZSI/PC9GT05UPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6 IENoYW5nZWQgcGVyaW9kIHRvIGN5Y2xlLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj4xMSkgUGt0Y1JpbmdDYWRlbmNlOiB0aGUgc2VudGVuY2UgIkVhY2ggYml0IA0KPEJSPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANCmFmdGVyIHRoZSB0aGlyZCBvY3RldCByZXByZXNlbnRzIDUwIG1zIGFu ZCAxIHJlcHJlc2VudHMgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KcmluZyBhbmQgMCByZXByZXNl bnRzIHNpbGVudC4iIG1pZ2h0IGJlIGNsZWFyZXIgaWYgdGhlIGZpcnN0ICJyZXByZXNlbnRzIiB3 ZXJlIA0KcmVwbGFjZWQgd2l0aCAiY29ycmVzcG9uZHMgdG8iLCBhbmQgaWYgdGhlIGZpcnN0ICJh bmQiIHdlcmUgIndoZXJlIi4mbmJzcDsgDQooInNpbGVudCIgLSZndDsgInNpbGVuY2UiIHdvdWxk bid0IGh1cnQuKTwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPkFJOiBDaGFuZ2VkLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjEyKSBQa3RjUmluZ0NhZGVuY2U6IGFy ZSBpbXBsZW1lbnRhdGlvbnMgcmVxdWlyZWQgDQp0byBlbmZvcmNlIGFueSBjb25zdHJhaW50cyBv biB0aGUgdmFsdWVzIG9mIGEpIHRoZSBiaXQgY291bnQgZmllbGQsIGIpIHRoZSANCnJlcGVhdGFi bGUgZmllbGQsIGMpIHRoZSAzIG9uLW9mZiB0cmFuc2l0aW9uIGxpbWl0LCBkKSB2YWx1ZXMgZm9y IGJpdHMgYmV5b25kIA0KdGhlIGJpdCBjb3VudCwgZSkgYW4gb2N0ZXQtc3RyaW5nIGxlbmd0aCBv dGhlciB0aGFuIHRoZSBtaW5pbXVtIHJlcXVpcmVkIHRvIA0KZW5jb2RlIHdoYXRldmVyIGxlbmd0 aCBpcyBzcGVjaWZpZWQgaW4gdGhlIGJpdCBjb3VudCBmaWVsZD88L0ZPTlQ+PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogT3Blbi4gQSBz ZXBhcmF0ZSByZWZsZWN0b3IgdGhyZWFkIGhhcyBiZWVuIA0Kc3RhcnRlZCB0byBzb2xpY2l0IGNv bW1lbnRzIGZyb20gSVBDRE4gbWVtYmVycyBvbiBhZGRpbmcgbm9ybWF0aXZlIA0KcmVxdWlyZW1l bnRzLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPjEzKSBQa3RjU2lnVHlwZTogaXMgYW55IGd1aWRhbmNlIG5lZWRlZCBvbiB3aGVu IHRvIA0KdXNlIHJlc2VydmVkKDIpIGFuZCB3aGVuIHRvIHVzZSBvdGhlcigxKT88L0ZPTlQ+PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTog Q2hhbmdlZCBkZXNjcmlwdGlvbi48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4xNCkgcGt0Y1NpZ0RldkNvZGVjQ29tYm9JbmRleDog d2hlcmUgZG9lcyB0aGUgDQpyYW5nZTxCUj5jb25zdHJhaW50ICgxLi4yNTUpIGNvbWUgZnJvbT8m bmJzcDsgVGhlcmUncyBub3RoaW5nIGluIHRoZSBkb2N1bWVudCB0byANCmp1c3RpZnkgdGhhdCBw YXJ0aWN1bGFyIHVwcGVyIGJvdW5kLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBObyBjaGFuZ2UuIFNlZSByZWZsZWN0b3Ig DQpkaXNjdXNzaW9uLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPjE1KSBwa3RjU2lnRGV2Q2FsbGVySWRTaWdQcm90b2NvbDogdGhl IERFU0NSSVBUSU9OIA0KbmVlZHMgdG8gc3BlbGwgb3V0IHdoYXQgaXMgbWVhbnQgYnkgZWFjaCBl bnVtZXJhdGlvbjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPkFJOiBDaGFuZ2VkIGRlc2NyaXB0aW9uLjwvRk9OVD48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjE2KSBwa3RjU2ln RGV2KkNhZGVuY2U6Jm5ic3A7Jm5ic3A7IHdvdWxkbid0IGl0IGJlIA0Kc2ltcGxlciB0byBwdXQg dGhlc2U8QlI+dGVuIG9iamVjdHMgaW50byBhIHRhYmxlPyZuYnNwOyBqdXN0IGEgDQp0aG91Z2h0 Li4uLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPkFJOiBObyBjaGFuZ2UuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+MTcpIHBrdGNTaWdEZWZNZWRpYVN0cmVhbURz Y3A6IFRoZXJlJ3Mgbm8gDQphbnRlY2VkYW50IGZvcjxCUj4idGhlIG5ldyBjb25uZWN0aW9uIi4m bmJzcDsgSXMgIm5ldyBjb25uZWN0aW9ucyIgDQppbnRlbmRlZD88L0ZPTlQ+PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogQWRkZWQgdGhl IGZvbGxvd2luZyBiZWZvcmUgc2VudGVuY2Ugc3RhcnRpbmcgDQp3aXRoICJXaGVuIiB0byBwcm92 aWRlIGNvbnRleHQgZm9yICJuZXcgY29ubmVjdGlvbnMiOjwvRk9OVD48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFueSBjdXJyZW50bHkgYWN0 aXZlIGNvbm5lY3Rpb25zIGFyZSBub3QgYWZmZWN0ZWQgDQpieSB1cGRhdGVzIHRvIHRoaXMgb2Jq ZWN0LjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPjE4KSBwa3RjU2lnbmFsaW5nSW5kZXg6IHdoZXJlIGRvZXMgdGhlIHJhbmdlIA0K Y29uc3RyYWludDxCUj4oMS4uMjU1KSBjb21lIGZyb20/IFRoZXJlJ3Mgbm90aGluZyBpbiB0aGUg ZG9jdW1lbnQgdG88QlI+anVzdGlmeSANCnRoYXQgcGFydGljdWxhciB1cHBlciBib3VuZC48L0ZP TlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9 Mj5BSTogTm8gY2hhbmdlLiBTZWUgcmVmbGVjdG9yIA0KZGlzY3Vzc2lvbi48L0ZPTlQ+PC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4xOSkgcGt0 Y1NpZ0RlZk5jc1JlY2VpdmVVZHBQb3J0OiB3aGVyZSBkb2VzIHRoZSANCmxvd2VyIHJhbmdlIGNv bnN0cmFpbnQgY29tZSBmcm9tPzwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBObyBjaGFuZ2UuIElBTkEgcmVnaXN0ZXJzIHBv cnRzIDAtMTAyMyBhbmQgcG9ydCANCjEwMjQgaXMgaW5kaWNhdGVkIGFzIHJlc2VydmVkLjwvRk9O VD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PjIwKSBwa3RjU2lnUG93ZXJSaW5nRnJlcXVlbmN5OiBmb3IgZWFjaCBvZiB0aGUgDQplbnVtZXJh dGlvbiB2YWx1ZXMsIHRoZSBERVNDUklQVElPTiBjbGF1c2Ugc2hvdWxkIHNwZWxsIG91dCB3aGF0 IHRoYXQgdmFsdWUgDQptZWFucy48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogQ2hhbmdlZCBkZXNjcmlwdGlvbi48L0ZPTlQ+ PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4y MSkgcGt0Y1NpZ1B1bHNlU2lnbmFsVHlwZTogc2hvdWxkIHNwZWxsIG91dCB3aGF0IA0KZWFjaCBl bnVtZXJhdGlvbiB2YWx1ZSBtZWFucyBpbiB0aGUgREVTQ1JJUFRJT04uPC9GT05UPjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IENoYW5n ZWQgZGVzY3JpcHRpb24gdG8gbGlzdCANCmVudW1lcmF0aW9ucy48L0ZPTlQ+PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4yMikgcGt0Y1NpZ1B1 bHNlU2lnbmFsRnJlcXVlbmN5OiBkb2VzIHRoZSAibXVzdCIgDQptZWFuICJNVVNUIjxCUj5pbiB0 aGUgc2Vuc2UgdGhhdCBhbiBhdHRlbXB0IHRvIHdyaXRlIGEgdmFsdWUgaW5jb21wYXRpYmxlIHdp dGggDQp0aGUgaW5zdGFuY2UncyBwa3RjU2lnUHVsc2VTaWduYWxUeXBlIG11c3QgYmUgcmVqZWN0 ZWQ/Jm5ic3A7IFdoYXQgdmFsdWUgZG9lcyBpdCANCnRha2UgLyBjYW4gaXQgYmUgc2V0IHRvIGZv ciAiaW5hcHBsaWNhYmxlIiBzaWduYWwgdHlwZXM/PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IENoYW5nZWQgbXVzdCB0byBN VVNULiBBZGRlZCBkZXNjcmlwdGlvbiBmb3IgDQpyZXR1cm5pbmcgaW5jb25zaXN0ZW50IHZhbHVl IGZvciBhbiBpbmFwcGxpY2FibGUgc2lnbmFsIHR5cGUuPC9GT05UPjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+MjMpIHBrdGNTaWdQdWxzZVNp Z25hbERiTGV2ZWw6IFdoYXQgdmFsdWUgZG9lcyBpdCANCnRha2UgLyBjYW4gaXQgYmUgc2V0IHRv IGFuIGluYXBwbGljYWJsZSBzaWduYWwgdHlwZXM/Jm5ic3A7IDwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBBZGRlZCBkZXNj cmlwdGlvbiBmb3IgcmV0dXJuaW5nIGluY29uc2lzdGVudCANCnZhbHVlIGZvciBhbiBpbmFwcGxp Y2FibGUgc2lnbmFsIHR5cGUuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjI0 KSBwa3RjU2lnUHVsc2VTaWduYWxEdXJhdGlvbjogd2hhdCBoYXBwZW5zIHdoZW4gDQpzb21ldGhp bmcgYXR0ZW1wdHMgdG8gc2V0IHRoaXMgdG8gYSB2YWx1ZSB0aGF0IGRvZXNuJ3QgZmFsbCBvbiBv bmUgb2YgdGhlIA0KaW5jcmVtZW50IGJvdW5kYXJpZXMsIG9yIG9uIHRoZSB3cm9uZyBpbmNyZW1l bnQgYm91bmRhcnkgZm9yIHRoZSBzcGVjaWZpYyBzaWduYWwgDQp0eXBlPzwvRk9OVD48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBBZGRl ZCBkZXNjcmlwdGlvbiBmb3IgcmV0dXJuaW5nIGluY29uc2lzdGVudCANCnZhbHVlIGZvciBpbmNv cnJlY3QgaW5jcmVtZW50IGZvciBhIHNpZ25hbCB0eXBlLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjI1KSBwa3RjU2lnUHVsc2VT aWduYWxQdWxzZUludGVydmFsOiBzYW1lIA0KcXVlc3Rpb25zLjwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBBZGRlZCBkZXNj cmlwdGlvbiBmb3IgcmV0dXJuaW5nIGluY29uc2lzdGVudCANCnZhbHVlIGZvciBpbmNvcnJlY3Qg aW5jcmVtZW50IGZvciBhIHNpZ25hbCB0eXBlLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjI2KSBwa3RjU2lnUHVsc2VTaWduYWxS ZXBlYXRDb3VudDogIm11c3QiIG1lYW5zIA0KIk1VU1QiLCByaWdodD8gU2FtZSBxdWVzdGlvbnMg YXMgKDI0KSBhbmQgKDI1KS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogQ2hhbmdlIG11c3QgdG8gTVVTVC4gQWRkZWQgZGVz Y3JpcHRpb24gZm9yIA0KcmV0dXJuaW5nIGluY29uc2lzdGVudCB2YWx1ZSBmb3IgaW5jb3JyZWN0 IHJhbmdlLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 QXJpYWwgc2l6ZT0yPjI3KSBwa3RjU2lnRGV2Q0lERnNrQWZ0ZXJSaW5nOiBob3cgZG9lcyBvbmUg a25vdyANCndoZXRoZXIgYSBzeXN0ZW0gaXMgImludGVybmF0aW9uYWwiIG9yIG5vdD8mbmJzcDsg SXMgdGhlIHRhYmxlIHN1cHBvc2VkIHRvIGJlIG9mIA0KZGVmYXVsdHM/IFdoZW4gIm5vdCB1c2Vk Iiwgd2hhdCBoYXBwZW5zIHdoZW4gb25lIHRyaWVzIHRvIGdldC9zZXQgdGhpcyANCm9iamVjdD88 L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj5BSTogUmVwbGFjZWQgaGlzdG9yaWNhbCBNSUIgdXNlIG9mICJpbnRlcm5hdGlvbmFsIiAN CndpdGggZSBsaW5lIHBhY2thZ2UuIEFkZGVkIGRlc2NyaXB0aW9uIGZvciByZXR1cm5pbmcgaW5j b25zaXN0ZW50IA0KdmFsdWUuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+MjgpIHBrdGNTaWdEZXZDSURGc2tBZnRlckRUQVM6IHNh bWUgcXVlc3Rpb25zIGFzIA0KKDI3KTwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBSZXBsYWNlZCBoaXN0b3JpY2FsIE1JQiB1 c2Ugb2YgImludGVybmF0aW9uYWwiIA0Kd2l0aCBlIGxpbmUgcGFja2FnZS4gQWRkZWQgZGVzY3Jp cHRpb24gZm9yIHJldHVybmluZyBpbmNvbnNpc3RlbnQgDQp2YWx1ZS48L0ZPTlQ+PC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4yOSkgcGt0Y1Np Z0RldkNJREZza0FmdGVyUlBBUzogc2FtZSBxdWVzdGlvbnMgYXMgDQooMjcpPEJSPkZvciBleGFt cGxlLCB3aGF0IGhhcHBlbnMgd2hlbiBhIHN5c3RlbSBpcyBub3QgaW50ZXJuYXRpb25hbCBidXQg dGhlIA0KcGt0Y1NpZ0RldkNJRE1vZGUgaXMgcnBBc0VUUz88L0ZPTlQ+PC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogUmVwbGFjZWQgaGlz dG9yaWNhbCBNSUIgdXNlIG9mICJpbnRlcm5hdGlvbmFsIiANCndpdGggZSBsaW5lIHBhY2thZ2Uu IEFkZGVkIGRlc2NyaXB0aW9uIGZvciByZXR1cm5pbmcgaW5jb25zaXN0ZW50IA0KdmFsdWUuPC9G T05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+MzApIHBrdGNTaWdEZXZDSURSaW5nQWZ0ZXJGU0s6IHNhbWUgYXMgDQooMjcpPC9GT05UPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6 IFJlcGxhY2VkIGhpc3RvcmljYWwgTUlCIHVzZSBvZiAiaW50ZXJuYXRpb25hbCIgDQp3aXRoIGUg bGluZSBwYWNrYWdlLiBBZGRlZCBkZXNjcmlwdGlvbiBmb3IgcmV0dXJuaW5nIGluY29uc2lzdGVu dCANCnZhbHVlLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgDQpzaXplPTI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKjxCUj5QYXJ0IDUgDQooMzEtNzEpPEJSPioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4zMSkgcGt0Y1NpZ0RldkNJRFJp bmdBZnRlckZTSzogd2hhdCBpcyB0aGUgcHVycG9zZSANCm9mPEJSPnRoZSB0YWJsZSBpbiB0aGUg REVTQ1JJUFRJT04/PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+QUk6IFJlcGxhY2VkIGhpc3RvcmljYWwgTUlCIHVzZSBvZiAiaW50 ZXJuYXRpb25hbCIgDQp3aXRoIGUgbGluZSBwYWNrYWdlLiBBZGRlZCBkZXNjcmlwdGlvbiBmb3Ig cmV0dXJuaW5nIGluY29uc2lzdGVudCANCnZhbHVlLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjMyKSBwa3RjU2lnRGV2Q0lERFRB U0FmdGVyTFI6IGV4cGxhaW4gd2hhdCBpcyANCm1lYW50PEJSPmJ5IGludGVybmF0aW9uYWwsIHNw ZWNpZnkgaG93IGl0IGJlaGF2ZXMgZm9yIGdldC9zZXQ8QlI+b24gDQoibm9uLWludGVybmF0aW9u YWwiIHN5c3RlbXMsIGV4cGxhaW4gd2hhdCB0aGU8QlI+dGFibGUgaW4gdGhlIERFU0NSSVBUSU9O IGlzIA0KZm9yLCBhbmQgc3BlY2lmeSB3aGF0IHRoZTxCUj4ibm90IHVzZWQiIGJlaGF2aW91ciBp cy48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs IHNpemU9Mj5BSTogUmVwbGFjZWQgaGlzdG9yaWNhbCBNSUIgdXNlIG9mICJpbnRlcm5hdGlvbmFs IiANCndpdGggZSBsaW5lIHBhY2thZ2UuIEFkZGVkIGRlc2NyaXB0aW9uIGZvciByZXR1cm5pbmcg aW5jb25zaXN0ZW50IA0KdmFsdWUuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+MzMpIHBrdGNTaWdEZXZWbXdpRnNrQWZ0ZXJEVEFT OiBzYW1lIGFzIA0KKDMyKTwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBSZXBsYWNlZCBoaXN0b3JpY2FsIE1JQiB1c2Ugb2Yg ImludGVybmF0aW9uYWwiIA0Kd2l0aCBlIGxpbmUgcGFja2FnZS4gQWRkZWQgZGVzY3JpcHRpb24g Zm9yIHJldHVybmluZyBpbmNvbnNpc3RlbnQgDQp2YWx1ZS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4zNCkgcGt0Y1NpZ0RldlZt d2lGc2tBZnRlclJQQVM6IHNhbWUgYXMgDQooMzIpPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IFJlcGxhY2VkIGhpc3Rvcmlj YWwgTUlCIHVzZSBvZiAiaW50ZXJuYXRpb25hbCIgDQp3aXRoIGUgbGluZSBwYWNrYWdlLiBBZGRl ZCBkZXNjcmlwdGlvbiBmb3IgcmV0dXJuaW5nIGluY29uc2lzdGVudCANCnZhbHVlLjwvRk9OVD48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjM1 KSBwa3RjU2lnRGV2Vm13aURUQVNBZnRlckxSOiBzYW1lIGFzIA0KKDMyKTwvRk9OVD48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBSZXBs YWNlZCBoaXN0b3JpY2FsIE1JQiB1c2Ugb2YgImludGVybmF0aW9uYWwiIA0Kd2l0aCBlIGxpbmUg cGFja2FnZS4gQWRkZWQgZGVzY3JpcHRpb24gZm9yIHJldHVybmluZyBpbmNvbnNpc3RlbnQgDQp2 YWx1ZS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj4zNikgcGt0Y1NpZ0RldlJpbmdDYWRlbmNlVGFibGU6IHdoYXQgaXMgDQpWNS4y PzxCUj5WNS4xIGlzIG1lbnRpb25lZCBlbHNld2hlcmUsIGJ1dCB0aG9zZSByZWZlcmVuY2VzPEJS PmRvbid0IG1hdGNoIHRoaXMgDQpvbmUuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IERlbGV0ZWQgIkluIFY1LjIiIHNpbmNl IEUgbGluZSBwYWNrYWdlIA0KY29udGFpbmVkIGluIDEwMSA5MDktNCwgd2hpY2ggZGVmaW5lcyB0 aGUgcmluZyBjYWRlbmNlcyBpcyBhbHJlYWR5IG5vdGVkIGluIHRoZSANCmRlc2NyaXB0aW9uIGFu ZCByZWZlcmVuY2VzLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPjM3KSBwa3RjU2lnRGV2UmluZ0NhZGVuY2VUYWJsZSBhbmQgDQpw a3RjU2lnRGV2UmluZ0NhZGVuY2VJbmRleDo8QlI+VGhlIGluZGV4aW5nIHNob3VsZCBwcm9iYWJs eSBiZSAwLi4xMjcsIHNpbmNlIA0KdGhhdCdzIGhvdyBpdHMgZG9uZTxCUj5pbiB0aGUgcHJvdG9j b2wuIEFkZGluZyBhbiBvZmZzZXQgb2YgMSBkb2Vzbid0IGFkZCB2YWx1ZSANCmluPEJSPnRoaXMg Y2FzZSwgYW5kIGl0IGFwcGVhcnMgdG8gaW5jcmVhc2UgdGhlIGxpa2VsaWhvb2Qgb2Y8QlI+Y29u ZnVzaW9uIGZvciANCnRoZSB1c2VyLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBDaGFuZ2VkIHRvIDAgdG8gMTI3IHRvIG1h dGNoIEVUU0kgc3BlYyBhbmQgDQp1cGRhdGVkIGRlc2NyaXB0aW9uIGluIGFzc29jaWF0ZWQgdGFi bGUgb2JqZWN0cy48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj4zOCkgcGt0Y1NpZ0RldlJpbmdDYWRlbmNlVGFibGU6IHdoYXQgaXMg dGhlIA0KbGlmZWN5Y2xlIG9mIGVudHJpZXM8QlI+aW4gdGhpcyB0YWJsZT8mbmJzcDsgV2hlbi9I b3cgYXJlIHRoZXkgY3JlYXRlZCBhbmQgDQpkZWxldGVkPyZuYnNwOyBEbyB0aGV5PEJSPnBlcnNp c3QgYWNyb3NzIHJlYm9vdHMgb3IgcG93ZXIgZmFpbHVyZXM/PC9GT05UPjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IE5vIGNoYW5nZS4g VGhlIGRlc2NyaXB0aW9uIGFscmVhZHkgaW5kaWNhdGVzIA0KdGhlIG9iamVjdHMgZG8gbm90IHBl cnNpc3QgYWNyb3NzIHJlYm9vdHMuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+MzkpIHBrdGNTaWdEZXZSaW5nQ2FkZW5jZUVudHJ5 OiB0aGUgREVTQ1JJUFRJT04gaXMgDQp0aGUgb25lPEJSPnRoYXQgYmVsb25ncyBvbiBwa3RjU2ln RGV2UmluZ0NhZGVuY2VJbmRleC48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogTW92ZWQgZGVzY3JpcHRpb24uPC9GT05UPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+NDAp IHBrdGNTaWdEZXZUb25lVGFibGU6IHRoZSBzdHJ1Y3R1cmUgb2YgdGhpcyANCnRhYmxlIGlzPEJS PmEgYml0IGF3a3dhcmQuJm5ic3A7IEl0ICptaWdodCogbWFrZSBtb3JlIHNlbnNlIGlmIGl0IHdl cmUgDQpicm9rZW48QlI+aW50byB0d28gdGFibGVzLiZuYnNwOyBUaGUgZmlyc3QsIGluZGV4ZWQg YnkgDQpwa3RjU2lnRGV2VG9uZVR5cGUsPEJSPndvdWxkIGhvbGQgcGt0Y1NpZ0RldlRvbmVEYkxl dmVsLCANCnBrdGNTaWdEZXZUb25lRnJlcVR5cGUsPEJSPnBrdGNTaWdEZXZUb25lTnVtRnJlcXVl bmNpZXMsIA0KcGt0Y1NpZ0RldlRvbmVXaG9sZVRvbmVSZXBlYXRDb3VudCw8QlI+cGt0Y1NpZ0Rl dlRvbmVOdW1Pbk9mZlRpbWVzLCBhbmQgDQpwa3RjU2lnRGV2VG9uZVN0ZWFkeS48QlI+VGhlIHNl Y29uZCB3b3VsZCBiZSBpbmRleGVkIGJ5IHBrdFNpZ0RldlRvbmVUeXBlIGFuZCANCmFuPEJSPlVu c2lnbmVkMzIgKDEuLjQpLCBjb2xsYXBzaW5nIA0KcGt0Y1NpZ0RldlRvbmVGaXJzdEZyZXF1ZW5j eSw8QlI+cGt0Y1NpZ0RldlRvbmVTZWNvbmRGcmVxdWVuY3ksIA0KcGt0Y1NpZ0RldlRvbmVUaGly ZEZyZXF1ZW5jeSw8QlI+YW5kIHBrdGNTaWdEZXZUb25lRm91cnRoRnJlcXVlbmN5IGludG8gDQpw a3RTaWdEZXZUb25lc0ZyZXF1ZW5jeSw8QlI+Y29sbGFwc2luZyBwa3RjU2lnRGV2VG9uZUZpcnN0 VG9uZU9uLCANCnBrdGNTaWdEZXZUb25lU2Vjb25kVG9uZU9uLDxCUj5wa3RjU2lnRGV2VG9uZVRo aXJkVG9uZU9uLCBhbmQgDQpwa3RjU2lnRGV2VG9uZUZvdXJ0aFRvbmVPbiBpbnRvPEJSPnBrdGNT aWdEZXZUb25lc09uLCBhbmQgY29sbGFwc2luZyANCnBrdGNTaWdEZXZUb25lRmlyc3RUb25lT2Zm LDxCUj5wa3RjU2lnRGV2VG9uZVNlY29uZFRvbmVPZmYsIA0KcGt0Y1NpZ0RldlRvbmVUaGlyZFRv bmVPZmYsIGFuZDxCUj5wa3RjU2lnRGV2VG9uZUZvdXJ0aFRvbmVPZmYgaW50byANCnBrdFNpZ0Rl dlRvbmVzT2ZmLiZuYnNwOyBUaGlzIGlzIG9ubHk8QlI+YSBzdWdnZXN0aW9uLjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogTm8gY2hhbmdlLjwvRk9OVD48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjQxKSBwa3RjU2ln RGV2VG9uZVRhYmxlOiZuYnNwOyBUaGUgREVTQ1JJUFRJT04gc2F5cyANCiJBbnk8QlI+ZGVmaW5p dGlvbiBvZiB0aGUgdG9uZXMgY2FsbFdhaXRpbmcxLTQgaW4gdGhpcyB0YWJsZTxCUj5zaG91bGQg anVzdCANCmNvbnRhaW4gdGhlIGF1ZGlibGUgdG9uZSBpdHNlbGYgYW5kIE5PVDxCUj5jb250YWlu IHRoZSBkZWxheSBiZXR3ZWVuIHRvbmVzIG9yIA0KdGhlIHRvbmUgcmVwZWF0IGNvdW50LiI8QlI+ SW4gdGhvc2UgY2FzZXMsIGhvdyB3aWxsIA0KcGt0Y1NpZ0RldlRvbmVXaG9sZVRvbmVSZXBlYXRD b3VudDxCUj5iZWhhdmUgb24gZ2V0L3NldD88L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogQ2hhbmdlZC4gQWRkZWQgdGhlIGZv bGxvd2luZyB0ZXh0IHRvIHRoZSANCmRlc2NyaXB0aW9uOjwvRk9OVD48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPklmIHRoZSBwa3RjU2lnRGV2 VG9uZVR5cGUgaXMgY2FsbFdhaXRpbmcxLTQsIHRoZSANCnBrdGNTaWdEZXZUb25lV2hvbGVUb25l UmVwZWF0Q291bnQgZG9lcyBub3QgYXBwbHkgYW5kIE1VU1QgYmUgaWdub3JlZCBvbiBTTk1QIA0K c2V0L2dldCBvcGVyYXRpb25zLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjQyKSBwa3RjU2lnRGV2VG9uZUVudHJ5OiB0aGUgREVT Q1JJUFRJT04gaGFzIHRoZSANCnRleHQgdGhhdCBzaG91bGQ8QlI+YmUgb24gcGt0Y1NpZ0RldlRv bmVUeXBlLiZuYnNwOyBUaGUgcGhyYXNlICJ0aGF0IGFyZSBiZWluZyANCnN1cHBvcnRlZCI8QlI+ YXBwZWFycyB0byBiZSBhdCBvZGRzIHdpdGggdGhlIGxhbmd1YWdlIGluIA0KcGt0Y1NpZ0RldlRv bmVUYWJsZTxCUj50aGF0IHNheXMgImZvciBlYWNoIHBvc3NpYmxlIGluZGV4LCBhbiBlbnRyeSBN VVNUIGJlIA0KZGVmaW5lZCIuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IE1vdmVkIGRlc2NyaXB0aW9uLjwvRk9OVD48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjQzKSBw a3RjU2lnRGV2VG9uZVR5cGU6IHdoYXQgaXMgbWVhbnQgYnkgDQoidHJpZ2dlcmVkIj8mbmJzcDsg VGhpczxCUj5zb3VuZHMgYXQgb2RkcyB3aXRoIHRoZSBsYW5ndWFnZSBpbiANCnBrdGNTaWdEZXZU b25lVGFibGU8QlI+dGhhdCBzYXlzICJmb3IgZWFjaCBwb3NzaWJsZSBpbmRleCwgYW4gZW50cnkg TVVTVCBiZSANCmRlZmluZWQiLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBDaGFuZ2VkICJ0cmlnZ2VyZWQiIHRvICJ1c2Vk IGluIi48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj40NCkgcGt0Y1NpZ0RldlRvbmUqRnJlcXVlbmN5OiAiY291bGQiIHNlZW1zIG9k ZCBpbiANCnRoZXNlIGZvdXIuPEJSPklzIHRoaXMgaW50ZW5kZWQgdG8gbWVhbiB0aGF0IHRoZSBk ZXZpY2UgbWlnaHQgZG8gc29tZXRoaW5nIA0KZWxzZT88L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogQ2hhbmdlZCAiY291bGQg YmUiIHRvICJhcmUiLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPjQ1KSBwa3RjU2lnRGV2VG9uZSpUb25lT24gYW5kIA0KcGt0Y1Np Z0RldlRvbmUqVG9uZU9mZjogdGhlPEJSPkRFU0NSSVBUSU9OUyBhcmUgdW5jbGVhci4mbmJzcDsg Rm9yIGV4YW1wbGUsIGRvZXMgDQpwa3RjU2lnRGV2Rmlyc3RUb25lT248QlI+cmVwcmVzZW50IHRo ZSBsZW5ndGggb2YgdGltZSB0aGF0IHRoZSB0b25lIHdpbGwgYmUgb24sIA0Kb3IgZG9lcyBpdDxC Uj5yZXByZXNlbnQgdGhlIGFtb3VudCBvZiB0aW1lIHRoYXQgbXVzdCBwYXNzIGJlZm9yZSB0aGUg dG9uZSANCmlzPEJSPnR1cm5lZCBvbj8mbmJzcDsgRm9yIHBrdFNpZ0RldkZpcnN0VG9uZU9mZiwg Zm9yIGV4YW1wbGUsIGRvZXMgaXRzIA0KdmFsdWU8QlI+cmVwcmVzZW50IHRoZSBsZW5ndGggb2Yg dGltZSB0aGF0IHRoZSB0b25lIHdpbGwgYmUgb2ZmLCBvciBkb2VzIA0KaXM8QlI+cmVwcmVzZW50 IHRoZSBhbW91bnQgb2YgdGltZSB0aGF0IG11c3QgZWxhcHNlIGFmdGVyIHRoZSB0b25lIGlzPEJS PnR1cm5lZCANCm9uIGJlZm9yZSBpdCBpcyB0dXJuZWQgb2ZmLCBvciBkb2VzIGl0IHJlcHJlc2Vu dCB0aGUgYW1vdW50PEJSPm9mIHRpbWUgZnJvbSB0aGUgDQpiZWdpbm5pbmcgb2YgdGhlIGNhZGVu Y2UgdGhhdCBtdXN0IGVsYXBzZSBiZWZvcmU8QlI+dGhlIHRvbmUgaXMgdHVybmVkIA0Kb2ZmPzwv Rk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPkFJOiBDaGFuZ2VkIGRlc2NyaXB0aW9uLiBUb25lT24gPSBsZW5ndGggb2YgdGltZSANCnRv bmUgaXMgb24uIFRvbmVPZmYgPSBsZW5ndGggb2YgdGltZSB0b25lIGlzIG9mZi48L0ZPTlQ+PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj40Nikg cGt0Y05jc0VuZFBudENvbmZpZ1RhYmxlOiB0aGVyZSBpcyBzb21ldGhpbmcgDQp3cm9uZyB3aXRo PEJSPnRoaXMgc2VudGVuY2UgaW4gdGhlIA0KREVTQ1JJUFRJT046PEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCiJFYWNoIGVuZHBvaW50IGNhbiBiZSBhc3NpZ25lZCB0byBhIGl0cyBvd24gQ01TLiI8L0ZP TlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9 Mj5BSTogRGVsZXRlZCAiYSIuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjQ3 KSBwa3RjTmNzRW5kUG50Q29uZmlnRW50cnk6IHB1bmN0dWF0aW9uIGluIA0KREVTQ1JJUFRJT046 PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCiJFbnRyaWVzIGluIHBrdGNOY3NFbmRQbnRDb25maWdUYWJsZSA/IEVhY2ggZW50 cnkiPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+QUk6IENoYW5nZWQuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+NDgpIHBrdGNOY3NFbmRQbnRDb25maWdDYWxsQWdl bnRJZDogIml0IGlzIGhpZ2hseSANCnJlY29tbWVuZGVkIG5vdDxCUj50byBjaGFuZ2UgdGhpcyBv YmplY3QncyB2YWx1ZSB0aHJvdWdoIG1hbmFnZW1lbnQgc3RhdGlvbiANCmR1cmluZzxCUj5ub3Jt YWwgb3BlcmF0aW9ucy4iJm5ic3A7IERvIHlvdSBtZWFuICJkdXJpbmcgbm9ybWFsIA0Kb3BlcmF0 aW9uLDxCUj51c2luZyBTTk1QIHRvIGNoYW5nZSB0aGlzIG9iamVjdCdzIHZhbHVlIGlzIE5PVCBS RUNPTU1FTkRFRCIgDQpvcjxCUj4iZHVyaW5nIG5vcm1hbCBvcGVyYXRpb24sIHRoZSB1c2Ugb2Yg bWFuYWdlbWVudCBvcGVyYXRpb25zIHRvPEJSPmNoYW5nZSANCnRoaXMgb2JqZWN0J3MgdmFsdWUg aXMgTk9UIFJFQ09NTUVOREVEIj88L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogQ2hhbmdlZCAidGhyb3VnaCBtYW5hZ2VtZW50 IHN0YXRpb24iIHRvICJ1c2luZyANClNOTVAiLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjQ5KSBwa3RjTmNzRW5kUG50Q29uZmln Q2FsbEFnZW50VWRwUG9ydDogd2h5IHRoZSANCmxpbWl0ZWQgcG9ydCByYW5nZT88QlI+V2hlcmUg ZGlkIDI3MjcgY29tZSBmcm9tPzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5B STogTm8gY2hhbmdlLiBEdXBsaWNhdGUsIHNlZSBhYm92ZS4gMjcyNyBpcyB0aGUgDQpJQU5BIGRl ZmF1bHQgZm9yIHRoZSBNR0NQIENBIHBvcnQ6PEJSPm1nY3AtY2FsbGFnZW50Jm5ic3A7IDI3Mjcv dGNwJm5ic3A7Jm5ic3A7IA0KTWVkaWEgR2F0ZXdheSBDb250cm9sIFByb3RvY29sIENhbGwgQWdl bnQ8QlI+bWdjcC1jYWxsYWdlbnQmbmJzcDsgDQoyNzI3L3VkcCZuYnNwOyZuYnNwOyBNZWRpYSBH YXRld2F5IENvbnRyb2wgUHJvdG9jb2wgQ2FsbCBBZ2VudDwvRk9OVD48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjUwKSBwa3RjTmNzRW5kUG50 Q29uZmlnQ2FsbEFnZW50VWRwUG9ydDogIml0IGlzIA0KaGlnaGx5IHJlY29tbWVuZGVkIG5vdDxC Uj50byBjaGFuZ2UgdGhpcyBvYmplY3QncyB2YWx1ZSB0aHJvdWdoIG1hbmFnZW1lbnQgDQpzdGF0 aW9uIGR1cmluZzxCUj5ub3JtYWwgb3BlcmF0aW9ucy4iJm5ic3A7IERvIHlvdSBtZWFuICJkdXJp bmcgbm9ybWFsIA0Kb3BlcmF0aW9uLDxCUj51c2luZyBTTk1QIHRvIGNoYW5nZSB0aGlzIG9iamVj dCdzIHZhbHVlIGlzIE5PVCBSRUNPTU1FTkRFRCIgDQpvcjxCUj4iZHVyaW5nIG5vcm1hbCBvcGVy YXRpb24sIHRoZSB1c2Ugb2YgbWFuYWdlbWVudCBvcGVyYXRpb25zIHRvPEJSPmNoYW5nZSANCnRo aXMgb2JqZWN0J3MgdmFsdWUgaXMgTk9UIFJFQ09NTUVOREVEIj88L0ZPTlQ+PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogQ2hhbmdlZCAi dGhyb3VnaCBtYW5hZ2VtZW50IHN0YXRpb24iIHRvICJ1c2luZyANClNOTVAiLjwvRk9OVD48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjUxKSBw a3RjTmNzRW5kUG50Q29uZmlnUGFydGlhbERpYWxUTzo8QlI+ImNvbnRhaW5zIA0KbWF4aW11bSIg LSZndDsgImNvbnRhaW5zIHRoZSBtYXhpbXVtIiZuYnNwOyAoVGhlIGRlc2NyaXB0aW9uPEJSPmFu ZCB0aGUgDQpkZXNjcmlwdG9yIG1ha2UgaXQgc291bmQgbGlrZSB0aGUgZGV2aWNlIG1heSB1c2Ug YW55PEJSPnRpbWVvdXQgdmFsdWUsIGFzIGxvbmcgDQphcyB0aGF0IHRpbWVvdXQgdmFsdWUgaXMg bGVzcyB0aGFuIHRoaXM8QlI+b2JqZWN0J3MgdmFsdWUuJm5ic3A7IElzIHRoYXQgcmVhbGx5IA0K dGhlIGludGVudD8gQ29tcGFyZSB0aGU8QlI+REVTQ1JJUFRJT05zIG9mIHRoaXMsIHBrdGNOY3NF bmRQbnRDb25maWdCdXN5VG9uZVRPLCANCmFuZDxCUj5wa3RjTmNzRW5kUG50Q29uZmlnQ3JpdGlj YWxEaWFsVE8uPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbCBzaXplPTI+QUk6IEFkZGVkICJ0aGUiLiBSZW1haW5kZXIgb2YgY29tbWVudCBpcyAN CnVuY2xlYXIuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbCBzaXplPTI+NTIpIHBrdGNOY3NFbmRQbnRDb25maWdUU01heDogIm1heCIgLSZndDsg DQoibWF4aW11bSI8QlI+SXQncyBub3QgY2xlYXIgZnJvbSB0aGUgZGVzY3JpcHRpb24gd2hhdCB0 aGlzIG9iamVjdCANCmNvbnRyb2xzLjxCUj5JdCBkZWZpbmVzIGEgcGVyaW9kIHRoYXQgaXMgYm91 bmRlZCBvbiBvbmUgZW5kIGJ5PEJSPiJ0aGUgc2VuZGluZyANCm9mIHRoZSBpbml0aWFsIGRhdGFn cmFtIiAod2hhdGV2ZXIgdGhhdCBpcykgYnV0PEJSPmRvZXMgbm90IHNheSB3aGF0IGV2ZW50IGlz IGF0IA0KdGhlIG90aGVyIGVuZCBvZiB0aGUgaW50ZXJ2YWwuPC9GT05UPjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IENoYW5nZWQgbWF4 IHRvIG1heGltdW0uIENoYW5nZWQgZGVzY3JpcHRpb24gcGVyIA0KUEMgTkNTIHNwZWMuPC9GT05U PjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+ NTMpIHBrdGNOY3NFbmRQbnRDb25maWdNYXgxOiB0aGUgZGVzY3JpcHRpb24gc2F5cyANCnRoaXMg aXMgYTxCUj50aHJlc2hvbGQsIGJ1dCBkb2Vzbid0IHNheSB3aGF0IG9iamVjdCBvciBkZWx0YS9p bnRlcnZhbCBpdDxCUj5pcyANCmNvbXBhcmVkIHRvLCBhbmQgZG9lc24ndCBzYXkgd2hhdCBoYXBw ZW5zIHdoZW4gdGhlIHRocmVzaG9sZDxCUj5pcyANCmNyb3NzZWQuPC9GT05UPjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IENoYW5nZWQg ZGVzY3JpcHRpb24uIE1heDEgaXMgZGVmaW5lZCBpbiB0aGUgUEMgDQpNR0NQIHNwZWMuPEJSPiZu YnNwOzxCUj41NCkgcGt0Y05jc0VuZFBudENvbmZpZ01heDI6IHNhbWUgYXMgKDUzKTwvRk9OVD48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJ OiBDaGFuZ2VkIGRlc2NyaXB0aW9uLiBNYXgyIGlzIGRlZmluZWQgaW4gdGhlIFBDIA0KTUdDUCBz cGVjLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPjU1KSBwa3RjTmNzRW5kUG50Q29uZmlnTWF4MVFFbmFibGU6IHRoZSBkZXNjcmlw dGlvbiANCmlzIHVuY2xlYXIuPEJSPldoZXJlIGlzIHRpbWVyIE1heDEgZGVmaW5lZD8mbmJzcDsg VGhlIG9ubHkgb3RoZXIgTWF4MSBpbiANCnRoaXM8QlI+ZG9jdW1lbnQgaXMgYSB0aHJlc2hvbGQs IHJhdGhlciB0aGFuIGEgdGltZXIuJm5ic3A7IEFsc28sIHRoZXJlPEJSPmlzIGFuIA0KYW1iaWd1 aXR5IGluIHRoZSBzZW50ZW5jZS4mbmJzcDsgSXQgY2FuIGJlIHJlYWQgdG8gbWVhbjxCUj4id2hl biBNYXgxIGV4cGlyZXMsIA0KdGhpcyBvYmplY3Qgd2lsbCBlbmFibGUgb3IgZGlzYWJsZTxCUj50 aGUgcXVlcnkgb3BlcmF0aW9uIiBhcyB3ZWxsIGFzIHRvIG1lYW4gDQoidGhlIHF1ZXJ5IG9wZXJh dGlvbjxCUj5pbml0aWF0ZWQgd2hlbmV2ZXIgTWF4MSBleHBpcmVzIGlzIGVuYWJsZWQvZGlzYWJs ZWQgYnkgDQp0aGlzPEJSPm9iamVjdC4iPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPkFJOiBDaGFuZ2VkIGRlc2NyaXB0aW9uIHRvIHJlZmVyIHRvIHRocmVzaG9sZHMuIA0KTWF4 MSBhbmQgTWF4MiBhcmUgdGhyZXNob2xkcyBkZWZpbmVkIGluIHRoZSBQQyBNR0NQIHNwZWMuIDwv Rk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPjU2KSBwa3RjTmNzRW5kUG50Q29uZmlnTWF4MlFFbmFibGU6IHNhbWUgYXMgDQooNTUpPC9G T05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+QUk6IENoYW5nZWQgZGVzY3JpcHRpb24gdG8gcmVmZXIgdG8gdGhyZXNob2xkcy4gU2VlIA0K YWJvdmUgKDU1KS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj41NykgcGt0Y05jc0VuZFBudENvbmZpZ01XRDogdGhlIGZpcnN0IGFu ZCBzZWNvbmQgDQpzZW50ZW5jZXMgb2Y8QlI+dGhlIGRlc2NyaXB0aW9uIGRvbid0IHdvcmsgd2Vs bCB0b2dldGhlci4mbmJzcDsgVGFrZW4gdG9nZXRoZXIsIA0KdGhleTxCUj5zYXkgdGhlIE1UQSB3 aWxsIHJlc3RhcnQgZXZlcnkgTVdEIHNlY29uZHMgKG9yIGxlc3MpLiZuYnNwOyBUaGlzIA0KaXM8 QlI+cHJvYmFibHkgbm90IHdoYXQgaXMgaW50ZW5kZWQuPC9GT05UPjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IENoYW5nZWQgZGVzY3Jp cHRpb24gdG8gcmVmZXIgdG8gaW5pdGlhbCBwb3dlciANCm9uIGFuZCByZXN0YXJ0IHByb2NlZHVy ZSBwZXIgdGhlIFBDIE5DUyBzcGVjLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjU4KSBwa3RjTmNzRW5kUG50Q29uZmlnVGRpbml0 OiBzYW1lIHByb2JsZW0gYXMgDQooNTcpJm5ic3A7IENvdWxkIGJlPEJSPmZpeGVkIGJ5IGNoYW5n aW5nICJhZnRlciIgdG8gImJlZm9yZSIsIGJ1dCBJJ20gbm90IHN1cmUgDQp0aGF0J3M8QlI+d2hh dCB3YXMgaW50ZW5kZWQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9 Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBD aGFuZ2VkIGRlc2NyaXB0aW9uIHRvIHJlZmVyIHRvIGluaXRpYXRpbmcgdGhlIA0KZGlzY29ubmVj dCBwcm9jZWR1cmUgd2l0aCB0aGUgY2FsbCBhZ2VudCBwZXIgUEMgTkNTIHNwZWMuPC9GT05UPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+NTkp IHBrdGNOY3NFbmRQbnRDb25maWdUZG1pbiwgDQpwa3RjTmNzRW5kUG50Q29uZmlnVGRtYXgsIGFu ZDxCUj5wa3RjTmNzRW5kUG50Q29uZmlnVGRpbml0IGRvbid0IHdvcmsgd2VsbCANCnRvZ2V0aGVy LiZuYnNwOyBBcyBjdXJyZW50bHk8QlI+d3JpdHRlbiwgdGhlIGRpc2Nvbm5lY3RlZCBwcm9jZWR1 cmUgd2lsbCBiZSANCmluaXRpYXRlZCB0aHJlZSB0aW1lcyw8QlI+b25jZSBmb3IgZWFjaCBvZiB0 aGVzZSB0aHJlZSB0aW1lcnMuJm5ic3A7IA0KRnVydGhlcm1vcmUsIGFyZSB0aGVyZTxCUj5hbnkg Y29uc3RyYWludHMgb24gdGhlaXIgcmVsYXRpdmUgdmFsdWVzPyZuYnNwOyBGb3IgDQpleGFtcGxl LCBpcyBpdDxCUj5PSyB0byBzZXQgcGt0Y05jc0VuZFBudENvbmZpZ1RkbWluIHRvIGEgdmFsdWUg bGFyZ2VyIHRoYW4gDQp0aGF0PEJSPm9mIHBrdGNOY3NFbmRQbnRDb25maWdUZG1heD88L0ZPTlQ+ PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5B STogTm8gY2hhbmdlLiBUaGVzZSB2YWx1ZXMgYW5kIHRoZWlyIHJlbGF0aW9uc2hpcHMgDQphcmUg ZGVmaW5lZCBpbiBkZXRhaWwgaW4gdGhlIFBDIE5DUyBzcGVjLjwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjYwKSBwa3RjTmNzRW5k UG50Q29uZmlnUnRvTWF4IC8gDQpwa3RjTmNzRW5kUG50Q29uZmlnUnRvSW5pdDogaXM8QlI+dGhl cmUgYW55IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZXNlIHR3byANCm9iamVjdHM/Jm5ic3A7IFdo eSBkbyB0aGV5PEJSPmhhdmUgZGlmZmVyZW50IHVuaXRzPzwvRk9OVD48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBObyBjaGFuZ2UuIE1H Q1AgdXNlcyBleHBvbmVudGlhbGx5IGluY3JlYXNpbmcgDQp0aW1lcnMgZm9yIHJldHJhbnNtaXNz aW9uLiBSVE8gaW5pdCBpcyB0aGUgY29uZmlndXJlZCBpbml0aWFsIHJldHJhbnNtaXNzaW9uIA0K dGltZXIgdmFsdWUgaW4gbWlsbGlzZWNvbmRzIChwZXIgUEMgTUdDUCA0LjQuMikuPC9GT05UPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+NjEp IHBrdGNOY3NFbmRQbnRDb25maWdTdGF0dXM6IFJGQyAyNTc5IChwYWdlIDgsIA0KIk5PVEUgV0VM TCIpPEJSPnJlcXVpcmVzIGFueSB1c2Ugb2YgUm93U3RhdHVzIHRvIHNwZWNpZnkgd2hldGhlciBj b2x1bW5zIA0KbWF5PEJSPmJlIG1vZGlmaWVkIHdoZW4gdGhlIHJvdyBpcyBhY3RpdmUsIGFuZCAo cGFnZSAxNykgdW5kZXIgDQp3aGF0PEJSPmNpcmN1bXN0YW5jZSBpdCBzaG91bGQvbWF5IGJlIHRh a2VuIG91dCBvZiBzZXJ2aWNlLiZuYnNwOyBTZWUgDQpNSUI8QlI+cmV2aWV3IGd1aWRlbGluZXMg c2VjdGlvbiA0LjYuNCBmb3IgZGV0YWlscy48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BSTogT3Blbi4gSXNzdWUgcG9zdGVkIHRv IHRoZSBQQyBOQ1MvUFJPViByZWZsZWN0b3IgDQpmb3IgaW5wdXQuPC9GT05UPjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+NjMpIHBrdGNOY3NF bmRQbnRTdGF0dXNFcnJvcjombmJzcDsgdGhlIERFU0NSSVBUSU9OIA0Kc2F5cyAiT3RoZXJ3aXNl LDxCUj50aGUgc3RhdGUgaXMgdW51c2VkLiImbmJzcDsgSXMgInN0YXRlIiB0aGUgc2FtZSB0aGlu ZyBhcyANCiJzdGF0dXMiIGluPEJSPnRoZSByZXN0IG9mIHRoZSBERVNDUklQVElPTj8mbmJzcDsg V2hhdCB2YWx1ZSBkb2VzIHRoaXMgb2JqZWN0IA0KaGF2ZTxCUj53aGVuIGl0IGlzICJ1bnVzZWQi PzwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwg c2l6ZT0yPkFJOiBSZXBsYWNlZCAiT3RoZXdpc2UgdGhlIHN0YXRlIGlzIHVudXNlZC4iIHdpdGgg DQoiSWYgcGt0Y010YURldkNtc0lwc2VjQ3RybCBpcyBkaXNhYmxlZCBmb3IgdGhlIGFzc29jaWF0 ZWQgQ2FsbCBBZ2VudCwgdGhlIA0Kbm9TZWN1cml0eUFzc29jaWF0aW9uIHN0YXR1cyBpcyBub3Qg YXBwbGljYWJsZSBhbmQgc2hvdWxkIG5vdCBiZSB1c2VkIGJ5IHRoZSANCk1UQS4iPC9GT05UPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+NjQp IHBrdGNOY3NFbmRQbnRTdGF0dXNFcnJvcjombmJzcDsgc3VnZ2VzdCANCmNoYW5naW5nPEJSPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCiJPdGhlcndpc2UsIHBrdGNNdGFEZXZDbXNJcHNlY0N0cmwgaXMgZW5hYmxlZCwi IA0KLSZndDs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KIk90aGVyd2lzZSwgd2hlbiBwa3RjTXRhRGV2Q21zSXBz ZWNDdHJsIGlzIGVuYWJsZWQsIjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBDaGFuZ2VkLjwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjY1KSBwa3RjTmNzRW5k UG50Q29uZmlnTWluSG9va0ZsYXNoLCANCnBrdGNOY3NFbmRQbnRDb25maWdNYXhIb29rRmxhc2g6 PEJSPmFyZSB0aGVyZSBhbnkgY29uc3RyYWludHMgb24gdGhlIA0KcmVsYXRpb25zaGlwIG9mIHRo ZSB2YWx1ZXM8QlI+b2YgdGhlc2UgdHdvPzwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBDaGFuZ2VkIGRlc2NyaXB0aW9uIHRv IGluZGljYXRlIHRoZSBtYXggaG9vayANCmZsYXNoIG11c3QgYmUgZ3JlYXRlciB0aGFuIG1pbiBo b29rIGZsYXNoLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPjY2KSBwa3RjTmNzRW5kUG50Q29uZmlnTWluSG9va0ZsYXNoLCANCnBr dGNOY3NFbmRQbnRDb25maWdNYXhIb29rRmxhc2gsIGV0Yy46PEJSPiJUaGlzIG9iamVjdCBtdXN0 IG9ubHkgYmUgc2V0IHZpYSB0aGUgDQpjb25maWd1cmF0aW9uIGZpbGUgZHVyaW5nIHRoZTxCUj5w cm92aXNpb25pbmcgcHJvY2Vzcy4iJm5ic3A7IElzIHRoaXMgaW50ZW5kZWQgDQp0byBwcm9oaWJp dCBwcm92aXNpb25pbmc8QlI+YnkgbWVhbnMgb3RoZXIgdGhhbiBhIGNvbmZpZ3VyYXRpb24gDQpm aWxlPzwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPkFJOiBZZXMuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+NjcpIA0KcGt0Y05jc0VuZFBudENvbmZpZ1B1bHNlRGlh bE1pbk1ha2VUaW1lLDxCUj5wa3RjTmNzRW5kUG50Q29uZmlnUHVsc2VEaWFsTWF4TWFrZVRpbWUs PEJSPnBrdGNOY3NFbmRQbnRDb25maWdQdWxzZURpYWxNaW5CcmVha1RpbWUsPEJSPnBrdGNOY3NF bmRQbnRDb25maWdQdWxzZURpYWxNYXhCcmVha1RpbWUsIA0KYW5kPEJSPnBrdGNOY3NFbmRQbnRD b25maWdQdWxzZURpYWxJbnRlcmRpZ2l0VGltZTo8QlI+Y29uc3RyYWludHMgd2l0aCByZXNwZWN0 IA0KdG8gZWFjaCBvdGhlcj8mbmJzcDsgd2l0aCByZXNwZWN0IHRvIEhvb2sgRmxhc2g/PC9GT05U PjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+ QUk6IENoYW5nZWQgZGVzY3JpcHRpb25zIHRvIGluZGljYXRlIHRoZSBtYXggbXVzdCANCmJlIGdy ZWF0ZXIgdGhhbiBtaW4uIE5vIGZvcm1hbCByZWxhdGlvbnNoaXAgYmV0d2VlbjxCUj5taW4vbWF4 IG1ha2UvYnJlYWsuIEhvb2sgDQpmbGFzaCBpcyBnZW5lcmFsbHkgbG9uZ2VyIGR1cmF0aW9uIHRo YW4gZGlhbCBwdWxzZSBidXQgdGhlcmUgaXMgbm8gZm9ybWFsIA0Kc3BlYy48L0ZPTlQ+PC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj42OCkgUHJv YmxlbXMgaW4gb2JqZWN0IGRlc2NyaXB0b3JzIChyZXZpZXcgDQpndWlkZWxpbmVzPC9GT05UPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6 IE5vIGNoYW5nZS4gQ29tbWVudCBhYm91dCBvYmplY3QgZGVzY3JpcHRvcnMgaXMgDQpub3QgY2xl YXIuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjY5KSBNSUIgcmV2aWV3IGd1 aWRlbGluZXMgYXBwZW5kaXggQy4mbmJzcDsgVGhlc2UgDQphcmU8QlI+b25seSAqc3VnZ2VzdGVk KiBuYW1pbmcgY29udmVudGlvbnMsIGJ1dCB0aGV5J3JlIHdvcnRoPEJSPmNvbnNpZGVyaW5nLCAN CmVzcGVjaWFsbHkgc2luY2UgdGhlIGN1cnJlbnQgZHJhZnQgaXMgbW9zdGx5PEJSPmNvbnNpc3Rh bnQuJm5ic3A7IEN1cnJlbnQgDQphYmVycmF0aW9ucyB0aGF0IEkgbm90aWNlZDo8L0ZPTlQ+PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mbmJz cDsmbmJzcDsgUEtUQy1JRVRGLVNJRy1NSUIgREVGSU5JVElPTlMgOjo9IA0KQkVHSU48QlI+YnV0 PEJSPiZuYnNwOyZuYnNwOyBwa3RjU2lnTWliIE1PRFVMRS1JREVOVElUWTwvRk9OVD48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZuYnNwOyZu YnNwOyBwa3RjU2lnTWliIA0KTU9EVUxFLUlERU5USVRZPEJSPmFuZDxCUj4mbmJzcDsmbmJzcDsg UGt0Y1NpZ1R5cGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOjo9IA0KVEVYVFVBTC1DT05WRU5U SU9OPEJSPmJ1dDxCUj4mbmJzcDsmbmJzcDsgUGt0Y0NvZGVjVHlwZSA6Oj0gDQpURVhUVUFMLUNP TlZFTlRJT048QlI+Jm5ic3A7Jm5ic3A7IFBrdGNSaW5nQ2FkZW5jZSZuYnNwOyZuYnNwOyA6Oj0g DQpURVhUVUFMLUNPTlZFTlRJT048L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4oQXNzdW1pbmc8QlI+Jm5ic3A7Jm5ic3A7IFRlbnRo ZEJtIDo6PSANClRFWFRVQUwtQ09OVkVOVElPTjxCUj5pcyBpbnRlbmRlZCBmb3IgZXh0ZXJuYWwg dXNlLik8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj4mbmJzcDsmbmJzcDsgcGt0Y1NpZ01pYiANCk1PRFVMRS1JREVOVElUWTxCUj5h bmQ8QlI+Jm5ic3A7Jm5ic3A7IHBrdGNTaWdNaWJPYmplY3RzIE9CSkVDVCBJREVOVElGSUVSIDo6 PSB7IA0KcGt0Y1NpZ01pYiAxIH08QlI+Jm5ic3A7Jm5ic3A7IHBrdGNTaWdEZXZDb25maWdPYmpl Y3RzIE9CSkVDVCBJREVOVElGSUVSIA0KOjo9PEJSPiZuYnNwOyZuYnNwOyBwa3RjU2lnTm90aWZp Y2F0aW9uJm5ic3A7IE9CSkVDVCBJREVOVElGSUVSIDo6PSB7IHBrdGNTaWdNaWIgDQowIH08QlI+ Jm5ic3A7Jm5ic3A7IHBrdGNTaWdDb25mb3JtYW5jZSZuYnNwOyZuYnNwOyBPQkpFQ1QgSURFTlRJ RklFUiA6Oj0geyANCnBrdGNTaWdNaWIgMiB9PEJSPiZuYnNwOyZuYnNwOyBwa3RjU2lnQ29tcGxp YW5jZXMmbmJzcDsmbmJzcDsgT0JKRUNUIElERU5USUZJRVIgDQo6Oj0geyBwa3RjU2lnQ29uZm9y bWFuY2UgMSB9PEJSPiZuYnNwOyZuYnNwOyANCnBrdGNTaWdHcm91cHMmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT0JKRUNUIElERU5USUZJRVIgOjo9IHsgDQpwa3Rj U2lnQ29uZm9ybWFuY2UgMiB9PEJSPmJ1dDxCUj4mbmJzcDsmbmJzcDsgcGt0Y05jc0VuZFBudENv bmZpZ09iamVjdHMgT0JKRUNUIA0KSURFTlRJRklFUiA6Oj08L0ZPTlQ+PC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mbmJzcDsmbmJzcDsgDQpw a3RjU2lnQ2FwYWJpbGl0eUVudHJ5Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KT0JKRUNULVRZUEU8QlI+ YnV0PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnBrdGNTaWduYWxp bmdJbmRleCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANClVuc2lnbmVkMzIsPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCnBrdGNTaWduYWxpbmdUeXBlJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KUGt0Y1NpZ1R5cGUsPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCnBrdGNTaWduYWxpbmdWZXJzaW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KU25tcEFkbWluU3RyaW5nLDxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpwa3RjU2lnbmFsaW5nVmVuZG9yRXh0ZW5z aW9uJm5ic3A7Jm5ic3A7IFNubXBBZG1pblN0cmluZzwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZuYnNwOyZuYnNwOyBwa3RjU2ln TWliIA0KTU9EVUxFLUlERU5USVRZPEJSPmJ1dDxCUj4mbmJzcDsmbmJzcDsgcGt0Y05jc0VuZFBu dENvbmZpZ1RhYmxlJm5ic3A7IA0KT0JKRUNULVRZUEU8QlI+YW5kPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnBrdGNOY3NFbmRQbnRDb25maWdDYWxsQWdlbnRJZCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANClNubXBBZG1pblN0cmluZyw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KcGt0Y05jc0VuZFBudENvbmZpZ0NhbGxBZ2VudFVkcFBvcnQmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpJbmV0UG9ydE51bWJlciw8 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KcGt0Y05jc0VuZFBudENv bmZpZ1BhcnRpYWxEaWFsVE8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpVbnNpZ25lZDMyLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQpwa3RjTmNzRW5kUG50Q29uZmlnQ3JpdGljYWxEaWFsVE8mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpVbnNp Z25lZDMyLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpwa3RjTmNz RW5kUG50Q29uZmlnQnVzeVRvbmVUTyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANClVuc2lnbmVkMzIs PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnBrdGNOY3NFbmRQbnRD b25maWdEaWFsVG9uZVRPJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KVW5zaWduZWQzMiw8QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KcGt0Y05jc0VuZFBudENvbmZpZ01l c3NhZ2VXYWl0aW5nVE8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQpVbnNpZ25lZDMyLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpw a3RjTmNzRW5kUG50Q29uZmlnT2ZmSG9va1dhcm5Ub25lVE8mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQpVbnNpZ25lZDMyLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQpwa3RjTmNzRW5kUG50Q29uZmlnUmluZ2luZ1RPJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0KVW5zaWduZWQzMiw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KcGt0Y05jc0VuZFBudENvbmZpZ1JpbmdCYWNrVE8mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQpVbnNpZ25lZDMyLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQpwa3RjTmNzRW5kUG50Q29uZmlnUmVvcmRlclRvbmVUTyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANClVuc2lnbmVkMzIsPEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnBrdGNOY3NFbmRQbnRDb25m aWdTdHV0dGVyRGlhbFRvbmVUTyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN ClVuc2lnbmVkMzIsPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnBr dGNOY3NFbmRQbnRDb25maWdUU01heCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANClVuc2lnbmVkMzIsPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANCnBrdGNOY3NFbmRQbnRDb25maWdNYXgxJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KVW5zaWduZWQzMiw8QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KcGt0Y05jc0VuZFBudENvbmZp Z01heDImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQpVbnNpZ25lZDMyLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQpwa3RjTmNzRW5kUG50Q29uZmlnTWF4MVFFbmFibGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpUcnV0 aFZhbHVlLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpwa3RjTmNz RW5kUG50Q29uZmlnTWF4MlFFbmFibGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpUcnV0aFZhbHVlLDxCUj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpwa3RjTmNzRW5kUG50Q29uZmln TVdEJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KVW5zaWduZWQzMiw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KcGt0Y05jc0VuZFBudENvbmZpZ1RkaW5pdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANClVuc2lnbmVkMzIsPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCnBrdGNOY3NFbmRQbnRDb25maWdUZG1pbiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANClVuc2lnbmVkMzIsPEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnBrdGNOY3NFbmRQbnRDb25m aWdUZG1heCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANClVuc2lnbmVkMzIsPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CnBrdGNOY3NFbmRQbnRDb25maWdSdG9NYXgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQpVbnNpZ25lZDMyLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQpwa3RjTmNzRW5kUG50Q29uZmlnUnRvSW5pdCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANClVuc2lnbmVkMzIsPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCnBrdGNOY3NFbmRQbnRDb25maWdMb25nRHVyYXRpb25LZWVw QWxpdmUmbmJzcDsmbmJzcDsgDQpVbnNpZ25lZDMyLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQpwa3RjTmNzRW5kUG50Q29uZmlnVGhpc3QmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpVbnNpZ25lZDMyLDxCUj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpwa3RjTmNzRW5kUG50Q29uZmlnU3Rh dHVzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KUm93U3Rh dHVzLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpwa3RjTmNzRW5k UG50Q29uZmlnQ2FsbFdhaXRpbmdNYXhSZXAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQpVbnNpZ25lZDMyLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQpwa3RjTmNzRW5kUG50Q29uZmlnQ2FsbFdhaXRpbmdEZWxheSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANClVuc2lnbmVkMzIsPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnBrdGNOY3NFbmRQbnRTdGF0dXNDYWxsSXBBZGRyZXNz VHlwZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCkluZXRBZGRyZXNzVHlw ZSw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KcGt0Y05jc0VuZFBu dFN0YXR1c0NhbGxJcEFkZHJlc3MmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpJbmV0QWRkcmVzcyw8QlI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KcGt0Y05jc0VuZFBudFN0YXR1c0Vycm9yJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KSU5URUdFUiw8QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KcGt0Y05jc0VuZFBudENvbmZp Z01pbkhvb2tGbGFzaCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANClVuc2lnbmVkMzIsPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCnBrdGNOY3NFbmRQbnRDb25maWdNYXhIb29rRmxhc2gmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQpVbnNpZ25lZDMyLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQpwa3RjTmNzRW5kUG50Q29uZmlnUHVsc2VEaWFsSW50ZXJkaWdpdFRpbWUgDQpVbnNpZ25l ZDMyLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpwa3RjTmNzRW5k UG50Q29uZmlnUHVsc2VEaWFsTWluTWFrZVRpbWUmbmJzcDsmbmJzcDsmbmJzcDsgDQpVbnNpZ25l ZDMyLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpwa3RjTmNzRW5k UG50Q29uZmlnUHVsc2VEaWFsTWF4TWFrZVRpbWUmbmJzcDsmbmJzcDsmbmJzcDsgDQpVbnNpZ25l ZDMyLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpwa3RjTmNzRW5k UG50Q29uZmlnUHVsc2VEaWFsTWluQnJlYWtUaW1lJm5ic3A7Jm5ic3A7IA0KVW5zaWduZWQzMiw8 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KcGt0Y05jc0VuZFBudENv bmZpZ1B1bHNlRGlhbE1heEJyZWFrVGltZSZuYnNwOyZuYnNwOyBVbnNpZ25lZDMyPC9GT05UPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6 IENoYW5nZWQgTUlCIG1vZHVsZSBuYW1lIHRvIHBrdGNJZXRmU2lnTWliLiBObyANCm90aGVyIG5h bWUgY2hhbmdlcyBtYWRlLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj43MCkgTUlCIHJldmlldyBndWlkZWxpbmVzIHNlY3Rpb24g My4yIHNlY29uZCANCnBhcmFncmFwaDwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFJOiBEdXBsaWNhdGUsIHNlZSBhYm92ZS4gT3Zl cnZpZXcgc2VjdGlvbiBjaGFuZ2VkIA0KdG8gaW5jbHVkZSBuYXJyYXRpdmUgb24gTUlCIG1vZHVs ZXMuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+NzEpIE1JQiByZXZpZXcgZ3VpZGVsaW5lcyBzZWN0aW9uIA0KMy43LjI8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QUk6IER1cGxpY2F0ZSwgc2VlIGFib3ZlLiBJ QU5BIHNlY3Rpb24gDQphZGRlZC48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKio8QlI+UmVmbGVjdG9yIA0KQ29tbWVudHM8QlI+KioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4xLiBDaGFuZ2VkIGRlZmF1bHQgdmFsdWUgb2YgDQpw a3RjTmNzRW5kUG50Q29uZmlnTWF4SG9va0ZsYXNoIGZyb20gNTAwIHRvIDgwMC48L0ZPTlQ+PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4yLiBB ZGRlZCB0ZXh0IHRvIGRlc2NyaXB0aW9uIHRvIGluZGljYXRlIA0Kd2hvbGV0b25lcmVwZWF0Y291 bnQgYW5kIHBrdGNTaWdEZXZUb25lU3RlYWR5IGRvIG5vdCBvdmVycmlkZSB0aGU8QlI+ZHVyYXRp b24gaW4gDQphbiBhc3NvY2lhdGVkIHRpbWVvdXQgKFRPKSBvYmplY3QuPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9QXJpYWwgDQpzaXplPTI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKjxCUj48U1BBTiANCmNsYXNzPTI0NzIxMTExOS0wMzA5MjAwND48 L1NQQU4+TzxTUEFOIA0KY2xhc3M9MjQ3MjExMTE5LTAzMDkyMDA0PnRoZXI8L1NQQU4+PEJSPioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTI0NzIxMTExOS0wMzA5MjAwND48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj5BZGRlZCBpbGJjIGFuZCBidjE2IA0KdG8gUGt0Y0NvZGVjVHlwZS48L0ZPTlQ+ PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0yNDcyMTExMTktMDMwOTIwMDQ+PEZPTlQg ZmFjZT1BcmlhbCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BB TiBjbGFzcz0yNDcyMTExMTktMDMwOTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+R29yZG9u IA0KQmVhY2hhbTwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTI0NzIxMTEx OS0wMzA5MjAwND48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Nb3Rvcm9sYSwgDQpJbmMuPC9GT05U PjwvU1BBTj48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C491EE.C81B7C68-- --===============1827062096== 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 --===============1827062096==-- From ipcdn-bounces@ietf.org Mon Sep 6 10:01:09 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 KAA05786 for ; Mon, 6 Sep 2004 10:01:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4K6i-0007L0-F1 for ipcdn-archive@ietf.org; Mon, 06 Sep 2004 10:04:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4K1O-0003hA-5b; Mon, 06 Sep 2004 09:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4JyJ-0003Dw-JQ for ipcdn@megatron.ietf.org; Mon, 06 Sep 2004 09:55:54 -0400 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 JAA05449 for ; Mon, 6 Sep 2004 09:55:49 -0400 (EDT) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4K1Y-0007Er-GE for ipcdn@ietf.org; Mon, 06 Sep 2004 09:59:12 -0400 Received: from comcast.net (h00045af3c79a.ne.client2.attbi.com[24.128.30.151]) by comcast.net (sccrmhc13) with SMTP id <2004090613551901600nb8bhe> (Authid: sawyerwd); Mon, 6 Sep 2004 13:55:19 +0000 Message-ID: <413C6C55.5A988CB5@comcast.net> Date: Mon, 06 Sep 2004 09:55:33 -0400 From: Wilson Sawyer X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" References: <7D5D48D2CAA3D84C813F5B154F43B15504BEAD80@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Content-Transfer-Encoding: 7bit Cc: wsawyer@ieee.org, richard_woundy@cable.comcast.com, "Ipcdn \(E-mail\)" , jf.mule@cablelabs.com Subject: [ipcdn] Re: AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Content-Transfer-Encoding: 7bit Bert - I hope to have Jean-Francois' comments and have them incorporated in time for submission by Wednesday. Here are specific responses to your comments (interspersed): The other changes so far include: -- IPR and copyright boilerplate changes -- updated reference to BPI+ spec. - Wilson "Wijnen, Bert (Bert)" wrote: > Wilson (and WG). Sorry that it took long (again) to do another > good check of this MIB document. > > I think this doc is basically OK now. I did find some small things > as per below, and it would be good to fix those at some point. > I propose that I issue an IETF Last Call, and that the below comments > are considered as the initial comments on such an IETF Last Call > and that you address them (or answer them) as part of any other comments > that may come up from IETF Last Call. > > Wilson/WG-chair(s), pls let me know if that sounds like a plan or if > you ratehr address/answer the below first. > > What I did find is: > > >From SMICng (strict checking). I thought I had reported this before ( see I > did, but you probably opted to not do it since it is not mandatory). > Oh well, I am including it anayway (again), because I really belive it > is betetr to include them. > > E: f(ipcdnsub.mi2), (478,15) Item "diffServMIBDataPathGroup" should be IMPORTed > E: f(ipcdnsub.mi2), (479,15) Item "diffServMIBClfrGroup" should be IMPORTed > E: f(ipcdnsub.mi2), (480,15) Item "diffServMIBClfrElementGroup" should be IMPORTed > E: f(ipcdnsub.mi2), (481,15) Item "diffServMIBMultiFieldClfrGroup" should be IMPORTed > E: f(ipcdnsub.mi2), (482,15) Item "diffServMIBActionGroup" should be IMPORTed > E: f(ipcdnsub.mi2), (483,15) Item "diffServMIBAlgDropGroup" should be IMPORTed > E: f(ipcdnsub.mi2), (484,15) Item "diffServMIBCounterGroup" should be IMPORTed > E: f(ipcdnsub.mi2), (487,11) Item "diffServDataPathStatus" should be IMPORTed > E: f(ipcdnsub.mi2), (493,11) Item "diffServClfrStatus" should be IMPORTed > E: f(ipcdnsub.mi2), (499,11) Item "diffServClfrElementStatus" should be IMPORTed > E: f(ipcdnsub.mi2), (506,11) Item "diffServMultiFieldClfrAddrType" should be IMPORTed > E: f(ipcdnsub.mi2), (512,11) Item "diffServMultiFieldClfrSrcAddr" should be IMPORTed > E: f(ipcdnsub.mi2), (518,11) Item "diffServMultiFieldClfrDstAddr" should be IMPORTed > E: f(ipcdnsub.mi2), (524,11) Item "diffServAlgDropStatus" should be IMPORTed > E: f(ipcdnsub.mi2), (530,11) Item "diffServDataPathStorage" should be IMPORTed > E: f(ipcdnsub.mi2), (536,11) Item "diffServClfrStorage" should be IMPORTed > E: f(ipcdnsub.mi2), (542,11) Item "diffServClfrElementStorage" should be IMPORTed > E: f(ipcdnsub.mi2), (548,11) Item "diffServMultiFieldClfrStorage" should be IMPORTed > E: f(ipcdnsub.mi2), (554,11) Item "diffServActionStorage" should be IMPORTed > E: f(ipcdnsub.mi2), (560,11) Item "diffServCountActStorage" should be IMPORTed > E: f(ipcdnsub.mi2), (566,11) Item "diffServAlgDropStorage" should be IMPORTed > E: f(ipcdnsub.mi2), (572,11) Item "diffServAlgDropType" should be IMPORTed > Added these to the IMPORTS clause as suggested. > > According to our MIB review guidelines (draft-ietf-ops-mib-review-guidelines-03.txt) > section 4.4, 3rd para: > Note that exemptions to this general requirement are granted by RFC > 2580 Sections 5.4.3 and 6.5.2 for descriptors of objects appearing in > the OBJECT clause of a MODULE-COMPLIANCE statement or in the > VARIATION clause of an AGENT-CAPABILITIES statement. Some MIB > compilers also grant exemptions to descriptors of notifications > appearing in a VARIATION clause and to descriptors of object groups > and notification groups referenced by a MANDATORY-GROUPS clause, a > GROUP clause, or an INCLUDES clause, although RFC 2580 (through > apparent oversight) does not mention those cases. The exemptions are > sometimes seen as unhelpful because they make IMPORTS rules more > complicated and inter-module dependencies less obvious than they > otherwise would be. External symbols referenced by compliance > statements and capabilities statements MAY therefore be listed in the > IMPORTS statement; if this is done, it SHOULD be done consistently. > > So it is not mandatory to do the IMPORTs, but in my view it will help in > many places with less warning/errors. So may I suggest to add the IMPORT > statement for the above. > > Also, all documents from whihc you IMPORT (implied or explicit) you must > put in normative reference section (which you have done). But all such > references MUST have a citation in the text (see MIB review guidelines, > (draft-ietf-ops-mib-review-guidelines-03.txt, sect 3.5): > 3.5. References Sections > > Section 4.7f of [RFC2223bis] specifies the requirements for the > references sections. In particular, there MUST be separate lists of > normative and informative references, each in a separate section. > The style SHOULD follow that of recently published RFCs. > > The standard MIB boilerplate available at > http://www.ops.ietf.org/mib-boilerplate.html includes lists of > normative and informative references that MUST appear in all IETF > specifications that contain MIB modules. If items from other MIB > modules appear in an IMPORTS statement in the Definitions section, > then the specifications containing those MIB modules MUST be included > in the list of normative references. When items are imported from an > IANA-maintained MIB module the corresponding normative reference > SHALL point to the on-line version of that MIB module. It is the > policy of the RFC Editor that all references must be cited in the > text; such citations MUST appear in the overview section where > documents containing imported definitions (other those already > mentioned in the MIB boilerplate) are required to be mentioned (cf. > Section 3.2). > > You have such a reference for RFC3291 (as required), but no citation > to [RFC3291] anywhere in the document. Can you pls add it at > some point in the text. > > I have some other nits/questions: > > 1. Desription clause of docsSubMgtCpeIpIndex states, towards the end: > > the table and the packet is forwarded. If the number of entries > equals the docsSubMgtCpeControlMaxCpeIp, AND > docsSubMgtCpeControlActive is true, then the packet is dropped. > Otherwise the packet is forwarded. " > > In the case that the packet is forwarded, will then also an entry be > created? That is not clear to me. May I suggest to add some text to > make that 100% clear? > That paragraph reworded to: If docsSubMgtCpeControlActive is true and a CMTS receives an IP packet from a CM that contains a source IP address which does not match one of the docsSubMgtCpeIpAddr entries for this CM, one of two things occurs. If the number of entries is less than docsSubMgtCpeControlMaxCpeIp, the source address is added to the table and the packet is forwarded. If the number of entries equals the docsSubMgtCpeControlMaxCpeIp, then the packet is dropped." > > 2. In description clause of docsSubMgtCmFilterTable it states: > > Zero is a distinguished value, indicating that the default > filtering action is to be taken, rather than that associated > > Mmm... a value for the table? I guess you mean that such a zero > value "in any of the columns of the table has a special maening. > Right? Might want to make that clearer. > now reads: For each of the columns in this table, zero is a distinguished value, indicating that the default filtering action is to be taken, rather than that associated with a filter group number. Zero is used if the filter group is not signaled by DOCSIS registration. > > 3. I see: > 1.3.6.1.2.1.xx.1.6 docsSubMgtCmFilterTable > 1.3.6.1.2.1.xx.1.6.1 docsSubMgtCmFilterEntry > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream > 1.3.6.1.2.1.xx.1.6.1.3 docsSubMgtCmFilterDownstream > 1.3.6.1.2.1.xx.1.6.1.4 docsSubMgtCmFilterUpstream > I think that for naming consistency, it might be better to rename > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream > into something like: > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtCmSubFilterDownstream > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtCMmubFilterUpstream > so as to make it clearer (from the name/descriptor) that these 2 > objects exists in the docsSubMgtCmFilterTable. renamed, per your last exchange with Eduardo, to: docsSubMgtCmFilterSubDownstream docsSubMgtCmFilterSubUpstream docsSubMgtCmFilterCmDownstream docsSubMgtCmFilterCmUpstream > > 4. I am a bit worried about the hard limit (range) of 1-255 for FilterGroupIndex. > Is this enough forever in the future? Or would it be wiser to use a larger > range (and limit via MODULE-COMPLIANCE, as you already do)? > I see it was larger before, and that you changed it to this smaller range. > So I guess you are doing this consciously. I was mistaken regarding the signaled width of this item - it is actually 2 octets. I changed the range to 1..65535 to match the actual signaled width. > > 5. In description clause of docsSubMgtFilterGroupIndex I see: > > the four. Because this is the only field in this table, it is > read-only, contrary to the usual SNMP custom of making indices > not-accessible. > > Probably better to change SNMP into SMI. > done. > > 6. In the Security Considerations, I think I would change the 2nd para > to make a positive statement, namely that you MUST follow recommendations > in sect 2.2.6 in order to deploy an effective filtering. changed to: Effective network filtering of TCP traffic requires that implementors MUST follow the recommendations in section 2.2.6. > > Thanks, > Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Sep 6 10:42:19 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 KAA09427 for ; Mon, 6 Sep 2004 10:42:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4KkY-0007wW-Eb for ipcdn-archive@ietf.org; Mon, 06 Sep 2004 10:45:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4Kcg-0005zW-VF; Mon, 06 Sep 2004 10:37:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4KX0-0005ER-6A for ipcdn@megatron.ietf.org; Mon, 06 Sep 2004 10:31:42 -0400 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 KAA08662 for ; Mon, 6 Sep 2004 10:31:40 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4KaF-0007oB-7n for ipcdn@ietf.org; Mon, 06 Sep 2004 10:35:03 -0400 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 i86EVchE026134 for ; Mon, 6 Sep 2004 09:31:39 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 6 Sep 2004 16:31:37 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550526B22B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Wilson Sawyer , "Wijnen, Bert (Bert)" Date: Mon, 6 Sep 2004 16:31:35 +0200 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: 7c1a129dc3801d79d40c5ca8dee767eb Cc: wsawyer@ieee.org, richard_woundy@cable.comcast.com, "Ipcdn \(E-mail\)" , jf.mule@cablelabs.com Subject: [ipcdn] RE: AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Looks good to me. Thanks, Bert > -----Original Message----- > From: Wilson Sawyer [mailto:sawyerwd@comcast.net] > Sent: Monday, September 06, 2004 15:56 > To: Wijnen, Bert (Bert) > Cc: wsawyer@ieee.org; Ipcdn (E-mail); jf.mule@cablelabs.com; > richard_woundy@cable.comcast.com > Subject: Re: AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt > > > Bert - I hope to have Jean-Francois' comments and have them > incorporated in time for > submission by Wednesday. Here are specific responses to your > comments (interspersed): > > The other changes so far include: > -- IPR and copyright boilerplate changes > -- updated reference to BPI+ spec. > > - Wilson > > "Wijnen, Bert (Bert)" wrote: > > > Wilson (and WG). Sorry that it took long (again) to do another > > good check of this MIB document. > > > > I think this doc is basically OK now. I did find some small things > > as per below, and it would be good to fix those at some point. > > I propose that I issue an IETF Last Call, and that the > below comments > > are considered as the initial comments on such an IETF Last Call > > and that you address them (or answer them) as part of any > other comments > > that may come up from IETF Last Call. > > > > Wilson/WG-chair(s), pls let me know if that sounds like a plan or if > > you ratehr address/answer the below first. > > > > What I did find is: > > > > >From SMICng (strict checking). I thought I had reported > this before ( see I > > did, but you probably opted to not do it since it is not mandatory). > > Oh well, I am including it anayway (again), because I > really belive it > > is betetr to include them. > > > > E: f(ipcdnsub.mi2), (478,15) Item > "diffServMIBDataPathGroup" should be IMPORTed > > E: f(ipcdnsub.mi2), (479,15) Item "diffServMIBClfrGroup" > should be IMPORTed > > E: f(ipcdnsub.mi2), (480,15) Item > "diffServMIBClfrElementGroup" should be IMPORTed > > E: f(ipcdnsub.mi2), (481,15) Item > "diffServMIBMultiFieldClfrGroup" should be IMPORTed > > E: f(ipcdnsub.mi2), (482,15) Item > "diffServMIBActionGroup" should be IMPORTed > > E: f(ipcdnsub.mi2), (483,15) Item > "diffServMIBAlgDropGroup" should be IMPORTed > > E: f(ipcdnsub.mi2), (484,15) Item > "diffServMIBCounterGroup" should be IMPORTed > > E: f(ipcdnsub.mi2), (487,11) Item > "diffServDataPathStatus" should be IMPORTed > > E: f(ipcdnsub.mi2), (493,11) Item "diffServClfrStatus" > should be IMPORTed > > E: f(ipcdnsub.mi2), (499,11) Item > "diffServClfrElementStatus" should be IMPORTed > > E: f(ipcdnsub.mi2), (506,11) Item > "diffServMultiFieldClfrAddrType" should be IMPORTed > > E: f(ipcdnsub.mi2), (512,11) Item > "diffServMultiFieldClfrSrcAddr" should be IMPORTed > > E: f(ipcdnsub.mi2), (518,11) Item > "diffServMultiFieldClfrDstAddr" should be IMPORTed > > E: f(ipcdnsub.mi2), (524,11) Item "diffServAlgDropStatus" > should be IMPORTed > > E: f(ipcdnsub.mi2), (530,11) Item > "diffServDataPathStorage" should be IMPORTed > > E: f(ipcdnsub.mi2), (536,11) Item "diffServClfrStorage" > should be IMPORTed > > E: f(ipcdnsub.mi2), (542,11) Item > "diffServClfrElementStorage" should be IMPORTed > > E: f(ipcdnsub.mi2), (548,11) Item > "diffServMultiFieldClfrStorage" should be IMPORTed > > E: f(ipcdnsub.mi2), (554,11) Item "diffServActionStorage" > should be IMPORTed > > E: f(ipcdnsub.mi2), (560,11) Item > "diffServCountActStorage" should be IMPORTed > > E: f(ipcdnsub.mi2), (566,11) Item > "diffServAlgDropStorage" should be IMPORTed > > E: f(ipcdnsub.mi2), (572,11) Item "diffServAlgDropType" > should be IMPORTed > > > > Added these to the IMPORTS clause as suggested. > > > > > > According to our MIB review guidelines > (draft-ietf-ops-mib-review-guidelines-03.txt) > > section 4.4, 3rd para: > > Note that exemptions to this general requirement are > granted by RFC > > 2580 Sections 5.4.3 and 6.5.2 for descriptors of objects > appearing in > > the OBJECT clause of a MODULE-COMPLIANCE statement or in the > > VARIATION clause of an AGENT-CAPABILITIES statement. Some MIB > > compilers also grant exemptions to descriptors of notifications > > appearing in a VARIATION clause and to descriptors of > object groups > > and notification groups referenced by a MANDATORY-GROUPS > clause, a > > GROUP clause, or an INCLUDES clause, although RFC 2580 (through > > apparent oversight) does not mention those cases. The > exemptions are > > sometimes seen as unhelpful because they make IMPORTS rules more > > complicated and inter-module dependencies less obvious than they > > otherwise would be. External symbols referenced by compliance > > statements and capabilities statements MAY therefore be > listed in the > > IMPORTS statement; if this is done, it SHOULD be done > consistently. > > > > So it is not mandatory to do the IMPORTs, but in my view it > will help in > > many places with less warning/errors. So may I suggest to > add the IMPORT > > statement for the above. > > > > Also, all documents from whihc you IMPORT (implied or > explicit) you must > > put in normative reference section (which you have done). > But all such > > references MUST have a citation in the text (see MIB review > guidelines, > > (draft-ietf-ops-mib-review-guidelines-03.txt, sect 3.5): > > 3.5. References Sections > > > > Section 4.7f of [RFC2223bis] specifies the requirements for the > > references sections. In particular, there MUST be > separate lists of > > normative and informative references, each in a separate section. > > The style SHOULD follow that of recently published RFCs. > > > > The standard MIB boilerplate available at > > http://www.ops.ietf.org/mib-boilerplate.html includes lists of > > normative and informative references that MUST appear in all IETF > > specifications that contain MIB modules. If items from other MIB > > modules appear in an IMPORTS statement in the > Definitions section, > > then the specifications containing those MIB modules > MUST be included > > in the list of normative references. When items are > imported from an > > IANA-maintained MIB module the corresponding normative reference > > SHALL point to the on-line version of that MIB module. It is the > > policy of the RFC Editor that all references must be cited in the > > text; such citations MUST appear in the overview section where > > documents containing imported definitions (other those already > > mentioned in the MIB boilerplate) are required to be > mentioned (cf. > > Section 3.2). > > > > You have such a reference for RFC3291 (as required), but no citation > > to [RFC3291] anywhere in the document. Can you pls add it at > > some point in the text. > > > > I have some other nits/questions: > > > > 1. Desription clause of docsSubMgtCpeIpIndex states, > towards the end: > > > > the table and the packet is forwarded. If the > number of entries > > equals the docsSubMgtCpeControlMaxCpeIp, AND > > docsSubMgtCpeControlActive is true, then the packet > is dropped. > > Otherwise the packet is forwarded. " > > > > In the case that the packet is forwarded, will then also > an entry be > > created? That is not clear to me. May I suggest to add > some text to > > make that 100% clear? > > > > That paragraph reworded to: > > If docsSubMgtCpeControlActive is true and a CMTS receives > an IP packet from a CM that contains a source IP address which > does not match one of the docsSubMgtCpeIpAddr entries for this > CM, one of two things occurs. If the number of entries is less > than docsSubMgtCpeControlMaxCpeIp, the source address is added to > the table and the packet is forwarded. If the number of entries > equals the docsSubMgtCpeControlMaxCpeIp, then the packet is > dropped." > > > > > 2. In description clause of docsSubMgtCmFilterTable it states: > > > > Zero is a distinguished value, indicating that the default > > filtering action is to be taken, rather than that associated > > > > Mmm... a value for the table? I guess you mean that such a zero > > value "in any of the columns of the table has a special maening. > > Right? Might want to make that clearer. > > > > now reads: > > For each of the columns in this table, zero is a distinguished > value, indicating that the default filtering action is to be > taken, rather than that associated with a filter group number. > Zero is used if the filter group is not signaled by DOCSIS > registration. > > > > > 3. I see: > > 1.3.6.1.2.1.xx.1.6 docsSubMgtCmFilterTable > > 1.3.6.1.2.1.xx.1.6.1 docsSubMgtCmFilterEntry > > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream > > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream > > 1.3.6.1.2.1.xx.1.6.1.3 docsSubMgtCmFilterDownstream > > 1.3.6.1.2.1.xx.1.6.1.4 docsSubMgtCmFilterUpstream > > I think that for naming consistency, it might be better to rename > > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream > > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream > > into something like: > > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtCmSubFilterDownstream > > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtCMmubFilterUpstream > > so as to make it clearer (from the name/descriptor) that these 2 > > objects exists in the docsSubMgtCmFilterTable. > > renamed, per your last exchange with Eduardo, to: > > docsSubMgtCmFilterSubDownstream > docsSubMgtCmFilterSubUpstream > docsSubMgtCmFilterCmDownstream > docsSubMgtCmFilterCmUpstream > > > > > 4. I am a bit worried about the hard limit (range) of 1-255 > for FilterGroupIndex. > > Is this enough forever in the future? Or would it be > wiser to use a larger > > range (and limit via MODULE-COMPLIANCE, as you already do)? > > I see it was larger before, and that you changed it to > this smaller range. > > So I guess you are doing this consciously. > > I was mistaken regarding the signaled width of this item - it > is actually 2 octets. I > changed the range to 1..65535 to match the actual signaled width. > > > > > 5. In description clause of docsSubMgtFilterGroupIndex I see: > > > > the four. Because this is the only field in this table, it is > > read-only, contrary to the usual SNMP custom of > making indices > > not-accessible. > > > > Probably better to change SNMP into SMI. > > > > done. > > > > > 6. In the Security Considerations, I think I would change > the 2nd para > > to make a positive statement, namely that you MUST > follow recommendations > > in sect 2.2.6 in order to deploy an effective filtering. > > changed to: > > Effective network filtering of TCP traffic requires that implementors > MUST follow the recommendations in section 2.2.6. > > > > > > Thanks, > > Bert > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Sep 7 14:13: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 OAA16902 for ; Tue, 7 Sep 2004 14:13:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4kWK-0002LF-7h for ipcdn-archive@ietf.org; Tue, 07 Sep 2004 14:16:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4k5U-0000QT-Gw; Tue, 07 Sep 2004 13:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4jyJ-0005ba-IU for ipcdn@megatron.ietf.org; Tue, 07 Sep 2004 13:41:36 -0400 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 NAA13911 for ; Tue, 7 Sep 2004 13:41:31 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4k1m-0001XG-GK for ipcdn@ietf.org; Tue, 07 Sep 2004 13:45:11 -0400 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 i87HeiPJ027874; Tue, 7 Sep 2004 11:40:44 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Sep 2004 11:40:44 -0600 Message-ID: Thread-Topic: Partial review of draft-ietf-ipcdn-subscriber-mib-14.txt Thread-Index: AcSUGSvRf4zle28pSAaa6zfjg/xMjwA5PQEw From: "Jean-Francois Mule" To: "Wilson Sawyer" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 2fe944273194be3112d13b31c91e6941 Content-Transfer-Encoding: quoted-printable Cc: "Wijnen, Bert \(Bert\)" , wsawyer@ieee.org, "Richard Woundy @ Comcast" , "Ipcdn \(E-mail\)" Subject: [ipcdn] Partial review of draft-ietf-ipcdn-subscriber-mib-14.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 Content-Transfer-Encoding: quoted-printable Hi Wilson, Thanks for the update. Below are a couple of editorial and technical comments based on draft 14 and the alpha draft15 you provided to me. --- 1. I-D boilerplate http://www.ietf.org/ID-Checklist.html Per our discussion, see ID Checklist, section 2.2, especially, items 1, 10, 11 and 12. --- 2. Use of MUST, other requirement verbs and reference to 2119 Since you have some requirements using capital MUST verbs, you should add a section like this: 3. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. And add a normative reference for: [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. --- 3. Full spelling of the wg in the ORGANIZATION: See MIB review guidelines section 4.5. http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines -03.txt < ORGANIZATION "IETF IPCDN Working Group" > ORGANIZATION "IETF IP over Cable Data Network (IPCDN)=20 > Working Group" --- 4. Nits - consider using "MIB module" instead of "MIB" when you mean the subs. mgmt part of the MIB - DOCSIS should be all capital (global search/replace, I found one bad occurrence) -=20 --- 5. Technical - important Since RFC 2669 will be replaced by the cable device v2 RFC at publication, did you double-check that all the objects you are referencing (or using) from RFC 2669 are still "current" in the latest ID? In section 2.2.1, I found 1 instance where the above comment raises a concern for docsDevCpeIp (my comments start with #): o docsDevCpeEnroll # ok, this object is current. o docsDevCpeIpMax # ok, this object is current. o docsDevCpeIp # this one object is now deprecated from the RFC update. We should # probably mention the replacement: docsDevCpeInetTable table or # its equivalent in that table or mention both. --- 6. Add an IANA consideration section A new IANA consideration section is now required, see ID checklist 2.2 #7.b. Suggestion: The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: =20 Descriptor OBJECT IDENTIFIER Value ---------- ----------------------- docsSubMgt { mib-2 xx } =20 Editor's Note (to be removed prior to publication): the IANA is requested to assign a value for xx under the mib-2 subtree and to record the assignment in the SMI Numbers registry. When the assignment has been made, the RFC Editor is asked to replace xx (here and in the MIB module) with the assigned value and to remove this note. --- 7 . CableLabs Spec references: add archives URL For all CableLabs Spec' references, also add the following URL: http://www.cablelabs.com/specifications/archives/ (the main reason here is that if some specs get updated, readers will be able to find the referenced versions in the archive repository). --- 8. SMIC compilation errors Compiles clean except for those kinds of compilation errors: E: f(subs.mi2), (525,25) a bit or enum list is not allowed on a TC For e.g. MODULE DIFFSERV-MIB -- RFC3289 MANDATORY-GROUPS { diffServMIBDataPathGroup, diffServMIBClfrGroup, diffServMIBClfrElementGroup, diffServMIBMultiFieldClfrGroup, diffServMIBActionGroup, diffServMIBAlgDropGroup, diffServMIBCounterGroup } OBJECT diffServDataPathStatus -- same as RFC3289 SYNTAX RowStatus { active(1) } -- ># E: f(subs.mi2), (525,25) a bit or enum list is not allowed on a TC WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." I don't see the issue and don't have time to dig but the SMI you have looks good to me and is in sync with what is in RFC 3289. Just wanted to point this out though. That's all I could see in the time I could allocate for the review. Jean-Francois. > -----Original Message----- > From: Wilson Sawyer [mailto:sawyerwd@comcast.net]=20 > Sent: Monday, September 06, 2004 7:56 AM > To: Wijnen, Bert (Bert) > Cc: wsawyer@ieee.org; Ipcdn (E-mail); Jean-Francois Mule;=20 > Richard Woundy @ Comcast > Subject: Re: AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt >=20 >=20 > Bert - I hope to have Jean-Francois' comments and have them=20 > incorporated in time for submission by Wednesday. Here are=20 > specific responses to your comments (interspersed): >=20 > The other changes so far include: > -- IPR and copyright boilerplate changes > -- updated reference to BPI+ spec. >=20 > - Wilson >=20 > "Wijnen, Bert (Bert)" wrote: >=20 > > Wilson (and WG). Sorry that it took long (again) to do another good=20 > > check of this MIB document. > > > > I think this doc is basically OK now. I did find some small=20 > things as=20 > > per below, and it would be good to fix those at some point.=20 > I propose=20 > > that I issue an IETF Last Call, and that the below comments are=20 > > considered as the initial comments on such an IETF Last=20 > Call and that=20 > > you address them (or answer them) as part of any other=20 > comments that=20 > > may come up from IETF Last Call. > > > > Wilson/WG-chair(s), pls let me know if that sounds like a=20 > plan or if=20 > > you ratehr address/answer the below first. > > > > What I did find is: > > > > >From SMICng (strict checking). I thought I had reported=20 > this before (=20 > > >see I > > did, but you probably opted to not do it since it is not=20 > mandatory).=20 > > Oh well, I am including it anayway (again), because I=20 > really belive it=20 > > is betetr to include them. > > > > E: f(ipcdnsub.mi2), (478,15) Item=20 > "diffServMIBDataPathGroup" should be IMPORTed > > E: f(ipcdnsub.mi2), (479,15) Item "diffServMIBClfrGroup"=20 > should be IMPORTed > > E: f(ipcdnsub.mi2), (480,15) Item=20 > "diffServMIBClfrElementGroup" should be IMPORTed > > E: f(ipcdnsub.mi2), (481,15) Item=20 > "diffServMIBMultiFieldClfrGroup" should be IMPORTed > > E: f(ipcdnsub.mi2), (482,15) Item=20 > "diffServMIBActionGroup" should be IMPORTed > > E: f(ipcdnsub.mi2), (483,15) Item=20 > "diffServMIBAlgDropGroup" should be IMPORTed > > E: f(ipcdnsub.mi2), (484,15) Item=20 > "diffServMIBCounterGroup" should be IMPORTed > > E: f(ipcdnsub.mi2), (487,11) Item=20 > "diffServDataPathStatus" should be IMPORTed > > E: f(ipcdnsub.mi2), (493,11) Item "diffServClfrStatus"=20 > should be IMPORTed > > E: f(ipcdnsub.mi2), (499,11) Item=20 > "diffServClfrElementStatus" should be IMPORTed > > E: f(ipcdnsub.mi2), (506,11) Item=20 > "diffServMultiFieldClfrAddrType" should be IMPORTed > > E: f(ipcdnsub.mi2), (512,11) Item=20 > "diffServMultiFieldClfrSrcAddr" should be IMPORTed > > E: f(ipcdnsub.mi2), (518,11) Item=20 > "diffServMultiFieldClfrDstAddr" should be IMPORTed > > E: f(ipcdnsub.mi2), (524,11) Item "diffServAlgDropStatus"=20 > should be IMPORTed > > E: f(ipcdnsub.mi2), (530,11) Item=20 > "diffServDataPathStorage" should be IMPORTed > > E: f(ipcdnsub.mi2), (536,11) Item "diffServClfrStorage"=20 > should be IMPORTed > > E: f(ipcdnsub.mi2), (542,11) Item=20 > "diffServClfrElementStorage" should be IMPORTed > > E: f(ipcdnsub.mi2), (548,11) Item=20 > "diffServMultiFieldClfrStorage" should be IMPORTed > > E: f(ipcdnsub.mi2), (554,11) Item "diffServActionStorage"=20 > should be IMPORTed > > E: f(ipcdnsub.mi2), (560,11) Item=20 > "diffServCountActStorage" should be IMPORTed > > E: f(ipcdnsub.mi2), (566,11) Item=20 > "diffServAlgDropStorage" should be IMPORTed > > E: f(ipcdnsub.mi2), (572,11) Item "diffServAlgDropType" should be=20 > > IMPORTed > > >=20 > Added these to the IMPORTS clause as suggested. >=20 >=20 > > > > According to our MIB review guidelines=20 > > (draft-ietf-ops-mib-review-guidelines-03.txt) > > section 4.4, 3rd para: > > Note that exemptions to this general requirement are=20 > granted by RFC > > 2580 Sections 5.4.3 and 6.5.2 for descriptors of objects=20 > appearing in > > the OBJECT clause of a MODULE-COMPLIANCE statement or in the > > VARIATION clause of an AGENT-CAPABILITIES statement. Some MIB > > compilers also grant exemptions to descriptors of notifications > > appearing in a VARIATION clause and to descriptors of=20 > object groups > > and notification groups referenced by a MANDATORY-GROUPS=20 > clause, a > > GROUP clause, or an INCLUDES clause, although RFC 2580 (through > > apparent oversight) does not mention those cases. The=20 > exemptions are > > sometimes seen as unhelpful because they make IMPORTS rules more > > complicated and inter-module dependencies less obvious than they > > otherwise would be. External symbols referenced by compliance > > statements and capabilities statements MAY therefore be=20 > listed in the > > IMPORTS statement; if this is done, it SHOULD be done=20 > consistently. > > > > So it is not mandatory to do the IMPORTs, but in my view it=20 > will help=20 > > in many places with less warning/errors. So may I suggest=20 > to add the=20 > > IMPORT statement for the above. > > > > Also, all documents from whihc you IMPORT (implied or explicit) you=20 > > must put in normative reference section (which you have=20 > done). But all=20 > > such references MUST have a citation in the text (see MIB review=20 > > guidelines, (draft-ietf-ops-mib-review-guidelines-03.txt, sect 3.5): > > 3.5. References Sections > > > > Section 4.7f of [RFC2223bis] specifies the requirements for the > > references sections. In particular, there MUST be=20 > separate lists of > > normative and informative references, each in a separate section. > > The style SHOULD follow that of recently published RFCs. > > > > The standard MIB boilerplate available at > > http://www.ops.ietf.org/mib-boilerplate.html includes lists of > > normative and informative references that MUST appear in all IETF > > specifications that contain MIB modules. If items from other MIB > > modules appear in an IMPORTS statement in the=20 > Definitions section, > > then the specifications containing those MIB modules=20 > MUST be included > > in the list of normative references. When items are=20 > imported from an > > IANA-maintained MIB module the corresponding normative reference > > SHALL point to the on-line version of that MIB module. It is the > > policy of the RFC Editor that all references must be cited in the > > text; such citations MUST appear in the overview section where > > documents containing imported definitions (other those already > > mentioned in the MIB boilerplate) are required to be=20 > mentioned (cf. > > Section 3.2). > > > > You have such a reference for RFC3291 (as required), but no=20 > citation=20 > > to [RFC3291] anywhere in the document. Can you pls add it at some=20 > > point in the text. > > > > I have some other nits/questions: > > > > 1. Desription clause of docsSubMgtCpeIpIndex states,=20 > towards the end: > > > > the table and the packet is forwarded. If the=20 > number of entries > > equals the docsSubMgtCpeControlMaxCpeIp, AND > > docsSubMgtCpeControlActive is true, then the packet=20 > is dropped. > > Otherwise the packet is forwarded. " > > > > In the case that the packet is forwarded, will then also=20 > an entry be > > created? That is not clear to me. May I suggest to add=20 > some text to > > make that 100% clear? > > >=20 > That paragraph reworded to: >=20 > If docsSubMgtCpeControlActive is true and a CMTS receives > an IP packet from a CM that contains a source IP address which > does not match one of the docsSubMgtCpeIpAddr entries for this > CM, one of two things occurs. If the number of entries is less > than docsSubMgtCpeControlMaxCpeIp, the source address is added to > the table and the packet is forwarded. If the number of entries > equals the docsSubMgtCpeControlMaxCpeIp, then the packet is > dropped." >=20 > > > > 2. In description clause of docsSubMgtCmFilterTable it states: > > > > Zero is a distinguished value, indicating that the default > > filtering action is to be taken, rather than that associated > > > > Mmm... a value for the table? I guess you mean that such a zero > > value "in any of the columns of the table has a special maening. > > Right? Might want to make that clearer. > > >=20 > now reads: >=20 > For each of the columns in this table, zero is a distinguished > value, indicating that the default filtering action is to be > taken, rather than that associated with a filter group number. > Zero is used if the filter group is not signaled by DOCSIS > registration. >=20 > > > > 3. I see: > > 1.3.6.1.2.1.xx.1.6 docsSubMgtCmFilterTable > > 1.3.6.1.2.1.xx.1.6.1 docsSubMgtCmFilterEntry > > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream > > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream > > 1.3.6.1.2.1.xx.1.6.1.3 docsSubMgtCmFilterDownstream > > 1.3.6.1.2.1.xx.1.6.1.4 docsSubMgtCmFilterUpstream > > I think that for naming consistency, it might be better to rename > > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream > > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream > > into something like: > > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtCmSubFilterDownstream > > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtCMmubFilterUpstream > > so as to make it clearer (from the name/descriptor) that these 2 > > objects exists in the docsSubMgtCmFilterTable. >=20 > renamed, per your last exchange with Eduardo, to: >=20 > docsSubMgtCmFilterSubDownstream > docsSubMgtCmFilterSubUpstream > docsSubMgtCmFilterCmDownstream > docsSubMgtCmFilterCmUpstream >=20 > > > > 4. I am a bit worried about the hard limit (range) of 1-255=20 > for FilterGroupIndex. > > Is this enough forever in the future? Or would it be=20 > wiser to use a larger > > range (and limit via MODULE-COMPLIANCE, as you already do)? > > I see it was larger before, and that you changed it to=20 > this smaller range. > > So I guess you are doing this consciously. >=20 > I was mistaken regarding the signaled width of this item - it=20 > is actually 2 octets. I changed the range to 1..65535 to=20 > match the actual signaled width. >=20 > > > > 5. In description clause of docsSubMgtFilterGroupIndex I see: > > > > the four. Because this is the only field in this table, it is > > read-only, contrary to the usual SNMP custom of=20 > making indices > > not-accessible. > > > > Probably better to change SNMP into SMI. > > >=20 > done. >=20 > > > > 6. In the Security Considerations, I think I would change=20 > the 2nd para > > to make a positive statement, namely that you MUST=20 > follow recommendations > > in sect 2.2.6 in order to deploy an effective filtering. >=20 > changed to: >=20 > Effective network filtering of TCP traffic requires that=20 > implementors MUST follow the recommendations in section 2.2.6. >=20 >=20 > > > > Thanks, > > Bert >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Sep 8 16:24:01 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 QAA15215 for ; Wed, 8 Sep 2004 16:24:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C592n-00013s-Ua for ipcdn-archive@ietf.org; Wed, 08 Sep 2004 16:27:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C58XX-0007Yy-K6; Wed, 08 Sep 2004 15:55:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C58F4-0006JN-CO; Wed, 08 Sep 2004 15:36:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09820; Wed, 8 Sep 2004 15:36:28 -0400 (EDT) Message-Id: <200409081936.PAA09820@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 08 Sep 2004 15:36:28 -0400 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-signaling-06.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: a8a20a483a84f747e56475e290ee868e --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 : Network-Based Call Signaling (NCS) Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs) Author(s) : G. Beacham, et al. Filename : draft-ietf-ipcdn-pktc-signaling-06.txt Pages : 59 Date : 2004-9-8 This memo defines the Signaling Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it provides a common data and format representation for PacketCable/IPCablecom compliant Multimedia Terminal Adapter devices. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2. The set of objects are consistent with the SNMP framework and existing SNMP standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-06.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-pktc-signaling-06.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-pktc-signaling-06.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-9-8154337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-pktc-signaling-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-pktc-signaling-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-8154337.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 Thu Sep 9 16:28: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 QAA24151 for ; Thu, 9 Sep 2004 16:28:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5VbE-00033d-5h for ipcdn-archive@ietf.org; Thu, 09 Sep 2004 16:32:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Uii-0000BL-8H; Thu, 09 Sep 2004 15:36:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Ueg-0006Zg-5c; Thu, 09 Sep 2004 15:32:26 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16163; Thu, 9 Sep 2004 15:32:24 -0400 (EDT) Message-Id: <200409091932.PAA16163@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 09 Sep 2004 15:32:24 -0400 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-14.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --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-14.txt Pages : 87 Date : 2004-9-9 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 DOCSIS1.1 and DOCSIS 2.0 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-14.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-14.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-14.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-9-9145117.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-bpiplus-mib-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-bpiplus-mib-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-9145117.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 Fri Sep 17 11:18: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 LAA11939 for ; Fri, 17 Sep 2004 11:18:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8KaX-00047d-R0 for ipcdn-archive@ietf.org; Fri, 17 Sep 2004 11:23:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8KHg-0005Yt-Bv; Fri, 17 Sep 2004 11:04:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8KGw-0005JV-1A for ipcdn@megatron.ietf.org; Fri, 17 Sep 2004 11:03:38 -0400 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 LAA11238 for ; Fri, 17 Sep 2004 11:03:35 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8KMR-0003pJ-D1 for ipcdn@ietf.org; Fri, 17 Sep 2004 11:09:22 -0400 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 i8HF31kH017340 for ; Fri, 17 Sep 2004 09:03:02 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Sep 2004 09:03:01 -0600 Message-ID: Thread-Topic: Internet-Draft Submission Cutoff Dates for the 61st IETF Meeting in Washington, DC, USA Thread-Index: AcScwsyEstK1BTvcRSSmQNo68g/sJQABI2zw From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Internet-Draft Submission Cutoff Dates for the 61st IETF Meeting in Washington, DC, USA 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: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable fyi -----Original Message----- From: ietf-secretariat@ietf.org [mailto:ietf-secretariat@ietf.org]=20 Sent: Friday, September 17, 2004 8:23 AM To: ietf-announce@ietf.org Subject: Internet-Draft Submission Cutoff Dates for the 61st IETF Meeting inWashington, DC, USA There are two (2) Internet-Draft cutoff dates for the 61st IETF Meeting=20 in Washington, DC, USA: October 18: Cutoff Date for Initial (i.e., -00) Internet-Draft Submissions=20 All initial Internet-Drafts (-00) must be submitted by Monday, October 18 at 9:00 AM ET.=20 As always, all initial submissions (-00) with a filename beginning with "draft-ietf"=20 must be approved by the appropriate WG Chair before they can be processed or announced.=20 WG Chair approval must be received by Monday, October 11 at 9:00 AM ET. October 25: Cutoff Date for Revised (i.e., -01 and higher) Internet-Draft Submissions=20 All revised Internet-Drafts (-01 and higher) must be submitted by Monday, October 25=20 at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not=20 be made available in the Internet-Drafts directory or announced, and will have to be=20 resubmitted. Please do not wait until the last minute to submit. The Secretariat will=20 begin accepting Internet-Draft submissions starting Monday, November 08 at 9:00 AM ET,=20 but may not post or announce them until Monday, November 15. Thank you for your understanding and cooperation. If you have any questions or concerns,=20 then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 61st IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_61.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Sep 20 16:40:00 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 QAA14504 for ; Mon, 20 Sep 2004 16:40:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9V3M-0008OO-KC for ipcdn-archive@ietf.org; Mon, 20 Sep 2004 16:46:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9UAI-0000iY-Sv; Mon, 20 Sep 2004 15:49:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9U2q-0005Nm-17; Mon, 20 Sep 2004 15:41:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05292; Mon, 20 Sep 2004 15:41:50 -0400 (EDT) Message-Id: <200409201941.PAA05292@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, 20 Sep 2004 15:41:50 -0400 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-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 Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management Author(s) : W. Sawyer Filename : draft-ietf-ipcdn-subscriber-mib-15.txt Pages : 25 Date : 2004-9-20 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-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-subscriber-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-subscriber-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-9-20153122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-subscriber-mib-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-subscriber-mib-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-20153122.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 Thu Sep 23 08:18:02 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 IAA05968 for ; Thu, 23 Sep 2004 08:18:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CASem-0006dx-7Y for ipcdn-archive@ietf.org; Thu, 23 Sep 2004 08:25:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CASVV-0000SI-QQ; Thu, 23 Sep 2004 08:15:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CASSS-00004w-Qj for ipcdn@megatron.ietf.org; Thu, 23 Sep 2004 08:12:20 -0400 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 IAA05635 for ; Thu, 23 Sep 2004 08:12:19 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CASZF-0006XG-Aj for ipcdn@ietf.org; Thu, 23 Sep 2004 08:19:21 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i8NCBlns026655 for ; Thu, 23 Sep 2004 07:11:48 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Sep 2004 14:11:47 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79CC1@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Date: Thu, 23 Sep 2004 14:11:42 +0200 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: 9466e0365fc95844abaf7c3f15a05c7d Subject: [ipcdn] FW: COMMENT: draft-ietf-ipcdn-subscriber-mib-15 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: 97adf591118a232206bdb5a27b217034 I am forwarding IESG comments as I receive them. Answers are fine. Pls do not yet submit a changed document untill we get ALL the IESG comments. Should be around Tuesday next week. Bert -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Wednesday, September 22, 2004 21:47 To: iesg@ietf.org Subject: COMMENT: draft-ietf-ipcdn-subscriber-mib-15 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management (Proposed Standard) COMMENT The 2nd paragraph of Section 9 says: : : Effective network filtering of TCP traffic requires that implementors : MUST follow the recommendations in section 3.2.6. : I suggest replacement text: For network filtering of TCP traffic to be effective, implementors MUST follow the recommendations in section 3.2.6. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Sep 23 08:19:29 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 IAA06060 for ; Thu, 23 Sep 2004 08:19:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CASgB-0006fP-9d for ipcdn-archive@ietf.org; Thu, 23 Sep 2004 08:26:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CASVW-0000SN-0H; Thu, 23 Sep 2004 08:15:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CASSm-00005u-E8 for ipcdn@megatron.ietf.org; Thu, 23 Sep 2004 08:12:40 -0400 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 IAA05654 for ; Thu, 23 Sep 2004 08:12:38 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CASZZ-0006XR-1R for ipcdn@ietf.org; Thu, 23 Sep 2004 08:19:41 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i8NCC7Sw026833 for ; Thu, 23 Sep 2004 07:12:08 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Sep 2004 14:12:07 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79CC2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Date: Thu, 23 Sep 2004 14:12:04 +0200 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: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 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: f66b12316365a3fe519e75911daf28a8 I am forwarding IESG comments as I receive them. Answers are fine. Pls do not yet submit a changed document untill we get ALL the IESG comments. Should be around Tuesday next week. Bert -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Wednesday, September 22, 2004 21:51 To: iesg@ietf.org Subject: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus (Proposed Standard) DISCUSS The definition of docsBpi2CmPublicKey begins: : : docsBpi2CmPublicKey OBJECT-TYPE : SYNTAX OCTET STRING (SIZE (74|106|140|204|270)) : The selection of these few octet string sizes is inappropriate. PKCS #1 encoding of an RSA public key is a SEQUENCE of two INTEGERs. One example of an acceptable RSA public key that cannot be accommodated by this definition follows. It is 139 octets. 0 30 137: SEQUENCE { 3 02 129: INTEGER : 00 DD D8 49 85 DD 76 BE 9C 64 D2 6A 0C B3 3A 14 : 0B 37 A5 60 97 90 40 3D C0 C6 9C 01 FB D0 6F B6 : 49 56 E5 1A 44 F7 C7 1D 23 4C 91 A2 6F BE F7 9A : D0 5F F0 88 9A 01 A2 0A 20 78 22 45 1A 9D 77 8F : CA 14 3E 75 44 3C D6 67 16 21 E5 42 B5 EC BF 62 : 6C 09 0E 4D D9 79 D0 55 82 5C 9C FD B1 B9 B6 A6 : 5B 42 83 FA 90 1E 74 3F 5C 1C 1F D8 73 40 94 3C : 9A 9F 2A 04 FE ED 8C 69 C3 0E 10 A6 3B 0B A7 A4 : CD 135 02 3: INTEGER 65537 : } I do not believe that a five (or even ten) specific sizes can be chosen that accommodate all valid RSA public keys. The definition of docsBpi2CmtsAuthCmPublicKey has the same problem. The definition of docsBpi2CmTEKDataEncryptAlg begins: : : docsBpi2CmTEKDataEncryptAlg OBJECT-TYPE : SYNTAX INTEGER { : none(0), : des56CbcMode(1), : des40CbcMode(2) : } : And, the definition of docsBpi2CmTEKDataAuthentAlg begins: : : docsBpi2CmTEKDataAuthentAlg OBJECT-TYPE : SYNTAX INTEGER { : none(0) : } : These same values are also used in the docsBpi2CmCryptoSuiteDataEncryptAlg, docsBpi2CmCryptoSuiteDataAuthentAlg, docsBpi2CmtsTEKDataEncryptAlg, docsBpi2CmtsTEKDataAuthentAlg, docsBpi2CmtsIpMulticastDataEncryptAlg, and docsBpi2CmtsIpMulticastDataAuthentAlg definitions. None of the encryption algorithm choices is a strong encryption algorithm. Also, the encryption algorithm choice do not provide integrity, so they ought to be used with an integrity algorithm, but none are specified. Can we get a strong encryption algorithm added to the list? Can we get an strong integrity algorithm specified? If not, the last few paragraphs of of the Security Considerations need to be made much more forceful. COMMENT Please delete the second paragraph of the Abstract prior to publication as an RFC. In the Abstract: s/DOCSIS1.1/DOCSIS 1.1/ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Sep 23 12:57: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 MAA00990 for ; Thu, 23 Sep 2004 12:57:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAX1b-0004Tt-Oo for ipcdn-archive@ietf.org; Thu, 23 Sep 2004 13:04:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAWhr-0001F7-7k; Thu, 23 Sep 2004 12:44:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAWYC-0005nZ-DN for ipcdn@megatron.ietf.org; Thu, 23 Sep 2004 12:34:33 -0400 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 MAA28279 for ; Thu, 23 Sep 2004 12:34:29 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAWex-0003aK-0O for ipcdn@ietf.org; Thu, 23 Sep 2004 12:41:35 -0400 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 i8NGXskH002381; Thu, 23 Sep 2004 10:33:54 -0600 (MDT) 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: RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 Date: Thu, 23 Sep 2004 10:33:54 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F03E8F8@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 Thread-Index: AcShZ6uO0bvYOCs/T0eA+x9m9M2IsAAGpqfg From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 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: bcd240e64c427d3d3617cfc704e7fd7f Content-Transfer-Encoding: quoted-printable Bert, I am not sure if this is just perception from the parser output: Below is a similar public key pair that indicates the offsets line by line=20 Ofsset 135 (zero based) indicates the start of the public exponent (5 bytes) Offset 140 indicates the offset of byte 141 Here is a 140 octets PKCS#1 public key pair Off =20 0 30 81 89 3 02 81 81=20 6 00 cf 32 d2 0b 31 d5 47 f9 73 98 8a 83 62 e1 fb 22 dc e6 3b 0b 4b b8 d6 3b 35 31 5d dc 7a 72 89 fe 38 e9 18 20 c7 83 7b 76 d7 75 36 91 72 f6 17 8f 5a 54 59 68 28 87 0d 9b 25 88 52 7b cb a2 52 10 26 89 70 69 4f 0d d1 d9 2d 71 aa 03 35 e2 81 5d b0 31 8b 86 4c 3d e9 0a df b4 8c e4 99 7f d1 47 86 5b 9e 3d=20 102 07 c3 a8 58 f3 2f f2 d3 09 a6 e3 e5 4c 53 23 44=20 118 46 6c 6b 03 ae 90 76 38 60 de 23 02 f9 c0 3b e4=20 134 ed 135 02 03 01 00 01 140 Bytes size =3D 3 + 3 + 129 + 5 =3D 140 And the output from for the equivalent binary file=20 from openssl asn1parse command: 0:d=3D0 hl=3D3 l=3D 137 cons: SEQUENCE 3:d=3D1 hl=3D3 l=3D 129 prim: INTEGER =20 :CF32D20B31D547F973988A8362E1FBDC E63B0B4BB8D63B35315DDC7A7289FEE9 1820C7837B76D775369172F6178F5A59 6828870D9B2588527BCBA25210268969 4F0DD1D92D71AA0335E2815DB0318B4C 3DE90ADFB48CE4997FD147865B9E3D07 C3A858F32FF2D309A6E3E54C53234446 6C6B03AE90763860DE2302F9C03BE4ED 135:d=3D1 hl=3D2 l=3D 3 prim: INTEGER :010001 > > I do not believe that a five (or even ten) specific sizes can be > chosen that accommodate all valid RSA public keys. DOCSIS uses a subset of moduli values that matches the sizes described by the MIB object After the explanations above, is this still an issue? > Can we get an strong > integrity algorithm specified? If not, the last few paragraphs of > of the Security Considerations need to be made much more forceful. I can't disclosure current spec work around DOCSIS protocols in IPCDN who includes=20 persons probably not under CableLabs NDAs.=20 Perhaps a reference to section 7.7 of BPI+ specification (available at http://www.cablelabs.com/specifications/archives/SP-BPI+_I10-030730.pdf ) will that be sufice by indicate the Protocol extensibility for strong algorithms=20 which are highly recommended.=20 7.7 Supporting Alternative Algorithms The current BPI+ specification requires the use of 56-bit DES for encrypting packet data, two-key triple DES for encrypting traffic encryption keys, 1024-bit [RSA] for encrypting Authorization keys, and 1024-to-2048-bit [RSA] for signing BPI+ X.509 certificates. The choice of key lengths and algorithms, while appropriate for current threat models and hardware capabilities, may be inappropriate in the future. For example, it is generally agreed that DES is approaching the end of its practical usefulness as the industry standard for symmetric encryption. NIST is currently overseeing the development and adoption of a new standard encryption algorithm, commonly referred to as the Advanced Encryption Standard, or AES. Given the nature of the security services BPI+ is being asked to support (basic privacy at a level better than or equal to that possible over dedicated wires, and conditional access to RF data transport services) as well as the protocol's flexible key management policy (i.e., setting of key lifetimes), DOCSIS-based service providers will be justified in the continued reliance on DES for, at least, the next five years. Nevertheless, at some future date, DOCSIS Cable modems will need to adopt a stronger traffic encryption algorithm, possibly AES. Adopting a new algorithm for packet data encryption will not require a redesign of BPI+. The protocol's consistent use of Type/Length/Value encoding of BPKM attributes, MAC Header Extended Header elements, and security capabilities selection in the authorization exchange guarantee BPI+'s extensibility. In fact, changes in any of BPI+'s cryptographic algorithms, or associated key lengths, will have no impact on the overall structure and operation of the protocol.=20 -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Thursday, September 23, 2004 6:12 AM To: Ipcdn (E-mail) Subject: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 > COMMENT > > Please delete the second paragraph of the Abstract prior to publication > as an RFC. > > In the Abstract: s/DOCSIS1.1/DOCSIS 1.1/ OK Thanks Eduardo I am forwarding IESG comments as I receive them. Answers are fine. Pls do not yet submit a changed document untill we get ALL the IESG comments. Should be around Tuesday next week. Bert -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Wednesday, September 22, 2004 21:51 To: iesg@ietf.org Subject: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus (Proposed Standard) DISCUSS The definition of docsBpi2CmPublicKey begins: : : docsBpi2CmPublicKey OBJECT-TYPE : SYNTAX OCTET STRING (SIZE (74|106|140|204|270)) : The selection of these few octet string sizes is inappropriate. PKCS #1 encoding of an RSA public key is a SEQUENCE of two INTEGERs. One example of an acceptable RSA public key that cannot be accommodated by this definition follows. It is 139 octets. 0 30 137: SEQUENCE { 3 02 129: INTEGER : 00 DD D8 49 85 DD 76 BE 9C 64 D2 6A 0C B3 3A 14 : 0B 37 A5 60 97 90 40 3D C0 C6 9C 01 FB D0 6F B6 : 49 56 E5 1A 44 F7 C7 1D 23 4C 91 A2 6F BE F7 9A : D0 5F F0 88 9A 01 A2 0A 20 78 22 45 1A 9D 77 8F : CA 14 3E 75 44 3C D6 67 16 21 E5 42 B5 EC BF 62 : 6C 09 0E 4D D9 79 D0 55 82 5C 9C FD B1 B9 B6 A6 : 5B 42 83 FA 90 1E 74 3F 5C 1C 1F D8 73 40 94 3C : 9A 9F 2A 04 FE ED 8C 69 C3 0E 10 A6 3B 0B A7 A4 : CD 135 02 3: INTEGER 65537 : } I do not believe that a five (or even ten) specific sizes can be chosen that accommodate all valid RSA public keys. The definition of docsBpi2CmtsAuthCmPublicKey has the same problem. The definition of docsBpi2CmTEKDataEncryptAlg begins: : : docsBpi2CmTEKDataEncryptAlg OBJECT-TYPE : SYNTAX INTEGER { : none(0), : des56CbcMode(1), : des40CbcMode(2) : } : And, the definition of docsBpi2CmTEKDataAuthentAlg begins: : : docsBpi2CmTEKDataAuthentAlg OBJECT-TYPE : SYNTAX INTEGER { : none(0) : } : These same values are also used in the docsBpi2CmCryptoSuiteDataEncryptAlg, docsBpi2CmCryptoSuiteDataAuthentAlg, docsBpi2CmtsTEKDataEncryptAlg, docsBpi2CmtsTEKDataAuthentAlg, docsBpi2CmtsIpMulticastDataEncryptAlg, and docsBpi2CmtsIpMulticastDataAuthentAlg definitions. None of the encryption algorithm choices is a strong encryption algorithm. Also, the encryption algorithm choice do not provide integrity, so they ought to be used with an integrity algorithm, but none are specified. Can we get a strong encryption algorithm added to the list? Can we get an strong integrity algorithm specified? If not, the last few paragraphs of of the Security Considerations need to be made much more forceful. COMMENT Please delete the second paragraph of the Abstract prior to publication as an RFC. In the Abstract: s/DOCSIS1.1/DOCSIS 1.1/ _______________________________________________ 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 Sep 23 15:21: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 PAA13816 for ; Thu, 23 Sep 2004 15:21:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAZGj-0007dq-Bn for ipcdn-archive@ietf.org; Thu, 23 Sep 2004 15:28:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAZ3z-0001hz-1D; Thu, 23 Sep 2004 15:15:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAYqo-00019H-Ho for ipcdn@megatron.ietf.org; Thu, 23 Sep 2004 15:01:54 -0400 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 PAA11170 for ; Thu, 23 Sep 2004 15:01:52 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAYxd-0007EH-1i for ipcdn@ietf.org; Thu, 23 Sep 2004 15:08:58 -0400 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 i8NJ1Ilf001436 for ; Thu, 23 Sep 2004 14:01:19 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Sep 2004 21:01:18 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79CD5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Date: Thu, 23 Sep 2004 21:01:16 +0200 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: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib 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: 52e1467c2184c31006318542db5614d5 FYI and possible follow up -----Original Message----- From: Steve Bellovin [mailto:smb@research.att.com] Sent: Thursday, September 23, 2004 20:07 To: iesg@ietf.org Subject: DISCUSS: draft-ietf-ipcdn-bpiplus-mib I concur in Russ' comments about the lack of any suitably strong crypto algorithms. 40-bit DES is, frankly, an embarrassment at this point. Yes, I realize that DOCSIS isn't doing it right yet; that's no reason for us to do it wrong. We should put the code points into the MIB now, and let them catch up. But I'll let Russ hold that part of the DISCUSS (as well as the note that authentication algorithms are needed.) The Security Considerations section says The time to crack DES could be additionally mitigated by a compromised value for the TEK lifetime and Grace Time (up to a minimum of 30 minutes for the TEK lifetime, see Appendix A [1]). That's only partially correct. These keys are confidentiality keys; they're still valuable even after they're no longer in active use, because they can be used to decrypt old traffic. (By contrast, old authentication keys are useless to an attacker.) --Steve Bellovin, http://www.research.att.com/~smb _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Sep 24 03:15:09 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 DAA15049 for ; Fri, 24 Sep 2004 03:15:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAkPN-0003dn-Bw for ipcdn-archive@ietf.org; Fri, 24 Sep 2004 03:22:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAkH8-00040v-IS; Fri, 24 Sep 2004 03:13:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAkGK-0003tk-51 for ipcdn@megatron.ietf.org; Fri, 24 Sep 2004 03:13:00 -0400 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 DAA14936 for ; Fri, 24 Sep 2004 03:12:59 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAkNG-0003b2-K4 for ipcdn@ietf.org; Fri, 24 Sep 2004 03:20:11 -0400 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 i8O7CQkH029595; Fri, 24 Sep 2004 01:12:26 -0600 (MDT) 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: RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 Date: Fri, 24 Sep 2004 01:12:25 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F03E8FC@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 Thread-Index: AcShZ6uO0bvYOCs/T0eA+x9m9M2IsAAGpqfgAB/uc2A= From: "Eduardo Cardona" To: "Eduardo Cardona" , "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 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: dd7e0c3fd18d19cffdd4de99a114001d Content-Transfer-Encoding: quoted-printable All,=20 I wrote: "I can't disclosure current spec work around DOCSIS protocols in IPCDN who includes=20 persons probably not under CableLabs NDAs.=20 Perhaps a reference to section 7.7 of BPI+ specification ... " I would like to withdraw this part of my response, it was out of line. The valid question was asked by Russ (and Bert) as part of the open IETF process and a response should be provided in full disclosure to all the IETF participants. Thanks Eduardo -----Original Message----- From: Eduardo Cardona=20 Sent: Thursday, September 23, 2004 10:34 AM To: Wijnen, Bert (Bert); Ipcdn (E-mail) Subject: RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 Bert, I am not sure if this is just perception from the parser output: Below is a similar public key pair that indicates the offsets line by line=20 Ofsset 135 (zero based) indicates the start of the public exponent (5 bytes) Offset 140 indicates the offset of byte 141 Here is a 140 octets PKCS#1 public key pair Off =20 0 30 81 89 3 02 81 81=20 6 00 cf 32 d2 0b 31 d5 47 f9 73 98 8a 83 62 e1 fb 22 dc e6 3b 0b 4b b8 d6 3b 35 31 5d dc 7a 72 89 fe 38 e9 18 20 c7 83 7b 76 d7 75 36 91 72 f6 17 8f 5a 54 59 68 28 87 0d 9b 25 88 52 7b cb a2 52 10 26 89 70 69 4f 0d d1 d9 2d 71 aa 03 35 e2 81 5d b0 31 8b 86 4c 3d e9 0a df b4 8c e4 99 7f d1 47 86 5b 9e 3d=20 102 07 c3 a8 58 f3 2f f2 d3 09 a6 e3 e5 4c 53 23 44=20 118 46 6c 6b 03 ae 90 76 38 60 de 23 02 f9 c0 3b e4=20 134 ed 135 02 03 01 00 01 140 Bytes size =3D 3 + 3 + 129 + 5 =3D 140 And the output from for the equivalent binary file=20 from openssl asn1parse command: 0:d=3D0 hl=3D3 l=3D 137 cons: SEQUENCE 3:d=3D1 hl=3D3 l=3D 129 prim: INTEGER =20 :CF32D20B31D547F973988A8362E1FBDC E63B0B4BB8D63B35315DDC7A7289FEE9 1820C7837B76D775369172F6178F5A59 6828870D9B2588527BCBA25210268969 4F0DD1D92D71AA0335E2815DB0318B4C 3DE90ADFB48CE4997FD147865B9E3D07 C3A858F32FF2D309A6E3E54C53234446 6C6B03AE90763860DE2302F9C03BE4ED 135:d=3D1 hl=3D2 l=3D 3 prim: INTEGER :010001 > > I do not believe that a five (or even ten) specific sizes can be > chosen that accommodate all valid RSA public keys. DOCSIS uses a subset of moduli values that matches the sizes described by the MIB object After the explanations above, is this still an issue? > Can we get an strong > integrity algorithm specified? If not, the last few paragraphs of > of the Security Considerations need to be made much more forceful. I can't disclosure current spec work around DOCSIS protocols in IPCDN who includes=20 persons probably not under CableLabs NDAs.=20 Perhaps a reference to section 7.7 of BPI+ specification (available at http://www.cablelabs.com/specifications/archives/SP-BPI+_I10-030730.pdf ) will that be sufice by indicate the Protocol extensibility for strong algorithms=20 which are highly recommended.=20 7.7 Supporting Alternative Algorithms The current BPI+ specification requires the use of 56-bit DES for encrypting packet data, two-key triple DES for encrypting traffic encryption keys, 1024-bit [RSA] for encrypting Authorization keys, and 1024-to-2048-bit [RSA] for signing BPI+ X.509 certificates. The choice of key lengths and algorithms, while appropriate for current threat models and hardware capabilities, may be inappropriate in the future. For example, it is generally agreed that DES is approaching the end of its practical usefulness as the industry standard for symmetric encryption. NIST is currently overseeing the development and adoption of a new standard encryption algorithm, commonly referred to as the Advanced Encryption Standard, or AES. Given the nature of the security services BPI+ is being asked to support (basic privacy at a level better than or equal to that possible over dedicated wires, and conditional access to RF data transport services) as well as the protocol's flexible key management policy (i.e., setting of key lifetimes), DOCSIS-based service providers will be justified in the continued reliance on DES for, at least, the next five years. Nevertheless, at some future date, DOCSIS Cable modems will need to adopt a stronger traffic encryption algorithm, possibly AES. Adopting a new algorithm for packet data encryption will not require a redesign of BPI+. The protocol's consistent use of Type/Length/Value encoding of BPKM attributes, MAC Header Extended Header elements, and security capabilities selection in the authorization exchange guarantee BPI+'s extensibility. In fact, changes in any of BPI+'s cryptographic algorithms, or associated key lengths, will have no impact on the overall structure and operation of the protocol.=20 -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Thursday, September 23, 2004 6:12 AM To: Ipcdn (E-mail) Subject: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 > COMMENT > > Please delete the second paragraph of the Abstract prior to publication > as an RFC. > > In the Abstract: s/DOCSIS1.1/DOCSIS 1.1/ OK Thanks Eduardo I am forwarding IESG comments as I receive them. Answers are fine. Pls do not yet submit a changed document untill we get ALL the IESG comments. Should be around Tuesday next week. Bert -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Wednesday, September 22, 2004 21:51 To: iesg@ietf.org Subject: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus (Proposed Standard) DISCUSS The definition of docsBpi2CmPublicKey begins: : : docsBpi2CmPublicKey OBJECT-TYPE : SYNTAX OCTET STRING (SIZE (74|106|140|204|270)) : The selection of these few octet string sizes is inappropriate. PKCS #1 encoding of an RSA public key is a SEQUENCE of two INTEGERs. One example of an acceptable RSA public key that cannot be accommodated by this definition follows. It is 139 octets. 0 30 137: SEQUENCE { 3 02 129: INTEGER : 00 DD D8 49 85 DD 76 BE 9C 64 D2 6A 0C B3 3A 14 : 0B 37 A5 60 97 90 40 3D C0 C6 9C 01 FB D0 6F B6 : 49 56 E5 1A 44 F7 C7 1D 23 4C 91 A2 6F BE F7 9A : D0 5F F0 88 9A 01 A2 0A 20 78 22 45 1A 9D 77 8F : CA 14 3E 75 44 3C D6 67 16 21 E5 42 B5 EC BF 62 : 6C 09 0E 4D D9 79 D0 55 82 5C 9C FD B1 B9 B6 A6 : 5B 42 83 FA 90 1E 74 3F 5C 1C 1F D8 73 40 94 3C : 9A 9F 2A 04 FE ED 8C 69 C3 0E 10 A6 3B 0B A7 A4 : CD 135 02 3: INTEGER 65537 : } I do not believe that a five (or even ten) specific sizes can be chosen that accommodate all valid RSA public keys. The definition of docsBpi2CmtsAuthCmPublicKey has the same problem. The definition of docsBpi2CmTEKDataEncryptAlg begins: : : docsBpi2CmTEKDataEncryptAlg OBJECT-TYPE : SYNTAX INTEGER { : none(0), : des56CbcMode(1), : des40CbcMode(2) : } : And, the definition of docsBpi2CmTEKDataAuthentAlg begins: : : docsBpi2CmTEKDataAuthentAlg OBJECT-TYPE : SYNTAX INTEGER { : none(0) : } : These same values are also used in the docsBpi2CmCryptoSuiteDataEncryptAlg, docsBpi2CmCryptoSuiteDataAuthentAlg, docsBpi2CmtsTEKDataEncryptAlg, docsBpi2CmtsTEKDataAuthentAlg, docsBpi2CmtsIpMulticastDataEncryptAlg, and docsBpi2CmtsIpMulticastDataAuthentAlg definitions. None of the encryption algorithm choices is a strong encryption algorithm. Also, the encryption algorithm choice do not provide integrity, so they ought to be used with an integrity algorithm, but none are specified. Can we get a strong encryption algorithm added to the list? Can we get an strong integrity algorithm specified? If not, the last few paragraphs of of the Security Considerations need to be made much more forceful. COMMENT Please delete the second paragraph of the Abstract prior to publication as an RFC. In the Abstract: s/DOCSIS1.1/DOCSIS 1.1/ _______________________________________________ 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 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Sep 24 13:49:53 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 NAA01493 for ; Fri, 24 Sep 2004 13:49:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAuJf-0007mv-B9 for ipcdn-archive@ietf.org; Fri, 24 Sep 2004 13:57:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAu6K-0003bu-Ga; Fri, 24 Sep 2004 13:43:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAu1n-00015J-8R for ipcdn@megatron.ietf.org; Fri, 24 Sep 2004 13:38:42 -0400 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 NAA00445; Fri, 24 Sep 2004 13:38:35 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAu8l-0007Vn-1t; Fri, 24 Sep 2004 13:45:55 -0400 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 i8OHbskH019843; Fri, 24 Sep 2004 11:37:54 -0600 (MDT) 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 Date: Fri, 24 Sep 2004 11:37:54 -0600 Message-ID: Thread-Topic: Request for IPCDN ID publication: draft-ietf-ipcdn-qos-mib-10.txt Thread-Index: AcSiS95mLKmzCGmMQfKIQ/s+DHxilgAEQd2A From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: Murwin William-LWM008 , bwijnen@lucent.com, "Ipcdn \(E-mail\)" , Patrick Michael-LZZ007 , "Richard Woundy @ Comcast" Subject: [ipcdn] Request for IPCDN ID publication: draft-ietf-ipcdn-qos-mib-10.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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable =20 This note is a formal request to change the state of the ID to = publication requested. Jean-Fran=E7ois -----Original Message----- From: ID Tracker [mailto:internet-drafts-reply@ietf.org]=20 Sent: Friday, September 24, 2004 10:04 AM To: Richard Woundy @ Comcast; RWoundy@broadband.att.com; Jean-Francois = Mule; bwijnen@lucent.com Subject: New Version Notification - draft-ietf-ipcdn-qos-mib-10.txt New version (-10) has been submitted for = draft-ietf-ipcdn-qos-mib-10.txt. = http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-10.txt Sub state has been changed to AD Follow up from New Id Needed _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Sep 24 16:17:39 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 QAA14135 for ; Fri, 24 Sep 2004 16:17:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAwcl-0002vz-5b for ipcdn-archive@ietf.org; Fri, 24 Sep 2004 16:24:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAvzK-0006jd-6G; Fri, 24 Sep 2004 15:44:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAvt2-0003zS-Md; Fri, 24 Sep 2004 15:37:44 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08809; Fri, 24 Sep 2004 15:37:42 -0400 (EDT) Message-Id: <200409241937.PAA08809@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 24 Sep 2004 15:37:42 -0400 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-qos-mib-10.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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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 : Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QOS MIB) Author(s) : M. Patrick, W. Murwin Filename : draft-ietf-ipcdn-qos-mib-10.txt Pages : 88 Date : 2004-9-24 This document defines a basic set of managed objects for SNMP-based management of extended QOS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) standard version 1.1 and 2.0. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-10.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-qos-mib-10.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-qos-mib-10.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-9-24145820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-qos-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-qos-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-24145820.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 Fri Sep 24 18:37: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 SAA28245 for ; Fri, 24 Sep 2004 18:37:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAyoZ-0006nQ-PK for ipcdn-archive@ietf.org; Fri, 24 Sep 2004 18:45:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAyep-0008LG-0q; Fri, 24 Sep 2004 18:35:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAya2-0007hC-W1 for ipcdn@megatron.ietf.org; Fri, 24 Sep 2004 18:30:19 -0400 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 SAA27634 for ; Fri, 24 Sep 2004 18:30:16 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAyh7-0006ev-OX for ipcdn@ietf.org; Fri, 24 Sep 2004 18:37:38 -0400 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 i8OMTikH011892; Fri, 24 Sep 2004 16:29:44 -0600 (MDT) 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: RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 Date: Fri, 24 Sep 2004 16:29:43 -0600 Message-ID: Thread-Topic: RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 Thread-Index: AcSihf1vFW/jBV1RRj6+t2LSzDSCFw== From: "Jean-Francois Mule" To: "Russ Housley" , "Steven M. Bellovin" , , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: Eduardo Cardona , Greg White , Oscar Marcia , "Richard Woundy @ Comcast" , Eric Rosenfeld 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: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Russ, Steve and Bert, Thanks for your comments on draft-ietf-ipcdn-bpiplus-mib-14. To summarize, you expressed 2 main comments, see below a proposed resolution. Ipcdn folks: Feel free to interject and comment. --- 1. Syntax of docsBpi2CmPublicKey and range limitations: Per Eduardo and Rich's responses, the current object syntax of docsBpi2CmPublicKey is justified by the fact that DOCSIS BPI+ specifies a public modulus of 3 or 65537.=20 Eduardo wrote: > DOCSIS uses a subset of moduli values that matches the sizes > described by the MIB object. Rich added: > In general I am sure this is true, but for DOCSIS BPI+, a > specific public modulus is specified: 65537. >=20 > Per > >, section 4.2.2.4 and elsewhere: "PKCS #1 v2.0 states that > the RSA public exponent may be standardized in specific > applications, and the document suggests values of 3 or 65537=20 > (F4). Baseline Privacy Plus standardizes on F4 for a public=20 > exponent and employs a 1024-bit modulus (Baseline Privacy=20 > employed a 768-bit modulus)." Also see sections 7.5 and 7.6,=20 > for example. Proposed resolution: Even with the above justification, we (Rich and I) do not have any objection changing the syntax to not restrict the possible ranges in the MIB module. To allow the use of PCKS 4096 bits moduli, we (Eduardo, Oscar and I) would like to define the max limit to something like 524. The proposal is:=20 a) change the SYNTAX replace < docsBpi2CmPublicKey OBJECT-TYPE < SYNTAX OCTET STRING (SIZE (74|106|140|204|270)) with > docsBpi2CmPublicKey OBJECT-TYPE > SYNTAX OCTET STRING (SIZE 0..524) b) for existing 1.1 and 2.0 implementations, in the compliance statement, an OBJECT clause to say that DOCSIS 1.1 and 2.0 devices are not required to support any key with a size greater than 270. This proposal should suffice to address the comment: it adds flexibility in the generic object definition, yet reflects the reality of the underlying docsis 1.1 and 2.0 implementations and allow us to add a new compliance statement later for newer implementations without changing the mib definition. If this is not sufficient, let us know. --- 2. Lack of strong encryption & authentication mechanism in DOCSIS BPI+ The second comment raised by you both (Russ and Steve) is the lack of strong encryption & authentication mechanism in DOCSIS BPI+ and subsequently in the IPCDN DOCSIS BPI+ MIB module. While the current DOCSIS specifications do not support any additional algorithms (and therefore, the underlying protocols supported by this MIB may not allow additional algorithm to be negotiated and used), we believe it is ok to add a couple of stronger encryption/auth algorithms for future use. Vendors may opt to support these additional algorithms and future DOCSIS specs may consider these for inclusion - TBD. In any case, today's implementations should reject any values outside the range allowed in docsis per standard error handling procedures so we don't see a pb with adding some better algo there. Based on some input from Oscar Marcia, our chief security architect at CableLabs, Eric Rosenfeld, and Eduardo Cardona, we would like to propose that we add the following algorithms as optional to support: Symmetric encryption:=20 AES (AES128CbcMode, AES256CbcMode), 3DES, DES ^^^ new addition, optional to support Public-key algorithms:=20 RSA (768, 1024, 2048, 3072 -bit key) Data integrity algorithms:=20 SHA-1, SHA-256, MD5 ^ new addition, optional to support=20 On the data integrity, as Eric and Oscar pointed out, please note that the MAC level protocol DOCSIS only support encryption today. Authentication is used on the key management messages and all DOCSIS Dynamic Service Flow DSA, DSC, and DSD exchanges, but the actual data transport security only uses encryption. So proposing authentication algorithms is a clear stretch based on the current protocol and implementations. That said, we would be ok with adding a couple for potential future use. We would also like to add some text in the compliance statement of the MIB to specify what algs are mandatory to support for DOCSIS 1.1 and 2.0 to eliminate any potential confusions. =20 Are these proposals to resolve your comments ok with you?=20 Do you see any other possible algorithms we should consider for inclusion? Any one we should remove?=20 Once we have your blessing on the above, Eduardo or I will propose the exact text modifications for the Internet-Draft (we probably need to add some text in the description clauses, compliance statement, the security consideration section, references, etc.) Let us know if this message addresses those IESG comments. Special thanks all the folks in cc: for their input on this thread. Any additional comments, please include the ipcdn list. Thanks, Jean-Francois=20 IPCDN co-chair _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sat Sep 25 16:33:45 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 QAA16007 for ; Sat, 25 Sep 2004 16:33:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBJM6-0000wM-FU for ipcdn-archive@ietf.org; Sat, 25 Sep 2004 16:41:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBJCv-0002jW-KM; Sat, 25 Sep 2004 16:31:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAyjr-0000aJ-Bu for ipcdn@megatron.ietf.org; Fri, 24 Sep 2004 18:40:27 -0400 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 SAA28385 for ; Fri, 24 Sep 2004 18:40:24 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.240.3]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CAyqw-0006pV-E3 for ipcdn@ietf.org; Fri, 24 Sep 2004 18:47:46 -0400 Received: (qmail 1825 invoked by uid 0); 24 Sep 2004 22:40:18 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.180.219) by woodstock.binhost.com with SMTP; 24 Sep 2004 22:40:18 -0000 Message-Id: <6.1.2.0.2.20040924183709.05501fe0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 24 Sep 2004 18:41:28 -0400 To: "Jean-Francois Mule" , "Steven M. Bellovin" , , From: Russ Housley Subject: RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-Mailman-Approved-At: Sat, 25 Sep 2004 16:31:48 -0400 Cc: Eduardo Cardona , Greg White , Oscar Marcia , "Richard Woundy @ Comcast" , Eric Rosenfeld 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.2 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Jean-Francois: >--- 1. Syntax of docsBpi2CmPublicKey and range limitations: > Per Eduardo and Rich's responses, the current object syntax of >docsBpi2CmPublicKey is justified by the fact that DOCSIS BPI+ specifies >a public modulus of 3 or 65537. >Eduardo wrote: > > DOCSIS uses a subset of moduli values that matches the sizes > > described by the MIB object. > >Rich added: > > In general I am sure this is true, but for DOCSIS BPI+, a > > specific public modulus is specified: 65537. > > > > Per > > >, > section 4.2.2.4 and elsewhere: "PKCS #1 v2.0 states that > > the RSA public exponent may be standardized in specific > > applications, and the document suggests values of 3 or 65537 > > (F4). Baseline Privacy Plus standardizes on F4 for a public > > exponent and employs a 1024-bit modulus (Baseline Privacy > > employed a 768-bit modulus)." Also see sections 7.5 and 7.6, > > for example. > >Proposed resolution: > Even with the above justification, we (Rich and I) do not have any >objection changing the syntax to not restrict the possible ranges in the >MIB module. To allow the use of PCKS 4096 bits moduli, we (Eduardo, >Oscar and I) would like to define the max limit to something like 524. >The proposal is: > > a) change the SYNTAX >replace >< docsBpi2CmPublicKey OBJECT-TYPE >< SYNTAX OCTET STRING (SIZE (74|106|140|204|270)) >with > > docsBpi2CmPublicKey OBJECT-TYPE > > SYNTAX OCTET STRING (SIZE 0..524) > > b) for existing 1.1 and 2.0 implementations, in the compliance >statement, an OBJECT clause to say that DOCSIS 1.1 and 2.0 devices are >not required to support any key with a size greater than 270. > >This proposal should suffice to address the comment: it adds flexibility >in the generic object definition, yet reflects the reality of the >underlying docsis 1.1 and 2.0 implementations and allow us to add a new >compliance statement later for newer implementations without changing >the mib definition. If this is not sufficient, let us know. This is fine with me. >--- 2. Lack of strong encryption & authentication mechanism in DOCSIS >BPI+ > The second comment raised by you both (Russ and Steve) is the lack of >strong encryption & authentication mechanism in DOCSIS BPI+ and >subsequently in the IPCDN DOCSIS BPI+ MIB module. > While the current DOCSIS specifications do not support any additional >algorithms (and therefore, the underlying protocols supported by this >MIB may not allow additional algorithm to be negotiated and used), we >believe it is ok to add a couple of stronger encryption/auth algorithms >for future use. Vendors may opt to support these additional algorithms >and future DOCSIS specs may consider these for inclusion - TBD. In any >case, today's implementations should reject any values outside the range >allowed in docsis per standard error handling procedures so we don't see >a pb with adding some better algo there. > > Based on some input from Oscar Marcia, our chief security architect >at CableLabs, Eric Rosenfeld, and Eduardo Cardona, we would like to >propose that we add the following algorithms as optional to support: > > Symmetric encryption: > AES (AES128CbcMode, AES256CbcMode), 3DES, DES > ^^^ new addition, optional to support You need to specify a mode for 3DES too. It will probably be CBC like the rest of the algorithms you support. > Public-key algorithms: > RSA (768, 1024, 2048, 3072 -bit key) Okay. > Data integrity algorithms: > SHA-1, SHA-256, MD5 > ^ new addition, optional to support I expected HMAC-SHA-1. This can be truncated as is done in IPsec. Look at the HMAC-SHA1-96 definition for an example. MD5 is certainly not a good thing to add at this point. > On the data integrity, as Eric and Oscar pointed out, please note that >the MAC level protocol DOCSIS only support encryption today. >Authentication is used on the key management messages and all DOCSIS >Dynamic Service Flow DSA, DSC, and DSD exchanges, but the actual data >transport security only uses encryption. So proposing authentication >algorithms is a clear stretch based on the current protocol and >implementations. That said, we would be ok with adding a couple for >potential future use. > > > We would also like to add some text in the compliance statement of the >MIB to specify what algs are mandatory to support for DOCSIS 1.1 and 2.0 >to eliminate any potential confusions. Okay. Russ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Sep 27 05:34: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 FAA15304 for ; Mon, 27 Sep 2004 05:34:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBs1Y-0001lF-7X for ipcdn-archive@ietf.org; Mon, 27 Sep 2004 05:42:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBrsc-0000Li-Km; Mon, 27 Sep 2004 05:33:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBrms-0008OS-1l for ipcdn@megatron.ietf.org; Mon, 27 Sep 2004 05:27:14 -0400 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 FAA14867 for ; Mon, 27 Sep 2004 05:27:11 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBruS-0001e7-Va for ipcdn@ietf.org; Mon, 27 Sep 2004 05:35:05 -0400 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 i8R9RBLU022805 for ; Mon, 27 Sep 2004 04:27:11 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Sep 2004 11:27:09 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79D19@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Date: Mon, 27 Sep 2004 11:27:06 +0200 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: 7655788c23eb79e336f5f8ba8bce7906 Subject: [ipcdn] FW: Question on draft-ietf-ipcdn-bpiplus-mib-14.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 As expected... here is the question from IANA. So we have that on our plate to be fixed already. Just wanted to let you know the feedback we're getting Bert -----Original Message----- From: Michelle S. Cotton [mailto:cotton@icann.org] Sent: Monday, September 27, 2004 08:22 To: Bert Wijnen (Bert) Cc: iesg@ietf.org; iana@iana.org Subject: Question on draft-ietf-ipcdn-bpiplus-mib-14.txt Bert, For draft-ietf-ipcdn-bpiplus-mib-14.txt, it mentions an assignment to made under the docsIfMib subtree. Is this a new subtree? Where does this go? Thanks in advance. Michelle _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Sep 27 08:33:38 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 IAA25598 for ; Mon, 27 Sep 2004 08:33:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBuou-000503-SO for ipcdn-archive@ietf.org; Mon, 27 Sep 2004 08:41:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBue0-0000dQ-4B; Mon, 27 Sep 2004 08:30:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBuaT-00005a-Pw for ipcdn@megatron.ietf.org; Mon, 27 Sep 2004 08:26:37 -0400 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 IAA25056 for ; Mon, 27 Sep 2004 08:26:35 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBui5-0004qI-Tw for ipcdn@ietf.org; Mon, 27 Sep 2004 08:34:30 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i8RCQ312013978 for ; Mon, 27 Sep 2004 07:26:05 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Sep 2004 14:25:42 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79D21@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Date: Mon, 27 Sep 2004 14:25:35 +0200 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [ipcdn] subscriber mib issue 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: d6b246023072368de71562c0ab503126 IESG raised this one: Allison Mankin: Discuss: [2004-09-26] The document states: Effective network filtering of TCP traffic requires that implementors MUST follow the recommendations in section 3.2.6. But there is no section 3.2.6 here. MUST must be clear. Ooopss. I should have seen that. Not even sure we can just replace that with a single ptr to one other (sub)section, can we. ANyway, would be good to have a response ASAP. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Sep 27 11:01:11 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 LAA05658 for ; Mon, 27 Sep 2004 11:01:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBx7j-0007ek-Bx for ipcdn-archive@ietf.org; Mon, 27 Sep 2004 11:09:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBwqz-0002FV-IO; Mon, 27 Sep 2004 10:51:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBwf8-0008Qx-Lg for ipcdn@megatron.ietf.org; Mon, 27 Sep 2004 10:39:36 -0400 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 KAA04267 for ; Mon, 27 Sep 2004 10:39:32 -0400 (EDT) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBwml-0007Ey-A9 for ipcdn@ietf.org; Mon, 27 Sep 2004 10:47:28 -0400 Received: from ([10.20.62.20]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.4131861; Mon, 27 Sep 2004 10:36:37 -0400 Received: by pacdcexsmtp05.cable.comcast.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Sep 2004 10:43:44 -0400 Message-ID: From: "Woundy, Richard" To: "'Wijnen, Bert (Bert)'" , "'Wilson Sawyer'" Subject: RE: [ipcdn] subscriber mib issue Date: Mon, 27 Sep 2004 10:38:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "Ipcdn \(E-mail\)" 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Bert, I am pretty sure that this reference is supposed to be to the section entitled "Filtering and the Tiny Fragment Attack". For version -15, "Filtering and the Tiny Fragment Attack" is section 3.4. The original text in the drafts, prior to updates in version -15, is: The filtering mechanism defined here can be defeated through the "tiny fragment" and "overlapping fragment" attacks if the recommendations in section 2.2.6 are omitted. See [RFC1858] and [RFC3128] for discussion of these attacks. Version -06 of the draft points to the section entitled "Filtering and the Tiny Fragment Attack", . In versions -07 to -14, this text points to section 2.2.6, but that section no longer exists. In version -15, the revised text points to section 3.2.6, but that section also does not exist. Note that the wording in the original text, "See [RFC1858] and [RFC3128] for discussion of these attacks", is a direct reference to the contents of the "Filtering and the Tiny Fragment Attack" section. Wilson, can you confirm? -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Monday, September 27, 2004 8:26 AM To: Ipcdn (E-mail) Subject: [ipcdn] subscriber mib issue IESG raised this one: Allison Mankin: Discuss: [2004-09-26] The document states: Effective network filtering of TCP traffic requires that implementors MUST follow the recommendations in section 3.2.6. But there is no section 3.2.6 here. MUST must be clear. Ooopss. I should have seen that. Not even sure we can just replace that with a single ptr to one other (sub)section, can we. ANyway, would be good to have a response ASAP. 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 Mon Sep 27 13:36:29 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 NAA15252 for ; Mon, 27 Sep 2004 13:36:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBzY3-0001wx-GP for ipcdn-archive@ietf.org; Mon, 27 Sep 2004 13:44:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBzJw-0002Si-5Z; Mon, 27 Sep 2004 13:29:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBzEQ-00026U-Eg for ipcdn@megatron.ietf.org; Mon, 27 Sep 2004 13:24:10 -0400 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 NAA14567 for ; Mon, 27 Sep 2004 13:24:06 -0400 (EDT) From: sawyerwd@comcast.net Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBzM4-0001ku-CB for ipcdn@ietf.org; Mon, 27 Sep 2004 13:32:05 -0400 Received: from 204.127.205.145 ([204.127.205.145]) by comcast.net (sccrmhc12) with SMTP id <2004092717233701200fn649e>; Mon, 27 Sep 2004 17:23:37 +0000 Received: from [63.160.138.52] by 204.127.205.145; Mon, 27 Sep 2004 17:23:37 +0000 To: "Woundy, Richard" , "'Wijnen, Bert (Bert)'" Subject: RE: [ipcdn] subscriber mib issue Date: Mon, 27 Sep 2004 17:23:37 +0000 Message-Id: <092720041723.8617.41584C98000C8B8F000021A922007623020B999D0A97990E9C@comcast.net> X-Mailer: AT&T Message Center Version 1 (Jul 16 2004) X-Authenticated-Sender: c2F3eWVyd2RAY29tY2FzdC5uZXQ= MIME-Version: 1.0 X-Spam-Score: 1.2 (+) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: "Ipcdn \(E-mail\)" 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="===============1319322839==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --===============1319322839== Content-Type: multipart/alternative; boundary="NextPart_Webmail_9m3u9jl4l_8617_1096305817_0" --NextPart_Webmail_9m3u9jl4l_8617_1096305817_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit oops. yes, thanks - the sections were renumbered and I thought I'd checked this, but obviously not. It should be 3.4, as Rich notes. - Wilson -------------- Original message -------------- > Bert, > > I am pretty sure that this reference is supposed to be to the section > entitled "Filtering and the Tiny Fragment Attack". For version -15, > "Filtering and the Tiny Fragment Attack" is section 3.4. > > The original text in the drafts, prior to updates in version -15, is: > > The filtering mechanism defined here can be defeated through the > "tiny fragment" and "overlapping fragment" attacks if the > recommendations in section 2.2.6 are omitted. See [RFC1858] and > [RFC3128] for discussion of these attacks. > > Version -06 of the draft points to the section entitled "Filtering and the > Tiny Fragment Attack", > . In > versions -07 to -14, this text points to section 2.2.6, but that section no > longer exists. In version -15, the revised text points to section 3.2.6, but > that section also does not exist. > > Note that the wording in the original text, "See [RFC1858] and [RFC3128] for > discussion of these attacks", is a direct reference to the contents of the > "Filtering and the Tiny Fragment Attack" section. > > Wilson, can you confirm? > > -- Rich > > -----Original Message----- > From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of > Wijnen, Bert (Bert) > Sent: Monday, September 27, 2004 8:26 AM > To: Ipcdn (E-mail) > Subject: [ipcdn] subscriber mib issue > > > IESG raised this one: > > Allison Mankin: > Discuss: > [2004-09-26] The document states: > Effective network filtering of TCP traffic requires that implementors > MUST follow the recommendations in section 3.2.6. > But there is no section 3.2.6 here. MUST must be clear. > > Ooopss. I should have seen that. > Not even sure we can just replace that with a single ptr to one other > (sub)section, can we. ANyway, would be good to have a response ASAP. > > Bert > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart_Webmail_9m3u9jl4l_8617_1096305817_0 Content-Type: text/html Content-Transfer-Encoding: 8bit

oops. yes, thanks - the sections were renumbered and I thought I'd checked this, but obviously not. It should be 3.4, as Rich notes.

- Wilson

-------------- Original message --------------

> Bert,
>
> I am pretty sure that this reference is supposed to be to the section
> entitled "Filtering and the Tiny Fragment Attack". For version -15,
> "Filtering and the Tiny Fragment Attack" is section 3.4.
>
> The original text in the drafts, prior to updates in version -15, is:
>
> The filtering mechanism defined here can be defeated through the
> "tiny fragment" and "overlapping fragment" attacks if the
> recommendations in section 2.2.6 are omitted. See [RFC1858] and
> [RFC3128] for discussion of these attacks.
>
> Version -06 of the draft points to the section entitled "Filtering and the
> Tiny Fragment Attack",
> . In
> versions -07 to -14, this ! text points to section 2.2.6, but that section no
> longer exists. In version -15, the revised text points to section 3.2.6, but
> that section also does not exist.
>
> Note that the wording in the original text, "See [RFC1858] and [RFC3128] for
> discussion of these attacks", is a direct reference to the contents of the
> "Filtering and the Tiny Fragment Attack" section.
>
> Wilson, can you confirm?
>
> -- Rich
>
> -----Original Message-----
> From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of
> Wijnen, Bert (Bert)
> Sent: Monday, September 27, 2004 8:26 AM
> To: Ipcdn (E-mail)
> Subject: [ipcdn] subscriber mib issue
>
>
> IESG raised this one:
>
> Allison Mankin:
> Discuss:
> [2004-09-26] The document states:
> Effective network filtering of TCP traffic requires that implemento! rs
> MUST follow the recommendations in section 3.2.6.
> But there is no section 3.2.6 here. MUST must be clear.
>
> Ooopss. I should have seen that.
> Not even sure we can just replace that with a single ptr to one other
> (sub)section, can we. ANyway, would be good to have a response ASAP.
>
> Bert
>
> _______________________________________________
> IPCDN mailing list
> IPCDN@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipcdn
--NextPart_Webmail_9m3u9jl4l_8617_1096305817_0-- --===============1319322839== 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 --===============1319322839==-- From ipcdn-bounces@ietf.org Mon Sep 27 14:00: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 OAA17070 for ; Mon, 27 Sep 2004 14:00:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBzvc-0002RS-Cl for ipcdn-archive@ietf.org; Mon, 27 Sep 2004 14:08:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBzjI-0005Nj-IC; Mon, 27 Sep 2004 13:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBzaL-00045i-1B for ipcdn@megatron.ietf.org; Mon, 27 Sep 2004 13:46:49 -0400 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 NAA16137 for ; Mon, 27 Sep 2004 13:46:47 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBzhz-00029X-QB for ipcdn@ietf.org; Mon, 27 Sep 2004 13:54:44 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i8RHkFso019308 for ; Mon, 27 Sep 2004 12:46:16 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Sep 2004 19:46:14 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79D2B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'sawyerwd@comcast.net'" , "Woundy, Richard" Subject: RE: [ipcdn] subscriber mib issue Date: Mon, 27 Sep 2004 19:46:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: "Ipcdn \(E-mail\)" 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="===============0698430898==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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. --===============0698430898== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A4B9.D5DA2588" 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_01C4A4B9.D5DA2588 Content-Type: text/plain OK thanks. More later today. -----Original Message----- From: sawyerwd@comcast.net [mailto:sawyerwd@comcast.net] Sent: Monday, September 27, 2004 19:24 To: Woundy, Richard; 'Wijnen, Bert (Bert)' Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] subscriber mib issue oops. yes, thanks - the sections were renumbered and I thought I'd checked this, but obviously not. It should be 3.4, as Rich notes. - Wilson -------------- Original message -------------- > Bert, > > I am pretty sure that this reference is supposed to be to the section > entitled "Filtering and the Tiny Fragment Attack". For version -15, > "Filtering and the Tiny Fragment Attack" is section 3.4. > > The original text in the drafts, prior to updates in version -15, is: > > The filtering mechanism defined here can be defeated through the > "tiny fragment" and "overlapping fragment" attacks if the > recommendations in section 2.2.6 are omitted. See [RFC1858] and > [RFC3128] for discussion of these attacks. > > Version -06 of the draft points to the section entitled "Filtering and the > Tiny Fragment Attack", > . In > versions -07 to -14, this ! text points to section 2.2.6, but that section no > longer exists. In version -15, the revised text points to section 3.2.6, but > that section also does not exist. > > Note that the wording in the original text, "See [RFC1858] and [RFC3128] for > discussion of these attacks", is a direct reference to the contents of the > "Filtering and the Tiny Fragment Attack" section. > > Wilson, can you confirm? > > -- Rich > > -----Original Message----- > From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of > Wijnen, Bert (Bert) > Sent: Monday, September 27, 2004 8:26 AM > To: Ipcdn (E-mail) > Subject: [ipcdn] subscriber mib issue > > > IESG raised this one: > > Allison Mankin: > Discuss: > [2004-09-26] The document states: > Effective network filtering of TCP traffic requires that implemento! rs > MUST follow the recommendations in section 3.2.6. > But there is no section 3.2.6 here. MUST must be clear. > > Ooopss. I should have seen that. > Not even sure we can just replace that with a single ptr to one other > (sub)section, can we. ANyway, would be good to have a response ASAP. > > Bert > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn ------_=_NextPart_001_01C4A4B9.D5DA2588 Content-Type: text/html
OK thanks. More later today.
 
-----Original Message-----
From: sawyerwd@comcast.net [mailto:sawyerwd@comcast.net]
Sent: Monday, September 27, 2004 19:24
To: Woundy, Richard; 'Wijnen, Bert (Bert)'
Cc: Ipcdn (E-mail)
Subject: RE: [ipcdn] subscriber mib issue

oops. yes, thanks - the sections were renumbered and I thought I'd checked this, but obviously not. It should be 3.4, as Rich notes.

- Wilson

-------------- Original message --------------

> Bert,
>
> I am pretty sure that this reference is supposed to be to the section
> entitled "Filtering and the Tiny Fragment Attack". For version -15,
> "Filtering and the Tiny Fragment Attack" is section 3.4.
>
> The original text in the drafts, prior to updates in version -15, is:
>
> The filtering mechanism defined here can be defeated through the
> "tiny fragment" and "overlapping fragment" attacks if the
> recommendations in section 2.2.6 are omitted. See [RFC1858] and
> [RFC3128] for discussion of these attacks.
>
> Version -06 of the draft points to the section entitled "Filtering and the
> Tiny Fragment Attack",
> . In
> versions -07 to -14, this ! text points to section 2.2.6, but that section no
> longer exists. In version -15, the revised text points to section 3.2.6, but
> that section also does not exist.
>
> Note that the wording in the original text, "See [RFC1858] and [RFC3128] for
> discussion of these attacks", is a direct reference to the contents of the
> "Filtering and the Tiny Fragment Attack" section.
>
> Wilson, can you confirm?
>
> -- Rich
>
> -----Original Message-----
> From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of
> Wijnen, Bert (Bert)
> Sent: Monday, September 27, 2004 8:26 AM
> To: Ipcdn (E-mail)
> Subject: [ipcdn] subscriber mib issue
>
>
> IESG raised this one:
>
> Allison Mankin:
> Discuss:
> [2004-09-26] The document states:
> Effective network filtering of TCP traffic requires that implemento! rs
> MUST follow the recommendations in section 3.2.6.
> But there is no section 3.2.6 here. MUST must be clear.
>
> Ooopss. I should have seen that.
> Not even sure we can just replace that with a single ptr to one other
> (sub)section, can we. ANyway, would be good to have a response ASAP.
>
> Bert
>
> _______________________________________________
> IPCDN mailing list
> IPCDN@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipcdn
------_=_NextPart_001_01C4A4B9.D5DA2588-- --===============0698430898== 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 --===============0698430898==-- From ipcdn-bounces@ietf.org Mon Sep 27 17:44:41 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 RAA12201 for ; Mon, 27 Sep 2004 17:44:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC3QE-0001I7-Uo for ipcdn-archive@ietf.org; Mon, 27 Sep 2004 17:52:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC37A-0000OA-T6; Mon, 27 Sep 2004 17:32:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC2p5-00025h-TT for ipcdn@megatron.ietf.org; Mon, 27 Sep 2004 17:14:16 -0400 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 RAA09165 for ; Mon, 27 Sep 2004 17:14:13 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC2wm-0000LL-Um for ipcdn@ietf.org; Mon, 27 Sep 2004 17:22:13 -0400 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 i8RLEC54011600 for ; Mon, 27 Sep 2004 16:14:13 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Sep 2004 23:14:12 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79D38@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'wsawyer@ieee.org'" , "Ipcdn (E-mail)" Date: Mon, 27 Sep 2004 23:14:05 +0200 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: dbb8771284c7a36189745aa720dc20ab Subject: [ipcdn] IESG review of: 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: f49c97ce49302a02285a2d36a99eef8c So below is the complete set of IESG review comments. I think my reaction is as follows: 1. W.r.t. to referencing draft-ietf-ipcdn-device-mibv2-06.txt I wonder what the current status is of that document? It experied a while ago... and I am not seeing activity. So maybe we should just list RFC2669 and not talk about the draft? 2. Based on the above, I also wonder about draft-ietf-ipcdn-docs-rfmibv2-06.txt Where are we with that one? 3. The comment from Ted Hardie is the same as some discussion we had from Steve Bellovin, and I believe the answer is that current MODULE COMPLIANCE only requires IPv4 but the MIB module itself is all ready to also support IPv6. So no change needed. 4. The comments from Russ and Allison's DISCUSS seem valid to me. So to address all of the above, I could add the following RFC-Editor notes: RFC-Editor, pls fix the following - on page 4, pls ignore and remove: -- *********************************************************** -- * Note to RFC Editor (to be removed) -- * If DOCSIS Cable Device MIB [RFC2669] is updated prior to -- * this publication, replace "docsDevCpeIp" with -- * "docsDevCpeInetAddr" -- *********************************************************** - mmm also comes back on page 10 and page 14 - In section 9, 2nd para, pls change text OLD: Effective network filtering of TCP traffic requires that implementors MUST follow the recommendations in section 3.2.6. NEW: For network filtering of TCP traffic to be effective, implementors MUST follow the recommendations in section 3.4. - on page 23, pls ignore and remove: ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * * * The I-D (or a * * successor) is expected to eventually replace RFC 2669. * * If that draft (or a successor) is published as an RFC * * prior to or concurrently with this document, then the * * normative reference [RFC2669] should be updated to * * point to the replacement RFC, and the reference tag * * [RFC2669] should be updated to match. * * * ************************************************************ - ANd possibly a similar statement about draft-ietf-ipcdn-docs-rfmibv2-06.txt Mmm... that is I think more than we want to do in an RFC-Ed note. Wilson, how quick can you do a revision? Bert ------------- IESG comments/discusses Discusses and Comments Harald Alvestrand: Comment: [2004-09-27] Reviewed by John Loughney, Gen-ART His review: Document seems ready, a couple of small nits: 1) Shouldn't the Security Considerations come before the references? 2) For the references, there is text that says the following: ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * * * The I-D (or a * * successor) is expected to eventually replace RFC 2669. * * If that draft (or a successor) is published as an RFC * * prior to or concurrently with this document, then the * * normative reference [RFC2669] should be updated to * * point to the replacement RFC, and the reference tag * * [RFC2669] should be updated to match. * * * ************************************************************ Shouldn't the I-D just be referenced? Some of these references seem that they should reference the I-D, not the RFC. Ted Hardie: Comment: [2004-09-24] I have to say that I think the v4-only nature of this doc is pretty questionable; I understand that the document is relative to DOCSIS deployments which don't deploy v6, but this is starting them down a design road that is going to require more than a little backtracking. The whole mechanism presumes that use of multiple address is a wrong/restricted activity; this isn't the right focus for v6. Rather than working out some management framework than can handle both, they could end up with such separate things that the user experience is affected by the overlapping attempts at control (or the attempts to control are frustrated trivially). I'm not DISCUSSing this document, since it is clear on its scope, but I strongly encourage them to create a joint v4/v6 management scope as a successor to this, rather than a v6 auxillary to this. Russ Housley: Comment: [2004-09-22] The 2nd paragraph of Section 9 says: : : Effective network filtering of TCP traffic requires that implementors : MUST follow the recommendations in section 3.2.6. : I suggest replacement text: For network filtering of TCP traffic to be effective, implementors MUST follow the recommendations in section 3.2.6. Allison Mankin: Discuss: [2004-09-26] The document states: Effective network filtering of TCP traffic requires that implementors MUST follow the recommendations in section 3.2.6. But there is no section 3.2.6 here. MUST must be clear. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Sep 27 17:46: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 RAA12428 for ; Mon, 27 Sep 2004 17:46:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC3Ru-0001Lk-Sj for ipcdn-archive@ietf.org; Mon, 27 Sep 2004 17:54:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC38B-0000rm-RY; Mon, 27 Sep 2004 17:33:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC2tI-0003tP-Cb for ipcdn@megatron.ietf.org; Mon, 27 Sep 2004 17:18:36 -0400 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 RAA09756 for ; Mon, 27 Sep 2004 17:18:33 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC30z-0000Tg-8h for ipcdn@ietf.org; Mon, 27 Sep 2004 17:26:33 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i8RLI2Ws001950 for ; Mon, 27 Sep 2004 16:18:03 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Sep 2004 23:18:02 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79D39@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Date: Mon, 27 Sep 2004 23:17:56 +0200 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: 87a3f533bb300b99e2a18357f3c1563d Subject: [ipcdn] FW: IESG review of: draft-ietf-ipcdn-subscriber-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.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Sorry, forgot to set proper subject line -----Original Message----- From: Wijnen, Bert (Bert) Sent: Monday, September 27, 2004 23:14 To: 'wsawyer@ieee.org'; Ipcdn (E-mail) Subject: IESG review of: So below is the complete set of IESG review comments. I think my reaction is as follows: 1. W.r.t. to referencing draft-ietf-ipcdn-device-mibv2-06.txt I wonder what the current status is of that document? It experied a while ago... and I am not seeing activity. So maybe we should just list RFC2669 and not talk about the draft? 2. Based on the above, I also wonder about draft-ietf-ipcdn-docs-rfmibv2-06.txt Where are we with that one? 3. The comment from Ted Hardie is the same as some discussion we had from Steve Bellovin, and I believe the answer is that current MODULE COMPLIANCE only requires IPv4 but the MIB module itself is all ready to also support IPv6. So no change needed. 4. The comments from Russ and Allison's DISCUSS seem valid to me. So to address all of the above, I could add the following RFC-Editor notes: RFC-Editor, pls fix the following - on page 4, pls ignore and remove: -- *********************************************************** -- * Note to RFC Editor (to be removed) -- * If DOCSIS Cable Device MIB [RFC2669] is updated prior to -- * this publication, replace "docsDevCpeIp" with -- * "docsDevCpeInetAddr" -- *********************************************************** - mmm also comes back on page 10 and page 14 - In section 9, 2nd para, pls change text OLD: Effective network filtering of TCP traffic requires that implementors MUST follow the recommendations in section 3.2.6. NEW: For network filtering of TCP traffic to be effective, implementors MUST follow the recommendations in section 3.4. - on page 23, pls ignore and remove: ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * * * The I-D (or a * * successor) is expected to eventually replace RFC 2669. * * If that draft (or a successor) is published as an RFC * * prior to or concurrently with this document, then the * * normative reference [RFC2669] should be updated to * * point to the replacement RFC, and the reference tag * * [RFC2669] should be updated to match. * * * ************************************************************ - ANd possibly a similar statement about draft-ietf-ipcdn-docs-rfmibv2-06.txt Mmm... that is I think more than we want to do in an RFC-Ed note. Wilson, how quick can you do a revision? Bert ------------- IESG comments/discusses Discusses and Comments Harald Alvestrand: Comment: [2004-09-27] Reviewed by John Loughney, Gen-ART His review: Document seems ready, a couple of small nits: 1) Shouldn't the Security Considerations come before the references? 2) For the references, there is text that says the following: ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * * * The I-D (or a * * successor) is expected to eventually replace RFC 2669. * * If that draft (or a successor) is published as an RFC * * prior to or concurrently with this document, then the * * normative reference [RFC2669] should be updated to * * point to the replacement RFC, and the reference tag * * [RFC2669] should be updated to match. * * * ************************************************************ Shouldn't the I-D just be referenced? Some of these references seem that they should reference the I-D, not the RFC. Ted Hardie: Comment: [2004-09-24] I have to say that I think the v4-only nature of this doc is pretty questionable; I understand that the document is relative to DOCSIS deployments which don't deploy v6, but this is starting them down a design road that is going to require more than a little backtracking. The whole mechanism presumes that use of multiple address is a wrong/restricted activity; this isn't the right focus for v6. Rather than working out some management framework than can handle both, they could end up with such separate things that the user experience is affected by the overlapping attempts at control (or the attempts to control are frustrated trivially). I'm not DISCUSSing this document, since it is clear on its scope, but I strongly encourage them to create a joint v4/v6 management scope as a successor to this, rather than a v6 auxillary to this. Russ Housley: Comment: [2004-09-22] The 2nd paragraph of Section 9 says: : : Effective network filtering of TCP traffic requires that implementors : MUST follow the recommendations in section 3.2.6. : I suggest replacement text: For network filtering of TCP traffic to be effective, implementors MUST follow the recommendations in section 3.2.6. Allison Mankin: Discuss: [2004-09-26] The document states: Effective network filtering of TCP traffic requires that implementors MUST follow the recommendations in section 3.2.6. But there is no section 3.2.6 here. MUST must be clear. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Sep 27 17:51:19 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 RAA12800 for ; Mon, 27 Sep 2004 17:51:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC3Wh-0001RX-WF for ipcdn-archive@ietf.org; Mon, 27 Sep 2004 17:59:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC39c-0001QK-IH; Mon, 27 Sep 2004 17:35:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC33y-00054C-Lf for ipcdn@megatron.ietf.org; Mon, 27 Sep 2004 17:29:38 -0400 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 RAA10412 for ; Mon, 27 Sep 2004 17:29:35 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC3Bd-0000i3-KT for ipcdn@ietf.org; Mon, 27 Sep 2004 17:37:36 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i8RLT360007352 for ; Mon, 27 Sep 2004 16:29:03 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Sep 2004 23:29:02 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79D3A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'e.cardona@cablelabs.com'" , "Ipcdn (E-mail)" Date: Mon, 27 Sep 2004 23:29:00 +0200 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: 093efd19b5f651b2707595638f6c4003 Subject: [ipcdn] IESG review of: draft-ietf-ipcdn-bpiplus-mib-14.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 OK, below is the complete set of IESG comments. I know that discussion on the security issues is already underway. Pls make sure to address both Steve Bellovin's and Russ' Housleys DISCUSS comments. Pls also take a look at the other comments. And you may want to check statements like: ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * * * The I-D (or a * * successor) is expected to eventually replace RFC 2670. * * If that draft (or a successor) is published as an RFC * * prior to or concurrently with this document, then the * * normative reference [RFC2670] should be updated to * * point to the replacement RFC, and the reference tag * * [RFC2670] should be updated to match. * * * ************************************************************ cause I am not sure that that document is making real progress is it? The IANA of course was concerned about the IANA considerations and the assignment under ::= { docsIfMib yy } I believe we agreed that this one can go underneath mib-2, right? ANother nit I noticed: docsBpi2MIB MODULE-IDENTITY LAST-UPDATED "200409071700Z" -- September 7th, 2004 ORGANIZATION "IETF IP over Cable Data Network (IPCDN) > Working Group" CONTACT-INFO "--------------------------------------- you may want to remove that ">" sign at the beginning of line: > Working Group" Bert ------------ IESG comments and dsicusses Steve Bellovin: Discuss: [2004-09-24] The Security Considerations section says The time to crack DES could be additionally mitigated by a compromised value for the TEK lifetime and Grace Time (up to a minimum of 30 minutes for the TEK lifetime, see Appendix A [1]). That's only partially correct. These keys are confidentiality keys; they're still valuable even after they're no longer in active use, because they can be used to decrypt old traffic. (By contrast, old authentication keys are useless to an attacker.) Comment: [2004-09-24] I concur in Russ' comments about the lack of any suitably strong crypto algorithms. 40-bit DES is, frankly, an embarrassment at this point. Yes, I realize that DOCSIS isn't doing it right yet; that's no reason for us to do it wrong. We should put the code points into the MIB now, and let them catch up. But I'll let Russ hold that part of the DISCUSS (as well as the note that authentication algorithms are needed.) Russ Housley: Discuss: [2004-09-23] The definition of docsBpi2CmPublicKey begins: : : docsBpi2CmPublicKey OBJECT-TYPE : SYNTAX OCTET STRING (SIZE (74|106|140|204|270)) : The selection of these few octet string sizes is inappropriate. PKCS #1 encoding of an RSA public key is a SEQUENCE of two INTEGERs. One example of an acceptable RSA public key that cannot be accommodated by this definition follows. It is 139 octets. 0 30 135: SEQUENCE { 3 02 129: INTEGER : 00 B0 B3 67 A7 96 B5 76 83 E9 16 03 D9 1A A0 76 : D5 74 E7 9C 05 D2 51 3F DB 4F 19 A1 A8 39 4E CB : 24 7D 61 C4 1E 6A 20 AE 0F 81 DE EA B8 39 FD 1B : 1F 6B 36 40 ED 4D 21 25 F2 A3 D9 A1 51 D8 6C C0 : 1B 96 F8 D4 42 94 D4 A7 CE 1B 8F D3 54 26 A2 84 : EF 32 85 AF 4A 3F F1 32 36 AF 3D E6 3A 27 EB 03 : C2 25 7E F4 61 2B AD 8A 1A 4B E6 9B 36 68 D4 2F : E5 D2 88 94 DC 16 AA DA C2 15 4C 6C C3 E1 19 91 : C9 135 02 1: INTEGER 3 : } I do not believe that a five (or even ten) specific sizes can be chosen that accomodate all valid RSA public keys. The definition of docsBpi2CmtsAuthCmPublicKey has the same problem. The definition of docsBpi2CmTEKDataEncryptAlg begins: : : docsBpi2CmTEKDataEncryptAlg OBJECT-TYPE : SYNTAX INTEGER { : none(0), : des56CbcMode(1), : des40CbcMode(2) : } : And, the definition of docsBpi2CmTEKDataAuthentAlg begins: : : docsBpi2CmTEKDataAuthentAlg OBJECT-TYPE : SYNTAX INTEGER { : none(0) : } : These same values are also used in the docsBpi2CmCryptoSuiteDataEncryptAlg, docsBpi2CmCryptoSuiteDataAuthentAlg, docsBpi2CmtsTEKDataEncryptAlg, docsBpi2CmtsTEKDataAuthentAlg, docsBpi2CmtsIpMulticastDataEncryptAlg, and docsBpi2CmtsIpMulticastDataAuthentAlg definitions. None of the encryption algorithm choices is a strong encryption algorithm. Also, the encryption algorithm choice do not provide integrity, so they ought to be used with an integrity algorithm, but none are specified. Can we get a strong encryption algorithm added to the list? Can we get an strong integrity algorithm specified? If not, the last few paragraphs of of the Security Considerations need to be made much more forceful. Comment: [2004-09-22] Please delete the second paragraph of the Abstract prior to publication as an RFC. In the Abstract: s/DOCSIS1.1/DOCSIS 1.1/ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Sep 28 13:42:34 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 NAA07196 for ; Tue, 28 Sep 2004 13:42:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCM7c-00060q-94 for ipcdn-archive@ietf.org; Tue, 28 Sep 2004 13:50:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCLtA-0001Px-6t; Tue, 28 Sep 2004 13:35:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCLf2-0007ux-N6 for ipcdn@megatron.ietf.org; Tue, 28 Sep 2004 13:21:08 -0400 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 NAA06101 for ; Tue, 28 Sep 2004 13:21:05 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCLmr-0005cQ-Bc for ipcdn@ietf.org; Tue, 28 Sep 2004 13:29:16 -0400 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 i8SHKTkH003557; Tue, 28 Sep 2004 11:20:30 -0600 (MDT) 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: RE: [ipcdn] FW: IESG review of: draft-ietf-ipcdn-subscriber-mib-15.txt Date: Tue, 28 Sep 2004 11:20:29 -0600 Message-ID: Thread-Topic: [ipcdn] FW: IESG review of: draft-ietf-ipcdn-subscriber-mib-15.txt Thread-Index: AcSk251pZBkWg3gYRUaBrLWzQs/GYAAn333Q From: "Jean-Francois Mule" To: "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 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: b84f8c8fba0e1389e5eb998b64078964 Content-Transfer-Encoding: quoted-printable [sending the same text I sent to Wilson, Rich and Bert to IPCDN] I have some questions/concerns before deciding on the reference part. > > 1. W.r.t. to referencing draft-ietf-ipcdn-device-mibv2-06.txt > > I wonder what the current status is of that document? > > It experied a while ago... and I am not seeing activity. > > So maybe we should just list RFC2669 and not talk about > > the draft? > > I made some comments to Wilson in draft 15 about some tables that were = being deprecated or superseded by others in the cable device mib v2. For = e.g., section 3.2.1 in draft 15 now says: ---------------------------------- 3.2.1. Interaction with DOCSIS provisioning for CPE address control Rows in docsSubMgtCpeControlTable are created by the CMTS for each modem as a result of the DOCSIS registration process. The DOCSIS registration attributes may include items semantically equivalent to those in the docsDevCpe section of the DOCSIS Cable Device MIB [RFC2669]: o docsDevCpeEnroll o docsDevCpeIpMax o docsDevCpeIp -- *********************************************************** -- * Note to RFC Editor (to be removed) -- * If DOCSIS Cable Device MIB [RFC2669] is updated prior to -- * this publication, replace "docsDevCpeIp" with -- * "docsDevCpeInetAddr" -- *********************************************************** ---------------------------------- =3D> While I have no objection referencing RFC 2669 instead of the cable = device v2 MIB, I am concerned that some of the core tables used in the = subs mgmt mib are going away in RFC2669bis: for e.g. docsDevCpeTable. So the content of my comment to Wilson can be summarized as follows: + if the subs mgmt MIB module is supposed to co-exist with both = RFC2669 and its successor, may be we want to be explicit here and = provide guidance on what tables to use in each case. + if the subs mgmt MIB module is supposed to co-exist only with = RFC2669, I'm ok with removing the above text but I have some concerns = that within ipcdn, we are not consistent. + if the subs mgmt MIB module is supposed to co-exist with = RFC2669bis - the successor of RFC2669, may be we want to be explicit = here and provide guidance on what tables to use in case the old RFC is = implemented as well. Finally, I do not understand why the subs mgmt MIB could not move to = RFC editor status now and await the 2 dependent IDs to be updated and = advance. It seems that the proposed alternatives do not take into = consideration some of the updates in RFC2669bis and I have a pb with = that. Comments? Jean-Fran=E7ois=20 > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 > Sent: Monday, September 27, 2004 3:18 PM > To: Ipcdn (E-mail) > Subject: [ipcdn] FW: IESG review of:=20 > draft-ietf-ipcdn-subscriber-mib-15.txt >=20 >=20 > Sorry, forgot to set proper subject line >=20 > -----Original Message----- > From: Wijnen, Bert (Bert)=20 > Sent: Monday, September 27, 2004 23:14 > To: 'wsawyer@ieee.org'; Ipcdn (E-mail) > Subject: IESG review of:=20 >=20 >=20 >=20 > So below is the complete set of IESG review comments. >=20 > I think my reaction is as follows: >=20 > 1. W.r.t. to referencing draft-ietf-ipcdn-device-mibv2-06.txt > I wonder what the current status is of that document? > It experied a while ago... and I am not seeing activity. > So maybe we should just list RFC2669 and not talk about > the draft? >=20 > 2. Based on the above, I also wonder about=20 > draft-ietf-ipcdn-docs-rfmibv2-06.txt > Where are we with that one? >=20 > 3. The comment from Ted Hardie is the same as some discussion we=20 > had from Steve Bellovin, and I believe the answer is that=20 > current MODULE COMPLIANCE only requires IPv4 but the=20 > MIB module itself is all ready to also support IPv6. > So no change needed. >=20 > 4. The comments from Russ and Allison's DISCUSS seem valid to me. >=20 > So to address all of the above, I could add the > following RFC-Editor notes: >=20 > RFC-Editor, pls fix the following=20 >=20 > - on page 4, pls ignore and remove: >=20 > -- *********************************************************** > -- * Note to RFC Editor (to be removed) > -- * If DOCSIS Cable Device MIB [RFC2669] is updated prior to > -- * this publication, replace "docsDevCpeIp" with > -- * "docsDevCpeInetAddr" > -- *********************************************************** >=20 > - mmm also comes back on page 10 and page 14 >=20 > - In section 9, 2nd para, pls change text >=20 > OLD: > Effective network filtering of TCP traffic requires that=20 > implementors > MUST follow the recommendations in section 3.2.6. > =20 > NEW: > For network filtering of TCP traffic to be effective, implementors > MUST follow the recommendations in section 3.4. >=20 > - on page 23, pls ignore and remove: > ************************************************************ > * NOTES TO RFC Editor (to be removed prior to publication) * > * * > * The I-D (or a * > * successor) is expected to eventually replace RFC 2669. * > * If that draft (or a successor) is published as an RFC * > * prior to or concurrently with this document, then the * > * normative reference [RFC2669] should be updated to * > * point to the replacement RFC, and the reference tag * > * [RFC2669] should be updated to match. * > * * > ************************************************************ >=20 > - ANd possibly a similar statement about > draft-ietf-ipcdn-docs-rfmibv2-06.txt >=20 > Mmm... that is I think more than we want to do in an RFC-Ed=20 > note. Wilson, how quick can you do a revision? >=20 > Bert >=20 > ------------- IESG comments/discusses=20 >=20 > Discusses and Comments=20 > Harald Alvestrand: > Comment: > [2004-09-27] Reviewed by John Loughney, Gen-ART >=20 > His review: >=20 > Document seems ready, a couple of small nits: >=20 > 1) Shouldn't the Security Considerations come before the references? > 2) For the references, there is text that says the following: >=20 > ************************************************************ > * NOTES TO RFC Editor (to be removed prior to publication) * > * * > * The I-D (or a * > * successor) is expected to eventually replace RFC 2669. * > * If that draft (or a successor) is published as an RFC * > * prior to or concurrently with this document, then the * > * normative reference [RFC2669] should be updated to * > * point to the replacement RFC, and the reference tag * > * [RFC2669] should be updated to match. * > * * > ************************************************************ >=20 > Shouldn't the I-D just be referenced? Some of these=20 > references seem that they should reference the I-D, not the RFC. >=20 > Ted Hardie: > Comment: > [2004-09-24] I have to say that I think the v4-only nature of=20 > this doc is pretty questionable; I understand that the=20 > document is relative to DOCSIS deployments which don't deploy=20 > v6, but this is starting them down a design road that is=20 > going to require more than a little backtracking. The whole=20 > mechanism presumes that use of multiple address is a=20 > wrong/restricted activity; this isn't the right focus for v6.=20 > Rather than working out some management=20 > framework than can handle both, they could end up with such=20 > separate things that the user experience is affected by the=20 > overlapping attempts at control (or the attempts to control=20 > are frustrated trivially). >=20 > I'm not DISCUSSing this document, since it is clear on its=20 > scope, but I strongly encourage them to create a joint v4/v6=20 > management scope as a successor to this, rather than a v6=20 > auxillary to this. >=20 > Russ Housley: > Comment: > [2004-09-22]=20 > The 2nd paragraph of Section 9 says: > : > : Effective network filtering of TCP traffic requires that=20 > implementors > : MUST follow the recommendations in section 3.2.6. > : > I suggest replacement text: > =20 > For network filtering of TCP traffic to be effective, implementors > MUST follow the recommendations in section 3.2.6. >=20 > Allison Mankin: > Discuss: > [2004-09-26] The document states: > Effective network filtering of TCP traffic requires that=20 > implementors > MUST follow the recommendations in section 3.2.6. > But there is no section 3.2.6 here. MUST must be clear. >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Sep 28 18:28: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 SAA29636 for ; Tue, 28 Sep 2004 18:28:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCQa4-0004ZY-CR for ipcdn-archive@ietf.org; Tue, 28 Sep 2004 18:36:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCQI9-0004NQ-2V; Tue, 28 Sep 2004 18:17:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCQ5o-0005NG-OH for ipcdn@megatron.ietf.org; Tue, 28 Sep 2004 18:05:04 -0400 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 SAA26861 for ; Tue, 28 Sep 2004 18:05:01 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCQDi-0003tc-WF for ipcdn@ietf.org; Tue, 28 Sep 2004 18:13:15 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i8SM6GDx002944 for ; Tue, 28 Sep 2004 15:06:16 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i8SM3oTk015822 for ; Tue, 28 Sep 2004 17:03:51 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Sep 2004 15:05:00 -0700 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" , "'satish.kumar@ti.com'" Date: Tue, 28 Sep 2004 15:04:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.8 (++) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Subject: [ipcdn] IETF NCS Sig MIB draft 6 -> Issue for pktcSigDevToneWholeToneRepe atCount/pktcSigDevToneSteady when duration is shorter than TO 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="===============1402824146==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 2.8 (++) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 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. --===============1402824146== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A5A7.321B0BB2" 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_01C4A5A7.321B0BB2 Content-Type: text/plain Satish, Thanks for raising this issue. The intent of the pktcSigDevToneWholeToneRepeatCount and pktcSigDevToneSteady was to support telco industry standards. If a tone definition using repeat count objects results in a tone sequence that is shorter than the TO time, the repeat count takes significance. I checked the NCS spec on this issue and I don't see a clear indication of expected behaviour when a tone duration is shorter than an associated TO. Do you have text you would like to propose as a solution for the description of these objects? Comments? Gordon >The MIbs specify the case where longer duration is set. However they do not specifically say what to do in the case >where setting the pktcSigDevToneWholeToneRepeatCount results in a tone duration which is shorter than the tone >duration which is specified through the timeout (TO)??? >What is the expected duration behavior in this case?? Does the MTA has to observe the specified number of repeat counts?? or does it stick to the value in timeout(TO) MIB? Please throw some light on expected behavior. pktcSigDevToneWholeToneRepeatCount OBJECT-TYPE SYNTAX Unsigned32 (0..5000) MAX-ACCESS read-write STATUS current DESCRIPTION "This is the repeat count, which signifies how many times to repeat the entire on-off sequence. Setting this object may result in a tone duration longer than the overall signal duration specified by the time out (TO) object for a particular signal. In this case, the tone duration defined by the TO object for a particular signal always represents the overall signal duration for a tone." ::={ pktcSigDevToneEntry 18 } pktcSigDevToneSteady OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is the steady tone. Device must play out the on-off sequence for pktcSigDevToneWholeRepeatCount times and then apply the last tone forever. Setting this object may result in a tone duration longer than the overall signal duration specified by the time out (TO) object for a particular signal. In this case, the tone duration defined by the TO object for a particular signal always represents the overall signal duration for a tone." ::={ pktcSigDevToneEntry 19 } ------_=_NextPart_001_01C4A5A7.321B0BB2 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NTgiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNs YXNzPTM0NjU1MjIxOC0yODA5MjAwND5TYXRpc2gsPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz0zNDY1NTIyMTgtMjgwOTIwMDQ+ PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+ PFNQQU4gY2xhc3M9MzQ2NTUyMjE4LTI4MDkyMDA0PlRoYW5rcyBmb3IgcmFpc2luZyANCnRoaXMg aXNzdWUuJm5ic3A7VGhlIGludGVudCBvZiB0aGUmbmJzcDtwa3RjU2lnRGV2VG9uZVdob2xlVG9u ZVJlcGVhdENvdW50IGFuZCANCnBrdGNTaWdEZXZUb25lU3RlYWR5IHdhcyB0byBzdXBwb3J0IHRl bGNvIGluZHVzdHJ5IHN0YW5kYXJkcy4gSWYgYSB0b25lIA0KZGVmaW5pdGlvbiB1c2luZyByZXBl YXQgY291bnQgb2JqZWN0cyZuYnNwO3Jlc3VsdHMgaW4gYSB0b25lIHNlcXVlbmNlIHRoYXQgaXMg DQpzaG9ydGVyIHRoYW4mbmJzcDt0aGUgVE8gdGltZSwgdGhlIHJlcGVhdCBjb3VudCB0YWtlcyBz aWduaWZpY2FuY2UuIEkgY2hlY2tlZCANCnRoZSBOQ1Mgc3BlYyBvbiB0aGlzIGlzc3VlIGFuZCZu YnNwO0kgZG9uJ3Qgc2VlIGEgY2xlYXIgaW5kaWNhdGlvbiBvZiBleHBlY3RlZCANCmJlaGF2aW91 ciB3aGVuIGEgdG9uZSBkdXJhdGlvbiBpcyBzaG9ydGVyIHRoYW4gYW4gYXNzb2NpYXRlZCANClRP LjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFO IA0KY2xhc3M9MzQ2NTUyMjE4LTI4MDkyMDA0PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTM0NjU1MjIxOC0yODA5MjAw ND5EbyB5b3UgaGF2ZSB0ZXh0IHlvdSANCndvdWxkIGxpa2UgdG8mbmJzcDtwcm9wb3NlIGFzIGEg c29sdXRpb24gZm9yIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGVzZSANCm9iamVjdHM/PC9TUEFOPjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz0z NDY1NTIyMTgtMjgwOTIwMDQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz0zNDY1NTIyMTgtMjgwOTIwMDQ+Q29tbWVu dHM/PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQ QU4gDQpjbGFzcz0zNDY1NTIyMTgtMjgwOTIwMDQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz0zNDY1NTIyMTgtMjgw OTIwMDQ+R29yZG9uPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+PFNQQU4gDQpjbGFzcz0zNDY1NTIyMTgtMjgwOTIwMDQ+PC9TUEFOPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQ+PFNQQU4gY2xhc3M9MzQ2NTUyMjE4LTI4MDkyMDA0PjxGT05U IHNpemU9Mj48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZj4mZ3Q7VGhlJm5ic3A7TUli cyBzcGVjaWZ5IHRoZSBjYXNlIHdoZXJlIGxvbmdlciBkdXJhdGlvbiBpcyANCnNldC4mbmJzcDtI PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZj48U1BBTiANCmNsYXNzPTAxNzIz MzAxOS0yNzA5MjAwND5vd2V2ZXImbmJzcDt0aGV5IGRvIG5vdCZuYnNwO3NwZWNpZmljYWxseSBz YXkgd2hhdCB0byANCmRvIGluIHRoZSBjYXNlICZndDt3aGVyZSBzZXR0aW5nIHRoZSBwa3RjU2ln RGV2VG9uZVdob2xlVG9uZVJlcGVhdENvdW50IHJlc3VsdHMgDQppbiBhJm5ic3A7dG9uZSZuYnNw O2R1cmF0aW9uIHdoaWNoIGlzIDxTVFJPTkc+c2hvcnRlcjwvU1RST05HPiB0aGFuIA0KdGhlJm5i c3A7dG9uZSAmZ3Q7ZHVyYXRpb24gd2hpY2ggaXMgc3BlY2lmaWVkJm5ic3A7dGhyb3VnaCB0aGUm bmJzcDt0aW1lb3V0IA0KKFRPKT8/PyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PC9GT05UPjwv Rk9OVD4NCjxESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+ PFNQQU4gDQpjbGFzcz0wMTcyMzMwMTktMjcwOTIwMDQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PFNQQU4gY2xhc3M9MDE3MjMzMDE5LTI3MDkyMDA0PjxGT05UIGZhY2U9QXJpYWw+ PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9OVCANCnNpemU9Mj48U1BBTiBjbGFzcz0zNDY1NTIyMTgt MjgwOTIwMDQ+Jmd0OzwvU1BBTj5XaGF0IGlzIHRoZSBleHBlY3RlZCBkdXJhdGlvbiANCmJlaGF2 aW9yIGluIHRoaXMgY2FzZT8/Jm5ic3A7RG9lcyB0aGUgTVRBIGhhcyB0byBvYnNlcnZlIHRoZSBz cGVjaWZpZWQgbnVtYmVyIG9mIA0KcmVwZWF0Jm5ic3A7Y291bnRzPz8gb3IgZG9lcyBpdCBzdGlj ayB0byB0aGUgdmFsdWUgaW4mbmJzcDt0aW1lb3V0KFRPKSANCk1JQj8mbmJzcDsgUGxlYXNlIHRo cm93IHNvbWUgbGlnaHQgb24gZXhwZWN0ZWQgDQpiZWhhdmlvci48L0ZPTlQ+PC9GT05UPjwvRk9O VD48L1NQQU4+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXpl PTI+PFNQQU4gDQpjbGFzcz0wMTcyMzMwMTktMjcwOTIwMDQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8 L0RJVj48L0RJVj48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj48U1BBTiBjbGFzcz0zNDY1NTIyMTgtMjgwOTIwMDQ+DQo8RElWPjxGT05UIGZhY2U9QXJp YWwgDQpzaXplPTI+cGt0Y1NpZ0RldlRvbmVXaG9sZVRvbmVSZXBlYXRDb3VudCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCk9CSkVDVC1UWVBFJm5ic3A7IDxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpTWU5UQVgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVW5zaWduZWQzMiAoMC4uNTAwMCkmbmJzcDsgDQo8QlI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1BWC1BQ0NFU1MmbmJzcDsmbmJzcDsgcmVhZC13cml0 ZSZuYnNwOyANCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpTVEFU VVMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY3VycmVudCZuYnNwOyANCjxC Uj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgREVTQ1JJUFRJT04mbmJzcDsg DQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICJUaGlzIGlzIHRoZSANCnJlcGVhdCBjb3VudCwgd2hpY2ggc2lnbmlmaWVzIGhv dyBtYW55IHRpbWVzIA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byByZXBlYXQgDQp0aGUgZW50aXJlIG9uLW9m ZiBzZXF1ZW5jZS4gPEZPTlQgY29sb3I9I2ZmMDAwMD5TZXR0aW5nIHRoaXMgb2JqZWN0IA0KPEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBtYXkgDQpyZXN1bHQgaW4gYSB0b25lIGR1cmF0aW9uIDxVPmxvbmdlcjwvVT4g dGhhbiB0aGUgb3ZlcmFsbCANCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2lnbmFsIA0KZHVyYXRpb24gc3BlY2lm aWVkIGJ5IHRoZSB0aW1lIG91dCAoVE8pIG9iamVjdCBmb3IgYSANCjxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpw YXJ0aWN1bGFyIHNpZ25hbC4gSW4gdGhpcyBjYXNlLCB0aGUgdG9uZSBkdXJhdGlvbiBkZWZpbmVk IA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBieSB0aGUgVE8gDQpvYmplY3QgZm9yIGEgcGFydGljdWxhciBzaWdu YWwgYWx3YXlzIHJlcHJlc2VudHMgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSANCm92ZXJhbGwgc2lnbmFs IGR1cmF0aW9uIGZvciBhIHRvbmUuPC9GT05UPiIgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDo6PXsgcGt0Y1NpZ0RldlRvbmVFbnRyeSAxOCANCn0mbmJzcDsmbmJz cDs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PEJSPjxCUj48QlI+Jm5ic3A7Jm5ic3A7IA0K cGt0Y1NpZ0RldlRvbmVTdGVhZHkmbmJzcDsmbmJzcDsmbmJzcDsgT0JKRUNULVRZUEUmbmJzcDsg DQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KU1lOVEFYJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRydXRoVmFsdWUmbmJzcDsgDQo8QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1BWC1BQ0NFU1MmbmJzcDsmbmJzcDsg cmVhZC13cml0ZSZuYnNwOyANCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQpTVEFUVVMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY3VycmVudCZu YnNwOyANCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgREVTQ1JJUFRJ T04mbmJzcDsgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJUaGlzIGlzIHRoZSANCnN0ZWFkeSB0b25lLiBEZXZpY2UgbXVz dCBwbGF5IG91dCB0aGUgb24tb2ZmIA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZXF1ZW5jZSANCmZvciBwa3Rj U2lnRGV2VG9uZVdob2xlUmVwZWF0Q291bnQgdGltZXMgYW5kIA0KPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGVu IA0KYXBwbHkgdGhlIGxhc3QgdG9uZSBmb3JldmVyLiA8Rk9OVCBjb2xvcj0jZmYwMDAwPlNldHRp bmcgdGhpcyBvYmplY3QgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1heSANCnJlc3VsdCBpbiBhIHRvbmUgZHVy YXRpb24gPFU+bG9uZ2VyPC9VPiB0aGFuIHRoZSBvdmVyYWxsIA0KPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaWdu YWwgDQpkdXJhdGlvbiBzcGVjaWZpZWQgYnkgdGhlIHRpbWUgb3V0IChUTykgb2JqZWN0IGZvciBh IA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCnBhcnRpY3VsYXIgc2lnbmFsLiBJbiB0aGlzIGNhc2UsIHRoZSB0 b25lIGR1cmF0aW9uIGRlZmluZWQgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJ5IHRoZSBUTyANCm9iamVjdCBm b3IgYSBwYXJ0aWN1bGFyIHNpZ25hbCBhbHdheXMgcmVwcmVzZW50cyANCjxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dGhlIA0Kb3ZlcmFsbCBzaWduYWwgZHVyYXRpb24gZm9yIGEgdG9uZTwvRk9OVD4uIiZuYnNwOyAN CjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOjo9eyBwa3RjU2lnRGV2 VG9uZUVudHJ5IDE5IH0mbmJzcDsgDQo8QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+DQo8RElW PiZuYnNwOzwvRElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwg DQpzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjwvU1BBTj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwv SFRNTD4NCg== ------_=_NextPart_001_01C4A5A7.321B0BB2-- --===============1402824146== 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 --===============1402824146==-- From ipcdn-bounces@ietf.org Wed Sep 29 12:59: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 MAA19004 for ; Wed, 29 Sep 2004 12:59:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CChvO-0002Xg-Bs for ipcdn-archive@ietf.org; Wed, 29 Sep 2004 13:07:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CChXv-0004gj-CY; Wed, 29 Sep 2004 12:43:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CChP4-0002nH-4f for ipcdn@megatron.ietf.org; Wed, 29 Sep 2004 12:34:06 -0400 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 MAA17788 for ; Wed, 29 Sep 2004 12:34:02 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CChX7-00024n-Qz for ipcdn@ietf.org; Wed, 29 Sep 2004 12:42:26 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i8TGZIDx005394 for ; Wed, 29 Sep 2004 09:35:18 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i8TGY2EO010083 for ; Wed, 29 Sep 2004 11:34:02 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Wed, 29 Sep 2004 09:34:01 -0700 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" , "'satish.kumar@ti.com'" Date: Wed, 29 Sep 2004 09:34:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.7 (++) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec Subject: [ipcdn] RE: IETF NCS Sig MIB draft 6 -> Issue for pktcSigDevToneWholeTone RepeatCount/pktcSigDevToneSteady when duration is shorter than TO 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="===============0361240776==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 2.8 (++) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 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. --===============0361240776== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A642.20224C2C" 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_01C4A642.20224C2C Content-Type: text/plain Motorola's suggested text for the pktcSigDevToneWholeToneRepeatCount and pktcSigDevToneSteady objects to address this issue. Gordon pktcSigDevToneWholeToneRepeatCount OBJECT-TYPE SYNTAX Unsigned32 (0..5000) MAX-ACCESS read-write STATUS current DESCRIPTION "This is the repeat count, which signifies how many times to repeat the entire on-off sequence. Setting this object may result in a tone duration longer or shorter than the overall signal duration specified by the time out (TO) object for a particular signal. If the repeat count results in a longer tone duration than the signal duration specified by the TO, the tone duration defined by the TO object for a particular signal always represents the overall signal duration for a tone. In this case, the tone duration repeat count will not be fully exercised and the desired tone duration will be truncated per the TO setting. If the repeat count results in a shorter tone duration than the signal duration specified by the TO, the tone duration defined by the repeat count takes precedence over the TO and will end the signal event. In this case, the TO represents a time not to be exceeded for the signal. It is recommended to ensure proper telephony signalling that the TO duration setting should always be longer than the desired repeat count time duration." ::={ pktcSigDevToneEntry 18 } pktcSigDevToneSteady OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is the steady tone. Device must play out the on-off sequence for pktcSigDevToneWholeRepeatCount times and then apply the last tone forever. Setting this object may result in a tone duration longer or shorter than the overall signal duration specified by the time out (TO) object for a particular signal. If the repeat count results in a longer tone duration than the signal duration specified by the TO, the tone duration defined by the TO object for a particular signal always represents the overall signal duration for a tone. In this case, the tone duration repeat count will not be fully exercised and the desired tone duration will be truncated per the TO setting. If the repeat count results in a shorter tone duration than the signal duration specified by the TO, the tone duration defined by the repeat count takes precedence over the TO and will end the signal event. In this case, the TO represents a time not to be exceeded for the signal. It is recommended to ensure proper telephony signalling that the TO duration setting should always be longer than the desired repeat count time duration plus the desired maximum steady tone period. " ::={ pktcSigDevToneEntry 19 } -----Original Message----- From: Beacham Gordon-CGB005 Sent: Tuesday, September 28, 2004 3:05 PM To: 'ipcdn@ietf.org'; 'satish.kumar@ti.com' Subject: IETF NCS Sig MIB draft 6 -> Issue for pktcSigDevToneWholeToneRepeatCount/pktcSigDevToneSteady when duration is shorter than TO Satish, Thanks for raising this issue. The intent of the pktcSigDevToneWholeToneRepeatCount and pktcSigDevToneSteady was to support telco industry standards. If a tone definition using repeat count objects results in a tone sequence that is shorter than the TO time, the repeat count takes significance. I checked the NCS spec on this issue and I don't see a clear indication of expected behaviour when a tone duration is shorter than an associated TO. Do you have text you would like to propose as a solution for the description of these objects? Comments? Gordon >The MIbs specify the case where longer duration is set. However they do not specifically say what to do in the case >where setting the pktcSigDevToneWholeToneRepeatCount results in a tone duration which is shorter than the tone >duration which is specified through the timeout (TO)??? >What is the expected duration behavior in this case?? Does the MTA has to observe the specified number of repeat counts?? or does it stick to the value in timeout(TO) MIB? Please throw some light on expected behavior. pktcSigDevToneWholeToneRepeatCount OBJECT-TYPE SYNTAX Unsigned32 (0..5000) MAX-ACCESS read-write STATUS current DESCRIPTION "This is the repeat count, which signifies how many times to repeat the entire on-off sequence. Setting this object may result in a tone duration longer than the overall signal duration specified by the time out (TO) object for a particular signal. In this case, the tone duration defined by the TO object for a particular signal always represents the overall signal duration for a tone." ::={ pktcSigDevToneEntry 18 } pktcSigDevToneSteady OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is the steady tone. Device must play out the on-off sequence for pktcSigDevToneWholeRepeatCount times and then apply the last tone forever. Setting this object may result in a tone duration longer than the overall signal duration specified by the time out (TO) object for a particular signal. In this case, the tone duration defined by the TO object for a particular signal always represents the overall signal duration for a tone." ::={ pktcSigDevToneEntry 19 } ------_=_NextPart_001_01C4A642.20224C2C Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NTgiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz02NDg0NzI2MTYtMjkwOTIwMDQ+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPk1vdG9yb2xhJ3Mgc3VnZ2VzdGVk IHRleHQgZm9yIHRoZSA8Rk9OVCANCmNvbG9yPSMwMDAwMDA+cGt0Y1NpZ0RldlRvbmVXaG9sZVRv bmVSZXBlYXRDb3VudCA8L0ZPTlQ+PEZPTlQgY29sb3I9IzAwMDBmZj5hbmQgDQo8Rk9OVCBmYWNl PVRhaG9tYSBjb2xvcj0jMDAwMDAwPnBrdGNTaWdEZXZUb25lU3RlYWR5IDwvRk9OVD5vYmplY3Rz IHRvIGFkZHJlc3MgDQp0aGlzIGlzc3VlLjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJ Vj48U1BBTiBjbGFzcz02NDg0NzI2MTYtMjkwOTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNs YXNzPTY0ODQ3MjYxNi0yOTA5MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpz aXplPTI+R29yZG9uPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NjQ4NDcy NjE2LTI5MDkyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZP TlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz02NDg0NzI2MTYtMjkwOTIw MDQ+PEZPTlQgc2l6ZT0yPjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmPnBrdGNTaWdE ZXZUb25lV2hvbGVUb25lUmVwZWF0Q291bnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQpPQkpFQ1QtVFlQRSZuYnNwOyA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KU1lOVEFYJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVuc2lnbmVk MzIgKDAuLjUwMDApJm5ic3A7IA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBNQVgtQUNDRVNTJm5ic3A7Jm5ic3A7IHJlYWQtd3JpdGUmbmJzcDsgDQo8QlI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KU1RBVFVTJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGN1cnJlbnQmbmJzcDsgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IERFU0NSSVBUSU9OJm5ic3A7IA0KPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAiVGhpcyBpcyB0 aGUgDQpyZXBlYXQgY291bnQsIHdoaWNoIHNpZ25pZmllcyBob3cgbWFueSB0aW1lcyANCjxCUj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgdG8gcmVwZWF0IA0KdGhlIGVudGlyZSBvbi1vZmYgc2VxdWVuY2UuIFNldHRpbmcg dGhpcyBvYmplY3QgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1heSANCnJlc3VsdCBpbiBhIHRvbmUgZHVyYXRp b24gbG9uZ2VyIG9yIHNob3J0ZXI8L0ZPTlQ+PC9GT05UPjxGT05UIHNpemU9Mj48Rk9OVCANCmZh Y2U9QXJpYWwgY29sb3I9IzAwMDBmZj4gdGhhbiB0aGUgb3ZlcmFsbCANCjxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg c2lnbmFsIA0KZHVyYXRpb24gc3BlY2lmaWVkIGJ5IHRoZSB0aW1lIG91dCAoVE8pIG9iamVjdCBm b3IgYSANCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpwYXJ0aWN1bGFyIHNpZ25hbC4gSWYgdGhlIHJlcGVhdCBj b3VudCByZXN1bHRzIGluIGEgbG9uZ2VyIHRvbmUgZHVyYXRpb24gdGhhbiANCnRoZSBzaWduYWwg ZHVyYXRpb24gc3BlY2lmaWVkIGJ5IHRoZSBUTzwvRk9OVD48L0ZPTlQ+PEZPTlQgc2l6ZT0yPjxG T05UIA0KZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmPiwgdGhlIHRvbmUgZHVyYXRpb24gZGVmaW5l ZCANCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgYnkgdGhlIFRPIA0Kb2JqZWN0IGZvciBhIHBhcnRpY3VsYXIgc2ln bmFsIGFsd2F5cyByZXByZXNlbnRzIA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgDQpvdmVyYWxsIHNpZ25h bCBkdXJhdGlvbiBmb3IgYSB0b25lLiZuYnNwOzxTUEFOIGNsYXNzPTc4MTExMDcxNi0yOTA5MjAw ND4mbmJzcDtJbiANCnRoaXMgY2FzZSwgdGhlIHRvbmUgZHVyYXRpb24mbmJzcDtyZXBlYXQgY291 bnQgd2lsbCBub3QgYmUgZnVsbHkgZXhlcmNpc2VkIGFuZCANCnRoZSBkZXNpcmVkIHRvbmUgZHVy YXRpb24gd2lsbCBiZSB0cnVuY2F0ZWQgcGVyIHRoZSBUTyANCnNldHRpbmcuJm5ic3A7Jm5ic3A7 PC9TUEFOPklmIHRoZSByZXBlYXQgY291bnQgcmVzdWx0cyBpbiBhIHNob3J0ZXIgdG9uZSANCmR1 cmF0aW9uIHRoYW4gdGhlIHNpZ25hbCBkdXJhdGlvbiBzcGVjaWZpZWQgYnkgdGhlIFRPLCB0aGUg dG9uZSBkdXJhdGlvbiBkZWZpbmVkIA0KYnkgdGhlIHJlcGVhdCBjb3VudCB0YWtlcyBwcmVjZWRl bmNlIG92ZXIgdGhlIFRPIGFuZCB3aWxsIGVuZCB0aGUgc2lnbmFsIGV2ZW50LiANCkluIHRoaXMg Y2FzZSwgdGhlIFRPIHJlcHJlc2VudHMgYSB0aW1lIG5vdCZuYnNwO3RvIGJlIGV4Y2VlZGVkIGZv ciB0aGUgDQpzaWduYWwuPC9GT05UPjwvRk9OVD48Rk9OVCBzaXplPTI+PEZPTlQgZmFjZT1Bcmlh bD48Rk9OVCBjb2xvcj0jMDAwMGZmPjxTUEFOIA0KY2xhc3M9NzgxMTEwNzE2LTI5MDkyMDA0PiZu YnNwOyZuYnNwOyBJdCBpcyByZWNvbW1lbmRlZCZuYnNwO3RvIGVuc3VyZSBwcm9wZXIgDQp0ZWxl cGhvbnkgc2lnbmFsbGluZyB0aGF0IHRoZSBUTyBkdXJhdGlvbiBzZXR0aW5nIHNob3VsZCBhbHdh eXMgYmUgbG9uZ2VyIHRoYW4gDQp0aGUgZGVzaXJlZCByZXBlYXQgY291bnQgdGltZSBkdXJhdGlv bi48L1NQQU4+IiANCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOjo9 eyBwa3RjU2lnRGV2VG9uZUVudHJ5IDE4IA0KfTwvRk9OVD48L0ZPTlQ+PC9GT05UPg0KPERJVj48 U1BBTiBjbGFzcz0xOTQwMzQyMTUtMjkwOTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj48 L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0xOTQwMzQyMTUtMjkw OTIwMDQ+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPnBrdGNT aWdEZXZUb25lU3RlYWR5Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9CSkVDVC1UWVBFJm5ic3A7IA0KPEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANClNZTlRBWCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUcnV0aFZhbHVlJm5ic3A7IA0KPEJSPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNQVgtQUNDRVNTJm5ic3A7Jm5ic3A7IHJlYWQt d3JpdGUmbmJzcDsgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K U1RBVFVTJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGN1cnJlbnQmbmJzcDsg DQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERFU0NSSVBUSU9OJm5i c3A7IA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAiVGhpcyBpcyB0aGUgDQpzdGVhZHkgdG9uZS4gRGV2aWNlIG11c3QgcGxh eSBvdXQgdGhlIG9uLW9mZiANCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VxdWVuY2UgDQpmb3IgcGt0Y1NpZ0Rl dlRvbmVXaG9sZVJlcGVhdENvdW50IHRpbWVzIGFuZCANCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlbiANCmFw cGx5IHRoZSBsYXN0IHRvbmUgZm9yZXZlci4gU2V0dGluZyB0aGlzIG9iamVjdCANCjxCUj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgbWF5IA0KcmVzdWx0IGluIGEgdG9uZSBkdXJhdGlvbiBsb25nZXIgb3Igc2hvcnRlciB0 aGFuIHRoZSBvdmVyYWxsIA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaWduYWwgDQpkdXJhdGlvbiBzcGVjaWZp ZWQgYnkgdGhlIHRpbWUgb3V0IChUTykgb2JqZWN0IGZvciBhIA0KPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnBh cnRpY3VsYXIgc2lnbmFsLiBJZiB0aGUgcmVwZWF0IGNvdW50IHJlc3VsdHMgaW4gYSBsb25nZXIg dG9uZSBkdXJhdGlvbiB0aGFuIA0KdGhlIHNpZ25hbCBkdXJhdGlvbiBzcGVjaWZpZWQgYnkgdGhl IFRPLCB0aGUgdG9uZSBkdXJhdGlvbiBkZWZpbmVkIA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBieSB0aGUgVE8g DQpvYmplY3QgZm9yIGEgcGFydGljdWxhciBzaWduYWwgYWx3YXlzIHJlcHJlc2VudHMgDQo8QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHRoZSANCm92ZXJhbGwgc2lnbmFsIGR1cmF0aW9uIGZvciBhIHRvbmUuIEluIHRo aXMgY2FzZSwgdGhlIHRvbmUgZHVyYXRpb24mbmJzcDtyZXBlYXQgDQpjb3VudCB3aWxsIG5vdCBi ZSBmdWxseSBleGVyY2lzZWQgYW5kIHRoZSBkZXNpcmVkIHRvbmUgZHVyYXRpb24gd2lsbCBiZSAN CnRydW5jYXRlZCBwZXIgdGhlIFRPIHNldHRpbmcuJm5ic3A7SWYgdGhlIHJlcGVhdCBjb3VudCBy ZXN1bHRzIGluIGEgc2hvcnRlciB0b25lIA0KZHVyYXRpb24gdGhhbiB0aGUgc2lnbmFsIGR1cmF0 aW9uIHNwZWNpZmllZCBieSB0aGUgVE8sIHRoZSB0b25lIGR1cmF0aW9uIGRlZmluZWQgDQpieSB0 aGUgcmVwZWF0IGNvdW50IHRha2VzIHByZWNlZGVuY2Ugb3ZlciB0aGUgVE8gYW5kIHdpbGwgZW5k IHRoZSBzaWduYWwgZXZlbnQuIA0KSW4gdGhpcyBjYXNlLCB0aGUgVE8gcmVwcmVzZW50cyBhIHRp bWUgbm90Jm5ic3A7dG8gYmUgZXhjZWVkZWQgZm9yIHRoZSANCnNpZ25hbC48L0ZPTlQ+PC9GT05U PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxGT05UIGNvbG9yPSMwMDAwZmY+Jm5ic3A7 SXQgDQppcyByZWNvbW1lbmRlZCZuYnNwO3RvIGVuc3VyZSBwcm9wZXIgdGVsZXBob255IHNpZ25h bGxpbmcgdGhhdCB0aGUgVE8gZHVyYXRpb24gDQpzZXR0aW5nIHNob3VsZCBhbHdheXMgYmUgbG9u Z2VyIHRoYW4gdGhlIGRlc2lyZWQgcmVwZWF0IGNvdW50IHRpbWUgDQpkdXJhdGlvbjwvRk9OVD48 L0ZPTlQ+PEZPTlQgc2l6ZT0yPjxGT05UIGNvbG9yPSMwMDAwZmY+PFNQQU4gDQpjbGFzcz03ODEx MTA3MTYtMjkwOTIwMDQ+Jm5ic3A7cGx1cyB0aGUgZGVzaXJlZCBtYXhpbXVtIHN0ZWFkeSB0b25l IA0KcGVyaW9kLiZuYnNwOzwvU1BBTj4iJm5ic3A7IDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgOjo9eyANCnBrdGNTaWdEZXZUb25lRW50cnkgMTkgfSZuYnNwOyANCjwv Rk9OVD48L0ZPTlQ+PC9GT05UPiZuYnNwOzwvU1BBTj48L0RJVj48L1NQQU4+PC9ESVY+DQo8RElW PjxTUEFOIGNsYXNzPTY0ODQ3MjYxNi0yOTA5MjAwND4mbmJzcDs8L1NQQU4+PC9ESVY+DQo8QkxP Q0tRVU9URSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVY+PC9ESVY+ DQogIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFs aWduPWxlZnQ+PEZPTlQgDQogIGZhY2U9VGFob21hIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gQmVhY2hhbSANCiAgR29yZG9uLUNHQjAwNSA8QlI+PEI+ U2VudDo8L0I+IFR1ZXNkYXksIFNlcHRlbWJlciAyOCwgMjAwNCAzOjA1IA0KICBQTTxCUj48Qj5U bzo8L0I+ICdpcGNkbkBpZXRmLm9yZyc7ICdzYXRpc2gua3VtYXJAdGkuY29tJzxCUj48Qj5TdWJq ZWN0OjwvQj4gDQogIElFVEYgTkNTIFNpZyBNSUIgZHJhZnQgNiAtJmd0OyBJc3N1ZSBmb3IgDQog IHBrdGNTaWdEZXZUb25lV2hvbGVUb25lUmVwZWF0Q291bnQvcGt0Y1NpZ0RldlRvbmVTdGVhZHkg d2hlbiBkdXJhdGlvbiBpcyANCiAgc2hvcnRlciB0aGFuIFRPPEJSPjxCUj48L0ZPTlQ+PC9ESVY+ DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTM0NjU1MjIx OC0yODA5MjAwND5TYXRpc2gsPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9MzQ2NTUyMjE4LTI4MDkyMDA0PjwvU1BBTj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4g Y2xhc3M9MzQ2NTUyMjE4LTI4MDkyMDA0PlRoYW5rcyBmb3IgcmFpc2luZyANCiAgdGhpcyBpc3N1 ZS4mbmJzcDtUaGUgaW50ZW50IG9mIHRoZSZuYnNwO3BrdGNTaWdEZXZUb25lV2hvbGVUb25lUmVw ZWF0Q291bnQgYW5kIA0KICBwa3RjU2lnRGV2VG9uZVN0ZWFkeSB3YXMgdG8gc3VwcG9ydCB0ZWxj byBpbmR1c3RyeSBzdGFuZGFyZHMuIElmIGEgdG9uZSANCiAgZGVmaW5pdGlvbiB1c2luZyByZXBl YXQgY291bnQgb2JqZWN0cyZuYnNwO3Jlc3VsdHMgaW4gYSB0b25lIHNlcXVlbmNlIHRoYXQgaXMg DQogIHNob3J0ZXIgdGhhbiZuYnNwO3RoZSBUTyB0aW1lLCB0aGUgcmVwZWF0IGNvdW50IHRha2Vz IHNpZ25pZmljYW5jZS4gSSBjaGVja2VkIA0KICB0aGUgTkNTIHNwZWMgb24gdGhpcyBpc3N1ZSBh bmQmbmJzcDtJIGRvbid0IHNlZSBhIGNsZWFyIGluZGljYXRpb24gb2YgZXhwZWN0ZWQgDQogIGJl aGF2aW91ciB3aGVuIGEgdG9uZSBkdXJhdGlvbiBpcyBzaG9ydGVyIHRoYW4gYW4gYXNzb2NpYXRl ZCANCiAgVE8uPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj48U1BBTiANCiAgY2xhc3M9MzQ2NTUyMjE4LTI4MDkyMDA0PjwvU1BBTj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9MzQ2 NTUyMjE4LTI4MDkyMDA0PkRvIHlvdSBoYXZlIHRleHQgDQogIHlvdSB3b3VsZCBsaWtlIHRvJm5i c3A7cHJvcG9zZSBhcyBhIHNvbHV0aW9uIGZvciB0aGUgZGVzY3JpcHRpb24gb2YgdGhlc2UgDQog IG9iamVjdHM/PC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj48U1BBTiANCiAgY2xhc3M9MzQ2NTUyMjE4LTI4MDkyMDA0PjwvU1BBTj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIGNsYXNz PTM0NjU1MjIxOC0yODA5MjAwND5Db21tZW50cz88L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0zNDY1NTIyMTgtMjgwOTIw MDQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj48U1BBTiANCiAgY2xhc3M9MzQ2NTUyMjE4LTI4MDkyMDA0PkdvcmRvbjwvU1BBTj48L0ZP TlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIGNsYXNz PTM0NjU1MjIxOC0yODA5MjAwND48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxG T05UIHNpemU9KzA+PFNQQU4gY2xhc3M9MzQ2NTUyMjE4LTI4MDkyMDA0PjxGT05UIHNpemU9Mj48 Rk9OVCANCiAgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmPiZndDtUaGUmbmJzcDtNSWJzIHNwZWNp ZnkgdGhlIGNhc2Ugd2hlcmUgbG9uZ2VyIA0KICBkdXJhdGlvbiBpcyBzZXQuJm5ic3A7SDwvRk9O VD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmY+PFNQQU4gDQogIGNsYXNzPTAxNzIzMzAx OS0yNzA5MjAwND5vd2V2ZXImbmJzcDt0aGV5IGRvIG5vdCZuYnNwO3NwZWNpZmljYWxseSBzYXkg d2hhdCB0byANCiAgZG8gaW4gdGhlIGNhc2UgJmd0O3doZXJlIHNldHRpbmcgdGhlIHBrdGNTaWdE ZXZUb25lV2hvbGVUb25lUmVwZWF0Q291bnQgDQogIHJlc3VsdHMgaW4gYSZuYnNwO3RvbmUmbmJz cDtkdXJhdGlvbiB3aGljaCBpcyA8U1RST05HPnNob3J0ZXI8L1NUUk9ORz4gdGhhbiANCiAgdGhl Jm5ic3A7dG9uZSAmZ3Q7ZHVyYXRpb24gd2hpY2ggaXMgc3BlY2lmaWVkJm5ic3A7dGhyb3VnaCB0 aGUmbmJzcDt0aW1lb3V0IA0KICAoVE8pPz8/Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48L0ZP TlQ+PC9GT05UPg0KICA8RElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBm ZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTAxNzIzMzAxOS0yNzA5MjAwND48L1NQQU4+PC9GT05U PiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTAxNzIzMzAxOS0yNzA5MjAwND48Rk9O VCBmYWNlPUFyaWFsPjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgDQogIHNpemU9Mj48U1BBTiBj bGFzcz0zNDY1NTIyMTgtMjgwOTIwMDQ+Jmd0OzwvU1BBTj5XaGF0IGlzIHRoZSBleHBlY3RlZCBk dXJhdGlvbiANCiAgYmVoYXZpb3IgaW4gdGhpcyBjYXNlPz8mbmJzcDtEb2VzIHRoZSBNVEEgaGFz IHRvIG9ic2VydmUgdGhlIHNwZWNpZmllZCBudW1iZXIgDQogIG9mIHJlcGVhdCZuYnNwO2NvdW50 cz8/IG9yIGRvZXMgaXQgc3RpY2sgdG8gdGhlIHZhbHVlIGluJm5ic3A7dGltZW91dChUTykgDQog IE1JQj8mbmJzcDsgUGxlYXNlIHRocm93IHNvbWUgbGlnaHQgb24gZXhwZWN0ZWQgDQogIGJlaGF2 aW9yLjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0wMTcyMzMwMTktMjcw OTIwMDQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj48L0RJVj48L1NQQU4+PC9GT05UPjwvRElW Pg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTM0NjU1MjIxOC0y ODA5MjAwND4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIA0KICBzaXplPTI+cGt0Y1NpZ0RldlRv bmVXaG9sZVRvbmVSZXBlYXRDb3VudCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAg T0JKRUNULVRZUEUmbmJzcDsgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCiAgU1lOVEFYJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVuc2lnbmVk MzIgKDAuLjUwMDApJm5ic3A7IA0KICA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE1BWC1BQ0NFU1MmbmJzcDsmbmJzcDsgDQogIHJlYWQtd3JpdGUmbmJzcDsgPEJSPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgU1RBVFVTJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGN1cnJlbnQmbmJzcDsgDQogIDxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgREVTQ1JJUFRJT04mbmJzcDsgDQogIDxCUj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg IlRoaXMgaXMgdGhlIA0KICByZXBlYXQgY291bnQsIHdoaWNoIHNpZ25pZmllcyBob3cgbWFueSB0 aW1lcyANCiAgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byANCiAgcmVwZWF0IHRoZSBlbnRpcmUgb24tb2ZmIHNl cXVlbmNlLiA8Rk9OVCBjb2xvcj0jZmYwMDAwPlNldHRpbmcgdGhpcyBvYmplY3QgDQogIDxCUj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgbWF5IA0KICByZXN1bHQgaW4gYSB0b25lIGR1cmF0aW9uIDxVPmxvbmdlcjwvVT4g dGhhbiB0aGUgb3ZlcmFsbCANCiAgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaWduYWwgDQogIGR1cmF0aW9uIHNw ZWNpZmllZCBieSB0aGUgdGltZSBvdXQgKFRPKSBvYmplY3QgZm9yIGEgDQogIDxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQogIHBhcnRpY3VsYXIgc2lnbmFsLiBJbiB0aGlzIGNhc2UsIHRoZSB0b25lIGR1cmF0aW9u IGRlZmluZWQgDQogIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnkgdGhlIA0KICBUTyBvYmplY3QgZm9yIGEgcGFy dGljdWxhciBzaWduYWwgYWx3YXlzIHJlcHJlc2VudHMgDQogIDxCUj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIA0K ICBvdmVyYWxsIHNpZ25hbCBkdXJhdGlvbiBmb3IgYSB0b25lLjwvRk9OVD4iIA0KICA8QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDo6PXsgcGt0Y1NpZ0RldlRvbmVFbnRy eSAxOCANCiAgfSZuYnNwOyZuYnNwOzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8QlI+PEJS PjxCUj4mbmJzcDsmbmJzcDsgDQogIHBrdGNTaWdEZXZUb25lU3RlYWR5Jm5ic3A7Jm5ic3A7Jm5i c3A7IE9CSkVDVC1UWVBFJm5ic3A7IA0KICA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KICBTWU5UQVgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg VHJ1dGhWYWx1ZSZuYnNwOyANCiAgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBNQVgtQUNDRVNTJm5ic3A7Jm5ic3A7IA0KICByZWFkLXdyaXRlJm5ic3A7IDxCUj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIFNUQVRVUyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjdXJyZW50Jm5ic3A7IA0KICA8QlI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERFU0NSSVBUSU9OJm5ic3A7IA0KICA8QlI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJU aGlzIGlzIHRoZSANCiAgc3RlYWR5IHRvbmUuIERldmljZSBtdXN0IHBsYXkgb3V0IHRoZSBvbi1v ZmYgDQogIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIHNlcXVlbmNlIGZvciBwa3RjU2lnRGV2VG9uZVdob2xl UmVwZWF0Q291bnQgdGltZXMgYW5kIA0KICA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZW4gDQogIGFwcGx5IHRo ZSBsYXN0IHRvbmUgZm9yZXZlci4gPEZPTlQgY29sb3I9I2ZmMDAwMD5TZXR0aW5nIHRoaXMgb2Jq ZWN0IA0KICA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1heSANCiAgcmVzdWx0IGluIGEgdG9uZSBkdXJhdGlvbiA8 VT5sb25nZXI8L1U+IHRoYW4gdGhlIG92ZXJhbGwgDQogIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2lnbmFsIA0K ICBkdXJhdGlvbiBzcGVjaWZpZWQgYnkgdGhlIHRpbWUgb3V0IChUTykgb2JqZWN0IGZvciBhIA0K ICA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KICBwYXJ0aWN1bGFyIHNpZ25hbC4gSW4gdGhpcyBjYXNlLCB0aGUg dG9uZSBkdXJhdGlvbiBkZWZpbmVkIA0KICA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJ5IHRoZSANCiAgVE8gb2Jq ZWN0IGZvciBhIHBhcnRpY3VsYXIgc2lnbmFsIGFsd2F5cyByZXByZXNlbnRzIA0KICA8QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHRoZSANCiAgb3ZlcmFsbCBzaWduYWwgZHVyYXRpb24gZm9yIGEgdG9uZTwvRk9OVD4u IiZuYnNwOyANCiAgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6Oj17 IHBrdGNTaWdEZXZUb25lRW50cnkgMTkgfSZuYnNwOyANCiAgPEJSPjxGT05UIGZhY2U9QXJpYWwg c2l6ZT0yPg0KICA8RElWPiZuYnNwOzwvRElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogIDxESVY+ PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9TUEFOPjwvRk9O VD48L0RJVj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C4A642.20224C2C-- --===============0361240776== 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 --===============0361240776==-- From ipcdn-bounces@ietf.org Wed Sep 29 17:28:01 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 RAA18006 for ; Wed, 29 Sep 2004 17:28:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCm7b-0002d9-UO for ipcdn-archive@ietf.org; Wed, 29 Sep 2004 17:36:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCkTV-0004eG-4i; Wed, 29 Sep 2004 15:50:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCkGr-000793-9U for ipcdn@megatron.ietf.org; Wed, 29 Sep 2004 15:37:49 -0400 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 PAA02680 for ; Wed, 29 Sep 2004 15:37:46 -0400 (EDT) Received: from go4.ext.ti.com ([192.91.75.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCkOw-0005x9-KG for ipcdn@ietf.org; Wed, 29 Sep 2004 15:46:11 -0400 Received: from dlep90.itg.ti.com ([157.170.152.54]) by go4.ext.ti.com (8.12.11/8.12.11) with ESMTP id i8TJbH0s025248; Wed, 29 Sep 2004 14:37:17 -0500 (CDT) 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 i8TJbGXq005229; Wed, 29 Sep 2004 14:37:16 -0500 (CDT) Received: from dlee2k05.ent.ti.com ([157.170.152.114]) by dlee2k71.ent.ti.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 29 Sep 2004 14:37:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 29 Sep 2004 14:37:16 -0500 Message-ID: Thread-Topic: IETF NCS Sig MIB draft 6 -> Issue for pktcSigDevToneWholeToneRepeatCount/pktcSigDevToneSteady when duration is shorter than TO Thread-Index: AcSmQic1DmLK8l5YRUKJ6ueaR9dCSwAGV+bA From: "Kumar, Satish" To: "Beacham Gordon-CGB005" , X-OriginalArrivalTime: 29 Sep 2004 19:37:16.0739 (UTC) FILETIME=[BA150130:01C4A65B] X-Spam-Score: 1.1 (+) X-Scan-Signature: 1e47b908cbd1247f22e7953a41f1c4c6 Subject: [ipcdn] RE: IETF NCS Sig MIB draft 6 -> Issue for pktcSigDevToneWholeToneRepeatCount/pktcSigDevToneSteady when duration is shorter than TO 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="===============1801771642==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 8e140a89d08e89747ee196e282ac2228 This is a multi-part message in MIME format. --===============1801771642== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A65B.B9D45D56" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4A65B.B9D45D56 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Gordon, I agree with your proposed text. =20 Thanks, Satish =20 _____ =20 From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com]=20 Sent: Wednesday, September 29, 2004 4:34 PM To: 'ipcdn@ietf.org'; Kumar, Satish Subject: RE: IETF NCS Sig MIB draft 6 -> Issue for pktcSigDevToneWholeToneRepeatCount/pktcSigDevToneSteady when duration is shorter than TO Motorola's suggested text for the pktcSigDevToneWholeToneRepeatCount and pktcSigDevToneSteady objects to address this issue. =20 Gordon =20 pktcSigDevToneWholeToneRepeatCount OBJECT-TYPE =20 SYNTAX Unsigned32 (0..5000) =20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 "This is the repeat count, which signifies how many times=20 to repeat the entire on-off sequence. Setting this object=20 may result in a tone duration longer or shorter than the overall=20 signal duration specified by the time out (TO) object for a=20 particular signal. If the repeat count results in a longer tone duration than the signal duration specified by the TO, the tone duration defined=20 by the TO object for a particular signal always represents=20 the overall signal duration for a tone. In this case, the tone duration repeat count will not be fully exercised and the desired tone duration will be truncated per the TO setting. If the repeat count results in a shorter tone duration than the signal duration specified by the TO, the tone duration defined by the repeat count takes precedence over the TO and will end the signal event. In this case, the TO represents a time not to be exceeded for the signal. It is recommended to ensure proper telephony signalling that the TO duration setting should always be longer than the desired repeat count time duration."=20 ::=3D{ pktcSigDevToneEntry 18 }=20 =20 pktcSigDevToneSteady OBJECT-TYPE =20 SYNTAX TruthValue =20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 "This is the steady tone. Device must play out the on-off=20 sequence for pktcSigDevToneWholeRepeatCount times and=20 then apply the last tone forever. Setting this object=20 may result in a tone duration longer or shorter than the overall=20 signal duration specified by the time out (TO) object for a=20 particular signal. If the repeat count results in a longer tone duration than the signal duration specified by the TO, the tone duration defined=20 by the TO object for a particular signal always represents=20 the overall signal duration for a tone. In this case, the tone duration repeat count will not be fully exercised and the desired tone duration will be truncated per the TO setting. If the repeat count results in a shorter tone duration than the signal duration specified by the TO, the tone duration defined by the repeat count takes precedence over the TO and will end the signal event. In this case, the TO represents a time not to be exceeded for the signal. It is recommended to ensure proper telephony signalling that the TO duration setting should always be longer than the desired repeat count time duration plus the desired maximum steady tone period. " =20 ::=3D{ pktcSigDevToneEntry 19 } =20 =20 -----Original Message----- From: Beacham Gordon-CGB005=20 Sent: Tuesday, September 28, 2004 3:05 PM To: 'ipcdn@ietf.org'; 'satish.kumar@ti.com' Subject: IETF NCS Sig MIB draft 6 -> Issue for pktcSigDevToneWholeToneRepeatCount/pktcSigDevToneSteady when duration is shorter than TO =09 =09 Satish, =20 Thanks for raising this issue. The intent of the pktcSigDevToneWholeToneRepeatCount and pktcSigDevToneSteady was to support telco industry standards. If a tone definition using repeat count objects results in a tone sequence that is shorter than the TO time, the repeat count takes significance. I checked the NCS spec on this issue and I don't see a clear indication of expected behaviour when a tone duration is shorter than an associated TO. =20 Do you have text you would like to propose as a solution for the description of these objects? =20 Comments? =20 Gordon =20 >The MIbs specify the case where longer duration is set. However they do not specifically say what to do in the case >where setting the pktcSigDevToneWholeToneRepeatCount results in a tone duration which is shorter than the tone >duration which is specified through the timeout (TO)??? =20 =20 >What is the expected duration behavior in this case?? Does the MTA has to observe the specified number of repeat counts?? or does it stick to the value in timeout(TO) MIB? Please throw some light on expected behavior. =20 =09 pktcSigDevToneWholeToneRepeatCount OBJECT-TYPE =20 SYNTAX Unsigned32 (0..5000) =20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 "This is the repeat count, which signifies how many times=20 to repeat the entire on-off sequence. Setting this object=20 may result in a tone duration longer than the overall=20 signal duration specified by the time out (TO) object for a=20 particular signal. In this case, the tone duration defined=20 by the TO object for a particular signal always represents=20 the overall signal duration for a tone."=20 ::=3D{ pktcSigDevToneEntry 18 } =20 =20 =09 =09 pktcSigDevToneSteady OBJECT-TYPE =20 SYNTAX TruthValue =20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 "This is the steady tone. Device must play out the on-off=20 sequence for pktcSigDevToneWholeRepeatCount times and=20 then apply the last tone forever. Setting this object=20 may result in a tone duration longer than the overall=20 signal duration specified by the time out (TO) object for a=20 particular signal. In this case, the tone duration defined=20 by the TO object for a particular signal always represents=20 the overall signal duration for a tone." =20 ::=3D{ pktcSigDevToneEntry 19 } =20 =09 =20 =20 ------_=_NextPart_001_01C4A65B.B9D45D56 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Hi Gordon,
 I agree with your proposed = text.
 
Thanks, Satish
 

From: Beacham Gordon-CGB005=20 [mailto:Gordon.Beacham@motorola.com]
Sent: Wednesday, = September 29,=20 2004 4:34 PM
To: 'ipcdn@ietf.org'; Kumar, = Satish
Subject:=20 RE: IETF NCS Sig MIB draft 6 -> Issue for=20 pktcSigDevToneWholeToneRepeatCount/pktcSigDevToneSteady when duration is = shorter=20 than TO

Motorola's suggested text for the pktcSigDevToneWholeToneRepeatCount and=20 pktcSigDevToneSteady objects = to address=20 this issue.
 
Gordon
 
pktcSigDevToneWholeToneRepeatCount    = ; =20 OBJECT-TYPE 
      =20 SYNTAX       Unsigned32 (0..5000) =20
       MAX-ACCESS   = read-write =20
      =20 STATUS       current =20
       DESCRIPTION =20
           "This = is the=20 repeat count, which signifies how many times=20
            = to repeat=20 the entire on-off sequence. Setting this object=20
            = may=20 result in a tone duration longer or shorter than the overall=20
            = signal=20 duration specified by the time out (TO) object for a=20
           =20 particular signal. If the repeat count results in a longer tone duration = than=20 the signal duration specified by the TO, the tone duration defined=20
            = by the TO=20 object for a particular signal always represents=20
            = the=20 overall signal duration for a tone.  In=20 this case, the tone duration repeat count will not be fully = exercised and=20 the desired tone duration will be truncated per the TO=20 setting.  If the repeat count results in a shorter tone = duration than the signal duration specified by the TO, the tone duration = defined=20 by the repeat count takes precedence over the TO and will end the signal = event.=20 In this case, the TO represents a time not to be exceeded for the=20 signal.   It is recommended to ensure = proper=20 telephony signalling that the TO duration setting should always be = longer than=20 the desired repeat count time duration."=20
       ::=3D{ pktcSigDevToneEntry 18=20 }=20
 
pktcSigDevToneSteady    OBJECT-TYPE =20
      =20 SYNTAX       TruthValue =20
       MAX-ACCESS   = read-write =20
      =20 STATUS       current =20
       DESCRIPTION =20
           "This = is the=20 steady tone. Device must play out the on-off=20
            = sequence=20 for pktcSigDevToneWholeRepeatCount times and=20
            = then=20 apply the last tone forever. Setting this object=20
            = may=20 result in a tone duration longer or shorter than the overall=20
            = signal=20 duration specified by the time out (TO) object for a=20
           =20 particular signal. If the repeat count results in a longer tone duration = than=20 the signal duration specified by the TO, the tone duration defined=20
            = by the TO=20 object for a particular signal always represents=20
            = the=20 overall signal duration for a tone. In this case, the tone = duration repeat=20 count will not be fully exercised and the desired tone duration will be=20 truncated per the TO setting. If the repeat count results in a = shorter tone=20 duration than the signal duration specified by the TO, the tone duration = defined=20 by the repeat count takes precedence over the TO and will end the signal = event.=20 In this case, the TO represents a time not to be exceeded for the=20 signal. It=20 is recommended to ensure proper telephony signalling that the TO = duration=20 setting should always be longer than the desired repeat count time=20 duration plus the desired maximum steady tone=20 period. " 
       = ::=3D{=20 pktcSigDevToneEntry 19 } =20  
 
-----Original Message-----
From: = Beacham=20 Gordon-CGB005
Sent: Tuesday, September 28, 2004 3:05=20 PM
To: 'ipcdn@ietf.org'; = 'satish.kumar@ti.com'
Subject:=20 IETF NCS Sig MIB draft 6 -> Issue for=20 pktcSigDevToneWholeToneRepeatCount/pktcSigDevToneSteady when duration = is=20 shorter than TO

Satish,
 
Thanks for raising=20 this issue. The intent of = the pktcSigDevToneWholeToneRepeatCount and=20 pktcSigDevToneSteady was to support telco industry standards. If a = tone=20 definition using repeat count objects results in a tone sequence = that is=20 shorter than the TO time, the repeat count takes significance. I = checked=20 the NCS spec on this issue and I don't see a clear indication of = expected=20 behaviour when a tone duration is shorter than an associated=20 TO.
 
Do = you have text=20 you would like to propose as a solution for the description of = these=20 objects?
 
Comments?
 
Gordon
 
>The MIbs specify the case where = longer=20 duration is set. However they do not specifically = say what to=20 do in the case >where setting the = pktcSigDevToneWholeToneRepeatCount=20 results in a tone duration which is shorter = than=20 the tone >duration which is specified through = the timeout=20 (TO)???   
 
>What is the = expected duration=20 behavior in this case?? Does the MTA has to observe the specified = number=20 of repeat counts?? or does it stick to the value = in timeout(TO)=20 MIB?  Please throw some light on expected=20 behavior.
 
=
pktcSigDevToneWholeToneRepeatCount     = =20 OBJECT-TYPE 
      =20 SYNTAX       Unsigned32 (0..5000) =20
       MAX-ACCESS  =20 read-write 
      =20 STATUS       current =20
       DESCRIPTION =20
           "This = is the=20 repeat count, which signifies how many times=20
            = to=20 repeat the entire on-off sequence. Setting this = object=20
            = may=20 result in a tone duration longer than the overall=20
            = signal=20 duration specified by the time out (TO) object for a=20
            = particular signal. In this case, the tone duration defined=20
            = by the=20 TO object for a particular signal always represents=20
            = the=20 overall signal duration for a tone."=20
       ::=3D{ pktcSigDevToneEntry 18 = }  
    


  =20 pktcSigDevToneSteady    OBJECT-TYPE =20
      =20 SYNTAX       TruthValue =20
       MAX-ACCESS  =20 read-write 
      =20 STATUS       current =20
       DESCRIPTION =20
           "This = is the=20 steady tone. Device must play out the on-off=20
            = sequence for pktcSigDevToneWholeRepeatCount times and=20
            = then=20 apply the last tone forever. Setting this object =
            = may=20 result in a tone duration longer than the overall=20
            = signal=20 duration specified by the time out (TO) object for a=20
            = particular signal. In this case, the tone duration defined=20
            = by the=20 TO object for a particular signal always represents=20
            = the=20 overall signal duration for a tone." =20
       ::=3D{ pktcSigDevToneEntry 19 = } =20
 
 
------_=_NextPart_001_01C4A65B.B9D45D56-- --===============1801771642== 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 --===============1801771642==-- From ipcdn-bounces@ietf.org Thu Sep 30 03:40:18 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 DAA23313 for ; Thu, 30 Sep 2004 03:40:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCvgG-0007xj-UH for ipcdn-archive@ietf.org; Thu, 30 Sep 2004 03:48:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCvVw-0001AF-Dx; Thu, 30 Sep 2004 03:38:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCvMF-0007Q7-RZ for ipcdn@megatron.ietf.org; Thu, 30 Sep 2004 03:28:07 -0400 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 DAA22241 for ; Thu, 30 Sep 2004 03:28:05 -0400 (EDT) Received: from europa.telenet-ops.be ([195.130.132.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCvUP-0007hY-Ok for ipcdn@ietf.org; Thu, 30 Sep 2004 03:36:36 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by europa.telenet-ops.be (Postfix) with SMTP id 8FC8B37F23 for ; Thu, 30 Sep 2004 09:27:47 +0200 (MEST) Received: from tcomlabs.com (D5E00496.kabel.telenet.be [213.224.4.150]) by europa.telenet-ops.be (Postfix) with ESMTP id 6656C37EC0 for ; Thu, 30 Sep 2004 09:27:47 +0200 (MEST) Received: (qmail 30756 invoked from network); 30 Sep 2004 09:27:47 +0200 Received: from localhost (HELO gateway) (127.0.0.1) by localhost with SMTP; 30 Sep 2004 09:27:47 +0200 Received: from ([10.5.5.72]) by gateway.tcomlabs.com (MailMonitor for SMTP v1.2.2 ) ; Thu, 30 Sep 2004 09:27:47 +0200 (CEST) From: "David De Reu" To: "IPCDN Mailing List" Date: Thu, 30 Sep 2004 09:27:46 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] IETF NCS Sig MIB draft 6 -> Issue with E package requirements 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: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Dear all, In the DESCRIPTION of a number of MIB objects, the term "international systems" has been replaced by "E package" in draft 6. This introduces the side-effect that a number of MIB objects that have nothing to do with E package support, now only have to be supported when the E package is supported. The following MIB objects are the ones I believe have nothing = to do with the E package, since the caller ID and VMWI transmissions are triggered using the L package: pktcSigDevCIDMode pktcSigDevCIDFskAfterRing pktcSigDevCIDFskAfterDTAS pktcSigDevCIDFskAfterRPAS pktcSigDevCIDRingAfterFSK pktcSigDevCIDDTASAfterLR pktcSigDevVmwiFskAfterDTAS pktcSigDevVmwiFskAfterRPAS pktcSigDevVmwiDTASAfterLR An MTA for the international market that does however not support the E package, will want to support the above MIB objects. Maybe we can revert to the description of "international systems"? Thanks, Regards, David _____________________________________________________ David De Reu tComLabs Stapelplein 70/004 =96 9000 Ghent =96 Belgium Tel: +32 9 269 22 91 =96 Fax: +32 9 329 31 74 www.tComLabs.com _____________________________________________________ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn