From exim@www1.ietf.org Tue Nov 4 10:59:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20128 for ; Tue, 4 Nov 2003 10:59:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3a9-0005Mq-T9 for ipcdn-archive@odin.ietf.org; Tue, 04 Nov 2003 10:59:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4Fx1fP020628 for ipcdn-archive@odin.ietf.org; Tue, 4 Nov 2003 10:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3a8-0005MX-LL; Tue, 04 Nov 2003 10:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3Zn-0005KJ-BP for ipcdn@optimus.ietf.org; Tue, 04 Nov 2003 10:58:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20095 for ; Tue, 4 Nov 2003 10:58:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH3Zk-0007Xs-00 for ipcdn@ietf.org; Tue, 04 Nov 2003 10:58:36 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AH3Zj-0007Xc-00 for ipcdn@ietf.org; Tue, 04 Nov 2003 10:58:35 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hA4Fw1oK020914; Tue, 4 Nov 2003 08:58:02 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A2EC.6CA53B99" Date: Tue, 4 Nov 2003 08:58:01 -0700 Message-ID: Thread-Topic: RFI v2 MIB Draft 08 Thread-Index: AcNgJaYn06TBEeT1TRC5N0Q/BVl7hgT3JTZQBRgJoxAABa9pIAGKF0mAACappiAE6z+K0A== From: "Eduardo Cardona" To: "Ipcdn (E-mail)" Cc: "Richard Woundy" , "Jean-Francois Mule" , "DOCSIS OSS Majordomo List" X-Approved: ondar Subject: [ipcdn] RFI v2 MIB Draft 08 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A2EC.6CA53B99 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi dear IPCD folks and OSSI reflector=20 =20 Few updates of the last posted Draft -08=20 =20 I am planning to do a quick update to the MIB draft after the IETF meeting to correct the below minor issues, Just a quick note, I will wait until the resolutions of the IETF IPCDN meeting to take actions on that. =20 =20 Jason Tessier, identified a description in the idAdminStatus in the draft that is not needed and does not reflect the needs for interface Stack based on =20 RFC 2863 to propagate ifAdminStatus top to bottom of the stack for and up/down transition. Only ifOperStatus is propagated because of ifAdminStatus changes or inherent interface changes. =20 Also for docsIfUpChannelUpdate related to the clone mechanism, all the related objects were updated to not being SCMA specific. One objects left out of the updates docsIfUpChannelUpdate. The proposed change will align that object description. =20 See at the end of the email the Jasson arguments for the ifAdminStatus change =20 Below are the proposed changes, let us know any changes. =20 Thanks =20 Eduardo =20 =20 =20 update to RFI Mib v2 with two changes: =20 1- ifAdminStatus requirements for UpChannels should read. 3.2.5.2. ifEntry for Upstream interfaces=20 ifAdminStatus The administrative status of this interface.=20 =20 =20 2- Re-define the requirement for docsIfUpChannelUpdate as below =20 - All the associated objects for the Clone Mechanism are no longer=20 referencing exclusively to SCDMA. The intention now is normalize this=20 requirements for all type of profiles. =20 - change GEN-ERROR for genError and COMMIT_FAILED_ERROR for=20 commitFailed =20 =20 docsIfUpChannelUpdate OBJECT-TYPE=20 SYNTAX TruthValue=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "Used to perform the transfer of adjusted SCDMA parameters=20 from the temporary upstream row to the active upstream row=20 indicated by the docsIfUpChannelCloneFrom object. The=20 transfer is initiated through an SNMP SET of TRUE to this=20 object. The SNMP SET will fail with a GEN_ERROR (snmpv1)=20 or COMMIT_FAILED_ERROR (snmpv2c/v3) if the adjusted=20 SCDMA parameter values are not compatible with each other.=20 Although this object was created to facilitate SCDMA=20 parameter adjustment, it may also be used at the vendor's=20 discretion for non-SCDMA parameter adjustment.=20 An SNMP GET of this object always returns FALSE."=20 ::=3D { docsIfUpstreamChannelEntry 17 }=20 to: =20 docsIfUpChannelUpdate OBJECT-TYPE=20 SYNTAX TruthValue=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "Used to perform the transfer of adjusted parameters=20 from the temporary upstream row to the physical upstream row=20 indicated by the docsIfUpChannelCloneFrom object. The=20 transfer is initiated through an SNMP SET to 'true' of this object. The SNMP SET failure returns an error genError (snmpv1)=20 or commitFailed (snmpv2c/v3) if the adjusted parameter values are=20 not compatible with each other.=20 Reading this object always return 'false'."=20 ::=3D { docsIfUpstreamChannelEntry 17 }=20 =20 =20 --------------------------------=20 =20 IfAdminStatus Jasson email =20 =20 -----Original Message----- From: Jason.Tessier@arrisi.com [mailto:Jason.Tessier@arrisi.com]=20 Sent: Wednesday, October 22, 2003 10:20 AM To: DOCSIS OSS Majordomo List Subject: ifAdminStatus sets to docsCableUpstream (129) Hello,=20 In the DOCS-IF-MIB there's a requirement that ifAdminStatus sets to a docsCableUpstream interface also be applied to the docsCableUpstreamChannel interfaces under it.=20 3.2.5.2.1. ifEntry for Upstream interfaces in Cable Modem Termination=20 Systems=20 =20 ifTable Comments=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 ifType The IANA value of docsCableUpstream (129).=20 =20 =20 ifAdminStatus The administrative status of this interface.=20 This reflect the total status of all the channels =20 under this interface. So if at least one channel=20 has a physical connection this interface has=20 connection. Any SNMP SET on this interface will cause a SET to all the channels under this=20 interface.=20 So in the case where there are multiple logical channels under one upstream interface, if you want to enable/disable the docsCableUpstream interface all of the logical channels associated with it are also set to up/down.=20 I think that this makes it difficult for the operator to set the ifAdminStatus of the docsCableUpstream interface without affecting several logical channels, some of which may not even have been enabled in the first place. If an operator sets the ifAdminStatus of the docsCableUpstream to down, the set will already be reflected in the ifOperStatus of the docsCableUpstreamChannels under it. The OperStatus of the docsCableUpstreamChannels will reflect their own state, taking into account the upper layer and modulation profiles, etc. I don't see a need for this requirement.=20 An example:=20 interface ifAdminStatus=20 docsCableUpstream US 1 down=20 docsCableUpstreamChannel 1 up =20 docsCableUpstreamChannel 2 down (not in use)=20 docsCableUpstreamChannel 2 down (not in use)=20 docsCableUpstreamChannel 2 down (not in use)=20 Setting ifAdminStatus of US 1 to up results in this:=20 interface ifAdminStatus=20 docsCableUpstream US 1 up=20 docsCableUpstreamChannel 1 up =20 docsCableUpstreamChannel 2 up=20 docsCableUpstreamChannel 3 up=20 docsCableUpstreamChannel 4 up=20 The effect is that with one set 4 ifAdminStatus are affected, and 3 channels are put into use that may not be desired. I'm thinking of proposing an ECR to remove this requirement from the MIB.=20 Thanks,=20 Jason Tessier QA Engineer ARRIS Communications Ireland Ltd. Jason.Tessier@arrisi.com +353-21-7305826=20 ------_=_NextPart_001_01C3A2EC.6CA53B99 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi dear IPCD folks and OSSI reflector=20
 
Few updates of the last posted Draft -08=20
 
I=20 am planning to do a quick update to the MIB draft after the IETF = meeting to=20 correct the below minor issues, Just a quick note, I will wait until the = resolutions of the IETF IPCDN meeting to take actions on=20 that.
 
 
Jason Tessier, identified a description in = the=20 idAdminStatus in the draft that is not needed and does not reflect the = needs for=20 interface Stack based on 
RFC 2863 to propagate ifAdminStatus top to=20 bottom of the stack for and up/down transition. Only ifOperStatus = is=20 propagated because of ifAdminStatus changes or inherent interface=20 changes.
 
Also for docsIfUpChannelUpdate related to the = clone=20 mechanism, all the related objects were updated to not being SCMA = specific. One=20 objects left out of the updates docsIfUpChannelUpdate. The proposed = change=20 will align that object description.
 
See at the end of the email the Jasson = arguments for=20 the ifAdminStatus change
 
Below are the proposed changes, let us know = any=20 changes.
 
Thanks
 
Eduardo
 
 
 
update=20 to RFI Mib v2 with two changes:
 
1-  ifAdminStatus=20 requirements for UpChannels should = read.
     3.2.5.2.  ifEntry for Upstream=20 interfaces 
  ifAdminStatus     The=20 administrative status of this interface.
 
 
2- Re-define=20 the requirement for  docsIfUpChannelUpdate  as=20 below
 
- All the associated = objects for=20 the Clone Mechanism are no longer
referencing exclusively to=20 SCDMA. The intention now is normalize this
requirements for all type=20 of profiles.
 
- change GEN-ERROR for = genError and=20 COMMIT_FAILED_ERROR for
commitFailed
 
 
docsIfUpChannelUpdate OBJECT-TYPE=20
       =20 SYNTAX      TruthValue=20
        MAX-ACCESS  = read-create=20
       =20 STATUS      current=20
        DESCRIPTION=20
            = "Used to=20 perform the transfer of adjusted SCDMA parameters=20
           &nb= sp;=20 from the temporary upstream row to the active upstream row=20
           &nb= sp;=20 indicated by the docsIfUpChannelCloneFrom object. The=20
           &nb= sp;=20 transfer is initiated through an SNMP SET of TRUE to this=20
           &nb= sp;=20 object. The SNMP SET will fail with a GEN_ERROR (snmpv1)=20
           &nb= sp; or=20 COMMIT_FAILED_ERROR (snmpv2c/v3) if the adjusted=20
           &nb= sp;=20 SCDMA parameter values are not compatible with each other.=20
           &nb= sp;=20 Although this object was created to facilitate SCDMA=20
           &nb= sp;=20 parameter adjustment, it may also be used at the vendor's=20
           &nb= sp;=20 discretion for non-SCDMA parameter adjustment.=20
           &nb= sp; An=20 SNMP GET of this object always returns FALSE."=20
        ::=3D { = docsIfUpstreamChannelEntry=20 17 }
to:
 
docsIfUpChannelUpdate OBJECT-TYPE=20
       =20 SYNTAX      TruthValue=20
        MAX-ACCESS  = read-create=20
       =20 STATUS      current=20
        DESCRIPTION=20
            = "Used to=20 perform the transfer of adjusted parameters=20
           &nb= sp;=20 from the temporary upstream row to the physical upstream row=20
           &nb= sp;=20 indicated by the docsIfUpChannelCloneFrom object. The=20
           &nb= sp;=20 transfer is initiated through an SNMP SET to 'true' of this=20
           &nb= sp;=20 object. The SNMP SET failure returns an error genError = (snmpv1)=20
           &nb= sp; or=20 commitFailed (snmpv2c/v3) if the adjusted parameter values are=20
          &nbs= p; =20 not compatible with each=20 other. 
         &nb= sp;  =20 Reading this object always return 'false'."=20
        ::=3D { = docsIfUpstreamChannelEntry=20 17 }
 
 
--------------------------------=20
 
IfAdminStatus Jasson=20 email
 
 
-----Original Message-----
From: = Jason.Tessier@arrisi.com=20 [mailto:Jason.Tessier@arrisi.com]
Sent: Wednesday, October = 22, 2003=20 10:20 AM
To: DOCSIS OSS Majordomo List
Subject:=20 ifAdminStatus sets to docsCableUpstream = (129)


Hello,

In the=20 DOCS-IF-MIB there's a requirement that ifAdminStatus sets to a = docsCableUpstream=20 interface also be applied to the docsCableUpstreamChannel interfaces = under=20 it.

3.2.5.2.1.  ifEntry for = Upstream=20 interfaces in Cable Modem Termination
        =  =20       Systems
     
    =  =20  ifTable           Comments
  =  =20    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  =20  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =

<SNIP>
 =20    
       ifType       =  =20    The IANA value of docsCableUpstream (129).
  =  =20  
<SNIP>    
     =20  ifAdminStatus     The administrative status of this = interface.=20
                  =    =20    This reflect the total status of all the channels =  
 =20                     =  =20  under this interface. So if at least one channel
    =  =20                    has = a=20 physical connection this interface has
        =  =20                connection. Any = SNMP SET=20 on this interface will
            =  =20            cause a SET to all the channels = under=20 this
                  =  =20      interface.

So in = the case where=20 there are multiple logical channels under one upstream interface, if you = want to=20 enable/disable the docsCableUpstream interface all of the logical = channels=20 associated with it are also set to up/down.

I think that this makes it difficult for the operator to set = the=20 ifAdminStatus of the docsCableUpstream interface without affecting = several=20 logical channels, some of which may not even have been enabled in the = first=20 place.  If an operator sets the ifAdminStatus of the = docsCableUpstream to=20 down, the set will already be reflected in the ifOperStatus of the=20 docsCableUpstreamChannels under it. The OperStatus of the=20 docsCableUpstreamChannels will reflect their own state, taking into = account the=20 upper layer and modulation profiles, etc. I don't see a need for this=20 requirement.

An = example:=20

interface           =  =20            ifAdminStatus =
docsCableUpstream US 1        =20  down
docsCableUpstreamChannel 1 =  =20       up         =
docsCableUpstreamChannel 2        down = (not in=20 use)
docsCableUpstreamChannel 2 =    =20    down (not in use)
docsCableUpstreamChannel 2        down = (not in=20 use)

Setting = ifAdminStatus of=20 US 1 to up results in this:

interface =  =20                    =20  ifAdminStatus
docsCableUpstream = US 1=20          up
docsCableUpstreamChannel 1         up =  =20      
docsCableUpstreamChannel 2=20        up
docsCableUpstreamChannel 3       =  up=20
docsCableUpstreamChannel 4      =20  up

The effect = is that=20 with one set 4 ifAdminStatus are affected, and 3 channels are put into = use that=20 may not be desired. I'm thinking of proposing an ECR to remove this = requirement=20 from the MIB.

Thanks,=20


Jason Tessier
QA = Engineer
ARRIS=20 Communications Ireland=20 Ltd.
Jason.Tessier@arrisi.com
+353-21-7305826=20
=00 ------_=_NextPart_001_01C3A2EC.6CA53B99-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Nov 7 12:42:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26272 for ; Fri, 7 Nov 2003 12:42:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAcU-0003Db-Bw for ipcdn-archive@odin.ietf.org; Fri, 07 Nov 2003 12:42:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Hg2kb012368 for ipcdn-archive@odin.ietf.org; Fri, 7 Nov 2003 12:42:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAcS-0003DJ-Vk; Fri, 07 Nov 2003 12:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAbp-0003CU-63 for ipcdn@optimus.ietf.org; Fri, 07 Nov 2003 12:41:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26237 for ; Fri, 7 Nov 2003 12:41:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIAbn-0000GE-00 for ipcdn@ietf.org; Fri, 07 Nov 2003 12:41:19 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AIAbm-0000Fp-00 for ipcdn@ietf.org; Fri, 07 Nov 2003 12:41:18 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hA7HeioK025132; Fri, 7 Nov 2003 10:40:45 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Nov 2003 10:40:44 -0700 Message-ID: Thread-Topic: Agenda for the IETF#58 IPCDN Nov 11'03 meeting in Minneapolis Thread-Index: AcKF817qwqx0WLMUQ8ahOf2SFpiPNi0vOgXgGqiHBGA= From: "Jean-Francois Mule" To: "IPCDN (E-mail)" Cc: "Richard Woundy" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Agenda for the IETF#58 IPCDN Nov 11'03 meeting in Minneapolis Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Rich & I discussed the agenda items, sorry for the late notice, comments welcome. Here's the proposed agenda for the IPCDN WG meeting in Minneapolis.=20 =20 IP over Cable Data Network WG (ipcdn) =20 TUESDAY, November 11, 2003, from 1300 to 1400 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 CHAIRS: Richard Woundy Jean-Francois Mule =20 AGENDA: =20 I. Agenda Bashing =20 II. Administration Discuss new WG milestones Call for new editor for Event Notification MIB draft-ietf-ipcdn-docsisevent-mib-03.txt has expired and calls for action by WG chair have not helped. =20 III. DOCSIS Submissions We'll discuss recent updates, open issues and next=20 steps for the following drafts: o RF MIB v2 draft 08 draft did not make the cut-off deadline review of comments addressed in upcoming 08 o DOCSIS BPI+ MIB draft 12 draft-ietf-ipcdn-bpiplus-mib-12.txt o Subscriber Mgmt MIB draft 13 draft-ietf-ipcdn-subscriber-mib-13.txt o DOCSIS Cable Device MIB version 2 draft-ietf-ipcdn-device-mibv2-06.txt o DOCSIS QoS MIB draft-ietf-ipcdn-qos-mib-09.txt IV. IPCablecom/PacketCable Submissions We'll discuss recent updates, open issues and next=20 steps for the following drafts: o MTA MIB draft-ietf-ipcdn-pktc-mtamib-02.txt o Signaling MIB draft-ietf-ipcdn-pktc-signaling-02.txt=20 o Management Event MIB for PacketCable/IPCablecom=20 draft-ietf-ipcdn-pktc-eventmess-03.txt rev 3 was submitted but not posted. V. CableHome Submissions o CableHome Remote Diagnostic Tools MIB draft-ietf-ipcdn-cable-gateway-tools-mib-00. Discuss progress on Ping capability & Randy's comments VI. Next steps -- Richard Woundy and Jean-Francois Mule, IPCDN co-chairs _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Nov 7 13:12:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27358 for ; Fri, 7 Nov 2003 13:12:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIB5W-0004lZ-Gb for ipcdn-archive@odin.ietf.org; Fri, 07 Nov 2003 13:12:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7IC2Ap018303 for ipcdn-archive@odin.ietf.org; Fri, 7 Nov 2003 13:12:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIB5V-0004ku-Hu; Fri, 07 Nov 2003 13:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIB4s-0004jN-Qz for ipcdn@optimus.ietf.org; Fri, 07 Nov 2003 13:11:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27315 for ; Fri, 7 Nov 2003 13:11:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIB4q-0000e2-00 for ipcdn@ietf.org; Fri, 07 Nov 2003 13:11:20 -0500 Received: from coral.tci.com ([198.178.8.81] helo=snowmass.tci.com) by ietf-mx with esmtp (Exim 4.12) id 1AIB4q-0000dn-00 for ipcdn@ietf.org; Fri, 07 Nov 2003 13:11:20 -0500 Received: from entexchimc01.broadband.att.com (entexchimc01.broadband.att.com [147.191.89.203]) by snowmass.tci.com (8.12.9/8.12.9) with ESMTP id hA7IAhPb016593; Fri, 7 Nov 2003 11:10:44 -0700 (MST) Received: by entexchimc01.broadband.att.com with Internet Mail Service (5.5.2657.72) id ; Fri, 7 Nov 2003 11:10:42 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC0B6520F0@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "IPCDN (E-mail)" Cc: "'Jean-Francois Mule'" , "Woundy, Richard" Date: Fri, 7 Nov 2003 11:10:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Subject: [ipcdn] RE: Agenda for the IETF#58 IPCDN Nov 11'03 meeting in Minneapolis Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Just a couple of updates: > o RF MIB v2 draft 08 > draft did not make the cut-off deadline > review of comments addressed in upcoming 08 JF is correct that the cut-off deadline was missed... but somehow the draft was posted anyway at . > o Management Event MIB for PacketCable/IPCablecom > draft-ietf-ipcdn-pktc-eventmess-03.txt > rev 3 was submitted but not posted. Due to a submission error, rev 3 has been (mis-)posted as . So all documents that we want to discuss, with the obvious exception of the expired DOCSIS Event Notification MIB, are available from the IETF and IPCDN websites. -- Rich -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] Sent: Friday, November 07, 2003 12:41 PM To: IPCDN (E-mail) Cc: Woundy, Richard Subject: Agenda for the IETF#58 IPCDN Nov 11'03 meeting in Minneapolis Rich & I discussed the agenda items, sorry for the late notice, comments welcome. Here's the proposed agenda for the IPCDN WG meeting in Minneapolis. IP over Cable Data Network WG (ipcdn) TUESDAY, November 11, 2003, from 1300 to 1400 ============================================= CHAIRS: Richard Woundy Jean-Francois Mule AGENDA: I. Agenda Bashing II. Administration Discuss new WG milestones Call for new editor for Event Notification MIB draft-ietf-ipcdn-docsisevent-mib-03.txt has expired and calls for action by WG chair have not helped. III. DOCSIS Submissions We'll discuss recent updates, open issues and next steps for the following drafts: o RF MIB v2 draft 08 draft did not make the cut-off deadline review of comments addressed in upcoming 08 o DOCSIS BPI+ MIB draft 12 draft-ietf-ipcdn-bpiplus-mib-12.txt o Subscriber Mgmt MIB draft 13 draft-ietf-ipcdn-subscriber-mib-13.txt o DOCSIS Cable Device MIB version 2 draft-ietf-ipcdn-device-mibv2-06.txt o DOCSIS QoS MIB draft-ietf-ipcdn-qos-mib-09.txt IV. IPCablecom/PacketCable Submissions We'll discuss recent updates, open issues and next steps for the following drafts: o MTA MIB draft-ietf-ipcdn-pktc-mtamib-02.txt o Signaling MIB draft-ietf-ipcdn-pktc-signaling-02.txt o Management Event MIB for PacketCable/IPCablecom draft-ietf-ipcdn-pktc-eventmess-03.txt rev 3 was submitted but not posted. V. CableHome Submissions o CableHome Remote Diagnostic Tools MIB draft-ietf-ipcdn-cable-gateway-tools-mib-00. Discuss progress on Ping capability & Randy's comments VI. Next steps -- Richard Woundy and Jean-Francois Mule, IPCDN co-chairs _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Nov 10 15:06:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09662 for ; Mon, 10 Nov 2003 15:06:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIIV-00066M-5h for ipcdn-archive@odin.ietf.org; Mon, 10 Nov 2003 15:06:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAK63Tw023450 for ipcdn-archive@odin.ietf.org; Mon, 10 Nov 2003 15:06:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIIS-00065w-Mg; Mon, 10 Nov 2003 15:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIIB-00065O-Py for ipcdn@optimus.ietf.org; Mon, 10 Nov 2003 15:05:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09564 for ; Mon, 10 Nov 2003 15:05:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJII8-0003bI-00 for ipcdn@ietf.org; Mon, 10 Nov 2003 15:05:40 -0500 Received: from coral.tci.com ([198.178.8.81] helo=snowmass.tci.com) by ietf-mx with esmtp (Exim 4.12) id 1AJII8-0003au-00 for ipcdn@ietf.org; Mon, 10 Nov 2003 15:05:40 -0500 Received: from entexchimc02.broadband.att.com (entexchimc02.broadband.att.com [147.191.89.201]) by snowmass.tci.com (8.12.9/8.12.9) with ESMTP id hAAJviPb002331; Mon, 10 Nov 2003 12:57:44 -0700 (MST) Received: by entexchimc02.broadband.att.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Nov 2003 12:57:43 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC0B65210F@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'azlina@cisco.com'" , Jean-Francois Mule Cc: ipcdn@ietf.org Subject: RE: [ipcdn] Size of docsDevSwFilename in draft-ietf-ipcdn-device- mibv2-06.txt Date: Mon, 10 Nov 2003 12:57:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I believe Azlina is correct. What should we do to resolve? -- Rich -----Original Message----- From: Azlina Ahmad [mailto:azlina@cisco.com] Sent: Friday, October 31, 2003 1:01 PM To: Jean-Francois Mule Cc: Woundy, Richard; ipcdn@ietf.org Subject: Re: [ipcdn] Size of docsDevSwFilename in draft-ietf-ipcdn-device-mibv2-06.txt Jean-Francois, I believe we have extended the upper bound of a mib object in the past :) However, per RFC2578 Section 9 rule (3) defined that "the size in = octets=20 of the value may be refined by raising the lower-bounds, by reducing = the=20 upper-bounds, and/or by reducing the alternative size choices." So, extending this size may not be permitted. Thanks, Azlina Jean-Francois Mule wrote: > Rich, >=20 > Reviewing the cable device v2 mib to create the compliance statement = for PacketCable Standalone MTAs, we noticed that the object size is limited = to 64 chars. While this may be plenty for tftp filenames, it could be a = bit restrictive in the case of HTTP download. >=20 > Therefore, we'd like to recommend the following: > - the docsDevSwFilename object definition be extended to a size of = 128 at a minimum > - the compliance statement for v2 DOCSIS CM restrict the = implementation to 64 for those devices so that there is no requirement change for = DOCSIS >=20 > docsDevSwFilename OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..64)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The filename of the software image to be downloaded via > TFTP, or the abs_path (as defined in RFC2616) of the > software image to be downloaded via HTTP. >=20 > Unless set via SNMP, this is the filename or abs_path > specified by the provisioning server during the boot > process, that corresponds to the software version that > is desired for this device. >=20 > If unknown, the value of this object is the empty = string." > ::=3D { docsDevSoftware 2 } >=20 > Comments appreciated. > Jean-Fran=E7ois=20 >=20 >>-----Original Message----- >>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 >>Sent: Monday, October 27, 2003 3:10 PM >>Cc: ipcdn@ietf.org >>Subject: I-D ACTION:draft-ietf-ipcdn-device-mibv2-06.txt >> >> >>A New Internet-Draft is available from the on-line=20 >>Internet-Drafts directories. This draft is a work item of the=20 >>IP over Cable Data Network Working Group of the IETF. >> >> Title : Cable Device Management Information=20 >>Base for DOCSIS compliant Cable Modems and Cable Modem=20 >>Termination Systems >> Author(s) : R. Woundy >> Filename : draft-ietf-ipcdn-device-mibv2-06.txt >> Pages : 79 >> Date : 2003-10-27 >>=09 >>This memo is a draft revision of the standards track=20 >>RFC-2669. Please see 'Revision Descriptions' below for a=20 >>description of changes. This document will obsolete RFC-2669=20 >>when accepted. This memo defines a portion of the Management=20 >>Information Base (MIB) for use with network management=20 >>protocols in the Internet community. In particular, it=20 >>defines a basic set of managed objects for SNMP- based=20 >>management of DOCSIS compliant Cable Modems and Cable Modem=20 >>Termination Systems. This memo is a product of the IPCDN=20 >>working group within the Internet Engineering Task Force. =20 >>Comments are solicited and should be addressed to the working=20 >>group's mailing list at ipcdn@ietf.org and/or the author. >> >>A URL for this Internet-Draft is:=20 >>http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mi >=20 > bv2-06.txt >=20 > To remove yourself from the IETF Announcement list, send a message to = > ietf-announce-request with the word unsubscribe in the body of the message. >=20 > 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-device-mibv2-06.txt". >=20 > A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-06.txt". > =09 > 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. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Nov 10 15:27:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11639 for ; Mon, 10 Nov 2003 15:27:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIcp-0007vw-MP for ipcdn-archive@odin.ietf.org; Mon, 10 Nov 2003 15:27:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAKR3RG030496 for ipcdn-archive@odin.ietf.org; Mon, 10 Nov 2003 15:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIco-0007vS-KF; Mon, 10 Nov 2003 15:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIcX-0007uD-2P for ipcdn@optimus.ietf.org; Mon, 10 Nov 2003 15:26:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11557 for ; Mon, 10 Nov 2003 15:26:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIcV-000400-00 for ipcdn@ietf.org; Mon, 10 Nov 2003 15:26:43 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AJIcV-0003zE-00 for ipcdn@ietf.org; Mon, 10 Nov 2003 15:26:43 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAAKQ9w29049 for ; Mon, 10 Nov 2003 14:26:09 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Nov 2003 21:26:07 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502EAF5CE@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Woundy, Richard" , "'azlina@cisco.com'" , Jean-Francois Mule Cc: ipcdn@ietf.org Subject: RE: [ipcdn] Size of docsDevSwFilename in draft-ietf-ipcdn-device- mibv2-06.txt Date: Mon, 10 Nov 2003 21:26:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable One could wonder if the 64 size limit in RFC2669 could be=20 considered a (fatal) bug in that spec? If so, then fixing that seems plausable/acceptable, and=20 with a proper module COMPLIANCE as discussed below, that would probably be OK. Of course the WG needs to agree with that. my 2 cents Thanks, Bert=20 > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: maandag 10 november 2003 20:58 > To: 'azlina@cisco.com'; Jean-Francois Mule > Cc: ipcdn@ietf.org > Subject: RE: [ipcdn] Size of docsDevSwFilename in > draft-ietf-ipcdn-device- mibv2-06.txt >=20 >=20 > I believe Azlina is correct. What should we do to resolve? >=20 > -- Rich >=20 > -----Original Message----- > From: Azlina Ahmad [mailto:azlina@cisco.com] > Sent: Friday, October 31, 2003 1:01 PM > To: Jean-Francois Mule > Cc: Woundy, Richard; ipcdn@ietf.org > Subject: Re: [ipcdn] Size of docsDevSwFilename in > draft-ietf-ipcdn-device-mibv2-06.txt >=20 >=20 > Jean-Francois, > I believe we have extended the upper bound of a mib object > in the past :) > However, per RFC2578 Section 9 rule (3) defined that "the=20 > size in octets=20 > of the value may be refined by raising the lower-bounds, by=20 > reducing the=20 > upper-bounds, and/or by reducing the alternative size choices." > So, extending this size may not be permitted. >=20 > Thanks, > Azlina >=20 > Jean-Francois Mule wrote: > > Rich, > >=20 > > Reviewing the cable device v2 mib to create the compliance=20 > statement for > PacketCable Standalone MTAs, we noticed that the object size=20 > is limited to > 64 chars. While this may be plenty for tftp filenames, it=20 > could be a bit > restrictive in the case of HTTP download. > >=20 > > Therefore, we'd like to recommend the following: > > - the docsDevSwFilename object definition be extended to a=20 > size of 128 at > a minimum > > - the compliance statement for v2 DOCSIS CM restrict the=20 > implementation > to 64 for those devices so that there is no requirement=20 > change for DOCSIS > >=20 > > docsDevSwFilename OBJECT-TYPE > > SYNTAX SnmpAdminString (SIZE (0..64)) > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "The filename of the software image to be downloaded = via > > TFTP, or the abs_path (as defined in RFC2616) of the > > software image to be downloaded via HTTP. > >=20 > > Unless set via SNMP, this is the filename or abs_path > > specified by the provisioning server during the boot > > process, that corresponds to the software version that > > is desired for this device. > >=20 > > If unknown, the value of this object is the=20 > empty string." > > ::=3D { docsDevSoftware 2 } > >=20 > > Comments appreciated. > > Jean-Fran=E7ois=20 > >=20 > >>-----Original Message----- > >>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > >>Sent: Monday, October 27, 2003 3:10 PM > >>Cc: ipcdn@ietf.org > >>Subject: I-D ACTION:draft-ietf-ipcdn-device-mibv2-06.txt > >> > >> > >>A New Internet-Draft is available from the on-line=20 > >>Internet-Drafts directories. This draft is a work item of the=20 > >>IP over Cable Data Network Working Group of the IETF. > >> > >> Title : Cable Device Management Information=20 > >>Base for DOCSIS compliant Cable Modems and Cable Modem=20 > >>Termination Systems > >> Author(s) : R. Woundy > >> Filename : draft-ietf-ipcdn-device-mibv2-06.txt > >> Pages : 79 > >> Date : 2003-10-27 > >>=09 > >>This memo is a draft revision of the standards track=20 > >>RFC-2669. Please see 'Revision Descriptions' below for a=20 > >>description of changes. This document will obsolete RFC-2669=20 > >>when accepted. This memo defines a portion of the Management > >>Information Base (MIB) for use with network management=20 > >>protocols in the Internet community. In particular, it=20 > >>defines a basic set of managed objects for SNMP- based=20 > >>management of DOCSIS compliant Cable Modems and Cable Modem=20 > >>Termination Systems. This memo is a product of the IPCDN=20 > >>working group within the Internet Engineering Task Force. =20 > >>Comments are solicited and should be addressed to the working=20 > >>group's mailing list at ipcdn@ietf.org and/or the author. > >> > >>A URL for this Internet-Draft is:=20 > >>http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mi > >=20 > > bv2-06.txt > >=20 > > To remove yourself from the IETF Announcement list, send a=20 > message to=20 > > ietf-announce-request with the word unsubscribe in the body of the > message. > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address.=20 > After logging > in, type "cd internet-drafts" and then > > "get draft-ietf-ipcdn-device-mibv2-06.txt". > >=20 > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-06.txt". > > =09 > > 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=20 > 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. > > =09 > > =09 > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > >=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 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Nov 10 15:35:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12128 for ; Mon, 10 Nov 2003 15:35:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIkY-0000RB-Ak for ipcdn-archive@odin.ietf.org; Mon, 10 Nov 2003 15:35:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAKZ280001625 for ipcdn-archive@odin.ietf.org; Mon, 10 Nov 2003 15:35:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIkX-0000Q6-RM; Mon, 10 Nov 2003 15:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIkL-0000PD-St for ipcdn@optimus.ietf.org; Mon, 10 Nov 2003 15:34:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12049 for ; Mon, 10 Nov 2003 15:34:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIkK-0004CI-00 for ipcdn@ietf.org; Mon, 10 Nov 2003 15:34:48 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AJIkJ-0004B1-00 for ipcdn@ietf.org; Mon, 10 Nov 2003 15:34:47 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hAAKX4oK021272; Mon, 10 Nov 2003 13:33:05 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Size of docsDevSwFilename in draft-ietf-ipcdn-device-mibv2-06.txt Date: Mon, 10 Nov 2003 13:33:04 -0700 Message-ID: Thread-Topic: [ipcdn] Size of docsDevSwFilename in draft-ietf-ipcdn-device-mibv2-06.txt Thread-Index: AcOf2O6mqtcv+n3mQvqHRKSzDAsnkAHzA3hQ From: "Jean-Francois Mule" To: Cc: "Woundy, Richard" , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable (I thought I had sent this but it was stuck in my draft folder, and just = saw Rich's note - sorry). Azlina, Good point, I forgot that the device mib is *not* a "new" mib and we = can't increase the upper bound. We have a couple of options: - do nothing (operators should get their http server hostnames and URL = down to 64 chars) - keep docsDevSwFilename for TFTP and add a new object = docsDevSwFilenameURL for http (this has the advantage to leave the DOCSIS implementations intact on = this object) - deprecate docsDevSwFilename and a new object docsDevSwFilenameURL for = tftp and http Since this new object is moslty required for PAcketCable Standalone = MTAs, I'm ok with option 2 above. Jean-Fran=E7ois=20 > -----Original Message----- > From: Azlina Ahmad [mailto:azlina@cisco.com] > Sent: Friday, October 31, 2003 11:01 AM > To: Jean-Francois Mule > Cc: Woundy, Richard; ipcdn@ietf.org > Subject: Re: [ipcdn] Size of docsDevSwFilename in=20 > draft-ietf-ipcdn-device-mibv2-06.txt >=20 >=20 > Jean-Francois, > I believe we have extended the upper bound of a mib > object in the past :) However, per RFC2578 Section 9 rule (3)=20 > defined that "the size in octets=20 > of the value may be refined by raising the lower-bounds, by=20 > reducing the=20 > upper-bounds, and/or by reducing the alternative size=20 > choices." So, extending this size may not be permitted. >=20 > Thanks, > Azlina >=20 > Jean-Francois Mule wrote: > > Rich, > >=20 > > Reviewing the cable device v2 mib to create the compliance > statement > > for PacketCable Standalone MTAs, we noticed that the object size is > > limited to 64 chars. While this may be plenty for tftp=20 > filenames, it > > could be a bit restrictive in the case of HTTP download. > >=20 > > Therefore, we'd like to recommend the following: > > - the docsDevSwFilename object definition be extended to a size of > > 128 at a minimum > > - the compliance statement for v2 DOCSIS CM restrict the=20 > implementation to 64 for those devices so that there is no > requirement change for DOCSIS > >=20 > > docsDevSwFilename OBJECT-TYPE > > SYNTAX SnmpAdminString (SIZE (0..64)) > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "The filename of the software image to be downloaded via > > TFTP, or the abs_path (as defined in RFC2616) of the > > software image to be downloaded via HTTP. > >=20 > > Unless set via SNMP, this is the filename or abs_path > > specified by the provisioning server during the boot > > process, that corresponds to the software version that > > is desired for this device. > >=20 > > If unknown, the value of this object is the > empty string." > > ::=3D { docsDevSoftware 2 } > >=20 > > Comments appreciated. > > Jean-Fran=E7ois > >=20 > >>-----Original Message----- > >>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >>Sent: Monday, October 27, 2003 3:10 PM > >>Cc: ipcdn@ietf.org > >>Subject: I-D ACTION:draft-ietf-ipcdn-device-mibv2-06.txt > >> > >> > >>A New Internet-Draft is available from the on-line Internet-Drafts=20 > >>directories. This draft is a work item of the IP over Cable Data=20 > >>Network Working Group of the IETF. > >> > >> Title : Cable Device Management Information=20 > >>Base for DOCSIS compliant Cable Modems and Cable Modem Termination=20 > >>Systems > >> Author(s) : R. Woundy > >> Filename : draft-ietf-ipcdn-device-mibv2-06.txt > >> Pages : 79 > >> Date : 2003-10-27 > >>=09 > >>This memo is a draft revision of the standards track RFC-2669.=20 > >>Please see 'Revision Descriptions' below for a description of=20 > >>changes. This document will obsolete RFC-2669 when accepted. This=20 > >>memo defines a portion of the Management Information Base (MIB) for=20 > >>use with network management protocols in the Internet community. In=20 > >>particular, it defines a basic set of managed objects for SNMP-=20 > >>based management of DOCSIS compliant Cable Modems and Cable Modem > >>Termination Systems. This memo is a product of the IPCDN=20 > >>working group within the Internet Engineering Task Force. =20 > >>Comments are solicited and should be addressed to the working=20 > >>group's mailing list at ipcdn@ietf.org and/or the author. > >> > >>A URL for this Internet-Draft is:=20 > >>http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mi > >=20 > > bv2-06.txt > >=20 > > To remove yourself from the IETF Announcement list, send a > message to > > ietf-announce-request with the word unsubscribe in the body > of the message. > >=20 > > 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-device-mibv2-06.txt". > >=20 > > 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 > >=20 > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-06.txt". > > =09 > > 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. > > =09 > > =09 > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > >=20 >=20 >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Nov 11 12:45:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12911 for ; Tue, 11 Nov 2003 12:45:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcZa-0005IW-Oc for ipcdn-archive@odin.ietf.org; Tue, 11 Nov 2003 12:45:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHj2G3020340 for ipcdn-archive@odin.ietf.org; Tue, 11 Nov 2003 12:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcZZ-0005Hq-Vv; Tue, 11 Nov 2003 12:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcZO-0005HN-QZ for ipcdn@optimus.ietf.org; Tue, 11 Nov 2003 12:44:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12852 for ; Tue, 11 Nov 2003 12:44:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcZN-0006zI-00 for ipcdn@ietf.org; Tue, 11 Nov 2003 12:44:49 -0500 Received: from coral.tci.com ([198.178.8.81] helo=peacock.tci.com) by ietf-mx with esmtp (Exim 4.12) id 1AJcZM-0006z1-00 for ipcdn@ietf.org; Tue, 11 Nov 2003 12:44:48 -0500 Received: from entexchimc03.broadband.att.com (entexchimc03.broadband.att.com [147.191.90.10]) by peacock.tci.com (8.12.9/8.12.9) with ESMTP id hABHi4Ta028187; Tue, 11 Nov 2003 10:44:09 -0700 (MST) Received: by entexchimc03.broadband.att.com with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Nov 2003 10:44:03 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC0B652119@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'ipcdn@ietf.org '" Cc: "'jf.mule@cablelabs.com '" , "Woundy, Richard" Date: Tue, 11 Nov 2003 10:43:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [ipcdn] Slides for today's WG meeting Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Folks, Today's slides are posted at . The meeting will start at 1PM central time. We will attempt to get a jabber scribe onsite, so that remote folks can participate. -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Nov 11 13:39:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14750 for ; Tue, 11 Nov 2003 13:39:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdPs-0001Ng-3E for ipcdn-archive@odin.ietf.org; Tue, 11 Nov 2003 13:39:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABId4mJ005302 for ipcdn-archive@odin.ietf.org; Tue, 11 Nov 2003 13:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdPo-0001NJ-MO; Tue, 11 Nov 2003 13:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdPd-0001N6-0v for ipcdn@optimus.ietf.org; Tue, 11 Nov 2003 13:38:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14733 for ; Tue, 11 Nov 2003 13:38:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdPa-0007fn-00 for ipcdn@ietf.org; Tue, 11 Nov 2003 13:38:46 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AJdPa-0007fE-00 for ipcdn@ietf.org; Tue, 11 Nov 2003 13:38:46 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hABIauoK015217; Tue, 11 Nov 2003 11:36:56 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Nov 2003 11:36:55 -0700 Message-ID: Thread-Topic: Q of docsIfCmtsChannelUtUtilization for Upstream Thread-Index: AcOn8qB9FFYvNL3HRhqJHDqDiiP8BQAgrb7A From: "Eduardo Cardona" To: "Minnie Lu" , Cc: "DOCSIS OSS Majordomo List" , "Jean-Francois Mule" , "Greg White" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: Q of docsIfCmtsChannelUtUtilization for Upstream Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Minnie,=20 It is debatable if the current text imposes the fixed bandwidth allocation.=20 We believe the text should be taken in the context of the measurement interval. From that perspective we think It won't preclude or limit the CMTS capabilities to change dynamically the % bandwidth allocation.=20 Internally at CL, Greg and I looked at the case and probably the proposed text below may help.=20 -> added at the end of the below paragraph: "over the most recent utilization interval." For an upstream interface that has multiple logical upstream channels enabled, the utilization index is a weighted sum of utilization indices for the logical channels. The weight for each utilization index is the percentage of upstream minislots allocated for the corresponding logical channel over the most recent utilization interval. Eduardo, Greg =20 -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Monday, November 10, 2003 6:25 PM To: Jean-Francois Mule; Eduardo Cardona; Greg White Cc: milu@cisco.com; DOCSIS OSS Majordomo List Subject: Q of docsIfCmtsChannelUtUtilization for Upstream Hi, all, I have a question about upstream docsIfCmtsChannelUtUtilization. In the=20 description, it says: "Upstream Channel Utilization Index: The upstream channel utilization index is expressed as a percentage of minislots utilized on the physical channel, regardless of burst type. For an Initial Maintenance region, the minislots for the complete region are considered utilized if the CMTS received an upstream burst within the region from any CM on the physical channel. For contention REQ and REQ/DATA regions, the minislots for a transmission opportunity within the region are considered utilized if the CMTS received an upstream burst within the opportunity from any CM on the physical channel. For all other regions, utilized minislots are those in which the CMTS granted bandwidth to any unicast SID on the physical channel. For an upstream interface that has multiple logical upstream channels enabled, the utilization index is a weighted sum of utilization indices for the logical channels. The weight for each utilization index is the percentage of upstream minislots allocated for the corresponding logical channel. Example: If 75% of bandwidth is allocated to the first logical channel and 25% to the second, and the utilization indices for each are 60 and 40 respectively, the utilization index for the upstream physical channel is (60 * 0.75) + (40 * 0.25) =3D 55. This figure applies to the most recent utilization interval." Q: for multiple logical channels enabled case, why can it be still "a percentage of minislots utilized on the physical channel, regardless=20 of burst type." ? That is, (the sum of minislots utilized for all logical=20 channels) / (the sum of total minislots for all logical=20 channels) In the current description, it seems that CMTS must support fixed % of=20 bandwidth allocated for each logical channel, I cannot find such=20 requirement in RFIv2.0 spec. Also according to the RFIv2.0 spec, some CMTS=20 vendor might choose to support that the % could be changed dynamically at=20 the run time for logical channels or some vendors might choose to support=20 dynamical bandwidth allocation without any fixed %. So may I suggest to remove the follow statements from the description of=20 docsIfCmtsChannelUtUtilization ? " For an upstream interface that has multiple logical upstream channels enabled, the utilization index is a weighted sum of utilization indices for the logical channels. The weight for each utilization index is the percentage of upstream minislots allocated for the corresponding logical channel. Example: If 75% of bandwidth is allocated to the first logical channel and 25% to the second, and the utilization indices for each are 60 and 40 respectively, the utilization index for the upstream physical channel is (60 * 0.75) + (40 * 0.25) =3D 55. This figure applies to the most recent utilization interval." If I miss any thing, please advice me ! Thanks a lot for your help ! Minnie =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Nov 11 13:56:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15489 for ; Tue, 11 Nov 2003 13:56:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdgH-0002Yl-LM for ipcdn-archive@odin.ietf.org; Tue, 11 Nov 2003 13:56:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABIu11F009822 for ipcdn-archive@odin.ietf.org; Tue, 11 Nov 2003 13:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdgH-0002YF-8c; Tue, 11 Nov 2003 13:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdgE-0002Y2-9V for ipcdn@optimus.ietf.org; Tue, 11 Nov 2003 13:55:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15478 for ; Tue, 11 Nov 2003 13:55:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdgB-0000Af-00 for ipcdn@ietf.org; Tue, 11 Nov 2003 13:55:55 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AJdgB-0000AI-00 for ipcdn@ietf.org; Tue, 11 Nov 2003 13:55:55 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hABIsYoK017030; Tue, 11 Nov 2003 11:54:34 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Nov 2003 11:54:33 -0700 Message-ID: Thread-Topic: Q of docsIfCmtsChannelUtUtilization for Upstream Thread-Index: AcOn8qB9FFYvNL3HRhqJHDqDiiP8BQAgrb7AAAN9D5A= From: "Eduardo Cardona" To: "Minnie Lu" , Cc: "DOCSIS OSS Majordomo List" , "Jean-Francois Mule" , "Greg White" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: Q of docsIfCmtsChannelUtUtilization for Upstream Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Minnie Lu,=20 The other concern you have is the US Interface Utilization calculation,=20 I will assume that if a dynamic Burst profile adjustment is chosen by the CMTS, the Utilization interval must be adjusted to be lower that the dynamic Burst profile rate change ( actually half to be sort of Nyquist compliant.)=20 To support your case the description should be changed for the US interface, and I see no real benefit for overall historical data analysis perspective. The weighted perception of US Interface I believe is more realistic (valuable? )and shows the bandwidth utilization sensitivity better (See examples below) At the end, the users consume Bandwidth with a bad or good minislots usage/efficiencies of them, based on the Modulation profile used and CM allocation among channels. Also since burst types could be variable (Dynamic) the only average constant would be user bandwidth usage at least for planning purposes and historical recollection, weighted usage is a normalization of the differences among channels. =20 Supposed Channels A, B and lets use a coins (minislots) vs coins value (burst type)=20 A has 3 5 cents coins=20 B has 6 10 cents coins Minislots usage =3D coins spend=20 Weighted Minislots usage -> cents usage In Us Channels (A or B) spend coins vs spend cents ( minislots vs BW) is the same. With the US DS counters you can get also the U based on sharp=20 Total BW ( in cents is 3*5 + 6*10) =3D 75 Total coins =3D 3 + 6 =3D 9 If A spends 2 coins and B spends 1 coin=20 Spend coins =3D 2 + 1 =3D 3 U% 3/9 =3D 33% Spend Cents: 2*5 + 1*10 =3D 20 U% =3D 20/75 =3D 26% ChaA U =3D 2/3 =3D 66% ChaB U =3D 1/6 =3D 16% Supposed the other case of B more used A Spends 1 coin and B spend 4 coins US channel Coins spend 1 + 4 =3D 5; U =3D 5/9 =3D 55% Cents spend 1*5 + 5*10 =3D 55; U% =3D 75% ChaA U =3D 1/3 =3D 33% ChaB U =3D 5/6 =3D 83% -----Original Message----- From: Eduardo Cardona=20 Sent: Tuesday, November 11, 2003 11:37 AM To: 'Minnie Lu'; 'ipcdn@ietf.org' Cc: DOCSIS OSS Majordomo List; Jean-Francois Mule; Greg White Subject: RE: Q of docsIfCmtsChannelUtUtilization for Upstream Hi Minnie,=20 It is debatable if the current text imposes the fixed bandwidth allocation.=20 We believe the text should be taken in the context of the measurement interval. From that perspective we think It won't preclude or limit the CMTS capabilities to change dynamically the % bandwidth allocation.=20 Internally at CL, Greg and I looked at the case and probably the proposed text below may help.=20 -> added at the end of the below paragraph: "over the most recent=20 -> utilization interval." For an upstream interface that has multiple logical upstream channels enabled, the utilization index is a weighted sum of utilization indices for the logical channels. The weight for each utilization index is the percentage of upstream minislots allocated for the corresponding logical channel over the most recent utilization interval. Eduardo, Greg =20 -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Monday, November 10, 2003 6:25 PM To: Jean-Francois Mule; Eduardo Cardona; Greg White Cc: milu@cisco.com; DOCSIS OSS Majordomo List Subject: Q of docsIfCmtsChannelUtUtilization for Upstream Hi, all, I have a question about upstream docsIfCmtsChannelUtUtilization. In the=20 description, it says: "Upstream Channel Utilization Index: The upstream channel utilization index is expressed as a percentage of minislots utilized on the physical channel, regardless of burst type. For an Initial Maintenance region, the minislots for the complete region are considered utilized if the CMTS received an upstream burst within the region from any CM on the physical channel. For contention REQ and REQ/DATA regions, the minislots for a transmission opportunity within the region are considered utilized if the CMTS received an upstream burst within the opportunity from any CM on the physical channel. For all other regions, utilized minislots are those in which the CMTS granted bandwidth to any unicast SID on the physical channel. For an upstream interface that has multiple logical upstream channels enabled, the utilization index is a weighted sum of utilization indices for the logical channels. The weight for each utilization index is the percentage of upstream minislots allocated for the corresponding logical channel. Example: If 75% of bandwidth is allocated to the first logical channel and 25% to the second, and the utilization indices for each are 60 and 40 respectively, the utilization index for the upstream physical channel is (60 * 0.75) + (40 * 0.25) =3D 55. This figure applies to the most recent utilization interval." Q: for multiple logical channels enabled case, why can it be still "a percentage of minislots utilized on the physical channel, regardless=20 of burst type." ? That is, (the sum of minislots utilized for all logical=20 channels) / (the sum of total minislots for all logical=20 channels) In the current description, it seems that CMTS must support fixed % of=20 bandwidth allocated for each logical channel, I cannot find such=20 requirement in RFIv2.0 spec. Also according to the RFIv2.0 spec, some CMTS=20 vendor might choose to support that the % could be changed dynamically at=20 the run time for logical channels or some vendors might choose to support=20 dynamical bandwidth allocation without any fixed %. So may I suggest to remove the follow statements from the description of=20 docsIfCmtsChannelUtUtilization ? " For an upstream interface that has multiple logical upstream channels enabled, the utilization index is a weighted sum of utilization indices for the logical channels. The weight for each utilization index is the percentage of upstream minislots allocated for the corresponding logical channel. Example: If 75% of bandwidth is allocated to the first logical channel and 25% to the second, and the utilization indices for each are 60 and 40 respectively, the utilization index for the upstream physical channel is (60 * 0.75) + (40 * 0.25) =3D 55. This figure applies to the most recent utilization interval." If I miss any thing, please advice me ! Thanks a lot for your help ! Minnie =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Nov 21 17:26:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08662 for ; Fri, 21 Nov 2003 17:26:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJj2-00025O-OV for ipcdn-archive@odin.ietf.org; Fri, 21 Nov 2003 17:26:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALMQ4JP008014 for ipcdn-archive@odin.ietf.org; Fri, 21 Nov 2003 17:26:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJiz-00024x-IV; Fri, 21 Nov 2003 17:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJiB-00022V-Qz for ipcdn@optimus.ietf.org; Fri, 21 Nov 2003 17:25:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08514 for ; Fri, 21 Nov 2003 17:24:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJi9-000306-00 for ipcdn@ietf.org; Fri, 21 Nov 2003 17:25:09 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1ANJi8-0002wj-00 for ipcdn@ietf.org; Fri, 21 Nov 2003 17:25:08 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hALMOYoK015461; Fri, 21 Nov 2003 15:24:34 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3B07E.3DAC8ED1" Date: Fri, 21 Nov 2003 15:24:34 -0700 Message-ID: X-MS-Has-Attach: yes Thread-Topic: ipcdn DOCSIS QoS mib and closure on IP TOS vs. DSCP open issue Thread-Index: AcOTJRO6PIKvrIGETtWQ7K2i4k+kgAbyghZAAAFzfNAAYYoiEA== From: "Jean-Francois Mule" To: "Bert" Cc: , "Richard Woundy @ Comcast" , "Jean-Francois Mule" , "Greg White" , "Murwin William-LWM008" , "Patrick Michael-LZZ007" , "Eduardo Cardona" , "Matthew Schmitt" X-Approved: ondar Subject: [ipcdn] ipcdn DOCSIS QoS mib and closure on IP TOS vs. DSCP open issue Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B07E.3DAC8ED1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bert, At the last IETF meeting, you asked that we provide a short write-up to close the one open issue on the IPCDN DOCSIS QoS MIB draft09. Greg White has put together the attached note integrating thoughts & comments from the IPCDN QoS MIB co-authors - William Murwin & Patrick Michael, Matt Schmitt, Rich and myself (thank you Greg). I believe this write-up answers your request.=20 It provides: - the list of MIB objects using TOS value in the QoS mib object name, the max-access (read-only), what the object is for and whether it is used in the DOCSIS network only (between CM - CMTS) or whether it would potentially get propagated in the backbone (to understand whether this could break the PHB behavior in the backbone), - the range of TOS values these objects can have and how the mapping with the six bits of DSCP can be achieved, - the justification to maintain TOS based on past & current DOCSIS systems along with the limited applicability scope. Let us know what the next steps are to advance the IPCDN QoS MIB. Upon your review & recommendations, it is our intent to release an updated draft10 which will be ready for publication. Thanks, Rich & Jean-Francois - ipcdn wg co-chairs ------_=_NextPart_001_01C3B07E.3DAC8ED1 Content-Type: text/plain; name="ipcdn qos mib draft09 - closure on the use of TOS.txt" Content-Description: ipcdn qos mib draft09 - closure on the use of TOS.txt Content-Disposition: attachment; filename="ipcdn qos mib draft09 - closure on the use of TOS.txt" Content-Transfer-Encoding: base64 VG86IEJlcnQgV2lqbmVuIDxid2lqbmVuQGx1Y2VudC5jb20+LCBBcmVhIERpcmVjdG9yLCBJRVRG IE9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQgQXJlYQ0KRnJvbTogSVBDRE4gV0cgQ2hhaXJzOiBS aWNoYXJkIFdvdW5keSA8UmljaGFyZF9Xb3VuZHlAY2FibGUuY29tY2FzdC5jb20+LCBKZWFuLUZy YW5jb2lzIE11bGUgPGpmLm11bGVAY2FibGVsYWJzLmNvbT4NCkNDOiBpcGNkbkBpZXRmLm9yZw0K DQpSRTogaXBjZG4gRE9DU0lTIFFvUyBtaWIgYW5kIGNsb3N1cmUgb24gSVAgVE9TIHZzLiBEU0NQ IG9wZW4gaXNzdWUNCg0KVGhlIERPQ1NJUyBRb1MgTUlCIChkcmFmdC1pZXRmLWlwY2RuLXFvcy1t aWItMDkpIGNvbnRhaW5zIGZpdmUgb2JqZWN0cyB3aGljaCB1c2UgdGhlIChmb3JtZXIpIElQdjQg VE9TIG9jdGV0IGFzIGRlZmluZWQgaW4gUkZDIDc5MS4gQWxsIGFyZSByZWFkLW9ubHkgb2JqZWN0 cyB3aGljaCBhcmUgdXNlZCB0byBpbnN0cnVtZW50IHNldHRpbmdzIHRoYXQgaGF2ZSBiZWVuIGNv bmZpZ3VyZWQgdmlhIGEgRE9DU0lTLWRlZmluZWQgcHJvdG9jb2wgbWVjaGFuaXNtIChjb25maWd1 cmF0aW9uIGZpbGUgdHJhbnNmZXIgYW5kL29yIE1BQy1sYXllciBtYW5hZ2VtZW50IG1lc3NhZ2Ug ZXhjaGFuZ2UpLg0KDQpUaGUgZml2ZSBvYmplY3RzIGFyZSB1c2VkIGZvciB0d28gZGlmZmVyZW50 IGZ1bmN0aW9uYWxpdGllcyB3aXRoaW4gdGhlIERPQ1NJUyBhY2Nlc3MgbmV0d29yay4gDQoNClRo ZSBmaXJzdCBmdW5jdGlvbmFsaXR5IGlzIHBhY2tldCBjbGFzc2lmaWNhdGlvbiB0byBwcm92aWRl IFF1YWxpdHkgb2YgU2VydmljZSBvbiB0aGUgRE9DU0lTIGFjY2VzcyBuZXR3b3JrLiAgVGhlIERP Q1NJUyBwcm90b2NvbCBpbmNsdWRlcyBtZXNzYWdpbmcgdG8gY29uZmlndXJlIHBhY2tldCBjbGFz c2lmaWNhdGlvbiB0aGF0IGNhbiBtYXRjaCBwYWNrZXRzIGJhc2VkIG9uIChhbW9uZyBvdGhlciB0 aGluZ3MpIHRoZSBjb250ZW50cyBvZiB0aGUgVE9TIG9jdGV0IG9mIHRoZSBJUHY0IGhlYWRlci4g IFRoaXMgSVAgVHlwZS1vZi1TZXJ2aWNlIGNsYXNzaWZpZXIgY29uZmlndXJhdGlvbiB1c2VzIHRo cmVlIHBhcmFtZXRlcnM6IHRvcy1sb3csIHRvcy1oaWdoLCBhbmQgdG9zLW1hc2suICBQYWNrZXRz IG1hdGNoIHRoZSBjbGFzc2lmaWVyIGlmIHRoZWlyICJpcC10b3MiIGJ5dGUgbWVldHMgdGhlIGNy aXRlcmlhOiB0b3MtbG93IDw9IChpcC10b3MgQU5EIHRvcy1tYXNrKSA8PSB0b3MtaGlnaC4gIFdp dGggcHJvcGVyIGNob2ljZXMgb2YgdGhlIHRocmVlIHBhcmFtZXRlcnMgKGluIHBhcnRpY3VsYXIs IHRvcy1tYXNrPTB4RkMsIHRvcy1sb3c9dG9zLWhpZ2g9RFNDUDw8MiksIHRoaXMgZnVuY3Rpb25h bGl0eSBjb3VsZCBiZSB1c2VkIHRvIGVuYWJsZSBhIERpZmZTZXJ2LWNhcGFibGUgYWNjZXNzIG5l dHdvcmsuICBCZWNhdXNlIHRoaXMgZnVuY3Rpb25hbGl0eSBpcyBvbmx5IHVzZWQgdG8gcHJvdmlk ZSBRb1Mgb24gdGhlIERPQ1NJUyBhY2Nlc3MgbmV0d29yaywgYW5kIGRvZXMgbm90IG1vZGlmeSB0 aGUgY29udGVudHMgb2YgdGhlIElQdjQgZGF0YWdyYW0sIHRoaXMgZG9lcyBub3QgYnJlYWsgYW55 IHVzYWdlIG9mIERpZmZTZXJ2IG9yIEVDTiBvbiB0aGUgYmFja2JvbmUuIFRoZSBmb2xsb3dpbmcg dGhyZWUgcmVhZC1vbmx5IG9iamVjdHMgcmVmbGVjdCB0aGUgY29uZmlndXJlZCBzZXR0aW5ncyBm b3IgdGhpcyBmdW5jdGlvbmFsaXR5Og0KICAgIGRvY3NRb3NQa3RDbGFzc0lwVG9zTG93ICAgICAg ICAgICANCiAgICBkb2NzUW9zUGt0Q2xhc3NJcFRvc0hpZ2ggICAgICAgICAgDQogICAgZG9jc1Fv c1BrdENsYXNzSXBUb3NNYXNrICAgICAgICAgICANCg0KDQpUaGUgc2Vjb25kIGZ1bmN0aW9uYWxp dHkgaXMgVE9TIE92ZXJ3cml0ZS4gIFRoZSBET0NTSVMgcHJvdG9jb2wgaW5jbHVkZXMgbWVzc2Fn aW5nIHRvIGNvbmZpZ3VyZSB0aGUgb3ZlcndyaXRlIG9mIHRoZSBJUHY0IFRPUyBvY3RldCBmb3Ig Y2VydGFpbiBwYWNrZXQgZmxvd3MgaW4gdGhlIHVwc3RyZWFtIChmcm9tIHRoZSBjdXN0b21lcikg ZGlyZWN0aW9uLiAgVGhpcyBvdmVyd3JpdGUgaXMgZG9uZSBhdCB0aGUgaGVhZGVuZCAoQ01UUykg YmVmb3JlIHRoZSBwYWNrZXRzIGFyZSBmb3J3YXJkZWQgdG8gdGhlIG9wZXJhdG9yJ3MgbWFuYWdl ZCBJUCBtZXRyby9hZ2dyZWdhdGlvbiBuZXR3b3JrLiAgVGhlIFRPUyBvdmVyd3JpdGUgZnVuY3Rp b25hbGl0eSB1c2VzIHR3byBwYXJhbWV0ZXJzOiB0b3MtYW5kLW1hc2sgYW5kIHRvcy1vci1tYXNr LiAgVGhlIFRPUyBvY3RldCBpbiBhcHBsaWNhYmxlIHBhY2tldHMgaXMgb3ZlcndyaXR0ZW4gd2l0 aCB0aGUgdmFsdWUgKG9yaWctaXAtdG9zIEFORCB0b3MtYW5kLW1hc2spIE9SIHRvcy1vci1tYXNr LiBXaXRoIHByb3BlciBjaG9pY2Ugb2YgdGhlc2UgdHdvIHBhcmFtZXRlcnMgKGluIHBhcnRpY3Vs YXIsIHRvcy1hbmQtbWFzaz0weDAzLCB0b3Mtb3ItbWFzaz1EU0NQPDwyKSwgdGhlIG9wZXJhdG9y IGNhbiBzZXQgdGhlIERTQ1AgZm9yIHBhcnRpY3VsYXIgcGFja2V0IGZsb3dzIGluIG9yZGVyIHRv IHByb3ZpZGUgUEhCcyBpbiB0aGVpciBtZXRyby9hZ2dyZWdhdGlvbiBuZXR3b3JrLCB3aXRob3V0 IGFmZmVjdGluZyB0aGUgRUNOIGJpdHMuICBCZWNhdXNlIHRoZSBlbnRpcmUgVE9TIG9jdGV0IGNh biBiZSBvdmVyd3JpdHRlbiwgdGhlcmUgaXMgdGhlIHBvdGVudGlhbCBob3dldmVyIHRoYXQgYW4g b3BlcmF0b3IgY291bGQgY29uZmlndXJlIHRoZWlyIG5ldHdvcmsgdG8gb3ZlcndyaXRlIHRoZSBF Q04gYml0cyBvbiBwYWNrZXRzIGV2ZW50dWFsbHkgZGVzdGluZWQgZm9yIHRoZSBiYWNrYm9uZS4g IFRoaXMgY2xlYXJseSBzaG91bGQgYmUgYXZvaWRlZC4gIFRoZSBmb2xsb3dpbmcgdHdvIHJlYWQt b25seSBvYmplY3RzIHJlZmxlY3QgdGhlIGNvbmZpZ3VyZWQgc2V0dGluZ3MgZm9yIHRoaXMgZnVu Y3Rpb25hbGl0eToNCiAgICBkb2NzUW9zUGFyYW1TZXRUb3NBbmRNYXNrICAgICAgICANCiAgICBk b2NzUW9zUGFyYW1TZXRUb3NPck1hc2sgICAgICAgICAgDQoNCg0KU2luY2UgdGhlc2Ugb2JqZWN0 cyBhcmUgcmVhZC1vbmx5IGFuZCByZWZsZWN0IHNldHRpbmdzIHRoYXQgYXJlIGNvbmZpZ3VyZWQg dmlhIGEgc3RhbmRhcmRpemVkIChJVFUtVCBSZWMuIEouMTEyLUIsIElUVS1UIFJlYy4gSi4xMjIp LCB3aWRlbHkgaW1wbGVtZW50ZWQsIGFuZCB3aWRlbHkgZGVwbG95ZWQgcHJvdG9jb2wsIGNoYW5n ZXMgdG8gdGhlIHVuZGVybHlpbmcgcHJvdG9jb2wgd291bGQgYmUgcmVxdWlyZWQgaW4gb3JkZXIg dG8gY29tcGxldGVseSBlbGltaW5hdGUgdGhlIHBvc3NpYmlsaXR5IG9mIG92ZXJ3cml0aW5nIEVD Ti4gIFdlIHdpbGwgZW5zdXJlIHRoYXQgZnV0dXJlIHZlcnNpb25zIG9mIHRoZSBwcm90b2NvbCBk byBub3QgcHJvcGFnYXRlIHRoaXMgYmVoYXZpb3IuICBGb3IgdGhlIHBhc3QgYW5kIGN1cnJlbnQg dmVyc2lvbnMgKGZvciB3aGljaCB0aGlzIE1JQiB3YXMgZGV2ZWxvcGVkKSwgd2Ugc3VnZ2VzdCB0 aGF0IGFkZGl0aW9uYWwgdGV4dCBiZSBhZGRlZCB0byBET0NTSVMgUW9TIE1JQiBSRkMgdG8gaW5k aWNhdGUgdGhhdCB0aGUgVE9TIE92ZXJ3cml0ZSBmdW5jdGlvbmFsaXR5IHNob3VsZCBub3QgYmUg Y29uZmlndXJlZCBpbiBzdWNoIGEgd2F5IHRoYXQgaXQgbGVhZHMgdG8gbW9kaWZpY2F0aW9uIG9m IHRoZSBFQ04gZmllbGQuDQoNCkluIHBhcnRpY3VsYXIsIHdlIHN1Z2dlc3QgdGhhdCB0aGUgZm9s bG93aW5nIGNoYW5nZXMgYmUgbWFkZSB0byBhZGRyZXNzIHRoZXNlIGNvbmNlcm5zOg0KDQojI0No YW5nZSAxIyMNCg0KQ3VycmVudCB0ZXh0Og0KPT09PT09PT09PT09PQ0KNC4gIERPQ1NJUyBhbmQg SVB2NCBUeXBlLW9mLVNlcnZpY2UoVG9TKSBGaWVsZA0KDQogICBUaGUgRE9DU0lTLUlFVEYtUU9T LU1JQiBkb2VzIHJlZmxlY3QgRGlmZmVyZW50ZWQgU2VydmljZXMgQ29kZSBQb2ludA0KICAgKERT Q1ApIFsxM10sIGluc3RlYWQgaXQgdXNlIG9iamVjdHMgdGhhdCByZWZsZWN0IElQdjQgVHlwZS1v Zi1TZXJ2aWNlDQogICAoVG9TKSBmaWVsZHMuIFRoZSBET0NTSVMgc3BlY2lmaWNhdGlvbiBkb2Vz IG5vdCBzdXBwb3J0IERpZmZlcmVudGVkDQogICBTZXJ2aWNlcyBhdCB0aGlzIHRpbWUgYmVjYXVz ZSBET0NTSVMgcmVsaWVzIG9uIG1hc2tpbmcgb2YgdGhlIElQIFRvUw0KICAgYml0cy4gTWFza2lu ZyBpcyBub3QgYWxsb3dlZCBpbiBEaWZmZXJlbnRlZCBTZXJ2aWNlcyBiZWNhdXNlIG9mDQogICBj b2Nlcm4gdGhlIDIgYml0IHRoYXQgbWFrZSB1cCB0aGUgIkV4cGxpY2l0IENvbmdlc3Rpb24gTm90 aWZpY2F0aW9uDQogICAoRUNOKSIgZmllbGQgWzE0XSBjb3VsZCBiZSBvdmVyd3JpdHRlbiBpZiB0 aGUgbWFzayBjb25zaXN0ZWQgb2YgOA0KICAgYml0cy4NCg0KU3VnZ2VzdGVkIHRleHQ6DQo9PT09 PT09PT09PT09PT0NCjQuICBET0NTSVMgYW5kIElQdjQgVHlwZS1vZi1TZXJ2aWNlKFRvUykgRmll bGQNCg0KICAgVGhlIERPQ1NJUy1JRVRGLVFPUy1NSUIgTUlCIG1vZHVsZSByZWxpZXMgb24gdGhl IERPQ1NJUyBNQUMgbGF5ZXIgDQogICBwcm90b2NvbHMgYW5kIHVzZXMgb2JqZWN0cyB0aGF0IHJl ZmxlY3QgdGhlIElQdjQgVHlwZS1vZi1TZXJ2aWNlIChUb1MpIA0KICAgb2N0ZXQgYXMgZGVmaW5l ZCBpbiBSRkM3OTEuIFRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZXNlIG9iamVjdHMgaXMgDQogICBs aW1pdGVkIHRvIHRoZSBET0NTSVMgYWNjZXNzIG5ldHdvcmsuIFRoZSBwYXN0IGFuZCBjdXJyZW50 IHZlcnNpb25zIG9mIA0KICAgdGhlIERPQ1NJUyBzcGVjaWZpY2F0aW9ucyBmb3Igd2hpY2ggdGhp cyBNSUIgbW9kdWxlIGlzIGRlZmluZWQgZG8gbm90IA0KICAgcmVmbGVjdCBEaWZmZXJlbnRpYXRl ZCBTZXJ2aWNlcyBbMTNdIG9uIHRoZSBET0NTSVMgYWNjZXNzIG5ldHdvcmsuICANCiAgIEhvd2V2 ZXIsIHdpdGggcHJvcGVyIHNlbGVjdGlvbiBvZiB2YWx1ZXMgZm9yIHRoZXNlIG9iamVjdHMsIHRo ZSANCiAgIG5ldHdvcmsgb3BlcmF0b3IgY2FuIGVuZm9yY2UgRGlmZmVyZW50aWF0ZWQgU2Vydmlj ZXMgUGVyLWhvcCBCZWhhdmlvcnMgDQogICAoUEhCcykgb24gdGhlIERPQ1NJUyBBY2Nlc3MgTmV0 d29yaywgYW5kIGNhbiBjb25maWd1cmUgdGhlIA0KICAgbW9kaWZpY2F0aW9uIG9mIHRoZSBEU0NQ IGZvciBjZXJ0YWluIHBhY2tldCBmbG93cyBhcyB0aGV5IGVudGVyIHRoZSANCiAgIG1ldHJvIG5l dHdvcmsgZnJvbSB0aGUgYWNjZXNzIG5ldHdvcmssIGVzc2VudGlhbGx5IG1ha2luZyB0aGUgRE9D U0lTIA0KICAgYWNjZXNzIG5ldHdvcmsgVE9TIG1hcmtpbmcgY29tcGF0aWJsZSB3aXRoIHRoZSB3 aWRlciB1c2Ugb2YgRFNDUCANCiAgIG91dHNpZGUgRE9DU0lTIG5ldHdvcmtzLiAgSXQgc2hvdWxk IGJlIG5vdGVkIHRoYXQgYmVjYXVzZSB0aGUgZW50aXJlIA0KICAgSVB2NCBUT1Mgb2N0ZXQgaXMg YXZhaWxhYmxlIGZvciBtb2RpZmljYXRpb24gdmlhIHRoZSBsYXR0ZXIgbWVjaGFuaXNtIA0KICAg KGR1ZSB0byB0aGUgY3VycmVudCBNQUMgbGV2ZWwgRE9DU0lTIHByb3RvY29scyksIHRoZXJlIGlz IHRoZSANCiAgIHBvc3NpYmlsaXR5IHRoYXQgdGhlIERPQ1NJUyBuZXR3b3JrIGNvdWxkIGJlIGNv bmZpZ3VyZWQgdG8gbW9kaWZ5IHRoZSANCiAgIEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0 aW9uIChFQ04pIGZpZWxkIFsxNF0gb2YgY2VydGFpbiBwYWNrZXRzLiAgDQogICBUaGlzIG11c3Qg Y2xlYXJseSBiZSBhdm9pZGVkIGFuZCBhbiBhdHRlbXB0IGhhcyBiZWVuIG1hZGUgaW4gdGhpcyAN CiAgIGRvY3VtZW50IHRvIG91dGxpbmUgdGhpcyBsaW1pdGF0aW9uIG9mIERPQ1NJUy4NCg0KDQoN CiMjQ2hhbmdlIDIjIw0KDQpDdXJyZW50IFRleHQ6DQo9PT09PT09PT09PT09DQpkb2NzUW9zUGFy YW1TZXRUb3NBbmRNYXNrIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgICAgIE9DVEVUIFNU UklORyAoU0laRSgxKSkNCiAgICBNQVgtQUNDRVNTICAgICAgcmVhZC1vbmx5DQogICAgU1RBVFVT ICAgICAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTiAgICAiU3BlY2lmaWVzIHRoZSBBTkQg bWFzayBmb3IgSVAgVE9TIGJ5dGUgZm9yDQogICAgICAgICAgICAgICAgICAgIG92ZXJ3cml0aW5n IElQIHBhY2tldHMgVE9TIHZhbHVlLiBUaGUgSVAgcGFja2V0cyBUT1MNCiAgICAgICAgICAgICAg ICAgICAgYnl0ZSBpcyBiaXR3aXNlIEFORGVkIHdpdGggZG9jc1Fvc1BhcmFtU2V0VG9zQW5kTWFz aw0KICAgICAgICAgICAgICAgICAgICBhbmQgcmVzdWx0IGlzIGJpdHdpc2UgT1JlZCB3aXRoDQog ICAgICAgICAgICAgICAgICAgIGRvY3NRb3NQYXJhbVNldFRvc09STWFzayBhbmQgcmVzdWx0IGlz IHdyaXR0ZW4gdG8gSVANCiAgICAgICAgICAgICAgICAgICAgcGFja2V0IFRPUyBieXRlLg0KICAg ICAgICAgICAgICAgICAgICBBIHZhbHVlIG9mICdGRidIIGZvciBkb2NzUW9zUGFyYW1TZXRUb3NB bmRNYXNrIGFuZA0KICAgICAgICAgICAgICAgICAgICBhIHZhbHVlIG9mICcwMCdIIGZvciBkb2Nz UW9zUGFyYW1TZXRUb3NPck1hc2sgbWVhbnMNCiAgICAgICAgICAgICAgICAgICAgdGhhdCBJUCBQ YWNrZXQgVE9TIGJ5dGUgaXMgbm90IG92ZXJ3cml0dGVuLg0KDQogICAgICAgICAgICAgICAgICAg IFRoaXMgY29tYmluYXRpb24gaXMgcmVwb3J0ZWQgaWYgdGhlIHJlZmVyZW5jZWQNCiAgICAgICAg ICAgICAgICAgICAgcGFyYW1ldGVyIGlzIG5vdCBwcmVzZW50IGluIGEgUU9TIFBhcmFtZXRlciBT ZXQuDQoNCiAgICAgICAgICAgICAgICAgICAgRXZlbiB0aG91Z2ggdGhlIHRoaXMgb2JqZWN0IGlz IG9ubHkgZW5mb3JjZWQgYnkgdGhlDQogICAgICAgICAgICAgICAgICAgIENhYmxlIE1vZGVtIFRl cm1pbmF0aW9uIFN5c3RlbSAoQ01UUyksDQogICAgICAgICAgICAgICAgICAgIENhYmxlIE1vZGVt cyBtdXN0IHJlcG9ydCB0aGUgdmFsdWUgYXMgc2lnbmFsZWQgaW4NCiAgICAgICAgICAgICAgICAg ICAgdGhlIHJlZmVyZW5jZWQgcGFyYW1ldGVyLiINCiAgICBSRUZFUkVOQ0UgICAgICAiU1AtUkZJ djEuMS1JMTAtMDM3MDMwLCBBcHBlbmRpeCBDLjIuMi42LjEwIg0KICAgIDo6PSB7IGRvY3NRb3NQ YXJhbVNldEVudHJ5IDIxIH0NCg0KDQpTdWdnZXN0ZWQgVGV4dDoNCj09PT09PT09PT09PT0NCmRv Y3NRb3NQYXJhbVNldFRvc0FuZE1hc2sgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICAgICAg T0NURVQgU1RSSU5HIChTSVpFKDEpKQ0KICAgIE1BWC1BQ0NFU1MgICAgICByZWFkLW9ubHkNCiAg ICBTVEFUVVMgICAgICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9OICAgICJTcGVjaWZpZXMg dGhlIEFORCBtYXNrIGZvciBJUCBUT1MgYnl0ZSBmb3INCiAgICAgICAgICAgICAgICAgICAgb3Zl cndyaXRpbmcgSVAgcGFja2V0cyBUT1MgdmFsdWUuIFRoZSBJUCBwYWNrZXRzIFRPUw0KICAgICAg ICAgICAgICAgICAgICBieXRlIGlzIGJpdHdpc2UgQU5EZWQgd2l0aCBkb2NzUW9zUGFyYW1TZXRU b3NBbmRNYXNrDQogICAgICAgICAgICAgICAgICAgIGFuZCByZXN1bHQgaXMgYml0d2lzZSBPUmVk IHdpdGgNCiAgICAgICAgICAgICAgICAgICAgZG9jc1Fvc1BhcmFtU2V0VG9zT1JNYXNrIGFuZCBy ZXN1bHQgaXMgd3JpdHRlbiB0byBJUA0KICAgICAgICAgICAgICAgICAgICBwYWNrZXQgVE9TIGJ5 dGUuDQogICAgICAgICAgICAgICAgICAgIEEgdmFsdWUgb2YgJ0ZGJ0ggZm9yIGRvY3NRb3NQYXJh bVNldFRvc0FuZE1hc2sgYW5kDQogICAgICAgICAgICAgICAgICAgIGEgdmFsdWUgb2YgJzAwJ0gg Zm9yIGRvY3NRb3NQYXJhbVNldFRvc09yTWFzayBtZWFucw0KICAgICAgICAgICAgICAgICAgICB0 aGF0IElQIFBhY2tldCBUT1MgYnl0ZSBpcyBub3Qgb3ZlcndyaXR0ZW4uDQoNCiAgICAgICAgICAg ICAgICAgICAgVGhpcyBjb21iaW5hdGlvbiBpcyByZXBvcnRlZCBpZiB0aGUgcmVmZXJlbmNlZA0K ICAgICAgICAgICAgICAgICAgICBwYXJhbWV0ZXIgaXMgbm90IHByZXNlbnQgaW4gYSBRT1MgUGFy YW1ldGVyIFNldC4NCg0KICAgICAgICAgICAgICAgICAgICBUaGUgSVAgVE9TIG9jdGV0IGFzIG9y aWdpbmFsbHkgZGVmaW5lZCBpbiBSRkMgNzkxIGhhcw0KICAgICAgICAgICAgICAgICAgICBiZWVu IHN1cGVyc2VkZWQgYnkgdGhlIDYgYml0IERpZmZlcmVudGlhdGVkIFNlcnZpY2VzDQogICAgICAg ICAgICAgICAgICAgIEZpZWxkIChEU0ZpZWxkLCBSRkMgMzI2MCkgYW5kIHRoZSAyIGJpdCBFeHBs aWNpdA0KICAgICAgICAgICAgICAgICAgICBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiBGaWVsZCAo RUNOIGZpZWxkLCBSRkMgMzE2OCkuDQogICAgICAgICAgICAgICAgICAgIE5ldHdvcmsgb3BlcmF0 b3JzIHNob3VsZCBhdm9pZCBzcGVjaWZ5aW5nIHZhbHVlcyBvZiANCiAgICAgICAgICAgICAgICAg ICAgZG9jc1Fvc1BhcmFtU2V0VG9zQW5kTWFzayBhbmQgZG9jc1Fvc1BhcmFtU2V0VG9zT1JNYXNr IA0KICAgICAgICAgICAgICAgICAgICB3aGljaCB3b3VsZCByZXN1bHQgaW4gdGhlIG1vZGlmaWNh dGlvbiBvZiB0aGUgRUNOIA0KICAgICAgICAgICAgICAgICAgICBiaXRzLg0KDQogICAgICAgICAg ICAgICAgICAgIEluIHBhcnRpY3VsYXIsIG9wZXJhdG9ycyBzaG91bGQgbm90IHVzZSB2YWx1ZXMg b2YgDQogICAgICAgICAgICAgICAgICAgIGRvY3NRb3NQYXJhbVNldFRvc0FuZE1hc2sgd2hpY2gg aGF2ZSBlaXRoZXIgb2YgdGhlIA0KICAgICAgICAgICAgICAgICAgICBsZWFzdC1zaWduaWZpY2Fu dCB0d28gYml0cyBzZXQgdG8gMC4gIFNpbWlsYXJseSwgDQogICAgICAgICAgICAgICAgICAgIG9w ZXJhdG9ycyBzaG91bGQgbm90IHVzZSB2YWx1ZXMgb2YgDQogICAgICAgICAgICAgICAgICAgIGRv Y3NRb3NQYXJhbVNldFRvc09STWFzayB3aGljaCBoYXZlIGVpdGhlciBvZiB0aGUgDQogICAgICAg ICAgICAgICAgICAgIGxlYXN0LXNpZ25pZmljYW50IHR3byBiaXRzIHNldCB0byAxLiANCg0KICAg ICAgICAgICAgICAgICAgICBFdmVuIHRob3VnaCB0aGUgdGhpcyBvYmplY3QgaXMgb25seSBlbmZv cmNlZCBieSB0aGUNCiAgICAgICAgICAgICAgICAgICAgQ2FibGUgTW9kZW0gVGVybWluYXRpb24g U3lzdGVtIChDTVRTKSwNCiAgICAgICAgICAgICAgICAgICAgQ2FibGUgTW9kZW1zIG11c3QgcmVw b3J0IHRoZSB2YWx1ZSBhcyBzaWduYWxlZCBpbg0KICAgICAgICAgICAgICAgICAgICB0aGUgcmVm ZXJlbmNlZCBwYXJhbWV0ZXIuIg0KICAgIFJFRkVSRU5DRSAgICAgICJTUC1SRkl2MS4xLUkxMC0w MzcwMzAsIEFwcGVuZGl4IEMuMi4yLjYuMTA7DQogICAgICAgICAgICAgICAgICAgIFJGQyAzMTY4 LCBUaGUgQWRkaXRpb24gb2YgRXhwbGljaXQgQ29uZ2VzdGlvbiANCiAgICAgICAgICAgICAgICAg ICAgTm90aWZpY2F0aW9uIChFQ04pIHRvIElQOw0KICAgICAgICAgICAgICAgICAgICBSRkMgMzI2 MCwgTmV3IFRlcm1pbm9sb2d5IGFuZCBDbGFyaWZpY2F0aW9ucyBmb3INCiAgICAgICAgICAgICAg ICAgICAgRGlmZnNlcnYuIg0KICAgIDo6PSB7IGRvY3NRb3NQYXJhbVNldEVudHJ5IDIxIH0NCg0K DQoNCg0K ------_=_NextPart_001_01C3B07E.3DAC8ED1-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Sun Nov 23 07:25:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19891 for ; Sun, 23 Nov 2003 07:25:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANtIZ-0002WS-MK for ipcdn-archive@odin.ietf.org; Sun, 23 Nov 2003 07:25:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hANCP7t6009696 for ipcdn-archive@odin.ietf.org; Sun, 23 Nov 2003 07:25:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANtIU-0002Vl-Uc; Sun, 23 Nov 2003 07:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANtHi-0002VF-Nv for ipcdn@optimus.ietf.org; Sun, 23 Nov 2003 07:24:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19866 for ; Sun, 23 Nov 2003 07:24:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANtHi-0002NV-00 for ipcdn@ietf.org; Sun, 23 Nov 2003 07:24:14 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ANtHh-0002ND-00 for ipcdn@ietf.org; Sun, 23 Nov 2003 07:24:13 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hANCNbh24705 for ; Sun, 23 Nov 2003 06:23:38 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Sun, 23 Nov 2003 13:23:35 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502FB85AB@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Jean-Francois Mule , Bert Cc: ipcdn@ietf.org, "Richard Woundy @ Comcast" , Greg White , Murwin William-LWM008 , Patrick Michael-LZZ007 , Eduardo Cardona , Matthew Schmitt Date: Sun, 23 Nov 2003 13:23:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: [ipcdn] RE: ipcdn DOCSIS QoS mib and closure on IP TOS vs. DSCP open issu e Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Thanks for the follow up. I am checking myself, and I am also checking with other IESG members to see if this would make the doc pass when it comes to IESG. Hope to have an answer before Thanksgiving Thanks, Bert > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: vrijdag 21 november 2003 23:25 > To: Bert > Cc: ipcdn@ietf.org; Richard Woundy @ Comcast; Jean-Francois Mule; Greg > White; Murwin William-LWM008; Patrick Michael-LZZ007; Eduardo Cardona; > Matthew Schmitt > Subject: ipcdn DOCSIS QoS mib and closure on IP TOS vs. DSCP > open issue > > > Bert, > > At the last IETF meeting, you asked that we provide a short > write-up to > close the one open issue on the IPCDN DOCSIS QoS MIB draft09. > Greg White > has put together the attached note integrating thoughts & > comments from > the IPCDN QoS MIB co-authors - William Murwin & Patrick Michael, Matt > Schmitt, Rich and myself (thank you Greg). > > I believe this write-up answers your request. > It provides: > - the list of MIB objects using TOS value in the QoS mib > object name, the max-access (read-only), what the object is for and > whether it is used in the DOCSIS network only (between CM - CMTS) or > whether it would potentially get propagated in the backbone (to > understand whether this could break the PHB behavior in the backbone), > - the range of TOS values these objects can have and how the mapping > with the six bits of DSCP can be achieved, > - the justification to maintain TOS based on past & current DOCSIS > systems along with the limited applicability scope. > > Let us know what the next steps are to advance the IPCDN QoS MIB. Upon > your review & recommendations, it is our intent to release an updated > draft10 which will be ready for publication. > > Thanks, > Rich & Jean-Francois - ipcdn wg co-chairs > ------------------------ > To: Bert Wijnen , Area Director, IETF OPS Area > From: IPCDN WG Chairs: Richard Woundy > , > Jean-Francois Mule > CC: ipcdn@ietf.org > > RE: ipcdn DOCSIS QoS mib and closure on IP TOS vs. DSCP open issue > > The DOCSIS QoS MIB (draft-ietf-ipcdn-qos-mib-09) contains > five objects which > use the (former) IPv4 TOS octet as defined in RFC 791. All > are read-only > objects which are used to instrument settings that have been > configured > via a DOCSIS-defined protocol mechanism (configuration file > transfer and/or > MAC-layer management message exchange). > > The five objects are used for two different functionalities > within the > DOCSIS access network. > > The first functionality is packet classification to provide > Quality of > Service on the DOCSIS access network. The DOCSIS protocol includes > messaging to configure packet classification that can match packets > based on (among other things) the contents of the TOS octet of the > IPv4 header. This IP Type-of-Service classifier configuration uses > three parameters: tos-low, tos-high, and tos-mask. Packets match the > classifier if their "ip-tos" byte meets the criteria: > tos-low <= (ip-tos AND tos-mask) <= tos-high. > With proper choices of the three parameters (in particular, > tos-mask=0xFC, tos-low=tos-high=DSCP<<2), this functionality could > be used to enable a DiffServ-capable access network. Because this > functionality is only used to provide QoS on the DOCSIS > access network, > and does not modify the contents of the IPv4 datagram, this does not > break any usage of DiffServ or ECN on the backbone. The following > three read-only objects reflect the configured settings for this > functionality: > docsQosPktClassIpTosLow > docsQosPktClassIpTosHigh > docsQosPktClassIpTosMask > > > The second functionality is TOS Overwrite. The DOCSIS > protocol includes > messaging to configure the overwrite of the IPv4 TOS octet > for certain > packet flows in the upstream (from the customer) direction. This > overwrite is done at the headend (CMTS) before the packets > are forwarded > to the operator's managed IP metro/aggregation network. The TOS > overwrite functionality uses two parameters: tos-and-mask and > tos-or-mask. > The TOS octet in applicable packets is overwritten with the value > (orig-ip-tos AND tos-and-mask) OR tos-or-mask. With proper choice of > these two parameters (in particular, tos-and-mask=0x03, > tos-or-mask=DSCP<<2), > the operator can set the DSCP for particular packet flows in > order to provide > PHBs in their metro/aggregation network, without affecting > the ECN bits. > Because the entire TOS octet can be overwritten, there is the > potential > however that an operator could configure their network to > overwrite the > ECN bits on packets eventually destined for the backbone. > This clearly > should be avoided. The following two read-only objects reflect the > configured settings for this functionality: > docsQosParamSetTosAndMask > docsQosParamSetTosOrMask > > > Since these objects are read-only and reflect settings that > are configured via > a standardized (ITU-T Rec. J.112-B, ITU-T Rec. J.122), widely > implemented, and > widely deployed protocol, changes to the underlying protocol > would be required > in order to completely eliminate the possibility of > overwriting ECN. We will > ensure that future versions of the protocol do not propagate > this behavior. > For the past and current versions (for which this MIB was > developed), we > suggest that additional text be added to DOCSIS QoS MIB RFC > to indicate that > the TOS Overwrite functionality should not be configured in > such a way that > it leads to modification of the ECN field. > > In particular, we suggest that the following changes be made > to address > these concerns: > > ##Change 1## > > Current text: > ============= > 4. DOCSIS and IPv4 Type-of-Service(ToS) Field > > The DOCSIS-IETF-QOS-MIB does reflect Differented Services > Code Point > (DSCP) [13], instead it use objects that reflect IPv4 > Type-of-Service > (ToS) fields. The DOCSIS specification does not support Differented > Services at this time because DOCSIS relies on masking of > the IP ToS > bits. Masking is not allowed in Differented Services because of > cocern the 2 bit that make up the "Explicit Congestion Notification > (ECN)" field [14] could be overwritten if the mask consisted of 8 > bits. > > Suggested text: > =============== > 4. DOCSIS and IPv4 Type-of-Service(ToS) Field > > The DOCSIS-IETF-QOS-MIB MIB module relies on the DOCSIS MAC layer > protocols and uses objects that reflect the IPv4 > Type-of-Service (ToS) > octet as defined in RFC791. The applicability of these objects is > limited to the DOCSIS access network. The past and current > versions of > the DOCSIS specifications for which this MIB module is > defined do not > reflect Differentiated Services [13] on the DOCSIS access > network. > However, with proper selection of values for these objects, the > network operator can enforce Differentiated Services > Per-hop Behaviors > (PHBs) on the DOCSIS Access Network, and can configure the > modification of the DSCP for certain packet flows as they > enter the > metro network from the access network, essentially making > the DOCSIS > access network TOS marking compatible with the wider use of DSCP > outside DOCSIS networks. It should be noted that because > the entire > IPv4 TOS octet is available for modification via the > latter mechanism > (due to the current MAC level DOCSIS protocols), there is the > possibility that the DOCSIS network could be configured to > modify the > Explicit Congestion Notification (ECN) field [14] of > certain packets. > This must clearly be avoided and an attempt has been made in this > document to outline this limitation of DOCSIS. > > > > ##Change 2## > > Current Text: > ============= > docsQosParamSetTosAndMask OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(1)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION "Specifies the AND mask for IP TOS byte for > overwriting IP packets TOS value. The IP > packets TOS > byte is bitwise ANDed with > docsQosParamSetTosAndMask > and result is bitwise ORed with > docsQosParamSetTosORMask and result is > written to IP > packet TOS byte. > A value of 'FF'H for docsQosParamSetTosAndMask and > a value of '00'H for > docsQosParamSetTosOrMask means > that IP Packet TOS byte is not overwritten. > > This combination is reported if the referenced > parameter is not present in a QOS Parameter Set. > > Even though the this object is only > enforced by the > Cable Modem Termination System (CMTS), > Cable Modems must report the value as signaled in > the referenced parameter." > REFERENCE "SP-RFIv1.1-I10-037030, Appendix C.2.2.6.10" > ::= { docsQosParamSetEntry 21 } > > > Suggested Text: > ============= > docsQosParamSetTosAndMask OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(1)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION "Specifies the AND mask for IP TOS byte for > overwriting IP packets TOS value. The IP > packets TOS > byte is bitwise ANDed with > docsQosParamSetTosAndMask > and result is bitwise ORed with > docsQosParamSetTosORMask and result is > written to IP > packet TOS byte. > A value of 'FF'H for docsQosParamSetTosAndMask and > a value of '00'H for > docsQosParamSetTosOrMask means > that IP Packet TOS byte is not overwritten. > > This combination is reported if the referenced > parameter is not present in a QOS Parameter Set. > > The IP TOS octet as originally defined in > RFC 791 has > been superseded by the 6 bit > Differentiated Services > Field (DSField, RFC 3260) and the 2 bit Explicit > Congestion Notification Field (ECN field, > RFC 3168). > Network operators should avoid specifying > values of > docsQosParamSetTosAndMask and > docsQosParamSetTosORMask > which would result in the modification of the ECN > bits. > > In particular, operators should not use values of > docsQosParamSetTosAndMask which have > either of the > least-significant two bits set to 0. Similarly, > operators should not use values of > docsQosParamSetTosORMask which have either of the > least-significant two bits set to 1. > > Even though the this object is only > enforced by the > Cable Modem Termination System (CMTS), > Cable Modems must report the value as signaled in > the referenced parameter." > REFERENCE "SP-RFIv1.1-I10-037030, Appendix C.2.2.6.10; > RFC 3168, The Addition of Explicit Congestion > Notification (ECN) to IP; > RFC 3260, New Terminology and Clarifications for > Diffserv." > ::= { docsQosParamSetEntry 21 } > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Sun Nov 23 17:51:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02629 for ; Sun, 23 Nov 2003 17:51:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO34I-0006ls-2G for ipcdn-archive@odin.ietf.org; Sun, 23 Nov 2003 17:51:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hANMp2Kb026024 for ipcdn-archive@odin.ietf.org; Sun, 23 Nov 2003 17:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO34G-0006lW-Sd; Sun, 23 Nov 2003 17:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO33O-0006ky-DP for ipcdn@optimus.ietf.org; Sun, 23 Nov 2003 17:50:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02609 for ; Sun, 23 Nov 2003 17:49:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO33L-0000j6-00 for ipcdn@ietf.org; Sun, 23 Nov 2003 17:50:03 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AO33K-0000ir-00 for ipcdn@ietf.org; Sun, 23 Nov 2003 17:50:03 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hANMnSoK024012; Sun, 23 Nov 2003 15:49:29 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 23 Nov 2003 15:49:28 -0700 Message-ID: Thread-Topic: RFI v2 MIB Draft 08 Thread-Index: AcOx5thN+QKh/GZbTU64LlEqFDaFjQAK2xwQ From: "Eduardo Cardona" To: "Pollak, Lucy" , "Ipcdn (E-mail)" Cc: "Richard Woundy @ Comcast" , "Jean-Francois Mule" , "DOCSIS OSS Majordomo List" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: RFI v2 MIB Draft 08 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thanks Lucy for the comments,=20 Hence you agree with Jason, wouldn't be the case of that text you proposed well explained in overal inf RFC 2863 which is normative for RFI MIB module?=20 particularly =20 3.1.2. Guidance on Defining Sub-layers 3.1.13. IfAdminStatus and IfOperStatus 3.1.14. IfOperStatus in an Interface Stack The text was in particular for upstream channel but would that be applicable also for the CATV MAC interface,=20 Since a CMTS contains other interfaces not associated with DOCSIS interface, I would prefer leave all the requirements in RFC 2863 Let me know if I am missing something, Thanks Eduardo -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com]=20 Sent: Sunday, November 23, 2003 10:26 AM To: Eduardo Cardona; Ipcdn (E-mail) Cc: Richard Woundy @ Comcast; Jean-Francois Mule; DOCSIS OSS Majordomo List Subject: RE: RFI v2 MIB Draft 08=20 Eduardo and Jason. Sorry for so late answer. I guess, the text your mentioned should not be removed, but modified. Let me return to Jason's example. I guess, the problem here is the mistake, which always is done for Admin and Oper status. Admin status is a command, which should be reflected in Oper status of lower layers, but should not change the Admin status of lower layers (in this point I agree with Jason). =20 (1) Initial state: interface ifAdminStatus ifOperStatus docsCableUpstream US 1 up up docsCableUpstreamChannel 1 up up docsCableUpstreamChannel 2 up down (not in use)=20 docsCableUpstreamChannel 2 up down (not in use)=20 docsCableUpstreamChannel 2 up down (not in use)=20 (2)Setting ifAdminStatus of US 1 to down results in this:=20 interface ifAdminStatus ifOperStatus docsCableUpstream US 1 down down docsCableUpstreamChannel 1 up down docsCableUpstreamChannel 2 up down docsCableUpstreamChannel 2 up down docsCableUpstreamChannel 2 up down (3)Setting ifAdminStatus of US 1 to up results in exactly (1). This is my understanding of MIB text: "The administrative status of this interface.=20 This reflect the total status of all the channels =20 under this interface. So if at least one channel=20 has a physical connection this interface has=20 connection. Any SNMP SET on this interface will=20 cause a SET to all the channels under this=20 interface." So, from my POV "This reflect the total status of all the channels =20 under this interface. So if at least one channel=20 has a physical connection this interface has=20 connection." is applicable for ifOperStatus, not ifAdminStatus.=20 The "Any SNMP SET on this interface will=20 cause a SET to all the channels under this=20 interface." should be rephrased: "Any SNMP SET on this interface will=20 influence the ifOperStatus of all the channels under this=20 interface." The implicit SNMP SET will cause very complex implementation of different lower-higher layer state superposition. But, I guess, that wording about status of lower layer influenced by ifAdminStatus of higher layer should be kept. Regards. Lucy -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] Sent: Tuesday, November 04, 2003 5:58 PM To: Ipcdn (E-mail) Cc: Richard Woundy; Jean-Francois Mule; DOCSIS OSS Majordomo List Subject: RFI v2 MIB Draft 08=20 Hi dear IPCD folks and OSSI reflector=20 =20 Few updates of the last posted Draft -08=20 =20 I am planning to do a quick update to the MIB draft after the IETF meeting to correct the below minor issues, Just a quick note, I will wait until the resolutions of the IETF IPCDN meeting to take actions on that. =20 =20 Jason Tessier, identified a description in the idAdminStatus in the draft that is not needed and does not reflect the needs for interface Stack based on =20 RFC 2863 to propagate ifAdminStatus top to bottom of the stack for and up/down transition. Only ifOperStatus is propagated because of ifAdminStatus changes or inherent interface changes. =20 Also for docsIfUpChannelUpdate related to the clone mechanism, all the related objects were updated to not being SCMA specific. One objects left out of the updates docsIfUpChannelUpdate. The proposed change will align that object description. =20 See at the end of the email the Jasson arguments for the ifAdminStatus change =20 Below are the proposed changes, let us know any changes. =20 Thanks =20 Eduardo =20 =20 =20 update to RFI Mib v2 with two changes: 1- ifAdminStatus requirements for UpChannels should read. 3.2.5.2. ifEntry for Upstream interfaces=20 ifAdminStatus The administrative status of this interface.=20 2- Re-define the requirement for docsIfUpChannelUpdate as below - All the associated objects for the Clone Mechanism are no longer=20 referencing exclusively to SCDMA. The intention now is normalize this=20 requirements for all type of profiles. - change GEN-ERROR for genError and COMMIT_FAILED_ERROR for=20 commitFailed docsIfUpChannelUpdate OBJECT-TYPE=20 SYNTAX TruthValue=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "Used to perform the transfer of adjusted SCDMA parameters=20 from the temporary upstream row to the active upstream row=20 indicated by the docsIfUpChannelCloneFrom object. The=20 transfer is initiated through an SNMP SET of TRUE to this=20 object. The SNMP SET will fail with a GEN_ERROR (snmpv1)=20 or COMMIT_FAILED_ERROR (snmpv2c/v3) if the adjusted=20 SCDMA parameter values are not compatible with each other.=20 Although this object was created to facilitate SCDMA=20 parameter adjustment, it may also be used at the vendor's=20 discretion for non-SCDMA parameter adjustment.=20 An SNMP GET of this object always returns FALSE."=20 ::=3D { docsIfUpstreamChannelEntry 17 }=20 to: docsIfUpChannelUpdate OBJECT-TYPE=20 SYNTAX TruthValue=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "Used to perform the transfer of adjusted parameters=20 from the temporary upstream row to the physical upstream row=20 indicated by the docsIfUpChannelCloneFrom object. The=20 transfer is initiated through an SNMP SET to 'true' of this object. The SNMP SET failure returns an error genError (snmpv1)=20 or commitFailed (snmpv2c/v3) if the adjusted parameter values are=20 not compatible with each other.=20 Reading this object always return 'false'."=20 ::=3D { docsIfUpstreamChannelEntry 17 }=20 --------------------------------=20 IfAdminStatus Jasson email -----Original Message----- From: Jason.Tessier@arrisi.com [mailto:Jason.Tessier@arrisi.com]=20 Sent: Wednesday, October 22, 2003 10:20 AM To: DOCSIS OSS Majordomo List Subject: ifAdminStatus sets to docsCableUpstream (129) Hello,=20 In the DOCS-IF-MIB there's a requirement that ifAdminStatus sets to a docsCableUpstream interface also be applied to the docsCableUpstreamChannel interfaces under it.=20 3.2.5.2.1. ifEntry for Upstream interfaces in Cable Modem Termination=20 Systems=20 =20 ifTable Comments=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 ifType The IANA value of docsCableUpstream (129).=20 =20 =20 ifAdminStatus The administrative status of this interface.=20 This reflect the total status of all the channels =20 under this interface. So if at least one channel=20 has a physical connection this interface has=20 connection. Any SNMP SET on this interface will cause a SET to all the channels under this=20 interface.=20 So in the case where there are multiple logical channels under one upstream interface, if you want to enable/disable the docsCableUpstream interface all of the logical channels associated with it are also set to up/down.=20 I think that this makes it difficult for the operator to set the ifAdminStatus of the docsCableUpstream interface without affecting several logical channels, some of which may not even have been enabled in the first place. If an operator sets the ifAdminStatus of the docsCableUpstream to down, the set will already be reflected in the ifOperStatus of the docsCableUpstreamChannels under it. The OperStatus of the docsCableUpstreamChannels will reflect their own state, taking into account the upper layer and modulation profiles, etc. I don't see a need for this requirement.=20 An example:=20 interface ifAdminStatus=20 docsCableUpstream US 1 down=20 docsCableUpstreamChannel 1 up =20 docsCableUpstreamChannel 2 down (not in use)=20 docsCableUpstreamChannel 2 down (not in use)=20 docsCableUpstreamChannel 2 down (not in use)=20 Setting ifAdminStatus of US 1 to up results in this:=20 interface ifAdminStatus=20 docsCableUpstream US 1 up=20 docsCableUpstreamChannel 1 up =20 docsCableUpstreamChannel 2 up=20 docsCableUpstreamChannel 3 up=20 docsCableUpstreamChannel 4 up=20 The effect is that with one set 4 ifAdminStatus are affected, and 3 channels are put into use that may not be desired. I'm thinking of proposing an ECR to remove this requirement from the MIB.=20 Thanks,=20 Jason Tessier QA Engineer ARRIS Communications Ireland Ltd. Jason.Tessier@arrisi.com +353-21-7305826=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Nov 24 08:24:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06986 for ; Mon, 24 Nov 2003 08:24:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGhR-0007Yo-78 for ipcdn-archive@odin.ietf.org; Mon, 24 Nov 2003 08:24:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAODOLoq029049 for ipcdn-archive@odin.ietf.org; Mon, 24 Nov 2003 08:24:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGhJ-0007W3-Or; Mon, 24 Nov 2003 08:24:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANSmx-0002Y7-Vz for ipcdn@optimus.ietf.org; Sat, 22 Nov 2003 03:06:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06315 for ; Sat, 22 Nov 2003 03:06:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANSmp-0001yF-00 for ipcdn@ietf.org; Sat, 22 Nov 2003 03:06:35 -0500 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1ANSmo-0001yC-00 for ipcdn@ietf.org; Sat, 22 Nov 2003 03:06:34 -0500 Received: from h-68-164-78-197.snvacaid.dynamic.covad.net ([68.164.78.197] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ANSmo-0002hD-00 for ipcdn@ietf.org; Sat, 22 Nov 2003 00:06:34 -0800 Message-ID: <000a01c3b0cf$ce0a3480$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Date: Sat, 22 Nov 2003 00:08:25 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv2-06.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - Here are my comments on draft-ietf-ipcdn-device-mibv2-06.txt I recognize that this is based on an earlier RFC and external specifications, thus some of the "shoulds" you may choose to ignore. First the more-or-less mechanical stuff: Abstract: the language about "draft revision" and "will obsolete" wouldn't be appropriate if this is to be published as an RFC. Should be replaced with words that will be true when it becomes an RFC. Intellectual Property: BCP-11 is missing from the references. Table of contents: - many of the page numbers are wrong - the section titles in the table of contents sometimes don't match the actual section titles. Items based on http://www.ietf.org/ietf/1id-guidelines.txt: - on first page, "Internet Draft" -> "INTERNET-DRAFT" Items based on http://www.ietf.org/ID-nits.html: - missing introduction? (ID-nits.html section 1.2) this seems to be in the overview. Items based on draft-rfc-editor-rfc2223bis-07.txt: - Title: the acronynm DOCSIS should be expanded (2223 bis 2.9) - Use two spaces after period at the end of a sentence. (2223 bis 3.1.7) - some References have "," before the "and", others don't. be consistent, using a "," before the "and", as in the references section of the guidelines. - not consistent in use of "RFCxxxx", "RFC-xxxx", and "RFC XXXX" - section 2.4: ITU-T J.112 is missing from the references - section 2.7: "MAC" not expanded on first use - section 2.7: "PDU" not expanded on first use - section 3: "SNMPv1", "SNMPv2c", "SNMPv3" not expanded on first use - section 3: spurious blank line before "requirements" - section 3: "CPE" not expanded on first use - section 3.1: "IGMP" not expanded on first use - section 3.2.1: "TFTP" not expanded on first use - section 3.2.1: "HTTP" not expanded on first use - section 3.2.2: no reference for "syslog" - section 3.3: "LLC" not expanded - section 3.3: "IPX" not expanded - section 3.3: "ICMP" not expanded - section 3.3.3: "ToS" not expanded - section 3.3.4: "QOS" not expanded - section 4: "DSCP" not expanded - section 4: "OIDs" not expanded - section 4: "VACM" not expanded - section 4: "NMS" not expanded - section 4: "DHCP" not expanded - section 4: "occurrance" -> "occurrence" - section 4: "CMCI" not expanded - section 4: "SNAP" not expanded - section 4: "DSAP" not expanded - section 4: "MCNS" not expanded - (section 5.1: "simplication" -> "simplification") - Table of contents and document in general: sections are not in order stipulated by rfc2223bis section 4. MIB Compilation note: smilint produces lots of warnings regarding the fact that several of the "current" compliance statements reference "deprecated" groups, but this is specifically permitted by the MIB review guidelines and RFC 2580, so I'll assume it's intentional. MIB Review Guidelines: ORGANIZATION clause MUST have full name of working group (IP over cable data network) All REVISION clauses should be updated to four-digit years. docsDevMaxCpe: a UNITS clause would be nice. docsDevNmAccessTable: should specify what the persistance properties of this information are. docsDevNmAccessInterfaces: DEFVAL should give the actual value, rather than just an ASN.1 comment. However, since this is deprecated and the DESCRIPTION would make the length implementation dependent, I won't insist on it. docsDevSwServerTransportProtocol: are there any constraints on when this can be set to TFTP? For example, if docsDevSwServerAddressType is DNS, must an implementation reject attempts to set this to TFTP? Can the other docsDevSw* objects be changed when docsDevSwOperStatus is "in progress"? docsDevServerBootState should explain what enumeration values 9 and 10 mean. docsDevServerDhcpAddressType: what value does this have if DHCP was not used? docsDevServerTimeAddressType: what value does this have when no time server is known? docsDevServerConfigTftpAddressType: value if unknown? docsDevServerConfigTftpAddress: security considerations should address consequences of using TFTP here. docsDevEvThrottleThreshold and related objects should address the question of just what notifications they apply to. If, for example, the system also implemented the Alarm MIB, the answer would be of more than academic interest. docsDevEvThrottleThreshold: a UNITS clause would be nice docsDevEvThrottleInterval: should be Unsigned32. docsDevEvControlTable: what is the lifecycle / persistance of entries in this table? docsDevEvReporting: the DESCRIPTION doesn't mesh with the notion of using RFC 3413 where it talks about sending an SNMP trap. This bit of text is ambiguous: An event reported by trap or syslog logging MUST be accompanied by localVolatile logging. If the bit value for either traps(1) or syslog(2) is set, then the agent MUST enforce that the bit value for local(0) or localVolatile(3) is set as well." Is the intent that the agent must reject attempts to do SETs that don't satisfy the criteria, or does this text mean that the agent must act as though the bits in the request had been set appropriately? docsDevEventTable: does stuff in this table persist across reboots? docsDevEvIndex should be Unisnged32. docsDevEvLastTime and docsDevEvFirstTime: do these get the same special values as docsDevDateTime? docsDevEvCounts should have UNITS. Purists might object to using a Counter type here. docsDevEvLevel should explain what each of the enumeration values means. docsDevFilterLLCTable should spell out lifecycle / persistence docsDevFilterLLCIndex should be Unsigned32 docsDevFilterLLCIfIndex: if rows in this table can persist across reboots, this object has persistence / consistency implications with the interfaces table and related objects. Intent should be spelled out here. docsDevFilterLLCProtocol should be Unsigned32. docsDevFilterLLCMatches should have UNITS. docsDevFilterIpTable: should spell out persistance / lifecycle docsDevFilterIpIndex: should be Unsigned32. docsDevFilterIpIfIndex: if this table can persist across reboots, this object has implications for either the satbility of ifIndex values or its own renumbering. docsDevFilterIpDaddr: it's not quite right to talk about a value of "0" for this object, since it's syntactically an OCTET STRING. docsDevFilterIpProtocol: should be Unsigned32. a REFERENCE clause to the appropriate IANA registry would be nice. docsDevFilterIpSourcePortLow , docsDevFilterIpSourcePortHigh, docsDevFilterIpDestPortLow, docsDevFilterIpDestPortHigh: should be Unsigned32. docsDevFilterIpMatches needs UNITS, and syntax should be ZeroBasedCounter32. docsDevFilterIpPolicyId: should be Unsigned32. docsDevFilterPolicyTable: should talk about lifecycle and persistance. docsDevFilterPolicyIndex should be Unsigned32 docsDevFilterPolicyId should be Unsigned32 docsDevFilterPolicyStatus use of the RowStatus TC requires spelling out what columns are permitted to be modified in an active row. docsDevFilterPolicyPtr: what happens when this points to a row which does not exist? docsDevFilterTosTable: lifecycle and persistence. docsDevFilterTosIndex: should be Unsigned32. docsDevCpeEnroll: what is meant by "manually"? docsDevCpeIpMax: may this object be set to a value larger than "the maximum permitted for this device"? If it weren't for that -1, I'd like to see UNITS. docsDevCpeTable: persistance and lifecycle docsDevCpeInetTable: persistance and lifecycle docsDevCpeInetAddr: these words should probably be tweaked to be a bit more protocol-neutral: " N.B. Neither the all zeros or all ones addresses may be used as values for this object." docsDevCpeInetSource: when is (1) used? Security Considerations fails to mention these read-write objects: docsDevDateTime docsDevSTPControl docsDevIgmpModeControl docsDevSwServer docsDevSwFilename docsDevSwAdminStatus docsDevSwServerAddressType docsDevSwServerAddress docsDevSwServerTransportProtocol docsDevEvControl docsDevEvSyslog docsDevEvThrottleThreshold docsDevEvThrottleInterval docsDevEvReporting docsDevEvSyslogAddressType docsDevEvSyslogAddress docsDevFilterLLCUnmatchedAction docsDevFilterIpDefault docsDevCpeEnroll docsDevCpeIpMax Security Considerations doesn specifically address these read-create objects, although it does talk about their tables in general terms: docsDevNmAccessIp docsDevNmAccessIpMask docsDevNmAccessCommunity docsDevNmAccessControl docsDevNmAccessInterfaces docsDevNmAccessStatus docsDevNmAccessTrapVersion docsDevFilterLLCStatus docsDevFilterLLCIfIndex docsDevFilterLLCProtocolType docsDevFilterLLCProtocol docsDevFilterIpStatus docsDevFilterIpControl docsDevFilterIpIfIndex docsDevFilterIpDirection docsDevFilterIpBroadcast docsDevFilterIpSaddr docsDevFilterIpSmask docsDevFilterIpDaddr docsDevFilterIpDmask docsDevFilterIpProtocol docsDevFilterIpSourcePortLow docsDevFilterIpSourcePortHigh docsDevFilterIpDestPortLow docsDevFilterIpDestPortHigh docsDevFilterIpTos docsDevFilterIpTosMask docsDevFilterIpContinue docsDevFilterIpPolicyId docsDevFilterPolicyId docsDevFilterPolicyType docsDevFilterPolicyAction docsDevFilterPolicyStatus docsDevFilterPolicyPtr docsDevFilterTosStatus docsDevFilterTosAndMask docsDevFilterTosOrMask docsDevCpeStatus docsDevCpeInetRowStatus docsDevFilterIpDirection docsDevFilterIpBroadcast The value assigned to docsDevNotification doesn't meet the requirements of the MIB review guidelines section 4.7: it needs to end in zero in order for the RFC 2576 algorithms to work, if any notifications are ever defined. Detailed comments: editorial: section 3 says "Please note that the DOCSIS 1.0 standard only requires Cable Modems to implement SNMPv1 and to process IPv4 customer traffic. Design choices in this MIB reflect those requirements." Given the following paragraph, I'd suggest replacing these two sentences with something like: "Please not that the DOCSIS 1.0 standard only required Cable Models to implement SNMPv1 and to process IPv4 customer traffic. Design choices in the original version of this MIB reflected those requirements." technical question: section 3.1 is in terms of RFC 1213 system group (though no reference is given). would it make sense to update this to the RFC 3418 system group? (this is what one gets through the references to SNMPv3) Comment: It'd be nice if someone worked out the relationship between the docsDevEventGroup, the docsDevEventGroupV2, and RFC 3014 as well as the current disman Alarm MIB. I don't think it makes sense to delay things now, but someone really should figure out how these fit together. Section 3.2.1 (use of TFTP) should be addressed in the security considerations. Does the HTTP option provide any protection? Page 10: Why is it talking about 24.0.16/255.255.255.0 and 24.0.16.30? Are these addresses reserved somewhere? Ultra-picky comment: purists would prefer talking about "this MIB module" rather than "this MIB". Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Nov 24 08:24:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06991 for ; Mon, 24 Nov 2003 08:24:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGhR-0007Yl-6i for ipcdn-archive@odin.ietf.org; Mon, 24 Nov 2003 08:24:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAODOLg5029050 for ipcdn-archive@odin.ietf.org; Mon, 24 Nov 2003 08:24:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGhK-0007WB-2P; Mon, 24 Nov 2003 08:24:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANy03-0004BW-MN for ipcdn@optimus.ietf.org; Sun, 23 Nov 2003 12:26:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25224 for ; Sun, 23 Nov 2003 12:26:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANy02-0005Nb-00 for ipcdn@ietf.org; Sun, 23 Nov 2003 12:26:18 -0500 Received: from util.ext.ti.com ([192.91.75.135]) by ietf-mx with esmtp (Exim 4.12) id 1ANy01-0005NY-00 for ipcdn@ietf.org; Sun, 23 Nov 2003 12:26:17 -0500 Received: from dlep51.itg.ti.com ([157.170.141.75]) by util.ext.ti.com (8.12.10/8.12.10) with ESMTP id hANHPhCr028706; Sun, 23 Nov 2003 11:25:43 -0600 (CST) Received: from dlep90.itg.ti.com (localhost [127.0.0.1]) by dlep51.itg.ti.com (8.12.10/8.12.10) with ESMTP id hANHPgkg004018; Sun, 23 Nov 2003 11:25:42 -0600 (CST) Received: from dile70.itg.ti.com (dile70.itg.ti.com [137.167.1.21]) by dlep90.itg.ti.com (8.12.10/8.12.10) with ESMTP id hANHPdGv022632; Sun, 23 Nov 2003 11:25:40 -0600 (CST) Received: by dile70.itg.ti.com with Internet Mail Service (5.5.2653.19) id ; Sun, 23 Nov 2003 19:25:39 +0200 Message-ID: <7DF2A1B372BBD611912F00508BDFBA9A01FD3745@dile03.itg.ti.com> From: "Pollak, Lucy" To: "'Eduardo Cardona'" , "Ipcdn (E-mail)" Cc: Richard Woundy , Jean-Francois Mule , DOCSIS OSS Majordomo List Date: Sun, 23 Nov 2003 19:25:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B1E6.CFE7DE86" Subject: [ipcdn] RE: RFI v2 MIB Draft 08 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , 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_01C3B1E6.CFE7DE86 Content-Type: text/plain; charset="iso-8859-1" Eduardo and Jason. Sorry for so late answer. I guess, the text your mentioned should not be removed, but modified. Let me return to Jason's example. I guess, the problem here is the mistake, which always is done for Admin and Oper status. Admin status is a command, which should be reflected in Oper status of lower layers, but should not change the Admin status of lower layers (in this point I agree with Jason). (1) Initial state: interface ifAdminStatus ifOperStatus docsCableUpstream US 1 up up docsCableUpstreamChannel 1 up up docsCableUpstreamChannel 2 up down (not in use) docsCableUpstreamChannel 2 up down (not in use) docsCableUpstreamChannel 2 up down (not in use) (2)Setting ifAdminStatus of US 1 to down results in this: interface ifAdminStatus ifOperStatus docsCableUpstream US 1 down down docsCableUpstreamChannel 1 up down docsCableUpstreamChannel 2 up down docsCableUpstreamChannel 2 up down docsCableUpstreamChannel 2 up down (3)Setting ifAdminStatus of US 1 to up results in exactly (1). This is my understanding of MIB text: "The administrative status of this interface. This reflect the total status of all the channels under this interface. So if at least one channel has a physical connection this interface has connection. Any SNMP SET on this interface will cause a SET to all the channels under this interface." So, from my POV "This reflect the total status of all the channels under this interface. So if at least one channel has a physical connection this interface has connection." is applicable for ifOperStatus, not ifAdminStatus. The "Any SNMP SET on this interface will cause a SET to all the channels under this interface." should be rephrased: "Any SNMP SET on this interface will influence the ifOperStatus of all the channels under this interface." The implicit SNMP SET will cause very complex implementation of different lower-higher layer state superposition. But, I guess, that wording about status of lower layer influenced by ifAdminStatus of higher layer should be kept. Regards. Lucy -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] Sent: Tuesday, November 04, 2003 5:58 PM To: Ipcdn (E-mail) Cc: Richard Woundy; Jean-Francois Mule; DOCSIS OSS Majordomo List Subject: RFI v2 MIB Draft 08 Hi dear IPCD folks and OSSI reflector Few updates of the last posted Draft -08 I am planning to do a quick update to the MIB draft after the IETF meeting to correct the below minor issues, Just a quick note, I will wait until the resolutions of the IETF IPCDN meeting to take actions on that. Jason Tessier, identified a description in the idAdminStatus in the draft that is not needed and does not reflect the needs for interface Stack based on RFC 2863 to propagate ifAdminStatus top to bottom of the stack for and up/down transition. Only ifOperStatus is propagated because of ifAdminStatus changes or inherent interface changes. Also for docsIfUpChannelUpdate related to the clone mechanism, all the related objects were updated to not being SCMA specific. One objects left out of the updates docsIfUpChannelUpdate. The proposed change will align that object description. See at the end of the email the Jasson arguments for the ifAdminStatus change Below are the proposed changes, let us know any changes. Thanks Eduardo update to RFI Mib v2 with two changes: 1- ifAdminStatus requirements for UpChannels should read. 3.2.5.2. ifEntry for Upstream interfaces ifAdminStatus The administrative status of this interface. 2- Re-define the requirement for docsIfUpChannelUpdate as below - All the associated objects for the Clone Mechanism are no longer referencing exclusively to SCDMA. The intention now is normalize this requirements for all type of profiles. - change GEN-ERROR for genError and COMMIT_FAILED_ERROR for commitFailed docsIfUpChannelUpdate OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Used to perform the transfer of adjusted SCDMA parameters from the temporary upstream row to the active upstream row indicated by the docsIfUpChannelCloneFrom object. The transfer is initiated through an SNMP SET of TRUE to this object. The SNMP SET will fail with a GEN_ERROR (snmpv1) or COMMIT_FAILED_ERROR (snmpv2c/v3) if the adjusted SCDMA parameter values are not compatible with each other. Although this object was created to facilitate SCDMA parameter adjustment, it may also be used at the vendor's discretion for non-SCDMA parameter adjustment. An SNMP GET of this object always returns FALSE." ::= { docsIfUpstreamChannelEntry 17 } to: docsIfUpChannelUpdate OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Used to perform the transfer of adjusted parameters from the temporary upstream row to the physical upstream row indicated by the docsIfUpChannelCloneFrom object. The transfer is initiated through an SNMP SET to 'true' of this object. The SNMP SET failure returns an error genError (snmpv1) or commitFailed (snmpv2c/v3) if the adjusted parameter values are not compatible with each other. Reading this object always return 'false'." ::= { docsIfUpstreamChannelEntry 17 } -------------------------------- IfAdminStatus Jasson email -----Original Message----- From: Jason.Tessier@arrisi.com [mailto:Jason.Tessier@arrisi.com] Sent: Wednesday, October 22, 2003 10:20 AM To: DOCSIS OSS Majordomo List Subject: ifAdminStatus sets to docsCableUpstream (129) Hello, In the DOCS-IF-MIB there's a requirement that ifAdminStatus sets to a docsCableUpstream interface also be applied to the docsCableUpstreamChannel interfaces under it. 3.2.5.2.1. ifEntry for Upstream interfaces in Cable Modem Termination Systems ifTable Comments ============== =========================================== ifType The IANA value of docsCableUpstream (129). ifAdminStatus The administrative status of this interface. This reflect the total status of all the channels under this interface. So if at least one channel has a physical connection this interface has connection. Any SNMP SET on this interface will cause a SET to all the channels under this interface. So in the case where there are multiple logical channels under one upstream interface, if you want to enable/disable the docsCableUpstream interface all of the logical channels associated with it are also set to up/down. I think that this makes it difficult for the operator to set the ifAdminStatus of the docsCableUpstream interface without affecting several logical channels, some of which may not even have been enabled in the first place. If an operator sets the ifAdminStatus of the docsCableUpstream to down, the set will already be reflected in the ifOperStatus of the docsCableUpstreamChannels under it. The OperStatus of the docsCableUpstreamChannels will reflect their own state, taking into account the upper layer and modulation profiles, etc. I don't see a need for this requirement. An example: interface ifAdminStatus docsCableUpstream US 1 down docsCableUpstreamChannel 1 up docsCableUpstreamChannel 2 down (not in use) docsCableUpstreamChannel 2 down (not in use) docsCableUpstreamChannel 2 down (not in use) Setting ifAdminStatus of US 1 to up results in this: interface ifAdminStatus docsCableUpstream US 1 up docsCableUpstreamChannel 1 up docsCableUpstreamChannel 2 up docsCableUpstreamChannel 3 up docsCableUpstreamChannel 4 up The effect is that with one set 4 ifAdminStatus are affected, and 3 channels are put into use that may not be desired. I'm thinking of proposing an ECR to remove this requirement from the MIB. Thanks, Jason Tessier QA Engineer ARRIS Communications Ireland Ltd. Jason.Tessier@arrisi.com +353-21-7305826 ------_=_NextPart_001_01C3B1E6.CFE7DE86 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Eduardo and Jason.
Sorry=20 for so late answer. I guess, the text your mentioned should not be = removed, but=20 modified. Let me return to Jason's example. I guess, the problem here = is the=20 mistake, which always is done for Admin and Oper status. Admin status = is a=20 command, which should be reflected in Oper status of lower layers, but = should=20 not change the Admin status of lower layers (in this point I agree with = Jason).=20  
 
(1) Initial = state:
interface   =    =20                =20  ifAdminStatus       ifOperStatu= s
docsCableUpstream US=20 1            = up       &nb= sp;           &nb= sp;up
docsCableUpstreamChannel=20 1        up       &nb= sp;           &nb= sp;up
docsCableUpstreamChannel=20 2      =20  up          &nbs= p;        =20 down (not in use)
docsCableUpstreamChannel=20 2        up       &= nbsp;            = down (not in use)
docsCableUpstreamChannel=20 2        up       &= nbsp;       &nb= sp;   =20 down (not in use) 

(2)Setting ifAdminStatus of US 1 = to down results in this:=20
interface =      =20                =20  ifAdminStatus       ifOperStatu= s
docsCableUpstream US=20 1            = ;down       &nb= sp;          down
docsCableUpstreamChannel=20 1        up       &nb= sp;           &nb= sp;down
docsCableUpstreamChannel=20 2      =20  up          &nbs= p;        =20 down
docsCableUpstreamChannel=20 2        up       &= nbsp;            = down
docsCableUpstreamChannel=20 2        up       &= nbsp;       &nb= sp;   =20 down
(3)Setting=20 ifAdminStatus of US 1 to up results in exactly (1).
 
This is my=20 understanding of MIB text:
 "The=20 administrative status of this interface. 
This reflect the = total=20 status of all the channels  
under this interface. So if = at least=20 one channel 
has a physical connection this interface=20 has 
connection. Any SNMP SET on this interface = will 
cause a=20 SET to all the channels under=20 this 
interface."
So, from my POV "This reflect the total = status of all=20 the channels  
under this interface. So if at least one=20 channel 
has a physical connection this interface=20 has 
connection." is applicable for ifOperStatus, not=20 ifAdminStatus. 
 
The "Any SNMP SET on this interface = will 
cause=20 a SET to all the channels under this 
interface." should be=20 rephrased:
"Any SNMP SET on this interface = will 
influence=20 the ifOperStatus of all the channels under=20 this 
interface."
 
The implicit SNMP SET will cause very complex = implementation of=20 different lower-higher layer state superposition. But, I guess, that = wording=20 about status of lower layer influenced by ifAdminStatus of=20 higher layer should be kept.
 
Regards.
Lucy
 
 
-----Original Message-----
From: Eduardo Cardona=20 [mailto:e.cardona@cablelabs.com]
Sent: Tuesday, November = 04, 2003=20 5:58 PM
To: Ipcdn (E-mail)
Cc: Richard Woundy;=20 Jean-Francois Mule; DOCSIS OSS Majordomo List
Subject: RFI = v2 MIB=20 Draft 08

Hi dear IPCD folks and OSSI reflector=20
 
Few updates of the last posted Draft -08=20
 
I am planning to do a quick update to = the MIB=20 draft after the IETF meeting to correct the below minor issues, Just = a quick=20 note, I will wait until the resolutions of the IETF IPCDN meeting to = take=20 actions on that.
 
 
Jason Tessier, identified a description in = the=20 idAdminStatus in the draft that is not needed and does not reflect = the needs=20 for interface Stack based on 
RFC 2863 to propagate ifAdminStatus top to = bottom of the stack for and up/down transition. Only = ifOperStatus is=20 propagated because of ifAdminStatus changes or inherent interface=20 changes.
 
Also for docsIfUpChannelUpdate related to = the clone=20 mechanism, all the related objects were updated to not being SCMA = specific.=20 One objects left out of the updates docsIfUpChannelUpdate. The = proposed=20 change will align that object description.
 
See at the end of the email the Jasson = arguments for=20 the ifAdminStatus change
 
Below are the proposed changes, let us = know any=20 changes.
 
Thanks
 
Eduardo
 
 
 
update to RFI Mib v2 with two=20 changes:
 
1-  ifAdminStatus=20 requirements for UpChannels should = read.
     3.2.5.2.  ifEntry for Upstream = interfaces 
  ifAdminStatus     The=20 administrative status of this interface.
 
 
2- Re-define = the requirement=20 for  docsIfUpChannelUpdate  as=20 below
 
- All the associated = objects for=20 the Clone Mechanism are no longer
referencing exclusively to=20 SCDMA. The intention now is normalize this =
requirements for all type=20 of profiles.
 
- change GEN-ERROR = for genError=20 and COMMIT_FAILED_ERROR for
commitFailed
 
 
docsIfUpChannelUpdate OBJECT-TYPE=20
       =20 SYNTAX      TruthValue=20
        MAX-ACCESS  = read-create=20
       =20 STATUS      current=20
        DESCRIPTION=20 =
            = "Used=20 to perform the transfer of adjusted SCDMA parameters=20 =
           &n= bsp;=20 from the temporary upstream row to the active upstream row=20 =
           &n= bsp;=20 indicated by the docsIfUpChannelCloneFrom object. The=20 =
           &n= bsp;=20 transfer is initiated through an SNMP SET of TRUE to this=20 =
           &n= bsp;=20 object. The SNMP SET will fail with a GEN_ERROR (snmpv1)=20 =
           &n= bsp;=20 or COMMIT_FAILED_ERROR (snmpv2c/v3) if the adjusted=20 =
           &n= bsp;=20 SCDMA parameter values are not compatible with each other.=20 =
           &n= bsp;=20 Although this object was created to facilitate SCDMA=20 =
           &n= bsp;=20 parameter adjustment, it may also be used at the vendor's=20 =
           &n= bsp;=20 discretion for non-SCDMA parameter adjustment.=20
           =  =20 An SNMP GET of this object always returns FALSE."=20
        ::=3D {=20 docsIfUpstreamChannelEntry 17 }
to:
 
docsIfUpChannelUpdate OBJECT-TYPE=20
       =20 SYNTAX      TruthValue=20
        MAX-ACCESS  = read-create=20
       =20 STATUS      current=20
        DESCRIPTION=20 =
            = "Used=20 to perform the transfer of adjusted parameters=20 =
           &n= bsp;=20 from the temporary upstream row to the physical upstream row=20 =
           &n= bsp;=20 indicated by the docsIfUpChannelCloneFrom object. The=20 =
           &n= bsp;=20 transfer is initiated through an SNMP SET to 'true' of this=20 =
           &n= bsp;=20 object. The SNMP SET failure returns an error genError = (snmpv1)=20 =
           &n= bsp;=20 or commitFailed (snmpv2c/v3) if the adjusted parameter values = are=20
          &nb= sp; =20 not compatible with each=20 = other. 
         &n= bsp;  =20 Reading this object always return 'false'."=20
        ::=3D {=20 docsIfUpstreamChannelEntry 17 }
 
 
--------------------------------=20
 
IfAdminStatus=20 Jasson email
 
 
-----Original Message-----
From:=20 Jason.Tessier@arrisi.com [mailto:Jason.Tessier@arrisi.com] =
Sent:=20 Wednesday, October 22, 2003 10:20 AM
To: DOCSIS OSS = Majordomo=20 List
Subject: ifAdminStatus sets to docsCableUpstream=20 (129)


Hello,=20

In the DOCS-IF-MIB there's a = requirement=20 that ifAdminStatus sets to a docsCableUpstream interface also be = applied to=20 the docsCableUpstreamChannel interfaces under it. =

3.2.5.2.1.  ifEntry for Upstream interfaces in = Cable Modem=20 Termination
              =  =20 Systems
     
      =  ifTable  =20         Comments
     =20  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D   =  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20

<SNIP>
     
     =20  ifType            The IANA value = of=20 docsCableUpstream (129).
     
<SNIP> =  =20  
       ifAdminStatus     The = administrative status of this interface.
      =  =20                  This = reflect the=20 total status of all the channels  
      =    =20                under this = interface.=20 So if at least one channel
          =  =20              has a physical = connection this=20 interface has
              =  =20          connection. Any SNMP SET on this = interface=20 will
                =    =20      cause a SET to all the channels under this =
 =20                     =  =20  interface.

So in the case where there are multiple = logical=20 channels under one upstream interface, if you want to enable/disable = the=20 docsCableUpstream interface all of the logical channels associated = with it are=20 also set to up/down.

I think that=20 this makes it difficult for the operator to set the ifAdminStatus of = the=20 docsCableUpstream interface without affecting several logical = channels, some=20 of which may not even have been enabled in the first place.  If = an=20 operator sets the ifAdminStatus of the docsCableUpstream to down, the = set will=20 already be reflected in the ifOperStatus of the = docsCableUpstreamChannels=20 under it. The OperStatus of the docsCableUpstreamChannels will = reflect their=20 own state, taking into account the upper layer and modulation = profiles, etc. I=20 don't see a need for this requirement.

An example:

interface =    =20                  =20  ifAdminStatus
docsCableUpstream US 1=20          down
docsCableUpstreamChannel 1         = up  =20      
docsCableUpstreamChannel=20 2        down (not in use)
docsCableUpstreamChannel 2       =  down (not in=20 use)
docsCableUpstreamChannel 2 =    =20    down (not in use)

Setting ifAdminStatus of US 1 to up results in this:=20

interface         =    =20            ifAdminStatus =
docsCableUpstream US 1        =20  up
docsCableUpstreamChannel = 1  =20       up         =
docsCableUpstreamChannel 2      =20  up
docsCableUpstreamChannel = 3  =20      up
docsCableUpstreamChannel 4      =20  up

The = effect is that=20 with one set 4 ifAdminStatus are affected, and 3 channels are put = into use=20 that may not be desired. I'm thinking of proposing an ECR to remove = this=20 requirement from the MIB.

Thanks,


Jason=20 Tessier
QA Engineer
ARRIS Communications Ireland=20 Ltd.
Jason.Tessier@arrisi.com
+353-21-7305826=20 =
------_=_NextPart_001_01C3B1E6.CFE7DE86-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Nov 24 11:57:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15902 for ; Mon, 24 Nov 2003 11:57:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOK1G-0008QA-Sn for ipcdn-archive@odin.ietf.org; Mon, 24 Nov 2003 11:57:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOGv2iB032366 for ipcdn-archive@odin.ietf.org; Mon, 24 Nov 2003 11:57:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOK1F-0008Pr-KJ; Mon, 24 Nov 2003 11:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOK0k-0008OC-IC for ipcdn@optimus.ietf.org; Mon, 24 Nov 2003 11:56:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15874 for ; Mon, 24 Nov 2003 11:56:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOK0j-0000IC-00 for ipcdn@ietf.org; Mon, 24 Nov 2003 11:56:29 -0500 Received: from sys4.smerdon.livonia.mi.us ([208.176.108.155] helo=umcc.ais.org) by ietf-mx with smtp (Exim 4.12) id 1AOK0i-0000I6-00 for ipcdn@ietf.org; Mon, 24 Nov 2003 11:56:28 -0500 Received: from sys4.smerdon.livonia.mi.us([208.176.108.155]) (1323 bytes) by umcc.ais.org via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Mon, 24 Nov 2003 11:56:27 -0500 (EST) (Smail-3.2.0.111 2000-Feb-17 #1 built 2002-Nov-3) Date: Mon, 24 Nov 2003 11:56:26 -0500 (EST) From: Shahram Esfahani To: ipcdn@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ipcdn] Update to RFC2669 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi folks, In light of the recent virus/worm attacks on cable subscribers, has the IETF considered updating RFC2669 to include rate-limiting? Many MSOs combated the network impacts of the virus/worm infections by configuring ACLs on their CMTS. However, the traffic characteristics of these infected users reveled numerous ICMP echo requests being sent upstream -- in the magnitude of hundreds per second. Having just a few infected users in a MAC domain can put unnecessary stress on the CMTS to issue grants and flood the domain with ARP requests. A better solution to these CMTS-centric ACLs would be to rate-limit this type of traffic on the cable modem. Rate-limiting can also be applied to other traffic besides ICMP. For example, some MSOs have expressed concerns about very aggressive IP stacks sending DHCP packets too quickly causing server strain. Your thoughts about this? Thanks and regards, Shahram _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Nov 24 19:31:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13521 for ; Mon, 24 Nov 2003 19:31:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOR6d-0006iG-2Y for ipcdn-archive@odin.ietf.org; Mon, 24 Nov 2003 19:31:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP0V3Cn025803 for ipcdn-archive@odin.ietf.org; Mon, 24 Nov 2003 19:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOR6c-0006i3-Lc; Mon, 24 Nov 2003 19:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOR6Q-0006h0-AT for ipcdn@optimus.ietf.org; Mon, 24 Nov 2003 19:30:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13458 for ; Mon, 24 Nov 2003 19:30:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOR6O-0001hw-00 for ipcdn@ietf.org; Mon, 24 Nov 2003 19:30:48 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AOR6N-0001gT-00 for ipcdn@ietf.org; Mon, 24 Nov 2003 19:30:47 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hAP0SxoK006029; Mon, 24 Nov 2003 17:29:00 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Compliance statement in RF MIBv2 draft 08 Date: Mon, 24 Nov 2003 17:28:58 -0700 Message-ID: Thread-Topic: [ipcdn] Compliance statement in RF MIBv2 draft 08 Thread-Index: AcOyjm/TBeC3xFu/Thm4bRQ+5JsnLwAWhOag From: "Jean-Francois Mule" To: , "Raftus, David" Cc: "Eduardo Cardona" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Folks, Reviewing the RFI mib draft08, we have 2 module compliance statements, = one for v1 (RFC 2670) and one for v2 (new RFC which will obsolete RFC = 2670 - not update but obsolete per RFC2233). -- RFC 2670 docsIfCompliances OBJECT IDENTIFIER ::=3D { docsIfConformance 1 }=20 docsIfGroups OBJECT IDENTIFIER ::=3D { docsIfConformance 2 }=20 -- new RFC docsIfCompliancesV2 OBJECT IDENTIFIER ::=3D { docsIfConformance 3 } docsIfGroupsV2 OBJECT IDENTIFIER ::=3D { docsIfConformance 4 } The docsIfCompliancesV2 compliance statement defines the groups of = objects for v2 (the v1 objects plus the new v2 ones minus some = deprecated ones like the docsIfCmtsCmStatusIpAddress which used the old = IpAddress type for e.g.). 3 objects in total are deprecated from v1 -> = v2. Is there any good reason why both the v1 RFC2670 and v2 statements have = a STATUS of current? Isn't the intent was to deprecate the v1 compliance = statement along with the v1 groups.=20 If the intent of draft08 is to mandate some v1 deprecated objects in the = v2 implementation, I believe the right way to do this is to actually put = a deprecated object in a mandatory v2 group as described in the mib = guidelines: http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-= 02.txt - The status of a conformance group is independent of the status of its members. Thus, a current group MAY refer to deprecated objects or notifications. This may be desirable in certain cases, e.g., a set of widely-deployed objects or notifications may be deprecated when they are replaced by a more up-to-date set of definitions, but the conformance groups that contain them may remain current in order to encourage continued implementation of the deprecated objects and notifications. Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Nov 25 10:06:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20579 for ; Tue, 25 Nov 2003 10:06:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOelQ-0006F8-Vi for ipcdn-archive@odin.ietf.org; Tue, 25 Nov 2003 10:06:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPF64Jx023994 for ipcdn-archive@odin.ietf.org; Tue, 25 Nov 2003 10:06:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOelO-0006Ef-Cd; Tue, 25 Nov 2003 10:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOekX-0006Cl-5S for ipcdn@optimus.ietf.org; Tue, 25 Nov 2003 10:05:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20342 for ; Tue, 25 Nov 2003 10:04:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOekU-0006KC-00 for ipcdn@ietf.org; Tue, 25 Nov 2003 10:05:07 -0500 Received: from outmail2.comcast.com ([208.17.32.26] helo=cdcavux01.cable.comcast.com) by ietf-mx with esmtp (Exim 4.12) id 1AOekU-0006Jw-00 for ipcdn@ietf.org; Tue, 25 Nov 2003 10:05:06 -0500 Received: from cdcexsmtp01.cable.comcast.com (localhost [127.0.0.1]) by cdcavux01.cable.comcast.com (8.11.7+Sun/8.11.6) with ESMTP id hAPF4Pk08850; Tue, 25 Nov 2003 10:04:25 -0500 (EST) Received: by cdcexsmtp01.cable.comcast.com with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Nov 2003 10:02:08 -0500 Message-ID: From: "Woundy, Richard" To: "'Randy Presuhn'" Cc: ipcdn@ietf.org Subject: RE: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv 2-06.txt Date: Tue, 25 Nov 2003 10:00:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Randy, Thanks for your detailed review. There is a lot I need to go over. My plan is to respond to these comments (to you and the mailing list) by Thursday December 4th. My intent is to generate a revision of the draft incorporating these comments (and a few others) by mid-December. - Rich -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Saturday, November 22, 2003 3:08 AM To: ipcdn@ietf.org Subject: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv2-06.txt Hi - Here are my comments on draft-ietf-ipcdn-device-mibv2-06.txt I recognize that this is based on an earlier RFC and external specifications, thus some of the "shoulds" you may choose to ignore. First the more-or-less mechanical stuff: Abstract: the language about "draft revision" and "will obsolete" wouldn't be appropriate if this is to be published as an RFC. Should be replaced with words that will be true when it becomes an RFC. Intellectual Property: BCP-11 is missing from the references. Table of contents: - many of the page numbers are wrong - the section titles in the table of contents sometimes don't match the actual section titles. Items based on http://www.ietf.org/ietf/1id-guidelines.txt: - on first page, "Internet Draft" -> "INTERNET-DRAFT" Items based on http://www.ietf.org/ID-nits.html: - missing introduction? (ID-nits.html section 1.2) this seems to be in the overview. Items based on draft-rfc-editor-rfc2223bis-07.txt: - Title: the acronynm DOCSIS should be expanded (2223 bis 2.9) - Use two spaces after period at the end of a sentence. (2223 bis 3.1.7) - some References have "," before the "and", others don't. be consistent, using a "," before the "and", as in the references section of the guidelines. - not consistent in use of "RFCxxxx", "RFC-xxxx", and "RFC XXXX" - section 2.4: ITU-T J.112 is missing from the references - section 2.7: "MAC" not expanded on first use - section 2.7: "PDU" not expanded on first use - section 3: "SNMPv1", "SNMPv2c", "SNMPv3" not expanded on first use - section 3: spurious blank line before "requirements" - section 3: "CPE" not expanded on first use - section 3.1: "IGMP" not expanded on first use - section 3.2.1: "TFTP" not expanded on first use - section 3.2.1: "HTTP" not expanded on first use - section 3.2.2: no reference for "syslog" - section 3.3: "LLC" not expanded - section 3.3: "IPX" not expanded - section 3.3: "ICMP" not expanded - section 3.3.3: "ToS" not expanded - section 3.3.4: "QOS" not expanded - section 4: "DSCP" not expanded - section 4: "OIDs" not expanded - section 4: "VACM" not expanded - section 4: "NMS" not expanded - section 4: "DHCP" not expanded - section 4: "occurrance" -> "occurrence" - section 4: "CMCI" not expanded - section 4: "SNAP" not expanded - section 4: "DSAP" not expanded - section 4: "MCNS" not expanded - (section 5.1: "simplication" -> "simplification") - Table of contents and document in general: sections are not in order stipulated by rfc2223bis section 4. MIB Compilation note: smilint produces lots of warnings regarding the fact that several of the "current" compliance statements reference "deprecated" groups, but this is specifically permitted by the MIB review guidelines and RFC 2580, so I'll assume it's intentional. MIB Review Guidelines: ORGANIZATION clause MUST have full name of working group (IP over cable data network) All REVISION clauses should be updated to four-digit years. docsDevMaxCpe: a UNITS clause would be nice. docsDevNmAccessTable: should specify what the persistance properties of this information are. docsDevNmAccessInterfaces: DEFVAL should give the actual value, rather than just an ASN.1 comment. However, since this is deprecated and the DESCRIPTION would make the length implementation dependent, I won't insist on it. docsDevSwServerTransportProtocol: are there any constraints on when this can be set to TFTP? For example, if docsDevSwServerAddressType is DNS, must an implementation reject attempts to set this to TFTP? Can the other docsDevSw* objects be changed when docsDevSwOperStatus is "in progress"? docsDevServerBootState should explain what enumeration values 9 and 10 mean. docsDevServerDhcpAddressType: what value does this have if DHCP was not used? docsDevServerTimeAddressType: what value does this have when no time server is known? docsDevServerConfigTftpAddressType: value if unknown? docsDevServerConfigTftpAddress: security considerations should address consequences of using TFTP here. docsDevEvThrottleThreshold and related objects should address the question of just what notifications they apply to. If, for example, the system also implemented the Alarm MIB, the answer would be of more than academic interest. docsDevEvThrottleThreshold: a UNITS clause would be nice docsDevEvThrottleInterval: should be Unsigned32. docsDevEvControlTable: what is the lifecycle / persistance of entries in this table? docsDevEvReporting: the DESCRIPTION doesn't mesh with the notion of using RFC 3413 where it talks about sending an SNMP trap. This bit of text is ambiguous: An event reported by trap or syslog logging MUST be accompanied by localVolatile logging. If the bit value for either traps(1) or syslog(2) is set, then the agent MUST enforce that the bit value for local(0) or localVolatile(3) is set as well." Is the intent that the agent must reject attempts to do SETs that don't satisfy the criteria, or does this text mean that the agent must act as though the bits in the request had been set appropriately? docsDevEventTable: does stuff in this table persist across reboots? docsDevEvIndex should be Unisnged32. docsDevEvLastTime and docsDevEvFirstTime: do these get the same special values as docsDevDateTime? docsDevEvCounts should have UNITS. Purists might object to using a Counter type here. docsDevEvLevel should explain what each of the enumeration values means. docsDevFilterLLCTable should spell out lifecycle / persistence docsDevFilterLLCIndex should be Unsigned32 docsDevFilterLLCIfIndex: if rows in this table can persist across reboots, this object has persistence / consistency implications with the interfaces table and related objects. Intent should be spelled out here. docsDevFilterLLCProtocol should be Unsigned32. docsDevFilterLLCMatches should have UNITS. docsDevFilterIpTable: should spell out persistance / lifecycle docsDevFilterIpIndex: should be Unsigned32. docsDevFilterIpIfIndex: if this table can persist across reboots, this object has implications for either the satbility of ifIndex values or its own renumbering. docsDevFilterIpDaddr: it's not quite right to talk about a value of "0" for this object, since it's syntactically an OCTET STRING. docsDevFilterIpProtocol: should be Unsigned32. a REFERENCE clause to the appropriate IANA registry would be nice. docsDevFilterIpSourcePortLow , docsDevFilterIpSourcePortHigh, docsDevFilterIpDestPortLow, docsDevFilterIpDestPortHigh: should be Unsigned32. docsDevFilterIpMatches needs UNITS, and syntax should be ZeroBasedCounter32. docsDevFilterIpPolicyId: should be Unsigned32. docsDevFilterPolicyTable: should talk about lifecycle and persistance. docsDevFilterPolicyIndex should be Unsigned32 docsDevFilterPolicyId should be Unsigned32 docsDevFilterPolicyStatus use of the RowStatus TC requires spelling out what columns are permitted to be modified in an active row. docsDevFilterPolicyPtr: what happens when this points to a row which does not exist? docsDevFilterTosTable: lifecycle and persistence. docsDevFilterTosIndex: should be Unsigned32. docsDevCpeEnroll: what is meant by "manually"? docsDevCpeIpMax: may this object be set to a value larger than "the maximum permitted for this device"? If it weren't for that -1, I'd like to see UNITS. docsDevCpeTable: persistance and lifecycle docsDevCpeInetTable: persistance and lifecycle docsDevCpeInetAddr: these words should probably be tweaked to be a bit more protocol-neutral: " N.B. Neither the all zeros or all ones addresses may be used as values for this object." docsDevCpeInetSource: when is (1) used? Security Considerations fails to mention these read-write objects: docsDevDateTime docsDevSTPControl docsDevIgmpModeControl docsDevSwServer docsDevSwFilename docsDevSwAdminStatus docsDevSwServerAddressType docsDevSwServerAddress docsDevSwServerTransportProtocol docsDevEvControl docsDevEvSyslog docsDevEvThrottleThreshold docsDevEvThrottleInterval docsDevEvReporting docsDevEvSyslogAddressType docsDevEvSyslogAddress docsDevFilterLLCUnmatchedAction docsDevFilterIpDefault docsDevCpeEnroll docsDevCpeIpMax Security Considerations doesn specifically address these read-create objects, although it does talk about their tables in general terms: docsDevNmAccessIp docsDevNmAccessIpMask docsDevNmAccessCommunity docsDevNmAccessControl docsDevNmAccessInterfaces docsDevNmAccessStatus docsDevNmAccessTrapVersion docsDevFilterLLCStatus docsDevFilterLLCIfIndex docsDevFilterLLCProtocolType docsDevFilterLLCProtocol docsDevFilterIpStatus docsDevFilterIpControl docsDevFilterIpIfIndex docsDevFilterIpDirection docsDevFilterIpBroadcast docsDevFilterIpSaddr docsDevFilterIpSmask docsDevFilterIpDaddr docsDevFilterIpDmask docsDevFilterIpProtocol docsDevFilterIpSourcePortLow docsDevFilterIpSourcePortHigh docsDevFilterIpDestPortLow docsDevFilterIpDestPortHigh docsDevFilterIpTos docsDevFilterIpTosMask docsDevFilterIpContinue docsDevFilterIpPolicyId docsDevFilterPolicyId docsDevFilterPolicyType docsDevFilterPolicyAction docsDevFilterPolicyStatus docsDevFilterPolicyPtr docsDevFilterTosStatus docsDevFilterTosAndMask docsDevFilterTosOrMask docsDevCpeStatus docsDevCpeInetRowStatus docsDevFilterIpDirection docsDevFilterIpBroadcast The value assigned to docsDevNotification doesn't meet the requirements of the MIB review guidelines section 4.7: it needs to end in zero in order for the RFC 2576 algorithms to work, if any notifications are ever defined. Detailed comments: editorial: section 3 says "Please note that the DOCSIS 1.0 standard only requires Cable Modems to implement SNMPv1 and to process IPv4 customer traffic. Design choices in this MIB reflect those requirements." Given the following paragraph, I'd suggest replacing these two sentences with something like: "Please not that the DOCSIS 1.0 standard only required Cable Models to implement SNMPv1 and to process IPv4 customer traffic. Design choices in the original version of this MIB reflected those requirements." technical question: section 3.1 is in terms of RFC 1213 system group (though no reference is given). would it make sense to update this to the RFC 3418 system group? (this is what one gets through the references to SNMPv3) Comment: It'd be nice if someone worked out the relationship between the docsDevEventGroup, the docsDevEventGroupV2, and RFC 3014 as well as the current disman Alarm MIB. I don't think it makes sense to delay things now, but someone really should figure out how these fit together. Section 3.2.1 (use of TFTP) should be addressed in the security considerations. Does the HTTP option provide any protection? Page 10: Why is it talking about 24.0.16/255.255.255.0 and 24.0.16.30? Are these addresses reserved somewhere? Ultra-picky comment: purists would prefer talking about "this MIB module" rather than "this MIB". Randy _______________________________________________ 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 exim@www1.ietf.org Tue Nov 25 14:50:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04935 for ; Tue, 25 Nov 2003 14:50:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjCF-0003Hf-GQ for ipcdn-archive@odin.ietf.org; Tue, 25 Nov 2003 14:50:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPJo3to012598 for ipcdn-archive@odin.ietf.org; Tue, 25 Nov 2003 14:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjCD-0003Ge-QD; Tue, 25 Nov 2003 14:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjBt-0003Fi-O6 for ipcdn@optimus.ietf.org; Tue, 25 Nov 2003 14:49:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04906 for ; Tue, 25 Nov 2003 14:49:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjBq-00045n-00 for ipcdn@ietf.org; Tue, 25 Nov 2003 14:49:38 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AOjBp-000458-00 for ipcdn@ietf.org; Tue, 25 Nov 2003 14:49:38 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hAPJmjoK021474; Tue, 25 Nov 2003 12:48:45 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] New editors/authors for the ipcdn ID: draft-ietf-ipcdn-docsisevent-mib-03.txt Date: Tue, 25 Nov 2003 12:48:45 -0700 Message-ID: Thread-Topic: [ipcdn] New editors/authors for the ipcdn ID: draft-ietf-ipcdn-docsisevent-mib-03.txt Thread-Index: AcOyjm/TBeC3xFu/Thm4bRQ+5JsnLwAWhOagACjlpRA= From: "Jean-Francois Mule" To: , "Raftus, David" , "Junming Gao" , Cc: "Jean-Francois Mule" , "Richard Woundy @ Comcast" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Folks, During the IPCDN wg meeting at the last IETF, we put out a call for new = editors/co-authors for the IPCDN DOCSIS Notification mib = (draft-ietf-ipcdn-docsisevent-mib-03.txt). The draft expired in July = 2003. The call for volunteers is in our meeting materials: http://www.ipcdn.org/meetings.html Azlina Ahmad of Cisco and Greg Nakanishi of Motorola did volunteered to = take over the draft and help us advance it through the IETF process. = Rich and I have reviewed their proposal and accepted it. Let me or Rich = know if you have any comments or concerns. Unless we hear any concerns, = this decision will become effective 1 week from today. Thank you to David, Junming and Pak for their contributions and for = taking the draft to draft-03. Regards, Rich and Jean-Fran=E7ois - ipcdn wg chairs. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Nov 26 12:48:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19195 for ; Wed, 26 Nov 2003 12:48:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3ll-0004Mg-Ur for ipcdn-archive@odin.ietf.org; Wed, 26 Nov 2003 12:48:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQHm5qW016773 for ipcdn-archive@odin.ietf.org; Wed, 26 Nov 2003 12:48:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3lh-0004Lw-SP; Wed, 26 Nov 2003 12:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3lA-0004LM-0I for ipcdn@optimus.ietf.org; Wed, 26 Nov 2003 12:47:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19152 for ; Wed, 26 Nov 2003 12:47:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP3l8-0001ub-00 for ipcdn@ietf.org; Wed, 26 Nov 2003 12:47:26 -0500 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1AP3l7-0001u5-00 for ipcdn@ietf.org; Wed, 26 Nov 2003 12:47:25 -0500 Received: from h-68-164-158-203.snvacaid.dynamic.covad.net ([68.164.158.203] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AP3kw-0005lF-00 for ipcdn@ietf.org; Wed, 26 Nov 2003 09:47:14 -0800 Message-ID: <012301c3b445$9b42df60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Date: Wed, 26 Nov 2003 09:49:14 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [ipcdn] Additional comments on draft-ietf-ipcdn-device-mibv2-06.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - Bert Wijnen ran SMICng on the MIB module in draft-ietf-ipcdn-device-mibv2-06.txt and found some items that I overlooked: > E: f(ipcdndevice.mi2), (1342,1) Row "docsDevFilterIpEntry" must have > same status as parent table "docsDevFilterIpTable" This must be fixed. > E: f(ipcdndevice.mi2), (2389,12) Item "diffServMIBDataPathGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2390,12) Item "diffServMIBClfrGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2391,12) Item "diffServMIBClfrElementGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2392,12) Item "diffServMIBMultiFieldClfrGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2393,12) Item "diffServMIBActionGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2394,12) Item "diffServMIBDscpMarkActGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2395,12) Item "diffServMIBCounterGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2396,12) Item "diffServMIBAlgDropGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2399,8) Item "diffServDataPathStatus" should be IMPORTed > E: f(ipcdndevice.mi2), (2406,8) Item "diffServClfrStatus" should be IMPORTed > E: f(ipcdndevice.mi2), (2413,8) Item "diffServClfrElementStatus" should be IMPORTed > E: f(ipcdndevice.mi2), (2420,8) Item "diffServMultiFieldClfrAddrType" should be IMPORTed > E: f(ipcdndevice.mi2), (2426,8) Item "diffServMultiFieldClfrSrcAddr" should be IMPORTed > E: f(ipcdndevice.mi2), (2433,8) Item "diffServMultiFieldClfrDstAddr" should be IMPORTed > E: f(ipcdndevice.mi2), (2439,8) Item "diffServAlgDropStatus" should be IMPORTed > E: f(ipcdndevice.mi2), (2446,8) Item "diffServDataPathStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2452,8) Item "diffServClfrStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2458,8) Item "diffServClfrElementStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2464,8) Item "diffServMultiFieldClfrStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2470,8) Item "diffServActionStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2476,8) Item "diffServCountActStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2482,8) Item "diffServAlgDropStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2488,8) Item "diffServAlgDropType" should be IMPORTed The MIB review guidelines recommend that these be imported. This is not a hard requirement, but the consensus of the MIB reviewer mailing list was that having IMPORTS for these makes it easier for someone reading a module to see the dependencies in one place. Since this is an update to an existing specification, I'm also going to run it through smidiff, and will post comments regarding those results in a separate message. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Nov 26 13:27:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20604 for ; Wed, 26 Nov 2003 13:27:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4NV-00073O-48 for ipcdn-archive@odin.ietf.org; Wed, 26 Nov 2003 13:27:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQIR5pH027108 for ipcdn-archive@odin.ietf.org; Wed, 26 Nov 2003 13:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4NP-00072r-Rz; Wed, 26 Nov 2003 13:26:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4NB-000723-FV for ipcdn@optimus.ietf.org; Wed, 26 Nov 2003 13:26:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20585 for ; Wed, 26 Nov 2003 13:26:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP4N8-0002QR-00 for ipcdn@ietf.org; Wed, 26 Nov 2003 13:26:43 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AP4N7-0002QD-00 for ipcdn@ietf.org; Wed, 26 Nov 2003 13:26:42 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hAQIQ5oK026722; Wed, 26 Nov 2003 11:26:05 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Additional comments on draft-ietf-ipcdn-device-mibv2-06.txt Date: Wed, 26 Nov 2003 11:26:05 -0700 Message-ID: Thread-Topic: [ipcdn] Additional comments on draft-ietf-ipcdn-device-mibv2-06.txt Thread-Index: AcO0RYk04NhwPw1sR/K6ihSBoWG3wQAA0PIA From: "Eduardo Cardona" To: "Randy Presuhn" , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi,=20 I think this also affects DOCS-IETF-SUBMGT-MIB Current DOCS-IETF-SUBMGT-MIB do not have imports for DIFFSERV-MIB,=20 whishes to have something like * FROM DIFFSERV-MIB -- :) Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Wednesday, November 26, 2003 10:49 AM To: ipcdn@ietf.org Subject: [ipcdn] Additional comments on draft-ietf-ipcdn-device-mibv2-06.txt Hi - Bert Wijnen ran SMICng on the MIB module in draft-ietf-ipcdn-device-mibv2-06.txt and found some items that I overlooked: > E: f(ipcdndevice.mi2), (1342,1) Row "docsDevFilterIpEntry" must have > same status as parent table "docsDevFilterIpTable" This must be fixed. > E: f(ipcdndevice.mi2), (2389,12) Item "diffServMIBDataPathGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2390,12) Item "diffServMIBClfrGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2391,12) Item "diffServMIBClfrElementGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2392,12) Item "diffServMIBMultiFieldClfrGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2393,12) Item "diffServMIBActionGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2394,12) Item "diffServMIBDscpMarkActGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2395,12) Item "diffServMIBCounterGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2396,12) Item "diffServMIBAlgDropGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2399,8) Item "diffServDataPathStatus" should be IMPORTed > E: f(ipcdndevice.mi2), (2406,8) Item "diffServClfrStatus" should be IMPORTed > E: f(ipcdndevice.mi2), (2413,8) Item "diffServClfrElementStatus" should be IMPORTed > E: f(ipcdndevice.mi2), (2420,8) Item "diffServMultiFieldClfrAddrType" should be IMPORTed > E: f(ipcdndevice.mi2), (2426,8) Item "diffServMultiFieldClfrSrcAddr" should be IMPORTed > E: f(ipcdndevice.mi2), (2433,8) Item "diffServMultiFieldClfrDstAddr" should be IMPORTed > E: f(ipcdndevice.mi2), (2439,8) Item "diffServAlgDropStatus" should be IMPORTed > E: f(ipcdndevice.mi2), (2446,8) Item "diffServDataPathStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2452,8) Item "diffServClfrStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2458,8) Item "diffServClfrElementStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2464,8) Item "diffServMultiFieldClfrStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2470,8) Item "diffServActionStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2476,8) Item "diffServCountActStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2482,8) Item "diffServAlgDropStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2488,8) Item "diffServAlgDropType" should be > IMPORTed The MIB review guidelines recommend that these be imported. This is not a hard requirement, but the consensus of the MIB reviewer mailing list was that having IMPORTS for these makes it easier for someone reading a module to see the dependencies in one place. Since this is an update to an existing specification, I'm also going to run it through smidiff, and will post comments regarding those results in a separate message. Randy _______________________________________________ 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 exim@www1.ietf.org Wed Nov 26 14:15:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22403 for ; Wed, 26 Nov 2003 14:15:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP57z-00027f-Br for ipcdn-archive@odin.ietf.org; Wed, 26 Nov 2003 14:15:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQJF73P008153 for ipcdn-archive@odin.ietf.org; Wed, 26 Nov 2003 14:15:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP57t-000272-OS; Wed, 26 Nov 2003 14:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP57m-00026k-Eg for ipcdn@optimus.ietf.org; Wed, 26 Nov 2003 14:14:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22372 for ; Wed, 26 Nov 2003 14:14:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP57j-000349-00 for ipcdn@ietf.org; Wed, 26 Nov 2003 14:14:52 -0500 Received: from outmail1.comcast.com ([208.17.34.25] helo=oakavux02.cable.comcast.com) by ietf-mx with esmtp (Exim 4.12) id 1AP57j-00033P-00 for ipcdn@ietf.org; Wed, 26 Nov 2003 14:14:51 -0500 Received: from OAKEXSMTP01.cable.comcast.com (localhost [127.0.0.1]) by oakavux02.cable.comcast.com (8.11.7+Sun/8.11.6) with ESMTP id hAQJEJ120804; Wed, 26 Nov 2003 14:14:19 -0500 (EST) Received: by oakexsmtp01.cable.comcast.com with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Nov 2003 14:13:49 -0500 Message-ID: From: "Woundy, Richard" To: "'Randy Presuhn '" Cc: "'ipcdn@ietf.org '" Subject: RE: [ipcdn] Additional comments on draft-ietf-ipcdn-device-mibv2- 06.txt Date: Wed, 26 Nov 2003 14:12:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Randy, I can tackle these comments right away. The first SMICng error is because the STATUS of docsDevFilterIpTable is "current", but it should be "deprecated". My bad. I'll handle the other SMICng errors by IMPORTing the appropriate DiffServ MIB object, as you recommend. -- Rich -----Original Message----- From: Randy Presuhn To: ipcdn@ietf.org Sent: 11/26/2003 12:49 PM Subject: [ipcdn] Additional comments on draft-ietf-ipcdn-device-mibv2-06.txt Hi - Bert Wijnen ran SMICng on the MIB module in draft-ietf-ipcdn-device-mibv2-06.txt and found some items that I overlooked: > E: f(ipcdndevice.mi2), (1342,1) Row "docsDevFilterIpEntry" must have > same status as parent table "docsDevFilterIpTable" This must be fixed. > E: f(ipcdndevice.mi2), (2389,12) Item "diffServMIBDataPathGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2390,12) Item "diffServMIBClfrGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2391,12) Item "diffServMIBClfrElementGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2392,12) Item "diffServMIBMultiFieldClfrGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2393,12) Item "diffServMIBActionGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2394,12) Item "diffServMIBDscpMarkActGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2395,12) Item "diffServMIBCounterGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2396,12) Item "diffServMIBAlgDropGroup" should be IMPORTed > E: f(ipcdndevice.mi2), (2399,8) Item "diffServDataPathStatus" should be IMPORTed > E: f(ipcdndevice.mi2), (2406,8) Item "diffServClfrStatus" should be IMPORTed > E: f(ipcdndevice.mi2), (2413,8) Item "diffServClfrElementStatus" should be IMPORTed > E: f(ipcdndevice.mi2), (2420,8) Item "diffServMultiFieldClfrAddrType" should be IMPORTed > E: f(ipcdndevice.mi2), (2426,8) Item "diffServMultiFieldClfrSrcAddr" should be IMPORTed > E: f(ipcdndevice.mi2), (2433,8) Item "diffServMultiFieldClfrDstAddr" should be IMPORTed > E: f(ipcdndevice.mi2), (2439,8) Item "diffServAlgDropStatus" should be IMPORTed > E: f(ipcdndevice.mi2), (2446,8) Item "diffServDataPathStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2452,8) Item "diffServClfrStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2458,8) Item "diffServClfrElementStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2464,8) Item "diffServMultiFieldClfrStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2470,8) Item "diffServActionStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2476,8) Item "diffServCountActStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2482,8) Item "diffServAlgDropStorage" should be IMPORTed > E: f(ipcdndevice.mi2), (2488,8) Item "diffServAlgDropType" should be IMPORTed The MIB review guidelines recommend that these be imported. This is not a hard requirement, but the consensus of the MIB reviewer mailing list was that having IMPORTS for these makes it easier for someone reading a module to see the dependencies in one place. Since this is an update to an existing specification, I'm also going to run it through smidiff, and will post comments regarding those results in a separate message. Randy _______________________________________________ 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 exim@www1.ietf.org Thu Nov 27 18:35:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22910 for ; Thu, 27 Nov 2003 18:35:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APVf8-0008Ed-R2 for ipcdn-archive@odin.ietf.org; Thu, 27 Nov 2003 18:35:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hARNZ6YQ031649 for ipcdn-archive@odin.ietf.org; Thu, 27 Nov 2003 18:35:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APVf4-0008EA-C6; Thu, 27 Nov 2003 18:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APVee-0008DY-JP for ipcdn@optimus.ietf.org; Thu, 27 Nov 2003 18:34:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22897 for ; Thu, 27 Nov 2003 18:34:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APVeb-0006YG-00 for ipcdn@ietf.org; Thu, 27 Nov 2003 18:34:33 -0500 Received: from mms1.broadcom.com ([63.70.210.58]) by ietf-mx with esmtp (Exim 4.12) id 1APVeZ-0006YB-00 for ipcdn@ietf.org; Thu, 27 Nov 2003 18:34:32 -0500 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Thu, 27 Nov 2003 15:34:23 -0800 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from nt-irva-0740.brcm.ad.broadcom.com ( nt-irva-0740.brcm.ad.broadcom.com [10.8.194.53]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA05867; Thu, 27 Nov 2003 15:33:53 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(5.0.2195.5329) ; Thu, 27 Nov 2003 15:34:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] FW: Publication of PacketCable IETF MIBs - Signaling MIB draft 02 Date: Thu, 27 Nov 2003 15:34:21 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B85E2F9@nt-rmna-0740.ca.broadcom.com> X-MS-Has-Attach: yes Thread-Topic: [ipcdn] FW: Publication of PacketCable IETF MIBs - Signaling MIB draft 02 Thread-Index: AcOHY69+fRNLPpV2QHON+G2L6b0YDgt2vD9Q From: "Eugene Nechamkin" To: "Beacham Gordon-CGB005" cc: "Ipcdn (E-mail)" X-OriginalArrivalTime: 27 Nov 2003 23:34:23.0034 (UTC) FILETIME=[FCCC19A0:01C3B53E] X-WSS-ID: 13D856751NS1237379-01-01 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3B53E.FC19B661" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B53E.FC19B661 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C3B53E.FC19B661" ------_=_NextPart_002_01C3B53E.FC19B661 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Gordon, =20 Attached is the document with our comments on Signaling MIB draft-02. =20 Thanks, =20 Eugene. =20 ------_=_NextPart_002_01C3B53E.FC19B661 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message
Gordon,
 
Attached = is the=20 document with our comments on Signaling MIB=20 draft-02.
 
Thanks,
 
Eugene.
 

------_=_NextPart_002_01C3B53E.FC19B661-- ------_=_NextPart_001_01C3B53E.FC19B661 Content-Type: application/msword; name="Comments on SIG MIB draft-02 (BRCM)_2003-11-27.doc" Content-Transfer-Encoding: base64 Content-Description: Comments on SIG MIB draft-02 (BRCM)_2003-11-27.doc Content-Disposition: attachment; filename="Comments on SIG MIB draft-02 (BRCM)_2003-11-27.doc" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAVgAAAAAAAAAA EAAAWAAAAAEAAAD+////AAAAAFUAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEATSAJBAAA8BK/AAAAAAAAEAAAAAAABAAATy8AAA4AYmpiauI94j0AAAAAAAAAAAAAAAAAAAAA AAAJBBYAIk4AAIBXAACAVwAATysAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAKgAAAAAAAAAqAAAAKgA AAAAAAAAqAAAAAAAAACoAAAAAAAAAKgAAAAAAAAAqAAAABQAAAAAAAAAAAAAALwAAAAAAAAALBQA AAAAAAAsFAAAAAAAACwUAAAAAAAALBQAABQAAABAFAAATAAAALwAAAAAAAAA+TQAADIBAACYFAAA AAAAAJgUAAAAAAAAmBQAAAAAAACYFAAAAAAAAJgUAAAAAAAAmBQAAAAAAACYFAAAAAAAAJgUAAAA AAAAeDQAAAIAAAB6NAAAAAAAAHo0AAAAAAAAejQAAAAAAAB6NAAAAAAAAHo0AAAAAAAAejQAACQA AAArNgAAIAIAAEs4AACKAAAAnjQAABUAAAAAAAAAAAAAAAAAAAAAAAAAqAAAAAAAAACYFAAAAAAA AAAAAAAAAAAAAAAAAAAAAACYFAAAAAAAAJgUAAAAAAAAmBQAAAAAAACYFAAAAAAAAJ40AAAAAAAA HCEAAAAAAACoAAAAAAAAAKgAAAAAAAAAmBQAAAAAAAAAAAAAAAAAAJgUAAAAAAAAszQAABYAAAAc IQAAAAAAABwhAAAAAAAAHCEAAAAAAACYFAAAngUAAKgAAAAAAAAAmBQAAAAAAACoAAAAAAAAAJgU AAAAAAAAeDQAAAAAAAAAAAAAAAAAABwhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAmBQAAAAAAAB4NAAAAAAAABwhAABUCQAAHCEAAAAAAABwKgAA cgAAAHgzAABUAAAAqAAAAAAAAACoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeDQAAAAAAACYFAAAAAAAAIwUAAAMAAAAQI8E7ju1 wwG8AAAAcBMAACwUAAAAAAAANhoAAJIFAADMMwAADgAAAAAAAAAAAAAAeDQAAAAAAADJNAAAMAAA APk0AAAAAAAA2jMAAJ4AAADVOAAAAAAAAMgfAABUAQAA1TgAAAAAAAB4NAAAAAAAABwhAAAAAAAA vAAAAAAAAAC8AAAAAAAAAKgAAAAAAAAAqAAAAAAAAACoAAAAAAAAAKgAAAAAAAAAAgDZAAAAQ29t bWVudHMgb24gU2lnbmFsaW5nIE1JQiBkcmFmdC0wMg0oQnJvYWRjb20sIDI3LU5vdi0wMykNDQ0N MS4gcGt0Y1NpZ0RldlRvbmVUeXBlDQ1hbGVydGluZ1NpZ25hbCgyOSkgc2hvdWxkIGJlIG9ic29s ZXRlIGJlY2F1c2UgdGhlIGNhZGVuY2UgaXMgYWxyZWFkeSBzcGVjaWZpZWQgYnkgRVRTSS4gSGF2 aW5nIGEgc2luZ2xlIHByb3Zpc2lvbmVkIGFsZXJ0aW5nIHNpZ25hbCBkb2VzIG5vdCBtYWtlIHNl bnNlIHNpbmNlIHRoZXJlIGFyZSBkaWZmZXJlbnQgYWxlcnRpbmcgc2lnbmFsIHJlcXVpcmVtZW50 cyBmb3Igb24taG9vayBhbmQgb2ZmLWhvb2sgZGF0YSB0cmFuc21pc3Npb24uDQ1UaGUgZm9sbG93 aW5nIERUTUYgdG9uZXMgc2hvdWxkIGJlIG9ic29sZXRlLiBUaGUgZnJlcXVlbmN5L2NhZGVuY2Ug aXMgdGhlIHNhbWUgZm9yIGFsbCBFVFNJIGNvdW50cmllcy4gVGhlcmVmb3JlLCB0aGVyZSBpcyBu byBiZW5lZml0IHRvIGhhdmluZyB0aGVtIGluIHRoZSB0b25lIHRhYmxlLg0gICAgICAgICAgICAg ICAgIGR0bWYwKDApLCALICAgICAgICAgICAgICAgICBkdG1mMSgxKSwgCyAgICAgICAgICAgICAg ICAgZHRtZjIoMiksIAsgICAgICAgICAgICAgICAgIGR0bWYzKDMpLCALICAgICAgICAgICAgICAg ICBkdG1mNCg0KSwgCyAgICAgICAgICAgICAgICAgZHRtZjUoNSksIAsgICAgICAgICAgICAgICAg IGR0bWY2KDYpLCALICAgICAgICAgICAgICAgICBkdG1mNyg3KSwgCyAgICAgICAgICAgICAgICAg ZHRtZjgoOCksIAsgICAgICAgICAgICAgICAgIGR0bWY5KDkpLCALICAgICAgICAgICAgICAgICBk dG1mVG9uZVN0YXIoMTApLCALICAgICAgICAgICAgICAgICBkdG1mVG9uZVBvdW5kKDExKSwgCyAg ICAgICAgICAgICAgICAgZHRtZkEoMTIpLCALICAgICAgICAgICAgICAgICBkdG1mQigxMyksIAsg ICAgICAgICAgICAgICAgIGR0bWZDKDE0KSwgCyAgICAgICAgICAgICAgICAgZHRtZkQoMTUpLCAL DVRoZSBmb2xsb3dpbmcgdG9uZXMgc2hvdWxkIGJlIG9ic29sZXRlIHNpbmNlIHRoZXkgY2Fubm90 IGJlIHNpZ25hbGVkIHRocm91Z2ggTkNTOg0NICAgICAgICAgICAgICAgICBsb29wYmFjaygyNCks IAsgICAgICAgICAgICAgICAgIHRlc3RUb25lKDMwKSwgCyAgICAgICAgICAgICAgICAgc3BlY2lh bERpYWwoMzEpLCALICAgICAgICAgICAgICAgICBzcGVjaWFsSW5mbygzMiksIAsgICAgICAgICAg ICAgICAgIHJlbGVhc2UoMzMpLCALICAgICAgICAgICAgICAgICBjb25nZXN0aW9uKDM0KSwgCyAg ICAgICAgICAgICAgICAgdXNlckRlZmluZWQxKDM1KSwgCyAgICAgICAgICAgICAgICAgdXNlckRl ZmluZWQyKDM2KSwgCyAgICAgICAgICAgICAgICAgdXNlckRlZmluZWQzKDM3KSwgCyAgICAgICAg ICAgICAgICAgdXNlckRlZmluZWQ0KDM4KQsNDTIuIHBrdGNTaWdEZXZWbXdpTW9kZQ0NTmV3IFZN V0kgbW9kZSAoT1NJKSBpcyByZXF1aXJlZCB0byBzdXBwb3J0IE5vcnRoIEFtZXJpY2FuIFZNV0ku DQ1wa3RjU2lnRGV2Vm13aU1vZGUgICAgT0JKRUNULVRZUEUgCyAgICBTWU5UQVggICAgICAgSU5U RUdFUiB7CyAgICAgICAgICAgICAgICAgZHRBc0VUUygxKSwLICAgICAgICAgICAgICAgICBycEFz RVRTKDIpLAsgICAgICAgICAgICAgICAgIGxyQXNFVFMoMyksDQkJICAgb3NpKDQpCyAgICAgICAg ICAgICAgICAgfQsgICAgTUFYLUFDQ0VTUyByZWFkLXdyaXRlCyAgICBTVEFUVVMgY3VycmVudCAL ICAgIERFU0NSSVBUSU9OIAsgICAgICAgICIgRm9yIHZpc3VhbCBtZXNzYWdlIHdhaXRpbmcgaW5k aWNhdG9yIChWTVdJKSwgcGt0Y1NpZ0RldlZtd2lNb2RlCyAgICAgICAgICBzZWxlY3RzIHRoZSBh bGVydGluZyBzaWduYWwgbWV0aG9kLiBGb3IgdGhlIGR0QXNFVFMsCyAgICAgICAgICBycEFzRVRT LCBsckFzRVRTLCBhbmQgT1NJIG1ldGhvZHMsIHRoZSBGU0sgY29udGFpbmluZyB0aGULICAgICAg ICAgIFZNV0kgaW5mb3JtYXRpb24gaXMgc2VudCBhZnRlciBhbiBhbGVydGluZyBzaWduYWwuIEZv ciB0aGULICAgICAgICAgIGR0QXNFVFMgbWV0aG9kLCB0aGUgRlNLIGlzIHNlbnQgYWZ0ZXIgdGhl IER1YWwgVG9uZSBBbGVydAsgICAgICAgICAgU2lnbmFsLiBGb3IgdGhlIHJwQXNFVFMgbWV0aG9k LCB0aGUgRlNLIGlzIHNlbnQgYWZ0ZXIgYQsgICAgICAgICAgUmluZyBQdWxzZS4gRm9yIHRoZSBs ckFzRVRTIG1ldGhvZCwgdGhlIExpbmUgUmV2ZXJzYWwLICAgICAgICAgIG9jY3VycyBmaXJzdCwg dGhlbiB0aGUgRHVhbCBUb25lIEFsZXJ0IFNpZ25hbCwgYW5kIGZpbmFsbHkLICAgICAgICAgIHRo ZSBGU0sgaXMgc2VudC4gRm9yIHRoZSBPU0kgbWV0aG9kLCB0aGUgRlNLIGlzIHNlbnQgYWZ0ZXIN ICAgICAgICAgIHRoZSBPcGVuIFN3aXRjaGluZyBJbnRlcnZhbC4iCyAgICBERUZWQUwgeyBkdEFz RVRTIH0gCyAgICA6Oj0ge3BrdGNTaWdEZXZDb25maWdPYmplY3RzIDMyIH0gCw0NDTMuIHBrdGNT aWdEZXZUb25lRGJMZXZlbA0NQ2xhcmlmaWNhdGlvbiBpcyByZXF1aXJlZCBmb3IgdG9uZSBkQiBs ZXZlbC4NDXBrdGNTaWdEZXZUb25lRGJMZXZlbCAgICBPQkpFQ1QtVFlQRSALICAgIFNZTlRBWCAg ICAgICBJbnRlZ2VyMzIgKC02MC4uNCkgCyAgICBVTklUUyAgICAgICAgImRibSIgCyAgICBNQVgt QUNDRVNTICAgcmVhZC13cml0ZSALICAgIFNUQVRVUyAgICAgICBjdXJyZW50IAsgICAgREVTQ1JJ UFRJT04gCyAgICAgICAgICAgICAgIiBUaGlzIGlzIHRoZSBkZWNpYmVsIGxldmVsIGZvciBlYWNo IGZyZXF1ZW5jeSBhdCB3aGljaCB0b25lcyBzaG91bGQgYmULICAgICAgICAgICAgICBnZW5lcmF0 ZWQgYXQgdGhlIGEgYW5kIGIgdGVybWluYWxzIChURSBjb25uZWN0aW9uIHBvaW50KS4iIAsgICAg REVGVkFMIHsgLTQgfSALICAgIDo6PXtwa3RjU2lnRGV2VG9uZUVudHJ5IDIgfSALDQ0NNC4gcGt0 Y1NpZ1B1bHNlU2lnbmFsVGFibGUNDVRoZSBjdXJyZW50IGRlZmluaXRpb24gb2YgdGhlIHRhYmxl IGlzIG5vdCBjb21wbGV0ZWx5IGNvbnNpc3RlbnQgd2l0aCB0aGUgRVRTSSByZXF1aXJlbWVudHMs IHBhcnRpY3VsYXJseSB3aXRoIHRoZSBudW1iZXIgb2YgdGhlIFB1bHNlIFNpZ25hbCBUeXBlIGRl ZmluZWQuIEFsc28sIHNvbWUgcmFuZ2UgdmFsdWVzIG9mIHRoZSBNSUIgT2JqZWN0cyBhbmQgdGhl IHByZXNlbmNlIG9mIHRoZSBERUZWQUwgY2xhdXNlIGRvIG5vdCBtYWtlIHNlbnNlIGluIHRoZSBj b250ZXh0IG9mIHRoZSB0YWJsZS4NVGhlIGZvbGxvd2luZyB0YWJsZSBkZWZpbml0aW9uIGlzIHBy b3Bvc2VkICh3aXRoIGNoYW5nZXMgaW4gYmx1ZSBhbmQgc3RyaWtldGhyb3VnaCB0ZXh0KToNDQ1w a3RjU2lnUHVsc2VTaWduYWxUYWJsZSAgICBPQkpFQ1QtVFlQRSAgDSAgICAgICBTWU5UQVggICAg ICAgU0VRVUVOQ0UgT0YgUGt0Y1NpZ1B1bHNlU2lnbmFsRW50cnkgIA0gICAgICAgTUFYLUFDQ0VT UyAgIG5vdC1hY2Nlc3NpYmxlICANICAgICAgIFNUQVRVUyAgICAgICBjdXJyZW50ICANICAgICAg IERFU0NSSVBUSU9OICANICAgICAgICAgICAiIFRoZSBQdWxzZSBzaWduYWwgdGFibGUgZGVmaW5l cyB0aGUgcHVsc2Ugc2lnbmFsIG9wZXJhdGlvbi4gDSAgICAgICAgICAgICBUaGVyZSBhcmUgbmlu ZSB0eXBlcyBvZiBpbnRlcm5hdGlvbmFsIHB1bHNlIHNpZ25hbHMsIHdpdGgNICAgICAgICAgICAg IGVhY2ggc2lnbmFsIGhhdmluZyBhIHNldCBvZiBwcm92aXNpb25hYmxlIHBhcmFtZXRlcnMuDSAg ICAgICAgICAgICBPYmplY3RzIGluIHRoaXMgdGFibGUgZG8gbm90IHBlcnNpc3QgYWNyb3NzIE1U QSByZWJvb3RzLg0gICAgICAgICAgICAgVGhlIHZhbHVlcyBvZiB0aGUgTUlCIE9iamVjdHMgaW4g dGhlIHRhYmxlIGFyZSB0YWtpbmcgYWZmZWN0IA0gICAgICAgICAgICAgb25seSBpcyB0aGVzZSBw YXJhbWV0ZXJzIGFyZSBub3QgZGVmaW5lZCB2aWEgdGhlIHNpZ25hbGluZywNICAgICAgICAgICAg IGluIHdoaWNoIGNhc2UgdGhlIGxhdHRlciBkZXRlcm1pbmVzIHRoZSB2YWx1ZXMgb2YgdGhlIA0g ICAgICAgICAgICAgcGFyYW1ldGVycy4iDSAgICAgICA6Oj0geyBwa3RjU2lnRGV2Q29uZmlnT2Jq ZWN0cyAyNSB9ICANDSAgIHBrdGNTaWdQdWxzZVNpZ25hbEVudHJ5ICAgIE9CSkVDVC1UWVBFICAN ICAgICAgIFNZTlRBWCAgICAgICBQa3RjU2lnUHVsc2VTaWduYWxFbnRyeSAgDSAgICAgICBNQVgt QUNDRVNTICAgbm90LWFjY2Vzc2libGUgIA0gICAgICAgU1RBVFVTICAgICAgIGN1cnJlbnQgIA0g ICAgICAgREVTQ1JJUFRJT04gIA0gICAgICAgICAgICIgVGhpcyBvYmplY3QgZGVmaW5lcyB0aGUg c2V0IG9mIHRoZSBwYXJhbWV0ZXJzIGFzc29jaWF0ZWQgDSAgICAgICAgICAgICB3aXRoIGVhY2gg cGFydGljdWxhciB2YWx1ZSBvZiBQdWxzZSBTaWduYWwgVHlwZS4gRWFjaA0gICAgICAgICAgICAg ZW50cnkgaW4gdGhlIHBrdGNTaWdQdWxzZVNpZ25hbFRhYmxlIGlzIGluZGV4ZWQgYnkgDSAgICAg ICAgICAgICBwa3RjU2lnUHVsc2VTaWduYWxUeXBlIE1JQiBPYmplY3QuIg0gICAgICAgSU5ERVgg eyBwa3RjU2lnUHVsc2VTaWduYWxUeXBlIH0gICAgICAgICAgICAgICAgICAgICANICAgICAgIDo6 PSB7IHBrdGNTaWdQdWxzZVNpZ25hbFRhYmxlIDEgfSAgDQ0NICAgUGt0Y1NpZ1B1bHNlU2lnbmFs RW50cnkgOjo9IFNFUVVFTkNFIHsgIA0gICAgICAgICAgIHBrdGNTaWdQdWxzZVNpZ25hbEluZGV4 ICAgICAgICAgVW5zaWduZWQzMiwgIA0gICAgICAgICAgIHBrdGNTaWdQdWxzZVNpZ25hbFR5cGUg ICAgICAgICAgSU5URUdFUiwgIA0gICAgICAgICAgIHBrdGNTaWdQdWxzZVNpZ25hbEZyZXF1ZW5j eSAgICAgSU5URUdFUiwgIA0gICAgICAgICAgIHBrdGNTaWdQdWxzZVNpZ25hbERiTGV2ZWwgICAg ICAgVGVudGhkQm0sICANICAgICAgICAgICBwa3RjU2lnUHVsc2VTaWduYWxEdXJhdGlvbiAgICAg IFVuc2lnbmVkMzIsICANICAgICAgICAgICBwa3RjU2lnUHVsc2VTaWduYWxQdWxzZUludGVydmFs IFVuc2lnbmVkMzIsDSAgICAgICAgICAgcGt0Y1NpZ1B1bHNlU2lnbmFsUmVwZWF0Q291bnQgICBV bnNpZ25lZDMyICANICAgfSANDSAgcGt0Y1NpZ1B1bHNlU2lnbmFsVHlwZSAgICBPQkpFQ1QtVFlQ RSAgDSAgICAgICBTWU5UQVggICAgICAgSU5URUdFUiAgew0gICAgICAgICAgIGluaXRpYWxSaW5n ICAgICAgICAgICgxKSwgIA0gICAgICAgICAgIHB1bHNlTG9vcENsb3NlICAgICAgICgyKSwNICAg ICAgICAgICBwdWxzZUxvb3BPcGVuICAgICAgICAoMyksDSAgICAgICAgICAgZW5hYmxlTWV0ZXJQ dWxzZSAgICAgKDQpLA0gICAgICAgICAgIG1ldGVyUHVsc2VCdXJzdCAgICAgICg1KSwNICAgICAg ICAgICBwdWxzZU5vQmF0dGVyeSAgICAgICAoNiksDSAgICAgICAgICAgcHVsc2VOb3JtYWxQb2xh cml0eSAgKDcpLA0gICAgICAgICAgIHB1bHNlUmVkdWNlZEJhdHRlcnkgICg4KSwNICAgICAgICAg ICBwdWxzZVJldmVyc2VQb2xhcml0eSAoOSkNICAgICAgIH0gIA0gICAgICAgTUFYLUFDQ0VTUyAg IG5vdC1hY2Nlc3NpYmxlICANICAgICAgIFNUQVRVUyAgICAgICBjdXJyZW50ICANICAgICAgIERF U0NSSVBUSU9OICANICAgICAgICAgICAiIFRoZXJlIGFyZSBuaW5lIHR5cGVzIG9mIGludGVybmF0 aW9uYWwgcHVsc2Ugc2lnbmFscy4iICANICAgICAgIFJFRkVSRU5DRSAgDSAgICAgICAgICAgIkVO IDMwMCAwMDEgU3BlY2lmaWNhdGlvbiINICAgICAgIERFRlZBTCB7IGluaXRpYWxSaW5nIH0gIA0g ICAgICAgOjo9IHsgcGt0Y1NpZ1B1bHNlU2lnbmFsRW50cnkgMSB9ICANDSAgcGt0Y1NpZ1B1bHNl U2lnbmFsRnJlcXVlbmN5ICAgIE9CSkVDVC1UWVBFICANICAgICAgIFNZTlRBWCAgICAgICBJTlRF R0VSIHsNICAgICAgICAgICAgICAgICAgICB6ZXJvICgxKSwgIA0gICAgICAgICAgICAgICAgICAg IHR3ZW50eWZpdmUgICAgICAoMSksDSAgICAgICAgICAgICAgICAgICAgdHdlbHZldGhvdXNhbmQg ICgyKSwNICAgICAgICAgICAgICAgICAgICBzaXh0ZWVudGhvdXNhbmQgKDMpDSAgICAgICB9DSAg ICAgICBVTklUUyAgICAgICAgIkhlcnR6IiAgDSAgICAgICBNQVgtQUNDRVNTICAgcmVhZC13cml0 ZSAgDSAgICAgICBTVEFUVVMgICAgICAgY3VycmVudCAgDSAgICAgICBERVNDUklQVElPTiAgDSAg ICAgICAgICAgIiBUaGlzIG9iamVjdCBpcyBvbmx5IGFwcGxpY2FibGUgdG8gdGhlIGluaXRpYWxS aW5nLCANICAgICAgICAgICBlbmFibGVNZXRlclB1bHNlLCBhbmQgbWV0ZXJQdWxzZUJ1cnN0IHNp Z25hbCB0eXBlLg0gICAgICAgICAgIFRoaXMgb2JqZWN0IGlkZW50aWZpZXMgdGhlIGZyZXF1ZW5j eSBvZiB0aGUgZ2VuZXJhdGVkDSAgICAgICAgICAgc2lnbmFsLiBUaGUgZm9sbG93aW5nIHRhYmxl IGRlZmluZXMgdGhlIGRlZmF1bHQgdmFsdWVzDSAgICAgICAgICAgb2YgdGhpcyBvYmplY3QgZGVw ZW5kaW5nIG9uIHRoZSBzaWduYWwgdHlwZS4NDSAgICAgICAgICAgU0lHTkFMIFRZUEUgICAgICBE RUZBVUxUICAgIA0gICAgICAgICAgID09PT09PT09PT09PT09PT09PT09PT09PT09PT0NICAgICAg ICAgICBpbml0aWFsUmluZyAgICAgIDI1IA0gICAgICAgICAgIGVuYWJsZU1ldGVyUHVsc2UgMTYw MDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DSAgICAgICAgICAgbWV0ZXJQdWxzZUJ1cnN0ICAxNjAwMCANICANICAgICAgICAgICBUaGUgdmFs dWUgb2YgJ3R3ZW50eWZpdmUoMSknIG11c3QgYmUgdXNlZCBmb3IgaW5pdGlhbFJpbmcgDSAgICAg ICAgICAgc2lnbmFsIHR5cGUgb25seSwgdGhlIHZhbHVlcyBvZiAndHdlbHZldGhvdXNhbmQoMikn IGFuZCANICAgICAgICAgICBzaXh0ZWVudGhvdXNhbmQoMykgbXVzdCBiZSB1c2VkIGZvciBlbmFi bGVNZXRlclB1bHNlIGFuZA0gICAgICAgICAgIG1ldGVyUHVsc2VCdXJzdCBzaWduYWwgdHlwZXMg b25seS4iDSAgICAgICBSRUZFUkVOQ0UNICAgICAgICAgICAiRU4gMzAwIDAwMSBTcGVjaWZpY2F0 aW9uIiANICAgICAgIDo6PSB7IHBrdGNTaWdQdWxzZVNpZ25hbEVudHJ5IDJ9ICANDQ0gIHBrdGNT aWdQdWxzZVNpZ25hbERiTGV2ZWwgICAgT0JKRUNULVRZUEUgIA0gICAgICAgU1lOVEFYICAgICAg IFRlbnRoZEJtICgtMjUuLjE1LjIpICANICAgICAgIFVOSVRTICAgICAgICAiZGJtIiAgDSAgICAg ICBNQVgtQUNDRVNTICAgcmVhZC13cml0ZSAgDSAgICAgICBTVEFUVVMgICAgICAgY3VycmVudCAg DSAgICAgICBERVNDUklQVElPTiAgDSAgICAgICAgICAgIiBUaGlzIG9iamVjdCBpcyBvbmx5IGFw cGxpY2FibGUgdG8gdGhlIGVuYWJsZU1ldGVyUHVsc2UgDSAgICAgICAgICAgYW5kIG1ldGVyUHVs c2VCdXJzdCBzaWduYWwgdHlwZS4gIFRoaXMgb2JqZWN0IGlzIHVzZWQNICAgICAgICAgICB0byBz cGVjaWZ5IHRoZSBkZWNpYmVsIGxldmVsIGF0IHdoaWNoIHRoZSBtZXRlciBwdWxzZQ0gICAgICAg ICAgIGNvdWxkIGJlIGdlbmVyYXRlZC4iDSAgICAgICBSRUZFUkVOQ0UgIA0gICAgICAgICAgICJF TiAzMDAgMDAxIFNwZWNpZmljYXRpb24iIA0gICAgICAgREVGVkFMIHsgLTEzLjUgfSANICAgICAg IDo6PXtwa3RjU2lnUHVsc2VTaWduYWxFbnRyeSAzfSAgDQ0gIHBrdGNTaWdQdWxzZVNpZ25hbER1 cmF0aW9uICAgIE9CSkVDVC1UWVBFICANICAgICAgIFNZTlRBWCAgICAgICBVbnNpZ25lZDMyICgw Li41MDAwKSAgDSAgICAgICBVTklUUyAgICAgICAgIk1pbGxpc2Vjb25kcyIgIA0gICAgICAgTUFY LUFDQ0VTUyAgIHJlYWQtd3JpdGUgIA0gICAgICAgU1RBVFVTICAgICAgIGN1cnJlbnQgIA0gICAg ICAgREVTQ1JJUFRJT04gICANICAgICAgICAgICAiIFRoaXMgb2JqZWN0IHNwZWNpZmllcyB0aGUg cHVsc2UgZHVyYXRpb24gZm9yIGVhY2ggc2lnbmFsIHR5cGUuDSAgICAgICAgICAgSW4gYWRkaXRp b24sIHRoZSBNVEEgbXVzdCBhY2NlcHQgdGhlIHZhbHVlcyBpbiB0aGUgaW5jcmVtZW50YWwgDSAg ICAgICAgICAgc3RlcHMgIHNwZWNpZmljIGZvciBlYWNoIHNpZ25hbCB0eXBlLg0gICAgICAgICAg IFRoZSBmb2xsb3dpbmcgdGFibGUgZGVmaW5lcyB0aGUgZGVmYXVsdCB2YWx1ZXMgYW5kIHRoZSBp bmNyZW1lbnRhbCANICAgICAgICAgICBzdGVwcyBmb3IgdGhpcyBvYmplY3QgZGVwZW5kaW5nIG9u IHRoZSBzaWduYWwgdHlwZS4NDSAgICAgICAgICAgU0lHTkFMIFRZUEUgICAgICAgICAgREVGQVVM VCAgICAgICAgU1RFUFMNICAgICAgICAgICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DSAgICAgICAgICAgaW5pdGlhbFJpbmcgICAgICAgICAgMjAwICAgICAgICAgICAg NTANICAgICAgICAgICBwdWxzZUxvb3BDbG9zZSAgICAgICAyMDAgICAgICAgICAgICAxMA0gICAg ICAgICAgIHB1bHNlTG9vcE9wZW4gICAgICAgIDIwMCAgICAgICAgICAgIDEwDSAgICAgICAgICAg ZW5hYmxlTWV0ZXJQdWxzZSAgICAgMTUwICAgICAgICAgICAgMTANICAgICAgICAgICBtZXRlclB1 bHNlQnVyc3QgICAgICAxNTAgICAgICAgICAgICAxMA0gICAgICAgICAgIHB1bHNlTm9CYXR0ZXJ5 ICAgICAgIDIwMCAgICAgICAgICAgIDEwDSAgICAgICAgICAgcHVsc2VOb3JtYWxQb2xhcml0eSAg MjAwICAgICAgICAgICAgMTANICAgICAgICAgICBwdWxzZVJlZHVjZWRCYXR0ZXJ5ICAyMDAgICAg ICAgICAgICAxMA0gICAgICAgICAgIHB1bHNlUmV2ZXJzZVBvbGFyaXR5IDIwMCAgICAgICAgICAg IDEwIg0NICAgICAgIFJFRkVSRU5DRSAgDSAgICAgICAgICAgIkVOIDMwMCAwMDEgU3BlY2lmaWNh dGlvbiIgIA0gIDo6PSB7cGt0Y1NpZ1B1bHNlU2lnbmFsRW50cnkgNCB9DQ0gIHBrdGNTaWdQdWxz ZVNpZ25hbFB1bHNlSW50ZXJ2YWwgICAgT0JKRUNULVRZUEUgIA0gICAgICAgU1lOVEFYICAgICAg IFVuc2lnbmVkMzIgKDAuLjUwMDApICANICAgICAgIFVOSVRTICAgICAgICAiTWlsbGlzZWNvbmRz IiAgDSAgICAgICBNQVgtQUNDRVNTICAgcmVhZC13cml0ZSAgDSAgICAgICBTVEFUVVMgICAgICAg Y3VycmVudCAgDSAgICAgICBERVNDUklQVElPTiAgIA0gICAgICAgICAgICIgVGhpcyBvYmplY3Qg c3BlY2lmaWVzIHRoZSByZXBlYXQgaW50ZXJ2YWwsIG9yIHRoZSBwZXJpb2QgZm9yDSAgICAgICAg ICAgZWFjaCBzaWduYWwgdHlwZS4gIEluIGFkZGl0aW9uLCB0aGUgTVRBIG11c3QgYWNjZXB0IHRo ZSB2YWx1ZXMgDSAgICAgICAgICAgaW4gdGhlIGluY3JlbWVudGFsIHN0ZXBzICBzcGVjaWZpYyBm b3IgZWFjaCBzaWduYWwgdHlwZS4NICAgICAgICAgICBUaGUgZm9sbG93aW5nIHRhYmxlIGRlZmlu ZXMgdGhlIGRlZmF1bHQgdmFsdWVzIGFuZCB0aGUgaW5jcmVtZW50YWwgDSAgICAgICAgICAgc3Rl cHMgZm9yIHRoaXMgb2JqZWN0IGRlcGVuZGluZyBvbiB0aGUgc2lnbmFsIHR5cGUuDQ0gICAgICAg ICAgIFNJR05BTCBUWVBFICAgICAgICAgIERFRkFVTFQgICAgICAgIFNURVBTDSAgICAgICAgICAg PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0gICAgICAgICAgIGluaXRp YWxSaW5nICAgICAgICAgIDIwMCAgICAgICAgICAgIDUwDSAgICAgICAgICAgcHVsc2VMb29wQ2xv c2UgICAgICAgMTAwMCAgICAgICAgICAgMTANICAgICAgICAgICBwdWxzZUxvb3BPcGVuICAgICAg ICAxMDAwICAgICAgICAgICAxMA0gICAgICAgICAgIGVuYWJsZU1ldGVyUHVsc2UgICAgIDEwMDAg ICAgICAgICAgIDEwDSAgICAgICAgICAgbWV0ZXJQdWxzZUJ1cnN0ICAgICAgMTAwMCAgICAgICAg ICAgMTANICAgICAgICAgICBwdWxzZU5vQmF0dGVyeSAgICAgICAxMDAwICAgICAgICAgICAxMA0g ICAgICAgICAgIHB1bHNlTm9ybWFsUG9sYXJpdHkgIDEwMDAgICAgICAgICAgIDEwDSAgICAgICAg ICAgcHVsc2VSZWR1Y2VkQmF0dGVyeSAgMTAwMCAgICAgICAgICAgMTANICAgICAgICAgICBwdWxz ZVJldmVyc2VQb2xhcml0eSAxMDAwICAgICAgICAgICAxMCINDSAgICAgICBSRUZFUkVOQ0UgIA0g ICAgICAgICAgICJFTiAzMDAgMDAxIFNwZWNpZmljYXRpb24iICANICA6Oj0ge3BrdGNTaWdQdWxz ZVNpZ25hbEVudHJ5IDUgfQ0NICBwa3RjU2lnUHVsc2VTaWduYWxSZXBlYXRDb3VudCAgICBPQkpF Q1QtVFlQRSAgDSAgICAgICBTWU5UQVggICAgICAgVW5zaWduZWQzMiAoMC4uNTAwMCkgIA0gICAg ICAgTUFYLUFDQ0VTUyAgIHJlYWQtd3JpdGUgIA0gICAgICAgU1RBVFVTICAgICAgIGN1cnJlbnQg IA0gICAgICAgREVTQ1JJUFRJT04gIA0gICAgICAgICAgICIgVGhpcyBvYmplY3Qgc3BlY2lmaWVz IGhvdyBtYW55IHRpbWVzIHRvIHJlcGVhdCBhIHB1bHNlLiAgDSAgICAgICAgICAgVGhpcyBvYmpl Y3QgaXMgbm90IGFwcGxpY2FibGUgdG8gdGhlIGVuYWJsZU1ldGVyUHVsc2Ugc2lnbmFsIA0gICAg ICAgICAgIHR5cGUuDSAgICAgICAgICAgVGhlIGZvbGxvd2luZyB0YWJsZSBkZWZpbmVzIHRoZSBk ZWZhdWx0IHZhbHVlcyBhbmQgdmFsaWQgcmFuZ2VzDSAgICAgICAgICAgZm9yIHRoaXMgb2JqZWN0 IGRlcGVuZGluZyBvbiB0aGUgc2lnbmFsIHR5cGUuDQ0gICAgICAgICAgIFNJR05BTCBUWVBFICAg ICAgICAgIERFRkFVTFQgICAgICAgIFJBTkdFDSAgICAgICAgICAgPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DSAgICAgICAgICAgaW5pdGlhbFJpbmcgICAgICAgICAg MSAgICAgICAgICAgICAgMS01DSAgICAgICAgICAgcHVsc2VMb29wQ2xvc2UgICAgICAgMSAgICAg ICAgICAgICAgMS01MA0gICAgICAgICAgIHB1bHNlTG9vcE9wZW4gICAgICAgIDEgICAgICAgICAg ICAgIDEtNTANICAgICAgICAgICBtZXRlclB1bHNlQnVyc3QgICAgICAxICAgICAgICAgICAgICAx LTUwDSAgICAgICAgICAgcHVsc2VOb0JhdHRlcnkgICAgICAgMSAgICAgICAgICAgICAgMS01MA0g ICAgICAgICAgIHB1bHNlTm9ybWFsUG9sYXJpdHkgIDEgICAgICAgICAgICAgIDEtNTANICAgICAg ICAgICBwdWxzZVJlZHVjZWRCYXR0ZXJ5ICAxICAgICAgICAgICAgICAxLTUwDSAgICAgICAgICAg cHVsc2VSZXZlcnNlUG9sYXJpdHkgMSAgICAgICAgICAgICAgMS01MCINICAgICAgIFJFRkVSRU5D RSAgDSAgICAgICAgICAgIkVOIDMwMCAwMDEgU3BlY2lmaWNhdGlvbiIgIA0gIDo6PXsgcGt0Y1Np Z1B1bHNlU2lnbmFsRW50cnkgNiB9IA0NDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAIwQAADkEAAA8BAAAUgQAAFMEAAD3BQAA zAcAAB8IAAB2CQAAdwkAAI0JAACOCQAAzgkAAM8JAABkCgAAcAoAAGcLAABuCwAA+gwAAEoNAACL DQAAjg0AAKcNAACoDQAA1A0AANYNAACBDgAAqw4AAL4OAADvDgAAHQ8AACEPAABWDwAAWA8AAHMP AADsEAAApxEAALITAADeEwAAkRQAADUVAAB/FQAAjRUAAJwVAACyFQAAsxUAAPcVAAAjFgAAWxYA AFwWAACnFwAA+vcA8QDu4+7j7vEA7gDj1OPU49TjAPEA7gDj7s3uze7jAPEAwrPCqp2znaqdkKrC hMKzAAAAAAAXNwiBQ0oSAE9KAwBRSgMAXkoDAGFKFAAZQioFQ0oSAE9KAwBRSgMAXkoDAHBo/wD/ ABlCKgJDShIAT0oDAFFKAwBeSgMAcGgAAP8AEENKEgBPSgMAUUoDAF5KAwAAHUIqAkNKEgBPSgMA UUoDAF5KAwBhShQAcGgAAP8AFENKEgBPSgMAUUoDAF5KAwBhShQAAA1CKgZhShIAcGj/AAAAHUIq BkNKEgBPSgMAUUoDAF5KAwBhShIAcGj/AAAAFENKEgBPSgMAUUoDAF5KAwBhShIAAARhShIAAAo1 CIFDSiAAXAiBAARDSigAAAo1CIFDSiwAXAiBMwAEAAAjBAAAOQQAADoEAAA7BAAAPAQAAFIEAABT BAAATgUAAE8FAAD3BQAAzQcAAB8IAAAgCAAAdgkAAHcJAACNCQAAjgkAAM4JAADPCQAAZAoAACQN AACMDQAAjQ0AAI4NAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD4AAAA AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA7gAAAAAAAAAA AAAAAOgAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA3gAAAAAAAAAAAAAAANQAAAAAAAAAAAAAAADo AAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAA AAAAAAAAAOgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAA AAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAA CiYAC0YEADckADgkAEgkAAoAAA+EaAE3JAA4JABIJABehGgBBgAANyQAOCQASCQAAAkAAAomAAtG AwA3JAA4JABIJAAAAQAAAAQAAAMkAWEkAQAYAAQAAE8vAAD+AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQGODQAApw0AAKgNAADVDQAA1g0AAFYPAABXDwAAWA8A AHMPAAB0DwAAkBAAAOoQAADrEAAA7BAAABURAABPEQAAdBEAAJIRAACnEQAA8BEAADcSAAB6EgAA wBIAAAsTAABUEwAAmBMAALITAADeEwAA3xMAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAA AAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA AAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcA AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAYAADckADgkAEgkAAABAAAAHN8TAAALFAAAORQAAF4UAAB8FAAAkRQAANgUAAAbFQAA XBUAAI0VAADKFQAA9RUAAPYVAAD3FQAAIxYAAFwWAACSFgAAyBYAAP8WAAA4FwAAbxcAAKcXAACt FwAArhcAANgXAAD3FwAAHhgAAEMYAABoGAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAA AAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA AAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAA AAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAABgAANyQAOCQASCQAAAEAAAAcpxcAAKoXAACtFwAArhcAAPcXAABFGQAAZBkAAHIZAACo GQAA7RkAACYaAABFGgAAaxoAAGwaAABxGgAAchoAAL8aAADfGgAACBsAANQbAAD7HgAAWB8AAFkf AABdHwAAXx8AAKkfAACzHwAAJyAAAA4hAABYIQAAXSEAAIQhAACFIQAAiSEAAIohAADYIQAA3yEA AF0iAADhJQAAOyYAAD0mAAA/JgAAQCYAAAsrAAAMKwAAXCsAAGUrAABnKwAAvCsAACgvAABHLwAA SS8AAE4vAABPLwAA8OXc5c3lzeXN5cHl8OXc5cHN5c3lzeXc5c3lzeXN5c3l3OXN5c3lzeXczdzl wbDlzeXN5dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACA3CIFCKgxDShIAT0oDAFFKAwBeSgMA YUoUAHBogACAAAAXNwiBQ0oSAE9KAwBRSgMAXkoDAGFKFAAdQioCQ0oSAE9KAwBRSgMAXkoDAGFK FABwaAAA/wAQQ0oSAE9KAwBRSgMAXkoDAAAUQ0oSAE9KAwBRSgMAXkoDAGFKFAAAHUIqDENKEgBP SgMAUUoDAF5KAwBhShQAcGiAAIAAADVoGAAAjRgAALIYAADXGAAA/BgAACEZAABFGQAAUBkAAHUZ AACTGQAAqBkAAO0ZAAAAGgAAJhoAAEYaAABxGgAAchoAAKEaAAC/GgAA3xoAAAgbAAAxGwAAWRsA AGIbAACAGwAAoRsAAL8bAADUGwAAFRwAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABAAAGAAA3JAA4JABIJAAAHBUcAABTHAAAlBwAANYcAAAOHQAADx0AADcdAABfHQAAfx0A ANgdAAD7HQAA/h0AAEQeAACIHgAAzB4AAPseAAAMHwAAMx8AAF0fAABeHwAAXx8AAIwfAAC3HwAA 0x8AAPQfAAASIAAAJyAAAGwgAACtIAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAEAAAYAADckADgkAEgkAAAcrSAAAO4gAAAOIQAAISEAAEghAABhIQAAiSEAAIohAAC4IQAA 4yEAAAgiAAApIgAARyIAAF0iAACpIgAA9CIAACUjAAB0IwAAsyMAALQjAADpIwAAHSQAAE8kAACB JAAAsyQAAOUkAAAXJQAASSUAAHslAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAQAABgAANyQAOCQASCQAABx7JQAArSUAAOAlAADhJQAA9CUAABwmAAA/JgAAQCYAAHMmAACe JgAAwyYAAOQmAAACJwAAGCcAAGInAACtJwAA8ScAAEAoAAB/KAAAgCgAALUoAADpKAAAGykAAE0p AAB/KQAAsSkAAOMpAAAVKgAARyoAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAAGAAA3JAA4JABIJAAAHEcqAAB5KgAArCoAAK0qAADAKgAA6CoAAAsrAAAMKwAAPSsAAGgr AACJKwAApysAALwrAAADLAAATCwAAF0sAACoLAAA4SwAAOIsAAAXLQAATS0AAIAtAAC0LQAA6C0A ABwuAABQLgAAhC4AALguAADtLgAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEAAAYAADckADgkAEgkAAAc7S4AAAAvAAAoLwAATC8AAE0vAABOLwAATy8AAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AQAABgAANyQAOCQASCQAAAYgADGQaAEfsNAvILDgPSGwCAcisAgHI5CgBSSQoAUlsAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABQADwAKAAEAaQAPAAMAAAAAAAAAAAA4AABA8f8CADgADAAGAE4AbwBy AG0AYQBsAAAAAgAAABgAQ0oYAF9IAQRhShgAbUgJBHNICQR0SAkEAAAAAAAAAAAAAAAAAAAAAAAA PABBQPL/oQA8AAwAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0 AAAAAAAAAAAAAAAAAAAAAABPKwAABwAATgAACAD/////AAAAACMAAAA5AAAAOgAAADsAAAA8AAAA UgAAAFMAAABOAQAATwEAAPcBAADNAwAAHwQAACAEAAB2BQAAdwUAAI0FAACOBQAAzgUAAM8FAABk BgAAJAkAAIwJAACNCQAAjgkAAKcJAACoCQAA1QkAANYJAABWCwAAVwsAAFgLAABzCwAAdAsAAJAM AADqDAAA6wwAAOwMAAAVDQAATw0AAHQNAACSDQAApw0AAPANAAA3DgAAeg4AAMAOAAALDwAAVA8A AJgPAACyDwAA3g8AAN8PAAALEAAAORAAAF4QAAB8EAAAkRAAANgQAAAbEQAAXBEAAI0RAADKEQAA 9REAAPYRAAD3EQAAIxIAAFwSAACSEgAAyBIAAP8SAAA4EwAAbxMAAKcTAACtEwAArhMAANgTAAD3 EwAAHhQAAEMUAABoFAAAjRQAALIUAADXFAAA/BQAACEVAABFFQAAUBUAAHUVAACTFQAAqBUAAO0V AAAAFgAAJhYAAEYWAABxFgAAchYAAKEWAAC/FgAA3xYAAAgXAAAxFwAAWRcAAGIXAACAFwAAoRcA AL8XAADUFwAAFRgAAFMYAACUGAAA1hgAAA4ZAAAPGQAANxkAAF8ZAAB/GQAA2BkAAPsZAAD+GQAA RBoAAIgaAADMGgAA+xoAAAwbAAAzGwAAXRsAAF4bAABfGwAAjBsAALcbAADTGwAA9BsAABIcAAAn HAAAbBwAAK0cAADuHAAADh0AACEdAABIHQAAYR0AAIkdAACKHQAAuB0AAOMdAAAIHgAAKR4AAEce AABdHgAAqR4AAPQeAAAlHwAAdB8AALMfAAC0HwAA6R8AAB0gAABPIAAAgSAAALMgAADlIAAAFyEA AEkhAAB7IQAArSEAAOAhAADhIQAA9CEAABwiAAA/IgAAQCIAAHMiAACeIgAAwyIAAOQiAAACIwAA GCMAAGIjAACtIwAA8SMAAEAkAAB/JAAAgCQAALUkAADpJAAAGyUAAE0lAAB/JQAAsSUAAOMlAAAV JgAARyYAAHkmAACsJgAArSYAAMAmAADoJgAACycAAAwnAAA9JwAAaCcAAIknAACnJwAAvCcAAAMo AABMKAAAXSgAAKgoAADhKAAA4igAABcpAABNKQAAgCkAALQpAADoKQAAHCoAAFAqAACEKgAAuCoA AO0qAAAAKwAAKCsAAEwrAABNKwAATisAAFErAACYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAMgADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAMgADABAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAQgADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYQAAAADAAAAAA AAAAgAAAAICYQAAAADAAAAAAAAAAgAAAAICYQAAAADAAAAAAAAAAgAAAAICYQAAAADAAAAAAAAAA gAAAAICYQAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYQAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYQAAAADAAAAAAAAAAgAAAAICYQAAAADAAAAAAAAAAgAAAAICYQAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYQAAAADAAAAAAAAAA gAAAAICYQAAAADAAAAAAAAAAgAAAAICYQAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYQAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICaAAAAADAAAAAAAAAAgAAAAIAABAAApxcA AE8vAAAbAAAAIAAAAAAEAACODQAA3xMAAGgYAAAVHAAArSAAAHslAABHKgAA7S4AAE8vAAAcAAAA HgAAAB8AAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAABAAATy8AAB0AAAAAAAAAPwAAAFEAAABT AAAAYQAAACADAAAsAwAARAMAAFEDAABpAwAAbgMAAIYDAACLAwAAowMAAKgDAADAAwAAxQMAADEE AAA5BAAAUQQAAFkEAABxBAAAfAQAAJQEAACfBAAAegUAAIwFAADPBQAA4QUAAB4GAAAlBgAAOwYA AEIGAABYBgAAXwYAAGkGAABsBgAA+QYAAAsHAABCBwAASQcAAFUHAABcBwAAXgcAAGUHAADeBwAA 5QcAADIIAAA5CAAAeAgAAH8IAABZCQAAYAkAAG0JAACECQAAkQkAAKYJAADWCQAA6wkAADMKAAA2 CgAAPAsAAE8LAABbCwAAcgsAAOwMAAADDQAANQ0AAEwNAABgDgAAbQ4AAL8PAADWDwAA4g8AAPkP AAAfEAAANhAAADURAABMEQAAaREAAH8RAACcEQAAshEAANcRAADuEQAA+hEAABESAAAuEgAARRIA AGcSAAB9EgAAnRIAALgSAADTEgAA7BIAAPMSAAD7EgAAChMAACQTAABDEwAAYhMAAHoTAACXEwAA sBMAAMYTAAACFAAADRQAACkUAAA3FAAAThQAAFsUAABzFAAAgxQAAJgUAACnFAAAvRQAAMsUAADi FAAA9RQAAAcVAAAaFQAALBUAAEAVAAA2FgAAQRYAAFMWAABqFgAAdBYAAI8WAADzFgAA/RYAABwX AAAqFwAARRcAAFQXAAAHGAAAEhgAACAYAAAwGAAANhgAAEUYAABqGQAAdRkAAIoZAACaGQAA4xkA APIZAAAXGgAAIRoAADcaAABCGgAAcBoAAH4aAACTGgAAohoAALcaAADHGgAA1xoAAOYaAABAGwAA VxsAAGEbAAB6GwAAoBsAAKgbAADMGwAAzxsAAFocAABqHAAAexwAAIocAABsHQAAgx0AAIwdAACm HQAAKCAAADMgAABaIAAAaCAAAIwgAACZIAAAviAAAM4gAADwIAAA/yAAACIhAAAwIQAAVCEAAGch AACGIQAAmSEAALghAADMIQAAIyIAADoiAABCIgAAYSIAAPQkAAD/JAAAJiUAADQlAABYJQAAZSUA AIolAACaJQAAvCUAAMslAADuJQAA/CUAACAmAAAzJgAAUiYAAGUmAACEJgAAmCYAAO8mAAAGJwAA DicAACsnAAAzKAAAQygAAFgpAABjKQAAiykAAJkpAAC/KQAAzCkAAPMpAAACKgAAJyoAADUqAABb KgAAbioAAI8qAACiKgAAwyoAANcqAAAvKwAARisAAFErAAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA AAAAAD8AAABRAAAAUwAAAGEAAAAIAgAADQIAADEEAAA5BAAAegUAAIwFAADPBQAA4QUAAGkGAABs BgAASwcAAFwHAADUBwAA5QcAAFoIAABoCAAAmggAAKoIAAAuCQAAMQkAAFcJAABgCQAAkQkAAKYJ AADWCQAA6wkAACEKAAAqCgAALAsAAC8LAABbCwAAcgsAAOwMAAADDQAAYw0AAHENAABEDgAASA4A ABgPAAAcDwAAYQ8AAGMPAAClDwAArw8AALkPAAC7DwAA4g8AAPkPAABNEAAAWxAAAOUQAADpEAAA KBEAAC0RAABpEQAAfxEAAJoRAACyEQAA0REAANMRAAD6EQAAExIAAC4SAABFEgAAZxIAAH0SAACd EgAAuBIAANMSAADsEgAAChMAACQTAABDEwAAYhMAAHoTAACXEwAAsBMAAMYTAAACFAAADRQAACkU AAA3FAAAThQAAFsUAABzFAAAgxQAAJgUAACnFAAAvRQAAMsUAADiFAAA9RQAAAcVAAAaFQAALBUA AEAVAABkFQAAchUAADQWAABBFgAATRYAAE8WAAB0FgAAjxYAANMWAADXFgAA8xYAAP0WAAAcFwAA KhcAAEUXAABUFwAAIBgAADAYAACfGAAApRgAAOEYAADjGAAAahkAAHUZAACKGQAAmhkAAOMZAADy GQAAFhoAACIaAABPGgAAVRoAAJMaAACiGgAA1xoAAOYaAAA6GwAAPBsAAGEbAAB6GwAArRsAAK8b AAB3HAAAehwAALgcAAC6HAAA+RwAAP4cAABWHQAAWR0AAGgdAABqHQAAjB0AAKYdAADZHQAA2x0A AP8eAAAEHwAAfx8AAIQfAAAoIAAAMyAAAFogAABoIAAAjCAAAJkgAAC+IAAAziAAAPAgAAD/IAAA IiEAADAhAABUIQAAZyEAAIYhAACZIQAAuCEAAMwhAAAeIgAAICIAAEIiAABhIgAAlCIAAJYiAABt IwAAcSMAALgjAAC6IwAASyQAAFAkAAD0JAAA/yQAACYlAAA0JQAAWCUAAGUlAACKJQAAmiUAALwl AADLJQAA7iUAAPwlAAAgJgAAMyYAAFImAABlJgAAhCYAAJgmAADqJgAA7CYAAA4nAAArJwAAXicA AGAnAABXKAAAWygAALMoAAC2KAAAWCkAAGMpAACLKQAAmSkAAL8pAADMKQAA8ykAAAIqAAAnKgAA NSoAAFsqAABuKgAAjyoAAKIqAADDKgAA1yoAACorAAAsKwAAUSsAAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH AAAAAAAuAAAAMAAAAIEKAAAhCwAAwwsAAMMLAADECwAAxAsAAGMMAABjDAAAJRYAACUWAADfFgAA CBcAADYZAAA2GQAAXhkAAF4ZAAB9GQAAfRkAAH4ZAAB+GQAAfxkAAH8ZAACgGQAAoBkAAPkZAAD5 GQAA+hkAAPkaAAChKQAAoSkAAKwpAACvKQAA1SkAANUpAADgKQAA4ykAAAkqAAAJKgAAFCoAABcq AABIKgAASyoAAHwqAAB/KgAAsCoAALMqAADkKgAA5yoAAO0qAAAqKwAASysAAE0rAABOKwAAUSsA AAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQA AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABwD/ /xQAAAAKAGUAbgBlAGMAaABhAG0AawBpAG4AXQBDADoAXABWAG8ASQBQAFwAQwBhAGIAbABlAEwA YQBiAHMAXABQAGEAYwBrAGUAdABDAGEAYgBsAGUAXABJAEUAVABGAFwAUwBJAEcALQBNAEkAQgBc AEMAbwBtAG0AZQBuAHQAcwAgAG8AbgAgAFMASQBHACAATQBJAEIAIABkAHIAYQBmAHQALQAwADIA IAAoAEIAUgBDAE0AKQBfADIAMAAwADMALQAxADEALQAyADcALgBkAG8AYwAKAGUAbgBlAGMAaABh AG0AawBpAG4AXQBDADoAXABWAG8ASQBQAFwAQwBhAGIAbABlAEwAYQBiAHMAXABQAGEAYwBrAGUA dABDAGEAYgBsAGUAXABJAEUAVABGAFwAUwBJAEcALQBNAEkAQgBcAEMAbwBtAG0AZQBuAHQAcwAg AG8AbgAgAFMASQBHACAATQBJAEIAIABkAHIAYQBmAHQALQAwADIAIAAoAEIAUgBDAE0AKQBfADIA MAAwADMALQAxADEALQAyADcALgBkAG8AYwAKAGUAbgBlAGMAaABhAG0AawBpAG4AXQBDADoAXABW AG8ASQBQAFwAQwBhAGIAbABlAEwAYQBiAHMAXABQAGEAYwBrAGUAdABDAGEAYgBsAGUAXABJAEUA VABGAFwAUwBJAEcALQBNAEkAQgBcAEMAbwBtAG0AZQBuAHQAcwAgAG8AbgAgAFMASQBHACAATQBJ AEIAIABkAHIAYQBmAHQALQAwADIAIAAoAEIAUgBDAE0AKQBfADIAMAAwADMALQAxADEALQAyADcA LgBkAG8AYwAKAGUAbgBlAGMAaABhAG0AawBpAG4AXQBDADoAXABWAG8ASQBQAFwAQwBhAGIAbABl AEwAYQBiAHMAXABQAGEAYwBrAGUAdABDAGEAYgBsAGUAXABJAEUAVABGAFwAUwBJAEcALQBNAEkA QgBcAEMAbwBtAG0AZQBuAHQAcwAgAG8AbgAgAFMASQBHACAATQBJAEIAIABkAHIAYQBmAHQALQAw ADIAIAAoAEIAUgBDAE0AKQBfADIAMAAwADMALQAxADEALQAyADcALgBkAG8AYwAKAGUAbgBlAGMA aABhAG0AawBpAG4AjABDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABp AG4AZwBzAFwAZQBuAGUAYwBoAGEAbQBrAGkAbgBcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQA YQB0AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBl AHIAeQAgAHMAYQB2AGUAIABvAGYAIABDAG8AbQBtAGUAbgB0AHMAIABvAG4AIABTAEkARwAgAE0A SQBCACAAZAByAGEAZgB0AC0AMAAyACAAKABCAFIAQwBNACkAXwAyADAAMAAzAC0AMQAxAC0AMgA3 AC4AYQBzAGQACgBlAG4AZQBjAGgAYQBtAGsAaQBuAF0AQwA6AFwAVgBvAEkAUABcAEMAYQBiAGwA ZQBMAGEAYgBzAFwAUABhAGMAawBlAHQAQwBhAGIAbABlAFwASQBFAFQARgBcAFMASQBHAC0ATQBJ AEIAXABDAG8AbQBtAGUAbgB0AHMAIABvAG4AIABTAEkARwAgAE0ASQBCACAAZAByAGEAZgB0AC0A MAAyACAAKABCAFIAQwBNACkAXwAyADAAMAAzAC0AMQAxAC0AMgA3AC4AZABvAGMACgBlAG4AZQBj AGgAYQBtAGsAaQBuAF0AQwA6AFwAVgBvAEkAUABcAEMAYQBiAGwAZQBMAGEAYgBzAFwAUABhAGMA awBlAHQAQwBhAGIAbABlAFwASQBFAFQARgBcAFMASQBHAC0ATQBJAEIAXABDAG8AbQBtAGUAbgB0 AHMAIABvAG4AIABTAEkARwAgAE0ASQBCACAAZAByAGEAZgB0AC0AMAAyACAAKABCAFIAQwBNACkA XwAyADAAMAAzAC0AMQAxAC0AMgA3AC4AZABvAGMACgBlAG4AZQBjAGgAYQBtAGsAaQBuAIwAQwA6 AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAGUAbgBlAGMA aABhAG0AawBpAG4AXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEAdABhAFwATQBpAGMAcgBv AHMAbwBmAHQAXABXAG8AcgBkAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAA bwBmACAAQwBvAG0AbQBlAG4AdABzACAAbwBuACAAUwBJAEcAIABNAEkAQgAgAGQAcgBhAGYAdAAt ADAAMgAgACgAQgBSAEMATQApAF8AMgAwADAAMwAtADEAMQAtADIANwAuAGEAcwBkAAoAZQBuAGUA YwBoAGEAbQBrAGkAbgBdAEMAOgBcAFYAbwBJAFAAXABDAGEAYgBsAGUATABhAGIAcwBcAFAAYQBj AGsAZQB0AEMAYQBiAGwAZQBcAEkARQBUAEYAXABTAEkARwAtAE0ASQBCAFwAQwBvAG0AbQBlAG4A dABzACAAbwBuACAAUwBJAEcAIABNAEkAQgAgAGQAcgBhAGYAdAAtADAAMgAgACgAQgBSAEMATQAp AF8AMgAwADAAMwAtADEAMQAtADIANwAuAGQAbwBjAAoAZQBuAGUAYwBoAGEAbQBrAGkAbgCMAEMA OgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABlAG4AZQBj AGgAYQBtAGsAaQBuAFwAQQBwAHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIA bwBzAG8AZgB0AFwAVwBvAHIAZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAg AG8AZgAgAEMAbwBtAG0AZQBuAHQAcwAgAG8AbgAgAFMASQBHACAATQBJAEIAIABkAHIAYQBmAHQA LQAwADIAIAAoAEIAUgBDAE0AKQBfADIAMAAwADMALQAxADEALQAyADcALgBhAHMAZAAEAFRY/RR8 OpYq/w//D/8P/w//D/8P/w//D/8PEABPMFYvuoigHP8P/w//D/8P/w//D/8P/w//DxAAcCuzRXw6 lir/D/8P/w//D/8P/w//D/8P/w8QAJlSjWN8OpYq/w//D/8P/w//D/8P/w//D/8PEAABAAAAFwAA AAAAAAAAAAAAaAEAAAAAAAAPGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+Q0oQAE9KBABRSgQA bygAAQBx8AEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCE mP4CAAEALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhg hEz/AgACAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EQAsRhJj+FcYFAAFACwZehEAL YISY/gIAAwAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhBAOEYSY/hXGBQABEA4GXoQQ DmCEmP4CAAQALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4TgEBGETP8VxgUAAeAQBl6E 4BBghEz/AgAFAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EsBMRhJj+FcYFAAGwEwZe hLATYISY/gIABgAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhIAWEYSY/hXGBQABgBYG XoSAFmCEmP4CAAcALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RQGRGETP8VxgUAAVAZ Bl6EUBlghEz/AgAIAC4AAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E0AIRhJj+FcYFAAHQ AgZehNACYISY/k9KBABRSgQAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhKAF EYSY/hXGBQABoAUGXoSgBWCEmP5PSgMAUUoDAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAA AAALGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+T0oEAFFKBABvKAABAKfwAQAAABeQAAAAAAAA AAAAAGgBAAAAAAAACxgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBRSgEAbygAAQC38AEA AAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5PSgMAUUoD AG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBg hJj+T0oEAFFKBABvKAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EsBMRhJj+FcYF AAGwEwZehLATYISY/k9KAQBRSgEAbygAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAP hIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgMAUUoDAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEA AAAAAAALGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+T0oEAFFKBABvKAABAKfwAQAAABcAAAAA AAAAAAAAAGgBAAAAAAAADxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/kNKEABPSgQAUUoEAG8o AAEAcfABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+ AgABAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM /wIAAgAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CE mP4CAAMALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5g hJj+AgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E4BARhEz/FcYFAAHgEAZehOAQ YIRM/wIABQAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhLATEYSY/hXGBQABsBMGXoSw E2CEmP4CAAYALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SAFhGEmP4VxgUAAYAWBl6E gBZghJj+AgAHAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EUBkRhEz/FcYFAAFQGQZe hFAZYIRM/wIACAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYSY/hXGBQAB0AIG XoTQAmCEmP5vKAACAAAALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SgBRGEmP4VxgUA AaAFBl6EoAVghJj+AgABAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EcAgRhEz/FcYF AAFwCAZehHAIYIRM/wIAAgAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhEALEYSY/hXG BQABQAsGXoRAC2CEmP4CAAMALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QQDhGEmP4V xgUAARAOBl6EEA5ghJj+AgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E4BARhEz/ FcYFAAHgEAZehOAQYIRM/wIABQAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhLATEYSY /hXGBQABsBMGXoSwE2CEmP4CAAYALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SAFhGE mP4VxgUAAYAWBl6EgBZghJj+AgAHAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EUBkR hEz/FcYFAAFQGQZehFAZYIRM/wIACAAuAAQAAABPMFYvAAAAAAAAAAAAAAAAmVKNYwAAAAAAAAAA AAAAAFRY/RQAAAAAAAAAAAAASwBwK7NFAAAAAAAAAAAAAEsA////////////////////////BAAA AAAAAAAAAAAA//8EAAAAEgAHAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSAAUA CQQDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIABwAJBBkACQQbAAkEDwAJBBkACQQb AAkEDwAJBBkACQQbAAkEEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQT/QAOA AQD+GQAA/hkAAKCL9gIBAAAA/hkAAAAAAAD+GQAAAAAAAAIQAAAAAAAAAE8rAABwAAAIAEAAAP// AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD/ /wAAAgD//wAAAAAFAAAARxaQAQAAAgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAFQA aQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAA AAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBId6ACAAAACACAAAAAAA AAD/AQAAAAAAAEEAcgBpAGEAbAAAAD81kAEAAAIHAwkCAgUCBASHegAgAAAAgAgAAAAAAAAA/wEA AAAAAABDAG8AdQByAGkAZQByACAATgBlAHcAAAA7BpABAgAFAAAAAAAAAAAAAAAAAAAAABAAAAAA AAAAAAAAAIAAAAAAVwBpAG4AZwBkAGkAbgBnAHMAAAAiAAQAcQiIGADw0AIAAGgBAAAAABvbe4bM 23uGAAAAACgAdAAAAEMGAAC2IwAAAQASAAAABAADEEwAAAAAAAAAAAAAAAEAAQAAAAEAAAAAAAAA IQMA8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAegBbQAtACBgTIwAAAQABkAZAAAABkA AADbKwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAEMoNRAPAQAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA//8SAAAAAAAAABwAQwBvAG0AbQBlAG4AdABzACAAbwBuACAAUwBJAEcAIABNAEkAQgAg AGQAcgBhAGYAdAAtADAAMgAAAAAAAAAKAGUAbgBlAGMAaABhAG0AawBpAG4ACgBlAG4AZQBjAGgA YQBtAGsAaQBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQACAAAAAAAA AAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACMAQAAEQAAAAEAAACQAAAAAgAAAJgA AAADAAAAwAAAAAQAAADMAAAABQAAAOAAAAAGAAAA7AAAAAcAAAD4AAAACAAAAAwBAAAJAAAAIAEA ABIAAAAsAQAACgAAAEgBAAAMAAAAVAEAAA0AAABgAQAADgAAAGwBAAAPAAAAdAEAABAAAAB8AQAA EwAAAIQBAAACAAAA5AQAAB4AAAAdAAAAQ29tbWVudHMgb24gU0lHIE1JQiBkcmFmdC0wMgAATWke AAAAAQAAAABvbW0eAAAACwAAAGVuZWNoYW1raW4AIB4AAAABAAAAAG5lYx4AAAABAAAAAG5lYx4A AAALAAAATm9ybWFsLmRvdAAgHgAAAAsAAABlbmVjaGFta2luACAeAAAAAwAAADQwAGMeAAAAEwAA AE1pY3Jvc29mdCBXb3JkIDkuMAAgQAAAAAC4ezQQAAAAQAAAAABCbc8ktcMBQAAAAABgSdw7tcMB AwAAAAEAAAADAAAAQwYAAAMAAAC2IwAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAA AAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAADAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIQA AAAGAAAAjAAAABEAAACUAAAAFwAAAJwAAAALAAAApAAAABAAAACsAAAAEwAAALQAAAAWAAAAvAAA AA0AAADEAAAADAAAAO0AAAACAAAA5AQAAB4AAAAJAAAAQnJvYWRjb20AAG8AAwAAAEwAAAADAAAA EgAAAAMAAADbKwAAAwAAAO0OCQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAB AAAAHQAAAENvbW1lbnRzIG9uIFNJRyBNSUIgZHJhZnQtMDIADBAAAAIAAAAeAAAABgAAAFRpdGxl AAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAI AAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYA AAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAA ACUAAAAmAAAAJwAAAP7///8pAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAA MwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABB AAAAQgAAAEMAAABEAAAA/v///0YAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAAD+////TgAAAE8A AABQAAAAUQAAAFIAAABTAAAAVAAAAP7////9////VwAAAP7////+/////v////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAA AMAAAAAAAABGAAAAAAAAAAAAAAAA8BA37ju1wwFZAAAAgAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAP////// /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAADVOAAAAAAAAFcA bwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAaAAIBBQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACJOAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABFAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5 AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE0AAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIBAQAAAAYA AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAAAAAAATwBi AGoAZQBjAHQAUABvAG8AbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABYAAQD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAFCKNe47tcMBUIo17ju1wwEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABN aWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA 9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------_=_NextPart_001_01C3B53E.FC19B661-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn