From exim@www1.ietf.org Wed Oct 1 17:28:26 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 RAA05588 for ; Wed, 1 Oct 2003 17:28:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4oVv-0005M5-1r for ipcdn-archive@odin.ietf.org; Wed, 01 Oct 2003 17:28:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91LS3dK020579 for ipcdn-archive@odin.ietf.org; Wed, 1 Oct 2003 17:28:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4oVt-0005Lo-Fc; Wed, 01 Oct 2003 17:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4oUy-0005Kq-HZ for ipcdn@optimus.ietf.org; Wed, 01 Oct 2003 17:27:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05573 for ; Wed, 1 Oct 2003 17:26:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4oUv-0005jn-00 for ipcdn@ietf.org; Wed, 01 Oct 2003 17:27:01 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A4oUv-0005jE-00 for ipcdn@ietf.org; Wed, 01 Oct 2003 17:27:01 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h91LQM10002987; Wed, 1 Oct 2003 15:26:23 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: MIB doctor review of: draft-ietf-ipcdn-pktc-mtamib-01.txt (Part 1) Date: Wed, 1 Oct 2003 15:26:22 -0600 Message-ID: Thread-Topic: [ipcdn] RE: MIB doctor review of: draft-ietf-ipcdn-pktc-mtamib-01.txt (Part 1) Thread-Index: AcNgJaYn06TBEeT1TRC5N0Q/BVl7hgT3JTZQBRgJoxA= From: "Jean-Francois Mule" To: "Jean-Francois Mule" , "C. M. Heard" , "Bert Wijnen" Cc: "Eugene Nechamkin" , "Ipcdn (E-mail)" 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 Mike, Below are the second part of our response to your MIB doctor review.=20 It is in response to your comment #11. Thank you, Eugene and Jean-Francois. > 11.) Technical content -- here are the comments on the=20 > content of Section 4, "Definitions," which contains the=20 > PKTC-IETF-MTA-MIB. >=20 > (a) In the MODULE-IDENTITY DESCRIPTION clause: > s/set if requirements/requirements/ ok, done in draft-02. >=20 > (b) The ASN.1 comment preceding=20 > DocsX509ASN1DEREncodedCertificate promises to do something=20 > that is not allowed: >=20 > -- > -- The following textual convention will be imported from BPI+ RFC > -- when introduced there. > -- >=20 > It is ILLEGAL to move a TC from one module to another or to=20 > remove a definition from a published MIB module. If the TC=20 > is to be imported from the BPI-plus MIB, then do so before=20 > this module is published; otherwise, plan on leaving it in=20 > in perpetuity (in which case there is no point in IMPORTING=20 > it). In the latter case, you may want to change the name to=20 > PktcMtaX509ASN1DEREncodedCertificate. In any case, that=20 > comment has to go. Now that draft-ietf-ipcdn-bpiplus-mib-11.txt contains the TC convention DocsX509ASN1DEREncodedCertificate, in draft02 of the MTA MIB, we did the following: 1. remove the TC definition and imported the object def from DOCS-IETF-BPI2-MIB. 2. added normative reference to BPI+ mib RFC and added RFC editor note. =20 > (c) The REFERENCE clauses do not have a consistent style=20 > throughout. Sometimes a document is referred to by title=20 > alone; sometimes a document is referred to by number alone; =20 > and in some cases both styles are used in the same REFERENCE=20 > clause, e.g., >=20 > REFERENCE > "PacketCable Provisioning Specification. RFC 3495." >=20 > I find this a little confusing: it's not clear at a glance=20 > whether RFC 3495 is the number of the PacketCable=20 > Provisioning Specification or is a separate document. For=20 > this reason I ask that all REFERENCE clauses be updated to=20 > use a consistent style when referring to documents. My=20 > suggestion would be to see something line this, which has=20 > both document number and > (abbreviated) title, and which has distinct document=20 > references separated by a semicolon: >=20 > REFERENCE > "PKT-SP-PROV-I07-030728, PacketCable MTA Device Provisioning > Specification; RFC 3495, DHCP Option for CableLabs Client > Configuration." >=20 Comment received and partially addressed. We did follow the recommendation for the published RFCs.=20 However, for PacketCable specifications, since we update them 3 times a year, we did not include the PKT-SP-xxx-I0n numbering in the REFERENCE clause. For e.g., in draft02, we have: REFERENCE " RFC 2132, DHCP Options and BOOTP Vendor Extensions" REFERENCE " PacketCable MTA Device Provisioning Specification; RFC 3495, DHCP Option for CableLabs Client Configuration." > (d) In the DESCRIPTION clause of pktcMtaDevSwCurrentVers:=20 > s/'sysDecr'/'sysDescr'/ >=20 ok, done in draft-02. > (e) Should the DESCRIPTION clause of pktcMtaDevFQDN say what > is returned if the device is queried before a domain name > has been assigned to it? No action taken.=20 Explanation: the MTA cannot be queried via SNMP before the boot process is complete and an MTA gets its FQDN before it starts its SNMP agent process. > (f) In the DESCRIPTION clause of pktcMtaDevEndPntCount: > s/The physical end points/The number of physical end points/ >=20 ok, done. Also we cleaned the wording of endpoint throughout the document (we now have a consistent use of endpoint in lieu of end point or end-point). > (g) In the definition of pktcMtaDevTypeIdentifier: please > add a REFERENCE clause pointing to RFC 2132, where option #60=20 > is defined. NOTE: there are several other objects that need=20 > to have a REFERENCE to RFC 2132. Among them are=20 > pktcMtaDevServerDns1 (option #6), pktcMtaDevServerDns2=20 > (option #6), and pktcMtaDevTimeServer (option #4). >=20 ok, done in draft02. > (h) In the DESCRIPTION clause of pktcMtaDevErrorOidsTable: > it might be a good idea to specify when in the provisioning=20 > process this table is cleared (presumably you do want the=20 > table cleared if provisioning is restarted). > ok, done in draft-02. Added clarification in the last sentence, now says:=20 "The table MUST be cleared each time the MTA reboots." > (i) The DESCRIPTION clause of pktcMtaDevErrorOid says: >=20 > "If the error was due to a reason which cannot be associated > with 'recognizable' OID of the parameter, then this MIB > object must contain an empty value." >=20 > It is not clear what the words "an empty value" mean. If you=20 > mean "{ 0 0 }" please say so. >=20 > (also, s/Parameter, which caused/Parameter that caused/) >=20 ok, done in draft-02. The DESCRIPTION and SYNTAX have been modified as follows: pktcMtaDevErrorOidsTable OBJECT-TYPE =20 SYNTAX SEQUENCE OF PktcMtaDevErrorOidsEntry=20 MAX-ACCESS not-accessible STATUS current DESCRIPTION=20 " This table contains the list of configuration errors or=20 warnings the MTA encountered when parsing the configuration file it received from the provisioning=20 server.=20 For each error, an entry is created in this table containing the configuration parameters the MTA rejected and the associated reason (e.g. wrong or unknown OID,=20 inappropriate object values, etc.). If the MTA=20 did not report a provisioning state of 'pass(1)' in the pktcMtaDevProvisioningState object, this table MUST be populated for each error or warning instance. Even if different parameters share the same error type (e.g., all realm name configuration parameters are invalid), all observed errors or warnings must be reported as=20 different instances. Errors are placed into the table in=20 no particular order. The table MUST be cleared each time=20 the MTA reboots."=20 REFERENCE " PacketCable MTA Device Provisioning Specification." ::=3D {pktcMtaDevBase 11 } > (j) The DESCRIPTION clause of pktcMtaDevErrorValue says: >=20 > "If the error was due to unrecognizable OID of the > parameter in the Configuration File, then this MIB > Object contains the value of the OID as interpreted > MTA. Otherwise (the error happens due to a wrong value > of the parameter) - the MIB Object contains the value > from the Configuration File converted to SnmpAdminString." >=20 > Putting on my implementor's hat I have a number of problems=20 > with this DESCRIPTION clause. First, it's not clear what is=20 > meant by the first sentence. I'm guessing that it means that=20 > if I see an OID in a configuration file that I don't=20 > recognize then I must populate this object (rather than=20 > pktcMtaDevErrorOid) with that OID. I shouldn't have to=20 > guess. Second, there is no guidance on how I am suppose to=20 > turn OIDs or other values into an SnmpAdminString. If this=20 > is left unspecified then it's quite likely that different=20 > implementations will do different things. So, I must ask that=20 > you clarify this DESCRIPTION clause. >=20 ok, attempt to improve the description was done in draft02. The DESCRIPTION has been modified as follows: pktcMtaDevErrorValue OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the value of the OID corresponding to the configuration file parameter that caused the error. If the MTA cannot recognize the OID of the configuration parameter causing the error, then this object instance contains the OID itself as interpreted by the MTA in human readable representation. If the MTA can recognize the OID but generate an error due to a wrong value of the parameter, then the object instance contains the erroneous value of the parameter as read from the configuration file. In both cases, the value of this object must be represented in human readable form as a character string. For example, if the value of the pktcMtaDevEnabled object in the configuration file was 3 (invalid value), then the pktcMtaDevErrorValue object instance will contain the human readable (string) representation of value '3'. Similarly, if the OID in the configuration file has been interpreted by the MTA as being .1.2.3.4.5, and the MTA cannot recognize this OID as a valid one, then this pktcMtaDevErrorValue object instance will contain human readable (string) representation of value '.1.2.3.4.5'" ::=3D {pktcMtaDevErrorOidsEntry 3} > (k) This comment deals with some problems related to the=20 > usage of the InetAddressType/InetAddress TCs that affect=20 > objects of those types in the pktcMtaDevServer group. >=20 > First: the DESCRIPTION clause of pktcMtaDevServerAddressType says: >=20 > This object defines the address type for the following=20 > servers: pktcMtaDevServerDhcp1, pktcMtaDevServerDhcp2,=20 > pktcMtaDevServerDns1, pktcMtaDevServerDns2, pktcMtaDevTimeServer. >=20 > However, the DESCRIPTION clauses of pktcMtaDevServerDhcp1,=20 > pktcMtaDevServerDhcp2, pktcMtaDevServerDns1,=20 > pktcMtaDevServerDns2, and pktcMtaDevTimeServer do not have=20 > this information, as required by the DESCRIPTION clause of=20 > the InetAddress TC: >=20 > | An InetAddress value is always interpreted within the context of an=20 > | InetAddressType value. Every usage of the InetAddress textual=20 > | convention is required to specify the InetAddressType object which=20 > | provides the context. >=20 > I strongly recommend, for reasons of ease of maintenance,=20 > that the InetAddress/InetAddressType association be specified=20 > in the DESCRIPTION clauses of the InetAddress objects _only_.=20 ok done. > The reason is that it is possible to add new InetAddress=20 > objects -- possibly in a different MIB module -- that use a=20 > pktcMtaDevServerAddressType as the type discriminator, and if=20 > the associations are listed in the=20 > pktcMtaDevServerAddressType DESCRIPTION clause the it would=20 > need to be updated whenever this happens. It's clearly=20 > undesirable (and not always feasible) to do that. ok, makes sense. > Second: although InetAddressType object=20 > pktcMtaDevServerAddressType is formally allowed to assume=20 > values other than ipv4 -- which may indeed be desirable for=20 > future extensibility -- the DESCRIPTION and REFERENCE clauses=20 > for the corresponding InetAddress objects=20 > pktcMtaDevServerDhcp1, pktcMtaDevServerDhcp2,=20 > pktcMtaDevServerDns1, pktcMtaDevServerDns2, and=20 > pktcMtaDevTimeServer do not currently provide any meaning for=20 > any address types other than ipv4(1). The main reference=20 > PacketCable MTA Device Provisioning Specification,=20 > PKT-SP-PROV-I07-030728, only discusses provisioning with=20 > DHCPv4 and not DHCPv6, and only discusses the use of IPv4 for=20 > communication with the DHCP server. So it's not clear what a=20 > client would do with anything other than IPv4 addresses for=20 > pktcMtaDevServerDhcp1 and pktcMtaDevServerDhcp2. Also, the=20 > DHCP options that correspond to the pktcMtaDevServerDns1,=20 > pktcMtaDevServerDns2, and pktcMtaDevTimeServer objects (cf.=20 > #11(g) above) are values of DHCPv4 options, which can only=20 > contain IPv4 addresses. Understand our current limitations, however, this MTA MIB is derived from specifications that only defined IPv4 behavior. > If future extensibility to IPv6 is desirable and possible,=20 > then the suggested fixes for the problems are to revise the=20 > DESCRIPTION clauses for pktcMtaDevServerDhcp1,=20 > pktcMtaDevServerDhcp2, pktcMtaDevServerDns1,=20 > pktcMtaDevServerDns2, and pktcMtaDevTimeServer along the=20 > following lines: >=20 > "The type of this address is determined by the value of > the pktcMtaDevServerAddressType object. When the latter > has the value ipv4(1), this object is [ ... ]. >=20 > The behavior of this object when the value of > pktcMtaDevServerAddressType is other than ipv4(1) > is not presently specified, but may be specified > in future versions of this MIB module." ok, done in draft02. > where [ ... ] contains the existing description text=20 > (modified as needed for grammatical correctness and to remedy=20 > the deficiencies noted in #11(g) above and #11(l) through=20 > #11(n) below) and to remove the second sentence of the=20 > pktcMtaDevServerAddressType DESCRIPTION clause. ok, done in draft02. > If, on the other hand, there is no realistic possibility of=20 > re-using this MIB module with a future IPv6-capable version=20 > of the PacketCable MTA specs, then it would probably be=20 > better to eliminate pktcMtaDevServerAddressType and change=20 > the SYNTAX value of pktcMtaDevServerDhcp1,=20 > pktcMtaDevServerDhcp2, pktcMtaDevServerDns1,=20 > pktcMtaDevServerDns2, pktcMtaDevTimeServer to=20 > InetAddressIPv4. Note that this is permitted (although not=20 > encouraged) by RFC 3291 (and its successor=20 > draft-ietf-ops-rfc3291bis-01.txt). > In subsequent comments I'll assume that the first solution is=20 > adopted; if it isn't please modify suggested text as appropriate. we opted to keep InetAddressType and add your proposed statement. > (l) The DESCRIPTION clauses of pktcMtaDevServerDhcp1 and=20 > pktcMtaDevServerDhcp2 should explicitly state that these=20 > parameters are normally provided by the Cable Modem (CM)=20 > entity associated with the MTA, and that the CM gets them as=20 > the values of suboptions 1 and 2 (respectively) of the DHCP=20 > CableLabs Client Configuration Option (option #122) defined=20 > in RFC 3495. Note that RFC 3495 (and the provisioning spec)=20 > explicitly say that these suboptions apply only to the CM. >=20 > For example, the DESCRIPTION clause for pktcMtaDevServerDhcp1=20 > might become: >=20 > "The type of this address is determined by the value of > the pktcMtaDevServerAddressType object. When the latter > has the value ipv4(1), this object is the IP address of > the primary DHCPv4 server which will cater to the MTA > during its provisioning. It is provided by the CM to > the MTA from suboption 1 of the DHCP Option for > CableLabs Client Configuration (option #122) defined > in RFC 3495. It contains the value 255.255.255.255 if > there was no preference given with respect to the DHCP > servers for MTA provisioning. >=20 > The behavior of this object when the value of > pktcMtaDevServerAddressType is other than ipv4(1) > is not presently specified, but may be specified > in future versions of this MIB module." Updated to the following - in draft02: pktcMtaDevServerDhcp1 OBJECT-TYPE=20 SYNTAX InetAddress=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 " This object contains the Internet Address of the primary DHCP server the MTA uses during provisioning. The type of this address is determined by the value of the pktcMtaDevServerAddressType object. =20 When the latter has the value 'ipv4(1)', this object=20 contains the IP address of the primary DHCPv4 server the=20 MTA uses during provisioning. It is provided by the CM to=20 the MTA via the DHCP option code 122 sub-option 1 as =20 defined in RFC 3495. =20 This object must be of value '255.255.255.255' if the address type was 'ipv4(1)' and if there was no=20 preference given for the primary DHCP server. The behavior of this object when the value of pktcMtaDevServerAddressType is other than 'ipv4(1)' is not presently specified, but may be specified in future versions of this MIB module." REFERENCE " PacketCable MTA Device Provisioning Specification; RFC 3495, DHCP Option for CableLabs Client Configuration." ::=3D { pktcMtaDevServer 2 }=20 >=20 > Similarly, the DESCRIPTION clause for pktcMtaDevServerDhcp2=20 > might become: >=20 > "The type of this address is determined by the value of > the pktcMtaDevServerAddressType object. When the latter > has the value ipv4(1), this object is the IP address of > the primary DHCPv4 server which will cater to the MTA > during its provisioning. It is provided by the CM to > the MTA from suboption 2 of the DHCP Option for > CableLabs Client Configuration (option #122) defined > in RFC 3495. It contains the value 0.0.0.0 if there > is no specific secondary DHCP server to be considered > during MTA provisioning. >=20 > The behavior of this object when the value of > pktcMtaDevServerAddressType is other than ipv4(1) > is not presently specified, but may be specified > in future versions of this MIB module." same as above. > Question: do these objects apply only to E-MTA or do they=20 > apply to S-MTA also? If they don't apply to S-MTA (i.e.,=20 > have the value 255.255.255.255/0.0.0.0) then say so; if they=20 > apply to both, I am curious to know how the CM communicates=20 > the values to the MTA in that case. >=20 ok, done. The modifications apply to both - E- and S-MTA. In S-MTA case, it is the DHCP Server that provides the S-MTA with the values of sub-options-1 & 2. Details are in S-MTA Prov Spec, current in Draft. > (m) The DESCRIPTION clauses for pktcMtaDevServerDns1 and=20 > pktcMtaDevServerDns2 claim that these objects get their=20 > values from DHCP option 6 "as defined in RFC-3495". That is=20 > incorrect: DHCP option 6 is defined in RFC 2132. The=20 > REFERENCE clause also contains this error. These clauses=20 > also read awkwardly. See #11(l) above for a model=20 > DESCRIPTION clause and #11(c) for a model REFERENCE clause. >=20 ok, done. pktcMtaDevServerDns1 OBJECT-TYPE=20 SYNTAX InetAddress=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION=20 " This object contains the IP Address of the primary DNS server to be used by the MTA to resolve FQDNs. The type of this address is determined by the value of the pktcMtaDevServerAddressType object. =20 When the latter has the value 'ipv4(1)', this object=20 contains the IP address of the primary DNS server. As defined in RFC 2132, PacketCable compliant MTAs receive the IP address of the primary DNS Server in the DHCP=20 option 6. The behavior of this object when the value of pktcMtaDevServerAddressType is other than 'ipv4(1)' is not presently specified, but may be specified in future versions of this MIB module." REFERENCE " PacketCable MTA Device Provisioning Specification; RFC 2132, DHCP Options and BOOTP Vendor Extensions." ::=3D { pktcMtaDevServer 4 }=20 > (n) The DESCRIPTION clause for pktcMtaDevTimeServer does not=20 > mention that the value MAY appear as option #4 in a DHCP=20 > Offer/DHCP Ack. In fairness, neither does the provisioning=20 > spec PKT-SP-PROV-I07-030728, but it references the DOCSIS=20 > spec, which clearly spells this out. Here is an excerpt I=20 > picked up from DOCSIS 1.0: >=20 > The protocol by which the time of day MUST be retrieved is=20 > defined in [RFC-868]. Refer to Figure 7-10. The request=20 > and response MUST be transferred using UDP. The time=20 > retrieved from the server (UTC) MUST be combined with the=20 > time offset received from the DHCP response to create the=20 > current local time. >=20 > The DHCP server may offer a CM multiple Time of Day server=20 > IP addresses to attempt. The CM MUST attempt all Time of=20 > Day servers included in the DHCP offer until local time is=20 > established. >=20 > I presume that something like this applies to an S-MTA. I=20 > also presume that populating this object is optional for an=20 > E-MTA since the latter could get the time-of-day from the CM. >=20 > If these presumptions are correct, please revise the=20 > DESCRIPTION clause to say so, and add a reference clause=20 > pointing to RFC 2132. >=20 > It these presumptions are not correct, you will probably=20 > still want to note that this is the address of an RFC 868=20 > timer server and maybe add a REFERENCE clause pointing to RFC 868. >=20 > In any case, please fix this spelling error: s/SMTA/S-MTA/ > It caused me some confusion in trying to decipher what the=20 > DESCRIPTION clause means. And please also make this change=20 > too: s/populated/populated with a value other than 0.0.0.0/ >=20 ok, done. > (o) In the DESCRIPTION clause of pktcMtaDevConfigFile I see: >=20 > The object returns NULL if the server address is unknown. >=20 > It's not clear what NULL means in this context: the SYNTAX=20 > value is SnmpAdminString, and the TC definition in RFC 3411=20 > does not define a NULL value. If you mean a zero-length=20 > string then you must say so explicitly. >=20 > In addition, the English needs to be re-worked a little to=20 > get definite and indefinite articles in the right places. >=20 ok, done. > (p) In the DESCRIPTION clause of pktcMtaDevSnmpEntity: > s/the DHCP Option CCC/DHCP Option 122/ to be consistent with=20 > other DESCRIPTION clauses (and fix the English). > ok, done. > (q) Objects pktcMtaDevProvConfigHash and=20 > pktcMtaDevProvConfigKey have SIZE constraints in the=20 > definitions that are appropriate to the currently supported=20 > algorithms -- MD5 and SHA-1 for authentication, null or DES=20 > for privacy -- but may be overly constraining if new=20 > algorithms are added in a future version of the PacketCable=20 > security spec. The designers need to be aware that removing=20 > or changing SIZE constraints after a MIB module has been=20 > published constitutes an illegal revision (see RFC 2578=20 > Section 10). If there is a possibility of adding new=20 > algorithms, then the SIZE constraints should be removed=20 > before initial publication as an RFC. >=20 Not done at this time. This requires further consideration by the PacketCable implementers, the provisioning and security teams. > ... skipping down to the read-create tables ... >=20 > (r) The conceptual rows pktcMtaDevRealmEntry and=20 > pktcMtaDevCmsEntry support dynamic creation of rows, but do=20 > not have a StorageType column, nor do their DESCRIPTION=20 > clauses state what happens to dynamically created rows after=20 > a reboot. > You must have one or the other; see=20 > Section 4.6.3. =20 added "The conceptual rows MUST NOT persist across MTA reboots." > If the fate of a row depends on some conditions such as the=20 > value of some other object, then putting a statement to that=20 > effect in the conceptual row DESCRIPTION clause is the best=20 > way to satisfy this requirement. >=20 ok, done. > (s) The DESCRIPTION clause of pktcMtaDevRealmStatus needs=20 > many improvements. In particular, in view of #11(z) below,=20 > the following is not correct: >=20 > There is no restriction on setting columns in this table > when the value of pktcMtaDevRealmStatus is active(1). >=20 > Furthermore, the following stuff just adds unneeded words=20 > that have no value at all to the implementor: >=20 > The RowStatus TC [RFC2579] requires that this=20 > DESCRIPTION > clause states under which circumstances other objects in > this row can be modified: >=20 > Please eliminate the above paragraph here and wherever else=20 done > it appears. Also eliminate the following, which (in context)=20 > appears to be a duplicate of the first (erroneous) statement: >=20 > The value of this object has no effect on whether other > objects in this conceptual row can be modified." done >=20 > Here is the suggested replacement for all of the above text: >=20 > The columnar objects pktcMtaDevRealmName and > pktcMtaDevRealmOrgName may not be modified when > the value of this object is active(1). The value > of this object has no effect on whether other > columns in this conceptual row can be modified." >=20 > pktcMtaDevCmsStatus has similar problems (pktcMtaDevCmsFqdn=20 > and pktcMtaDevCmsKerbRealmName can't be modified while it is=20 > active(1)) and its DESCRIPTION clause needs similar modifications. >=20 > ... skipping down to the notifications section ... >=20 ok, done. > (t) Regarding the following: >=20 > -- > -- notification group is for future extension. > -- >=20 > pktcMtaNotificationPrefix OBJECT IDENTIFIER ::=3D { pktcMtaMib 2 } > pktcMtaNotification OBJECT IDENTIFIER ::=3D { > pktcMtaNotificationPrefix 0 } > pktcMtaConformance OBJECT IDENTIFIER ::=3D { pktcMtaMib 3 } > pktcMtaCompliances OBJECT IDENTIFIER ::=3D { pktcMtaConformance 1 = } > pktcMtaGroups OBJECT IDENTIFIER ::=3D { pktcMtaConformance 2 = } >=20 > Please remove the ASN.1 comment, as it is now incorrect. done >=20 > For the remainder, consider instead using the following=20 > definitions, placed right at the front of the MIB module,=20 > just below the TEXTUAL-CONVENTION section (currently page 9): >=20 > pktcMtaNotification OBJECT IDENTIFIER ::=3D { pktcMtaMib 0 } > pktcMtaMibObjects OBJECT IDENTIFIER ::=3D { pktcMtaMib 1 } > pktcMtaConformance OBJECT IDENTIFIER ::=3D { pktcMtaMib 2 } Not done at this time. This requires further consideration by the PacketCable implementers, the provisioning and security teams. >=20 > and consider relocating the following >=20 > pktcMtaCompliances OBJECT IDENTIFIER ::=3D { pktcMtaConformance 1 = } > pktcMtaGroups OBJECT IDENTIFIER ::=3D { pktcMtaConformance 2 = } done >=20 > down to the conformance section (p. 32). These changes are=20 > not mandatory, but they cost nothing and will save one=20 > sub-identifier in each OID that identifies a notification. >=20 > (u) In the definitions of the=20 > pktcMtaDevProvisioningEnrollment and=20 > pktcMtaDevProvisioningStatus notifications, the following=20 > REFERENCE clause is bogus: >=20 > REFERENCE > " Inform as defined in RFC 1902" removed. >=20 > An "inform" or "trap" is a protocol construct that transports=20 > a notification, and has nothing directly to do with the SMI. =20 > You won't find them defined in RFC 1902; the definitions of=20 > the SNMPv2-Trap-PDU and the InformRequest-PDU are in RFC 3416=20 > (formerly RFC 1905). You seem to be trying to define a=20 > notification that can be transported in an inform, but that's=20 > not possible with the SMI. If you want to require use of=20 > informs instead of traps, the place to do so is in a=20 > PacketCable protocol spec (where I believe such a restriction=20 > indeed exists), not in a MIB module. In any case, RFC 1902=20 > is obsolete; it has been replaced by 2578. >=20 ok. > ... skipping down to the conformance section ... >=20 > (v) The DESCRIPTION clause for the compliance statement=20 > pktcMtaBasicCompliance says: >=20 > " The compliance statement for devices that implement > PacketCable/IPCablecom MTA. It is left to=20 > manufacturers to > determine whether to support both PacketCable and > IPCablecom objects in the same MTA." >=20 > This is somewhat incomprehensible in the context of a MIB=20 > module that contains neither PacketCable nor IPCablecom=20 > objects but rather IETF objects. May I suggest instead=20 > borrowing the text from the PKTC-MTA-MIB in PKT-SP-MIB-MTA-I07-030728: >=20 > " The compliance statement for devices that implement > MTA feature." point taken. Here is our new proposed text: pktcMtaBasicRFCyyyyCompliance MODULE-COMPLIANCE=20 STATUS current=20 DESCRIPTION=20 " The compliance statement for MTA devices that implement PacketCable or IPCablecom requirements.=20 =20 This compliance statement applies to MTA implementations that support PacketCable 1.x or IPCablecom requirements,=20 which are not IPv6-capable at the time of this=20 RFC publication." >=20 > If you decide to retain pktcMtaDevServerAddressType for=20 > future extensibility to IPv6 (cf. #11(k) above), you might=20 > want to add to this an additional sentence like this: >=20 > This compliance statement applies to implementations that > support DOCSIS 1.0/1.1/2.0, which are not IPv6-capable. ok, see above. >=20 > modified as appropriate for MTAs. See this e-mail message: >=20 > http://ops.ietf.org/lists/mreview/mreview.2003/msg00503.html >=20 > for a discussion of the issues (and other recommended modifications). >=20 ok, done. > (w) pktcMtaNotificationGroup either needs to be added to the=20 > list of MANDATORY-GROUPS of pktcMtaBasicCompliance, if it is=20 > indeed mandatory to implement, or else there should be a=20 > GROUP clause explaining that it is optional, as explained in=20 > comment #9 above. In this case it appears that the correct=20 > course would be to add the group to the MANDATORY-GROUPS=20 > clause; that is what was done in the PKTC-MTA-MIB in=20 > PKT-SP-MIB-MTA-I07-030728. >=20 ok, done (added to the list of MANDATORY-GROUPS). > (x) If you decide to retain the object=20 > pktcMtaDevServerAddressType then it would be proper to add=20 > the following OBJECT clause: >=20 > OBJECT pktcMtaDevServerAddressType > SYNTAX { ipv4(1) } > DESCRIPTION > " Support for address types other than ipv4(1) > is not required." >=20 ok, done. OBJECT pktcMtaDevServerAddressType SYNTAX { ipv4(1) } DESCRIPTION " Support for address types other than 'ipv4(1)'=20 is not presently specified and therefore, is not=20 required. It may be defined in future versions of=20 this MIB module." > (y) The following OBJECT clause looks suspect to me: >=20 > OBJECT pktcMtaDevSnmpEntity > MIN-ACCESS read-only > DESCRIPTION > " The behavior of the SNMP Agent when the object is > set is currently undefined. Object should be > implemented as read-only." >=20 > Unless there is some clear way that the behavior could in the=20 > future be well-defined if this object is changed, then the=20 > correct thing to do is to eliminate this OBJECT clause and=20 > change the MAX-ACCESS value in the object definition to read-only. Understood. Removed and changed SYNTAX to read-only which makes sense. > (z) The following OBJECT clauses are all bogus and need to be > removed: >=20 > OBJECT pktcMtaDevRealmName > MIN-ACCESS read-only > DESCRIPTION > " The behavior of the SNMP Agent when the object is > set is currently undefined. Object should be > implemented as read-only after the conceptual > row is created." >=20 > OBJECT pktcMtaDevRealmOrgName > MIN-ACCESS read-only > DESCRIPTION > " The behavior of the SNMP Agent when the object is > set is currently undefined. Object should be > implemented as read-only after the conceptual > row is created." >=20 > OBJECT pktcMtaDevCmsFqdn > MIN-ACCESS read-only > DESCRIPTION > " The behavior of the SNMP Agent when the object is > set is currently undefined. Object should be > implemented as read-only after the conceptual > row is created." >=20 > OBJECT pktcMtaDevCmsKerbRealmName > MIN-ACCESS read-only > DESCRIPTION > " The behavior of the SNMP Agent when the object is > set is currently undefined. Object should be > implemented as read-only after the conceptual > row is created." > Each of the objects in question has a MAX-ACCESS of=20 > read-create. Using a MIN-ACCESS clause in this way means that=20 > an agent may (but need not) allow full read-create access. =20 > That is clearly not what you want, if the DESCRIPTION clause=20 > means what it says. agreed, removed. >=20 > The correct way to do what you want is to say, in the=20 > DESCRIPTION clause of the status column, that the object in=20 > question may not be modified when the status is active(1). =20 > See #11(s) above, where specific changes are recommended. >=20 ok, done. > This concludes the review of draft-ietf-ipcdn-pktc-mtamib-01.txt, > Part 1. Much of the MIB module still need be reviewed, but=20 > that is deferred until the -02 draft and/or another reviewer=20 > is available. >=20 > Regards, >=20 > Mike Heard _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Oct 1 20:12:25 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 UAA11490 for ; Wed, 1 Oct 2003 20:12:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4r4c-00064H-N8 for ipcdn-archive@odin.ietf.org; Wed, 01 Oct 2003 20:12:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h920C2W0023320 for ipcdn-archive@odin.ietf.org; Wed, 1 Oct 2003 20:12:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4r4b-00063f-In; Wed, 01 Oct 2003 20:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4r3r-00063D-1G for ipcdn@optimus.ietf.org; Wed, 01 Oct 2003 20:11:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11457 for ; Wed, 1 Oct 2003 20:11:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4r3k-0007Ok-00 for ipcdn@ietf.org; Wed, 01 Oct 2003 20:11:08 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A4r3j-0007Od-00 for ipcdn@ietf.org; Wed, 01 Oct 2003 20:11:07 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h920AZ10015323; Wed, 1 Oct 2003 18:10:35 -0600 (MDT) 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_01C38879.99FBE2B4" Date: Wed, 1 Oct 2003 18:10:35 -0600 Message-ID: Thread-Topic: Status of IPCDN RF MIBv2 and 3 open issues Thread-Index: AcNgJaYn06TBEeT1TRC5N0Q/BVl7hgT3JTZQBRgJoxAABa9pIA== From: "Jean-Francois Mule" To: "Ipcdn (E-mail)" Cc: "Eduardo Cardona" , "Jean-Francois Mule" , "Richard Woundy" , "Bert Wijnen" , "Raftus, David" X-Approved: ondar Subject: [ipcdn] Status of IPCDN RF MIBv2 and 3 open issues 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_01C38879.99FBE2B4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This note provides a status on the DOCSIS 2.0 RF MIB (aka rfmibv2). In summary, 3 issues are still OPEN and the wg chairs would like to have working group consensus by Friday October 10 on issues: #13, #14, #16. Eduardo Cardona of CableLabs has kindly accepted to help resolve those and will be posting some text soon. Please read this carefully and raise any concerns or objections to the wg chairs on this action plan by Friday Oct 10. -- Rich Woundy and Jean-Francois Mule', ipcdn co-chairs. --- Status of RF MIBv2 Internet-Draft Name: DOCSIS 2.0 RF MIB draft-ietf-ipcdn-docs-rfmibv2-06.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-06.txt soon to be draft-ietf-ipcdn-docs-rfmibv2-07.txt 1) Follow-up on the IETF posting of rfmibv2-07 The editor, David Raftus sent draft-07 to the internet-draft on 9/9. The revision has not shown up yet. This is probably due to the fact that a zip file was attached instead of the plain text file. Action Item (AI): wg chair to follow up on posting. 2) Categorization of the remaining open issues David Raftus sent a list of open issues to the ipcdn list on 9/12/03, see attached file rfdraftv7_issues_Sept12_2003.txt The remaining open issues not addressed in draft-07 split into 2 categories: - a) issue is not required to be addressed ("nice to have") This category includes some of the improvements that were not in the original scope of rfmibv2. A lot of improvements has been done and it is time to freeze rfmibv2. - b) issue that should be addressed in draft v8 ("must fix") This category includes some issues that need to be addressed. 5 open issues are in this category. =3D> Please raise any objection on the ipcdn list by COB Friday 9/10/03 if you believe this is not reflecting the correct status of the draft or if you believe more open issues must be fixed. 3) Open issues: The numbering is based on David Raftus status file sent on 9/12/2003 on the ipcdn list and attached to this posting. + Issue #7: Status: Closed (will be in draft08) (7) docsIfUpChannelPreEqEnable - add DEFVAL clause. Contributor - John Gillis ADC David indicated that a defval is not required ("DEFVAL not appropriate here, also too many other items in same table do not have DEFVAL"). # category: "must fix" # Eduardo recommends to add a default value of false for this object. # Action Item: add DEFVAL false in draft 08 + Issue #13 Status: Open (13) Adjust compliance statements for objects designated optional. Add separate augmentation table for optional objects in docsIfCmtsUpChannelCounterTable. Contributors - Will Murwin Motorola, Rich Woundy IPCDN/Comcast, Mike StJohns Mindspring, Eduardo Cardona Cablelabs # category: "must fix" # Action Item: Eduardo to summarize the discussion & a recommendation # for the augmentation. Consensus must be reached by 10/10 or else WG # chair will make a decision. + Issue #14=20 Status: Open (14) Add section explaining counter interaction between Docsis 1.0/1.1/2.0. David indicated that this could be done in OSS spec but since rfmib v2 obsoletes an exising IETF MIB, the wg chairs recommendation is to include a section in the new MIB. # category: "must fix" # Action Item: Eduardo to propose some text. + Issue #15 Status: Closed, pending ipcdn review (15) Change docsIfCmtsServiceTable to count packets for both upstream and downstream flows. David Raftus commented: "Will not do - inappropriate - table indexed by SID, SIDs are not defined for downstream flows". WG chairs agree with David Raftus. # category: "nice to have", For further study. # Action item: none, issue is closed.=20 + Issue #16 Status: Open (16) Add 4 objects to docsIfCmtsCmStatusTable See David Raftus' status on this open issue and associated emails. # category: "nice to have" # Action item: Eduardo to close on this issue on the ipcdn mailing # list. If no consensus can be reached by Oct 10, wg chair will make a # decision to leave it out of rf mib v2. + Issue #20 Status: Closed (will be in draft08) (20) Update snmpv3 references to latest mib versions # category: "must fix" # Action item: edit draft 08 and include proper refs in the document + Issue #22 Status: Closed (pending ipcdn review) (22) Addition of object to report received power level per channel at CMTS # category: "nice to have" -> out of scope # Recommendation is that this issue will not be addressed in any # future revision of RF MIB v2. # Action item: none, issue is closed.=20 ------_=_NextPart_001_01C38879.99FBE2B4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Status of IPCDN RF MIBv2 and 3 open issues

This note = provides a status on the DOCSIS 2.0 RF MIB (aka rfmibv2).

In summary, 3 issues are still OPEN and the wg chairs would like to
have working group consensus by Friday October 10 on issues: #13, = #14,
 #16. Eduardo Cardona of = CableLabs has kindly accepted to help resolve
those and = will be posting some text soon.

Please read this carefully and raise = any concerns or objections to the
wg chairs on this action plan = by Friday Oct 10.

 -- Rich Woundy and Jean-Francois Mule', ipcdn co-chairs.

--- Status of RF MIBv2
Internet-Draft Name: DOCSIS 2.0 RF = MIB
            &= nbsp;        = draft-ietf-ipcdn-docs-rfmibv2-06.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-06.= txt
soon to be
draft-ietf-ipcdn-docs-rfmibv2-07.txt


1) = Follow-up on the IETF posting of rfmibv2-07
   The editor, David = Raftus sent draft-07 to the internet-draft on
   9/9. The revision has not shown up yet. This is probably = due to the
   fact that a zip file was attached instead of the plain text = file.
   Action Item (AI): wg chair to follow up on posting.


2) = Categorization of the remaining open issues
David Raftus sent a list of open = issues to the ipcdn list on 9/12/03,
see attached file rfdraftv7_issues_Sept12_2003.txt
The remaining open issues not addressed in draft-07 split into 2
categories:
- a) issue = is not required to be addressed ("nice to have")
  This category includes some = of the improvements that were not in the
  original scope of rfmibv2. A lot of improvements has been done = and
  it is time to freeze rfmibv2.
- b) issue = that should be addressed in draft v8 ("must fix")
  This category includes some = issues that need to be addressed.
  5 open issues are in this category.
=3D> Please raise any objection on the ipcdn list by COB Friday = 9/10/03
if you believe this is not reflecting the correct status of the = draft
or if you believe more open issues must be fixed.


3) Open = issues:
The numbering is based on David = Raftus status file sent on 9/12/2003
on the ipcdn list and attached to this posting.

+ Issue = #7:
Status: Closed (will be in = draft08)
(7) docsIfUpChannelPreEqEnable - add DEFVAL clause.
    Contributor - John Gillis ADC
David indicated that a defval is not required ("DEFVAL not = appropriate
here, also too many other items in same table do not have = DEFVAL").
# category: = "must fix"
# Eduardo = recommends to add a default value of false for this object.
# Action Item: add = DEFVAL false in draft 08

+ Issue = #13
Status: Open
(13) Adjust compliance statements for objects designated optional. = Add
     separate augmentation table for optional = objects in
     docsIfCmtsUpChannelCounterTable.
     Contributors - Will Murwin Motorola, Rich = Woundy IPCDN/Comcast,
     Mike StJohns Mindspring, Eduardo Cardona = Cablelabs
# category: = "must fix"
# Action Item: = Eduardo to summarize the discussion & a recommendation
# for the = augmentation. Consensus must be reached by 10/10 or else WG
# chair will make = a decision.

+ Issue = #14
Status: Open
(14) Add section explaining counter interaction between
     Docsis 1.0/1.1/2.0.
David indicated that this could be done in OSS spec but since rfmib = v2
obsoletes an exising IETF MIB, the wg chairs recommendation is to
include a section in the new MIB.
# category: = "must fix"
# Action Item: = Eduardo to propose some text.

+ Issue = #15
Status: Closed, pending ipcdn = review
(15) Change docsIfCmtsServiceTable to count packets for both = upstream
     and downstream flows.
David Raftus commented: "Will not do - inappropriate - table = indexed
by SID, SIDs are not defined for downstream flows".
WG chairs agree with David Raftus.
# category: = "nice to have", For further study.
# Action item: = none, issue is closed.

+ Issue = #16
Status: Open
(16) Add 4 objects to docsIfCmtsCmStatusTable
See David Raftus' status on this open issue and associated emails.
# category: = "nice to have"
# Action item: = Eduardo to close on this issue on the ipcdn mailing
# list. If no = consensus can be reached by Oct 10, wg chair will make a
# decision to = leave it out of rf mib v2.

+ Issue = #20
Status: Closed (will be in = draft08)
(20) Update snmpv3 references to latest mib versions
# category: = "must fix"
# Action item: = edit draft 08 and include proper refs in the document

+ Issue = #22
Status: Closed (pending ipcdn = review)
(22) Addition of object to report received power level per channel at = CMTS
# category: = "nice to have" -> out of scope
# Recommendation = is that this issue will not be addressed in any
# future revision = of RF MIB v2.
# Action item: = none, issue is closed.

------_=_NextPart_001_01C38879.99FBE2B4-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Oct 1 20:15:25 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 UAA11604 for ; Wed, 1 Oct 2003 20:15:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4r7X-0006JE-KI for ipcdn-archive@odin.ietf.org; Wed, 01 Oct 2003 20:15:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h920F3Fi024230 for ipcdn-archive@odin.ietf.org; Wed, 1 Oct 2003 20:15:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4r7U-0006I1-OR; Wed, 01 Oct 2003 20:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4r6Y-0006HQ-Qp for ipcdn@optimus.ietf.org; Wed, 01 Oct 2003 20:14:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11576 for ; Wed, 1 Oct 2003 20:13:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4r6W-0007QP-00 for ipcdn@ietf.org; Wed, 01 Oct 2003 20:14:00 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A4r6V-0007QA-00 for ipcdn@ietf.org; Wed, 01 Oct 2003 20:13:59 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h920DR10015558; Wed, 1 Oct 2003 18:13:27 -0600 (MDT) 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_01C3887A.00B59F86" Subject: RE: [ipcdn] Status of IPCDN RF MIBv2 and 3 open issues Date: Wed, 1 Oct 2003 18:13:27 -0600 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [ipcdn] Status of IPCDN RF MIBv2 and 3 open issues Thread-Index: AcNgJaYn06TBEeT1TRC5N0Q/BVl7hgT3JTZQBRgJoxAABa9pIAAANCCw From: "Jean-Francois Mule" To: "Ipcdn (E-mail)" Cc: "Eduardo Cardona" , "Richard Woundy" , "Bert Wijnen" , "Raftus, David" X-Approved: ondar 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_01C3887A.00B59F86 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C3887A.00B59F86" ------_=_NextPart_002_01C3887A.00B59F86 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the list of open issues (the "attachment" mentioned below). -----Original Message----- From: Jean-Francois Mule=20 Sent: Wednesday, October 01, 2003 6:11 PM To: Ipcdn (E-mail) Cc: Eduardo Cardona; Jean-Francois Mule; Richard Woundy; Bert Wijnen; Raftus, David Subject: [ipcdn] Status of IPCDN RF MIBv2 and 3 open issues =09 =09 This note provides a status on the DOCSIS 2.0 RF MIB (aka rfmibv2). =09 In summary, 3 issues are still OPEN and the wg chairs would like to have working group consensus by Friday October 10 on issues: #13, #14, #16. Eduardo Cardona of CableLabs has kindly accepted to help resolve=20 those and will be posting some text soon. =09 Please read this carefully and raise any concerns or objections to the wg chairs on this action plan by Friday Oct 10. =09 -- Rich Woundy and Jean-Francois Mule', ipcdn co-chairs. =09 --- Status of RF MIBv2 Internet-Draft Name: DOCSIS 2.0 RF MIB draft-ietf-ipcdn-docs-rfmibv2-06.txt =09 ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-06.txt =20 soon to be draft-ietf-ipcdn-docs-rfmibv2-07.txt =09 =09 1) Follow-up on the IETF posting of rfmibv2-07 The editor, David Raftus sent draft-07 to the internet-draft on 9/9. The revision has not shown up yet. This is probably due to the fact that a zip file was attached instead of the plain text file. Action Item (AI): wg chair to follow up on posting. =09 =09 2) Categorization of the remaining open issues David Raftus sent a list of open issues to the ipcdn list on 9/12/03, see attached file rfdraftv7_issues_Sept12_2003.txt The remaining open issues not addressed in draft-07 split into 2 categories: - a) issue is not required to be addressed ("nice to have") This category includes some of the improvements that were not in the original scope of rfmibv2. A lot of improvements has been done and it is time to freeze rfmibv2. - b) issue that should be addressed in draft v8 ("must fix") This category includes some issues that need to be addressed. 5 open issues are in this category. =3D> Please raise any objection on the ipcdn list by COB Friday 9/10/03 if you believe this is not reflecting the correct status of the draft or if you believe more open issues must be fixed. =09 =09 3) Open issues: The numbering is based on David Raftus status file sent on 9/12/2003 on the ipcdn list and attached to this posting. =09 + Issue #7: Status: Closed (will be in draft08) (7) docsIfUpChannelPreEqEnable - add DEFVAL clause. Contributor - John Gillis ADC David indicated that a defval is not required ("DEFVAL not appropriate here, also too many other items in same table do not have DEFVAL"). # category: "must fix" # Eduardo recommends to add a default value of false for this object. # Action Item: add DEFVAL false in draft 08 =09 + Issue #13 Status: Open (13) Adjust compliance statements for objects designated optional. Add separate augmentation table for optional objects in docsIfCmtsUpChannelCounterTable. Contributors - Will Murwin Motorola, Rich Woundy IPCDN/Comcast, Mike StJohns Mindspring, Eduardo Cardona Cablelabs # category: "must fix" # Action Item: Eduardo to summarize the discussion & a recommendation # for the augmentation. Consensus must be reached by 10/10 or else WG # chair will make a decision. =09 + Issue #14 Status: Open (14) Add section explaining counter interaction between Docsis 1.0/1.1/2.0. David indicated that this could be done in OSS spec but since rfmib v2 obsoletes an exising IETF MIB, the wg chairs recommendation is to include a section in the new MIB. # category: "must fix" # Action Item: Eduardo to propose some text. =09 + Issue #15 Status: Closed, pending ipcdn review (15) Change docsIfCmtsServiceTable to count packets for both upstream and downstream flows. David Raftus commented: "Will not do - inappropriate - table indexed by SID, SIDs are not defined for downstream flows". WG chairs agree with David Raftus. # category: "nice to have", For further study. # Action item: none, issue is closed. =09 + Issue #16 Status: Open (16) Add 4 objects to docsIfCmtsCmStatusTable See David Raftus' status on this open issue and associated emails. # category: "nice to have" # Action item: Eduardo to close on this issue on the ipcdn mailing # list. If no consensus can be reached by Oct 10, wg chair will make a # decision to leave it out of rf mib v2. =09 + Issue #20 Status: Closed (will be in draft08) (20) Update snmpv3 references to latest mib versions # category: "must fix" # Action item: edit draft 08 and include proper refs in the document =09 + Issue #22 Status: Closed (pending ipcdn review) (22) Addition of object to report received power level per channel at CMTS # category: "nice to have" -> out of scope # Recommendation is that this issue will not be addressed in any # future revision of RF MIB v2. # Action item: none, issue is closed.=20 ------_=_NextPart_002_01C3887A.00B59F86 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Here is the list of open issues (the "attachment" mentioned=20 below).
-----Original Message-----
From: = Jean-Francois=20 Mule
Sent: Wednesday, October 01, 2003 6:11 = PM
To: Ipcdn=20 (E-mail)
Cc: Eduardo Cardona; Jean-Francois Mule; Richard = Woundy;=20 Bert Wijnen; Raftus, David
Subject: [ipcdn] Status of IPCDN = RF MIBv2=20 and 3 open issues

This note = provides a=20 status on the DOCSIS 2.0 RF MIB (aka rfmibv2).

In summary, 3 = issues are=20 still OPEN and the wg chairs would like to
have working group = consensus by=20 Friday October 10 on issues: #13, #14,
 #16. Eduardo Cardona of CableLabs has kindly = accepted to=20 help resolve
those and will be posting some text soon.

Please read this carefully and raise any = concerns or=20 objections to the
wg chairs on this=20 action plan by Friday Oct 10.

 -- Rich Woundy and Jean-Francois Mule', ipcdn=20 co-chairs.

--- Status of RF MIBv2
Internet-Draft Name: DOCSIS 2.0 RF=20 = MIB
           =          =20 draft-ietf-ipcdn-docs-rfmibv2-06.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2= -06.txt
soon to=20 be
draft-ietf-ipcdn-docs-rfmibv2-07.txt


1) Follow-up on the IETF = posting of=20 rfmibv2-07
   The=20 editor, David Raftus sent draft-07 to the internet-draft = on
  =20 9/9. The revision has not shown up yet. This is probably due to=20 the
   fact that a zip file was attached instead of the = plain=20 text file.
   Action Item (AI): wg chair to follow up on=20 posting.


2)=20 Categorization of the remaining open issues
David Raftus sent a list of open issues = to the ipcdn=20 list on 9/12/03,
see attached file = rfdraftv7_issues_Sept12_2003.txt
The=20 remaining open issues not addressed in draft-07 split into=20 2
categories:
- a)=20 issue is not required to be addressed ("nice to have")
  This category includes some of = the=20 improvements that were not in the
  original scope of rfmibv2. = A lot=20 of improvements has been done and
  it is time to freeze=20 rfmibv2.
- b) issue=20 that should be addressed in draft v8 ("must fix")
  This category includes some = issues that need=20 to be addressed.
  5 open issues are in this = category.
=3D> Please=20 raise any objection on the ipcdn list by COB Friday 9/10/03
if you = believe=20 this is not reflecting the correct status of the draft
or if you = believe=20 more open issues must be fixed.


3) Open issues:
The numbering is based on David Raftus status file sent on=20 9/12/2003
on the ipcdn list and attached to this=20 posting.

+ Issue=20 #7:
Status: Closed (will = be in=20 draft08)
(7) docsIfUpChannelPreEqEnable - add DEFVAL=20 clause.
    Contributor - John Gillis ADC
David = indicated=20 that a defval is not required ("DEFVAL not appropriate
here, also = too many=20 other items in same table do not have DEFVAL").
# category: "must = fix"
# Eduardo recommends to = add a default=20 value of false for this object.
# Action Item: add DEFVAL false in draft=20 08

+ = Issue=20 #13
Status: Open
(13) = Adjust=20 compliance statements for objects designated optional.=20 Add
     separate augmentation table for = optional=20 objects in
    =20 docsIfCmtsUpChannelCounterTable.
     = Contributors -=20 Will Murwin Motorola, Rich Woundy = IPCDN/Comcast,
    =20 Mike StJohns Mindspring, Eduardo Cardona Cablelabs
# category: "must = fix"
# Action Item: Eduardo = to summarize=20 the discussion & a recommendation
# for the augmentation. Consensus must be = reached by=20 10/10 or else WG
#=20 chair will make a decision.

+ Issue #14
Status: Open
(14) Add section explaining counter = interaction=20 between
     Docsis 1.0/1.1/2.0.
David = indicated=20 that this could be done in OSS spec but since rfmib v2
obsoletes an = exising=20 IETF MIB, the wg chairs recommendation is to
include a section in = the new=20 MIB.
# = category: "must=20 fix"
# = Action Item:=20 Eduardo to propose some text.

+ Issue #15
Status: Closed, pending ipcdn review
(15) Change=20 docsIfCmtsServiceTable to count packets for both=20 upstream
     and downstream flows.
David = Raftus=20 commented: "Will not do - inappropriate - table indexed
by SID, = SIDs are=20 not defined for downstream flows".
WG chairs agree with David=20 Raftus.
# category:=20 "nice to have", For further study.
# Action item: none, issue is = closed.

+ Issue = #16
Status: Open
(16) Add 4 objects to=20 docsIfCmtsCmStatusTable
See David Raftus' status on this open issue = and=20 associated emails.
#=20 category: "nice to have"
# Action item: Eduardo to close on this issue on the ipcdn=20 mailing
# list. If no=20 consensus can be reached by Oct 10, wg chair will make = a
# decision to leave it = out of rf mib=20 v2.

+ Issue=20 #20
Status: Closed (will = be in=20 draft08)
(20) Update snmpv3 references to latest mib=20 versions
# category:=20 "must fix"
# Action=20 item: edit draft 08 and include proper refs in the=20 document

+ Issue=20 #22
Status: Closed = (pending ipcdn=20 review)
(22) Addition of object to report received power level per = channel=20 at CMTS
# category:=20 "nice to have" -> out of scope
# Recommendation is that this issue will not = be addressed=20 in any
# = future=20 revision of RF MIB v2.
# Action item: none, issue is closed.=20

=00 ------_=_NextPart_002_01C3887A.00B59F86-- ------_=_NextPart_001_01C3887A.00B59F86 Content-Type: text/plain; name="rfdraftv7_issues_Sept12_2003.txt" Content-Transfer-Encoding: base64 Content-Description: rfdraftv7_issues_Sept12_2003.txt Content-Disposition: attachment; filename="rfdraftv7_issues_Sept12_2003.txt" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 U2VwdCAxMC8wMyAtIFN0YXR1cyBvZiBzdWdnZXN0ZWQgcmYgbWliIGNoYW5nZXMsIGNvcnJlc3Bv bmRpbmcgdG8gaXRlbXMgaW4gdGhpcyBkb2MNCjEpIENvbXBsZXRlIC0gdjcNCjIpIENvbXBsZXRl IC0gdjcNCjMpIENvbXBsZXRlIC0gdjcNCjQpIENvbXBsZXRlIC0gdjcNCjUpIENvbXBsZXRlIC0g djcNCjYpIENvbXBsZXRlIC0gdjcNCjcpIFdpbGwgbm90IGRvIC0gREVGVkFMIG5vdCBhcHByb3By aWF0ZSBoZXJlLCBhbHNvIHRvbyBtYW55IG90aGVyIGl0ZW1zIGluIHNhbWUgdGFibGUgZG8gbm90 IGhhdmUgREVGVkFMDQo4KSBDb21wbGV0ZSAtIHY3DQo5KSBDb21wbGV0ZSAtIHY3DQoxMCkgQ29t cGxldGUgLSB2Nw0KMTEpIENvbXBsZXRlIC0gdjcNCjEyKSBDb21wbGV0ZSAtIHY3DQoxMykgTm90 IHlldCAtIHY4DQoxNCkgV2lsbCBub3QgZG8gLSBtb3JlIGFwcHJvcHJpYXRlIHRvIGhhdmUgaW4g T1NTIHNwZWMNCjE1KSBXaWxsIG5vdCBkbyAtIGluYXBwcm9wcmlhdGUgLSB0YWJsZSBpbmRleGVk IGJ5IFNJRCwgU0lEcyBhcmUgbm90IGRlZmluZWQgZm9yIGRvd25zdHJlYW0gZmxvd3MNCjE2KSBX YXMgZG9uZSBmb3IgdjcsIHJldmVyc2VkIGR1ZSB0byBjb250aW51aW5nIGRlYmF0ZSAtIG5vdyB2 OA0KMTcpIENvbXBsZXRlIC0gdjcNCjE4KSBDb21wbGV0ZSAtIHY3DQoxOSkgQ29tcGxldGUgLSB2 Nw0KMjApIE5vdCB5ZXQgLSB2OA0KMjEpIENvbXBsZXRlIC0gdjcNCjIyKSBXaWxsIG5vdCBkbyBu b3cgLSBtdXN0IGJlIGRlYmF0ZWQgLSB2OA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqOA0KDQoxKSBSZXR1cm4gbmFtZSB0 byBwcmUgZHJhZnQgdjYgRE9DUy1JRi1NSUIgZnJvbSBkcmFmdCB2NiANCkRPQ1MtSUVURi1SRkkt TUlCLiANCkNvbnRyaWJ1dG9ycyAtIFJpY2ggV291bmR5IElQQ0ROL0NvbWNhc3QsIE1pbm5pZSBM dSBDaXNjbywgU3RldmUgDQpNYWxlbmZhbnQgQ29tMjEgDQoNCjIpIGRvY3NJZkNtdHNDaGFubmVs VXRVdGlsaXphdGlvbiBmb3JtdWxhIC0gcmVtb3ZlIGxpbmUgKDEwMCAqICgocmF3IA0KYnl0ZXMg LSBzdHVmZmVkIGJ5dGVzKSAvIHJhdyBieXRlcykpIA0Kc2luY2UgaXQgYXNzdW1lcyB0aGF0IE1Q RUcgcGF5bG9hZCBjb25zaXN0cyBvbmx5IERPQyBNQUMgcGF5bG9hZC4gQXMgd2UgDQprbm93LCBN UEVHIGNvdWxkIGNvbnNpc3QgdmlkZW8gcGF5bG9hZCBhbmQgTlVMTCBwYWNrZXRzLiBTdWdnZXN0 IHRvIA0KcmVtb3ZlIA0KdGhpcyBsaW5lIHNpbmNlIHRoZSBmaXJzdCAyIGxpbmVzIGluIHRoZSBm b3JtdWxhIGFyZSBnb29kIGVub3VnaC4gDQpDb250cmlidXRvciAtIE1pbm5pZSBMdSAgICBDaXNj byANCg0KMykgQWRkIGRpc2NvbnRpbnVpdHkgZGVzY3JpcHRpb25zIHRvIGFsbCBjb3VudGVycyBy ZWxhdGVkIHRvIGFuIA0KaW50ZXJmYWNlLiANCkNvbnRyaWJ1dG9yIC0gTWlubmllIEx1ICAgIENp c2NvIA0KDQo0KSBkb2NzSWZDbXRzSW5zZXJ0SW50ZXJ2YWwgLSBGb3IgdGhlIGRvY3NJZkNtdHNJ bnNlcnRJbnRlcnZhbCBvYmplY3QsIA0KdGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBhIA0KImJy b2FkY2FzdCBzdGF0aW9uIG1haW50ZW5hbmNlIiBpbnRlcnZhbCBmb3IgbmV3IG1vZGVtcyBqb2lu aW5nIHRoZSANCm5ldHdvcmsuICAgU3RhdGlvbiBzaG91bGQgYmUgDQpjaGFuZ2VkIHRvIGluaXRp YWwgdG8gbWFrZSB0aGUgdGV4dCByZWFkIC0gIlRoZSBhbW91bnQgb2YgdGltZSB0byBlbGFwc2Ug DQpiZXR3ZWVuIGVhY2ggYnJvYWRjYXN0IA0KaW5pdGlhbCBtYWludGVuYW5jZSBncmFudC4gIEJy b2FkY2FzdCBpbml0aWFsIG1haW50ZW5hbmNlIGdyYW50cyBhcmUgDQp1c2VkIHRvIGFsbG93IG5l dyBjYWJsZSBtb2RlbXMgDQp0byBqb2luIHRoZSBuZXR3b3JrLiAgWmVybyBpbmRpY2F0ZXMgdGhh dCBhIHZlbmRvci1zcGVjaWZpYyBhbGdvcml0aG0gaXMgDQp1c2VkIGluc3RlYWQgb2YgYSBmaXhl ZCB0aW1lLiANCk1heGltdW0gYW1vdW50IG9mIHRpbWUgcGVybWl0dGVkIGJ5IHRoZSBzcGVjaWZp Y2F0aW9uIGlzIDIgc2Vjb25kcy4iIA0KQ29udHJpYnV0b3IgLSBNYXJnbyBEb2xhcyBCcm9hZGNv bSANCg0KNSkgZG9jc0lmQ210c01vZFByZWFtYmxlVHlwZSAtIChKb2VsKSBJbiBkb2NzSWZDbXRz TW9kdWxhdGlvblRhYmxlLCB0aGUgDQpkb2NzSWZDbXRzTW9kUHJlYW1ibGVUeXBlIG9iamVjdCBo YXMgDQoyIHBvc3NpYmxlIHZhbHVlcyBxcHNrMCgxKSBhbmQgcXBzazEoMikuIEl0IHNlZW1zIGxp a2UgaXQncyB0aGUgb25seSANCm9iamVjdCBpbiB0aGlzIHRhYmxlIHdpdGhvdXQgYSANCm1lYW5p bmdmdWwgZGVmYXVsdCB2YWx1ZSB3aGVuIHRoaXMgcGFyYW1ldGVyIGRvZXMgbm90IG1ha2Ugc2Vu c2UuIEZvciANCmluc3RhbmNlLCBmb3IgYSBURE1BIG1vZHVsYXRpb24gDQpwcm9maWxlIHVzaW5n IFFBTTE2LCB0aGUgYWN0dWFsIHByZWFtYmxlIHR5cGUgaXMgaW5kZWVkIG5vdCBRUFNLMCBidXQg DQpzb21ldGhpbmcgZWxzZS4gRG9lcyBpdCBtYWtlIHNlbnNlIA0KdG8gaGF2ZSBhIHZhbHVlIG9m IDAgaW4gdGhpcyBjYXNlLCBsaWtlIA0KZG9jc0lmQ210c01vZFNjZG1hSW50ZXJsZWF2ZXJTdGVw U2l6ZSBmb3Igbm9uLVNDRE1BIHByb2ZpbGVzPyANCihFZHVhcmRvKSBmb3IgdGhlIGJlbmVmaXQg b2YgY2xhcmlmaWNhdGlvbnMgd291bGRuJ3QgYmUgZ29vZCB0byBoYXZlIGEgDQplbnVtZXJhdGlv biB1bmtub3duKDApIGZvciB0aGlzIA0Kb2JqZWN0IHdoZW4gbm90IGEgMi4wIGJ1cnN0ID8gDQpB bHNvIGEgbm90ZSBpbiB0aGUgREVTQ1JJUFRJT04gbGlrZSAiaWYgZG9jc0lmQ210c01vZENoYW5u ZWxUeXBlIGlzIA0KdGRtYSgxKSBhIHZhbHVlIHVua25vd24oMCkgaXMgdXNlZCBmb3IgdGhpcyBv YmplY3QiIA0KSSB3b3VsZCBzYXkgdW5rbm93bigwKSByYXRoZXIgdGhhbiB1bmtub3duKDMpIHNp bmNlIGl0IGxvb2tzIGxpa2UgdGhlIA0KcG9zc2libGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBt YXkgYmUgcmVwb3J0aW5nIA0KJzAnICwgYW5kIGRlZmVuZGFibGUgaW4gSUVURiBzaW5jZSBSRkMg MzI5MSB1c2VzICcwJyBmb3IgaW5ldEFkZHJlc3NUeXBlIA0KQ29udHJpYnV0b3JzIC0gSm9lbCBE ZW1hcnR5IEp1bmlwZXIsIEVkdWFyZG8gQ2FyZG9uYSBDYWJsZWxhYnMgDQoNCjYpIGRvY3NJZlVw c3RyZWFtQ2hhbm5lbFRhYmxlIGNsb25lIG1lY2hhbmlzbSAtIGltcHJvdmUgZGVzY3JpcHRpdmUg DQp3b3JkaW5nLiBUaGUgc3BlYyBpcyB2YWd1ZSBhYm91dCB0aGUgbWluaW11bSBzZXQgb2YgcGFy YW1ldGVycyANCnRoYXQgdGhlIA0KQ01UUyBtdXN0IHRyYW5zZmVyIGR1cmluZyBhIGNsb25lIG9w ZXJhdGlvbiB0byBiZSBET0NTSVMgMi4wIGNvbXBsaWFudC4gDQpPbmx5IHRob3NlIHN0YXJ0aW5n IHdpdGggZG9jc0lmVXBDaGFubmVsU2NkbWEgb3IgDQphbGwgcGFyYW1ldGVycyBkZWZpbmluZyBh biBTQ0RNQSBjaGFubmVsLCBsaWtlIHRoZSBjaGFubmVsIHdpZHRoPyBUaGVuIA0Kd2hhdCBhYm91 dCB0aGUgZnJlcXVlbmN5PyANCkRlZmluaXRlbHksIHRoaXMgY2xvbmUgbWVjaGFuaXNtIGlzIHNv cGhpc3RpY2F0ZWQgZW5vdWdoIHRoYXQgaXQgd291bGQgDQpkZXNlcnZlIGEgbW9yZSBkZXRhaWxl ZCBzcGVjaWZpY2F0aW9uIA0KKGFuZCB0ZXN0aW5nKSBhbmQsIGFzIGEgY29uc2VxdWVuY2UsIGFu IEVDUi4gDQpDb250cmlidXRvciAtIEpvZWwgRGVtYXJ0eSBKdW5pcGVyIA0KDQo3KSBkb2NzSWZV cENoYW5uZWxQcmVFcUVuYWJsZSAtIGFkZCBERUZWQUwgY2xhdXNlLiANCkNvbnRyaWJ1dG9yIC0g Sm9obiBHaWxsaXMgQURDIA0KDQo4KSBkb2NzSWZDbXRzVXBDaG5sQ3RyVWNhc3RHcmFudGVkTXNs b3RzIC0gSW4gQ2lzY28gQ01UUywgd2UgdXNlIElVQzE0IA0KKHJlc2VydmVkKSBhbmQgU0lEIChI RVgpOiAxRkZGIChtYXguIG9mIA0KdW5pY2FzdCBzaWQgbnVtYmVyKSBmb3IgcXVpdGUgc29tZSB0 aW1lLiANClE6IFNob3VsZCBpdCBiZSBjb3VudGVkIGluIGRvY3NJZkNtdHNVcENobmxDdHJVY2Fz dEdyYW50ZWRNc2xvdHMgPyANCk15IHBlcnNvbmFsIHRoaW5rIHRoYXQgdGhpcyBvYmplY3RzIHNl ZW1zIHRvIG1lYW4gdGhlIA0KbWVhbmluZ2Z1bCAgVU5JQ0FTVCBTSUQsIHNvIHVzZXIgY291bGQg Z2V0IGEgZ29vZCBpZGVhIGFib3V0IHRoZSBob3cgDQptYW55IA0KbWluaXNsb3RzIHJlYWxseSBh c3NpZ25lZCB0byBzb21lIG1lYW5pbmdmdWwgQ00uICBTbywgdGhlIHJlc2VydmVkIElVQ3MgDQpz aG91bGQgYmUgZXhjbHVkZWQgZnJvbSB0aGlzIG9iamVjdCB0aG91Z2ggbWluaXNsb3RzIGZvciBy ZXNlcnZlZCBJVUNzIA0KYXJlIA0Kc3RpbGwgYmUgY291bnRlZCBpbnRvIGRvY3NJZkNtdHNVcENo bmxDdHJUb3RhbE1zbG90cy4gDQpNaW5uaWUsIA0KSSBhZ3JlZSwgSSB0aGluayBJVUMxNCBncmFu dHMgdG8gU0lEIDFGRkYgKGFzc3VtaW5nIHRoZSBDTVRTIHJlc2VydmVzIA0KdGhhdCBTSUQgdG8g bWVhbiBubyBDTSkgc2hvdWxkIG5vdCBiZSBjb3VudGVkIGluIFVjYXN0R3JhbnRlZE1zbG90cy4g DQpJIGFsc28gdGhpbmsgKGFuZCBtYXliZSB0aGlzIGNhc2UgaXMgbW9yZSBvYnZpb3VzKSB0aGFu IGdyYW50cyB0byBTSUQgMCANCnNob3VsZCBub3QgYmUgY291bnRlZCBpbiBVY2FzdEdyYW50ZWRN c2xvdHMuIA0KVGhpcyBicmluZ3MgdXAgYSBxdWVzdGlvbiB0aGF0IEkndmUgaGFkIGZvciBzb21l IHRpbWUuICBXaHkgZG9lcyB0aGUgDQpDaXNjbyBDTVRTIHVzZSBJVUMxNCBhbmQgU0lEIDFGRkY/ Pz8/ICBUaGUgdXNlIG9mIElVQzE0IGlzIHByb2hpYml0ZWQgYnkgDQp0aGUgc3BlYywgc2luY2Ug aXQgaXMgbGFiZWxlZCBhcyAiUmVzZXJ2ZWQiLCBhbmQgU0lEIDAgaXMgYWxyZWFkeSANCmRlZmlu ZWQgdG8gbWVhbiAibm8gQ00iLiANCi1HcmVnIA0KQ29udHJpYnV0b3JzIC0gTWlubmllIEx1IENp c2NvLCBHcmVnIFdoaXRlIENhYmxlbGFicyANCg0KOSkgZG9jc0lmQ21TdGF0dXNUYWJsZSAtIHBv c3NpYmx5IGFkZCBuZXcgb2JqZWN0cyBmb3Igc3VjY2Vzc2Z1bC9mYWlsZWQgDQp1Y2MgdHJhbnNh Y3Rpb25zLiANCkhpLCBBbGV4LCANCkkgZG8gbm90IHRoaW5rIHRoYXQgdGhpcyBpcyBnb29kIGlk ZWEuIFdoYXQgd2lsbCB5b3UgY291bnQgaW50byANCmRvY3NRb3NEQ0NBY2tzPyBUaGUgcmVsYXRp b25zaGlwcyBiZXR3ZWVuIERDQyBSZXEvUnNwL0FjayBpcyBpbXBvcnRhbnQgDQphbmQgDQpzaG91 bGQgbm90IGJlIGxvc3QgYmVjYXVzZSBvZiBVQ0MgYWRkaXRpb25zLiBJIGd1ZXNzLCB0aGUgYmV0 dGVyIHBsYWNlIA0KZm9yIA0KdGhpcyBjb3VudGVycyBpcyBSRkkgTUlCIGRvY3NJZkNtU3RhdHVz VGFibGUuIEl0IG1heSBiZSBleHRlbmRlZCBpbiANCmZ1dHVyZSANCnZlcnNpb25zLiANClJlZ2Fy ZHMuIA0KTHVjeSANCkhlbGxvIGFsbCwgDQpBIHF1ZXN0aW9uIGFib3V0IGNvdW50aW5nIHN1Y2Nl c3NmdWwgYW5kIGZhaWxlZCBVQ0MgdHJhbnNhY3Rpb25zLiANCkl0IHNlZW1zIGxpa2UgdGhlcmUg aXMgbm8gY291bnRlcnMgZGVkaWNhdGVkIGZvciBVQ0MgZmFpbGVkIG9yIA0Kc3VjY2VlZGVkIG9w ZXJhdGlvbiBhcyBpdCBpcyBmb3IgRENDIHRyYW5zYWN0aW9ucy4gDQpUaGUgcXVlc3Rpb24gaXMs IHNpbmNlIFVDQyBpcyBhIHN1YnNldCBvZiBEQ0Mgb3BlcmF0aW9uIGZvciAxLjEgbW9kZW0sIA0K c2hvdWxkIHRoZSBtb2RlbSBjb3VudCBVQ0MgdHJhbnNhY3Rpb25zIGluIERDQyBjb3VudGVycyAo ZG9jc1Fvc0RDQ3MsIA0KZG9jc1Fvc0RDQ0ZhaWxzKSA/IA0KVGhhbmsgeW91IGluIGFkdmFuY2Uu IA0KQ29udHJpYnV0b3JzIC0gTHVjeSBQb2xsYWsgVEksIEFsZXggQmV0aXMgQ29yZXNtYSANCg0K MTApIGRvY3NJZlVwQ2hhbm5lbFByZUVxRW5hYmxlLCBkb2NzSWZDbVN0YXR1c0VxdWFsaXphdGlv bkRhdGEgLSBjbGFyaWZ5IA0KZGVzY3JpcHRpb25zLiANCkx1Y3ksIA0KU29ycnkgZm9yIHRoZSBk ZWxheSBpbiByZXNwb25kaW5nLiAgSSBkb24ndCBoYXZlIGFuIG9iamVjdGlvbiB0byB5b3VyIA0K cHJvcG9zYWwsIGFzIGxvbmcgYXMgdGhlIA0KZm9ybWF0IG9mIHRoZSBvYmplY3QgaXMgY2xlYXIu IA0KVG8gc3VtbWFyaXplLCB0aGUgb2JqZWN0IGRvY3NJZkNtU3RhdHVzRXF1YWxpemF0aW9uRGF0 YSB3aWxsIG9ubHkgDQppbmNsdWRlIHRoZSAidmFsdWUiIGZyb20gZmlndXJlIDgtMjMuIA0KSW4g b3RoZXIgd29yZHMsIHRoZSBmaXJzdCBieXRlIHJlcG9ydGVkIGluIHRoZSBNSUIgb2JqZWN0IHdp bGwgYmUgdGhlIA0KbWFpbiB0YXAgbG9jYXRpb24uICBBIGNsYXJpZmljYXRpb24gDQpzaG91bGQg YWxzbyBiZSBtYWRlIHRvIHRoZSBkZXNjcmlwdGlvbiBvZiBkb2NzSWZVcENoYW5uZWxQcmVFcUVu YWJsZSB0byANCmluZGljYXRlIHlvdXIgaW50ZXJwcmV0YXRpb24gKGIpLiANClJlZ2FyZGluZyB0 aGUgcXVlc3Rpb24gYWJvdXQgcmV2ZXJzZSB0YXBzLCBmaWd1cmUgOC0yMyBpcyBhIA0Kc2ltcGxp ZmljYXRpb24gb2YgZmlndXJlIDYtMjMgZnJvbSB0aGUgMS4xIFJGSSANCnNwZWMgKHdoaWNoIGlu Y2x1ZGVzIGEgZm9ybWF0IHRvIGVuY29kZSByZXZlcnNlIHRhcHMpLiAgSXQgc2VlbXMgdG8gbWFr ZSANCnNlbnNlIHRvIG1lIHRvIHVzZSB0aGUgZm9ybWF0IA0Kc2hvd24gaW4gdGhhdCBmaWd1cmUu ICBQZXJoYXBzIHRoaXMgTUlCIG9iamVjdCBjb3VsZCBiZSBjbGFyaWZpZWQgdG8gDQpyZWZlcmVu Y2UgYm90aCBmaWd1cmVzLiANCi1HcmVnIA0KR3JlZywgDQp0byBzdW1tYXJpemUgb3VyIG9iamVj dGlvbnM6IA0KMS4gTUlCIHJlcXVpcmVzIGVxdWFsaXphdGlvbiBkYXRhLCB0aGVuIHR5cGUvbGVu Z3RoIGlzIGlycmVsZXZhbnQuIA0KMi4gVGhlcmUgYXJlIDIgcG9zc2libGUgdHlwZXMgNCAoVHJh bnNtaXQgRXF1YWxpemF0aW9uIEFkanVzdCkgb3IgOSANCihUcmFuc21pdCBFcXVhbGl6YXRpb24g U2V0KSwgd2hpY2ggaXMgDQppcnJlbGV2YW50IGFmdGVyIGNvbnZvbHV0aW9uLiANCjMuIFRvIGJl IGNvbnNpc3RlbnQgd2l0aCBEUyBlcXVhIGRhdGEsIHNvbWUgVExWIHNob3VsZCBiZSBhZGRlZCBh bHNvIA0KaW50byBpdC4gV2hhdD8gDQpXZSBwcm9wb3NlIHRvIHVzZSBvbmx5IHZhbHVlIGZyb20g cmVmZXJlbmNlZCBmaWd1cmUgd2l0aG91dCB0eXBlL2xlbmd0aCANCnRvIGF2b2lkIHF1ZXN0aW9u cyBpbiB0aGUgZnV0dXJlLiBJZiBub3QsIA0KKDIpIGFuZCAoMykgc2hvdWxkIGJlIGNsYXJpZmll ZC4gSSBndWVzcywgdGhhdCBpdCB3aWxsIGJlIGFsc28gdmVyeSANCmhlbHBmdWwgaWYgY2xhcmlm aWNhdGlvbiAoYikgd2lsbCBiZSBlbnRlcmVkIGludG8gTUlCLiANCkJlc3QgUmVnYXJkcy4gDQpM dWN5IA0KQ29udHJpYnV0b3JzIC0gTHVjeSBQb2xsYWsgVEksIEdyZWcgV2hpdGUgQ2FibGVsYWJz IA0KDQoxMSkgZG9jc0lmU2lnbmFsUXVhbGl0eUVudHJ5IC0gY2xhcmlmeSB3b3JkaW5nIGZvciBi YWNrIGNvbXBhdGliaWxpdHkuIA0KSW4gZHJhZnQgLTAzIHRoZSBkZXNjcmlwdGlvbiBvZiAgZG9j c0lmU2lnbmFsUXVhbGl0eUVudHJ5IHdhcyBjaGFuZ2VkIA0KZnJvbSA6IA0KZG9jc0lmU2lnbmFs UXVhbGl0eUVudHJ5IE9CSkVDVC1UWVBFIA0KICAgICAgICAgICBTWU5UQVggICAgICBEb2NzSWZT aWduYWxRdWFsaXR5RW50cnkgDQogICAgICAgICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxl IA0KICAgICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IA0KICAgICAgICAgICBERVNDUklQVElP TiANCiAgICAgICAgICAgICAgICJBdCB0aGUgQ00sIGRlc2NyaWJlcyB0aGUgUEhZIGNoYXJhY3Rl cmlzdGljcyBvZiBhIA0KICAgICAgICAgICAgICAgIGRvd25zdHJlYW0gY2hhbm5lbC4gQXQgdGhl IENNVFMsIGRlc2NyaWJlcyB0aGUgUEhZIA0Kc2lnbmFsIA0KICAgICAgICAgICAgICAgIHF1YWxp dHkgb2YgYW4gdXBzdHJlYW0gY2hhbm5lbC4gDQogICAgICAgICAgICAgICAgQW4gZW50cnkgaW4g dGhpcyB0YWJsZSBleGlzdHMgZm9yIGVhY2ggaWZFbnRyeSB3aXRoIGFuIA0KICAgICAgICAgICAg ICAgIGlmVHlwZSBvZiBkb2NzQ2FibGVVcHN0cmVhbSgxMjkpIGZvciBDYWJsZSBNb2RlbSANClRl cm1pbmF0aW9uIA0KICAgICAgICAgICAgICAgIFN5c3RlbXMgYW5kIGRvY3NDYWJsZURvd25zdHJl YW0oMTI4KSBmb3IgQ2FibGUgTW9kZW1zLiIgDQogICAgICAgICAgIElOREVYIHsgaWZJbmRleCB9 IA0KICAgICAgICAgICA6Oj0geyBkb2NzSWZTaWduYWxRdWFsaXR5VGFibGUgMSB9IA0KdG8gOiAN CmRvY3NJZlNpZ25hbFF1YWxpdHlFbnRyeSBPQkpFQ1QtVFlQRSANCiAgICAgICAgU1lOVEFYICAg ICAgRG9jc0lmU2lnbmFsUXVhbGl0eUVudHJ5IA0KICAgICAgICBNQVgtQUNDRVNTICBub3QtYWNj ZXNzaWJsZSANCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudCANCiAgICAgICAgREVTQ1JJUFRJ T04gDQogICAgICAgICAgICAiQXQgdGhlIENNLCBkZXNjcmliZXMgdGhlIFBIWSBjaGFyYWN0ZXJp c3RpY3Mgb2YgYSANCiAgICAgICAgICAgICBkb3duc3RyZWFtIGNoYW5uZWwuIEF0IHRoZSBDTVRT LCBkZXNjcmliZXMgdGhlIFBIWSBzaWduYWwgDQogICAgICAgICAgICAgcXVhbGl0eSBvZiBhbiB1 cHN0cmVhbSBjaGFubmVsLiANCiAgICAgICAgICAgICBBbiBlbnRyeSBpbiB0aGlzIHRhYmxlIGV4 aXN0cyBmb3IgZWFjaCBpZkVudHJ5IHdpdGggYW4gDQogICAgICAgICAgICAgaWZUeXBlIG9mIGRv Y3NDYWJsZVVwc3RyZWFtQ2hhbm5lbCgyMDUpIGZvciBDYWJsZSBNb2RlbSANClRlcm1pbmF0aW9u IA0KICAgICAgICAgICAgIFN5c3RlbXMgYW5kIGRvY3NDYWJsZURvd25zdHJlYW0oMTI4KSBmb3Ig Q2FibGUgTW9kZW1zLiIgDQogICAgICAgIElOREVYIHsgaWZJbmRleCB9IA0KICAgICAgICA6Oj0g eyBkb2NzSWZTaWduYWxRdWFsaXR5VGFibGUgMSB9IA0KQnV0IG5vdyBSRkkgbWliIGFsc28gYXBw bHkgdG8gMS4xIENNVFNlcyB3aXRoIG5vIGNvbmNlcHQgb2YgaWZUeXBlIDIwNSANCmJ1dCAxMjkg DQpDb250cmlidXRvciAtIEVkdWFyZG8gQ2FyZG9uYSBDYWJsZWxhYnMgDQoNCjEyKSBkb2NzSWZD bXRzQ21TdGF0dXNWYWx1ZSAtIGFkZCBuZXcgZGVmaW5lZCB2YWx1ZSANCnJlZ2lzdGVyZWRCUElJ bml0aWFsaXppbmcoOSksIA0KZGVwcmVjYXRlIGZvcm1lciB2YWx1ZSBvcGVyYXRpb25hbCg4KS4g DQpDb250cmlidXRvcnMgLSBFZHVhcmRvIENhcmRvbmEgQ2FibGVsYWJzLCBMdWN5IFBvbGxhayBU SSwgTWlubmllIEx1IA0KQ2lzY28sIERhdmlkIFdoaXRlIEFycmlzLCANCk1hdHQgU2NobWl0dCBB cnJpcywgS2lyayBGcmllZG1hbiBDb3JyZWxhbnQsIEZyZWQgT2tvIFN0YXJndXMsIEpvZSBHb2Rh cyANCkthci1lbCwgU3RldmUgTWFsZW5mYW50IENvbTIxIA0KDQoxMykgQWRqdXN0IGNvbXBsaWFu Y2Ugc3RhdGVtZW50cyBmb3Igb2JqZWN0cyBkZXNpZ25hdGVkIG9wdGlvbmFsLiBBZGQgDQpzZXBh cmF0ZSBhdWdtZW50YXRpb24gdGFibGUgZm9yIA0Kb3B0aW9uYWwgb2JqZWN0cyBpbiBkb2NzSWZD bXRzVXBDaGFubmVsQ291bnRlclRhYmxlLiANCkNvbnRyaWJ1dG9ycyAtIFdpbGwgTXVyd2luIE1v dG9yb2xhLCBSaWNoIFdvdW5keSBJUENETi9Db21jYXN0LCBNaWtlIA0KU3RKb2hucyBNaW5kc3By aW5nLCBFZHVhcmRvIENhcmRvbmEgQ2FibGVsYWJzIA0KDQoxNCkgQWRkIHNlY3Rpb24gZXhwbGFp bmluZyBjb3VudGVyIGludGVyYWN0aW9uIGJldHdlZW4gRG9jc2lzIA0KMS4wLzEuMS8yLjAuIA0K VGhlIFFPUyBNSUIgdHJpZWQgdG8gaGFuZGxlIA0KRE9DU0lTIDEuMSBjaGFuZ2VzIHRvIFJGQzI2 NzAuIE5vdyB0aGF0IHJmYzI2NzAgaXMgYmVpbmcgb2Jzb2xldGVkLCB0aGUgDQpyZi1taWIgdjIg YW5kIHRoZSBET0NTSVMgT1NTIFNwZWNzIGlzIHRoZSBwbGFjZSANCnRoYXQgc2hvdWxkIGNsZWFy bHkgc3RhdGUgaG93IHRoZXNlIGNvdW50ZXJzIGFuZCBvdGhlciB0YWJsZXMgaW50ZXJhY3QgDQpp biBET0NTSVMgMS4wLCBET0NTSVMgMS4xLCBhbmQgRE9DU0lTIDIuMC4gDQpJIHdvdWxkIGV2ZW4g aG9wZSB0byBzZWUgYSBzZWN0aW9uIGluIHRoZSByZi1taWIgdjIsICJJbnRlcm9wZXJhdGlvbiAN CndpdGggdGhlIHZlcnNpb24gb2YgRE9DU0lTIiBsaWtlIG9yIHRvIHJlcGxhY2UgDQp3aGF0IHRo ZSBET0NTSVMgUU9TIE1JQiBoYXMuIFRoaXMgaXMgdGhlIHBsYWNlIHRvIGRlc2NyaWJlIHdoYXQg dGFibGUgDQphcmUgcG9wdWxhdGVkIHVuZGVyIHRoZSBkb2NzSWZNaWIgd2hlbiB0aGUgDQp0aGUg bW9kZW1zIGFyZSByZWdpc3RlcmluZy4gDQpUaGlzIHdheSB0aGlzIGlzc3VlIGNhbiBiZSByZS1k aXNjdXNzZWQgYW5kIHdoYXRldmVyIGNvbmN1bHNpb24gaXMgDQpyZWFjaGVkLCBjYW4gYmUgZG9j dW1lbnQgaW4gdGhlIGRlc2NyaXB0aW9uIG9mIHRob3NlIA0Kb2JqZWN0cy4gDQpDb250cmlidXRv ciAtIFdpbGwgTXVyd2luIE1vdG9yb2xhLCBNaW5uaWUgTHUgQ2lzY28gDQoNCjE1KSBDaGFuZ2Ug ZG9jc0lmQ210c1NlcnZpY2VUYWJsZSB0byBjb3VudCBwYWNrZXRzIGZvciBib3RoIHVwc3RyZWFt IGFuZCANCmRvd25zdHJlYW0gZmxvd3MuIA0KT25lIG9mIHRoZSB0aGluZ3MgdGhhdCBoYXMgbG9u ZyBiZWVuIGFuIGlzc3VlIHdpdGggdGhlIFJGIE1JQiBpcyB0aGF0IA0KdGhlIGRvY3NJZkNtdHNT ZXJ2aWNlVGFibGUgb25seSBjb3VudHMgDQpJbk9jdGV0cyBhbmQgSW5QYWNrZXRzIChpLmUuIHVw c3RyZWFtIHBhY2tldHMgb25seSkuIElmIHRoZSByZWFzb24gZm9yIA0Ka2VlcGluZyB0aGlzIHRh YmxlIGlzIHRvIHN1cHBvcnQgRE9DU0lTIA0KMS4wIG1vZGVtcyB3b3VsZCBpdCBhbHNvIG1ha2Ug c2Vuc2UgdG8gYWRkIGRvd25zdHJlYW0gcGFja2V0IGNvdW50cyB0byANCnRoaXMgdGFibGUsIHRv bz8gTWFueSBDTVRTJ2VzIGFscmVhZHkgDQpjb3VudCB0aGlzIGluZm9ybWF0aW9uIGFuZCBzdG9y ZSBpdCBpbiBhIHByb3ByaWV0YXJ5IE1JQi4gSXQgd291bGQgYmUgDQpuaWNlIHRvIHN0YW5kYXJk aXplIHRoaXMgYXMgYSByZXF1aXJlbWVudCANCnNvIHRoYXQgTk1TIHN1Y2ggYXMgdXNhZ2UgbW9u aXRvcmluZyBzeXN0ZW1zIGNvdWxkIChhKSBjb3VudCBvbiBpdCANCmV4aXN0aW5nIGFuZCAoYikg ZmluZCBpdCBpbiBhIHN0YW5kYXJkIGxvY2F0aW9uLiANCkNvbnRyaWJ1dG9yIC0gQW5kcmV3IFN1 bmRlbGluIFN0YXJndXMgDQoNCjE2KSBBZGQgNCBvYmplY3RzIHRvIGRvY3NJZkNtdHNDbVN0YXR1 c1RhYmxlIA0KV2hpbGUgd3JpdGluZyBET0NTLUlFVEYtUU9TLU1JQiB2ZXJzaW9uIDksIEkgZmlu ZCBteXNlbGYgc3RpbGwgdGhpbmtpbmcgDQphYm91dCBNaW5uaWUgc3VnZ2VzdGlvbiBvZiBoYXZp bmcgDQpkb2NzSWZDbXRzU2VydmljZUluUGFja2V0cyBhbmQgZG9jc0lmQ210c1NlcnZpY2VJbk9j dGV0cyBjb3VudCBmb3IgDQpET0NTSVMgMS4xIGFuZCAyLjAuIEV2ZW4gdGhvdWdoIHRoZSBRT1Mg DQpNSUIgaGFzIHBhd25lZCBvZmYgdGhpcyBkaXNjdXNzaW9uLCBJIGhhdmUgaGFkIHNvbWUgdGhv dWdodHMgb24gdGhlIA0Kc3ViamVjdC4gDQooMSkgSWYgdGhlc2UgY291bnRlcnMgd2hlcmUgdXNl ZCB0byBjb3VudCB0aGUgRE9DU0lTIDEuMSBhbmQgMi4wLCB0aGFuIA0KdGhpcyB3b3VsZCB0aGUg YmVzdCBwbGFjZSBpbiBhbGwgDQpvZiB0aGUgbWlicyB0byANCiAgICBnZXQgYSBxdWljayBzdW1t YXJ5IG9mIHRoZSB1cHN0cmVhbSBkYXRhIHJlY2VpdmVkIGJ5IGEgcGFydGljdWxhciANCm1vZGVt LCBubyBtYXR0ZXIgdGhlIHZlcnNpb24uIA0KKDIpIEF0IHRoZSBzYW1lIHRpbWUsIFRoZSByZXN0 IG9mIHRoZSBkb2NzSWZDbXRzQ21TZXJ2aWNlVGFibGUgbWlnaHQgbm90IA0KbWFrZSBzZW5zZSBm b3IgRE9DU0lTIDEuMSBvciAyLjAgDQpIb3dldmVyIHRoZSBtb3JlIEkgbG9va2VkIGFyb3VuZCBh dCB0aGUgZGlmZmVyZW50IGNvdW50ZXJzIHRoYXQgZXhpc3RlZCANCmluIGFsbCBvZiBNSUIgcmVx dWlyZWQgYnkgRE9DU0lTLCANCnRoZSBtb3JlIEkga2VwdCBsb29raW5nIGZvciBhbiBvdmVyYWxs IGNvdW50ZXIgb24gdGhlIENNVFMgdG8gY291bnQgZGF0YSANCnBhY2tldCByZWNlaXZlZCBhbmQg dHJhbnNtaXR0ZWQgDQpmb3IgYSBwYXJ0aWN1bGFyIENNLiANCkkgd291bGQgbGlrZSB0byBzdGFy dCBhIGRpc2N1c3Npb24gb24gYWJvdXQgYWRkaW5nIDQgbmV3IG9iamVjdCB0byB0aGUgDQpkb2Nz SWZDbXRzQ21TdGF0dXNUYWJsZTogDQpkb2NzSWZDbXRzQ21TdGF0dXNJblBhY2tldHMgDQpkb2Nz SWZDbXRzQ21TdGF0dXNJbk9jdGV0cyANCmRvY3NJZkNtdHNDbVN0YXR1c091dFBhY2tldHMgDQpk b2NzSWZDbXRzQ21TdGF0dXNPdXRvY3RldHMgDQpXaGlsZSBJIHVuZGVyc3RhbmQgdGhhdCB0aGVz ZSBjb3VudHMgY2FuIGJlIGdhdGhlcmVkIGJ5IHZpYSBudW1lcm91cyANCm9iamVjdHMgb24gYm90 aCB0aGUgQ01UUyBhbmQgQ00gDQphbmQgdGhlbiBqdXN0IGFwcGxpbmcgc2ltcGxlIG1hdGguIEhv d2V2ZXIgSSB3YW50IHRvIHF1ZXJ5IG9ubHkgb25lIA0KYWdlbnQgYW5kIGp1c3QgZ2V0IGEgcXVp Y2sgc3VtbWFyeSANCndpdGhvdXQgaGF2ZSB0byBkZXRlcm1pbmUgd2hpY2ggdmVyc2lvbiBvZiBE T0NTSVMgdGhlIG1vZGVtIGlzLCB3aGljaCANCndpbGwgZGV0ZXJtaW5lIHdoaWNoIG1pYnMgSSBs b29rIGV0Yy4gDQphbmQgb2JqZWN0cyBJIHF1ZXJ5LiANCkZvciBleGFtcGxlIGlmIEkgd2FudCBx dWVyeSBvbmx5IG9uZSBhZ2VudChpLmUuIHRoZSBDTVRTKSBhbmQgZ2V0IHRoZSANCm51bWJlciBv ZiB0cmFuc21pdHRlZCBhbmQgcmVjZWl2ZWQgDQpkYXRhIGZvciBlYWNoIENNLCB0aGVuIA0KICAg ICAgICgxKSBHRVQtTkVYVCB0aGUgZG9jc0lmQ210c0NtU3RhdHVzUmVnTW9kZSB0byBzZWUgd2hh dCB2ZXJzaW9uIG9mIA0KRE9DU0lTIHRoaXMgbW9kZW0gaXMgb3BlcnRpbmcgDQogICAgICAgaWYg J2RvY3NpczEwKDEpJyB0aGVuIA0KICAgICAgICAgICAgICAgICAgICAgKDIpIFdBTEsgdGhlIGVu dGlyZSBkb2NzSWZDbXRzU2VydmljZVRhYmxlIGZvciANCmlmSW5kZXggYW5kIFNJRCB0aGF0IA0K ICAgICAgICAgICAgICAgICAgICAgICBoYXZlIGRvY3NJZkNtdHNTZXJ2aWNlTmV3Q21TdGF0dXNJ bmRleCB0aGF0IA0KbWF0Y2hlcyB0aGUgaW5kZXggZm9yIHN0ZXAgKDEpLiANCiAgICAgIA0KICAg ICAgICAgICAgICAgICAgICAgKDMpIEFkZCB0aGUgYWxsIHRoZSBpbnN0YW5jZXMgb2YgDQpkb2Nz SWZDbXRzU2VydmljZUluUGFja2V0IGZvciB0aGUgDQogICAgICAgICAgICAgICAgICAgICAgIGlm SW5kZXggYW5kIFNJRHMgdGhhdCBtYXRjaCBmcm9tIHN0ZXAoMikgdG8gZ2V0IA0KdGhlIHRvdGFs IFJlY2VpdmVkIHBhY2tldHMgZnJvbSBhIENNLiANCiAgICAgICAgICAgICAgICAgICAgIE5PVEU6 IE5vdCBzdXJlIGl0IGlzIHBvc3NpYmxlIHRvIGdldCBmcm9tIGEgQ01UUyANCmFnZW50IGZyb20g dGhlIFN0YW5kYXJkIE1JQnMgdGhlIG51bWJlciBvZiANCiAgICAgICAgICAgICAgICAgICAgICAg ICBvZiBwYWNrZXRzIHRyYW5zbWl0dGVkIHRvIGEgc2luZ2xlIGRvY3NpcyAxLjAgDQpjYWJsZSBt b2RlbS4gDQogICAgICAgZWxzZSBpZiAnZG9jc2lzMTEoMiknIG9yICdkb2NzaXMyMCgpJyB0aGVu IA0KICAgICAgICAgICAgICAgICAgICAgKDIpIFdBTEsgdGhlIGRvY3NRb3NDbXRzTWFjVG9TcnZG bG93VGFibGUgYWxsIGZvciANCnRoZSBpbnN0YW5jZXMgb2YgdGhhdCBjb250YWluIHRoZSANCiAg ICAgICAgICAgICAgICAgICAgICAgc2FtZSBtYWMgYWRkcmVzcy4gDQogICAgICAgICAgICAgICAg ICAgICAoMykgVGhlbiBHRVQgdGhlIGRvY1Fvc1NlcnZpY2VGbG93UGt0cyB1c2luZyB0aGUgDQpp ZkluZGV4IGFuZCANCiAgICAgICAgICAgICAgICAgICAgICBzZXJ2aWNlIGZsb3cgaWQgZnJvbSBz dGVwKDIpLiBBZGQgdGhpcyB0byB0aGUgDQp0b3RhbCBvZiByZWNlaXZlZCBvciB0cmFuc21pdHRl ZCBmb3IgdGhpcyBDTS4gDQogICAgICAgICAgICAgICAgICAgICAgICAgVG8gZGV0ZXJtaW5lIHRo ZSBkaXJlY3Rpb24gb2YgdGhlIGZsb3cgdXNlIHRoZSANCnNhbWUgaW5kZXggYW5kIHF1ZXJ5IHRo ZSBkb2NzUW9zU2VydmljZUZsb3dEaXJlY3Rpb24uIA0KVGhpcyBzZWVtcyB2ZXJ5IGNvbXBsaWNh dGVkIGZvciBzb21ldGhpbmcgc28gc2ltcGxlLiBUaGlzIGlzIGp1c3QgYSANCnN1Z2dlc3Rpb24g b2Ygc2ltcGxlIHdheSB0aGUgUkYgTUlCIHYyIGNhbiBjb3JyZWN0IHRoZSANCm1pc3Rha2VzIG9m IHRoZSBwYXN0LiANCkNvbnRyaWJ1dG9ycyAtIFdpbGwgTXVyd2luIE1vdG9yb2xhLCBNaW5uaWUg THUgQ2lzY28gDQoNCjE3KSBkb2NzSWZDbXRzQ21TdGF0dXNUaW1pbmdPZmZzZXQgLSByZXR1cm4g dG8gdW5pdHMgb2YgNi4yNS82NC4gQWRkIG5ldyBvYmplY3QgZG9jc0lmQ210c0NtU3RhdHVzSGln aFJlc29sdXRpb25UaW1pbmdPZmZzZXQgdXNpbmcgdW5pdHMgNi4yNS8oMjU2KjY0KQ0KdW5kZXIg ZGlzY3Vzc2lvbi4gDQpDb250cmlidXRvcnMgLSBWaWN0b3IgSG91IEp1bmlwZXIsIFJpY2ggV291 bmR5IElQQ0ROL0NvbWNhc3QsIEtpcmsgDQpGcmllZG1hbiBDb3JyZWxhbnQsIEVkdWFyZG8gQ2Fy ZG9uYSAtIENhYmxlbGFicw0KMTgpIEFkZCBuZXcgb2JqZWN0IGRvY3NJZkNtdHNDbVN0YXR1c1Zh bHVlTGFzdFVwZGF0ZSBhcyBwZXIgZWNuIG9zcy1uLTAzMDY4Lg0KQ29udHJpYnV0b3IgLSBFZHVh cmRvIENhcmRvbmEgLSBDYWJsZWxhYnMNCjE5KSBVcGRhdGUgcmVmZXJlbmNlcyB0byBSRiBhbmQg T1NTIHNwZWMgdmVyc2lvbnMgSTA0LTAzMDczMC4NCjIwKSBVcGRhdGUgc25tcHYzIHJlZmVyZW5j ZXMgdG8gbGF0ZXN0IG1pYiB2ZXJzaW9ucy4NCjIxKSBDbGFyaWZpY2F0aW9uIG9mIHRleHQgaW4g ZG9jc0lmQ210c0NoYW5uZWxVdGlsaXphdGlvbkludGVydmFsDQpDb250cmlidXRvciAtIE1pbm5p ZSBMdSAtIENpc2NvDQoyMikgQWRkaXRpb24gb2Ygb2JqZWN0IHRvIHJlcG9ydCByZWNlaXZlZCBw b3dlciBsZXZlbCBwZXIgY2hhbm5lbCBhdCBDTVRTLg0KQ29udHJpYnV0b3IgLSBEYW4gUmljZSAt IFN0YXJndXMNCg0KDQo= ------_=_NextPart_001_01C3887A.00B59F86-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Oct 2 08:48:23 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 IAA16615 for ; Thu, 2 Oct 2003 08:48:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A52sD-0004rq-07 for ipcdn-archive@odin.ietf.org; Thu, 02 Oct 2003 08:48:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Cm0OG018705 for ipcdn-archive@odin.ietf.org; Thu, 2 Oct 2003 08:48:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A52sC-0004rR-J2; Thu, 02 Oct 2003 08:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A52rK-0004qi-GC for ipcdn@optimus.ietf.org; Thu, 02 Oct 2003 08:47:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16590 for ; Thu, 2 Oct 2003 08:46:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A52rI-0007nh-00 for ipcdn@ietf.org; Thu, 02 Oct 2003 08:47:04 -0400 Received: from coral.tci.com ([198.178.8.81] helo=snowmass.tci.com) by ietf-mx with esmtp (Exim 4.12) id 1A52rH-0007mb-00 for ipcdn@ietf.org; Thu, 02 Oct 2003 08:47:04 -0400 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 h92CkRVb026995; Thu, 2 Oct 2003 06:46:27 -0600 (MDT) Received: by entexchimc02.broadband.att.com with Internet Mail Service (5.5.2656.59) id ; Thu, 2 Oct 2003 06:46:26 -0600 Message-ID: <6732623D2548D61193C90002A5C88DCC0B651EF8@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "Ipcdn (E-mail)" Cc: "'Jean-Francois Mule'" , Eduardo Cardona , Bert Wijnen , "Raftus, David" , "Woundy, Richard" Date: Thu, 2 Oct 2003 06:46:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C388E3.2ED64E3A" Subject: [ipcdn] RE: Status of IPCDN RF MIBv2 and 3 open issues 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_01C388E3.2ED64E3A Content-Type: text/plain; charset="iso-8859-1" Folks, Jean-Francois and I completely agree on this list below. Allow me to make a small clarification. When we say: # Recommendation is that this issue will not be addressed in any # future revision of RF MIB v2. This does *not* mean that we will never discuss the issue in IPCDN. For example, the technology proponents can write a separate internet-draft that extends the RF MIB (or creates a new separate MIB) with the proposed functionality. This allows us to publish the RF MIB v2 in the short-term, but resolve these "nice to have" issues (e.g. new MIB objects) in the long-term. Keep in mind that IPCDN has real scheduled milestones now: http://www.ietf.org/html.charters/ipcdn-charter.html . -- Rich -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] Sent: Wednesday, October 01, 2003 8:11 PM To: Ipcdn (E-mail) Cc: Eduardo Cardona; Jean-Francois Mule; Woundy, Richard; Bert Wijnen; Raftus, David Subject: Status of IPCDN RF MIBv2 and 3 open issues This note provides a status on the DOCSIS 2.0 RF MIB (aka rfmibv2). In summary, 3 issues are still OPEN and the wg chairs would like to have working group consensus by Friday October 10 on issues: #13, #14, #16. Eduardo Cardona of CableLabs has kindly accepted to help resolve those and will be posting some text soon. Please read this carefully and raise any concerns or objections to the wg chairs on this action plan by Friday Oct 10. -- Rich Woundy and Jean-Francois Mule', ipcdn co-chairs. --- Status of RF MIBv2 Internet-Draft Name: DOCSIS 2.0 RF MIB draft-ietf-ipcdn-docs-rfmibv2-06.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-06.txt soon to be draft-ietf-ipcdn-docs-rfmibv2-07.txt 1) Follow-up on the IETF posting of rfmibv2-07 The editor, David Raftus sent draft-07 to the internet-draft on 9/9. The revision has not shown up yet. This is probably due to the fact that a zip file was attached instead of the plain text file. Action Item (AI): wg chair to follow up on posting. 2) Categorization of the remaining open issues David Raftus sent a list of open issues to the ipcdn list on 9/12/03, see attached file rfdraftv7_issues_Sept12_2003.txt The remaining open issues not addressed in draft-07 split into 2 categories: - a) issue is not required to be addressed ("nice to have") This category includes some of the improvements that were not in the original scope of rfmibv2. A lot of improvements has been done and it is time to freeze rfmibv2. - b) issue that should be addressed in draft v8 ("must fix") This category includes some issues that need to be addressed. 5 open issues are in this category. => Please raise any objection on the ipcdn list by COB Friday 9/10/03 if you believe this is not reflecting the correct status of the draft or if you believe more open issues must be fixed. 3) Open issues: The numbering is based on David Raftus status file sent on 9/12/2003 on the ipcdn list and attached to this posting. + Issue #7: Status: Closed (will be in draft08) (7) docsIfUpChannelPreEqEnable - add DEFVAL clause. Contributor - John Gillis ADC David indicated that a defval is not required ("DEFVAL not appropriate here, also too many other items in same table do not have DEFVAL"). # category: "must fix" # Eduardo recommends to add a default value of false for this object. # Action Item: add DEFVAL false in draft 08 + Issue #13 Status: Open (13) Adjust compliance statements for objects designated optional. Add separate augmentation table for optional objects in docsIfCmtsUpChannelCounterTable. Contributors - Will Murwin Motorola, Rich Woundy IPCDN/Comcast, Mike StJohns Mindspring, Eduardo Cardona Cablelabs # category: "must fix" # Action Item: Eduardo to summarize the discussion & a recommendation # for the augmentation. Consensus must be reached by 10/10 or else WG # chair will make a decision. + Issue #14 Status: Open (14) Add section explaining counter interaction between Docsis 1.0/1.1/2.0. David indicated that this could be done in OSS spec but since rfmib v2 obsoletes an exising IETF MIB, the wg chairs recommendation is to include a section in the new MIB. # category: "must fix" # Action Item: Eduardo to propose some text. + Issue #15 Status: Closed, pending ipcdn review (15) Change docsIfCmtsServiceTable to count packets for both upstream and downstream flows. David Raftus commented: "Will not do - inappropriate - table indexed by SID, SIDs are not defined for downstream flows". WG chairs agree with David Raftus. # category: "nice to have", For further study. # Action item: none, issue is closed. + Issue #16 Status: Open (16) Add 4 objects to docsIfCmtsCmStatusTable See David Raftus' status on this open issue and associated emails. # category: "nice to have" # Action item: Eduardo to close on this issue on the ipcdn mailing # list. If no consensus can be reached by Oct 10, wg chair will make a # decision to leave it out of rf mib v2. + Issue #20 Status: Closed (will be in draft08) (20) Update snmpv3 references to latest mib versions # category: "must fix" # Action item: edit draft 08 and include proper refs in the document + Issue #22 Status: Closed (pending ipcdn review) (22) Addition of object to report received power level per channel at CMTS # category: "nice to have" -> out of scope # Recommendation is that this issue will not be addressed in any # future revision of RF MIB v2. # Action item: none, issue is closed. ------_=_NextPart_001_01C388E3.2ED64E3A Content-Type: text/html; charset="iso-8859-1" Status of IPCDN RF MIBv2 and 3 open issues
Folks,
 
Jean-Francois and I completely agree on this list below.
 
Allow me to make a small clarification. When we say:
 
# Recommendation is that this issue will not be addressed in any
# future revision of RF MIB v2.
 
This does *not* mean that we will never discuss the issue in IPCDN. For example, the technology proponents can write a separate internet-draft that extends the RF MIB (or creates a new separate MIB) with the proposed functionality. This allows us to publish the RF MIB v2 in the short-term, but resolve these "nice to have" issues (e.g. new MIB objects) in the long-term.
 
Keep in mind that IPCDN has real scheduled milestones now: http://www.ietf.org/html.charters/ipcdn-charter.html.
 
-- Rich
-----Original Message-----
From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]
Sent: Wednesday, October 01, 2003 8:11 PM
To: Ipcdn (E-mail)
Cc: Eduardo Cardona; Jean-Francois Mule; Woundy, Richard; Bert Wijnen; Raftus, David
Subject: Status of IPCDN RF MIBv2 and 3 open issues

This note provides a status on the DOCSIS 2.0 RF MIB (aka rfmibv2).

In summary, 3 issues are still OPEN and the wg chairs would like to
have working group consensus by Friday October 10 on issues: #13, #14,
 #16. Eduardo Cardona of CableLabs has kindly accepted to help resolve
those and will be posting some text soon.

Please read this carefully and raise any concerns or objections to the
wg chairs on this action plan by Friday Oct 10.

 -- Rich Woundy and Jean-Francois Mule', ipcdn co-chairs.

--- Status of RF MIBv2
Internet-Draft Name: DOCSIS 2.0 RF MIB
                     draft-ietf-ipcdn-docs-rfmibv2-06.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-06.txt
soon to be
draft-ietf-ipcdn-docs-rfmibv2-07.txt


1) Follow-up on the IETF posting of rfmibv2-07
   The editor, David Raftus sent draft-07 to the internet-draft on
   9/9. The revision has not shown up yet. This is probably due to the
   fact that a zip file was attached instead of the plain text file.
   Action Item (AI): wg chair to follow up on posting.


2) Categorization of the remaining open issues
David Raftus sent a list of open issues to the ipcdn list on 9/12/03,
see attached file rfdraftv7_issues_Sept12_2003.txt
The remaining open issues not addressed in draft-07 split into 2
categories:
- a) issue is not required to be addressed ("nice to have")
  This category includes some of the improvements that were not in the
  original scope of rfmibv2. A lot of improvements has been done and
  it is time to freeze rfmibv2.
- b) issue that should be addressed in draft v8 ("must fix")
  This category includes some issues that need to be addressed.
  5 open issues are in this category.
=> Please raise any objection on the ipcdn list by COB Friday 9/10/03
if you believe this is not reflecting the correct status of the draft
or if you believe more open issues must be fixed.


3) Open issues:
The numbering is based on David Raftus status file sent on 9/12/2003
on the ipcdn list and attached to this posting.

+ Issue #7:
Status: Closed (will be in draft08)
(7) docsIfUpChannelPreEqEnable - add DEFVAL clause.
    Contributor - John Gillis ADC
David indicated that a defval is not required ("DEFVAL not appropriate
here, also too many other items in same table do not have DEFVAL").
# category: "must fix"
# Eduardo recommends to add a default value of false for this object.
# Action Item: add DEFVAL false in draft 08

+ Issue #13
Status: Open
(13) Adjust compliance statements for objects designated optional. Add
     separate augmentation table for optional objects in
     docsIfCmtsUpChannelCounterTable.
     Contributors - Will Murwin Motorola, Rich Woundy IPCDN/Comcast,
     Mike StJohns Mindspring, Eduardo Cardona Cablelabs
# category: "must fix"
# Action Item: Eduardo to summarize the discussion & a recommendation
# for the augmentation. Consensus must be reached by 10/10 or else WG
# chair will make a decision.

+ Issue #14
Status: Open
(14) Add section explaining counter interaction between
     Docsis 1.0/1.1/2.0.
David indicated that this could be done in OSS spec but since rfmib v2
obsoletes an exising IETF MIB, the wg chairs recommendation is to
include a section in the new MIB.
# category: "must fix"
# Action Item: Eduardo to propose some text.

+ Issue #15
Status: Closed, pending ipcdn review
(15) Change docsIfCmtsServiceTable to count packets for both upstream
     and downstream flows.
David Raftus commented: "Will not do - inappropriate - table indexed
by SID, SIDs are not defined for downstream flows".
WG chairs agree with David Raftus.
# category: "nice to have", For further study.
# Action item: none, issue is closed.

+ Issue #16
Status: Open
(16) Add 4 objects to docsIfCmtsCmStatusTable
See David Raftus' status on this open issue and associated emails.
# category: "nice to have"
# Action item: Eduardo to close on this issue on the ipcdn mailing
# list. If no consensus can be reached by Oct 10, wg chair will make a
# decision to leave it out of rf mib v2.

+ Issue #20
Status: Closed (will be in draft08)
(20) Update snmpv3 references to latest mib versions
# category: "must fix"
# Action item: edit draft 08 and include proper refs in the document

+ Issue #22
Status: Closed (pending ipcdn review)
(22) Addition of object to report received power level per channel at CMTS
# category: "nice to have" -> out of scope
# Recommendation is that this issue will not be addressed in any
# future revision of RF MIB v2.
# Action item: none, issue is closed.

------_=_NextPart_001_01C388E3.2ED64E3A-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Oct 2 11:07:23 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 LAA24367 for ; Thu, 2 Oct 2003 11:07:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A552l-0004s3-98 for ipcdn-archive@odin.ietf.org; Thu, 02 Oct 2003 11:07:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92F73gF018711 for ipcdn-archive@odin.ietf.org; Thu, 2 Oct 2003 11:07:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A552j-0004qx-BK; Thu, 02 Oct 2003 11:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A552G-0004qM-La for ipcdn@optimus.ietf.org; Thu, 02 Oct 2003 11:06:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24331 for ; Thu, 2 Oct 2003 11:06:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A552D-0001ij-00 for ipcdn@ietf.org; Thu, 02 Oct 2003 11:06:29 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A552C-0001iZ-00 for ipcdn@ietf.org; Thu, 02 Oct 2003 11:06:28 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h92F5s10011644; Thu, 2 Oct 2003 09:05:54 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C388F6.AD0F1848" Date: Thu, 2 Oct 2003 09:05:54 -0600 Message-ID: Thread-Topic: Status of IPCDN RF MIBv2 and 3 open issues Thread-Index: AcOI40h4d7FBm9SmRV+NIrQ7Xw66pgAEuXGQ From: "Eduardo Cardona" To: "Woundy, Richard" , "Ipcdn (E-mail)" Cc: "Jean-Francois Mule" , "Bert Wijnen" , "Raftus, David" X-Approved: ondar Subject: [ipcdn] RE: Status of IPCDN RF MIBv2 and 3 open issues 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_01C388F6.AD0F1848 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rich, you are correct, It is certainly an inaccurate final wording if the recommendation note. =20 Jean-Francois and I discussed yesterday that RFC updates could be possible in the future, specially requirements that may come out from new projects inside CableLabs affecting any MIB.=20 =20 Depending of the scope ( in particular the note address item#22 ) new OIDs may be assigned to a new OBJECT GROUP in a further RFC update. =20 We might get later off-line guidelines from the IETF OPS group of where updates (aka mib extensions) are desirable rather than a new MIB draft status. =20 We will revise the statement for note #22 for October 10 final report. =20 Eduardo -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]=20 Sent: Thursday, October 02, 2003 6:46 AM To: Ipcdn (E-mail) Cc: Jean-Francois Mule; Eduardo Cardona; Bert Wijnen; Raftus, David; Woundy, Richard Subject: RE: Status of IPCDN RF MIBv2 and 3 open issues =09 =09 Folks, =20 Jean-Francois and I completely agree on this list below. =20 Allow me to make a small clarification. When we say: =20 # Recommendation is that this issue will not be addressed in any # future revision of RF MIB v2. =20 This does *not* mean that we will never discuss the issue in IPCDN. For example, the technology proponents can write a separate internet-draft that extends the RF MIB (or creates a new separate MIB) with the proposed functionality. This allows us to publish the RF MIB v2 in the short-term, but resolve these "nice to have" issues (e.g. new MIB objects) in the long-term. =20 Keep in mind that IPCDN has real scheduled milestones now: http://www.ietf.org/html.charters/ipcdn-charter.html. =20 -- Rich -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] Sent: Wednesday, October 01, 2003 8:11 PM To: Ipcdn (E-mail) Cc: Eduardo Cardona; Jean-Francois Mule; Woundy, Richard; Bert Wijnen; Raftus, David Subject: Status of IPCDN RF MIBv2 and 3 open issues =09 =09 This note provides a status on the DOCSIS 2.0 RF MIB (aka rfmibv2). =09 In summary, 3 issues are still OPEN and the wg chairs would like to have working group consensus by Friday October 10 on issues: #13, #14, #16. Eduardo Cardona of CableLabs has kindly accepted to help resolve=20 those and will be posting some text soon. =09 Please read this carefully and raise any concerns or objections to the wg chairs on this action plan by Friday Oct 10. =09 -- Rich Woundy and Jean-Francois Mule', ipcdn co-chairs. =09 --- Status of RF MIBv2 Internet-Draft Name: DOCSIS 2.0 RF MIB =09 draft-ietf-ipcdn-docs-rfmibv2-06.txt =09 ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-06.txt =20 soon to be draft-ietf-ipcdn-docs-rfmibv2-07.txt =09 =09 1) Follow-up on the IETF posting of rfmibv2-07 The editor, David Raftus sent draft-07 to the internet-draft on 9/9. The revision has not shown up yet. This is probably due to the fact that a zip file was attached instead of the plain text file. Action Item (AI): wg chair to follow up on posting. =09 =09 2) Categorization of the remaining open issues David Raftus sent a list of open issues to the ipcdn list on 9/12/03, see attached file rfdraftv7_issues_Sept12_2003.txt The remaining open issues not addressed in draft-07 split into 2 categories: - a) issue is not required to be addressed ("nice to have") This category includes some of the improvements that were not in the original scope of rfmibv2. A lot of improvements has been done and it is time to freeze rfmibv2. - b) issue that should be addressed in draft v8 ("must fix") This category includes some issues that need to be addressed. 5 open issues are in this category. =3D> Please raise any objection on the ipcdn list by COB Friday 9/10/03 if you believe this is not reflecting the correct status of the draft or if you believe more open issues must be fixed. =09 =09 3) Open issues: The numbering is based on David Raftus status file sent on 9/12/2003 on the ipcdn list and attached to this posting. =09 + Issue #7: Status: Closed (will be in draft08) (7) docsIfUpChannelPreEqEnable - add DEFVAL clause. Contributor - John Gillis ADC David indicated that a defval is not required ("DEFVAL not appropriate here, also too many other items in same table do not have DEFVAL"). # category: "must fix" # Eduardo recommends to add a default value of false for this object. # Action Item: add DEFVAL false in draft 08 =09 + Issue #13 Status: Open (13) Adjust compliance statements for objects designated optional. Add separate augmentation table for optional objects in docsIfCmtsUpChannelCounterTable. Contributors - Will Murwin Motorola, Rich Woundy IPCDN/Comcast, Mike StJohns Mindspring, Eduardo Cardona Cablelabs # category: "must fix" # Action Item: Eduardo to summarize the discussion & a recommendation # for the augmentation. Consensus must be reached by 10/10 or else WG # chair will make a decision. =09 + Issue #14 Status: Open (14) Add section explaining counter interaction between Docsis 1.0/1.1/2.0. David indicated that this could be done in OSS spec but since rfmib v2 obsoletes an exising IETF MIB, the wg chairs recommendation is to include a section in the new MIB. # category: "must fix" # Action Item: Eduardo to propose some text. =09 + Issue #15 Status: Closed, pending ipcdn review (15) Change docsIfCmtsServiceTable to count packets for both upstream and downstream flows. David Raftus commented: "Will not do - inappropriate - table indexed by SID, SIDs are not defined for downstream flows". WG chairs agree with David Raftus. # category: "nice to have", For further study. # Action item: none, issue is closed. =09 + Issue #16 Status: Open (16) Add 4 objects to docsIfCmtsCmStatusTable See David Raftus' status on this open issue and associated emails. # category: "nice to have" # Action item: Eduardo to close on this issue on the ipcdn mailing # list. If no consensus can be reached by Oct 10, wg chair will make a # decision to leave it out of rf mib v2. =09 + Issue #20 Status: Closed (will be in draft08) (20) Update snmpv3 references to latest mib versions # category: "must fix" # Action item: edit draft 08 and include proper refs in the document =09 + Issue #22 Status: Closed (pending ipcdn review) (22) Addition of object to report received power level per channel at CMTS # category: "nice to have" -> out of scope # Recommendation is that this issue will not be addressed in any # future revision of RF MIB v2. # Action item: none, issue is closed.=20 ------_=_NextPart_001_01C388F6.AD0F1848 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Rich,=20 you are correct, It is = certainly an=20 inaccurate final wording if the=20 recommendation note.
 
Jean-Francois and I discussed yesterday that RFC = updates could be=20 possible in the future, specially requirements that may come out from = new=20 projects inside CableLabs affecting any MIB.
 
Depending of the scope ( in particular the = note address item#22=20 ) new OIDs may be assigned to a new OBJECT GROUP  in a further=20 RFC update.
 
We=20 might get later off-line guidelines from the IETF OPS=20 group of where updates (aka mib=20 extensions) are desirable rather than a new MIB draft=20 status.
 
We=20 will revise the statement for note #22 for October 10 final=20 report.
 
Eduardo
-----Original Message-----
From: = Woundy, Richard=20 [mailto:Richard_Woundy@cable.comcast.com]
Sent: Thursday, = October=20 02, 2003 6:46 AM
To: Ipcdn (E-mail)
Cc: = Jean-Francois=20 Mule; Eduardo Cardona; Bert Wijnen; Raftus, David; Woundy,=20 Richard
Subject: RE: Status of IPCDN RF MIBv2 and 3 open=20 issues

Folks,
 
Jean-Francois and I completely agree on = this list=20 below.
 
Allow me to make a small clarification.=20 When we say:
 
# Recommendation is that this issue will not be = addressed=20 in any
# future revision of RF MIB=20 v2.
 
This=20 does *not* mean that we will never discuss the issue in IPCDN. For = example,=20 the technology proponents can write a separate internet-draft that = extends the=20 RF MIB (or creates a new separate MIB) with the proposed = functionality. This=20 allows us to publish the RF MIB v2 in the short-term, but resolve = these "nice=20 to have" issues (e.g. new MIB objects) in the = long-term.
 
Keep=20 in mind that IPCDN has real scheduled milestones now: http://www.= ietf.org/html.charters/ipcdn-charter.html.
 
--=20 Rich
-----Original Message-----
From: Jean-Francois = Mule=20 [mailto:jf.mule@cablelabs.com]
Sent: Wednesday, October = 01, 2003=20 8:11 PM
To: Ipcdn (E-mail)
Cc: Eduardo Cardona;=20 Jean-Francois Mule; Woundy, Richard; Bert Wijnen; Raftus,=20 David
Subject: Status of IPCDN RF MIBv2 and 3 open=20 issues

This note = provides a=20 status on the DOCSIS 2.0 RF MIB (aka rfmibv2).

In summary, 3 = issues=20 are still OPEN and the wg chairs would like to
have working group = consensus by Friday October 10 on issues: #13,=20 #14,
 #16. = Eduardo Cardona of=20 CableLabs has kindly accepted to help resolve =
those and will be = posting some=20 text soon.

Please = read this=20 carefully and raise any concerns or objections to the
wg=20 chairs on this action = plan by Friday=20 Oct 10.

 -- = Rich Woundy=20 and Jean-Francois Mule', ipcdn = co-chairs.

--- Status of RF=20 MIBv2
Internet-Draft Name:=20 DOCSIS 2.0 RF=20 = MIB
           =          =20 draft-ietf-ipcdn-docs-rfmibv2-06.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2= -06.txt
soon to=20 = be
draft-ietf-ipcdn-docs-rfmibv2-07.txt


1) Follow-up on the = IETF posting of=20 rfmibv2-07
   The=20 editor, David Raftus sent draft-07 to the internet-draft = on
  =20 9/9. The revision has not shown up yet. This is probably due to=20 the
   fact that a zip file was attached instead of the = plain=20 text file.
   Action Item (AI): wg chair to follow up = on=20 posting.


2) Categorization of the remaining open = issues
David Raftus sent a list of open = issues to the=20 ipcdn list on 9/12/03,
see attached file=20 rfdraftv7_issues_Sept12_2003.txt
The remaining open issues not = addressed=20 in draft-07 split into 2
categories:
- a) issue is not required to be addressed = ("nice to=20 have")
  This = category=20 includes some of the improvements that were not in the
  = original=20 scope of rfmibv2. A lot of improvements has been done and
  = it is=20 time to freeze rfmibv2.
- b) issue that should be addressed in draft v8 ("must=20 fix")
  This = category=20 includes some issues that need to be addressed.
  5 open = issues are=20 in this category.
=3D> Please raise any objection on the ipcdn = list by=20 COB Friday 9/10/03
if you believe this is not reflecting the = correct=20 status of the draft
or if you believe more open issues must be=20 fixed.


3)=20 Open issues:
The = numbering is=20 based on David Raftus status file sent on 9/12/2003
on the ipcdn = list and=20 attached to this posting.

+ Issue #7:
Status: Closed (will be in draft08)
(7) = docsIfUpChannelPreEqEnable=20 - add DEFVAL clause.
    Contributor - John Gillis = ADC
David indicated that a defval is not required ("DEFVAL not=20 appropriate
here, also too many other items in same table do not = have=20 DEFVAL").
#=20 category: "must fix"
# Eduardo recommends to add a default value of false for = this=20 object.
# Action=20 Item: add DEFVAL false in draft 08

+ Issue #13
Status: Open
(13) Adjust compliance statements for = objects=20 designated optional. Add
     separate = augmentation=20 table for optional objects in
    =20 docsIfCmtsUpChannelCounterTable.
     = Contributors -=20 Will Murwin Motorola, Rich Woundy = IPCDN/Comcast,
    =20 Mike StJohns Mindspring, Eduardo Cardona Cablelabs
# category: "must=20 fix"
# = Action Item:=20 Eduardo to summarize the discussion & a = recommendation
# for the = augmentation. Consensus=20 must be reached by 10/10 or else WG
# chair will make a = decision.

+ Issue = #14
Status: Open
(14) Add section = explaining=20 counter interaction between
     Docsis=20 1.0/1.1/2.0.
David indicated that this could be done in OSS spec = but=20 since rfmib v2
obsoletes an exising IETF MIB, the wg chairs=20 recommendation is to
include a section in the new = MIB.
# category: "must=20 fix"
# = Action Item:=20 Eduardo to propose some text.

+ Issue #15
Status: Closed, pending ipcdn review
(15) Change=20 docsIfCmtsServiceTable to count packets for both=20 upstream
     and downstream flows.
David = Raftus=20 commented: "Will not do - inappropriate - table indexed
by SID, = SIDs are=20 not defined for downstream flows".
WG chairs agree with David=20 Raftus.
# category:=20 "nice to have", For further study.
# Action item: none, issue is=20 closed.

+ Issue=20 #16
Status: = Open
(16) Add 4=20 objects to docsIfCmtsCmStatusTable
See David Raftus' status on = this open=20 issue and associated emails.
# category: "nice to have"
# Action item: Eduardo = to close on=20 this issue on the ipcdn mailing
# list. If no consensus can be reached by = Oct 10, wg=20 chair will make a
#=20 decision to leave it out of rf mib v2.

+ Issue = #20
Status: Closed (will be in = draft08)
(20) Update=20 snmpv3 references to latest mib versions
# category: "must fix"
# Action item: edit = draft 08 and=20 include proper refs in the document

+ Issue #22
Status: Closed (pending ipcdn review)
(22) Addition of = object to=20 report received power level per channel at CMTS
# category: "nice to = have" -> out=20 of scope
#=20 Recommendation is that this issue will not be addressed in=20 any
# = future=20 revision of RF MIB v2.
# Action item: none, issue is closed.=20

=00 ------_=_NextPart_001_01C388F6.AD0F1848-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Oct 3 07:31:27 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 HAA01436 for ; Fri, 3 Oct 2003 07:31:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5O9I-0000lB-Jm for ipcdn-archive@odin.ietf.org; Fri, 03 Oct 2003 07:31:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93BV4GD002917 for ipcdn-archive@odin.ietf.org; Fri, 3 Oct 2003 07:31:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5O9H-0000kT-61; Fri, 03 Oct 2003 07:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5O8Y-0000eb-V0 for ipcdn@optimus.ietf.org; Fri, 03 Oct 2003 07:30:18 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01312; Fri, 3 Oct 2003 07:30:10 -0400 (EDT) Message-Id: <200310031130.HAA01312@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 03 Oct 2003 07:30:10 -0400 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-docs-rfmibv2-07.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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces Author(s) : D. Raftus Filename : draft-ietf-ipcdn-docs-rfmibv2-07.txt Pages : 124 Date : 2003-10-2 This memo is a draft revision of the standards track RFC-2670. Please see 'Section 9 Changes from RFC2670' for a description of modifications. This document or its successor will obsolete RFC-2670 when accepted. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS compliant Radio Frequency (RF) interfaces. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-07.txt 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. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-docs-rfmibv2-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-2141255.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-docs-rfmibv2-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-2141255.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Oct 3 11:02:21 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 LAA11179 for ; Fri, 3 Oct 2003 11:02:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5RRR-0001ai-9K for ipcdn-archive@odin.ietf.org; Fri, 03 Oct 2003 11:02:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93F21sY006092 for ipcdn-archive@odin.ietf.org; Fri, 3 Oct 2003 11:02:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5RRQ-0001a2-Iu; Fri, 03 Oct 2003 11:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5RQj-0001ZM-Mi for ipcdn@optimus.ietf.org; Fri, 03 Oct 2003 11:01:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11156 for ; Fri, 3 Oct 2003 11:01:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5RQh-0001sL-00 for ipcdn@ietf.org; Fri, 03 Oct 2003 11:01:15 -0400 Received: from coral.tci.com ([198.178.8.81] helo=snowmass.tci.com) by ietf-mx with esmtp (Exim 4.12) id 1A5RQg-0001s2-00 for ipcdn@ietf.org; Fri, 03 Oct 2003 11:01:14 -0400 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 h93F0dVb017539 for ; Fri, 3 Oct 2003 09:00:43 -0600 (MDT) Received: by entexchimc02.broadband.att.com with Internet Mail Service (5.5.2656.59) id ; Fri, 3 Oct 2003 09:00:38 -0600 Message-ID: <6732623D2548D61193C90002A5C88DCC0B651F1E@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "IPCDN WG (E-mail)" Date: Fri, 3 Oct 2003 08:59:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] Anyone working on version -00 internet-drafts? 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: , If anyone plans to submit an ipcdn -00 draft before the next draft deadline, please notify Jean-Francois or myself very soon... -- Rich -----Original Message----- From: Internet-Drafts Administrator [mailto:internet-drafts@ietf.org] Sent: Friday, October 03, 2003 7:30 AM Subject: To the attention of all WG Chairs In order to process the many version 00 I-Ds that are received before an IETF meeting in a timely manner, we ask that you send a LIST OF THE NAMES of the drafts you expect to have submitted and have approved for publication as WG documents to internet-drafts@ietf.org no later than five (5) business days prior to the cutoff date for the meeting. Please include the word "Permission" in the Subject field. This procedure will expedite the posting of version 00 I-Ds, allowing more time for review by the public. Thank you you for your cooperation in this matter. The IETF Secretariat FYI: All significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_58.html _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Oct 3 16:33:22 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 QAA25988 for ; Fri, 3 Oct 2003 16:33:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wbk-0002EY-Vk for ipcdn-archive@odin.ietf.org; Fri, 03 Oct 2003 16:33:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93KX0i3008580 for ipcdn-archive@odin.ietf.org; Fri, 3 Oct 2003 16:33:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wbk-0002EA-Gb; Fri, 03 Oct 2003 16:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Waq-0002Cg-46 for ipcdn@optimus.ietf.org; Fri, 03 Oct 2003 16:32:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25802; Fri, 3 Oct 2003 16:31:54 -0400 (EDT) Message-Id: <200310032031.QAA25802@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 03 Oct 2003 16:31:54 -0400 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-signaling-02.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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Network Control Signaling (NCS) Signaling MIB for PacketCable/IPCablecom MTAs Author(s) : G. Beacham, S. Kumar, S. Channabasappa Filename : draft-ietf-ipcdn-pktc-signaling-02.txt Pages : 58 Date : 2003-10-3 This memo defines the Signaling Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it provides a common data and format representation for PacketCable/IPCablecom compliant Multimedia Terminal Adapter devices. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2 [5][6][7]. The set of objects are consistent with the SNMP framework and existing SNMP standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-02.txt 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. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-pktc-signaling-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-pktc-signaling-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-3164310.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-pktc-signaling-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-pktc-signaling-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-3164310.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Oct 3 16:34:23 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 QAA26159 for ; Fri, 3 Oct 2003 16:34:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wcj-0002Ht-OG for ipcdn-archive@odin.ietf.org; Fri, 03 Oct 2003 16:34:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93KY1M5008769 for ipcdn-archive@odin.ietf.org; Fri, 3 Oct 2003 16:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wcj-0002HK-3r; Fri, 03 Oct 2003 16:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WcG-0002GV-L6 for ipcdn@optimus.ietf.org; Fri, 03 Oct 2003 16:33:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25983; Fri, 3 Oct 2003 16:33:21 -0400 (EDT) Message-Id: <200310032033.QAA25983@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 03 Oct 2003 16:33:21 -0400 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-docs-rfmibv2-07.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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces Author(s) : D. Raftus Filename : draft-ietf-ipcdn-docs-rfmibv2-07.txt Pages : 124 Date : 2003-10-3 This memo is a draft revision of the standards track RFC-2670. Please see 'Section 9 Changes from RFC2670' for a description of modifications. This document or its successor will obsolete RFC-2670 when accepted. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS compliant Radio Frequency (RF) interfaces. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-07.txt 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. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-docs-rfmibv2-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-3164329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-docs-rfmibv2-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-3164329.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Oct 6 11:00:28 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 LAA05093 for ; Mon, 6 Oct 2003 11:00:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6WqG-0001ao-A2 for ipcdn-archive@odin.ietf.org; Mon, 06 Oct 2003 11:00:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96F07xS006101 for ipcdn-archive@odin.ietf.org; Mon, 6 Oct 2003 11:00:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Wq9-0001aB-8X; Mon, 06 Oct 2003 11:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Wpe-0001ZS-87 for ipcdn@optimus.ietf.org; Mon, 06 Oct 2003 10:59:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05043; Mon, 6 Oct 2003 10:59:18 -0400 (EDT) Message-Id: <200310061459.KAA05043@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 06 Oct 2003 10:59:18 -0400 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-02.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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable and IPCablecom compliant devices Author(s) : E. Nechamkin, J. Mule Filename : draft-ietf-ipcdn-pktc-mtamib-02.txt Pages : 47 Date : 2003-10-6 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of PacketCable and IPCablecom compliant Multimedia Terminal Adapter devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-02.txt 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. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-pktc-mtamib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-pktc-mtamib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-6105810.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-pktc-mtamib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-pktc-mtamib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-6105810.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Oct 6 12:09:23 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 MAA09097 for ; Mon, 6 Oct 2003 12:09:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Xuw-0005UY-HH for ipcdn-archive@odin.ietf.org; Mon, 06 Oct 2003 12:09:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96G92QJ021101 for ipcdn-archive@odin.ietf.org; Mon, 6 Oct 2003 12:09:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Xuv-0005Tw-Bc; Mon, 06 Oct 2003 12:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Xty-0005SO-On for ipcdn@optimus.ietf.org; Mon, 06 Oct 2003 12:08:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09041 for ; Mon, 6 Oct 2003 12:07:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6Xtx-0007l6-00 for ipcdn@ietf.org; Mon, 06 Oct 2003 12:08:01 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A6Xtw-0007kB-00 for ipcdn@ietf.org; Mon, 06 Oct 2003 12:08:00 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h96G7P10005000; Mon, 6 Oct 2003 10:07:26 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C38C23.EECD9F11" Date: Mon, 6 Oct 2003 10:07:25 -0600 Message-ID: X-MS-Has-Attach: yes Thread-Topic: Issue#16 IPCDN RF MIBv2 Thread-Index: AcNgJaYn06TBEeT1TRC5N0Q/BVl7hgT3JTZQBRgJoxAABa9pIADpuJMQ From: "Eduardo Cardona" To: "Jean-Francois Mule" , "Ipcdn (E-mail)" , "Richard Woundy" , "DOCSIS OSS Majordomo List" , "DOCSIS 2.0 Majordomo List" Cc: "Bert Wijnen" X-Approved: ondar Subject: [ipcdn] Issue#16 IPCDN RF MIBv2 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_01C38C23.EECD9F11 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 Attached is a summary of the issue #16 discussions being held in the past months. The added counter objects to docsIfCmtsCmStatusTable =20 Please review mainly items which are the ones that need resolution=20 2. Applicability: Advantages and disadvantages 1. Proposal We need to come up to know if "Nice to have" goes and MUST be consensus in the final wording. Let me know if I capture most of the considerations in Item 2, or if I miss interpreted some participants appreciations. Would like to have OSS RFI reflector comments in possible open issues at the spec level. (1.0 CMs in QOS mibs) During the day I will post documents for the other issues=20 I will try to open =20 Thanks Eduardo ------_=_NextPart_001_01C38C23.EECD9F11 Content-Type: application/x-zip-compressed; name="issue#16.zip" Content-Description: issue#16.zip Content-Disposition: attachment; filename="issue#16.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIALVNRi8edBY7HzkAAAAoAQAMAAAAaXNzdWUjMTYuZG9j7FxNbGRXVq6EaKRIU0NA kMWIxVUFFFspl7udTgeMwsguV/fUTPunXeVOBrHg1Xu3yq/96r3q91Nl92gQC8QGCMMWsQAkJBYI gcSKzQgxyha27CASK1hELFlM851z7n0/9eOyO5FIBE9yP7+q+3P+z3fOfe5//qef+dc/+9tv/ltt 7vq12k/VfvLi9drXSp+9ip8/tA9v1Gp/hNsr+PnJixcv6KM/wM/H+Hnx/9dX5vrPv/iH2qF6/bVa 7bOf/VGuWVz45JOLWu0btcHTwdNPP/j0g9rC9fprb9Yaf1Wr/faH8vPJaHFM+Xrx4qfX/m6vgP/9 +JVafi//vur+c6UVPn1V7p+9vfr+C7h/faNW+53S+GcPa7X/xlp/siHPN7n/Ne7f2azV7uH+W5uy 7mcPxGP+64GMu8n9F3G/6NZqChN/77u12m/i+U3Q8/O1xcvy/cebS76sLdJpx9k7rUvXN+/IfV6e dp697PM7mPdmad78ndZ/82uL68w/f2b4tpedf9vL8mPXo3U+fq1Y7y+hlE9wf6NTq/2wtsjny14/ NvtZfn6I+9dx/9N7T/5d/f4/vkL29I1fKuztb7Zrtaf0fadqp7ROE/c9yJVIfmb08ncY9wZo/I/v yrPlxz7/uMQvXX+OsX+P+29g39+trfeXV2v/gn/r76hukmRavXX3fr2XOmmW7KrjiQ7rG3fvb6o9 z1P3VDR4qt00UWmkvMhNusP2OE3aYxnedwaBrve0VgfO1PfUqTPEp2+rhL9VUajScx93rKl83soJ PeUkSeT6Tqo9pceOHySt+lvKxfMoiq92VSP0XU37nTtT3cBXe27qYyk/1eNd1fEyJ/Yi+t4NokTn m8j6/KSVP3G9UNHifjjCEoGfpC3VHaoQ06Iw0WEC+lwnVAOtYu245yBmcKWO3VTdvdNUs5Fyzx0/ VjM/CLDOBSjHMp52/YRowe6BBnkgSkUZfoYqHqqxP1DTnVa9LmI90Ikb+xMivv4wiAZOoNqHKgN7 TpKCjCxMdZwwmyADIvL8xM2SBKT4wkb3pH1wxMSz4BI91TFWcQJMDJ3Un+pEzXSs1STW4IkkCsoc KA6zx7SKm8UxvjArHXb3lRdDSUlL7YExkM0Dk2isz6OZcmKiBCJTSTaZRDEtOIxiNdWhF4FULOhg r2gS+zp14is1dJJzsAeWD3Lay9TV605LjOytu++pzmUKwZP8sHFhTT0dT6FyNqZWfdCScZ7axk6X V5AZb3y3dUeNIw8iD8HjwXG7t/X4uLcFlupuPmWVidaPolQnu/XyNFiMykTYIBjqDkeaBjPHVm5D XwcYMZ4Eeoxnh5SZWOmQoNJzR5RD+nKjMX3W7fQfwKqmYiszPz1X3cn0Phmad6WSK6xzKRzQyJwN +qTbA6N3MXIYsNvRA62+A+5JEHClWMQwjKMxb4rpCp8mE0yAzKGL/nluEdam2IFAeBpnbprFYmLv qokTp1DSE9bvPJv1vckkgLEO4EUpHHPPmzr4bqSTJi3r5I9MIftfUj+BdUSJE9TzVbtzq9Zt0LmR QaiN0wdttXP//Tubu3VizSe/hd/jXli9QyYCvY15Dydoqg2ODt6mMhTpxLrGQa/wPXxEItSXcDHW Jtug6kvUSkV9cJQwSilSJJq0gv3IYZQWthJ2G31JmyCI6CCaGR04EwQ+z79UMBHehnwYfgafh7NB AdqJgysKSK6epJkT+M+ZfpLG46hHI04fdKdk+Q3PSR01xNpJw04wvl8Kp2Cn1zl90m13VNdL1Eav e5BswgFDOKorNMzOo4AYkZhqJK26B2oGGcZ6y9NDPySJgtZs4tll4SNx5GUUmNnOmQCi067wgEgz FOdWS/tj0UA0f+5PEOrrHUQTrBJlo3NejGW+SvuI3xcJD2tDIAgIQ59sIt+2HYB9ddbbPmBxySqP o+RERsoiW5u5hxJ1LNCMLQKfJA5UCWMYl4VBIaCiHGK1ogO74OFe2wSJYnpTCD7s9/IPhRA3kEXh 3sb6znrqcabhDmNNEchPxlAbrQnRbYKjJEXMoM0ReEv0FaQ0INETHZ87E9ihOuj02qfdk373+Aib OWCSWUGeg6HCiSHPiyWyZikad3MunBXK2CQ3a0hWGxjpOWmKhwzBlYjMJggw2kFCMaQ+I95M3mjz +oeIXWPVh7z9UIy9dwUmx62GmkVZQA5E5JaSSJO9FMkGt5EOKQP6z8UOjRzY9hrbYguG4obNoazf mXNVSRngEGSRaCr22yShIVhCobFENUIyFBvcROwUibNePws9RGGYcMJxduxbW7JZQ/IlYoIJb4nJ tPPmYBmegiWOyLC2FLOaCiLloENgxcduJrNPI59ck2PTGEjAhbRTLUloDB4pgvuGGOt3tLejQj0z nrbOBJrqIoxmFA1LCYmSjBNIAgPgQb6haGtkEOtnmR9LMGzVVf22+bv+yIlHGn5xDQASn6ro0Mmw fcxpYEj6iNSF1hMOFIlGZuPYRaH0uIeElRFYS7DFEINJSaBOMjSxSrr2dOKPwio3FDtp4wj/xIpU YR3qsHcsqd1hAbG30ypj/xLbgttt+bi6zwQ6YckBOBb2DidyOHmzh0UhrDaNJpQrJuTf9XXopi8A mCkdR0CLjGtE3UaSB+Qo4oLicE11UgJyBF1L5mowKVGcgwKDBTn1WUAIcgmQkCxIbBpbg9yVuEHE XIYO9XqbkrmDPN0W5yEzoBzkW9tdkRnYg0NO6YABUCwYQS1BM9qU3lnaSGixHsF8YnGFieNe6BR+ 3tdjIDgn9rEdZ6lpok47D7dOeyeUUGEHWtJXizO5FBeDmJIWpDuhWqENY43Ey8Q7J8BVNEf1iqCR 56QF+kEXCpmASAfJxl62d4yXNAV3wDgqPrHhG+x0D/OTKMiIq00I0QIaAoLYWiNpGdEONgn8qqF2 Er9kD7CtOJW8R67B0YshcEKmWcQSb1cyNsETyIq1T1AT1ht71nMgiAkvaQyasa+xF8q4NOa41+ta 3AG108d7Yagv1UMwv6PqjZ4PoimHSdQRxAunSq8mMCbanMCvQ6mG/Q6FlAc/dQXx5SmHIzhBVLBB BR7xjbmwgDAhVRU7UETisLcVDbdyQBGFQ3+UGXvp6ZQNKY9ZJhyCL6KvnDxUJ3QjkojklcTMhK1c TygpJIjAoEC+ClhuqW9HMyr6mrxmiW6ykXFSBMWywA7Pen3OJH6YCexFIYwVjeaxjUFHJkJssDgH /laZSkmmFEXHmixrkykYwH9mMFuqdCYgUVxc9FEihShEhG4YHGzRpjOIEFbGPvnQgAUQU6r1mkVu A9lDxA4rdB3DhW3VhWBD6LkEssWA9pEmDk7J60IPtAECZAPkZK4rSmKT4MdxUCIgDxQwE6uzBOFI 7cPpaOtT7cK84fz7rG6zglX3aSXf1RutVkvda6l97D/zPYiihHdK+1GEHsMcufyyGQqmidGDyAjQ i2ahwVCCwM1DrhrAQ0nsU22rF1I6UH7Hcc+rFkkFbtX2OEHBtweVsoHVJ6GR/GQ49F0BDeToPj3B B2EnujVCbdQ+IfM/OzjBnuKznHJ6j/YSyXU2RyZXY9hOjOmDXDKjDFxDr8ZBQWGoXcRAR/Cdlcq1 srAkDm3JQYMHRnMZ6zE2+ivpREr9kgas2E1O4D0iVHec9YdGsjRDMog2c+ackF2QSUDwtzHbwaJ+ vFgeMU4jz7S+6IxGlAfAsBE/5MY0SInKcpzzKxs+uHyExnP1thom4rub9SLl1g+R2QlFcuVv2gBU h4T1Q1JbnskNuOPML/CxMHLaDMjFJRuAWqUZuJnX+sptwX/0MAuYYE8PstEIymiitvHdi1I+bM6X fwVumfrsLyXgT3U4F7j44bwTDQDHQTvHNO7aFc28XQCPXjYekyFB7qXOWdEBSXj4bn0FjlKmSZd3 B2hjbEOpJ9Ta0963cpRSSQaclsTBGOESO0EUXSD2D7PQuK2NRAa+HtHqu/UGBVICS/DDBo/hvD7l zBoEDJ43FMC+XXGzTluYyMHKoElPMzBKuBEWu5HLnxslmznJEwaZ8LaSOW0vZUBCtGGBuNESin2C atmIbMKUQ2qjLEbxoViVwA5skWuPvfI0O6Yq/kIUYhFHhz3QMPLdpulA6BHxvasCuIx7VcLYSHpU LCXIorwS9UGiYTojBWYTzPJ4S2cKhCgdnr0gidQTY/vCLjV3MY4WIvsmdCcplImRuALLigBxHgkB uaGIN/sEjqu7sqWabqEl2xF0zFbRgnKhP9eCL4KhgV18jG/SzRY8mMgzLajM4ioT8ABlUaxu2ajg QIdXQIBNjt3w+THifQjSSfjbQeQgeUJIocvmEY0HpgqHVzxCxqAqg4IMZ63jECaG/cgTMo+KJyrx WQ7OgFoLY7K6YRRQriEZlTvDuaxLJXSrzuvKklEoqa/kSGx7G9zPtDUTdfAIE10tOCfCEx4Jdsc+ e30l1LYQnPwoRhHxnMC5yRgsQ8iN6kJbDEAekJfaAPxwEc3HWUDe5vnOZlM9pKpXWMcomaXjGNKH XSa/WsouhZDBBWqXyGQLCh9b7L4kBupcEXuAfRKPpOpLoOQ26wKTvEJE7xBvORNGxYngOyQNqkh5 dKmRJzmRWWotiGyArAhKsjDPuVRcosJNJHAKnCz1kiWPi2Nqjji2F1ApajcGVPjpIdkrhYBtylol qwR4tJkxyUgRWiBHpZrfaHyIRPqtRhMyk1zDYhsSAGU67rYiCoebdWBiqf54RkPZZoQzcqhhZh0o r8htV4Y+0Ikpa42DcuFmD2fyIqqU12gLU6mjyiV/jgKOGAxTuAlPEcHsSS2q6mIINSBhJhgB2f+c m8Lwzxk9gXRXc6IGR9ssJE9T05h02n7Uhb1QZe6H8imGblKI6B0dntDC1IrhnsTUR4iVdhK5hT+8 YlVS4EV9zNAZ0Dsm/wfLldROojWS8QX1cP0jDT3HM11w/A4rgGkvCKtLtyHpi+KexeXJLG+vU4eI WwNs8TbWUpe53Bc3e9uallBBUQuZlAH3JYNVxSEDVRcSgKTcN3qzZ458kgOypUsfeqWzv9yfufeW N8qIhj0TQ3lG3t/jgAH73oFOVp1+cKEVXCFyfHjuA50Aa4aSy/i8KU10MGTMG6VG0pRyqZLmhl+1 VIYPJramPndiCivPUdT3LESWpAlrkF+gZ00MBtk4dGJiiwgCsfuWUz6jfTuh/S5Ug3ojdLqwIyeC W3feb9T3UbRKJy3PfabFJXvIgYBwvHw/GJocBbu0qMRA2on3UHfeb9ncmZgSjG2+kmkNwEgs/qBg wrs/jeDeLWBb2rgtxaPk0WqbxaKKTmi6xqgFpE2jGie2P5IaihvC4dgP/TGSJQeNahFOj4jTLQqU BSvHci7eLAEFroSdZO5ABoiMxNUdduG/l9Xh8OE0lcNnctV5yC0MyAk8ahLCALP8DEFcSI6SGEfn YZ71ayuHSRZP+Jgczuy6pjG2zVnc4GuM1MZNq7xwxipOuEAYYoiADxDSVLRWUPIvHuNq5A0P+eyQ u4iMY8l8PQnnDNylnFIMdlEf6qmAEcRuh/t/LvdgFLUopNdDR+y9zKWk1bSn9h4SEp/FDcRoWY16 yhmYkht5pr6ksxuKO00gPlN0zM+3kqoy/8hJ0jM2dzEUsmzPHH3k7emqgg4hSIqyRWykpW15ORBB V9qRNrEacGAoozDjS8NrQJUi9ttgtHTW2yyOfdNqB1OOAmhRlvOyvmObDwv69LVT6Sab77vhMZe/ zWVfnQgbXBpTo5zwjUNdLrKsne17Kn9TRBbZtnyzDFb0YUHmNul2w3DOZYyR3rs73JjkPgY74KaV jxx6wMb2T7qKG8V0IsRvLaRcH5xqSqoUoXxJOgTCWcJjOBslHhA0ZaOVDmNEVHJfyyLF2Tn1x3iD pLJHU/qirs+N6izO3wFAKvcjL3+9g4FZpZKkoG9OVFv8ukQQUSOiSV4IszCnD5yDyt7MBXn5KEha Y0N72E1dtSytYG8km54YihNemQq/SYpz7MmUABo+CeICZTQiBCeHHMjl1NXzNbcXKSwQ9TMdEHis 1ymT2U6xTbhIyqvC7/H+dzrt/lb/eyedujJX73tH/b2P5PeD5fPysYd7H23ttdudXk+RFLYcjgLU yS6W6+/1z3ryu8F6+XelA9H8M7oapmAtC1LAbgL5QvWl08pWZSbBLs2s+ebNI8lO/A5BYk6OkftL C1Tns7WwhgmHmyyRmj5ekXvEsOzyczRUnySzwMeoKCPXJvroGNDhLoAEhMTqPoeSLXXdoqRnk+Qk tpr3Vgr3pJ3whIf79+YmV65F0zjondiDmFvOsxHqVtPOXnK7s5fbrnOZFgzefqbZ87YTz156y7Pl W5LXS1DS8jqIOVegviSnIwJ48ZxoFjd4wtlTciiM8O1yHmib/Pf2nHkjIia6CIG8sel/MPwpMjC/ CiS/kLtVl+FDEttZoSK+koPkJcVmJQT4hDrpELOyTnkvKoR4K1m88DTC2FnaalzrqEM5vKd2G0Vh J5Q3K20FW+QL8+oBItRc8IihZHJqBhoCqSo1EHW+CZB55tCkOJSbW8i5oJcy6VzL4MLduRF3W0u0 eei4e+bA1fRt2RTkBYZlOqBLROVTzOFXK7BjHGEF7rXAANQERbVpfcxZwk5LHZRwma/zhn+7pIUl el0kYx73mYpTLNOUfoJhFueuMOsSSCxVdfLGCUImKF1YKZ2ZN1DdTN7fNOcR9uWJ8vVuSxpxFRgB bWVc/1UPkHO2lvC9QlDenGAdKcMXFyjIFVgz4R4IowLh0rGgE1RCnoqJWmQdjlgkulJuEuhUcp3u 0UHnI/X9JWKXVPeDfOTu7gdLx0m9ehcj6ysQBk/tdR6fdY7aHfX9CrWr9q1e1PkYUSZsrplccpr8 Kj5bN7s7qU7On5tKbW2pAw0wy+cHa9Y5iGZhGyoIdWCL0aJ5w8/H8a/rOFpHz9lkfpWXW+f08iSa IRiUrz684NzbHz9ZNxlVDMzneDikCsRcZ6Ekq/UK6TwrXrZkD8N13O53+sCSp92jh+vmS06rXt2j fudh53St9EJuIGuvZAs5pFo3uU2NDPLyl5l8FroyXQ5ubje5B8k6wVFEJ0D2Mspaa/2+SwzzC82c ktQtXIfgybzEDNH3791g8oLEbjN5QWI3nkwxx09O9Yjwvxklnz2OkifUg4rCtXKLvEze4OvT6buZ f2ZOwekzGbc2foQ6NRFDFlIk/8pnt1giH1X67EbuUsqVdFEbAt+OJ+smf9sfnZ/m7zpV/P7mDp/j 8dKoG9u+heTlUTf3us+z89nn2blchsxNvpH1L7B9K9f5PDsvsJ1Pzuf+YGnLoeB3Xdshl2L+bbnR QK9CbBGwLea+TI+hH6UAQ7YjZHte/Cba2E/zyp//oiHHaJUlTB8KEGt53SRtrRJyWoWHBPLs3CPB XWPhXyKxyas43CKN/YSP7K4VZFVu81L9ogX53nJBnn3VDNC0k68xwS9YcPdXCe6rboEkyS/CBhut m4ry/RVRsBL4byjPUmj9PxEIf3m5GZbT3pdIcl/uWPgrK2V563D4v22GS8NhtZPxxQrv3TvXCO+r bohfVEi8uTTvzoXEh3GUTZ7sWBE+PD0+O8nXkg97q3s/zkT+hoWOwlaM6V2Fbte0vVaNOXO9dUMO nUt70uphr62t5cO6YaJjEtC69brh1IcGTp2Qumx7KR0Wzzf455ddt6YIGitTr5dW1qf62WrB8GhL wID/lnzNYLu0Hq1f+IEDu7nZULMs9XnWD+6/R4UpvVa1tjy/cQNvsfG2tu6b3G68aaWtG1YunteW YXMtshvV+Gv5yls560YWfZv1a5abNOtGl/pYaxU817e6SeF6Y/4qrakbrXwbLg+iUvtpLZ+VPtO6 0S/fObqRBRVdonXDV/eF1kpn+UnpsoHLDkaXmOBNF1x+0rpU4TcmcuWZ8XI7usWy66g1GWvPg+hl 0pqRxd/lrxlYvKm0ZmD+ytK6YWu4NuOO9Kww3GviLlzmOuPH1+2I/sOE1fk+8k6oiwtnfqRXdoIx 6sD+ubLvBPYPDK8Z/qDT7lAEMrHlmi6zDG4jPtDrpyBilJ5fM7bnxkxt3NPau2YcgMx+Fidpz39+ nXge0n/iwy3g68dROLA09ugvVnV47fY5mdeM2b9KNWMd/h984gM9uZbzueH7QeRe/A97ZwJcVZEu 4P+yZIMQQFlFvUhGE0xCEnaRkQQICbIn7GsgIURDErOQhMKpoQZxgNHxzaNAp1SiVaPoMBaljCjD KIiggAqIjrIIWDoCpa8GQZ74rDHv6z7LPSfJhSSoMHqa+u5N9+nt9N/buaf/n0vU2hLtJfpI1ryF tYQ19mLiypyXszDbUZPMstziS1REJ8ksVo8AuSXDC9XaccnY5XP1kXvV6kGHi+rgxgblYrcYGO7j lLkHQ+Uh+Lwzriz4BsYobGJZvrUludRm1U7hSBMsrrE/KywYWlaSEbRzOSLpRyHVLYLejCPyxNLc nIbGZc5tVN5qjr5U9moreYlbs6PowkeXFhQFnyjtuBPVU98IrcuZ08AkOvuhhWWFDS2Ce2tEdKv1 Gh69CfdgFdK4ejXyToYWFTSmALtCPN40smkbnsKqU8NTOKulniAaX7VGpHJUrxGp7CpmFOaXjVZK 8o2sZGPTWdVsbDr9uNCoTuHsqA2XmaOvNipR43tHrfo1QmjuOjYuYdO6ibOuTZBcUzuLo761ktop AwehmvSjnv55TCu1mgd9ncZe8guDmWxyZWIZUwjyI50uonRSsr+3/mnOcCmWYTTbWtkwffrM8qaN GjvZYQXGtiumdaKUsUGXgRhL95FMiJc5Tqk1ZSQmxQ/sn9g7uZ+/bIE222JeiM9I7BefmJTYt7dh oixlTGZGr8yhWcP9ycnxSf7kxMRkf4w6jJmrlGyGZWb6E5PjE/vGRkb2S0hKSE7oHR4oTquf1WML TdmTUb9zqsOhho6qPltoaVlbhw2Vma/ikqKyonlFBQmuxJYZBW2fICfX0Pc3j0+aGk9am80yXmJp /wa0ULXhIq1IMo+H+xKt2Vmlj+yZetS6WrZJhYCBhuwCZYxEFaH0+JxtaykcZTvypcTiYvUz8Nzc sgplwjLb0neyzvmZxvSseOahUUPnltuo0HpygeKV1p1RA+e5eGVuJ3BwsFCb6jRS6iZQDWqbRXB1 4gT/ZOuEIq0dX1o+tyC7SqnNFilNvTitYu9seH3SWGlZF+bfU26ZUjSMqqRMNQ0DaT37ImWFsSTX ldgwt6dqbSgAjI4zNM9Ki4sKtakc834swy+OWpuaXzmBG63VblbFCnPzisoM3TKryV0NY7aXqZjC X86f1RO0sm+2bv152riFS9EtLqD94BC7eWxW6Z0PMrQbKrNVMnU3Rerh1K+0f+NN7d+McdY9OWzX qEo5czRHjBJ0haExodvS0Iaq1DYPyFyf1V2UW8C4MU2UWIr0OoV1dthqQqtVjTcKDgud+lSqHnxO azW6RKMh9JuI0vpGTH21zldqZcW24oZVpzL3VPDfAVuBqwP93BrtyoIo3uxS/4TMSeO04CZkjTPM ryptTbPjOSe2UrNPBo7cmqKqp19rxT5/gX6mr215zsgrqY9/rjoQH5NdUBawxOiOo0xuqOO56oVN SUm+sSJk+5P6xZPUsHkYq9Rx65+MbXuQxrS7KDkhkam3T3xi78T+vRNVwYa9EctOaam2JGNGTkpI itcz+MDE3klJzL0xdOH8u3OtqVybw8utLNPqlkUl+XlKj7bKXCW0eUe1Uqij/f68EjVG9JFsx2XV 4snmN4XFxvnnah2/EkNnWudtRw9YYK1/FRhgBLlv/WJrQ602upyVwp3V5a8bfn+2bYlSjzN7iTBU Bm2LPOPV64GyKuet/XCrj7ZmFGwJqmXi6KpfkVIM0wrWQc7aN6mKKzWMXzs1iZ1CRyzaNF0gj+DV VRHjdA0XKKNwhkYyIY7617/3UFcDXcG+PVto9XSAK7T22g0Xk5nW5BXYPZAath6bS+Nlrcnqbhbl Z/tzqgqzF7IYWfVhTWXznV+6QI/KGNvEZaZpSy0pKaFPbMMXdKV24r5FhlOMak1LoHG6bQMj3FC3 nWdpD31f6781lL1NwCU3AXr8qDyVqR1n2yw0jf8ZBtSKiwx9WL9hXSy3RFsXcwvbMr8yz7RuaCzm RvnaOK5Oq2dppK61jVnzq/QYVbbfDAO2hm60Gglag9Wc1pU9OWO24s9KbUXBOAxC31uszM0uzC+z u7o2DqkWc7vpFqoy5mujqTp+eWFpkdavJiBP/TaHUNLKSyiqRDeCsk7pNIjEgNSqz+pgucpPG09R sf135xfmGLpRtYzkOIyxBSze24aVhpqGCPypFDVBZRszNHVCbLy2gecy3mQaMzMU0kqDycdl4E5V eG5BoKaWuOxp1TpHYxgc0xVSq39gbY3T1l9cAXdrKQT8uWUIKc00a1DIlKQMQigld9MYmdbbVs+3 cbaNMT2fWd04W9nQyTYtirk2AO4pwtWgCabWpruRdb7ZBXSxUm3aIGDXSVUo2zYdxdxVVuS3bMjq WdNsIXW1QNkHVoeMrK7OjTDMkE2hnna1EW5tKMieKCOtiXIAe7Pk2PprZ5isIIFlX9nYCwTb84yr 19KU3mwrCwy23VhzlbGzqS+dYViwTtF21Ixh5groCKndmrULnJ9fUlrmauPyejcZttmCWuYoSKm6 qj/GmKjUwFaTLF/mWFMpTHvphvEJo1r20AmWo9H89befve7nL9Rmt7SZKW0XS4uWvujKUT2R1Mqt bsPYFTI0C5neS4yDSKbOsuuh+GJVY+PhzM6eAdV/nmGdfKvnbspNpWSlNlmiVhtrI6fuwLKwbzVY fUUn+GMmWCv+dMNC2oCZsUaHSHHsm+ytT77Rma/KZ0RdkrVxUnZo6jRdRkA1WA2FQtMuWq/sHPMk oet+3RvFBt1szOXtRWMv1lrWjobm6J2sm+xHff4Wz3nOc57znOc85znPec5znvOc5zznOc95znOe 85znPOe5gGshMq2lSAHMCROpgAmtCYOpbUXug+PtRZ68RuS6TiL7YWusyH8liuztJ/IWvA0vDBA5 nC7Sc6TI4kkiL8MWSJgskgoPwIOwHp6Bj+AYzJ8ikgefwj9h+VSR++FxWAezp1EviJou0hYSIQky IQv+BWcgbYbIn6HPTJG+kA6zYCFUQhUsh83wEuwA+UrOyD/hBP+OmP/OyD7Zs23Py7DN9a3+7duz 7/kje57e8/iebU+LtEvt2WzsyJYyHooXiNTItf3Dlqb2DAkE1qgmbm2EWr4x6T6xYkj7vmFL+4Ut HTqyLWEtCEMeYfbVjly1ghemS4tCKA/zSTglGyWG2xnbZTcnenOr7BBymBG2VDqORTDjAc/C9HBy Cicn+aWSvw8ioSukwyp4Ck5DIrWY2jLQR0aFiIyGHMiFNbAbPocv4Bw8FCryIRyCcPpTBHSHiTAL /u3sf1fE823Dol3Nnv9tmMfpEF/EzdIqraUhch9B3ZT8d90t8l2wRJ77ybpmPp9PjcfZYYG5vxKe hxdgE5yEGeEiM2FRBHHgzVaMeRgQKTIQJrdhjoAVsBLWRzHHw7OwO+pinfiM0/OZ03PI6TkY1ONK c+U9wWsdPI0rmisDh2sZJZG7WopvgU8ioxjFvlZpIXZIu2XIDyQ8ECtq2QLfLNCxxRE7xI6txn9n JZ89MJl1fkrbwJq/HH4Pt7TjOuyFE/AxnIYY9gSxsATuhQch51rWBNgOr0F0B5ERkA7nnXfj8pxz ev7H6TkR9MpPzXM4qMcVzXQssf2jZUC0pEfLReQb6DMh4ouqt3dIFyWbd9nTHYQj8BlIZ5EUKIdF sB8OwDfQt4vIMtgMpyCvK+P9OvZn3URK4Rg8cD2F30A9IRRegql+0jtvwiX279fzZcM8XwT1nAzq CR6tgRkE9zSlorWdXuGZG0LttT7UGOeOvuDsPdJVyWUavAib4SXYAjvgr90Jh/Y3cQ0Se7AOkGj7 zYz7W+gLMSL94E4YBaPhHngMtsFROAM9Y2vJ/munp4HS+rRh0Vye49+r56Mr7nE7xnTLKEvKDZ0H RHeSwPhXsrkLnos1nuua9+S5BsbAcvg7nIe4W3lWg3VwCNrHMbfDA/AedItnDYFceBrOQPsE1hRY C8fhul5ch9W9/lM33T8BT8CpNeF6JYsPoDPP83PgD7AVPoOT0CaJ8Q0r4AB0SRbJhsfhKHTrjdxh NRyANn1EMmA57ADpKzIYlsJuaN2P/Pp5orhinoDT8ley+K35G05Ef8Y0LIPt8B0MGsAzAWyCV+BV 2AanIGQgezwYAlmwFt6Cr+EC3HgbsofpUAGrYB90GOSJ4op5Ak7LX8liCKRAPtwPf4Lt8D50vZ21 AKpgMTwBr8JH8A1EDhbJhEfgddgJu+BLiPqlSDxkwEyohvdB7vBEccU8Aaflr2Thg1shA/LgN7AW jkD3IeztYDRUwhrYBPvhU+iZIjILVsBK2ATvwhlonSrih/mwAT6AD+FQqieKK+YJOC1/JYsLEDFU JAEmQDn8EXbCOegyjHUByqAa9sIF8A8XGQlLYAMchBrolcZ6AL+C9fAP8I0QSYJZsGqEJ4or5gk4 LX8li61wGjqli6TBPVCdbrzPaZ7B3ABZsATWw0GoyTDe9WTBvfAUvA3nIfpOkaGQC6tgC5yEa0ax n4C5ozxRXDFPwGn5K1mshC1wDCJHsx+APFgDu+FriB7DWIcKWA274Cx0GisyDIqhGvbBWbhhnMh4 WAob4Th0GC+SDovHe6K4Yp6A0/JXsngGjkKbCcgeKuAv8Al0y2SMw+/gFfgKYrOYx+FhOAARE5k3 YCn8DXbCx3AebptEP4ASKIWySZ4YfkzPRZySfzclj3JYBBVQCVWT6r7D72W+x+8+ReQm6DGVOQHO wVfw6HSRx2D4DONd/Ah4Nsg7eddvgcE9rl8Jm+Jp4DuHyy6nKTX4fj3Bfws3nfW+V8nc+XtgN3UO 4nU4AIfhBHwMHWaJdIRpMB1mwLPwHLwB78MF+AbSZ9OHoAJmzxGZA9mwDt6Et+AgvAf/B2HZIuEQ CV0hAXrB7TAEUmAY3AevwSfwOXwB/4IL8G/4DmQu+1DoAdEQC7NhDpRDFSyGJXDtPO4L+sK3Z789 efgkn/tBffL3G5s3aA8XzBDlMT+tuCe/fVT9bH+DcW7DOHPhPL1hnrswTmO0chwP+XWtVK3cqfT1 dnWS1Hc+pLNRqvMciavU2udP6p5TsU+YDFbjcR0yrJ5lyKsaXqddd0JqLvs4ODaf5/48kSfh+XyR F2Dn3ca5gR9w6go+kj4P6jnaBM9/pmvTVm7OCfGJr3+0b0C0Lz3aN25XGOE1IT6fRIh50REmvrau N4d6LohSY6EfTIGpUD3PLXclcyXvF2EL7IA3YA/shbfgHbjmLnofLIAvII6+MQ2KoNjsK+dOnTt1 /LAcl4Pyjvp38J033pFtoj5/ts44G9bKHP+R/KmGteENty+4T5AFzoc19ARa0Bmjq1+SHlrgu3Hj /l7+jScGd98YFnoT9HioumU0/GJj0Ip77ifhrpV2zBY+yZcoaW6HDmAh/rKmGd+tmTPGSJGUyELJ lgKuNRN1QGDoyM4yO93XIptvdZ6wFMrASL9MWszxEZNv6SnpkkvaHMoolDzxSx+JI0x9Wn/F1xtn gf7MlgQdy3ldvVgKI++QaN+Qm5t3lCDHJG13u6QMOVvzBN+tpaMMI6/55FbO/ZRR1jj+LoE8/VlM uX5J454Luep03eS7Ip+c5bs1ZacSI0eqdIswk+JPVffsS+VquH3VL1mUVqlzaiVtHdNvO6kzeLXb xYzbQWSDkk0NLpKwFt1ranxSvfgRIwq+ZrZPXWvuutYicM1fU9MycA1fiOtaqOtamOtauOtahOta K9e11q5rkYFruEUsOUvUmbBO7Nf87Gd68hyJ+N6/TWRkCjNeBnsJnj378AxxR65x9+ZWVX82ExXQ XHb41FHlNFGvr1V4iNzKZ6gki+oJvfkMRy6i+7Jq6VI+W9u1UGGqHbtCOqyCp+A0JHJxKkyDAhhF Bx8NOZALa2A3fA5fwDl4iKHyIRwC1ecjoDtMhFkwG+ZABVTC8/ACbIKTMIO5e2ZLo3Uq4M1QyoAB 4SIDYTIL+FRYASthfSue0uFZ8+TdHpjM7U1Rp7ThPlgOv4dbuNE9sBdOwMdwGmKQQmwbQxr3woOQ 05Z7hO3wGkS348kN0uHda9i1wxH4DOiOkgLlsAj2wwH4BvrSYZfBZjgFeR0NiUd15qkfjsEDXZAd AgiBUHgJpiKyafAibIaXYAvsgL9eTzi0v4FrkHgjbUYP2n4T99CDMhlD/eBOGAWj4R54DLbBUTgD PX8hchc8B1uh+c2MPRgDy+HvcB7ibhGZD+vgELSPoS3gAXgPusXS5pALT8OZWKM3T4G1cByuo1Pm wmr4ADrH0Q/gD7AVPoOT0CaeesMKOABdEnhigsfhKHTrRVnmSYkD0CZRJAOWww6QJJHBsBR2Q2uG wZ3wW3gbIhgQI2AZbIfvYBCjrhI29TFG4KuwDU71UafEkT0MgSxYC2/B13ABbuxHeTAdKmAV7IMO /UkDKZAP98OfzLfH70NXFpIxUAWL4QnzDfJH8A1EDhTJhEfgddgJu+BLiGKGiIcMmAnVtxmzhgxi PMOtkAF58BtYC0eg++30BxgNlbAGNsF++BR6DmaMwgpYCZvgXTgDrX/JhAbzYQN8AB/CIbgAEXfw tAoToBz+CDvhHHQZQptDGVTDXrgA/hRjplsCG+Ag1ECvVNoafgXr4R/gG4poYRasgq1wGjoNE0mD e4YZb2AOQ/PhtAFkmW9g1jvewPQ038DcC0/B23Aeokews4dc8y3MFjgJ1zApDoK5sBK2wLF0Y3Ye AnmwBnbD1xA9knuCClgNu+AsdLqTJ3cohmrYB2fhhlEi42EpbITj0GE08wwshmfgKLQZQ3nmr8x/ gU+g21juBX4Hr8BXEDuONoKH4QBEsIKkwVL423hjRfkYzsNtEygbSqAUyqAcFpm/dFZCFSyGl2EL JGQiH0iF7lkiN0GPidw3nIOv4NHJzDUwfAplwwh4Fv48xVjN+kI6zIJ102gPWDeD7xnGLy47IZWn 7KFwbC5jgyevJ+F5VsEXYCcL35vwsFrAEs2F7NeKqz+EoS0tLhJHrbU/p5CW/vpCfHVCmjU65xB/ VJ04tUJ8Vpw5LYxdTj1xfqoh+t5VO3/v965zbvZD5CxWnS83n593SEPGaUNSXf13UTsktM5sE1p7 tvFZcdTOPRDic4boVM3qTXXKFad5vXHU/t+dszukWZ2Q5s4QlUWD7rRFnZCWl0hVX0hTx2ntGbsp +YSST0idkNA6IWF1QsLrhETUCWl1idK9EC/EC/FCvBAvxAvxQrwQL8QL8UK8EC/EC/FCvBAvxAv5 YUIu9cvkAKnvPVogH/WO8scOkasopG77XKrF1BvZHztE6oS0bUCchqRqfIi0MGwfqnO/6kxuKkE0 pEwU45qyB6ZsQim7QFP9hu0WdQpF2QlQuuJKX1jpjKrTA//f3rkAR1WdAfi/m2w2IYEsQfIQi5FU pAIxAQLEVhokAlEgaYKACBjywIAkC3koopYgiIro+GCAzjiW6djKKFrb0kqVtnR00DI6olMGrDKl PlpGpxZtdaoVtt9/z91ls9nNZnGmU8f773z3/f/nnLvnnnvOuf89V98d0/eH9B0S9SNXe9M45ApQ Ty0Osb2tquBKuApQkdkwB6qhBjAhtTDXiYPaqWRRvdXUb+s69gSkUcbLJE5KqZTLOKYlMqHXvvHs K2W77o21b5xMZFrea98EpjqfGMPmBHJZua0brTeO3wT7iDKmlzg+A9G8dL05/VzOtu9kikmkDsMi U+tiE9J5ZqzIfjgGVjG6kAcXwgy4Cq6DVtgED8HD8Di8BCdgAP9eI6yDnbAPjsEpOJe8MQkqYAZc DTeVmFFAfgavwoeQVUpaoApaIADr4F54En4KL8Jh+BT+AwPGieRDGUyBKrgNNsFW2A+55KYxcCnU wBLogPWwA3bB8/AafARByKsg/XAF1EE7dMMjsBv+AEfgU5g3lRwKd8HjsBdegz/DKcgkJ4+FergV NsNPYA/8Ed6GIAwkW18Cl8EiWAF3w3Z4Fl6Cv8EnMJSsWwSVUAsB2A1HYSKXRS3Uwy3TzVvRI6AE pkI1NMJquBu2w144AO/BP2Ewl9T5UA4zoB7a4C7YBnvhALwF70Mml18BTIFZ0AwdsBV+BC/CYfgE UrhMR0AJzIR50AUb4EHYCS/A63ASTsNQLusiuBxqoA1uhUdgN7wCb8JJOA3nUQRcDNWwGNbBvfAU 7INj8AEMoZi4AKbDXFgDm+Ax+CX8CU7M1vFUyccwBWZBF2yAJ+DX8Bf4hx5DcTMKaqEeNsMO2AcH q81bq1ocXQRlsAhWwDZ4FF6FY5BOcZULlVAL6+BeeBY+pgj7HA7O5xzBiwtEDkHuQpFCaFskciO8 DkdgIKXmOfBcA/kWPmwm38Kby0Tegc/B4/gB+eQ8l68Vw2JsU3mOHPYO5HPTPhdmX0uuh63kqG3w W+7t+2FLk8h9cATegN+Qm363LJSbLk1AMHiOqG91M3c79Y9vsj3il3Knm8b+RUznc/+bxFIVd/y5 3PHrpEsapFWWSwe/5fbxhdzJqzm2jqPGwnSms5lfjp45rosQirhjT5RiO4xGN0w3TDdMN8weYfqk YPHurKaWBZXB7OifX0bPq/dvO/jIF7H25U4feU1F/sL3Y+378ZSPromnN6Dhgabh17/VFmvfKws/ a3l78ZZrY+27vev9dfFsWuGWQE9JyafduHFy6uCNJaeG6rvZk1PTlrBez3pglN1sKLbVUrt7K4ut vNM7eOOO07byTi/KO731rHvQMpqe2+NprkofvHFW0NZclY7mqvR61j2EajQlbpgVmeEwKzLRrMg0 YaYkjK1/UFjTPwhN/yCjmZowtsf94dge96N53G9i600Y26eHhMN8egiaTw8xYaYljG13blizOxfN 7lyj6UsY25qCcGxrCtCsKTCxTUeTFrbk9daTIbZmixUOs8VK08E6NUwdxb/mSjOS/xIgc1hcPRp8 XndvU5nhfOWYCucrNZWGmTRjIpDARLovbCLdh4l0nzHhw4TPmHjsZN8mjmaETRzNwMTRDGPCwoRl TDyTwMSurLCJXVmY2JWVdELWZIdNrMnGxJrspBMyMydsYmYOJmbmJJ2Q/KFhE/lDMZE/NOmEnMgL mziRh4kTeXESEr+8oS0ZKm9EMKHjxUaXN3GVY+dPWzlxkaM50rkswjmyf0VO7IzYnyIndv7rT5Gj 2c6JbTjb9a/IiZ3b+lPkxM5k/SlyNG85sQ3nrVCRE50fWkKLffylZzKDW8K4JUx0QjR3xL+JHfKE TRzyYOKQJ9FNLIYpE5vY9ZukEqQVHcdEuKKT5D8Tu8aT1D8Tu+qTVEK0DuSYCNeBkkxI7MpQUgmJ XStKKiFaPXJMhKtHsW9i/niFVuwsFnEHuz+eZsIa84PxNBPWmOOGmbDGHFczYY05bmwT1pjjhpmw xhxXM2GNOW5s3Rpz2IR7Pztj4n91P9MeVm3BR6prL8GZNcvubYhc196AyOO1pyJyXXsgIte1ZyFy Pdin+CRazLYcue/w5qICyUgdBtkQazlHDvy1ZG0KS16wINZyjswpyh0779Oag33byo6j39PWOXuP /yDxUfFCST72ek6e5JTMG2BGxahcYPq4NTtEE6ywui37maqS7vPpKFn2sorOKzbuv8UT+n91OJIa i8KnQk+7GvDJ1dImN0BAbmKqW9N7/DmWM9fHvcFg9LIeOyNXC06PJy3Fm+r1pKTeuVYK2dwdsuOY kLmyXFqlWTrYPYf5TcxrCVeH4mljfxl2KMe9lsfypXm8oZwSkTltFwipk5vRaUBzJWvjR9qhZ6al elTihj5V2gnfDPozPqdnjM8MFWQkVISfibHIt0f0DCeejg7ts1JuZNqJtnYs8jdqeBGnNX54rfbZ qWXeJonP2HfL7Dj5UjI8Hq8nNW7ap6HTZae/mWnIFmlKs894VGx6n/H5YgYqCg1YpOdjBPfq1elb 8uXkIU/orrdgzNq01nFrR+pytsxPMaOy3XO1uj2MFm1/p/h/FWF8YDgjq1yQIicjg3YlGUn37fTu kT2yfv2UEh2OqUC0VC6AgcsT6UbKAftxWlrUVq2BVtlvh2aN2/A9/Z8iS4lYEgzmOEuZ/PeFUhXu Ci90OsON9O5+772l33I6qJ4onl7bNYsdv+OHH39W3eJ/4oF0GX3RL95QR6I1lp4qs/9+McncIeYC 3S3Gs2WvGO+Wl8X+VpkcFbGfXL4rpvj7t+hoTZwYS+9i1PssHbdJZIJlxmyqsMxoTbOYD2K+wBJ7 hK16y1xpeukMYb7KMuG/S6DDxeiOLqzq6OhqLiwqnWhvsy8Vtg13wmxuXNreFGhbKpH72Ra9rG/N zgm0ty5dWdwU6DT2e+g72zTdpWVi62icZi9vbA90BJZ1Fs4PtDcVlherd43aPVi8WgsQe/nEPb/f fs/zlr088sjLhVuet9TOQMeeFgE612IguuBzxRVXXHHFFVdcccUVV1xxxZWzkb7a/57Drxx+uHiY /6HttP/HfPaUtv+/ENPO1v3a6a3t8lVi2vsbxbT3t4jpI9gq5nHNw2La04+Kab9rP4G2lfdALuwT 0/Z9wbGtX2eIbNdr38C0pQ0rm2ctbeiQUrtNrJ1iOh/tzLXLRud/H5QhzohXcefD/Sb+0f0FWX4T roap6Zi7vHNls2mRiyuuuOKKK6644oorrrjiiiuufJXFbudLz1EptO2rz+v1Wb0+89b2t7adtb2s 7XR9Jq/tfm3Laztfn+Fre17fF1YXTW3Ta7s/X4w7hX51aZjo97NEviGmfX0+FMIFoo4xIkXwTbgQ 1BvmIhgF34KLxbTzx4A6ahXDJWIGSCkF/QbUeNCvgpWBOkpMEjM6TDk4H42R78BlMEXsYUzsZ/FT xYyBMk3MmCNnO3ZJnZjxS3QclXmi/SrB4ALm6vi3EK6FRbAYlsB1UA/qqtEAjaDuJ82wDHQAEO1f UU+UFXADqCNWK6gjU0BMv8tqaAd1MNJvjHXBjaC+BmvgZlgLt8CtYuL1febq4NgN6+F22CCm/0b3 b2J+J9wFd8NmMV/M2uLsP+Vwv7MewpWvnqhzXMD+Ct4Vot+7a7dzTP8lV7xWyJaWIWkZpi9xv9k9 PfLY40+sfk99XR4Ux0tO9PqdyzXQQN5ulrORQbZj5RlJrKHOeSIfXBVaDthuU5X2W8ZdtvNg9Hf/ +pJzxWNpmZlM+Cojdpu5135DutV2UNRzX0XoyyT0vcVO543p+DKK8PWMa9nd3/Bv04njN+jtlfLk 4jOZ8JM9/3foxAnfsl0tWynLqskFK/pSiyk5hK/3ML1nJXP+QyGZUNV9rpPyPOC4yPZfcklBovSH 8n1oHuuYLyPJnv9I0ci4ZffXVyz+/ZQBJg9Fl91af4vyZ6wMNHa1Nrd12nXC2XW6jU32xazLxaH9 xZPlX+U/Xx07z7ny/yP/BVBLAQIUABQAAAAIALVNRi8edBY7HzkAAAAoAQAMAAAAAAAAAAEAIAC2 gQAAAABpc3N1ZSMxNi5kb2NQSwUGAAAAAAEAAQA6AAAASTkAAAAA ------_=_NextPart_001_01C38C23.EECD9F11-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Oct 6 14:26:25 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 OAA15898 for ; Mon, 6 Oct 2003 14:26:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6a3Y-00036c-44 for ipcdn-archive@odin.ietf.org; Mon, 06 Oct 2003 14:26:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96IQ4Bx011932 for ipcdn-archive@odin.ietf.org; Mon, 6 Oct 2003 14:26:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6a3W-00036H-1H; Mon, 06 Oct 2003 14:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6a3J-00035x-7n for ipcdn@optimus.ietf.org; Mon, 06 Oct 2003 14:25:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15871 for ; Mon, 6 Oct 2003 14:25:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6a3G-0001yW-00 for ipcdn@ietf.org; Mon, 06 Oct 2003 14:25:46 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A6a3F-0001yT-00 for ipcdn@ietf.org; Mon, 06 Oct 2003 14:25:46 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h96IPC10017004; Mon, 6 Oct 2003 12:25:12 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Oct 2003 12:25:12 -0600 Message-ID: Thread-Topic: Issue#7 IPCDN RF MIBv2 - already closed - Thread-Index: AcNgJaYn06TBEeT1TRC5N0Q/BVl7hgT3JTZQBRgJoxAABa9pIADpuJMQAAWICSA= From: "Eduardo Cardona" To: "Jean-Francois Mule" , "Ipcdn (E-mail)" , "Richard Woundy" , "DOCSIS OSS Majordomo List" , "DOCSIS 2.0 Majordomo List" Cc: "Bert Wijnen" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Issue#7 IPCDN RF MIBv2 - already closed - 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 everybody, One informational item =20 Last week the IPCDN chairs sent out the list with pending issues, and closed one, In the closed list issue#7 was in original list as 'will not do', with a set of reasons for that (see notes from IPCDN chairs rigth below) We discuss the issue and below are notes for documenting the DEFVAL clause added to docsIfUpChannelPreEqEnable object.=20 Thanks Eduardo + Issue #7: Status: Closed (will be in draft08) (7) docsIfUpChannelPreEqEnable - add DEFVAL clause. Contributor - John Gillis ADC David indicated that a defval is not required (DEFVAL not appropriate here, also too many other items in same table do not have DEFVAL"). # category: "must fix" # Eduardo recommends to add a default value of false for this object. # Action Item: add DEFVAL false in draft 08 Some comments around the Decision of add DEFVAL Clause to object docsIfUpChannelPreEqEnable =20 docsIfUpstreamChannelTable ibjects in RFC=20 =20 docsIfUpChannelId Integer32, docsIfUpChannelFrequency Integer32, docsIfUpChannelWidth Integer32, docsIfUpChannelModulationProfile Unsigned32, docsIfUpChannelSlotSize Unsigned32, docsIfUpChannelTxTimingOffset Unsigned32, docsIfUpChannelRangingBackoffStart Integer32, docsIfUpChannelRangingBackoffEnd Integer32, docsIfUpChannelTxBackoffStart Integer32, docsIfUpChannelTxBackoffEnd Integer32 Additions if RFI Mibv2 docsIfUpChannelScdmaActiveCodes Unsigned32, docsIfUpChannelScdmaCodesPerSlot Integer32, docsIfUpChannelScdmaFrameSize Unsigned32, docsIfUpChannelScdmaHoppingSeed Unsigned32, docsIfUpChannelType DocsisUpstreamType, docsIfUpChannelCloneFrom InterfaceIndexOrZero, docsIfUpChannelUpdate TruthValue, docsIfUpChannelStatus RowStatus, docsIfUpChannelPreEqEnable TruthValue =20 RFC 2670 the table entries were read-write, -dynamic entry created for the agent- In this case for operator definition of new entries in ifTable for type 129 and/or 205=20 as defined in docsIfUpstreamChannelEntry=20 Particularly the objects in this table (RFC 2670) does not define DEFVAL clauses for its objects due its context. Although indications in some object descriptions indicate methodologies for default values, like "verbose" DEFVAL clauses into the DESCRIPTION clause.. See Annex at end In rfimib v2, the inclusion of the clone Mechanism for SCDMA creates modifies the SYNTAX from read-write to read-create, Any new created row does not correspond to existing ifIndex (ifType 129|205) In practice, still mapped entries to ifTable (Agent dynamically created, RowStatus =3D 'active') are "read-write", but the MIB SYNTAX MUST be read-create for RFC-2578, the only objects using the clone mechanism=20 Annex below shows how the Interpretation of not requiring DEFVAL for all objects listed there, expressed for David Raftus in the period comment while updating draft v7. docsIfUpChannelPreEqEnable is intentionally out of the list in the annex to present its characteristics. Object definition=20 docsIfUpChannelPreEqEnable OBJECT-TYPE SYNTAX TruthValue ... DESCRIPTION "At the CMTS, used to enable or disable pre-equalization on the upstream channel represented by this table instance.=20 At the CM, this object is read-only and reflects the status of pre-equalization as represented in the RNG-RSP. Pre-equalization is considered enabled at the CM if a=20 RNG-RSP with pre-equalization data has been received at=20 least once since the last mac reinit." This is a control Object for CMTS and RO status in the CM; The object apply to all Upstream Channels ( active -> real interfaces and cloning process- CMTS only ) Due its characteristics, It could be better associate Pre-Equalizers into the docsIfCmtsModulationTable=20 because: - Modulation Table contains parameters to efficiently offer bandwidth/efficiency vs channel robustness, while UpstreamChannel objects are more in terms of channel frequency and timing characteristics.=20 The modulation table objects are more in the robustness design, like FEC, Scrambler, interleave, Modulation Type. Pre-Equalizers do not compromise bandwidth efficiency, but is a robustness parameter.=20 The Object is not in Modulation table because: - CM does not support docsIfCmtsModulationTable, and that's why it was the desire to be reported by CMs also,=20 - Some sort of flexibility to handle in the CMTS the same Modulation Profile for several channels and turns Equalization enabled/disabled on a channel basis.=20 DEFVAL considerations The recommending was defining a DEFVAL clause for the object, below are some elements taken in the decision - Considering the Object nature as explained above,=20 non DEFVAL style table might not be a strong factor, there is no dependencies in other objects/states for switching enable/disable pre-equalizers. =20 - For CM CM Default value is implicit in the definition of where is enabled at the RNG-RSP time,=20 the DEFVAL clause just makes the initialization clear in the case no Equalization data is received in RNG-RSP, if Equalization data is received the object value is updated as normal objects - For CMTS Cloning mechanism uses also this value at row creation, Will be clean=20 To choose between always enabled and always disabled, it is preferable 'disabled'=20 Match the initialization value in the CM. Dynamic entries are created via CLI configuration tools/ or SNMP without RowStatus set, would be expected CLI commands to mandate pre-equalizer value in the command or default to disabled if not considered. (last one mainly for backward compatibility in CLI tools with previous CMTS where pre-equalizers were not supported or not in MSO lans). =20 Annex : Initial objects in RFC 2670 docsIfUpChannelFrequency OBJECT-TYPE SYNTAX Integer32 (0..1000000000) ... DESCRIPTION "... This object returns 0 if the frequency is undefined or unknown..." docsIfUpChannelWidth OBJECT-TYPE SYNTAX Integer32 (0..20000000) ... DESCRIPTION "... This object returns 0 if the channel width is=20 undefined or unknown..." >> explicit default value docsIfUpChannelModulationProfile OBJECT-TYPE SYNTAX Unsigned32 ... DESCRIPTION "... This object returns 0 if the=20 docsIfCmtsModulationTable entry does not=20 exist or docsIfCmtsModulationTable is empty..." >> Explicit default value docsIfUpChannelSlotSize OBJECT-TYPE SYNTAX Unsigned32 ... DESCRIPTION "... Returns zero if the value is undefined or unknown..." >> Explicit default value docsIfUpChannelTxTimingOffset OBJECT-TYPE SYNTAX Unsigned32 ... DESCRIPTION "..."=20 >> Not explicit default value, it is a measurement value, --implicit zero if unknown ? --=20 =20 docsIfUpChannelRangingBackoffStart OBJECT-TYPE SYNTAX Integer32 (0..16) ... DESCRIPTION "The initial random backoff window to use when retrying Ranging Requests...". >> Random Value, implicit random initialization docsIfUpChannelRangingBackoffEnd OBJECT-TYPE SYNTAX Integer32 (0..16) DESCRIPTION "The final random backoff window to use when retrying Ranging Requests..." >> Random Value, implicit random initialization docsIfUpChannelTxBackoffStart OBJECT-TYPE SYNTAX Integer32 (0..16) ... DESCRIPTION "The initial random backoff window to use when retrying transmissions..." >> Random Value, implicit random initialization docsIfUpChannelTxBackoffEnd OBJECT-TYPE SYNTAX Integer32 (0..16) ... DESCRIPTION "The final random backoff window to use when retrying transmissions..." >> Random Value, implicit random initialization) =20 ------------------------------------------------------------------------ ---- Added Objects in RFI v2 MIB There are tree conditions here: Dynamic entries (RowStatus =3D 'active')=20 1) SCDMA=20 2) non-SCDMA channels and=20 cloning Entry (RowStatus 'createAndWait' -> 'notInService' 3) (CMTS only) for SCDMA channels and optionally if creating non-SCDMA channels=20 docsIfUpChannelScdmaActiveCodes OBJECT-TYPE SYNTAX Unsigned32 (0 | 64..128) ... DESCRIPTION "...Returns zero for Non-SCDMA channel types..." >> Default covers 2) docsIfUpChannelScdmaCodesPerSlot OBJECT-TYPE SYNTAX Integer32(0 | 2..32) ... DESCRIPTION "...Returns zero if the value is undefined, unknown or in case of a TDMA or ATDMA channel..." >> Default covers 1), 2), 3) =20 docsIfUpChannelScdmaFrameSize OBJECT-TYPE SYNTAX Unsigned32 (0..32) ... DESCRIPTION "... This value returns zero for non SCDMA Profiles." >> Default covers 2) docsIfUpChannelScdmaHoppingSeed OBJECT-TYPE ... STATUS current DESCRIPTION "...Returns zero for non-SCDMA channel types..." >> Default covers 2) docsIfUpChannelType OBJECT-TYPE SYNTAX DocsisUpstreamType ... DESCRIPTION "...Given the channel type, other channel attributes can be checked for value validity at the time of entry creation and update." >> Default covers 3) -> based on DocsisUpstreamType TC value 'unknown'=20 e.g. after RowStatus =3D 'createAndWait' docsIfUpChannelCloneFrom OBJECT-TYPE SYNTAX InterfaceIndexOrZero ... DESCRIPTION "This object must contain a value of zero for active upstream rows." >> Default Covers 1), 2)=20 3) Might be covered by InterfaceIndexOrZero TC of unknown value e.g. after RowStatus =3D 'createAndWait' docsIfUpChannelUpdate OBJECT-TYPE SYNTAX TruthValue ... DESCRIPTION "...An SNMP GET of this object always returns FALSE." >> Default covers 1), 2), 3) docsIfUpChannelStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "... 1) Create an inactive row through an SNMP SET using createAndWait(5). Use an ifIndex value outside the operational range of the system. ... 1) This object must contain a value of active(1) for active rows. ... The following restrictions apply to this object: 3) The only possible status change of a row created using createAndWait(5) (ie notInService(2)) is to destroy(6). These temporary rows must never become active. 4) ... Entries with docsIfUpChannelStatus set to active(1) are logically linked to a physical interface..."=20 >> RowStatus description covers 1), 2), 3) _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Oct 7 11:47:25 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 LAA09058 for ; Tue, 7 Oct 2003 11:47:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6u3E-0008Nh-MW for ipcdn-archive@odin.ietf.org; Tue, 07 Oct 2003 11:47:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97Fl4Qd032213 for ipcdn-archive@odin.ietf.org; Tue, 7 Oct 2003 11:47:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6u3A-0008NK-GQ; Tue, 07 Oct 2003 11:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6u2P-0008IN-UF for ipcdn@optimus.ietf.org; Tue, 07 Oct 2003 11:46:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08994 for ; Tue, 7 Oct 2003 11:46:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6u2O-0007ey-00 for ipcdn@ietf.org; Tue, 07 Oct 2003 11:46:12 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A6u2O-0007ed-00 for ipcdn@ietf.org; Tue, 07 Oct 2003 11:46:12 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h97Fje10019168 for ; Tue, 7 Oct 2003 09:45:40 -0600 (MDT) 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_01C38CEA.0F3024CC" Date: Tue, 7 Oct 2003 09:45:40 -0600 Message-ID: X-MS-Has-Attach: yes Thread-Topic: Issue#13 IPCDN RF MIBv2 Thread-Index: AcNgJaYn06TBEeT1TRC5N0Q/BVl7hgT3JTZQBRgJoxAABa9pIADpuJMQAAWICSAAKu36sAABhZuAAABtTGA= From: "Eduardo Cardona" To: "Ipcdn (E-mail)" X-Approved: ondar Subject: [ipcdn] RE: Issue#13 IPCDN RF MIBv2 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_01C38CEA.0F3024CC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI,=20 Third try, Attachment is zipped=20 I appoligy for those who received duplicated copies. Regards Eduardo=20 -----Original Message----- From: Eduardo Cardona=20 Sent: Tuesday, October 07, 2003 9:33 AM To: Jean-Francois Mule; Ipcdn (E-mail); Richard Woundy; DOCSIS OSS Majordomo List; DOCSIS 2.0 Majordomo List Cc: Bert Wijnen Subject: RE: Issue#13 IPCDN RF MIBv2 To All,=20 I got a list-owner message of holding the below email due to very long body message. Here is again only with the attachment Eduardo Hi all,=20 Attached and below are the item actions for issue #13 The attached file is text based to facilitate MIB edits later, of if having formatting difficulties Reading the same text below. Regards=20 Eduardo -------------------------------------------- ------_=_NextPart_001_01C38CEA.0F3024CC Content-Type: application/x-zip-compressed; name="issue#13.zip" Content-Description: issue#13.zip Content-Disposition: attachment; filename="issue#13.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIABFHRy9HpxL5/hYAAC4bAQAMAAAAaXNzdWUjMTMudHh07V3rcxs3kv+8qtL/gNJW na06mbGlJJdz1X1QKMnhnvVYkYqz9w2cAUmsh4PxYEYUs3X/+3Y35kWQnBnKlK0HWIkfYqPRaHT/ 0A004Ddv2n92d/6T9bROBfvru6PdnX7Ck1S/Z5eRCHd3Xr872mfH/j9TnTBPTaNA8tATTAORmIow 0WykYqaG/xQe/NkXWo5D+MpnKkqkCnnQgdb+7g7DjxYRj+FbxtMxNuZIwhI+DIRhk7Up+Mkwa+kr T/dG3Wmib6LuhIehCLoqDRMRD7B1JyPrqjCJ5TBNVKzZG/ZJBgE7T+OZDNm5gh+qgB+wa+lN2Cdo 7c9Z76p7cvFDV009rpODjMu5/CxYP/mbmoQa/hL6OoplOD5gp37KY1+xLv4acvgd+g74UO/u/JV5 MLCxiufv2d4UtTWSd3v482OPRtkDfb0vOCSK6XQ65bH8U7BkIpgvtZdqjZT/wTiLBSgbVOSTipAN 6gcJq6rr4IC1CHWqGfU5FNCSexPQ/3DO3r394d1bBu1EoAX79IGknHAZsxkqZsphmBzmzJPYL+hw d8fYgQRZM7lhaO/22YkYydAIepnP0ThWaYRtDvfZtZiqW/N9Iu4SmDdfemZ21agyrTF0imMCNWVz DKTUbHfn5LTfve5dDXqXF8wLeAoiY9vCEjI7abAEFOgIBTaDQhbHNx/OTy8GvYsPKAD3fdCOp4J0 GvK4HE6lo92dhk4Y9gJqgbEwGD2PUe1aBbfAeSJi0cmkkDqfV5wQEagZNeGahhyLEdCCN2kWKQnM /QN22e/3mI6Ex3gAMwkWGosvqQTuZJuxSNI4ZCKOYSSeAncju7AGwUIFegVfJQ8VPrhgoBXMKgok 7oA7Oig2JKZln2CVWQ+eimPkdMuDVJBSRimYjKdCaDYlCJjJZELjyDr10UakMVfgKkfmS1u/qCyd RpGKUTIipV8G6ASVWSuwAmd+pszsG8WVNoTaXOphgvqFFrdSzHSlB/qF77MzGYOrdD8aLyg8jbSG fgkYlxhTprkecpw9EIqzqYpRSBExsPaYQ2sOHc81qDWDDnYWqyk1Jh8CGwCuIPZr7ABGBYaV4qQY 2wFXiTkqVUsf+JG/GYH/8oZpUDB4skaZvqQCRqvT4RstYIQVv0B18lsuA5I1cyYAM3KeIfdZ/+L8 CliowIj4F5ZrHwnMCCcKNNthFzB+X47IKEkTYPg+Ms0tyQjIoljcSpWSYDnP67PeVA5vD9kM7Z+F AoxDxG1mCwcAHAHFkmLov4FANAjzNU6MCgNgAJQKJJ5maAh6pxEcYCdzhj4Uj7iHrhXQIoTLlNSJ 9HQhKVnHRGmR89Ioc8iGafAZQJ6BrBxHFgErMHWGjGKc/pEM4E8682CtPJkBXFzw5uNxLMa88AEY CtkDZ+F0nJB84xh1YXoJFPeR41SOwZUybYNFhBpMH/QBI86s/rXxNpqo/aK7W0T9IJFRIHLC6upA ov6A8H+XwBphwNxI1YRvOehAj+ozTbQcDYymcfhy9Iehgy98kaD35zIh3sEiLMMUoEBooPenMjQx xQETiddBTwfoQ1dCn+9iUCHuZDIng0QUQN0A8Ei/okmW23ZFxwzdhryq1GamTC3MajRDlWVmDhPP yZZ0oiKY3k7OuUSH4T5jvVHF5feRC7oY/E/ejzGQCAK0FMBnjVpGzEgMlJDWKthBWJJDA7tEG846 16ugxkvjbN49lQa4ZBS4wnqWFyYTnhSLRO7SJSuaJtCQmgKCpRpWb60zl0KiW8Cj3HDxQ1AYBZxC u1jB6EBKpaUJ0GCWlelwKDxamV9nDo4op/ffF3ze0JyudHJcQOYl9LPXoUKfCuCPZNx/ilhpnCQ/ 5qOEvf2ptMKCPaNxZYuT8I1NyKzJfkWKU2PytwjXt9JbArEKaW+0Ku7M58JqyF7/H4gp/P0Do7KF lZb11SiZ4VgrAsNCQa6HPI2CKdKFQGSEwNL9dPgLujdZWQRrBfgOLCks18IvaNCTLLIjdfhV7rDK Xp91cV1HSaJ0GEiN0R9g2zQCQ9rvEDX+fxUIXBZAn5EKSwqcXbQIaJigWChmLG9x5YVvMjuJKrEK BQkQY9K6ZWJPZJ9PBQQBPDDhUEoay5cCVVjpUYdjT0edIU1n7kezybyTja3664lIYHnDwDUcY6gU KzBMHuQkzfEpxwTGz/T9AX/Kuia+3PtwfXlzVUFD+vb3w72KhktBKn9988bqR2NHNrecJONacqmE uous9waoQuKIc1rYJZoMJRuQxviw/A1EDKhqLLI/1+iEB5aQPItoeAQg4xUpVoWL7uyh1IB516dX H4+7p+9JndXoN5OcXf76t9Pu4A0NsOzH/LTP/rXYddm8yyM+lIFZCdYR9eeh18OlByB/LdGN5zfS nPO7PlCAt/d87A4maSVdD8w2RtU1cuyFtwBw/jVYHgD+cQJ6jpL1IzGMG7maxRB44xKHvMW1+FKj HyLPZRgSeDZR58zFuAXrM3Av0ZI2Y3wCC24L6sFPAzkVKq3RWXdqSM+5B04KsNFMeqJmYRa09Ea9 0Bd3jU2KKKdtg+u7KzUTcSMdjA9m5XI0gri8kfj0SwrK+5PcFjXY2OB3zL6aBxdSPlhnFTlpN185 m0lvwmyZpcCykbyP+z7BhZK6WeBz6aG8o0CYLYZmxd0lGwwSqDcYJ/HeaKgn8BOpwV8QRZsHq/w0 oCkfzKNm8l4okswRNqVvZ04fuU5uIoiYm3n/BpHHdbGQtzL1DICPK0F/A+nflb6KFQSC6+XJKLsQ KCQCEaWJshdewuTXoE5Bd8W9zy0IL8SsVHgdfsBs104bfE97lKpmGVP+FYx0Crb4UYR1ZCd5sg4R 4ynYsI+blDX0Z6fdU3SizDtgThuou2DgMxX7IAckVXXEfS8mieO+EH4dISzSv6axTvryz1otfcB9 UpzrJkK051zO/gRXx7BegkLUOqJf54mghRyCZojgT0RUP36L/tdAeZ+bJM9nuclgBt7UmrbL2onr e/6UV4TpJyJqkoXa9CPMJkV8GlKq30ieDkegSoHaX+9BaPFm7a0dZwkDVxjb0k54HaJdJTWLs+nv BpLybLVtjMmKJpVGa4lNABIG3STurTe1CtVAJTxAE1k/ogr1jRZ+a2JYvjbjjutdYwcYLzWNr6Ch /s91oGpwtCC+wYOWDzHHfem2baiDbpiErTuBAW5CnytxA/r7jCPvZkPRNh1NVwUbdVHIBBH9phre oEku1gZNqpJhwHwP6TZpVpFwk2aFlL1QJudchsmmcm7cMJd044YUG29mHlWr3WDuKoa7Wat72Ikl 4iaTtyjmhi3vaTBVce8zg/c2m4rIVtuy6f+Xf+wPjgc3ffPnbDu0/HL9HpbZYque3ZZHkbhNuGYj a5FLvq3VqezFvX//P+xf2bioE/37ITsiieG/T73Bb+/dBpZF6TawVjJ2G1huA2uR3G1graF2G1j1 pG4Da5nEbWC5DayKQbkNLJvabWC5Day6Tp7xBlbZ4kmmmtXs0irwuG+W6Xbu3M5dGz9yO3frxXQ7 dw8Np3kx2twGVgtNV9SmNSLrjwZZH+Vtki4VHjItqOSfKQ8UaiohgeEeCTkRe6aGFf+6Z8YRZ4PA AYywCHxZIv1+d6ef1UQWBe35QMrqvw6WqFYuWphiT0vrRV3tAePm1gaKhzW1SG9uddB9C16W+y0u ZmtWoXxRG/zj6rRiYP+4GBz/Yf6cKeyoUuB4fvzHm+Nu97Tfxzsr3H+D5ftfbZ7drCTXww4PjFa7 57Cy0r2TYmfqAEeOReiYWC4t9mCb0gxMp6RPMO1E4YWgQJpCXWVsCCwzwQSHBWoM5hdYfDxjLR12 Rldx8t5guGOK/JGHNoXjdAsi79ZiUynPBCmGmFlmtd3YikZnKuxxZodpklWGLxtAtgMU4I0hT8hb gYX2MPXSFHwfHbKhTPJqZNCQ1bzVimOqytF9vCD1zR0ii8+Qe5+pSB6mgnbO58Yz8BrK7Tt0WD4G GTrMNnyLT1s3WDB8i0edGywQnixeWshRpGhPjukZM2ceDw0I2DOZAP9FS8xvNJhR+0wTHBo1ArnC wmiLSyKngqrgM9AzN/kylCklslrJUeaE1ZHMcfehvDeYXVnBwNjsIa9D5VVoeBomMV4ozHG6VTD6 3KAjFl9SoZMKhNCdt+wuHRlJW9AYFBaVOxNMOt7JLFgjy95N951tZRpv2BrM4mwYK+5jIkeLId4F or/0eyc5irWR46sgYkWEacOExQdH1hYmrKbffLVcaOVgoiVMvKuBiaXU4vmjREpbcuZG2VZQohJu LACGxQfho02AUYQOSyOhQMLfBkwsZ5RbRIkqLtiOsglKVHDB9lqHEltHicMalFjaSnj+KFGbjlRA w2KUQYi9pDfBxQpvawsXC/mIDV15dvKw+YhDEYciGYoctUxJym2+5woldAv+W+YmhxaHR52bVLZ5 M8ywDbayqeHyk2eNGT+2y09eHGR8XaLSKkVZiRsbpChlUmIxqUUL29A2OU5yaPHC0eKndnnKi0OL hoTFYmJDSTvwsJgsQ0kL8LB9f/VxSnPCYvH5uvTFAYwDmBxgfm6TwljH/s8NYzJamFR8JS2kFwZb 5DIWlxbYsgQhR7bFPdosxjKBpd2F5cPZBuCw0XXt4WwNcFg81h/OOuDYOnD8V4s85kXjxtqEZnPc aL+JevQNzlw2S2gccDjgWACOX1qkNC8aONbnNvY8r9omqcERq3ndNkkNjiwJUV8qtiq3MR+L0RYw p12Bs8OcBSYvAXP+uwZzlkoNW6PNzz8+LrTJkKKNm6vVdaYFeFg8ztRGdaYV8LDNZLM606ZQZTFS +fnHjVOcVUWmxeO6Q1t67nkCMrQMExvLSksft32/fVnpIhjY7uOg4Wuh4bCurHRlieGThYeGHdZn Wll6D1BYV1a6bWBY9ub7AIPFxcUMWwKGukLSVUWFzx8Xnlct6T2AYU0hqQsY8s9LwIW60tFVZYLP HxeeXvWoxWOjw1iDGxaHyk5Fm4riEjcsPgZFNsUNGy3c/bVHiBt1xaJr6wWfK3g853rRr8w47OoM F13kn5eAEnXloevKBF8ISDypClFsaTHaXvLhIOIlQ0RdTei6Qr8XAhEvqizUYvIVpx+LkGK71CLA tIQUi0mL81FXBfr9IKWuCrSmCvCJokr2I9uRN6v+3Fpm8g1rQJcgokVZxSYVoJvDxIrd3o1gwt13 xc+3gom6ms/1JX8vACW+UWqyBBWPLDVxEPHiIaKuunN9hd5zS0+kK/Bk2waZdcWdC7Bisdn8KMWV ZtDncYNMUc5Z/LtLjaV97ilR95ToAzwl6jzYPebpSi63e9X0QR7Yco7qntN0JZCP/zlN56fuQcsX WZL4zB60dH7snpR0JYJLcmwtQv4mbzg5r3WPOr6ckj2LSa2/Ps5HHZ2/umcVXf3cBmGzxecJPKvo XNw9bLilY2j3sGHLmpVKRtzCdW18c478dY7sHhps8GP30OC3fWjQObJ7+M/VhZVe/hIf/nMY4B7i W+/97iG+7/oQn3NO9xSeq8tqcf2r2S23/RSec033GJ2rxHqMj9E5z3TPwbnn4OjzxJ6Dc57rHmRz 1Var5NhO3Lut15acn7on0dyTaAuMthcCOyf9vk7qHiVzRVXIyWLyOB4lc07tngVr9uvsR7YruWfB agNka+6do1Y/38pR3cNcm9ZGuYe5Kh/npN/CSd3TWPiRrgSKPYmnsZybf8XjVNdiqm4FG4i7hO3V /COxMGrIFlU8x46G++z69Orjcfe07t7Ck66MXAh1bcNuiqlXRdFL6FJZscGXNdkRhMXgDOJWoM0q LJQKAmUMBwx/OWu9uPn4kWJpFIWzw85bWwQ2m0hvYooJuZcUWbAtzrqqxpqE6nyVbrZXuVj3TxaX 1uic/37OX3dXATO0DzEHav9J+3AaUrJpaXhsRta+tNEOQmMx5rEfwIqEndCiy5J5BI51Yzpc0QWP l+oayb/BPo2DFit0kT4PwbZm0gc/wUQ6nK8ZznImXaLPb2oGWLLoPb4Sq96tzxzWCjJioUUMET8h 1AGm8DQ0TcswYNVS/i1QeDJNMPyp4KEMx+xVqGBsr2ovUViM1iLPsnEWj4GsHtFmlxhtJg6DHg6D Wr0g8jyvV2ywP7cYS1h8avfn1m/E2dLUbMvVXWW02LSLGuza6Qe5fOzc9uHcts0TIs/daxd362pu ReA9iCWfLTL64lZEwW8hYrBiBNtIJms36MC2SpFMgEIjxiiie24vtU1D+HrHXzQL5/dP0u8bDs7v k/I/rp3Al5nyL5+p1e/nbHVL3vnrw/lrw5n4V2T5j8ttXZb/iLP8RXSx+KzGmnUZ/pYK5RzkPBzk NJzu3zepfyIHhk89qb/HBZGVGf2Wroc4R304R2044b9nGv/k/PTFpvH3cPVVOfyWTuydpz+cpy/8 C1TutP5Zpe6P6bTeuac7h3cZujuHlw9zDu/wxJ2puzP173qm7lzQnY+7xPppn487H3Zn3e6s+/uc dTvfc+fWLit259blx8GHO4MuPi4JLv3OYvP9zqCd07nzZJf2PrXzZOe1G54N7+4c7bMT4cl8vo5v PpyfXgx6Fx8wquI+bjt4KkinIY/ZZYTKAFMwMRvp1/b8amcDep8AeyGTSVQkPTYDnfgwulTjCEI2 VsqHNUtE+WzJyPNDFkgwUtQvGNPcEO3uoEpiOUxRDM1mIsYp8cUBe01bIoFIBBNTLgM0WpMbst5V 9+QCaIcsgrnbBy4DBSFgmLl3KIrJVRpnPhC3nIBhikRgnygwecs1BsSfYGj+HLic8zk7essO3749 OjBbMNnLEPDdXq6pvXxQsJZ6sYxyY8oVSHzx+3gkp3J4e4jKon6+pIqyY/hOA2nW7vqsyw5/+fmI HXXedd79wvaOwW/ImDQ7TzWtc/8bqlkIJvFpgvoBI4dhh/isCy+jbJDVVF7wwh0iEYN5AyXgxhRZ Idnujgx1AvpAgyNhsnD9teiMO1l2HvEYFvs0AAvJLBJ+N3OfMwe63Z2EfiTuAO3Q3HAqzM/FFGTh cTCnfyWEHZO8E34rwldJObFkGyvdEiczmZsoBP+e9zpKQ9JcB7XaC2HQ0ymPs16MVgh4IJ2IFKEQ zKKIY5AKcoN+6k0uabSvYDyV0hS0QyNTgNnPZ9R3to3BJH6BhmMERDUxlbvN4pf7RitZTz3Ssyeo L5r1CNxyJMEGYjXLR1oKgbMDEy99GtxxSBgEIxnBpOODJZGSYZKj9GW/3yOGRNyXSCBQ4eYbsLyc Mz4QKGORmX7WNv+pSb6K4cD0ZWaMdCMVBGqGedVrMnoMzgAoQ7Bl0iu5zytdGDbYwf57FKdAlVIM ctxjQJI7dgzwlIBHQ5Pz3q/suiIfex0qsFnc+9knlNm7LCCqAw3BfnxlcN6bKFw5YZKKOUDtoxLL H5QKxlPI3ghMO2dBzfVi+5L8oDo35zf9AbphQSgMcuVrMixoKvZRT5nJ4LAoZpdkq2xVxyjoQufg NZXuCyenzi8uB6zqthrMK5cOEZWIFmzecONRFKsopjbkBT+IO08YzALk9WVh0p0DkGiBLxoGLc6H 3j6uR6A/sj4vADtjxbtS4g6MkNZCAf4tFcFOaZ5kr4qBLsBAEC10Lt+riYK/vSp3/Xigjfp6p4Mz DHQU6MXnRoXYf1dhDpMfbe/unOVQSx0Z9wCvupViZpZlQifqjjAEVrKxoDgH0ykacChM6rO7o6NA GmWakIDmRKtRMsMwrZz62Gx/KhglFrNpsPHxJEE1BAoI09B4ONgHPsgZQD4F6tDknxSrwISAVNPc 4WE+cEi3ZTBDUps3fXAtFSF0hJ5JyAzQhi8YxSMO/GBlo6BBI/poAGwjWiF0FrSBYXby2ICZ3/4N UEsBAhQAFAAAAAgAEUdHL0enEvn+FgAALhsBAAwAAAAAAAAAAQAgALaBAAAAAGlzc3VlIzEzLnR4 dFBLBQYAAAAAAQABADoAAAAoFwAAAAA= ------_=_NextPart_001_01C38CEA.0F3024CC-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Oct 7 12:21:25 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 MAA10465 for ; Tue, 7 Oct 2003 12:21:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6ua7-0001do-LY for ipcdn-archive@odin.ietf.org; Tue, 07 Oct 2003 12:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97GL36x006296 for ipcdn-archive@odin.ietf.org; Tue, 7 Oct 2003 12:21:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6ua6-0001d4-K8; Tue, 07 Oct 2003 12:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tII-0005OK-Ep for ipcdn@optimus.ietf.org; Tue, 07 Oct 2003 10:58:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05332 for ; Tue, 7 Oct 2003 10:58:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6tIF-0006aH-00 for ipcdn@ietf.org; Tue, 07 Oct 2003 10:58:31 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A6tID-0006Z4-00 for ipcdn@ietf.org; Tue, 07 Oct 2003 10:58:29 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h97Evp12014248; Tue, 7 Oct 2003 08:57:53 -0600 (MDT) 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_01C38CE3.61DFCDD3" Date: Tue, 7 Oct 2003 08:57:52 -0600 Message-ID: X-MS-Has-Attach: yes Thread-Topic: Issue#13 IPCDN RF MIBv2 Thread-Index: AcNgJaYn06TBEeT1TRC5N0Q/BVl7hgT3JTZQBRgJoxAABa9pIADpuJMQAAWICSAAKu36sA== From: "Eduardo Cardona" To: "Jean-Francois Mule" , "Ipcdn (E-mail)" , "Richard Woundy" , "DOCSIS OSS Majordomo List" , "DOCSIS 2.0 Majordomo List" Cc: "Bert Wijnen" X-Approved: ondar Subject: [ipcdn] RE: Issue#13 IPCDN RF MIBv2 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_01C38CE3.61DFCDD3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 Attached and below are the item actions for issue #13 The attached file is text based to facilitate MIB edits later, of if having formatting difficulties Reading the same text below. Regards=20 Eduardo -------------------------------------------- + Issue #13 Status: Open (13) Adjust compliance statements for objects designated optional. Add separate augmentation table for optional objects in docsIfCmtsUpChannelCounterTable. Contributors - Will Murwin Motorola, Rich Woundy IPCDN/Comcast, Mike StJohns Mindspring, Eduardo Cardona Cablelabs # category: "must fix" # Action Item: Eduardo to summarize the discussion & a recommendation # for the augmentation. Consensus must be reached by 10/10 or else WG # chair will make a decision. Issue item Actions 1) Define the Optional group 2) Remove the text indication of optional or mandatory object in the=20 DESCRIPTION clause of objects in table docsIfCmtsUpChannelCounterTable 3) Decision of AUGMENTING or added columnar Optional objects in=20 docsIfCmtsUpChannelCounterTable=20 1) and 2) are resolved here. 3) is discussed below and as the references pointed, OSSI spec already requires return error codes for Optional object not implemented. Also it is expected for=20 OSSI spec to return correct values in full conformance with the object definition if the optional objects are supported. =20 The decision of separate in two tables the mandatory and optional objects has two views. =20 =20 a) First CL will recommend not to split the table based on a more deep overall analysis=20 From the item 3) notes (end of document) and extra considerations. - switches to query sub-sets of objects are available in the case of bad SNMP tool=20 support of table holes. Not different to handle implementations previous to=20 RFImibv2 where neither the mandatory and optional objects are present. - Hole cases are not only a problem for this table, many interface related statistics=20 has those problems when bulking data to perform later on filters and association or=20 aggregation - From a nmgt integrator data loaders migth handle transparently tables ( with holes)=20 vs multiple tables augmentations and/or extensions - docsIfCmtsUpChannelCounterTable requires hooks to ifTable, and ifXTable to detect=20 discontinuities, adminStatus, etc. Therefore The Complexity of the data validation in the aggregation side of data loader migth see the whole table as a not stopper. =20 =20 b) If based on a) there are more compelling reasons to still require the table split Only stoppers to split the table currently could be=20 Implementations that already support the table and in some business cases the vendor=20 will place strong opposition to do that because (either items): - The optional objects are fully supported (no filled with zeros as draft 05 requires=20 and corrected in this draft) - Extensive device implementations - If optional objects in current implementation (Zeroed), will not implement Software=20 versions in place for or after CW28 ( where potentialy draft 08 might be required=20 if RFC is not published promptly).=20 =20 Please respond promptly to the list or in private to vendor preferences to reach consensus=20 in this final resolution either to support 3.a or 3.b and reasons why. =20 =20 Detail changes proposal =20 1) Define the Optional group a) Add after Group Clause "GROUP docsIfCmtsGroupV2" =20 =20 -- Optional groups GROUP docsIfCmtsOptionalGroupV2 DESCRIPTION "This group is optional for Cable Modem Termination Systems, and not applicable for Cable Modems." b) REPLACE:=20 docsIfCmtsGroupV2 OBJECT-GROUP OBJECTS { docsIfCmtsCapabilities, docsIfCmtsSyncInterval, docsIfCmtsUcdInterval, docsIfCmtsMaxServiceIds, -- docsIfCmtsInsertionInterval, docsIfCmtsInvitedRangingAttempts, docsIfCmtsInsertInterval, docsIfCmtsStatusInvalidRangeReqs, docsIfCmtsStatusRangingAborteds, docsIfCmtsStatusInvalidRegReqs, docsIfCmtsStatusFailedRegReqs, docsIfCmtsStatusInvalidDataReqs, docsIfCmtsStatusT5Timeouts, docsIfCmtsCmStatusMacAddress, docsIfCmtsCmStatusDownChannelIfIndex, docsIfCmtsCmStatusUpChannelIfIndex, docsIfCmtsCmStatusRxPower, docsIfCmtsCmStatusTimingOffset, docsIfCmtsCmStatusEqualizationData, docsIfCmtsCmStatusValue, docsIfCmtsCmStatusUnerroreds, docsIfCmtsCmStatusCorrecteds, docsIfCmtsCmStatusUncorrectables, docsIfCmtsCmStatusSignalNoise, docsIfCmtsCmStatusMicroreflections, docsIfCmtsCmStatusExtUnerroreds, docsIfCmtsCmStatusExtCorrecteds, docsIfCmtsCmStatusExtUncorrectables, docsIfCmtsCmStatusDocsisRegMode, docsIfCmtsCmStatusModulationType, docsIfCmtsCmStatusInetAddressType, docsIfCmtsCmStatusInetAddress, docsIfCmtsCmStatusValueLastUpdate, docsIfCmtsCmStatusHighResolutionTimingOffset, docsIfCmtsServiceAdminStatus, docsIfCmtsServiceQosProfile, docsIfCmtsServiceCreateTime, docsIfCmtsServiceInOctets, docsIfCmtsServiceInPackets, docsIfCmtsServiceNewCmStatusIndex, docsIfCmtsModType, docsIfCmtsModControl, docsIfCmtsModPreambleLen, docsIfCmtsModDifferentialEncoding, docsIfCmtsModFECErrorCorrection, docsIfCmtsModFECCodewordLength, docsIfCmtsModScramblerSeed, docsIfCmtsModMaxBurstSize, docsIfCmtsModGuardTimeSize, docsIfCmtsModLastCodewordShortened, docsIfCmtsModScrambler, docsIfCmtsModByteInterleaverDepth, docsIfCmtsModByteInterleaverBlockSize, docsIfCmtsModPreambleType, docsIfCmtsModTcmErrorCorrectionOn, docsIfCmtsModScdmaInterleaverStepSize, docsIfCmtsModScdmaSpreaderEnable, docsIfCmtsModScdmaSubframeCodes, docsIfCmtsModChannelType, docsIfCmtsQosProfilePermissions, docsIfCmtsCmPtr, docsIfCmtsChannelUtilizationInterval, docsIfCmtsChannelUtUtilization, docsIfCmtsDownChnlCtrId, docsIfCmtsDownChnlCtrTotalBytes, docsIfCmtsDownChnlCtrUsedBytes, docsIfCmtsDownChnlCtrExtTotalBytes, docsIfCmtsDownChnlCtrExtUsedBytes, docsIfCmtsUpChnlCtrId, docsIfCmtsUpChnlCtrTotalMslots, docsIfCmtsUpChnlCtrUcastGrantedMslots, docsIfCmtsUpChnlCtrTotalCntnMslots, docsIfCmtsUpChnlCtrUsedCntnMslots, docsIfCmtsUpChnlCtrExtTotalMslots, docsIfCmtsUpChnlCtrExtUcastGrantedMslots, docsIfCmtsUpChnlCtrExtTotalCntnMslots, docsIfCmtsUpChnlCtrExtUsedCntnMslots, docsIfCmtsUpChnlCtrCollCntnMslots, docsIfCmtsUpChnlCtrTotalCntnReqMslots, docsIfCmtsUpChnlCtrUsedCntnReqMslots, docsIfCmtsUpChnlCtrCollCntnReqMslots, docsIfCmtsUpChnlCtrTotalCntnReqDataMslots, docsIfCmtsUpChnlCtrUsedCntnReqDataMslots, docsIfCmtsUpChnlCtrCollCntnReqDataMslots, docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots, docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots, docsIfCmtsUpChnlCtrCollCntnInitMaintMslots, docsIfCmtsUpChnlCtrExtCollCntnMslots, docsIfCmtsUpChnlCtrExtTotalCntnReqMslots, docsIfCmtsUpChnlCtrExtUsedCntnReqMslots, docsIfCmtsUpChnlCtrExtCollCntnReqMslots, docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots, docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots, docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots, docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots, docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots, docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots } STATUS current DESCRIPTION "Group of objects implemented in Cable Modem Termination Systems." ::=3D { docsIfGroupsV2 3 } =20 WITH: docsIfCmtsGroupV2 OBJECT-GROUP OBJECTS { docsIfCmtsCapabilities, docsIfCmtsSyncInterval, docsIfCmtsUcdInterval, docsIfCmtsMaxServiceIds, -- docsIfCmtsInsertionInterval, docsIfCmtsInvitedRangingAttempts, docsIfCmtsInsertInterval, docsIfCmtsStatusInvalidRangeReqs, docsIfCmtsStatusRangingAborteds, docsIfCmtsStatusInvalidRegReqs, docsIfCmtsStatusFailedRegReqs, docsIfCmtsStatusInvalidDataReqs, docsIfCmtsStatusT5Timeouts, docsIfCmtsCmStatusMacAddress, docsIfCmtsCmStatusDownChannelIfIndex, docsIfCmtsCmStatusUpChannelIfIndex, docsIfCmtsCmStatusRxPower, docsIfCmtsCmStatusTimingOffset, docsIfCmtsCmStatusEqualizationData, docsIfCmtsCmStatusValue, docsIfCmtsCmStatusUnerroreds, docsIfCmtsCmStatusCorrecteds, docsIfCmtsCmStatusUncorrectables, docsIfCmtsCmStatusSignalNoise, docsIfCmtsCmStatusMicroreflections, docsIfCmtsCmStatusExtUnerroreds, docsIfCmtsCmStatusExtCorrecteds, docsIfCmtsCmStatusExtUncorrectables, docsIfCmtsCmStatusDocsisRegMode, docsIfCmtsCmStatusModulationType, docsIfCmtsCmStatusInetAddressType, docsIfCmtsCmStatusInetAddress, docsIfCmtsCmStatusValueLastUpdate, docsIfCmtsCmStatusHighResolutionTimingOffset, docsIfCmtsServiceAdminStatus, docsIfCmtsServiceQosProfile, docsIfCmtsServiceCreateTime, docsIfCmtsServiceInOctets, docsIfCmtsServiceInPackets, docsIfCmtsServiceNewCmStatusIndex, docsIfCmtsModType, docsIfCmtsModControl, docsIfCmtsModPreambleLen, docsIfCmtsModDifferentialEncoding, docsIfCmtsModFECErrorCorrection, docsIfCmtsModFECCodewordLength, docsIfCmtsModScramblerSeed, docsIfCmtsModMaxBurstSize, docsIfCmtsModGuardTimeSize, docsIfCmtsModLastCodewordShortened, docsIfCmtsModScrambler, docsIfCmtsModByteInterleaverDepth, docsIfCmtsModByteInterleaverBlockSize, docsIfCmtsModPreambleType, docsIfCmtsModTcmErrorCorrectionOn, docsIfCmtsModScdmaInterleaverStepSize, docsIfCmtsModScdmaSpreaderEnable, docsIfCmtsModScdmaSubframeCodes, docsIfCmtsModChannelType, docsIfCmtsQosProfilePermissions, docsIfCmtsCmPtr, docsIfCmtsChannelUtilizationInterval, docsIfCmtsChannelUtUtilization, docsIfCmtsDownChnlCtrId, docsIfCmtsDownChnlCtrTotalBytes, docsIfCmtsDownChnlCtrUsedBytes, docsIfCmtsDownChnlCtrExtTotalBytes, docsIfCmtsDownChnlCtrExtUsedBytes, docsIfCmtsUpChnlCtrId, docsIfCmtsUpChnlCtrTotalMslots, docsIfCmtsUpChnlCtrUcastGrantedMslots, docsIfCmtsUpChnlCtrTotalCntnMslots, docsIfCmtsUpChnlCtrUsedCntnMslots, docsIfCmtsUpChnlCtrExtTotalMslots, docsIfCmtsUpChnlCtrExtUcastGrantedMslots, docsIfCmtsUpChnlCtrExtTotalCntnMslots, docsIfCmtsUpChnlCtrExtUsedCntnMslots } STATUS current DESCRIPTION "Group of objects implemented in Cable Modem Termination Systems." ::=3D { docsIfGroupsV2 3 } docsIfCmtsOptionalGroupV2 OBJECT-GROUP OBJECTS { docsIfCmtsUpChnlCtrCollCntnMslots, docsIfCmtsUpChnlCtrTotalCntnReqMslots, docsIfCmtsUpChnlCtrUsedCntnReqMslots, docsIfCmtsUpChnlCtrCollCntnReqMslots, docsIfCmtsUpChnlCtrTotalCntnReqDataMslots, docsIfCmtsUpChnlCtrUsedCntnReqDataMslots, docsIfCmtsUpChnlCtrCollCntnReqDataMslots, docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots, docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots, docsIfCmtsUpChnlCtrCollCntnInitMaintMslots, docsIfCmtsUpChnlCtrExtCollCntnMslots, docsIfCmtsUpChnlCtrExtTotalCntnReqMslots, docsIfCmtsUpChnlCtrExtUsedCntnReqMslots, docsIfCmtsUpChnlCtrExtCollCntnReqMslots, docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots, docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots, docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots, docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots, docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots, docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots } STATUS current DESCRIPTION "Group of objects implemented optionaly in Cable Modem=20 Termination Systems." ::=3D { docsIfGroupsV2 4 } 2) Remove the text indication of optional or mandatory object in the=20 DESCRIPTION clause of objects in table docsIfCmtsUpChannelCounterTable Change several occurences of "the the" with "the" remove text from DESCRIPTION clauses: Support for this object is optional. If the object is not supported, a value of zero is returned. a) REPLACE: docsIfCmtsUpChnlCtrCollCntnMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention minislots subjected to collisions on the upstream logical channel. For contention regions, these are the minislots applicable to bursts that the CMTS detected, but could not correctly receive. This is the 32 bit version of docsIfCmtsUpChnlCtrExtCollCntnMslots, and is included for back compatibility with SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 10 } docsIfCmtsUpChnlCtrTotalCntnReqMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request minislots defined for this upstream logical channel. This count includes all minislots for IUC1 assigned to a broadcast or multicast SID on the logical channel. This is the 32 bit version of docsIfCmtsUpChnlCtrExtTotalCntnReqMslots, and is included for back compatibility with SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 11 } docsIfCmtsUpChnlCtrUsedCntnReqMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request minislots utilized on this upstream logical channel. This count includes all contention minislots for IUC1 applicable to bursts that the CMTS correctly received. This is the 32 bit version of docsIfCmtsUpChnlCtrExtUsedCntnReqMslots, and is included for back compatibility with SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 12 } docsIfCmtsUpChnlCtrCollCntnReqMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request minislots subjected to collisions on this upstream logical channel. This includes all contention minislots for IUC1 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 32 bit version of docsIfCmtsUpChnlCtrExtCollCntnReqMslots, and is included for back compatibility with SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 13 } docsIfCmtsUpChnlCtrTotalCntnReqDataMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request data minislots defined for this upstream logical channel. This count includes all minislots for IUC2 assigned to a broadcast or multicast SID on the logical channel. This is the 32 bit version of docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots, and is included for back compatibility with SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 14 } docsIfCmtsUpChnlCtrUsedCntnReqDataMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request data minislots utilized on this upstream logical channel. This includes all contention minislots for IUC2 applicable to bursts that the CMTS correctly received. This is the 32 bit version of=20 docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots, and is included for back compatibility with SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 15 } docsIfCmtsUpChnlCtrCollCntnReqDataMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request data minislots subjected to collisions on this upstream logical channel. This includes all contention minislots for IUC2 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 32 bit version of docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots, and is included for back compatibility with SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 16 } docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention initial maintenance minislots defined for this upstream logical channel. This includes all minislots for IUC3 assigned to a broadcast or multicast SID on the logical channel. This is the 32 bit version of docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots, and is included for back compatibility with SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 17 } docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention initial maintenance minislots utilized on this upstream logical channel. This includes all contention minislots for IUC3 applicable to bursts that the CMTS correctly received. This is the 32 bit version of=20 docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots, and is included for back compatibility with SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 18 } docsIfCmtsUpChnlCtrCollCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention initial maintenance minislots subjected to collisions on this upstream logical channel. This includes all contention minislots for IUC3 applicable to bursts that the CMTS detected, but could not correctly receive. =20 This is the 32 bit version of=20 docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots, and is included for back compatibility with SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 19 } docsIfCmtsUpChnlCtrExtCollCntnMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of collision contention minislots on the upstream logical channel. For contention regions, these are the minislots applicable to bursts that the CMTS detected, but could not correctly receive. This is the 64 bit version of docsIfCmtsUpChnlCtrCollCntnMslots, and will not be accessible to SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 20 } docsIfCmtsUpChnlCtrExtTotalCntnReqMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request minislots defined for this upstream logical channel. This count includes all minislots for IUC1 assigned to a broadcast or multicast SID on the logical channel. This is the 64 bit version of docsIfCmtsUpChnlCtrTotalCntnReqMslots, and will not be accessible to SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 21 } docsIfCmtsUpChnlCtrExtUsedCntnReqMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request minislots utilized on this upstream logical channel. This count includes all contention minislots for IUC1 applicable to bursts that the CMTS correctly received. This is the 64 bit version of docsIfCmtsUpChnlCtrUsedCntnReqMslots, and will not be accessible to SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 22 } docsIfCmtsUpChnlCtrExtCollCntnReqMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request minislots subjected to collisions on this upstream logical channel. This includes all contention minislots for IUC1 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 64 bit version of docsIfCmtsUpChnlCtrCollCntnReqMslots, and will not be accessible to SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 23 } docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request data minislots defined for this upstream logical channel. This count includes all minislots for IUC2 assigned to a broadcast or multicast SID on the logical channel. This is the 64 bit version of docsIfCmtsUpChnlCtrTotalCntnReqDataMslots, and will not be accessible to SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 24 } docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request data minislots utilized on this upstream logical channel. This includes all contention minislots for IUC2 applicable to bursts that the CMTS correctly received. =20 This is the 64 bit version of docsIfCmtsUpChnlCtrUsedCntnReqDataMslots, and will not be accessible to SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 25 } docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request data minislots subjected to collisions on this upstream logical channel. This includes all contention minislots for IUC2 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 64 bit version of docsIfCmtsUpChnlCtrCollCntnReqDataMslots, and will not be accessible to SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 26 } docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of initial maintenance minislots defined for this upstream logical channel. This count includes all minislots for IUC3 assigned to a broadcast or multicast SID on the logical channel. This is the 64 bit version of=20 docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots, and will not be accessible to SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 27 } docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of initial maintenance minislots utilized on this upstream logical channel. This includes all contention minislots for IUC3 applicable to bursts that the CMTS correctly received. =20 This is the 64 bit version of docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots, and will not be accessible to SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 28 } docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention initial maintenance minislots subjected to collisions on this upstream logical channel. This includes all contention minislots for IUC3 applicable to bursts that the CMTS detected, but could not correctly receive. =20 This is the 64 bit version of docsIfCmtsUpChnlCtrCollCntnInitMaintMslots, and will not be accessible to SNMPv1 managers. Support for this object is optional. If the object is not supported, a value of zero is returned. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 29 } WITH: docsIfCmtsUpChnlCtrCollCntnMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention minislots subjected to collisions on the upstream logical channel. For contention regions, these are the minislots applicable to bursts that the CMTS detected, but could not correctly receive. This is the 32 bit version of docsIfCmtsUpChnlCtrExtCollCntnMslots, and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 10 } docsIfCmtsUpChnlCtrTotalCntnReqMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request minislots defined for this upstream logical channel. This count includes all minislots for IUC1 assigned to a broadcast or multicast SID on the logical channel. This is the 32 bit version of docsIfCmtsUpChnlCtrExtTotalCntnReqMslots, and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 11 } docsIfCmtsUpChnlCtrUsedCntnReqMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request minislots utilized on this upstream logical channel. This count includes all contention minislots for IUC1 applicable to bursts that the CMTS correctly received. This is the 32 bit version of docsIfCmtsUpChnlCtrExtUsedCntnReqMslots, and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 12 } docsIfCmtsUpChnlCtrCollCntnReqMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request minislots subjected to collisions on this upstream logical channel. This includes all contention minislots for IUC1 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 32 bit version of docsIfCmtsUpChnlCtrExtCollCntnReqMslots, and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 13 } docsIfCmtsUpChnlCtrTotalCntnReqDataMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request data minislots defined for this upstream logical channel. This count includes all minislots for IUC2 assigned to a broadcast or multicast SID on the logical channel. This is the 32 bit version of docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots, and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 14 } docsIfCmtsUpChnlCtrUsedCntnReqDataMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request data minislots utilized on this upstream logical channel. This includes all contention minislots for IUC2 applicable to bursts that the CMTS correctly received. This is the 32 bit version of=20 docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots, and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 15 } docsIfCmtsUpChnlCtrCollCntnReqDataMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request data minislots subjected to collisions on this upstream logical channel. This includes all contention minislots for IUC2 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 32 bit version of docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots, and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 16 } docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention initial maintenance minislots defined for this upstream logical channel. This includes all minislots for IUC3 assigned to a broadcast or multicast SID on the logical channel. This is the 32 bit version of docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots, and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 17 } docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention initial maintenance minislots utilized on this upstream logical channel. This includes all contention minislots for IUC3 applicable to bursts that the CMTS correctly received. This is the 32 bit version of=20 docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots, and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 18 } docsIfCmtsUpChnlCtrCollCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention initial maintenance minislots subjected to collisions on this upstream logical channel. This includes all contention minislots for IUC3 applicable to bursts that the CMTS detected, but could not correctly receive. =20 This is the 32 bit version of=20 docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots, and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 19 } docsIfCmtsUpChnlCtrExtCollCntnMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of collision contention minislots on the upstream logical channel. For contention regions, these are the minislots applicable to bursts that the CMTS detected, but could not correctly receive. This is the 64 bit version of docsIfCmtsUpChnlCtrCollCntnMslots, and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 20 } docsIfCmtsUpChnlCtrExtTotalCntnReqMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request minislots defined for this upstream logical channel. This count includes all minislots for IUC1 assigned to a broadcast or multicast SID on the logical channel. This is the 64 bit version of docsIfCmtsUpChnlCtrTotalCntnReqMslots, and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 21 } docsIfCmtsUpChnlCtrExtUsedCntnReqMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request minislots utilized on this upstream logical channel. This count includes all contention minislots for IUC1 applicable to bursts that the CMTS correctly received. This is the 64 bit version of docsIfCmtsUpChnlCtrUsedCntnReqMslots, and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 22 } docsIfCmtsUpChnlCtrExtCollCntnReqMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request minislots subjected to collisions on this upstream logical channel. This includes all contention minislots for IUC1 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 64 bit version of docsIfCmtsUpChnlCtrCollCntnReqMslots, and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 23 } docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request data minislots defined for this upstream logical channel. This count includes all minislots for IUC2 assigned to a broadcast or multicast SID on the logical channel. This is the 64 bit version of docsIfCmtsUpChnlCtrTotalCntnReqDataMslots, and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 24 } docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request data minislots utilized on this upstream logical channel. This includes all contention minislots for IUC2 applicable to bursts that the CMTS correctly received. =20 This is the 64 bit version of docsIfCmtsUpChnlCtrUsedCntnReqDataMslots, and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 25 } docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request data minislots subjected to collisions on this upstream logical channel. This includes all contention minislots for IUC2 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 64 bit version of docsIfCmtsUpChnlCtrCollCntnReqDataMslots, and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 26 } docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of initial maintenance minislots defined for this upstream logical channel. This count includes all minislots for IUC3 assigned to a broadcast or multicast SID on the logical channel. This is the 64 bit version of=20 docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots, and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 27 } docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of initial maintenance minislots utilized on this upstream logical channel. This includes all contention minislots for IUC3 applicable to bursts that the CMTS correctly received. =20 This is the 64 bit version of docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots, and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 28 } docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention initial maintenance minislots subjected to collisions on this upstream logical channel. This includes all contention minislots for IUC3 applicable to bursts that the CMTS detected, but could not correctly receive. =20 This is the 64 bit version of docsIfCmtsUpChnlCtrCollCntnInitMaintMslots, and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 29 } Remove Text "Support for this object is mandatory." b) REPLACE docsIfCmtsUpChnlCtrTotalMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of all minislots defined for this upstream logical channel. This count includes all IUCs and SIDs, even those allocated to the NULL SID for a 2.0 logical channel which is inactive. This is the 32 bit version of docsIfCmtsUpChnlCtrExtTotalMslots and is included for back compatibility with SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 2 } docsIfCmtsUpChnlCtrUcastGrantedMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of unicast granted minislots on the upstream logical channel, regardless of burst type. Unicast granted minislots are those in which the CMTS assigned bandwidth to any unicast SID on the logical channel. However this object does not include minislots for reserved IUCs, or grants to SIDs=20 designated as meaning 'no CM'. This is the 32 bit version=20 of docsIfCmtsUpChnlCtrExtUcastGrantedMslots, and is=20 included for back compatibility with SNMPv1 managers.=20 Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 3 } docsIfCmtsUpChnlCtrTotalCntnMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention minislots defined for this upstream logical channel. This count includes all minislots assigned to a broadcast or multicast SID on the logical channel. This is the 32 bit version of docsIfCmtsUpChnlCtrExtTotalCntnMslots, and is included for back compatibility with SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 4 } docsIfCmtsUpChnlCtrUsedCntnMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention minislots utilized on the upstream logical channel. For contention regions, utilized minislots are those in which the CMTS correctly received an upstream burst from any CM on the upstream logical channel. This is the 32 bit version of docsIfCmtsUpChnlCtrExtUsedCntnMslots, and is included for back compatibility with SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 5 } docsIfCmtsUpChnlCtrExtTotalMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of all minislots defined for this upstream logical channel. This count includes all IUCs and SIDs, even those allocated to the NULL SID for a 2.0 logical channel which is inactive. This is the 64 bit version of docsIfCmtsUpChnlCtrTotalMslots, and will not be accessible to SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 6 } docsIfCmtsUpChnlCtrExtUcastGrantedMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of unicast granted minislots on the upstream logical channel, regardless of burst type. Unicast granted minislots are those in which the CMTS assigned bandwidth to any unicast SID on the logical channel. However this object does not include minislots for reserved IUCs, or grants to SIDs=20 designated as meaning 'no CM'. This is the 64 bit version of docsIfCmtsUpChnlCtrUcastGrantedMslots, and will not be accessible to SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 7 } docsIfCmtsUpChnlCtrExtTotalCntnMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention minislots defined for this upstream logical channel. This count includes all minislots assigned to a broadcast or multicast SID on the logical channel. This is the 64 bit version of docsIfCmtsUpChnlCtrTotalCntnMslots, and will not be accessible to SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 8 } docsIfCmtsUpChnlCtrExtUsedCntnMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention minislots utilized on the upstream logical channel. For contention regions, utilized minislots are those in which the CMTS correctly received an upstream burst from any CM on the upstream logical channel. This is the 64 bit version of docsIfCmtsUpChnlCtrUsedCntnMslots, and will not be accessible to SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 9 } WITH docsIfCmtsUpChnlCtrTotalMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of all minislots defined for this upstream logical channel. This count includes all IUCs and SIDs, even those allocated to the NULL SID for a 2.0 logical channel which is inactive. This is the 32 bit version of docsIfCmtsUpChnlCtrExtTotalMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 2 } docsIfCmtsUpChnlCtrUcastGrantedMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of unicast granted minislots on the upstream logical channel, regardless of burst type. Unicast granted minislots are those in which the CMTS assigned bandwidth to any unicast SID on the logical channel. However this object does not include minislots for reserved IUCs, or grants to SIDs=20 designated as meaning 'no CM'. This is the 32 bit version=20 of docsIfCmtsUpChnlCtrExtUcastGrantedMslots, and is=20 included for back compatibility with SNMPv1 managers.=20 Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 3 } docsIfCmtsUpChnlCtrTotalCntnMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention minislots defined for this upstream logical channel. This count includes all minislots assigned to a broadcast or multicast SID on the logical channel. This is the 32 bit version of docsIfCmtsUpChnlCtrExtTotalCntnMslots, and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 4 } docsIfCmtsUpChnlCtrUsedCntnMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention minislots utilized on the upstream logical channel. For contention regions, utilized minislots are those in which the CMTS correctly received an upstream burst from any CM on the upstream logical channel. This is the 32 bit version of docsIfCmtsUpChnlCtrExtUsedCntnMslots, and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 5 } docsIfCmtsUpChnlCtrExtTotalMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of all minislots defined for this upstream logical channel. This count includes all IUCs and SIDs, even those allocated to the NULL SID for a 2.0 logical channel which is inactive. This is the 64 bit version of docsIfCmtsUpChnlCtrTotalMslots, and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 6 } docsIfCmtsUpChnlCtrExtUcastGrantedMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of unicast granted minislots on the upstream logical channel, regardless of burst type. Unicast granted minislots are those in which the CMTS assigned bandwidth to any unicast SID on the logical channel. However this object does not include minislots for reserved IUCs, or grants to SIDs=20 designated as meaning 'no CM'. This is the 64 bit version of docsIfCmtsUpChnlCtrUcastGrantedMslots, and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 7 } docsIfCmtsUpChnlCtrExtTotalCntnMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention minislots defined for this upstream logical channel. This count includes all minislots assigned to a broadcast or multicast SID on the logical channel. This is the 64 bit version of docsIfCmtsUpChnlCtrTotalCntnMslots, and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 8 } docsIfCmtsUpChnlCtrExtUsedCntnMslots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention minislots utilized on the upstream logical channel. For contention regions, utilized minislots are those in which the CMTS correctly received an upstream burst from any CM on the upstream logical channel. This is the 64 bit version of docsIfCmtsUpChnlCtrUsedCntnMslots, and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the the value of=20 ifCounterDiscontinuityTime for the associated ifIndex." ::=3D { docsIfCmtsUpChannelCounterEntry 9 } 3) Decision of AUGMENTING or added columnar Optional objects in=20 docsIfCmtsUpChannelCounterTable=20 This topic was discused in good deep in the ipcdn list and very good=20 contributions were made, ( complete email log is in IPCDN web page)=20 To mention, one of the most relevant comments, was from Rich Woundy=20 May 30 2003, with subject=20 "Optional" in the description of objects from the rfimibv2 Rich quoted the section of RFC 2863 3.1.18 "All values Must be Known" Where an agent that does not support a counter permanently must not=20 instantiate the object (e.g. for a particular ifIndex ifTable counter or table extension)=20 or=20 temporarly, the Agent haven't complete the initialization of the entity or the counter function. In summary, the agent will respond with error 'noSuchObject' if object is=20 completely unknown to the implementation (e.g optional implementation) or=20 'noSuchInstance' if the specified row of the object is not valid. Another reference point is the OSSI spec. Since early OSSI mib object requirements, the OSS requires for optional=20 objects the following ( in total synch with Rich's quoted text): Optional mib objects in Annex A Detailed MIB Requirements (normative)=20 "O Optional. A vendor can choose to implement or not implement the object.=20 If a vendor chooses to implement the object, the object MUST be implemented=20 correctly according to the MIB definition. If a vendor chooses not to implement=20 the object, an agent MUST NOT instantiate such object and MUST respond with=20 the appropriate error/exception condition (e.g., no such object for SNMPv2c)." It is clear that the expected behavior per OSSI spec is to find tables with=20 'holes' which is also the IETF recomendation.=20 Conclusion=20 =20 >From the spec point of view the table with the changes is fine, no need to=20 split and management software implementers and operators might explore unified=20 cata loader since this problem is not exclusive of this table, but in general=20 for all interface related statistics and software versioning. =20 ------_=_NextPart_001_01C38CE3.61DFCDD3 Content-Type: text/plain; name="issue#13.txt" Content-Description: issue#13.txt Content-Disposition: attachment; filename="issue#13.txt" Content-Transfer-Encoding: base64 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCisgSXNzdWUgIzEz DQpTdGF0dXM6IE9wZW4NCigxMykgQWRqdXN0IGNvbXBsaWFuY2Ugc3RhdGVtZW50cyBmb3Igb2Jq ZWN0cyBkZXNpZ25hdGVkIG9wdGlvbmFsLiBBZGQNCiAgICAgc2VwYXJhdGUgYXVnbWVudGF0aW9u IHRhYmxlIGZvciBvcHRpb25hbCBvYmplY3RzIGluDQogICAgIGRvY3NJZkNtdHNVcENoYW5uZWxD b3VudGVyVGFibGUuDQogICAgIENvbnRyaWJ1dG9ycyAtIFdpbGwgTXVyd2luIE1vdG9yb2xhLCBS aWNoIFdvdW5keSBJUENETi9Db21jYXN0LA0KICAgICBNaWtlIFN0Sm9obnMgTWluZHNwcmluZywg RWR1YXJkbyBDYXJkb25hIENhYmxlbGFicw0KIyBjYXRlZ29yeTogIm11c3QgZml4Ig0KIyBBY3Rp b24gSXRlbTogRWR1YXJkbyB0byBzdW1tYXJpemUgdGhlIGRpc2N1c3Npb24gJiBhIHJlY29tbWVu ZGF0aW9uDQojIGZvciB0aGUgYXVnbWVudGF0aW9uLiBDb25zZW5zdXMgbXVzdCBiZSByZWFjaGVk IGJ5IDEwLzEwIG9yIGVsc2UgV0cNCiMgY2hhaXIgd2lsbCBtYWtlIGEgZGVjaXNpb24uDQoNCklz c3VlIGl0ZW0gQWN0aW9ucw0KMSkgRGVmaW5lIHRoZSBPcHRpb25hbCBncm91cA0KDQoyKSBSZW1v dmUgdGhlIHRleHQgaW5kaWNhdGlvbiBvZiBvcHRpb25hbCBvciBtYW5kYXRvcnkgb2JqZWN0IGlu IHRoZSANCkRFU0NSSVBUSU9OIGNsYXVzZSBvZiBvYmplY3RzIGluIHRhYmxlIGRvY3NJZkNtdHNV cENoYW5uZWxDb3VudGVyVGFibGUNCg0KMykgRGVjaXNpb24gb2YgQVVHTUVOVElORyBvciBhZGRl ZCBjb2x1bW5hciBPcHRpb25hbCBvYmplY3RzIGluIA0KZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50 ZXJUYWJsZSANCg0KMSkgYW5kIDIpIGFyZSByZXNvbHZlZCBoZXJlLg0KDQozKSBpcyBkaXNjdXNz ZWQgYmVsb3cgYW5kIGFzIHRoZSByZWZlcmVuY2VzIHBvaW50ZWQsIE9TU0kgc3BlYyBhbHJlYWR5 IHJlcXVpcmVzDQogICByZXR1cm4gZXJyb3IgY29kZXMgZm9yIE9wdGlvbmFsIG9iamVjdCBub3Qg aW1wbGVtZW50ZWQuIEFsc28gaXQgaXMgZXhwZWN0ZWQgZm9yIA0KICAgT1NTSSBzcGVjIHRvIHJl dHVybiBjb3JyZWN0IHZhbHVlcyBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlIG9iamVjdCBk ZWZpbml0aW9uDQogICBpZiB0aGUgb3B0aW9uYWwgb2JqZWN0cyBhcmUgc3VwcG9ydGVkLg0KICAg DQogICBUaGUgZGVjaXNpb24gb2Ygc2VwYXJhdGUgaW4gdHdvIHRhYmxlcyB0aGUgbWFuZGF0b3J5 IGFuZCBvcHRpb25hbCBvYmplY3RzIGhhcyB0d28gdmlld3MuDQogICANCiAgIA0KICAgYSkgRmly c3QgQ0wgd2lsbCByZWNvbW1lbmQgbm90IHRvIHNwbGl0IHRoZSB0YWJsZSBiYXNlZCBvbiBhIG1v cmUgZGVlcCBvdmVyYWxsIGFuYWx5c2lzIA0KICAgICAgRnJvbSB0aGUgaXRlbSAzKSBub3RlcyAo ZW5kIG9mIGRvY3VtZW50KSBhbmQgZXh0cmEgY29uc2lkZXJhdGlvbnMuDQogICAJLSBzd2l0Y2hl cyB0byBxdWVyeSBzdWItc2V0cyBvZiBvYmplY3RzIGFyZSBhdmFpbGFibGUgaW4gdGhlIGNhc2Ug b2YgYmFkIFNOTVAgdG9vbCANCiAgIAkgIHN1cHBvcnQgb2YgdGFibGUgaG9sZXMuIE5vdCBkaWZm ZXJlbnQgdG8gaGFuZGxlIGltcGxlbWVudGF0aW9ucyBwcmV2aW91cyB0byANCiAgIAkgIFJGSW1p YnYyIHdoZXJlIG5laXRoZXIgdGhlIG1hbmRhdG9yeSBhbmQgb3B0aW9uYWwgb2JqZWN0cyBhcmUg cHJlc2VudC4NCiAgIAktIEhvbGUgY2FzZXMgYXJlIG5vdCBvbmx5IGEgcHJvYmxlbSBmb3IgdGhp cyB0YWJsZSwgbWFueSBpbnRlcmZhY2UgcmVsYXRlZCBzdGF0aXN0aWNzIA0KICAgCSAgaGFzIHRo b3NlIHByb2JsZW1zIHdoZW4gYnVsa2luZyBkYXRhIHRvIHBlcmZvcm0gbGF0ZXIgb24gZmlsdGVy cyBhbmQgYXNzb2NpYXRpb24gb3IgDQogICAJICBhZ2dyZWdhdGlvbg0KICAgCS0gRnJvbSBhIG5t Z3QgaW50ZWdyYXRvciBkYXRhIGxvYWRlcnMgbWlndGggaGFuZGxlIHRyYW5zcGFyZW50bHkgdGFi bGVzICggd2l0aCBob2xlcykgDQogICAJICB2cyBtdWx0aXBsZSB0YWJsZXMgYXVnbWVudGF0aW9u cyBhbmQvb3IgZXh0ZW5zaW9ucw0KICAgCS0gZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50ZXJUYWJs ZSByZXF1aXJlcyBob29rcyB0byBpZlRhYmxlLCBhbmQgaWZYVGFibGUgdG8gZGV0ZWN0IA0KICAg CSAgZGlzY29udGludWl0aWVzLCBhZG1pblN0YXR1cywgZXRjLiBUaGVyZWZvcmUgVGhlIENvbXBs ZXhpdHkgb2YgdGhlIGRhdGEgdmFsaWRhdGlvbg0KICAgCSAgaW4gdGhlIGFnZ3JlZ2F0aW9uIHNp ZGUgb2YgZGF0YSBsb2FkZXIgbWlndGggc2VlIHRoZSB3aG9sZSB0YWJsZSBhcyBhIG5vdCBzdG9w cGVyLg0KICAgCSAgDQogICANCiAgIGIpICBJZiBiYXNlZCBvbiBhKSB0aGVyZSBhcmUgbW9yZSBj b21wZWxsaW5nIHJlYXNvbnMgdG8gc3RpbGwgcmVxdWlyZSB0aGUgdGFibGUgc3BsaXQNCiAgICAg ICBPbmx5IHN0b3BwZXJzIHRvIHNwbGl0IHRoZSB0YWJsZSBjdXJyZW50bHkgY291bGQgYmUgDQog ICAgICAgSW1wbGVtZW50YXRpb25zIHRoYXQgYWxyZWFkeSBzdXBwb3J0IHRoZSB0YWJsZSBhbmQg aW4gc29tZSBidXNpbmVzcyBjYXNlcyB0aGUgdmVuZG9yIA0KICAgICAgIHdpbGwgcGxhY2Ugc3Ry b25nIG9wcG9zaXRpb24gdG8gZG8gdGhhdCBiZWNhdXNlIChlaXRoZXIgaXRlbXMpOg0KICAgICAg IC0gVGhlIG9wdGlvbmFsIG9iamVjdHMgYXJlIGZ1bGx5IHN1cHBvcnRlZCAobm8gZmlsbGVkIHdp dGggemVyb3MgYXMgZHJhZnQgMDUgcmVxdWlyZXMgDQogICAgICAgICBhbmQgY29ycmVjdGVkIGlu IHRoaXMgZHJhZnQpDQogICAgICAgLSBFeHRlbnNpdmUgZGV2aWNlIGltcGxlbWVudGF0aW9ucw0K ICAgICAgIC0gSWYgb3B0aW9uYWwgb2JqZWN0cyBpbiBjdXJyZW50IGltcGxlbWVudGF0aW9uICha ZXJvZWQpLCB3aWxsIG5vdCBpbXBsZW1lbnQgU29mdHdhcmUgDQogICAgICAgICB2ZXJzaW9ucyBp biBwbGFjZSBmb3Igb3IgYWZ0ZXIgQ1cyOCAoIHdoZXJlIHBvdGVudGlhbHkgIGRyYWZ0IDA4IG1p Z2h0IGJlIHJlcXVpcmVkIA0KICAgICAgICAgaWYgUkZDIGlzIG5vdCBwdWJsaXNoZWQgcHJvbXB0 bHkpLiANCiAgDQogIFBsZWFzZSByZXNwb25kIHByb21wdGx5IHRvIHRoZSBsaXN0IG9yIGluIHBy aXZhdGUgdG8gdmVuZG9yIHByZWZlcmVuY2VzIHRvIHJlYWNoIGNvbnNlbnN1cyANCiAgaW4gdGhp cyBmaW5hbCByZXNvbHV0aW9uIGVpdGhlciB0byBzdXBwb3J0IDMuYSBvciAzLmIgYW5kIHJlYXNv bnMgd2h5LiANCiAgICANCiAgICANCiAgICBEZXRhaWwgY2hhbmdlcyBwcm9wb3NhbA0KICAgIA0K DQoxKSBEZWZpbmUgdGhlIE9wdGlvbmFsIGdyb3VwDQoNCmEpIEFkZCBhZnRlciBHcm91cCBDbGF1 c2UgIkdST1VQIGRvY3NJZkNtdHNHcm91cFYyIg0KICAgICAgICAgICAgIA0KICAgICAgICAgICAg IA0KLS0gT3B0aW9uYWwgZ3JvdXBzDQoNCkdST1VQIGRvY3NJZkNtdHNPcHRpb25hbEdyb3VwVjIN CiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJUaGlzIGdyb3VwIGlzIG9wdGlvbmFs IGZvciBDYWJsZSBNb2RlbSBUZXJtaW5hdGlvbiBTeXN0ZW1zLA0KICAgICAgICAgICAgIGFuZCBu b3QgYXBwbGljYWJsZSBmb3IgQ2FibGUgTW9kZW1zLiINCg0KYikgUkVQTEFDRTogDQoNCg0KZG9j c0lmQ210c0dyb3VwVjIgT0JKRUNULUdST1VQDQogICAgICAgIE9CSkVDVFMgew0KICAgICAgICAg ICAgZG9jc0lmQ210c0NhcGFiaWxpdGllcywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNTeW5jSW50 ZXJ2YWwsDQogICAgICAgICAgICBkb2NzSWZDbXRzVWNkSW50ZXJ2YWwsDQogICAgICAgICAgICBk b2NzSWZDbXRzTWF4U2VydmljZUlkcywNCi0tICAgICAgICAgICAgZG9jc0lmQ210c0luc2VydGlv bkludGVydmFsLA0KICAgICAgICAgICAgZG9jc0lmQ210c0ludml0ZWRSYW5naW5nQXR0ZW1wdHMs DQogICAgICAgICAgICBkb2NzSWZDbXRzSW5zZXJ0SW50ZXJ2YWwsDQogICAgICAgICAgICBkb2Nz SWZDbXRzU3RhdHVzSW52YWxpZFJhbmdlUmVxcywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNTdGF0 dXNSYW5naW5nQWJvcnRlZHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzU3RhdHVzSW52YWxpZFJl Z1JlcXMsDQogICAgICAgICAgICBkb2NzSWZDbXRzU3RhdHVzRmFpbGVkUmVnUmVxcywNCiAgICAg ICAgICAgIGRvY3NJZkNtdHNTdGF0dXNJbnZhbGlkRGF0YVJlcXMsDQogICAgICAgICAgICBkb2Nz SWZDbXRzU3RhdHVzVDVUaW1lb3V0cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c01h Y0FkZHJlc3MsDQogICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNEb3duQ2hhbm5lbElmSW5k ZXgsDQogICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNVcENoYW5uZWxJZkluZGV4LA0KICAg ICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzUnhQb3dlciwNCiAgICAgICAgICAgIGRvY3NJZkNt dHNDbVN0YXR1c1RpbWluZ09mZnNldCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c0Vx dWFsaXphdGlvbkRhdGEsDQogICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNWYWx1ZSwNCiAg ICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c1VuZXJyb3JlZHMsDQogICAgICAgICAgICBkb2Nz SWZDbXRzQ21TdGF0dXNDb3JyZWN0ZWRzLA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVz VW5jb3JyZWN0YWJsZXMsDQogICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNTaWduYWxOb2lz ZSwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c01pY3JvcmVmbGVjdGlvbnMsDQogICAg ICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNFeHRVbmVycm9yZWRzLA0KICAgICAgICAgICAgZG9j c0lmQ210c0NtU3RhdHVzRXh0Q29ycmVjdGVkcywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0 YXR1c0V4dFVuY29ycmVjdGFibGVzLA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzRG9j c2lzUmVnTW9kZSwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c01vZHVsYXRpb25UeXBl LA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzSW5ldEFkZHJlc3NUeXBlLA0KICAgICAg ICAgICAgZG9jc0lmQ210c0NtU3RhdHVzSW5ldEFkZHJlc3MsDQogICAgICAgICAgICBkb2NzSWZD bXRzQ21TdGF0dXNWYWx1ZUxhc3RVcGRhdGUsDQogICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0 dXNIaWdoUmVzb2x1dGlvblRpbWluZ09mZnNldCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNTZXJ2 aWNlQWRtaW5TdGF0dXMsDQogICAgICAgICAgICBkb2NzSWZDbXRzU2VydmljZVFvc1Byb2ZpbGUs DQogICAgICAgICAgICBkb2NzSWZDbXRzU2VydmljZUNyZWF0ZVRpbWUsDQogICAgICAgICAgICBk b2NzSWZDbXRzU2VydmljZUluT2N0ZXRzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1NlcnZpY2VJ blBhY2tldHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzU2VydmljZU5ld0NtU3RhdHVzSW5kZXgs DQogICAgICAgICAgICBkb2NzSWZDbXRzTW9kVHlwZSwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNN b2RDb250cm9sLA0KICAgICAgICAgICAgZG9jc0lmQ210c01vZFByZWFtYmxlTGVuLA0KICAgICAg ICAgICAgZG9jc0lmQ210c01vZERpZmZlcmVudGlhbEVuY29kaW5nLA0KICAgICAgICAgICAgZG9j c0lmQ210c01vZEZFQ0Vycm9yQ29ycmVjdGlvbiwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RG RUNDb2Rld29yZExlbmd0aCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RTY3JhbWJsZXJTZWVk LA0KICAgICAgICAgICAgZG9jc0lmQ210c01vZE1heEJ1cnN0U2l6ZSwNCiAgICAgICAgICAgIGRv Y3NJZkNtdHNNb2RHdWFyZFRpbWVTaXplLA0KICAgICAgICAgICAgZG9jc0lmQ210c01vZExhc3RD b2Rld29yZFNob3J0ZW5lZCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RTY3JhbWJsZXIsDQog ICAgICAgICAgICBkb2NzSWZDbXRzTW9kQnl0ZUludGVybGVhdmVyRGVwdGgsDQogICAgICAgICAg ICBkb2NzSWZDbXRzTW9kQnl0ZUludGVybGVhdmVyQmxvY2tTaXplLA0KICAgICAgICAgICAgZG9j c0lmQ210c01vZFByZWFtYmxlVHlwZSwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RUY21FcnJv ckNvcnJlY3Rpb25PbiwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RTY2RtYUludGVybGVhdmVy U3RlcFNpemUsDQogICAgICAgICAgICBkb2NzSWZDbXRzTW9kU2NkbWFTcHJlYWRlckVuYWJsZSwN CiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RTY2RtYVN1YmZyYW1lQ29kZXMsDQogICAgICAgICAg ICBkb2NzSWZDbXRzTW9kQ2hhbm5lbFR5cGUsDQogICAgICAgICAgICBkb2NzSWZDbXRzUW9zUHJv ZmlsZVBlcm1pc3Npb25zLA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtUHRyLA0KICAgICAgICAg ICAgZG9jc0lmQ210c0NoYW5uZWxVdGlsaXphdGlvbkludGVydmFsLA0KICAgICAgICAgICAgZG9j c0lmQ210c0NoYW5uZWxVdFV0aWxpemF0aW9uLA0KICAgICAgICAgICAgZG9jc0lmQ210c0Rvd25D aG5sQ3RySWQsDQogICAgICAgICAgICBkb2NzSWZDbXRzRG93bkNobmxDdHJUb3RhbEJ5dGVzLA0K ICAgICAgICAgICAgZG9jc0lmQ210c0Rvd25DaG5sQ3RyVXNlZEJ5dGVzLA0KICAgICAgICAgICAg ZG9jc0lmQ210c0Rvd25DaG5sQ3RyRXh0VG90YWxCeXRlcywNCiAgICAgICAgICAgIGRvY3NJZkNt dHNEb3duQ2hubEN0ckV4dFVzZWRCeXRlcywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxD dHJJZCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJUb3RhbE1zbG90cywNCiAgICAg ICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJVY2FzdEdyYW50ZWRNc2xvdHMsDQogICAgICAgICAg ICBkb2NzSWZDbXRzVXBDaG5sQ3RyVG90YWxDbnRuTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lm Q210c1VwQ2hubEN0clVzZWRDbnRuTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hu bEN0ckV4dFRvdGFsTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFVj YXN0R3JhbnRlZE1zbG90cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3Rh bENudG5Nc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0VXNlZENudG5N c2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyQ29sbENudG5Nc2xvdHMsDQog ICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyVG90YWxDbnRuUmVxTXNsb3RzLA0KICAgICAg ICAgICAgZG9jc0lmQ210c1VwQ2hubEN0clVzZWRDbnRuUmVxTXNsb3RzLA0KICAgICAgICAgICAg ZG9jc0lmQ210c1VwQ2hubEN0ckNvbGxDbnRuUmVxTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lm Q210c1VwQ2hubEN0clRvdGFsQ250blJlcURhdGFNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZD bXRzVXBDaG5sQ3RyVXNlZENudG5SZXFEYXRhTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210 c1VwQ2hubEN0ckNvbGxDbnRuUmVxRGF0YU1zbG90cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNV cENobmxDdHJUb3RhbENudG5Jbml0TWFpbnRNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRz VXBDaG5sQ3RyVXNlZENudG5Jbml0TWFpbnRNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRz VXBDaG5sQ3RyQ29sbENudG5Jbml0TWFpbnRNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRz VXBDaG5sQ3RyRXh0Q29sbENudG5Nc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5s Q3RyRXh0VG90YWxDbnRuUmVxTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0 ckV4dFVzZWRDbnRuUmVxTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4 dENvbGxDbnRuUmVxTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRv dGFsQ250blJlcURhdGFNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0 VXNlZENudG5SZXFEYXRhTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4 dENvbGxDbnRuUmVxRGF0YU1zbG90cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJF eHRUb3RhbENudG5Jbml0TWFpbnRNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5s Q3RyRXh0VXNlZENudG5Jbml0TWFpbnRNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBD aG5sQ3RyRXh0Q29sbENudG5Jbml0TWFpbnRNc2xvdHMNCiAgICAgICAgfQ0KICAgICAgICBTVEFU VVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiR3JvdXAg b2Ygb2JqZWN0cyBpbXBsZW1lbnRlZCBpbiBDYWJsZSBNb2RlbSBUZXJtaW5hdGlvbg0KICAgICAg ICAgICAgIFN5c3RlbXMuIg0KICAgICAgICA6Oj0geyBkb2NzSWZHcm91cHNWMiAzIH0NCiANCiBX SVRIOg0KDQoNCmRvY3NJZkNtdHNHcm91cFYyIE9CSkVDVC1HUk9VUA0KICAgICAgICBPQkpFQ1RT IHsNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDYXBhYmlsaXRpZXMsDQogICAgICAgICAgICBkb2Nz SWZDbXRzU3luY0ludGVydmFsLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VjZEludGVydmFsLA0K ICAgICAgICAgICAgZG9jc0lmQ210c01heFNlcnZpY2VJZHMsDQotLSAgICAgICAgICAgIGRvY3NJ ZkNtdHNJbnNlcnRpb25JbnRlcnZhbCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNJbnZpdGVkUmFu Z2luZ0F0dGVtcHRzLA0KICAgICAgICAgICAgZG9jc0lmQ210c0luc2VydEludGVydmFsLA0KICAg ICAgICAgICAgZG9jc0lmQ210c1N0YXR1c0ludmFsaWRSYW5nZVJlcXMsDQogICAgICAgICAgICBk b2NzSWZDbXRzU3RhdHVzUmFuZ2luZ0Fib3J0ZWRzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1N0 YXR1c0ludmFsaWRSZWdSZXFzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1N0YXR1c0ZhaWxlZFJl Z1JlcXMsDQogICAgICAgICAgICBkb2NzSWZDbXRzU3RhdHVzSW52YWxpZERhdGFSZXFzLA0KICAg ICAgICAgICAgZG9jc0lmQ210c1N0YXR1c1Q1VGltZW91dHMsDQogICAgICAgICAgICBkb2NzSWZD bXRzQ21TdGF0dXNNYWNBZGRyZXNzLA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzRG93 bkNoYW5uZWxJZkluZGV4LA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzVXBDaGFubmVs SWZJbmRleCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c1J4UG93ZXIsDQogICAgICAg ICAgICBkb2NzSWZDbXRzQ21TdGF0dXNUaW1pbmdPZmZzZXQsDQogICAgICAgICAgICBkb2NzSWZD bXRzQ21TdGF0dXNFcXVhbGl6YXRpb25EYXRhLA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtU3Rh dHVzVmFsdWUsDQogICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNVbmVycm9yZWRzLA0KICAg ICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzQ29ycmVjdGVkcywNCiAgICAgICAgICAgIGRvY3NJ ZkNtdHNDbVN0YXR1c1VuY29ycmVjdGFibGVzLA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtU3Rh dHVzU2lnbmFsTm9pc2UsDQogICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNNaWNyb3JlZmxl Y3Rpb25zLA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzRXh0VW5lcnJvcmVkcywNCiAg ICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c0V4dENvcnJlY3RlZHMsDQogICAgICAgICAgICBk b2NzSWZDbXRzQ21TdGF0dXNFeHRVbmNvcnJlY3RhYmxlcywNCiAgICAgICAgICAgIGRvY3NJZkNt dHNDbVN0YXR1c0RvY3Npc1JlZ01vZGUsDQogICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNN b2R1bGF0aW9uVHlwZSwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c0luZXRBZGRyZXNz VHlwZSwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c0luZXRBZGRyZXNzLA0KICAgICAg ICAgICAgZG9jc0lmQ210c0NtU3RhdHVzVmFsdWVMYXN0VXBkYXRlLA0KICAgICAgICAgICAgZG9j c0lmQ210c0NtU3RhdHVzSGlnaFJlc29sdXRpb25UaW1pbmdPZmZzZXQsDQogICAgICAgICAgICBk b2NzSWZDbXRzU2VydmljZUFkbWluU3RhdHVzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1NlcnZp Y2VRb3NQcm9maWxlLA0KICAgICAgICAgICAgZG9jc0lmQ210c1NlcnZpY2VDcmVhdGVUaW1lLA0K ICAgICAgICAgICAgZG9jc0lmQ210c1NlcnZpY2VJbk9jdGV0cywNCiAgICAgICAgICAgIGRvY3NJ ZkNtdHNTZXJ2aWNlSW5QYWNrZXRzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1NlcnZpY2VOZXdD bVN0YXR1c0luZGV4LA0KICAgICAgICAgICAgZG9jc0lmQ210c01vZFR5cGUsDQogICAgICAgICAg ICBkb2NzSWZDbXRzTW9kQ29udHJvbCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RQcmVhbWJs ZUxlbiwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2REaWZmZXJlbnRpYWxFbmNvZGluZywNCiAg ICAgICAgICAgIGRvY3NJZkNtdHNNb2RGRUNFcnJvckNvcnJlY3Rpb24sDQogICAgICAgICAgICBk b2NzSWZDbXRzTW9kRkVDQ29kZXdvcmRMZW5ndGgsDQogICAgICAgICAgICBkb2NzSWZDbXRzTW9k U2NyYW1ibGVyU2VlZCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RNYXhCdXJzdFNpemUsDQog ICAgICAgICAgICBkb2NzSWZDbXRzTW9kR3VhcmRUaW1lU2l6ZSwNCiAgICAgICAgICAgIGRvY3NJ ZkNtdHNNb2RMYXN0Q29kZXdvcmRTaG9ydGVuZWQsDQogICAgICAgICAgICBkb2NzSWZDbXRzTW9k U2NyYW1ibGVyLA0KICAgICAgICAgICAgZG9jc0lmQ210c01vZEJ5dGVJbnRlcmxlYXZlckRlcHRo LA0KICAgICAgICAgICAgZG9jc0lmQ210c01vZEJ5dGVJbnRlcmxlYXZlckJsb2NrU2l6ZSwNCiAg ICAgICAgICAgIGRvY3NJZkNtdHNNb2RQcmVhbWJsZVR5cGUsDQogICAgICAgICAgICBkb2NzSWZD bXRzTW9kVGNtRXJyb3JDb3JyZWN0aW9uT24sDQogICAgICAgICAgICBkb2NzSWZDbXRzTW9kU2Nk bWFJbnRlcmxlYXZlclN0ZXBTaXplLA0KICAgICAgICAgICAgZG9jc0lmQ210c01vZFNjZG1hU3By ZWFkZXJFbmFibGUsDQogICAgICAgICAgICBkb2NzSWZDbXRzTW9kU2NkbWFTdWJmcmFtZUNvZGVz LA0KICAgICAgICAgICAgZG9jc0lmQ210c01vZENoYW5uZWxUeXBlLA0KICAgICAgICAgICAgZG9j c0lmQ210c1Fvc1Byb2ZpbGVQZXJtaXNzaW9ucywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVB0 ciwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDaGFubmVsVXRpbGl6YXRpb25JbnRlcnZhbCwNCiAg ICAgICAgICAgIGRvY3NJZkNtdHNDaGFubmVsVXRVdGlsaXphdGlvbiwNCiAgICAgICAgICAgIGRv Y3NJZkNtdHNEb3duQ2hubEN0cklkLA0KICAgICAgICAgICAgZG9jc0lmQ210c0Rvd25DaG5sQ3Ry VG90YWxCeXRlcywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNEb3duQ2hubEN0clVzZWRCeXRlcywN CiAgICAgICAgICAgIGRvY3NJZkNtdHNEb3duQ2hubEN0ckV4dFRvdGFsQnl0ZXMsDQogICAgICAg ICAgICBkb2NzSWZDbXRzRG93bkNobmxDdHJFeHRVc2VkQnl0ZXMsDQogICAgICAgICAgICBkb2Nz SWZDbXRzVXBDaG5sQ3RySWQsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyVG90YWxN c2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyVWNhc3RHcmFudGVkTXNsb3Rz LA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0clRvdGFsQ250bk1zbG90cywNCiAgICAg ICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJVc2VkQ250bk1zbG90cywNCiAgICAgICAgICAgIGRv Y3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbE1zbG90cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNV cENobmxDdHJFeHRVY2FzdEdyYW50ZWRNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBD aG5sQ3RyRXh0VG90YWxDbnRuTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0 ckV4dFVzZWRDbnRuTXNsb3RzDQogICAgICAgIH0NCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVu dA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkdyb3VwIG9mIG9iamVjdHMgaW1w bGVtZW50ZWQgaW4gQ2FibGUgTW9kZW0gVGVybWluYXRpb24NCiAgICAgICAgICAgICBTeXN0ZW1z LiINCiAgICAgICAgOjo9IHsgZG9jc0lmR3JvdXBzVjIgMyB9DQoNCmRvY3NJZkNtdHNPcHRpb25h bEdyb3VwVjIgT0JKRUNULUdST1VQDQogICAgICAgIE9CSkVDVFMgew0KICAgICAgICAgICAgZG9j c0lmQ210c1VwQ2hubEN0ckNvbGxDbnRuTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1Vw Q2hubEN0clRvdGFsQ250blJlcU1zbG90cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxD dHJVc2VkQ250blJlcU1zbG90cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJDb2xs Q250blJlcU1zbG90cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJUb3RhbENudG5S ZXFEYXRhTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0clVzZWRDbnRuUmVx RGF0YU1zbG90cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJDb2xsQ250blJlcURh dGFNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyVG90YWxDbnRuSW5pdE1h aW50TXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0clVzZWRDbnRuSW5pdE1h aW50TXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckNvbGxDbnRuSW5pdE1h aW50TXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dENvbGxDbnRuTXNs b3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRvdGFsQ250blJlcU1zbG90 cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJFeHRVc2VkQ250blJlcU1zbG90cywN CiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJFeHRDb2xsQ250blJlcU1zbG90cywNCiAg ICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbENudG5SZXFEYXRhTXNsb3RzLA0K ICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFVzZWRDbnRuUmVxRGF0YU1zbG90cywN CiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJFeHRDb2xsQ250blJlcURhdGFNc2xvdHMs DQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0VG90YWxDbnRuSW5pdE1haW50TXNs b3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFVzZWRDbnRuSW5pdE1haW50 TXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dENvbGxDbnRuSW5pdE1h aW50TXNsb3RzDQogICAgICAgIH0NCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAg ICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkdyb3VwIG9mIG9iamVjdHMgaW1wbGVtZW50ZWQg b3B0aW9uYWx5IGluIENhYmxlIE1vZGVtIA0KICAgICAgICAgICAgIFRlcm1pbmF0aW9uIFN5c3Rl bXMuIg0KICAgICAgICA6Oj0geyBkb2NzSWZHcm91cHNWMiA0IH0NCg0KDQoNCjIpIFJlbW92ZSB0 aGUgdGV4dCBpbmRpY2F0aW9uIG9mIG9wdGlvbmFsIG9yIG1hbmRhdG9yeSBvYmplY3QgaW4gdGhl IA0KREVTQ1JJUFRJT04gY2xhdXNlIG9mIG9iamVjdHMgaW4gdGFibGUgZG9jc0lmQ210c1VwQ2hh bm5lbENvdW50ZXJUYWJsZQ0KDQpDaGFuZ2Ugc2V2ZXJhbCBvY2N1cmVuY2VzIG9mICJ0aGUgdGhl IiB3aXRoICJ0aGUiDQoNCg0KcmVtb3ZlIHRleHQgZnJvbSBERVNDUklQVElPTiBjbGF1c2VzOg0K U3VwcG9ydCBmb3IgdGhpcyBvYmplY3QgaXMgb3B0aW9uYWwuIElmIHRoZSBvYmplY3QgaXMgbm90 DQogICAgICAgICAgICAgc3VwcG9ydGVkLCBhIHZhbHVlIG9mIHplcm8gaXMgcmV0dXJuZWQuDQph KSBSRVBMQUNFOg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3RyQ29sbENudG5Nc2xvdHMgT0JKRUNULVRZ UEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJl YWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9O DQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBv ZiBjb250ZW50aW9uDQogICAgICAgICAgICAgbWluaXNsb3RzIHN1YmplY3RlZCB0byBjb2xsaXNp b25zIG9uIHRoZSB1cHN0cmVhbSBsb2dpY2FsDQogICAgICAgICAgICAgY2hhbm5lbC4gRm9yIGNv bnRlbnRpb24gcmVnaW9ucywgdGhlc2UgYXJlIHRoZSBtaW5pc2xvdHMNCiAgICAgICAgICAgICBh cHBsaWNhYmxlIHRvIGJ1cnN0cyB0aGF0IHRoZSBDTVRTIGRldGVjdGVkLCBidXQgY291bGQgbm90 DQogICAgICAgICAgICAgY29ycmVjdGx5IHJlY2VpdmUuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJz aW9uIG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dENvbGxDbnRuTXNsb3Rz LCBhbmQgaXMgaW5jbHVkZWQgZm9yDQogICAgICAgICAgICAgYmFjayBjb21wYXRpYmlsaXR5IHdp dGggU05NUHYxIG1hbmFnZXJzLiBTdXBwb3J0IGZvciB0aGlzDQogICAgICAgICAgICAgb2JqZWN0 IGlzIG9wdGlvbmFsLiBJZiB0aGUgb2JqZWN0IGlzIG5vdCBzdXBwb3J0ZWQsIGENCiAgICAgICAg ICAgICB2YWx1ZSBvZiB6ZXJvIGlzIHJldHVybmVkLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVp dGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAg IGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXIN CiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAg ICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQg aWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkg MTAgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJUb3RhbENudG5SZXFNc2xvdHMgT0JKRUNULVRZ UEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJl YWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9O DQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBv ZiBjb250ZW50aW9uDQogICAgICAgICAgICAgcmVxdWVzdCBtaW5pc2xvdHMgZGVmaW5lZCBmb3Ig dGhpcyB1cHN0cmVhbSBsb2dpY2FsDQogICAgICAgICAgICAgY2hhbm5lbC4gVGhpcyBjb3VudCBp bmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMxDQogICAgICAgICAgICAgYXNzaWduZWQgdG8g YSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBvbiB0aGUgbG9naWNhbA0KICAgICAgICAgICAg IGNoYW5uZWwuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAgICAgZG9j c0lmQ210c1VwQ2hubEN0ckV4dFRvdGFsQ250blJlcU1zbG90cywgYW5kIGlzIGluY2x1ZGVkDQog ICAgICAgICAgICAgZm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2MSBtYW5hZ2Vycy4N CiAgICAgICAgICAgICBTdXBwb3J0IGZvciB0aGlzIG9iamVjdCBpcyBvcHRpb25hbC4gSWYgdGhl IG9iamVjdCBpcyBub3QNCiAgICAgICAgICAgICBzdXBwb3J0ZWQsIGEgdmFsdWUgb2YgemVybyBp cyByZXR1cm5lZC4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9m IHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9u IG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMg YXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVy RGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6 Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDExIH0NCg0KDQpkb2NzSWZDbXRz VXBDaG5sQ3RyVXNlZENudG5SZXFNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAg ICAgQ291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFU VVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVu dCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAg ICAgICAgcmVxdWVzdCBtaW5pc2xvdHMgdXRpbGl6ZWQgb24gdGhpcyB1cHN0cmVhbSBsb2dpY2Fs DQogICAgICAgICAgICAgY2hhbm5lbC4gVGhpcyBjb3VudCBpbmNsdWRlcyBhbGwgY29udGVudGlv biBtaW5pc2xvdHMgZm9yDQogICAgICAgICAgICAgSVVDMSBhcHBsaWNhYmxlIHRvIGJ1cnN0cyB0 aGF0IHRoZSBDTVRTIGNvcnJlY3RseQ0KICAgICAgICAgICAgIHJlY2VpdmVkLiBUaGlzIGlzIHRo ZSAzMiBiaXQgdmVyc2lvbiBvZg0KICAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJFeHRV c2VkQ250blJlcU1zbG90cywgYW5kIGlzIGluY2x1ZGVkDQogICAgICAgICAgICAgZm9yIGJhY2sg Y29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2MSBtYW5hZ2Vycy4gU3VwcG9ydCBmb3INCiAgICAgICAg ICAgICB0aGlzIG9iamVjdCBpcyBvcHRpb25hbC4gSWYgdGhlIG9iamVjdCBpcyBub3Qgc3VwcG9y dGVkLA0KICAgICAgICAgICAgIGEgdmFsdWUgb2YgemVybyBpcyByZXR1cm5lZC4NCiAgICAgICAg ICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2Nj dXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3Rl bSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0 aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9y IHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFu bmVsQ291bnRlckVudHJ5IDEyIH0NCg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3RyQ29sbENudG5SZXFN c2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAg IE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAg ICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGlu aXRpYWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgcmVxdWVzdCBtaW5pc2xv dHMgc3ViamVjdGVkIHRvIGNvbGxpc2lvbnMgb24gdGhpcyB1cHN0cmVhbQ0KICAgICAgICAgICAg IGxvZ2ljYWwgY2hhbm5lbC4gVGhpcyBpbmNsdWRlcyBhbGwgY29udGVudGlvbiBtaW5pc2xvdHMN CiAgICAgICAgICAgICBmb3IgSVVDMSBhcHBsaWNhYmxlIHRvIGJ1cnN0cyB0aGF0IHRoZSBDTVRT IGRldGVjdGVkLCBidXQNCiAgICAgICAgICAgICBjb3VsZCBub3QgY29ycmVjdGx5IHJlY2VpdmUu IFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1Vw Q2hubEN0ckV4dENvbGxDbnRuUmVxTXNsb3RzLCBhbmQgaXMgaW5jbHVkZWQNCiAgICAgICAgICAg ICBmb3IgYmFjayBjb21wYXRpYmlsaXR5IHdpdGggU05NUHYxIG1hbmFnZXJzLiBTdXBwb3J0IGZv cg0KICAgICAgICAgICAgIHRoaXMgb2JqZWN0IGlzIG9wdGlvbmFsLiBJZiB0aGUgb2JqZWN0IGlz IG5vdCBzdXBwb3J0ZWQsDQogICAgICAgICAgICAgYSB2YWx1ZSBvZiB6ZXJvIGlzIHJldHVybmVk Lg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3Vu dGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1h bmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0 ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51 aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJ ZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMTMgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJU b3RhbENudG5SZXFEYXRhTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENv dW50ZXIzMg0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAg ICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291 bnQsIGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAg IHJlcXVlc3QgZGF0YSBtaW5pc2xvdHMgZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2Fs DQogICAgICAgICAgICAgY2hhbm5lbC4gVGhpcyBjb3VudCBpbmNsdWRlcyBhbGwgbWluaXNsb3Rz IGZvciBJVUMyDQogICAgICAgICAgICAgYXNzaWduZWQgdG8gYSBicm9hZGNhc3Qgb3IgbXVsdGlj YXN0IFNJRCBvbiB0aGUgbG9naWNhbA0KICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgaXMgdGhl IDMyIGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRv dGFsQ250blJlcURhdGFNc2xvdHMsIGFuZCBpcw0KICAgICAgICAgICAgIGluY2x1ZGVkIGZvciBi YWNrIGNvbXBhdGliaWxpdHkgd2l0aCBTTk1QdjEgbWFuYWdlcnMuDQogICAgICAgICAgICAgU3Vw cG9ydCBmb3IgdGhpcyBvYmplY3QgaXMgb3B0aW9uYWwuIElmIHRoZSBvYmplY3QgaXMgbm90DQog ICAgICAgICAgICAgc3VwcG9ydGVkLCBhIHZhbHVlIG9mIHplcm8gaXMgcmV0dXJuZWQuDQogICAg ICAgICAgICAgRGlzY29udGludWl0aWVzIGluIHRoZSB2YWx1ZSBvZiB0aGlzIGNvdW50ZXIgY2Fu IG9jY3VyDQogICAgICAgICAgICAgYXQgcmVpbml0aWFsaXphdGlvbiBvZiB0aGUgbWFuYWdlZCBz eXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAgICAgICAgIHRpbWVzIGFzIGluZGljYXRlZCBieSB0 aGUgdGhlIHZhbHVlIG9mIA0KICAgICAgICAgICAgIGlmQ291bnRlckRpc2NvbnRpbnVpdHlUaW1l IGZvciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4LiINCiAgICAgICAgOjo9IHsgZG9jc0lmQ210c1Vw Q2hhbm5lbENvdW50ZXJFbnRyeSAxNCB9DQoNCg0KZG9jc0lmQ210c1VwQ2hubEN0clVzZWRDbnRu UmVxRGF0YU1zbG90cyBPQkpFQ1QtVFlQRQ0KICAgICAgICBTWU5UQVggICAgICBDb3VudGVyMzIN CiAgICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJl bnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJDdXJyZW50IGNvdW50LCBmcm9t IENNVFMgaW5pdGlhbGl6YXRpb24sIG9mIGNvbnRlbnRpb24NCiAgICAgICAgICAgICByZXF1ZXN0 IGRhdGEgbWluaXNsb3RzIHV0aWxpemVkIG9uIHRoaXMgdXBzdHJlYW0gbG9naWNhbA0KICAgICAg ICAgICAgIGNoYW5uZWwuIFRoaXMgaW5jbHVkZXMgYWxsIGNvbnRlbnRpb24gbWluaXNsb3RzIGZv ciBJVUMyDQogICAgICAgICAgICAgYXBwbGljYWJsZSB0byBidXJzdHMgdGhhdCB0aGUgQ01UUyBj b3JyZWN0bHkgcmVjZWl2ZWQuDQogICAgICAgICAgICAgVGhpcyBpcyB0aGUgMzIgYml0IHZlcnNp b24gb2YgDQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFVzZWRDbnRuUmVxRGF0 YU1zbG90cywgYW5kIGlzDQogICAgICAgICAgICAgaW5jbHVkZWQgZm9yIGJhY2sgY29tcGF0aWJp bGl0eSB3aXRoIFNOTVB2MSBtYW5hZ2Vycy4NCiAgICAgICAgICAgICBTdXBwb3J0IGZvciB0aGlz IG9iamVjdCBpcyBvcHRpb25hbC4gSWYgdGhlIG9iamVjdCBpcyBub3QNCiAgICAgICAgICAgICBz dXBwb3J0ZWQsIGEgdmFsdWUgb2YgemVybyBpcyByZXR1cm5lZC4NCiAgICAgICAgICAgICBEaXNj b250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAg ICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0 IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUg b2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3Nv Y2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRl ckVudHJ5IDE1IH0NCg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3RyQ29sbENudG5SZXFEYXRhTXNsb3Rz IE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgICAgICBNQVgt QUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBE RVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20gQ01UUyBpbml0aWFs aXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAgIHJlcXVlc3QgZGF0YSBtaW5pc2xv dHMgc3ViamVjdGVkIHRvIGNvbGxpc2lvbnMgb24gdGhpcw0KICAgICAgICAgICAgIHVwc3RyZWFt IGxvZ2ljYWwgY2hhbm5lbC4gVGhpcyBpbmNsdWRlcyBhbGwgY29udGVudGlvbg0KICAgICAgICAg ICAgIG1pbmlzbG90cyBmb3IgSVVDMiBhcHBsaWNhYmxlIHRvIGJ1cnN0cyB0aGF0IHRoZSBDTVRT DQogICAgICAgICAgICAgZGV0ZWN0ZWQsIGJ1dCBjb3VsZCBub3QgY29ycmVjdGx5IHJlY2VpdmUu IFRoaXMgaXMgdGhlIDMyDQogICAgICAgICAgICAgYml0IHZlcnNpb24gb2YNCiAgICAgICAgICAg ICBkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0Q29sbENudG5SZXFEYXRhTXNsb3RzLCBhbmQgaXMNCiAg ICAgICAgICAgICBpbmNsdWRlZCBmb3IgYmFjayBjb21wYXRpYmlsaXR5IHdpdGggU05NUHYxIG1h bmFnZXJzLg0KICAgICAgICAgICAgIFN1cHBvcnQgZm9yIHRoaXMgb2JqZWN0IGlzIG9wdGlvbmFs LiBJZiB0aGUgb2JqZWN0IGlzIG5vdA0KICAgICAgICAgICAgIHN1cHBvcnRlZCwgYSB2YWx1ZSBv ZiB6ZXJvIGlzIHJldHVybmVkLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUg dmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlh bGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAg ICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBp ZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQog ICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMTYgfQ0KDQoNCmRv Y3NJZkNtdHNVcENobmxDdHJUb3RhbENudG5Jbml0TWFpbnRNc2xvdHMgT0JKRUNULVRZUEUNCiAg ICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25s eQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAg ICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250 ZW50aW9uDQogICAgICAgICAgICAgaW5pdGlhbCBtYWludGVuYW5jZSBtaW5pc2xvdHMgZGVmaW5l ZCBmb3IgdGhpcyB1cHN0cmVhbQ0KICAgICAgICAgICAgIGxvZ2ljYWwgY2hhbm5lbC4gVGhpcyBp bmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMzDQogICAgICAgICAgICAgYXNzaWduZWQgdG8g YSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBvbiB0aGUgbG9naWNhbA0KICAgICAgICAgICAg IGNoYW5uZWwuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAgICAgZG9j c0lmQ210c1VwQ2hubEN0ckV4dFRvdGFsQ250bkluaXRNYWludE1zbG90cywNCiAgICAgICAgICAg ICBhbmQgaXMgaW5jbHVkZWQgZm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2MQ0KICAg ICAgICAgICAgIG1hbmFnZXJzLiBTdXBwb3J0IGZvciB0aGlzIG9iamVjdCBpcyBvcHRpb25hbC4g SWYgdGhlDQogICAgICAgICAgICAgb2JqZWN0IGlzIG5vdCBzdXBwb3J0ZWQsIGEgdmFsdWUgb2Yg emVybyBpcyByZXR1cm5lZC4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZh bHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxp emF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAg dGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZD b3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAg ICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDE3IH0NCg0KDQpkb2Nz SWZDbXRzVXBDaG5sQ3RyVXNlZENudG5Jbml0TWFpbnRNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAg ICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0K ICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAg ICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250ZW50 aW9uDQogICAgICAgICAgICAgaW5pdGlhbCBtYWludGVuYW5jZSBtaW5pc2xvdHMgdXRpbGl6ZWQg b24gdGhpcyB1cHN0cmVhbQ0KICAgICAgICAgICAgIGxvZ2ljYWwgY2hhbm5lbC4gVGhpcyBpbmNs dWRlcyBhbGwgY29udGVudGlvbiBtaW5pc2xvdHMNCiAgICAgICAgICAgICBmb3IgSVVDMyBhcHBs aWNhYmxlIHRvIGJ1cnN0cyB0aGF0IHRoZSBDTVRTIGNvcnJlY3RseQ0KICAgICAgICAgICAgIHJl Y2VpdmVkLiBUaGlzIGlzIHRoZSAzMiBiaXQgdmVyc2lvbiBvZiANCiAgICAgICAgICAgICBkb2Nz SWZDbXRzVXBDaG5sQ3RyRXh0VXNlZENudG5Jbml0TWFpbnRNc2xvdHMsDQogICAgICAgICAgICAg YW5kIGlzIGluY2x1ZGVkIGZvciBiYWNrIGNvbXBhdGliaWxpdHkgd2l0aCBTTk1QdjENCiAgICAg ICAgICAgICBtYW5hZ2Vycy4gU3VwcG9ydCBmb3IgdGhpcyBvYmplY3QgaXMgb3B0aW9uYWwuIElm IHRoZQ0KICAgICAgICAgICAgIG9iamVjdCBpcyBub3Qgc3VwcG9ydGVkLCBhIHZhbHVlIG9mIHpl cm8gaXMgcmV0dXJuZWQuDQogICAgICAgICAgICAgRGlzY29udGludWl0aWVzIGluIHRoZSB2YWx1 ZSBvZiB0aGlzIGNvdW50ZXIgY2FuIG9jY3VyDQogICAgICAgICAgICAgYXQgcmVpbml0aWFsaXph dGlvbiBvZiB0aGUgbWFuYWdlZCBzeXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAgICAgICAgIHRp bWVzIGFzIGluZGljYXRlZCBieSB0aGUgdGhlIHZhbHVlIG9mIA0KICAgICAgICAgICAgIGlmQ291 bnRlckRpc2NvbnRpbnVpdHlUaW1lIGZvciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4LiINCiAgICAg ICAgOjo9IHsgZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50ZXJFbnRyeSAxOCB9DQoNCg0KZG9jc0lm Q210c1VwQ2hubEN0ckNvbGxDbnRuSW5pdE1haW50TXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAg IFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAg ICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAg ICAgIkN1cnJlbnQgY291bnQsIGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29udGVudGlv bg0KICAgICAgICAgICAgIGluaXRpYWwgbWFpbnRlbmFuY2UgbWluaXNsb3RzIHN1YmplY3RlZCB0 byBjb2xsaXNpb25zIG9uDQogICAgICAgICAgICAgdGhpcyB1cHN0cmVhbSBsb2dpY2FsIGNoYW5u ZWwuIFRoaXMgaW5jbHVkZXMgYWxsDQogICAgICAgICAgICAgY29udGVudGlvbiBtaW5pc2xvdHMg Zm9yIElVQzMgYXBwbGljYWJsZSB0byBidXJzdHMgdGhhdA0KICAgICAgICAgICAgIHRoZSBDTVRT IGRldGVjdGVkLCBidXQgY291bGQgbm90IGNvcnJlY3RseSByZWNlaXZlLiAgICAgICANCiAgICAg ICAgICAgICBUaGlzIGlzIHRoZSAzMiBiaXQgdmVyc2lvbiBvZiANCiAgICAgICAgICAgICBkb2Nz SWZDbXRzVXBDaG5sQ3RyRXh0Q29sbENudG5Jbml0TWFpbnRNc2xvdHMsDQogICAgICAgICAgICAg YW5kIGlzIGluY2x1ZGVkIGZvciBiYWNrIGNvbXBhdGliaWxpdHkgd2l0aCBTTk1QdjENCiAgICAg ICAgICAgICBtYW5hZ2Vycy4gU3VwcG9ydCBmb3IgdGhpcyBvYmplY3QgaXMgb3B0aW9uYWwuIElm IHRoZQ0KICAgICAgICAgICAgIG9iamVjdCBpcyBub3Qgc3VwcG9ydGVkLCBhIHZhbHVlIG9mIHpl cm8gaXMgcmV0dXJuZWQuDQogICAgICAgICAgICAgRGlzY29udGludWl0aWVzIGluIHRoZSB2YWx1 ZSBvZiB0aGlzIGNvdW50ZXIgY2FuIG9jY3VyDQogICAgICAgICAgICAgYXQgcmVpbml0aWFsaXph dGlvbiBvZiB0aGUgbWFuYWdlZCBzeXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAgICAgICAgIHRp bWVzIGFzIGluZGljYXRlZCBieSB0aGUgdGhlIHZhbHVlIG9mIA0KICAgICAgICAgICAgIGlmQ291 bnRlckRpc2NvbnRpbnVpdHlUaW1lIGZvciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4LiINCiAgICAg ICAgOjo9IHsgZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50ZXJFbnRyeSAxOSB9DQoNCg0KZG9jc0lm Q210c1VwQ2hubEN0ckV4dENvbGxDbnRuTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRB WCAgICAgIENvdW50ZXI2NA0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAg U1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1 cnJlbnQgY291bnQsIGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29sbGlzaW9uDQogICAg ICAgICAgICAgY29udGVudGlvbiBtaW5pc2xvdHMgb24gdGhlIHVwc3RyZWFtIGxvZ2ljYWwgY2hh bm5lbC4NCiAgICAgICAgICAgICBGb3IgY29udGVudGlvbiByZWdpb25zLCB0aGVzZSBhcmUgdGhl IG1pbmlzbG90cyBhcHBsaWNhYmxlDQogICAgICAgICAgICAgdG8gYnVyc3RzIHRoYXQgdGhlIENN VFMgZGV0ZWN0ZWQsIGJ1dCBjb3VsZCBub3QgY29ycmVjdGx5DQogICAgICAgICAgICAgcmVjZWl2 ZS4gVGhpcyBpcyB0aGUgNjQgYml0IHZlcnNpb24gb2YNCiAgICAgICAgICAgICBkb2NzSWZDbXRz VXBDaG5sQ3RyQ29sbENudG5Nc2xvdHMsIGFuZCB3aWxsIG5vdCBiZQ0KICAgICAgICAgICAgIGFj Y2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLiBTdXBwb3J0IGZvciB0aGlzIG9iamVjdCBpcw0K ICAgICAgICAgICAgIG9wdGlvbmFsLiBJZiB0aGUgb2JqZWN0IGlzIG5vdCBzdXBwb3J0ZWQsIGEg dmFsdWUgb2YgemVybw0KICAgICAgICAgICAgIGlzIHJldHVybmVkLg0KICAgICAgICAgICAgIERp c2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAg ICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQg YXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1 ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFz c29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3Vu dGVyRW50cnkgMjAgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbENudG5SZXFNc2xv dHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1B WC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRp YWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgcmVxdWVzdCBtaW5pc2xvdHMg ZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2FsDQogICAgICAgICAgICAgY2hhbm5lbC4g VGhpcyBjb3VudCBpbmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMxDQogICAgICAgICAgICAg YXNzaWduZWQgdG8gYSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBvbiB0aGUgbG9naWNhbA0K ICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgaXMgdGhlIDY0IGJpdCB2ZXJzaW9uIG9mDQogICAg ICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0clRvdGFsQ250blJlcU1zbG90cywgYW5kIHdpbGwg bm90IGJlDQogICAgICAgICAgICAgYWNjZXNzaWJsZSB0byBTTk1QdjEgbWFuYWdlcnMuIFN1cHBv cnQgZm9yIHRoaXMgb2JqZWN0DQogICAgICAgICAgICAgaXMgb3B0aW9uYWwuIElmIHRoZSBvYmpl Y3QgaXMgbm90IHN1cHBvcnRlZCwgYSB2YWx1ZSBvZg0KICAgICAgICAgICAgIHplcm8gaXMgcmV0 dXJuZWQuDQogICAgICAgICAgICAgRGlzY29udGludWl0aWVzIGluIHRoZSB2YWx1ZSBvZiB0aGlz IGNvdW50ZXIgY2FuIG9jY3VyDQogICAgICAgICAgICAgYXQgcmVpbml0aWFsaXphdGlvbiBvZiB0 aGUgbWFuYWdlZCBzeXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAgICAgICAgIHRpbWVzIGFzIGlu ZGljYXRlZCBieSB0aGUgdGhlIHZhbHVlIG9mIA0KICAgICAgICAgICAgIGlmQ291bnRlckRpc2Nv bnRpbnVpdHlUaW1lIGZvciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4LiINCiAgICAgICAgOjo9IHsg ZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50ZXJFbnRyeSAyMSB9DQoNCg0KZG9jc0lmQ210c1VwQ2hu bEN0ckV4dFVzZWRDbnRuUmVxTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAg IENvdW50ZXI2NA0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVT ICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQg Y291bnQsIGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAg ICAgIHJlcXVlc3QgbWluaXNsb3RzIHV0aWxpemVkIG9uIHRoaXMgdXBzdHJlYW0gbG9naWNhbA0K ICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgY291bnQgaW5jbHVkZXMgYWxsIGNvbnRlbnRpb24g bWluaXNsb3RzIGZvcg0KICAgICAgICAgICAgIElVQzEgYXBwbGljYWJsZSB0byBidXJzdHMgdGhh dCB0aGUgQ01UUyBjb3JyZWN0bHkNCiAgICAgICAgICAgICByZWNlaXZlZC4gVGhpcyBpcyB0aGUg NjQgYml0IHZlcnNpb24gb2YNCiAgICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyVXNlZENu dG5SZXFNc2xvdHMsIGFuZCB3aWxsIG5vdCBiZQ0KICAgICAgICAgICAgIGFjY2Vzc2libGUgdG8g U05NUHYxIG1hbmFnZXJzLiBTdXBwb3J0IGZvciB0aGlzIG9iamVjdCBpcw0KICAgICAgICAgICAg IG9wdGlvbmFsLiBJZiB0aGUgb2JqZWN0IGlzIG5vdCBzdXBwb3J0ZWQsIGEgdmFsdWUgb2YgemVy bw0KICAgICAgICAgICAgIGlzIHJldHVybmVkLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGll cyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0 IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAg ICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAg ICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJ bmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMjIg fQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRDb2xsQ250blJlcU1zbG90cyBPQkpFQ1QtVFlQ RQ0KICAgICAgICBTWU5UQVggICAgICBDb3VudGVyNjQNCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVh ZC1vbmx5DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04N CiAgICAgICAgICAgICJDdXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRpb24sIG9m IGNvbnRlbnRpb24NCiAgICAgICAgICAgICByZXF1ZXN0IG1pbmlzbG90cyBzdWJqZWN0ZWQgdG8g Y29sbGlzaW9ucyBvbiB0aGlzIHVwc3RyZWFtDQogICAgICAgICAgICAgbG9naWNhbCBjaGFubmVs LiBUaGlzIGluY2x1ZGVzIGFsbCBjb250ZW50aW9uIG1pbmlzbG90cw0KICAgICAgICAgICAgIGZv ciBJVUMxIGFwcGxpY2FibGUgdG8gYnVyc3RzIHRoYXQgdGhlIENNVFMgZGV0ZWN0ZWQsDQogICAg ICAgICAgICAgYnV0IGNvdWxkIG5vdCBjb3JyZWN0bHkgcmVjZWl2ZS4gVGhpcyBpcyB0aGUgNjQg Yml0DQogICAgICAgICAgICAgdmVyc2lvbiBvZiBkb2NzSWZDbXRzVXBDaG5sQ3RyQ29sbENudG5S ZXFNc2xvdHMsIGFuZCB3aWxsDQogICAgICAgICAgICAgbm90IGJlIGFjY2Vzc2libGUgdG8gU05N UHYxIG1hbmFnZXJzLiBTdXBwb3J0IGZvciB0aGlzDQogICAgICAgICAgICAgb2JqZWN0IGlzIG9w dGlvbmFsLiBJZiB0aGUgb2JqZWN0IGlzIG5vdCBzdXBwb3J0ZWQsIGENCiAgICAgICAgICAgICB2 YWx1ZSBvZiB6ZXJvIGlzIHJldHVybmVkLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBp biB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJl aW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAg ICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAg ICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRl eC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMjMgfQ0K DQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbENudG5SZXFEYXRhTXNsb3RzIE9CSkVDVC1U WVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXI2NA0KICAgICAgICBNQVgtQUNDRVNTICBy ZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElP Tg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwg b2YgY29udGVudGlvbg0KICAgICAgICAgICAgIHJlcXVlc3QgZGF0YSBtaW5pc2xvdHMgZGVmaW5l ZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2FsDQogICAgICAgICAgICAgY2hhbm5lbC4gVGhpcyBj b3VudCBpbmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMyDQogICAgICAgICAgICAgYXNzaWdu ZWQgdG8gYSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBvbiB0aGUgbG9naWNhbA0KICAgICAg ICAgICAgIGNoYW5uZWwuIFRoaXMgaXMgdGhlIDY0IGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAg ICAgZG9jc0lmQ210c1VwQ2hubEN0clRvdGFsQ250blJlcURhdGFNc2xvdHMsIGFuZCB3aWxsIG5v dCBiZQ0KICAgICAgICAgICAgIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLiBTdXBwb3J0 IGZvciB0aGlzIG9iamVjdCBpcw0KICAgICAgICAgICAgIG9wdGlvbmFsLiBJZiB0aGUgb2JqZWN0 IGlzIG5vdCBzdXBwb3J0ZWQsIGEgdmFsdWUgb2YgemVybw0KICAgICAgICAgICAgIGlzIHJldHVy bmVkLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBj b3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhl IG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRp Y2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250 aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRv Y3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMjQgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxD dHJFeHRVc2VkQ250blJlcURhdGFNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAg ICAgQ291bnRlcjY0DQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFU VVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVu dCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAg ICAgICAgcmVxdWVzdCBkYXRhIG1pbmlzbG90cyB1dGlsaXplZCBvbiB0aGlzIHVwc3RyZWFtIGxv Z2ljYWwNCiAgICAgICAgICAgICBjaGFubmVsLiBUaGlzIGluY2x1ZGVzIGFsbCBjb250ZW50aW9u IG1pbmlzbG90cyBmb3IgSVVDMg0KICAgICAgICAgICAgIGFwcGxpY2FibGUgdG8gYnVyc3RzIHRo YXQgdGhlIENNVFMgY29ycmVjdGx5IHJlY2VpdmVkLiAgICANCiAgICAgICAgICAgICBUaGlzIGlz IHRoZSA2NCBiaXQgdmVyc2lvbiBvZg0KICAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJV c2VkQ250blJlcURhdGFNc2xvdHMsIGFuZCB3aWxsIG5vdCBiZQ0KICAgICAgICAgICAgIGFjY2Vz c2libGUgdG8gU05NUHYxIG1hbmFnZXJzLiBTdXBwb3J0IGZvciB0aGlzIG9iamVjdCBpcw0KICAg ICAgICAgICAgIG9wdGlvbmFsLiBJZiB0aGUgb2JqZWN0IGlzIG5vdCBzdXBwb3J0ZWQsIGEgdmFs dWUgb2YgemVybw0KICAgICAgICAgICAgIGlzIHJldHVybmVkLg0KICAgICAgICAgICAgIERpc2Nv bnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAg ICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQg b3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBv ZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29j aWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVy RW50cnkgMjUgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRDb2xsQ250blJlcURhdGFNc2xv dHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1B WC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRp YWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgcmVxdWVzdCBkYXRhIG1pbmlz bG90cyBzdWJqZWN0ZWQgdG8gY29sbGlzaW9ucyBvbiB0aGlzDQogICAgICAgICAgICAgdXBzdHJl YW0gbG9naWNhbCBjaGFubmVsLiBUaGlzIGluY2x1ZGVzIGFsbCBjb250ZW50aW9uDQogICAgICAg ICAgICAgbWluaXNsb3RzIGZvciBJVUMyIGFwcGxpY2FibGUgdG8gYnVyc3RzIHRoYXQgdGhlIENN VFMNCiAgICAgICAgICAgICBkZXRlY3RlZCwgYnV0IGNvdWxkIG5vdCBjb3JyZWN0bHkgcmVjZWl2 ZS4gVGhpcyBpcyB0aGUNCiAgICAgICAgICAgICA2NCBiaXQgdmVyc2lvbiBvZg0KICAgICAgICAg ICAgIGRvY3NJZkNtdHNVcENobmxDdHJDb2xsQ250blJlcURhdGFNc2xvdHMsDQogICAgICAgICAg ICAgYW5kIHdpbGwgbm90IGJlIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLiBTdXBwb3J0 DQogICAgICAgICAgICAgZm9yIHRoaXMgb2JqZWN0IGlzIG9wdGlvbmFsLiBJZiB0aGUgb2JqZWN0 IGlzIG5vdA0KICAgICAgICAgICAgIHN1cHBvcnRlZCwgYSB2YWx1ZSBvZiB6ZXJvIGlzIHJldHVy bmVkLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBj b3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhl IG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRp Y2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250 aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRv Y3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMjYgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxD dHJFeHRUb3RhbENudG5Jbml0TWFpbnRNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFY ICAgICAgQ291bnRlcjY0DQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBT VEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3Vy cmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBpbml0aWFsDQogICAgICAg ICAgICAgbWFpbnRlbmFuY2UgbWluaXNsb3RzIGRlZmluZWQgZm9yIHRoaXMgdXBzdHJlYW0gbG9n aWNhbA0KICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgY291bnQgaW5jbHVkZXMgYWxsIG1pbmlz bG90cyBmb3IgSVVDMw0KICAgICAgICAgICAgIGFzc2lnbmVkIHRvIGEgYnJvYWRjYXN0IG9yIG11 bHRpY2FzdCBTSUQgb24gdGhlIGxvZ2ljYWwNCiAgICAgICAgICAgICBjaGFubmVsLiBUaGlzIGlz IHRoZSA2NCBiaXQgdmVyc2lvbiBvZiANCiAgICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3Ry VG90YWxDbnRuSW5pdE1haW50TXNsb3RzLA0KICAgICAgICAgICAgIGFuZCB3aWxsIG5vdCBiZSBh Y2Nlc3NpYmxlIHRvIFNOTVB2MSBtYW5hZ2Vycy4gU3VwcG9ydCBmb3INCiAgICAgICAgICAgICB0 aGlzIG9iamVjdCBpcyBvcHRpb25hbC4gSWYgdGhlIG9iamVjdCBpcyBub3Qgc3VwcG9ydGVkLA0K ICAgICAgICAgICAgIGEgdmFsdWUgb2YgemVybyBpcyByZXR1cm5lZC4NCiAgICAgICAgICAgICBE aXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAg ICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5k IGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFs dWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBh c3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291 bnRlckVudHJ5IDI3IH0NCg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0VXNlZENudG5Jbml0TWFp bnRNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAg ICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQog ICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRT IGluaXRpYWxpemF0aW9uLCBvZiBpbml0aWFsDQogICAgICAgICAgICAgbWFpbnRlbmFuY2UgbWlu aXNsb3RzIHV0aWxpemVkIG9uIHRoaXMgdXBzdHJlYW0gbG9naWNhbA0KICAgICAgICAgICAgIGNo YW5uZWwuIFRoaXMgaW5jbHVkZXMgYWxsIGNvbnRlbnRpb24gbWluaXNsb3RzIGZvciBJVUMzDQog ICAgICAgICAgICAgYXBwbGljYWJsZSB0byBidXJzdHMgdGhhdCB0aGUgQ01UUyBjb3JyZWN0bHkg cmVjZWl2ZWQuICAgIA0KICAgICAgICAgICAgIFRoaXMgaXMgdGhlIDY0IGJpdCB2ZXJzaW9uIG9m DQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0clVzZWRDbnRuSW5pdE1haW50TXNsb3Rz LA0KICAgICAgICAgICAgIGFuZCB3aWxsIG5vdCBiZSBhY2Nlc3NpYmxlIHRvIFNOTVB2MSBtYW5h Z2Vycy4gU3VwcG9ydCBmb3INCiAgICAgICAgICAgICB0aGlzIG9iamVjdCBpcyBvcHRpb25hbC4g SWYgdGhlIG9iamVjdCBpcyBub3Qgc3VwcG9ydGVkLA0KICAgICAgICAgICAgIGEgdmFsdWUgb2Yg emVybyBpcyByZXR1cm5lZC4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZh bHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxp emF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAg dGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZD b3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAg ICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDI4IH0NCg0KDQpkb2Nz SWZDbXRzVXBDaG5sQ3RyRXh0Q29sbENudG5Jbml0TWFpbnRNc2xvdHMgT0JKRUNULVRZUEUNCiAg ICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25s eQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAg ICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250 ZW50aW9uDQogICAgICAgICAgICAgaW5pdGlhbCBtYWludGVuYW5jZSBtaW5pc2xvdHMgc3ViamVj dGVkIHRvIGNvbGxpc2lvbnMgb24NCiAgICAgICAgICAgICB0aGlzIHVwc3RyZWFtIGxvZ2ljYWwg Y2hhbm5lbC4gVGhpcyBpbmNsdWRlcyBhbGwNCiAgICAgICAgICAgICBjb250ZW50aW9uIG1pbmlz bG90cyBmb3IgSVVDMyBhcHBsaWNhYmxlIHRvIGJ1cnN0cyB0aGF0DQogICAgICAgICAgICAgdGhl IENNVFMgZGV0ZWN0ZWQsIGJ1dCBjb3VsZCBub3QgY29ycmVjdGx5IHJlY2VpdmUuICAgICAgIA0K ICAgICAgICAgICAgIFRoaXMgaXMgdGhlIDY0IGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAgICAg ZG9jc0lmQ210c1VwQ2hubEN0ckNvbGxDbnRuSW5pdE1haW50TXNsb3RzLCBhbmQgd2lsbCBub3QN CiAgICAgICAgICAgICBiZSBhY2Nlc3NpYmxlIHRvIFNOTVB2MSBtYW5hZ2Vycy4gU3VwcG9ydCBm b3IgdGhpcyBvYmplY3QNCiAgICAgICAgICAgICBpcyBvcHRpb25hbC4gSWYgdGhlIG9iamVjdCBp cyBub3Qgc3VwcG9ydGVkLCBhIHZhbHVlIG9mDQogICAgICAgICAgICAgemVybyBpcyByZXR1cm5l ZC4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291 bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBt YW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNh dGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGlu dWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2Nz SWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDI5IH0NCg0KDQpXSVRIOg0KDQpkb2NzSWZDbXRz VXBDaG5sQ3RyQ29sbENudG5Nc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAg Q291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMg ICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBj b3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAg ICAgbWluaXNsb3RzIHN1YmplY3RlZCB0byBjb2xsaXNpb25zIG9uIHRoZSB1cHN0cmVhbSBsb2dp Y2FsDQogICAgICAgICAgICAgY2hhbm5lbC4gRm9yIGNvbnRlbnRpb24gcmVnaW9ucywgdGhlc2Ug YXJlIHRoZSBtaW5pc2xvdHMNCiAgICAgICAgICAgICBhcHBsaWNhYmxlIHRvIGJ1cnN0cyB0aGF0 IHRoZSBDTVRTIGRldGVjdGVkLCBidXQgY291bGQgbm90DQogICAgICAgICAgICAgY29ycmVjdGx5 IHJlY2VpdmUuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAgICAgZG9j c0lmQ210c1VwQ2hubEN0ckV4dENvbGxDbnRuTXNsb3RzLCBhbmQgaXMgaW5jbHVkZWQgZm9yDQog ICAgICAgICAgICAgYmFjayBjb21wYXRpYmlsaXR5IHdpdGggU05NUHYxIG1hbmFnZXJzLg0KICAg ICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNh biBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQg c3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkg dGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGlt ZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNV cENoYW5uZWxDb3VudGVyRW50cnkgMTAgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJUb3RhbENu dG5SZXFNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQog ICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50 DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBD TVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgcmVxdWVzdCBt aW5pc2xvdHMgZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2FsDQogICAgICAgICAgICAg Y2hhbm5lbC4gVGhpcyBjb3VudCBpbmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMxDQogICAg ICAgICAgICAgYXNzaWduZWQgdG8gYSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBvbiB0aGUg bG9naWNhbA0KICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9u IG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRvdGFsQ250blJlcU1zbG90 cywgYW5kIGlzIGluY2x1ZGVkDQogICAgICAgICAgICAgZm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3 aXRoIFNOTVB2MSBtYW5hZ2Vycy4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhl IHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRp YWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAg ICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAg aWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0K ICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDExIH0NCg0KDQpk b2NzSWZDbXRzVXBDaG5sQ3RyVXNlZENudG5SZXFNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAg U1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAg ICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAg ICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250ZW50aW9u DQogICAgICAgICAgICAgcmVxdWVzdCBtaW5pc2xvdHMgdXRpbGl6ZWQgb24gdGhpcyB1cHN0cmVh bSBsb2dpY2FsDQogICAgICAgICAgICAgY2hhbm5lbC4gVGhpcyBjb3VudCBpbmNsdWRlcyBhbGwg Y29udGVudGlvbiBtaW5pc2xvdHMgZm9yDQogICAgICAgICAgICAgSVVDMSBhcHBsaWNhYmxlIHRv IGJ1cnN0cyB0aGF0IHRoZSBDTVRTIGNvcnJlY3RseQ0KICAgICAgICAgICAgIHJlY2VpdmVkLiBU aGlzIGlzIHRoZSAzMiBiaXQgdmVyc2lvbiBvZg0KICAgICAgICAgICAgIGRvY3NJZkNtdHNVcENo bmxDdHJFeHRVc2VkQ250blJlcU1zbG90cywgYW5kIGlzIGluY2x1ZGVkDQogICAgICAgICAgICAg Zm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2MSBtYW5hZ2Vycy4NCiAgICAgICAgICAg ICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXIN CiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwg YW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUg dmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRo ZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVs Q291bnRlckVudHJ5IDEyIH0NCg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3RyQ29sbENudG5SZXFNc2xv dHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAgIE1B WC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRp YWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgcmVxdWVzdCBtaW5pc2xvdHMg c3ViamVjdGVkIHRvIGNvbGxpc2lvbnMgb24gdGhpcyB1cHN0cmVhbQ0KICAgICAgICAgICAgIGxv Z2ljYWwgY2hhbm5lbC4gVGhpcyBpbmNsdWRlcyBhbGwgY29udGVudGlvbiBtaW5pc2xvdHMNCiAg ICAgICAgICAgICBmb3IgSVVDMSBhcHBsaWNhYmxlIHRvIGJ1cnN0cyB0aGF0IHRoZSBDTVRTIGRl dGVjdGVkLCBidXQNCiAgICAgICAgICAgICBjb3VsZCBub3QgY29ycmVjdGx5IHJlY2VpdmUuIFRo aXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hu bEN0ckV4dENvbGxDbnRuUmVxTXNsb3RzLCBhbmQgaXMgaW5jbHVkZWQNCiAgICAgICAgICAgICBm b3IgYmFjayBjb21wYXRpYmlsaXR5IHdpdGggU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAgICAg IERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0K ICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBh bmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2 YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhl IGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxD b3VudGVyRW50cnkgMTMgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJUb3RhbENudG5SZXFEYXRh TXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgICAg ICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAg ICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20gQ01UUyBp bml0aWFsaXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAgIHJlcXVlc3QgZGF0YSBt aW5pc2xvdHMgZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2FsDQogICAgICAgICAgICAg Y2hhbm5lbC4gVGhpcyBjb3VudCBpbmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMyDQogICAg ICAgICAgICAgYXNzaWduZWQgdG8gYSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBvbiB0aGUg bG9naWNhbA0KICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9u IG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRvdGFsQ250blJlcURhdGFN c2xvdHMsIGFuZCBpcw0KICAgICAgICAgICAgIGluY2x1ZGVkIGZvciBiYWNrIGNvbXBhdGliaWxp dHkgd2l0aCBTTk1QdjEgbWFuYWdlcnMuDQogICAgICAgICAgICAgRGlzY29udGludWl0aWVzIGlu IHRoZSB2YWx1ZSBvZiB0aGlzIGNvdW50ZXIgY2FuIG9jY3VyDQogICAgICAgICAgICAgYXQgcmVp bml0aWFsaXphdGlvbiBvZiB0aGUgbWFuYWdlZCBzeXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAg ICAgICAgIHRpbWVzIGFzIGluZGljYXRlZCBieSB0aGUgdGhlIHZhbHVlIG9mIA0KICAgICAgICAg ICAgIGlmQ291bnRlckRpc2NvbnRpbnVpdHlUaW1lIGZvciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4 LiINCiAgICAgICAgOjo9IHsgZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50ZXJFbnRyeSAxNCB9DQoN Cg0KZG9jc0lmQ210c1VwQ2hubEN0clVzZWRDbnRuUmVxRGF0YU1zbG90cyBPQkpFQ1QtVFlQRQ0K ICAgICAgICBTWU5UQVggICAgICBDb3VudGVyMzINCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1v bmx5DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAg ICAgICAgICAgICJDdXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRpb24sIG9mIGNv bnRlbnRpb24NCiAgICAgICAgICAgICByZXF1ZXN0IGRhdGEgbWluaXNsb3RzIHV0aWxpemVkIG9u IHRoaXMgdXBzdHJlYW0gbG9naWNhbA0KICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgaW5jbHVk ZXMgYWxsIGNvbnRlbnRpb24gbWluaXNsb3RzIGZvciBJVUMyDQogICAgICAgICAgICAgYXBwbGlj YWJsZSB0byBidXJzdHMgdGhhdCB0aGUgQ01UUyBjb3JyZWN0bHkgcmVjZWl2ZWQuDQogICAgICAg ICAgICAgVGhpcyBpcyB0aGUgMzIgYml0IHZlcnNpb24gb2YgDQogICAgICAgICAgICAgZG9jc0lm Q210c1VwQ2hubEN0ckV4dFVzZWRDbnRuUmVxRGF0YU1zbG90cywgYW5kIGlzDQogICAgICAgICAg ICAgaW5jbHVkZWQgZm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2MSBtYW5hZ2Vycy4N CiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRl ciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5h Z2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVk IGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0 eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZD bXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDE1IH0NCg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3RyQ29s bENudG5SZXFEYXRhTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50 ZXIzMg0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAg Y3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQs IGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAgIHJl cXVlc3QgZGF0YSBtaW5pc2xvdHMgc3ViamVjdGVkIHRvIGNvbGxpc2lvbnMgb24gdGhpcw0KICAg ICAgICAgICAgIHVwc3RyZWFtIGxvZ2ljYWwgY2hhbm5lbC4gVGhpcyBpbmNsdWRlcyBhbGwgY29u dGVudGlvbg0KICAgICAgICAgICAgIG1pbmlzbG90cyBmb3IgSVVDMiBhcHBsaWNhYmxlIHRvIGJ1 cnN0cyB0aGF0IHRoZSBDTVRTDQogICAgICAgICAgICAgZGV0ZWN0ZWQsIGJ1dCBjb3VsZCBub3Qg Y29ycmVjdGx5IHJlY2VpdmUuIFRoaXMgaXMgdGhlIDMyDQogICAgICAgICAgICAgYml0IHZlcnNp b24gb2YNCiAgICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0Q29sbENudG5SZXFEYXRh TXNsb3RzLCBhbmQgaXMNCiAgICAgICAgICAgICBpbmNsdWRlZCBmb3IgYmFjayBjb21wYXRpYmls aXR5IHdpdGggU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBp biB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJl aW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAg ICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAg ICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRl eC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMTYgfQ0K DQoNCmRvY3NJZkNtdHNVcENobmxDdHJUb3RhbENudG5Jbml0TWFpbnRNc2xvdHMgT0JKRUNULVRZ UEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJl YWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9O DQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBv ZiBjb250ZW50aW9uDQogICAgICAgICAgICAgaW5pdGlhbCBtYWludGVuYW5jZSBtaW5pc2xvdHMg ZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbQ0KICAgICAgICAgICAgIGxvZ2ljYWwgY2hhbm5lbC4g VGhpcyBpbmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMzDQogICAgICAgICAgICAgYXNzaWdu ZWQgdG8gYSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBvbiB0aGUgbG9naWNhbA0KICAgICAg ICAgICAgIGNoYW5uZWwuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAg ICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRvdGFsQ250bkluaXRNYWludE1zbG90cywNCiAgICAg ICAgICAgICBhbmQgaXMgaW5jbHVkZWQgZm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2 MQ0KICAgICAgICAgICAgIG1hbmFnZXJzLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBp biB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJl aW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAg ICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAg ICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRl eC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMTcgfQ0K DQoNCmRvY3NJZkNtdHNVcENobmxDdHJVc2VkQ250bkluaXRNYWludE1zbG90cyBPQkpFQ1QtVFlQ RQ0KICAgICAgICBTWU5UQVggICAgICBDb3VudGVyMzINCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVh ZC1vbmx5DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04N CiAgICAgICAgICAgICJDdXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRpb24sIG9m IGNvbnRlbnRpb24NCiAgICAgICAgICAgICBpbml0aWFsIG1haW50ZW5hbmNlIG1pbmlzbG90cyB1 dGlsaXplZCBvbiB0aGlzIHVwc3RyZWFtDQogICAgICAgICAgICAgbG9naWNhbCBjaGFubmVsLiBU aGlzIGluY2x1ZGVzIGFsbCBjb250ZW50aW9uIG1pbmlzbG90cw0KICAgICAgICAgICAgIGZvciBJ VUMzIGFwcGxpY2FibGUgdG8gYnVyc3RzIHRoYXQgdGhlIENNVFMgY29ycmVjdGx5DQogICAgICAg ICAgICAgcmVjZWl2ZWQuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9uIG9mIA0KICAgICAgICAg ICAgIGRvY3NJZkNtdHNVcENobmxDdHJFeHRVc2VkQ250bkluaXRNYWludE1zbG90cywNCiAgICAg ICAgICAgICBhbmQgaXMgaW5jbHVkZWQgZm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2 MQ0KICAgICAgICAgICAgIG1hbmFnZXJzLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBp biB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJl aW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAg ICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAg ICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRl eC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMTggfQ0K DQoNCmRvY3NJZkNtdHNVcENobmxDdHJDb2xsQ250bkluaXRNYWludE1zbG90cyBPQkpFQ1QtVFlQ RQ0KICAgICAgICBTWU5UQVggICAgICBDb3VudGVyMzINCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVh ZC1vbmx5DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04N CiAgICAgICAgICAgICJDdXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRpb24sIG9m IGNvbnRlbnRpb24NCiAgICAgICAgICAgICBpbml0aWFsIG1haW50ZW5hbmNlIG1pbmlzbG90cyBz dWJqZWN0ZWQgdG8gY29sbGlzaW9ucyBvbg0KICAgICAgICAgICAgIHRoaXMgdXBzdHJlYW0gbG9n aWNhbCBjaGFubmVsLiBUaGlzIGluY2x1ZGVzIGFsbA0KICAgICAgICAgICAgIGNvbnRlbnRpb24g bWluaXNsb3RzIGZvciBJVUMzIGFwcGxpY2FibGUgdG8gYnVyc3RzIHRoYXQNCiAgICAgICAgICAg ICB0aGUgQ01UUyBkZXRlY3RlZCwgYnV0IGNvdWxkIG5vdCBjb3JyZWN0bHkgcmVjZWl2ZS4gICAg ICAgDQogICAgICAgICAgICAgVGhpcyBpcyB0aGUgMzIgYml0IHZlcnNpb24gb2YgDQogICAgICAg ICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dENvbGxDbnRuSW5pdE1haW50TXNsb3RzLA0KICAg ICAgICAgICAgIGFuZCBpcyBpbmNsdWRlZCBmb3IgYmFjayBjb21wYXRpYmlsaXR5IHdpdGggU05N UHYxDQogICAgICAgICAgICAgbWFuYWdlcnMuDQogICAgICAgICAgICAgRGlzY29udGludWl0aWVz IGluIHRoZSB2YWx1ZSBvZiB0aGlzIGNvdW50ZXIgY2FuIG9jY3VyDQogICAgICAgICAgICAgYXQg cmVpbml0aWFsaXphdGlvbiBvZiB0aGUgbWFuYWdlZCBzeXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAg ICAgICAgICAgIHRpbWVzIGFzIGluZGljYXRlZCBieSB0aGUgdGhlIHZhbHVlIG9mIA0KICAgICAg ICAgICAgIGlmQ291bnRlckRpc2NvbnRpbnVpdHlUaW1lIGZvciB0aGUgYXNzb2NpYXRlZCBpZklu ZGV4LiINCiAgICAgICAgOjo9IHsgZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50ZXJFbnRyeSAxOSB9 DQoNCg0KZG9jc0lmQ210c1VwQ2hubEN0ckV4dENvbGxDbnRuTXNsb3RzIE9CSkVDVC1UWVBFDQog ICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXI2NA0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9u bHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAg ICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29s bGlzaW9uDQogICAgICAgICAgICAgY29udGVudGlvbiBtaW5pc2xvdHMgb24gdGhlIHVwc3RyZWFt IGxvZ2ljYWwgY2hhbm5lbC4NCiAgICAgICAgICAgICBGb3IgY29udGVudGlvbiByZWdpb25zLCB0 aGVzZSBhcmUgdGhlIG1pbmlzbG90cyBhcHBsaWNhYmxlDQogICAgICAgICAgICAgdG8gYnVyc3Rz IHRoYXQgdGhlIENNVFMgZGV0ZWN0ZWQsIGJ1dCBjb3VsZCBub3QgY29ycmVjdGx5DQogICAgICAg ICAgICAgcmVjZWl2ZS4gVGhpcyBpcyB0aGUgNjQgYml0IHZlcnNpb24gb2YNCiAgICAgICAgICAg ICBkb2NzSWZDbXRzVXBDaG5sQ3RyQ29sbENudG5Nc2xvdHMsIGFuZCB3aWxsIG5vdCBiZQ0KICAg ICAgICAgICAgIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAgICAgIERp c2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAg ICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQg YXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1 ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFz c29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3Vu dGVyRW50cnkgMjAgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbENudG5SZXFNc2xv dHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1B WC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRp YWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgcmVxdWVzdCBtaW5pc2xvdHMg ZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2FsDQogICAgICAgICAgICAgY2hhbm5lbC4g VGhpcyBjb3VudCBpbmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMxDQogICAgICAgICAgICAg YXNzaWduZWQgdG8gYSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBvbiB0aGUgbG9naWNhbA0K ICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgaXMgdGhlIDY0IGJpdCB2ZXJzaW9uIG9mDQogICAg ICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0clRvdGFsQ250blJlcU1zbG90cywgYW5kIHdpbGwg bm90IGJlDQogICAgICAgICAgICAgYWNjZXNzaWJsZSB0byBTTk1QdjEgbWFuYWdlcnMuDQogICAg ICAgICAgICAgRGlzY29udGludWl0aWVzIGluIHRoZSB2YWx1ZSBvZiB0aGlzIGNvdW50ZXIgY2Fu IG9jY3VyDQogICAgICAgICAgICAgYXQgcmVpbml0aWFsaXphdGlvbiBvZiB0aGUgbWFuYWdlZCBz eXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAgICAgICAgIHRpbWVzIGFzIGluZGljYXRlZCBieSB0 aGUgdGhlIHZhbHVlIG9mIA0KICAgICAgICAgICAgIGlmQ291bnRlckRpc2NvbnRpbnVpdHlUaW1l IGZvciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4LiINCiAgICAgICAgOjo9IHsgZG9jc0lmQ210c1Vw Q2hhbm5lbENvdW50ZXJFbnRyeSAyMSB9DQoNCg0KZG9jc0lmQ210c1VwQ2hubEN0ckV4dFVzZWRD bnRuUmVxTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXI2NA0K ICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVu dA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20g Q01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAgIHJlcXVlc3Qg bWluaXNsb3RzIHV0aWxpemVkIG9uIHRoaXMgdXBzdHJlYW0gbG9naWNhbA0KICAgICAgICAgICAg IGNoYW5uZWwuIFRoaXMgY291bnQgaW5jbHVkZXMgYWxsIGNvbnRlbnRpb24gbWluaXNsb3RzIGZv cg0KICAgICAgICAgICAgIElVQzEgYXBwbGljYWJsZSB0byBidXJzdHMgdGhhdCB0aGUgQ01UUyBj b3JyZWN0bHkNCiAgICAgICAgICAgICByZWNlaXZlZC4gVGhpcyBpcyB0aGUgNjQgYml0IHZlcnNp b24gb2YNCiAgICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyVXNlZENudG5SZXFNc2xvdHMs IGFuZCB3aWxsIG5vdCBiZQ0KICAgICAgICAgICAgIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFn ZXJzLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBj b3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhl IG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRp Y2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250 aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRv Y3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMjIgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxD dHJFeHRDb2xsQ250blJlcU1zbG90cyBPQkpFQ1QtVFlQRQ0KICAgICAgICBTWU5UQVggICAgICBD b3VudGVyNjQNCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgICAgIFNUQVRVUyAg ICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJDdXJyZW50IGNv dW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRpb24sIG9mIGNvbnRlbnRpb24NCiAgICAgICAgICAg ICByZXF1ZXN0IG1pbmlzbG90cyBzdWJqZWN0ZWQgdG8gY29sbGlzaW9ucyBvbiB0aGlzIHVwc3Ry ZWFtDQogICAgICAgICAgICAgbG9naWNhbCBjaGFubmVsLiBUaGlzIGluY2x1ZGVzIGFsbCBjb250 ZW50aW9uIG1pbmlzbG90cw0KICAgICAgICAgICAgIGZvciBJVUMxIGFwcGxpY2FibGUgdG8gYnVy c3RzIHRoYXQgdGhlIENNVFMgZGV0ZWN0ZWQsDQogICAgICAgICAgICAgYnV0IGNvdWxkIG5vdCBj b3JyZWN0bHkgcmVjZWl2ZS4gVGhpcyBpcyB0aGUgNjQgYml0DQogICAgICAgICAgICAgdmVyc2lv biBvZiBkb2NzSWZDbXRzVXBDaG5sQ3RyQ29sbENudG5SZXFNc2xvdHMsIGFuZCB3aWxsDQogICAg ICAgICAgICAgbm90IGJlIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAg ICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1 cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVt LCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRo ZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3Ig dGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5u ZWxDb3VudGVyRW50cnkgMjMgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbENudG5S ZXFEYXRhTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXI2NA0K ICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVu dA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20g Q01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAgIHJlcXVlc3Qg ZGF0YSBtaW5pc2xvdHMgZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2FsDQogICAgICAg ICAgICAgY2hhbm5lbC4gVGhpcyBjb3VudCBpbmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMy DQogICAgICAgICAgICAgYXNzaWduZWQgdG8gYSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBv biB0aGUgbG9naWNhbA0KICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgaXMgdGhlIDY0IGJpdCB2 ZXJzaW9uIG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0clRvdGFsQ250blJlcURh dGFNc2xvdHMsIGFuZCB3aWxsIG5vdCBiZQ0KICAgICAgICAgICAgIGFjY2Vzc2libGUgdG8gU05N UHYxIG1hbmFnZXJzLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUg b2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRp b24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1l cyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50 ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAg IDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMjQgfQ0KDQoNCmRvY3NJZkNt dHNVcENobmxDdHJFeHRVc2VkQ250blJlcURhdGFNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAg U1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAg ICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAg ICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250ZW50aW9u DQogICAgICAgICAgICAgcmVxdWVzdCBkYXRhIG1pbmlzbG90cyB1dGlsaXplZCBvbiB0aGlzIHVw c3RyZWFtIGxvZ2ljYWwNCiAgICAgICAgICAgICBjaGFubmVsLiBUaGlzIGluY2x1ZGVzIGFsbCBj b250ZW50aW9uIG1pbmlzbG90cyBmb3IgSVVDMg0KICAgICAgICAgICAgIGFwcGxpY2FibGUgdG8g YnVyc3RzIHRoYXQgdGhlIENNVFMgY29ycmVjdGx5IHJlY2VpdmVkLiAgICANCiAgICAgICAgICAg ICBUaGlzIGlzIHRoZSA2NCBiaXQgdmVyc2lvbiBvZg0KICAgICAgICAgICAgIGRvY3NJZkNtdHNV cENobmxDdHJVc2VkQ250blJlcURhdGFNc2xvdHMsIGFuZCB3aWxsIG5vdCBiZQ0KICAgICAgICAg ICAgIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAgICAgIERpc2NvbnRp bnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAg ICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3Ro ZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiAN CiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0 ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50 cnkgMjUgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRDb2xsQ250blJlcURhdGFNc2xvdHMg T0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1BWC1B Q0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERF U0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxp emF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgcmVxdWVzdCBkYXRhIG1pbmlzbG90 cyBzdWJqZWN0ZWQgdG8gY29sbGlzaW9ucyBvbiB0aGlzDQogICAgICAgICAgICAgdXBzdHJlYW0g bG9naWNhbCBjaGFubmVsLiBUaGlzIGluY2x1ZGVzIGFsbCBjb250ZW50aW9uDQogICAgICAgICAg ICAgbWluaXNsb3RzIGZvciBJVUMyIGFwcGxpY2FibGUgdG8gYnVyc3RzIHRoYXQgdGhlIENNVFMN CiAgICAgICAgICAgICBkZXRlY3RlZCwgYnV0IGNvdWxkIG5vdCBjb3JyZWN0bHkgcmVjZWl2ZS4g VGhpcyBpcyB0aGUNCiAgICAgICAgICAgICA2NCBiaXQgdmVyc2lvbiBvZg0KICAgICAgICAgICAg IGRvY3NJZkNtdHNVcENobmxDdHJDb2xsQ250blJlcURhdGFNc2xvdHMsDQogICAgICAgICAgICAg YW5kIHdpbGwgbm90IGJlIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAg ICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1 cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVt LCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRo ZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3Ig dGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5u ZWxDb3VudGVyRW50cnkgMjYgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbENudG5J bml0TWFpbnRNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0 DQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJy ZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJv bSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBpbml0aWFsDQogICAgICAgICAgICAgbWFpbnRlbmFu Y2UgbWluaXNsb3RzIGRlZmluZWQgZm9yIHRoaXMgdXBzdHJlYW0gbG9naWNhbA0KICAgICAgICAg ICAgIGNoYW5uZWwuIFRoaXMgY291bnQgaW5jbHVkZXMgYWxsIG1pbmlzbG90cyBmb3IgSVVDMw0K ICAgICAgICAgICAgIGFzc2lnbmVkIHRvIGEgYnJvYWRjYXN0IG9yIG11bHRpY2FzdCBTSUQgb24g dGhlIGxvZ2ljYWwNCiAgICAgICAgICAgICBjaGFubmVsLiBUaGlzIGlzIHRoZSA2NCBiaXQgdmVy c2lvbiBvZiANCiAgICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyVG90YWxDbnRuSW5pdE1h aW50TXNsb3RzLA0KICAgICAgICAgICAgIGFuZCB3aWxsIG5vdCBiZSBhY2Nlc3NpYmxlIHRvIFNO TVB2MSBtYW5hZ2Vycy4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVl IG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0 aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGlt ZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3Vu dGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAg ICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDI3IH0NCg0KDQpkb2NzSWZD bXRzVXBDaG5sQ3RyRXh0VXNlZENudG5Jbml0TWFpbnRNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAg ICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0K ICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAg ICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBpbml0aWFs DQogICAgICAgICAgICAgbWFpbnRlbmFuY2UgbWluaXNsb3RzIHV0aWxpemVkIG9uIHRoaXMgdXBz dHJlYW0gbG9naWNhbA0KICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgaW5jbHVkZXMgYWxsIGNv bnRlbnRpb24gbWluaXNsb3RzIGZvciBJVUMzDQogICAgICAgICAgICAgYXBwbGljYWJsZSB0byBi dXJzdHMgdGhhdCB0aGUgQ01UUyBjb3JyZWN0bHkgcmVjZWl2ZWQuICAgIA0KICAgICAgICAgICAg IFRoaXMgaXMgdGhlIDY0IGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1Vw Q2hubEN0clVzZWRDbnRuSW5pdE1haW50TXNsb3RzLA0KICAgICAgICAgICAgIGFuZCB3aWxsIG5v dCBiZSBhY2Nlc3NpYmxlIHRvIFNOTVB2MSBtYW5hZ2Vycy4NCiAgICAgICAgICAgICBEaXNjb250 aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAg ICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90 aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2Yg DQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lh dGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVu dHJ5IDI4IH0NCg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0Q29sbENudG5Jbml0TWFpbnRNc2xv dHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1B WC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRp YWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgaW5pdGlhbCBtYWludGVuYW5j ZSBtaW5pc2xvdHMgc3ViamVjdGVkIHRvIGNvbGxpc2lvbnMgb24NCiAgICAgICAgICAgICB0aGlz IHVwc3RyZWFtIGxvZ2ljYWwgY2hhbm5lbC4gVGhpcyBpbmNsdWRlcyBhbGwNCiAgICAgICAgICAg ICBjb250ZW50aW9uIG1pbmlzbG90cyBmb3IgSVVDMyBhcHBsaWNhYmxlIHRvIGJ1cnN0cyB0aGF0 DQogICAgICAgICAgICAgdGhlIENNVFMgZGV0ZWN0ZWQsIGJ1dCBjb3VsZCBub3QgY29ycmVjdGx5 IHJlY2VpdmUuICAgICAgIA0KICAgICAgICAgICAgIFRoaXMgaXMgdGhlIDY0IGJpdCB2ZXJzaW9u IG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckNvbGxDbnRuSW5pdE1haW50TXNs b3RzLCBhbmQgd2lsbCBub3QNCiAgICAgICAgICAgICBiZSBhY2Nlc3NpYmxlIHRvIFNOTVB2MSBt YW5hZ2Vycy4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRo aXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9m IHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMg aW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlz Y29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0g eyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDI5IH0NClJlbW92ZSBUZXh0ICJTdXBw b3J0IGZvciB0aGlzIG9iamVjdCBpcyBtYW5kYXRvcnkuIg0KYikgUkVQTEFDRQ0KDQpkb2NzSWZD bXRzVXBDaG5sQ3RyVG90YWxNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAg Q291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMg ICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBj b3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBhbGwgbWluaXNsb3RzDQogICAgICAg ICAgICAgZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2FsIGNoYW5uZWwuIFRoaXMgY291 bnQNCiAgICAgICAgICAgICBpbmNsdWRlcyBhbGwgSVVDcyBhbmQgU0lEcywgZXZlbiB0aG9zZSBh bGxvY2F0ZWQgdG8gdGhlDQogICAgICAgICAgICAgTlVMTCBTSUQgZm9yIGEgMi4wIGxvZ2ljYWwg Y2hhbm5lbCB3aGljaCBpcyBpbmFjdGl2ZS4gVGhpcw0KICAgICAgICAgICAgIGlzIHRoZSAzMiBi aXQgdmVyc2lvbiBvZiBkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0VG90YWxNc2xvdHMNCiAgICAgICAg ICAgICBhbmQgaXMgaW5jbHVkZWQgZm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2MQ0K ICAgICAgICAgICAgIG1hbmFnZXJzLiBTdXBwb3J0IGZvciB0aGlzIG9iamVjdCBpcyBtYW5kYXRv cnkuDQogICAgICAgICAgICAgRGlzY29udGludWl0aWVzIGluIHRoZSB2YWx1ZSBvZiB0aGlzIGNv dW50ZXIgY2FuIG9jY3VyDQogICAgICAgICAgICAgYXQgcmVpbml0aWFsaXphdGlvbiBvZiB0aGUg bWFuYWdlZCBzeXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAgICAgICAgIHRpbWVzIGFzIGluZGlj YXRlZCBieSB0aGUgdGhlIHZhbHVlIG9mIA0KICAgICAgICAgICAgIGlmQ291bnRlckRpc2NvbnRp bnVpdHlUaW1lIGZvciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4LiINCiAgICAgICAgOjo9IHsgZG9j c0lmQ210c1VwQ2hhbm5lbENvdW50ZXJFbnRyeSAyIH0NCg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3Ry VWNhc3RHcmFudGVkTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50 ZXIzMg0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAg Y3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQs IGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgdW5pY2FzdA0KICAgICAgICAgICAgIGdyYW50 ZWQgbWluaXNsb3RzIG9uIHRoZSB1cHN0cmVhbSBsb2dpY2FsIGNoYW5uZWwsDQogICAgICAgICAg ICAgcmVnYXJkbGVzcyBvZiBidXJzdCB0eXBlLiBVbmljYXN0IGdyYW50ZWQgbWluaXNsb3RzIGFy ZQ0KICAgICAgICAgICAgIHRob3NlIGluIHdoaWNoIHRoZSBDTVRTIGFzc2lnbmVkIGJhbmR3aWR0 aCB0byBhbnkgdW5pY2FzdA0KICAgICAgICAgICAgIFNJRCBvbiB0aGUgbG9naWNhbCBjaGFubmVs LiBIb3dldmVyIHRoaXMgb2JqZWN0IGRvZXMgbm90DQogICAgICAgICAgICAgaW5jbHVkZSBtaW5p c2xvdHMgZm9yIHJlc2VydmVkIElVQ3MsIG9yIGdyYW50cyB0byBTSURzIA0KICAgICAgICAgICAg IGRlc2lnbmF0ZWQgYXMgbWVhbmluZyAnbm8gQ00nLiBUaGlzIGlzIHRoZSAzMiBiaXQgdmVyc2lv biANCiAgICAgICAgICAgICBvZiBkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0VWNhc3RHcmFudGVkTXNs b3RzLCBhbmQgaXMgDQogICAgICAgICAgICAgaW5jbHVkZWQgZm9yIGJhY2sgY29tcGF0aWJpbGl0 eSB3aXRoIFNOTVB2MSBtYW5hZ2Vycy4gDQogICAgICAgICAgICAgU3VwcG9ydCBmb3IgdGhpcyBv YmplY3QgaXMgbWFuZGF0b3J5Lg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUg dmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlh bGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAg ICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBp ZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQog ICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMyB9DQoNCg0KZG9j c0lmQ210c1VwQ2hubEN0clRvdGFsQ250bk1zbG90cyBPQkpFQ1QtVFlQRQ0KICAgICAgICBTWU5U QVggICAgICBDb3VudGVyMzINCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgICAg IFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJD dXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRpb24sIG9mIGNvbnRlbnRpb24NCiAg ICAgICAgICAgICBtaW5pc2xvdHMgZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2FsIGNo YW5uZWwuIFRoaXMNCiAgICAgICAgICAgICBjb3VudCBpbmNsdWRlcyBhbGwgbWluaXNsb3RzIGFz c2lnbmVkIHRvIGEgYnJvYWRjYXN0IG9yDQogICAgICAgICAgICAgbXVsdGljYXN0IFNJRCBvbiB0 aGUgbG9naWNhbCBjaGFubmVsLiBUaGlzIGlzIHRoZSAzMiBiaXQNCiAgICAgICAgICAgICB2ZXJz aW9uIG9mIGRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbENudG5Nc2xvdHMsIGFuZCBpcw0KICAg ICAgICAgICAgIGluY2x1ZGVkIGZvciBiYWNrIGNvbXBhdGliaWxpdHkgd2l0aCBTTk1QdjEgbWFu YWdlcnMuDQogICAgICAgICAgICAgU3VwcG9ydCBmb3IgdGhpcyBvYmplY3QgaXMgbWFuZGF0b3J5 Lg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3Vu dGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1h bmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0 ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51 aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJ ZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgNCB9DQoNCg0KZG9jc0lmQ210c1VwQ2hubEN0clVz ZWRDbnRuTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0K ICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVu dA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20g Q01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAgIG1pbmlzbG90 cyB1dGlsaXplZCBvbiB0aGUgdXBzdHJlYW0gbG9naWNhbCBjaGFubmVsLiBGb3INCiAgICAgICAg ICAgICBjb250ZW50aW9uIHJlZ2lvbnMsIHV0aWxpemVkIG1pbmlzbG90cyBhcmUgdGhvc2UgaW4g d2hpY2gNCiAgICAgICAgICAgICB0aGUgQ01UUyBjb3JyZWN0bHkgcmVjZWl2ZWQgYW4gdXBzdHJl YW0gYnVyc3QgZnJvbSBhbnkgQ00NCiAgICAgICAgICAgICBvbiB0aGUgdXBzdHJlYW0gbG9naWNh bCBjaGFubmVsLiBUaGlzIGlzIHRoZSAzMiBiaXQNCiAgICAgICAgICAgICB2ZXJzaW9uIG9mIGRv Y3NJZkNtdHNVcENobmxDdHJFeHRVc2VkQ250bk1zbG90cywgYW5kIGlzDQogICAgICAgICAgICAg aW5jbHVkZWQgZm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2MSBtYW5hZ2Vycy4NCiAg ICAgICAgICAgICBTdXBwb3J0IGZvciB0aGlzIG9iamVjdCBpcyBtYW5kYXRvcnkuDQogICAgICAg ICAgICAgRGlzY29udGludWl0aWVzIGluIHRoZSB2YWx1ZSBvZiB0aGlzIGNvdW50ZXIgY2FuIG9j Y3VyDQogICAgICAgICAgICAgYXQgcmVpbml0aWFsaXphdGlvbiBvZiB0aGUgbWFuYWdlZCBzeXN0 ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAgICAgICAgIHRpbWVzIGFzIGluZGljYXRlZCBieSB0aGUg dGhlIHZhbHVlIG9mIA0KICAgICAgICAgICAgIGlmQ291bnRlckRpc2NvbnRpbnVpdHlUaW1lIGZv ciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4LiINCiAgICAgICAgOjo9IHsgZG9jc0lmQ210c1VwQ2hh bm5lbENvdW50ZXJFbnRyeSA1IH0NCg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0VG90YWxNc2xv dHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1B WC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRp YWxpemF0aW9uLCBvZiBhbGwgbWluaXNsb3RzDQogICAgICAgICAgICAgZGVmaW5lZCBmb3IgdGhp cyB1cHN0cmVhbSBsb2dpY2FsIGNoYW5uZWwuIFRoaXMgY291bnQNCiAgICAgICAgICAgICBpbmNs dWRlcyBhbGwgSVVDcyBhbmQgU0lEcywgZXZlbiB0aG9zZSBhbGxvY2F0ZWQgdG8gdGhlDQogICAg ICAgICAgICAgTlVMTCBTSUQgZm9yIGEgMi4wIGxvZ2ljYWwgY2hhbm5lbCB3aGljaCBpcyBpbmFj dGl2ZS4gVGhpcw0KICAgICAgICAgICAgIGlzIHRoZSA2NCBiaXQgdmVyc2lvbiBvZiBkb2NzSWZD bXRzVXBDaG5sQ3RyVG90YWxNc2xvdHMsDQogICAgICAgICAgICAgYW5kIHdpbGwgbm90IGJlIGFj Y2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAgICAgIFN1cHBvcnQgZm9yIHRo aXMgb2JqZWN0IGlzIG1hbmRhdG9yeS4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4g dGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWlu aXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAg ICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAg ICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXgu Ig0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDYgfQ0KDQoN CmRvY3NJZkNtdHNVcENobmxDdHJFeHRVY2FzdEdyYW50ZWRNc2xvdHMgT0JKRUNULVRZUEUNCiAg ICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25s eQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAg ICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiB1bmlj YXN0DQogICAgICAgICAgICAgZ3JhbnRlZCBtaW5pc2xvdHMgb24gdGhlIHVwc3RyZWFtIGxvZ2lj YWwgY2hhbm5lbCwNCiAgICAgICAgICAgICByZWdhcmRsZXNzIG9mIGJ1cnN0IHR5cGUuIFVuaWNh c3QgZ3JhbnRlZCBtaW5pc2xvdHMgYXJlDQogICAgICAgICAgICAgdGhvc2UgaW4gd2hpY2ggdGhl IENNVFMgYXNzaWduZWQgYmFuZHdpZHRoIHRvIGFueSB1bmljYXN0DQogICAgICAgICAgICAgU0lE IG9uIHRoZSBsb2dpY2FsIGNoYW5uZWwuIEhvd2V2ZXIgdGhpcyBvYmplY3QgZG9lcyBub3QNCiAg ICAgICAgICAgICBpbmNsdWRlIG1pbmlzbG90cyBmb3IgcmVzZXJ2ZWQgSVVDcywgb3IgZ3JhbnRz IHRvIFNJRHMgDQogICAgICAgICAgICAgZGVzaWduYXRlZCBhcyBtZWFuaW5nICdubyBDTScuIFRo aXMgaXMgdGhlIDY0IGJpdCB2ZXJzaW9uDQogICAgICAgICAgICAgb2YgZG9jc0lmQ210c1VwQ2hu bEN0clVjYXN0R3JhbnRlZE1zbG90cywgYW5kIHdpbGwgbm90IGJlDQogICAgICAgICAgICAgYWNj ZXNzaWJsZSB0byBTTk1QdjEgbWFuYWdlcnMuDQogICAgICAgICAgICAgU3VwcG9ydCBmb3IgdGhp cyBvYmplY3QgaXMgbWFuZGF0b3J5Lg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0 aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5p dGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAg ICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAg ICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4i DQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgNyB9DQoNCg0K ZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRvdGFsQ250bk1zbG90cyBPQkpFQ1QtVFlQRQ0KICAgICAg ICBTWU5UQVggICAgICBDb3VudGVyNjQNCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQog ICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAg ICAgICJDdXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRpb24sIG9mIGNvbnRlbnRp b24NCiAgICAgICAgICAgICBtaW5pc2xvdHMgZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dp Y2FsIGNoYW5uZWwuIFRoaXMNCiAgICAgICAgICAgICBjb3VudCBpbmNsdWRlcyBhbGwgbWluaXNs b3RzIGFzc2lnbmVkIHRvIGEgYnJvYWRjYXN0IG9yDQogICAgICAgICAgICAgbXVsdGljYXN0IFNJ RCBvbiB0aGUgbG9naWNhbCBjaGFubmVsLiBUaGlzIGlzIHRoZSA2NCBiaXQNCiAgICAgICAgICAg ICB2ZXJzaW9uIG9mIGRvY3NJZkNtdHNVcENobmxDdHJUb3RhbENudG5Nc2xvdHMsIGFuZCB3aWxs DQogICAgICAgICAgICAgbm90IGJlIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0KICAg ICAgICAgICAgIFN1cHBvcnQgZm9yIHRoaXMgb2JqZWN0IGlzIG1hbmRhdG9yeS4NCiAgICAgICAg ICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2Nj dXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3Rl bSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0 aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9y IHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFu bmVsQ291bnRlckVudHJ5IDggfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRVc2VkQ250bk1z bG90cyBPQkpFQ1QtVFlQRQ0KICAgICAgICBTWU5UQVggICAgICBDb3VudGVyNjQNCiAgICAgICAg TUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAg ICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJDdXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5p dGlhbGl6YXRpb24sIG9mIGNvbnRlbnRpb24NCiAgICAgICAgICAgICBtaW5pc2xvdHMgdXRpbGl6 ZWQgb24gdGhlIHVwc3RyZWFtIGxvZ2ljYWwgY2hhbm5lbC4gRm9yDQogICAgICAgICAgICAgY29u dGVudGlvbiByZWdpb25zLCB1dGlsaXplZCBtaW5pc2xvdHMgYXJlIHRob3NlIGluIHdoaWNoDQog ICAgICAgICAgICAgdGhlIENNVFMgY29ycmVjdGx5IHJlY2VpdmVkIGFuIHVwc3RyZWFtIGJ1cnN0 IGZyb20gYW55IENNDQogICAgICAgICAgICAgb24gdGhlIHVwc3RyZWFtIGxvZ2ljYWwgY2hhbm5l bC4gVGhpcyBpcyB0aGUgNjQgYml0DQogICAgICAgICAgICAgdmVyc2lvbiBvZiBkb2NzSWZDbXRz VXBDaG5sQ3RyVXNlZENudG5Nc2xvdHMsIGFuZCB3aWxsIG5vdA0KICAgICAgICAgICAgIGJlIGFj Y2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAgICAgIFN1cHBvcnQgZm9yIHRo aXMgb2JqZWN0IGlzIG1hbmRhdG9yeS4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4g dGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWlu aXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAg ICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAg ICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXgu Ig0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDkgfQ0KDQoN CldJVEgNCg0KZG9jc0lmQ210c1VwQ2hubEN0clRvdGFsTXNsb3RzIE9CSkVDVC1UWVBFDQogICAg ICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkN CiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAg ICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgYWxsIG1p bmlzbG90cw0KICAgICAgICAgICAgIGRlZmluZWQgZm9yIHRoaXMgdXBzdHJlYW0gbG9naWNhbCBj aGFubmVsLiBUaGlzIGNvdW50DQogICAgICAgICAgICAgaW5jbHVkZXMgYWxsIElVQ3MgYW5kIFNJ RHMsIGV2ZW4gdGhvc2UgYWxsb2NhdGVkIHRvIHRoZQ0KICAgICAgICAgICAgIE5VTEwgU0lEIGZv ciBhIDIuMCBsb2dpY2FsIGNoYW5uZWwgd2hpY2ggaXMgaW5hY3RpdmUuIFRoaXMNCiAgICAgICAg ICAgICBpcyB0aGUgMzIgYml0IHZlcnNpb24gb2YgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRvdGFs TXNsb3RzDQogICAgICAgICAgICAgYW5kIGlzIGluY2x1ZGVkIGZvciBiYWNrIGNvbXBhdGliaWxp dHkgd2l0aCBTTk1QdjENCiAgICAgICAgICAgICBtYW5hZ2Vycy4NCiAgICAgICAgICAgICBEaXNj b250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAg ICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0 IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUg b2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3Nv Y2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRl ckVudHJ5IDIgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJVY2FzdEdyYW50ZWRNc2xvdHMgT0JK RUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NF U1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NS SVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0 aW9uLCBvZiB1bmljYXN0DQogICAgICAgICAgICAgZ3JhbnRlZCBtaW5pc2xvdHMgb24gdGhlIHVw c3RyZWFtIGxvZ2ljYWwgY2hhbm5lbCwNCiAgICAgICAgICAgICByZWdhcmRsZXNzIG9mIGJ1cnN0 IHR5cGUuIFVuaWNhc3QgZ3JhbnRlZCBtaW5pc2xvdHMgYXJlDQogICAgICAgICAgICAgdGhvc2Ug aW4gd2hpY2ggdGhlIENNVFMgYXNzaWduZWQgYmFuZHdpZHRoIHRvIGFueSB1bmljYXN0DQogICAg ICAgICAgICAgU0lEIG9uIHRoZSBsb2dpY2FsIGNoYW5uZWwuIEhvd2V2ZXIgdGhpcyBvYmplY3Qg ZG9lcyBub3QNCiAgICAgICAgICAgICBpbmNsdWRlIG1pbmlzbG90cyBmb3IgcmVzZXJ2ZWQgSVVD cywgb3IgZ3JhbnRzIHRvIFNJRHMgDQogICAgICAgICAgICAgZGVzaWduYXRlZCBhcyBtZWFuaW5n ICdubyBDTScuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9uIA0KICAgICAgICAgICAgIG9mIGRv Y3NJZkNtdHNVcENobmxDdHJFeHRVY2FzdEdyYW50ZWRNc2xvdHMsIGFuZCBpcyANCiAgICAgICAg ICAgICBpbmNsdWRlZCBmb3IgYmFjayBjb21wYXRpYmlsaXR5IHdpdGggU05NUHYxIG1hbmFnZXJz LiANCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291 bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBt YW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNh dGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGlu dWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2Nz SWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDMgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJU b3RhbENudG5Nc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMy DQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJy ZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJv bSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgbWluaXNs b3RzIGRlZmluZWQgZm9yIHRoaXMgdXBzdHJlYW0gbG9naWNhbCBjaGFubmVsLiBUaGlzDQogICAg ICAgICAgICAgY291bnQgaW5jbHVkZXMgYWxsIG1pbmlzbG90cyBhc3NpZ25lZCB0byBhIGJyb2Fk Y2FzdCBvcg0KICAgICAgICAgICAgIG11bHRpY2FzdCBTSUQgb24gdGhlIGxvZ2ljYWwgY2hhbm5l bC4gVGhpcyBpcyB0aGUgMzIgYml0DQogICAgICAgICAgICAgdmVyc2lvbiBvZiBkb2NzSWZDbXRz VXBDaG5sQ3RyRXh0VG90YWxDbnRuTXNsb3RzLCBhbmQgaXMNCiAgICAgICAgICAgICBpbmNsdWRl ZCBmb3IgYmFjayBjb21wYXRpYmlsaXR5IHdpdGggU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAg ICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1 cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVt LCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRo ZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3Ig dGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5u ZWxDb3VudGVyRW50cnkgNCB9DQoNCg0KZG9jc0lmQ210c1VwQ2hubEN0clVzZWRDbnRuTXNsb3Rz IE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgICAgICBNQVgt QUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBE RVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20gQ01UUyBpbml0aWFs aXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAgIG1pbmlzbG90cyB1dGlsaXplZCBv biB0aGUgdXBzdHJlYW0gbG9naWNhbCBjaGFubmVsLiBGb3INCiAgICAgICAgICAgICBjb250ZW50 aW9uIHJlZ2lvbnMsIHV0aWxpemVkIG1pbmlzbG90cyBhcmUgdGhvc2UgaW4gd2hpY2gNCiAgICAg ICAgICAgICB0aGUgQ01UUyBjb3JyZWN0bHkgcmVjZWl2ZWQgYW4gdXBzdHJlYW0gYnVyc3QgZnJv bSBhbnkgQ00NCiAgICAgICAgICAgICBvbiB0aGUgdXBzdHJlYW0gbG9naWNhbCBjaGFubmVsLiBU aGlzIGlzIHRoZSAzMiBiaXQNCiAgICAgICAgICAgICB2ZXJzaW9uIG9mIGRvY3NJZkNtdHNVcENo bmxDdHJFeHRVc2VkQ250bk1zbG90cywgYW5kIGlzDQogICAgICAgICAgICAgaW5jbHVkZWQgZm9y IGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2MSBtYW5hZ2Vycy4NCiAgICAgICAgICAgICBE aXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAg ICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5k IGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFs dWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBh c3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291 bnRlckVudHJ5IDUgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbE1zbG90cyBPQkpF Q1QtVFlQRQ0KICAgICAgICBTWU5UQVggICAgICBDb3VudGVyNjQNCiAgICAgICAgTUFYLUFDQ0VT UyAgcmVhZC1vbmx5DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJ UFRJT04NCiAgICAgICAgICAgICJDdXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRp b24sIG9mIGFsbCBtaW5pc2xvdHMNCiAgICAgICAgICAgICBkZWZpbmVkIGZvciB0aGlzIHVwc3Ry ZWFtIGxvZ2ljYWwgY2hhbm5lbC4gVGhpcyBjb3VudA0KICAgICAgICAgICAgIGluY2x1ZGVzIGFs bCBJVUNzIGFuZCBTSURzLCBldmVuIHRob3NlIGFsbG9jYXRlZCB0byB0aGUNCiAgICAgICAgICAg ICBOVUxMIFNJRCBmb3IgYSAyLjAgbG9naWNhbCBjaGFubmVsIHdoaWNoIGlzIGluYWN0aXZlLiBU aGlzDQogICAgICAgICAgICAgaXMgdGhlIDY0IGJpdCB2ZXJzaW9uIG9mIGRvY3NJZkNtdHNVcENo bmxDdHJUb3RhbE1zbG90cywNCiAgICAgICAgICAgICBhbmQgd2lsbCBub3QgYmUgYWNjZXNzaWJs ZSB0byBTTk1QdjEgbWFuYWdlcnMuDQogICAgICAgICAgICAgRGlzY29udGludWl0aWVzIGluIHRo ZSB2YWx1ZSBvZiB0aGlzIGNvdW50ZXIgY2FuIG9jY3VyDQogICAgICAgICAgICAgYXQgcmVpbml0 aWFsaXphdGlvbiBvZiB0aGUgbWFuYWdlZCBzeXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAgICAg ICAgIHRpbWVzIGFzIGluZGljYXRlZCBieSB0aGUgdGhlIHZhbHVlIG9mIA0KICAgICAgICAgICAg IGlmQ291bnRlckRpc2NvbnRpbnVpdHlUaW1lIGZvciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4LiIN CiAgICAgICAgOjo9IHsgZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50ZXJFbnRyeSA2IH0NCg0KDQpk b2NzSWZDbXRzVXBDaG5sQ3RyRXh0VWNhc3RHcmFudGVkTXNsb3RzIE9CSkVDVC1UWVBFDQogICAg ICAgIFNZTlRBWCAgICAgIENvdW50ZXI2NA0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkN CiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAg ICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgdW5pY2Fz dA0KICAgICAgICAgICAgIGdyYW50ZWQgbWluaXNsb3RzIG9uIHRoZSB1cHN0cmVhbSBsb2dpY2Fs IGNoYW5uZWwsDQogICAgICAgICAgICAgcmVnYXJkbGVzcyBvZiBidXJzdCB0eXBlLiBVbmljYXN0 IGdyYW50ZWQgbWluaXNsb3RzIGFyZQ0KICAgICAgICAgICAgIHRob3NlIGluIHdoaWNoIHRoZSBD TVRTIGFzc2lnbmVkIGJhbmR3aWR0aCB0byBhbnkgdW5pY2FzdA0KICAgICAgICAgICAgIFNJRCBv biB0aGUgbG9naWNhbCBjaGFubmVsLiBIb3dldmVyIHRoaXMgb2JqZWN0IGRvZXMgbm90DQogICAg ICAgICAgICAgaW5jbHVkZSBtaW5pc2xvdHMgZm9yIHJlc2VydmVkIElVQ3MsIG9yIGdyYW50cyB0 byBTSURzIA0KICAgICAgICAgICAgIGRlc2lnbmF0ZWQgYXMgbWVhbmluZyAnbm8gQ00nLiBUaGlz IGlzIHRoZSA2NCBiaXQgdmVyc2lvbg0KICAgICAgICAgICAgIG9mIGRvY3NJZkNtdHNVcENobmxD dHJVY2FzdEdyYW50ZWRNc2xvdHMsIGFuZCB3aWxsIG5vdCBiZQ0KICAgICAgICAgICAgIGFjY2Vz c2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBp biB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJl aW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAg ICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAg ICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRl eC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgNyB9DQoN Cg0KZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRvdGFsQ250bk1zbG90cyBPQkpFQ1QtVFlQRQ0KICAg ICAgICBTWU5UQVggICAgICBDb3VudGVyNjQNCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5 DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAg ICAgICAgICJDdXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRpb24sIG9mIGNvbnRl bnRpb24NCiAgICAgICAgICAgICBtaW5pc2xvdHMgZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBs b2dpY2FsIGNoYW5uZWwuIFRoaXMNCiAgICAgICAgICAgICBjb3VudCBpbmNsdWRlcyBhbGwgbWlu aXNsb3RzIGFzc2lnbmVkIHRvIGEgYnJvYWRjYXN0IG9yDQogICAgICAgICAgICAgbXVsdGljYXN0 IFNJRCBvbiB0aGUgbG9naWNhbCBjaGFubmVsLiBUaGlzIGlzIHRoZSA2NCBiaXQNCiAgICAgICAg ICAgICB2ZXJzaW9uIG9mIGRvY3NJZkNtdHNVcENobmxDdHJUb3RhbENudG5Nc2xvdHMsIGFuZCB3 aWxsDQogICAgICAgICAgICAgbm90IGJlIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0K ICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVy IGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFn ZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQg YnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5 VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNt dHNVcENoYW5uZWxDb3VudGVyRW50cnkgOCB9DQoNCg0KZG9jc0lmQ210c1VwQ2hubEN0ckV4dFVz ZWRDbnRuTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXI2NA0K ICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVu dA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20g Q01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAgIG1pbmlzbG90 cyB1dGlsaXplZCBvbiB0aGUgdXBzdHJlYW0gbG9naWNhbCBjaGFubmVsLiBGb3INCiAgICAgICAg ICAgICBjb250ZW50aW9uIHJlZ2lvbnMsIHV0aWxpemVkIG1pbmlzbG90cyBhcmUgdGhvc2UgaW4g d2hpY2gNCiAgICAgICAgICAgICB0aGUgQ01UUyBjb3JyZWN0bHkgcmVjZWl2ZWQgYW4gdXBzdHJl YW0gYnVyc3QgZnJvbSBhbnkgQ00NCiAgICAgICAgICAgICBvbiB0aGUgdXBzdHJlYW0gbG9naWNh bCBjaGFubmVsLiBUaGlzIGlzIHRoZSA2NCBiaXQNCiAgICAgICAgICAgICB2ZXJzaW9uIG9mIGRv Y3NJZkNtdHNVcENobmxDdHJVc2VkQ250bk1zbG90cywgYW5kIHdpbGwgbm90DQogICAgICAgICAg ICAgYmUgYWNjZXNzaWJsZSB0byBTTk1QdjEgbWFuYWdlcnMuDQogICAgICAgICAgICAgRGlzY29u dGludWl0aWVzIGluIHRoZSB2YWx1ZSBvZiB0aGlzIGNvdW50ZXIgY2FuIG9jY3VyDQogICAgICAg ICAgICAgYXQgcmVpbml0aWFsaXphdGlvbiBvZiB0aGUgbWFuYWdlZCBzeXN0ZW0sIGFuZCBhdCBv dGhlcg0KICAgICAgICAgICAgIHRpbWVzIGFzIGluZGljYXRlZCBieSB0aGUgdGhlIHZhbHVlIG9m IA0KICAgICAgICAgICAgIGlmQ291bnRlckRpc2NvbnRpbnVpdHlUaW1lIGZvciB0aGUgYXNzb2Np YXRlZCBpZkluZGV4LiINCiAgICAgICAgOjo9IHsgZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50ZXJF bnRyeSA5IH0NCg0KDQoNCjMpIERlY2lzaW9uIG9mIEFVR01FTlRJTkcgb3IgYWRkZWQgY29sdW1u YXIgT3B0aW9uYWwgb2JqZWN0cyBpbiANCmRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyVGFibGUg DQoNClRoaXMgdG9waWMgd2FzIGRpc2N1c2VkIGluIGdvb2QgZGVlcCBpbiB0aGUgaXBjZG4gbGlz dCBhbmQgdmVyeSBnb29kIA0KY29udHJpYnV0aW9ucyB3ZXJlIG1hZGUsICggY29tcGxldGUgZW1h aWwgbG9nIGlzIGluIElQQ0ROIHdlYiBwYWdlKSANClRvIG1lbnRpb24sIG9uZSBvZiB0aGUgbW9z dCByZWxldmFudCBjb21tZW50cywgd2FzIGZyb20gUmljaCBXb3VuZHkgDQpNYXkgMzAgMjAwMywg d2l0aCBzdWJqZWN0IA0KIk9wdGlvbmFsIiBpbiB0aGUgZGVzY3JpcHRpb24gb2Ygb2JqZWN0cyBm cm9tIHRoZSByZmltaWJ2Mg0KDQpSaWNoIHF1b3RlZCB0aGUgc2VjdGlvbiBvZiBSRkMgMjg2MyAz LjEuMTggIkFsbCB2YWx1ZXMgTXVzdCBiZSBLbm93biINCldoZXJlIGFuIGFnZW50IHRoYXQgZG9l cyBub3Qgc3VwcG9ydCBhIGNvdW50ZXIgcGVybWFuZW50bHkgbXVzdCBub3QgDQppbnN0YW50aWF0 ZSB0aGUgb2JqZWN0IChlLmcuIGZvciBhIHBhcnRpY3VsYXIgaWZJbmRleCBpZlRhYmxlIGNvdW50 ZXIgb3IgDQp0YWJsZSBleHRlbnNpb24pIA0Kb3IgDQp0ZW1wb3Jhcmx5LCB0aGUgQWdlbnQgaGF2 ZW4ndCBjb21wbGV0ZSB0aGUgaW5pdGlhbGl6YXRpb24gb2YgdGhlIGVudGl0eSBvcg0KIHRoZSBj b3VudGVyIGZ1bmN0aW9uLg0KDQpJbiBzdW1tYXJ5LCB0aGUgYWdlbnQgd2lsbCByZXNwb25kIHdp dGggZXJyb3IgJ25vU3VjaE9iamVjdCcgaWYgb2JqZWN0IGlzIA0KY29tcGxldGVseSB1bmtub3du IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiAoZS5nIG9wdGlvbmFsIGltcGxlbWVudGF0aW9uKSBvciAN Cidub1N1Y2hJbnN0YW5jZScgaWYgdGhlIHNwZWNpZmllZCByb3cgb2YgdGhlIG9iamVjdCBpcyBu b3QgdmFsaWQuDQoNCkFub3RoZXIgcmVmZXJlbmNlIHBvaW50IGlzIHRoZSBPU1NJIHNwZWMuDQoN ClNpbmNlIGVhcmx5IE9TU0kgbWliIG9iamVjdCByZXF1aXJlbWVudHMsIHRoZSBPU1MgcmVxdWly ZXMgZm9yIG9wdGlvbmFsIA0Kb2JqZWN0cyB0aGUgZm9sbG93aW5nICggaW4gdG90YWwgc3luY2gg d2l0aCAgUmljaCdzIHF1b3RlZCB0ZXh0KToNCg0KT3B0aW9uYWwgbWliIG9iamVjdHMgaW4gQW5u ZXggQSBEZXRhaWxlZCBNSUIgUmVxdWlyZW1lbnRzIChub3JtYXRpdmUpIA0KDQoiTyBPcHRpb25h bC4gQSB2ZW5kb3IgY2FuIGNob29zZSB0byBpbXBsZW1lbnQgb3Igbm90IGltcGxlbWVudCB0aGUg b2JqZWN0LiANCklmIGEgdmVuZG9yIGNob29zZXMgdG8gaW1wbGVtZW50IHRoZSBvYmplY3QsIHRo ZSBvYmplY3QgTVVTVCBiZSBpbXBsZW1lbnRlZCANCmNvcnJlY3RseSBhY2NvcmRpbmcgdG8gdGhl IE1JQiBkZWZpbml0aW9uLiBJZiBhIHZlbmRvciBjaG9vc2VzIG5vdCB0byBpbXBsZW1lbnQgDQp0 aGUgb2JqZWN0LCBhbiBhZ2VudCBNVVNUIE5PVCBpbnN0YW50aWF0ZSBzdWNoIG9iamVjdCBhbmQg TVVTVCByZXNwb25kIHdpdGggDQp0aGUgYXBwcm9wcmlhdGUgZXJyb3IvZXhjZXB0aW9uIGNvbmRp dGlvbiAoZS5nLiwgbm8gc3VjaCBvYmplY3QgZm9yIFNOTVB2MmMpLiINCg0KSXQgaXMgY2xlYXIg dGhhdCB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IgcGVyIE9TU0kgc3BlYyBpcyB0byBmaW5kIHRhYmxl cyB3aXRoIA0KJ2hvbGVzJyB3aGljaCBpcyBhbHNvIHRoZSBJRVRGIHJlY29tZW5kYXRpb24uIA0K DQpDb25jbHVzaW9uIA0KIA0KRnJvbSB0aGUgc3BlYyBwb2ludCBvZiB2aWV3IHRoZSB0YWJsZSB3 aXRoIHRoZSBjaGFuZ2VzIGlzIGZpbmUsIG5vIG5lZWQgdG8gDQpzcGxpdCBhbmQgbWFuYWdlbWVu dCBzb2Z0d2FyZSBpbXBsZW1lbnRlcnMgYW5kIG9wZXJhdG9ycyBtaWdodCBleHBsb3JlIHVuaWZp ZWQgDQpjYXRhIGxvYWRlciBzaW5jZSB0aGlzIHByb2JsZW0gaXMgbm90IGV4Y2x1c2l2ZSBvZiB0 aGlzIHRhYmxlLCBidXQgaW4gZ2VuZXJhbCANCmZvciBhbGwgaW50ZXJmYWNlIHJlbGF0ZWQgc3Rh dGlzdGljcyBhbmQgc29mdHdhcmUgdmVyc2lvbmluZy4NCg0KDQoNCiANCg0KDQo= ------_=_NextPart_001_01C38CE3.61DFCDD3-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Oct 7 13:10:16 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 MAA10466 for ; Tue, 7 Oct 2003 12:21:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6ua7-0001dn-LG for ipcdn-archive@odin.ietf.org; Tue, 07 Oct 2003 12:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97GL303006295 for ipcdn-archive@odin.ietf.org; Tue, 7 Oct 2003 12:21:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6ua7-0001dJ-7W; Tue, 07 Oct 2003 12:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tqd-0007Wb-59 for ipcdn@optimus.ietf.org; Tue, 07 Oct 2003 11:34:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08168 for ; Tue, 7 Oct 2003 11:33:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6tqW-0007OQ-00 for ipcdn@ietf.org; Tue, 07 Oct 2003 11:33:56 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A6tqU-0007OK-00 for ipcdn@ietf.org; Tue, 07 Oct 2003 11:33:54 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h97FXI10017928; Tue, 7 Oct 2003 09:33:18 -0600 (MDT) 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_01C38CE8.54CC35AD" Date: Tue, 7 Oct 2003 09:33:17 -0600 Message-ID: X-MS-Has-Attach: yes Thread-Topic: Issue#13 IPCDN RF MIBv2 Thread-Index: AcNgJaYn06TBEeT1TRC5N0Q/BVl7hgT3JTZQBRgJoxAABa9pIADpuJMQAAWICSAAKu36sAABhZuA From: "Eduardo Cardona" To: "Jean-Francois Mule" , "Ipcdn (E-mail)" , "Richard Woundy" , "DOCSIS OSS Majordomo List" , "DOCSIS 2.0 Majordomo List" Cc: "Bert Wijnen" X-Approved: ondar Subject: [ipcdn] RE: Issue#13 IPCDN RF MIBv2 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_01C38CE8.54CC35AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To All,=20 I got a list-owner message of holding the below email due to very long body message. Here is again only with the attachment Eduardo Hi all,=20 Attached and below are the item actions for issue #13 The attached file is text based to facilitate MIB edits later, of if having formatting difficulties Reading the same text below. Regards=20 Eduardo -------------------------------------------- ------_=_NextPart_001_01C38CE8.54CC35AD Content-Type: text/plain; name="issue#13.txt" Content-Description: issue#13.txt Content-Disposition: attachment; filename="issue#13.txt" Content-Transfer-Encoding: base64 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCisgSXNzdWUgIzEz DQpTdGF0dXM6IE9wZW4NCigxMykgQWRqdXN0IGNvbXBsaWFuY2Ugc3RhdGVtZW50cyBmb3Igb2Jq ZWN0cyBkZXNpZ25hdGVkIG9wdGlvbmFsLiBBZGQNCiAgICAgc2VwYXJhdGUgYXVnbWVudGF0aW9u IHRhYmxlIGZvciBvcHRpb25hbCBvYmplY3RzIGluDQogICAgIGRvY3NJZkNtdHNVcENoYW5uZWxD b3VudGVyVGFibGUuDQogICAgIENvbnRyaWJ1dG9ycyAtIFdpbGwgTXVyd2luIE1vdG9yb2xhLCBS aWNoIFdvdW5keSBJUENETi9Db21jYXN0LA0KICAgICBNaWtlIFN0Sm9obnMgTWluZHNwcmluZywg RWR1YXJkbyBDYXJkb25hIENhYmxlbGFicw0KIyBjYXRlZ29yeTogIm11c3QgZml4Ig0KIyBBY3Rp b24gSXRlbTogRWR1YXJkbyB0byBzdW1tYXJpemUgdGhlIGRpc2N1c3Npb24gJiBhIHJlY29tbWVu ZGF0aW9uDQojIGZvciB0aGUgYXVnbWVudGF0aW9uLiBDb25zZW5zdXMgbXVzdCBiZSByZWFjaGVk IGJ5IDEwLzEwIG9yIGVsc2UgV0cNCiMgY2hhaXIgd2lsbCBtYWtlIGEgZGVjaXNpb24uDQoNCklz c3VlIGl0ZW0gQWN0aW9ucw0KMSkgRGVmaW5lIHRoZSBPcHRpb25hbCBncm91cA0KDQoyKSBSZW1v dmUgdGhlIHRleHQgaW5kaWNhdGlvbiBvZiBvcHRpb25hbCBvciBtYW5kYXRvcnkgb2JqZWN0IGlu IHRoZSANCkRFU0NSSVBUSU9OIGNsYXVzZSBvZiBvYmplY3RzIGluIHRhYmxlIGRvY3NJZkNtdHNV cENoYW5uZWxDb3VudGVyVGFibGUNCg0KMykgRGVjaXNpb24gb2YgQVVHTUVOVElORyBvciBhZGRl ZCBjb2x1bW5hciBPcHRpb25hbCBvYmplY3RzIGluIA0KZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50 ZXJUYWJsZSANCg0KMSkgYW5kIDIpIGFyZSByZXNvbHZlZCBoZXJlLg0KDQozKSBpcyBkaXNjdXNz ZWQgYmVsb3cgYW5kIGFzIHRoZSByZWZlcmVuY2VzIHBvaW50ZWQsIE9TU0kgc3BlYyBhbHJlYWR5 IHJlcXVpcmVzDQogICByZXR1cm4gZXJyb3IgY29kZXMgZm9yIE9wdGlvbmFsIG9iamVjdCBub3Qg aW1wbGVtZW50ZWQuIEFsc28gaXQgaXMgZXhwZWN0ZWQgZm9yIA0KICAgT1NTSSBzcGVjIHRvIHJl dHVybiBjb3JyZWN0IHZhbHVlcyBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlIG9iamVjdCBk ZWZpbml0aW9uDQogICBpZiB0aGUgb3B0aW9uYWwgb2JqZWN0cyBhcmUgc3VwcG9ydGVkLg0KICAg DQogICBUaGUgZGVjaXNpb24gb2Ygc2VwYXJhdGUgaW4gdHdvIHRhYmxlcyB0aGUgbWFuZGF0b3J5 IGFuZCBvcHRpb25hbCBvYmplY3RzIGhhcyB0d28gdmlld3MuDQogICANCiAgIA0KICAgYSkgRmly c3QgQ0wgd2lsbCByZWNvbW1lbmQgbm90IHRvIHNwbGl0IHRoZSB0YWJsZSBiYXNlZCBvbiBhIG1v cmUgZGVlcCBvdmVyYWxsIGFuYWx5c2lzIA0KICAgICAgRnJvbSB0aGUgaXRlbSAzKSBub3RlcyAo ZW5kIG9mIGRvY3VtZW50KSBhbmQgZXh0cmEgY29uc2lkZXJhdGlvbnMuDQogICAJLSBzd2l0Y2hl cyB0byBxdWVyeSBzdWItc2V0cyBvZiBvYmplY3RzIGFyZSBhdmFpbGFibGUgaW4gdGhlIGNhc2Ug b2YgYmFkIFNOTVAgdG9vbCANCiAgIAkgIHN1cHBvcnQgb2YgdGFibGUgaG9sZXMuIE5vdCBkaWZm ZXJlbnQgdG8gaGFuZGxlIGltcGxlbWVudGF0aW9ucyBwcmV2aW91cyB0byANCiAgIAkgIFJGSW1p YnYyIHdoZXJlIG5laXRoZXIgdGhlIG1hbmRhdG9yeSBhbmQgb3B0aW9uYWwgb2JqZWN0cyBhcmUg cHJlc2VudC4NCiAgIAktIEhvbGUgY2FzZXMgYXJlIG5vdCBvbmx5IGEgcHJvYmxlbSBmb3IgdGhp cyB0YWJsZSwgbWFueSBpbnRlcmZhY2UgcmVsYXRlZCBzdGF0aXN0aWNzIA0KICAgCSAgaGFzIHRo b3NlIHByb2JsZW1zIHdoZW4gYnVsa2luZyBkYXRhIHRvIHBlcmZvcm0gbGF0ZXIgb24gZmlsdGVy cyBhbmQgYXNzb2NpYXRpb24gb3IgDQogICAJICBhZ2dyZWdhdGlvbg0KICAgCS0gRnJvbSBhIG5t Z3QgaW50ZWdyYXRvciBkYXRhIGxvYWRlcnMgbWlndGggaGFuZGxlIHRyYW5zcGFyZW50bHkgdGFi bGVzICggd2l0aCBob2xlcykgDQogICAJICB2cyBtdWx0aXBsZSB0YWJsZXMgYXVnbWVudGF0aW9u cyBhbmQvb3IgZXh0ZW5zaW9ucw0KICAgCS0gZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50ZXJUYWJs ZSByZXF1aXJlcyBob29rcyB0byBpZlRhYmxlLCBhbmQgaWZYVGFibGUgdG8gZGV0ZWN0IA0KICAg CSAgZGlzY29udGludWl0aWVzLCBhZG1pblN0YXR1cywgZXRjLiBUaGVyZWZvcmUgVGhlIENvbXBs ZXhpdHkgb2YgdGhlIGRhdGEgdmFsaWRhdGlvbg0KICAgCSAgaW4gdGhlIGFnZ3JlZ2F0aW9uIHNp ZGUgb2YgZGF0YSBsb2FkZXIgbWlndGggc2VlIHRoZSB3aG9sZSB0YWJsZSBhcyBhIG5vdCBzdG9w cGVyLg0KICAgCSAgDQogICANCiAgIGIpICBJZiBiYXNlZCBvbiBhKSB0aGVyZSBhcmUgbW9yZSBj b21wZWxsaW5nIHJlYXNvbnMgdG8gc3RpbGwgcmVxdWlyZSB0aGUgdGFibGUgc3BsaXQNCiAgICAg ICBPbmx5IHN0b3BwZXJzIHRvIHNwbGl0IHRoZSB0YWJsZSBjdXJyZW50bHkgY291bGQgYmUgDQog ICAgICAgSW1wbGVtZW50YXRpb25zIHRoYXQgYWxyZWFkeSBzdXBwb3J0IHRoZSB0YWJsZSBhbmQg aW4gc29tZSBidXNpbmVzcyBjYXNlcyB0aGUgdmVuZG9yIA0KICAgICAgIHdpbGwgcGxhY2Ugc3Ry b25nIG9wcG9zaXRpb24gdG8gZG8gdGhhdCBiZWNhdXNlIChlaXRoZXIgaXRlbXMpOg0KICAgICAg IC0gVGhlIG9wdGlvbmFsIG9iamVjdHMgYXJlIGZ1bGx5IHN1cHBvcnRlZCAobm8gZmlsbGVkIHdp dGggemVyb3MgYXMgZHJhZnQgMDUgcmVxdWlyZXMgDQogICAgICAgICBhbmQgY29ycmVjdGVkIGlu IHRoaXMgZHJhZnQpDQogICAgICAgLSBFeHRlbnNpdmUgZGV2aWNlIGltcGxlbWVudGF0aW9ucw0K ICAgICAgIC0gSWYgb3B0aW9uYWwgb2JqZWN0cyBpbiBjdXJyZW50IGltcGxlbWVudGF0aW9uICha ZXJvZWQpLCB3aWxsIG5vdCBpbXBsZW1lbnQgU29mdHdhcmUgDQogICAgICAgICB2ZXJzaW9ucyBp biBwbGFjZSBmb3Igb3IgYWZ0ZXIgQ1cyOCAoIHdoZXJlIHBvdGVudGlhbHkgIGRyYWZ0IDA4IG1p Z2h0IGJlIHJlcXVpcmVkIA0KICAgICAgICAgaWYgUkZDIGlzIG5vdCBwdWJsaXNoZWQgcHJvbXB0 bHkpLiANCiAgDQogIFBsZWFzZSByZXNwb25kIHByb21wdGx5IHRvIHRoZSBsaXN0IG9yIGluIHBy aXZhdGUgdG8gdmVuZG9yIHByZWZlcmVuY2VzIHRvIHJlYWNoIGNvbnNlbnN1cyANCiAgaW4gdGhp cyBmaW5hbCByZXNvbHV0aW9uIGVpdGhlciB0byBzdXBwb3J0IDMuYSBvciAzLmIgYW5kIHJlYXNv bnMgd2h5LiANCiAgICANCiAgICANCiAgICBEZXRhaWwgY2hhbmdlcyBwcm9wb3NhbA0KICAgIA0K DQoxKSBEZWZpbmUgdGhlIE9wdGlvbmFsIGdyb3VwDQoNCmEpIEFkZCBhZnRlciBHcm91cCBDbGF1 c2UgIkdST1VQIGRvY3NJZkNtdHNHcm91cFYyIg0KICAgICAgICAgICAgIA0KICAgICAgICAgICAg IA0KLS0gT3B0aW9uYWwgZ3JvdXBzDQoNCkdST1VQIGRvY3NJZkNtdHNPcHRpb25hbEdyb3VwVjIN CiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJUaGlzIGdyb3VwIGlzIG9wdGlvbmFs IGZvciBDYWJsZSBNb2RlbSBUZXJtaW5hdGlvbiBTeXN0ZW1zLA0KICAgICAgICAgICAgIGFuZCBu b3QgYXBwbGljYWJsZSBmb3IgQ2FibGUgTW9kZW1zLiINCg0KYikgUkVQTEFDRTogDQoNCg0KZG9j c0lmQ210c0dyb3VwVjIgT0JKRUNULUdST1VQDQogICAgICAgIE9CSkVDVFMgew0KICAgICAgICAg ICAgZG9jc0lmQ210c0NhcGFiaWxpdGllcywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNTeW5jSW50 ZXJ2YWwsDQogICAgICAgICAgICBkb2NzSWZDbXRzVWNkSW50ZXJ2YWwsDQogICAgICAgICAgICBk b2NzSWZDbXRzTWF4U2VydmljZUlkcywNCi0tICAgICAgICAgICAgZG9jc0lmQ210c0luc2VydGlv bkludGVydmFsLA0KICAgICAgICAgICAgZG9jc0lmQ210c0ludml0ZWRSYW5naW5nQXR0ZW1wdHMs DQogICAgICAgICAgICBkb2NzSWZDbXRzSW5zZXJ0SW50ZXJ2YWwsDQogICAgICAgICAgICBkb2Nz SWZDbXRzU3RhdHVzSW52YWxpZFJhbmdlUmVxcywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNTdGF0 dXNSYW5naW5nQWJvcnRlZHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzU3RhdHVzSW52YWxpZFJl Z1JlcXMsDQogICAgICAgICAgICBkb2NzSWZDbXRzU3RhdHVzRmFpbGVkUmVnUmVxcywNCiAgICAg ICAgICAgIGRvY3NJZkNtdHNTdGF0dXNJbnZhbGlkRGF0YVJlcXMsDQogICAgICAgICAgICBkb2Nz SWZDbXRzU3RhdHVzVDVUaW1lb3V0cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c01h Y0FkZHJlc3MsDQogICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNEb3duQ2hhbm5lbElmSW5k ZXgsDQogICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNVcENoYW5uZWxJZkluZGV4LA0KICAg ICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzUnhQb3dlciwNCiAgICAgICAgICAgIGRvY3NJZkNt dHNDbVN0YXR1c1RpbWluZ09mZnNldCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c0Vx dWFsaXphdGlvbkRhdGEsDQogICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNWYWx1ZSwNCiAg ICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c1VuZXJyb3JlZHMsDQogICAgICAgICAgICBkb2Nz SWZDbXRzQ21TdGF0dXNDb3JyZWN0ZWRzLA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVz VW5jb3JyZWN0YWJsZXMsDQogICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNTaWduYWxOb2lz ZSwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c01pY3JvcmVmbGVjdGlvbnMsDQogICAg ICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNFeHRVbmVycm9yZWRzLA0KICAgICAgICAgICAgZG9j c0lmQ210c0NtU3RhdHVzRXh0Q29ycmVjdGVkcywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0 YXR1c0V4dFVuY29ycmVjdGFibGVzLA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzRG9j c2lzUmVnTW9kZSwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c01vZHVsYXRpb25UeXBl LA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzSW5ldEFkZHJlc3NUeXBlLA0KICAgICAg ICAgICAgZG9jc0lmQ210c0NtU3RhdHVzSW5ldEFkZHJlc3MsDQogICAgICAgICAgICBkb2NzSWZD bXRzQ21TdGF0dXNWYWx1ZUxhc3RVcGRhdGUsDQogICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0 dXNIaWdoUmVzb2x1dGlvblRpbWluZ09mZnNldCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNTZXJ2 aWNlQWRtaW5TdGF0dXMsDQogICAgICAgICAgICBkb2NzSWZDbXRzU2VydmljZVFvc1Byb2ZpbGUs DQogICAgICAgICAgICBkb2NzSWZDbXRzU2VydmljZUNyZWF0ZVRpbWUsDQogICAgICAgICAgICBk b2NzSWZDbXRzU2VydmljZUluT2N0ZXRzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1NlcnZpY2VJ blBhY2tldHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzU2VydmljZU5ld0NtU3RhdHVzSW5kZXgs DQogICAgICAgICAgICBkb2NzSWZDbXRzTW9kVHlwZSwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNN b2RDb250cm9sLA0KICAgICAgICAgICAgZG9jc0lmQ210c01vZFByZWFtYmxlTGVuLA0KICAgICAg ICAgICAgZG9jc0lmQ210c01vZERpZmZlcmVudGlhbEVuY29kaW5nLA0KICAgICAgICAgICAgZG9j c0lmQ210c01vZEZFQ0Vycm9yQ29ycmVjdGlvbiwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RG RUNDb2Rld29yZExlbmd0aCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RTY3JhbWJsZXJTZWVk LA0KICAgICAgICAgICAgZG9jc0lmQ210c01vZE1heEJ1cnN0U2l6ZSwNCiAgICAgICAgICAgIGRv Y3NJZkNtdHNNb2RHdWFyZFRpbWVTaXplLA0KICAgICAgICAgICAgZG9jc0lmQ210c01vZExhc3RD b2Rld29yZFNob3J0ZW5lZCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RTY3JhbWJsZXIsDQog ICAgICAgICAgICBkb2NzSWZDbXRzTW9kQnl0ZUludGVybGVhdmVyRGVwdGgsDQogICAgICAgICAg ICBkb2NzSWZDbXRzTW9kQnl0ZUludGVybGVhdmVyQmxvY2tTaXplLA0KICAgICAgICAgICAgZG9j c0lmQ210c01vZFByZWFtYmxlVHlwZSwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RUY21FcnJv ckNvcnJlY3Rpb25PbiwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RTY2RtYUludGVybGVhdmVy U3RlcFNpemUsDQogICAgICAgICAgICBkb2NzSWZDbXRzTW9kU2NkbWFTcHJlYWRlckVuYWJsZSwN CiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RTY2RtYVN1YmZyYW1lQ29kZXMsDQogICAgICAgICAg ICBkb2NzSWZDbXRzTW9kQ2hhbm5lbFR5cGUsDQogICAgICAgICAgICBkb2NzSWZDbXRzUW9zUHJv ZmlsZVBlcm1pc3Npb25zLA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtUHRyLA0KICAgICAgICAg ICAgZG9jc0lmQ210c0NoYW5uZWxVdGlsaXphdGlvbkludGVydmFsLA0KICAgICAgICAgICAgZG9j c0lmQ210c0NoYW5uZWxVdFV0aWxpemF0aW9uLA0KICAgICAgICAgICAgZG9jc0lmQ210c0Rvd25D aG5sQ3RySWQsDQogICAgICAgICAgICBkb2NzSWZDbXRzRG93bkNobmxDdHJUb3RhbEJ5dGVzLA0K ICAgICAgICAgICAgZG9jc0lmQ210c0Rvd25DaG5sQ3RyVXNlZEJ5dGVzLA0KICAgICAgICAgICAg ZG9jc0lmQ210c0Rvd25DaG5sQ3RyRXh0VG90YWxCeXRlcywNCiAgICAgICAgICAgIGRvY3NJZkNt dHNEb3duQ2hubEN0ckV4dFVzZWRCeXRlcywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxD dHJJZCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJUb3RhbE1zbG90cywNCiAgICAg ICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJVY2FzdEdyYW50ZWRNc2xvdHMsDQogICAgICAgICAg ICBkb2NzSWZDbXRzVXBDaG5sQ3RyVG90YWxDbnRuTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lm Q210c1VwQ2hubEN0clVzZWRDbnRuTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hu bEN0ckV4dFRvdGFsTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFVj YXN0R3JhbnRlZE1zbG90cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3Rh bENudG5Nc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0VXNlZENudG5N c2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyQ29sbENudG5Nc2xvdHMsDQog ICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyVG90YWxDbnRuUmVxTXNsb3RzLA0KICAgICAg ICAgICAgZG9jc0lmQ210c1VwQ2hubEN0clVzZWRDbnRuUmVxTXNsb3RzLA0KICAgICAgICAgICAg ZG9jc0lmQ210c1VwQ2hubEN0ckNvbGxDbnRuUmVxTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lm Q210c1VwQ2hubEN0clRvdGFsQ250blJlcURhdGFNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZD bXRzVXBDaG5sQ3RyVXNlZENudG5SZXFEYXRhTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210 c1VwQ2hubEN0ckNvbGxDbnRuUmVxRGF0YU1zbG90cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNV cENobmxDdHJUb3RhbENudG5Jbml0TWFpbnRNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRz VXBDaG5sQ3RyVXNlZENudG5Jbml0TWFpbnRNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRz VXBDaG5sQ3RyQ29sbENudG5Jbml0TWFpbnRNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRz VXBDaG5sQ3RyRXh0Q29sbENudG5Nc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5s Q3RyRXh0VG90YWxDbnRuUmVxTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0 ckV4dFVzZWRDbnRuUmVxTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4 dENvbGxDbnRuUmVxTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRv dGFsQ250blJlcURhdGFNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0 VXNlZENudG5SZXFEYXRhTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4 dENvbGxDbnRuUmVxRGF0YU1zbG90cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJF eHRUb3RhbENudG5Jbml0TWFpbnRNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5s Q3RyRXh0VXNlZENudG5Jbml0TWFpbnRNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBD aG5sQ3RyRXh0Q29sbENudG5Jbml0TWFpbnRNc2xvdHMNCiAgICAgICAgfQ0KICAgICAgICBTVEFU VVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiR3JvdXAg b2Ygb2JqZWN0cyBpbXBsZW1lbnRlZCBpbiBDYWJsZSBNb2RlbSBUZXJtaW5hdGlvbg0KICAgICAg ICAgICAgIFN5c3RlbXMuIg0KICAgICAgICA6Oj0geyBkb2NzSWZHcm91cHNWMiAzIH0NCiANCiBX SVRIOg0KDQoNCmRvY3NJZkNtdHNHcm91cFYyIE9CSkVDVC1HUk9VUA0KICAgICAgICBPQkpFQ1RT IHsNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDYXBhYmlsaXRpZXMsDQogICAgICAgICAgICBkb2Nz SWZDbXRzU3luY0ludGVydmFsLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VjZEludGVydmFsLA0K ICAgICAgICAgICAgZG9jc0lmQ210c01heFNlcnZpY2VJZHMsDQotLSAgICAgICAgICAgIGRvY3NJ ZkNtdHNJbnNlcnRpb25JbnRlcnZhbCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNJbnZpdGVkUmFu Z2luZ0F0dGVtcHRzLA0KICAgICAgICAgICAgZG9jc0lmQ210c0luc2VydEludGVydmFsLA0KICAg ICAgICAgICAgZG9jc0lmQ210c1N0YXR1c0ludmFsaWRSYW5nZVJlcXMsDQogICAgICAgICAgICBk b2NzSWZDbXRzU3RhdHVzUmFuZ2luZ0Fib3J0ZWRzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1N0 YXR1c0ludmFsaWRSZWdSZXFzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1N0YXR1c0ZhaWxlZFJl Z1JlcXMsDQogICAgICAgICAgICBkb2NzSWZDbXRzU3RhdHVzSW52YWxpZERhdGFSZXFzLA0KICAg ICAgICAgICAgZG9jc0lmQ210c1N0YXR1c1Q1VGltZW91dHMsDQogICAgICAgICAgICBkb2NzSWZD bXRzQ21TdGF0dXNNYWNBZGRyZXNzLA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzRG93 bkNoYW5uZWxJZkluZGV4LA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzVXBDaGFubmVs SWZJbmRleCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c1J4UG93ZXIsDQogICAgICAg ICAgICBkb2NzSWZDbXRzQ21TdGF0dXNUaW1pbmdPZmZzZXQsDQogICAgICAgICAgICBkb2NzSWZD bXRzQ21TdGF0dXNFcXVhbGl6YXRpb25EYXRhLA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtU3Rh dHVzVmFsdWUsDQogICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNVbmVycm9yZWRzLA0KICAg ICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzQ29ycmVjdGVkcywNCiAgICAgICAgICAgIGRvY3NJ ZkNtdHNDbVN0YXR1c1VuY29ycmVjdGFibGVzLA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtU3Rh dHVzU2lnbmFsTm9pc2UsDQogICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNNaWNyb3JlZmxl Y3Rpb25zLA0KICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzRXh0VW5lcnJvcmVkcywNCiAg ICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c0V4dENvcnJlY3RlZHMsDQogICAgICAgICAgICBk b2NzSWZDbXRzQ21TdGF0dXNFeHRVbmNvcnJlY3RhYmxlcywNCiAgICAgICAgICAgIGRvY3NJZkNt dHNDbVN0YXR1c0RvY3Npc1JlZ01vZGUsDQogICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNN b2R1bGF0aW9uVHlwZSwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c0luZXRBZGRyZXNz VHlwZSwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c0luZXRBZGRyZXNzLA0KICAgICAg ICAgICAgZG9jc0lmQ210c0NtU3RhdHVzVmFsdWVMYXN0VXBkYXRlLA0KICAgICAgICAgICAgZG9j c0lmQ210c0NtU3RhdHVzSGlnaFJlc29sdXRpb25UaW1pbmdPZmZzZXQsDQogICAgICAgICAgICBk b2NzSWZDbXRzU2VydmljZUFkbWluU3RhdHVzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1NlcnZp Y2VRb3NQcm9maWxlLA0KICAgICAgICAgICAgZG9jc0lmQ210c1NlcnZpY2VDcmVhdGVUaW1lLA0K ICAgICAgICAgICAgZG9jc0lmQ210c1NlcnZpY2VJbk9jdGV0cywNCiAgICAgICAgICAgIGRvY3NJ ZkNtdHNTZXJ2aWNlSW5QYWNrZXRzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1NlcnZpY2VOZXdD bVN0YXR1c0luZGV4LA0KICAgICAgICAgICAgZG9jc0lmQ210c01vZFR5cGUsDQogICAgICAgICAg ICBkb2NzSWZDbXRzTW9kQ29udHJvbCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RQcmVhbWJs ZUxlbiwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2REaWZmZXJlbnRpYWxFbmNvZGluZywNCiAg ICAgICAgICAgIGRvY3NJZkNtdHNNb2RGRUNFcnJvckNvcnJlY3Rpb24sDQogICAgICAgICAgICBk b2NzSWZDbXRzTW9kRkVDQ29kZXdvcmRMZW5ndGgsDQogICAgICAgICAgICBkb2NzSWZDbXRzTW9k U2NyYW1ibGVyU2VlZCwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RNYXhCdXJzdFNpemUsDQog ICAgICAgICAgICBkb2NzSWZDbXRzTW9kR3VhcmRUaW1lU2l6ZSwNCiAgICAgICAgICAgIGRvY3NJ ZkNtdHNNb2RMYXN0Q29kZXdvcmRTaG9ydGVuZWQsDQogICAgICAgICAgICBkb2NzSWZDbXRzTW9k U2NyYW1ibGVyLA0KICAgICAgICAgICAgZG9jc0lmQ210c01vZEJ5dGVJbnRlcmxlYXZlckRlcHRo LA0KICAgICAgICAgICAgZG9jc0lmQ210c01vZEJ5dGVJbnRlcmxlYXZlckJsb2NrU2l6ZSwNCiAg ICAgICAgICAgIGRvY3NJZkNtdHNNb2RQcmVhbWJsZVR5cGUsDQogICAgICAgICAgICBkb2NzSWZD bXRzTW9kVGNtRXJyb3JDb3JyZWN0aW9uT24sDQogICAgICAgICAgICBkb2NzSWZDbXRzTW9kU2Nk bWFJbnRlcmxlYXZlclN0ZXBTaXplLA0KICAgICAgICAgICAgZG9jc0lmQ210c01vZFNjZG1hU3By ZWFkZXJFbmFibGUsDQogICAgICAgICAgICBkb2NzSWZDbXRzTW9kU2NkbWFTdWJmcmFtZUNvZGVz LA0KICAgICAgICAgICAgZG9jc0lmQ210c01vZENoYW5uZWxUeXBlLA0KICAgICAgICAgICAgZG9j c0lmQ210c1Fvc1Byb2ZpbGVQZXJtaXNzaW9ucywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDbVB0 ciwNCiAgICAgICAgICAgIGRvY3NJZkNtdHNDaGFubmVsVXRpbGl6YXRpb25JbnRlcnZhbCwNCiAg ICAgICAgICAgIGRvY3NJZkNtdHNDaGFubmVsVXRVdGlsaXphdGlvbiwNCiAgICAgICAgICAgIGRv Y3NJZkNtdHNEb3duQ2hubEN0cklkLA0KICAgICAgICAgICAgZG9jc0lmQ210c0Rvd25DaG5sQ3Ry VG90YWxCeXRlcywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNEb3duQ2hubEN0clVzZWRCeXRlcywN CiAgICAgICAgICAgIGRvY3NJZkNtdHNEb3duQ2hubEN0ckV4dFRvdGFsQnl0ZXMsDQogICAgICAg ICAgICBkb2NzSWZDbXRzRG93bkNobmxDdHJFeHRVc2VkQnl0ZXMsDQogICAgICAgICAgICBkb2Nz SWZDbXRzVXBDaG5sQ3RySWQsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyVG90YWxN c2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyVWNhc3RHcmFudGVkTXNsb3Rz LA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0clRvdGFsQ250bk1zbG90cywNCiAgICAg ICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJVc2VkQ250bk1zbG90cywNCiAgICAgICAgICAgIGRv Y3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbE1zbG90cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNV cENobmxDdHJFeHRVY2FzdEdyYW50ZWRNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBD aG5sQ3RyRXh0VG90YWxDbnRuTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0 ckV4dFVzZWRDbnRuTXNsb3RzDQogICAgICAgIH0NCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVu dA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkdyb3VwIG9mIG9iamVjdHMgaW1w bGVtZW50ZWQgaW4gQ2FibGUgTW9kZW0gVGVybWluYXRpb24NCiAgICAgICAgICAgICBTeXN0ZW1z LiINCiAgICAgICAgOjo9IHsgZG9jc0lmR3JvdXBzVjIgMyB9DQoNCmRvY3NJZkNtdHNPcHRpb25h bEdyb3VwVjIgT0JKRUNULUdST1VQDQogICAgICAgIE9CSkVDVFMgew0KICAgICAgICAgICAgZG9j c0lmQ210c1VwQ2hubEN0ckNvbGxDbnRuTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1Vw Q2hubEN0clRvdGFsQ250blJlcU1zbG90cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxD dHJVc2VkQ250blJlcU1zbG90cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJDb2xs Q250blJlcU1zbG90cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJUb3RhbENudG5S ZXFEYXRhTXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0clVzZWRDbnRuUmVx RGF0YU1zbG90cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJDb2xsQ250blJlcURh dGFNc2xvdHMsDQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyVG90YWxDbnRuSW5pdE1h aW50TXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0clVzZWRDbnRuSW5pdE1h aW50TXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckNvbGxDbnRuSW5pdE1h aW50TXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dENvbGxDbnRuTXNs b3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRvdGFsQ250blJlcU1zbG90 cywNCiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJFeHRVc2VkQ250blJlcU1zbG90cywN CiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJFeHRDb2xsQ250blJlcU1zbG90cywNCiAg ICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbENudG5SZXFEYXRhTXNsb3RzLA0K ICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFVzZWRDbnRuUmVxRGF0YU1zbG90cywN CiAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJFeHRDb2xsQ250blJlcURhdGFNc2xvdHMs DQogICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0VG90YWxDbnRuSW5pdE1haW50TXNs b3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFVzZWRDbnRuSW5pdE1haW50 TXNsb3RzLA0KICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dENvbGxDbnRuSW5pdE1h aW50TXNsb3RzDQogICAgICAgIH0NCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAg ICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkdyb3VwIG9mIG9iamVjdHMgaW1wbGVtZW50ZWQg b3B0aW9uYWx5IGluIENhYmxlIE1vZGVtIA0KICAgICAgICAgICAgIFRlcm1pbmF0aW9uIFN5c3Rl bXMuIg0KICAgICAgICA6Oj0geyBkb2NzSWZHcm91cHNWMiA0IH0NCg0KDQoNCjIpIFJlbW92ZSB0 aGUgdGV4dCBpbmRpY2F0aW9uIG9mIG9wdGlvbmFsIG9yIG1hbmRhdG9yeSBvYmplY3QgaW4gdGhl IA0KREVTQ1JJUFRJT04gY2xhdXNlIG9mIG9iamVjdHMgaW4gdGFibGUgZG9jc0lmQ210c1VwQ2hh bm5lbENvdW50ZXJUYWJsZQ0KDQpDaGFuZ2Ugc2V2ZXJhbCBvY2N1cmVuY2VzIG9mICJ0aGUgdGhl IiB3aXRoICJ0aGUiDQoNCg0KcmVtb3ZlIHRleHQgZnJvbSBERVNDUklQVElPTiBjbGF1c2VzOg0K U3VwcG9ydCBmb3IgdGhpcyBvYmplY3QgaXMgb3B0aW9uYWwuIElmIHRoZSBvYmplY3QgaXMgbm90 DQogICAgICAgICAgICAgc3VwcG9ydGVkLCBhIHZhbHVlIG9mIHplcm8gaXMgcmV0dXJuZWQuDQph KSBSRVBMQUNFOg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3RyQ29sbENudG5Nc2xvdHMgT0JKRUNULVRZ UEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJl YWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9O DQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBv ZiBjb250ZW50aW9uDQogICAgICAgICAgICAgbWluaXNsb3RzIHN1YmplY3RlZCB0byBjb2xsaXNp b25zIG9uIHRoZSB1cHN0cmVhbSBsb2dpY2FsDQogICAgICAgICAgICAgY2hhbm5lbC4gRm9yIGNv bnRlbnRpb24gcmVnaW9ucywgdGhlc2UgYXJlIHRoZSBtaW5pc2xvdHMNCiAgICAgICAgICAgICBh cHBsaWNhYmxlIHRvIGJ1cnN0cyB0aGF0IHRoZSBDTVRTIGRldGVjdGVkLCBidXQgY291bGQgbm90 DQogICAgICAgICAgICAgY29ycmVjdGx5IHJlY2VpdmUuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJz aW9uIG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dENvbGxDbnRuTXNsb3Rz LCBhbmQgaXMgaW5jbHVkZWQgZm9yDQogICAgICAgICAgICAgYmFjayBjb21wYXRpYmlsaXR5IHdp dGggU05NUHYxIG1hbmFnZXJzLiBTdXBwb3J0IGZvciB0aGlzDQogICAgICAgICAgICAgb2JqZWN0 IGlzIG9wdGlvbmFsLiBJZiB0aGUgb2JqZWN0IGlzIG5vdCBzdXBwb3J0ZWQsIGENCiAgICAgICAg ICAgICB2YWx1ZSBvZiB6ZXJvIGlzIHJldHVybmVkLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVp dGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAg IGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXIN CiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAg ICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQg aWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkg MTAgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJUb3RhbENudG5SZXFNc2xvdHMgT0JKRUNULVRZ UEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJl YWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9O DQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBv ZiBjb250ZW50aW9uDQogICAgICAgICAgICAgcmVxdWVzdCBtaW5pc2xvdHMgZGVmaW5lZCBmb3Ig dGhpcyB1cHN0cmVhbSBsb2dpY2FsDQogICAgICAgICAgICAgY2hhbm5lbC4gVGhpcyBjb3VudCBp bmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMxDQogICAgICAgICAgICAgYXNzaWduZWQgdG8g YSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBvbiB0aGUgbG9naWNhbA0KICAgICAgICAgICAg IGNoYW5uZWwuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAgICAgZG9j c0lmQ210c1VwQ2hubEN0ckV4dFRvdGFsQ250blJlcU1zbG90cywgYW5kIGlzIGluY2x1ZGVkDQog ICAgICAgICAgICAgZm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2MSBtYW5hZ2Vycy4N CiAgICAgICAgICAgICBTdXBwb3J0IGZvciB0aGlzIG9iamVjdCBpcyBvcHRpb25hbC4gSWYgdGhl IG9iamVjdCBpcyBub3QNCiAgICAgICAgICAgICBzdXBwb3J0ZWQsIGEgdmFsdWUgb2YgemVybyBp cyByZXR1cm5lZC4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9m IHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9u IG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMg YXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVy RGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6 Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDExIH0NCg0KDQpkb2NzSWZDbXRz VXBDaG5sQ3RyVXNlZENudG5SZXFNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAg ICAgQ291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFU VVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVu dCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAg ICAgICAgcmVxdWVzdCBtaW5pc2xvdHMgdXRpbGl6ZWQgb24gdGhpcyB1cHN0cmVhbSBsb2dpY2Fs DQogICAgICAgICAgICAgY2hhbm5lbC4gVGhpcyBjb3VudCBpbmNsdWRlcyBhbGwgY29udGVudGlv biBtaW5pc2xvdHMgZm9yDQogICAgICAgICAgICAgSVVDMSBhcHBsaWNhYmxlIHRvIGJ1cnN0cyB0 aGF0IHRoZSBDTVRTIGNvcnJlY3RseQ0KICAgICAgICAgICAgIHJlY2VpdmVkLiBUaGlzIGlzIHRo ZSAzMiBiaXQgdmVyc2lvbiBvZg0KICAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJFeHRV c2VkQ250blJlcU1zbG90cywgYW5kIGlzIGluY2x1ZGVkDQogICAgICAgICAgICAgZm9yIGJhY2sg Y29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2MSBtYW5hZ2Vycy4gU3VwcG9ydCBmb3INCiAgICAgICAg ICAgICB0aGlzIG9iamVjdCBpcyBvcHRpb25hbC4gSWYgdGhlIG9iamVjdCBpcyBub3Qgc3VwcG9y dGVkLA0KICAgICAgICAgICAgIGEgdmFsdWUgb2YgemVybyBpcyByZXR1cm5lZC4NCiAgICAgICAg ICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2Nj dXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3Rl bSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0 aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9y IHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFu bmVsQ291bnRlckVudHJ5IDEyIH0NCg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3RyQ29sbENudG5SZXFN c2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAg IE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAg ICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGlu aXRpYWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgcmVxdWVzdCBtaW5pc2xv dHMgc3ViamVjdGVkIHRvIGNvbGxpc2lvbnMgb24gdGhpcyB1cHN0cmVhbQ0KICAgICAgICAgICAg IGxvZ2ljYWwgY2hhbm5lbC4gVGhpcyBpbmNsdWRlcyBhbGwgY29udGVudGlvbiBtaW5pc2xvdHMN CiAgICAgICAgICAgICBmb3IgSVVDMSBhcHBsaWNhYmxlIHRvIGJ1cnN0cyB0aGF0IHRoZSBDTVRT IGRldGVjdGVkLCBidXQNCiAgICAgICAgICAgICBjb3VsZCBub3QgY29ycmVjdGx5IHJlY2VpdmUu IFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1Vw Q2hubEN0ckV4dENvbGxDbnRuUmVxTXNsb3RzLCBhbmQgaXMgaW5jbHVkZWQNCiAgICAgICAgICAg ICBmb3IgYmFjayBjb21wYXRpYmlsaXR5IHdpdGggU05NUHYxIG1hbmFnZXJzLiBTdXBwb3J0IGZv cg0KICAgICAgICAgICAgIHRoaXMgb2JqZWN0IGlzIG9wdGlvbmFsLiBJZiB0aGUgb2JqZWN0IGlz IG5vdCBzdXBwb3J0ZWQsDQogICAgICAgICAgICAgYSB2YWx1ZSBvZiB6ZXJvIGlzIHJldHVybmVk Lg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3Vu dGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1h bmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0 ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51 aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJ ZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMTMgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJU b3RhbENudG5SZXFEYXRhTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENv dW50ZXIzMg0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAg ICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291 bnQsIGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAg IHJlcXVlc3QgZGF0YSBtaW5pc2xvdHMgZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2Fs DQogICAgICAgICAgICAgY2hhbm5lbC4gVGhpcyBjb3VudCBpbmNsdWRlcyBhbGwgbWluaXNsb3Rz IGZvciBJVUMyDQogICAgICAgICAgICAgYXNzaWduZWQgdG8gYSBicm9hZGNhc3Qgb3IgbXVsdGlj YXN0IFNJRCBvbiB0aGUgbG9naWNhbA0KICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgaXMgdGhl IDMyIGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRv dGFsQ250blJlcURhdGFNc2xvdHMsIGFuZCBpcw0KICAgICAgICAgICAgIGluY2x1ZGVkIGZvciBi YWNrIGNvbXBhdGliaWxpdHkgd2l0aCBTTk1QdjEgbWFuYWdlcnMuDQogICAgICAgICAgICAgU3Vw cG9ydCBmb3IgdGhpcyBvYmplY3QgaXMgb3B0aW9uYWwuIElmIHRoZSBvYmplY3QgaXMgbm90DQog ICAgICAgICAgICAgc3VwcG9ydGVkLCBhIHZhbHVlIG9mIHplcm8gaXMgcmV0dXJuZWQuDQogICAg ICAgICAgICAgRGlzY29udGludWl0aWVzIGluIHRoZSB2YWx1ZSBvZiB0aGlzIGNvdW50ZXIgY2Fu IG9jY3VyDQogICAgICAgICAgICAgYXQgcmVpbml0aWFsaXphdGlvbiBvZiB0aGUgbWFuYWdlZCBz eXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAgICAgICAgIHRpbWVzIGFzIGluZGljYXRlZCBieSB0 aGUgdGhlIHZhbHVlIG9mIA0KICAgICAgICAgICAgIGlmQ291bnRlckRpc2NvbnRpbnVpdHlUaW1l IGZvciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4LiINCiAgICAgICAgOjo9IHsgZG9jc0lmQ210c1Vw Q2hhbm5lbENvdW50ZXJFbnRyeSAxNCB9DQoNCg0KZG9jc0lmQ210c1VwQ2hubEN0clVzZWRDbnRu UmVxRGF0YU1zbG90cyBPQkpFQ1QtVFlQRQ0KICAgICAgICBTWU5UQVggICAgICBDb3VudGVyMzIN CiAgICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJl bnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJDdXJyZW50IGNvdW50LCBmcm9t IENNVFMgaW5pdGlhbGl6YXRpb24sIG9mIGNvbnRlbnRpb24NCiAgICAgICAgICAgICByZXF1ZXN0 IGRhdGEgbWluaXNsb3RzIHV0aWxpemVkIG9uIHRoaXMgdXBzdHJlYW0gbG9naWNhbA0KICAgICAg ICAgICAgIGNoYW5uZWwuIFRoaXMgaW5jbHVkZXMgYWxsIGNvbnRlbnRpb24gbWluaXNsb3RzIGZv ciBJVUMyDQogICAgICAgICAgICAgYXBwbGljYWJsZSB0byBidXJzdHMgdGhhdCB0aGUgQ01UUyBj b3JyZWN0bHkgcmVjZWl2ZWQuDQogICAgICAgICAgICAgVGhpcyBpcyB0aGUgMzIgYml0IHZlcnNp b24gb2YgDQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFVzZWRDbnRuUmVxRGF0 YU1zbG90cywgYW5kIGlzDQogICAgICAgICAgICAgaW5jbHVkZWQgZm9yIGJhY2sgY29tcGF0aWJp bGl0eSB3aXRoIFNOTVB2MSBtYW5hZ2Vycy4NCiAgICAgICAgICAgICBTdXBwb3J0IGZvciB0aGlz IG9iamVjdCBpcyBvcHRpb25hbC4gSWYgdGhlIG9iamVjdCBpcyBub3QNCiAgICAgICAgICAgICBz dXBwb3J0ZWQsIGEgdmFsdWUgb2YgemVybyBpcyByZXR1cm5lZC4NCiAgICAgICAgICAgICBEaXNj b250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAg ICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0 IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUg b2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3Nv Y2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRl ckVudHJ5IDE1IH0NCg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3RyQ29sbENudG5SZXFEYXRhTXNsb3Rz IE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgICAgICBNQVgt QUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBE RVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20gQ01UUyBpbml0aWFs aXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAgIHJlcXVlc3QgZGF0YSBtaW5pc2xv dHMgc3ViamVjdGVkIHRvIGNvbGxpc2lvbnMgb24gdGhpcw0KICAgICAgICAgICAgIHVwc3RyZWFt IGxvZ2ljYWwgY2hhbm5lbC4gVGhpcyBpbmNsdWRlcyBhbGwgY29udGVudGlvbg0KICAgICAgICAg ICAgIG1pbmlzbG90cyBmb3IgSVVDMiBhcHBsaWNhYmxlIHRvIGJ1cnN0cyB0aGF0IHRoZSBDTVRT DQogICAgICAgICAgICAgZGV0ZWN0ZWQsIGJ1dCBjb3VsZCBub3QgY29ycmVjdGx5IHJlY2VpdmUu IFRoaXMgaXMgdGhlIDMyDQogICAgICAgICAgICAgYml0IHZlcnNpb24gb2YNCiAgICAgICAgICAg ICBkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0Q29sbENudG5SZXFEYXRhTXNsb3RzLCBhbmQgaXMNCiAg ICAgICAgICAgICBpbmNsdWRlZCBmb3IgYmFjayBjb21wYXRpYmlsaXR5IHdpdGggU05NUHYxIG1h bmFnZXJzLg0KICAgICAgICAgICAgIFN1cHBvcnQgZm9yIHRoaXMgb2JqZWN0IGlzIG9wdGlvbmFs LiBJZiB0aGUgb2JqZWN0IGlzIG5vdA0KICAgICAgICAgICAgIHN1cHBvcnRlZCwgYSB2YWx1ZSBv ZiB6ZXJvIGlzIHJldHVybmVkLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUg dmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlh bGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAg ICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBp ZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQog ICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMTYgfQ0KDQoNCmRv Y3NJZkNtdHNVcENobmxDdHJUb3RhbENudG5Jbml0TWFpbnRNc2xvdHMgT0JKRUNULVRZUEUNCiAg ICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25s eQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAg ICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250 ZW50aW9uDQogICAgICAgICAgICAgaW5pdGlhbCBtYWludGVuYW5jZSBtaW5pc2xvdHMgZGVmaW5l ZCBmb3IgdGhpcyB1cHN0cmVhbQ0KICAgICAgICAgICAgIGxvZ2ljYWwgY2hhbm5lbC4gVGhpcyBp bmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMzDQogICAgICAgICAgICAgYXNzaWduZWQgdG8g YSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBvbiB0aGUgbG9naWNhbA0KICAgICAgICAgICAg IGNoYW5uZWwuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAgICAgZG9j c0lmQ210c1VwQ2hubEN0ckV4dFRvdGFsQ250bkluaXRNYWludE1zbG90cywNCiAgICAgICAgICAg ICBhbmQgaXMgaW5jbHVkZWQgZm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2MQ0KICAg ICAgICAgICAgIG1hbmFnZXJzLiBTdXBwb3J0IGZvciB0aGlzIG9iamVjdCBpcyBvcHRpb25hbC4g SWYgdGhlDQogICAgICAgICAgICAgb2JqZWN0IGlzIG5vdCBzdXBwb3J0ZWQsIGEgdmFsdWUgb2Yg emVybyBpcyByZXR1cm5lZC4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZh bHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxp emF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAg dGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZD b3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAg ICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDE3IH0NCg0KDQpkb2Nz SWZDbXRzVXBDaG5sQ3RyVXNlZENudG5Jbml0TWFpbnRNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAg ICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0K ICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAg ICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250ZW50 aW9uDQogICAgICAgICAgICAgaW5pdGlhbCBtYWludGVuYW5jZSBtaW5pc2xvdHMgdXRpbGl6ZWQg b24gdGhpcyB1cHN0cmVhbQ0KICAgICAgICAgICAgIGxvZ2ljYWwgY2hhbm5lbC4gVGhpcyBpbmNs dWRlcyBhbGwgY29udGVudGlvbiBtaW5pc2xvdHMNCiAgICAgICAgICAgICBmb3IgSVVDMyBhcHBs aWNhYmxlIHRvIGJ1cnN0cyB0aGF0IHRoZSBDTVRTIGNvcnJlY3RseQ0KICAgICAgICAgICAgIHJl Y2VpdmVkLiBUaGlzIGlzIHRoZSAzMiBiaXQgdmVyc2lvbiBvZiANCiAgICAgICAgICAgICBkb2Nz SWZDbXRzVXBDaG5sQ3RyRXh0VXNlZENudG5Jbml0TWFpbnRNc2xvdHMsDQogICAgICAgICAgICAg YW5kIGlzIGluY2x1ZGVkIGZvciBiYWNrIGNvbXBhdGliaWxpdHkgd2l0aCBTTk1QdjENCiAgICAg ICAgICAgICBtYW5hZ2Vycy4gU3VwcG9ydCBmb3IgdGhpcyBvYmplY3QgaXMgb3B0aW9uYWwuIElm IHRoZQ0KICAgICAgICAgICAgIG9iamVjdCBpcyBub3Qgc3VwcG9ydGVkLCBhIHZhbHVlIG9mIHpl cm8gaXMgcmV0dXJuZWQuDQogICAgICAgICAgICAgRGlzY29udGludWl0aWVzIGluIHRoZSB2YWx1 ZSBvZiB0aGlzIGNvdW50ZXIgY2FuIG9jY3VyDQogICAgICAgICAgICAgYXQgcmVpbml0aWFsaXph dGlvbiBvZiB0aGUgbWFuYWdlZCBzeXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAgICAgICAgIHRp bWVzIGFzIGluZGljYXRlZCBieSB0aGUgdGhlIHZhbHVlIG9mIA0KICAgICAgICAgICAgIGlmQ291 bnRlckRpc2NvbnRpbnVpdHlUaW1lIGZvciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4LiINCiAgICAg ICAgOjo9IHsgZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50ZXJFbnRyeSAxOCB9DQoNCg0KZG9jc0lm Q210c1VwQ2hubEN0ckNvbGxDbnRuSW5pdE1haW50TXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAg IFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAg ICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAg ICAgIkN1cnJlbnQgY291bnQsIGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29udGVudGlv bg0KICAgICAgICAgICAgIGluaXRpYWwgbWFpbnRlbmFuY2UgbWluaXNsb3RzIHN1YmplY3RlZCB0 byBjb2xsaXNpb25zIG9uDQogICAgICAgICAgICAgdGhpcyB1cHN0cmVhbSBsb2dpY2FsIGNoYW5u ZWwuIFRoaXMgaW5jbHVkZXMgYWxsDQogICAgICAgICAgICAgY29udGVudGlvbiBtaW5pc2xvdHMg Zm9yIElVQzMgYXBwbGljYWJsZSB0byBidXJzdHMgdGhhdA0KICAgICAgICAgICAgIHRoZSBDTVRT IGRldGVjdGVkLCBidXQgY291bGQgbm90IGNvcnJlY3RseSByZWNlaXZlLiAgICAgICANCiAgICAg ICAgICAgICBUaGlzIGlzIHRoZSAzMiBiaXQgdmVyc2lvbiBvZiANCiAgICAgICAgICAgICBkb2Nz SWZDbXRzVXBDaG5sQ3RyRXh0Q29sbENudG5Jbml0TWFpbnRNc2xvdHMsDQogICAgICAgICAgICAg YW5kIGlzIGluY2x1ZGVkIGZvciBiYWNrIGNvbXBhdGliaWxpdHkgd2l0aCBTTk1QdjENCiAgICAg ICAgICAgICBtYW5hZ2Vycy4gU3VwcG9ydCBmb3IgdGhpcyBvYmplY3QgaXMgb3B0aW9uYWwuIElm IHRoZQ0KICAgICAgICAgICAgIG9iamVjdCBpcyBub3Qgc3VwcG9ydGVkLCBhIHZhbHVlIG9mIHpl cm8gaXMgcmV0dXJuZWQuDQogICAgICAgICAgICAgRGlzY29udGludWl0aWVzIGluIHRoZSB2YWx1 ZSBvZiB0aGlzIGNvdW50ZXIgY2FuIG9jY3VyDQogICAgICAgICAgICAgYXQgcmVpbml0aWFsaXph dGlvbiBvZiB0aGUgbWFuYWdlZCBzeXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAgICAgICAgIHRp bWVzIGFzIGluZGljYXRlZCBieSB0aGUgdGhlIHZhbHVlIG9mIA0KICAgICAgICAgICAgIGlmQ291 bnRlckRpc2NvbnRpbnVpdHlUaW1lIGZvciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4LiINCiAgICAg ICAgOjo9IHsgZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50ZXJFbnRyeSAxOSB9DQoNCg0KZG9jc0lm Q210c1VwQ2hubEN0ckV4dENvbGxDbnRuTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRB WCAgICAgIENvdW50ZXI2NA0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAg U1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1 cnJlbnQgY291bnQsIGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29sbGlzaW9uDQogICAg ICAgICAgICAgY29udGVudGlvbiBtaW5pc2xvdHMgb24gdGhlIHVwc3RyZWFtIGxvZ2ljYWwgY2hh bm5lbC4NCiAgICAgICAgICAgICBGb3IgY29udGVudGlvbiByZWdpb25zLCB0aGVzZSBhcmUgdGhl IG1pbmlzbG90cyBhcHBsaWNhYmxlDQogICAgICAgICAgICAgdG8gYnVyc3RzIHRoYXQgdGhlIENN VFMgZGV0ZWN0ZWQsIGJ1dCBjb3VsZCBub3QgY29ycmVjdGx5DQogICAgICAgICAgICAgcmVjZWl2 ZS4gVGhpcyBpcyB0aGUgNjQgYml0IHZlcnNpb24gb2YNCiAgICAgICAgICAgICBkb2NzSWZDbXRz VXBDaG5sQ3RyQ29sbENudG5Nc2xvdHMsIGFuZCB3aWxsIG5vdCBiZQ0KICAgICAgICAgICAgIGFj Y2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLiBTdXBwb3J0IGZvciB0aGlzIG9iamVjdCBpcw0K ICAgICAgICAgICAgIG9wdGlvbmFsLiBJZiB0aGUgb2JqZWN0IGlzIG5vdCBzdXBwb3J0ZWQsIGEg dmFsdWUgb2YgemVybw0KICAgICAgICAgICAgIGlzIHJldHVybmVkLg0KICAgICAgICAgICAgIERp c2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAg ICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQg YXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1 ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFz c29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3Vu dGVyRW50cnkgMjAgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbENudG5SZXFNc2xv dHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1B WC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRp YWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgcmVxdWVzdCBtaW5pc2xvdHMg ZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2FsDQogICAgICAgICAgICAgY2hhbm5lbC4g VGhpcyBjb3VudCBpbmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMxDQogICAgICAgICAgICAg YXNzaWduZWQgdG8gYSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBvbiB0aGUgbG9naWNhbA0K ICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgaXMgdGhlIDY0IGJpdCB2ZXJzaW9uIG9mDQogICAg ICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0clRvdGFsQ250blJlcU1zbG90cywgYW5kIHdpbGwg bm90IGJlDQogICAgICAgICAgICAgYWNjZXNzaWJsZSB0byBTTk1QdjEgbWFuYWdlcnMuIFN1cHBv cnQgZm9yIHRoaXMgb2JqZWN0DQogICAgICAgICAgICAgaXMgb3B0aW9uYWwuIElmIHRoZSBvYmpl Y3QgaXMgbm90IHN1cHBvcnRlZCwgYSB2YWx1ZSBvZg0KICAgICAgICAgICAgIHplcm8gaXMgcmV0 dXJuZWQuDQogICAgICAgICAgICAgRGlzY29udGludWl0aWVzIGluIHRoZSB2YWx1ZSBvZiB0aGlz IGNvdW50ZXIgY2FuIG9jY3VyDQogICAgICAgICAgICAgYXQgcmVpbml0aWFsaXphdGlvbiBvZiB0 aGUgbWFuYWdlZCBzeXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAgICAgICAgIHRpbWVzIGFzIGlu ZGljYXRlZCBieSB0aGUgdGhlIHZhbHVlIG9mIA0KICAgICAgICAgICAgIGlmQ291bnRlckRpc2Nv bnRpbnVpdHlUaW1lIGZvciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4LiINCiAgICAgICAgOjo9IHsg ZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50ZXJFbnRyeSAyMSB9DQoNCg0KZG9jc0lmQ210c1VwQ2hu bEN0ckV4dFVzZWRDbnRuUmVxTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAg IENvdW50ZXI2NA0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVT ICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQg Y291bnQsIGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAg ICAgIHJlcXVlc3QgbWluaXNsb3RzIHV0aWxpemVkIG9uIHRoaXMgdXBzdHJlYW0gbG9naWNhbA0K ICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgY291bnQgaW5jbHVkZXMgYWxsIGNvbnRlbnRpb24g bWluaXNsb3RzIGZvcg0KICAgICAgICAgICAgIElVQzEgYXBwbGljYWJsZSB0byBidXJzdHMgdGhh dCB0aGUgQ01UUyBjb3JyZWN0bHkNCiAgICAgICAgICAgICByZWNlaXZlZC4gVGhpcyBpcyB0aGUg NjQgYml0IHZlcnNpb24gb2YNCiAgICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyVXNlZENu dG5SZXFNc2xvdHMsIGFuZCB3aWxsIG5vdCBiZQ0KICAgICAgICAgICAgIGFjY2Vzc2libGUgdG8g U05NUHYxIG1hbmFnZXJzLiBTdXBwb3J0IGZvciB0aGlzIG9iamVjdCBpcw0KICAgICAgICAgICAg IG9wdGlvbmFsLiBJZiB0aGUgb2JqZWN0IGlzIG5vdCBzdXBwb3J0ZWQsIGEgdmFsdWUgb2YgemVy bw0KICAgICAgICAgICAgIGlzIHJldHVybmVkLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGll cyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0 IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAg ICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAg ICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJ bmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMjIg fQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRDb2xsQ250blJlcU1zbG90cyBPQkpFQ1QtVFlQ RQ0KICAgICAgICBTWU5UQVggICAgICBDb3VudGVyNjQNCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVh ZC1vbmx5DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04N CiAgICAgICAgICAgICJDdXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRpb24sIG9m IGNvbnRlbnRpb24NCiAgICAgICAgICAgICByZXF1ZXN0IG1pbmlzbG90cyBzdWJqZWN0ZWQgdG8g Y29sbGlzaW9ucyBvbiB0aGlzIHVwc3RyZWFtDQogICAgICAgICAgICAgbG9naWNhbCBjaGFubmVs LiBUaGlzIGluY2x1ZGVzIGFsbCBjb250ZW50aW9uIG1pbmlzbG90cw0KICAgICAgICAgICAgIGZv ciBJVUMxIGFwcGxpY2FibGUgdG8gYnVyc3RzIHRoYXQgdGhlIENNVFMgZGV0ZWN0ZWQsDQogICAg ICAgICAgICAgYnV0IGNvdWxkIG5vdCBjb3JyZWN0bHkgcmVjZWl2ZS4gVGhpcyBpcyB0aGUgNjQg Yml0DQogICAgICAgICAgICAgdmVyc2lvbiBvZiBkb2NzSWZDbXRzVXBDaG5sQ3RyQ29sbENudG5S ZXFNc2xvdHMsIGFuZCB3aWxsDQogICAgICAgICAgICAgbm90IGJlIGFjY2Vzc2libGUgdG8gU05N UHYxIG1hbmFnZXJzLiBTdXBwb3J0IGZvciB0aGlzDQogICAgICAgICAgICAgb2JqZWN0IGlzIG9w dGlvbmFsLiBJZiB0aGUgb2JqZWN0IGlzIG5vdCBzdXBwb3J0ZWQsIGENCiAgICAgICAgICAgICB2 YWx1ZSBvZiB6ZXJvIGlzIHJldHVybmVkLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBp biB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJl aW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAg ICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAg ICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRl eC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMjMgfQ0K DQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbENudG5SZXFEYXRhTXNsb3RzIE9CSkVDVC1U WVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXI2NA0KICAgICAgICBNQVgtQUNDRVNTICBy ZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElP Tg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwg b2YgY29udGVudGlvbg0KICAgICAgICAgICAgIHJlcXVlc3QgZGF0YSBtaW5pc2xvdHMgZGVmaW5l ZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2FsDQogICAgICAgICAgICAgY2hhbm5lbC4gVGhpcyBj b3VudCBpbmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMyDQogICAgICAgICAgICAgYXNzaWdu ZWQgdG8gYSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBvbiB0aGUgbG9naWNhbA0KICAgICAg ICAgICAgIGNoYW5uZWwuIFRoaXMgaXMgdGhlIDY0IGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAg ICAgZG9jc0lmQ210c1VwQ2hubEN0clRvdGFsQ250blJlcURhdGFNc2xvdHMsIGFuZCB3aWxsIG5v dCBiZQ0KICAgICAgICAgICAgIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLiBTdXBwb3J0 IGZvciB0aGlzIG9iamVjdCBpcw0KICAgICAgICAgICAgIG9wdGlvbmFsLiBJZiB0aGUgb2JqZWN0 IGlzIG5vdCBzdXBwb3J0ZWQsIGEgdmFsdWUgb2YgemVybw0KICAgICAgICAgICAgIGlzIHJldHVy bmVkLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBj b3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhl IG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRp Y2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250 aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRv Y3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMjQgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxD dHJFeHRVc2VkQ250blJlcURhdGFNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAg ICAgQ291bnRlcjY0DQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFU VVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVu dCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAg ICAgICAgcmVxdWVzdCBkYXRhIG1pbmlzbG90cyB1dGlsaXplZCBvbiB0aGlzIHVwc3RyZWFtIGxv Z2ljYWwNCiAgICAgICAgICAgICBjaGFubmVsLiBUaGlzIGluY2x1ZGVzIGFsbCBjb250ZW50aW9u IG1pbmlzbG90cyBmb3IgSVVDMg0KICAgICAgICAgICAgIGFwcGxpY2FibGUgdG8gYnVyc3RzIHRo YXQgdGhlIENNVFMgY29ycmVjdGx5IHJlY2VpdmVkLiAgICANCiAgICAgICAgICAgICBUaGlzIGlz IHRoZSA2NCBiaXQgdmVyc2lvbiBvZg0KICAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJV c2VkQ250blJlcURhdGFNc2xvdHMsIGFuZCB3aWxsIG5vdCBiZQ0KICAgICAgICAgICAgIGFjY2Vz c2libGUgdG8gU05NUHYxIG1hbmFnZXJzLiBTdXBwb3J0IGZvciB0aGlzIG9iamVjdCBpcw0KICAg ICAgICAgICAgIG9wdGlvbmFsLiBJZiB0aGUgb2JqZWN0IGlzIG5vdCBzdXBwb3J0ZWQsIGEgdmFs dWUgb2YgemVybw0KICAgICAgICAgICAgIGlzIHJldHVybmVkLg0KICAgICAgICAgICAgIERpc2Nv bnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAg ICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQg b3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBv ZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29j aWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVy RW50cnkgMjUgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRDb2xsQ250blJlcURhdGFNc2xv dHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1B WC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRp YWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgcmVxdWVzdCBkYXRhIG1pbmlz bG90cyBzdWJqZWN0ZWQgdG8gY29sbGlzaW9ucyBvbiB0aGlzDQogICAgICAgICAgICAgdXBzdHJl YW0gbG9naWNhbCBjaGFubmVsLiBUaGlzIGluY2x1ZGVzIGFsbCBjb250ZW50aW9uDQogICAgICAg ICAgICAgbWluaXNsb3RzIGZvciBJVUMyIGFwcGxpY2FibGUgdG8gYnVyc3RzIHRoYXQgdGhlIENN VFMNCiAgICAgICAgICAgICBkZXRlY3RlZCwgYnV0IGNvdWxkIG5vdCBjb3JyZWN0bHkgcmVjZWl2 ZS4gVGhpcyBpcyB0aGUNCiAgICAgICAgICAgICA2NCBiaXQgdmVyc2lvbiBvZg0KICAgICAgICAg ICAgIGRvY3NJZkNtdHNVcENobmxDdHJDb2xsQ250blJlcURhdGFNc2xvdHMsDQogICAgICAgICAg ICAgYW5kIHdpbGwgbm90IGJlIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLiBTdXBwb3J0 DQogICAgICAgICAgICAgZm9yIHRoaXMgb2JqZWN0IGlzIG9wdGlvbmFsLiBJZiB0aGUgb2JqZWN0 IGlzIG5vdA0KICAgICAgICAgICAgIHN1cHBvcnRlZCwgYSB2YWx1ZSBvZiB6ZXJvIGlzIHJldHVy bmVkLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBj b3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhl IG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRp Y2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250 aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRv Y3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMjYgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxD dHJFeHRUb3RhbENudG5Jbml0TWFpbnRNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFY ICAgICAgQ291bnRlcjY0DQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBT VEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3Vy cmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBpbml0aWFsDQogICAgICAg ICAgICAgbWFpbnRlbmFuY2UgbWluaXNsb3RzIGRlZmluZWQgZm9yIHRoaXMgdXBzdHJlYW0gbG9n aWNhbA0KICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgY291bnQgaW5jbHVkZXMgYWxsIG1pbmlz bG90cyBmb3IgSVVDMw0KICAgICAgICAgICAgIGFzc2lnbmVkIHRvIGEgYnJvYWRjYXN0IG9yIG11 bHRpY2FzdCBTSUQgb24gdGhlIGxvZ2ljYWwNCiAgICAgICAgICAgICBjaGFubmVsLiBUaGlzIGlz IHRoZSA2NCBiaXQgdmVyc2lvbiBvZiANCiAgICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3Ry VG90YWxDbnRuSW5pdE1haW50TXNsb3RzLA0KICAgICAgICAgICAgIGFuZCB3aWxsIG5vdCBiZSBh Y2Nlc3NpYmxlIHRvIFNOTVB2MSBtYW5hZ2Vycy4gU3VwcG9ydCBmb3INCiAgICAgICAgICAgICB0 aGlzIG9iamVjdCBpcyBvcHRpb25hbC4gSWYgdGhlIG9iamVjdCBpcyBub3Qgc3VwcG9ydGVkLA0K ICAgICAgICAgICAgIGEgdmFsdWUgb2YgemVybyBpcyByZXR1cm5lZC4NCiAgICAgICAgICAgICBE aXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAg ICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5k IGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFs dWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBh c3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291 bnRlckVudHJ5IDI3IH0NCg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0VXNlZENudG5Jbml0TWFp bnRNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAg ICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQog ICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRT IGluaXRpYWxpemF0aW9uLCBvZiBpbml0aWFsDQogICAgICAgICAgICAgbWFpbnRlbmFuY2UgbWlu aXNsb3RzIHV0aWxpemVkIG9uIHRoaXMgdXBzdHJlYW0gbG9naWNhbA0KICAgICAgICAgICAgIGNo YW5uZWwuIFRoaXMgaW5jbHVkZXMgYWxsIGNvbnRlbnRpb24gbWluaXNsb3RzIGZvciBJVUMzDQog ICAgICAgICAgICAgYXBwbGljYWJsZSB0byBidXJzdHMgdGhhdCB0aGUgQ01UUyBjb3JyZWN0bHkg cmVjZWl2ZWQuICAgIA0KICAgICAgICAgICAgIFRoaXMgaXMgdGhlIDY0IGJpdCB2ZXJzaW9uIG9m DQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0clVzZWRDbnRuSW5pdE1haW50TXNsb3Rz LA0KICAgICAgICAgICAgIGFuZCB3aWxsIG5vdCBiZSBhY2Nlc3NpYmxlIHRvIFNOTVB2MSBtYW5h Z2Vycy4gU3VwcG9ydCBmb3INCiAgICAgICAgICAgICB0aGlzIG9iamVjdCBpcyBvcHRpb25hbC4g SWYgdGhlIG9iamVjdCBpcyBub3Qgc3VwcG9ydGVkLA0KICAgICAgICAgICAgIGEgdmFsdWUgb2Yg emVybyBpcyByZXR1cm5lZC4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZh bHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxp emF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAg dGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZD b3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAg ICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDI4IH0NCg0KDQpkb2Nz SWZDbXRzVXBDaG5sQ3RyRXh0Q29sbENudG5Jbml0TWFpbnRNc2xvdHMgT0JKRUNULVRZUEUNCiAg ICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25s eQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAg ICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250 ZW50aW9uDQogICAgICAgICAgICAgaW5pdGlhbCBtYWludGVuYW5jZSBtaW5pc2xvdHMgc3ViamVj dGVkIHRvIGNvbGxpc2lvbnMgb24NCiAgICAgICAgICAgICB0aGlzIHVwc3RyZWFtIGxvZ2ljYWwg Y2hhbm5lbC4gVGhpcyBpbmNsdWRlcyBhbGwNCiAgICAgICAgICAgICBjb250ZW50aW9uIG1pbmlz bG90cyBmb3IgSVVDMyBhcHBsaWNhYmxlIHRvIGJ1cnN0cyB0aGF0DQogICAgICAgICAgICAgdGhl IENNVFMgZGV0ZWN0ZWQsIGJ1dCBjb3VsZCBub3QgY29ycmVjdGx5IHJlY2VpdmUuICAgICAgIA0K ICAgICAgICAgICAgIFRoaXMgaXMgdGhlIDY0IGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAgICAg ZG9jc0lmQ210c1VwQ2hubEN0ckNvbGxDbnRuSW5pdE1haW50TXNsb3RzLCBhbmQgd2lsbCBub3QN CiAgICAgICAgICAgICBiZSBhY2Nlc3NpYmxlIHRvIFNOTVB2MSBtYW5hZ2Vycy4gU3VwcG9ydCBm b3IgdGhpcyBvYmplY3QNCiAgICAgICAgICAgICBpcyBvcHRpb25hbC4gSWYgdGhlIG9iamVjdCBp cyBub3Qgc3VwcG9ydGVkLCBhIHZhbHVlIG9mDQogICAgICAgICAgICAgemVybyBpcyByZXR1cm5l ZC4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291 bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBt YW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNh dGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGlu dWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2Nz SWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDI5IH0NCg0KDQpXSVRIOg0KDQpkb2NzSWZDbXRz VXBDaG5sQ3RyQ29sbENudG5Nc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAg Q291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMg ICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBj b3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAg ICAgbWluaXNsb3RzIHN1YmplY3RlZCB0byBjb2xsaXNpb25zIG9uIHRoZSB1cHN0cmVhbSBsb2dp Y2FsDQogICAgICAgICAgICAgY2hhbm5lbC4gRm9yIGNvbnRlbnRpb24gcmVnaW9ucywgdGhlc2Ug YXJlIHRoZSBtaW5pc2xvdHMNCiAgICAgICAgICAgICBhcHBsaWNhYmxlIHRvIGJ1cnN0cyB0aGF0 IHRoZSBDTVRTIGRldGVjdGVkLCBidXQgY291bGQgbm90DQogICAgICAgICAgICAgY29ycmVjdGx5 IHJlY2VpdmUuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAgICAgZG9j c0lmQ210c1VwQ2hubEN0ckV4dENvbGxDbnRuTXNsb3RzLCBhbmQgaXMgaW5jbHVkZWQgZm9yDQog ICAgICAgICAgICAgYmFjayBjb21wYXRpYmlsaXR5IHdpdGggU05NUHYxIG1hbmFnZXJzLg0KICAg ICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNh biBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQg c3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkg dGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGlt ZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNV cENoYW5uZWxDb3VudGVyRW50cnkgMTAgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJUb3RhbENu dG5SZXFNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQog ICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50 DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBD TVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgcmVxdWVzdCBt aW5pc2xvdHMgZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2FsDQogICAgICAgICAgICAg Y2hhbm5lbC4gVGhpcyBjb3VudCBpbmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMxDQogICAg ICAgICAgICAgYXNzaWduZWQgdG8gYSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBvbiB0aGUg bG9naWNhbA0KICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9u IG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRvdGFsQ250blJlcU1zbG90 cywgYW5kIGlzIGluY2x1ZGVkDQogICAgICAgICAgICAgZm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3 aXRoIFNOTVB2MSBtYW5hZ2Vycy4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhl IHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRp YWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAg ICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAg aWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0K ICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDExIH0NCg0KDQpk b2NzSWZDbXRzVXBDaG5sQ3RyVXNlZENudG5SZXFNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAg U1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAg ICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAg ICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250ZW50aW9u DQogICAgICAgICAgICAgcmVxdWVzdCBtaW5pc2xvdHMgdXRpbGl6ZWQgb24gdGhpcyB1cHN0cmVh bSBsb2dpY2FsDQogICAgICAgICAgICAgY2hhbm5lbC4gVGhpcyBjb3VudCBpbmNsdWRlcyBhbGwg Y29udGVudGlvbiBtaW5pc2xvdHMgZm9yDQogICAgICAgICAgICAgSVVDMSBhcHBsaWNhYmxlIHRv IGJ1cnN0cyB0aGF0IHRoZSBDTVRTIGNvcnJlY3RseQ0KICAgICAgICAgICAgIHJlY2VpdmVkLiBU aGlzIGlzIHRoZSAzMiBiaXQgdmVyc2lvbiBvZg0KICAgICAgICAgICAgIGRvY3NJZkNtdHNVcENo bmxDdHJFeHRVc2VkQ250blJlcU1zbG90cywgYW5kIGlzIGluY2x1ZGVkDQogICAgICAgICAgICAg Zm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2MSBtYW5hZ2Vycy4NCiAgICAgICAgICAg ICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXIN CiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwg YW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUg dmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRo ZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVs Q291bnRlckVudHJ5IDEyIH0NCg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3RyQ29sbENudG5SZXFNc2xv dHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAgIE1B WC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRp YWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgcmVxdWVzdCBtaW5pc2xvdHMg c3ViamVjdGVkIHRvIGNvbGxpc2lvbnMgb24gdGhpcyB1cHN0cmVhbQ0KICAgICAgICAgICAgIGxv Z2ljYWwgY2hhbm5lbC4gVGhpcyBpbmNsdWRlcyBhbGwgY29udGVudGlvbiBtaW5pc2xvdHMNCiAg ICAgICAgICAgICBmb3IgSVVDMSBhcHBsaWNhYmxlIHRvIGJ1cnN0cyB0aGF0IHRoZSBDTVRTIGRl dGVjdGVkLCBidXQNCiAgICAgICAgICAgICBjb3VsZCBub3QgY29ycmVjdGx5IHJlY2VpdmUuIFRo aXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hu bEN0ckV4dENvbGxDbnRuUmVxTXNsb3RzLCBhbmQgaXMgaW5jbHVkZWQNCiAgICAgICAgICAgICBm b3IgYmFjayBjb21wYXRpYmlsaXR5IHdpdGggU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAgICAg IERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0K ICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBh bmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2 YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhl IGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxD b3VudGVyRW50cnkgMTMgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJUb3RhbENudG5SZXFEYXRh TXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgICAg ICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAg ICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20gQ01UUyBp bml0aWFsaXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAgIHJlcXVlc3QgZGF0YSBt aW5pc2xvdHMgZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2FsDQogICAgICAgICAgICAg Y2hhbm5lbC4gVGhpcyBjb3VudCBpbmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMyDQogICAg ICAgICAgICAgYXNzaWduZWQgdG8gYSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBvbiB0aGUg bG9naWNhbA0KICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9u IG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRvdGFsQ250blJlcURhdGFN c2xvdHMsIGFuZCBpcw0KICAgICAgICAgICAgIGluY2x1ZGVkIGZvciBiYWNrIGNvbXBhdGliaWxp dHkgd2l0aCBTTk1QdjEgbWFuYWdlcnMuDQogICAgICAgICAgICAgRGlzY29udGludWl0aWVzIGlu IHRoZSB2YWx1ZSBvZiB0aGlzIGNvdW50ZXIgY2FuIG9jY3VyDQogICAgICAgICAgICAgYXQgcmVp bml0aWFsaXphdGlvbiBvZiB0aGUgbWFuYWdlZCBzeXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAg ICAgICAgIHRpbWVzIGFzIGluZGljYXRlZCBieSB0aGUgdGhlIHZhbHVlIG9mIA0KICAgICAgICAg ICAgIGlmQ291bnRlckRpc2NvbnRpbnVpdHlUaW1lIGZvciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4 LiINCiAgICAgICAgOjo9IHsgZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50ZXJFbnRyeSAxNCB9DQoN Cg0KZG9jc0lmQ210c1VwQ2hubEN0clVzZWRDbnRuUmVxRGF0YU1zbG90cyBPQkpFQ1QtVFlQRQ0K ICAgICAgICBTWU5UQVggICAgICBDb3VudGVyMzINCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1v bmx5DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAg ICAgICAgICAgICJDdXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRpb24sIG9mIGNv bnRlbnRpb24NCiAgICAgICAgICAgICByZXF1ZXN0IGRhdGEgbWluaXNsb3RzIHV0aWxpemVkIG9u IHRoaXMgdXBzdHJlYW0gbG9naWNhbA0KICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgaW5jbHVk ZXMgYWxsIGNvbnRlbnRpb24gbWluaXNsb3RzIGZvciBJVUMyDQogICAgICAgICAgICAgYXBwbGlj YWJsZSB0byBidXJzdHMgdGhhdCB0aGUgQ01UUyBjb3JyZWN0bHkgcmVjZWl2ZWQuDQogICAgICAg ICAgICAgVGhpcyBpcyB0aGUgMzIgYml0IHZlcnNpb24gb2YgDQogICAgICAgICAgICAgZG9jc0lm Q210c1VwQ2hubEN0ckV4dFVzZWRDbnRuUmVxRGF0YU1zbG90cywgYW5kIGlzDQogICAgICAgICAg ICAgaW5jbHVkZWQgZm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2MSBtYW5hZ2Vycy4N CiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRl ciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5h Z2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVk IGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0 eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZD bXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDE1IH0NCg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3RyQ29s bENudG5SZXFEYXRhTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50 ZXIzMg0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAg Y3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQs IGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAgIHJl cXVlc3QgZGF0YSBtaW5pc2xvdHMgc3ViamVjdGVkIHRvIGNvbGxpc2lvbnMgb24gdGhpcw0KICAg ICAgICAgICAgIHVwc3RyZWFtIGxvZ2ljYWwgY2hhbm5lbC4gVGhpcyBpbmNsdWRlcyBhbGwgY29u dGVudGlvbg0KICAgICAgICAgICAgIG1pbmlzbG90cyBmb3IgSVVDMiBhcHBsaWNhYmxlIHRvIGJ1 cnN0cyB0aGF0IHRoZSBDTVRTDQogICAgICAgICAgICAgZGV0ZWN0ZWQsIGJ1dCBjb3VsZCBub3Qg Y29ycmVjdGx5IHJlY2VpdmUuIFRoaXMgaXMgdGhlIDMyDQogICAgICAgICAgICAgYml0IHZlcnNp b24gb2YNCiAgICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0Q29sbENudG5SZXFEYXRh TXNsb3RzLCBhbmQgaXMNCiAgICAgICAgICAgICBpbmNsdWRlZCBmb3IgYmFjayBjb21wYXRpYmls aXR5IHdpdGggU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBp biB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJl aW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAg ICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAg ICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRl eC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMTYgfQ0K DQoNCmRvY3NJZkNtdHNVcENobmxDdHJUb3RhbENudG5Jbml0TWFpbnRNc2xvdHMgT0JKRUNULVRZ UEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJl YWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9O DQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBv ZiBjb250ZW50aW9uDQogICAgICAgICAgICAgaW5pdGlhbCBtYWludGVuYW5jZSBtaW5pc2xvdHMg ZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbQ0KICAgICAgICAgICAgIGxvZ2ljYWwgY2hhbm5lbC4g VGhpcyBpbmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMzDQogICAgICAgICAgICAgYXNzaWdu ZWQgdG8gYSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBvbiB0aGUgbG9naWNhbA0KICAgICAg ICAgICAgIGNoYW5uZWwuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAg ICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRvdGFsQ250bkluaXRNYWludE1zbG90cywNCiAgICAg ICAgICAgICBhbmQgaXMgaW5jbHVkZWQgZm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2 MQ0KICAgICAgICAgICAgIG1hbmFnZXJzLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBp biB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJl aW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAg ICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAg ICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRl eC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMTcgfQ0K DQoNCmRvY3NJZkNtdHNVcENobmxDdHJVc2VkQ250bkluaXRNYWludE1zbG90cyBPQkpFQ1QtVFlQ RQ0KICAgICAgICBTWU5UQVggICAgICBDb3VudGVyMzINCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVh ZC1vbmx5DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04N CiAgICAgICAgICAgICJDdXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRpb24sIG9m IGNvbnRlbnRpb24NCiAgICAgICAgICAgICBpbml0aWFsIG1haW50ZW5hbmNlIG1pbmlzbG90cyB1 dGlsaXplZCBvbiB0aGlzIHVwc3RyZWFtDQogICAgICAgICAgICAgbG9naWNhbCBjaGFubmVsLiBU aGlzIGluY2x1ZGVzIGFsbCBjb250ZW50aW9uIG1pbmlzbG90cw0KICAgICAgICAgICAgIGZvciBJ VUMzIGFwcGxpY2FibGUgdG8gYnVyc3RzIHRoYXQgdGhlIENNVFMgY29ycmVjdGx5DQogICAgICAg ICAgICAgcmVjZWl2ZWQuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9uIG9mIA0KICAgICAgICAg ICAgIGRvY3NJZkNtdHNVcENobmxDdHJFeHRVc2VkQ250bkluaXRNYWludE1zbG90cywNCiAgICAg ICAgICAgICBhbmQgaXMgaW5jbHVkZWQgZm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2 MQ0KICAgICAgICAgICAgIG1hbmFnZXJzLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBp biB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJl aW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAg ICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAg ICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRl eC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMTggfQ0K DQoNCmRvY3NJZkNtdHNVcENobmxDdHJDb2xsQ250bkluaXRNYWludE1zbG90cyBPQkpFQ1QtVFlQ RQ0KICAgICAgICBTWU5UQVggICAgICBDb3VudGVyMzINCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVh ZC1vbmx5DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04N CiAgICAgICAgICAgICJDdXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRpb24sIG9m IGNvbnRlbnRpb24NCiAgICAgICAgICAgICBpbml0aWFsIG1haW50ZW5hbmNlIG1pbmlzbG90cyBz dWJqZWN0ZWQgdG8gY29sbGlzaW9ucyBvbg0KICAgICAgICAgICAgIHRoaXMgdXBzdHJlYW0gbG9n aWNhbCBjaGFubmVsLiBUaGlzIGluY2x1ZGVzIGFsbA0KICAgICAgICAgICAgIGNvbnRlbnRpb24g bWluaXNsb3RzIGZvciBJVUMzIGFwcGxpY2FibGUgdG8gYnVyc3RzIHRoYXQNCiAgICAgICAgICAg ICB0aGUgQ01UUyBkZXRlY3RlZCwgYnV0IGNvdWxkIG5vdCBjb3JyZWN0bHkgcmVjZWl2ZS4gICAg ICAgDQogICAgICAgICAgICAgVGhpcyBpcyB0aGUgMzIgYml0IHZlcnNpb24gb2YgDQogICAgICAg ICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckV4dENvbGxDbnRuSW5pdE1haW50TXNsb3RzLA0KICAg ICAgICAgICAgIGFuZCBpcyBpbmNsdWRlZCBmb3IgYmFjayBjb21wYXRpYmlsaXR5IHdpdGggU05N UHYxDQogICAgICAgICAgICAgbWFuYWdlcnMuDQogICAgICAgICAgICAgRGlzY29udGludWl0aWVz IGluIHRoZSB2YWx1ZSBvZiB0aGlzIGNvdW50ZXIgY2FuIG9jY3VyDQogICAgICAgICAgICAgYXQg cmVpbml0aWFsaXphdGlvbiBvZiB0aGUgbWFuYWdlZCBzeXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAg ICAgICAgICAgIHRpbWVzIGFzIGluZGljYXRlZCBieSB0aGUgdGhlIHZhbHVlIG9mIA0KICAgICAg ICAgICAgIGlmQ291bnRlckRpc2NvbnRpbnVpdHlUaW1lIGZvciB0aGUgYXNzb2NpYXRlZCBpZklu ZGV4LiINCiAgICAgICAgOjo9IHsgZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50ZXJFbnRyeSAxOSB9 DQoNCg0KZG9jc0lmQ210c1VwQ2hubEN0ckV4dENvbGxDbnRuTXNsb3RzIE9CSkVDVC1UWVBFDQog ICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXI2NA0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9u bHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAg ICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29s bGlzaW9uDQogICAgICAgICAgICAgY29udGVudGlvbiBtaW5pc2xvdHMgb24gdGhlIHVwc3RyZWFt IGxvZ2ljYWwgY2hhbm5lbC4NCiAgICAgICAgICAgICBGb3IgY29udGVudGlvbiByZWdpb25zLCB0 aGVzZSBhcmUgdGhlIG1pbmlzbG90cyBhcHBsaWNhYmxlDQogICAgICAgICAgICAgdG8gYnVyc3Rz IHRoYXQgdGhlIENNVFMgZGV0ZWN0ZWQsIGJ1dCBjb3VsZCBub3QgY29ycmVjdGx5DQogICAgICAg ICAgICAgcmVjZWl2ZS4gVGhpcyBpcyB0aGUgNjQgYml0IHZlcnNpb24gb2YNCiAgICAgICAgICAg ICBkb2NzSWZDbXRzVXBDaG5sQ3RyQ29sbENudG5Nc2xvdHMsIGFuZCB3aWxsIG5vdCBiZQ0KICAg ICAgICAgICAgIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAgICAgIERp c2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAg ICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQg YXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1 ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFz c29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3Vu dGVyRW50cnkgMjAgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbENudG5SZXFNc2xv dHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1B WC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRp YWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgcmVxdWVzdCBtaW5pc2xvdHMg ZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2FsDQogICAgICAgICAgICAgY2hhbm5lbC4g VGhpcyBjb3VudCBpbmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMxDQogICAgICAgICAgICAg YXNzaWduZWQgdG8gYSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBvbiB0aGUgbG9naWNhbA0K ICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgaXMgdGhlIDY0IGJpdCB2ZXJzaW9uIG9mDQogICAg ICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0clRvdGFsQ250blJlcU1zbG90cywgYW5kIHdpbGwg bm90IGJlDQogICAgICAgICAgICAgYWNjZXNzaWJsZSB0byBTTk1QdjEgbWFuYWdlcnMuDQogICAg ICAgICAgICAgRGlzY29udGludWl0aWVzIGluIHRoZSB2YWx1ZSBvZiB0aGlzIGNvdW50ZXIgY2Fu IG9jY3VyDQogICAgICAgICAgICAgYXQgcmVpbml0aWFsaXphdGlvbiBvZiB0aGUgbWFuYWdlZCBz eXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAgICAgICAgIHRpbWVzIGFzIGluZGljYXRlZCBieSB0 aGUgdGhlIHZhbHVlIG9mIA0KICAgICAgICAgICAgIGlmQ291bnRlckRpc2NvbnRpbnVpdHlUaW1l IGZvciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4LiINCiAgICAgICAgOjo9IHsgZG9jc0lmQ210c1Vw Q2hhbm5lbENvdW50ZXJFbnRyeSAyMSB9DQoNCg0KZG9jc0lmQ210c1VwQ2hubEN0ckV4dFVzZWRD bnRuUmVxTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXI2NA0K ICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVu dA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20g Q01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAgIHJlcXVlc3Qg bWluaXNsb3RzIHV0aWxpemVkIG9uIHRoaXMgdXBzdHJlYW0gbG9naWNhbA0KICAgICAgICAgICAg IGNoYW5uZWwuIFRoaXMgY291bnQgaW5jbHVkZXMgYWxsIGNvbnRlbnRpb24gbWluaXNsb3RzIGZv cg0KICAgICAgICAgICAgIElVQzEgYXBwbGljYWJsZSB0byBidXJzdHMgdGhhdCB0aGUgQ01UUyBj b3JyZWN0bHkNCiAgICAgICAgICAgICByZWNlaXZlZC4gVGhpcyBpcyB0aGUgNjQgYml0IHZlcnNp b24gb2YNCiAgICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyVXNlZENudG5SZXFNc2xvdHMs IGFuZCB3aWxsIG5vdCBiZQ0KICAgICAgICAgICAgIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFn ZXJzLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBj b3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhl IG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRp Y2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250 aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRv Y3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMjIgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxD dHJFeHRDb2xsQ250blJlcU1zbG90cyBPQkpFQ1QtVFlQRQ0KICAgICAgICBTWU5UQVggICAgICBD b3VudGVyNjQNCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgICAgIFNUQVRVUyAg ICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJDdXJyZW50IGNv dW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRpb24sIG9mIGNvbnRlbnRpb24NCiAgICAgICAgICAg ICByZXF1ZXN0IG1pbmlzbG90cyBzdWJqZWN0ZWQgdG8gY29sbGlzaW9ucyBvbiB0aGlzIHVwc3Ry ZWFtDQogICAgICAgICAgICAgbG9naWNhbCBjaGFubmVsLiBUaGlzIGluY2x1ZGVzIGFsbCBjb250 ZW50aW9uIG1pbmlzbG90cw0KICAgICAgICAgICAgIGZvciBJVUMxIGFwcGxpY2FibGUgdG8gYnVy c3RzIHRoYXQgdGhlIENNVFMgZGV0ZWN0ZWQsDQogICAgICAgICAgICAgYnV0IGNvdWxkIG5vdCBj b3JyZWN0bHkgcmVjZWl2ZS4gVGhpcyBpcyB0aGUgNjQgYml0DQogICAgICAgICAgICAgdmVyc2lv biBvZiBkb2NzSWZDbXRzVXBDaG5sQ3RyQ29sbENudG5SZXFNc2xvdHMsIGFuZCB3aWxsDQogICAg ICAgICAgICAgbm90IGJlIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAg ICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1 cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVt LCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRo ZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3Ig dGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5u ZWxDb3VudGVyRW50cnkgMjMgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbENudG5S ZXFEYXRhTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXI2NA0K ICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVu dA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20g Q01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAgIHJlcXVlc3Qg ZGF0YSBtaW5pc2xvdHMgZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2FsDQogICAgICAg ICAgICAgY2hhbm5lbC4gVGhpcyBjb3VudCBpbmNsdWRlcyBhbGwgbWluaXNsb3RzIGZvciBJVUMy DQogICAgICAgICAgICAgYXNzaWduZWQgdG8gYSBicm9hZGNhc3Qgb3IgbXVsdGljYXN0IFNJRCBv biB0aGUgbG9naWNhbA0KICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgaXMgdGhlIDY0IGJpdCB2 ZXJzaW9uIG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0clRvdGFsQ250blJlcURh dGFNc2xvdHMsIGFuZCB3aWxsIG5vdCBiZQ0KICAgICAgICAgICAgIGFjY2Vzc2libGUgdG8gU05N UHYxIG1hbmFnZXJzLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUg b2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRp b24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1l cyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50 ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAg IDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMjQgfQ0KDQoNCmRvY3NJZkNt dHNVcENobmxDdHJFeHRVc2VkQ250blJlcURhdGFNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAg U1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAg ICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAg ICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250ZW50aW9u DQogICAgICAgICAgICAgcmVxdWVzdCBkYXRhIG1pbmlzbG90cyB1dGlsaXplZCBvbiB0aGlzIHVw c3RyZWFtIGxvZ2ljYWwNCiAgICAgICAgICAgICBjaGFubmVsLiBUaGlzIGluY2x1ZGVzIGFsbCBj b250ZW50aW9uIG1pbmlzbG90cyBmb3IgSVVDMg0KICAgICAgICAgICAgIGFwcGxpY2FibGUgdG8g YnVyc3RzIHRoYXQgdGhlIENNVFMgY29ycmVjdGx5IHJlY2VpdmVkLiAgICANCiAgICAgICAgICAg ICBUaGlzIGlzIHRoZSA2NCBiaXQgdmVyc2lvbiBvZg0KICAgICAgICAgICAgIGRvY3NJZkNtdHNV cENobmxDdHJVc2VkQ250blJlcURhdGFNc2xvdHMsIGFuZCB3aWxsIG5vdCBiZQ0KICAgICAgICAg ICAgIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAgICAgIERpc2NvbnRp bnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAg ICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3Ro ZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiAN CiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0 ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50 cnkgMjUgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRDb2xsQ250blJlcURhdGFNc2xvdHMg T0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1BWC1B Q0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERF U0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxp emF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgcmVxdWVzdCBkYXRhIG1pbmlzbG90 cyBzdWJqZWN0ZWQgdG8gY29sbGlzaW9ucyBvbiB0aGlzDQogICAgICAgICAgICAgdXBzdHJlYW0g bG9naWNhbCBjaGFubmVsLiBUaGlzIGluY2x1ZGVzIGFsbCBjb250ZW50aW9uDQogICAgICAgICAg ICAgbWluaXNsb3RzIGZvciBJVUMyIGFwcGxpY2FibGUgdG8gYnVyc3RzIHRoYXQgdGhlIENNVFMN CiAgICAgICAgICAgICBkZXRlY3RlZCwgYnV0IGNvdWxkIG5vdCBjb3JyZWN0bHkgcmVjZWl2ZS4g VGhpcyBpcyB0aGUNCiAgICAgICAgICAgICA2NCBiaXQgdmVyc2lvbiBvZg0KICAgICAgICAgICAg IGRvY3NJZkNtdHNVcENobmxDdHJDb2xsQ250blJlcURhdGFNc2xvdHMsDQogICAgICAgICAgICAg YW5kIHdpbGwgbm90IGJlIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAg ICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1 cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVt LCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRo ZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3Ig dGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5u ZWxDb3VudGVyRW50cnkgMjYgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbENudG5J bml0TWFpbnRNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0 DQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJy ZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJv bSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBpbml0aWFsDQogICAgICAgICAgICAgbWFpbnRlbmFu Y2UgbWluaXNsb3RzIGRlZmluZWQgZm9yIHRoaXMgdXBzdHJlYW0gbG9naWNhbA0KICAgICAgICAg ICAgIGNoYW5uZWwuIFRoaXMgY291bnQgaW5jbHVkZXMgYWxsIG1pbmlzbG90cyBmb3IgSVVDMw0K ICAgICAgICAgICAgIGFzc2lnbmVkIHRvIGEgYnJvYWRjYXN0IG9yIG11bHRpY2FzdCBTSUQgb24g dGhlIGxvZ2ljYWwNCiAgICAgICAgICAgICBjaGFubmVsLiBUaGlzIGlzIHRoZSA2NCBiaXQgdmVy c2lvbiBvZiANCiAgICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3RyVG90YWxDbnRuSW5pdE1h aW50TXNsb3RzLA0KICAgICAgICAgICAgIGFuZCB3aWxsIG5vdCBiZSBhY2Nlc3NpYmxlIHRvIFNO TVB2MSBtYW5hZ2Vycy4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVl IG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0 aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGlt ZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3Vu dGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAg ICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDI3IH0NCg0KDQpkb2NzSWZD bXRzVXBDaG5sQ3RyRXh0VXNlZENudG5Jbml0TWFpbnRNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAg ICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0K ICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAg ICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBpbml0aWFs DQogICAgICAgICAgICAgbWFpbnRlbmFuY2UgbWluaXNsb3RzIHV0aWxpemVkIG9uIHRoaXMgdXBz dHJlYW0gbG9naWNhbA0KICAgICAgICAgICAgIGNoYW5uZWwuIFRoaXMgaW5jbHVkZXMgYWxsIGNv bnRlbnRpb24gbWluaXNsb3RzIGZvciBJVUMzDQogICAgICAgICAgICAgYXBwbGljYWJsZSB0byBi dXJzdHMgdGhhdCB0aGUgQ01UUyBjb3JyZWN0bHkgcmVjZWl2ZWQuICAgIA0KICAgICAgICAgICAg IFRoaXMgaXMgdGhlIDY0IGJpdCB2ZXJzaW9uIG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1Vw Q2hubEN0clVzZWRDbnRuSW5pdE1haW50TXNsb3RzLA0KICAgICAgICAgICAgIGFuZCB3aWxsIG5v dCBiZSBhY2Nlc3NpYmxlIHRvIFNOTVB2MSBtYW5hZ2Vycy4NCiAgICAgICAgICAgICBEaXNjb250 aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAg ICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90 aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2Yg DQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lh dGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVu dHJ5IDI4IH0NCg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0Q29sbENudG5Jbml0TWFpbnRNc2xv dHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1B WC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRp YWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgaW5pdGlhbCBtYWludGVuYW5j ZSBtaW5pc2xvdHMgc3ViamVjdGVkIHRvIGNvbGxpc2lvbnMgb24NCiAgICAgICAgICAgICB0aGlz IHVwc3RyZWFtIGxvZ2ljYWwgY2hhbm5lbC4gVGhpcyBpbmNsdWRlcyBhbGwNCiAgICAgICAgICAg ICBjb250ZW50aW9uIG1pbmlzbG90cyBmb3IgSVVDMyBhcHBsaWNhYmxlIHRvIGJ1cnN0cyB0aGF0 DQogICAgICAgICAgICAgdGhlIENNVFMgZGV0ZWN0ZWQsIGJ1dCBjb3VsZCBub3QgY29ycmVjdGx5 IHJlY2VpdmUuICAgICAgIA0KICAgICAgICAgICAgIFRoaXMgaXMgdGhlIDY0IGJpdCB2ZXJzaW9u IG9mDQogICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0ckNvbGxDbnRuSW5pdE1haW50TXNs b3RzLCBhbmQgd2lsbCBub3QNCiAgICAgICAgICAgICBiZSBhY2Nlc3NpYmxlIHRvIFNOTVB2MSBt YW5hZ2Vycy4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRo aXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9m IHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMg aW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlz Y29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0g eyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDI5IH0NClJlbW92ZSBUZXh0ICJTdXBw b3J0IGZvciB0aGlzIG9iamVjdCBpcyBtYW5kYXRvcnkuIg0KYikgUkVQTEFDRQ0KDQpkb2NzSWZD bXRzVXBDaG5sQ3RyVG90YWxNc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAg Q291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMg ICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBj b3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBhbGwgbWluaXNsb3RzDQogICAgICAg ICAgICAgZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2FsIGNoYW5uZWwuIFRoaXMgY291 bnQNCiAgICAgICAgICAgICBpbmNsdWRlcyBhbGwgSVVDcyBhbmQgU0lEcywgZXZlbiB0aG9zZSBh bGxvY2F0ZWQgdG8gdGhlDQogICAgICAgICAgICAgTlVMTCBTSUQgZm9yIGEgMi4wIGxvZ2ljYWwg Y2hhbm5lbCB3aGljaCBpcyBpbmFjdGl2ZS4gVGhpcw0KICAgICAgICAgICAgIGlzIHRoZSAzMiBi aXQgdmVyc2lvbiBvZiBkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0VG90YWxNc2xvdHMNCiAgICAgICAg ICAgICBhbmQgaXMgaW5jbHVkZWQgZm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2MQ0K ICAgICAgICAgICAgIG1hbmFnZXJzLiBTdXBwb3J0IGZvciB0aGlzIG9iamVjdCBpcyBtYW5kYXRv cnkuDQogICAgICAgICAgICAgRGlzY29udGludWl0aWVzIGluIHRoZSB2YWx1ZSBvZiB0aGlzIGNv dW50ZXIgY2FuIG9jY3VyDQogICAgICAgICAgICAgYXQgcmVpbml0aWFsaXphdGlvbiBvZiB0aGUg bWFuYWdlZCBzeXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAgICAgICAgIHRpbWVzIGFzIGluZGlj YXRlZCBieSB0aGUgdGhlIHZhbHVlIG9mIA0KICAgICAgICAgICAgIGlmQ291bnRlckRpc2NvbnRp bnVpdHlUaW1lIGZvciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4LiINCiAgICAgICAgOjo9IHsgZG9j c0lmQ210c1VwQ2hhbm5lbENvdW50ZXJFbnRyeSAyIH0NCg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3Ry VWNhc3RHcmFudGVkTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50 ZXIzMg0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAg Y3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQs IGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgdW5pY2FzdA0KICAgICAgICAgICAgIGdyYW50 ZWQgbWluaXNsb3RzIG9uIHRoZSB1cHN0cmVhbSBsb2dpY2FsIGNoYW5uZWwsDQogICAgICAgICAg ICAgcmVnYXJkbGVzcyBvZiBidXJzdCB0eXBlLiBVbmljYXN0IGdyYW50ZWQgbWluaXNsb3RzIGFy ZQ0KICAgICAgICAgICAgIHRob3NlIGluIHdoaWNoIHRoZSBDTVRTIGFzc2lnbmVkIGJhbmR3aWR0 aCB0byBhbnkgdW5pY2FzdA0KICAgICAgICAgICAgIFNJRCBvbiB0aGUgbG9naWNhbCBjaGFubmVs LiBIb3dldmVyIHRoaXMgb2JqZWN0IGRvZXMgbm90DQogICAgICAgICAgICAgaW5jbHVkZSBtaW5p c2xvdHMgZm9yIHJlc2VydmVkIElVQ3MsIG9yIGdyYW50cyB0byBTSURzIA0KICAgICAgICAgICAg IGRlc2lnbmF0ZWQgYXMgbWVhbmluZyAnbm8gQ00nLiBUaGlzIGlzIHRoZSAzMiBiaXQgdmVyc2lv biANCiAgICAgICAgICAgICBvZiBkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0VWNhc3RHcmFudGVkTXNs b3RzLCBhbmQgaXMgDQogICAgICAgICAgICAgaW5jbHVkZWQgZm9yIGJhY2sgY29tcGF0aWJpbGl0 eSB3aXRoIFNOTVB2MSBtYW5hZ2Vycy4gDQogICAgICAgICAgICAgU3VwcG9ydCBmb3IgdGhpcyBv YmplY3QgaXMgbWFuZGF0b3J5Lg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUg dmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlh bGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAg ICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBp ZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQog ICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgMyB9DQoNCg0KZG9j c0lmQ210c1VwQ2hubEN0clRvdGFsQ250bk1zbG90cyBPQkpFQ1QtVFlQRQ0KICAgICAgICBTWU5U QVggICAgICBDb3VudGVyMzINCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgICAg IFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJD dXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRpb24sIG9mIGNvbnRlbnRpb24NCiAg ICAgICAgICAgICBtaW5pc2xvdHMgZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dpY2FsIGNo YW5uZWwuIFRoaXMNCiAgICAgICAgICAgICBjb3VudCBpbmNsdWRlcyBhbGwgbWluaXNsb3RzIGFz c2lnbmVkIHRvIGEgYnJvYWRjYXN0IG9yDQogICAgICAgICAgICAgbXVsdGljYXN0IFNJRCBvbiB0 aGUgbG9naWNhbCBjaGFubmVsLiBUaGlzIGlzIHRoZSAzMiBiaXQNCiAgICAgICAgICAgICB2ZXJz aW9uIG9mIGRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbENudG5Nc2xvdHMsIGFuZCBpcw0KICAg ICAgICAgICAgIGluY2x1ZGVkIGZvciBiYWNrIGNvbXBhdGliaWxpdHkgd2l0aCBTTk1QdjEgbWFu YWdlcnMuDQogICAgICAgICAgICAgU3VwcG9ydCBmb3IgdGhpcyBvYmplY3QgaXMgbWFuZGF0b3J5 Lg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3Vu dGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1h bmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0 ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51 aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJ ZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgNCB9DQoNCg0KZG9jc0lmQ210c1VwQ2hubEN0clVz ZWRDbnRuTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0K ICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVu dA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20g Q01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAgIG1pbmlzbG90 cyB1dGlsaXplZCBvbiB0aGUgdXBzdHJlYW0gbG9naWNhbCBjaGFubmVsLiBGb3INCiAgICAgICAg ICAgICBjb250ZW50aW9uIHJlZ2lvbnMsIHV0aWxpemVkIG1pbmlzbG90cyBhcmUgdGhvc2UgaW4g d2hpY2gNCiAgICAgICAgICAgICB0aGUgQ01UUyBjb3JyZWN0bHkgcmVjZWl2ZWQgYW4gdXBzdHJl YW0gYnVyc3QgZnJvbSBhbnkgQ00NCiAgICAgICAgICAgICBvbiB0aGUgdXBzdHJlYW0gbG9naWNh bCBjaGFubmVsLiBUaGlzIGlzIHRoZSAzMiBiaXQNCiAgICAgICAgICAgICB2ZXJzaW9uIG9mIGRv Y3NJZkNtdHNVcENobmxDdHJFeHRVc2VkQ250bk1zbG90cywgYW5kIGlzDQogICAgICAgICAgICAg aW5jbHVkZWQgZm9yIGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2MSBtYW5hZ2Vycy4NCiAg ICAgICAgICAgICBTdXBwb3J0IGZvciB0aGlzIG9iamVjdCBpcyBtYW5kYXRvcnkuDQogICAgICAg ICAgICAgRGlzY29udGludWl0aWVzIGluIHRoZSB2YWx1ZSBvZiB0aGlzIGNvdW50ZXIgY2FuIG9j Y3VyDQogICAgICAgICAgICAgYXQgcmVpbml0aWFsaXphdGlvbiBvZiB0aGUgbWFuYWdlZCBzeXN0 ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAgICAgICAgIHRpbWVzIGFzIGluZGljYXRlZCBieSB0aGUg dGhlIHZhbHVlIG9mIA0KICAgICAgICAgICAgIGlmQ291bnRlckRpc2NvbnRpbnVpdHlUaW1lIGZv ciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4LiINCiAgICAgICAgOjo9IHsgZG9jc0lmQ210c1VwQ2hh bm5lbENvdW50ZXJFbnRyeSA1IH0NCg0KDQpkb2NzSWZDbXRzVXBDaG5sQ3RyRXh0VG90YWxNc2xv dHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1B WC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRp YWxpemF0aW9uLCBvZiBhbGwgbWluaXNsb3RzDQogICAgICAgICAgICAgZGVmaW5lZCBmb3IgdGhp cyB1cHN0cmVhbSBsb2dpY2FsIGNoYW5uZWwuIFRoaXMgY291bnQNCiAgICAgICAgICAgICBpbmNs dWRlcyBhbGwgSVVDcyBhbmQgU0lEcywgZXZlbiB0aG9zZSBhbGxvY2F0ZWQgdG8gdGhlDQogICAg ICAgICAgICAgTlVMTCBTSUQgZm9yIGEgMi4wIGxvZ2ljYWwgY2hhbm5lbCB3aGljaCBpcyBpbmFj dGl2ZS4gVGhpcw0KICAgICAgICAgICAgIGlzIHRoZSA2NCBiaXQgdmVyc2lvbiBvZiBkb2NzSWZD bXRzVXBDaG5sQ3RyVG90YWxNc2xvdHMsDQogICAgICAgICAgICAgYW5kIHdpbGwgbm90IGJlIGFj Y2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAgICAgIFN1cHBvcnQgZm9yIHRo aXMgb2JqZWN0IGlzIG1hbmRhdG9yeS4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4g dGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWlu aXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAg ICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAg ICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXgu Ig0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDYgfQ0KDQoN CmRvY3NJZkNtdHNVcENobmxDdHJFeHRVY2FzdEdyYW50ZWRNc2xvdHMgT0JKRUNULVRZUEUNCiAg ICAgICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25s eQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAg ICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiB1bmlj YXN0DQogICAgICAgICAgICAgZ3JhbnRlZCBtaW5pc2xvdHMgb24gdGhlIHVwc3RyZWFtIGxvZ2lj YWwgY2hhbm5lbCwNCiAgICAgICAgICAgICByZWdhcmRsZXNzIG9mIGJ1cnN0IHR5cGUuIFVuaWNh c3QgZ3JhbnRlZCBtaW5pc2xvdHMgYXJlDQogICAgICAgICAgICAgdGhvc2UgaW4gd2hpY2ggdGhl IENNVFMgYXNzaWduZWQgYmFuZHdpZHRoIHRvIGFueSB1bmljYXN0DQogICAgICAgICAgICAgU0lE IG9uIHRoZSBsb2dpY2FsIGNoYW5uZWwuIEhvd2V2ZXIgdGhpcyBvYmplY3QgZG9lcyBub3QNCiAg ICAgICAgICAgICBpbmNsdWRlIG1pbmlzbG90cyBmb3IgcmVzZXJ2ZWQgSVVDcywgb3IgZ3JhbnRz IHRvIFNJRHMgDQogICAgICAgICAgICAgZGVzaWduYXRlZCBhcyBtZWFuaW5nICdubyBDTScuIFRo aXMgaXMgdGhlIDY0IGJpdCB2ZXJzaW9uDQogICAgICAgICAgICAgb2YgZG9jc0lmQ210c1VwQ2hu bEN0clVjYXN0R3JhbnRlZE1zbG90cywgYW5kIHdpbGwgbm90IGJlDQogICAgICAgICAgICAgYWNj ZXNzaWJsZSB0byBTTk1QdjEgbWFuYWdlcnMuDQogICAgICAgICAgICAgU3VwcG9ydCBmb3IgdGhp cyBvYmplY3QgaXMgbWFuZGF0b3J5Lg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0 aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5p dGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAg ICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAg ICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4i DQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgNyB9DQoNCg0K ZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRvdGFsQ250bk1zbG90cyBPQkpFQ1QtVFlQRQ0KICAgICAg ICBTWU5UQVggICAgICBDb3VudGVyNjQNCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQog ICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAg ICAgICJDdXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRpb24sIG9mIGNvbnRlbnRp b24NCiAgICAgICAgICAgICBtaW5pc2xvdHMgZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBsb2dp Y2FsIGNoYW5uZWwuIFRoaXMNCiAgICAgICAgICAgICBjb3VudCBpbmNsdWRlcyBhbGwgbWluaXNs b3RzIGFzc2lnbmVkIHRvIGEgYnJvYWRjYXN0IG9yDQogICAgICAgICAgICAgbXVsdGljYXN0IFNJ RCBvbiB0aGUgbG9naWNhbCBjaGFubmVsLiBUaGlzIGlzIHRoZSA2NCBiaXQNCiAgICAgICAgICAg ICB2ZXJzaW9uIG9mIGRvY3NJZkNtdHNVcENobmxDdHJUb3RhbENudG5Nc2xvdHMsIGFuZCB3aWxs DQogICAgICAgICAgICAgbm90IGJlIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0KICAg ICAgICAgICAgIFN1cHBvcnQgZm9yIHRoaXMgb2JqZWN0IGlzIG1hbmRhdG9yeS4NCiAgICAgICAg ICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2Nj dXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3Rl bSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0 aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9y IHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFu bmVsQ291bnRlckVudHJ5IDggfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRVc2VkQ250bk1z bG90cyBPQkpFQ1QtVFlQRQ0KICAgICAgICBTWU5UQVggICAgICBDb3VudGVyNjQNCiAgICAgICAg TUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAg ICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJDdXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5p dGlhbGl6YXRpb24sIG9mIGNvbnRlbnRpb24NCiAgICAgICAgICAgICBtaW5pc2xvdHMgdXRpbGl6 ZWQgb24gdGhlIHVwc3RyZWFtIGxvZ2ljYWwgY2hhbm5lbC4gRm9yDQogICAgICAgICAgICAgY29u dGVudGlvbiByZWdpb25zLCB1dGlsaXplZCBtaW5pc2xvdHMgYXJlIHRob3NlIGluIHdoaWNoDQog ICAgICAgICAgICAgdGhlIENNVFMgY29ycmVjdGx5IHJlY2VpdmVkIGFuIHVwc3RyZWFtIGJ1cnN0 IGZyb20gYW55IENNDQogICAgICAgICAgICAgb24gdGhlIHVwc3RyZWFtIGxvZ2ljYWwgY2hhbm5l bC4gVGhpcyBpcyB0aGUgNjQgYml0DQogICAgICAgICAgICAgdmVyc2lvbiBvZiBkb2NzSWZDbXRz VXBDaG5sQ3RyVXNlZENudG5Nc2xvdHMsIGFuZCB3aWxsIG5vdA0KICAgICAgICAgICAgIGJlIGFj Y2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAgICAgIFN1cHBvcnQgZm9yIHRo aXMgb2JqZWN0IGlzIG1hbmRhdG9yeS4NCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4g dGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWlu aXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAg ICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAg ICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXgu Ig0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDkgfQ0KDQoN CldJVEgNCg0KZG9jc0lmQ210c1VwQ2hubEN0clRvdGFsTXNsb3RzIE9CSkVDVC1UWVBFDQogICAg ICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkN CiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAg ICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgYWxsIG1p bmlzbG90cw0KICAgICAgICAgICAgIGRlZmluZWQgZm9yIHRoaXMgdXBzdHJlYW0gbG9naWNhbCBj aGFubmVsLiBUaGlzIGNvdW50DQogICAgICAgICAgICAgaW5jbHVkZXMgYWxsIElVQ3MgYW5kIFNJ RHMsIGV2ZW4gdGhvc2UgYWxsb2NhdGVkIHRvIHRoZQ0KICAgICAgICAgICAgIE5VTEwgU0lEIGZv ciBhIDIuMCBsb2dpY2FsIGNoYW5uZWwgd2hpY2ggaXMgaW5hY3RpdmUuIFRoaXMNCiAgICAgICAg ICAgICBpcyB0aGUgMzIgYml0IHZlcnNpb24gb2YgZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRvdGFs TXNsb3RzDQogICAgICAgICAgICAgYW5kIGlzIGluY2x1ZGVkIGZvciBiYWNrIGNvbXBhdGliaWxp dHkgd2l0aCBTTk1QdjENCiAgICAgICAgICAgICBtYW5hZ2Vycy4NCiAgICAgICAgICAgICBEaXNj b250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAgICAg ICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5kIGF0 IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFsdWUg b2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBhc3Nv Y2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291bnRl ckVudHJ5IDIgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJVY2FzdEdyYW50ZWRNc2xvdHMgT0JK RUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgICAgIE1BWC1BQ0NF U1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NS SVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJvbSBDTVRTIGluaXRpYWxpemF0 aW9uLCBvZiB1bmljYXN0DQogICAgICAgICAgICAgZ3JhbnRlZCBtaW5pc2xvdHMgb24gdGhlIHVw c3RyZWFtIGxvZ2ljYWwgY2hhbm5lbCwNCiAgICAgICAgICAgICByZWdhcmRsZXNzIG9mIGJ1cnN0 IHR5cGUuIFVuaWNhc3QgZ3JhbnRlZCBtaW5pc2xvdHMgYXJlDQogICAgICAgICAgICAgdGhvc2Ug aW4gd2hpY2ggdGhlIENNVFMgYXNzaWduZWQgYmFuZHdpZHRoIHRvIGFueSB1bmljYXN0DQogICAg ICAgICAgICAgU0lEIG9uIHRoZSBsb2dpY2FsIGNoYW5uZWwuIEhvd2V2ZXIgdGhpcyBvYmplY3Qg ZG9lcyBub3QNCiAgICAgICAgICAgICBpbmNsdWRlIG1pbmlzbG90cyBmb3IgcmVzZXJ2ZWQgSVVD cywgb3IgZ3JhbnRzIHRvIFNJRHMgDQogICAgICAgICAgICAgZGVzaWduYXRlZCBhcyBtZWFuaW5n ICdubyBDTScuIFRoaXMgaXMgdGhlIDMyIGJpdCB2ZXJzaW9uIA0KICAgICAgICAgICAgIG9mIGRv Y3NJZkNtdHNVcENobmxDdHJFeHRVY2FzdEdyYW50ZWRNc2xvdHMsIGFuZCBpcyANCiAgICAgICAg ICAgICBpbmNsdWRlZCBmb3IgYmFjayBjb21wYXRpYmlsaXR5IHdpdGggU05NUHYxIG1hbmFnZXJz LiANCiAgICAgICAgICAgICBEaXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291 bnRlciBjYW4gb2NjdXINCiAgICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBt YW5hZ2VkIHN5c3RlbSwgYW5kIGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNh dGVkIGJ5IHRoZSB0aGUgdmFsdWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGlu dWl0eVRpbWUgZm9yIHRoZSBhc3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2Nz SWZDbXRzVXBDaGFubmVsQ291bnRlckVudHJ5IDMgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJU b3RhbENudG5Nc2xvdHMgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMy DQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJy ZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQ3VycmVudCBjb3VudCwgZnJv bSBDTVRTIGluaXRpYWxpemF0aW9uLCBvZiBjb250ZW50aW9uDQogICAgICAgICAgICAgbWluaXNs b3RzIGRlZmluZWQgZm9yIHRoaXMgdXBzdHJlYW0gbG9naWNhbCBjaGFubmVsLiBUaGlzDQogICAg ICAgICAgICAgY291bnQgaW5jbHVkZXMgYWxsIG1pbmlzbG90cyBhc3NpZ25lZCB0byBhIGJyb2Fk Y2FzdCBvcg0KICAgICAgICAgICAgIG11bHRpY2FzdCBTSUQgb24gdGhlIGxvZ2ljYWwgY2hhbm5l bC4gVGhpcyBpcyB0aGUgMzIgYml0DQogICAgICAgICAgICAgdmVyc2lvbiBvZiBkb2NzSWZDbXRz VXBDaG5sQ3RyRXh0VG90YWxDbnRuTXNsb3RzLCBhbmQgaXMNCiAgICAgICAgICAgICBpbmNsdWRl ZCBmb3IgYmFjayBjb21wYXRpYmlsaXR5IHdpdGggU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAg ICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1 cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVt LCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRo ZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3Ig dGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5u ZWxDb3VudGVyRW50cnkgNCB9DQoNCg0KZG9jc0lmQ210c1VwQ2hubEN0clVzZWRDbnRuTXNsb3Rz IE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgICAgICBNQVgt QUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBE RVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20gQ01UUyBpbml0aWFs aXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAgIG1pbmlzbG90cyB1dGlsaXplZCBv biB0aGUgdXBzdHJlYW0gbG9naWNhbCBjaGFubmVsLiBGb3INCiAgICAgICAgICAgICBjb250ZW50 aW9uIHJlZ2lvbnMsIHV0aWxpemVkIG1pbmlzbG90cyBhcmUgdGhvc2UgaW4gd2hpY2gNCiAgICAg ICAgICAgICB0aGUgQ01UUyBjb3JyZWN0bHkgcmVjZWl2ZWQgYW4gdXBzdHJlYW0gYnVyc3QgZnJv bSBhbnkgQ00NCiAgICAgICAgICAgICBvbiB0aGUgdXBzdHJlYW0gbG9naWNhbCBjaGFubmVsLiBU aGlzIGlzIHRoZSAzMiBiaXQNCiAgICAgICAgICAgICB2ZXJzaW9uIG9mIGRvY3NJZkNtdHNVcENo bmxDdHJFeHRVc2VkQ250bk1zbG90cywgYW5kIGlzDQogICAgICAgICAgICAgaW5jbHVkZWQgZm9y IGJhY2sgY29tcGF0aWJpbGl0eSB3aXRoIFNOTVB2MSBtYW5hZ2Vycy4NCiAgICAgICAgICAgICBE aXNjb250aW51aXRpZXMgaW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4gb2NjdXINCiAg ICAgICAgICAgICBhdCByZWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VkIHN5c3RlbSwgYW5k IGF0IG90aGVyDQogICAgICAgICAgICAgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB0aGUgdmFs dWUgb2YgDQogICAgICAgICAgICAgaWZDb3VudGVyRGlzY29udGludWl0eVRpbWUgZm9yIHRoZSBh c3NvY2lhdGVkIGlmSW5kZXguIg0KICAgICAgICA6Oj0geyBkb2NzSWZDbXRzVXBDaGFubmVsQ291 bnRlckVudHJ5IDUgfQ0KDQoNCmRvY3NJZkNtdHNVcENobmxDdHJFeHRUb3RhbE1zbG90cyBPQkpF Q1QtVFlQRQ0KICAgICAgICBTWU5UQVggICAgICBDb3VudGVyNjQNCiAgICAgICAgTUFYLUFDQ0VT UyAgcmVhZC1vbmx5DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJ UFRJT04NCiAgICAgICAgICAgICJDdXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRp b24sIG9mIGFsbCBtaW5pc2xvdHMNCiAgICAgICAgICAgICBkZWZpbmVkIGZvciB0aGlzIHVwc3Ry ZWFtIGxvZ2ljYWwgY2hhbm5lbC4gVGhpcyBjb3VudA0KICAgICAgICAgICAgIGluY2x1ZGVzIGFs bCBJVUNzIGFuZCBTSURzLCBldmVuIHRob3NlIGFsbG9jYXRlZCB0byB0aGUNCiAgICAgICAgICAg ICBOVUxMIFNJRCBmb3IgYSAyLjAgbG9naWNhbCBjaGFubmVsIHdoaWNoIGlzIGluYWN0aXZlLiBU aGlzDQogICAgICAgICAgICAgaXMgdGhlIDY0IGJpdCB2ZXJzaW9uIG9mIGRvY3NJZkNtdHNVcENo bmxDdHJUb3RhbE1zbG90cywNCiAgICAgICAgICAgICBhbmQgd2lsbCBub3QgYmUgYWNjZXNzaWJs ZSB0byBTTk1QdjEgbWFuYWdlcnMuDQogICAgICAgICAgICAgRGlzY29udGludWl0aWVzIGluIHRo ZSB2YWx1ZSBvZiB0aGlzIGNvdW50ZXIgY2FuIG9jY3VyDQogICAgICAgICAgICAgYXQgcmVpbml0 aWFsaXphdGlvbiBvZiB0aGUgbWFuYWdlZCBzeXN0ZW0sIGFuZCBhdCBvdGhlcg0KICAgICAgICAg ICAgIHRpbWVzIGFzIGluZGljYXRlZCBieSB0aGUgdGhlIHZhbHVlIG9mIA0KICAgICAgICAgICAg IGlmQ291bnRlckRpc2NvbnRpbnVpdHlUaW1lIGZvciB0aGUgYXNzb2NpYXRlZCBpZkluZGV4LiIN CiAgICAgICAgOjo9IHsgZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50ZXJFbnRyeSA2IH0NCg0KDQpk b2NzSWZDbXRzVXBDaG5sQ3RyRXh0VWNhc3RHcmFudGVkTXNsb3RzIE9CSkVDVC1UWVBFDQogICAg ICAgIFNZTlRBWCAgICAgIENvdW50ZXI2NA0KICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkN CiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAg ICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20gQ01UUyBpbml0aWFsaXphdGlvbiwgb2YgdW5pY2Fz dA0KICAgICAgICAgICAgIGdyYW50ZWQgbWluaXNsb3RzIG9uIHRoZSB1cHN0cmVhbSBsb2dpY2Fs IGNoYW5uZWwsDQogICAgICAgICAgICAgcmVnYXJkbGVzcyBvZiBidXJzdCB0eXBlLiBVbmljYXN0 IGdyYW50ZWQgbWluaXNsb3RzIGFyZQ0KICAgICAgICAgICAgIHRob3NlIGluIHdoaWNoIHRoZSBD TVRTIGFzc2lnbmVkIGJhbmR3aWR0aCB0byBhbnkgdW5pY2FzdA0KICAgICAgICAgICAgIFNJRCBv biB0aGUgbG9naWNhbCBjaGFubmVsLiBIb3dldmVyIHRoaXMgb2JqZWN0IGRvZXMgbm90DQogICAg ICAgICAgICAgaW5jbHVkZSBtaW5pc2xvdHMgZm9yIHJlc2VydmVkIElVQ3MsIG9yIGdyYW50cyB0 byBTSURzIA0KICAgICAgICAgICAgIGRlc2lnbmF0ZWQgYXMgbWVhbmluZyAnbm8gQ00nLiBUaGlz IGlzIHRoZSA2NCBiaXQgdmVyc2lvbg0KICAgICAgICAgICAgIG9mIGRvY3NJZkNtdHNVcENobmxD dHJVY2FzdEdyYW50ZWRNc2xvdHMsIGFuZCB3aWxsIG5vdCBiZQ0KICAgICAgICAgICAgIGFjY2Vz c2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0KICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBp biB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJl aW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAg ICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAg ICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRl eC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyRW50cnkgNyB9DQoN Cg0KZG9jc0lmQ210c1VwQ2hubEN0ckV4dFRvdGFsQ250bk1zbG90cyBPQkpFQ1QtVFlQRQ0KICAg ICAgICBTWU5UQVggICAgICBDb3VudGVyNjQNCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5 DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAg ICAgICAgICJDdXJyZW50IGNvdW50LCBmcm9tIENNVFMgaW5pdGlhbGl6YXRpb24sIG9mIGNvbnRl bnRpb24NCiAgICAgICAgICAgICBtaW5pc2xvdHMgZGVmaW5lZCBmb3IgdGhpcyB1cHN0cmVhbSBs b2dpY2FsIGNoYW5uZWwuIFRoaXMNCiAgICAgICAgICAgICBjb3VudCBpbmNsdWRlcyBhbGwgbWlu aXNsb3RzIGFzc2lnbmVkIHRvIGEgYnJvYWRjYXN0IG9yDQogICAgICAgICAgICAgbXVsdGljYXN0 IFNJRCBvbiB0aGUgbG9naWNhbCBjaGFubmVsLiBUaGlzIGlzIHRoZSA2NCBiaXQNCiAgICAgICAg ICAgICB2ZXJzaW9uIG9mIGRvY3NJZkNtdHNVcENobmxDdHJUb3RhbENudG5Nc2xvdHMsIGFuZCB3 aWxsDQogICAgICAgICAgICAgbm90IGJlIGFjY2Vzc2libGUgdG8gU05NUHYxIG1hbmFnZXJzLg0K ICAgICAgICAgICAgIERpc2NvbnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVy IGNhbiBvY2N1cg0KICAgICAgICAgICAgIGF0IHJlaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFn ZWQgc3lzdGVtLCBhbmQgYXQgb3RoZXINCiAgICAgICAgICAgICB0aW1lcyBhcyBpbmRpY2F0ZWQg YnkgdGhlIHRoZSB2YWx1ZSBvZiANCiAgICAgICAgICAgICBpZkNvdW50ZXJEaXNjb250aW51aXR5 VGltZSBmb3IgdGhlIGFzc29jaWF0ZWQgaWZJbmRleC4iDQogICAgICAgIDo6PSB7IGRvY3NJZkNt dHNVcENoYW5uZWxDb3VudGVyRW50cnkgOCB9DQoNCg0KZG9jc0lmQ210c1VwQ2hubEN0ckV4dFVz ZWRDbnRuTXNsb3RzIE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXI2NA0K ICAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVu dA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIkN1cnJlbnQgY291bnQsIGZyb20g Q01UUyBpbml0aWFsaXphdGlvbiwgb2YgY29udGVudGlvbg0KICAgICAgICAgICAgIG1pbmlzbG90 cyB1dGlsaXplZCBvbiB0aGUgdXBzdHJlYW0gbG9naWNhbCBjaGFubmVsLiBGb3INCiAgICAgICAg ICAgICBjb250ZW50aW9uIHJlZ2lvbnMsIHV0aWxpemVkIG1pbmlzbG90cyBhcmUgdGhvc2UgaW4g d2hpY2gNCiAgICAgICAgICAgICB0aGUgQ01UUyBjb3JyZWN0bHkgcmVjZWl2ZWQgYW4gdXBzdHJl YW0gYnVyc3QgZnJvbSBhbnkgQ00NCiAgICAgICAgICAgICBvbiB0aGUgdXBzdHJlYW0gbG9naWNh bCBjaGFubmVsLiBUaGlzIGlzIHRoZSA2NCBiaXQNCiAgICAgICAgICAgICB2ZXJzaW9uIG9mIGRv Y3NJZkNtdHNVcENobmxDdHJVc2VkQ250bk1zbG90cywgYW5kIHdpbGwgbm90DQogICAgICAgICAg ICAgYmUgYWNjZXNzaWJsZSB0byBTTk1QdjEgbWFuYWdlcnMuDQogICAgICAgICAgICAgRGlzY29u dGludWl0aWVzIGluIHRoZSB2YWx1ZSBvZiB0aGlzIGNvdW50ZXIgY2FuIG9jY3VyDQogICAgICAg ICAgICAgYXQgcmVpbml0aWFsaXphdGlvbiBvZiB0aGUgbWFuYWdlZCBzeXN0ZW0sIGFuZCBhdCBv dGhlcg0KICAgICAgICAgICAgIHRpbWVzIGFzIGluZGljYXRlZCBieSB0aGUgdGhlIHZhbHVlIG9m IA0KICAgICAgICAgICAgIGlmQ291bnRlckRpc2NvbnRpbnVpdHlUaW1lIGZvciB0aGUgYXNzb2Np YXRlZCBpZkluZGV4LiINCiAgICAgICAgOjo9IHsgZG9jc0lmQ210c1VwQ2hhbm5lbENvdW50ZXJF bnRyeSA5IH0NCg0KDQoNCjMpIERlY2lzaW9uIG9mIEFVR01FTlRJTkcgb3IgYWRkZWQgY29sdW1u YXIgT3B0aW9uYWwgb2JqZWN0cyBpbiANCmRvY3NJZkNtdHNVcENoYW5uZWxDb3VudGVyVGFibGUg DQoNClRoaXMgdG9waWMgd2FzIGRpc2N1c2VkIGluIGdvb2QgZGVlcCBpbiB0aGUgaXBjZG4gbGlz dCBhbmQgdmVyeSBnb29kIA0KY29udHJpYnV0aW9ucyB3ZXJlIG1hZGUsICggY29tcGxldGUgZW1h aWwgbG9nIGlzIGluIElQQ0ROIHdlYiBwYWdlKSANClRvIG1lbnRpb24sIG9uZSBvZiB0aGUgbW9z dCByZWxldmFudCBjb21tZW50cywgd2FzIGZyb20gUmljaCBXb3VuZHkgDQpNYXkgMzAgMjAwMywg d2l0aCBzdWJqZWN0IA0KIk9wdGlvbmFsIiBpbiB0aGUgZGVzY3JpcHRpb24gb2Ygb2JqZWN0cyBm cm9tIHRoZSByZmltaWJ2Mg0KDQpSaWNoIHF1b3RlZCB0aGUgc2VjdGlvbiBvZiBSRkMgMjg2MyAz LjEuMTggIkFsbCB2YWx1ZXMgTXVzdCBiZSBLbm93biINCldoZXJlIGFuIGFnZW50IHRoYXQgZG9l cyBub3Qgc3VwcG9ydCBhIGNvdW50ZXIgcGVybWFuZW50bHkgbXVzdCBub3QgDQppbnN0YW50aWF0 ZSB0aGUgb2JqZWN0IChlLmcuIGZvciBhIHBhcnRpY3VsYXIgaWZJbmRleCBpZlRhYmxlIGNvdW50 ZXIgb3IgDQp0YWJsZSBleHRlbnNpb24pIA0Kb3IgDQp0ZW1wb3Jhcmx5LCB0aGUgQWdlbnQgaGF2 ZW4ndCBjb21wbGV0ZSB0aGUgaW5pdGlhbGl6YXRpb24gb2YgdGhlIGVudGl0eSBvcg0KIHRoZSBj b3VudGVyIGZ1bmN0aW9uLg0KDQpJbiBzdW1tYXJ5LCB0aGUgYWdlbnQgd2lsbCByZXNwb25kIHdp dGggZXJyb3IgJ25vU3VjaE9iamVjdCcgaWYgb2JqZWN0IGlzIA0KY29tcGxldGVseSB1bmtub3du IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiAoZS5nIG9wdGlvbmFsIGltcGxlbWVudGF0aW9uKSBvciAN Cidub1N1Y2hJbnN0YW5jZScgaWYgdGhlIHNwZWNpZmllZCByb3cgb2YgdGhlIG9iamVjdCBpcyBu b3QgdmFsaWQuDQoNCkFub3RoZXIgcmVmZXJlbmNlIHBvaW50IGlzIHRoZSBPU1NJIHNwZWMuDQoN ClNpbmNlIGVhcmx5IE9TU0kgbWliIG9iamVjdCByZXF1aXJlbWVudHMsIHRoZSBPU1MgcmVxdWly ZXMgZm9yIG9wdGlvbmFsIA0Kb2JqZWN0cyB0aGUgZm9sbG93aW5nICggaW4gdG90YWwgc3luY2gg d2l0aCAgUmljaCdzIHF1b3RlZCB0ZXh0KToNCg0KT3B0aW9uYWwgbWliIG9iamVjdHMgaW4gQW5u ZXggQSBEZXRhaWxlZCBNSUIgUmVxdWlyZW1lbnRzIChub3JtYXRpdmUpIA0KDQoiTyBPcHRpb25h bC4gQSB2ZW5kb3IgY2FuIGNob29zZSB0byBpbXBsZW1lbnQgb3Igbm90IGltcGxlbWVudCB0aGUg b2JqZWN0LiANCklmIGEgdmVuZG9yIGNob29zZXMgdG8gaW1wbGVtZW50IHRoZSBvYmplY3QsIHRo ZSBvYmplY3QgTVVTVCBiZSBpbXBsZW1lbnRlZCANCmNvcnJlY3RseSBhY2NvcmRpbmcgdG8gdGhl IE1JQiBkZWZpbml0aW9uLiBJZiBhIHZlbmRvciBjaG9vc2VzIG5vdCB0byBpbXBsZW1lbnQgDQp0 aGUgb2JqZWN0LCBhbiBhZ2VudCBNVVNUIE5PVCBpbnN0YW50aWF0ZSBzdWNoIG9iamVjdCBhbmQg TVVTVCByZXNwb25kIHdpdGggDQp0aGUgYXBwcm9wcmlhdGUgZXJyb3IvZXhjZXB0aW9uIGNvbmRp dGlvbiAoZS5nLiwgbm8gc3VjaCBvYmplY3QgZm9yIFNOTVB2MmMpLiINCg0KSXQgaXMgY2xlYXIg dGhhdCB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IgcGVyIE9TU0kgc3BlYyBpcyB0byBmaW5kIHRhYmxl cyB3aXRoIA0KJ2hvbGVzJyB3aGljaCBpcyBhbHNvIHRoZSBJRVRGIHJlY29tZW5kYXRpb24uIA0K DQpDb25jbHVzaW9uIA0KIA0KRnJvbSB0aGUgc3BlYyBwb2ludCBvZiB2aWV3IHRoZSB0YWJsZSB3 aXRoIHRoZSBjaGFuZ2VzIGlzIGZpbmUsIG5vIG5lZWQgdG8gDQpzcGxpdCBhbmQgbWFuYWdlbWVu dCBzb2Z0d2FyZSBpbXBsZW1lbnRlcnMgYW5kIG9wZXJhdG9ycyBtaWdodCBleHBsb3JlIHVuaWZp ZWQgDQpjYXRhIGxvYWRlciBzaW5jZSB0aGlzIHByb2JsZW0gaXMgbm90IGV4Y2x1c2l2ZSBvZiB0 aGlzIHRhYmxlLCBidXQgaW4gZ2VuZXJhbCANCmZvciBhbGwgaW50ZXJmYWNlIHJlbGF0ZWQgc3Rh dGlzdGljcyBhbmQgc29mdHdhcmUgdmVyc2lvbmluZy4NCg0KDQoNCiANCg0KDQo= ------_=_NextPart_001_01C38CE8.54CC35AD-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Oct 7 18:24:24 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 SAA25801 for ; Tue, 7 Oct 2003 18:24:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A70FQ-00034B-Ht for ipcdn-archive@odin.ietf.org; Tue, 07 Oct 2003 18:24:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97MO45m011783 for ipcdn-archive@odin.ietf.org; Tue, 7 Oct 2003 18:24:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A70FN-00033r-VP; Tue, 07 Oct 2003 18:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A70EQ-000336-AW for ipcdn@optimus.ietf.org; Tue, 07 Oct 2003 18:23:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25762 for ; Tue, 7 Oct 2003 18:22:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A70EN-0004cq-00 for ipcdn@ietf.org; Tue, 07 Oct 2003 18:22:59 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A70EM-0004cn-00 for ipcdn@ietf.org; Tue, 07 Oct 2003 18:22:58 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h97MMG10024583; Tue, 7 Oct 2003 16:22:17 -0600 (MDT) 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_01C38D21.77191F2C" Date: Tue, 7 Oct 2003 16:22:16 -0600 Message-ID: X-MS-Has-Attach: yes Thread-Topic: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcNrZOVcJIoX6N/8SlSQ6cbW5exQZwhtChQA From: "Greg White" To: , "Minnie Lu" Cc: "DOCSIS OSS Majordomo List" , , , "Minnie Lu" , X-Approved: ondar Subject: [ipcdn] Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) 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_01C38D21.77191F2C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C38D21.77191F2C" ------_=_NextPart_002_01C38D21.77191F2C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 As a final issue to resolve in the RFMIBv2 before draft-08, I would like to propose that we complete the clarification of the relationship between the ChannelType parameters in modulation profiles and upstream channels. =20 There is currently an ECO (OSS2-O-03092) written by Minnie Lu which clarifies part of the relationship by adding requirements to the OSSI spec. I would like to suggest that we propagate those requirements to the MIB descriptions. =20 =20 Also, I would like to propose that we make docsIfUpChannelType a read-only object for active rows in the Upstream Channel Table. The value reported would be taken from the modulation profile pointed to by docsIfUpChannelModulationProfile. =20 =20 Attached is a detailed proposal that Eduardo and I wrote to frame the issue. =20 In order not to delay draft-08, we would like to have consensus from the community and working group by this Friday, October 10. Please review the attached proposal and provide comments. =20 Many thanks, Greg -----Original Message----- From: David.White@arrisi.com [mailto:David.White@arrisi.com]=20 Sent: Monday, August 25, 2003 5:59 PM To: Minnie Lu Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels =09 =09 Minnie,=20 I am emphathetic to your concerns. I ran across the same issue while implementing cross-checks for the 2.0 modulation and upstream data. I found it made the code far simpler to lead the user down the path of "define the channel type first, then build everything around that" kind of configuration model. I am then able to check the settings of the other parameters against the channel type. After a modulation profile or upstream channel has already been provisioned, changing just the channel type becomes difficult, as many parameters are incompatible with other channel types. I allow it, but don't recommend it.=20 =09 My 2 cents,=20 David=20 =09 =09 =09 =09 Minnie Lu =20 08/25/2003 07:01 PM=20 =20 To: "Greg White" =20 cc: , "Minnie Lu" , , , "DOCSIS OSS Majordomo List" , "Owner DOCSIS OSS Majordomo List" =20 Fax to: =20 Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels Hi, Greg, =09 Please see my response inline. Thanks a lot ! Minnie At 02:29 PM 8/25/2003 -0600, Greg White wrote: >The email exchange between Steve and Alberto notwithstanding, I think it=20 >does make sense to enforce that all entries in a modulation profile (i.e.=20 >all entries that share a common docsIfCmtsModIndex) have the same=20 >ModChannelType. Also, based on the exchange here it seems that there is=20 >some support for the additional restriction that UpChannelType and=20 >ModChannelType always match. With those two restrictions, there clearly=20 >is a need for all defined values of ModChannelType. > >Since this has been a point of confusion at least twice now, does anyone=20 >have a concern with making these two items part of the specification? > =09 [milu]: I agree with you. =09 >A further point, how does the CMTS enforce the match between UpChannelType=20 >and ModChannelType? One implementation may automatically change=20 >UpChannelType to match ModChannelType whenever=20 >docsIfUpChannelModulationProfile is set. Another might reject the change=20 >if the two don't already match, and require the use of the=20 >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd argue=20 >that the first implementation makes more sense, and ought to be made a=20 >SHOULD in the spec, but I'd like to hear other views. > =09 [milu]: I think this needs to be thought over carefully. How about the=20 case that some modulation profile is used by some upstream channel, and=20 user change the modulation profile channel type ? Does it mean that the=20 upstream channel type would be changed automatically, too ? If yes, I am=20 afraid that there might be some user who forget the modulation profile is=20 being used and change the channel type without knowing the upstream channel=20 type for some upstream channels are changed at the same time. The=20 modulation profile channel type and upstream channel type are in two=20 different MIB tables. =09 Actually, I am always puzzled when the modulation profile is being used=20 by some upstream channels, could the modulation profile channel type be=20 changed ? Maybe this is a confusing point which needs to be clarified, too. =09 Thanks a lot for your help ! Minnie =09 =09 =09 >-Greg >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Monday, August 25, 2003 11:07 AM >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner DOCSIS=20 >OSS Majordomo List >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to=20 >upstream channels > >Minnie, > Sounds good to me. This would make verifying the consistency of=20 > the data in the modulation profiles and the upstream channels far easier. >So, if I understand correctly, this means that all modulation profile=20 >entries with the same docsIfCmtsModIndex will have to have the same=20 >docsIfCmtsModChannelType. Otherwise, you would not be able to use that=20 >modulation profile set on any upstream channel. So, this modulation=20 >profile set with different docsIfCmtsModChannelTypes from an e-mail thread=20 >between Alberto and Steve from almost a year ago would be invalid, no ?=20 >The way to patch it up would be to make all of the IUCs tdmaAndAtdma,=20 >correct ? > >Thanks, >David > >--- end David's e-mail --- >--- start e-mail exchange between Alberto and Steve --- > >Hi Steve > >Sorry for the delay in responding > >Your configuration settings for operation in multiple mode is correct and=20 >will support tdma, tdmaAndAtdma and Atdma. >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with UCD=20 >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and IUCs=20 >5&6 are not used. Your interpretation of the spec in the example described=20 >is accurate. > >Alberto Campos >a.campos@cablelabs.com > > > > > >-----Original Message----- >From: Steve Malenfant [mailto:smalenfant@com21.com] >Sent: Monday, September 30, 2002 9:39 AM >To: 'docsis-20@cablelabs.com' >Subject: Correlation between docsIfUpChannelType and >docsIfCmtsModChannelT ype > > > >We are having some discussion internally here, and would like to clarify >things about the modulation profile. >Let's take an example, expecting all parameters are good : > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. >set IUC 5 docsIfCmtsModChannelType to tdma. >set IUC 6 docsIfCmtsModChannelType to tdma. >set IUC 9 docsIfCmtsModChannelType to Atdma. >set IUC 10 docsIfCmtsModChannelType to Atdma. > >Would this burst profile be good for docsIfUpChannelType tdma, tdmaAndAtdma >and Atdma? > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 inside >UCD type 2. >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. > > > > > >Minnie Lu >Sent by: owner-docsis-oss@cablelabs.com > >08/21/2003 07:15 PM > > To: David.White@arrisi.com, "Greg White"=20 > > cc: "DOCSIS OSS Majordomo List"=20 > , milu@cisco.com > Fax to: > Subject: RE: DOCSIS 2.0 : rules for assigning modulation=20 > profiles to upstream channels > > > > > >Hi, David and Greg, > > I like Greg's "Perhaps it is simpler just to require that ModChannelType >match UpChannelType.". > > I don't think that "we could just drop tdmaAndAtdma for >ModChannelType". Please keep in mind that when assigning the modulation >profile to some upstream via SNMP docsIfUpChannelModulationProfile, it uses >only the docsIfModIndex and only one docsIfModIndex can be assigned to some >upstream channel. > > If I miss anything, please correct me. > Thanks! > Minnie > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > >Greg, > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma channels. > > However, the modulation profiles objects > > docsIfCmtsModByteInterleaverBlockSize and > > docsIfCmtsModByteInterleaverDepth are only valid for atdma channels. So, > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these objects set, > > it assumably could not be used on a tdma-only upstream channel. Hence, > > the whole purpose of even having ModChannelType - to verify consistency > > within the modulation profile - is weakened. This has the unintended side > > effect of requiring any assignment of modulation profiles with IUCs 1, 2, > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see if the > > Interleaver parameters have been set before assigning it to a tdma-only > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation=20 > profiles.=20 > > I can't think of any need/requirement for tdmaAndAtdma for > > modulation profiles that could not be met with a pair of tdma and atdma > > modulation profile. In other words, I don't think allowing tdmaAndAtdma > > for ModChannelType really buys us anything. I'm thinking we could just > > drop tdmaAndAtdma for ModChannelType (making it a > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of confusion. > > For the mixed-mode channels, where UpChannelType is tdmaAndAtdma, > > the modulation profile set could look like so: > > > >IUC 1 tdma > >IUC 2 tdma > >IUC 3 tdma > >IUC 4 tdma > >IUC 5 tdma > >IUC 6 tdma > >IUC 9 atdma > >IUC 10 atdma > >IUC 11 atdma > > > >For tdma-only upstream channels, the modulation profile set could be: > > > >IUC 1 tdma > >IUC 2 tdma > >IUC 3 tdma > >IUC 4 tdma > >IUC 5 tdma > >IUC 6 tdma > > > >Likewise, for atdma-only upstream channel, the modulation profile set > >could be: > > > >IUC 1 atdma > >IUC 2 atdma > >IUC 3 atdma > >IUC 4 atdma > >IUC 9 atdma > >IUC 10 atdma > >IUC 11 atdma > > > >As far as I know, there is no hard limit on the number of the modulation > >profile sets that the CMTS and CM can support. I'm really liking your "not > >sure the benefits of flexibility outweigh disadvantages..." line of > >thinking. tdmaAndAtdma for modulation profiles has my head spinning. > > > >Thanks, > >David > > > > > > > >"Greg White" > >Sent by: owner-docsis-oss@cablelabs.com > > > >08/20/2003 07:35 PM > > > > To: , "DOCSIS OSS Majordomo List" > > > > cc: > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning modulation > > profiles to upstream channels > > > > > >David, > > > >I agree with all of your clearly legal/illegal combinations. Among the > >four that cause you consternation, I would break them done like this: > > > >illegal: > >tdma, atdma > >atdma, tdma > > > >potentially legal: > >tdma, tdmaAndAtdma > >atdma, tdmaAndAtdma > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and possibly 11, > >so cannot be used for a tdma channel. Similarly a tdma modulation profile > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma channel. > > > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10, and > >possibly 11, so could potentially be used for a tdma or an atdma channel > >(in addition to a tdmaAndAtdma channel), as long as the CMTS ignored the > >IUCs that don't apply to the channel type. I'm not sure that the > >advantages of that flexibility outweigh the disadvantages of having the > >MIB reporting something that doesn't exactly reflect what is > >configured. Perhaps it is simpler just to require that ModChannelType > >match UpChannelType. > > > >-Greg > > > > > > ----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Tuesday, August 19, 2003 9:37 AM > >To: DOCSIS OSS Majordomo List > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to upstream > >channels > > > > > >DOCSIS 2.0 Community, > > It seems that the DocsisUpstreamType objects in both the > > modulation profile table and the upstream channel table exist, in part, > > to provide the equipment vendor a way to cross-check the data for > > consistency. Furthermore, it would seem possible to compare the two > > DocsisUpstreamType objects when assigning an upstream to a modulation > > profile to make sure the assignment is compatible. For instance, the > > following combination of docsIfUpChannelType, docsIfCmtsModChannelType > > would clearly be illegal: > > > >scdma, tdma > >scdma, atdma > >scdma, tdmaAndAtdma > > > >tdma, scdma > >atdma, scdma > >tdmaAndAtdma, scdma > > > > > >It is also pretty clear the following are legal: > > > >tdma, tdma > >atdma, atdma > >scdma, scdma=20 > >tdmaAndAtdma, tdmaAndAtdma > > > > > >However, it is the following cases that are causing me consternation: > > > >tdma, atdma > >tdma, tdmaAndAtdma > >atdma, tdma > >atdma, tdmaAndAtdma > > > > > >If ALL of these are legal, then I do not understand the point of > >tdmaAndAtdma, other than to cause confusion, especially for modulation > >profiles. > > > >Thanks, > >David White > >ARRIS Cadant C4 CMTS > =09 =09 =09 =09 ------_=_NextPart_002_01C38D21.77191F2C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
All,
 
As a=20 final issue to resolve in the RFMIBv2 before draft-08, I would like to = propose=20 that we complete the clarification of the relationship between the = ChannelType=20 parameters in modulation profiles and upstream=20 channels.
 
There=20 is currently an ECO (OSS2-O-03092) written by Minnie Lu which clarifies = part of=20 the relationship by adding requirements to the OSSI spec.  I would = like to=20 suggest that we propagate those requirements to the MIB = descriptions. =20
 
Also,=20 I would like to propose that we make docsIfUpChannelType a read-only = object for=20 active rows in the Upstream Channel Table.  The value reported = would be=20 taken from the modulation profile pointed to by=20 docsIfUpChannelModulationProfile. 
 
Attached is a detailed proposal that Eduardo = and I=20 wrote to frame the issue.
 
In=20 order not to delay draft-08, we would like to have consensus from the = community=20 and working group by this Friday, October 10.  Please review the = attached=20 proposal and provide comments.
 
Many=20 thanks,
Greg
-----Original Message-----
From:=20 David.White@arrisi.com [mailto:David.White@arrisi.com] =
Sent:=20 Monday, August 25, 2003 5:59 PM
To: Minnie Lu
Cc: = DOCSIS=20 OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White;=20 Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo=20 List
Subject: RE: DOCSIS 2.0 : rules for assigning = modulation=20 profiles to upstream channels


Minnie,
  =    =20   I am emphathetic to your concerns. I ran across the same issue = while=20 implementing cross-checks for the 2.0 modulation and upstream data. I = found it=20 made the code far simpler to lead the user down the path of "define = the=20 channel type first, then build everything around that" kind of = configuration=20 model. I am then able to check the settings of the other parameters = against=20 the channel type. After a modulation profile or upstream channel has = already=20 been provisioned, changing just the channel type becomes difficult, as = many=20 parameters are incompatible with other channel types. I allow it, but = don't=20 recommend it.

My 2 = cents,=20
David



Minnie Lu=20 <milu@cisco.com>=20

08/25/2003 07:01 PM =

        =
        To: =    =20    "Greg White" <g.white@CableLabs.com> =
        cc: =    =20    <David.White@arrisi.com>, "Minnie Lu"=20 <milu@cisco.com>, <Greg.Gohman@arrisi.com>,=20 <Larry.Spaete@arrisi.com>, "DOCSIS OSS Majordomo List"=20 <docsis-oss@CableLabs.com>, "Owner DOCSIS OSS Majordomo = List"=20 <owner-docsis-oss@CableLabs.com>
        Fax to:     =  =20  
    =  =20   Subject:        RE: DOCSIS 2.0 : = rules for=20 assigning modulation profiles to   upstream=20 channels



Hi, Greg,

 Please see my response = inline.
 Thanks a=20 lot !
 Minnie
At 02:29 PM 8/25/2003 -0600, Greg White=20 wrote:
>The email exchange between Steve and Alberto = notwithstanding, I=20 think it
>does make sense to enforce that all entries in a = modulation=20 profile (i.e.
>all entries that share a common = docsIfCmtsModIndex) have=20 the same
>ModChannelType.  Also, based on the exchange = here it=20 seems that there is
>some support for the additional = restriction that=20 UpChannelType and
>ModChannelType always match.  With = those two=20 restrictions, there clearly
>is a need for all defined values = of=20 ModChannelType.
>
>Since this has been a point of = confusion at=20 least twice now, does anyone
>have a concern with making these = two=20 items part of the specification?
>

[milu]: I agree with=20 you.

>A further point, how does the CMTS enforce the match = between=20 UpChannelType
>and ModChannelType?  One implementation may = automatically change
>UpChannelType to match ModChannelType = whenever=20
>docsIfUpChannelModulationProfile is set.  Another might = reject=20 the change
>if the two don't already match, and require the use = of the=20
>docsIfUpChannelCloneFrom mechanism to change the channel type. =  I'd argue
>that the first implementation makes more = sense, and=20 ought to be made a
>SHOULD in the spec, but I'd like to hear = other=20 views.
>

[milu]: I think this needs to be thought over = carefully.=20  How about the
case that some modulation profile is used by = some=20 upstream channel, and
user change the modulation profile channel = type ?=20  Does it mean that  the
upstream channel type would be = changed=20 automatically, too ?  If yes, I am
afraid that there might be = some=20 user who forget the modulation profile is
being used and change = the=20 channel type without knowing the upstream channel
type for some = upstream=20 channels are changed at the same time.  The
modulation = profile=20 channel type and upstream channel type are in two
different MIB=20 tables.

  Actually, I am always puzzled when the = modulation=20 profile is being used
by some upstream channels, could the = modulation=20 profile channel type be
changed ?  Maybe this is a confusing = point=20 which needs to be clarified, too.

  Thanks a lot for your = help=20 !
  Minnie



>-Greg
>-----Original=20 Message-----
>From: David.White@arrisi.com=20 [mailto:David.White@arrisi.com]
>Sent: Monday, August 25, 2003 = 11:07=20 AM
>To: Minnie Lu; Greg.Gohman@arrisi.com;=20 Larry.Spaete@arrisi.com
>Cc: DOCSIS OSS Majordomo List; Greg = White;=20 milu@cisco.com; Owner DOCSIS
>OSS Majordomo = List
>Subject: RE:=20 DOCSIS 2.0 : rules for assigning modulation profiles to =
>upstream=20 channels
>
>Minnie,
>         = Sounds=20 good to me. This would make verifying the consistency of =
> the data in the modulation profiles = and the=20 upstream channels far easier.
>So, if I understand correctly, = this means=20 that all modulation profile
>entries with the same = docsIfCmtsModIndex=20 will have to have the same
>docsIfCmtsModChannelType. = Otherwise, you=20 would not be able to use that
>modulation profile set on any = upstream=20 channel. So, this modulation
>profile set with different=20 docsIfCmtsModChannelTypes from an e-mail thread
>between = Alberto and=20 Steve from almost a year ago would be invalid, no ?
>The way to = patch=20 it up would be to make all of the IUCs tdmaAndAtdma,
>correct=20 ?
>
>Thanks,
>David
>
>--- end David's = e-mail=20 ---
>--- start e-mail exchange between Alberto and Steve=20 ---
>
>Hi Steve
>
>Sorry for the delay in=20 responding
>
>Your configuration settings for operation in = multiple mode is correct and
>will support tdma, tdmaAndAtdma = and=20 Atdma.
>In tdma only IUCs 9&10 are not used. In mixed mode = TLV 5 is=20 used with UCD
>type 2 and in DOCSIS 2.0 only case TLV 5 is used = with=20 UCD type 29 and IUCs
>5&6 are not used. Your interpretation = of the=20 spec in the example described
>is = accurate.
>
>Alberto=20 = Campos
>a.campos@cablelabs.com
>
>
>
>
&= gt;
>-----Original=20 Message-----
>From: Steve Malenfant=20 [mailto:smalenfant@com21.com]
>Sent: Monday, September 30, 2002 = 9:39=20 AM
>To: 'docsis-20@cablelabs.com'
>Subject: Correlation = between=20 docsIfUpChannelType and
>docsIfCmtsModChannelT=20 ype
>
>
>
>We are having some discussion = internally=20 here, and would like to clarify
>things about the modulation=20 profile.
>Let's take an example, expecting all parameters are = good=20 :
>
>set IUC 1 docsIfCmtsModChannelType to=20 tdmaAndAtdma.
>set IUC 3 docsIfCmtsModChannelType to=20 tdmaAndAtdma.
>set IUC 4 docsIfCmtsModChannelType to=20 tdmaAndAtdma.
>set IUC 5 docsIfCmtsModChannelType to = tdma.
>set=20 IUC 6 docsIfCmtsModChannelType to tdma.
>set IUC 9=20 docsIfCmtsModChannelType to Atdma.
>set IUC 10 = docsIfCmtsModChannelType=20 to Atdma.
>
>Would this burst profile be good for=20 docsIfUpChannelType tdma, tdmaAndAtdma
>and = Atdma?
>
>tdma=20 would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type = 2.
>mixed=20 would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5=20 inside
>UCD type 2.
>Atdma would only use IUC 1,3,4,9 and = 10 in=20 TLV 5 inside UCD type=20 29.
>
>
>
>
>
>Minnie Lu=20 <milu@cisco.com>
>Sent by:=20 owner-docsis-oss@cablelabs.com
>
>08/21/2003 07:15=20 PM
>
>         To:     =  =20  David.White@arrisi.com, "Greg White"
>=20 <g.white@cablelabs.com>
>         cc: =  =20      "DOCSIS OSS Majordomo List"
>=20 <docsis-oss@cablelabs.com>, milu@cisco.com
>     =  =20   Fax to:
>         Subject:   =  =20    RE: DOCSIS 2.0 : rules for assigning modulation
> = profiles=20 to  upstream = channels
>
>
>
>
>
>Hi,=20 David and Greg,
>
>  I like Greg's "Perhaps it is = simpler=20 just to require that ModChannelType
>match=20 UpChannelType.".
>
>  I don't think that "we could = just drop=20 tdmaAndAtdma for
>ModChannelType".  Please keep in mind = that when=20 assigning the modulation
>profile to some upstream via SNMP=20 docsIfUpChannelModulationProfile, it uses
>only the = docsIfModIndex and=20 only one docsIfModIndex can be assigned to some
>upstream=20 channel.
>
>  If I miss anything, please correct = me.
>=20  Thanks!
>  Minnie
>
>At 10:53 AM = 8/21/2003 -0400,=20 David.White@arrisi.com wrote:
>
> >Greg,
> > =  =20       IUCs 1, 2, 3, and 4 are used for both tdma and = atdma=20 channels.
> > However, the modulation profiles = objects
> >=20 docsIfCmtsModByteInterleaverBlockSize and
> >=20 docsIfCmtsModByteInterleaverDepth are only valid for atdma channels.=20 So,
> > if a modulation profile with IUCs 1, 2, 3 and/or 4 = had these=20 objects set,
> > it assumably could not be used on a = tdma-only=20 upstream channel. Hence,
> > the whole purpose of even having = ModChannelType - to verify consistency
> > within the = modulation=20 profile - is weakened. This has the unintended side
> > = effect of=20 requiring any assignment of modulation profiles with IUCs 1, = 2,
> >=20 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see if=20 the
> > Interleaver parameters have been set before assigning = it to a=20 tdma-only
> > upstream channel. Hence, my gripe with = tdmaAndAtdma for=20 modulation
> profiles.
>=20 >         I can't think of any need/requirement = for=20 tdmaAndAtdma for
> > modulation profiles that could not be = met with a=20 pair of tdma and atdma
> > modulation profile. In other = words, I=20 don't think allowing tdmaAndAtdma
> > for ModChannelType = really buys=20 us anything. I'm thinking we could just
> > drop tdmaAndAtdma = for=20 ModChannelType (making it a
> > DocsisUpstreamTypeStatus = object,=20 perhaps ?) to avoid a lot of confusion.
> >     =  =20   For the mixed-mode channels, where UpChannelType is=20 tdmaAndAtdma,
> > the modulation profile set could look like=20 so:
> >
> >IUC  1  tdma
> >IUC =  2=20  tdma
> >IUC  3  tdma
> >IUC  4=20  tdma
> >IUC  5  tdma
> >IUC  6=20  tdma
> >IUC  9 atdma
> >IUC 10 = atdma
>=20 >IUC 11 atdma
> >
> >For tdma-only upstream = channels, the=20 modulation profile set could be:
> >
> >IUC 1 = tdma
>=20 >IUC 2 tdma
> >IUC 3 tdma
> >IUC 4 tdma
> = >IUC 5=20 tdma
> >IUC 6 tdma
> >
> >Likewise, for = atdma-only=20 upstream channel, the modulation profile set
> >could = be:
>=20 >
> >IUC  1 atdma
> >IUC  2 = atdma
>=20 >IUC  3 atdma
> >IUC  4 atdma
> >IUC =  9=20 atdma
> >IUC 10 atdma
> >IUC 11 atdma
> = >
>=20 >As far as I know, there is no hard limit on the number of the=20 modulation
> >profile sets that the CMTS and CM can support. = I'm=20 really liking your "not
> >sure the benefits of flexibility = outweigh=20 disadvantages..." line of
> >thinking. tdmaAndAtdma for = modulation=20 profiles has my head spinning.
> >
> = >Thanks,
>=20 >David
> >
> >
> >
> >"Greg = White"=20 <g.white@cablelabs.com>
> >Sent by:=20 owner-docsis-oss@cablelabs.com
> >
> >08/20/2003 = 07:35=20 PM
> >
> >         To:   =  =20    <David.White@arrisi.com>, "DOCSIS OSS Majordomo=20 List"
> > <docsis-oss@cablelabs.com>
> > =    =20     cc:
> >         Fax = to:
>=20 >         Subject:       =  RE:=20 DOCSIS 2.0 : rules for assigning modulation
> > profiles to = upstream=20 channels
> >
> >
> >David,
> = >
>=20 >I agree with all of your clearly legal/illegal combinations. =  Among=20 the
> >four that cause you consternation, I would break them = done=20 like this:
> >
> >illegal:
> >tdma, = atdma
>=20 >atdma, tdma
> >
> >potentially legal:
> = >tdma,=20 tdmaAndAtdma
> >atdma, tdmaAndAtdma
> >
> = >An atdma=20 modulation profile will include IUCs 1,3,4,9,10, and possibly = 11,
>=20 >so cannot be used for a tdma channel. Similarly a tdma modulation=20 profile
> >will include IUCs 1,3,4,5,6, so cannot be used for = an=20 atdma channel.
> >
> >A tdmaAndAtdma modulation = profile will=20 include IUCs 1,3,4,5,6,9,10, and
> >possibly 11, so could = potentially=20 be used for a tdma or an atdma channel
> >(in addition to a=20 tdmaAndAtdma channel), as long as the CMTS ignored the
> = >IUCs that=20 don't apply to the channel type.  I'm not sure that the
>=20 >advantages of that flexibility outweigh the disadvantages of = having=20 the
> >MIB reporting something that doesn't exactly reflect = what=20 is
> >configured.  Perhaps it is simpler just to require = that=20 ModChannelType
> >match UpChannelType.
> >
>=20 >-Greg
> >
> >
> >  ----Original=20 Message-----
> >From: David.White@arrisi.com=20 [mailto:David.White@arrisi.com]
> >Sent: Tuesday, August 19, = 2003=20 9:37 AM
> >To: DOCSIS OSS Majordomo List
> >Subject: = DOCSIS=20 2.0 : rules for assigning modulation profiles to upstream
>=20 >channels
> >
> >
> >DOCSIS 2.0=20 Community,
> >        It seems that the=20 DocsisUpstreamType objects in both the
> > modulation profile = table=20 and the upstream channel table exist, in part,
> > to provide = the=20 equipment vendor a way to cross-check the data for
> > = consistency.=20 Furthermore, it would seem possible to compare the two
> >=20 DocsisUpstreamType objects when assigning an upstream to a = modulation
>=20 > profile to make sure the assignment is compatible. For instance,=20 the
> > following combination of docsIfUpChannelType,=20 docsIfCmtsModChannelType
> > would clearly be = illegal:
>=20 >
> >scdma, tdma
> >scdma, atdma
> = >scdma,=20 tdmaAndAtdma
> >
> >tdma, scdma
> >atdma,=20 scdma
> >tdmaAndAtdma, scdma
> >
> = >
> >It=20 is also pretty clear the following are legal:
> >
> = >tdma,=20 tdma
> >atdma, atdma
> >scdma, scdma =
> >tdmaAndAtdma, = tdmaAndAtdma
>=20 >
> >
> >However, it is the following cases that = are=20 causing me consternation:
> >
> >tdma, atdma
> = >tdma, tdmaAndAtdma
> >atdma, tdma
> >atdma,=20 tdmaAndAtdma
> >
> >
> >If ALL of these are = legal,=20 then I do not understand the point of
> >tdmaAndAtdma, other = than to=20 cause confusion, especially for modulation
> = >profiles.
>=20 >
> >Thanks,
> >David White
> >ARRIS = Cadant C4=20 CMTS
>



=00 ------_=_NextPart_002_01C38D21.77191F2C-- ------_=_NextPart_001_01C38D21.77191F2C Content-Type: text/plain; name="issue#23.txt" Content-Transfer-Encoding: base64 Content-Description: issue#23.txt Content-Disposition: attachment; filename="issue#23.txt" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 KyBJc3N1ZSAjMjMgKG5ldykNClN0YXR1czogT3Blbg0KKDIzKSBDaGFuZ2UgdGhlIHN5bnRheCBv ZiBuZXdseSBhZGRlZCBSRkl2MiBNSUIgb2JqZWN0IA0KICAgICBkb2NzSWZVcENoYW5uZWxUeXBl IGFzIHJlYWQtb25seS4NCiAgICAgVGhlIHB1cnBvc2Ugb2YgdGhlIGNoYW5nZSBpcyB0byBjbGFy aWZ5LCBzaW1wbGlmeSBhbmQNCiAgICAgbm9ybWFsaXplIHRoZSBjb25maWd1cmF0aW9uIG9mIG1v ZHVsYXRpb24gcHJvZmlsZXMgd2hlbiANCiAgICAgYXNzaWduaW5nIHRoZW0gdG8gdXBzdHJlYW0g Y2hhbm5lbHMuDQogICAgIENsYXJpZnkgb3RoZXIgaW50ZXJkZXBlbmRlbmNpZXMgYmV0d2VlbiBV UyBjaGFubmVsIGFuZCANCiAgICAgTW9kdWxhdGlvbiBQcm9maWxlIHRhYmxlcyBhcyBjdXJyZW50 bHkgcHJlc2VudCBpbiB1cCB0b2RheQ0KICAgICBPU1MyLTAtMDMwOTINCiAgICAgQ29udHJpYnV0 b3JzIC0gTWlubmllIEx1IENpc2NvLCBEYXZpZCBXaGl0ZSBBcnJpcywgSmltIEZsZXRjaGVyIEFE Qw0KICAgICBHcmVnIFdoaXRlIENhYmxlTGFicywgRWR1YXJkbyBDYXJkb25hIENhYmxlTGFicw0K IyBjYXRlZ29yeTogIm11c3QgZml4Ig0KIyBBY3Rpb24gSXRlbTogTmV3IGl0ZW0gcHJlc2VudGVk LCB0byB0aGUgSVBDRE4gZ3JvdXAgZm9yIGNvbnNpZGVyYXRpb25zDQojIGNoYWlyIHdpbGwgbWFr ZSBhIGRlY2lzaW9uLg0KDQpJc3N1ZSBEZXRhaWxzDQoNClNldHRpbmcgYSBtb2R1bGF0aW9uIHBy b2ZpbGUgZm9yIGFuIFVTIGNoYW5uZWwgaW52b2x2ZXM6DQoNCjEgRGVmaW5lIGEgTW9kdWxhdGlv biBwcm9maWxlIGluIGRvY3NJZkNtdHNNb2R1bGF0aW9uVGFibGUNCjIgQXNzaWduIHRoZSBtb2R1 bGF0aW9uIHByb2ZpbGUgYW5kIG90aGVyIHBhcmFtZXRlcnMgdG8gdGhlIFVTIGludGVyZmFjZSAN CiAgKGlmSW5kZXgpIGluIGRvY3NJZlVwc3RyZWFtQ2hhbm5lbFRhYmxlIGJ5IHNldHRpbmcgDQog IGRvY3NJZlVwQ2hhbm5lbE1vZHVsYXRpb25Qcm9maWxlIHRvIHRoZSB2YWx1ZSBvZiBkb2NzSWZD bXRzTW9kSW5kZXggb2YgdGhlIA0KICBkZXNpcmVkIHByb2ZpbGUNCiAgDQpUaGUgY3VycmVudCBw cm9ibGVtIHJlc3VsdHMgZnJvbSBhbiBhbWJpZ3VpdHkgaW4gdGhlIG1pYiByZWxhdGluZyB0byBz b21lIA0KaW50ZXJkZXBlbmRlbmNpZXMgYmV0d2VlbiB0aGUgdHdvIHRhYmxlcy4gSW4gcGFydGlj dWxhciwgYm90aCB0YWJsZXMgY3VycmVudGx5IA0KaGF2ZSBDaGFubmVsVHlwZSBvYmplY3RzIChk b2NzSWZVcENoYW5uZWxUeXBlIGFuZCBkb2NzSWZDbXRzTW9kQ2hhbm5lbFR5cGUpLg0KDQpCYXNl ZCBvbiB0aGUgY3VycmVudCBNSUIsIHRoZXJlIGlzIGEgc3Ryb25nIGxpa2VsaWhvb2QgdGhhdCB0 aGUgdHdvIG9iamVjdHMgDQpjb3VsZCBjb25mbGljdCwgYW5kIENNVFMgdmVuZG9ycyB3b3VsZCBu ZWVkIHRvIGRldmVsb3AgbWVjaGFuaXNtcyB0byByZXNvbHZlIA0KdGhlIGNvbmZsaWN0cy4gDQoN ClRoaXMgcHJvcG9zYWwgY2hhbmdlcyBkb2NzSWZVcENoYW5uZWxUeXBlIHRvIHJlYWQtb25seSwg dGhlIHZhbHVlIHJlcG9ydGVkICANCmlzIHRha2VuIGZyb20gdGhlIGRvY3NJZkNtdHNNb2RDaGFu bmVsVHlwZSBvYmplY3Qgb2YgdGhlIGN1cnJlbnRseSBzZWxlY3RlZCANCm1vZHVsYXRpb24gcHJv ZmlsZS4NCg0KVGhpcyBjaGFuZ2Ugd2lsbCBhcHBseSB0byBhbGwgZG9jc0lmVXBDaGFubmVsVHlw ZSBlbnRyaWVzIGUuZy4gcGh5c2ljYWwgDQpleGlzdGluZyBvbmVzIChlLmcuIGRvY3NJZlVwQ2hh bm5lbFN0YXR1cyA9ICdhY3RpdmUnICkgYW5kIGNsb25lZCBlbnRyaWVzIA0KKGUuZy4gZG9jc0lm VXBDaGFubmVsU3RhdHVzID0gJ2NyZWF0ZUFuZFdhaXQnLT4gJ25vdEluU2VydmljZScpLg0KDQog DQpBcyB3cml0dGVuIGluIE9TUzItTy0wMzA5MiwgYW4gZXh0cmEgcmVzdHJpY3Rpb24gaXMgbmVl ZGVkOg0KDQpJbiBvcmRlciBmb3IgYSBtb2R1bGF0aW9uIHByb2ZpbGUgdG8gYmUgY29uc2lkZXJl ZCB2YWxpZCwgYWxsIElVQ3MgaW4gdGhlIA0KbW9kdWxhdGlvbiBwcm9maWxlIE1VU1QgaGF2ZSB0 aGUgc2FtZSBkb2NzSWZDbXRzTW9kQ2hhbm5lbFR5cGUuICBUaGUgdmFsaWRhdGlvbiANCmlzIHRv IGJlIHBlcmZvcm1lZCB3aGVuZXZlciBhIHByb2ZpbGUgaXMgYXNzaWduZWQgdG8gYW4gdXBzdHJl YW0gY2hhbm5lbC4gIA0KQWRkaXRpb25hbGx5LCB0aGUgdmFsdWVzIG9mIGRvY3NJZkNtdHNNb2RD aGFubmVsVHlwZSBmb3IgYSBwcm9maWxlIE1VU1QgTk9UIGJlIA0KY2hhbmdlZCB3aGlsZSB0aGUg cHJvZmlsZSBpcyBhc3NpZ25lZCB0byBvbmUgb3IgbW9yZSB1cHN0cmVhbSBjaGFubmVscy4NCiAN Ck5vdCBkaXJlY3RseSByZWxhdGVkIHRvIHRoaXMgaXNzdWUsIGJ1dCBhbHNvIGZyb20gT1NTMi1P LTAzMDkyOiAgIEEgbW9kdWxhdGlvbiANCnByb2ZpbGUgTVVTVCBOT1QgYmUgZGVzdHJveWVkIGlm IGl0IGFzc2lnbmVkIHRvIG9uZSBvciBtb3JlIGFjdGl2ZSBjaGFubmVscy4gDQogDQogDQpQcm9w b3NlZCBuZXcgZGVzY3JpcHRpb25zIGZvciBjdXJyZW50IE1JQiBvYmplY3RzOg0KDQoNCmRvY3NJ ZkNtdHNNb2R1bGF0aW9uRW50cnkgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgRG9j c0lmQ210c01vZHVsYXRpb25FbnRyeQ0KICAgICAgICBNQVgtQUNDRVNTICBub3QtYWNjZXNzaWJs ZQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAg ICAgICAgICAiRGVzY3JpYmVzIGEgbW9kdWxhdGlvbiBwcm9maWxlIGZvciBhbiBJbnRlcnZhbCBV c2FnZSBDb2RlDQogICAgICAgICAgICAgZm9yIG9uZSBvciBtb3JlIHVwc3RyZWFtIGNoYW5uZWxz Lg0KICAgICAgICAgICAgIEVudHJpZXMgaW4gdGhpcyB0YWJsZSBhcmUgY3JlYXRlZCBieSB0aGUg b3BlcmF0b3IuIEluaXRpYWwNCiAgICAgICAgICAgICBkZWZhdWx0IGVudHJpZXMgbWF5IGJlIGNy ZWF0ZWQgYXQgc3lzdGVtIGluaXRpYWxpemF0aW9uDQogICAgICAgICAgICAgdGltZS4gTm8gaW5k aXZpZHVhbCBvYmplY3RzIGhhdmUgdG8gYmUgc3BlY2lmaWVkIGluIG9yZGVyDQogICAgICAgICAg ICAgdG8gY3JlYXRlIGFuIGVudHJ5IGluIHRoaXMgdGFibGUuDQogICAgICAgICAgICAgTm90ZSB0 aGF0IHNvbWUgb2JqZWN0cyBkbyBub3QgaGF2ZSBERUZWQUxzLCBidXQgZG8gaGF2ZQ0KICAgICAg ICAgICAgIGNhbGN1bGF0ZWQgZGVmYXVsdHMgYW5kIG5lZWQgbm90IGJlIHNwZWNpZmllZCBkdXJp bmcgcm93DQogICAgICAgICAgICAgY3JlYXRpb24uDQogICAgICAgICAgICAgVGhlcmUgaXMgbm8g cmVzdHJpY3Rpb24gb24gdGhlIGNoYW5naW5nIG9mIHZhbHVlcyBpbiB0aGlzDQogICAgICAgICAg ICAgdGFibGUgd2hpbGUgdGhlaXIgYXNzb2NpYXRlZCByb3dzIGFyZSBhY3RpdmUgd2l0aCB0aGUg DQogICAgICAgICAgICAgZXhjZXB0aW9uIG9mOg0KICAgICAgICAgICAgIA0KICAgICAgICAgICAg IDEuICBJZiBhIG1vZHVsYXRpb24gcHJvZmlsZSBpcyBpbiB1c2UgYnkgb25lIG9yIG1vcmUgdXBz dHJlYW0gDQogICAgICAgICAgICAgICAgIGNoYW5uZWxzLCB0aGUgdmFsdWUgb2YgZG9jc0lmQ210 c01vZENoYW5uZWxUeXBlIE1VU1QgTk9UIA0KICAgICAgICAgICAgICAgICBiZSBjaGFuZ2VkDQog ICAgICAgICAgICAgMi4gIElmIGEgbW9kdWxhdGlvbiBwcm9maWxlIGlzIGluIHVzZSBieSBvbmUg b3IgbW9yZSB1cHN0cmVhbSANCiAgICAgICAgICAgICAgICAgY2hhbm5lbHMsIGl0IGRvY3NJZkNt dHNNb2RDb250cm9sIE1VU1QgTk9UIGJlIHNldCB0byANCiAgICAgICAgICAgICAgICAgJ2Rlc3Ry b3knIG9yICdub3RJblNlcnZpY2UnLiINCiAgICAgICAgSU5ERVggeyBkb2NzSWZDbXRzTW9kSW5k ZXgsIGRvY3NJZkNtdHNNb2RJbnRlcnZhbFVzYWdlQ29kZX0NCiAgICAgICAgOjo9IHsgZG9jc0lm Q210c01vZHVsYXRpb25UYWJsZSAxIH0NCg0KDQpkb2NzSWZVcENoYW5uZWxNb2R1bGF0aW9uUHJv ZmlsZSBPQkpFQ1QtVFlQRQ0KICAgICAgICBTWU5UQVggICAgICBVbnNpZ25lZDMyDQogICAgICAg IE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlDQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAg ICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJBbiBlbnRyeSBpZGVudGljYWwgdG8gdGhl IGRvY3NJZk1vZEluZGV4IGluIHRoZQ0KICAgICAgICAgICAgIGRvY3NJZkNtdHNNb2R1bGF0aW9u VGFibGUgdGhhdCBkZXNjcmliZXMgdGhpcyBjaGFubmVsLg0KICAgICAgICAgICAgIFRoaXMgY2hh bm5lbCBpcyBmdXJ0aGVyIGluc3RhbnRpYXRlZCB0aGVyZSBieSBhIGdyb3VwaW5nDQogICAgICAg ICAgICAgb2YgaW50ZXJ2YWwgdXNhZ2UgY29kZXMgKElVQ3MpIHdoaWNoIHRvZ2V0aGVyIGZ1bGx5 IGRlc2NyaWJlIA0KICAgICAgICAgICAgIHRoZSBjaGFubmVsIG1vZHVsYXRpb24uIFRoaXMgb2Jq ZWN0IHJldHVybnMgMCBpZiB0aGUNCiAgICAgICAgICAgICBkb2NzSWZDbXRzTW9kdWxhdGlvblRh YmxlIGVudHJ5IGRvZXMgbm90IGV4aXN0IG9yDQogICAgICAgICAgICAgZG9jc0lmQ210c01vZHVs YXRpb25UYWJsZSBpcyBlbXB0eS4gU2VlDQogICAgICAgICAgICAgdGhlIGFzc29jaWF0ZWQgY29u Zm9ybWFuY2Ugb2JqZWN0IGZvciB3cml0ZSBjb25kaXRpb25zDQogICAgICAgICAgICAgYW5kIGxp bWl0YXRpb25zLg0KICAgICAgICAgICAgIA0KICAgICAgICAgICAgIFNldHRpbmcgdGhpcyBvYmpl Y3QgTVVTVCByZXR1cm4gYW4gZXJyb3IgaWYgdGhlIGZvbGxvd2luZyANCiAgICAgICAgICAgICBj b25kaXRpb25zIGFyZSBub3Qgc2F0aXNmaWVkOg0KICAgICAgICAgICAgIDEuIEFsbCB0aGUgSVVD IGVudHJpZXMgaW4gdGhlIHNlbGVjdGVkIG1vZHVsYXRpb24gcHJvZmlsZSANCiAgICAgICAgICAg ICBNVVNUIGhhdmUgdGhlIHNhbWUgdmFsdWUgb2YgZG9jc0lmQ210c01vZENoYW5uZWxUeXBlLiAN CiAgICAgICAgICAgICAyLiBBbGwgb2YgdGhlIG1vZHVsYXRpb24gcGFyYW1ldGVycyBpbiB0aGUg c2VsZWN0ZWQgDQogICAgICAgICAgICAgbW9kdWxhdGlvbiBwcm9maWxlIE1VU1QgYmUgY29uc2lz dGVudCB3aXRoIHRoZSBvdGhlciANCiAgICAgICAgICAgICBwYXJhbWV0ZXJzIGluIHRoaXMgZG9j c0lmVXBDaGFubmVsRW50cnkuIA0KICAgICAgICBSRUZFUkVOQ0UNCiAgICAgICAgICAgICJEYXRh LU92ZXItQ2FibGUgU2VydmljZSBJbnRlcmZhY2UgU3BlY2lmaWNhdGlvbnM6IFJhZGlvDQogICAg ICAgICAgICAgRnJlcXVlbmN5IEludGVyZmFjZSBTcGVjaWZpY2F0aW9uIFNQLVJGSXYyLjAtSTA0 LTAzMDczMCwNCiAgICAgICAgICAgICBUYWJsZSA4LTE5LiINCiAgICAgICAgOjo9IHsgZG9jc0lm VXBzdHJlYW1DaGFubmVsRW50cnkgNCB9DQoNCmRvY3NJZlVwQ2hhbm5lbFR5cGUgT0JKRUNULVRZ UEUNCiAgICAgICAgU1lOVEFYICAgICAgRG9jc2lzVXBzdHJlYW1UeXBlDQogICAgICAgIE1BWC1B Q0NFU1MgIHJlYWQtb25seQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgIERF U0NSSVBUSU9ODQogICAgICAgICAgICAgIlJlZmxlY3RzIHRoZSBVcHN0cmVhbSBjaGFubmVsIHR5 cGUuIA0KICAgICAgICAgICAgIFRoaXMgb2JqZWN0IHJldHVybnMgdGhlIHZhbHVlIG9mIGRvY3NJ ZkNtdHNNb2RDaGFubmVsVHlwZQ0KICAgICAgICAgICAgIGZvciB0aGUgTW9kdWxhdGlvbiBQcm9m aWxlIHNlbGVjdGVkIGluIA0KICAgICAgICAgICAgIGRvY3NJZlVwQ2hhbm5lbE1vZHVsYXRpb25Q cm9maWxlIGZvciB0aGlzIHJvdy4iDQogICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgIkRh dGEtT3Zlci1DYWJsZSBTZXJ2aWNlIEludGVyZmFjZSBTcGVjaWZpY2F0aW9uczogUmFkaW8NCiAg ICAgICAgICAgICBGcmVxdWVuY3kgSW50ZXJmYWNlIFNwZWNpZmljYXRpb24gU1AtUkZJdjIuMC1J MDQtMDMwNzMwLA0KICAgICAgICAgICAgIFNlY3Rpb24gNi4yLjEuIg0KICAgICAgICA6Oj0geyBk b2NzSWZVcHN0cmVhbUNoYW5uZWxFbnRyeSAxNSB9DQogICAgICAgIA0KZG9jc0lmQ210c01vZENo YW5uZWxUeXBlICAgICAgICAgICAgICBPQkpFQ1QtVFlQRQ0KICAgICAgICBTWU5UQVggICAgICBE b2NzaXNVcHN0cmVhbVR5cGUNCiAgICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUNCiAgICAg ICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAg IkRlc2NyaWJlcyB0aGUgbW9kdWxhdGlvbiBjaGFubmVsIHR5cGUgZm9yIHRoaXMgbW9kdWxhdGlv bg0KICAgICAgICAgICAgIGVudHJ5Lg0KICAgICAgICAgICAgIEluIG9yZGVyIHRvIGJlIGNvbnNp ZGVyZWQgYSB2YWxpZCBtb2R1bGF0aW9uIHByb2ZpbGUgZm9yIA0KICAgICAgICAgICAgIGFzc2ln bm1lbnQgdG8gYW4gdXBzdHJlYW0gY2hhbm5lbCwgYWxsIGVudHJpZXMgKElVQ3MpIGluDQogICAg ICAgICAgICAgdGhlIG1vZHVsYXRpb24gcHJvZmlsZSBtdXN0IGhhdmUgdGhlIHNhbWUgY2hhbm5l bCB0eXBlLiINCiAgICAgICAgUkVGRVJFTkNFDQogICAgICAgICAgICAiRGF0YS1PdmVyLUNhYmxl IFNlcnZpY2UgSW50ZXJmYWNlIFNwZWNpZmljYXRpb25zOiBSYWRpbw0KICAgICAgICAgICAgIEZy ZXF1ZW5jeSBJbnRlcmZhY2UgU3BlY2lmaWNhdGlvbiBTUC1SRkl2Mi4wLUkwNC0wMzA3MzAsDQog ICAgICAgICAgICAgVGFibGUgOC0xOS4iDQogICAgICAgIERFRlZBTCB7IHRkbWEgfQ0KICAgICAg ICA6Oj0geyBkb2NzSWZDbXRzTW9kdWxhdGlvbkVudHJ5IDIxIH0gICAgICAgIA== ------_=_NextPart_001_01C38D21.77191F2C-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Oct 7 19:35:25 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 TAA27773 for ; Tue, 7 Oct 2003 19:35:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A71M9-00064I-98 for ipcdn-archive@odin.ietf.org; Tue, 07 Oct 2003 19:35:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97NZ54K023323 for ipcdn-archive@odin.ietf.org; Tue, 7 Oct 2003 19:35:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A71M6-00063y-Iq; Tue, 07 Oct 2003 19:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A71LQ-00063R-1E for ipcdn@optimus.ietf.org; Tue, 07 Oct 2003 19:34:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27733 for ; Tue, 7 Oct 2003 19:34:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A71LO-0005Gz-00 for ipcdn@ietf.org; Tue, 07 Oct 2003 19:34:18 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A71LN-0005Go-00 for ipcdn@ietf.org; Tue, 07 Oct 2003 19:34:17 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h97NXa10029749; Tue, 7 Oct 2003 17:33:36 -0600 (MDT) 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_01C38D2B.6DBA4366" Date: Tue, 7 Oct 2003 17:33:36 -0600 Message-ID: Thread-Topic: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcNrZOVcJIoX6N/8SlSQ6cbW5exQZwhtChQAAAOXF3A= From: "Eduardo Cardona" To: "Greg White" , , "Minnie Lu" Cc: "DOCSIS OSS Majordomo List" , , , "Minnie Lu" , X-Approved: ondar Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) 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_01C38D2B.6DBA4366 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable all IPCDN folks, =20 For the already posted issues, sometimes being silent is not always the clear way to say agree,=20 The IPCDN chairs will take the final decisions in the issues posted, so please take your time before Oct 10 to be able to hear your comments. =20 specially the Issues #13, #16 are being heavely debated, just we need concensus if they are really needed and how. # 14 is editorial and I left that for the end =20 # 23 already posted by Greg White, is being discussed in DOCSIS reflector and the MIB is just reflecting the current ECO wording in more detailed SNMP terms. =20 =20 =20 =20 Thanks =20 Eduardo =20 P.D. I will post the last issue (#14) tomorrow. =20 =20 =20 =20 =20 =20 -----Original Message----- From: Greg White=20 Sent: Tuesday, October 07, 2003 4:22 PM To: David.White@arrisi.com; Minnie Lu Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; Minnie Lu; ipcdn@ietf.org Subject: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) =09 =09 All, =20 As a final issue to resolve in the RFMIBv2 before draft-08, I would like to propose that we complete the clarification of the relationship between the ChannelType parameters in modulation profiles and upstream channels. =20 There is currently an ECO (OSS2-O-03092) written by Minnie Lu which clarifies part of the relationship by adding requirements to the OSSI spec. I would like to suggest that we propagate those requirements to the MIB descriptions. =20 =20 Also, I would like to propose that we make docsIfUpChannelType a read-only object for active rows in the Upstream Channel Table. The value reported would be taken from the modulation profile pointed to by docsIfUpChannelModulationProfile. =20 =20 Attached is a detailed proposal that Eduardo and I wrote to frame the issue. =20 In order not to delay draft-08, we would like to have consensus from the community and working group by this Friday, October 10. Please review the attached proposal and provide comments. =20 Many thanks, Greg -----Original Message----- From: David.White@arrisi.com [mailto:David.White@arrisi.com]=20 Sent: Monday, August 25, 2003 5:59 PM To: Minnie Lu Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels =09 =09 Minnie,=20 I am emphathetic to your concerns. I ran across the same issue while implementing cross-checks for the 2.0 modulation and upstream data. I found it made the code far simpler to lead the user down the path of "define the channel type first, then build everything around that" kind of configuration model. I am then able to check the settings of the other parameters against the channel type. After a modulation profile or upstream channel has already been provisioned, changing just the channel type becomes difficult, as many parameters are incompatible with other channel types. I allow it, but don't recommend it.=20 =09 My 2 cents,=20 David=20 =09 =09 =09 =09 Minnie Lu =20 08/25/2003 07:01 PM=20 =20 To: "Greg White" =20 cc: , "Minnie Lu" , , , "DOCSIS OSS Majordomo List" , "Owner DOCSIS OSS Majordomo List" =20 Fax to: =20 Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels=09 Hi, Greg, =09 Please see my response inline. Thanks a lot ! Minnie At 02:29 PM 8/25/2003 -0600, Greg White wrote: >The email exchange between Steve and Alberto notwithstanding, I think it=20 >does make sense to enforce that all entries in a modulation profile (i.e.=20 >all entries that share a common docsIfCmtsModIndex) have the same=20 >ModChannelType. Also, based on the exchange here it seems that there is=20 >some support for the additional restriction that UpChannelType and=20 >ModChannelType always match. With those two restrictions, there clearly=20 >is a need for all defined values of ModChannelType. > >Since this has been a point of confusion at least twice now, does anyone=20 >have a concern with making these two items part of the specification? > =09 [milu]: I agree with you. =09 >A further point, how does the CMTS enforce the match between UpChannelType=20 >and ModChannelType? One implementation may automatically change=20 >UpChannelType to match ModChannelType whenever=20 >docsIfUpChannelModulationProfile is set. Another might reject the change=20 >if the two don't already match, and require the use of the=20 >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd argue=20 >that the first implementation makes more sense, and ought to be made a=20 >SHOULD in the spec, but I'd like to hear other views. > =09 [milu]: I think this needs to be thought over carefully. How about the=20 case that some modulation profile is used by some upstream channel, and=20 user change the modulation profile channel type ? Does it mean that the=20 upstream channel type would be changed automatically, too ? If yes, I am=20 afraid that there might be some user who forget the modulation profile is=20 being used and change the channel type without knowing the upstream channel=20 type for some upstream channels are changed at the same time. The=20 modulation profile channel type and upstream channel type are in two=20 different MIB tables. =09 Actually, I am always puzzled when the modulation profile is being used=20 by some upstream channels, could the modulation profile channel type be=20 changed ? Maybe this is a confusing point which needs to be clarified, too. =09 Thanks a lot for your help ! Minnie =09 =09 =09 >-Greg >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Monday, August 25, 2003 11:07 AM >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner DOCSIS=20 >OSS Majordomo List >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to=20 >upstream channels > >Minnie, > Sounds good to me. This would make verifying the consistency of=20 > the data in the modulation profiles and the upstream channels far easier. >So, if I understand correctly, this means that all modulation profile=20 >entries with the same docsIfCmtsModIndex will have to have the same=20 >docsIfCmtsModChannelType. Otherwise, you would not be able to use that=20 >modulation profile set on any upstream channel. So, this modulation=20 >profile set with different docsIfCmtsModChannelTypes from an e-mail thread=20 >between Alberto and Steve from almost a year ago would be invalid, no ?=20 >The way to patch it up would be to make all of the IUCs tdmaAndAtdma,=20 >correct ? > >Thanks, >David > >--- end David's e-mail --- >--- start e-mail exchange between Alberto and Steve --- > >Hi Steve > >Sorry for the delay in responding > >Your configuration settings for operation in multiple mode is correct and=20 >will support tdma, tdmaAndAtdma and Atdma. >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with UCD=20 >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and IUCs=20 >5&6 are not used. Your interpretation of the spec in the example described=20 >is accurate. > >Alberto Campos >a.campos@cablelabs.com > > > > > >-----Original Message----- >From: Steve Malenfant [mailto:smalenfant@com21.com] >Sent: Monday, September 30, 2002 9:39 AM >To: 'docsis-20@cablelabs.com' >Subject: Correlation between docsIfUpChannelType and >docsIfCmtsModChannelT ype > > > >We are having some discussion internally here, and would like to clarify >things about the modulation profile. >Let's take an example, expecting all parameters are good : > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. >set IUC 5 docsIfCmtsModChannelType to tdma. >set IUC 6 docsIfCmtsModChannelType to tdma. >set IUC 9 docsIfCmtsModChannelType to Atdma. >set IUC 10 docsIfCmtsModChannelType to Atdma. > >Would this burst profile be good for docsIfUpChannelType tdma, tdmaAndAtdma >and Atdma? > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 inside >UCD type 2. >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. > > > > > >Minnie Lu >Sent by: owner-docsis-oss@cablelabs.com > >08/21/2003 07:15 PM > > To: David.White@arrisi.com, "Greg White"=20 > > cc: "DOCSIS OSS Majordomo List"=20 > , milu@cisco.com > Fax to: > Subject: RE: DOCSIS 2.0 : rules for assigning modulation=20 > profiles to upstream channels > > > > > >Hi, David and Greg, > > I like Greg's "Perhaps it is simpler just to require that ModChannelType >match UpChannelType.". > > I don't think that "we could just drop tdmaAndAtdma for >ModChannelType". Please keep in mind that when assigning the modulation >profile to some upstream via SNMP docsIfUpChannelModulationProfile, it uses >only the docsIfModIndex and only one docsIfModIndex can be assigned to some >upstream channel. > > If I miss anything, please correct me. > Thanks! > Minnie > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > >Greg, > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma channels. > > However, the modulation profiles objects > > docsIfCmtsModByteInterleaverBlockSize and > > docsIfCmtsModByteInterleaverDepth are only valid for atdma channels. So, > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these objects set, > > it assumably could not be used on a tdma-only upstream channel. Hence, > > the whole purpose of even having ModChannelType - to verify consistency > > within the modulation profile - is weakened. This has the unintended side > > effect of requiring any assignment of modulation profiles with IUCs 1, 2, > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see if the > > Interleaver parameters have been set before assigning it to a tdma-only > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation=20 > profiles.=20 > > I can't think of any need/requirement for tdmaAndAtdma for > > modulation profiles that could not be met with a pair of tdma and atdma > > modulation profile. In other words, I don't think allowing tdmaAndAtdma > > for ModChannelType really buys us anything. I'm thinking we could just > > drop tdmaAndAtdma for ModChannelType (making it a > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of confusion. > > For the mixed-mode channels, where UpChannelType is tdmaAndAtdma, > > the modulation profile set could look like so: > > > >IUC 1 tdma > >IUC 2 tdma > >IUC 3 tdma > >IUC 4 tdma > >IUC 5 tdma > >IUC 6 tdma > >IUC 9 atdma > >IUC 10 atdma > >IUC 11 atdma > > > >For tdma-only upstream channels, the modulation profile set could be: > > > >IUC 1 tdma > >IUC 2 tdma > >IUC 3 tdma > >IUC 4 tdma > >IUC 5 tdma > >IUC 6 tdma > > > >Likewise, for atdma-only upstream channel, the modulation profile set > >could be: > > > >IUC 1 atdma > >IUC 2 atdma > >IUC 3 atdma > >IUC 4 atdma > >IUC 9 atdma > >IUC 10 atdma > >IUC 11 atdma > > > >As far as I know, there is no hard limit on the number of the modulation > >profile sets that the CMTS and CM can support. I'm really liking your "not > >sure the benefits of flexibility outweigh disadvantages..." line of > >thinking. tdmaAndAtdma for modulation profiles has my head spinning. > > > >Thanks, > >David > > > > > > > >"Greg White" > >Sent by: owner-docsis-oss@cablelabs.com > > > >08/20/2003 07:35 PM > > > > To: , "DOCSIS OSS Majordomo List" > > > > cc: > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning modulation > > profiles to upstream channels > > > > > >David, > > > >I agree with all of your clearly legal/illegal combinations. Among the > >four that cause you consternation, I would break them done like this: > > > >illegal: > >tdma, atdma > >atdma, tdma > > > >potentially legal: > >tdma, tdmaAndAtdma > >atdma, tdmaAndAtdma > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and possibly 11, > >so cannot be used for a tdma channel. Similarly a tdma modulation profile > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma channel. > > > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10, and > >possibly 11, so could potentially be used for a tdma or an atdma channel > >(in addition to a tdmaAndAtdma channel), as long as the CMTS ignored the > >IUCs that don't apply to the channel type. I'm not sure that the > >advantages of that flexibility outweigh the disadvantages of having the > >MIB reporting something that doesn't exactly reflect what is > >configured. Perhaps it is simpler just to require that ModChannelType > >match UpChannelType. > > > >-Greg > > > > > > ----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Tuesday, August 19, 2003 9:37 AM > >To: DOCSIS OSS Majordomo List > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to upstream > >channels > > > > > >DOCSIS 2.0 Community, > > It seems that the DocsisUpstreamType objects in both the > > modulation profile table and the upstream channel table exist, in part, > > to provide the equipment vendor a way to cross-check the data for > > consistency. Furthermore, it would seem possible to compare the two > > DocsisUpstreamType objects when assigning an upstream to a modulation > > profile to make sure the assignment is compatible. For instance, the > > following combination of docsIfUpChannelType, docsIfCmtsModChannelType > > would clearly be illegal: > > > >scdma, tdma > >scdma, atdma > >scdma, tdmaAndAtdma > > > >tdma, scdma > >atdma, scdma > >tdmaAndAtdma, scdma > > > > > >It is also pretty clear the following are legal: > > > >tdma, tdma > >atdma, atdma > >scdma, scdma=20 > >tdmaAndAtdma, tdmaAndAtdma > > > > > >However, it is the following cases that are causing me consternation: > > > >tdma, atdma > >tdma, tdmaAndAtdma > >atdma, tdma > >atdma, tdmaAndAtdma > > > > > >If ALL of these are legal, then I do not understand the point of > >tdmaAndAtdma, other than to cause confusion, especially for modulation > >profiles. > > > >Thanks, > >David White > >ARRIS Cadant C4 CMTS > =09 =09 =09 =09 ------_=_NextPart_001_01C38D2B.6DBA4366 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
all=20 IPCDN folks,
 
For=20 the already posted issues, sometimes being silent is not always  = the clear=20 way to say agree, 
The=20 IPCDN chairs will take the final decisions in the issues posted, so = please=20 take your time before Oct 10 to be able to hear your=20 comments.
 
specially the Issues #13, #16 are being heavely debated, just = we need=20 concensus if they are really needed and how.
# 14=20 is editorial and I left that for the end
 
# 23=20 already posted by Greg White, is being discussed in DOCSIS reflector and = the MIB=20 is just reflecting the current ECO wording in more detailed SNMP=20 terms.
 
 
 
 
Thanks
 
Eduardo
 
P.D. I=20 will post the last issue (#14) tomorrow.
 
 
 
 
 
 
-----Original Message-----
From: Greg = White=20
Sent: Tuesday, October 07, 2003 4:22 PM
To:=20 David.White@arrisi.com; Minnie Lu
Cc: DOCSIS OSS Majordomo = List;=20 Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; Minnie Lu;=20 ipcdn@ietf.org
Subject: Channel Types in RFMIBv2 (was RE: = DOCSIS 2.0=20 : rules for assigning modulation profiles to upstream=20 channels)

All,
 
As a=20 final issue to resolve in the RFMIBv2 before draft-08, I would like to = propose=20 that we complete the clarification of the relationship between the = ChannelType=20 parameters in modulation profiles and upstream=20 channels.
 
There is currently an ECO (OSS2-O-03092) = written by=20 Minnie Lu which clarifies part of the relationship by adding = requirements to=20 the OSSI spec.  I would like to suggest that we propagate those=20 requirements to the MIB descriptions. 
 
Also, I would like to propose that we make=20 docsIfUpChannelType a read-only object for active rows in the Upstream = Channel=20 Table.  The value reported would be taken from the modulation = profile=20 pointed to by docsIfUpChannelModulationProfile.  =
 
Attached is a detailed proposal that = Eduardo and I=20 wrote to frame the issue.
 
In=20 order not to delay draft-08, we would like to have consensus from the=20 community and working group by this Friday, October 10.  Please = review=20 the attached proposal and provide comments.
 
Many=20 thanks,
Greg
-----Original Message-----
From:=20 David.White@arrisi.com [mailto:David.White@arrisi.com] =
Sent:=20 Monday, August 25, 2003 5:59 PM
To: Minnie = Lu
Cc: DOCSIS=20 OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White;=20 Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo=20 List
Subject: RE: DOCSIS 2.0 : rules for assigning = modulation=20 profiles to upstream channels


Minnie,
  =    =20   I am emphathetic to your concerns. I ran across the same = issue while=20 implementing cross-checks for the 2.0 modulation and upstream data. = I found=20 it made the code far simpler to lead the user down the path of = "define the=20 channel type first, then build everything around that" kind of = configuration=20 model. I am then able to check the settings of the other parameters = against=20 the channel type. After a modulation profile or upstream channel has = already=20 been provisioned, changing just the channel type becomes difficult, = as many=20 parameters are incompatible with other channel types. I allow it, = but don't=20 recommend it.

My 2 = cents,=20
David



Minnie Lu=20 <milu@cisco.com>=20

08/25/2003 07:01 PM =

       =20
    =    =20 To:        "Greg White"=20 <g.white@CableLabs.com>
        cc:      =20  <David.White@arrisi.com>, "Minnie Lu"=20 <milu@cisco.com>, <Greg.Gohman@arrisi.com>,=20 <Larry.Spaete@arrisi.com>, "DOCSIS OSS Majordomo List"=20 <docsis-oss@CableLabs.com>, "Owner DOCSIS OSS Majordomo = List"=20 <owner-docsis-oss@CableLabs.com>
        Fax to: =  =20      
 =20       Subject:        RE: = DOCSIS=20 2.0 : rules for assigning modulation profiles to   = upstream=20 channels



Hi, Greg,

 Please see my = response=20 inline.
 Thanks a lot !
 Minnie
At 02:29 PM = 8/25/2003=20 -0600, Greg White wrote:
>The email exchange between Steve and = Alberto=20 notwithstanding, I think it
>does make sense to enforce that = all=20 entries in a modulation profile (i.e.
>all entries that share = a=20 common docsIfCmtsModIndex) have the same
>ModChannelType. =  Also,=20 based on the exchange here it seems that there is
>some = support for=20 the additional restriction that UpChannelType and =
>ModChannelType=20 always match.  With those two restrictions, there clearly =
>is a=20 need for all defined values of ModChannelType.
>
>Since = this has=20 been a point of confusion at least twice now, does anyone =
>have a=20 concern with making these two items part of the=20 specification?
>

[milu]: I agree with you.

>A = further=20 point, how does the CMTS enforce the match between UpChannelType =
>and=20 ModChannelType?  One implementation may automatically change=20
>UpChannelType to match ModChannelType whenever=20
>docsIfUpChannelModulationProfile is set.  Another might = reject=20 the change
>if the two don't already match, and require the = use of=20 the
>docsIfUpChannelCloneFrom mechanism to change the channel = type.=20  I'd argue
>that the first implementation makes more = sense, and=20 ought to be made a
>SHOULD in the spec, but I'd like to hear = other=20 views.
>

[milu]: I think this needs to be thought over=20 carefully.  How about the
case that some modulation profile = is used=20 by some upstream channel, and
user change the modulation profile = channel=20 type ?  Does it mean that  the
upstream channel type = would be=20 changed automatically, too ?  If yes, I am
afraid that = there might=20 be some user who forget the modulation profile is
being used and = change=20 the channel type without knowing the upstream channel
type for = some=20 upstream channels are changed at the same time.  The =
modulation=20 profile channel type and upstream channel type are in two =
different MIB=20 tables.

  Actually, I am always puzzled when the = modulation=20 profile is being used
by some upstream channels, could the = modulation=20 profile channel type be
changed ?  Maybe this is a = confusing point=20 which needs to be clarified, too.

  Thanks a lot for = your help=20 !
  Minnie



>-Greg
>-----Original=20 Message-----
>From: David.White@arrisi.com=20 [mailto:David.White@arrisi.com]
>Sent: Monday, August 25, 2003 = 11:07=20 AM
>To: Minnie Lu; Greg.Gohman@arrisi.com;=20 Larry.Spaete@arrisi.com
>Cc: DOCSIS OSS Majordomo List; Greg = White;=20 milu@cisco.com; Owner DOCSIS
>OSS Majordomo = List
>Subject: RE:=20 DOCSIS 2.0 : rules for assigning modulation profiles to =
>upstream=20 channels
>
>Minnie,
>         = Sounds=20 good to me. This would make verifying the consistency of =
> the data in the modulation = profiles and the=20 upstream channels far easier.
>So, if I understand correctly, = this=20 means that all modulation profile
>entries with the same=20 docsIfCmtsModIndex will have to have the same=20
>docsIfCmtsModChannelType. Otherwise, you would not be able = to use=20 that
>modulation profile set on any upstream channel. So, = this=20 modulation
>profile set with different = docsIfCmtsModChannelTypes from=20 an e-mail thread
>between Alberto and Steve from almost a = year ago=20 would be invalid, no ?
>The way to patch it up would be to = make all=20 of the IUCs tdmaAndAtdma,
>correct=20 ?
>
>Thanks,
>David
>
>--- end David's = e-mail=20 ---
>--- start e-mail exchange between Alberto and Steve=20 ---
>
>Hi Steve
>
>Sorry for the delay in=20 responding
>
>Your configuration settings for operation = in=20 multiple mode is correct and
>will support tdma, tdmaAndAtdma = and=20 Atdma.
>In tdma only IUCs 9&10 are not used. In mixed mode = TLV 5=20 is used with UCD
>type 2 and in DOCSIS 2.0 only case TLV 5 is = used=20 with UCD type 29 and IUCs
>5&6 are not used. Your = interpretation=20 of the spec in the example described
>is=20 accurate.
>
>Alberto=20 = Campos
>a.campos@cablelabs.com
>
>
>
>
&= gt;
>-----Original=20 Message-----
>From: Steve Malenfant=20 [mailto:smalenfant@com21.com]
>Sent: Monday, September 30, = 2002 9:39=20 AM
>To: 'docsis-20@cablelabs.com'
>Subject: Correlation = between=20 docsIfUpChannelType and
>docsIfCmtsModChannelT=20 ype
>
>
>
>We are having some discussion = internally=20 here, and would like to clarify
>things about the modulation=20 profile.
>Let's take an example, expecting all parameters are = good=20 :
>
>set IUC 1 docsIfCmtsModChannelType to=20 tdmaAndAtdma.
>set IUC 3 docsIfCmtsModChannelType to=20 tdmaAndAtdma.
>set IUC 4 docsIfCmtsModChannelType to=20 tdmaAndAtdma.
>set IUC 5 docsIfCmtsModChannelType to = tdma.
>set=20 IUC 6 docsIfCmtsModChannelType to tdma.
>set IUC 9=20 docsIfCmtsModChannelType to Atdma.
>set IUC 10=20 docsIfCmtsModChannelType to Atdma.
>
>Would this burst = profile=20 be good for docsIfUpChannelType tdma, tdmaAndAtdma
>and=20 Atdma?
>
>tdma would only use IUC 1,3,4,5 and 6 in TLV 4 = inside=20 UCD type 2.
>mixed would use IUC 1,3,4,5 and 6 in TLV 4 and = IUC 9 and=20 10 in TLV 5 inside
>UCD type 2.
>Atdma would only use = IUC=20 1,3,4,9 and 10 in TLV 5 inside UCD type=20 29.
>
>
>
>
>
>Minnie Lu=20 <milu@cisco.com>
>Sent by:=20 owner-docsis-oss@cablelabs.com
>
>08/21/2003 07:15=20 PM
>
>         To:     =  =20  David.White@arrisi.com, "Greg White"
>=20 <g.white@cablelabs.com>
>         = cc:  =20      "DOCSIS OSS Majordomo List"
>=20 <docsis-oss@cablelabs.com>, milu@cisco.com
>   =  =20     Fax to:
>         Subject: =  =20      RE: DOCSIS 2.0 : rules for assigning modulation =
>=20 profiles to  upstream=20 channels
>
>
>
>
>
>Hi, David = and=20 Greg,
>
>  I like Greg's "Perhaps it is simpler = just to=20 require that ModChannelType
>match = UpChannelType.".
>
>=20  I don't think that "we could just drop tdmaAndAtdma=20 for
>ModChannelType".  Please keep in mind that when = assigning=20 the modulation
>profile to some upstream via SNMP=20 docsIfUpChannelModulationProfile, it uses
>only the = docsIfModIndex and=20 only one docsIfModIndex can be assigned to some
>upstream=20 channel.
>
>  If I miss anything, please correct=20 me.
>  Thanks!
>  Minnie
>
>At = 10:53 AM=20 8/21/2003 -0400, David.White@arrisi.com wrote:
>
>=20 >Greg,
> >         IUCs 1, 2, 3, and = 4 are=20 used for both tdma and atdma channels.
> > However, the = modulation=20 profiles objects
> > docsIfCmtsModByteInterleaverBlockSize=20 and
> > docsIfCmtsModByteInterleaverDepth are only valid = for atdma=20 channels. So,
> > if a modulation profile with IUCs 1, 2, 3 = and/or=20 4 had these objects set,
> > it assumably could not be used = on a=20 tdma-only upstream channel. Hence,
> > the whole purpose of = even=20 having ModChannelType - to verify consistency
> > within = the=20 modulation profile - is weakened. This has the unintended = side
> >=20 effect of requiring any assignment of modulation profiles with IUCs = 1,=20 2,
> > 3, and 4 and ModChannelType equal to tdmaAndAtdma to = check=20 to see if the
> > Interleaver parameters have been set = before=20 assigning it to a tdma-only
> > upstream channel. Hence, my = gripe=20 with tdmaAndAtdma for modulation
> profiles.
> >         = I can't=20 think of any need/requirement for tdmaAndAtdma for
> > = modulation=20 profiles that could not be met with a pair of tdma and atdma
> = >=20 modulation profile. In other words, I don't think allowing=20 tdmaAndAtdma
> > for ModChannelType really buys us = anything. I'm=20 thinking we could just
> > drop tdmaAndAtdma for = ModChannelType=20 (making it a
> > DocsisUpstreamTypeStatus object, perhaps = ?) to=20 avoid a lot of confusion.
> >         = For the=20 mixed-mode channels, where UpChannelType is tdmaAndAtdma,
> = > the=20 modulation profile set could look like so:
> >
> = >IUC=20  1  tdma
> >IUC  2  tdma
> = >IUC=20  3  tdma
> >IUC  4  tdma
> = >IUC=20  5  tdma
> >IUC  6  tdma
> = >IUC=20  9 atdma
> >IUC 10 atdma
> >IUC 11 = atdma
>=20 >
> >For tdma-only upstream channels, the modulation = profile set=20 could be:
> >
> >IUC 1 tdma
> >IUC 2 = tdma
>=20 >IUC 3 tdma
> >IUC 4 tdma
> >IUC 5 tdma
> = >IUC=20 6 tdma
> >
> >Likewise, for atdma-only upstream = channel,=20 the modulation profile set
> >could be:
> = >
>=20 >IUC  1 atdma
> >IUC  2 atdma
> >IUC =  3=20 atdma
> >IUC  4 atdma
> >IUC  9 = atdma
>=20 >IUC 10 atdma
> >IUC 11 atdma
> >
> = >As far as=20 I know, there is no hard limit on the number of the = modulation
>=20 >profile sets that the CMTS and CM can support. I'm really liking = your=20 "not
> >sure the benefits of flexibility outweigh = disadvantages..."=20 line of
> >thinking. tdmaAndAtdma for modulation profiles = has my=20 head spinning.
> >
> >Thanks,
> = >David
>=20 >
> >
> >
> >"Greg White"=20 <g.white@cablelabs.com>
> >Sent by:=20 owner-docsis-oss@cablelabs.com
> >
> >08/20/2003 = 07:35=20 PM
> >
> >         To:   =  =20    <David.White@arrisi.com>, "DOCSIS OSS Majordomo=20 List"
> > <docsis-oss@cablelabs.com>
> > =  =20       cc:
> >         = Fax=20 to:
> >         Subject:     =  =20  RE: DOCSIS 2.0 : rules for assigning modulation
> > = profiles=20 to upstream channels
> >
> >
> = >David,
>=20 >
> >I agree with all of your clearly legal/illegal=20 combinations.  Among the
> >four that cause you = consternation,=20 I would break them done like this:
> >
> = >illegal:
>=20 >tdma, atdma
> >atdma, tdma
> >
> = >potentially=20 legal:
> >tdma, tdmaAndAtdma
> >atdma,=20 tdmaAndAtdma
> >
> >An atdma modulation profile = will=20 include IUCs 1,3,4,9,10, and possibly 11,
> >so cannot be = used for=20 a tdma channel. Similarly a tdma modulation profile
> >will = include=20 IUCs 1,3,4,5,6, so cannot be used for an atdma channel.
> = >
>=20 >A tdmaAndAtdma modulation profile will include IUCs = 1,3,4,5,6,9,10,=20 and
> >possibly 11, so could potentially be used for a tdma = or an=20 atdma channel
> >(in addition to a tdmaAndAtdma channel), = as long=20 as the CMTS ignored the
> >IUCs that don't apply to the = channel=20 type.  I'm not sure that the
> >advantages of that = flexibility=20 outweigh the disadvantages of having the
> >MIB reporting = something=20 that doesn't exactly reflect what is
> >configured. =  Perhaps=20 it is simpler just to require that ModChannelType
> >match=20 UpChannelType.
> >
> >-Greg
> >
>=20 >
> >  ----Original Message-----
> >From:=20 David.White@arrisi.com [mailto:David.White@arrisi.com]
> = >Sent:=20 Tuesday, August 19, 2003 9:37 AM
> >To: DOCSIS OSS = Majordomo=20 List
> >Subject: DOCSIS 2.0 : rules for assigning = modulation=20 profiles to upstream
> >channels
> >
> = >
>=20 >DOCSIS 2.0 Community,
> >        It = seems=20 that the DocsisUpstreamType objects in both the
> > = modulation=20 profile table and the upstream channel table exist, in part,
> = > to=20 provide the equipment vendor a way to cross-check the data = for
> >=20 consistency. Furthermore, it would seem possible to compare the = two
>=20 > DocsisUpstreamType objects when assigning an upstream to a=20 modulation
> > profile to make sure the assignment is = compatible.=20 For instance, the
> > following combination of = docsIfUpChannelType,=20 docsIfCmtsModChannelType
> > would clearly be = illegal:
>=20 >
> >scdma, tdma
> >scdma, atdma
> = >scdma,=20 tdmaAndAtdma
> >
> >tdma, scdma
> >atdma, = scdma
> >tdmaAndAtdma, scdma
> >
> = >
>=20 >It is also pretty clear the following are legal:
> = >
>=20 >tdma, tdma
> >atdma, atdma
> >scdma, = scdma=20
> >tdmaAndAtdma,=20 tdmaAndAtdma
> >
> >
> >However, it is = the=20 following cases that are causing me consternation:
> = >
>=20 >tdma, atdma
> >tdma, tdmaAndAtdma
> >atdma,=20 tdma
> >atdma, tdmaAndAtdma
> >
> = >
>=20 >If ALL of these are legal, then I do not understand the point = of
>=20 >tdmaAndAtdma, other than to cause confusion, especially for=20 modulation
> >profiles.
> >
> = >Thanks,
>=20 >David White
> >ARRIS Cadant C4=20 = CMTS
>



=00 ------_=_NextPart_001_01C38D2B.6DBA4366-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Oct 8 12:28:27 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 MAA26224 for ; Wed, 8 Oct 2003 12:28:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7HAT-0000OM-8v for ipcdn-archive@odin.ietf.org; Wed, 08 Oct 2003 12:28:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98GS5Zv001500 for ipcdn-archive@odin.ietf.org; Wed, 8 Oct 2003 12:28:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7HAP-0000Nm-2F; Wed, 08 Oct 2003 12:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7H9T-0000Ib-0y for ipcdn@optimus.ietf.org; Wed, 08 Oct 2003 12:27:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26166 for ; Wed, 8 Oct 2003 12:26:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7H9R-0000hn-00 for ipcdn@ietf.org; Wed, 08 Oct 2003 12:27:01 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1A7H9Q-0000hY-00 for ipcdn@ietf.org; Wed, 08 Oct 2003 12:27:00 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h98GR0C7026422 for ; Wed, 8 Oct 2003 09:27:00 -0700 (MST) Received: from ma07exm01.e6.bcs.mot.com (ma07exm01.e6.bcs.mot.com [10.14.33.191]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h98GQswA006549 for ; Wed, 8 Oct 2003 11:26:56 -0500 Received: by ma07exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.2) id <42T69KGA>; Wed, 8 Oct 2003 12:26:38 -0400 Message-ID: <19CD0E423FC1D611893500508B6F0B9CF3983F@ma07exm01.e6.bcs.mot.com> From: Murwin William-LWM008 To: "'Eduardo Cardona'" , "IPCDN (E-mail) (E-mail)" Cc: "Michael W. Patrick (E-mail)" , Minnie Lu , Jean-Francois Mule , Richard_Woundy@cable.comcast.com Date: Wed, 8 Oct 2003 12:26:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Subject: [ipcdn] RE: sid counter inconsistent between draft-ietf-ipcdn-qos-mib-08. txt and DOCS-IF-MIB ? 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: , Eduardo, (1) I am not sure if the QOS MIB is allowed to change [10] to be RFI v2 MIB. [10] currently references RFC2670 RF-MIB, which is still applicable, because RF-MIBv2 has to maintain backward compatiblity with RFC2670. The ietf draft guideline specifically say that: " It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."" http://www.ietf.org/ietf/1id-guidelines.txt Also according to RFC2026: ******************************************************** * * * Under no circumstances should an Internet-Draft * * be referenced by any paper, report, or Request- * * for-Proposal, nor should a vendor claim compliance * * with an Internet-Draft. * * * ******************************************************** Note: It is acceptable to reference a standards-track specification that may reasonably be expected to be published as an RFC using the phrase "Work in Progress" without referencing an Internet-Draft. This may also be done in a standards track document itself as long as the specification in which the reference is made would stand as a complete and understandable document with or without the reference to the "Work in Progress". To me this means the RF-MIB v2 would have to be published as another document an we could cite that within the QOS-MIB. Rich, do you know if it is acceptable to cite another "ietf-draft" and if their are examples of this within other "ietf-drafts"? I will address your other questions in a email to come Will Murwin -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] Sent: Wednesday, October 08, 2003 11:08 AM To: Murwin William-LWM008 Cc: Michael W. Patrick (E-mail); Minnie Lu; Jean-Francois Mule; Richard_Woundy@cable.comcast.com Subject: RE: sid counter inconsistent between draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ? Hi William, Minnie, Rich, Before complete issue#14 for discussion, Could you please review my assupmtions for the cross- RFI/QOS MIB interoperability issue#14 attached document? I have some concerns ( no comments still for item #13 Counters in/out CmtsCmStatusTable as you proposed and I relauched with Q to solve by Ipcdn participants thinking in the operational environment for 1-2 years ahead. Also how it is adjustable with already propietary methods supported supported, ( they migth and will stay there... Since we do not have resolution for #13 yet, and for keeping some sort of legacy support ( Minnie Lu comments ), I do not know for sure if those restrictions are useful right now due the divergency in current implementations. I like the cleanest as possible solution ( starting from William already wrote Qos interoperability section, but I don't know its possible impacts in the field applications or if handle the exceptions/violation out of specification /Qualification for MSOs considerations Thanks Eduardo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Tuesday, October 07, 2003 10:23 AM To: Eduardo Cardona Cc: Michael W. Patrick (E-mail); Minnie Lu; Jean-Francois Mule; Richard_Woundy@cable.comcast.com Subject: RE: sid counter inconsistent between draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ? Yes item 5 from section 2.2.2.1 has been removed -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] Sent: Tuesday, October 07, 2003 12:02 PM To: Murwin William-LWM008 Cc: Michael W. Patrick (E-mail); Minnie Lu; Jean-Francois Mule; Richard_Woundy@cable.comcast.com Subject: RE: sid counter inconsistent between draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ? Hi William, Just to confirm that you are planning to delete only the item 5 in 2.2.2.1 for the coming draft-ietf-ipcdn-qos-mib-09.txt I will propose a similar wording and section in the RFI v2 mib and any extra information you have will be very valuable Thanks Eduardo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Tuesday, May 06, 2003 1:23 PM To: 'Minnie Lu'; Richard_Woundy@cable.comcast.com; DOCSIS OSS Majordomo List; IPCDN (E-mail) (E-mail) Cc: Michael W. Patrick (E-mail); David Raftus (E-mail) Subject: RE: sid counter inconsistent between draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ? Minnie, After much consideration, DOCSIS QOS MIB version 9 will remove the text from section Section 2.2.2.1 Interoperation with DOCSIS 1.0: 5. At the CMTS, the Docsis 1.0 MIB objects docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets for a SID assigned to a Docsis 1.1 or Docsis 2.0 modem count only the pre-registration packets/bytes of those modems." This is not an issue for the QOS MIB. The QOS MIB tried to handle DOCSIS 1.1 changes to RFC2670. Now that rfc2670 is being obsoleted, the rf-mib v2 and the DOCSIS OSS Specs is the place that should clearly state how these counters and other tables interact in DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0. I would even hope to see a section in the rf-mib v2, "Interoperation with the version of DOCSIS" like or to replace what the DOCSIS QOS MIB has. This is the place to describe what table are populated under the docsIfMib when the the modems are registering. This way this issue can be re-discussed and whatever conculsion is reached, can be document in the description of those objects. Sincerely, Will Murwin -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com] Sent: Thursday, March 20, 2003 4:16 PM To: Richard_Woundy@cable.comcast.com; docsis-oss@cablelabs.com Cc: milu@cisco.com Subject: sid counter inconsistent between draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ? Hi, Since I have not yet got any reason for the sid counter inconsistence, I would like to raise this issue again and hope this time, people will reconsider it. In draft-ietf-ipcdn-qos-mib-08.txt, 1. Section 2.2.2.1 Interoperation with DOCSIS 1.0 "5. At the CMTS, the Docsis 1.0 MIB objects docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets for a SID assigned to a Docsis 1.1 or Docsis 2.0 modem count only the pre-registration packets/bytes of those modems." Maybe I miss some discussion before. If there was some discussion before, please excuse me to bring this up again because I really don't understand why this is necessary to enforce this rule. SID concept is still applicable to DOCSIS1.1 or 2.0. The MIB objects docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets definitions look good to me even for DOCSIS1.1 or 2.0. docsIfCmtsServiceInOctets OBJECT-TYPE "The cumulative number of Packet Data octets received on this Service ID. The count does not include the size of the Cable MAC header" docsIfCmtsServiceInPackets OBJECT-TYPE "The cumulative number of Packet Data packets received on this Service ID." From the description, it seems to me that they will count all the traffic including pre-registration and post-registration received on this Service ID no matter that this Service ID associates with DOCSIS1.0 or DOCSIS1.1 or DOCSIS2.0 CMs. So they are consistent for various version of CMs mode. Also, in the same section, item 3 . "The docsIfCmServiceTable row for the DOCSIS 1.1 or DOCSIS 2.0 modem continues to exist, and the various statistic objects in that row are incremented." It sounds to me the item 4 is inconsistent with item 3 above. For the same MIB object, it counts differently in CM and CMTS for the SIDs associated with DOCSIS1.1 CMs. I think it is good to keep CM and CMTS the same as described in item 3. Also when customer queries the docsIfCmtsServiceTable, the customer might wonder why some entries have low count and not aware of they are for the SID belongs to CM in DOCSIS1.1 mode. I noticed this is not in version 4. From v5, it starts having such statements. Thanks ! Minnie _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Oct 8 14:01:25 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 OAA29958 for ; Wed, 8 Oct 2003 14:01:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IcQ-00077Q-AX for ipcdn-archive@odin.ietf.org; Wed, 08 Oct 2003 14:01:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98I12HG027353 for ipcdn-archive@odin.ietf.org; Wed, 8 Oct 2003 14:01:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IcP-00076a-Jp; Wed, 08 Oct 2003 14:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Ibj-00073k-3z for ipcdn@optimus.ietf.org; Wed, 08 Oct 2003 14:00:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29910 for ; Wed, 8 Oct 2003 14:00:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Ibg-0001y5-00 for ipcdn@ietf.org; Wed, 08 Oct 2003 14:00:16 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A7Ibf-0001xC-00 for ipcdn@ietf.org; Wed, 08 Oct 2003 14:00:15 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h98HxH12020936; Wed, 8 Oct 2003 11:59:19 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Oct 2003 11:59:18 -0600 Message-ID: Thread-Topic: sid counter inconsistent between draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ? Thread-Index: AcONuQVPDPrksp5zSZGn/aebAJhI7gADFmyg From: "Eduardo Cardona" To: "Murwin William-LWM008" , "IPCDN (E-mail) (E-mail)" Cc: "Michael W. Patrick (E-mail)" , "Minnie Lu" , "Jean-Francois Mule" , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: sid counter inconsistent between draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ? 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 William, I could be not clear on that,=20 Look at BPI draft 11 a note added by Jean-Francois added [RFC3291] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, =20 J., "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002.=20 =20 ************************************************************=20 * NOTES TO RFC Editor (to be removed prior to publication) *=20 * *=20 * 1.) The I-D (or a *=20 * successor) is expected to eventually replace RFC 3291. *=20 * If that draft (or a successor) is published as an RFC *=20 * prior to or concurrently with this document, then the *=20 * normative reference [RFC3291] should be updated to *=20 * point to the replacement RFC, and the reference tag *=20 * [RFC3291] should be updated to match. *=20 * *=20 ************************************************************=20 =20 [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An=20 Architecture for Describing Simple Network Management =20 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,=20 December 2002.=20 Thanks Eduardo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com]=20 Sent: Wednesday, October 08, 2003 10:26 AM To: Eduardo Cardona; IPCDN (E-mail) (E-mail) Cc: Michael W. Patrick (E-mail); Minnie Lu; Jean-Francois Mule; Richard_Woundy@cable.comcast.com Subject: RE: sid counter inconsistent between draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ? Eduardo, (1) I am not sure if the QOS MIB is allowed to change [10] to be RFI v2 MIB.=20 [10] currently references RFC2670 RF-MIB, which is still applicable, because RF-MIBv2 has to maintain backward compatiblity with RFC2670. The ietf draft guideline specifically say that: " It is inappropriate=20 to use Internet-Drafts as reference material or to cite them other than as "work in progress."" http://www.ietf.org/ietf/1id-guidelines.txt Also according to RFC2026: ******************************************************** * * * Under no circumstances should an Internet-Draft * * be referenced by any paper, report, or Request- * * for-Proposal, nor should a vendor claim compliance * * with an Internet-Draft. * * * ******************************************************** =20 Note: It is acceptable to reference a standards-track specification that may reasonably be expected to be published as an RFC using the phrase "Work in Progress" without referencing an Internet-Draft. This may also be done in a standards track document itself as long as the specification in which the reference is made would stand as a complete and understandable document with or without the reference to the "Work in Progress". To me this means the RF-MIB v2 would have to be published as another document an we could cite that within the QOS-MIB. Rich, do you know if it is acceptable to cite another "ietf-draft" and if their are examples of this within other "ietf-drafts"?=09 I will address your other questions in a email to come Will Murwin -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] Sent: Wednesday, October 08, 2003 11:08 AM To: Murwin William-LWM008 Cc: Michael W. Patrick (E-mail); Minnie Lu; Jean-Francois Mule; Richard_Woundy@cable.comcast.com Subject: RE: sid counter inconsistent between draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ? Hi William, Minnie, Rich,=20 Before complete issue#14 for discussion,=20 Could you please review my assupmtions for the cross- RFI/QOS MIB interoperability issue#14 attached document? I have some concerns ( no comments still for item #13 Counters in/out CmtsCmStatusTable as you proposed and I relauched with Q to solve by Ipcdn participants thinking in the operational environment for 1-2 years ahead. Also how it is adjustable with already propietary methods supported supported, ( they migth and will stay there... Since we do not have resolution for #13 yet, and for keeping some sort of legacy support ( Minnie Lu comments ), I do not know for sure if those restrictions are useful right now due the divergency in current implementations. I like the cleanest as possible solution ( starting from William already wrote Qos interoperability section, but I don't know its possible impacts in the field applications or if handle the exceptions/violation out of specification /Qualification for MSOs considerations=20 Thanks Eduardo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com]=20 Sent: Tuesday, October 07, 2003 10:23 AM To: Eduardo Cardona Cc: Michael W. Patrick (E-mail); Minnie Lu; Jean-Francois Mule; Richard_Woundy@cable.comcast.com Subject: RE: sid counter inconsistent between draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ? Yes=20 item 5 from section 2.2.2.1 has been removed -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] Sent: Tuesday, October 07, 2003 12:02 PM To: Murwin William-LWM008 Cc: Michael W. Patrick (E-mail); Minnie Lu; Jean-Francois Mule; Richard_Woundy@cable.comcast.com Subject: RE: sid counter inconsistent between draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ? Hi William,=20 Just to confirm that you are planning to delete only the item 5 in 2.2.2.1 for the coming draft-ietf-ipcdn-qos-mib-09.txt I will propose a similar wording and section in the RFI v2 mib and any extra information you have will be very valuable Thanks Eduardo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com]=20 Sent: Tuesday, May 06, 2003 1:23 PM To: 'Minnie Lu'; Richard_Woundy@cable.comcast.com; DOCSIS OSS Majordomo List; IPCDN (E-mail) (E-mail) Cc: Michael W. Patrick (E-mail); David Raftus (E-mail) Subject: RE: sid counter inconsistent between draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ? Minnie, After much consideration, DOCSIS QOS MIB version 9 will remove the text from section Section 2.2.2.1 Interoperation with DOCSIS 1.0: 5. At the CMTS, the Docsis 1.0 MIB objects docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets for a SID assigned to a Docsis 1.1 or Docsis 2.0 modem count only the pre-registration packets/bytes of those modems." This is not an issue for the QOS MIB. The QOS MIB tried to handle DOCSIS 1.1 changes to RFC2670. Now that rfc2670 is being obsoleted, the rf-mib v2 and the DOCSIS OSS Specs is the place that should clearly state how these counters and other tables interact in DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0. I would even hope to see a section in the rf-mib v2, "Interoperation with the version of DOCSIS" like or to replace what the DOCSIS QOS MIB has. This is the place to describe what table are populated under the docsIfMib when the the modems are registering. This way this issue can be re-discussed and whatever conculsion is reached, can be document in the description of those objects. Sincerely, Will Murwin -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com] Sent: Thursday, March 20, 2003 4:16 PM To: Richard_Woundy@cable.comcast.com; docsis-oss@cablelabs.com Cc: milu@cisco.com Subject: sid counter inconsistent between draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ? Hi, Since I have not yet got any reason for the sid counter=20 inconsistence, I would like to raise this issue again and hope this time,=20 people will reconsider it. In draft-ietf-ipcdn-qos-mib-08.txt, 1. Section 2.2.2.1 Interoperation with DOCSIS 1.0 "5. At the CMTS, the Docsis 1.0 MIB objects docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets for a SID assigned to a Docsis 1.1 or Docsis 2.0 modem count only the pre-registration packets/bytes of those modems." Maybe I miss some discussion before. If there was some=20 discussion before, please excuse me to bring this up again because I really=20 don't understand why this is necessary to enforce this rule. SID concept is=20 still applicable to DOCSIS1.1 or 2.0. The MIB objects=20 docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets definitions look=20 good to me even for DOCSIS1.1 or 2.0. docsIfCmtsServiceInOctets OBJECT-TYPE "The cumulative number of Packet Data octets received on this Service ID. The count does not include the size of the Cable MAC header" docsIfCmtsServiceInPackets OBJECT-TYPE "The cumulative number of Packet Data packets received on this Service ID." From the description, it seems to me that they will count all the=20 traffic including pre-registration and post-registration received on this=20 Service ID no matter that this Service ID associates with DOCSIS1.0 or=20 DOCSIS1.1 or DOCSIS2.0 CMs. So they are consistent for various version of=20 CMs mode. Also, in the same section, item 3 . "The docsIfCmServiceTable row for the DOCSIS 1.1 or DOCSIS 2.0 modem continues to exist, and the various statistic objects in that row are incremented." It sounds to me the item 4 is inconsistent with item 3 above. For the=20 same MIB object, it counts differently in CM and CMTS for the SIDs=20 associated with DOCSIS1.1 CMs. I think it is good to keep CM and CMTS the=20 same as described in item 3. Also when customer queries the docsIfCmtsServiceTable, the customer=20 might wonder why some entries have low count and not aware of they are for=20 the SID belongs to CM in DOCSIS1.1 mode. I noticed this is not in version 4. From v5, it starts having such statements. Thanks ! Minnie _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Oct 8 16:14:23 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 QAA07182 for ; Wed, 8 Oct 2003 16:14:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Kh8-0007Da-Im for ipcdn-archive@odin.ietf.org; Wed, 08 Oct 2003 16:14:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98KE2Eu027742 for ipcdn-archive@odin.ietf.org; Wed, 8 Oct 2003 16:14:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Kh7-0007DE-Ip; Wed, 08 Oct 2003 16:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KgU-0007Ck-C1 for ipcdn@optimus.ietf.org; Wed, 08 Oct 2003 16:13:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07162 for ; Wed, 8 Oct 2003 16:13:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KgS-0003rF-00 for ipcdn@ietf.org; Wed, 08 Oct 2003 16:13:20 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A7KgR-0003qU-00 for ipcdn@ietf.org; Wed, 08 Oct 2003 16:13:19 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h98KCb10002657; Wed, 8 Oct 2003 14:12:38 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Oct 2003 14:12:37 -0600 Message-ID: Thread-Topic: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcONzLPhRWqGxyplR/+EIEFlkEp34gACcNMg From: "Greg White" To: "Minnie Lu" Cc: , "DOCSIS OSS Majordomo List" , , , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) 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 Minnie, I didn't want to prevent a user from changing their mind regarding channel type when creating a new modulation profile. Suppose you started out setting channel type to atdma and, after completing a few IUCs, realized that you really wanted tdmaAndAtdma. Rather than make you start from scratch (or do a simultaneous set across all IUCs), you could just update the channel type on each row. I understand your view as well. =20 If there is a consensus to change the text, I am not strongly opposed. -Greg -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Wednesday, October 08, 2003 12:48 PM To: Greg White Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, Greg, Thanks a lot to you and Eduardo for this proposal ! docsIfCmtsModChannelType : "... In order to be considered a valid modulation profile for assignment to an upstream channel, all entries (IUCs) in the modulation profile must have the same channel type." In addition to do the checking at the time the modulation profile is=20 assigned to some upstream, I think that the checking could also be done=20 when user create/modify an entry of docsIfCmtsModulationEntry even the=20 modulation profile is not assigned to any upstreams. So the error could be=20 caught earlier. So I would suggest to enhance the description as the ECO=20 (OSS2-O-03092) "All the entries in a modulation profile (i.e. all entries that share a=20 common docsIfCmtsModIndex) MUST have the same value of=20 docsIfCmtsModChannelType." If I miss anything, please let me know. Thanks a lot! Minnie At 04:22 PM 10/7/2003 -0600, Greg White wrote: >All, > >As a final issue to resolve in the RFMIBv2 before draft-08, I would like=20 >to propose that we complete the clarification of the relationship between=20 >the ChannelType parameters in modulation profiles and upstream channels. > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which=20 >clarifies part of the relationship by adding requirements to the OSSI=20 >spec. I would like to suggest that we propagate those requirements to the=20 >MIB descriptions. > >Also, I would like to propose that we make docsIfUpChannelType a read-only=20 >object for active rows in the Upstream Channel Table. The value reported=20 >would be taken from the modulation profile pointed to by=20 >docsIfUpChannelModulationProfile. > >Attached is a detailed proposal that Eduardo and I wrote to frame the issue. > >In order not to delay draft-08, we would like to have consensus from the=20 >community and working group by this Friday, October 10. Please review the=20 >attached proposal and provide comments. > >Many thanks, >Greg >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Monday, August 25, 2003 5:59 PM >To: Minnie Lu >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White;=20 >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to=20 >upstream channels > >Minnie, > I am emphathetic to your concerns. I ran across the same issue > while implementing cross-checks for the 2.0 modulation and upstream data.=20 > I found it made the code far simpler to lead the user down the path of > "define the channel type first, then build everything around that" kind=20 > of configuration model. I am then able to check the settings of the other=20 > parameters against the channel type. After a modulation profile or=20 > upstream channel has already been provisioned, changing just the channel=20 > type becomes difficult, as many parameters are incompatible with other > channel types. I allow it, but don't recommend it. > >My 2 cents, >David > > > > > >Minnie Lu > >08/25/2003 07:01 PM > > To: "Greg White" > cc: , "Minnie Lu"=20 > , , , > "DOCSIS OSS Majordomo List" , "Owner DOCSIS OSS=20 > Majordomo List" > Fax to: > Subject: RE: DOCSIS 2.0 : rules for assigning modulation=20 > profiles to upstream channels > > > > > >Hi, Greg, > > Please see my response inline. > Thanks a lot ! > Minnie >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > >The email exchange between Steve and Alberto notwithstanding, I think it > >does make sense to enforce that all entries in a modulation profile (i.e. > >all entries that share a common docsIfCmtsModIndex) have the same > >ModChannelType. Also, based on the exchange here it seems that there is > >some support for the additional restriction that UpChannelType and > >ModChannelType always match. With those two restrictions, there clearly > >is a need for all defined values of ModChannelType. > > > >Since this has been a point of confusion at least twice now, does anyone > >have a concern with making these two items part of the specification? > > > >[milu]: I agree with you. > > >A further point, how does the CMTS enforce the match between UpChannelType > >and ModChannelType? One implementation may automatically change > >UpChannelType to match ModChannelType whenever > >docsIfUpChannelModulationProfile is set. Another might reject the change > >if the two don't already match, and require the use of the > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd argue > >that the first implementation makes more sense, and ought to be made a > >SHOULD in the spec, but I'd like to hear other views. > > > >[milu]: I think this needs to be thought over carefully. How about the >case that some modulation profile is used by some upstream channel, and >user change the modulation profile channel type ? Does it mean that the >upstream channel type would be changed automatically, too ? If yes, I am >afraid that there might be some user who forget the modulation profile is >being used and change the channel type without knowing the upstream channel >type for some upstream channels are changed at the same time. The >modulation profile channel type and upstream channel type are in two >different MIB tables. > > Actually, I am always puzzled when the modulation profile is being used >by some upstream channels, could the modulation profile channel type be >changed ? Maybe this is a confusing point which needs to be clarified, too. > > Thanks a lot for your help ! > Minnie > > > > > > >-Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 11:07 AM > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner DOCSIS > >OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > Sounds good to me. This would make verifying the consistency of > > the data in the modulation profiles and the upstream channels far easier. > >So, if I understand correctly, this means that all modulation profile > >entries with the same docsIfCmtsModIndex will have to have the same > >docsIfCmtsModChannelType. Otherwise, you would not be able to use that > >modulation profile set on any upstream channel. So, this modulation > >profile set with different docsIfCmtsModChannelTypes from an e-mail thread > >between Alberto and Steve from almost a year ago would be invalid, no ? > >The way to patch it up would be to make all of the IUCs tdmaAndAtdma, > >correct ? > > > >Thanks, > >David > > > >--- end David's e-mail --- > >--- start e-mail exchange between Alberto and Steve --- > > > >Hi Steve > > > >Sorry for the delay in responding > > > >Your configuration settings for operation in multiple mode is correct and > >will support tdma, tdmaAndAtdma and Atdma. > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with UCD > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and IUCs > >5&6 are not used. Your interpretation of the spec in the example described > >is accurate. > > > >Alberto Campos > >a.campos@cablelabs.com > > > > > > > > > > > >-----Original Message----- > >From: Steve Malenfant [mailto:smalenfant@com21.com] > >Sent: Monday, September 30, 2002 9:39 AM > >To: 'docsis-20@cablelabs.com' > >Subject: Correlation between docsIfUpChannelType and > >docsIfCmtsModChannelT ype > > > > > > > >We are having some discussion internally here, and would like to clarify > >things about the modulation profile. > >Let's take an example, expecting all parameters are good : > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > >set IUC 5 docsIfCmtsModChannelType to tdma. > >set IUC 6 docsIfCmtsModChannelType to tdma. > >set IUC 9 docsIfCmtsModChannelType to Atdma. > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > >Would this burst profile be good for docsIfUpChannelType tdma, tdmaAndAtdma > >and Atdma? > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 inside > >UCD type 2. > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. > > > > > > > > > > > >Minnie Lu > >Sent by: owner-docsis-oss@cablelabs.com > > > >08/21/2003 07:15 PM > > > > To: David.White@arrisi.com, "Greg White" > > > > cc: "DOCSIS OSS Majordomo List" > > , milu@cisco.com > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, David and Greg, > > > > I like Greg's "Perhaps it is simpler just to require that ModChannelType > >match UpChannelType.". > > > > I don't think that "we could just drop tdmaAndAtdma for > >ModChannelType". Please keep in mind that when assigning the modulation > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, it uses > >only the docsIfModIndex and only one docsIfModIndex can be assigned to some > >upstream channel. > > > > If I miss anything, please correct me. > > Thanks! > > Minnie > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > >Greg, > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma channels. > > > However, the modulation profiles objects > > > docsIfCmtsModByteInterleaverBlockSize and > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma channels. So, > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these objects=20 > set, > > > it assumably could not be used on a tdma-only upstream channel. Hence, > > > the whole purpose of even having ModChannelType - to verify consistency > > > within the modulation profile - is weakened. This has the unintended=20 > side > > > effect of requiring any assignment of modulation profiles with IUCs=20 > 1, 2, > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see if the > > > Interleaver parameters have been set before assigning it to a tdma-only > > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation > > profiles. > > > I can't think of any need/requirement for tdmaAndAtdma for > > > modulation profiles that could not be met with a pair of tdma and atdma > > > modulation profile. In other words, I don't think allowing tdmaAndAtdma > > > for ModChannelType really buys us anything. I'm thinking we could just > > > drop tdmaAndAtdma for ModChannelType (making it a > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of confusion. > > > For the mixed-mode channels, where UpChannelType is=20 > tdmaAndAtdma, > > > the modulation profile set could look like so: > > > > > >IUC 1 tdma > > >IUC 2 tdma > > >IUC 3 tdma > > >IUC 4 tdma > > >IUC 5 tdma > > >IUC 6 tdma > > >IUC 9 atdma > > >IUC 10 atdma > > >IUC 11 atdma > > > > > >For tdma-only upstream channels, the modulation profile set could be: > > > > > >IUC 1 tdma > > >IUC 2 tdma > > >IUC 3 tdma > > >IUC 4 tdma > > >IUC 5 tdma > > >IUC 6 tdma > > > > > >Likewise, for atdma-only upstream channel, the modulation profile set > > >could be: > > > > > >IUC 1 atdma > > >IUC 2 atdma > > >IUC 3 atdma > > >IUC 4 atdma > > >IUC 9 atdma > > >IUC 10 atdma > > >IUC 11 atdma > > > > > >As far as I know, there is no hard limit on the number of the modulation > > >profile sets that the CMTS and CM can support. I'm really liking your=20 > "not > > >sure the benefits of flexibility outweigh disadvantages..." line of > > >thinking. tdmaAndAtdma for modulation profiles has my head spinning. > > > > > >Thanks, > > >David > > > > > > > > > > > >"Greg White" > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/20/2003 07:35 PM > > > > > > To: , "DOCSIS OSS Majordomo List" > > > > > > cc: > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning modulation > > > profiles to upstream channels > > > > > > > > >David, > > > > > >I agree with all of your clearly legal/illegal combinations. Among the > > >four that cause you consternation, I would break them done like this: > > > > > >illegal: > > >tdma, atdma > > >atdma, tdma > > > > > >potentially legal: > > >tdma, tdmaAndAtdma > > >atdma, tdmaAndAtdma > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and possibly=20 > 11, > > >so cannot be used for a tdma channel. Similarly a tdma modulation profile > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma channel. > > > > > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10, and > > >possibly 11, so could potentially be used for a tdma or an atdma channel > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS ignored the > > >IUCs that don't apply to the channel type. I'm not sure that the > > >advantages of that flexibility outweigh the disadvantages of having the > > >MIB reporting something that doesn't exactly reflect what is > > >configured. Perhaps it is simpler just to require that ModChannelType > > >match UpChannelType. > > > > > >-Greg > > > > > > > > > ----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Tuesday, August 19, 2003 9:37 AM > > >To: DOCSIS OSS Majordomo List > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to upstream > > >channels > > > > > > > > >DOCSIS 2.0 Community, > > > It seems that the DocsisUpstreamType objects in both the > > > modulation profile table and the upstream channel table exist, in part, > > > to provide the equipment vendor a way to cross-check the data for > > > consistency. Furthermore, it would seem possible to compare the two > > > DocsisUpstreamType objects when assigning an upstream to a modulation > > > profile to make sure the assignment is compatible. For instance, the > > > following combination of docsIfUpChannelType, docsIfCmtsModChannelType > > > would clearly be illegal: > > > > > >scdma, tdma > > >scdma, atdma > > >scdma, tdmaAndAtdma > > > > > >tdma, scdma > > >atdma, scdma > > >tdmaAndAtdma, scdma > > > > > > > > >It is also pretty clear the following are legal: > > > > > >tdma, tdma > > >atdma, atdma > > >scdma, scdma > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > >However, it is the following cases that are causing me consternation: > > > > > >tdma, atdma > > >tdma, tdmaAndAtdma > > >atdma, tdma > > >atdma, tdmaAndAtdma > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > >tdmaAndAtdma, other than to cause confusion, especially for modulation > > >profiles. > > > > > >Thanks, > > >David White > > >ARRIS Cadant C4 CMTS > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Oct 8 18:40:26 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 SAA13289 for ; Wed, 8 Oct 2003 18:40:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7MyU-0007Fs-DO for ipcdn-archive@odin.ietf.org; Wed, 08 Oct 2003 18:40:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Me5q3027867 for ipcdn-archive@odin.ietf.org; Wed, 8 Oct 2003 18:40:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7MyR-0007F8-7s; Wed, 08 Oct 2003 18:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JMK-0001j2-Cx for ipcdn@optimus.ietf.org; Wed, 08 Oct 2003 14:48:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02413 for ; Wed, 8 Oct 2003 14:48:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7JMH-0002it-00 for ipcdn@ietf.org; Wed, 08 Oct 2003 14:48:25 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A7JMG-0002iG-00 for ipcdn@ietf.org; Wed, 08 Oct 2003 14:48:24 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h98IlocZ022233; Wed, 8 Oct 2003 11:47:51 -0700 (PDT) Received: from milu-w2k.cisco.com (dhcp-171-71-51-93.cisco.com [171.71.51.93]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMY21982; Wed, 8 Oct 2003 11:47:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20031008111101.03202c58@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Oct 2003 11:47:48 -0700 To: "Greg White" From: Minnie Lu Cc: , "Minnie Lu" , "DOCSIS OSS Majordomo List" , , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) 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, Greg, Thanks a lot to you and Eduardo for this proposal ! docsIfCmtsModChannelType : "... In order to be considered a valid modulation profile for assignment to an upstream channel, all entries (IUCs) in the modulation profile must have the same channel type." In addition to do the checking at the time the modulation profile is assigned to some upstream, I think that the checking could also be done when user create/modify an entry of docsIfCmtsModulationEntry even the modulation profile is not assigned to any upstreams. So the error could be caught earlier. So I would suggest to enhance the description as the ECO (OSS2-O-03092) "All the entries in a modulation profile (i.e. all entries that share a common docsIfCmtsModIndex) MUST have the same value of docsIfCmtsModChannelType." If I miss anything, please let me know. Thanks a lot! Minnie At 04:22 PM 10/7/2003 -0600, Greg White wrote: >All, > >As a final issue to resolve in the RFMIBv2 before draft-08, I would like >to propose that we complete the clarification of the relationship between >the ChannelType parameters in modulation profiles and upstream channels. > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which >clarifies part of the relationship by adding requirements to the OSSI >spec. I would like to suggest that we propagate those requirements to the >MIB descriptions. > >Also, I would like to propose that we make docsIfUpChannelType a read-only >object for active rows in the Upstream Channel Table. The value reported >would be taken from the modulation profile pointed to by >docsIfUpChannelModulationProfile. > >Attached is a detailed proposal that Eduardo and I wrote to frame the issue. > >In order not to delay draft-08, we would like to have consensus from the >community and working group by this Friday, October 10. Please review the >attached proposal and provide comments. > >Many thanks, >Greg >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Monday, August 25, 2003 5:59 PM >To: Minnie Lu >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream channels > >Minnie, > I am emphathetic to your concerns. I ran across the same issue > while implementing cross-checks for the 2.0 modulation and upstream data. > I found it made the code far simpler to lead the user down the path of > "define the channel type first, then build everything around that" kind > of configuration model. I am then able to check the settings of the other > parameters against the channel type. After a modulation profile or > upstream channel has already been provisioned, changing just the channel > type becomes difficult, as many parameters are incompatible with other > channel types. I allow it, but don't recommend it. > >My 2 cents, >David > > > > > >Minnie Lu > >08/25/2003 07:01 PM > > To: "Greg White" > cc: , "Minnie Lu" > , , , > "DOCSIS OSS Majordomo List" , "Owner DOCSIS OSS > Majordomo List" > Fax to: > Subject: RE: DOCSIS 2.0 : rules for assigning modulation > profiles to upstream channels > > > > > >Hi, Greg, > > Please see my response inline. > Thanks a lot ! > Minnie >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > >The email exchange between Steve and Alberto notwithstanding, I think it > >does make sense to enforce that all entries in a modulation profile (i.e. > >all entries that share a common docsIfCmtsModIndex) have the same > >ModChannelType. Also, based on the exchange here it seems that there is > >some support for the additional restriction that UpChannelType and > >ModChannelType always match. With those two restrictions, there clearly > >is a need for all defined values of ModChannelType. > > > >Since this has been a point of confusion at least twice now, does anyone > >have a concern with making these two items part of the specification? > > > >[milu]: I agree with you. > > >A further point, how does the CMTS enforce the match between UpChannelType > >and ModChannelType? One implementation may automatically change > >UpChannelType to match ModChannelType whenever > >docsIfUpChannelModulationProfile is set. Another might reject the change > >if the two don't already match, and require the use of the > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd argue > >that the first implementation makes more sense, and ought to be made a > >SHOULD in the spec, but I'd like to hear other views. > > > >[milu]: I think this needs to be thought over carefully. How about the >case that some modulation profile is used by some upstream channel, and >user change the modulation profile channel type ? Does it mean that the >upstream channel type would be changed automatically, too ? If yes, I am >afraid that there might be some user who forget the modulation profile is >being used and change the channel type without knowing the upstream channel >type for some upstream channels are changed at the same time. The >modulation profile channel type and upstream channel type are in two >different MIB tables. > > Actually, I am always puzzled when the modulation profile is being used >by some upstream channels, could the modulation profile channel type be >changed ? Maybe this is a confusing point which needs to be clarified, too. > > Thanks a lot for your help ! > Minnie > > > > > > >-Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 11:07 AM > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner DOCSIS > >OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > Sounds good to me. This would make verifying the consistency of > > the data in the modulation profiles and the upstream channels far easier. > >So, if I understand correctly, this means that all modulation profile > >entries with the same docsIfCmtsModIndex will have to have the same > >docsIfCmtsModChannelType. Otherwise, you would not be able to use that > >modulation profile set on any upstream channel. So, this modulation > >profile set with different docsIfCmtsModChannelTypes from an e-mail thread > >between Alberto and Steve from almost a year ago would be invalid, no ? > >The way to patch it up would be to make all of the IUCs tdmaAndAtdma, > >correct ? > > > >Thanks, > >David > > > >--- end David's e-mail --- > >--- start e-mail exchange between Alberto and Steve --- > > > >Hi Steve > > > >Sorry for the delay in responding > > > >Your configuration settings for operation in multiple mode is correct and > >will support tdma, tdmaAndAtdma and Atdma. > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with UCD > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and IUCs > >5&6 are not used. Your interpretation of the spec in the example described > >is accurate. > > > >Alberto Campos > >a.campos@cablelabs.com > > > > > > > > > > > >-----Original Message----- > >From: Steve Malenfant [mailto:smalenfant@com21.com] > >Sent: Monday, September 30, 2002 9:39 AM > >To: 'docsis-20@cablelabs.com' > >Subject: Correlation between docsIfUpChannelType and > >docsIfCmtsModChannelT ype > > > > > > > >We are having some discussion internally here, and would like to clarify > >things about the modulation profile. > >Let's take an example, expecting all parameters are good : > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > >set IUC 5 docsIfCmtsModChannelType to tdma. > >set IUC 6 docsIfCmtsModChannelType to tdma. > >set IUC 9 docsIfCmtsModChannelType to Atdma. > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > >Would this burst profile be good for docsIfUpChannelType tdma, tdmaAndAtdma > >and Atdma? > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 inside > >UCD type 2. > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. > > > > > > > > > > > >Minnie Lu > >Sent by: owner-docsis-oss@cablelabs.com > > > >08/21/2003 07:15 PM > > > > To: David.White@arrisi.com, "Greg White" > > > > cc: "DOCSIS OSS Majordomo List" > > , milu@cisco.com > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, David and Greg, > > > > I like Greg's "Perhaps it is simpler just to require that ModChannelType > >match UpChannelType.". > > > > I don't think that "we could just drop tdmaAndAtdma for > >ModChannelType". Please keep in mind that when assigning the modulation > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, it uses > >only the docsIfModIndex and only one docsIfModIndex can be assigned to some > >upstream channel. > > > > If I miss anything, please correct me. > > Thanks! > > Minnie > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > >Greg, > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma channels. > > > However, the modulation profiles objects > > > docsIfCmtsModByteInterleaverBlockSize and > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma channels. So, > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these objects > set, > > > it assumably could not be used on a tdma-only upstream channel. Hence, > > > the whole purpose of even having ModChannelType - to verify consistency > > > within the modulation profile - is weakened. This has the unintended > side > > > effect of requiring any assignment of modulation profiles with IUCs > 1, 2, > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see if the > > > Interleaver parameters have been set before assigning it to a tdma-only > > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation > > profiles. > > > I can't think of any need/requirement for tdmaAndAtdma for > > > modulation profiles that could not be met with a pair of tdma and atdma > > > modulation profile. In other words, I don't think allowing tdmaAndAtdma > > > for ModChannelType really buys us anything. I'm thinking we could just > > > drop tdmaAndAtdma for ModChannelType (making it a > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of confusion. > > > For the mixed-mode channels, where UpChannelType is > tdmaAndAtdma, > > > the modulation profile set could look like so: > > > > > >IUC 1 tdma > > >IUC 2 tdma > > >IUC 3 tdma > > >IUC 4 tdma > > >IUC 5 tdma > > >IUC 6 tdma > > >IUC 9 atdma > > >IUC 10 atdma > > >IUC 11 atdma > > > > > >For tdma-only upstream channels, the modulation profile set could be: > > > > > >IUC 1 tdma > > >IUC 2 tdma > > >IUC 3 tdma > > >IUC 4 tdma > > >IUC 5 tdma > > >IUC 6 tdma > > > > > >Likewise, for atdma-only upstream channel, the modulation profile set > > >could be: > > > > > >IUC 1 atdma > > >IUC 2 atdma > > >IUC 3 atdma > > >IUC 4 atdma > > >IUC 9 atdma > > >IUC 10 atdma > > >IUC 11 atdma > > > > > >As far as I know, there is no hard limit on the number of the modulation > > >profile sets that the CMTS and CM can support. I'm really liking your > "not > > >sure the benefits of flexibility outweigh disadvantages..." line of > > >thinking. tdmaAndAtdma for modulation profiles has my head spinning. > > > > > >Thanks, > > >David > > > > > > > > > > > >"Greg White" > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/20/2003 07:35 PM > > > > > > To: , "DOCSIS OSS Majordomo List" > > > > > > cc: > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning modulation > > > profiles to upstream channels > > > > > > > > >David, > > > > > >I agree with all of your clearly legal/illegal combinations. Among the > > >four that cause you consternation, I would break them done like this: > > > > > >illegal: > > >tdma, atdma > > >atdma, tdma > > > > > >potentially legal: > > >tdma, tdmaAndAtdma > > >atdma, tdmaAndAtdma > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and possibly > 11, > > >so cannot be used for a tdma channel. Similarly a tdma modulation profile > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma channel. > > > > > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10, and > > >possibly 11, so could potentially be used for a tdma or an atdma channel > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS ignored the > > >IUCs that don't apply to the channel type. I'm not sure that the > > >advantages of that flexibility outweigh the disadvantages of having the > > >MIB reporting something that doesn't exactly reflect what is > > >configured. Perhaps it is simpler just to require that ModChannelType > > >match UpChannelType. > > > > > >-Greg > > > > > > > > > ----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Tuesday, August 19, 2003 9:37 AM > > >To: DOCSIS OSS Majordomo List > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to upstream > > >channels > > > > > > > > >DOCSIS 2.0 Community, > > > It seems that the DocsisUpstreamType objects in both the > > > modulation profile table and the upstream channel table exist, in part, > > > to provide the equipment vendor a way to cross-check the data for > > > consistency. Furthermore, it would seem possible to compare the two > > > DocsisUpstreamType objects when assigning an upstream to a modulation > > > profile to make sure the assignment is compatible. For instance, the > > > following combination of docsIfUpChannelType, docsIfCmtsModChannelType > > > would clearly be illegal: > > > > > >scdma, tdma > > >scdma, atdma > > >scdma, tdmaAndAtdma > > > > > >tdma, scdma > > >atdma, scdma > > >tdmaAndAtdma, scdma > > > > > > > > >It is also pretty clear the following are legal: > > > > > >tdma, tdma > > >atdma, atdma > > >scdma, scdma > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > >However, it is the following cases that are causing me consternation: > > > > > >tdma, atdma > > >tdma, tdmaAndAtdma > > >atdma, tdma > > >atdma, tdmaAndAtdma > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > >tdmaAndAtdma, other than to cause confusion, especially for modulation > > >profiles. > > > > > >Thanks, > > >David White > > >ARRIS Cadant C4 CMTS > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Oct 8 19:21:21 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 TAA14537 for ; Wed, 8 Oct 2003 19:21:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Nc4-0000bi-Ts for ipcdn-archive@odin.ietf.org; Wed, 08 Oct 2003 19:21:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98NL0rZ002335 for ipcdn-archive@odin.ietf.org; Wed, 8 Oct 2003 19:21:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Nc3-0000bT-UI; Wed, 08 Oct 2003 19:20:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Nc0-0000bG-A3 for ipcdn@optimus.ietf.org; Wed, 08 Oct 2003 19:20:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14526 for ; Wed, 8 Oct 2003 19:20:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Nby-0005mN-00 for ipcdn@ietf.org; Wed, 08 Oct 2003 19:20:54 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A7Nby-0005mH-00 for ipcdn@ietf.org; Wed, 08 Oct 2003 19:20:54 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h98NKC10018788; Wed, 8 Oct 2003 17:20:12 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Oct 2003 17:20:12 -0600 Message-ID: Thread-Topic: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcON4HQlGjFPumzdSPCnH47/qeYknQAEa5kg From: "Greg White" To: "Minnie Lu" Cc: , "DOCSIS OSS Majordomo List" , , , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) 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 That sounds like a workable alternative. If no one disagrees, I will make that change to the proposal. -Greg -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Wednesday, October 08, 2003 3:09 PM To: Greg White Cc: Minnie Lu; David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, Greg, Then how about enforce this rule for "active" entries ? So in the case you=20 mentioned, user can change the row status to notInService first or at the=20 same time changing the channel type. When user changed all the entries' channel type to be the same, use can put the entries in active again. I personally think it affects a lot when the channel type is changed, so a little more steps should be ok. To me, if there is an error, better catch=20 it as earlier as possible. "All the active entries in a modulation profile (i.e. all active entries that share a common docsIfCmtsModIndex) MUST have the same value of docsIfCmtsModChannelType." Thanks a lot ! Minnie At 02:12 PM 10/8/2003 -0600, Greg White wrote: >Minnie, > >I didn't want to prevent a user from changing their mind regarding >channel type when creating a new modulation profile. Suppose you >started out setting channel type to atdma and, after completing a few >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make >you start from scratch (or do a simultaneous set across all IUCs), you >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Hi, Greg, > > Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the >modulation profile is not assigned to any upstreams. So the error could >be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please review >the > >attached proposal and provide comments. > > > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , , , > > > "DOCSIS OSS Majordomo List" , "Owner DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same > > >ModChannelType. Also, based on the exchange here it seems that there >is > > >some support for the additional restriction that UpChannelType and > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change > > >UpChannelType to match ModChannelType whenever > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about the > >case that some modulation profile is used by some upstream channel, and > >user change the modulation profile channel type ? Does it mean that >the > >upstream channel type would be changed automatically, too ? If yes, I >am > >afraid that there might be some user who forget the modulation profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The > >modulation profile channel type and upstream channel type are in two > >different MIB tables. > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type be > >changed ? Maybe this is a confusing point which needs to be clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > > >upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation profile > > >entries with the same docsIfCmtsModIndex will have to have the same > > >docsIfCmtsModChannelType. Otherwise, you would not be able to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid, no >? > > >The way to patch it up would be to make all of the IUCs tdmaAndAtdma, > > >correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List" > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects > > > > docsIfCmtsModByteInterleaverBlockSize and > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma for > > > > modulation profiles that could not be met with a pair of tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line of > > > >thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations. Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of having >the > > > >MIB reporting something that doesn't exactly reflect what is > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the > > > > modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data for > > > > consistency. Furthermore, it would seem possible to compare the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Oct 8 19:25:45 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 SAA13291 for ; Wed, 8 Oct 2003 18:40:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7MyU-0007G9-Qz for ipcdn-archive@odin.ietf.org; Wed, 08 Oct 2003 18:40:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Me5N6027868 for ipcdn-archive@odin.ietf.org; Wed, 8 Oct 2003 18:40:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7MyS-0007FK-6E; Wed, 08 Oct 2003 18:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LZ7-0002Vm-J7 for ipcdn@optimus.ietf.org; Wed, 08 Oct 2003 17:09:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09463 for ; Wed, 8 Oct 2003 17:09:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7LZ5-0004VF-00 for ipcdn@ietf.org; Wed, 08 Oct 2003 17:09:47 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A7LZ4-0004V8-00 for ipcdn@ietf.org; Wed, 08 Oct 2003 17:09:46 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 08 Oct 2003 14:17:19 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h98L96Lt016671; Wed, 8 Oct 2003 14:09:06 -0700 (PDT) Received: from milu-w2k.cisco.com (dhcp-171-71-51-93.cisco.com [171.71.51.93]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMY40659; Wed, 8 Oct 2003 14:09:05 -0700 (PDT) Message-Id: <4.3.2.7.2.20031008135957.03201210@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Oct 2003 14:09:05 -0700 To: "Greg White" From: Minnie Lu Cc: "Minnie Lu" , , "DOCSIS OSS Majordomo List" , , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) 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, Greg, Then how about enforce this rule for "active" entries ? So in the case you mentioned, user can change the row status to notInService first or at the same time changing the channel type. When user changed all the entries' channel type to be the same, use can put the entries in active again. I personally think it affects a lot when the channel type is changed, so a little more steps should be ok. To me, if there is an error, better catch it as earlier as possible. "All the active entries in a modulation profile (i.e. all active entries that share a common docsIfCmtsModIndex) MUST have the same value of docsIfCmtsModChannelType." Thanks a lot ! Minnie At 02:12 PM 10/8/2003 -0600, Greg White wrote: >Minnie, > >I didn't want to prevent a user from changing their mind regarding >channel type when creating a new modulation profile. Suppose you >started out setting channel type to atdma and, after completing a few >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make >you start from scratch (or do a simultaneous set across all IUCs), you >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Hi, Greg, > > Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the >modulation profile is not assigned to any upstreams. So the error could >be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please review >the > >attached proposal and provide comments. > > > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , , , > > > "DOCSIS OSS Majordomo List" , "Owner DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same > > >ModChannelType. Also, based on the exchange here it seems that there >is > > >some support for the additional restriction that UpChannelType and > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change > > >UpChannelType to match ModChannelType whenever > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about the > >case that some modulation profile is used by some upstream channel, and > >user change the modulation profile channel type ? Does it mean that >the > >upstream channel type would be changed automatically, too ? If yes, I >am > >afraid that there might be some user who forget the modulation profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The > >modulation profile channel type and upstream channel type are in two > >different MIB tables. > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type be > >changed ? Maybe this is a confusing point which needs to be clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > > >upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation profile > > >entries with the same docsIfCmtsModIndex will have to have the same > > >docsIfCmtsModChannelType. Otherwise, you would not be able to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid, no >? > > >The way to patch it up would be to make all of the IUCs tdmaAndAtdma, > > >correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List" > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects > > > > docsIfCmtsModByteInterleaverBlockSize and > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma for > > > > modulation profiles that could not be met with a pair of tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line of > > > >thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations. Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of having >the > > > >MIB reporting something that doesn't exactly reflect what is > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the > > > > modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data for > > > > consistency. Furthermore, it would seem possible to compare the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Oct 8 19:25:45 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 SAA13293 for ; Wed, 8 Oct 2003 18:40:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7MyV-0007Gv-Kf for ipcdn-archive@odin.ietf.org; Wed, 08 Oct 2003 18:40:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Me7lI027925 for ipcdn-archive@odin.ietf.org; Wed, 8 Oct 2003 18:40:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7MyU-0007G8-Ol; Wed, 08 Oct 2003 18:40:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Lap-0002Ys-0h for ipcdn@optimus.ietf.org; Wed, 08 Oct 2003 17:11:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09529 for ; Wed, 8 Oct 2003 17:11:24 -0400 (EDT) From: David.White@arrisi.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Lam-0004WA-00 for ipcdn@ietf.org; Wed, 08 Oct 2003 17:11:32 -0400 Received: from pluto.arrisi.com ([63.82.122.6]) by ietf-mx with esmtp (Exim 4.12) id 1A7Lal-0004W7-00 for ipcdn@ietf.org; Wed, 08 Oct 2003 17:11:31 -0400 To: "Greg White" Cc: "DOCSIS OSS Majordomo List" , Greg.Gohman@arrisi.com, ipcdn@ietf.org, Larry.Spaete@arrisi.com, "Minnie Lu" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: Date: Wed, 8 Oct 2003 17:11:29 -0400 X-MIMETrack: Serialize by Router on Pluto/Antec(Release 6.0.2CF1|June 9, 2003) at 10/08/2003 05:19:09 PM, Serialize complete at 10/08/2003 05:19:09 PM Content-Type: multipart/alternative; boundary="=_alternative 007467A785256DB9_=" Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) 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 multipart message in MIME format. --=_alternative 007467A785256DB9_= Content-Type: text/plain; charset="us-ascii" Greg, Per your earlier e-mail on this thread: "Also, I would like to propose that we make docsIfUpChannelType a read-only object for active rows in the Upstream Channel Table. The value reported would be taken from the modulation profile pointed to by docsIfUpChannelModulationProfile." I'm assuming "active" mean in-service. Otherwise, we have to be careful with this because the channelType is used to verify things like channelWidth and whether or not setting of the scdma-specific parameters is allowed. Along the same lines, if setting the upstream modulation profile index implies that the SNMP agent changes the upChannelType to match the modProfChannelType, then the agent must also verify that all of the other parameters in the upstream channel are compatible with the possibly new channel type. David "Greg White" 10/08/2003 04:12 PM To: "Minnie Lu" cc: , "DOCSIS OSS Majordomo List" , , , Fax to: Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Minnie, I didn't want to prevent a user from changing their mind regarding channel type when creating a new modulation profile. Suppose you started out setting channel type to atdma and, after completing a few IUCs, realized that you really wanted tdmaAndAtdma. Rather than make you start from scratch (or do a simultaneous set across all IUCs), you could just update the channel type on each row. I understand your view as well. If there is a consensus to change the text, I am not strongly opposed. -Greg -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com] Sent: Wednesday, October 08, 2003 12:48 PM To: Greg White Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, Greg, Thanks a lot to you and Eduardo for this proposal ! docsIfCmtsModChannelType : "... In order to be considered a valid modulation profile for assignment to an upstream channel, all entries (IUCs) in the modulation profile must have the same channel type." In addition to do the checking at the time the modulation profile is assigned to some upstream, I think that the checking could also be done when user create/modify an entry of docsIfCmtsModulationEntry even the modulation profile is not assigned to any upstreams. So the error could be caught earlier. So I would suggest to enhance the description as the ECO (OSS2-O-03092) "All the entries in a modulation profile (i.e. all entries that share a common docsIfCmtsModIndex) MUST have the same value of docsIfCmtsModChannelType." If I miss anything, please let me know. Thanks a lot! Minnie At 04:22 PM 10/7/2003 -0600, Greg White wrote: >All, > >As a final issue to resolve in the RFMIBv2 before draft-08, I would like >to propose that we complete the clarification of the relationship between >the ChannelType parameters in modulation profiles and upstream channels. > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which >clarifies part of the relationship by adding requirements to the OSSI >spec. I would like to suggest that we propagate those requirements to the >MIB descriptions. > >Also, I would like to propose that we make docsIfUpChannelType a read-only >object for active rows in the Upstream Channel Table. The value reported >would be taken from the modulation profile pointed to by >docsIfUpChannelModulationProfile. > >Attached is a detailed proposal that Eduardo and I wrote to frame the issue. > >In order not to delay draft-08, we would like to have consensus from the >community and working group by this Friday, October 10. Please review the >attached proposal and provide comments. > >Many thanks, >Greg >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Monday, August 25, 2003 5:59 PM >To: Minnie Lu >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream channels > >Minnie, > I am emphathetic to your concerns. I ran across the same issue > while implementing cross-checks for the 2.0 modulation and upstream data. > I found it made the code far simpler to lead the user down the path of > "define the channel type first, then build everything around that" kind > of configuration model. I am then able to check the settings of the other > parameters against the channel type. After a modulation profile or > upstream channel has already been provisioned, changing just the channel > type becomes difficult, as many parameters are incompatible with other > channel types. I allow it, but don't recommend it. > >My 2 cents, >David > > > > > >Minnie Lu > >08/25/2003 07:01 PM > > To: "Greg White" > cc: , "Minnie Lu" > , , , > "DOCSIS OSS Majordomo List" , "Owner DOCSIS OSS > Majordomo List" > Fax to: > Subject: RE: DOCSIS 2.0 : rules for assigning modulation > profiles to upstream channels > > > > > >Hi, Greg, > > Please see my response inline. > Thanks a lot ! > Minnie >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > >The email exchange between Steve and Alberto notwithstanding, I think it > >does make sense to enforce that all entries in a modulation profile (i.e. > >all entries that share a common docsIfCmtsModIndex) have the same > >ModChannelType. Also, based on the exchange here it seems that there is > >some support for the additional restriction that UpChannelType and > >ModChannelType always match. With those two restrictions, there clearly > >is a need for all defined values of ModChannelType. > > > >Since this has been a point of confusion at least twice now, does anyone > >have a concern with making these two items part of the specification? > > > >[milu]: I agree with you. > > >A further point, how does the CMTS enforce the match between UpChannelType > >and ModChannelType? One implementation may automatically change > >UpChannelType to match ModChannelType whenever > >docsIfUpChannelModulationProfile is set. Another might reject the change > >if the two don't already match, and require the use of the > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd argue > >that the first implementation makes more sense, and ought to be made a > >SHOULD in the spec, but I'd like to hear other views. > > > >[milu]: I think this needs to be thought over carefully. How about the >case that some modulation profile is used by some upstream channel, and >user change the modulation profile channel type ? Does it mean that the >upstream channel type would be changed automatically, too ? If yes, I am >afraid that there might be some user who forget the modulation profile is >being used and change the channel type without knowing the upstream channel >type for some upstream channels are changed at the same time. The >modulation profile channel type and upstream channel type are in two >different MIB tables. > > Actually, I am always puzzled when the modulation profile is being used >by some upstream channels, could the modulation profile channel type be >changed ? Maybe this is a confusing point which needs to be clarified, too. > > Thanks a lot for your help ! > Minnie > > > > > > >-Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 11:07 AM > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner DOCSIS > >OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > Sounds good to me. This would make verifying the consistency of > > the data in the modulation profiles and the upstream channels far easier. > >So, if I understand correctly, this means that all modulation profile > >entries with the same docsIfCmtsModIndex will have to have the same > >docsIfCmtsModChannelType. Otherwise, you would not be able to use that > >modulation profile set on any upstream channel. So, this modulation > >profile set with different docsIfCmtsModChannelTypes from an e-mail thread > >between Alberto and Steve from almost a year ago would be invalid, no ? > >The way to patch it up would be to make all of the IUCs tdmaAndAtdma, > >correct ? > > > >Thanks, > >David > > > >--- end David's e-mail --- > >--- start e-mail exchange between Alberto and Steve --- > > > >Hi Steve > > > >Sorry for the delay in responding > > > >Your configuration settings for operation in multiple mode is correct and > >will support tdma, tdmaAndAtdma and Atdma. > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with UCD > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and IUCs > >5&6 are not used. Your interpretation of the spec in the example described > >is accurate. > > > >Alberto Campos > >a.campos@cablelabs.com > > > > > > > > > > > >-----Original Message----- > >From: Steve Malenfant [mailto:smalenfant@com21.com] > >Sent: Monday, September 30, 2002 9:39 AM > >To: 'docsis-20@cablelabs.com' > >Subject: Correlation between docsIfUpChannelType and > >docsIfCmtsModChannelT ype > > > > > > > >We are having some discussion internally here, and would like to clarify > >things about the modulation profile. > >Let's take an example, expecting all parameters are good : > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > >set IUC 5 docsIfCmtsModChannelType to tdma. > >set IUC 6 docsIfCmtsModChannelType to tdma. > >set IUC 9 docsIfCmtsModChannelType to Atdma. > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > >Would this burst profile be good for docsIfUpChannelType tdma, tdmaAndAtdma > >and Atdma? > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 inside > >UCD type 2. > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. > > > > > > > > > > > >Minnie Lu > >Sent by: owner-docsis-oss@cablelabs.com > > > >08/21/2003 07:15 PM > > > > To: David.White@arrisi.com, "Greg White" > > > > cc: "DOCSIS OSS Majordomo List" > > , milu@cisco.com > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, David and Greg, > > > > I like Greg's "Perhaps it is simpler just to require that ModChannelType > >match UpChannelType.". > > > > I don't think that "we could just drop tdmaAndAtdma for > >ModChannelType". Please keep in mind that when assigning the modulation > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, it uses > >only the docsIfModIndex and only one docsIfModIndex can be assigned to some > >upstream channel. > > > > If I miss anything, please correct me. > > Thanks! > > Minnie > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > >Greg, > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma channels. > > > However, the modulation profiles objects > > > docsIfCmtsModByteInterleaverBlockSize and > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma channels. So, > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these objects > set, > > > it assumably could not be used on a tdma-only upstream channel. Hence, > > > the whole purpose of even having ModChannelType - to verify consistency > > > within the modulation profile - is weakened. This has the unintended > side > > > effect of requiring any assignment of modulation profiles with IUCs > 1, 2, > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see if the > > > Interleaver parameters have been set before assigning it to a tdma-only > > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation > > profiles. > > > I can't think of any need/requirement for tdmaAndAtdma for > > > modulation profiles that could not be met with a pair of tdma and atdma > > > modulation profile. In other words, I don't think allowing tdmaAndAtdma > > > for ModChannelType really buys us anything. I'm thinking we could just > > > drop tdmaAndAtdma for ModChannelType (making it a > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of confusion. > > > For the mixed-mode channels, where UpChannelType is > tdmaAndAtdma, > > > the modulation profile set could look like so: > > > > > >IUC 1 tdma > > >IUC 2 tdma > > >IUC 3 tdma > > >IUC 4 tdma > > >IUC 5 tdma > > >IUC 6 tdma > > >IUC 9 atdma > > >IUC 10 atdma > > >IUC 11 atdma > > > > > >For tdma-only upstream channels, the modulation profile set could be: > > > > > >IUC 1 tdma > > >IUC 2 tdma > > >IUC 3 tdma > > >IUC 4 tdma > > >IUC 5 tdma > > >IUC 6 tdma > > > > > >Likewise, for atdma-only upstream channel, the modulation profile set > > >could be: > > > > > >IUC 1 atdma > > >IUC 2 atdma > > >IUC 3 atdma > > >IUC 4 atdma > > >IUC 9 atdma > > >IUC 10 atdma > > >IUC 11 atdma > > > > > >As far as I know, there is no hard limit on the number of the modulation > > >profile sets that the CMTS and CM can support. I'm really liking your > "not > > >sure the benefits of flexibility outweigh disadvantages..." line of > > >thinking. tdmaAndAtdma for modulation profiles has my head spinning. > > > > > >Thanks, > > >David > > > > > > > > > > > >"Greg White" > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/20/2003 07:35 PM > > > > > > To: , "DOCSIS OSS Majordomo List" > > > > > > cc: > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning modulation > > > profiles to upstream channels > > > > > > > > >David, > > > > > >I agree with all of your clearly legal/illegal combinations. Among the > > >four that cause you consternation, I would break them done like this: > > > > > >illegal: > > >tdma, atdma > > >atdma, tdma > > > > > >potentially legal: > > >tdma, tdmaAndAtdma > > >atdma, tdmaAndAtdma > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and possibly > 11, > > >so cannot be used for a tdma channel. Similarly a tdma modulation profile > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma channel. > > > > > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10, and > > >possibly 11, so could potentially be used for a tdma or an atdma channel > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS ignored the > > >IUCs that don't apply to the channel type. I'm not sure that the > > >advantages of that flexibility outweigh the disadvantages of having the > > >MIB reporting something that doesn't exactly reflect what is > > >configured. Perhaps it is simpler just to require that ModChannelType > > >match UpChannelType. > > > > > >-Greg > > > > > > > > > ----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Tuesday, August 19, 2003 9:37 AM > > >To: DOCSIS OSS Majordomo List > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to upstream > > >channels > > > > > > > > >DOCSIS 2.0 Community, > > > It seems that the DocsisUpstreamType objects in both the > > > modulation profile table and the upstream channel table exist, in part, > > > to provide the equipment vendor a way to cross-check the data for > > > consistency. Furthermore, it would seem possible to compare the two > > > DocsisUpstreamType objects when assigning an upstream to a modulation > > > profile to make sure the assignment is compatible. For instance, the > > > following combination of docsIfUpChannelType, docsIfCmtsModChannelType > > > would clearly be illegal: > > > > > >scdma, tdma > > >scdma, atdma > > >scdma, tdmaAndAtdma > > > > > >tdma, scdma > > >atdma, scdma > > >tdmaAndAtdma, scdma > > > > > > > > >It is also pretty clear the following are legal: > > > > > >tdma, tdma > > >atdma, atdma > > >scdma, scdma > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > >However, it is the following cases that are causing me consternation: > > > > > >tdma, atdma > > >tdma, tdmaAndAtdma > > >atdma, tdma > > >atdma, tdmaAndAtdma > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > >tdmaAndAtdma, other than to cause confusion, especially for modulation > > >profiles. > > > > > >Thanks, > > >David White > > >ARRIS Cadant C4 CMTS > > > > > --=_alternative 007467A785256DB9_= Content-Type: text/html; charset="us-ascii"
Greg,
        Per your earlier e-mail on this thread:

"Also, I would like to propose that we make docsIfUpChannelType a
read-only object for active rows in the Upstream Channel Table.
The value reported would be taken from the modulation profile pointed
to by docsIfUpChannelModulationProfile."

I'm assuming "active" mean in-service. Otherwise, we have to be careful with this because the channelType is used to verify things like channelWidth and whether or not setting of the scdma-specific parameters is allowed. Along the same lines, if setting the upstream modulation profile index implies that the SNMP agent changes the upChannelType to match the modProfChannelType, then the agent must also verify that all of the other parameters in the upstream channel are compatible with the possibly new channel type.

David
       


"Greg White" <g.white@CableLabs.com>

10/08/2003 04:12 PM

       
        To:        "Minnie Lu" <milu@cisco.com>
        cc:        <David.White@arrisi.com>, "DOCSIS OSS Majordomo List" <docsis-oss@CableLabs.com>, <Greg.Gohman@arrisi.com>, <Larry.Spaete@arrisi.com>, <ipcdn@ietf.org>
        Fax to:        
        Subject:        RE: Channel Types in RFMIBv2  (was RE: DOCSIS 2.0 : rules for  assigning modulation profiles to upstream channels)



Minnie,

I didn't want to prevent a user from changing their mind regarding
channel type when creating a new modulation profile.  Suppose you
started out setting channel type to atdma and, after completing a few
IUCs, realized that you really wanted tdmaAndAtdma.  Rather than make
you start from scratch (or do a simultaneous set across all IUCs), you
could just update the channel type on each row.

I understand your view as well.  

If there is a consensus to change the text, I am not strongly opposed.

-Greg

-----Original Message-----
From: Minnie Lu [mailto:milu@cisco.com]
Sent: Wednesday, October 08, 2003 12:48 PM
To: Greg White
Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List;
Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org
Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for
assigning modulation profiles to upstream channels)


Hi, Greg,

 Thanks a lot to you and Eduardo for this proposal !

docsIfCmtsModChannelType :
  "...
    In order to be considered a valid modulation profile for
    assignment to an upstream channel, all entries (IUCs) in
      the modulation profile must have the same channel type."

  In addition to do the checking at the time the modulation profile is
assigned to some upstream, I think that the checking could also be done
when user create/modify an entry of docsIfCmtsModulationEntry even the
modulation profile is not assigned to any upstreams.  So the error could
be
caught earlier.   So I would suggest to enhance the description as the
ECO
(OSS2-O-03092)

"All the entries in a modulation profile (i.e. all entries that share a
common docsIfCmtsModIndex) MUST have the same value of
docsIfCmtsModChannelType."

If I miss anything, please let me know.
Thanks a lot!
Minnie

At 04:22 PM 10/7/2003 -0600, Greg White wrote:
>All,
>
>As a final issue to resolve in the RFMIBv2 before draft-08, I would
like
>to propose that we complete the clarification of the relationship
between
>the ChannelType parameters in modulation profiles and upstream
channels.
>
>There is currently an ECO (OSS2-O-03092) written by Minnie Lu which
>clarifies part of the relationship by adding requirements to the OSSI
>spec.  I would like to suggest that we propagate those requirements to
the
>MIB descriptions.
>
>Also, I would like to propose that we make docsIfUpChannelType a
read-only
>object for active rows in the Upstream Channel Table.  The value
reported
>would be taken from the modulation profile pointed to by
>docsIfUpChannelModulationProfile.
>
>Attached is a detailed proposal that Eduardo and I wrote to frame the
issue.
>
>In order not to delay draft-08, we would like to have consensus from
the
>community and working group by this Friday, October 10.  Please review
the
>attached proposal and provide comments.
>
>Many thanks,
>Greg
>-----Original Message-----
>From: David.White@arrisi.com [mailto:David.White@arrisi.com]
>Sent: Monday, August 25, 2003 5:59 PM
>To: Minnie Lu
>Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White;
>Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List
>Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to
>upstream channels
>
>Minnie,
>         I am emphathetic to your concerns. I ran across the same issue

> while implementing cross-checks for the 2.0 modulation and upstream
data.
> I found it made the code far simpler to lead the user down the path of

> "define the channel type first, then build everything around that"
kind
> of configuration model. I am then able to check the settings of the
other
> parameters against the channel type. After a modulation profile or
> upstream channel has already been provisioned, changing just the
channel
> type becomes difficult, as many parameters are incompatible with other

> channel types. I allow it, but don't recommend it.
>
>My 2 cents,
>David
>
>
>
>
>
>Minnie Lu <milu@cisco.com>
>
>08/25/2003 07:01 PM
>
>         To:        "Greg White" <g.white@CableLabs.com>
>         cc:        <David.White@arrisi.com>, "Minnie Lu"
> <milu@cisco.com>, <Greg.Gohman@arrisi.com>, <Larry.Spaete@arrisi.com>,

> "DOCSIS OSS Majordomo List" <docsis-oss@CableLabs.com>, "Owner DOCSIS
OSS
> Majordomo List" <owner-docsis-oss@CableLabs.com>
>         Fax to:
>         Subject:        RE: DOCSIS 2.0 : rules for assigning
modulation
> profiles to   upstream channels
>
>
>
>
>
>Hi, Greg,
>
>  Please see my response inline.
>  Thanks a lot !
>  Minnie
>At 02:29 PM 8/25/2003 -0600, Greg White wrote:
> >The email exchange between Steve and Alberto notwithstanding, I think
it
> >does make sense to enforce that all entries in a modulation profile
(i.e.
> >all entries that share a common docsIfCmtsModIndex) have the same
> >ModChannelType.  Also, based on the exchange here it seems that there
is
> >some support for the additional restriction that UpChannelType and
> >ModChannelType always match.  With those two restrictions, there
clearly
> >is a need for all defined values of ModChannelType.
> >
> >Since this has been a point of confusion at least twice now, does
anyone
> >have a concern with making these two items part of the specification?
> >
>
>[milu]: I agree with you.
>
> >A further point, how does the CMTS enforce the match between
UpChannelType
> >and ModChannelType?  One implementation may automatically change
> >UpChannelType to match ModChannelType whenever
> >docsIfUpChannelModulationProfile is set.  Another might reject the
change
> >if the two don't already match, and require the use of the
> >docsIfUpChannelCloneFrom mechanism to change the channel type.  I'd
argue
> >that the first implementation makes more sense, and ought to be made
a
> >SHOULD in the spec, but I'd like to hear other views.
> >
>
>[milu]: I think this needs to be thought over carefully.  How about the
>case that some modulation profile is used by some upstream channel, and
>user change the modulation profile channel type ?  Does it mean that
the
>upstream channel type would be changed automatically, too ?  If yes, I
am
>afraid that there might be some user who forget the modulation profile
is
>being used and change the channel type without knowing the upstream
channel
>type for some upstream channels are changed at the same time.  The
>modulation profile channel type and upstream channel type are in two
>different MIB tables.
>
>   Actually, I am always puzzled when the modulation profile is being
used
>by some upstream channels, could the modulation profile channel type be
>changed ?  Maybe this is a confusing point which needs to be clarified,
too.
>
>   Thanks a lot for your help !
>   Minnie
>
>
>
>
>
> >-Greg
> >-----Original Message-----
> >From: David.White@arrisi.com [mailto:David.White@arrisi.com]
> >Sent: Monday, August 25, 2003 11:07 AM
> >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com
> >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner
DOCSIS
> >OSS Majordomo List
> >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to
> >upstream channels
> >
> >Minnie,
> >         Sounds good to me. This would make verifying the consistency
of
> > the data in the modulation profiles and the upstream channels far
easier.
> >So, if I understand correctly, this means that all modulation profile
> >entries with the same docsIfCmtsModIndex will have to have the same
> >docsIfCmtsModChannelType. Otherwise, you would not be able to use
that
> >modulation profile set on any upstream channel. So, this modulation
> >profile set with different docsIfCmtsModChannelTypes from an e-mail
thread
> >between Alberto and Steve from almost a year ago would be invalid, no
?
> >The way to patch it up would be to make all of the IUCs tdmaAndAtdma,
> >correct ?
> >
> >Thanks,
> >David
> >
> >--- end David's e-mail ---
> >--- start e-mail exchange between Alberto and Steve ---
> >
> >Hi Steve
> >
> >Sorry for the delay in responding
> >
> >Your configuration settings for operation in multiple mode is correct
and
> >will support tdma, tdmaAndAtdma and Atdma.
> >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with
UCD
> >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and
IUCs
> >5&6 are not used. Your interpretation of the spec in the example
described
> >is accurate.
> >
> >Alberto Campos
> >a.campos@cablelabs.com
> >
> >
> >
> >
> >
> >-----Original Message-----
> >From: Steve Malenfant [mailto:smalenfant@com21.com]
> >Sent: Monday, September 30, 2002 9:39 AM
> >To: 'docsis-20@cablelabs.com'
> >Subject: Correlation between docsIfUpChannelType and
> >docsIfCmtsModChannelT ype
> >
> >
> >
> >We are having some discussion internally here, and would like to
clarify
> >things about the modulation profile.
> >Let's take an example, expecting all parameters are good :
> >
> >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma.
> >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma.
> >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma.
> >set IUC 5 docsIfCmtsModChannelType to tdma.
> >set IUC 6 docsIfCmtsModChannelType to tdma.
> >set IUC 9 docsIfCmtsModChannelType to Atdma.
> >set IUC 10 docsIfCmtsModChannelType to Atdma.
> >
> >Would this burst profile be good for docsIfUpChannelType tdma,
tdmaAndAtdma
> >and Atdma?
> >
> >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2.
> >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5
inside
> >UCD type 2.
> >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29.
> >
> >
> >
> >
> >
> >Minnie Lu <milu@cisco.com>
> >Sent by: owner-docsis-oss@cablelabs.com
> >
> >08/21/2003 07:15 PM
> >
> >         To:        David.White@arrisi.com, "Greg White"
> > <g.white@cablelabs.com>
> >         cc:        "DOCSIS OSS Majordomo List"
> > <docsis-oss@cablelabs.com>, milu@cisco.com
> >         Fax to:
> >         Subject:        RE: DOCSIS 2.0 : rules for assigning
modulation
> > profiles to  upstream channels
> >
> >
> >
> >
> >
> >Hi, David and Greg,
> >
> >  I like Greg's "Perhaps it is simpler just to require that
ModChannelType
> >match UpChannelType.".
> >
> >  I don't think that "we could just drop tdmaAndAtdma for
> >ModChannelType".  Please keep in mind that when assigning the
modulation
> >profile to some upstream via SNMP docsIfUpChannelModulationProfile,
it uses
> >only the docsIfModIndex and only one docsIfModIndex can be assigned
to some
> >upstream channel.
> >
> >  If I miss anything, please correct me.
> >  Thanks!
> >  Minnie
> >
> >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote:
> >
> > >Greg,
> > >         IUCs 1, 2, 3, and 4 are used for both tdma and atdma
channels.
> > > However, the modulation profiles objects
> > > docsIfCmtsModByteInterleaverBlockSize and
> > > docsIfCmtsModByteInterleaverDepth are only valid for atdma
channels. So,
> > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these
objects
> set,
> > > it assumably could not be used on a tdma-only upstream channel.
Hence,
> > > the whole purpose of even having ModChannelType - to verify
consistency
> > > within the modulation profile - is weakened. This has the
unintended
> side
> > > effect of requiring any assignment of modulation profiles with
IUCs
> 1, 2,
> > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see
if the
> > > Interleaver parameters have been set before assigning it to a
tdma-only
> > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation
> > profiles.
> > >         I can't think of any need/requirement for tdmaAndAtdma for
> > > modulation profiles that could not be met with a pair of tdma and
atdma
> > > modulation profile. In other words, I don't think allowing
tdmaAndAtdma
> > > for ModChannelType really buys us anything. I'm thinking we could
just
> > > drop tdmaAndAtdma for ModChannelType (making it a
> > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of
confusion.
> > >         For the mixed-mode channels, where UpChannelType is
> tdmaAndAtdma,
> > > the modulation profile set could look like so:
> > >
> > >IUC  1  tdma
> > >IUC  2  tdma
> > >IUC  3  tdma
> > >IUC  4  tdma
> > >IUC  5  tdma
> > >IUC  6  tdma
> > >IUC  9 atdma
> > >IUC 10 atdma
> > >IUC 11 atdma
> > >
> > >For tdma-only upstream channels, the modulation profile set could
be:
> > >
> > >IUC 1 tdma
> > >IUC 2 tdma
> > >IUC 3 tdma
> > >IUC 4 tdma
> > >IUC 5 tdma
> > >IUC 6 tdma
> > >
> > >Likewise, for atdma-only upstream channel, the modulation profile
set
> > >could be:
> > >
> > >IUC  1 atdma
> > >IUC  2 atdma
> > >IUC  3 atdma
> > >IUC  4 atdma
> > >IUC  9 atdma
> > >IUC 10 atdma
> > >IUC 11 atdma
> > >
> > >As far as I know, there is no hard limit on the number of the
modulation
> > >profile sets that the CMTS and CM can support. I'm really liking
your
> "not
> > >sure the benefits of flexibility outweigh disadvantages..." line of
> > >thinking. tdmaAndAtdma for modulation profiles has my head
spinning.
> > >
> > >Thanks,
> > >David
> > >
> > >
> > >
> > >"Greg White" <g.white@cablelabs.com>
> > >Sent by: owner-docsis-oss@cablelabs.com
> > >
> > >08/20/2003 07:35 PM
> > >
> > >         To:        <David.White@arrisi.com>, "DOCSIS OSS Majordomo
List"
> > > <docsis-oss@cablelabs.com>
> > >         cc:
> > >         Fax to:
> > >         Subject:        RE: DOCSIS 2.0 : rules for assigning
modulation
> > > profiles to upstream channels
> > >
> > >
> > >David,
> > >
> > >I agree with all of your clearly legal/illegal combinations.  Among
the
> > >four that cause you consternation, I would break them done like
this:
> > >
> > >illegal:
> > >tdma, atdma
> > >atdma, tdma
> > >
> > >potentially legal:
> > >tdma, tdmaAndAtdma
> > >atdma, tdmaAndAtdma
> > >
> > >An atdma modulation profile will include IUCs 1,3,4,9,10, and
possibly
> 11,
> > >so cannot be used for a tdma channel. Similarly a tdma modulation
profile
> > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma
channel.
> > >
> > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10,
and
> > >possibly 11, so could potentially be used for a tdma or an atdma
channel
> > >(in addition to a tdmaAndAtdma channel), as long as the CMTS
ignored the
> > >IUCs that don't apply to the channel type.  I'm not sure that the
> > >advantages of that flexibility outweigh the disadvantages of having
the
> > >MIB reporting something that doesn't exactly reflect what is
> > >configured.  Perhaps it is simpler just to require that
ModChannelType
> > >match UpChannelType.
> > >
> > >-Greg
> > >
> > >
> > >  ----Original Message-----
> > >From: David.White@arrisi.com [mailto:David.White@arrisi.com]
> > >Sent: Tuesday, August 19, 2003 9:37 AM
> > >To: DOCSIS OSS Majordomo List
> > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to
upstream
> > >channels
> > >
> > >
> > >DOCSIS 2.0 Community,
> > >        It seems that the DocsisUpstreamType objects in both the
> > > modulation profile table and the upstream channel table exist, in
part,
> > > to provide the equipment vendor a way to cross-check the data for
> > > consistency. Furthermore, it would seem possible to compare the
two
> > > DocsisUpstreamType objects when assigning an upstream to a
modulation
> > > profile to make sure the assignment is compatible. For instance,
the
> > > following combination of docsIfUpChannelType,
docsIfCmtsModChannelType
> > > would clearly be illegal:
> > >
> > >scdma, tdma
> > >scdma, atdma
> > >scdma, tdmaAndAtdma
> > >
> > >tdma, scdma
> > >atdma, scdma
> > >tdmaAndAtdma, scdma
> > >
> > >
> > >It is also pretty clear the following are legal:
> > >
> > >tdma, tdma
> > >atdma, atdma
> > >scdma, scdma
> > >tdmaAndAtdma, tdmaAndAtdma
> > >
> > >
> > >However, it is the following cases that are causing me
consternation:
> > >
> > >tdma, atdma
> > >tdma, tdmaAndAtdma
> > >atdma, tdma
> > >atdma, tdmaAndAtdma
> > >
> > >
> > >If ALL of these are legal, then I do not understand the point of
> > >tdmaAndAtdma, other than to cause confusion, especially for
modulation
> > >profiles.
> > >
> > >Thanks,
> > >David White
> > >ARRIS Cadant C4 CMTS
> >
>
>
>

--=_alternative 007467A785256DB9_=-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Oct 8 19:37:22 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 TAA15051 for ; Wed, 8 Oct 2003 19:37:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Nra-0001cW-ID for ipcdn-archive@odin.ietf.org; Wed, 08 Oct 2003 19:37:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Nb2ll006219 for ipcdn-archive@odin.ietf.org; Wed, 8 Oct 2003 19:37:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NrZ-0001bx-GU; Wed, 08 Oct 2003 19:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Nql-0001Uz-QO for ipcdn@optimus.ietf.org; Wed, 08 Oct 2003 19:36:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14979 for ; Wed, 8 Oct 2003 19:36:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Nqj-0005wy-00 for ipcdn@ietf.org; Wed, 08 Oct 2003 19:36:09 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A7Nqi-0005w3-00 for ipcdn@ietf.org; Wed, 08 Oct 2003 19:36:08 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h98NZR10020055; Wed, 8 Oct 2003 17:35:27 -0600 (MDT) 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_01C38DF4.DA782133" Date: Wed, 8 Oct 2003 17:35:27 -0600 Message-ID: Thread-Topic: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcON4McUIpnLZP31SUW9kUe6SGU4bwAEfM0g From: "Greg White" To: Cc: "DOCSIS OSS Majordomo List" , , , , "Minnie Lu" X-Approved: ondar Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) 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_01C38DF4.DA782133 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David, =20 According to the proposed text, docsIfUpChannelType would be read-only for ALL rows. =20 =20 For "active" rows (docsIfUpChannelStatus =3D active(1)) setting UpChannelModulationProfile would return an error if the channel type of the profile does not work with the other parameters in the row. =20 =20 For "cloned" rows (docsIfUpChannelStatus =3D notInService(2)) no verification is done on consistency of parameters until docsIfUpChannelUpdate is set to true. =20 The verification for active rows is indicated in the proposed text for UpChannelModulationProfile, although it looks like it could be clarified:=20 =20 Setting this object on an "active" row MUST return an error if the following=20 conditions are not satisfied: 1. All the IUC entries in the selected modulation profile=20 MUST have the same value of docsIfCmtsModChannelType.=20 2. All of the modulation parameters in the selected=20 modulation profile MUST be consistent with the other=20 parameters in this docsIfUpChannelEntry.=20 =20 Does that address your concern? =20 -Greg =20 -----Original Message----- From: David.White@arrisi.com [mailto:David.White@arrisi.com]=20 Sent: Wednesday, October 08, 2003 3:11 PM To: Greg White Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) =09 =09 Greg,=20 Per your earlier e-mail on this thread:=20 =09 "Also, I would like to propose that we make docsIfUpChannelType a read-only object for active rows in the Upstream Channel Table.=20 The value reported would be taken from the modulation profile pointed=20 to by docsIfUpChannelModulationProfile."=20 =09 I'm assuming "active" mean in-service. Otherwise, we have to be careful with this because the channelType is used to verify things like channelWidth and whether or not setting of the scdma-specific parameters is allowed. Along the same lines, if setting the upstream modulation profile index implies that the SNMP agent changes the upChannelType to match the modProfChannelType, then the agent must also verify that all of the other parameters in the upstream channel are compatible with the possibly new channel type.=20 =09 David=20 =20 =09 =09 =09 "Greg White" =20 10/08/2003 04:12 PM=20 =20 To: "Minnie Lu" =20 cc: , "DOCSIS OSS Majordomo List" , , , =20 Fax to: =20 Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Minnie, =09 I didn't want to prevent a user from changing their mind regarding channel type when creating a new modulation profile. Suppose you started out setting channel type to atdma and, after completing a few IUCs, realized that you really wanted tdmaAndAtdma. Rather than make you start from scratch (or do a simultaneous set across all IUCs), you could just update the channel type on each row. =09 I understand your view as well. =20 =09 If there is a consensus to change the text, I am not strongly opposed. =09 -Greg =09 -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Wednesday, October 08, 2003 12:48 PM To: Greg White Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) =09 =09 Hi, Greg, =09 Thanks a lot to you and Eduardo for this proposal ! =09 docsIfCmtsModChannelType : "... In order to be considered a valid modulation profile for assignment to an upstream channel, all entries (IUCs) in the modulation profile must have the same channel type." =09 In addition to do the checking at the time the modulation profile is=20 assigned to some upstream, I think that the checking could also be done=20 when user create/modify an entry of docsIfCmtsModulationEntry even the=20 modulation profile is not assigned to any upstreams. So the error could be=20 caught earlier. So I would suggest to enhance the description as the ECO=20 (OSS2-O-03092) =09 "All the entries in a modulation profile (i.e. all entries that share a=20 common docsIfCmtsModIndex) MUST have the same value of=20 docsIfCmtsModChannelType." =09 If I miss anything, please let me know. Thanks a lot! Minnie =09 At 04:22 PM 10/7/2003 -0600, Greg White wrote: >All, > >As a final issue to resolve in the RFMIBv2 before draft-08, I would like=20 >to propose that we complete the clarification of the relationship between=20 >the ChannelType parameters in modulation profiles and upstream channels. > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which=20 >clarifies part of the relationship by adding requirements to the OSSI=20 >spec. I would like to suggest that we propagate those requirements to the=20 >MIB descriptions. > >Also, I would like to propose that we make docsIfUpChannelType a read-only=20 >object for active rows in the Upstream Channel Table. The value reported=20 >would be taken from the modulation profile pointed to by=20 >docsIfUpChannelModulationProfile. > >Attached is a detailed proposal that Eduardo and I wrote to frame the issue. > >In order not to delay draft-08, we would like to have consensus from=20 the=20 >community and working group by this Friday, October 10. Please review the=20 >attached proposal and provide comments. > >Many thanks, >Greg >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Monday, August 25, 2003 5:59 PM >To: Minnie Lu >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White;=20 >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to=20 >upstream channels > >Minnie, > I am emphathetic to your concerns. I ran across the same issue =09 > while implementing cross-checks for the 2.0 modulation and upstream data.=20 > I found it made the code far simpler to lead the user down the path of =09 > "define the channel type first, then build everything around that" kind=20 > of configuration model. I am then able to check the settings of the other=20 > parameters against the channel type. After a modulation profile or=20 > upstream channel has already been provisioned, changing just the channel=20 > type becomes difficult, as many parameters are incompatible with other =09 > channel types. I allow it, but don't recommend it. > >My 2 cents, >David > > > > > >Minnie Lu > >08/25/2003 07:01 PM > > To: "Greg White" > cc: , "Minnie Lu"=20 > , , , =09 > "DOCSIS OSS Majordomo List" , "Owner DOCSIS OSS=20 > Majordomo List" > Fax to: > Subject: RE: DOCSIS 2.0 : rules for assigning modulation=20 > profiles to upstream channels > > > > > >Hi, Greg, > > Please see my response inline. > Thanks a lot ! > Minnie >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > >The email exchange between Steve and Alberto notwithstanding, I think it > >does make sense to enforce that all entries in a modulation profile (i.e. > >all entries that share a common docsIfCmtsModIndex) have the same > >ModChannelType. Also, based on the exchange here it seems that there is > >some support for the additional restriction that UpChannelType and > >ModChannelType always match. With those two restrictions, there clearly > >is a need for all defined values of ModChannelType. > > > >Since this has been a point of confusion at least twice now, does anyone > >have a concern with making these two items part of the specification? > > > >[milu]: I agree with you. > > >A further point, how does the CMTS enforce the match between UpChannelType > >and ModChannelType? One implementation may automatically change > >UpChannelType to match ModChannelType whenever > >docsIfUpChannelModulationProfile is set. Another might reject the change > >if the two don't already match, and require the use of the > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd argue > >that the first implementation makes more sense, and ought to be made a > >SHOULD in the spec, but I'd like to hear other views. > > > >[milu]: I think this needs to be thought over carefully. How about the >case that some modulation profile is used by some upstream channel, and >user change the modulation profile channel type ? Does it mean that the >upstream channel type would be changed automatically, too ? If yes, I am >afraid that there might be some user who forget the modulation profile is >being used and change the channel type without knowing the upstream channel >type for some upstream channels are changed at the same time. The >modulation profile channel type and upstream channel type are in two >different MIB tables. > > Actually, I am always puzzled when the modulation profile is being used >by some upstream channels, could the modulation profile channel type be >changed ? Maybe this is a confusing point which needs to be clarified,=20 too. > > Thanks a lot for your help ! > Minnie > > > > > > >-Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 11:07 AM > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner DOCSIS > >OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > Sounds good to me. This would make verifying the consistency of > > the data in the modulation profiles and the upstream channels far easier. > >So, if I understand correctly, this means that all modulation profile > >entries with the same docsIfCmtsModIndex will have to have the same > >docsIfCmtsModChannelType. Otherwise, you would not be able to use that > >modulation profile set on any upstream channel. So, this modulation > >profile set with different docsIfCmtsModChannelTypes from an e-mail thread > >between Alberto and Steve from almost a year ago would be invalid, no ? > >The way to patch it up would be to make all of the IUCs tdmaAndAtdma, > >correct ? > > > >Thanks, > >David > > > >--- end David's e-mail --- > >--- start e-mail exchange between Alberto and Steve --- > > > >Hi Steve > > > >Sorry for the delay in responding > > > >Your configuration settings for operation in multiple mode is correct and > >will support tdma, tdmaAndAtdma and Atdma. > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with UCD > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and IUCs > >5&6 are not used. Your interpretation of the spec in the example described > >is accurate. > > > >Alberto Campos > >a.campos@cablelabs.com > > > > > > > > > > > >-----Original Message----- > >From: Steve Malenfant [mailto:smalenfant@com21.com] > >Sent: Monday, September 30, 2002 9:39 AM > >To: 'docsis-20@cablelabs.com' > >Subject: Correlation between docsIfUpChannelType and > >docsIfCmtsModChannelT ype > > > > > > > >We are having some discussion internally here, and would like to clarify > >things about the modulation profile. > >Let's take an example, expecting all parameters are good : > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > >set IUC 5 docsIfCmtsModChannelType to tdma. > >set IUC 6 docsIfCmtsModChannelType to tdma. > >set IUC 9 docsIfCmtsModChannelType to Atdma. > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > >Would this burst profile be good for docsIfUpChannelType tdma, tdmaAndAtdma > >and Atdma? > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 inside > >UCD type 2. > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. > > > > > > > > > > > >Minnie Lu > >Sent by: owner-docsis-oss@cablelabs.com > > > >08/21/2003 07:15 PM > > > > To: David.White@arrisi.com, "Greg White" > > > > cc: "DOCSIS OSS Majordomo List" > > , milu@cisco.com > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, David and Greg, > > > > I like Greg's "Perhaps it is simpler just to require that ModChannelType > >match UpChannelType.". > >=20 > > I don't think that "we could just drop tdmaAndAtdma for > >ModChannelType". Please keep in mind that when assigning the modulation > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, it uses > >only the docsIfModIndex and only one docsIfModIndex can be assigned to some > >upstream channel. > > > > If I miss anything, please correct me. > > Thanks! > > Minnie > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > >Greg, > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma channels. > > > However, the modulation profiles objects > > > docsIfCmtsModByteInterleaverBlockSize and > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma channels. So, > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these objects=20 > set, > > > it assumably could not be used on a tdma-only upstream channel. Hence, > > > the whole purpose of even having ModChannelType - to verify consistency > > > within the modulation profile - is weakened. This has the unintended=20 > side > > > effect of requiring any assignment of modulation profiles with IUCs=20 > 1, 2, > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see if the > > > Interleaver parameters have been set before assigning it to a tdma-only > > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation > > profiles. > > > I can't think of any need/requirement for tdmaAndAtdma for > > > modulation profiles that could not be met with a pair of tdma and atdma > > > modulation profile. In other words, I don't think allowing tdmaAndAtdma > > > for ModChannelType really buys us anything. I'm thinking we could just > > > drop tdmaAndAtdma for ModChannelType (making it a > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of confusion. > > > For the mixed-mode channels, where UpChannelType is=20 > tdmaAndAtdma, > > > the modulation profile set could look like so: > > > > > >IUC 1 tdma > > >IUC 2 tdma > > >IUC 3 tdma > > >IUC 4 tdma > > >IUC 5 tdma > > >IUC 6 tdma > > >IUC 9 atdma > > >IUC 10 atdma > > >IUC 11 atdma > > > > > >For tdma-only upstream channels, the modulation profile set could be: > > > > > >IUC 1 tdma > > >IUC 2 tdma > > >IUC 3 tdma > > >IUC 4 tdma > > >IUC 5 tdma > > >IUC 6 tdma > > > > > >Likewise, for atdma-only upstream channel, the modulation profile set > > >could be: > > > > > >IUC 1 atdma > > >IUC 2 atdma > > >IUC 3 atdma > > >IUC 4 atdma > > >IUC 9 atdma > > >IUC 10 atdma > > >IUC 11 atdma > > > > > >As far as I know, there is no hard limit on the number of the modulation > > >profile sets that the CMTS and CM can support. I'm really liking your=20 > "not > > >sure the benefits of flexibility outweigh disadvantages..." line of > > >thinking. tdmaAndAtdma for modulation profiles has my head spinning. > > > > > >Thanks, > > >David > > > > > > > > > > > >"Greg White" > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/20/2003 07:35 PM > > > > > > To: , "DOCSIS OSS Majordomo List" > > > > > > cc: > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning modulation > > > profiles to upstream channels > > > > > > > > >David, > > > > > >I agree with all of your clearly legal/illegal combinations. Among the > > >four that cause you consternation, I would break them done like this: > > > > > >illegal: > > >tdma, atdma > > >atdma, tdma > > > > > >potentially legal: > > >tdma, tdmaAndAtdma=20 > > >atdma, tdmaAndAtdma > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and possibly=20 > 11, > > >so cannot be used for a tdma channel. Similarly a tdma modulation profile > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma channel. > > > > > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10, and > > >possibly 11, so could potentially be used for a tdma or an atdma channel > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS ignored the > > >IUCs that don't apply to the channel type. I'm not sure that the > > >advantages of that flexibility outweigh the disadvantages of having the > > >MIB reporting something that doesn't exactly reflect what is > > >configured. Perhaps it is simpler just to require that ModChannelType > > >match UpChannelType. > > > > > >-Greg > > > > > > > > > ----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Tuesday, August 19, 2003 9:37 AM > > >To: DOCSIS OSS Majordomo List > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to upstream > > >channels > > > > > > > > >DOCSIS 2.0 Community, > > > It seems that the DocsisUpstreamType objects in both the > > > modulation profile table and the upstream channel table exist, in part, > > > to provide the equipment vendor a way to cross-check the data for > > > consistency. Furthermore, it would seem possible to compare the two > > > DocsisUpstreamType objects when assigning an upstream to a modulation > > > profile to make sure the assignment is compatible. For instance, the > > > following combination of docsIfUpChannelType, docsIfCmtsModChannelType > > > would clearly be illegal: > > > > > >scdma, tdma > > >scdma, atdma > > >scdma, tdmaAndAtdma > > > > > >tdma, scdma > > >atdma, scdma > > >tdmaAndAtdma, scdma > > > > > > > > >It is also pretty clear the following are legal: > > > > > >tdma, tdma > > >atdma, atdma > > >scdma, scdma > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > >However, it is the following cases that are causing me consternation: > > > > > >tdma, atdma > > >tdma, tdmaAndAtdma > > >atdma, tdma > > >atdma, tdmaAndAtdma > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > >tdmaAndAtdma, other than to cause confusion, especially for modulation > > >profiles. > > > > > >Thanks, > > >David White > > >ARRIS Cadant C4 CMTS > > > > > =09 =09 =09 =09 ------_=_NextPart_001_01C38DF4.DA782133 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
David,
 
According to the proposed text, = docsIfUpChannelType=20 would be read-only for ALL rows. 
 
For=20 "active" rows (docsIfUpChannelStatus =3D active(1)) setting=20 UpChannelModulationProfile would return an error if the channel type of = the=20 profile does not work with the other parameters in the row. =20
 
For=20 "cloned" rows (docsIfUpChannelStatus =3D notInService(2)) no = verification is done=20 on consistency of parameters until docsIfUpChannelUpdate is set to=20 true.
 
The=20 verification for active rows is indicated in the proposed text = for=20 UpChannelModulationProfile, although it looks like it could be = clarified:
 
       &nbs= p;    =20 Setting this object on an "active" row MUST return an error if the = following=20
           &nb= sp;=20 conditions are not=20 satisfied:
          = ;  =20 1. All the IUC entries in the selected modulation profile=20
           &nb= sp;=20 MUST have the same value of docsIfCmtsModChannelType.=20
           &nb= sp; 2.=20 All of the modulation parameters in the selected=20
           &nb= sp;=20 modulation profile MUST be consistent with the other=20
           &nb= sp;=20 parameters in this docsIfUpChannelEntry.=20
 
Does=20 that address your concern?
 
-Greg
 
-----Original Message-----
From:=20 David.White@arrisi.com [mailto:David.White@arrisi.com] =
Sent:=20 Wednesday, October 08, 2003 3:11 PM
To: Greg = White
Cc:=20 DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org;=20 Larry.Spaete@arrisi.com; Minnie Lu
Subject: RE: Channel = Types in=20 RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles = to=20 upstream channels)


Greg,
  =    =20   Per your earlier e-mail on this thread:

"Also, I would=20 like to propose that we make docsIfUpChannelType a
read-only object = for=20 active rows in the Upstream Channel Table.
The value reported would be taken from the modulation profile = pointed
to by=20 docsIfUpChannelModulationProfile."

I'm assuming "active" mean in-service. Otherwise, we have to = be careful=20 with this because the channelType is used to verify things like = channelWidth=20 and whether or not setting of the scdma-specific parameters is = allowed. Along=20 the same lines, if setting the upstream modulation profile index = implies that=20 the SNMP agent changes the upChannelType to match the = modProfChannelType, then=20 the agent must also verify that all of the other parameters in the = upstream=20 channel are compatible with the possibly new channel type.=20

David
       


"Greg White"=20 <g.white@CableLabs.com>=20

10/08/2003 04:12 PM =

        =
        To: =    =20    "Minnie Lu" <milu@cisco.com>
        cc: =    =20    <David.White@arrisi.com>, "DOCSIS OSS = Majordomo List"=20 <docsis-oss@CableLabs.com>, = <Greg.Gohman@arrisi.com>,=20 <Larry.Spaete@arrisi.com>, <ipcdn@ietf.org> =
        Fax to: =    =20    
  =  =20     Subject:        RE: Channel = Types in=20 RFMIBv2  (was RE: DOCSIS 2.0 : rules for  assigning = modulation=20 profiles to upstream = channels)



Minnie,

I didn't want to prevent = a user from=20 changing their mind regarding
channel type when creating a new = modulation=20 profile.  Suppose you
started out setting channel type to = atdma and,=20 after completing a few
IUCs, realized that you really wanted = tdmaAndAtdma.=20  Rather than make
you start from scratch (or do a simultaneous = set=20 across all IUCs), you
could just update the channel type on each=20 row.

I understand your view as well.  

If there is = a=20 consensus to change the text, I am not strongly=20 opposed.

-Greg

-----Original Message-----
From: = Minnie Lu=20 [mailto:milu@cisco.com]
Sent: Wednesday, October 08, 2003 12:48 = PM
To:=20 Greg White
Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS = Majordomo=20 List;
Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com;=20 ipcdn@ietf.org
Subject: Re: Channel Types in RFMIBv2 (was RE: = DOCSIS 2.0 :=20 rules for
assigning modulation profiles to upstream=20 channels)


Hi, Greg,

 Thanks a lot to you and = Eduardo=20 for this proposal !

docsIfCmtsModChannelType :
  = "...
 =20   In order to be considered a valid modulation profile = for
 =20   assignment to an upstream channel, all entries (IUCs) = in
 =20     the modulation profile must have the same channel=20 type."

  In addition to do the checking at the time the = modulation=20 profile is
assigned to some upstream, I think that the checking = could also=20 be done
when user create/modify an entry of = docsIfCmtsModulationEntry even=20 the
modulation profile is not assigned to any upstreams.  So = the=20 error could
be
caught earlier.   So I would suggest to = enhance the=20 description as the
ECO
(OSS2-O-03092)

"All the entries = in a=20 modulation profile (i.e. all entries that share a
common=20 docsIfCmtsModIndex) MUST have the same value of=20
docsIfCmtsModChannelType."

If I miss anything, please let = me=20 know.
Thanks a lot!
Minnie

At 04:22 PM 10/7/2003 -0600, = Greg=20 White wrote:
>All,
>
>As a final issue to resolve in = the=20 RFMIBv2 before draft-08, I would
like
>to propose that we = complete=20 the clarification of the relationship
between
>the = ChannelType=20 parameters in modulation profiles and=20 upstream
channels.
>
>There is currently an ECO = (OSS2-O-03092)=20 written by Minnie Lu which
>clarifies part of the relationship = by=20 adding requirements to the OSSI
>spec.  I would like to = suggest=20 that we propagate those requirements to
the
>MIB=20 descriptions.
>
>Also, I would like to propose that we = make=20 docsIfUpChannelType a
read-only
>object for active rows in = the=20 Upstream Channel Table.  The value
reported
>would be = taken=20 from the modulation profile pointed to by=20
>docsIfUpChannelModulationProfile.
>
>Attached is a = detailed proposal that Eduardo and I wrote to frame=20 the
issue.
>
>In order not to delay draft-08, we would = like to=20 have consensus from
the =
>community and working group by this Friday, October 10. =  Please=20 review
the
>attached proposal and provide=20 comments.
>
>Many thanks,
>Greg
>-----Original = Message-----
>From: David.White@arrisi.com=20 [mailto:David.White@arrisi.com]
>Sent: Monday, August 25, 2003 = 5:59=20 PM
>To: Minnie Lu
>Cc: DOCSIS OSS Majordomo List;=20 Greg.Gohman@arrisi.com; Greg White;
>Larry.Spaete@arrisi.com; = Minnie=20 Lu; Owner DOCSIS OSS Majordomo List
>Subject: RE: DOCSIS 2.0 : = rules for=20 assigning modulation profiles to
>upstream=20 channels
>
>Minnie,
>         I = am=20 emphathetic to your concerns. I ran across the same issue

> = while=20 implementing cross-checks for the 2.0 modulation and upstream
data. =
> I found it made the code far simpler to lead the user down = the path=20 of

> "define the channel type first, then build everything = around=20 that"
kind
> of configuration model. I am then able to check = the=20 settings of the
other
> parameters against the channel type. = After a=20 modulation profile or
> upstream channel has already been = provisioned,=20 changing just the
channel
> type becomes difficult, as many=20 parameters are incompatible with other

> channel types. I = allow it,=20 but don't recommend it.
>
>My 2=20 = cents,
>David
>
>
>
>
>
>Minnie= Lu=20 <milu@cisco.com>
>
>08/25/2003 07:01 = PM
>
>=20         To:        "Greg = White"=20 <g.white@CableLabs.com>
>         cc: =  =20      <David.White@arrisi.com>, "Minnie Lu" =
>=20 <milu@cisco.com>, <Greg.Gohman@arrisi.com>,=20 <Larry.Spaete@arrisi.com>,

> "DOCSIS OSS Majordomo = List"=20 <docsis-oss@CableLabs.com>, "Owner DOCSIS
OSS
> = Majordomo=20 List" <owner-docsis-oss@CableLabs.com>
>     =  =20   Fax to:
>         Subject:   =  =20    RE: DOCSIS 2.0 : rules for assigning
modulation =
>=20 profiles to   upstream=20 channels
>
>
>
>
>
>Hi,=20 Greg,
>
>  Please see my response inline.
>=20  Thanks a lot !
>  Minnie
>At 02:29 PM 8/25/2003 = -0600,=20 Greg White wrote:
> >The email exchange between Steve and = Alberto=20 notwithstanding, I think
it
> >does make sense to enforce = that all=20 entries in a modulation profile
(i.e.
> >all entries that = share a=20 common docsIfCmtsModIndex) have the same
> >ModChannelType.=20  Also, based on the exchange here it seems that = there
is
>=20 >some support for the additional restriction that UpChannelType = and
>=20 >ModChannelType always match.  With those two restrictions,=20 there
clearly
> >is a need for all defined values of=20 ModChannelType.
> >
> >Since this has been a point = of=20 confusion at least twice now, does
anyone
> >have a = concern with=20 making these two items part of the specification?
>=20 >
>
>[milu]: I agree with you.
>
> >A = further=20 point, how does the CMTS enforce the match = between
UpChannelType
>=20 >and ModChannelType?  One implementation may automatically=20 change
> >UpChannelType to match ModChannelType = whenever
>=20 >docsIfUpChannelModulationProfile is set.  Another might = reject=20 the
change
> >if the two don't already match, and require = the use=20 of the
> >docsIfUpChannelCloneFrom mechanism to change the = channel=20 type.  I'd
argue
> >that the first implementation = makes more=20 sense, and ought to be made
a
> >SHOULD in the spec, but = I'd like=20 to hear other views.
> >
>
>[milu]: I think this = needs to=20 be thought over carefully.  How about the
>case that some=20 modulation profile is used by some upstream channel, and
>user = change=20 the modulation profile channel type ?  Does it mean=20 that
the
>upstream channel type would be changed = automatically, too ?=20  If yes, I
am
>afraid that there might be some user who = forget=20 the modulation profile
is
>being used and change the channel = type=20 without knowing the upstream
channel
>type for some upstream = channels=20 are changed at the same time.  The
>modulation profile = channel type=20 and upstream channel type are in two
>different MIB=20 tables.
>
>   Actually, I am always puzzled when the=20 modulation profile is being
used
>by some upstream channels, = could=20 the modulation profile channel type be
>changed ?  Maybe = this is a=20 confusing point which needs to be clarified,
too.
>
>   Thanks a lot = for your=20 help !
>   = Minnie
>
>
>
>
>
>=20 >-Greg
> >-----Original Message-----
> >From:=20 David.White@arrisi.com [mailto:David.White@arrisi.com]
> = >Sent:=20 Monday, August 25, 2003 11:07 AM
> >To: Minnie Lu;=20 Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com
> >Cc: DOCSIS = OSS=20 Majordomo List; Greg White; milu@cisco.com; Owner
DOCSIS
> = >OSS=20 Majordomo List
> >Subject: RE: DOCSIS 2.0 : rules for = assigning=20 modulation profiles to
> >upstream channels
> = >
>=20 >Minnie,
> >         Sounds good to = me. This=20 would make verifying the consistency
of
> > the data in = the=20 modulation profiles and the upstream channels far
easier.
> = >So,=20 if I understand correctly, this means that all modulation = profile
>=20 >entries with the same docsIfCmtsModIndex will have to have the=20 same
> >docsIfCmtsModChannelType. Otherwise, you would not be = able to=20 use
that
> >modulation profile set on any upstream = channel. So,=20 this modulation
> >profile set with different=20 docsIfCmtsModChannelTypes from an e-mail
thread
> >between = Alberto=20 and Steve from almost a year ago would be invalid, no
?
> = >The way=20 to patch it up would be to make all of the IUCs tdmaAndAtdma,
>=20 >correct ?
> >
> >Thanks,
> = >David
>=20 >
> >--- end David's e-mail ---
> >--- start = e-mail=20 exchange between Alberto and Steve ---
> >
> >Hi=20 Steve
> >
> >Sorry for the delay in = responding
>=20 >
> >Your configuration settings for operation in multiple = mode is=20 correct
and
> >will support tdma, tdmaAndAtdma and = Atdma.
>=20 >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is = used=20 with
UCD
> >type 2 and in DOCSIS 2.0 only case TLV 5 is = used with=20 UCD type 29 and
IUCs
> >5&6 are not used. Your = interpretation=20 of the spec in the example
described
> >is = accurate.
>=20 >
> >Alberto Campos
> = >a.campos@cablelabs.com
>=20 >
> >
> >
> >
> >
>=20 >-----Original Message-----
> >From: Steve Malenfant=20 [mailto:smalenfant@com21.com]
> >Sent: Monday, September 30, = 2002=20 9:39 AM
> >To: 'docsis-20@cablelabs.com'
> >Subject: = Correlation between docsIfUpChannelType and
> = >docsIfCmtsModChannelT=20 ype
> >
> >
> >
> >We are having = some=20 discussion internally here, and would like to
clarify
> = >things=20 about the modulation profile.
> >Let's take an example, = expecting all=20 parameters are good :
> >
> >set IUC 1=20 docsIfCmtsModChannelType to tdmaAndAtdma.
> >set IUC 3=20 docsIfCmtsModChannelType to tdmaAndAtdma.
> >set IUC 4=20 docsIfCmtsModChannelType to tdmaAndAtdma.
> >set IUC 5=20 docsIfCmtsModChannelType to tdma.
> >set IUC 6=20 docsIfCmtsModChannelType to tdma.
> >set IUC 9=20 docsIfCmtsModChannelType to Atdma.
> >set IUC 10=20 docsIfCmtsModChannelType to Atdma.
> >
> >Would this = burst=20 profile be good for docsIfUpChannelType tdma,
tdmaAndAtdma
> = >and=20 Atdma?
> >
> >tdma would only use IUC 1,3,4,5 and 6 = in TLV 4=20 inside UCD type 2.
> >mixed would use IUC 1,3,4,5 and 6 in = TLV 4 and=20 IUC 9 and 10 in TLV 5
inside
> >UCD type 2.
> = >Atdma=20 would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29.
> = >
> >
> >
> >
> >
> = >Minnie Lu=20 <milu@cisco.com>
> >Sent by:=20 owner-docsis-oss@cablelabs.com
> >
> >08/21/2003 = 07:15=20 PM
> >
> >         To:   =  =20    David.White@arrisi.com, "Greg White"
> >=20 <g.white@cablelabs.com>
> >         = cc:=20        "DOCSIS OSS Majordomo List"
> >=20 <docsis-oss@cablelabs.com>, milu@cisco.com
> >   =  =20     Fax to:
> >         = Subject:  =20      RE: DOCSIS 2.0 : rules for = assigning
modulation
>=20 > profiles to  upstream channels
> >
> = >
>=20 >
> >
> >
> >Hi, David and Greg,
> = >
> >  I like Greg's "Perhaps it is simpler just to = require=20 that
ModChannelType
> >match UpChannelType.".
> = >=20
> >  I don't think = that "we=20 could just drop tdmaAndAtdma for
> >ModChannelType". =  Please=20 keep in mind that when assigning the
modulation
> >profile = to some=20 upstream via SNMP docsIfUpChannelModulationProfile,
it uses
> = >only the docsIfModIndex and only one docsIfModIndex can be = assigned
to=20 some
> >upstream channel.
> >
> >  If = I miss=20 anything, please correct me.
> >  Thanks!
> >=20  Minnie
> >
> >At 10:53 AM 8/21/2003 -0400,=20 David.White@arrisi.com wrote:
> >
> > = >Greg,
> >=20 >         IUCs 1, 2, 3, and 4 are used for both = tdma=20 and atdma
channels.
> > > However, the modulation = profiles=20 objects
> > > docsIfCmtsModByteInterleaverBlockSize = and
>=20 > > docsIfCmtsModByteInterleaverDepth are only valid for=20 atdma
channels. So,
> > > if a modulation profile with = IUCs 1,=20 2, 3 and/or 4 had these
objects
> set,
> > > it=20 assumably could not be used on a tdma-only upstream = channel.
Hence,
>=20 > > the whole purpose of even having ModChannelType - to=20 verify
consistency
> > > within the modulation profile = - is=20 weakened. This has the
unintended
> side
> > > = effect of=20 requiring any assignment of modulation profiles with
IUCs
> = 1,=20 2,
> > > 3, and 4 and ModChannelType equal to tdmaAndAtdma = to=20 check to see
if the
> > > Interleaver parameters have = been set=20 before assigning it to a
tdma-only
> > > upstream = channel.=20 Hence, my gripe with tdmaAndAtdma for modulation
> >=20 profiles.
> > >         I can't think = of any=20 need/requirement for tdmaAndAtdma for
> > > modulation = profiles=20 that could not be met with a pair of tdma and
atdma
> > = >=20 modulation profile. In other words, I don't think=20 allowing
tdmaAndAtdma
> > > for ModChannelType really = buys us=20 anything. I'm thinking we could
just
> > > drop = tdmaAndAtdma=20 for ModChannelType (making it a
> > > = DocsisUpstreamTypeStatus=20 object, perhaps ?) to avoid a lot of
confusion.
> > > =  =20       For the mixed-mode channels, where UpChannelType = is=20
> tdmaAndAtdma,
> > > the modulation profile set = could look=20 like so:
> > >
> > >IUC  1 =  tdma
>=20 > >IUC  2  tdma
> > >IUC  3=20  tdma
> > >IUC  4  tdma
> > = >IUC=20  5  tdma
> > >IUC  6  tdma
> = >=20 >IUC  9 atdma
> > >IUC 10 atdma
> > = >IUC 11=20 atdma
> > >
> > >For tdma-only upstream = channels, the=20 modulation profile set could
be:
> > >
> > = >IUC 1=20 tdma
> > >IUC 2 tdma
> > >IUC 3 tdma
> = >=20 >IUC 4 tdma
> > >IUC 5 tdma
> > >IUC 6 = tdma
>=20 > >
> > >Likewise, for atdma-only upstream channel, = the=20 modulation profile
set
> > >could be:
> > = >
>=20 > >IUC  1 atdma
> > >IUC  2 atdma
> = >=20 >IUC  3 atdma
> > >IUC  4 atdma
> > = >IUC=20  9 atdma
> > >IUC 10 atdma
> > >IUC 11=20 atdma
> > >
> > >As far as I know, there is no = hard=20 limit on the number of the
modulation
> > >profile sets = that=20 the CMTS and CM can support. I'm really liking
your
> = "not
>=20 > >sure the benefits of flexibility outweigh disadvantages..." = line=20 of
> > >thinking. tdmaAndAtdma for modulation profiles has = my=20 head
spinning.
> > >
> > >Thanks,
> = >=20 >David
> > >
> > >
> > = >
> >=20 >"Greg White" <g.white@cablelabs.com>
> > >Sent = by:=20 owner-docsis-oss@cablelabs.com
> > >
> > = >08/20/2003=20 07:35 PM
> > >
> > >       =   To:=20        <David.White@arrisi.com>, "DOCSIS OSS = Majordomo
List"
> > > = <docsis-oss@cablelabs.com>
>=20 > >         cc:
> > >   =  =20     Fax to:
> > >         = Subject:=20        RE: DOCSIS 2.0 : rules for=20 assigning
modulation
> > > profiles to upstream=20 channels
> > >
> > >
> > = >David,
>=20 > >
> > >I agree with all of your clearly = legal/illegal=20 combinations.  Among
the
> > >four that cause you=20 consternation, I would break them done like
this:
> > = >
>=20 > >illegal:
> > >tdma, atdma
> > >atdma, = tdma
> > >
> > >potentially legal:
> = >=20 >tdma, tdmaAndAtdma
> >=20 >atdma, tdmaAndAtdma
> > >
> > >An atdma = modulation=20 profile will include IUCs 1,3,4,9,10, and
possibly
> = 11,
>=20 > >so cannot be used for a tdma channel. Similarly a tdma=20 modulation
profile
> > >will include IUCs 1,3,4,5,6, so = cannot=20 be used for an atdma
channel.
> > >
> > >A=20 tdmaAndAtdma modulation profile will include IUCs=20 1,3,4,5,6,9,10,
and
> > >possibly 11, so could = potentially be=20 used for a tdma or an atdma
channel
> > >(in addition = to a=20 tdmaAndAtdma channel), as long as the CMTS
ignored the
> > = >IUCs that don't apply to the channel type.  I'm not sure that = the
> > >advantages of that flexibility outweigh the = disadvantages=20 of having
the
> > >MIB reporting something that doesn't = exactly=20 reflect what is
> > >configured.  Perhaps it is = simpler just=20 to require that
ModChannelType
> > >match=20 UpChannelType.
> > >
> > >-Greg
> >=20 >
> > >
> > >  ----Original=20 Message-----
> > >From: David.White@arrisi.com=20 [mailto:David.White@arrisi.com]
> > >Sent: Tuesday, August = 19,=20 2003 9:37 AM
> > >To: DOCSIS OSS Majordomo List
> = >=20 >Subject: DOCSIS 2.0 : rules for assigning modulation profiles=20 to
upstream
> > >channels
> > >
> = >=20 >
> > >DOCSIS 2.0 Community,
> > >   =  =20    It seems that the DocsisUpstreamType objects in both = the
>=20 > > modulation profile table and the upstream channel table = exist,=20 in
part,
> > > to provide the equipment vendor a way to = cross-check the data for
> > > consistency. Furthermore, = it would=20 seem possible to compare the
two
> > > = DocsisUpstreamType=20 objects when assigning an upstream to a
modulation
> > = >=20 profile to make sure the assignment is compatible. For=20 instance,
the
> > > following combination of=20 docsIfUpChannelType,
docsIfCmtsModChannelType
> > > = would=20 clearly be illegal:
> > >
> > >scdma, = tdma
>=20 > >scdma, atdma
> > >scdma, tdmaAndAtdma
> = >=20 >
> > >tdma, scdma
> > >atdma, = scdma
> >=20 >tdmaAndAtdma, scdma
> > >
> > >
> = >=20 >It is also pretty clear the following are legal:
> > = >
>=20 > >tdma, tdma
> > >atdma, atdma
> > = >scdma,=20 scdma
> > >tdmaAndAtdma, tdmaAndAtdma
> > = >
>=20 > >
> > >However, it is the following cases that are = causing=20 me
consternation:
> > >
> > >tdma, = atdma
>=20 > >tdma, tdmaAndAtdma
> > >atdma, tdma
> >=20 >atdma, tdmaAndAtdma
> > >
> > >
> = >=20 >If ALL of these are legal, then I do not understand the point = of
>=20 > >tdmaAndAtdma, other than to cause confusion, especially=20 for
modulation
> > >profiles.
> > >
> = >=20 >Thanks,
> > >David White
> > >ARRIS Cadant = C4=20 CMTS
>=20 >
>
>
>



=00 ------_=_NextPart_001_01C38DF4.DA782133-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Oct 9 13:53:26 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 NAA01378 for ; Thu, 9 Oct 2003 13:53:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7eyG-0003Uk-AJ for ipcdn-archive@odin.ietf.org; Thu, 09 Oct 2003 13:53:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99Hr4K4013406 for ipcdn-archive@odin.ietf.org; Thu, 9 Oct 2003 13:53:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7eyD-0003TN-V5; Thu, 09 Oct 2003 13:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7csS-0002jV-34 for ipcdn@optimus.ietf.org; Thu, 09 Oct 2003 11:38:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24825 for ; Thu, 9 Oct 2003 11:38:47 -0400 (EDT) From: David.White@arrisi.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7csQ-00000u-00 for ipcdn@ietf.org; Thu, 09 Oct 2003 11:38:54 -0400 Received: from pluto.arrisi.com ([63.82.122.6]) by ietf-mx with esmtp (Exim 4.12) id 1A7csO-00000r-00 for ipcdn@ietf.org; Thu, 09 Oct 2003 11:38:53 -0400 To: "Greg White" Cc: "DOCSIS OSS Majordomo List" , Greg.Gohman@arrisi.com, ipcdn@ietf.org, Larry.Spaete@arrisi.com, "Minnie Lu" , owner-docsis-oss@cablelabs.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: Date: Thu, 9 Oct 2003 11:35:27 -0400 X-MIMETrack: Serialize by Router on Pluto/Antec(Release 6.0.2CF1|June 9, 2003) at 10/09/2003 11:46:31 AM, Serialize complete at 10/09/2003 11:46:31 AM Content-Type: multipart/alternative; boundary="=_alternative 0055A42085256DBA_=" Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) 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 multipart message in MIME format. --=_alternative 0055A42085256DBA_= Content-Type: text/plain; charset="us-ascii" Greg, The main problem I have with this is that it forces the CMTS to postpone data checking until possibly the very end when the modulation profile is finally assigned. That is, the user may get a wrongValue or inconsistentValue while attempting to set the modulation profile because one or more already-set parameters do not agree with the ModChannelType. What I liked about having the UpChannelType being a configurable and "active" (rather than passive) object is that the CMTS verify things like ChannelWidth, SlotSize, and the Scdma parameters as they are being set. Thus, the error is immediate and pertitent. However, what I like about your proposal is that it makes it easier to transition an upstream channel from tdma, atdma, and tdmaAndAtdma without having to change both the modulation profile and UpChannelType at the same time. I'm not rejecting your proposal, but just wanted to voice my concerns. Thanks, David "Greg White" Sent by: owner-docsis-oss@cablelabs.com 10/08/2003 07:35 PM To: cc: "DOCSIS OSS Majordomo List" , , , , "Minnie Lu" Fax to: Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) David, According to the proposed text, docsIfUpChannelType would be read-only for ALL rows. For "active" rows (docsIfUpChannelStatus = active(1)) setting UpChannelModulationProfile would return an error if the channel type of the profile does not work with the other parameters in the row. For "cloned" rows (docsIfUpChannelStatus = notInService(2)) no verification is done on consistency of parameters until docsIfUpChannelUpdate is set to true. The verification for active rows is indicated in the proposed text for UpChannelModulationProfile, although it looks like it could be clarified: Setting this object on an "active" row MUST return an error if the following conditions are not satisfied: 1. All the IUC entries in the selected modulation profile MUST have the same value of docsIfCmtsModChannelType. 2. All of the modulation parameters in the selected modulation profile MUST be consistent with the other parameters in this docsIfUpChannelEntry. Does that address your concern? -Greg -----Original Message----- From: David.White@arrisi.com [mailto:David.White@arrisi.com] Sent: Wednesday, October 08, 2003 3:11 PM To: Greg White Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Greg, Per your earlier e-mail on this thread: "Also, I would like to propose that we make docsIfUpChannelType a read-only object for active rows in the Upstream Channel Table. The value reported would be taken from the modulation profile pointed to by docsIfUpChannelModulationProfile." I'm assuming "active" mean in-service. Otherwise, we have to be careful with this because the channelType is used to verify things like channelWidth and whether or not setting of the scdma-specific parameters is allowed. Along the same lines, if setting the upstream modulation profile index implies that the SNMP agent changes the upChannelType to match the modProfChannelType, then the agent must also verify that all of the other parameters in the upstream channel are compatible with the possibly new channel type. David "Greg White" 10/08/2003 04:12 PM To: "Minnie Lu" cc: , "DOCSIS OSS Majordomo List" , , , Fax to: Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Minnie, I didn't want to prevent a user from changing their mind regarding channel type when creating a new modulation profile. Suppose you started out setting channel type to atdma and, after completing a few IUCs, realized that you really wanted tdmaAndAtdma. Rather than make you start from scratch (or do a simultaneous set across all IUCs), you could just update the channel type on each row. I understand your view as well. If there is a consensus to change the text, I am not strongly opposed. -Greg -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com] Sent: Wednesday, October 08, 2003 12:48 PM To: Greg White Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, Greg, Thanks a lot to you and Eduardo for this proposal ! docsIfCmtsModChannelType : "... In order to be considered a valid modulation profile for assignment to an upstream channel, all entries (IUCs) in the modulation profile must have the same channel type." In addition to do the checking at the time the modulation profile is assigned to some upstream, I think that the checking could also be done when user create/modify an entry of docsIfCmtsModulationEntry even the modulation profile is not assigned to any upstreams. So the error could be caught earlier. So I would suggest to enhance the description as the ECO (OSS2-O-03092) "All the entries in a modulation profile (i.e. all entries that share a common docsIfCmtsModIndex) MUST have the same value of docsIfCmtsModChannelType." If I miss anything, please let me know. Thanks a lot! Minnie At 04:22 PM 10/7/2003 -0600, Greg White wrote: >All, > >As a final issue to resolve in the RFMIBv2 before draft-08, I would like >to propose that we complete the clarification of the relationship between >the ChannelType parameters in modulation profiles and upstream channels. > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which >clarifies part of the relationship by adding requirements to the OSSI >spec. I would like to suggest that we propagate those requirements to the >MIB descriptions. > >Also, I would like to propose that we make docsIfUpChannelType a read-only >object for active rows in the Upstream Channel Table. The value reported >would be taken from the modulation profile pointed to by >docsIfUpChannelModulationProfile. > >Attached is a detailed proposal that Eduardo and I wrote to frame the issue. > >In order not to delay draft-08, we would like to have consensus from the >community and working group by this Friday, October 10. Please review the >attached proposal and provide comments. > >Many thanks, >Greg >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Monday, August 25, 2003 5:59 PM >To: Minnie Lu >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream channels > >Minnie, > I am emphathetic to your concerns. I ran across the same issue > while implementing cross-checks for the 2.0 modulation and upstream data. > I found it made the code far simpler to lead the user down the path of > "define the channel type first, then build everything around that" kind > of configuration model. I am then able to check the settings of the other > parameters against the channel type. After a modulation profile or > upstream channel has already been provisioned, changing just the channel > type becomes difficult, as many parameters are incompatible with other > channel types. I allow it, but don't recommend it. > >My 2 cents, >David > > > > > >Minnie Lu > >08/25/2003 07:01 PM > > To: "Greg White" > cc: , "Minnie Lu" > , , , > "DOCSIS OSS Majordomo List" , "Owner DOCSIS OSS > Majordomo List" > Fax to: > Subject: RE: DOCSIS 2.0 : rules for assigning modulation > profiles to upstream channels > > > > > >Hi, Greg, > > Please see my response inline. > Thanks a lot ! > Minnie >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > >The email exchange between Steve and Alberto notwithstanding, I think it > >does make sense to enforce that all entries in a modulation profile (i.e. > >all entries that share a common docsIfCmtsModIndex) have the same > >ModChannelType. Also, based on the exchange here it seems that there is > >some support for the additional restriction that UpChannelType and > >ModChannelType always match. With those two restrictions, there clearly > >is a need for all defined values of ModChannelType. > > > >Since this has been a point of confusion at least twice now, does anyone > >have a concern with making these two items part of the specification? > > > >[milu]: I agree with you. > > >A further point, how does the CMTS enforce the match between UpChannelType > >and ModChannelType? One implementation may automatically change > >UpChannelType to match ModChannelType whenever > >docsIfUpChannelModulationProfile is set. Another might reject the change > >if the two don't already match, and require the use of the > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd argue > >that the first implementation makes more sense, and ought to be made a > >SHOULD in the spec, but I'd like to hear other views. > > > >[milu]: I think this needs to be thought over carefully. How about the >case that some modulation profile is used by some upstream channel, and >user change the modulation profile channel type ? Does it mean that the >upstream channel type would be changed automatically, too ? If yes, I am >afraid that there might be some user who forget the modulation profile is >being used and change the channel type without knowing the upstream channel >type for some upstream channels are changed at the same time. The >modulation profile channel type and upstream channel type are in two >different MIB tables. > > Actually, I am always puzzled when the modulation profile is being used >by some upstream channels, could the modulation profile channel type be >changed ? Maybe this is a confusing point which needs to be clarified, too. > > Thanks a lot for your help ! > Minnie > > > > > > >-Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 11:07 AM > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner DOCSIS > >OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > Sounds good to me. This would make verifying the consistency of > > the data in the modulation profiles and the upstream channels far easier. > >So, if I understand correctly, this means that all modulation profile > >entries with the same docsIfCmtsModIndex will have to have the same > >docsIfCmtsModChannelType. Otherwise, you would not be able to use that > >modulation profile set on any upstream channel. So, this modulation > >profile set with different docsIfCmtsModChannelTypes from an e-mail thread > >between Alberto and Steve from almost a year ago would be invalid, no ? > >The way to patch it up would be to make all of the IUCs tdmaAndAtdma, > >correct ? > > > >Thanks, > >David > > > >--- end David's e-mail --- > >--- start e-mail exchange between Alberto and Steve --- > > > >Hi Steve > > > >Sorry for the delay in responding > > > >Your configuration settings for operation in multiple mode is correct and > >will support tdma, tdmaAndAtdma and Atdma. > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with UCD > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and IUCs > >5&6 are not used. Your interpretation of the spec in the example described > >is accurate. > > > >Alberto Campos > >a.campos@cablelabs.com > > > > > > > > > > > >-----Original Message----- > >From: Steve Malenfant [mailto:smalenfant@com21.com] > >Sent: Monday, September 30, 2002 9:39 AM > >To: 'docsis-20@cablelabs.com' > >Subject: Correlation between docsIfUpChannelType and > >docsIfCmtsModChannelT ype > > > > > > > >We are having some discussion internally here, and would like to clarify > >things about the modulation profile. > >Let's take an example, expecting all parameters are good : > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > >set IUC 5 docsIfCmtsModChannelType to tdma. > >set IUC 6 docsIfCmtsModChannelType to tdma. > >set IUC 9 docsIfCmtsModChannelType to Atdma. > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > >Would this burst profile be good for docsIfUpChannelType tdma, tdmaAndAtdma > >and Atdma? > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 inside > >UCD type 2. > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. > > > > > > > > > > > >Minnie Lu > >Sent by: owner-docsis-oss@cablelabs.com > > > >08/21/2003 07:15 PM > > > > To: David.White@arrisi.com, "Greg White" > > > > cc: "DOCSIS OSS Majordomo List" > > , milu@cisco.com > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, David and Greg, > > > > I like Greg's "Perhaps it is simpler just to require that ModChannelType > >match UpChannelType.". > > > > I don't think that "we could just drop tdmaAndAtdma for > >ModChannelType". Please keep in mind that when assigning the modulation > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, it uses > >only the docsIfModIndex and only one docsIfModIndex can be assigned to some > >upstream channel. > > > > If I miss anything, please correct me. > > Thanks! > > Minnie > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > >Greg, > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma channels. > > > However, the modulation profiles objects > > > docsIfCmtsModByteInterleaverBlockSize and > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma channels. So, > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these objects > set, > > > it assumably could not be used on a tdma-only upstream channel. Hence, > > > the whole purpose of even having ModChannelType - to verify consistency > > > within the modulation profile - is weakened. This has the unintended > side > > > effect of requiring any assignment of modulation profiles with IUCs > 1, 2, > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see if the > > > Interleaver parameters have been set before assigning it to a tdma-only > > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation > > profiles. > > > I can't think of any need/requirement for tdmaAndAtdma for > > > modulation profiles that could not be met with a pair of tdma and atdma > > > modulation profile. In other words, I don't think allowing tdmaAndAtdma > > > for ModChannelType really buys us anything. I'm thinking we could just > > > drop tdmaAndAtdma for ModChannelType (making it a > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of confusion. > > > For the mixed-mode channels, where UpChannelType is > tdmaAndAtdma, > > > the modulation profile set could look like so: > > > > > >IUC 1 tdma > > >IUC 2 tdma > > >IUC 3 tdma > > >IUC 4 tdma > > >IUC 5 tdma > > >IUC 6 tdma > > >IUC 9 atdma > > >IUC 10 atdma > > >IUC 11 atdma > > > > > >For tdma-only upstream channels, the modulation profile set could be: > > > > > >IUC 1 tdma > > >IUC 2 tdma > > >IUC 3 tdma > > >IUC 4 tdma > > >IUC 5 tdma > > >IUC 6 tdma > > > > > >Likewise, for atdma-only upstream channel, the modulation profile set > > >could be: > > > > > >IUC 1 atdma > > >IUC 2 atdma > > >IUC 3 atdma > > >IUC 4 atdma > > >IUC 9 atdma > > >IUC 10 atdma > > >IUC 11 atdma > > > > > >As far as I know, there is no hard limit on the number of the modulation > > >profile sets that the CMTS and CM can support. I'm really liking your > "not > > >sure the benefits of flexibility outweigh disadvantages..." line of > > >thinking. tdmaAndAtdma for modulation profiles has my head spinning. > > > > > >Thanks, > > >David > > > > > > > > > > > >"Greg White" > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/20/2003 07:35 PM > > > > > > To: , "DOCSIS OSS Majordomo List" > > > > > > cc: > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning modulation > > > profiles to upstream channels > > > > > > > > >David, > > > > > >I agree with all of your clearly legal/illegal combinations. Among the > > >four that cause you consternation, I would break them done like this: > > > > > >illegal: > > >tdma, atdma > > >atdma, tdma > > > > > >potentially legal: > > >tdma, tdmaAndAtdma > > >atdma, tdmaAndAtdma > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and possibly > 11, > > >so cannot be used for a tdma channel. Similarly a tdma modulation profile > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma channel. > > > > > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10, and > > >possibly 11, so could potentially be used for a tdma or an atdma channel > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS ignored the > > >IUCs that don't apply to the channel type. I'm not sure that the > > >advantages of that flexibility outweigh the disadvantages of having the > > >MIB reporting something that doesn't exactly reflect what is > > >configured. Perhaps it is simpler just to require that ModChannelType > > >match UpChannelType. > > > > > >-Greg > > > > > > > > > ----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Tuesday, August 19, 2003 9:37 AM > > >To: DOCSIS OSS Majordomo List > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to upstream > > >channels > > > > > > > > >DOCSIS 2.0 Community, > > > It seems that the DocsisUpstreamType objects in both the > > > modulation profile table and the upstream channel table exist, in part, > > > to provide the equipment vendor a way to cross-check the data for > > > consistency. Furthermore, it would seem possible to compare the two > > > DocsisUpstreamType objects when assigning an upstream to a modulation > > > profile to make sure the assignment is compatible. For instance, the > > > following combination of docsIfUpChannelType, docsIfCmtsModChannelType > > > would clearly be illegal: > > > > > >scdma, tdma > > >scdma, atdma > > >scdma, tdmaAndAtdma > > > > > >tdma, scdma > > >atdma, scdma > > >tdmaAndAtdma, scdma > > > > > > > > >It is also pretty clear the following are legal: > > > > > >tdma, tdma > > >atdma, atdma > > >scdma, scdma > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > >However, it is the following cases that are causing me consternation: > > > > > >tdma, atdma > > >tdma, tdmaAndAtdma > > >atdma, tdma > > >atdma, tdmaAndAtdma > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > >tdmaAndAtdma, other than to cause confusion, especially for modulation > > >profiles. > > > > > >Thanks, > > >David White > > >ARRIS Cadant C4 CMTS > > > > > --=_alternative 0055A42085256DBA_= Content-Type: text/html; charset="us-ascii"
Greg,
        The main problem I have with this is that it forces the CMTS to postpone data checking until possibly the very end when the modulation profile is finally assigned. That is, the user may get a wrongValue or inconsistentValue while attempting to set the modulation profile because one or more already-set parameters do not agree with the ModChannelType. What I liked about having the UpChannelType being a configurable and "active" (rather than passive) object is that the CMTS verify things like ChannelWidth, SlotSize, and the Scdma parameters as they are being set. Thus, the error is immediate and pertitent.

However, what I like about your proposal is that it makes it easier to transition an upstream channel from tdma, atdma, and tdmaAndAtdma without having to change both the modulation profile and UpChannelType at the same time.

I'm not rejecting your proposal, but just wanted to voice my concerns.

Thanks,
David



"Greg White" <g.white@cablelabs.com>
Sent by: owner-docsis-oss@cablelabs.com

10/08/2003 07:35 PM

       
        To:        <David.White@arrisi.com>
        cc:        "DOCSIS OSS Majordomo List" <docsis-oss@cablelabs.com>, <Greg.Gohman@arrisi.com>, <ipcdn@ietf.org>, <Larry.Spaete@arrisi.com>, "Minnie Lu" <milu@cisco.com>
        Fax to:        
        Subject:        RE: Channel Types in RFMIBv2  (was RE: DOCSIS 2.0 : rules for  assigning modulation profiles to upstream channels)



David,
 
According to the proposed text, docsIfUpChannelType would be read-only for ALL rows.  
 
For "active" rows (docsIfUpChannelStatus = active(1)) setting UpChannelModulationProfile would return an error if the channel type of the profile does not work with the other parameters in the row.  
 
For "cloned" rows (docsIfUpChannelStatus = notInService(2)) no verification is done on consistency of parameters until docsIfUpChannelUpdate is set to true.
 
The verification for active rows is indicated in the proposed text for UpChannelModulationProfile, although it looks like it could be clarified:
 
             Setting this object on an "active" row MUST return an error if the following
            conditions are not satisfied:
            1. All the IUC entries in the selected modulation profile
            MUST have the same value of docsIfCmtsModChannelType.
            2. All of the modulation parameters in the selected
            modulation profile MUST be consistent with the other
            parameters in this docsIfUpChannelEntry.
 
Does that address your concern?
 
-Greg
 
-----Original Message-----
From: David.White@arrisi.com [mailto:David.White@arrisi.com]
Sent: Wednesday, October 08, 2003 3:11 PM
To: Greg White
Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu
Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels)

Greg,
       Per your earlier e-mail on this thread:

"Also, I would like to propose that we make docsIfUpChannelType a
read-only object for active rows in the Upstream Channel Table.
The value reported would be taken from the modulation profile pointed
to by docsIfUpChannelModulationProfile."

I'm assuming "active" mean in-service. Otherwise, we have to be careful with this because the channelType is used to verify things like channelWidth and whether or not setting of the scdma-specific parameters is allowed. Along the same lines, if setting the upstream modulation profile index implies that the SNMP agent changes the upChannelType to match the modProfChannelType, then the agent must also verify that all of the other parameters in the upstream channel are compatible with the possibly new channel type.

David
       
"Greg White" <g.white@CableLabs.com>

10/08/2003 04:12 PM

       
       To:        "Minnie Lu" <milu@cisco.com>
       cc:        <David.White@arrisi.com>, "DOCSIS OSS Majordomo List" <docsis-oss@CableLabs.com>, <Greg.Gohman@arrisi.com>, <Larry.Spaete@arrisi.com>, <ipcdn@ietf.org>
       Fax to:        
       Subject:        RE: Channel Types in RFMIBv2  (was RE: DOCSIS 2.0 : rules for  assigning modulation profiles to upstream channels)




Minnie,

I didn't want to prevent a user from changing their mind regarding
channel type when creating a new modulation profile.  Suppose you
started out setting channel type to atdma and, after completing a few
IUCs, realized that you really wanted tdmaAndAtdma.  Rather than make
you start from scratch (or do a simultaneous set across all IUCs), you
could just update the channel type on each row.

I understand your view as well.  

If there is a consensus to change the text, I am not strongly opposed.

-Greg

-----Original Message-----
From: Minnie Lu [mailto:milu@cisco.com]
Sent: Wednesday, October 08, 2003 12:48 PM
To: Greg White
Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List;
Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org
Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for
assigning modulation profiles to upstream channels)


Hi, Greg,

Thanks a lot to you and Eduardo for this proposal !

docsIfCmtsModChannelType :
 "...
   In order to be considered a valid modulation profile for
   assignment to an upstream channel, all entries (IUCs) in
     the modulation profile must have the same channel type."

 In addition to do the checking at the time the modulation profile is
assigned to some upstream, I think that the checking could also be done
when user create/modify an entry of docsIfCmtsModulationEntry even the
modulation profile is not assigned to any upstreams.  So the error could
be
caught earlier.   So I would suggest to enhance the description as the
ECO
(OSS2-O-03092)

"All the entries in a modulation profile (i.e. all entries that share a
common docsIfCmtsModIndex) MUST have the same value of
docsIfCmtsModChannelType."

If I miss anything, please let me know.
Thanks a lot!
Minnie

At 04:22 PM 10/7/2003 -0600, Greg White wrote:
>All,
>
>As a final issue to resolve in the RFMIBv2 before draft-08, I would
like
>to propose that we complete the clarification of the relationship
between
>the ChannelType parameters in modulation profiles and upstream
channels.
>
>There is currently an ECO (OSS2-O-03092) written by Minnie Lu which
>clarifies part of the relationship by adding requirements to the OSSI
>spec.  I would like to suggest that we propagate those requirements to
the
>MIB descriptions.
>
>Also, I would like to propose that we make docsIfUpChannelType a
read-only
>object for active rows in the Upstream Channel Table.  The value
reported
>would be taken from the modulation profile pointed to by
>docsIfUpChannelModulationProfile.
>
>Attached is a detailed proposal that Eduardo and I wrote to frame the
issue.
>
>In order not to delay draft-08, we would like to have consensus from
the
>community and working group by this Friday, October 10.  Please review
the
>attached proposal and provide comments.
>
>Many thanks,
>Greg
>-----Original Message-----
>From: David.White@arrisi.com [mailto:David.White@arrisi.com]
>Sent: Monday, August 25, 2003 5:59 PM
>To: Minnie Lu
>Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White;
>Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List
>Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to
>upstream channels
>
>Minnie,
>         I am emphathetic to your concerns. I ran across the same issue

> while implementing cross-checks for the 2.0 modulation and upstream
data.
> I found it made the code far simpler to lead the user down the path of

> "define the channel type first, then build everything around that"
kind
> of configuration model. I am then able to check the settings of the
other
> parameters against the channel type. After a modulation profile or
> upstream channel has already been provisioned, changing just the
channel
> type becomes difficult, as many parameters are incompatible with other

> channel types. I allow it, but don't recommend it.
>
>My 2 cents,
>David
>
>
>
>
>
>Minnie Lu <milu@cisco.com>
>
>08/25/2003 07:01 PM
>
>         To:        "Greg White" <g.white@CableLabs.com>
>         cc:        <David.White@arrisi.com>, "Minnie Lu"
> <milu@cisco.com>, <Greg.Gohman@arrisi.com>, <Larry.Spaete@arrisi.com>,

> "DOCSIS OSS Majordomo List" <docsis-oss@CableLabs.com>, "Owner DOCSIS
OSS
> Majordomo List" <owner-docsis-oss@CableLabs.com>
>         Fax to:
>         Subject:        RE: DOCSIS 2.0 : rules for assigning
modulation
> profiles to   upstream channels
>
>
>
>
>
>Hi, Greg,
>
>  Please see my response inline.
>  Thanks a lot !
>  Minnie
>At 02:29 PM 8/25/2003 -0600, Greg White wrote:
> >The email exchange between Steve and Alberto notwithstanding, I think
it
> >does make sense to enforce that all entries in a modulation profile
(i.e.
> >all entries that share a common docsIfCmtsModIndex) have the same
> >ModChannelType.  Also, based on the exchange here it seems that there
is
> >some support for the additional restriction that UpChannelType and
> >ModChannelType always match.  With those two restrictions, there
clearly
> >is a need for all defined values of ModChannelType.
> >
> >Since this has been a point of confusion at least twice now, does
anyone
> >have a concern with making these two items part of the specification?
> >
>
>[milu]: I agree with you.
>
> >A further point, how does the CMTS enforce the match between
UpChannelType
> >and ModChannelType?  One implementation may automatically change
> >UpChannelType to match ModChannelType whenever
> >docsIfUpChannelModulationProfile is set.  Another might reject the
change
> >if the two don't already match, and require the use of the
> >docsIfUpChannelCloneFrom mechanism to change the channel type.  I'd
argue
> >that the first implementation makes more sense, and ought to be made
a
> >SHOULD in the spec, but I'd like to hear other views.
> >
>
>[milu]: I think this needs to be thought over carefully.  How about the
>case that some modulation profile is used by some upstream channel, and
>user change the modulation profile channel type ?  Does it mean that
the
>upstream channel type would be changed automatically, too ?  If yes, I
am
>afraid that there might be some user who forget the modulation profile
is
>being used and change the channel type without knowing the upstream
channel
>type for some upstream channels are changed at the same time.  The
>modulation profile channel type and upstream channel type are in two
>different MIB tables.
>
>   Actually, I am always puzzled when the modulation profile is being
used
>by some upstream channels, could the modulation profile channel type be
>changed ?  Maybe this is a confusing point which needs to be clarified,
too.
>
>   Thanks a lot for your help !
>   Minnie
>
>
>
>
>
> >-Greg
> >-----Original Message-----
> >From: David.White@arrisi.com [mailto:David.White@arrisi.com]
> >Sent: Monday, August 25, 2003 11:07 AM
> >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com
> >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner
DOCSIS
> >OSS Majordomo List
> >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to
> >upstream channels
> >
> >Minnie,
> >         Sounds good to me. This would make verifying the consistency
of
> > the data in the modulation profiles and the upstream channels far
easier.
> >So, if I understand correctly, this means that all modulation profile
> >entries with the same docsIfCmtsModIndex will have to have the same
> >docsIfCmtsModChannelType. Otherwise, you would not be able to use
that
> >modulation profile set on any upstream channel. So, this modulation
> >profile set with different docsIfCmtsModChannelTypes from an e-mail
thread
> >between Alberto and Steve from almost a year ago would be invalid, no
?
> >The way to patch it up would be to make all of the IUCs tdmaAndAtdma,
> >correct ?
> >
> >Thanks,
> >David
> >
> >--- end David's e-mail ---
> >--- start e-mail exchange between Alberto and Steve ---
> >
> >Hi Steve
> >
> >Sorry for the delay in responding
> >
> >Your configuration settings for operation in multiple mode is correct
and
> >will support tdma, tdmaAndAtdma and Atdma.
> >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with
UCD
> >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and
IUCs
> >5&6 are not used. Your interpretation of the spec in the example
described
> >is accurate.
> >
> >Alberto Campos
> >a.campos@cablelabs.com
> >
> >
> >
> >
> >
> >-----Original Message-----
> >From: Steve Malenfant [mailto:smalenfant@com21.com]
> >Sent: Monday, September 30, 2002 9:39 AM
> >To: 'docsis-20@cablelabs.com'
> >Subject: Correlation between docsIfUpChannelType and
> >docsIfCmtsModChannelT ype
> >
> >
> >
> >We are having some discussion internally here, and would like to
clarify
> >things about the modulation profile.
> >Let's take an example, expecting all parameters are good :
> >
> >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma.
> >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma.
> >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma.
> >set IUC 5 docsIfCmtsModChannelType to tdma.
> >set IUC 6 docsIfCmtsModChannelType to tdma.
> >set IUC 9 docsIfCmtsModChannelType to Atdma.
> >set IUC 10 docsIfCmtsModChannelType to Atdma.
> >
> >Would this burst profile be good for docsIfUpChannelType tdma,
tdmaAndAtdma
> >and Atdma?
> >
> >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2.
> >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5
inside
> >UCD type 2.
> >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29.
> >
> >
> >
> >
> >
> >Minnie Lu <milu@cisco.com>
> >Sent by: owner-docsis-oss@cablelabs.com
> >
> >08/21/2003 07:15 PM
> >
> >         To:        David.White@arrisi.com, "Greg White"
> > <g.white@cablelabs.com>
> >         cc:        "DOCSIS OSS Majordomo List"
> > <docsis-oss@cablelabs.com>, milu@cisco.com
> >         Fax to:
> >         Subject:        RE: DOCSIS 2.0 : rules for assigning
modulation
> > profiles to  upstream channels
> >
> >
> >
> >
> >
> >Hi, David and Greg,
> >
> >  I like Greg's "Perhaps it is simpler just to require that
ModChannelType
> >match UpChannelType.".
> >
> >  I don't think that "we could just drop tdmaAndAtdma for
> >ModChannelType".  Please keep in mind that when assigning the
modulation
> >profile to some upstream via SNMP docsIfUpChannelModulationProfile,
it uses
> >only the docsIfModIndex and only one docsIfModIndex can be assigned
to some
> >upstream channel.
> >
> >  If I miss anything, please correct me.
> >  Thanks!
> >  Minnie
> >
> >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote:
> >
> > >Greg,
> > >         IUCs 1, 2, 3, and 4 are used for both tdma and atdma
channels.
> > > However, the modulation profiles objects
> > > docsIfCmtsModByteInterleaverBlockSize and
> > > docsIfCmtsModByteInterleaverDepth are only valid for atdma
channels. So,
> > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these
objects
> set,
> > > it assumably could not be used on a tdma-only upstream channel.
Hence,
> > > the whole purpose of even having ModChannelType - to verify
consistency
> > > within the modulation profile - is weakened. This has the
unintended
> side
> > > effect of requiring any assignment of modulation profiles with
IUCs
> 1, 2,
> > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see
if the
> > > Interleaver parameters have been set before assigning it to a
tdma-only
> > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation
> > profiles.
> > >         I can't think of any need/requirement for tdmaAndAtdma for
> > > modulation profiles that could not be met with a pair of tdma and
atdma
> > > modulation profile. In other words, I don't think allowing
tdmaAndAtdma
> > > for ModChannelType really buys us anything. I'm thinking we could
just
> > > drop tdmaAndAtdma for ModChannelType (making it a
> > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of
confusion.
> > >         For the mixed-mode channels, where UpChannelType is
> tdmaAndAtdma,
> > > the modulation profile set could look like so:
> > >
> > >IUC  1  tdma
> > >IUC  2  tdma
> > >IUC  3  tdma
> > >IUC  4  tdma
> > >IUC  5  tdma
> > >IUC  6  tdma
> > >IUC  9 atdma
> > >IUC 10 atdma
> > >IUC 11 atdma
> > >
> > >For tdma-only upstream channels, the modulation profile set could
be:
> > >
> > >IUC 1 tdma
> > >IUC 2 tdma
> > >IUC 3 tdma
> > >IUC 4 tdma
> > >IUC 5 tdma
> > >IUC 6 tdma
> > >
> > >Likewise, for atdma-only upstream channel, the modulation profile
set
> > >could be:
> > >
> > >IUC  1 atdma
> > >IUC  2 atdma
> > >IUC  3 atdma
> > >IUC  4 atdma
> > >IUC  9 atdma
> > >IUC 10 atdma
> > >IUC 11 atdma
> > >
> > >As far as I know, there is no hard limit on the number of the
modulation
> > >profile sets that the CMTS and CM can support. I'm really liking
your
> "not
> > >sure the benefits of flexibility outweigh disadvantages..." line of
> > >thinking. tdmaAndAtdma for modulation profiles has my head
spinning.
> > >
> > >Thanks,
> > >David
> > >
> > >
> > >
> > >"Greg White" <g.white@cablelabs.com>
> > >Sent by: owner-docsis-oss@cablelabs.com
> > >
> > >08/20/2003 07:35 PM
> > >
> > >         To:        <David.White@arrisi.com>, "DOCSIS OSS Majordomo
List"
> > > <docsis-oss@cablelabs.com>
> > >         cc:
> > >         Fax to:
> > >         Subject:        RE: DOCSIS 2.0 : rules for assigning
modulation
> > > profiles to upstream channels
> > >
> > >
> > >David,
> > >
> > >I agree with all of your clearly legal/illegal combinations.  Among
the
> > >four that cause you consternation, I would break them done like
this:
> > >
> > >illegal:
> > >tdma, atdma
> > >atdma, tdma
> > >
> > >potentially legal:
> > >tdma, tdmaAndAtdma
> > >atdma, tdmaAndAtdma
> > >
> > >An atdma modulation profile will include IUCs 1,3,4,9,10, and
possibly
> 11,
> > >so cannot be used for a tdma channel. Similarly a tdma modulation
profile
> > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma
channel.
> > >
> > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10,
and
> > >possibly 11, so could potentially be used for a tdma or an atdma
channel
> > >(in addition to a tdmaAndAtdma channel), as long as the CMTS
ignored the
> > >IUCs that don't apply to the channel type.  I'm not sure that the
> > >advantages of that flexibility outweigh the disadvantages of having
the
> > >MIB reporting something that doesn't exactly reflect what is
> > >configured.  Perhaps it is simpler just to require that
ModChannelType
> > >match UpChannelType.
> > >
> > >-Greg
> > >
> > >
> > >  ----Original Message-----
> > >From: David.White@arrisi.com [mailto:David.White@arrisi.com]
> > >Sent: Tuesday, August 19, 2003 9:37 AM
> > >To: DOCSIS OSS Majordomo List
> > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to
upstream
> > >channels
> > >
> > >
> > >DOCSIS 2.0 Community,
> > >        It seems that the DocsisUpstreamType objects in both the
> > > modulation profile table and the upstream channel table exist, in
part,
> > > to provide the equipment vendor a way to cross-check the data for
> > > consistency. Furthermore, it would seem possible to compare the
two
> > > DocsisUpstreamType objects when assigning an upstream to a
modulation
> > > profile to make sure the assignment is compatible. For instance,
the
> > > following combination of docsIfUpChannelType,
docsIfCmtsModChannelType
> > > would clearly be illegal:
> > >
> > >scdma, tdma
> > >scdma, atdma
> > >scdma, tdmaAndAtdma
> > >
> > >tdma, scdma
> > >atdma, scdma
> > >tdmaAndAtdma, scdma
> > >
> > >
> > >It is also pretty clear the following are legal:
> > >
> > >tdma, tdma
> > >atdma, atdma
> > >scdma, scdma
> > >tdmaAndAtdma, tdmaAndAtdma
> > >
> > >
> > >However, it is the following cases that are causing me
consternation:
> > >
> > >tdma, atdma
> > >tdma, tdmaAndAtdma
> > >atdma, tdma
> > >atdma, tdmaAndAtdma
> > >
> > >
> > >If ALL of these are legal, then I do not understand the point of
> > >tdmaAndAtdma, other than to cause confusion, especially for
modulation
> > >profiles.
> > >
> > >Thanks,
> > >David White
> > >ARRIS Cadant C4 CMTS
> >
>
>
>

--=_alternative 0055A42085256DBA_=-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Oct 9 15:40:28 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 PAA06757 for ; Thu, 9 Oct 2003 15:40:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gdo-0002r6-Tr for ipcdn-archive@odin.ietf.org; Thu, 09 Oct 2003 15:40:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99Je3Fa010966 for ipcdn-archive@odin.ietf.org; Thu, 9 Oct 2003 15:40:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gdl-0002qB-AP; Thu, 09 Oct 2003 15:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gdP-0002pG-MW for ipcdn@optimus.ietf.org; Thu, 09 Oct 2003 15:39:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06712 for ; Thu, 9 Oct 2003 15:39:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7gdN-0003Jf-00 for ipcdn@ietf.org; Thu, 09 Oct 2003 15:39:37 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A7gdM-0003JC-00 for ipcdn@ietf.org; Thu, 09 Oct 2003 15:39:36 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h99JbW10020129; Thu, 9 Oct 2003 13:37:32 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Oct 2003 13:37:32 -0600 Message-ID: Thread-Topic: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcOOktBv0hn4SqViTae2STkl2UxTNwABYoEw From: "Eduardo Cardona" To: "Minnie Lu" , Cc: "Greg White" , "DOCSIS OSS Majordomo List" , , , , "Owner DOCSIS OSS Majordomo List" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) 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 David, Minnie,=20 Greg may have other comments. I think the idea was to define one clear way of configuration rather than finding possible broken paths The idea was to pass the role of The UpChannel parameters vs ChannelType verification to one trigger, the docsIfUpChannelModulationProfile so it verifies that all the channelTypes are the same (in the mod profile) All Modulation Parameters are consistent in into their own IUC [ can be done also as user change an IUC itself -invalid value for that particulat CMTS-, etc] Then as the Type is knew from the profile verifies that the ChannelType is compatible with the UpChannel parameters, if fails nothing haven change or undo-commit.=20 The point is that UpChannel to ModulationProfile is one-to-many so going in that path eventually the user won't break the Profile that works for other UpChannels and instead maybe create a one-to-one UpChannel-to-ModulationProfile ( by creating a new Profile) In the current UpChannelChanelType read-create we have, implies UpChannelModProfile and ChannelType might need to be modified simultaneously or: 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelType to 'x' and=20 -verify Chnnl- 4 UpChannelModulationProfile to 'y' -verify Chnnl UpCh/ModProfile-=20 if failed start again from 1 With the proposal at maximum ( channelType RO) would be =20 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelModulationProfile to 'y' - do all verifications chnnl/ModProf- =20 if failed redo 2, maybe adjust ModulationProfileTable and 3) Are there any other updated paths to consider for simplified setup, other sequence?=20 Or maybe be more details in the sequence for the objects ? Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Thursday, October 09, 2003 12:25 PM To: David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, David, Your concern sounds very valid. Then it seems to me that 1. either have docsIfUpChannelType is read-only and ask the=20 docsIfUpChannelModulationProfile must be assigned first before setting=20 other upstream attributes. For this is one, I don't know user would like=20 it or not. 2. or we still need to keep the docsIfUpChannelType is read-create, so it=20 can be used to check other upstream attributes consistence without having=20 an modulation profile assigned. The user must make sure both=20 docsIfUpChannelModulationProfile and docsIfUpChannelType are the same when=20 trying to set either one of them if docsIfUpChannelModulationProfile is not=20 value 0. If they are not consistent, the set will fail. Any more possible solution ? Just some more thoughts. Thanks a lot ! Minnie At 11:35 AM 10/9/2003 -0400, David.White@arrisi.com wrote: >Greg, > The main problem I have with this is that it forces the CMTS=20 >to > postpone data checking until possibly the very end when the modulation > profile is finally assigned. That is, the user may get a wrongValue or > inconsistentValue while attempting to set the modulation profile because=20 > one or more already-set parameters do not agree with the ModChannelType.=20 > What I liked about having the UpChannelType being a configurable and=20 > "active" (rather than passive) object is that the CMTS verify things like=20 > ChannelWidth, SlotSize, and the Scdma parameters as they are being set.=20 > Thus, the error is immediate and pertitent. > >However, what I like about your proposal is that it makes it easier to >transition an upstream channel from tdma, atdma, and tdmaAndAtdma without=20 >having to change both the modulation profile and UpChannelType at the same=20 >time. > >I'm not rejecting your proposal, but just wanted to voice my concerns. > >Thanks, >David > > > >"Greg White" >Sent by: owner-docsis-oss@cablelabs.com > >10/08/2003 07:35 PM > > To: > cc: "DOCSIS OSS Majordomo List"=20 > , ,=20 > , > , "Minnie Lu" > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > >David, > >According to the proposed text, docsIfUpChannelType would be read-only=20 >for >ALL rows. > >For "active" rows (docsIfUpChannelStatus =3D active(1)) setting >UpChannelModulationProfile would return an error if the channel type of >the profile does not work with the other parameters in the row. > >For "cloned" rows (docsIfUpChannelStatus =3D notInService(2)) no >verification is done on consistency of parameters until=20 >docsIfUpChannelUpdate is set to true. > >The verification for active rows is indicated in the proposed text for >UpChannelModulationProfile, although it looks like it could be clarified: > > Setting this object on an "active" row MUST return an=20 > error > if the following > conditions are not satisfied: > 1. All the IUC entries in the selected modulation profile > MUST have the same value of docsIfCmtsModChannelType. > 2. All of the modulation parameters in the selected > modulation profile MUST be consistent with the other > parameters in this docsIfUpChannelEntry. > >Does that address your concern? > >-Greg > >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Wednesday, October 08, 2003 3:11 PM >To: Greg White >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; >Larry.Spaete@arrisi.com; Minnie Lu >Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for=20 >assigning modulation profiles to upstream channels) > > >Greg, > Per your earlier e-mail on this thread: > >"Also, I would like to propose that we make docsIfUpChannelType a=20 >read-only object for active rows in the Upstream Channel Table. The=20 >value reported would be taken from the modulation profile pointed to by >docsIfUpChannelModulationProfile." > >I'm assuming "active" mean in-service. Otherwise, we have to be careful >with this because the channelType is used to verify things like=20 >channelWidth and whether or not setting of the scdma-specific parameters=20 >is allowed. Along the same lines, if setting the upstream modulation=20 >profile index implies that the SNMP agent changes the upChannelType to=20 >match the modProfChannelType, then the agent must also verify that all of=20 >the other parameters in the upstream channel are compatible with the=20 >possibly new channel type. > >David > > >"Greg White" > >10/08/2003 04:12 PM > To: "Minnie Lu" > cc: , "DOCSIS OSS Majordomo List"=20 > , , > , > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > > >Minnie, > >I didn't want to prevent a user from changing their mind regarding=20 >channel type when creating a new modulation profile. Suppose you=20 >started out setting channel type to atdma and, after completing a few=20 >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make=20 >you start from scratch (or do a simultaneous set across all IUCs), you=20 >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List;=20 >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for=20 >assigning modulation profiles to upstream channels) > > >Hi, Greg, > >Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is=20 >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the=20 >modulation profile is not assigned to any upstreams. So the error=20 >could be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of=20 >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which=20 > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements=20 > >to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by=20 > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please=20 > >review >the > >attached proposal and provide comments. > > > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White;=20 > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to=20 > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same=20 > >issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path=20 > > of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or=20 > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with=20 > > other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , ,=20 > > , > > > "DOCSIS OSS Majordomo List" , "Owner=20 > > DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I=20 > > >think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same=20 > > >ModChannelType. Also, based on the exchange here it seems that=20 > > >there >is > > >some support for the additional restriction that UpChannelType and=20 > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the=20 > > >specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change=20 > > >UpChannelType to match ModChannelType whenever=20 > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the=20 > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be=20 > > >made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about=20 > >the case that some modulation profile is used by some upstream=20 > >channel, and user change the modulation profile channel type ? Does=20 > >it mean that >the > >upstream channel type would be changed automatically, too ? If yes,=20 > >I >am > >afraid that there might be some user who forget the modulation=20 > >profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The=20 > >modulation profile channel type and upstream channel type are in two=20 > >different MIB tables. > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type=20 > >be changed ? Maybe this is a confusing point which needs to be=20 > >clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles=20 > > >to upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the=20 > > >consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation=20 > > >profile entries with the same docsIfCmtsModIndex will have to have=20 > > >the same docsIfCmtsModChannelType. Otherwise, you would not be able > > >to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid,=20 > > >no >? > > >The way to patch it up would be to make all of the IUCs=20 > > >tdmaAndAtdma, correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is=20 > > >correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used=20 > > >with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29=20 > > >and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and=20 > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2.=20 > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV=20 > > >5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type=20 > > >29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List" > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for=20 > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects=20 > > > > docsIfCmtsModByteInterleaverBlockSize and=20 > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to=20 > > > > see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for=20 > > > > modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma=20 > > > > for modulation profiles that could not be met with a pair of=20 > > > > tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we=20 > > > > could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a=20 > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line=20 > > > >of thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations. =20 > > > >Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs=20 > > > >1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of=20 > > > >having >the > > > >MIB reporting something that doesn't exactly reflect what is=20 > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the > > > >modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data=20 > > > > for consistency. Furthermore, it would seem possible to compare=20 > > > > the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of=20 > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Oct 9 16:16:25 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 QAA09276 for ; Thu, 9 Oct 2003 16:16:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hCc-0005Ng-P2 for ipcdn-archive@odin.ietf.org; Thu, 09 Oct 2003 16:16:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99KG2vB020663 for ipcdn-archive@odin.ietf.org; Thu, 9 Oct 2003 16:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hCb-0005N5-8b; Thu, 09 Oct 2003 16:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hBw-0005Gm-BR for ipcdn@optimus.ietf.org; Thu, 09 Oct 2003 16:15:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09249 for ; Thu, 9 Oct 2003 16:15:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7hBu-00045Z-00 for ipcdn@ietf.org; Thu, 09 Oct 2003 16:15:18 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A7hBt-00045D-00 for ipcdn@ietf.org; Thu, 09 Oct 2003 16:15:17 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h99KEi10023350; Thu, 9 Oct 2003 14:14:44 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38EA1.F9BF26B3" Subject: RE: [ipcdn] Status of IPCDN RF MIBv2 and 3 open issues Date: Thu, 9 Oct 2003 14:14:42 -0600 Message-ID: Thread-Topic: [ipcdn] Status of IPCDN RF MIBv2 and 3 open issues Thread-Index: AcNgJaYn06TBEeT1TRC5N0Q/BVl7hgT3JTZQBRgJoxAABa9pIAGKF0mA From: "Eduardo Cardona" To: "Jean-Francois Mule" , "Ipcdn (E-mail)" Cc: "Richard Woundy" , "Bert Wijnen" , "Raftus, David" X-Approved: ondar 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_01C38EA1.F9BF26B3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 =20 Just a reminder if you have comments for the open issues, listed this week, please do so. so far only the New added comment #23 for ChannelType has being discussed. =20 Thanks =20 Eduardo =20 -----Original Message----- From: Jean-Francois Mule=20 Sent: Wednesday, October 01, 2003 6:11 PM To: Ipcdn (E-mail) Cc: Eduardo Cardona; Jean-Francois Mule; Richard Woundy; Bert Wijnen; Raftus, David Subject: [ipcdn] Status of IPCDN RF MIBv2 and 3 open issues =09 =09 This note provides a status on the DOCSIS 2.0 RF MIB (aka rfmibv2). =09 In summary, 3 issues are still OPEN and the wg chairs would like to have working group consensus by Friday October 10 on issues: #13, #14, #16. Eduardo Cardona of CableLabs has kindly accepted to help resolve=20 those and will be posting some text soon. =09 Please read this carefully and raise any concerns or objections to the wg chairs on this action plan by Friday Oct 10. =09 -- Rich Woundy and Jean-Francois Mule', ipcdn co-chairs. =09 --- Status of RF MIBv2 Internet-Draft Name: DOCSIS 2.0 RF MIB draft-ietf-ipcdn-docs-rfmibv2-06.txt =09 ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-06.txt =20 soon to be draft-ietf-ipcdn-docs-rfmibv2-07.txt =09 =09 1) Follow-up on the IETF posting of rfmibv2-07 The editor, David Raftus sent draft-07 to the internet-draft on 9/9. The revision has not shown up yet. This is probably due to the fact that a zip file was attached instead of the plain text file. Action Item (AI): wg chair to follow up on posting. =09 =09 2) Categorization of the remaining open issues David Raftus sent a list of open issues to the ipcdn list on 9/12/03, see attached file rfdraftv7_issues_Sept12_2003.txt The remaining open issues not addressed in draft-07 split into 2 categories: - a) issue is not required to be addressed ("nice to have") This category includes some of the improvements that were not in the original scope of rfmibv2. A lot of improvements has been done and it is time to freeze rfmibv2. - b) issue that should be addressed in draft v8 ("must fix") This category includes some issues that need to be addressed. 5 open issues are in this category. =3D> Please raise any objection on the ipcdn list by COB Friday 9/10/03 if you believe this is not reflecting the correct status of the draft or if you believe more open issues must be fixed. =09 =09 3) Open issues: The numbering is based on David Raftus status file sent on 9/12/2003 on the ipcdn list and attached to this posting. =09 + Issue #7: Status: Closed (will be in draft08) (7) docsIfUpChannelPreEqEnable - add DEFVAL clause. Contributor - John Gillis ADC David indicated that a defval is not required ("DEFVAL not appropriate here, also too many other items in same table do not have DEFVAL"). # category: "must fix" # Eduardo recommends to add a default value of false for this object. # Action Item: add DEFVAL false in draft 08 =09 + Issue #13 Status: Open (13) Adjust compliance statements for objects designated optional. Add separate augmentation table for optional objects in docsIfCmtsUpChannelCounterTable. Contributors - Will Murwin Motorola, Rich Woundy IPCDN/Comcast, Mike StJohns Mindspring, Eduardo Cardona Cablelabs # category: "must fix" # Action Item: Eduardo to summarize the discussion & a recommendation # for the augmentation. Consensus must be reached by 10/10 or else WG # chair will make a decision. =09 + Issue #14 Status: Open (14) Add section explaining counter interaction between Docsis 1.0/1.1/2.0. David indicated that this could be done in OSS spec but since rfmib v2 obsoletes an exising IETF MIB, the wg chairs recommendation is to include a section in the new MIB. # category: "must fix" # Action Item: Eduardo to propose some text. =09 + Issue #15 Status: Closed, pending ipcdn review (15) Change docsIfCmtsServiceTable to count packets for both upstream and downstream flows. David Raftus commented: "Will not do - inappropriate - table indexed by SID, SIDs are not defined for downstream flows". WG chairs agree with David Raftus. # category: "nice to have", For further study. # Action item: none, issue is closed. =09 + Issue #16 Status: Open (16) Add 4 objects to docsIfCmtsCmStatusTable See David Raftus' status on this open issue and associated emails. # category: "nice to have" # Action item: Eduardo to close on this issue on the ipcdn mailing # list. If no consensus can be reached by Oct 10, wg chair will make a # decision to leave it out of rf mib v2. =09 + Issue #20 Status: Closed (will be in draft08) (20) Update snmpv3 references to latest mib versions # category: "must fix" # Action item: edit draft 08 and include proper refs in the document =09 + Issue #22 Status: Closed (pending ipcdn review) (22) Addition of object to report received power level per channel at CMTS # category: "nice to have" -> out of scope # Recommendation is that this issue will not be addressed in any # future revision of RF MIB v2. # Action item: none, issue is closed.=20 ------_=_NextPart_001_01C38EA1.F9BF26B3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 all,
 
Just a=20 reminder if you have comments for the open issues, listed this = week, please=20 do so. so far only the New added comment #23 for ChannelType has being=20 discussed.
 
Thanks
 
Eduardo
 
-----Original Message-----
From: = Jean-Francois=20 Mule
Sent: Wednesday, October 01, 2003 6:11 = PM
To: Ipcdn=20 (E-mail)
Cc: Eduardo Cardona; Jean-Francois Mule; Richard = Woundy;=20 Bert Wijnen; Raftus, David
Subject: [ipcdn] Status of IPCDN = RF MIBv2=20 and 3 open issues

This note = provides a=20 status on the DOCSIS 2.0 RF MIB (aka rfmibv2).

In summary, 3 = issues are=20 still OPEN and the wg chairs would like to
have working group = consensus by=20 Friday October 10 on issues: #13, #14,
 #16. Eduardo Cardona of CableLabs has kindly = accepted to=20 help resolve
those and will be posting some text soon.

Please read this carefully and raise any = concerns or=20 objections to the
wg chairs on this=20 action plan by Friday Oct 10.

 -- Rich Woundy and Jean-Francois Mule', ipcdn=20 co-chairs.

--- Status of RF MIBv2
Internet-Draft Name: DOCSIS 2.0 RF=20 = MIB
           =          =20 draft-ietf-ipcdn-docs-rfmibv2-06.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2= -06.txt
soon to=20 be
draft-ietf-ipcdn-docs-rfmibv2-07.txt


1) Follow-up on the IETF = posting of=20 rfmibv2-07
   The=20 editor, David Raftus sent draft-07 to the internet-draft = on
  =20 9/9. The revision has not shown up yet. This is probably due to=20 the
   fact that a zip file was attached instead of the = plain=20 text file.
   Action Item (AI): wg chair to follow up on=20 posting.


2)=20 Categorization of the remaining open issues
David Raftus sent a list of open issues = to the ipcdn=20 list on 9/12/03,
see attached file = rfdraftv7_issues_Sept12_2003.txt
The=20 remaining open issues not addressed in draft-07 split into=20 2
categories:
- a)=20 issue is not required to be addressed ("nice to have")
  This category includes some of = the=20 improvements that were not in the
  original scope of rfmibv2. = A lot=20 of improvements has been done and
  it is time to freeze=20 rfmibv2.
- b) issue=20 that should be addressed in draft v8 ("must fix")
  This category includes some = issues that need=20 to be addressed.
  5 open issues are in this = category.
=3D> Please=20 raise any objection on the ipcdn list by COB Friday 9/10/03
if you = believe=20 this is not reflecting the correct status of the draft
or if you = believe=20 more open issues must be fixed.


3) Open issues:
The numbering is based on David Raftus status file sent on=20 9/12/2003
on the ipcdn list and attached to this=20 posting.

+ Issue=20 #7:
Status: Closed (will = be in=20 draft08)
(7) docsIfUpChannelPreEqEnable - add DEFVAL=20 clause.
    Contributor - John Gillis ADC
David = indicated=20 that a defval is not required ("DEFVAL not appropriate
here, also = too many=20 other items in same table do not have DEFVAL").
# category: "must = fix"
# Eduardo recommends to = add a default=20 value of false for this object.
# Action Item: add DEFVAL false in draft=20 08

+ = Issue=20 #13
Status: Open
(13) = Adjust=20 compliance statements for objects designated optional.=20 Add
     separate augmentation table for = optional=20 objects in
    =20 docsIfCmtsUpChannelCounterTable.
     = Contributors -=20 Will Murwin Motorola, Rich Woundy = IPCDN/Comcast,
    =20 Mike StJohns Mindspring, Eduardo Cardona Cablelabs
# category: "must = fix"
# Action Item: Eduardo = to summarize=20 the discussion & a recommendation
# for the augmentation. Consensus must be = reached by=20 10/10 or else WG
#=20 chair will make a decision.

+ Issue #14
Status: Open
(14) Add section explaining counter = interaction=20 between
     Docsis 1.0/1.1/2.0.
David = indicated=20 that this could be done in OSS spec but since rfmib v2
obsoletes an = exising=20 IETF MIB, the wg chairs recommendation is to
include a section in = the new=20 MIB.
# = category: "must=20 fix"
# = Action Item:=20 Eduardo to propose some text.

+ Issue #15
Status: Closed, pending ipcdn review
(15) Change=20 docsIfCmtsServiceTable to count packets for both=20 upstream
     and downstream flows.
David = Raftus=20 commented: "Will not do - inappropriate - table indexed
by SID, = SIDs are=20 not defined for downstream flows".
WG chairs agree with David=20 Raftus.
# category:=20 "nice to have", For further study.
# Action item: none, issue is = closed.

+ Issue = #16
Status: Open
(16) Add 4 objects to=20 docsIfCmtsCmStatusTable
See David Raftus' status on this open issue = and=20 associated emails.
#=20 category: "nice to have"
# Action item: Eduardo to close on this issue on the ipcdn=20 mailing
# list. If no=20 consensus can be reached by Oct 10, wg chair will make = a
# decision to leave it = out of rf mib=20 v2.

+ Issue=20 #20
Status: Closed (will = be in=20 draft08)
(20) Update snmpv3 references to latest mib=20 versions
# category:=20 "must fix"
# Action=20 item: edit draft 08 and include proper refs in the=20 document

+ Issue=20 #22
Status: Closed = (pending ipcdn=20 review)
(22) Addition of object to report received power level per = channel=20 at CMTS
# category:=20 "nice to have" -> out of scope
# Recommendation is that this issue will not = be addressed=20 in any
# = future=20 revision of RF MIB v2.
# Action item: none, issue is closed.=20

=00 ------_=_NextPart_001_01C38EA1.F9BF26B3-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Oct 9 17:14:26 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 RAA11403 for ; Thu, 9 Oct 2003 17:14:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7i6l-0000hn-Co for ipcdn-archive@odin.ietf.org; Thu, 09 Oct 2003 17:14:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99LE3DZ002698 for ipcdn-archive@odin.ietf.org; Thu, 9 Oct 2003 17:14:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7i6j-0000hC-Tb; Thu, 09 Oct 2003 17:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hSv-0005xW-Rd for ipcdn@optimus.ietf.org; Thu, 09 Oct 2003 16:32:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09748 for ; Thu, 9 Oct 2003 16:32:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7hSt-0004Cj-00 for ipcdn@ietf.org; Thu, 09 Oct 2003 16:32:51 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A7hSi-0004Cf-00 for ipcdn@ietf.org; Thu, 09 Oct 2003 16:32:40 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h99KW7Js016773; Thu, 9 Oct 2003 13:32:07 -0700 (PDT) Received: from milu-w2k.cisco.com (dhcp-171-71-51-93.cisco.com [171.71.51.93]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMZ54136; Thu, 9 Oct 2003 13:32:06 -0700 (PDT) Message-Id: <4.3.2.7.2.20031009133117.0332ab50@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Oct 2003 13:32:05 -0700 To: "Eduardo Cardona" From: Minnie Lu Cc: "Jean-Francois Mule" , "Ipcdn (E-mail)" , "Richard Woundy" , "DOCSIS OSS Majordomo List" , "DOCSIS 2.0 Majordomo List" , "Bert Wijnen" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] RE: Issue#13 IPCDN RF MIBv2 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 Eduardo, Your proposal for issue#13 looks good to me. Thanks a lot ! Minnie At 08:57 AM 10/7/2003 -0600, Eduardo Cardona wrote: >Hi all, > >Attached and below are the item actions for issue #13 >The attached file is text based to facilitate MIB edits later, of if >having formatting difficulties >Reading the same text below. > >Regards > >Eduardo > >-------------------------------------------- >+ Issue #13 >Status: Open >(13) Adjust compliance statements for objects designated optional. Add > separate augmentation table for optional objects in > docsIfCmtsUpChannelCounterTable. > Contributors - Will Murwin Motorola, Rich Woundy IPCDN/Comcast, > Mike StJohns Mindspring, Eduardo Cardona Cablelabs ># category: "must fix" ># Action Item: Eduardo to summarize the discussion & a recommendation ># for the augmentation. Consensus must be reached by 10/10 or else WG ># chair will make a decision. > >Issue item Actions >1) Define the Optional group > >2) Remove the text indication of optional or mandatory object in the >DESCRIPTION clause of objects in table docsIfCmtsUpChannelCounterTable > >3) Decision of AUGMENTING or added columnar Optional objects in >docsIfCmtsUpChannelCounterTable > >1) and 2) are resolved here. > >3) is discussed below and as the references pointed, OSSI spec already >requires > return error codes for Optional object not implemented. Also it is >expected for > OSSI spec to return correct values in full conformance with the >object definition > if the optional objects are supported. > > The decision of separate in two tables the mandatory and optional >objects has two views. > > > a) First CL will recommend not to split the table based on a more >deep overall analysis > From the item 3) notes (end of document) and extra considerations. > - switches to query sub-sets of objects are available in the >case of bad SNMP tool > support of table holes. Not different to handle >implementations previous to > RFImibv2 where neither the mandatory and optional objects are >present. > - Hole cases are not only a problem for this table, many >interface related statistics > has those problems when bulking data to perform later on >filters and association or > aggregation > - From a nmgt integrator data loaders migth handle transparently >tables ( with holes) > vs multiple tables augmentations and/or extensions > - docsIfCmtsUpChannelCounterTable requires hooks to ifTable, and >ifXTable to detect > discontinuities, adminStatus, etc. Therefore The Complexity of >the data validation > in the aggregation side of data loader migth see the whole >table as a not stopper. > > > b) If based on a) there are more compelling reasons to still require >the table split > Only stoppers to split the table currently could be > Implementations that already support the table and in some >business cases the vendor > will place strong opposition to do that because (either items): > - The optional objects are fully supported (no filled with zeros >as draft 05 requires > and corrected in this draft) > - Extensive device implementations > - If optional objects in current implementation (Zeroed), will >not implement Software > versions in place for or after CW28 ( where potentialy draft >08 might be required > if RFC is not published promptly). > > Please respond promptly to the list or in private to vendor >preferences to reach consensus > in this final resolution either to support 3.a or 3.b and reasons why. > > > > Detail changes proposal > > >1) Define the Optional group > >a) Add after Group Clause "GROUP docsIfCmtsGroupV2" > > >-- Optional groups > >GROUP docsIfCmtsOptionalGroupV2 > DESCRIPTION > "This group is optional for Cable Modem Termination Systems, > and not applicable for Cable Modems." > >b) REPLACE: > > >docsIfCmtsGroupV2 OBJECT-GROUP > OBJECTS { > docsIfCmtsCapabilities, > docsIfCmtsSyncInterval, > docsIfCmtsUcdInterval, > docsIfCmtsMaxServiceIds, >-- docsIfCmtsInsertionInterval, > docsIfCmtsInvitedRangingAttempts, > docsIfCmtsInsertInterval, > docsIfCmtsStatusInvalidRangeReqs, > docsIfCmtsStatusRangingAborteds, > docsIfCmtsStatusInvalidRegReqs, > docsIfCmtsStatusFailedRegReqs, > docsIfCmtsStatusInvalidDataReqs, > docsIfCmtsStatusT5Timeouts, > docsIfCmtsCmStatusMacAddress, > docsIfCmtsCmStatusDownChannelIfIndex, > docsIfCmtsCmStatusUpChannelIfIndex, > docsIfCmtsCmStatusRxPower, > docsIfCmtsCmStatusTimingOffset, > docsIfCmtsCmStatusEqualizationData, > docsIfCmtsCmStatusValue, > docsIfCmtsCmStatusUnerroreds, > docsIfCmtsCmStatusCorrecteds, > docsIfCmtsCmStatusUncorrectables, > docsIfCmtsCmStatusSignalNoise, > docsIfCmtsCmStatusMicroreflections, > docsIfCmtsCmStatusExtUnerroreds, > docsIfCmtsCmStatusExtCorrecteds, > docsIfCmtsCmStatusExtUncorrectables, > docsIfCmtsCmStatusDocsisRegMode, > docsIfCmtsCmStatusModulationType, > docsIfCmtsCmStatusInetAddressType, > docsIfCmtsCmStatusInetAddress, > docsIfCmtsCmStatusValueLastUpdate, > docsIfCmtsCmStatusHighResolutionTimingOffset, > docsIfCmtsServiceAdminStatus, > docsIfCmtsServiceQosProfile, > docsIfCmtsServiceCreateTime, > docsIfCmtsServiceInOctets, > docsIfCmtsServiceInPackets, > docsIfCmtsServiceNewCmStatusIndex, > docsIfCmtsModType, > docsIfCmtsModControl, > docsIfCmtsModPreambleLen, > docsIfCmtsModDifferentialEncoding, > docsIfCmtsModFECErrorCorrection, > docsIfCmtsModFECCodewordLength, > docsIfCmtsModScramblerSeed, > docsIfCmtsModMaxBurstSize, > docsIfCmtsModGuardTimeSize, > docsIfCmtsModLastCodewordShortened, > docsIfCmtsModScrambler, > docsIfCmtsModByteInterleaverDepth, > docsIfCmtsModByteInterleaverBlockSize, > docsIfCmtsModPreambleType, > docsIfCmtsModTcmErrorCorrectionOn, > docsIfCmtsModScdmaInterleaverStepSize, > docsIfCmtsModScdmaSpreaderEnable, > docsIfCmtsModScdmaSubframeCodes, > docsIfCmtsModChannelType, > docsIfCmtsQosProfilePermissions, > docsIfCmtsCmPtr, > docsIfCmtsChannelUtilizationInterval, > docsIfCmtsChannelUtUtilization, > docsIfCmtsDownChnlCtrId, > docsIfCmtsDownChnlCtrTotalBytes, > docsIfCmtsDownChnlCtrUsedBytes, > docsIfCmtsDownChnlCtrExtTotalBytes, > docsIfCmtsDownChnlCtrExtUsedBytes, > docsIfCmtsUpChnlCtrId, > docsIfCmtsUpChnlCtrTotalMslots, > docsIfCmtsUpChnlCtrUcastGrantedMslots, > docsIfCmtsUpChnlCtrTotalCntnMslots, > docsIfCmtsUpChnlCtrUsedCntnMslots, > docsIfCmtsUpChnlCtrExtTotalMslots, > docsIfCmtsUpChnlCtrExtUcastGrantedMslots, > docsIfCmtsUpChnlCtrExtTotalCntnMslots, > docsIfCmtsUpChnlCtrExtUsedCntnMslots, > docsIfCmtsUpChnlCtrCollCntnMslots, > docsIfCmtsUpChnlCtrTotalCntnReqMslots, > docsIfCmtsUpChnlCtrUsedCntnReqMslots, > docsIfCmtsUpChnlCtrCollCntnReqMslots, > docsIfCmtsUpChnlCtrTotalCntnReqDataMslots, > docsIfCmtsUpChnlCtrUsedCntnReqDataMslots, > docsIfCmtsUpChnlCtrCollCntnReqDataMslots, > docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots, > docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots, > docsIfCmtsUpChnlCtrCollCntnInitMaintMslots, > docsIfCmtsUpChnlCtrExtCollCntnMslots, > docsIfCmtsUpChnlCtrExtTotalCntnReqMslots, > docsIfCmtsUpChnlCtrExtUsedCntnReqMslots, > docsIfCmtsUpChnlCtrExtCollCntnReqMslots, > docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots, > docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots, > docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots, > docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots, > docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots, > docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots > } > STATUS current > DESCRIPTION > "Group of objects implemented in Cable Modem Termination > Systems." > ::= { docsIfGroupsV2 3 } > > WITH: > > >docsIfCmtsGroupV2 OBJECT-GROUP > OBJECTS { > docsIfCmtsCapabilities, > docsIfCmtsSyncInterval, > docsIfCmtsUcdInterval, > docsIfCmtsMaxServiceIds, >-- docsIfCmtsInsertionInterval, > docsIfCmtsInvitedRangingAttempts, > docsIfCmtsInsertInterval, > docsIfCmtsStatusInvalidRangeReqs, > docsIfCmtsStatusRangingAborteds, > docsIfCmtsStatusInvalidRegReqs, > docsIfCmtsStatusFailedRegReqs, > docsIfCmtsStatusInvalidDataReqs, > docsIfCmtsStatusT5Timeouts, > docsIfCmtsCmStatusMacAddress, > docsIfCmtsCmStatusDownChannelIfIndex, > docsIfCmtsCmStatusUpChannelIfIndex, > docsIfCmtsCmStatusRxPower, > docsIfCmtsCmStatusTimingOffset, > docsIfCmtsCmStatusEqualizationData, > docsIfCmtsCmStatusValue, > docsIfCmtsCmStatusUnerroreds, > docsIfCmtsCmStatusCorrecteds, > docsIfCmtsCmStatusUncorrectables, > docsIfCmtsCmStatusSignalNoise, > docsIfCmtsCmStatusMicroreflections, > docsIfCmtsCmStatusExtUnerroreds, > docsIfCmtsCmStatusExtCorrecteds, > docsIfCmtsCmStatusExtUncorrectables, > docsIfCmtsCmStatusDocsisRegMode, > docsIfCmtsCmStatusModulationType, > docsIfCmtsCmStatusInetAddressType, > docsIfCmtsCmStatusInetAddress, > docsIfCmtsCmStatusValueLastUpdate, > docsIfCmtsCmStatusHighResolutionTimingOffset, > docsIfCmtsServiceAdminStatus, > docsIfCmtsServiceQosProfile, > docsIfCmtsServiceCreateTime, > docsIfCmtsServiceInOctets, > docsIfCmtsServiceInPackets, > docsIfCmtsServiceNewCmStatusIndex, > docsIfCmtsModType, > docsIfCmtsModControl, > docsIfCmtsModPreambleLen, > docsIfCmtsModDifferentialEncoding, > docsIfCmtsModFECErrorCorrection, > docsIfCmtsModFECCodewordLength, > docsIfCmtsModScramblerSeed, > docsIfCmtsModMaxBurstSize, > docsIfCmtsModGuardTimeSize, > docsIfCmtsModLastCodewordShortened, > docsIfCmtsModScrambler, > docsIfCmtsModByteInterleaverDepth, > docsIfCmtsModByteInterleaverBlockSize, > docsIfCmtsModPreambleType, > docsIfCmtsModTcmErrorCorrectionOn, > docsIfCmtsModScdmaInterleaverStepSize, > docsIfCmtsModScdmaSpreaderEnable, > docsIfCmtsModScdmaSubframeCodes, > docsIfCmtsModChannelType, > docsIfCmtsQosProfilePermissions, > docsIfCmtsCmPtr, > docsIfCmtsChannelUtilizationInterval, > docsIfCmtsChannelUtUtilization, > docsIfCmtsDownChnlCtrId, > docsIfCmtsDownChnlCtrTotalBytes, > docsIfCmtsDownChnlCtrUsedBytes, > docsIfCmtsDownChnlCtrExtTotalBytes, > docsIfCmtsDownChnlCtrExtUsedBytes, > docsIfCmtsUpChnlCtrId, > docsIfCmtsUpChnlCtrTotalMslots, > docsIfCmtsUpChnlCtrUcastGrantedMslots, > docsIfCmtsUpChnlCtrTotalCntnMslots, > docsIfCmtsUpChnlCtrUsedCntnMslots, > docsIfCmtsUpChnlCtrExtTotalMslots, > docsIfCmtsUpChnlCtrExtUcastGrantedMslots, > docsIfCmtsUpChnlCtrExtTotalCntnMslots, > docsIfCmtsUpChnlCtrExtUsedCntnMslots > } > STATUS current > DESCRIPTION > "Group of objects implemented in Cable Modem Termination > Systems." > ::= { docsIfGroupsV2 3 } > >docsIfCmtsOptionalGroupV2 OBJECT-GROUP > OBJECTS { > docsIfCmtsUpChnlCtrCollCntnMslots, > docsIfCmtsUpChnlCtrTotalCntnReqMslots, > docsIfCmtsUpChnlCtrUsedCntnReqMslots, > docsIfCmtsUpChnlCtrCollCntnReqMslots, > docsIfCmtsUpChnlCtrTotalCntnReqDataMslots, > docsIfCmtsUpChnlCtrUsedCntnReqDataMslots, > docsIfCmtsUpChnlCtrCollCntnReqDataMslots, > docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots, > docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots, > docsIfCmtsUpChnlCtrCollCntnInitMaintMslots, > docsIfCmtsUpChnlCtrExtCollCntnMslots, > docsIfCmtsUpChnlCtrExtTotalCntnReqMslots, > docsIfCmtsUpChnlCtrExtUsedCntnReqMslots, > docsIfCmtsUpChnlCtrExtCollCntnReqMslots, > docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots, > docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots, > docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots, > docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots, > docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots, > docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots > } > STATUS current > DESCRIPTION > "Group of objects implemented optionaly in Cable Modem > Termination Systems." > ::= { docsIfGroupsV2 4 } > > > >2) Remove the text indication of optional or mandatory object in the >DESCRIPTION clause of objects in table docsIfCmtsUpChannelCounterTable > >Change several occurences of "the the" with "the" > > >remove text from DESCRIPTION clauses: >Support for this object is optional. If the object is not > supported, a value of zero is returned. >a) REPLACE: > >docsIfCmtsUpChnlCtrCollCntnMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > minislots subjected to collisions on the upstream logical > channel. For contention regions, these are the minislots > applicable to bursts that the CMTS detected, but could not > correctly receive. This is the 32 bit version of > docsIfCmtsUpChnlCtrExtCollCntnMslots, and is included for > back compatibility with SNMPv1 managers. Support for this > object is optional. If the object is not supported, a > value of zero is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 10 } > > >docsIfCmtsUpChnlCtrTotalCntnReqMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request minislots defined for this upstream logical > channel. This count includes all minislots for IUC1 > assigned to a broadcast or multicast SID on the logical > channel. This is the 32 bit version of > docsIfCmtsUpChnlCtrExtTotalCntnReqMslots, and is included > for back compatibility with SNMPv1 managers. > Support for this object is optional. If the object is not > supported, a value of zero is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 11 } > > >docsIfCmtsUpChnlCtrUsedCntnReqMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request minislots utilized on this upstream logical > channel. This count includes all contention minislots for > IUC1 applicable to bursts that the CMTS correctly > received. This is the 32 bit version of > docsIfCmtsUpChnlCtrExtUsedCntnReqMslots, and is included > for back compatibility with SNMPv1 managers. Support for > this object is optional. If the object is not supported, > a value of zero is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 12 } > > >docsIfCmtsUpChnlCtrCollCntnReqMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request minislots subjected to collisions on this upstream > logical channel. This includes all contention minislots > for IUC1 applicable to bursts that the CMTS detected, but > could not correctly receive. This is the 32 bit version of > docsIfCmtsUpChnlCtrExtCollCntnReqMslots, and is included > for back compatibility with SNMPv1 managers. Support for > this object is optional. If the object is not supported, > a value of zero is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 13 } > > >docsIfCmtsUpChnlCtrTotalCntnReqDataMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request data minislots defined for this upstream logical > channel. This count includes all minislots for IUC2 > assigned to a broadcast or multicast SID on the logical > channel. This is the 32 bit version of > docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots, and is > included for back compatibility with SNMPv1 managers. > Support for this object is optional. If the object is not > supported, a value of zero is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 14 } > > >docsIfCmtsUpChnlCtrUsedCntnReqDataMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request data minislots utilized on this upstream logical > channel. This includes all contention minislots for IUC2 > applicable to bursts that the CMTS correctly received. > This is the 32 bit version of > docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots, and is > included for back compatibility with SNMPv1 managers. > Support for this object is optional. If the object is not > supported, a value of zero is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 15 } > > >docsIfCmtsUpChnlCtrCollCntnReqDataMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request data minislots subjected to collisions on this > upstream logical channel. This includes all contention > minislots for IUC2 applicable to bursts that the CMTS > detected, but could not correctly receive. This is the 32 > bit version of > docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots, and is > included for back compatibility with SNMPv1 managers. > Support for this object is optional. If the object is not > supported, a value of zero is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 16 } > > >docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > initial maintenance minislots defined for this upstream > logical channel. This includes all minislots for IUC3 > assigned to a broadcast or multicast SID on the logical > channel. This is the 32 bit version of > docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots, > and is included for back compatibility with SNMPv1 > managers. Support for this object is optional. If the > object is not supported, a value of zero is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 17 } > > >docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > initial maintenance minislots utilized on this upstream > logical channel. This includes all contention minislots > for IUC3 applicable to bursts that the CMTS correctly > received. This is the 32 bit version of > docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots, > and is included for back compatibility with SNMPv1 > managers. Support for this object is optional. If the > object is not supported, a value of zero is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 18 } > > >docsIfCmtsUpChnlCtrCollCntnInitMaintMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > initial maintenance minislots subjected to collisions on > this upstream logical channel. This includes all > contention minislots for IUC3 applicable to bursts that > the CMTS detected, but could not correctly receive. > This is the 32 bit version of > docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots, > and is included for back compatibility with SNMPv1 > managers. Support for this object is optional. If the > object is not supported, a value of zero is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 19 } > > >docsIfCmtsUpChnlCtrExtCollCntnMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of collision > contention minislots on the upstream logical channel. > For contention regions, these are the minislots applicable > to bursts that the CMTS detected, but could not correctly > receive. This is the 64 bit version of > docsIfCmtsUpChnlCtrCollCntnMslots, and will not be > accessible to SNMPv1 managers. Support for this object is > optional. If the object is not supported, a value of zero > is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 20 } > > >docsIfCmtsUpChnlCtrExtTotalCntnReqMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request minislots defined for this upstream logical > channel. This count includes all minislots for IUC1 > assigned to a broadcast or multicast SID on the logical > channel. This is the 64 bit version of > docsIfCmtsUpChnlCtrTotalCntnReqMslots, and will not be > accessible to SNMPv1 managers. Support for this object > is optional. If the object is not supported, a value of > zero is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 21 } > > >docsIfCmtsUpChnlCtrExtUsedCntnReqMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request minislots utilized on this upstream logical > channel. This count includes all contention minislots for > IUC1 applicable to bursts that the CMTS correctly > received. This is the 64 bit version of > docsIfCmtsUpChnlCtrUsedCntnReqMslots, and will not be > accessible to SNMPv1 managers. Support for this object is > optional. If the object is not supported, a value of zero > is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 22 } > > >docsIfCmtsUpChnlCtrExtCollCntnReqMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request minislots subjected to collisions on this upstream > logical channel. This includes all contention minislots > for IUC1 applicable to bursts that the CMTS detected, > but could not correctly receive. This is the 64 bit > version of docsIfCmtsUpChnlCtrCollCntnReqMslots, and will > not be accessible to SNMPv1 managers. Support for this > object is optional. If the object is not supported, a > value of zero is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 23 } > > >docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request data minislots defined for this upstream logical > channel. This count includes all minislots for IUC2 > assigned to a broadcast or multicast SID on the logical > channel. This is the 64 bit version of > docsIfCmtsUpChnlCtrTotalCntnReqDataMslots, and will not be > accessible to SNMPv1 managers. Support for this object is > optional. If the object is not supported, a value of zero > is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 24 } > > >docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request data minislots utilized on this upstream logical > channel. This includes all contention minislots for IUC2 > applicable to bursts that the CMTS correctly received. > This is the 64 bit version of > docsIfCmtsUpChnlCtrUsedCntnReqDataMslots, and will not be > accessible to SNMPv1 managers. Support for this object is > optional. If the object is not supported, a value of zero > is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 25 } > > >docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request data minislots subjected to collisions on this > upstream logical channel. This includes all contention > minislots for IUC2 applicable to bursts that the CMTS > detected, but could not correctly receive. This is the > 64 bit version of > docsIfCmtsUpChnlCtrCollCntnReqDataMslots, > and will not be accessible to SNMPv1 managers. Support > for this object is optional. If the object is not > supported, a value of zero is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 26 } > > >docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of initial > maintenance minislots defined for this upstream logical > channel. This count includes all minislots for IUC3 > assigned to a broadcast or multicast SID on the logical > channel. This is the 64 bit version of > docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots, > and will not be accessible to SNMPv1 managers. Support for > this object is optional. If the object is not supported, > a value of zero is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 27 } > > >docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of initial > maintenance minislots utilized on this upstream logical > channel. This includes all contention minislots for IUC3 > applicable to bursts that the CMTS correctly received. > This is the 64 bit version of > docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots, > and will not be accessible to SNMPv1 managers. Support for > this object is optional. If the object is not supported, > a value of zero is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 28 } > > >docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > initial maintenance minislots subjected to collisions on > this upstream logical channel. This includes all > contention minislots for IUC3 applicable to bursts that > the CMTS detected, but could not correctly receive. > This is the 64 bit version of > docsIfCmtsUpChnlCtrCollCntnInitMaintMslots, and will not > be accessible to SNMPv1 managers. Support for this object > is optional. If the object is not supported, a value of > zero is returned. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 29 } > > >WITH: > >docsIfCmtsUpChnlCtrCollCntnMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > minislots subjected to collisions on the upstream logical > channel. For contention regions, these are the minislots > applicable to bursts that the CMTS detected, but could not > correctly receive. This is the 32 bit version of > docsIfCmtsUpChnlCtrExtCollCntnMslots, and is included for > back compatibility with SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 10 } > > >docsIfCmtsUpChnlCtrTotalCntnReqMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request minislots defined for this upstream logical > channel. This count includes all minislots for IUC1 > assigned to a broadcast or multicast SID on the logical > channel. This is the 32 bit version of > docsIfCmtsUpChnlCtrExtTotalCntnReqMslots, and is included > for back compatibility with SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 11 } > > >docsIfCmtsUpChnlCtrUsedCntnReqMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request minislots utilized on this upstream logical > channel. This count includes all contention minislots for > IUC1 applicable to bursts that the CMTS correctly > received. This is the 32 bit version of > docsIfCmtsUpChnlCtrExtUsedCntnReqMslots, and is included > for back compatibility with SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 12 } > > >docsIfCmtsUpChnlCtrCollCntnReqMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request minislots subjected to collisions on this upstream > logical channel. This includes all contention minislots > for IUC1 applicable to bursts that the CMTS detected, but > could not correctly receive. This is the 32 bit version of > docsIfCmtsUpChnlCtrExtCollCntnReqMslots, and is included > for back compatibility with SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 13 } > > >docsIfCmtsUpChnlCtrTotalCntnReqDataMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request data minislots defined for this upstream logical > channel. This count includes all minislots for IUC2 > assigned to a broadcast or multicast SID on the logical > channel. This is the 32 bit version of > docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots, and is > included for back compatibility with SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 14 } > > >docsIfCmtsUpChnlCtrUsedCntnReqDataMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request data minislots utilized on this upstream logical > channel. This includes all contention minislots for IUC2 > applicable to bursts that the CMTS correctly received. > This is the 32 bit version of > docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots, and is > included for back compatibility with SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 15 } > > >docsIfCmtsUpChnlCtrCollCntnReqDataMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request data minislots subjected to collisions on this > upstream logical channel. This includes all contention > minislots for IUC2 applicable to bursts that the CMTS > detected, but could not correctly receive. This is the 32 > bit version of > docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots, and is > included for back compatibility with SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 16 } > > >docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > initial maintenance minislots defined for this upstream > logical channel. This includes all minislots for IUC3 > assigned to a broadcast or multicast SID on the logical > channel. This is the 32 bit version of > docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots, > and is included for back compatibility with SNMPv1 > managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 17 } > > >docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > initial maintenance minislots utilized on this upstream > logical channel. This includes all contention minislots > for IUC3 applicable to bursts that the CMTS correctly > received. This is the 32 bit version of > docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots, > and is included for back compatibility with SNMPv1 > managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 18 } > > >docsIfCmtsUpChnlCtrCollCntnInitMaintMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > initial maintenance minislots subjected to collisions on > this upstream logical channel. This includes all > contention minislots for IUC3 applicable to bursts that > the CMTS detected, but could not correctly receive. > This is the 32 bit version of > docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots, > and is included for back compatibility with SNMPv1 > managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 19 } > > >docsIfCmtsUpChnlCtrExtCollCntnMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of collision > contention minislots on the upstream logical channel. > For contention regions, these are the minislots applicable > to bursts that the CMTS detected, but could not correctly > receive. This is the 64 bit version of > docsIfCmtsUpChnlCtrCollCntnMslots, and will not be > accessible to SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 20 } > > >docsIfCmtsUpChnlCtrExtTotalCntnReqMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request minislots defined for this upstream logical > channel. This count includes all minislots for IUC1 > assigned to a broadcast or multicast SID on the logical > channel. This is the 64 bit version of > docsIfCmtsUpChnlCtrTotalCntnReqMslots, and will not be > accessible to SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 21 } > > >docsIfCmtsUpChnlCtrExtUsedCntnReqMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request minislots utilized on this upstream logical > channel. This count includes all contention minislots for > IUC1 applicable to bursts that the CMTS correctly > received. This is the 64 bit version of > docsIfCmtsUpChnlCtrUsedCntnReqMslots, and will not be > accessible to SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 22 } > > >docsIfCmtsUpChnlCtrExtCollCntnReqMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request minislots subjected to collisions on this upstream > logical channel. This includes all contention minislots > for IUC1 applicable to bursts that the CMTS detected, > but could not correctly receive. This is the 64 bit > version of docsIfCmtsUpChnlCtrCollCntnReqMslots, and will > not be accessible to SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 23 } > > >docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request data minislots defined for this upstream logical > channel. This count includes all minislots for IUC2 > assigned to a broadcast or multicast SID on the logical > channel. This is the 64 bit version of > docsIfCmtsUpChnlCtrTotalCntnReqDataMslots, and will not be > accessible to SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 24 } > > >docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request data minislots utilized on this upstream logical > channel. This includes all contention minislots for IUC2 > applicable to bursts that the CMTS correctly received. > This is the 64 bit version of > docsIfCmtsUpChnlCtrUsedCntnReqDataMslots, and will not be > accessible to SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 25 } > > >docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > request data minislots subjected to collisions on this > upstream logical channel. This includes all contention > minislots for IUC2 applicable to bursts that the CMTS > detected, but could not correctly receive. This is the > 64 bit version of > docsIfCmtsUpChnlCtrCollCntnReqDataMslots, > and will not be accessible to SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 26 } > > >docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of initial > maintenance minislots defined for this upstream logical > channel. This count includes all minislots for IUC3 > assigned to a broadcast or multicast SID on the logical > channel. This is the 64 bit version of > docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots, > and will not be accessible to SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 27 } > > >docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of initial > maintenance minislots utilized on this upstream logical > channel. This includes all contention minislots for IUC3 > applicable to bursts that the CMTS correctly received. > This is the 64 bit version of > docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots, > and will not be accessible to SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 28 } > > >docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > initial maintenance minislots subjected to collisions on > this upstream logical channel. This includes all > contention minislots for IUC3 applicable to bursts that > the CMTS detected, but could not correctly receive. > This is the 64 bit version of > docsIfCmtsUpChnlCtrCollCntnInitMaintMslots, and will not > be accessible to SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 29 } >Remove Text "Support for this object is mandatory." >b) REPLACE > >docsIfCmtsUpChnlCtrTotalMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of all minislots > defined for this upstream logical channel. This count > includes all IUCs and SIDs, even those allocated to the > NULL SID for a 2.0 logical channel which is inactive. This > is the 32 bit version of docsIfCmtsUpChnlCtrExtTotalMslots > and is included for back compatibility with SNMPv1 > managers. Support for this object is mandatory. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 2 } > > >docsIfCmtsUpChnlCtrUcastGrantedMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of unicast > granted minislots on the upstream logical channel, > regardless of burst type. Unicast granted minislots are > those in which the CMTS assigned bandwidth to any unicast > SID on the logical channel. However this object does not > include minislots for reserved IUCs, or grants to SIDs > designated as meaning 'no CM'. This is the 32 bit version > of docsIfCmtsUpChnlCtrExtUcastGrantedMslots, and is > included for back compatibility with SNMPv1 managers. > Support for this object is mandatory. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 3 } > > >docsIfCmtsUpChnlCtrTotalCntnMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > minislots defined for this upstream logical channel. This > count includes all minislots assigned to a broadcast or > multicast SID on the logical channel. This is the 32 bit > version of docsIfCmtsUpChnlCtrExtTotalCntnMslots, and is > included for back compatibility with SNMPv1 managers. > Support for this object is mandatory. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 4 } > > >docsIfCmtsUpChnlCtrUsedCntnMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > minislots utilized on the upstream logical channel. For > contention regions, utilized minislots are those in which > the CMTS correctly received an upstream burst from any CM > on the upstream logical channel. This is the 32 bit > version of docsIfCmtsUpChnlCtrExtUsedCntnMslots, and is > included for back compatibility with SNMPv1 managers. > Support for this object is mandatory. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 5 } > > >docsIfCmtsUpChnlCtrExtTotalMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of all minislots > defined for this upstream logical channel. This count > includes all IUCs and SIDs, even those allocated to the > NULL SID for a 2.0 logical channel which is inactive. This > is the 64 bit version of docsIfCmtsUpChnlCtrTotalMslots, > and will not be accessible to SNMPv1 managers. > Support for this object is mandatory. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 6 } > > >docsIfCmtsUpChnlCtrExtUcastGrantedMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of unicast > granted minislots on the upstream logical channel, > regardless of burst type. Unicast granted minislots are > those in which the CMTS assigned bandwidth to any unicast > SID on the logical channel. However this object does not > include minislots for reserved IUCs, or grants to SIDs > designated as meaning 'no CM'. This is the 64 bit version > of docsIfCmtsUpChnlCtrUcastGrantedMslots, and will not be > accessible to SNMPv1 managers. > Support for this object is mandatory. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 7 } > > >docsIfCmtsUpChnlCtrExtTotalCntnMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > minislots defined for this upstream logical channel. This > count includes all minislots assigned to a broadcast or > multicast SID on the logical channel. This is the 64 bit > version of docsIfCmtsUpChnlCtrTotalCntnMslots, and will > not be accessible to SNMPv1 managers. > Support for this object is mandatory. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 8 } > > >docsIfCmtsUpChnlCtrExtUsedCntnMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > minislots utilized on the upstream logical channel. For > contention regions, utilized minislots are those in which > the CMTS correctly received an upstream burst from any CM > on the upstream logical channel. This is the 64 bit > version of docsIfCmtsUpChnlCtrUsedCntnMslots, and will not > be accessible to SNMPv1 managers. > Support for this object is mandatory. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 9 } > > >WITH > >docsIfCmtsUpChnlCtrTotalMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of all minislots > defined for this upstream logical channel. This count > includes all IUCs and SIDs, even those allocated to the > NULL SID for a 2.0 logical channel which is inactive. This > is the 32 bit version of docsIfCmtsUpChnlCtrExtTotalMslots > and is included for back compatibility with SNMPv1 > managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 2 } > > >docsIfCmtsUpChnlCtrUcastGrantedMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of unicast > granted minislots on the upstream logical channel, > regardless of burst type. Unicast granted minislots are > those in which the CMTS assigned bandwidth to any unicast > SID on the logical channel. However this object does not > include minislots for reserved IUCs, or grants to SIDs > designated as meaning 'no CM'. This is the 32 bit version > of docsIfCmtsUpChnlCtrExtUcastGrantedMslots, and is > included for back compatibility with SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 3 } > > >docsIfCmtsUpChnlCtrTotalCntnMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > minislots defined for this upstream logical channel. This > count includes all minislots assigned to a broadcast or > multicast SID on the logical channel. This is the 32 bit > version of docsIfCmtsUpChnlCtrExtTotalCntnMslots, and is > included for back compatibility with SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 4 } > > >docsIfCmtsUpChnlCtrUsedCntnMslots OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > minislots utilized on the upstream logical channel. For > contention regions, utilized minislots are those in which > the CMTS correctly received an upstream burst from any CM > on the upstream logical channel. This is the 32 bit > version of docsIfCmtsUpChnlCtrExtUsedCntnMslots, and is > included for back compatibility with SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 5 } > > >docsIfCmtsUpChnlCtrExtTotalMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of all minislots > defined for this upstream logical channel. This count > includes all IUCs and SIDs, even those allocated to the > NULL SID for a 2.0 logical channel which is inactive. This > is the 64 bit version of docsIfCmtsUpChnlCtrTotalMslots, > and will not be accessible to SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 6 } > > >docsIfCmtsUpChnlCtrExtUcastGrantedMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of unicast > granted minislots on the upstream logical channel, > regardless of burst type. Unicast granted minislots are > those in which the CMTS assigned bandwidth to any unicast > SID on the logical channel. However this object does not > include minislots for reserved IUCs, or grants to SIDs > designated as meaning 'no CM'. This is the 64 bit version > of docsIfCmtsUpChnlCtrUcastGrantedMslots, and will not be > accessible to SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 7 } > > >docsIfCmtsUpChnlCtrExtTotalCntnMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > minislots defined for this upstream logical channel. This > count includes all minislots assigned to a broadcast or > multicast SID on the logical channel. This is the 64 bit > version of docsIfCmtsUpChnlCtrTotalCntnMslots, and will > not be accessible to SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 8 } > > >docsIfCmtsUpChnlCtrExtUsedCntnMslots OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current count, from CMTS initialization, of contention > minislots utilized on the upstream logical channel. For > contention regions, utilized minislots are those in which > the CMTS correctly received an upstream burst from any CM > on the upstream logical channel. This is the 64 bit > version of docsIfCmtsUpChnlCtrUsedCntnMslots, and will not > be accessible to SNMPv1 managers. > Discontinuities in the value of this counter can occur > at reinitialization of the managed system, and at other > times as indicated by the the value of > ifCounterDiscontinuityTime for the associated ifIndex." > ::= { docsIfCmtsUpChannelCounterEntry 9 } > > > >3) Decision of AUGMENTING or added columnar Optional objects in >docsIfCmtsUpChannelCounterTable > >This topic was discused in good deep in the ipcdn list and very good >contributions were made, ( complete email log is in IPCDN web page) >To mention, one of the most relevant comments, was from Rich Woundy >May 30 2003, with subject >"Optional" in the description of objects from the rfimibv2 > >Rich quoted the section of RFC 2863 3.1.18 "All values Must be Known" >Where an agent that does not support a counter permanently must not >instantiate the object (e.g. for a particular ifIndex ifTable counter or > >table extension) >or >temporarly, the Agent haven't complete the initialization of the entity >or > the counter function. > >In summary, the agent will respond with error 'noSuchObject' if object >is >completely unknown to the implementation (e.g optional implementation) >or >'noSuchInstance' if the specified row of the object is not valid. > >Another reference point is the OSSI spec. > >Since early OSSI mib object requirements, the OSS requires for optional >objects the following ( in total synch with Rich's quoted text): > >Optional mib objects in Annex A Detailed MIB Requirements (normative) > >"O Optional. A vendor can choose to implement or not implement the >object. >If a vendor chooses to implement the object, the object MUST be >implemented >correctly according to the MIB definition. If a vendor chooses not to >implement >the object, an agent MUST NOT instantiate such object and MUST respond >with >the appropriate error/exception condition (e.g., no such object for >SNMPv2c)." > >It is clear that the expected behavior per OSSI spec is to find tables >with >'holes' which is also the IETF recomendation. > >Conclusion > > From the spec point of view the table with the changes is fine, no need >to >split and management software implementers and operators might explore >unified >cata loader since this problem is not exclusive of this table, but in >general >for all interface related statistics and software versioning. > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Oct 9 18:00:54 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 RAA11402 for ; Thu, 9 Oct 2003 17:14:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7i6l-0000hm-CS for ipcdn-archive@odin.ietf.org; Thu, 09 Oct 2003 17:14:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99LE3jq002699 for ipcdn-archive@odin.ietf.org; Thu, 9 Oct 2003 17:14:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7i6j-0000h4-Gn; Thu, 09 Oct 2003 17:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7fUE-00069C-Qs for ipcdn@optimus.ietf.org; Thu, 09 Oct 2003 14:26:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02567 for ; Thu, 9 Oct 2003 14:25:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7fUC-0002Mk-00 for ipcdn@ietf.org; Thu, 09 Oct 2003 14:26:04 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A7fU7-0002MU-00 for ipcdn@ietf.org; Thu, 09 Oct 2003 14:25:59 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 09 Oct 2003 11:26:29 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h99IPQXg004213; Thu, 9 Oct 2003 11:25:27 -0700 (PDT) Received: from milu-w2k.cisco.com (dhcp-171-71-51-93.cisco.com [171.71.51.93]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMZ37476; Thu, 9 Oct 2003 11:25:25 -0700 (PDT) Message-Id: <4.3.2.7.2.20031009111217.032daf00@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Oct 2003 11:25:25 -0700 To: David.White@arrisi.com From: Minnie Lu Cc: "Greg White" , "DOCSIS OSS Majordomo List" , Greg.Gohman@arrisi.com, ipcdn@ietf.org, Larry.Spaete@arrisi.com, "Minnie Lu" , owner-docsis-oss@cablelabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) 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, David, Your concern sounds very valid. Then it seems to me that 1. either have docsIfUpChannelType is read-only and ask the docsIfUpChannelModulationProfile must be assigned first before setting other upstream attributes. For this is one, I don't know user would like it or not. 2. or we still need to keep the docsIfUpChannelType is read-create, so it can be used to check other upstream attributes consistence without having an modulation profile assigned. The user must make sure both docsIfUpChannelModulationProfile and docsIfUpChannelType are the same when trying to set either one of them if docsIfUpChannelModulationProfile is not value 0. If they are not consistent, the set will fail. Any more possible solution ? Just some more thoughts. Thanks a lot ! Minnie At 11:35 AM 10/9/2003 -0400, David.White@arrisi.com wrote: >Greg, > The main problem I have with this is that it forces the CMTS to > postpone data checking until possibly the very end when the modulation > profile is finally assigned. That is, the user may get a wrongValue or > inconsistentValue while attempting to set the modulation profile because > one or more already-set parameters do not agree with the ModChannelType. > What I liked about having the UpChannelType being a configurable and > "active" (rather than passive) object is that the CMTS verify things like > ChannelWidth, SlotSize, and the Scdma parameters as they are being set. > Thus, the error is immediate and pertitent. > >However, what I like about your proposal is that it makes it easier to >transition an upstream channel from tdma, atdma, and tdmaAndAtdma without >having to change both the modulation profile and UpChannelType at the same >time. > >I'm not rejecting your proposal, but just wanted to voice my concerns. > >Thanks, >David > > > >"Greg White" >Sent by: owner-docsis-oss@cablelabs.com > >10/08/2003 07:35 PM > > To: > cc: "DOCSIS OSS Majordomo List" > , , , > , "Minnie Lu" > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 > : rules for assigning modulation profiles to upstream channels) > > >David, > >According to the proposed text, docsIfUpChannelType would be read-only for >ALL rows. > >For "active" rows (docsIfUpChannelStatus = active(1)) setting >UpChannelModulationProfile would return an error if the channel type of >the profile does not work with the other parameters in the row. > >For "cloned" rows (docsIfUpChannelStatus = notInService(2)) no >verification is done on consistency of parameters until >docsIfUpChannelUpdate is set to true. > >The verification for active rows is indicated in the proposed text for >UpChannelModulationProfile, although it looks like it could be clarified: > > Setting this object on an "active" row MUST return an error > if the following > conditions are not satisfied: > 1. All the IUC entries in the selected modulation profile > MUST have the same value of docsIfCmtsModChannelType. > 2. All of the modulation parameters in the selected > modulation profile MUST be consistent with the other > parameters in this docsIfUpChannelEntry. > >Does that address your concern? > >-Greg > >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Wednesday, October 08, 2003 3:11 PM >To: Greg White >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; >Larry.Spaete@arrisi.com; Minnie Lu >Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Greg, > Per your earlier e-mail on this thread: > >"Also, I would like to propose that we make docsIfUpChannelType a >read-only object for active rows in the Upstream Channel Table. >The value reported would be taken from the modulation profile pointed >to by docsIfUpChannelModulationProfile." > >I'm assuming "active" mean in-service. Otherwise, we have to be careful >with this because the channelType is used to verify things like >channelWidth and whether or not setting of the scdma-specific parameters >is allowed. Along the same lines, if setting the upstream modulation >profile index implies that the SNMP agent changes the upChannelType to >match the modProfChannelType, then the agent must also verify that all of >the other parameters in the upstream channel are compatible with the >possibly new channel type. > >David > > >"Greg White" > >10/08/2003 04:12 PM > To: "Minnie Lu" > cc: , "DOCSIS OSS Majordomo List" > , , > , > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 > : rules for assigning modulation profiles to upstream channels) > > > >Minnie, > >I didn't want to prevent a user from changing their mind regarding >channel type when creating a new modulation profile. Suppose you >started out setting channel type to atdma and, after completing a few >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make >you start from scratch (or do a simultaneous set across all IUCs), you >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Hi, Greg, > >Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the >modulation profile is not assigned to any upstreams. So the error could >be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please review >the > >attached proposal and provide comments. > > > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , , , > > > "DOCSIS OSS Majordomo List" , "Owner DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same > > >ModChannelType. Also, based on the exchange here it seems that there >is > > >some support for the additional restriction that UpChannelType and > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change > > >UpChannelType to match ModChannelType whenever > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about the > >case that some modulation profile is used by some upstream channel, and > >user change the modulation profile channel type ? Does it mean that >the > >upstream channel type would be changed automatically, too ? If yes, I >am > >afraid that there might be some user who forget the modulation profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The > >modulation profile channel type and upstream channel type are in two > >different MIB tables. > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type be > >changed ? Maybe this is a confusing point which needs to be clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > > >upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation profile > > >entries with the same docsIfCmtsModIndex will have to have the same > > >docsIfCmtsModChannelType. Otherwise, you would not be able to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid, no >? > > >The way to patch it up would be to make all of the IUCs tdmaAndAtdma, > > >correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List" > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects > > > > docsIfCmtsModByteInterleaverBlockSize and > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma for > > > > modulation profiles that could not be met with a pair of tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line of > > > >thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations. Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of having >the > > > >MIB reporting something that doesn't exactly reflect what is > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the > > > > modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data for > > > > consistency. Furthermore, it would seem possible to compare the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Oct 9 18:44:23 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 SAA15334 for ; Thu, 9 Oct 2003 18:44:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7jVr-0005sF-11 for ipcdn-archive@odin.ietf.org; Thu, 09 Oct 2003 18:44:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99Mi3Zo022580 for ipcdn-archive@odin.ietf.org; Thu, 9 Oct 2003 18:44:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7jVo-0005ry-Ty; Thu, 09 Oct 2003 18:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7jUt-0005ot-4s for ipcdn@optimus.ietf.org; Thu, 09 Oct 2003 18:43:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15322 for ; Thu, 9 Oct 2003 18:42:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7jUp-0005dC-00 for ipcdn@ietf.org; Thu, 09 Oct 2003 18:42:59 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A7jUo-0005cx-00 for ipcdn@ietf.org; Thu, 09 Oct 2003 18:42:58 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h99MUZ10005733; Thu, 9 Oct 2003 16:30:35 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Oct 2003 16:30:35 -0600 Message-ID: Thread-Topic: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcOOktBv0hn4SqViTae2STkl2UxTNwABYoEwAAWCS7A= From: "Greg White" To: "Eduardo Cardona" , "Minnie Lu" , Cc: "DOCSIS OSS Majordomo List" , , , , "Owner DOCSIS OSS Majordomo List" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) 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 So, first off, there are a number of parameters that must be consistent across the two tables for the configuration to be valid, and the active rows in the UpChannelTable *always* have to be valid. The only possible exception to this would be if the interface were turned down before the changes were made, but I don't think that is an operationally useful scenario to consider, and some (all?) vendors might want to enforce validity even in that case. Any active row in the UpChannelTable will be populated by consistent defaults or stored values when the CMTS is booted, so we only need to consider *changes* to those rows (i.e. they can't be created from scratch and so would never have to be populated one-object-at-a-time). Any change to an active row can be done by two methods: direct change & cloning. When a change is made directly, the validation occurs immediately upon receiving the snmp set. When using the cloning mechanism, the validation only occurs when the ChannelUpdate object is set true. This proposal does not change either of those aspects. It only enforces that UpChannelModulationProfile and UpChannelType are guaranteed to be consistent with each other. The whole point of the cloning mechanism was to have a temporary "scratch" area where an operator could manipulate the values without having the constraint that they are consistent at every step. Thus the consistency verification is only done upon ChannelUpdate. I don't think that the steps Eduardo suggested are valid, setting ModulationProfile to '0' on an active row would seem to make the channel unusable, no? Setting ModulationProfile to '0' on an inactive row wouldn't be necessary since there is no consistency checking. Let me know if I'm completely missing the boat here.... -Greg -----Original Message----- From: Eduardo Cardona=20 Sent: Thursday, October 09, 2003 1:38 PM To: 'Minnie Lu'; David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi David, Minnie,=20 Greg may have other comments. I think the idea was to define one clear way of configuration rather than finding possible broken paths The idea was to pass the role of The UpChannel parameters vs ChannelType verification to one trigger, the docsIfUpChannelModulationProfile so it verifies that all the channelTypes are the same (in the mod profile) All Modulation Parameters are consistent in into their own IUC [ can be done also as user change an IUC itself -invalid value for that particulat CMTS-, etc] Then as the Type is knew from the profile verifies that the ChannelType is compatible with the UpChannel parameters, if fails nothing haven change or undo-commit.=20 The point is that UpChannel to ModulationProfile is one-to-many so going in that path eventually the user won't break the Profile that works for other UpChannels and instead maybe create a one-to-one UpChannel-to-ModulationProfile ( by creating a new Profile) In the current UpChannelChanelType read-create we have, implies UpChannelModProfile and ChannelType might need to be modified simultaneously or: 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelType to 'x' and=20 -verify Chnnl- 4 UpChannelModulationProfile to 'y' -verify Chnnl UpCh/ModProfile-=20 if failed start again from 1 With the proposal at maximum ( channelType RO) would be =20 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelModulationProfile to 'y' - do all verifications chnnl/ModProf- =20 if failed redo 2, maybe adjust ModulationProfileTable and 3) Are there any other updated paths to consider for simplified setup, other sequence?=20 Or maybe be more details in the sequence for the objects ? Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Thursday, October 09, 2003 12:25 PM To: David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, David, Your concern sounds very valid. Then it seems to me that 1. either have docsIfUpChannelType is read-only and ask the=20 docsIfUpChannelModulationProfile must be assigned first before setting=20 other upstream attributes. For this is one, I don't know user would like=20 it or not. 2. or we still need to keep the docsIfUpChannelType is read-create, so it=20 can be used to check other upstream attributes consistence without having=20 an modulation profile assigned. The user must make sure both=20 docsIfUpChannelModulationProfile and docsIfUpChannelType are the same when=20 trying to set either one of them if docsIfUpChannelModulationProfile is not=20 value 0. If they are not consistent, the set will fail. Any more possible solution ? Just some more thoughts. Thanks a lot ! Minnie At 11:35 AM 10/9/2003 -0400, David.White@arrisi.com wrote: >Greg, > The main problem I have with this is that it forces the CMTS >to > postpone data checking until possibly the very end when the modulation > profile is finally assigned. That is, the user may get a wrongValue or > inconsistentValue while attempting to set the modulation profile because=20 > one or more already-set parameters do not agree with the ModChannelType.=20 > What I liked about having the UpChannelType being a configurable and=20 > "active" (rather than passive) object is that the CMTS verify things like=20 > ChannelWidth, SlotSize, and the Scdma parameters as they are being set.=20 > Thus, the error is immediate and pertitent. > >However, what I like about your proposal is that it makes it easier to=20 >transition an upstream channel from tdma, atdma, and tdmaAndAtdma=20 >without having to change both the modulation profile and UpChannelType=20 >at the same time. > >I'm not rejecting your proposal, but just wanted to voice my concerns. > >Thanks, >David > > > >"Greg White" >Sent by: owner-docsis-oss@cablelabs.com > >10/08/2003 07:35 PM > > To: > cc: "DOCSIS OSS Majordomo List"=20 > , , > , > , "Minnie Lu" > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > >David, > >According to the proposed text, docsIfUpChannelType would be read-only >for >ALL rows. > >For "active" rows (docsIfUpChannelStatus =3D active(1)) setting=20 >UpChannelModulationProfile would return an error if the channel type of >the profile does not work with the other parameters in the row. > >For "cloned" rows (docsIfUpChannelStatus =3D notInService(2)) no=20 >verification is done on consistency of parameters until=20 >docsIfUpChannelUpdate is set to true. > >The verification for active rows is indicated in the proposed text for=20 >UpChannelModulationProfile, although it looks like it could be=20 >clarified: > > Setting this object on an "active" row MUST return an > error > if the following > conditions are not satisfied: > 1. All the IUC entries in the selected modulation profile > MUST have the same value of docsIfCmtsModChannelType. > 2. All of the modulation parameters in the selected > modulation profile MUST be consistent with the other > parameters in this docsIfUpChannelEntry. > >Does that address your concern? > >-Greg > >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Wednesday, October 08, 2003 3:11 PM >To: Greg White >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org;=20 >Larry.Spaete@arrisi.com; Minnie Lu >Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Greg, > Per your earlier e-mail on this thread: > >"Also, I would like to propose that we make docsIfUpChannelType a >read-only object for active rows in the Upstream Channel Table. The=20 >value reported would be taken from the modulation profile pointed to by >docsIfUpChannelModulationProfile." > >I'm assuming "active" mean in-service. Otherwise, we have to be careful >with this because the channelType is used to verify things like=20 >channelWidth and whether or not setting of the scdma-specific=20 >parameters is allowed. Along the same lines, if setting the upstream=20 >modulation profile index implies that the SNMP agent changes the=20 >upChannelType to match the modProfChannelType, then the agent must also >verify that all of the other parameters in the upstream channel are=20 >compatible with the possibly new channel type. > >David > > >"Greg White" > >10/08/2003 04:12 PM > To: "Minnie Lu" > cc: , "DOCSIS OSS Majordomo List"=20 > , , =20 >, > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > > >Minnie, > >I didn't want to prevent a user from changing their mind regarding >channel type when creating a new modulation profile. Suppose you=20 >started out setting channel type to atdma and, after completing a few=20 >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make=20 >you start from scratch (or do a simultaneous set across all IUCs), you=20 >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for=20 >assigning modulation profiles to upstream channels) > > >Hi, Greg, > >Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the=20 >modulation profile is not assigned to any upstreams. So the error=20 >could be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of=20 >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements=20 > >to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please > >review >the > >attached proposal and provide comments. > > > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to=20 > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same > >issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path > > of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with > > other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , , > > , > > > "DOCSIS OSS Majordomo List" , "Owner > > DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I > > >think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same > > >ModChannelType. Also, based on the exchange here it seems that=20 > > >there >is > > >some support for the additional restriction that UpChannelType and > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the > > >specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change > > >UpChannelType to match ModChannelType whenever=20 > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be > > >made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about > >the case that some modulation profile is used by some upstream=20 > >channel, and user change the modulation profile channel type ? Does=20 > >it mean that >the > >upstream channel type would be changed automatically, too ? If yes, > >I >am > >afraid that there might be some user who forget the modulation > >profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The > >modulation profile channel type and upstream channel type are in two=20 > >different MIB tables. > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type > >be changed ? Maybe this is a confusing point which needs to be=20 > >clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles > > >to upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the > > >consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation > > >profile entries with the same docsIfCmtsModIndex will have to have=20 > > >the same docsIfCmtsModChannelType. Otherwise, you would not be able > > >to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid, > > >no >? > > >The way to patch it up would be to make all of the IUCs > > >tdmaAndAtdma, correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is > > >correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used > > >with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 > > >and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV=20 > > >5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type > > >29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List" > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects > > > > docsIfCmtsModByteInterleaverBlockSize and=20 > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to > > > > see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for > > > > modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma > > > > for modulation profiles that could not be met with a pair of=20 > > > > tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we > > > > could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line > > > >of thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations. > > > >Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs > > > >1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of=20 > > > >having >the > > > >MIB reporting something that doesn't exactly reflect what is > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the > > > >modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data > > > > for consistency. Furthermore, it would seem possible to compare=20 > > > > the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Oct 9 20:45:26 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 UAA19187 for ; Thu, 9 Oct 2003 20:45:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7lOx-0004fN-4T for ipcdn-archive@odin.ietf.org; Thu, 09 Oct 2003 20:45:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A0j3G1017931 for ipcdn-archive@odin.ietf.org; Thu, 9 Oct 2003 20:45:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7lOv-0004f0-AL; Thu, 09 Oct 2003 20:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7lOo-0004ej-U3 for ipcdn@optimus.ietf.org; Thu, 09 Oct 2003 20:44:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19176 for ; Thu, 9 Oct 2003 20:44:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7lOm-0006yS-00 for ipcdn@ietf.org; Thu, 09 Oct 2003 20:44:52 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A7lOl-0006yA-00 for ipcdn@ietf.org; Thu, 09 Oct 2003 20:44:51 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9A0bI10015639; Thu, 9 Oct 2003 18:37:19 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Oct 2003 18:37:18 -0600 Message-ID: Thread-Topic: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcOOktBv0hn4SqViTae2STkl2UxTNwABYoEwAAWCS7AABY6OcA== From: "Eduardo Cardona" To: "Greg White" , "Minnie Lu" , Cc: "DOCSIS OSS Majordomo List" , , , , "Owner DOCSIS OSS Majordomo List" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) 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 agree that turning off is not desired for in-service if the changes are not incremental or very drastic changes, I did not enforce the "at maximum" word in both cases (actually I only used that in the second example). It might be some cases where the interface or implementations definitely have to be turn off, but will be on maintenance windows, (season changes -?- school calendar, long weekend?, maintenance measurements.) very uncommon or at knowledge of consequences by MSOs. I agree that the primarily intention is minimum service disruption primarily for spectrum management when changes might be incremental in robustness parameters or phy channel parameters.=20 And as Greg said, one shot change if moving channel from profile A to B. and seems to me that changes in profile should be compatible to the current channel PHY and ulterior modification of the channel will be also, the only problem as today is the double location of ChannelType=20 Eduardo -----Original Message----- From: Greg White=20 Sent: Thursday, October 09, 2003 4:31 PM To: Eduardo Cardona; 'Minnie Lu'; 'David.White@arrisi.com' Cc: DOCSIS OSS Majordomo List; 'Greg.Gohman@arrisi.com'; 'ipcdn@ietf.org'; 'Larry.Spaete@arrisi.com'; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) So, first off, there are a number of parameters that must be consistent across the two tables for the configuration to be valid, and the active rows in the UpChannelTable *always* have to be valid. The only possible exception to this would be if the interface were turned down before the changes were made, but I don't think that is an operationally useful scenario to consider, and some (all?) vendors might want to enforce validity even in that case. Any active row in the UpChannelTable will be populated by consistent defaults or stored values when the CMTS is booted, so we only need to consider *changes* to those rows (i.e. they can't be created from scratch and so would never have to be populated one-object-at-a-time). Any change to an active row can be done by two methods: direct change & cloning. When a change is made directly, the validation occurs immediately upon receiving the snmp set. When using the cloning mechanism, the validation only occurs when the ChannelUpdate object is set true. This proposal does not change either of those aspects. It only enforces that UpChannelModulationProfile and UpChannelType are guaranteed to be consistent with each other. The whole point of the cloning mechanism was to have a temporary "scratch" area where an operator could manipulate the values without having the constraint that they are consistent at every step. Thus the consistency verification is only done upon ChannelUpdate. I don't think that the steps Eduardo suggested are valid, setting ModulationProfile to '0' on an active row would seem to make the channel unusable, no? Setting ModulationProfile to '0' on an inactive row wouldn't be necessary since there is no consistency checking. Let me know if I'm completely missing the boat here.... -Greg -----Original Message----- From: Eduardo Cardona=20 Sent: Thursday, October 09, 2003 1:38 PM To: 'Minnie Lu'; David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi David, Minnie,=20 Greg may have other comments. I think the idea was to define one clear way of configuration rather than finding possible broken paths The idea was to pass the role of The UpChannel parameters vs ChannelType verification to one trigger, the docsIfUpChannelModulationProfile so it verifies that all the channelTypes are the same (in the mod profile) All Modulation Parameters are consistent in into their own IUC [ can be done also as user change an IUC itself -invalid value for that particulat CMTS-, etc] Then as the Type is knew from the profile verifies that the ChannelType is compatible with the UpChannel parameters, if fails nothing haven change or undo-commit.=20 The point is that UpChannel to ModulationProfile is one-to-many so going in that path eventually the user won't break the Profile that works for other UpChannels and instead maybe create a one-to-one UpChannel-to-ModulationProfile ( by creating a new Profile) In the current UpChannelChanelType read-create we have, implies UpChannelModProfile and ChannelType might need to be modified simultaneously or: 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelType to 'x' and=20 -verify Chnnl- 4 UpChannelModulationProfile to 'y' -verify Chnnl UpCh/ModProfile-=20 if failed start again from 1 With the proposal at maximum ( channelType RO) would be =20 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelModulationProfile to 'y' - do all verifications chnnl/ModProf- =20 if failed redo 2, maybe adjust ModulationProfileTable and 3) Are there any other updated paths to consider for simplified setup, other sequence?=20 Or maybe be more details in the sequence for the objects ? Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Thursday, October 09, 2003 12:25 PM To: David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, David, Your concern sounds very valid. Then it seems to me that 1. either have docsIfUpChannelType is read-only and ask the=20 docsIfUpChannelModulationProfile must be assigned first before setting=20 other upstream attributes. For this is one, I don't know user would like=20 it or not. 2. or we still need to keep the docsIfUpChannelType is read-create, so it=20 can be used to check other upstream attributes consistence without having=20 an modulation profile assigned. The user must make sure both=20 docsIfUpChannelModulationProfile and docsIfUpChannelType are the same when=20 trying to set either one of them if docsIfUpChannelModulationProfile is not=20 value 0. If they are not consistent, the set will fail. Any more possible solution ? Just some more thoughts. Thanks a lot ! Minnie At 11:35 AM 10/9/2003 -0400, David.White@arrisi.com wrote: >Greg, > The main problem I have with this is that it forces the CMTS=20 >to postpone data checking until possibly the very end when the=20 >modulation profile is finally assigned. That is, the user may get a=20 >wrongValue or inconsistentValue while attempting to set the modulation >profile because one or more already-set parameters do not agree with=20 >the ModChannelType. What I liked about having the UpChannelType being=20 >a configurable and "active" (rather than passive) object is that the=20 >CMTS verify things like ChannelWidth, SlotSize, and the Scdma=20 >parameters as they are being set. Thus, the error is immediate and=20 >pertitent. > >However, what I like about your proposal is that it makes it easier to >transition an upstream channel from tdma, atdma, and tdmaAndAtdma=20 >without having to change both the modulation profile and UpChannelType=20 >at the same time. > >I'm not rejecting your proposal, but just wanted to voice my concerns. > >Thanks, >David > > > >"Greg White" >Sent by: owner-docsis-oss@cablelabs.com > >10/08/2003 07:35 PM > > To: > cc: "DOCSIS OSS Majordomo List"=20 > , ,=20 > , , "Minnie Lu"=20 > > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > >David, > >According to the proposed text, docsIfUpChannelType would be read-only=20 >for ALL rows. > >For "active" rows (docsIfUpChannelStatus =3D active(1)) setting >UpChannelModulationProfile would return an error if the channel type of >the profile does not work with the other parameters in the row. > >For "cloned" rows (docsIfUpChannelStatus =3D notInService(2)) no >verification is done on consistency of parameters until=20 >docsIfUpChannelUpdate is set to true. > >The verification for active rows is indicated in the proposed text for >UpChannelModulationProfile, although it looks like it could be=20 >clarified: > > Setting this object on an "active" row MUST return an=20 > error if the following > conditions are not satisfied: > 1. All the IUC entries in the selected modulation profile > MUST have the same value of docsIfCmtsModChannelType. > 2. All of the modulation parameters in the selected > modulation profile MUST be consistent with the other > parameters in this docsIfUpChannelEntry. > >Does that address your concern? > >-Greg > >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Wednesday, October 08, 2003 3:11 PM >To: Greg White >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; >Larry.Spaete@arrisi.com; Minnie Lu >Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Greg, > Per your earlier e-mail on this thread: > >"Also, I would like to propose that we make docsIfUpChannelType a=20 >read-only object for active rows in the Upstream Channel Table. The=20 >value reported would be taken from the modulation profile pointed to by >docsIfUpChannelModulationProfile." > >I'm assuming "active" mean in-service. Otherwise, we have to be careful >with this because the channelType is used to verify things like=20 >channelWidth and whether or not setting of the scdma-specific=20 >parameters is allowed. Along the same lines, if setting the upstream=20 >modulation profile index implies that the SNMP agent changes the=20 >upChannelType to match the modProfChannelType, then the agent must also >verify that all of the other parameters in the upstream channel are=20 >compatible with the possibly new channel type. > >David > > >"Greg White" > >10/08/2003 04:12 PM > To: "Minnie Lu" > cc: , "DOCSIS OSS Majordomo List"=20 > , , >, > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > > >Minnie, > >I didn't want to prevent a user from changing their mind regarding >channel type when creating a new modulation profile. Suppose you=20 >started out setting channel type to atdma and, after completing a few=20 >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make=20 >you start from scratch (or do a simultaneous set across all IUCs), you=20 >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for=20 >assigning modulation profiles to upstream channels) > > >Hi, Greg, > >Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the=20 >modulation profile is not assigned to any upstreams. So the error=20 >could be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of=20 >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements=20 > >to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please > >review >the > >attached proposal and provide comments. > > > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to=20 > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same > >issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path > > of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with > > other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , , > > , > > > "DOCSIS OSS Majordomo List" , "Owner > > DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I > > >think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same > > >ModChannelType. Also, based on the exchange here it seems that=20 > > >there >is > > >some support for the additional restriction that UpChannelType and > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the > > >specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change > > >UpChannelType to match ModChannelType whenever=20 > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be > > >made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about > >the case that some modulation profile is used by some upstream=20 > >channel, and user change the modulation profile channel type ? Does=20 > >it mean that >the > >upstream channel type would be changed automatically, too ? If yes, > >I >am > >afraid that there might be some user who forget the modulation > >profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The > >modulation profile channel type and upstream channel type are in two=20 > >different MIB tables. > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type > >be changed ? Maybe this is a confusing point which needs to be=20 > >clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles > > >to upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the > > >consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation > > >profile entries with the same docsIfCmtsModIndex will have to have=20 > > >the same docsIfCmtsModChannelType. Otherwise, you would not be able > > >to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid, > > >no >? > > >The way to patch it up would be to make all of the IUCs > > >tdmaAndAtdma, correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is > > >correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used > > >with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 > > >and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV=20 > > >5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type > > >29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List" > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects > > > > docsIfCmtsModByteInterleaverBlockSize and=20 > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to > > > > see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for > > > > modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma > > > > for modulation profiles that could not be met with a pair of=20 > > > > tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we > > > > could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line > > > >of thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations. > > > >Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs > > > >1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of=20 > > > >having >the > > > >MIB reporting something that doesn't exactly reflect what is > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the > > > >modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data > > > > for consistency. Furthermore, it would seem possible to compare=20 > > > > the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Oct 10 10:03:26 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 KAA28527 for ; Fri, 10 Oct 2003 10:03:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7xrC-0004qf-MP for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 10:03:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AE32ll018636 for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 10:03:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7xrA-0004qE-Ub; Fri, 10 Oct 2003 10:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7xqU-0004pf-QH for ipcdn@optimus.ietf.org; Fri, 10 Oct 2003 10:02:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28476 for ; Fri, 10 Oct 2003 10:02:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7xqS-0003qZ-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 10:02:16 -0400 Received: from mail.stargus.com ([65.193.169.166]) by ietf-mx with smtp (Exim 4.12) id 1A7xqR-0003qI-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 10:02:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Oct 2003 09:59:09 -0400 Message-ID: <344C3B42FD36C54A8BC47A471265DEF001A90F@xchange.stargus.com> Thread-Topic: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcON4HQlGjFPumzdSPCnH47/qeYknQAEa5kgAFC7PKA= From: "Dan Rice" To: "Greg White" , "Minnie Lu" Cc: , "DOCSIS OSS Majordomo List" , , , 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 Sorry for chiming in 11th hour, but want to make sure I understand minnie's suggestion for active entries. I believe the suggestion is that for active entries you change the row status to not in service. What would we expect to happen to the upstream currently assigned this modulation profile while it is notInService? Would the existing active assignment continue to be valid for the upstream using it until all IUC rows became active again with the changes in them? Also if the changes are to docsIfCmtsModChannelType wouldn't you have to edit all IUC rows before checking to see if this is valid? I guess when you started going in and making each IUC active that would be the point to check it? Could you guarantee that all IUCs are committed at the same time since they would "immediately" be committed to the active upstream channel entries with pointers to the docsIfCmtsModIndex? Thanks for the clarifications. - Dan -----Original Message----- From: Greg White [mailto:g.white@CableLabs.com]=20 Sent: Wednesday, October 08, 2003 7:20 PM To: Minnie Lu Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) That sounds like a workable alternative. If no one disagrees, I will make that change to the proposal. -Greg -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Wednesday, October 08, 2003 3:09 PM To: Greg White Cc: Minnie Lu; David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, Greg, Then how about enforce this rule for "active" entries ? So in the case you=20 mentioned, user can change the row status to notInService first or at the=20 same time changing the channel type. When user changed all the entries' channel type to be the same, use can put the entries in active again. I personally think it affects a lot when the channel type is changed, so a little more steps should be ok. To me, if there is an error, better catch=20 it as earlier as possible. "All the active entries in a modulation profile (i.e. all active entries that share a common docsIfCmtsModIndex) MUST have the same value of docsIfCmtsModChannelType." Thanks a lot ! Minnie At 02:12 PM 10/8/2003 -0600, Greg White wrote: >Minnie, > >I didn't want to prevent a user from changing their mind regarding >channel type when creating a new modulation profile. Suppose you >started out setting channel type to atdma and, after completing a few >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make >you start from scratch (or do a simultaneous set across all IUCs), you >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Hi, Greg, > > Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the >modulation profile is not assigned to any upstreams. So the error could >be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please review >the > >attached proposal and provide comments. > > > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , , , > > > "DOCSIS OSS Majordomo List" , "Owner DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same > > >ModChannelType. Also, based on the exchange here it seems that there >is > > >some support for the additional restriction that UpChannelType and > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change > > >UpChannelType to match ModChannelType whenever > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about the > >case that some modulation profile is used by some upstream channel, and > >user change the modulation profile channel type ? Does it mean that >the > >upstream channel type would be changed automatically, too ? If yes, I >am > >afraid that there might be some user who forget the modulation profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The > >modulation profile channel type and upstream channel type are in two > >different MIB tables. > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type be > >changed ? Maybe this is a confusing point which needs to be clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > > >upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation profile > > >entries with the same docsIfCmtsModIndex will have to have the same > > >docsIfCmtsModChannelType. Otherwise, you would not be able to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid, no >? > > >The way to patch it up would be to make all of the IUCs tdmaAndAtdma, > > >correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List" > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects > > > > docsIfCmtsModByteInterleaverBlockSize and > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma for > > > > modulation profiles that could not be met with a pair of tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line of > > > >thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations. Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of having >the > > > >MIB reporting something that doesn't exactly reflect what is > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the > > > > modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data for > > > > consistency. Furthermore, it would seem possible to compare the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > _______________________________________________ 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 Fri Oct 10 10:21:27 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 KAA00043 for ; Fri, 10 Oct 2003 10:21:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7y8e-0005yC-JE for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 10:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AEL4TF022948 for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 10:21:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7y8c-0005xp-Ag; Fri, 10 Oct 2003 10:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7y7z-0005xJ-ET for ipcdn@optimus.ietf.org; Fri, 10 Oct 2003 10:20:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00009 for ; Fri, 10 Oct 2003 10:20:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7y7x-00040a-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 10:20:21 -0400 Received: from mail.stargus.com ([65.193.169.166]) by ietf-mx with smtp (Exim 4.12) id 1A7y7v-00040N-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 10:20:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Oct 2003 10:17:14 -0400 Message-ID: <344C3B42FD36C54A8BC47A471265DEF001A910@xchange.stargus.com> Thread-Topic: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcOOktBv0hn4SqViTae2STkl2UxTNwABYoEwAAWCS7AABY6OcAAcphSw From: "Dan Rice" To: "Eduardo Cardona" , "Greg White" , "Minnie Lu" , Cc: "DOCSIS OSS Majordomo List" , , , , "Owner DOCSIS OSS Majordomo List" 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 For my $0.02 I would prefer just having the clone mechanism. Even within the upstream channel parameters you must change things in the right order for them to be correct if you do it while row is active. This is not just an UpChannelType issue. For example setting a minislot size before changing the symbol rate can result in some situations that CMTSs today will reject. If you reduce the minislot size before increasing symbol rate, you could no longer send a max packet. I think if we made the clone method mandatory for both TDMA and SCDMA and changed the descriptions to be this way than I would be happy because there is now a deterministic way to make changes and commit them. Today in most deployed CMTSs its hard to know how many UCD changes occur when you make changes to upstream channel today. It seems to depend on vendor. When all you are really shooting for is an end result this seems the safest and most deterministic route to me. =20 I think that many of the cases of making changes to active modulation profiles and upstream channel settings can make things a little funny if the commit isn't very defined. If there are requirements for support of enough modulation table entries and enough clone rows to accommodate an active and notInService for each upstream interface this could be a lot cleaner. Any change that is made is done by creating a new complete modulation profile (even if its just changing one value, I imagine most of this will done through software as opposed to hand editing) then creating a clone upstream channel table entry with pointer to this new mod profile and associated upstream channel settings, then commit the changes. Additionally it would be nice to have the same functionality in the downstream channel table to be consistent. For example it would be nice to commit modulation and interleave settings at the same time. -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com]=20 Sent: Thursday, October 09, 2003 8:37 PM To: Greg White; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) I agree that turning off is not desired for in-service if the changes are not incremental or very drastic changes, I did not enforce the "at maximum" word in both cases (actually I only used that in the second example). It might be some cases where the interface or implementations definitely have to be turn off, but will be on maintenance windows, (season changes -?- school calendar, long weekend?, maintenance measurements.) very uncommon or at knowledge of consequences by MSOs. I agree that the primarily intention is minimum service disruption primarily for spectrum management when changes might be incremental in robustness parameters or phy channel parameters.=20 And as Greg said, one shot change if moving channel from profile A to B. and seems to me that changes in profile should be compatible to the current channel PHY and ulterior modification of the channel will be also, the only problem as today is the double location of ChannelType=20 Eduardo -----Original Message----- From: Greg White=20 Sent: Thursday, October 09, 2003 4:31 PM To: Eduardo Cardona; 'Minnie Lu'; 'David.White@arrisi.com' Cc: DOCSIS OSS Majordomo List; 'Greg.Gohman@arrisi.com'; 'ipcdn@ietf.org'; 'Larry.Spaete@arrisi.com'; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) So, first off, there are a number of parameters that must be consistent across the two tables for the configuration to be valid, and the active rows in the UpChannelTable *always* have to be valid. The only possible exception to this would be if the interface were turned down before the changes were made, but I don't think that is an operationally useful scenario to consider, and some (all?) vendors might want to enforce validity even in that case. Any active row in the UpChannelTable will be populated by consistent defaults or stored values when the CMTS is booted, so we only need to consider *changes* to those rows (i.e. they can't be created from scratch and so would never have to be populated one-object-at-a-time). Any change to an active row can be done by two methods: direct change & cloning. When a change is made directly, the validation occurs immediately upon receiving the snmp set. When using the cloning mechanism, the validation only occurs when the ChannelUpdate object is set true. This proposal does not change either of those aspects. It only enforces that UpChannelModulationProfile and UpChannelType are guaranteed to be consistent with each other. The whole point of the cloning mechanism was to have a temporary "scratch" area where an operator could manipulate the values without having the constraint that they are consistent at every step. Thus the consistency verification is only done upon ChannelUpdate. I don't think that the steps Eduardo suggested are valid, setting ModulationProfile to '0' on an active row would seem to make the channel unusable, no? Setting ModulationProfile to '0' on an inactive row wouldn't be necessary since there is no consistency checking. Let me know if I'm completely missing the boat here.... -Greg -----Original Message----- From: Eduardo Cardona=20 Sent: Thursday, October 09, 2003 1:38 PM To: 'Minnie Lu'; David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi David, Minnie,=20 Greg may have other comments. I think the idea was to define one clear way of configuration rather than finding possible broken paths The idea was to pass the role of The UpChannel parameters vs ChannelType verification to one trigger, the docsIfUpChannelModulationProfile so it verifies that all the channelTypes are the same (in the mod profile) All Modulation Parameters are consistent in into their own IUC [ can be done also as user change an IUC itself -invalid value for that particulat CMTS-, etc] Then as the Type is knew from the profile verifies that the ChannelType is compatible with the UpChannel parameters, if fails nothing haven change or undo-commit.=20 The point is that UpChannel to ModulationProfile is one-to-many so going in that path eventually the user won't break the Profile that works for other UpChannels and instead maybe create a one-to-one UpChannel-to-ModulationProfile ( by creating a new Profile) In the current UpChannelChanelType read-create we have, implies UpChannelModProfile and ChannelType might need to be modified simultaneously or: 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelType to 'x' and=20 -verify Chnnl- 4 UpChannelModulationProfile to 'y' -verify Chnnl UpCh/ModProfile-=20 if failed start again from 1 With the proposal at maximum ( channelType RO) would be =20 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelModulationProfile to 'y' - do all verifications chnnl/ModProf- =20 if failed redo 2, maybe adjust ModulationProfileTable and 3) Are there any other updated paths to consider for simplified setup, other sequence?=20 Or maybe be more details in the sequence for the objects ? Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Thursday, October 09, 2003 12:25 PM To: David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, David, Your concern sounds very valid. Then it seems to me that 1. either have docsIfUpChannelType is read-only and ask the=20 docsIfUpChannelModulationProfile must be assigned first before setting=20 other upstream attributes. For this is one, I don't know user would like=20 it or not. 2. or we still need to keep the docsIfUpChannelType is read-create, so it=20 can be used to check other upstream attributes consistence without having=20 an modulation profile assigned. The user must make sure both=20 docsIfUpChannelModulationProfile and docsIfUpChannelType are the same when=20 trying to set either one of them if docsIfUpChannelModulationProfile is not=20 value 0. If they are not consistent, the set will fail. Any more possible solution ? Just some more thoughts. Thanks a lot ! Minnie At 11:35 AM 10/9/2003 -0400, David.White@arrisi.com wrote: >Greg, > The main problem I have with this is that it forces the CMTS=20 >to postpone data checking until possibly the very end when the=20 >modulation profile is finally assigned. That is, the user may get a=20 >wrongValue or inconsistentValue while attempting to set the modulation >profile because one or more already-set parameters do not agree with=20 >the ModChannelType. What I liked about having the UpChannelType being=20 >a configurable and "active" (rather than passive) object is that the=20 >CMTS verify things like ChannelWidth, SlotSize, and the Scdma=20 >parameters as they are being set. Thus, the error is immediate and=20 >pertitent. > >However, what I like about your proposal is that it makes it easier to >transition an upstream channel from tdma, atdma, and tdmaAndAtdma=20 >without having to change both the modulation profile and UpChannelType=20 >at the same time. > >I'm not rejecting your proposal, but just wanted to voice my concerns. > >Thanks, >David > > > >"Greg White" >Sent by: owner-docsis-oss@cablelabs.com > >10/08/2003 07:35 PM > > To: > cc: "DOCSIS OSS Majordomo List"=20 > , ,=20 > , , "Minnie Lu"=20 > > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > >David, > >According to the proposed text, docsIfUpChannelType would be read-only=20 >for ALL rows. > >For "active" rows (docsIfUpChannelStatus =3D active(1)) setting >UpChannelModulationProfile would return an error if the channel type of >the profile does not work with the other parameters in the row. > >For "cloned" rows (docsIfUpChannelStatus =3D notInService(2)) no >verification is done on consistency of parameters until=20 >docsIfUpChannelUpdate is set to true. > >The verification for active rows is indicated in the proposed text for >UpChannelModulationProfile, although it looks like it could be=20 >clarified: > > Setting this object on an "active" row MUST return an=20 > error if the following > conditions are not satisfied: > 1. All the IUC entries in the selected modulation profile > MUST have the same value of docsIfCmtsModChannelType. > 2. All of the modulation parameters in the selected > modulation profile MUST be consistent with the other > parameters in this docsIfUpChannelEntry. > >Does that address your concern? > >-Greg > >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Wednesday, October 08, 2003 3:11 PM >To: Greg White >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; >Larry.Spaete@arrisi.com; Minnie Lu >Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Greg, > Per your earlier e-mail on this thread: > >"Also, I would like to propose that we make docsIfUpChannelType a=20 >read-only object for active rows in the Upstream Channel Table. The=20 >value reported would be taken from the modulation profile pointed to by >docsIfUpChannelModulationProfile." > >I'm assuming "active" mean in-service. Otherwise, we have to be careful >with this because the channelType is used to verify things like=20 >channelWidth and whether or not setting of the scdma-specific=20 >parameters is allowed. Along the same lines, if setting the upstream=20 >modulation profile index implies that the SNMP agent changes the=20 >upChannelType to match the modProfChannelType, then the agent must also >verify that all of the other parameters in the upstream channel are=20 >compatible with the possibly new channel type. > >David > > >"Greg White" > >10/08/2003 04:12 PM > To: "Minnie Lu" > cc: , "DOCSIS OSS Majordomo List"=20 > , , >, > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > > >Minnie, > >I didn't want to prevent a user from changing their mind regarding >channel type when creating a new modulation profile. Suppose you=20 >started out setting channel type to atdma and, after completing a few=20 >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make=20 >you start from scratch (or do a simultaneous set across all IUCs), you=20 >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for=20 >assigning modulation profiles to upstream channels) > > >Hi, Greg, > >Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the=20 >modulation profile is not assigned to any upstreams. So the error=20 >could be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of=20 >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements=20 > >to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please > >review >the > >attached proposal and provide comments. > > > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to=20 > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same > >issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path > > of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with > > other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , , > > , > > > "DOCSIS OSS Majordomo List" , "Owner > > DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I > > >think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same > > >ModChannelType. Also, based on the exchange here it seems that=20 > > >there >is > > >some support for the additional restriction that UpChannelType and > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the > > >specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change > > >UpChannelType to match ModChannelType whenever=20 > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be > > >made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about > >the case that some modulation profile is used by some upstream=20 > >channel, and user change the modulation profile channel type ? Does=20 > >it mean that >the > >upstream channel type would be changed automatically, too ? If yes, > >I >am > >afraid that there might be some user who forget the modulation > >profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The > >modulation profile channel type and upstream channel type are in two=20 > >different MIB tables. > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type > >be changed ? Maybe this is a confusing point which needs to be=20 > >clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles > > >to upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the > > >consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation > > >profile entries with the same docsIfCmtsModIndex will have to have=20 > > >the same docsIfCmtsModChannelType. Otherwise, you would not be able > > >to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid, > > >no >? > > >The way to patch it up would be to make all of the IUCs > > >tdmaAndAtdma, correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is > > >correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used > > >with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 > > >and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV=20 > > >5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type > > >29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List" > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects > > > > docsIfCmtsModByteInterleaverBlockSize and=20 > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to > > > > see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for > > > > modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma > > > > for modulation profiles that could not be met with a pair of=20 > > > > tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we > > > > could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line > > > >of thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations. > > > >Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs > > > >1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of=20 > > > >having >the > > > >MIB reporting something that doesn't exactly reflect what is > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the > > > >modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data > > > > for consistency. Furthermore, it would seem possible to compare=20 > > > > the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > > > > _______________________________________________ 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 Fri Oct 10 10:43:28 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 KAA01144 for ; Fri, 10 Oct 2003 10:43:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yTt-0007bs-1K for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 10:43:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AEh01v029246 for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 10:43:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yTs-0007bY-Ne; Fri, 10 Oct 2003 10:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yTH-0007aN-S7 for ipcdn@optimus.ietf.org; Fri, 10 Oct 2003 10:42:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01090 for ; Fri, 10 Oct 2003 10:42:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yTF-0004Ht-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 10:42:21 -0400 Received: from mail.stargus.com ([65.193.169.166]) by ietf-mx with smtp (Exim 4.12) id 1A7yTE-0004HQ-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 10:42:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [ipcdn] Status of IPCDN RF MIBv2 and 3 open issues MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38F3C.427C909F" Date: Fri, 10 Oct 2003 10:39:07 -0400 Message-ID: <344C3B42FD36C54A8BC47A471265DEF001A912@xchange.stargus.com> Thread-Topic: [ipcdn] Status of IPCDN RF MIBv2 and 3 open issues Thread-Index: AcNgJaYn06TBEeT1TRC5N0Q/BVl7hgT3JTZQBRgJoxAABa9pIAGKF0mAACappiA= From: "Dan Rice" To: "Eduardo Cardona" , "Jean-Francois Mule" , "Ipcdn (E-mail)" Cc: "Richard Woundy" , "Bert Wijnen" , "Raftus, David" 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_01C38F3C.427C909F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am sorry I could never find the ECR or MIB text for Issue number 6. Sorry if I missed it, could someone post it again? - Dan =20 -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com]=20 Sent: Thursday, October 09, 2003 4:15 PM To: Jean-Francois Mule; Ipcdn (E-mail) Cc: Richard Woundy; Bert Wijnen; Raftus, David Subject: RE: [ipcdn] Status of IPCDN RF MIBv2 and 3 open issues =20 Hi all,=20 =20 Just a reminder if you have comments for the open issues, listed this week, please do so. so far only the New added comment #23 for ChannelType has being discussed. =20 Thanks =20 Eduardo =20 -----Original Message----- From: Jean-Francois Mule=20 Sent: Wednesday, October 01, 2003 6:11 PM To: Ipcdn (E-mail) Cc: Eduardo Cardona; Jean-Francois Mule; Richard Woundy; Bert Wijnen; Raftus, David Subject: [ipcdn] Status of IPCDN RF MIBv2 and 3 open issues This note provides a status on the DOCSIS 2.0 RF MIB (aka rfmibv2). In summary, 3 issues are still OPEN and the wg chairs would like to have working group consensus by Friday October 10 on issues: #13, #14, #16. Eduardo Cardona of CableLabs has kindly accepted to help resolve=20 those and will be posting some text soon. Please read this carefully and raise any concerns or objections to the wg chairs on this action plan by Friday Oct 10. -- Rich Woundy and Jean-Francois Mule', ipcdn co-chairs. --- Status of RF MIBv2 Internet-Draft Name: DOCSIS 2.0 RF MIB draft-ietf-ipcdn-docs-rfmibv2-06.txt =20 ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-06.txt soon to be draft-ietf-ipcdn-docs-rfmibv2-07.txt 1) Follow-up on the IETF posting of rfmibv2-07 The editor, David Raftus sent draft-07 to the internet-draft on 9/9. The revision has not shown up yet. This is probably due to the fact that a zip file was attached instead of the plain text file. Action Item (AI): wg chair to follow up on posting. 2) Categorization of the remaining open issues David Raftus sent a list of open issues to the ipcdn list on 9/12/03, see attached file rfdraftv7_issues_Sept12_2003.txt The remaining open issues not addressed in draft-07 split into 2 categories: - a) issue is not required to be addressed ("nice to have") This category includes some of the improvements that were not in the original scope of rfmibv2. A lot of improvements has been done and it is time to freeze rfmibv2. - b) issue that should be addressed in draft v8 ("must fix") This category includes some issues that need to be addressed. 5 open issues are in this category. =3D> Please raise any objection on the ipcdn list by COB Friday 9/10/03 if you believe this is not reflecting the correct status of the draft or if you believe more open issues must be fixed. 3) Open issues: The numbering is based on David Raftus status file sent on 9/12/2003 on the ipcdn list and attached to this posting. + Issue #7: Status: Closed (will be in draft08) (7) docsIfUpChannelPreEqEnable - add DEFVAL clause. Contributor - John Gillis ADC David indicated that a defval is not required ("DEFVAL not appropriate here, also too many other items in same table do not have DEFVAL"). # category: "must fix" # Eduardo recommends to add a default value of false for this object. # Action Item: add DEFVAL false in draft 08 + Issue #13 Status: Open (13) Adjust compliance statements for objects designated optional. Add separate augmentation table for optional objects in docsIfCmtsUpChannelCounterTable. Contributors - Will Murwin Motorola, Rich Woundy IPCDN/Comcast, Mike StJohns Mindspring, Eduardo Cardona Cablelabs # category: "must fix" # Action Item: Eduardo to summarize the discussion & a recommendation # for the augmentation. Consensus must be reached by 10/10 or else WG # chair will make a decision. + Issue #14 Status: Open (14) Add section explaining counter interaction between Docsis 1.0/1.1/2.0. David indicated that this could be done in OSS spec but since rfmib v2 obsoletes an exising IETF MIB, the wg chairs recommendation is to include a section in the new MIB. # category: "must fix" # Action Item: Eduardo to propose some text. + Issue #15 Status: Closed, pending ipcdn review (15) Change docsIfCmtsServiceTable to count packets for both upstream and downstream flows. David Raftus commented: "Will not do - inappropriate - table indexed by SID, SIDs are not defined for downstream flows". WG chairs agree with David Raftus. # category: "nice to have", For further study. # Action item: none, issue is closed. + Issue #16 Status: Open (16) Add 4 objects to docsIfCmtsCmStatusTable See David Raftus' status on this open issue and associated emails. # category: "nice to have" # Action item: Eduardo to close on this issue on the ipcdn mailing # list. If no consensus can be reached by Oct 10, wg chair will make a # decision to leave it out of rf mib v2. + Issue #20 Status: Closed (will be in draft08) (20) Update snmpv3 references to latest mib versions # category: "must fix" # Action item: edit draft 08 and include proper refs in the document + Issue #22 Status: Closed (pending ipcdn review) (22) Addition of object to report received power level per channel at CMTS # category: "nice to have" -> out of scope # Recommendation is that this issue will not be addressed in any # future revision of RF MIB v2. # Action item: none, issue is closed.=20 ------_=_NextPart_001_01C38F3C.427C909F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

I am sorry I could never find the = ECR or MIB text for Issue number 6.  = Sorry if I missed it, could someone post it again? - = Dan

 

-----Original = Message-----
From: Eduardo Cardona [mailto:e.cardona@CableLabs.com]
Sent: Thursday, October = 09, 2003 4:15 PM
To: Jean-Francois Mule; = Ipcdn (E-mail)
Cc: Richard Woundy; Bert = Wijnen; Raftus, David
Subject: RE: [ipcdn] = Status of IPCDN RF MIBv2 and 3 open issues

 

Hi all, =

 

Just a reminder = if you have comments for the open issues, listed this week, please do so. = so far only the New added comment #23 for ChannelType has being = discussed.

 

Thanks

 

Eduardo

 

-----Original Message-----
From: Jean-Francois Mule =
Sent: Wednesday, October = 01, 2003 6:11 PM
To: Ipcdn (E-mail)
Cc: Eduardo Cardona; = Jean-Francois Mule; Richard Woundy; Bert Wijnen; Raftus, David
Subject: [ipcdn] Status = of IPCDN RF MIBv2 and 3 open issues

This note provides a status on the DOCSIS 2.0 RF MIB (aka rfmibv2).

In summary, 3 issues are still OPEN and the wg chairs would like to
have working group consensus by Friday October 10 on issues: #13, = #14,
 #16. Eduardo Cardona of CableLabs has kindly accepted to help = resolve
those and will be posting some text soon.

Please read this carefully and raise any concerns or objections to the
wg chairs on this action plan by Friday Oct 10.

 -- Rich Woundy and Jean-Francois Mule', ipcdn co-chairs.

--- Status of RF MIBv2
Internet-Draft Name: DOCSIS 2.0 RF MIB
            &= nbsp;        draft-ietf-ipcdn-docs-rfmibv2-06.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-06= .txt
soon to be
draft-ietf-ipcdn-docs-rfmibv2-07.txt


1) Follow-up on the IETF posting of = rfmibv2-07
   The editor, David Raftus sent draft-07 to the internet-draft on
   9/9. The revision has not shown up yet. This is probably = due to the
   fact that a zip file was attached instead of the plain text = file.
   Action Item (AI): wg chair to follow up on posting.


2) Categorization of the remaining open = issues
David Raftus sent a list of open issues to the ipcdn list on 9/12/03,
see attached file rfdraftv7_issues_Sept12_2003.txt
The remaining open issues not addressed in draft-07 split into 2
categories:
- a) issue is = not required to be addressed ("nice to = have")
  This category includes some of the improvements that were not in the
  original scope of rfmibv2. A lot of improvements has been done = and
  it is time to freeze rfmibv2.
- b) issue that = should be addressed in draft v8 ("must = fix")
  This category includes some issues that need to be addressed.
  5 open issues are in this category.
=3D> Please raise any objection on the ipcdn list by COB Friday = 9/10/03
if you believe this is not reflecting the correct status of the = draft
or if you believe more open issues must be fixed.


3) Open issues:
The numbering is based on David Raftus status file sent on 9/12/2003
on the ipcdn list and attached to this posting.

+ Issue = #7:
Status: Closed (will be in draft08)
(7) docsIfUpChannelPreEqEnable - add DEFVAL clause.
    Contributor - John Gillis ADC
David indicated that a defval is not required ("DEFVAL not = appropriate
here, also too many other items in same table do not have = DEFVAL").
# category: "must = fix"
# Eduardo recommends to add a = default value of false for this object.
# Action Item: add DEFVAL false in = draft 08

+ Issue #13
Status: Open
(13) Adjust compliance statements for objects designated optional. = Add
     separate augmentation table for optional = objects in
     docsIfCmtsUpChannelCounterTable.
     Contributors - Will Murwin Motorola, Rich = Woundy IPCDN/Comcast,
     Mike StJohns Mindspring, Eduardo Cardona = Cablelabs
# category: "must = fix"
# Action Item: Eduardo to = summarize the discussion & a recommendation
# for the augmentation. Consensus = must be reached by 10/10 or else WG
# chair will make a = decision.

+ Issue #14
Status: Open
(14) Add section explaining counter interaction between
     Docsis 1.0/1.1/2.0.
David indicated that this could be done in OSS spec but since rfmib = v2
obsoletes an exising IETF MIB, the wg chairs recommendation is to
include a section in the new MIB.
# category: "must = fix"
# Action Item: Eduardo to propose = some text.

+ Issue #15
Status: Closed, pending ipcdn review
(15) Change docsIfCmtsServiceTable to count packets for both = upstream
     and downstream flows.
David Raftus commented: "Will not do - inappropriate - table = indexed
by SID, SIDs are not defined for downstream flows".
WG chairs agree with David Raftus.
# category: "nice to = have", For further study.
# Action item: none, issue is = closed.

+ Issue #16
Status: Open
(16) Add 4 objects to docsIfCmtsCmStatusTable
See David Raftus' status on this open issue and associated emails.
# category: "nice to = have"
# Action item: Eduardo to close on = this issue on the ipcdn mailing
# list. If no consensus can be = reached by Oct 10, wg chair will make a
# decision to leave it out of rf = mib v2.

+ Issue #20
Status: Closed (will be in draft08)
(20) Update snmpv3 references to latest mib versions
# category: "must = fix"
# Action item: edit draft 08 and = include proper refs in the document

+ Issue #22
Status: Closed (pending ipcdn review)
(22) Addition of object to report received power level per channel at = CMTS
# category: "nice to = have" -> out of scope
# Recommendation is that this = issue will not be addressed in any
# future revision of RF MIB = v2.
# Action item: none, issue is = closed.

------_=_NextPart_001_01C38F3C.427C909F-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Oct 10 11:36:26 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 LAA03795 for ; Fri, 10 Oct 2003 11:36:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zJE-0002ox-1e for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 11:36:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AFa4Ex010840 for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 11:36:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zJC-0002oX-Po; Fri, 10 Oct 2003 11:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zJ4-0002o1-1Z for ipcdn@optimus.ietf.org; Fri, 10 Oct 2003 11:35:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03769 for ; Fri, 10 Oct 2003 11:35:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zJ2-0005Ax-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 11:35:52 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A7zJ1-0005AT-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 11:35:51 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9AFXO10016004; Fri, 10 Oct 2003 09:33:24 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Date: Fri, 10 Oct 2003 09:33:24 -0600 Message-ID: Thread-Topic: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcOOktBv0hn4SqViTae2STkl2UxTNwABYoEwAAWCS7AABY6OcAAcphSwAADDo1A= From: "Eduardo Cardona" To: "Dan Rice @ Stargus" , "Greg White" , "Minnie Lu" , Cc: "DOCSIS OSS Majordomo List" , , , , "Owner DOCSIS OSS Majordomo List" 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 Dan,=20 That's a very good point, Currently is up to de Vendor for non-SCDMA, I think we did not finish the discussion about that last time. Also, The "active" (a mix with RowStatus 'active' but not necessarily linked to ifAdmin/OperStatus) was initially though to be the entries associated to real physical US ports. The row Status was intended for Clonning process,=20 as we know RFC 2670 did not have RowStatus; and for "active", now RowStatus may have ramifications with RowStatus values not really defined, like 'notReady' and the connotations of ifAdminStatus, ifOperStatus that are the currently used,=20 To avoid that, I would think that RowStatus object is not instantiated for "real" mapped entries by ifIndex. Leaving ifAdminStatus the complete activation/de-activation of entries. Or 'always' report 'active' regardless of the IfOperStatus, Would be good to clear that. The clonning entry, will be the simulation bench to tuning the values, Will explode the Whole range of RowStatus 'notReady' After creation will indicates the US Channel/Mod profile setup is not right. 'notInService' all parameters are consistent and can be turn via Update object to the cloned interface. =20 Also one thing that could be sticky=20 "CloneFrom" object is the pointer to later transfer the values. Alas "CopyTo" I may be wrong but just by name references when CloneFrom is set, (as a clonning process) will copy values of pointed entry to created entry,=20 Currently CloneFrom object does not say that. But I believe it does not limit implementers to think on that, Just to make sure the object does always the same think A) Clonning process semantics=20 - after createAndWait the first object to set is CloneFrom (copy parameters into clonning entry) - It Might be clarified in the object - - Adjust objects values - Set update object to 'true' will success if: =20 before set, RowStatus was 'notInService',=20 and no other error condition is raised by CMTS for the set=20 B) Copy Process (CopyTo) - After createAndWait set arbitrary objects , setting object CloneFrom does NOT transfer=20 parameters from pointed entry to created entry - Set update object to 'true' will success if: =20 before set, RowStatus was 'notInService',=20 and no other error condition is raised by CMTS for the set Being specific will clear a little bit the process in the user/system thinking doing B) - CMTS does A) - and loosing previous sets if object "CloneFrom" is set after some others.=20 A) is User friendly ( few Sets) B) is autonomous system efficient, -algorithms always calculates all 'optimal' parameters, so might not need to initialize previous setups but should be aware of setting first=20 For the object Name ( something we might not want to change at this state) I believe A) is the precisely even though I would prefer 1 but the correct name should be "CopyTo" Summary of possible edits: No RowStatus for 'real' ifIndex associated entries Explicitly say cloneFrom update values in created entry from pointed entry Let me know any comments Eduardo -----Original Message----- From: Dan Rice @ Stargus=20 Sent: Friday, October 10, 2003 8:17 AM To: Eduardo Cardona; Greg White; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) For my $0.02 I would prefer just having the clone mechanism. Even within the upstream channel parameters you must change things in the right order for them to be correct if you do it while row is active. This is not just an UpChannelType issue. For example setting a minislot size before changing the symbol rate can result in some situations that CMTSs today will reject. If you reduce the minislot size before increasing symbol rate, you could no longer send a max packet. I think if we made the clone method mandatory for both TDMA and SCDMA and changed the descriptions to be this way than I would be happy because there is now a deterministic way to make changes and commit them. Today in most deployed CMTSs its hard to know how many UCD changes occur when you make changes to upstream channel today. It seems to depend on vendor. When all you are really shooting for is an end result this seems the safest and most deterministic route to me. =20 I think that many of the cases of making changes to active modulation profiles and upstream channel settings can make things a little funny if the commit isn't very defined. If there are requirements for support of enough modulation table entries and enough clone rows to accommodate an active and notInService for each upstream interface this could be a lot cleaner. Any change that is made is done by creating a new complete modulation profile (even if its just changing one value, I imagine most of this will done through software as opposed to hand editing) then creating a clone upstream channel table entry with pointer to this new mod profile and associated upstream channel settings, then commit the changes. Additionally it would be nice to have the same functionality in the downstream channel table to be consistent. For example it would be nice to commit modulation and interleave settings at the same time. -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com]=20 Sent: Thursday, October 09, 2003 8:37 PM To: Greg White; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) I agree that turning off is not desired for in-service if the changes are not incremental or very drastic changes, I did not enforce the "at maximum" word in both cases (actually I only used that in the second example). It might be some cases where the interface or implementations definitely have to be turn off, but will be on maintenance windows, (season changes -?- school calendar, long weekend?, maintenance measurements.) very uncommon or at knowledge of consequences by MSOs. I agree that the primarily intention is minimum service disruption primarily for spectrum management when changes might be incremental in robustness parameters or phy channel parameters.=20 And as Greg said, one shot change if moving channel from profile A to B. and seems to me that changes in profile should be compatible to the current channel PHY and ulterior modification of the channel will be also, the only problem as today is the double location of ChannelType=20 Eduardo -----Original Message----- From: Greg White=20 Sent: Thursday, October 09, 2003 4:31 PM To: Eduardo Cardona; 'Minnie Lu'; 'David.White@arrisi.com' Cc: DOCSIS OSS Majordomo List; 'Greg.Gohman@arrisi.com'; 'ipcdn@ietf.org'; 'Larry.Spaete@arrisi.com'; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) So, first off, there are a number of parameters that must be consistent across the two tables for the configuration to be valid, and the active rows in the UpChannelTable *always* have to be valid. The only possible exception to this would be if the interface were turned down before the changes were made, but I don't think that is an operationally useful scenario to consider, and some (all?) vendors might want to enforce validity even in that case. Any active row in the UpChannelTable will be populated by consistent defaults or stored values when the CMTS is booted, so we only need to consider *changes* to those rows (i.e. they can't be created from scratch and so would never have to be populated one-object-at-a-time). Any change to an active row can be done by two methods: direct change & cloning. When a change is made directly, the validation occurs immediately upon receiving the snmp set. When using the cloning mechanism, the validation only occurs when the ChannelUpdate object is set true. This proposal does not change either of those aspects. It only enforces that UpChannelModulationProfile and UpChannelType are guaranteed to be consistent with each other. The whole point of the cloning mechanism was to have a temporary "scratch" area where an operator could manipulate the values without having the constraint that they are consistent at every step. Thus the consistency verification is only done upon ChannelUpdate. I don't think that the steps Eduardo suggested are valid, setting ModulationProfile to '0' on an active row would seem to make the channel unusable, no? Setting ModulationProfile to '0' on an inactive row wouldn't be necessary since there is no consistency checking. Let me know if I'm completely missing the boat here.... -Greg -----Original Message----- From: Eduardo Cardona=20 Sent: Thursday, October 09, 2003 1:38 PM To: 'Minnie Lu'; David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi David, Minnie,=20 Greg may have other comments. I think the idea was to define one clear way of configuration rather than finding possible broken paths The idea was to pass the role of The UpChannel parameters vs ChannelType verification to one trigger, the docsIfUpChannelModulationProfile so it verifies that all the channelTypes are the same (in the mod profile) All Modulation Parameters are consistent in into their own IUC [ can be done also as user change an IUC itself -invalid value for that particulat CMTS-, etc] Then as the Type is knew from the profile verifies that the ChannelType is compatible with the UpChannel parameters, if fails nothing haven change or undo-commit.=20 The point is that UpChannel to ModulationProfile is one-to-many so going in that path eventually the user won't break the Profile that works for other UpChannels and instead maybe create a one-to-one UpChannel-to-ModulationProfile ( by creating a new Profile) In the current UpChannelChanelType read-create we have, implies UpChannelModProfile and ChannelType might need to be modified simultaneously or: 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelType to 'x' and=20 -verify Chnnl- 4 UpChannelModulationProfile to 'y' -verify Chnnl UpCh/ModProfile-=20 if failed start again from 1 With the proposal at maximum ( channelType RO) would be =20 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelModulationProfile to 'y' - do all verifications chnnl/ModProf- =20 if failed redo 2, maybe adjust ModulationProfileTable and 3) Are there any other updated paths to consider for simplified setup, other sequence?=20 Or maybe be more details in the sequence for the objects ? Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Thursday, October 09, 2003 12:25 PM To: David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, David, Your concern sounds very valid. Then it seems to me that 1. either have docsIfUpChannelType is read-only and ask the=20 docsIfUpChannelModulationProfile must be assigned first before setting=20 other upstream attributes. For this is one, I don't know user would like=20 it or not. 2. or we still need to keep the docsIfUpChannelType is read-create, so it=20 can be used to check other upstream attributes consistence without having=20 an modulation profile assigned. The user must make sure both=20 docsIfUpChannelModulationProfile and docsIfUpChannelType are the same when=20 trying to set either one of them if docsIfUpChannelModulationProfile is not=20 value 0. If they are not consistent, the set will fail. Any more possible solution ? Just some more thoughts. Thanks a lot ! Minnie At 11:35 AM 10/9/2003 -0400, David.White@arrisi.com wrote: >Greg, > The main problem I have with this is that it forces the CMTS >to postpone data checking until possibly the very end when the=20 >modulation profile is finally assigned. That is, the user may get a=20 >wrongValue or inconsistentValue while attempting to set the modulation >profile because one or more already-set parameters do not agree with >the ModChannelType. What I liked about having the UpChannelType being=20 >a configurable and "active" (rather than passive) object is that the=20 >CMTS verify things like ChannelWidth, SlotSize, and the Scdma=20 >parameters as they are being set. Thus, the error is immediate and=20 >pertitent. > >However, what I like about your proposal is that it makes it easier to=20 >transition an upstream channel from tdma, atdma, and tdmaAndAtdma=20 >without having to change both the modulation profile and UpChannelType=20 >at the same time. > >I'm not rejecting your proposal, but just wanted to voice my concerns. > >Thanks, >David > > > >"Greg White" >Sent by: owner-docsis-oss@cablelabs.com > >10/08/2003 07:35 PM > > To: > cc: "DOCSIS OSS Majordomo List"=20 > , , > , , "Minnie Lu"=20 > > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > >David, > >According to the proposed text, docsIfUpChannelType would be read-only >for ALL rows. > >For "active" rows (docsIfUpChannelStatus =3D active(1)) setting=20 >UpChannelModulationProfile would return an error if the channel type of >the profile does not work with the other parameters in the row. > >For "cloned" rows (docsIfUpChannelStatus =3D notInService(2)) no=20 >verification is done on consistency of parameters until=20 >docsIfUpChannelUpdate is set to true. > >The verification for active rows is indicated in the proposed text for=20 >UpChannelModulationProfile, although it looks like it could be >clarified: > > Setting this object on an "active" row MUST return an > error if the following > conditions are not satisfied: > 1. All the IUC entries in the selected modulation profile > MUST have the same value of docsIfCmtsModChannelType. > 2. All of the modulation parameters in the selected > modulation profile MUST be consistent with the other > parameters in this docsIfUpChannelEntry. > >Does that address your concern? > >-Greg > >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Wednesday, October 08, 2003 3:11 PM >To: Greg White >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org;=20 >Larry.Spaete@arrisi.com; Minnie Lu >Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for=20 >assigning modulation profiles to upstream channels) > > >Greg, > Per your earlier e-mail on this thread: > >"Also, I would like to propose that we make docsIfUpChannelType a >read-only object for active rows in the Upstream Channel Table. The=20 >value reported would be taken from the modulation profile pointed to by >docsIfUpChannelModulationProfile." > >I'm assuming "active" mean in-service. Otherwise, we have to be careful >with this because the channelType is used to verify things like=20 >channelWidth and whether or not setting of the scdma-specific=20 >parameters is allowed. Along the same lines, if setting the upstream=20 >modulation profile index implies that the SNMP agent changes the=20 >upChannelType to match the modProfChannelType, then the agent must also >verify that all of the other parameters in the upstream channel are >compatible with the possibly new channel type. > >David > > >"Greg White" > >10/08/2003 04:12 PM > To: "Minnie Lu" > cc: , "DOCSIS OSS Majordomo List"=20 > , ,=20 >, > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > > >Minnie, > >I didn't want to prevent a user from changing their mind regarding=20 >channel type when creating a new modulation profile. Suppose you=20 >started out setting channel type to atdma and, after completing a few=20 >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make=20 >you start from scratch (or do a simultaneous set across all IUCs), you=20 >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List;=20 >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Hi, Greg, > >Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is=20 >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the >modulation profile is not assigned to any upstreams. So the error=20 >could be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of=20 >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which=20 > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements > >to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by=20 > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please=20 > >review >the > >attached proposal and provide comments. > > > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White;=20 > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same=20 > >issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path=20 > > of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or=20 > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with=20 > > other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , ,=20 > > , > > > "DOCSIS OSS Majordomo List" , "Owner=20 > > DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I=20 > > >think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same=20 > > >ModChannelType. Also, based on the exchange here it seems that=20 > > >there >is > > >some support for the additional restriction that UpChannelType and=20 > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the=20 > > >specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change=20 > > >UpChannelType to match ModChannelType whenever=20 > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the=20 > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be=20 > > >made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about=20 > >the case that some modulation profile is used by some upstream=20 > >channel, and user change the modulation profile channel type ? Does=20 > >it mean that >the > >upstream channel type would be changed automatically, too ? If yes,=20 > >I >am > >afraid that there might be some user who forget the modulation=20 > >profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The=20 > >modulation profile channel type and upstream channel type are in two=20 > >different MIB tables. > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type=20 > >be changed ? Maybe this is a confusing point which needs to be=20 > >clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles=20 > > >to upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the=20 > > >consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation=20 > > >profile entries with the same docsIfCmtsModIndex will have to have=20 > > >the same docsIfCmtsModChannelType. Otherwise, you would not be able > > >to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid,=20 > > >no >? > > >The way to patch it up would be to make all of the IUCs=20 > > >tdmaAndAtdma, correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is=20 > > >correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used=20 > > >with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29=20 > > >and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and=20 > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2.=20 > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV=20 > > >5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type=20 > > >29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List" > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for=20 > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects=20 > > > > docsIfCmtsModByteInterleaverBlockSize and=20 > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to=20 > > > > see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for=20 > > > > modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma=20 > > > > for modulation profiles that could not be met with a pair of=20 > > > > tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we=20 > > > > could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a=20 > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line=20 > > > >of thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations.=20 > > > >Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs=20 > > > >1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of=20 > > > >having >the > > > >MIB reporting something that doesn't exactly reflect what is=20 > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the=20 > > > >modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data=20 > > > > for consistency. Furthermore, it would seem possible to compare=20 > > > > the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of=20 > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > > > > _______________________________________________ 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 Fri Oct 10 12:58:24 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 MAA07172 for ; Fri, 10 Oct 2003 12:58:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80aY-0001Np-F8 for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 12:58:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AGw2Ml005313 for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 12:58:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80aX-0001NU-OA; Fri, 10 Oct 2003 12:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80aN-0001My-Oo for ipcdn@optimus.ietf.org; Fri, 10 Oct 2003 12:57:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07146 for ; Fri, 10 Oct 2003 12:57:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A80aG-0006Cy-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 12:57:44 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A80aF-0006CM-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 12:57:43 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9AGlW10023673; Fri, 10 Oct 2003 10:47:33 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Date: Fri, 10 Oct 2003 10:47:32 -0600 Message-ID: Thread-Topic: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcOOktBv0hn4SqViTae2STkl2UxTNwABYoEwAAWCS7AABY6OcAAcphSwAADDo1AABFhoUA== From: "Greg White" To: "Eduardo Cardona" , "Dan Rice @ Stargus" , "Minnie Lu" , Cc: "DOCSIS OSS Majordomo List" , , , , "Owner DOCSIS OSS Majordomo List" 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 3 comments in-line. -----Original Message----- From: Eduardo Cardona=20 Sent: Friday, October 10, 2003 9:33 AM To: Dan Rice @ Stargus; Greg White; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Dan,=20 That's a very good point, Currently is up to de Vendor for non-SCDMA, I think we did not finish the discussion about that last time. I have always been uncomfortable with the descriptions referring to SCDMA only. I don't see any real benefit for the vendor in only supporting this feature for rows that have a channel type of SCDMA, and even if they did, how would they handle changes to/from SCDMA mode? I would very much be in favor of cleaning up those definitions to remove the references to SCDMA and the text making support optional for non-SCDMA rows. Also, The "active" (a mix with RowStatus 'active' but not necessarily linked to ifAdmin/OperStatus) was initially though to be the entries associated to real physical US ports. The row Status was intended for Clonning process,=20 as we know RFC 2670 did not have RowStatus; and for "active", now RowStatus may have ramifications with RowStatus values not really defined, like 'notReady' and the connotations of ifAdminStatus, ifOperStatus that are the currently used,=20 To avoid that, I would think that RowStatus object is not instantiated for "real" mapped entries by ifIndex. Leaving ifAdminStatus the complete activation/de-activation of entries. Or 'always' report 'active' regardless of the IfOperStatus, Would be good to clear that. Isn't the description text for UpChannelStatus clear enough on this?=20 The clonning entry, will be the simulation bench to tuning the values, Will explode the Whole range of RowStatus 'notReady' After creation will indicates the US Channel/Mod profile setup is not right. 'notInService' all parameters are consistent and can be turn via Update object to the cloned interface. =20 Also one thing that could be sticky=20 "CloneFrom" object is the pointer to later transfer the values. Alas "CopyTo" I may be wrong but just by name references when CloneFrom is set, (as a clonning process) will copy values of pointed entry to created entry,=20 Currently CloneFrom object does not say that. But I believe it does not limit implementers to think on that, I agree, I was surprised to see that there is no mention of what operation takes place upon setting CloneFrom. The name certainly implies (and was the intention I believe) that setting CloneFrom copied all of the entries from the referenced 'active' row, which implies that it is the first object to set after row creation. I'd rather clean up the description to match that intent, rather than change the object to 'CopyTo'. I don't think 'CopyTo' would really be more efficient than 'CloneFrom' for an automated NMS. The only efficiency lost would be having the CMTS copy 60-odd bytes from one memory location to another only to potentially have them overwritten by the NMS. If these operations were happening on millisecond timescales I would be concerned, but this is more like a once-a-day, once-a-month, once-a-year type operation. Let's keep the changes simple and just update the description to match the object name and the original intent. Just to make sure the object does always the same think A) Clonning process semantics=20 - after createAndWait the first object to set is CloneFrom (copy parameters into clonning entry) - It Might be clarified in the object - - Adjust objects values - Set update object to 'true' will success if: =20 before set, RowStatus was 'notInService',=20 and no other error condition is raised by CMTS for the set=20 B) Copy Process (CopyTo) - After createAndWait set arbitrary objects , setting object CloneFrom does NOT transfer=20 parameters from pointed entry to created entry - Set update object to 'true' will success if: =20 before set, RowStatus was 'notInService',=20 and no other error condition is raised by CMTS for the set Being specific will clear a little bit the process in the user/system thinking doing B) - CMTS does A) - and loosing previous sets if object "CloneFrom" is set after some others.=20 A) is User friendly ( few Sets) B) is autonomous system efficient, -algorithms always calculates all 'optimal' parameters, so might not need to initialize previous setups but should be aware of setting first=20 For the object Name ( something we might not want to change at this state) I believe A) is the precisely even though I would prefer 1 but the correct name should be "CopyTo" Summary of possible edits: No RowStatus for 'real' ifIndex associated entries Explicitly say cloneFrom update values in created entry from pointed entry Let me know any comments Eduardo -----Original Message----- From: Dan Rice @ Stargus=20 Sent: Friday, October 10, 2003 8:17 AM To: Eduardo Cardona; Greg White; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) For my $0.02 I would prefer just having the clone mechanism. Even within the upstream channel parameters you must change things in the right order for them to be correct if you do it while row is active. This is not just an UpChannelType issue. For example setting a minislot size before changing the symbol rate can result in some situations that CMTSs today will reject. If you reduce the minislot size before increasing symbol rate, you could no longer send a max packet. I think if we made the clone method mandatory for both TDMA and SCDMA and changed the descriptions to be this way than I would be happy because there is now a deterministic way to make changes and commit them. Today in most deployed CMTSs its hard to know how many UCD changes occur when you make changes to upstream channel today. It seems to depend on vendor. When all you are really shooting for is an end result this seems the safest and most deterministic route to me. =20 I think that many of the cases of making changes to active modulation profiles and upstream channel settings can make things a little funny if the commit isn't very defined. If there are requirements for support of enough modulation table entries and enough clone rows to accommodate an active and notInService for each upstream interface this could be a lot cleaner. Any change that is made is done by creating a new complete modulation profile (even if its just changing one value, I imagine most of this will done through software as opposed to hand editing) then creating a clone upstream channel table entry with pointer to this new mod profile and associated upstream channel settings, then commit the changes. Additionally it would be nice to have the same functionality in the downstream channel table to be consistent. For example it would be nice to commit modulation and interleave settings at the same time. -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com]=20 Sent: Thursday, October 09, 2003 8:37 PM To: Greg White; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) I agree that turning off is not desired for in-service if the changes are not incremental or very drastic changes, I did not enforce the "at maximum" word in both cases (actually I only used that in the second example). It might be some cases where the interface or implementations definitely have to be turn off, but will be on maintenance windows, (season changes -?- school calendar, long weekend?, maintenance measurements.) very uncommon or at knowledge of consequences by MSOs. I agree that the primarily intention is minimum service disruption primarily for spectrum management when changes might be incremental in robustness parameters or phy channel parameters.=20 And as Greg said, one shot change if moving channel from profile A to B. and seems to me that changes in profile should be compatible to the current channel PHY and ulterior modification of the channel will be also, the only problem as today is the double location of ChannelType=20 Eduardo -----Original Message----- From: Greg White=20 Sent: Thursday, October 09, 2003 4:31 PM To: Eduardo Cardona; 'Minnie Lu'; 'David.White@arrisi.com' Cc: DOCSIS OSS Majordomo List; 'Greg.Gohman@arrisi.com'; 'ipcdn@ietf.org'; 'Larry.Spaete@arrisi.com'; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) So, first off, there are a number of parameters that must be consistent across the two tables for the configuration to be valid, and the active rows in the UpChannelTable *always* have to be valid. The only possible exception to this would be if the interface were turned down before the changes were made, but I don't think that is an operationally useful scenario to consider, and some (all?) vendors might want to enforce validity even in that case. Any active row in the UpChannelTable will be populated by consistent defaults or stored values when the CMTS is booted, so we only need to consider *changes* to those rows (i.e. they can't be created from scratch and so would never have to be populated one-object-at-a-time). Any change to an active row can be done by two methods: direct change & cloning. When a change is made directly, the validation occurs immediately upon receiving the snmp set. When using the cloning mechanism, the validation only occurs when the ChannelUpdate object is set true. This proposal does not change either of those aspects. It only enforces that UpChannelModulationProfile and UpChannelType are guaranteed to be consistent with each other. The whole point of the cloning mechanism was to have a temporary "scratch" area where an operator could manipulate the values without having the constraint that they are consistent at every step. Thus the consistency verification is only done upon ChannelUpdate. I don't think that the steps Eduardo suggested are valid, setting ModulationProfile to '0' on an active row would seem to make the channel unusable, no? Setting ModulationProfile to '0' on an inactive row wouldn't be necessary since there is no consistency checking. Let me know if I'm completely missing the boat here.... -Greg -----Original Message----- From: Eduardo Cardona=20 Sent: Thursday, October 09, 2003 1:38 PM To: 'Minnie Lu'; David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi David, Minnie,=20 Greg may have other comments. I think the idea was to define one clear way of configuration rather than finding possible broken paths The idea was to pass the role of The UpChannel parameters vs ChannelType verification to one trigger, the docsIfUpChannelModulationProfile so it verifies that all the channelTypes are the same (in the mod profile) All Modulation Parameters are consistent in into their own IUC [ can be done also as user change an IUC itself -invalid value for that particulat CMTS-, etc] Then as the Type is knew from the profile verifies that the ChannelType is compatible with the UpChannel parameters, if fails nothing haven change or undo-commit.=20 The point is that UpChannel to ModulationProfile is one-to-many so going in that path eventually the user won't break the Profile that works for other UpChannels and instead maybe create a one-to-one UpChannel-to-ModulationProfile ( by creating a new Profile) In the current UpChannelChanelType read-create we have, implies UpChannelModProfile and ChannelType might need to be modified simultaneously or: 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelType to 'x' and=20 -verify Chnnl- 4 UpChannelModulationProfile to 'y' -verify Chnnl UpCh/ModProfile-=20 if failed start again from 1 With the proposal at maximum ( channelType RO) would be =20 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelModulationProfile to 'y' - do all verifications chnnl/ModProf- =20 if failed redo 2, maybe adjust ModulationProfileTable and 3) Are there any other updated paths to consider for simplified setup, other sequence?=20 Or maybe be more details in the sequence for the objects ? Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Thursday, October 09, 2003 12:25 PM To: David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, David, Your concern sounds very valid. Then it seems to me that 1. either have docsIfUpChannelType is read-only and ask the=20 docsIfUpChannelModulationProfile must be assigned first before setting=20 other upstream attributes. For this is one, I don't know user would like=20 it or not. 2. or we still need to keep the docsIfUpChannelType is read-create, so it=20 can be used to check other upstream attributes consistence without having=20 an modulation profile assigned. The user must make sure both=20 docsIfUpChannelModulationProfile and docsIfUpChannelType are the same when=20 trying to set either one of them if docsIfUpChannelModulationProfile is not=20 value 0. If they are not consistent, the set will fail. Any more possible solution ? Just some more thoughts. Thanks a lot ! Minnie At 11:35 AM 10/9/2003 -0400, David.White@arrisi.com wrote: >Greg, > The main problem I have with this is that it forces the CMTS >to postpone data checking until possibly the very end when the=20 >modulation profile is finally assigned. That is, the user may get a=20 >wrongValue or inconsistentValue while attempting to set the modulation >profile because one or more already-set parameters do not agree with >the ModChannelType. What I liked about having the UpChannelType being=20 >a configurable and "active" (rather than passive) object is that the=20 >CMTS verify things like ChannelWidth, SlotSize, and the Scdma=20 >parameters as they are being set. Thus, the error is immediate and=20 >pertitent. > >However, what I like about your proposal is that it makes it easier to=20 >transition an upstream channel from tdma, atdma, and tdmaAndAtdma=20 >without having to change both the modulation profile and UpChannelType=20 >at the same time. > >I'm not rejecting your proposal, but just wanted to voice my concerns. > >Thanks, >David > > > >"Greg White" >Sent by: owner-docsis-oss@cablelabs.com > >10/08/2003 07:35 PM > > To: > cc: "DOCSIS OSS Majordomo List"=20 > , , > , , "Minnie Lu"=20 > > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > >David, > >According to the proposed text, docsIfUpChannelType would be read-only >for ALL rows. > >For "active" rows (docsIfUpChannelStatus =3D active(1)) setting=20 >UpChannelModulationProfile would return an error if the channel type of >the profile does not work with the other parameters in the row. > >For "cloned" rows (docsIfUpChannelStatus =3D notInService(2)) no=20 >verification is done on consistency of parameters until=20 >docsIfUpChannelUpdate is set to true. > >The verification for active rows is indicated in the proposed text for=20 >UpChannelModulationProfile, although it looks like it could be >clarified: > > Setting this object on an "active" row MUST return an > error if the following > conditions are not satisfied: > 1. All the IUC entries in the selected modulation profile > MUST have the same value of docsIfCmtsModChannelType. > 2. All of the modulation parameters in the selected > modulation profile MUST be consistent with the other > parameters in this docsIfUpChannelEntry. > >Does that address your concern? > >-Greg > >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Wednesday, October 08, 2003 3:11 PM >To: Greg White >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org;=20 >Larry.Spaete@arrisi.com; Minnie Lu >Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for=20 >assigning modulation profiles to upstream channels) > > >Greg, > Per your earlier e-mail on this thread: > >"Also, I would like to propose that we make docsIfUpChannelType a >read-only object for active rows in the Upstream Channel Table. The=20 >value reported would be taken from the modulation profile pointed to by >docsIfUpChannelModulationProfile." > >I'm assuming "active" mean in-service. Otherwise, we have to be careful >with this because the channelType is used to verify things like=20 >channelWidth and whether or not setting of the scdma-specific=20 >parameters is allowed. Along the same lines, if setting the upstream=20 >modulation profile index implies that the SNMP agent changes the=20 >upChannelType to match the modProfChannelType, then the agent must also >verify that all of the other parameters in the upstream channel are >compatible with the possibly new channel type. > >David > > >"Greg White" > >10/08/2003 04:12 PM > To: "Minnie Lu" > cc: , "DOCSIS OSS Majordomo List"=20 > , ,=20 >, > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > > >Minnie, > >I didn't want to prevent a user from changing their mind regarding=20 >channel type when creating a new modulation profile. Suppose you=20 >started out setting channel type to atdma and, after completing a few=20 >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make=20 >you start from scratch (or do a simultaneous set across all IUCs), you=20 >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List;=20 >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Hi, Greg, > >Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is=20 >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the >modulation profile is not assigned to any upstreams. So the error=20 >could be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of=20 >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which=20 > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements > >to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by=20 > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please=20 > >review >the > >attached proposal and provide comments. > > > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White;=20 > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same=20 > >issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path=20 > > of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or=20 > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with=20 > > other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , ,=20 > > , > > > "DOCSIS OSS Majordomo List" , "Owner=20 > > DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I=20 > > >think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same=20 > > >ModChannelType. Also, based on the exchange here it seems that=20 > > >there >is > > >some support for the additional restriction that UpChannelType and=20 > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the=20 > > >specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change=20 > > >UpChannelType to match ModChannelType whenever=20 > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the=20 > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be=20 > > >made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about=20 > >the case that some modulation profile is used by some upstream=20 > >channel, and user change the modulation profile channel type ? Does=20 > >it mean that >the > >upstream channel type would be changed automatically, too ? If yes,=20 > >I >am > >afraid that there might be some user who forget the modulation=20 > >profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The=20 > >modulation profile channel type and upstream channel type are in two=20 > >different MIB tables. > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type=20 > >be changed ? Maybe this is a confusing point which needs to be=20 > >clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles=20 > > >to upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the=20 > > >consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation=20 > > >profile entries with the same docsIfCmtsModIndex will have to have=20 > > >the same docsIfCmtsModChannelType. Otherwise, you would not be able > > >to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid,=20 > > >no >? > > >The way to patch it up would be to make all of the IUCs=20 > > >tdmaAndAtdma, correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is=20 > > >correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used=20 > > >with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29=20 > > >and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and=20 > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2.=20 > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV=20 > > >5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type=20 > > >29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List" > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for=20 > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects=20 > > > > docsIfCmtsModByteInterleaverBlockSize and=20 > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to=20 > > > > see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for=20 > > > > modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma=20 > > > > for modulation profiles that could not be met with a pair of=20 > > > > tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we=20 > > > > could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a=20 > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line=20 > > > >of thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations.=20 > > > >Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs=20 > > > >1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of=20 > > > >having >the > > > >MIB reporting something that doesn't exactly reflect what is=20 > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the=20 > > > >modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data=20 > > > > for consistency. Furthermore, it would seem possible to compare=20 > > > > the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of=20 > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > > > > _______________________________________________ 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 Fri Oct 10 13:00:26 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 NAA07332 for ; Fri, 10 Oct 2003 13:00:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80cX-0001kV-KL for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 13:00:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AH054s006709 for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 13:00:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80cW-0001k3-0D; Fri, 10 Oct 2003 13:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80cN-0001ix-5F for ipcdn@optimus.ietf.org; Fri, 10 Oct 2003 12:59:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07299 for ; Fri, 10 Oct 2003 12:59:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A80cL-0006G4-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 12:59:53 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A80cK-0006D3-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 12:59:52 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9AGuD10024815; Fri, 10 Oct 2003 10:56:14 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Date: Fri, 10 Oct 2003 10:56:13 -0600 Message-ID: Thread-Topic: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcON4HQlGjFPumzdSPCnH47/qeYknQAEa5kgAFC7PKAABmTZ4A== From: "Greg White" To: "Dan Rice @ Stargus" , "Minnie Lu" Cc: , "DOCSIS OSS Majordomo List" , , , 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 What I had interpreted Minnie's suggestion to be was that ChannelType consistency was enforced across all modulation profile rows with a Status of 'active', regardless of whether they were assigned to an upstream channel or not. Setting Status to 'notInService' is not allowed for propfiles assigned to an upstream channel, nor is changing ChannelType. So, the operation Minnie suggested only applies to profiles that have been created and set 'active', but are not assigned to any upstream channel. Does that clarify? -Greg -----Original Message----- From: Dan Rice @ Stargus=20 Sent: Friday, October 10, 2003 7:59 AM To: Greg White; Minnie Lu Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Sorry for chiming in 11th hour, but want to make sure I understand minnie's suggestion for active entries. I believe the suggestion is that for active entries you change the row status to not in service. What would we expect to happen to the upstream currently assigned this modulation profile while it is notInService? Would the existing active assignment continue to be valid for the upstream using it until all IUC rows became active again with the changes in them? Also if the changes are to docsIfCmtsModChannelType wouldn't you have to edit all IUC rows before checking to see if this is valid? I guess when you started going in and making each IUC active that would be the point to check it? Could you guarantee that all IUCs are committed at the same time since they would "immediately" be committed to the active upstream channel entries with pointers to the docsIfCmtsModIndex? Thanks for the clarifications. - Dan -----Original Message----- From: Greg White [mailto:g.white@CableLabs.com]=20 Sent: Wednesday, October 08, 2003 7:20 PM To: Minnie Lu Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) That sounds like a workable alternative. If no one disagrees, I will make that change to the proposal. -Greg -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Wednesday, October 08, 2003 3:09 PM To: Greg White Cc: Minnie Lu; David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, Greg, Then how about enforce this rule for "active" entries ? So in the case you=20 mentioned, user can change the row status to notInService first or at the=20 same time changing the channel type. When user changed all the entries' channel type to be the same, use can put the entries in active again. I personally think it affects a lot when the channel type is changed, so a little more steps should be ok. To me, if there is an error, better catch=20 it as earlier as possible. "All the active entries in a modulation profile (i.e. all active entries that share a common docsIfCmtsModIndex) MUST have the same value of docsIfCmtsModChannelType." Thanks a lot ! Minnie At 02:12 PM 10/8/2003 -0600, Greg White wrote: >Minnie, > >I didn't want to prevent a user from changing their mind regarding >channel type when creating a new modulation profile. Suppose you >started out setting channel type to atdma and, after completing a few >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make >you start from scratch (or do a simultaneous set across all IUCs), you >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Hi, Greg, > > Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the >modulation profile is not assigned to any upstreams. So the error could >be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please review >the > >attached proposal and provide comments. > > > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , , , > > > "DOCSIS OSS Majordomo List" , "Owner DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same > > >ModChannelType. Also, based on the exchange here it seems that there >is > > >some support for the additional restriction that UpChannelType and > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change > > >UpChannelType to match ModChannelType whenever > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about the > >case that some modulation profile is used by some upstream channel, and > >user change the modulation profile channel type ? Does it mean that >the > >upstream channel type would be changed automatically, too ? If yes, I >am > >afraid that there might be some user who forget the modulation profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The > >modulation profile channel type and upstream channel type are in two > >different MIB tables. > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type be > >changed ? Maybe this is a confusing point which needs to be clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > > >upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation profile > > >entries with the same docsIfCmtsModIndex will have to have the same > > >docsIfCmtsModChannelType. Otherwise, you would not be able to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid, no >? > > >The way to patch it up would be to make all of the IUCs tdmaAndAtdma, > > >correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List" > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects > > > > docsIfCmtsModByteInterleaverBlockSize and > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma for > > > > modulation profiles that could not be met with a pair of tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line of > > > >thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations. Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of having >the > > > >MIB reporting something that doesn't exactly reflect what is > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the > > > > modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data for > > > > consistency. Furthermore, it would seem possible to compare the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > _______________________________________________ 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 Fri Oct 10 13:30:28 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 NAA08763 for ; Fri, 10 Oct 2003 13:30:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A815a-0003nO-4Y for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 13:30:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AHU6Us014584 for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 13:30:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A815Y-0003my-Dh; Fri, 10 Oct 2003 13:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A815L-0003lz-Al for ipcdn@optimus.ietf.org; Fri, 10 Oct 2003 13:29:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08703 for ; Fri, 10 Oct 2003 13:29:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A815J-0006dU-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 13:29:49 -0400 Received: from mail.stargus.com ([65.193.169.166]) by ietf-mx with smtp (Exim 4.12) id 1A815I-0006d1-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 13:29:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Oct 2003 13:26:40 -0400 Message-ID: <344C3B42FD36C54A8BC47A471265DEF001A91D@xchange.stargus.com> Thread-Topic: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcON4HQlGjFPumzdSPCnH47/qeYknQAEa5kgAFC7PKAABmTZ4AABAixw From: "Dan Rice" To: "Greg White" , "Minnie Lu" Cc: , "DOCSIS OSS Majordomo List" , , , 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 -----Original Message----- From: Greg White [mailto:g.white@CableLabs.com]=20 Sent: Friday, October 10, 2003 12:56 PM To: Dan Rice; Minnie Lu Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) What I had interpreted Minnie's suggestion to be was that ChannelType consistency was enforced across all modulation profile rows with a Status of 'active', regardless of whether they were assigned to an upstream channel or not. Setting Status to 'notInService' is not allowed for propfiles assigned to an upstream channel, nor is changing ChannelType. So, the operation Minnie suggested only applies to profiles that have been created and set 'active', but are not assigned to any upstream channel. Does that clarify? [DJR] Yes that sounds good. Thank You Greg Can I also extend your answer to infer one or both of the following: 1) Changing of the channel type is not allowed for any set of iuc rows while their modulation profile is assigned to an active upstream channel. 2) Changing any of the modulation profile attributes is not allowed while it is assigned to an active upstream channel? -Greg -----Original Message----- From: Dan Rice @ Stargus=20 Sent: Friday, October 10, 2003 7:59 AM To: Greg White; Minnie Lu Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Sorry for chiming in 11th hour, but want to make sure I understand minnie's suggestion for active entries. I believe the suggestion is that for active entries you change the row status to not in service. What would we expect to happen to the upstream currently assigned this modulation profile while it is notInService? Would the existing active assignment continue to be valid for the upstream using it until all IUC rows became active again with the changes in them? Also if the changes are to docsIfCmtsModChannelType wouldn't you have to edit all IUC rows before checking to see if this is valid? I guess when you started going in and making each IUC active that would be the point to check it? Could you guarantee that all IUCs are committed at the same time since they would "immediately" be committed to the active upstream channel entries with pointers to the docsIfCmtsModIndex? Thanks for the clarifications. - Dan -----Original Message----- From: Greg White [mailto:g.white@CableLabs.com]=20 Sent: Wednesday, October 08, 2003 7:20 PM To: Minnie Lu Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) That sounds like a workable alternative. If no one disagrees, I will make that change to the proposal. -Greg -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Wednesday, October 08, 2003 3:09 PM To: Greg White Cc: Minnie Lu; David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, Greg, Then how about enforce this rule for "active" entries ? So in the case you=20 mentioned, user can change the row status to notInService first or at the=20 same time changing the channel type. When user changed all the entries' channel type to be the same, use can put the entries in active again. I personally think it affects a lot when the channel type is changed, so a little more steps should be ok. To me, if there is an error, better catch=20 it as earlier as possible. "All the active entries in a modulation profile (i.e. all active entries that share a common docsIfCmtsModIndex) MUST have the same value of docsIfCmtsModChannelType." Thanks a lot ! Minnie At 02:12 PM 10/8/2003 -0600, Greg White wrote: >Minnie, > >I didn't want to prevent a user from changing their mind regarding >channel type when creating a new modulation profile. Suppose you >started out setting channel type to atdma and, after completing a few >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make >you start from scratch (or do a simultaneous set across all IUCs), you >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Hi, Greg, > > Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the >modulation profile is not assigned to any upstreams. So the error could >be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please review >the > >attached proposal and provide comments. > > > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , , , > > > "DOCSIS OSS Majordomo List" , "Owner DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same > > >ModChannelType. Also, based on the exchange here it seems that there >is > > >some support for the additional restriction that UpChannelType and > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change > > >UpChannelType to match ModChannelType whenever > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about the > >case that some modulation profile is used by some upstream channel, and > >user change the modulation profile channel type ? Does it mean that >the > >upstream channel type would be changed automatically, too ? If yes, I >am > >afraid that there might be some user who forget the modulation profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The > >modulation profile channel type and upstream channel type are in two > >different MIB tables. > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type be > >changed ? Maybe this is a confusing point which needs to be clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > > >upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation profile > > >entries with the same docsIfCmtsModIndex will have to have the same > > >docsIfCmtsModChannelType. Otherwise, you would not be able to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid, no >? > > >The way to patch it up would be to make all of the IUCs tdmaAndAtdma, > > >correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List" > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects > > > > docsIfCmtsModByteInterleaverBlockSize and > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma for > > > > modulation profiles that could not be met with a pair of tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line of > > > >thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations. Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of having >the > > > >MIB reporting something that doesn't exactly reflect what is > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the > > > > modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data for > > > > consistency. Furthermore, it would seem possible to compare the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > _______________________________________________ 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 Fri Oct 10 13:51:25 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 NAA09549 for ; Fri, 10 Oct 2003 13:51:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81Pq-00058F-TR for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 13:51:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AHp2PM019721 for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 13:51:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81Pq-00057p-5q; Fri, 10 Oct 2003 13:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81Os-00054l-9b for ipcdn@optimus.ietf.org; Fri, 10 Oct 2003 13:50:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09462 for ; Fri, 10 Oct 2003 13:49:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81Op-0006sa-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 13:49:59 -0400 Received: from mail.stargus.com ([65.193.169.166]) by ietf-mx with smtp (Exim 4.12) id 1A81Oo-0006rl-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 13:49:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Oct 2003 13:46:50 -0400 Message-ID: <344C3B42FD36C54A8BC47A471265DEF001A91F@xchange.stargus.com> Thread-Topic: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcOOktBv0hn4SqViTae2STkl2UxTNwABYoEwAAWCS7AABY6OcAAcphSwAADDo1AABFhoUAACTZvg From: "Dan Rice" To: "Greg White" , "Eduardo Cardona" , "Minnie Lu" , Cc: "DOCSIS OSS Majordomo List" , , , , "Owner DOCSIS OSS Majordomo List" 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 Agreements and my preferences below -----Original Message----- From: Greg White [mailto:g.white@CableLabs.com]=20 Sent: Friday, October 10, 2003 12:48 PM To: Eduardo Cardona; Dan Rice; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) 3 comments in-line. -----Original Message----- From: Eduardo Cardona=20 Sent: Friday, October 10, 2003 9:33 AM To: Dan Rice @ Stargus; Greg White; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Dan,=20 That's a very good point, Currently is up to de Vendor for non-SCDMA, I think we did not finish the discussion about that last time. I have always been uncomfortable with the descriptions referring to SCDMA only. I don't see any real benefit for the vendor in only supporting this feature for rows that have a channel type of SCDMA, and even if they did, how would they handle changes to/from SCDMA mode? I would very much be in favor of cleaning up those definitions to remove the references to SCDMA and the text making support optional for non-SCDMA rows. [DJR] Great this was issue 6, may need an ecr also? Also, The "active" (a mix with RowStatus 'active' but not necessarily linked to ifAdmin/OperStatus) was initially though to be the entries associated to real physical US ports. The row Status was intended for Clonning process,=20 as we know RFC 2670 did not have RowStatus; and for "active", now RowStatus may have ramifications with RowStatus values not really defined, like 'notReady' and the connotations of ifAdminStatus, ifOperStatus that are the currently used,=20 To avoid that, I would think that RowStatus object is not instantiated for "real" mapped entries by ifIndex. Leaving ifAdminStatus the complete activation/de-activation of entries. Or 'always' report 'active' regardless of the IfOperStatus, Would be good to clear that. Isn't the description text for UpChannelStatus clear enough on this?=20 [DJR] I believe this was clear. The clonning entry, will be the simulation bench to tuning the values, Will explode the Whole range of RowStatus 'notReady' After creation will indicates the US Channel/Mod profile setup is not right. 'notInService' all parameters are consistent and can be turn via Update object to the cloned interface. =20 Also one thing that could be sticky=20 "CloneFrom" object is the pointer to later transfer the values. Alas "CopyTo" I may be wrong but just by name references when CloneFrom is set, (as a clonning process) will copy values of pointed entry to created entry,=20 Currently CloneFrom object does not say that. But I believe it does not limit implementers to think on that, I agree, I was surprised to see that there is no mention of what operation takes place upon setting CloneFrom. The name certainly implies (and was the intention I believe) that setting CloneFrom copied all of the entries from the referenced 'active' row, which implies that it is the first object to set after row creation. I'd rather clean up the description to match that intent, rather than change the object to 'CopyTo'. I don't think 'CopyTo' would really be more efficient than 'CloneFrom' for an automated NMS. The only efficiency lost would be having the CMTS copy 60-odd bytes from one memory location to another only to potentially have them overwritten by the NMS. If these operations were happening on millisecond timescales I would be concerned, but this is more like a once-a-day, once-a-month, once-a-year type operation. Let's keep the changes simple and just update the description to match the object name and the original intent. [DJR] I am not sure that this entry is super useful for most applications besides experimenting in the lab. I think if this entry just identified the active row you would be changing as opposed to creating a template for one to tweak that would be more effective. I think a management system would first create a new mod profile, then create a clone row including all relevant entries from upstream channel table, enter the upstream index it is intended to change and then commit it with UpChannelUpdate assuming all columns in the upstream channel would be applied in a single commit. I think it is a little waste of time to copy the current values when you are going to overwrite them all anyway. In addition it makes this 3 transactions instead of 2. I could live with it, but not sure I need it Just to make sure the object does always the same think A) Clonning process semantics=20 - after createAndWait the first object to set is CloneFrom (copy parameters into clonning entry) - It Might be clarified in the object - - Adjust objects values - Set update object to 'true' will success if: =20 before set, RowStatus was 'notInService',=20 and no other error condition is raised by CMTS for the set=20 B) Copy Process (CopyTo) - After createAndWait set arbitrary objects , setting object CloneFrom does NOT transfer=20 parameters from pointed entry to created entry - Set update object to 'true' will success if: =20 before set, RowStatus was 'notInService',=20 and no other error condition is raised by CMTS for the set Being specific will clear a little bit the process in the user/system thinking doing B) - CMTS does A) - and loosing previous sets if object "CloneFrom" is set after some others.=20 A) is User friendly ( few Sets) B) is autonomous system efficient, -algorithms always calculates all 'optimal' parameters, so might not need to initialize previous setups but should be aware of setting first=20 For the object Name ( something we might not want to change at this state) I believe A) is the precisely even though I would prefer 1 but the correct name should be "CopyTo" Summary of possible edits: No RowStatus for 'real' ifIndex associated entries Explicitly say cloneFrom update values in created entry from pointed entry Let me know any comments Eduardo -----Original Message----- From: Dan Rice @ Stargus=20 Sent: Friday, October 10, 2003 8:17 AM To: Eduardo Cardona; Greg White; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) For my $0.02 I would prefer just having the clone mechanism. Even within the upstream channel parameters you must change things in the right order for them to be correct if you do it while row is active. This is not just an UpChannelType issue. For example setting a minislot size before changing the symbol rate can result in some situations that CMTSs today will reject. If you reduce the minislot size before increasing symbol rate, you could no longer send a max packet. I think if we made the clone method mandatory for both TDMA and SCDMA and changed the descriptions to be this way than I would be happy because there is now a deterministic way to make changes and commit them. Today in most deployed CMTSs its hard to know how many UCD changes occur when you make changes to upstream channel today. It seems to depend on vendor. When all you are really shooting for is an end result this seems the safest and most deterministic route to me. =20 I think that many of the cases of making changes to active modulation profiles and upstream channel settings can make things a little funny if the commit isn't very defined. If there are requirements for support of enough modulation table entries and enough clone rows to accommodate an active and notInService for each upstream interface this could be a lot cleaner. Any change that is made is done by creating a new complete modulation profile (even if its just changing one value, I imagine most of this will done through software as opposed to hand editing) then creating a clone upstream channel table entry with pointer to this new mod profile and associated upstream channel settings, then commit the changes. Additionally it would be nice to have the same functionality in the downstream channel table to be consistent. For example it would be nice to commit modulation and interleave settings at the same time. -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com]=20 Sent: Thursday, October 09, 2003 8:37 PM To: Greg White; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) I agree that turning off is not desired for in-service if the changes are not incremental or very drastic changes, I did not enforce the "at maximum" word in both cases (actually I only used that in the second example). It might be some cases where the interface or implementations definitely have to be turn off, but will be on maintenance windows, (season changes -?- school calendar, long weekend?, maintenance measurements.) very uncommon or at knowledge of consequences by MSOs. I agree that the primarily intention is minimum service disruption primarily for spectrum management when changes might be incremental in robustness parameters or phy channel parameters.=20 And as Greg said, one shot change if moving channel from profile A to B. and seems to me that changes in profile should be compatible to the current channel PHY and ulterior modification of the channel will be also, the only problem as today is the double location of ChannelType=20 Eduardo -----Original Message----- From: Greg White=20 Sent: Thursday, October 09, 2003 4:31 PM To: Eduardo Cardona; 'Minnie Lu'; 'David.White@arrisi.com' Cc: DOCSIS OSS Majordomo List; 'Greg.Gohman@arrisi.com'; 'ipcdn@ietf.org'; 'Larry.Spaete@arrisi.com'; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) So, first off, there are a number of parameters that must be consistent across the two tables for the configuration to be valid, and the active rows in the UpChannelTable *always* have to be valid. The only possible exception to this would be if the interface were turned down before the changes were made, but I don't think that is an operationally useful scenario to consider, and some (all?) vendors might want to enforce validity even in that case. Any active row in the UpChannelTable will be populated by consistent defaults or stored values when the CMTS is booted, so we only need to consider *changes* to those rows (i.e. they can't be created from scratch and so would never have to be populated one-object-at-a-time). Any change to an active row can be done by two methods: direct change & cloning. When a change is made directly, the validation occurs immediately upon receiving the snmp set. When using the cloning mechanism, the validation only occurs when the ChannelUpdate object is set true. This proposal does not change either of those aspects. It only enforces that UpChannelModulationProfile and UpChannelType are guaranteed to be consistent with each other. The whole point of the cloning mechanism was to have a temporary "scratch" area where an operator could manipulate the values without having the constraint that they are consistent at every step. Thus the consistency verification is only done upon ChannelUpdate. I don't think that the steps Eduardo suggested are valid, setting ModulationProfile to '0' on an active row would seem to make the channel unusable, no? Setting ModulationProfile to '0' on an inactive row wouldn't be necessary since there is no consistency checking. Let me know if I'm completely missing the boat here.... -Greg -----Original Message----- From: Eduardo Cardona=20 Sent: Thursday, October 09, 2003 1:38 PM To: 'Minnie Lu'; David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi David, Minnie,=20 Greg may have other comments. I think the idea was to define one clear way of configuration rather than finding possible broken paths The idea was to pass the role of The UpChannel parameters vs ChannelType verification to one trigger, the docsIfUpChannelModulationProfile so it verifies that all the channelTypes are the same (in the mod profile) All Modulation Parameters are consistent in into their own IUC [ can be done also as user change an IUC itself -invalid value for that particulat CMTS-, etc] Then as the Type is knew from the profile verifies that the ChannelType is compatible with the UpChannel parameters, if fails nothing haven change or undo-commit.=20 The point is that UpChannel to ModulationProfile is one-to-many so going in that path eventually the user won't break the Profile that works for other UpChannels and instead maybe create a one-to-one UpChannel-to-ModulationProfile ( by creating a new Profile) In the current UpChannelChanelType read-create we have, implies UpChannelModProfile and ChannelType might need to be modified simultaneously or: 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelType to 'x' and=20 -verify Chnnl- 4 UpChannelModulationProfile to 'y' -verify Chnnl UpCh/ModProfile-=20 if failed start again from 1 With the proposal at maximum ( channelType RO) would be =20 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelModulationProfile to 'y' - do all verifications chnnl/ModProf- =20 if failed redo 2, maybe adjust ModulationProfileTable and 3) Are there any other updated paths to consider for simplified setup, other sequence?=20 Or maybe be more details in the sequence for the objects ? Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Thursday, October 09, 2003 12:25 PM To: David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, David, Your concern sounds very valid. Then it seems to me that 1. either have docsIfUpChannelType is read-only and ask the=20 docsIfUpChannelModulationProfile must be assigned first before setting=20 other upstream attributes. For this is one, I don't know user would like=20 it or not. 2. or we still need to keep the docsIfUpChannelType is read-create, so it=20 can be used to check other upstream attributes consistence without having=20 an modulation profile assigned. The user must make sure both=20 docsIfUpChannelModulationProfile and docsIfUpChannelType are the same when=20 trying to set either one of them if docsIfUpChannelModulationProfile is not=20 value 0. If they are not consistent, the set will fail. Any more possible solution ? Just some more thoughts. Thanks a lot ! Minnie At 11:35 AM 10/9/2003 -0400, David.White@arrisi.com wrote: >Greg, > The main problem I have with this is that it forces the CMTS >to postpone data checking until possibly the very end when the=20 >modulation profile is finally assigned. That is, the user may get a=20 >wrongValue or inconsistentValue while attempting to set the modulation >profile because one or more already-set parameters do not agree with >the ModChannelType. What I liked about having the UpChannelType being=20 >a configurable and "active" (rather than passive) object is that the=20 >CMTS verify things like ChannelWidth, SlotSize, and the Scdma=20 >parameters as they are being set. Thus, the error is immediate and=20 >pertitent. > >However, what I like about your proposal is that it makes it easier to=20 >transition an upstream channel from tdma, atdma, and tdmaAndAtdma=20 >without having to change both the modulation profile and UpChannelType=20 >at the same time. > >I'm not rejecting your proposal, but just wanted to voice my concerns. > >Thanks, >David > > > >"Greg White" >Sent by: owner-docsis-oss@cablelabs.com > >10/08/2003 07:35 PM > > To: > cc: "DOCSIS OSS Majordomo List"=20 > , , > , , "Minnie Lu"=20 > > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > >David, > >According to the proposed text, docsIfUpChannelType would be read-only >for ALL rows. > >For "active" rows (docsIfUpChannelStatus =3D active(1)) setting=20 >UpChannelModulationProfile would return an error if the channel type of >the profile does not work with the other parameters in the row. > >For "cloned" rows (docsIfUpChannelStatus =3D notInService(2)) no=20 >verification is done on consistency of parameters until=20 >docsIfUpChannelUpdate is set to true. > >The verification for active rows is indicated in the proposed text for=20 >UpChannelModulationProfile, although it looks like it could be >clarified: > > Setting this object on an "active" row MUST return an > error if the following > conditions are not satisfied: > 1. All the IUC entries in the selected modulation profile > MUST have the same value of docsIfCmtsModChannelType. > 2. All of the modulation parameters in the selected > modulation profile MUST be consistent with the other > parameters in this docsIfUpChannelEntry. > >Does that address your concern? > >-Greg > >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Wednesday, October 08, 2003 3:11 PM >To: Greg White >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org;=20 >Larry.Spaete@arrisi.com; Minnie Lu >Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for=20 >assigning modulation profiles to upstream channels) > > >Greg, > Per your earlier e-mail on this thread: > >"Also, I would like to propose that we make docsIfUpChannelType a >read-only object for active rows in the Upstream Channel Table. The=20 >value reported would be taken from the modulation profile pointed to by >docsIfUpChannelModulationProfile." > >I'm assuming "active" mean in-service. Otherwise, we have to be careful >with this because the channelType is used to verify things like=20 >channelWidth and whether or not setting of the scdma-specific=20 >parameters is allowed. Along the same lines, if setting the upstream=20 >modulation profile index implies that the SNMP agent changes the=20 >upChannelType to match the modProfChannelType, then the agent must also >verify that all of the other parameters in the upstream channel are >compatible with the possibly new channel type. > >David > > >"Greg White" > >10/08/2003 04:12 PM > To: "Minnie Lu" > cc: , "DOCSIS OSS Majordomo List"=20 > , ,=20 >, > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > > >Minnie, > >I didn't want to prevent a user from changing their mind regarding=20 >channel type when creating a new modulation profile. Suppose you=20 >started out setting channel type to atdma and, after completing a few=20 >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make=20 >you start from scratch (or do a simultaneous set across all IUCs), you=20 >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List;=20 >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Hi, Greg, > >Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is=20 >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the >modulation profile is not assigned to any upstreams. So the error=20 >could be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of=20 >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which=20 > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements > >to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by=20 > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please=20 > >review >the > >attached proposal and provide comments. > > > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White;=20 > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same=20 > >issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path=20 > > of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or=20 > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with=20 > > other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , ,=20 > > , > > > "DOCSIS OSS Majordomo List" , "Owner=20 > > DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I=20 > > >think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same=20 > > >ModChannelType. Also, based on the exchange here it seems that=20 > > >there >is > > >some support for the additional restriction that UpChannelType and=20 > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the=20 > > >specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change=20 > > >UpChannelType to match ModChannelType whenever=20 > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the=20 > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be=20 > > >made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about=20 > >the case that some modulation profile is used by some upstream=20 > >channel, and user change the modulation profile channel type ? Does=20 > >it mean that >the > >upstream channel type would be changed automatically, too ? If yes,=20 > >I >am > >afraid that there might be some user who forget the modulation=20 > >profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The=20 > >modulation profile channel type and upstream channel type are in two=20 > >different MIB tables. > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type=20 > >be changed ? Maybe this is a confusing point which needs to be=20 > >clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles=20 > > >to upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the=20 > > >consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation=20 > > >profile entries with the same docsIfCmtsModIndex will have to have=20 > > >the same docsIfCmtsModChannelType. Otherwise, you would not be able > > >to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid,=20 > > >no >? > > >The way to patch it up would be to make all of the IUCs=20 > > >tdmaAndAtdma, correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is=20 > > >correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used=20 > > >with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29=20 > > >and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and=20 > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2.=20 > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV=20 > > >5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type=20 > > >29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List" > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for=20 > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects=20 > > > > docsIfCmtsModByteInterleaverBlockSize and=20 > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to=20 > > > > see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for=20 > > > > modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma=20 > > > > for modulation profiles that could not be met with a pair of=20 > > > > tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we=20 > > > > could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a=20 > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line=20 > > > >of thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations.=20 > > > >Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs=20 > > > >1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of=20 > > > >having >the > > > >MIB reporting something that doesn't exactly reflect what is=20 > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the=20 > > > >modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data=20 > > > > for consistency. Furthermore, it would seem possible to compare=20 > > > > the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of=20 > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > > > > _______________________________________________ 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 Fri Oct 10 14:24:27 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 OAA10856 for ; Fri, 10 Oct 2003 14:24:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81vo-00081h-5t for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 14:24:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AIO4Pn030847 for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 14:24:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81vk-000811-VR; Fri, 10 Oct 2003 14:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81up-0007uC-KS for ipcdn@optimus.ietf.org; Fri, 10 Oct 2003 14:23:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10752 for ; Fri, 10 Oct 2003 14:22:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81ui-0007Fn-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 14:22:56 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A81ug-0007FY-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 14:22:54 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9AILd10002440; Fri, 10 Oct 2003 12:21:39 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Date: Fri, 10 Oct 2003 12:21:39 -0600 Message-ID: Thread-Topic: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcOOktBv0hn4SqViTae2STkl2UxTNwABYoEwAAWCS7AABY6OcAAcphSwAADDo1AABFhoUAACTZvgAAGMJFA= From: "Eduardo Cardona" To: "Dan Rice @ Stargus" , "Greg White" , "Minnie Lu" , Cc: "DOCSIS OSS Majordomo List" , , , , "Owner DOCSIS OSS Majordomo List" 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 Greg,=20 some comments In my email, my conclusions were Summary of possible edits: No RowStatus for 'real' ifIndex associated entries (see below) Explicitly say cloneFrom update values in created entry from pointed entry -> Agree with you to Clean the CloneFrom Definition, as "cloning : transfer values from active to cloned"=20 Not changing current "cloneFrom object. =20 from Dan's comments, that's the Mngmt system approach (deterministic)=20 The cloneFrom is more as you said experiments, lab testing, vendor testing, ( human friendly, if a,b,c=20 needs to be replaced for a,b1,c, then update only b1) Mngmt systems should imply that first object to set is CloneFrom Implicitly. And Dan is comfortable with that, other vendors might chime on that.=20 =20 Edo wrote: To avoid that, I would think that RowStatus object is not instantiated for "real" mapped entries by ifIndex. Leaving ifAdminStatus the complete activation/de-activation of entries. Or 'always' report 'active' regardless of the IfOperStatus, Would be good to clear that. Isn't the description text for UpChannelStatus clear enough on this?=20 RowStatus Says=20 The following restrictions apply to this object: 1) This object must contain a value of active(1) for active rows. "active rows" is in-service? In other words ifOperStatus =3D 'up'? Or non-cloning rows? ifOperstatus =3D any value- (all ifindex associated UpChannel) Specially active(1) for active rows, is a loos definition I believe. What I was looking at was to separate in clear any possible dependency of ifOperStatus=20 I will think 'real' regardless of the ifOperStatus,=20 I believe would make sense to set the "Update" object and reject the set regardless if the interface is up/down (CMTS rules based on templates of UpCh/Prof capabilities) that way if set 'up' later it won't fail start again Text could be clarify as : =20 docsIfUpChannelStatus=20 ..... The following restrictions apply to this object: 1) This object must contain a value of active(1) for active rows regardless of its ifOperStatus. =20 Implementers will understand that there is no link in a UPChannel 'active' row with the current operational status=20 Cloned entries ( not associated with ifIndex value ) have no ifOperStatus. Will imply all verifications are done regardless of the up/down state of the interface. -----Original Message----- From: Dan Rice @ Stargus=20 Sent: Friday, October 10, 2003 11:47 AM To: Greg White; Eduardo Cardona; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Agreements and my preferences below -----Original Message----- From: Greg White [mailto:g.white@CableLabs.com]=20 Sent: Friday, October 10, 2003 12:48 PM To: Eduardo Cardona; Dan Rice; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) 3 comments in-line. -----Original Message----- From: Eduardo Cardona=20 Sent: Friday, October 10, 2003 9:33 AM To: Dan Rice @ Stargus; Greg White; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Dan,=20 That's a very good point, Currently is up to de Vendor for non-SCDMA, I think we did not finish the discussion about that last time. I have always been uncomfortable with the descriptions referring to SCDMA only. I don't see any real benefit for the vendor in only supporting this feature for rows that have a channel type of SCDMA, and even if they did, how would they handle changes to/from SCDMA mode? I would very much be in favor of cleaning up those definitions to remove the references to SCDMA and the text making support optional for non-SCDMA rows. [DJR] Great this was issue 6, may need an ecr also? Also, The "active" (a mix with RowStatus 'active' but not necessarily linked to ifAdmin/OperStatus) was initially though to be the entries associated to real physical US ports. The row Status was intended for Clonning process,=20 as we know RFC 2670 did not have RowStatus; and for "active", now RowStatus may have ramifications with RowStatus values not really defined, like 'notReady' and the connotations of ifAdminStatus, ifOperStatus that are the currently used,=20 To avoid that, I would think that RowStatus object is not instantiated for "real" mapped entries by ifIndex. Leaving ifAdminStatus the complete activation/de-activation of entries. Or 'always' report 'active' regardless of the IfOperStatus, Would be good to clear that. Isn't the description text for UpChannelStatus clear enough on this?=20 [DJR] I believe this was clear. The clonning entry, will be the simulation bench to tuning the values, Will explode the Whole range of RowStatus 'notReady' After creation will indicates the US Channel/Mod profile setup is not right. 'notInService' all parameters are consistent and can be turn via Update object to the cloned interface. =20 Also one thing that could be sticky=20 "CloneFrom" object is the pointer to later transfer the values. Alas "CopyTo" I may be wrong but just by name references when CloneFrom is set, (as a clonning process) will copy values of pointed entry to created entry,=20 Currently CloneFrom object does not say that. But I believe it does not limit implementers to think on that, I agree, I was surprised to see that there is no mention of what operation takes place upon setting CloneFrom. The name certainly implies (and was the intention I believe) that setting CloneFrom copied all of the entries from the referenced 'active' row, which implies that it is the first object to set after row creation. I'd rather clean up the description to match that intent, rather than change the object to 'CopyTo'. I don't think 'CopyTo' would really be more efficient than 'CloneFrom' for an automated NMS. The only efficiency lost would be having the CMTS copy 60-odd bytes from one memory location to another only to potentially have them overwritten by the NMS. If these operations were happening on millisecond timescales I would be concerned, but this is more like a once-a-day, once-a-month, once-a-year type operation. Let's keep the changes simple and just update the description to match the object name and the original intent. [DJR] I am not sure that this entry is super useful for most applications besides experimenting in the lab. I think if this entry just identified the active row you would be changing as opposed to creating a template for one to tweak that would be more effective. I think a management system would first create a new mod profile, then create a clone row including all relevant entries from upstream channel table, enter the upstream index it is intended to change and then commit it with UpChannelUpdate assuming all columns in the upstream channel would be applied in a single commit. I think it is a little waste of time to copy the current values when you are going to overwrite them all anyway. In addition it makes this 3 transactions instead of 2. I could live with it, but not sure I need it Just to make sure the object does always the same think A) Clonning process semantics=20 - after createAndWait the first object to set is CloneFrom (copy parameters into clonning entry) - It Might be clarified in the object - - Adjust objects values - Set update object to 'true' will success if: =20 before set, RowStatus was 'notInService',=20 and no other error condition is raised by CMTS for the set=20 B) Copy Process (CopyTo) - After createAndWait set arbitrary objects , setting object CloneFrom does NOT transfer=20 parameters from pointed entry to created entry - Set update object to 'true' will success if: =20 before set, RowStatus was 'notInService',=20 and no other error condition is raised by CMTS for the set Being specific will clear a little bit the process in the user/system thinking doing B) - CMTS does A) - and loosing previous sets if object "CloneFrom" is set after some others.=20 A) is User friendly ( few Sets) B) is autonomous system efficient, -algorithms always calculates all 'optimal' parameters, so might not need to initialize previous setups but should be aware of setting first=20 For the object Name ( something we might not want to change at this state) I believe A) is the precisely even though I would prefer 1 but the correct name should be "CopyTo" Summary of possible edits: No RowStatus for 'real' ifIndex associated entries Explicitly say cloneFrom update values in created entry from pointed entry Let me know any comments Eduardo -----Original Message----- From: Dan Rice @ Stargus=20 Sent: Friday, October 10, 2003 8:17 AM To: Eduardo Cardona; Greg White; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) For my $0.02 I would prefer just having the clone mechanism. Even within the upstream channel parameters you must change things in the right order for them to be correct if you do it while row is active. This is not just an UpChannelType issue. For example setting a minislot size before changing the symbol rate can result in some situations that CMTSs today will reject. If you reduce the minislot size before increasing symbol rate, you could no longer send a max packet. I think if we made the clone method mandatory for both TDMA and SCDMA and changed the descriptions to be this way than I would be happy because there is now a deterministic way to make changes and commit them. Today in most deployed CMTSs its hard to know how many UCD changes occur when you make changes to upstream channel today. It seems to depend on vendor. When all you are really shooting for is an end result this seems the safest and most deterministic route to me. =20 I think that many of the cases of making changes to active modulation profiles and upstream channel settings can make things a little funny if the commit isn't very defined. If there are requirements for support of enough modulation table entries and enough clone rows to accommodate an active and notInService for each upstream interface this could be a lot cleaner. Any change that is made is done by creating a new complete modulation profile (even if its just changing one value, I imagine most of this will done through software as opposed to hand editing) then creating a clone upstream channel table entry with pointer to this new mod profile and associated upstream channel settings, then commit the changes. Additionally it would be nice to have the same functionality in the downstream channel table to be consistent. For example it would be nice to commit modulation and interleave settings at the same time. -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com]=20 Sent: Thursday, October 09, 2003 8:37 PM To: Greg White; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) I agree that turning off is not desired for in-service if the changes are not incremental or very drastic changes, I did not enforce the "at maximum" word in both cases (actually I only used that in the second example). It might be some cases where the interface or implementations definitely have to be turn off, but will be on maintenance windows, (season changes -?- school calendar, long weekend?, maintenance measurements.) very uncommon or at knowledge of consequences by MSOs. I agree that the primarily intention is minimum service disruption primarily for spectrum management when changes might be incremental in robustness parameters or phy channel parameters.=20 And as Greg said, one shot change if moving channel from profile A to B. and seems to me that changes in profile should be compatible to the current channel PHY and ulterior modification of the channel will be also, the only problem as today is the double location of ChannelType=20 Eduardo -----Original Message----- From: Greg White=20 Sent: Thursday, October 09, 2003 4:31 PM To: Eduardo Cardona; 'Minnie Lu'; 'David.White@arrisi.com' Cc: DOCSIS OSS Majordomo List; 'Greg.Gohman@arrisi.com'; 'ipcdn@ietf.org'; 'Larry.Spaete@arrisi.com'; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) So, first off, there are a number of parameters that must be consistent across the two tables for the configuration to be valid, and the active rows in the UpChannelTable *always* have to be valid. The only possible exception to this would be if the interface were turned down before the changes were made, but I don't think that is an operationally useful scenario to consider, and some (all?) vendors might want to enforce validity even in that case. Any active row in the UpChannelTable will be populated by consistent defaults or stored values when the CMTS is booted, so we only need to consider *changes* to those rows (i.e. they can't be created from scratch and so would never have to be populated one-object-at-a-time). Any change to an active row can be done by two methods: direct change & cloning. When a change is made directly, the validation occurs immediately upon receiving the snmp set. When using the cloning mechanism, the validation only occurs when the ChannelUpdate object is set true. This proposal does not change either of those aspects. It only enforces that UpChannelModulationProfile and UpChannelType are guaranteed to be consistent with each other. The whole point of the cloning mechanism was to have a temporary "scratch" area where an operator could manipulate the values without having the constraint that they are consistent at every step. Thus the consistency verification is only done upon ChannelUpdate. I don't think that the steps Eduardo suggested are valid, setting ModulationProfile to '0' on an active row would seem to make the channel unusable, no? Setting ModulationProfile to '0' on an inactive row wouldn't be necessary since there is no consistency checking. Let me know if I'm completely missing the boat here.... -Greg -----Original Message----- From: Eduardo Cardona=20 Sent: Thursday, October 09, 2003 1:38 PM To: 'Minnie Lu'; David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi David, Minnie,=20 Greg may have other comments. I think the idea was to define one clear way of configuration rather than finding possible broken paths The idea was to pass the role of The UpChannel parameters vs ChannelType verification to one trigger, the docsIfUpChannelModulationProfile so it verifies that all the channelTypes are the same (in the mod profile) All Modulation Parameters are consistent in into their own IUC [ can be done also as user change an IUC itself -invalid value for that particulat CMTS-, etc] Then as the Type is knew from the profile verifies that the ChannelType is compatible with the UpChannel parameters, if fails nothing haven change or undo-commit.=20 The point is that UpChannel to ModulationProfile is one-to-many so going in that path eventually the user won't break the Profile that works for other UpChannels and instead maybe create a one-to-one UpChannel-to-ModulationProfile ( by creating a new Profile) In the current UpChannelChanelType read-create we have, implies UpChannelModProfile and ChannelType might need to be modified simultaneously or: 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelType to 'x' and=20 -verify Chnnl- 4 UpChannelModulationProfile to 'y' -verify Chnnl UpCh/ModProfile-=20 if failed start again from 1 With the proposal at maximum ( channelType RO) would be =20 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelModulationProfile to 'y' - do all verifications chnnl/ModProf- =20 if failed redo 2, maybe adjust ModulationProfileTable and 3) Are there any other updated paths to consider for simplified setup, other sequence?=20 Or maybe be more details in the sequence for the objects ? Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Thursday, October 09, 2003 12:25 PM To: David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, David, Your concern sounds very valid. Then it seems to me that 1. either have docsIfUpChannelType is read-only and ask the=20 docsIfUpChannelModulationProfile must be assigned first before setting=20 other upstream attributes. For this is one, I don't know user would like=20 it or not. 2. or we still need to keep the docsIfUpChannelType is read-create, so it=20 can be used to check other upstream attributes consistence without having=20 an modulation profile assigned. The user must make sure both=20 docsIfUpChannelModulationProfile and docsIfUpChannelType are the same when=20 trying to set either one of them if docsIfUpChannelModulationProfile is not=20 value 0. If they are not consistent, the set will fail. Any more possible solution ? Just some more thoughts. Thanks a lot ! Minnie At 11:35 AM 10/9/2003 -0400, David.White@arrisi.com wrote: >Greg, > The main problem I have with this is that it forces the CMTS=20 >to postpone data checking until possibly the very end when the=20 >modulation profile is finally assigned. That is, the user may get a=20 >wrongValue or inconsistentValue while attempting to set the modulation >profile because one or more already-set parameters do not agree with=20 >the ModChannelType. What I liked about having the UpChannelType being=20 >a configurable and "active" (rather than passive) object is that the=20 >CMTS verify things like ChannelWidth, SlotSize, and the Scdma=20 >parameters as they are being set. Thus, the error is immediate and=20 >pertitent. > >However, what I like about your proposal is that it makes it easier to >transition an upstream channel from tdma, atdma, and tdmaAndAtdma=20 >without having to change both the modulation profile and UpChannelType=20 >at the same time. > >I'm not rejecting your proposal, but just wanted to voice my concerns. > >Thanks, >David > > > >"Greg White" >Sent by: owner-docsis-oss@cablelabs.com > >10/08/2003 07:35 PM > > To: > cc: "DOCSIS OSS Majordomo List"=20 > , ,=20 > , , "Minnie Lu"=20 > > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > >David, > >According to the proposed text, docsIfUpChannelType would be read-only=20 >for ALL rows. > >For "active" rows (docsIfUpChannelStatus =3D active(1)) setting >UpChannelModulationProfile would return an error if the channel type of >the profile does not work with the other parameters in the row. > >For "cloned" rows (docsIfUpChannelStatus =3D notInService(2)) no >verification is done on consistency of parameters until=20 >docsIfUpChannelUpdate is set to true. > >The verification for active rows is indicated in the proposed text for >UpChannelModulationProfile, although it looks like it could be >clarified: > > Setting this object on an "active" row MUST return an=20 > error if the following > conditions are not satisfied: > 1. All the IUC entries in the selected modulation profile > MUST have the same value of docsIfCmtsModChannelType. > 2. All of the modulation parameters in the selected > modulation profile MUST be consistent with the other > parameters in this docsIfUpChannelEntry. > >Does that address your concern? > >-Greg > >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Wednesday, October 08, 2003 3:11 PM >To: Greg White >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; >Larry.Spaete@arrisi.com; Minnie Lu >Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for=20 >assigning modulation profiles to upstream channels) > > >Greg, > Per your earlier e-mail on this thread: > >"Also, I would like to propose that we make docsIfUpChannelType a=20 >read-only object for active rows in the Upstream Channel Table. The=20 >value reported would be taken from the modulation profile pointed to by >docsIfUpChannelModulationProfile." > >I'm assuming "active" mean in-service. Otherwise, we have to be careful >with this because the channelType is used to verify things like >channelWidth and whether or not setting of the scdma-specific=20 >parameters is allowed. Along the same lines, if setting the upstream=20 >modulation profile index implies that the SNMP agent changes the=20 >upChannelType to match the modProfChannelType, then the agent must also >verify that all of the other parameters in the upstream channel are=20 >compatible with the possibly new channel type. > >David > > >"Greg White" > >10/08/2003 04:12 PM > To: "Minnie Lu" > cc: , "DOCSIS OSS Majordomo List"=20 > , , >, > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > > >Minnie, > >I didn't want to prevent a user from changing their mind regarding >channel type when creating a new modulation profile. Suppose you=20 >started out setting channel type to atdma and, after completing a few=20 >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make=20 >you start from scratch (or do a simultaneous set across all IUCs), you=20 >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Hi, Greg, > >Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the=20 >modulation profile is not assigned to any upstreams. So the error=20 >could be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements=20 > >to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please > >review >the > >attached proposal and provide comments. > > > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same > >issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path > > of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with > > other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , , > > , > > > "DOCSIS OSS Majordomo List" , "Owner > > DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I > > >think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same > > >ModChannelType. Also, based on the exchange here it seems that=20 > > >there >is > > >some support for the additional restriction that UpChannelType and > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the > > >specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change > > >UpChannelType to match ModChannelType whenever=20 > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be > > >made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about > >the case that some modulation profile is used by some upstream=20 > >channel, and user change the modulation profile channel type ? Does=20 > >it mean that >the > >upstream channel type would be changed automatically, too ? If yes, > >I >am > >afraid that there might be some user who forget the modulation > >profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The > >modulation profile channel type and upstream channel type are in two=20 > >different MIB tables. > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type > >be changed ? Maybe this is a confusing point which needs to be=20 > >clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles > > >to upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the > > >consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation > > >profile entries with the same docsIfCmtsModIndex will have to have=20 > > >the same docsIfCmtsModChannelType. Otherwise, you would not be able > > >to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid, > > >no >? > > >The way to patch it up would be to make all of the IUCs > > >tdmaAndAtdma, correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is > > >correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used > > >with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 > > >and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV=20 > > >5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type > > >29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List" > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects > > > > docsIfCmtsModByteInterleaverBlockSize and=20 > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to > > > > see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for > > > > modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma > > > > for modulation profiles that could not be met with a pair of=20 > > > > tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we > > > > could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line > > > >of thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations. > > > >Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs > > > >1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of > > > >having >the > > > >MIB reporting something that doesn't exactly reflect what is > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the > > > >modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data > > > > for consistency. Furthermore, it would seem possible to compare=20 > > > > the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > > > > _______________________________________________ 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 Fri Oct 10 16:04:28 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 QAA18963 for ; Fri, 10 Oct 2003 16:04:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83UZ-0008QN-C6 for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 16:04:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AK431H032377 for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 16:04:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83UX-0008Pu-D1; Fri, 10 Oct 2003 16:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83UG-0008Lg-8a for ipcdn@optimus.ietf.org; Fri, 10 Oct 2003 16:03:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18869 for ; Fri, 10 Oct 2003 16:03:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83U9-0001SB-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 16:03:37 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A83U7-0001Pf-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 16:03:35 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9AK2N10012009; Fri, 10 Oct 2003 14:02:23 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Date: Fri, 10 Oct 2003 14:02:22 -0600 Message-ID: Thread-Topic: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcOOktBv0hn4SqViTae2STkl2UxTNwABYoEwAAWCS7AABY6OcAAcphSwAADDo1AABFhoUAACTZvgAAGMJFAAA1AvsA== From: "Greg White" To: "Eduardo Cardona" , "Dan Rice @ Stargus" , "Minnie Lu" , Cc: "DOCSIS OSS Majordomo List" , , , 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 Regarding UpChannelStatus for 'active' rows, there is also the following statement: 4) A status transition from active (1) to destroy (6) is=20 not permitted. Entries with docsIfUpChannelStatus set=20 to active(1) are logically linked to a physical=20 interface, not temporarily created to clone parameters.=20 The Interface MIB [RFC2863] ifAdminStatus should be used to take an Upstream Channel offline.=20 That is what I was referring to. Perhaps it could be improved to say "A status transition from active(1) to notInService(2) or destroy(6) is not permitted." I agree that "... must contain a value of active(1) for active rows." is not a very good, and is probably a circular, definition. -Greg -----Original Message----- From: Eduardo Cardona=20 Sent: Friday, October 10, 2003 12:22 PM To: Dan Rice @ Stargus; Greg White; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Greg,=20 some comments In my email, my conclusions were Summary of possible edits: No RowStatus for 'real' ifIndex associated entries (see below) Explicitly say cloneFrom update values in created entry from pointed entry -> Agree with you to Clean the CloneFrom Definition, as "cloning : transfer values from active to cloned"=20 Not changing current "cloneFrom object. =20 from Dan's comments, that's the Mngmt system approach (deterministic)=20 The cloneFrom is more as you said experiments, lab testing, vendor testing, ( human friendly, if a,b,c=20 needs to be replaced for a,b1,c, then update only b1) Mngmt systems should imply that first object to set is CloneFrom Implicitly. And Dan is comfortable with that, other vendors might chime on that.=20 =20 Edo wrote: To avoid that, I would think that RowStatus object is not instantiated for "real" mapped entries by ifIndex. Leaving ifAdminStatus the complete activation/de-activation of entries. Or 'always' report 'active' regardless of the IfOperStatus, Would be good to clear that. Isn't the description text for UpChannelStatus clear enough on this?=20 RowStatus Says=20 The following restrictions apply to this object: 1) This object must contain a value of active(1) for active rows. "active rows" is in-service? In other words ifOperStatus =3D 'up'? Or non-cloning rows? ifOperstatus =3D any value- (all ifindex associated UpChannel) Specially active(1) for active rows, is a loos definition I believe. What I was looking at was to separate in clear any possible dependency of ifOperStatus=20 I will think 'real' regardless of the ifOperStatus,=20 I believe would make sense to set the "Update" object and reject the set regardless if the interface is up/down (CMTS rules based on templates of UpCh/Prof capabilities) that way if set 'up' later it won't fail start again Text could be clarify as : =20 docsIfUpChannelStatus=20 ..... The following restrictions apply to this object: 1) This object must contain a value of active(1) for active rows regardless of its ifOperStatus. =20 Implementers will understand that there is no link in a UPChannel 'active' row with the current operational status=20 Cloned entries ( not associated with ifIndex value ) have no ifOperStatus. Will imply all verifications are done regardless of the up/down state of the interface. -----Original Message----- From: Dan Rice @ Stargus=20 Sent: Friday, October 10, 2003 11:47 AM To: Greg White; Eduardo Cardona; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Agreements and my preferences below -----Original Message----- From: Greg White [mailto:g.white@CableLabs.com]=20 Sent: Friday, October 10, 2003 12:48 PM To: Eduardo Cardona; Dan Rice; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) 3 comments in-line. -----Original Message----- From: Eduardo Cardona=20 Sent: Friday, October 10, 2003 9:33 AM To: Dan Rice @ Stargus; Greg White; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Dan,=20 That's a very good point, Currently is up to de Vendor for non-SCDMA, I think we did not finish the discussion about that last time. I have always been uncomfortable with the descriptions referring to SCDMA only. I don't see any real benefit for the vendor in only supporting this feature for rows that have a channel type of SCDMA, and even if they did, how would they handle changes to/from SCDMA mode? I would very much be in favor of cleaning up those definitions to remove the references to SCDMA and the text making support optional for non-SCDMA rows. [DJR] Great this was issue 6, may need an ecr also? Also, The "active" (a mix with RowStatus 'active' but not necessarily linked to ifAdmin/OperStatus) was initially though to be the entries associated to real physical US ports. The row Status was intended for Clonning process,=20 as we know RFC 2670 did not have RowStatus; and for "active", now RowStatus may have ramifications with RowStatus values not really defined, like 'notReady' and the connotations of ifAdminStatus, ifOperStatus that are the currently used,=20 To avoid that, I would think that RowStatus object is not instantiated for "real" mapped entries by ifIndex. Leaving ifAdminStatus the complete activation/de-activation of entries. Or 'always' report 'active' regardless of the IfOperStatus, Would be good to clear that. Isn't the description text for UpChannelStatus clear enough on this?=20 [DJR] I believe this was clear. The clonning entry, will be the simulation bench to tuning the values, Will explode the Whole range of RowStatus 'notReady' After creation will indicates the US Channel/Mod profile setup is not right. 'notInService' all parameters are consistent and can be turn via Update object to the cloned interface. =20 Also one thing that could be sticky=20 "CloneFrom" object is the pointer to later transfer the values. Alas "CopyTo" I may be wrong but just by name references when CloneFrom is set, (as a clonning process) will copy values of pointed entry to created entry,=20 Currently CloneFrom object does not say that. But I believe it does not limit implementers to think on that, I agree, I was surprised to see that there is no mention of what operation takes place upon setting CloneFrom. The name certainly implies (and was the intention I believe) that setting CloneFrom copied all of the entries from the referenced 'active' row, which implies that it is the first object to set after row creation. I'd rather clean up the description to match that intent, rather than change the object to 'CopyTo'. I don't think 'CopyTo' would really be more efficient than 'CloneFrom' for an automated NMS. The only efficiency lost would be having the CMTS copy 60-odd bytes from one memory location to another only to potentially have them overwritten by the NMS. If these operations were happening on millisecond timescales I would be concerned, but this is more like a once-a-day, once-a-month, once-a-year type operation. Let's keep the changes simple and just update the description to match the object name and the original intent. [DJR] I am not sure that this entry is super useful for most applications besides experimenting in the lab. I think if this entry just identified the active row you would be changing as opposed to creating a template for one to tweak that would be more effective. I think a management system would first create a new mod profile, then create a clone row including all relevant entries from upstream channel table, enter the upstream index it is intended to change and then commit it with UpChannelUpdate assuming all columns in the upstream channel would be applied in a single commit. I think it is a little waste of time to copy the current values when you are going to overwrite them all anyway. In addition it makes this 3 transactions instead of 2. I could live with it, but not sure I need it Just to make sure the object does always the same think A) Clonning process semantics=20 - after createAndWait the first object to set is CloneFrom (copy parameters into clonning entry) - It Might be clarified in the object - - Adjust objects values - Set update object to 'true' will success if: =20 before set, RowStatus was 'notInService',=20 and no other error condition is raised by CMTS for the set=20 B) Copy Process (CopyTo) - After createAndWait set arbitrary objects , setting object CloneFrom does NOT transfer=20 parameters from pointed entry to created entry - Set update object to 'true' will success if: =20 before set, RowStatus was 'notInService',=20 and no other error condition is raised by CMTS for the set Being specific will clear a little bit the process in the user/system thinking doing B) - CMTS does A) - and loosing previous sets if object "CloneFrom" is set after some others.=20 A) is User friendly ( few Sets) B) is autonomous system efficient, -algorithms always calculates all 'optimal' parameters, so might not need to initialize previous setups but should be aware of setting first=20 For the object Name ( something we might not want to change at this state) I believe A) is the precisely even though I would prefer 1 but the correct name should be "CopyTo" Summary of possible edits: No RowStatus for 'real' ifIndex associated entries Explicitly say cloneFrom update values in created entry from pointed entry Let me know any comments Eduardo -----Original Message----- From: Dan Rice @ Stargus=20 Sent: Friday, October 10, 2003 8:17 AM To: Eduardo Cardona; Greg White; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) For my $0.02 I would prefer just having the clone mechanism. Even within the upstream channel parameters you must change things in the right order for them to be correct if you do it while row is active. This is not just an UpChannelType issue. For example setting a minislot size before changing the symbol rate can result in some situations that CMTSs today will reject. If you reduce the minislot size before increasing symbol rate, you could no longer send a max packet. I think if we made the clone method mandatory for both TDMA and SCDMA and changed the descriptions to be this way than I would be happy because there is now a deterministic way to make changes and commit them. Today in most deployed CMTSs its hard to know how many UCD changes occur when you make changes to upstream channel today. It seems to depend on vendor. When all you are really shooting for is an end result this seems the safest and most deterministic route to me. =20 I think that many of the cases of making changes to active modulation profiles and upstream channel settings can make things a little funny if the commit isn't very defined. If there are requirements for support of enough modulation table entries and enough clone rows to accommodate an active and notInService for each upstream interface this could be a lot cleaner. Any change that is made is done by creating a new complete modulation profile (even if its just changing one value, I imagine most of this will done through software as opposed to hand editing) then creating a clone upstream channel table entry with pointer to this new mod profile and associated upstream channel settings, then commit the changes. Additionally it would be nice to have the same functionality in the downstream channel table to be consistent. For example it would be nice to commit modulation and interleave settings at the same time. -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com]=20 Sent: Thursday, October 09, 2003 8:37 PM To: Greg White; Minnie Lu; David.White@arrisi.com Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) I agree that turning off is not desired for in-service if the changes are not incremental or very drastic changes, I did not enforce the "at maximum" word in both cases (actually I only used that in the second example). It might be some cases where the interface or implementations definitely have to be turn off, but will be on maintenance windows, (season changes -?- school calendar, long weekend?, maintenance measurements.) very uncommon or at knowledge of consequences by MSOs. I agree that the primarily intention is minimum service disruption primarily for spectrum management when changes might be incremental in robustness parameters or phy channel parameters.=20 And as Greg said, one shot change if moving channel from profile A to B. and seems to me that changes in profile should be compatible to the current channel PHY and ulterior modification of the channel will be also, the only problem as today is the double location of ChannelType=20 Eduardo -----Original Message----- From: Greg White=20 Sent: Thursday, October 09, 2003 4:31 PM To: Eduardo Cardona; 'Minnie Lu'; 'David.White@arrisi.com' Cc: DOCSIS OSS Majordomo List; 'Greg.Gohman@arrisi.com'; 'ipcdn@ietf.org'; 'Larry.Spaete@arrisi.com'; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) So, first off, there are a number of parameters that must be consistent across the two tables for the configuration to be valid, and the active rows in the UpChannelTable *always* have to be valid. The only possible exception to this would be if the interface were turned down before the changes were made, but I don't think that is an operationally useful scenario to consider, and some (all?) vendors might want to enforce validity even in that case. Any active row in the UpChannelTable will be populated by consistent defaults or stored values when the CMTS is booted, so we only need to consider *changes* to those rows (i.e. they can't be created from scratch and so would never have to be populated one-object-at-a-time). Any change to an active row can be done by two methods: direct change & cloning. When a change is made directly, the validation occurs immediately upon receiving the snmp set. When using the cloning mechanism, the validation only occurs when the ChannelUpdate object is set true. This proposal does not change either of those aspects. It only enforces that UpChannelModulationProfile and UpChannelType are guaranteed to be consistent with each other. The whole point of the cloning mechanism was to have a temporary "scratch" area where an operator could manipulate the values without having the constraint that they are consistent at every step. Thus the consistency verification is only done upon ChannelUpdate. I don't think that the steps Eduardo suggested are valid, setting ModulationProfile to '0' on an active row would seem to make the channel unusable, no? Setting ModulationProfile to '0' on an inactive row wouldn't be necessary since there is no consistency checking. Let me know if I'm completely missing the boat here.... -Greg -----Original Message----- From: Eduardo Cardona=20 Sent: Thursday, October 09, 2003 1:38 PM To: 'Minnie Lu'; David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi David, Minnie,=20 Greg may have other comments. I think the idea was to define one clear way of configuration rather than finding possible broken paths The idea was to pass the role of The UpChannel parameters vs ChannelType verification to one trigger, the docsIfUpChannelModulationProfile so it verifies that all the channelTypes are the same (in the mod profile) All Modulation Parameters are consistent in into their own IUC [ can be done also as user change an IUC itself -invalid value for that particulat CMTS-, etc] Then as the Type is knew from the profile verifies that the ChannelType is compatible with the UpChannel parameters, if fails nothing haven change or undo-commit.=20 The point is that UpChannel to ModulationProfile is one-to-many so going in that path eventually the user won't break the Profile that works for other UpChannels and instead maybe create a one-to-one UpChannel-to-ModulationProfile ( by creating a new Profile) In the current UpChannelChanelType read-create we have, implies UpChannelModProfile and ChannelType might need to be modified simultaneously or: 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelType to 'x' and=20 -verify Chnnl- 4 UpChannelModulationProfile to 'y' -verify Chnnl UpCh/ModProfile-=20 if failed start again from 1 With the proposal at maximum ( channelType RO) would be =20 1 UpChannelModProfile to '0' then=20 2 (updates UpChannel Parameters) then=20 3 UpChannelModulationProfile to 'y' - do all verifications chnnl/ModProf- =20 if failed redo 2, maybe adjust ModulationProfileTable and 3) Are there any other updated paths to consider for simplified setup, other sequence?=20 Or maybe be more details in the sequence for the objects ? Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Thursday, October 09, 2003 12:25 PM To: David.White@arrisi.com Cc: Greg White; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, David, Your concern sounds very valid. Then it seems to me that 1. either have docsIfUpChannelType is read-only and ask the=20 docsIfUpChannelModulationProfile must be assigned first before setting=20 other upstream attributes. For this is one, I don't know user would like=20 it or not. 2. or we still need to keep the docsIfUpChannelType is read-create, so it=20 can be used to check other upstream attributes consistence without having=20 an modulation profile assigned. The user must make sure both=20 docsIfUpChannelModulationProfile and docsIfUpChannelType are the same when=20 trying to set either one of them if docsIfUpChannelModulationProfile is not=20 value 0. If they are not consistent, the set will fail. Any more possible solution ? Just some more thoughts. Thanks a lot ! Minnie At 11:35 AM 10/9/2003 -0400, David.White@arrisi.com wrote: >Greg, > The main problem I have with this is that it forces the CMTS >to postpone data checking until possibly the very end when the=20 >modulation profile is finally assigned. That is, the user may get a=20 >wrongValue or inconsistentValue while attempting to set the modulation >profile because one or more already-set parameters do not agree with >the ModChannelType. What I liked about having the UpChannelType being=20 >a configurable and "active" (rather than passive) object is that the=20 >CMTS verify things like ChannelWidth, SlotSize, and the Scdma=20 >parameters as they are being set. Thus, the error is immediate and=20 >pertitent. > >However, what I like about your proposal is that it makes it easier to=20 >transition an upstream channel from tdma, atdma, and tdmaAndAtdma=20 >without having to change both the modulation profile and UpChannelType=20 >at the same time. > >I'm not rejecting your proposal, but just wanted to voice my concerns. > >Thanks, >David > > > >"Greg White" >Sent by: owner-docsis-oss@cablelabs.com > >10/08/2003 07:35 PM > > To: > cc: "DOCSIS OSS Majordomo List"=20 > , , > , , "Minnie Lu"=20 > > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > >David, > >According to the proposed text, docsIfUpChannelType would be read-only >for ALL rows. > >For "active" rows (docsIfUpChannelStatus =3D active(1)) setting=20 >UpChannelModulationProfile would return an error if the channel type of >the profile does not work with the other parameters in the row. > >For "cloned" rows (docsIfUpChannelStatus =3D notInService(2)) no=20 >verification is done on consistency of parameters until=20 >docsIfUpChannelUpdate is set to true. > >The verification for active rows is indicated in the proposed text for=20 >UpChannelModulationProfile, although it looks like it could be >clarified: > > Setting this object on an "active" row MUST return an > error if the following > conditions are not satisfied: > 1. All the IUC entries in the selected modulation profile > MUST have the same value of docsIfCmtsModChannelType. > 2. All of the modulation parameters in the selected > modulation profile MUST be consistent with the other > parameters in this docsIfUpChannelEntry. > >Does that address your concern? > >-Greg > >-----Original Message----- >From: David.White@arrisi.com [mailto:David.White@arrisi.com] >Sent: Wednesday, October 08, 2003 3:11 PM >To: Greg White >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org;=20 >Larry.Spaete@arrisi.com; Minnie Lu >Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Greg, > Per your earlier e-mail on this thread: > >"Also, I would like to propose that we make docsIfUpChannelType a >read-only object for active rows in the Upstream Channel Table. The=20 >value reported would be taken from the modulation profile pointed to by >docsIfUpChannelModulationProfile." > >I'm assuming "active" mean in-service. Otherwise, we have to be careful >with this because the channelType is used to verify things like=20 >channelWidth and whether or not setting of the scdma-specific=20 >parameters is allowed. Along the same lines, if setting the upstream=20 >modulation profile index implies that the SNMP agent changes the=20 >upChannelType to match the modProfChannelType, then the agent must also >verify that all of the other parameters in the upstream channel are >compatible with the possibly new channel type. > >David > > >"Greg White" > >10/08/2003 04:12 PM > To: "Minnie Lu" > cc: , "DOCSIS OSS Majordomo List"=20 > , ,=20 >, > Fax to: > Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0=20 > : rules for assigning modulation profiles to upstream channels) > > > >Minnie, > >I didn't want to prevent a user from changing their mind regarding=20 >channel type when creating a new modulation profile. Suppose you=20 >started out setting channel type to atdma and, after completing a few=20 >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make=20 >you start from scratch (or do a simultaneous set across all IUCs), you=20 >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List;=20 >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for=20 >assigning modulation profiles to upstream channels) > > >Hi, Greg, > >Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is=20 >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the >modulation profile is not assigned to any upstreams. So the error=20 >could be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of=20 >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which=20 > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements > >to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by=20 > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please=20 > >review >the > >attached proposal and provide comments. > > > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White;=20 > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to=20 > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same=20 > >issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path=20 > > of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or=20 > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with=20 > > other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , ,=20 > > , > > > "DOCSIS OSS Majordomo List" , "Owner=20 > > DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I=20 > > >think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same=20 > > >ModChannelType. Also, based on the exchange here it seems that=20 > > >there >is > > >some support for the additional restriction that UpChannelType and=20 > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the=20 > > >specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change=20 > > >UpChannelType to match ModChannelType whenever=20 > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the=20 > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be=20 > > >made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about=20 > >the case that some modulation profile is used by some upstream=20 > >channel, and user change the modulation profile channel type ? Does=20 > >it mean that >the > >upstream channel type would be changed automatically, too ? If yes,=20 > >I >am > >afraid that there might be some user who forget the modulation=20 > >profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The=20 > >modulation profile channel type and upstream channel type are in two=20 > >different MIB tables. > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type=20 > >be changed ? Maybe this is a confusing point which needs to be=20 > >clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles=20 > > >to upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the=20 > > >consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation=20 > > >profile entries with the same docsIfCmtsModIndex will have to have=20 > > >the same docsIfCmtsModChannelType. Otherwise, you would not be able > > >to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid,=20 > > >no >? > > >The way to patch it up would be to make all of the IUCs=20 > > >tdmaAndAtdma, correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is=20 > > >correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used=20 > > >with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29=20 > > >and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and=20 > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2.=20 > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV=20 > > >5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type=20 > > >29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List" > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for=20 > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects=20 > > > > docsIfCmtsModByteInterleaverBlockSize and=20 > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to=20 > > > > see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for=20 > > > > modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma=20 > > > > for modulation profiles that could not be met with a pair of=20 > > > > tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we=20 > > > > could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a=20 > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line=20 > > > >of thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations.=20 > > > >Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs=20 > > > >1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of=20 > > > >having >the > > > >MIB reporting something that doesn't exactly reflect what is=20 > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the=20 > > > >modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data=20 > > > > for consistency. Furthermore, it would seem possible to compare=20 > > > > the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of=20 > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > > > > _______________________________________________ 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 Fri Oct 10 16:35:28 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 QAA21498 for ; Fri, 10 Oct 2003 16:35:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83yc-0002Lb-Ii for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 16:35:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AKZ6xX009020 for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 16:35:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83yY-0002L0-Tj; Fri, 10 Oct 2003 16:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83yP-0002Jr-BX for ipcdn@optimus.ietf.org; Fri, 10 Oct 2003 16:34:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21440 for ; Fri, 10 Oct 2003 16:34:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83yN-0002Gh-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 16:34:51 -0400 Received: from mail.stargus.com ([65.193.169.166]) by ietf-mx with smtp (Exim 4.12) id 1A83yM-0002GL-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 16:34:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Oct 2003 16:31:39 -0400 Message-ID: <344C3B42FD36C54A8BC47A471265DEF001A923@xchange.stargus.com> Thread-Topic: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcOPW31JHKepkZguQZSH9R9K5RMlfAACEfyQ From: "Dan Rice" To: "Minnie Lu" Cc: "Greg White" , , "DOCSIS OSS Majordomo List" , , , 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 Thanks for getting me up to speed. It appears to me that I could still change an element in an active IUC as long as I don't change the docsIfCmtsModChannelType, can you please confirm? Also it says " The maximum number of modulation profiles that a CMTS can support in=20 docsIfCmtsModulationTable is vendor -specific" Would there be resistance to setting a minimum number of modulation profiles that a CMTS MUST support? If not, than something like 2 times the number of upstream interfaces would be more than enough. - Dan -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Friday, October 10, 2003 2:25 PM To: Dan Rice Cc: Greg White; Minnie Lu; David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, Dan, In the original proposal of Greg and Eduardo (also in OSS2-O-03092), there=20 are more rules. Please see Greg and Eduardo's original proposal for more=20 details. Here please allow me to list the ones in OSS2-O-03092. (I added=20 the word 'active' in the first sentence of the original OSS2-O-03092.) All the active entries in a modulation profile (i.e. all active entries=20 that share a common docsIfCmtsModIndex) MUST have the same value of=20 docsIfCmtsModChannelType. When assigning a modulation profile to an=20 upstream channel, the value of docsIfUpChannelType and the value of=20 docsIfCmtsModChannelType MUST match. If a modulation profile is in use by one or more upstream channels, the=20 value of docsIfCmtsModChannelType MUST NOT be changed. Also, if a=20 modulation profile is in use by one or more upstream channels, it MUST NOT=20 be destroyed. Before destroying a modulation profile, or changing the=20 value of docsIfCmtsModChannelType for a profile, the user will need to=20 ensure that it is not currently in use by any upstream channel. The maximum number of modulation profiles that a CMTS can support in=20 docsIfCmtsModulationTable is vendor -specific. Now we are discussing how and when to enforce it as cleaner and easier way. Thanks! Minnie At 01:26 PM 10/10/2003 -0400, Dan Rice wrote: >-----Original Message----- >From: Greg White [mailto:g.white@CableLabs.com] >Sent: Friday, October 10, 2003 12:56 PM >To: Dan Rice; Minnie Lu >Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : >rules for assigning modulation profiles to upstream channels) > >What I had interpreted Minnie's suggestion to be was that ChannelType >consistency was enforced across all modulation profile rows with a >Status of 'active', regardless of whether they were assigned to an >upstream channel or not. Setting Status to 'notInService' is not >allowed for propfiles assigned to an upstream channel, nor is changing >ChannelType. > >So, the operation Minnie suggested only applies to profiles that have >been created and set 'active', but are not assigned to any upstream >channel. > >Does that clarify? >[DJR] Yes that sounds good. Thank You Greg >Can I also extend your answer to infer one or both of the following: > > 1) Changing of the channel type is not allowed for any set of >iuc rows while their modulation profile is assigned to an active >upstream channel. > 2) Changing any of the modulation profile attributes is not >allowed while it is assigned to an active upstream channel? > >-Greg > > >-----Original Message----- >From: Dan Rice @ Stargus >Sent: Friday, October 10, 2003 7:59 AM >To: Greg White; Minnie Lu >Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : >rules for assigning modulation profiles to upstream channels) > > >Sorry for chiming in 11th hour, but want to make sure I understand >minnie's suggestion for active entries. I believe the suggestion is >that for active entries you change the row status to not in service. >What would we expect to happen to the upstream currently assigned this >modulation profile while it is notInService? Would the existing active >assignment continue to be valid for the upstream using it until all IUC >rows became active again with the changes in them? > >Also if the changes are to docsIfCmtsModChannelType wouldn't you have to >edit all IUC rows before checking to see if this is valid? I guess when >you started going in and making each IUC active that would be the point >to check it? Could you guarantee that all IUCs are committed at the >same time since they would "immediately" be committed to the active >upstream channel entries with pointers to the docsIfCmtsModIndex? > >Thanks for the clarifications. - Dan > >-----Original Message----- >From: Greg White [mailto:g.white@CableLabs.com] >Sent: Wednesday, October 08, 2003 7:20 PM >To: Minnie Lu >Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : >rules for assigning modulation profiles to upstream channels) > >That sounds like a workable alternative. If no one disagrees, I will >make that change to the proposal. > >-Greg > > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 3:09 PM >To: Greg White >Cc: Minnie Lu; David.White@arrisi.com; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Hi, Greg, > >Then how about enforce this rule for "active" entries ? So in the case >you >mentioned, user can change the row status to notInService first or at >the >same time changing the channel type. When user changed all the entries' > >channel type to be the same, use can put the entries in active again. I > >personally think it affects a lot when the channel type is changed, so a > >little more steps should be ok. To me, if there is an error, better >catch >it as earlier as possible. > >"All the active entries in a modulation profile (i.e. all active entries > >that share a >common docsIfCmtsModIndex) MUST have the same value of >docsIfCmtsModChannelType." > >Thanks a lot ! >Minnie > >At 02:12 PM 10/8/2003 -0600, Greg White wrote: > >Minnie, > > > >I didn't want to prevent a user from changing their mind regarding > >channel type when creating a new modulation profile. Suppose you > >started out setting channel type to atdma and, after completing a few > >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make > >you start from scratch (or do a simultaneous set across all IUCs), you > >could just update the channel type on each row. > > > >I understand your view as well. > > > >If there is a consensus to change the text, I am not strongly opposed. > > > >-Greg > > > >-----Original Message----- > >From: Minnie Lu [mailto:milu@cisco.com] > >Sent: Wednesday, October 08, 2003 12:48 PM > >To: Greg White > >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; > >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org > >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for > >assigning modulation profiles to upstream channels) > > > > > >Hi, Greg, > > > > Thanks a lot to you and Eduardo for this proposal ! > > > >docsIfCmtsModChannelType : > > "... > > In order to be considered a valid modulation profile for > > assignment to an upstream channel, all entries (IUCs) in > > the modulation profile must have the same channel type." > > > > In addition to do the checking at the time the modulation profile >is > >assigned to some upstream, I think that the checking could also be done > >when user create/modify an entry of docsIfCmtsModulationEntry even the > >modulation profile is not assigned to any upstreams. So the error >could > >be > >caught earlier. So I would suggest to enhance the description as the > >ECO > >(OSS2-O-03092) > > > >"All the entries in a modulation profile (i.e. all entries that share a > >common docsIfCmtsModIndex) MUST have the same value of > >docsIfCmtsModChannelType." > > > >If I miss anything, please let me know. > >Thanks a lot! > >Minnie > > > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > > >All, > > > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would > >like > > >to propose that we complete the clarification of the relationship > >between > > >the ChannelType parameters in modulation profiles and upstream > >channels. > > > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which > > >clarifies part of the relationship by adding requirements to the OSSI > > >spec. I would like to suggest that we propagate those requirements >to > >the > > >MIB descriptions. > > > > > >Also, I would like to propose that we make docsIfUpChannelType a > >read-only > > >object for active rows in the Upstream Channel Table. The value > >reported > > >would be taken from the modulation profile pointed to by > > >docsIfUpChannelModulationProfile. > > > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the > >issue. > > > > > >In order not to delay draft-08, we would like to have consensus from > >the > > >community and working group by this Friday, October 10. Please >review > >the > > >attached proposal and provide comments. > > > > > >Many thanks, > > >Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 5:59 PM > > >To: Minnie Lu > > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; > > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > > >upstream channels > > > > > >Minnie, > > > I am emphathetic to your concerns. I ran across the same >issue > > > > > while implementing cross-checks for the 2.0 modulation and upstream > >data. > > > I found it made the code far simpler to lead the user down the path >of > > > > > "define the channel type first, then build everything around that" > >kind > > > of configuration model. I am then able to check the settings of the > >other > > > parameters against the channel type. After a modulation profile or > > > upstream channel has already been provisioned, changing just the > >channel > > > type becomes difficult, as many parameters are incompatible with >other > > > > > channel types. I allow it, but don't recommend it. > > > > > >My 2 cents, > > >David > > > > > > > > > > > > > > > > > >Minnie Lu > > > > > >08/25/2003 07:01 PM > > > > > > To: "Greg White" > > > cc: , "Minnie Lu" > > > , , >, > > > > > "DOCSIS OSS Majordomo List" , "Owner >DOCSIS > >OSS > > > Majordomo List" > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning > >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, Greg, > > > > > > Please see my response inline. > > > Thanks a lot ! > > > Minnie > > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > > >The email exchange between Steve and Alberto notwithstanding, I >think > >it > > > >does make sense to enforce that all entries in a modulation profile > >(i.e. > > > >all entries that share a common docsIfCmtsModIndex) have the same > > > >ModChannelType. Also, based on the exchange here it seems that >there > >is > > > >some support for the additional restriction that UpChannelType and > > > >ModChannelType always match. With those two restrictions, there > >clearly > > > >is a need for all defined values of ModChannelType. > > > > > > > >Since this has been a point of confusion at least twice now, does > >anyone > > > >have a concern with making these two items part of the >specification? > > > > > > > > > >[milu]: I agree with you. > > > > > > >A further point, how does the CMTS enforce the match between > >UpChannelType > > > >and ModChannelType? One implementation may automatically change > > > >UpChannelType to match ModChannelType whenever > > > >docsIfUpChannelModulationProfile is set. Another might reject the > >change > > > >if the two don't already match, and require the use of the > > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd > >argue > > > >that the first implementation makes more sense, and ought to be >made > >a > > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > > > > >[milu]: I think this needs to be thought over carefully. How about >the > > >case that some modulation profile is used by some upstream channel, >and > > >user change the modulation profile channel type ? Does it mean that > >the > > >upstream channel type would be changed automatically, too ? If yes, >I > >am > > >afraid that there might be some user who forget the modulation >profile > >is > > >being used and change the channel type without knowing the upstream > >channel > > >type for some upstream channels are changed at the same time. The > > >modulation profile channel type and upstream channel type are in two > > >different MIB tables. > > > > > > Actually, I am always puzzled when the modulation profile is being > >used > > >by some upstream channels, could the modulation profile channel type >be > > >changed ? Maybe this is a confusing point which needs to be >clarified, > >too. > > > > > > Thanks a lot for your help ! > > > Minnie > > > > > > > > > > > > > > > > > > >-Greg > > > >-----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Monday, August 25, 2003 11:07 AM > > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner > >DOCSIS > > > >OSS Majordomo List > > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles >to > > > >upstream channels > > > > > > > >Minnie, > > > > Sounds good to me. This would make verifying the >consistency > >of > > > > the data in the modulation profiles and the upstream channels far > >easier. > > > >So, if I understand correctly, this means that all modulation >profile > > > >entries with the same docsIfCmtsModIndex will have to have the same > > > >docsIfCmtsModChannelType. Otherwise, you would not be able to use > >that > > > >modulation profile set on any upstream channel. So, this modulation > > > >profile set with different docsIfCmtsModChannelTypes from an e-mail > >thread > > > >between Alberto and Steve from almost a year ago would be invalid, >no > >? > > > >The way to patch it up would be to make all of the IUCs >tdmaAndAtdma, > > > >correct ? > > > > > > > >Thanks, > > > >David > > > > > > > >--- end David's e-mail --- > > > >--- start e-mail exchange between Alberto and Steve --- > > > > > > > >Hi Steve > > > > > > > >Sorry for the delay in responding > > > > > > > >Your configuration settings for operation in multiple mode is >correct > >and > > > >will support tdma, tdmaAndAtdma and Atdma. > > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used >with > >UCD > > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 >and > >IUCs > > > >5&6 are not used. Your interpretation of the spec in the example > >described > > > >is accurate. > > > > > > > >Alberto Campos > > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > > >Sent: Monday, September 30, 2002 9:39 AM > > > >To: 'docsis-20@cablelabs.com' > > > >Subject: Correlation between docsIfUpChannelType and > > > >docsIfCmtsModChannelT ype > > > > > > > > > > > > > > > >We are having some discussion internally here, and would like to > >clarify > > > >things about the modulation profile. > > > >Let's take an example, expecting all parameters are good : > > > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, > >tdmaAndAtdma > > > >and Atdma? > > > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV >5 > >inside > > > >UCD type 2. > > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type >29. > > > > > > > > > > > > > > > > > > > > > > > >Minnie Lu > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/21/2003 07:15 PM > > > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > > > cc: "DOCSIS OSS Majordomo List" > > > > , milu@cisco.com > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning > >modulation > > > > profiles to upstream channels > > > > > > > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > > > I like Greg's "Perhaps it is simpler just to require that > >ModChannelType > > > >match UpChannelType.". > > > > > > > > I don't think that "we could just drop tdmaAndAtdma for > > > >ModChannelType". Please keep in mind that when assigning the > >modulation > > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, > >it uses > > > >only the docsIfModIndex and only one docsIfModIndex can be assigned > >to some > > > >upstream channel. > > > > > > > > If I miss anything, please correct me. > > > > Thanks! > > > > Minnie > > > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > > > >Greg, > > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma > >channels. > > > > > However, the modulation profiles objects > > > > > docsIfCmtsModByteInterleaverBlockSize and > > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma > >channels. So, > > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these > >objects > > > set, > > > > > it assumably could not be used on a tdma-only upstream channel. > >Hence, > > > > > the whole purpose of even having ModChannelType - to verify > >consistency > > > > > within the modulation profile - is weakened. This has the > >unintended > > > side > > > > > effect of requiring any assignment of modulation profiles with > >IUCs > > > 1, 2, > > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to >see > >if the > > > > > Interleaver parameters have been set before assigning it to a > >tdma-only > > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for >modulation > > > > profiles. > > > > > I can't think of any need/requirement for tdmaAndAtdma >for > > > > > modulation profiles that could not be met with a pair of tdma >and > >atdma > > > > > modulation profile. In other words, I don't think allowing > >tdmaAndAtdma > > > > > for ModChannelType really buys us anything. I'm thinking we >could > >just > > > > > drop tdmaAndAtdma for ModChannelType (making it a > > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of > >confusion. > > > > > For the mixed-mode channels, where UpChannelType is > > > tdmaAndAtdma, > > > > > the modulation profile set could look like so: > > > > > > > > > >IUC 1 tdma > > > > >IUC 2 tdma > > > > >IUC 3 tdma > > > > >IUC 4 tdma > > > > >IUC 5 tdma > > > > >IUC 6 tdma > > > > >IUC 9 atdma > > > > >IUC 10 atdma > > > > >IUC 11 atdma > > > > > > > > > >For tdma-only upstream channels, the modulation profile set could > >be: > > > > > > > > > >IUC 1 tdma > > > > >IUC 2 tdma > > > > >IUC 3 tdma > > > > >IUC 4 tdma > > > > >IUC 5 tdma > > > > >IUC 6 tdma > > > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile > >set > > > > >could be: > > > > > > > > > >IUC 1 atdma > > > > >IUC 2 atdma > > > > >IUC 3 atdma > > > > >IUC 4 atdma > > > > >IUC 9 atdma > > > > >IUC 10 atdma > > > > >IUC 11 atdma > > > > > > > > > >As far as I know, there is no hard limit on the number of the > >modulation > > > > >profile sets that the CMTS and CM can support. I'm really liking > >your > > > "not > > > > >sure the benefits of flexibility outweigh disadvantages..." line >of > > > > >thinking. tdmaAndAtdma for modulation profiles has my head > >spinning. > > > > > > > > > >Thanks, > > > > >David > > > > > > > > > > > > > > > > > > > >"Greg White" > > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > > > >08/20/2003 07:35 PM > > > > > > > > > > To: , "DOCSIS OSS >Majordomo > >List" > > > > > > > > > > cc: > > > > > Fax to: > > > > > Subject: RE: DOCSIS 2.0 : rules for assigning > >modulation > > > > > profiles to upstream channels > > > > > > > > > > > > > > >David, > > > > > > > > > >I agree with all of your clearly legal/illegal combinations. >Among > >the > > > > >four that cause you consternation, I would break them done like > >this: > > > > > > > > > >illegal: > > > > >tdma, atdma > > > > >atdma, tdma > > > > > > > > > >potentially legal: > > > > >tdma, tdmaAndAtdma > > > > >atdma, tdmaAndAtdma > > > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and > >possibly > > > 11, > > > > >so cannot be used for a tdma channel. Similarly a tdma modulation > >profile > > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma > >channel. > > > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs >1,3,4,5,6,9,10, > >and > > > > >possibly 11, so could potentially be used for a tdma or an atdma > >channel > > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS > >ignored the > > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > > >advantages of that flexibility outweigh the disadvantages of >having > >the > > > > >MIB reporting something that doesn't exactly reflect what is > > > > >configured. Perhaps it is simpler just to require that > >ModChannelType > > > > >match UpChannelType. > > > > > > > > > >-Greg > > > > > > > > > > > > > > > ----Original Message----- > > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > > >To: DOCSIS OSS Majordomo List > > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream > > > > >channels > > > > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > > It seems that the DocsisUpstreamType objects in both the > > > > > modulation profile table and the upstream channel table exist, >in > >part, > > > > > to provide the equipment vendor a way to cross-check the data >for > > > > > consistency. Furthermore, it would seem possible to compare the > >two > > > > > DocsisUpstreamType objects when assigning an upstream to a > >modulation > > > > > profile to make sure the assignment is compatible. For instance, > >the > > > > > following combination of docsIfUpChannelType, > >docsIfCmtsModChannelType > > > > > would clearly be illegal: > > > > > > > > > >scdma, tdma > > > > >scdma, atdma > > > > >scdma, tdmaAndAtdma > > > > > > > > > >tdma, scdma > > > > >atdma, scdma > > > > >tdmaAndAtdma, scdma > > > > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > > > >tdma, tdma > > > > >atdma, atdma > > > > >scdma, scdma > > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > > > > >However, it is the following cases that are causing me > >consternation: > > > > > > > > > >tdma, atdma > > > > >tdma, tdmaAndAtdma > > > > >atdma, tdma > > > > >atdma, tdmaAndAtdma > > > > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > > > >tdmaAndAtdma, other than to cause confusion, especially for > >modulation > > > > >profiles. > > > > > > > > > >Thanks, > > > > >David White > > > > >ARRIS Cadant C4 CMTS > > > > > > > > > > > > > > > >_______________________________________________ >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 Fri Oct 10 17:43:24 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 RAA24287 for ; Fri, 10 Oct 2003 17:43:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A852M-0006Px-Av for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 17:43:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ALh20D024663 for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 17:43:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A852L-0006Pa-2N; Fri, 10 Oct 2003 17:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81xN-00086Z-5l for ipcdn@optimus.ietf.org; Fri, 10 Oct 2003 14:25:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10897 for ; Fri, 10 Oct 2003 14:25:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81xK-0007IU-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 14:25:38 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A81xH-0007Hq-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 14:25:35 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 10 Oct 2003 11:33:23 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9AIOhXg020726; Fri, 10 Oct 2003 11:24:44 -0700 (PDT) Received: from milu-w2k.cisco.com (dhcp-171-71-51-93.cisco.com [171.71.51.93]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANA46296; Fri, 10 Oct 2003 11:24:43 -0700 (PDT) Message-Id: <4.3.2.7.2.20031010111523.02f475a8@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Oct 2003 11:24:42 -0700 To: "Dan Rice" From: Minnie Lu Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Cc: "Greg White" , "Minnie Lu" , , "DOCSIS OSS Majordomo List" , , , In-Reply-To: <344C3B42FD36C54A8BC47A471265DEF001A91D@xchange.stargus.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, Dan, In the original proposal of Greg and Eduardo (also in OSS2-O-03092), there are more rules. Please see Greg and Eduardo's original proposal for more details. Here please allow me to list the ones in OSS2-O-03092. (I added the word 'active' in the first sentence of the original OSS2-O-03092.) All the active entries in a modulation profile (i.e. all active entries that share a common docsIfCmtsModIndex) MUST have the same value of docsIfCmtsModChannelType. When assigning a modulation profile to an upstream channel, the value of docsIfUpChannelType and the value of docsIfCmtsModChannelType MUST match. If a modulation profile is in use by one or more upstream channels, the value of docsIfCmtsModChannelType MUST NOT be changed. Also, if a modulation profile is in use by one or more upstream channels, it MUST NOT be destroyed. Before destroying a modulation profile, or changing the value of docsIfCmtsModChannelType for a profile, the user will need to ensure that it is not currently in use by any upstream channel. The maximum number of modulation profiles that a CMTS can support in docsIfCmtsModulationTable is vendor -specific. Now we are discussing how and when to enforce it as cleaner and easier way. Thanks! Minnie At 01:26 PM 10/10/2003 -0400, Dan Rice wrote: >-----Original Message----- >From: Greg White [mailto:g.white@CableLabs.com] >Sent: Friday, October 10, 2003 12:56 PM >To: Dan Rice; Minnie Lu >Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : >rules for assigning modulation profiles to upstream channels) > >What I had interpreted Minnie's suggestion to be was that ChannelType >consistency was enforced across all modulation profile rows with a >Status of 'active', regardless of whether they were assigned to an >upstream channel or not. Setting Status to 'notInService' is not >allowed for propfiles assigned to an upstream channel, nor is changing >ChannelType. > >So, the operation Minnie suggested only applies to profiles that have >been created and set 'active', but are not assigned to any upstream >channel. > >Does that clarify? >[DJR] Yes that sounds good. Thank You Greg >Can I also extend your answer to infer one or both of the following: > > 1) Changing of the channel type is not allowed for any set of >iuc rows while their modulation profile is assigned to an active >upstream channel. > 2) Changing any of the modulation profile attributes is not >allowed while it is assigned to an active upstream channel? > >-Greg > > >-----Original Message----- >From: Dan Rice @ Stargus >Sent: Friday, October 10, 2003 7:59 AM >To: Greg White; Minnie Lu >Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : >rules for assigning modulation profiles to upstream channels) > > >Sorry for chiming in 11th hour, but want to make sure I understand >minnie's suggestion for active entries. I believe the suggestion is >that for active entries you change the row status to not in service. >What would we expect to happen to the upstream currently assigned this >modulation profile while it is notInService? Would the existing active >assignment continue to be valid for the upstream using it until all IUC >rows became active again with the changes in them? > >Also if the changes are to docsIfCmtsModChannelType wouldn't you have to >edit all IUC rows before checking to see if this is valid? I guess when >you started going in and making each IUC active that would be the point >to check it? Could you guarantee that all IUCs are committed at the >same time since they would "immediately" be committed to the active >upstream channel entries with pointers to the docsIfCmtsModIndex? > >Thanks for the clarifications. - Dan > >-----Original Message----- >From: Greg White [mailto:g.white@CableLabs.com] >Sent: Wednesday, October 08, 2003 7:20 PM >To: Minnie Lu >Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : >rules for assigning modulation profiles to upstream channels) > >That sounds like a workable alternative. If no one disagrees, I will >make that change to the proposal. > >-Greg > > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 3:09 PM >To: Greg White >Cc: Minnie Lu; David.White@arrisi.com; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Hi, Greg, > >Then how about enforce this rule for "active" entries ? So in the case >you >mentioned, user can change the row status to notInService first or at >the >same time changing the channel type. When user changed all the entries' > >channel type to be the same, use can put the entries in active again. I > >personally think it affects a lot when the channel type is changed, so a > >little more steps should be ok. To me, if there is an error, better >catch >it as earlier as possible. > >"All the active entries in a modulation profile (i.e. all active entries > >that share a >common docsIfCmtsModIndex) MUST have the same value of >docsIfCmtsModChannelType." > >Thanks a lot ! >Minnie > >At 02:12 PM 10/8/2003 -0600, Greg White wrote: > >Minnie, > > > >I didn't want to prevent a user from changing their mind regarding > >channel type when creating a new modulation profile. Suppose you > >started out setting channel type to atdma and, after completing a few > >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make > >you start from scratch (or do a simultaneous set across all IUCs), you > >could just update the channel type on each row. > > > >I understand your view as well. > > > >If there is a consensus to change the text, I am not strongly opposed. > > > >-Greg > > > >-----Original Message----- > >From: Minnie Lu [mailto:milu@cisco.com] > >Sent: Wednesday, October 08, 2003 12:48 PM > >To: Greg White > >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; > >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org > >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for > >assigning modulation profiles to upstream channels) > > > > > >Hi, Greg, > > > > Thanks a lot to you and Eduardo for this proposal ! > > > >docsIfCmtsModChannelType : > > "... > > In order to be considered a valid modulation profile for > > assignment to an upstream channel, all entries (IUCs) in > > the modulation profile must have the same channel type." > > > > In addition to do the checking at the time the modulation profile >is > >assigned to some upstream, I think that the checking could also be done > >when user create/modify an entry of docsIfCmtsModulationEntry even the > >modulation profile is not assigned to any upstreams. So the error >could > >be > >caught earlier. So I would suggest to enhance the description as the > >ECO > >(OSS2-O-03092) > > > >"All the entries in a modulation profile (i.e. all entries that share a > >common docsIfCmtsModIndex) MUST have the same value of > >docsIfCmtsModChannelType." > > > >If I miss anything, please let me know. > >Thanks a lot! > >Minnie > > > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > > >All, > > > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would > >like > > >to propose that we complete the clarification of the relationship > >between > > >the ChannelType parameters in modulation profiles and upstream > >channels. > > > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which > > >clarifies part of the relationship by adding requirements to the OSSI > > >spec. I would like to suggest that we propagate those requirements >to > >the > > >MIB descriptions. > > > > > >Also, I would like to propose that we make docsIfUpChannelType a > >read-only > > >object for active rows in the Upstream Channel Table. The value > >reported > > >would be taken from the modulation profile pointed to by > > >docsIfUpChannelModulationProfile. > > > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the > >issue. > > > > > >In order not to delay draft-08, we would like to have consensus from > >the > > >community and working group by this Friday, October 10. Please >review > >the > > >attached proposal and provide comments. > > > > > >Many thanks, > > >Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 5:59 PM > > >To: Minnie Lu > > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; > > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > > >upstream channels > > > > > >Minnie, > > > I am emphathetic to your concerns. I ran across the same >issue > > > > > while implementing cross-checks for the 2.0 modulation and upstream > >data. > > > I found it made the code far simpler to lead the user down the path >of > > > > > "define the channel type first, then build everything around that" > >kind > > > of configuration model. I am then able to check the settings of the > >other > > > parameters against the channel type. After a modulation profile or > > > upstream channel has already been provisioned, changing just the > >channel > > > type becomes difficult, as many parameters are incompatible with >other > > > > > channel types. I allow it, but don't recommend it. > > > > > >My 2 cents, > > >David > > > > > > > > > > > > > > > > > >Minnie Lu > > > > > >08/25/2003 07:01 PM > > > > > > To: "Greg White" > > > cc: , "Minnie Lu" > > > , , >, > > > > > "DOCSIS OSS Majordomo List" , "Owner >DOCSIS > >OSS > > > Majordomo List" > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning > >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, Greg, > > > > > > Please see my response inline. > > > Thanks a lot ! > > > Minnie > > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > > >The email exchange between Steve and Alberto notwithstanding, I >think > >it > > > >does make sense to enforce that all entries in a modulation profile > >(i.e. > > > >all entries that share a common docsIfCmtsModIndex) have the same > > > >ModChannelType. Also, based on the exchange here it seems that >there > >is > > > >some support for the additional restriction that UpChannelType and > > > >ModChannelType always match. With those two restrictions, there > >clearly > > > >is a need for all defined values of ModChannelType. > > > > > > > >Since this has been a point of confusion at least twice now, does > >anyone > > > >have a concern with making these two items part of the >specification? > > > > > > > > > >[milu]: I agree with you. > > > > > > >A further point, how does the CMTS enforce the match between > >UpChannelType > > > >and ModChannelType? One implementation may automatically change > > > >UpChannelType to match ModChannelType whenever > > > >docsIfUpChannelModulationProfile is set. Another might reject the > >change > > > >if the two don't already match, and require the use of the > > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd > >argue > > > >that the first implementation makes more sense, and ought to be >made > >a > > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > > > > >[milu]: I think this needs to be thought over carefully. How about >the > > >case that some modulation profile is used by some upstream channel, >and > > >user change the modulation profile channel type ? Does it mean that > >the > > >upstream channel type would be changed automatically, too ? If yes, >I > >am > > >afraid that there might be some user who forget the modulation >profile > >is > > >being used and change the channel type without knowing the upstream > >channel > > >type for some upstream channels are changed at the same time. The > > >modulation profile channel type and upstream channel type are in two > > >different MIB tables. > > > > > > Actually, I am always puzzled when the modulation profile is being > >used > > >by some upstream channels, could the modulation profile channel type >be > > >changed ? Maybe this is a confusing point which needs to be >clarified, > >too. > > > > > > Thanks a lot for your help ! > > > Minnie > > > > > > > > > > > > > > > > > > >-Greg > > > >-----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Monday, August 25, 2003 11:07 AM > > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner > >DOCSIS > > > >OSS Majordomo List > > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles >to > > > >upstream channels > > > > > > > >Minnie, > > > > Sounds good to me. This would make verifying the >consistency > >of > > > > the data in the modulation profiles and the upstream channels far > >easier. > > > >So, if I understand correctly, this means that all modulation >profile > > > >entries with the same docsIfCmtsModIndex will have to have the same > > > >docsIfCmtsModChannelType. Otherwise, you would not be able to use > >that > > > >modulation profile set on any upstream channel. So, this modulation > > > >profile set with different docsIfCmtsModChannelTypes from an e-mail > >thread > > > >between Alberto and Steve from almost a year ago would be invalid, >no > >? > > > >The way to patch it up would be to make all of the IUCs >tdmaAndAtdma, > > > >correct ? > > > > > > > >Thanks, > > > >David > > > > > > > >--- end David's e-mail --- > > > >--- start e-mail exchange between Alberto and Steve --- > > > > > > > >Hi Steve > > > > > > > >Sorry for the delay in responding > > > > > > > >Your configuration settings for operation in multiple mode is >correct > >and > > > >will support tdma, tdmaAndAtdma and Atdma. > > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used >with > >UCD > > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 >and > >IUCs > > > >5&6 are not used. Your interpretation of the spec in the example > >described > > > >is accurate. > > > > > > > >Alberto Campos > > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > > >Sent: Monday, September 30, 2002 9:39 AM > > > >To: 'docsis-20@cablelabs.com' > > > >Subject: Correlation between docsIfUpChannelType and > > > >docsIfCmtsModChannelT ype > > > > > > > > > > > > > > > >We are having some discussion internally here, and would like to > >clarify > > > >things about the modulation profile. > > > >Let's take an example, expecting all parameters are good : > > > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, > >tdmaAndAtdma > > > >and Atdma? > > > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV >5 > >inside > > > >UCD type 2. > > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type >29. > > > > > > > > > > > > > > > > > > > > > > > >Minnie Lu > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/21/2003 07:15 PM > > > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > > > cc: "DOCSIS OSS Majordomo List" > > > > , milu@cisco.com > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning > >modulation > > > > profiles to upstream channels > > > > > > > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > > > I like Greg's "Perhaps it is simpler just to require that > >ModChannelType > > > >match UpChannelType.". > > > > > > > > I don't think that "we could just drop tdmaAndAtdma for > > > >ModChannelType". Please keep in mind that when assigning the > >modulation > > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, > >it uses > > > >only the docsIfModIndex and only one docsIfModIndex can be assigned > >to some > > > >upstream channel. > > > > > > > > If I miss anything, please correct me. > > > > Thanks! > > > > Minnie > > > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > > > >Greg, > > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma > >channels. > > > > > However, the modulation profiles objects > > > > > docsIfCmtsModByteInterleaverBlockSize and > > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma > >channels. So, > > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these > >objects > > > set, > > > > > it assumably could not be used on a tdma-only upstream channel. > >Hence, > > > > > the whole purpose of even having ModChannelType - to verify > >consistency > > > > > within the modulation profile - is weakened. This has the > >unintended > > > side > > > > > effect of requiring any assignment of modulation profiles with > >IUCs > > > 1, 2, > > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to >see > >if the > > > > > Interleaver parameters have been set before assigning it to a > >tdma-only > > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for >modulation > > > > profiles. > > > > > I can't think of any need/requirement for tdmaAndAtdma >for > > > > > modulation profiles that could not be met with a pair of tdma >and > >atdma > > > > > modulation profile. In other words, I don't think allowing > >tdmaAndAtdma > > > > > for ModChannelType really buys us anything. I'm thinking we >could > >just > > > > > drop tdmaAndAtdma for ModChannelType (making it a > > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of > >confusion. > > > > > For the mixed-mode channels, where UpChannelType is > > > tdmaAndAtdma, > > > > > the modulation profile set could look like so: > > > > > > > > > >IUC 1 tdma > > > > >IUC 2 tdma > > > > >IUC 3 tdma > > > > >IUC 4 tdma > > > > >IUC 5 tdma > > > > >IUC 6 tdma > > > > >IUC 9 atdma > > > > >IUC 10 atdma > > > > >IUC 11 atdma > > > > > > > > > >For tdma-only upstream channels, the modulation profile set could > >be: > > > > > > > > > >IUC 1 tdma > > > > >IUC 2 tdma > > > > >IUC 3 tdma > > > > >IUC 4 tdma > > > > >IUC 5 tdma > > > > >IUC 6 tdma > > > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile > >set > > > > >could be: > > > > > > > > > >IUC 1 atdma > > > > >IUC 2 atdma > > > > >IUC 3 atdma > > > > >IUC 4 atdma > > > > >IUC 9 atdma > > > > >IUC 10 atdma > > > > >IUC 11 atdma > > > > > > > > > >As far as I know, there is no hard limit on the number of the > >modulation > > > > >profile sets that the CMTS and CM can support. I'm really liking > >your > > > "not > > > > >sure the benefits of flexibility outweigh disadvantages..." line >of > > > > >thinking. tdmaAndAtdma for modulation profiles has my head > >spinning. > > > > > > > > > >Thanks, > > > > >David > > > > > > > > > > > > > > > > > > > >"Greg White" > > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > > > >08/20/2003 07:35 PM > > > > > > > > > > To: , "DOCSIS OSS >Majordomo > >List" > > > > > > > > > > cc: > > > > > Fax to: > > > > > Subject: RE: DOCSIS 2.0 : rules for assigning > >modulation > > > > > profiles to upstream channels > > > > > > > > > > > > > > >David, > > > > > > > > > >I agree with all of your clearly legal/illegal combinations. >Among > >the > > > > >four that cause you consternation, I would break them done like > >this: > > > > > > > > > >illegal: > > > > >tdma, atdma > > > > >atdma, tdma > > > > > > > > > >potentially legal: > > > > >tdma, tdmaAndAtdma > > > > >atdma, tdmaAndAtdma > > > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and > >possibly > > > 11, > > > > >so cannot be used for a tdma channel. Similarly a tdma modulation > >profile > > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma > >channel. > > > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs >1,3,4,5,6,9,10, > >and > > > > >possibly 11, so could potentially be used for a tdma or an atdma > >channel > > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS > >ignored the > > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > > >advantages of that flexibility outweigh the disadvantages of >having > >the > > > > >MIB reporting something that doesn't exactly reflect what is > > > > >configured. Perhaps it is simpler just to require that > >ModChannelType > > > > >match UpChannelType. > > > > > > > > > >-Greg > > > > > > > > > > > > > > > ----Original Message----- > > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > > >To: DOCSIS OSS Majordomo List > > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream > > > > >channels > > > > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > > It seems that the DocsisUpstreamType objects in both the > > > > > modulation profile table and the upstream channel table exist, >in > >part, > > > > > to provide the equipment vendor a way to cross-check the data >for > > > > > consistency. Furthermore, it would seem possible to compare the > >two > > > > > DocsisUpstreamType objects when assigning an upstream to a > >modulation > > > > > profile to make sure the assignment is compatible. For instance, > >the > > > > > following combination of docsIfUpChannelType, > >docsIfCmtsModChannelType > > > > > would clearly be illegal: > > > > > > > > > >scdma, tdma > > > > >scdma, atdma > > > > >scdma, tdmaAndAtdma > > > > > > > > > >tdma, scdma > > > > >atdma, scdma > > > > >tdmaAndAtdma, scdma > > > > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > > > >tdma, tdma > > > > >atdma, atdma > > > > >scdma, scdma > > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > > > > >However, it is the following cases that are causing me > >consternation: > > > > > > > > > >tdma, atdma > > > > >tdma, tdmaAndAtdma > > > > >atdma, tdma > > > > >atdma, tdmaAndAtdma > > > > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > > > >tdmaAndAtdma, other than to cause confusion, especially for > >modulation > > > > >profiles. > > > > > > > > > >Thanks, > > > > >David White > > > > >ARRIS Cadant C4 CMTS > > > > > > > > > > > > > > > >_______________________________________________ >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 Fri Oct 10 18:35:30 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 SAA27524 for ; Fri, 10 Oct 2003 18:35:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A85qn-0001My-MD for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 18:35:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AMZ9Nd005258 for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 18:35:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A85qf-0001MN-R7; Fri, 10 Oct 2003 18:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A85qE-0001LD-7o for ipcdn@optimus.ietf.org; Fri, 10 Oct 2003 18:34:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27498 for ; Fri, 10 Oct 2003 18:34:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A85qA-0003s8-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 18:34:30 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A85q4-0003rc-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 18:34:24 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9AMWjUt002058; Fri, 10 Oct 2003 15:32:46 -0700 (PDT) Received: from milu-w2k.cisco.com (dhcp-171-71-51-93.cisco.com [171.71.51.93]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANA75346; Fri, 10 Oct 2003 15:32:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20031010152652.04a7c948@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Oct 2003 15:32:44 -0700 To: "Dan Rice" From: Minnie Lu Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Cc: "Minnie Lu" , "Greg White" , , "DOCSIS OSS Majordomo List" , , , In-Reply-To: <344C3B42FD36C54A8BC47A471265DEF001A923@xchange.stargus.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, Dan, Thanks a lot for your review ! Please see my response inline. Thanks! Minnie At 04:31 PM 10/10/2003 -0400, Dan Rice wrote: >Thanks for getting me up to speed. > >It appears to me that I could still change an element in an active IUC >as long as I don't change the docsIfCmtsModChannelType, can you please >confirm? [milu]: I think so as long as all the attributes are consistent with each other. >Also it says >" The maximum number of modulation profiles that a CMTS can support in >docsIfCmtsModulationTable is vendor -specific" > >Would there be resistance to setting a minimum number of modulation >profiles that a CMTS MUST support? If not, than something like 2 times >the number of upstream interfaces would be more than enough. - Dan [milu]: I don't think the spec or mib need to define a minimum number of modulation profiles that a CMTS MUST support. If a CMTS vendor support the number less then the CMTS vendor's customer need, I think the customer will compliant or this CMTS will not be chosen by customers.:-) Thanks a lot ! Minnie >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Friday, October 10, 2003 2:25 PM >To: Dan Rice >Cc: Greg White; Minnie Lu; David.White@arrisi.com; DOCSIS OSS Majordomo >List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : >rules for assigning modulation profiles to upstream channels) > >Hi, Dan, > >In the original proposal of Greg and Eduardo (also in OSS2-O-03092), >there >are more rules. Please see Greg and Eduardo's original proposal for >more >details. Here please allow me to list the ones in OSS2-O-03092. (I >added >the word 'active' in the first sentence of the original OSS2-O-03092.) > >All the active entries in a modulation profile (i.e. all active entries >that share a common docsIfCmtsModIndex) MUST have the same value of >docsIfCmtsModChannelType. When assigning a modulation profile to an >upstream channel, the value of docsIfUpChannelType and the value of >docsIfCmtsModChannelType MUST match. >If a modulation profile is in use by one or more upstream channels, the >value of docsIfCmtsModChannelType MUST NOT be changed. Also, if a >modulation profile is in use by one or more upstream channels, it MUST >NOT >be destroyed. Before destroying a modulation profile, or changing the >value of docsIfCmtsModChannelType for a profile, the user will need to >ensure that it is not currently in use by any upstream channel. >The maximum number of modulation profiles that a CMTS can support in >docsIfCmtsModulationTable is vendor -specific. > >Now we are discussing how and when to enforce it as cleaner and easier >way. > >Thanks! >Minnie > >At 01:26 PM 10/10/2003 -0400, Dan Rice wrote: > > > >-----Original Message----- > >From: Greg White [mailto:g.white@CableLabs.com] > >Sent: Friday, October 10, 2003 12:56 PM > >To: Dan Rice; Minnie Lu > >Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; > >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org > >Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : > >rules for assigning modulation profiles to upstream channels) > > > >What I had interpreted Minnie's suggestion to be was that ChannelType > >consistency was enforced across all modulation profile rows with a > >Status of 'active', regardless of whether they were assigned to an > >upstream channel or not. Setting Status to 'notInService' is not > >allowed for propfiles assigned to an upstream channel, nor is changing > >ChannelType. > > > >So, the operation Minnie suggested only applies to profiles that have > >been created and set 'active', but are not assigned to any upstream > >channel. > > > >Does that clarify? > >[DJR] Yes that sounds good. Thank You Greg > >Can I also extend your answer to infer one or both of the following: > > > > 1) Changing of the channel type is not allowed for any set of > >iuc rows while their modulation profile is assigned to an active > >upstream channel. > > 2) Changing any of the modulation profile attributes is not > >allowed while it is assigned to an active upstream channel? > > > >-Greg > > > > > >-----Original Message----- > >From: Dan Rice @ Stargus > >Sent: Friday, October 10, 2003 7:59 AM > >To: Greg White; Minnie Lu > >Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; > >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org > >Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : > >rules for assigning modulation profiles to upstream channels) > > > > > >Sorry for chiming in 11th hour, but want to make sure I understand > >minnie's suggestion for active entries. I believe the suggestion is > >that for active entries you change the row status to not in service. > >What would we expect to happen to the upstream currently assigned this > >modulation profile while it is notInService? Would the existing active > >assignment continue to be valid for the upstream using it until all IUC > >rows became active again with the changes in them? > > > >Also if the changes are to docsIfCmtsModChannelType wouldn't you have >to > >edit all IUC rows before checking to see if this is valid? I guess >when > >you started going in and making each IUC active that would be the point > >to check it? Could you guarantee that all IUCs are committed at the > >same time since they would "immediately" be committed to the active > >upstream channel entries with pointers to the docsIfCmtsModIndex? > > > >Thanks for the clarifications. - Dan > > > >-----Original Message----- > >From: Greg White [mailto:g.white@CableLabs.com] > >Sent: Wednesday, October 08, 2003 7:20 PM > >To: Minnie Lu > >Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; > >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org > >Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : > >rules for assigning modulation profiles to upstream channels) > > > >That sounds like a workable alternative. If no one disagrees, I will > >make that change to the proposal. > > > >-Greg > > > > > >-----Original Message----- > >From: Minnie Lu [mailto:milu@cisco.com] > >Sent: Wednesday, October 08, 2003 3:09 PM > >To: Greg White > >Cc: Minnie Lu; David.White@arrisi.com; DOCSIS OSS Majordomo List; > >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org > >Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for > >assigning modulation profiles to upstream channels) > > > > > >Hi, Greg, > > > >Then how about enforce this rule for "active" entries ? So in the case > >you > >mentioned, user can change the row status to notInService first or at > >the > >same time changing the channel type. When user changed all the >entries' > > > >channel type to be the same, use can put the entries in active again. >I > > > >personally think it affects a lot when the channel type is changed, so >a > > > >little more steps should be ok. To me, if there is an error, better > >catch > >it as earlier as possible. > > > >"All the active entries in a modulation profile (i.e. all active >entries > > > >that share a > >common docsIfCmtsModIndex) MUST have the same value of > >docsIfCmtsModChannelType." > > > >Thanks a lot ! > >Minnie > > > >At 02:12 PM 10/8/2003 -0600, Greg White wrote: > > >Minnie, > > > > > >I didn't want to prevent a user from changing their mind regarding > > >channel type when creating a new modulation profile. Suppose you > > >started out setting channel type to atdma and, after completing a few > > >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make > > >you start from scratch (or do a simultaneous set across all IUCs), >you > > >could just update the channel type on each row. > > > > > >I understand your view as well. > > > > > >If there is a consensus to change the text, I am not strongly >opposed. > > > > > >-Greg > > > > > >-----Original Message----- > > >From: Minnie Lu [mailto:milu@cisco.com] > > >Sent: Wednesday, October 08, 2003 12:48 PM > > >To: Greg White > > >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; > > >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org > > >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for > > >assigning modulation profiles to upstream channels) > > > > > > > > >Hi, Greg, > > > > > > Thanks a lot to you and Eduardo for this proposal ! > > > > > >docsIfCmtsModChannelType : > > > "... > > > In order to be considered a valid modulation profile for > > > assignment to an upstream channel, all entries (IUCs) in > > > the modulation profile must have the same channel type." > > > > > > In addition to do the checking at the time the modulation profile > >is > > >assigned to some upstream, I think that the checking could also be >done > > >when user create/modify an entry of docsIfCmtsModulationEntry even >the > > >modulation profile is not assigned to any upstreams. So the error > >could > > >be > > >caught earlier. So I would suggest to enhance the description as >the > > >ECO > > >(OSS2-O-03092) > > > > > >"All the entries in a modulation profile (i.e. all entries that share >a > > >common docsIfCmtsModIndex) MUST have the same value of > > >docsIfCmtsModChannelType." > > > > > >If I miss anything, please let me know. > > >Thanks a lot! > > >Minnie > > > > > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > > > >All, > > > > > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would > > >like > > > >to propose that we complete the clarification of the relationship > > >between > > > >the ChannelType parameters in modulation profiles and upstream > > >channels. > > > > > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which > > > >clarifies part of the relationship by adding requirements to the >OSSI > > > >spec. I would like to suggest that we propagate those requirements > >to > > >the > > > >MIB descriptions. > > > > > > > >Also, I would like to propose that we make docsIfUpChannelType a > > >read-only > > > >object for active rows in the Upstream Channel Table. The value > > >reported > > > >would be taken from the modulation profile pointed to by > > > >docsIfUpChannelModulationProfile. > > > > > > > >Attached is a detailed proposal that Eduardo and I wrote to frame >the > > >issue. > > > > > > > >In order not to delay draft-08, we would like to have consensus >from > > >the > > > >community and working group by this Friday, October 10. Please > >review > > >the > > > >attached proposal and provide comments. > > > > > > > >Many thanks, > > > >Greg > > > >-----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Monday, August 25, 2003 5:59 PM > > > >To: Minnie Lu > > > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; > > > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles >to > > > >upstream channels > > > > > > > >Minnie, > > > > I am emphathetic to your concerns. I ran across the same > >issue > > > > > > > while implementing cross-checks for the 2.0 modulation and >upstream > > >data. > > > > I found it made the code far simpler to lead the user down the >path > >of > > > > > > > "define the channel type first, then build everything around that" > > >kind > > > > of configuration model. I am then able to check the settings of >the > > >other > > > > parameters against the channel type. After a modulation profile or > > > > upstream channel has already been provisioned, changing just the > > >channel > > > > type becomes difficult, as many parameters are incompatible with > >other > > > > > > > channel types. I allow it, but don't recommend it. > > > > > > > >My 2 cents, > > > >David > > > > > > > > > > > > > > > > > > > > > > > >Minnie Lu > > > > > > > >08/25/2003 07:01 PM > > > > > > > > To: "Greg White" > > > > cc: , "Minnie Lu" > > > > , , > >, > > > > > > > "DOCSIS OSS Majordomo List" , "Owner > >DOCSIS > > >OSS > > > > Majordomo List" > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning > > >modulation > > > > profiles to upstream channels > > > > > > > > > > > > > > > > > > > > > > > >Hi, Greg, > > > > > > > > Please see my response inline. > > > > Thanks a lot ! > > > > Minnie > > > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > > > >The email exchange between Steve and Alberto notwithstanding, I > >think > > >it > > > > >does make sense to enforce that all entries in a modulation >profile > > >(i.e. > > > > >all entries that share a common docsIfCmtsModIndex) have the same > > > > >ModChannelType. Also, based on the exchange here it seems that > >there > > >is > > > > >some support for the additional restriction that UpChannelType >and > > > > >ModChannelType always match. With those two restrictions, there > > >clearly > > > > >is a need for all defined values of ModChannelType. > > > > > > > > > >Since this has been a point of confusion at least twice now, does > > >anyone > > > > >have a concern with making these two items part of the > >specification? > > > > > > > > > > > > >[milu]: I agree with you. > > > > > > > > >A further point, how does the CMTS enforce the match between > > >UpChannelType > > > > >and ModChannelType? One implementation may automatically change > > > > >UpChannelType to match ModChannelType whenever > > > > >docsIfUpChannelModulationProfile is set. Another might reject >the > > >change > > > > >if the two don't already match, and require the use of the > > > > >docsIfUpChannelCloneFrom mechanism to change the channel type. >I'd > > >argue > > > > >that the first implementation makes more sense, and ought to be > >made > > >a > > > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > > > > > > > >[milu]: I think this needs to be thought over carefully. How about > >the > > > >case that some modulation profile is used by some upstream channel, > >and > > > >user change the modulation profile channel type ? Does it mean >that > > >the > > > >upstream channel type would be changed automatically, too ? If >yes, > >I > > >am > > > >afraid that there might be some user who forget the modulation > >profile > > >is > > > >being used and change the channel type without knowing the upstream > > >channel > > > >type for some upstream channels are changed at the same time. The > > > >modulation profile channel type and upstream channel type are in >two > > > >different MIB tables. > > > > > > > > Actually, I am always puzzled when the modulation profile is >being > > >used > > > >by some upstream channels, could the modulation profile channel >type > >be > > > >changed ? Maybe this is a confusing point which needs to be > >clarified, > > >too. > > > > > > > > Thanks a lot for your help ! > > > > Minnie > > > > > > > > > > > > > > > > > > > > > > > > >-Greg > > > > >-----Original Message----- > > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > > >Sent: Monday, August 25, 2003 11:07 AM > > > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner > > >DOCSIS > > > > >OSS Majordomo List > > > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles > >to > > > > >upstream channels > > > > > > > > > >Minnie, > > > > > Sounds good to me. This would make verifying the > >consistency > > >of > > > > > the data in the modulation profiles and the upstream channels >far > > >easier. > > > > >So, if I understand correctly, this means that all modulation > >profile > > > > >entries with the same docsIfCmtsModIndex will have to have the >same > > > > >docsIfCmtsModChannelType. Otherwise, you would not be able to use > > >that > > > > >modulation profile set on any upstream channel. So, this >modulation > > > > >profile set with different docsIfCmtsModChannelTypes from an >e-mail > > >thread > > > > >between Alberto and Steve from almost a year ago would be >invalid, > >no > > >? > > > > >The way to patch it up would be to make all of the IUCs > >tdmaAndAtdma, > > > > >correct ? > > > > > > > > > >Thanks, > > > > >David > > > > > > > > > >--- end David's e-mail --- > > > > >--- start e-mail exchange between Alberto and Steve --- > > > > > > > > > >Hi Steve > > > > > > > > > >Sorry for the delay in responding > > > > > > > > > >Your configuration settings for operation in multiple mode is > >correct > > >and > > > > >will support tdma, tdmaAndAtdma and Atdma. > > > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used > >with > > >UCD > > > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 > >and > > >IUCs > > > > >5&6 are not used. Your interpretation of the spec in the example > > >described > > > > >is accurate. > > > > > > > > > >Alberto Campos > > > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > > > >Sent: Monday, September 30, 2002 9:39 AM > > > > >To: 'docsis-20@cablelabs.com' > > > > >Subject: Correlation between docsIfUpChannelType and > > > > >docsIfCmtsModChannelT ype > > > > > > > > > > > > > > > > > > > >We are having some discussion internally here, and would like to > > >clarify > > > > >things about the modulation profile. > > > > >Let's take an example, expecting all parameters are good : > > > > > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, > > >tdmaAndAtdma > > > > >and Atdma? > > > > > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > > > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in >TLV > >5 > > >inside > > > > >UCD type 2. > > > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type > >29. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Minnie Lu > > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > > > >08/21/2003 07:15 PM > > > > > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > > > > > cc: "DOCSIS OSS Majordomo List" > > > > > , milu@cisco.com > > > > > Fax to: > > > > > Subject: RE: DOCSIS 2.0 : rules for assigning > > >modulation > > > > > profiles to upstream channels > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > > > > > I like Greg's "Perhaps it is simpler just to require that > > >ModChannelType > > > > >match UpChannelType.". > > > > > > > > > > I don't think that "we could just drop tdmaAndAtdma for > > > > >ModChannelType". Please keep in mind that when assigning the > > >modulation > > > > >profile to some upstream via SNMP >docsIfUpChannelModulationProfile, > > >it uses > > > > >only the docsIfModIndex and only one docsIfModIndex can be >assigned > > >to some > > > > >upstream channel. > > > > > > > > > > If I miss anything, please correct me. > > > > > Thanks! > > > > > Minnie > > > > > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > > > > > >Greg, > > > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma > > >channels. > > > > > > However, the modulation profiles objects > > > > > > docsIfCmtsModByteInterleaverBlockSize and > > > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma > > >channels. So, > > > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these > > >objects > > > > set, > > > > > > it assumably could not be used on a tdma-only upstream >channel. > > >Hence, > > > > > > the whole purpose of even having ModChannelType - to verify > > >consistency > > > > > > within the modulation profile - is weakened. This has the > > >unintended > > > > side > > > > > > effect of requiring any assignment of modulation profiles with > > >IUCs > > > > 1, 2, > > > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to > >see > > >if the > > > > > > Interleaver parameters have been set before assigning it to a > > >tdma-only > > > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for > >modulation > > > > > profiles. > > > > > > I can't think of any need/requirement for tdmaAndAtdma > >for > > > > > > modulation profiles that could not be met with a pair of tdma > >and > > >atdma > > > > > > modulation profile. In other words, I don't think allowing > > >tdmaAndAtdma > > > > > > for ModChannelType really buys us anything. I'm thinking we > >could > > >just > > > > > > drop tdmaAndAtdma for ModChannelType (making it a > > > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of > > >confusion. > > > > > > For the mixed-mode channels, where UpChannelType is > > > > tdmaAndAtdma, > > > > > > the modulation profile set could look like so: > > > > > > > > > > > >IUC 1 tdma > > > > > >IUC 2 tdma > > > > > >IUC 3 tdma > > > > > >IUC 4 tdma > > > > > >IUC 5 tdma > > > > > >IUC 6 tdma > > > > > >IUC 9 atdma > > > > > >IUC 10 atdma > > > > > >IUC 11 atdma > > > > > > > > > > > >For tdma-only upstream channels, the modulation profile set >could > > >be: > > > > > > > > > > > >IUC 1 tdma > > > > > >IUC 2 tdma > > > > > >IUC 3 tdma > > > > > >IUC 4 tdma > > > > > >IUC 5 tdma > > > > > >IUC 6 tdma > > > > > > > > > > > >Likewise, for atdma-only upstream channel, the modulation >profile > > >set > > > > > >could be: > > > > > > > > > > > >IUC 1 atdma > > > > > >IUC 2 atdma > > > > > >IUC 3 atdma > > > > > >IUC 4 atdma > > > > > >IUC 9 atdma > > > > > >IUC 10 atdma > > > > > >IUC 11 atdma > > > > > > > > > > > >As far as I know, there is no hard limit on the number of the > > >modulation > > > > > >profile sets that the CMTS and CM can support. I'm really >liking > > >your > > > > "not > > > > > >sure the benefits of flexibility outweigh disadvantages..." >line > >of > > > > > >thinking. tdmaAndAtdma for modulation profiles has my head > > >spinning. > > > > > > > > > > > >Thanks, > > > > > >David > > > > > > > > > > > > > > > > > > > > > > > >"Greg White" > > > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > > > > > >08/20/2003 07:35 PM > > > > > > > > > > > > To: , "DOCSIS OSS > >Majordomo > > >List" > > > > > > > > > > > > cc: > > > > > > Fax to: > > > > > > Subject: RE: DOCSIS 2.0 : rules for assigning > > >modulation > > > > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >David, > > > > > > > > > > > >I agree with all of your clearly legal/illegal combinations. > >Among > > >the > > > > > >four that cause you consternation, I would break them done like > > >this: > > > > > > > > > > > >illegal: > > > > > >tdma, atdma > > > > > >atdma, tdma > > > > > > > > > > > >potentially legal: > > > > > >tdma, tdmaAndAtdma > > > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and > > >possibly > > > > 11, > > > > > >so cannot be used for a tdma channel. Similarly a tdma >modulation > > >profile > > > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma > > >channel. > > > > > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs > >1,3,4,5,6,9,10, > > >and > > > > > >possibly 11, so could potentially be used for a tdma or an >atdma > > >channel > > > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS > > >ignored the > > > > > >IUCs that don't apply to the channel type. I'm not sure that >the > > > > > >advantages of that flexibility outweigh the disadvantages of > >having > > >the > > > > > >MIB reporting something that doesn't exactly reflect what is > > > > > >configured. Perhaps it is simpler just to require that > > >ModChannelType > > > > > >match UpChannelType. > > > > > > > > > > > >-Greg > > > > > > > > > > > > > > > > > > ----Original Message----- > > > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > > > >To: DOCSIS OSS Majordomo List > > > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles >to > > >upstream > > > > > >channels > > > > > > > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > > > It seems that the DocsisUpstreamType objects in both >the > > > > > > modulation profile table and the upstream channel table exist, > >in > > >part, > > > > > > to provide the equipment vendor a way to cross-check the data > >for > > > > > > consistency. Furthermore, it would seem possible to compare >the > > >two > > > > > > DocsisUpstreamType objects when assigning an upstream to a > > >modulation > > > > > > profile to make sure the assignment is compatible. For >instance, > > >the > > > > > > following combination of docsIfUpChannelType, > > >docsIfCmtsModChannelType > > > > > > would clearly be illegal: > > > > > > > > > > > >scdma, tdma > > > > > >scdma, atdma > > > > > >scdma, tdmaAndAtdma > > > > > > > > > > > >tdma, scdma > > > > > >atdma, scdma > > > > > >tdmaAndAtdma, scdma > > > > > > > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > > > > > >tdma, tdma > > > > > >atdma, atdma > > > > > >scdma, scdma > > > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > > > > > > > >However, it is the following cases that are causing me > > >consternation: > > > > > > > > > > > >tdma, atdma > > > > > >tdma, tdmaAndAtdma > > > > > >atdma, tdma > > > > > >atdma, tdmaAndAtdma > > > > > > > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point >of > > > > > >tdmaAndAtdma, other than to cause confusion, especially for > > >modulation > > > > > >profiles. > > > > > > > > > > > >Thanks, > > > > > >David White > > > > > >ARRIS Cadant C4 CMTS > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > >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 Fri Oct 10 19:49:28 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 TAA00433 for ; Fri, 10 Oct 2003 19:49:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A870K-0006Qi-GK for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 19:49:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ANn4qM024708 for ipcdn-archive@odin.ietf.org; Fri, 10 Oct 2003 19:49:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A870G-0006QH-Ol; Fri, 10 Oct 2003 19:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86zi-0006Pw-KE for ipcdn@optimus.ietf.org; Fri, 10 Oct 2003 19:48:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00402 for ; Fri, 10 Oct 2003 19:48:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A86zg-0004va-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 19:48:24 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A86zf-0004vT-00 for ipcdn@ietf.org; Fri, 10 Oct 2003 19:48:23 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9ANlg10029801; Fri, 10 Oct 2003 17:47:42 -0600 (MDT) 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_01C38F88.E5372656" Date: Fri, 10 Oct 2003 17:47:42 -0600 Message-ID: X-MS-Has-Attach: yes Thread-Topic: Issue#23 revision 1 Extra clarifications. Thread-Index: AcOOktBv0hn4SqViTae2STkl2UxTNwABYoEwAAWCS7AABY6OcAAcphSwAADDo1AABFhoUAACTZvgAAGMJFAAA1AvsAAHa3OQ From: "Eduardo Cardona" To: "Greg White" , "Dan Rice @ Stargus" , "Minnie Lu" , Cc: "DOCSIS OSS Majordomo List" , , , X-Approved: ondar Subject: [ipcdn] Issue#23 revision 1 Extra clarifications. 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_01C38F88.E5372656 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All,=20 Thanks to Dan Rice and Minnie Lu for the valuable input and suggestions With today's discussions about objects not proposed for modifications in issue#23 Greg and I worked a proposal for clarifying the cloneFrom object ( Copy from the pointed row to the temporarly entry explicitely ) and the RowStatusObject to close vage interpretations of other status value,=20 Attached is the updated file with issue#23 Let us know any comments Regards Greg, Eduardo docsIfUpChannelStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is generally intended to be used for the creation of a temporary upstream row for the purpose of=20 adjusting channel parameters of a permanent upstream channel=20 row.=20 The following restrictions apply to this object: 1) Entries with docsIfUpChannelStatus set to active(1)=20 are logically linked to a physical interface,=20 not temporarily created to clone parameters 2) A status transition from active (1) to notInService(2)=20 or destroy (6) is not permitted. The Interface MIB [RFC2863] ifAdminStatus should be used to take an Upstream Channel offline. 3) Temporary rows must be created using createAndWait(5). 4) The only possible status change of a row created using createAndWait(5) (ie notInService(2) or notReady(3)) is=20 to destroy(6). These temporary rows must never be given the Status=20 active(1). A mandatory procedure for adjusting an specific row is: 1) Create a temporary row through an SNMP SET using createAndWait(5). Use an ifIndex value outside the operational range of the system. 2) Set the docsIfUpChannelCloneFrom field to the ifIndex value of the active row whose parameters require adjustment. 3) Adjust the parameter values using the new temporary row. Ensure all parameters contain desired values before proceeding to step 4. 4) Update the permanent row by setting object docsIfUpChannelUpdate to TRUE. This SET will fail if the adjusted parameters are not compatible with each other. 5) Delete the temporary row through an SNMP SET using DELETE. ::=3D { docsIfUpstreamChannelEntry 18 } docsIfUpChannelCloneFrom OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "Intended for use when a temporary upstream table row is created=20 for the purpose of manipulating parameters for a permanent=20 upstream channel. Refer to the descriptions of docsIfUpChannelStatus and docsIfUpChannelUpdate for details of=20 this procedure. This object contains the ifIndex value of the=20 permanent upstream row whose parameters are to be adjusted. Upon=20 setting this object, the values of docsIfUpChannelFrequency,=20 docsIfUpChannelWidth, docsIfUpChannelModulationProfile,=20 docsIfUpChannelSlotSize, docsIfUpChannelRangingBackoffStart,=20 docsIfUpChannelRangingBackoffEnd, docsIfUpChannelTxBackoffStart,=20 docsIfUpChannelTxBackoffEnd, docsIfUpChannelScdmaActiveCodes,=20 docsIfUpChannelScdmaCodesPerSlot, docsIfUpChannelScdmaFrameSize,=20 docsIfUpChannelScdmaHoppingSeed, docsIfUpChannelType, and docsIfUpChannelPreEqEnable for this row are populated with the=20 corresponding values from the row referenced by this object. Seting this object to a non-existent or temporary upstream will=20 return the error 'wrongValue'. This object must contain a value of zero for permanent=20 upstream rows." ::=3D { docsIfUpstreamChannelEntry 16 } ------_=_NextPart_001_01C38F88.E5372656 Content-Type: text/plain; name="issue#23-rev1.txt" Content-Description: issue#23-rev1.txt Content-Disposition: attachment; filename="issue#23-rev1.txt" Content-Transfer-Encoding: base64 KyBJc3N1ZSAjMjMgKHJldmlzaW9uIDEpDQpTdGF0dXM6IE9wZW4NCigyMykgQ2hhbmdlIHRoZSBz eW50YXggb2YgbmV3bHkgYWRkZWQgUkZJdjIgTUlCIG9iamVjdCANCiAgICAgZG9jc0lmVXBDaGFu bmVsVHlwZSBhcyByZWFkLW9ubHkuDQogICAgIFRoZSBwdXJwb3NlIG9mIHRoZSBjaGFuZ2UgaXMg dG8gY2xhcmlmeSwgc2ltcGxpZnkgYW5kDQogICAgIG5vcm1hbGl6ZSB0aGUgY29uZmlndXJhdGlv biBvZiBtb2R1bGF0aW9uIHByb2ZpbGVzIHdoZW4gDQogICAgIGFzc2lnbmluZyB0aGVtIHRvIHVw c3RyZWFtIGNoYW5uZWxzLg0KICAgICBDbGFyaWZ5IG90aGVyIGludGVyZGVwZW5kZW5jaWVzIGJl dHdlZW4gVVMgY2hhbm5lbCBhbmQgDQogICAgIE1vZHVsYXRpb24gUHJvZmlsZSB0YWJsZXMgYXMg Y3VycmVudGx5IHByZXNlbnQgaW4gdXAgdG9kYXkNCiAgICAgT1NTMi0wLTAzMDkyDQogICAgIENv bnRyaWJ1dG9ycyAtIE1pbm5pZSBMdSBDaXNjbywgRGF2aWQgV2hpdGUgQXJyaXMsIEppbSBGbGV0 Y2hlciBBREMNCiAgICAgR3JlZyBXaGl0ZSBDYWJsZUxhYnMsIEVkdWFyZG8gQ2FyZG9uYSBDYWJs ZUxhYnMNCiMgY2F0ZWdvcnk6ICJtdXN0IGZpeCINCiMgQWN0aW9uIEl0ZW06IE5ldyBpdGVtIHBy ZXNlbnRlZCwgdG8gdGhlIElQQ0ROIGdyb3VwIGZvciBjb25zaWRlcmF0aW9ucw0KIyBjaGFpciB3 aWxsIG1ha2UgYSBkZWNpc2lvbi4NCg0KSXNzdWUgRGV0YWlscw0KDQpTZXR0aW5nIGEgbW9kdWxh dGlvbiBwcm9maWxlIGZvciBhbiBVUyBjaGFubmVsIGludm9sdmVzOg0KDQoxIERlZmluZSBhIE1v ZHVsYXRpb24gcHJvZmlsZSBpbiBkb2NzSWZDbXRzTW9kdWxhdGlvblRhYmxlDQoyIEFzc2lnbiB0 aGUgbW9kdWxhdGlvbiBwcm9maWxlIGFuZCBvdGhlciBwYXJhbWV0ZXJzIHRvIHRoZSBVUyBpbnRl cmZhY2UgDQogIChpZkluZGV4KSBpbiBkb2NzSWZVcHN0cmVhbUNoYW5uZWxUYWJsZSBieSBzZXR0 aW5nIA0KICBkb2NzSWZVcENoYW5uZWxNb2R1bGF0aW9uUHJvZmlsZSB0byB0aGUgdmFsdWUgb2Yg ZG9jc0lmQ210c01vZEluZGV4IG9mIHRoZSANCiAgZGVzaXJlZCBwcm9maWxlDQogIA0KVGhlIGN1 cnJlbnQgcHJvYmxlbSByZXN1bHRzIGZyb20gYW4gYW1iaWd1aXR5IGluIHRoZSBtaWIgcmVsYXRp bmcgdG8gc29tZSANCmludGVyZGVwZW5kZW5jaWVzIGJldHdlZW4gdGhlIHR3byB0YWJsZXMuIElu IHBhcnRpY3VsYXIsIGJvdGggdGFibGVzIGN1cnJlbnRseSANCmhhdmUgQ2hhbm5lbFR5cGUgb2Jq ZWN0cyAoZG9jc0lmVXBDaGFubmVsVHlwZSBhbmQgZG9jc0lmQ210c01vZENoYW5uZWxUeXBlKS4N Cg0KQmFzZWQgb24gdGhlIGN1cnJlbnQgTUlCLCB0aGVyZSBpcyBhIHN0cm9uZyBsaWtlbGlob29k IHRoYXQgdGhlIHR3byBvYmplY3RzIA0KY291bGQgY29uZmxpY3QsIGFuZCBDTVRTIHZlbmRvcnMg d291bGQgbmVlZCB0byBkZXZlbG9wIG1lY2hhbmlzbXMgdG8gcmVzb2x2ZSANCnRoZSBjb25mbGlj dHMuIA0KDQpUaGlzIHByb3Bvc2FsIGNoYW5nZXMgZG9jc0lmVXBDaGFubmVsVHlwZSB0byByZWFk LW9ubHksIHRoZSB2YWx1ZSByZXBvcnRlZCAgDQppcyB0YWtlbiBmcm9tIHRoZSBkb2NzSWZDbXRz TW9kQ2hhbm5lbFR5cGUgb2JqZWN0IG9mIHRoZSBjdXJyZW50bHkgc2VsZWN0ZWQgDQptb2R1bGF0 aW9uIHByb2ZpbGUuDQoNClRoaXMgY2hhbmdlIHdpbGwgYXBwbHkgdG8gYWxsIGRvY3NJZlVwQ2hh bm5lbFR5cGUgZW50cmllcyBlLmcuIHBoeXNpY2FsIA0KZXhpc3Rpbmcgb25lcyAoZS5nLiBkb2Nz SWZVcENoYW5uZWxTdGF0dXMgPSAnYWN0aXZlJyApIGFuZCBjbG9uZWQgZW50cmllcyANCihlLmcu IGRvY3NJZlVwQ2hhbm5lbFN0YXR1cyA9ICdjcmVhdGVBbmRXYWl0Jy0+ICdub3RJblNlcnZpY2Un KS4NCg0KIA0KQXMgd3JpdHRlbiBpbiBPU1MyLU8tMDMwOTIsIGFuIGV4dHJhIHJlc3RyaWN0aW9u IGlzIG5lZWRlZDoNCg0KSW4gb3JkZXIgZm9yIGEgbW9kdWxhdGlvbiBwcm9maWxlIHRvIGJlIGNv bnNpZGVyZWQgdmFsaWQsIGFsbCBJVUNzIGluIHRoZSANCm1vZHVsYXRpb24gcHJvZmlsZSBNVVNU IGhhdmUgdGhlIHNhbWUgZG9jc0lmQ210c01vZENoYW5uZWxUeXBlLiAgVGhlIHZhbGlkYXRpb24g DQppcyB0byBiZSBwZXJmb3JtZWQgd2hlbmV2ZXIgYSBwcm9maWxlIGlzIGFzc2lnbmVkIHRvIGFu IHVwc3RyZWFtIGNoYW5uZWwuICANCkFkZGl0aW9uYWxseSwgdGhlIHZhbHVlcyBvZiBkb2NzSWZD bXRzTW9kQ2hhbm5lbFR5cGUgZm9yIGEgcHJvZmlsZSBNVVNUIE5PVCBiZSANCmNoYW5nZWQgd2hp bGUgdGhlIHByb2ZpbGUgaXMgYXNzaWduZWQgdG8gb25lIG9yIG1vcmUgdXBzdHJlYW0gY2hhbm5l bHMuDQogDQpOb3QgZGlyZWN0bHkgcmVsYXRlZCB0byB0aGlzIGlzc3VlLCBidXQgYWxzbyBmcm9t IE9TUzItTy0wMzA5MjogICBBIG1vZHVsYXRpb24gDQpwcm9maWxlIE1VU1QgTk9UIGJlIGRlc3Ry b3llZCBpZiBpdCBhc3NpZ25lZCB0byBvbmUgb3IgbW9yZSBhY3RpdmUgY2hhbm5lbHMuIA0KIA0K DQpSZXZpc2lvbiAxDQpDbGFyaWZ5IHRoZSBvYmplY3QgZGVzY3JpcHRpb24gb2YgbWliIG9iamVj dHM6DQpkb2NzSWZVcENoYW5uZWxSb3dTdGF0dXMgYW5kIGRvY3NJZlVwQ2hhbm5lbENsb25lRnJv bSANCnNvdXJjZSBjb21tZW50IGFyZSBpbiBJUENETiBsb2dzOg0KDQpbaXBjZG5dIFJFOiBDaGFu bmVsIFR5cGVzIGluIFJGTUlCdjIgICh3YXMgUkU6IERPQ1NJUyAyLjAgOiBydWxlcyBmb3IgICBh c3NpZ25pbmcgbW9kdWxhdGlvbiBwcm9maWxlcyB0byB1cHN0cmVhbSBjaGFubmVscykiDQoNCg0K IA0KUHJvcG9zZWQgbmV3IGRlc2NyaXB0aW9ucyBmb3IgY3VycmVudCBNSUIgb2JqZWN0czoNCg0K DQpkb2NzSWZDbXRzTW9kdWxhdGlvbkVudHJ5IE9CSkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAg ICAgIERvY3NJZkNtdHNNb2R1bGF0aW9uRW50cnkNCiAgICAgICAgTUFYLUFDQ0VTUyAgbm90LWFj Y2Vzc2libGUNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgICBERVNDUklQVElP Tg0KICAgICAgICAgICAgIkRlc2NyaWJlcyBhIG1vZHVsYXRpb24gcHJvZmlsZSBmb3IgYW4gSW50 ZXJ2YWwgVXNhZ2UgQ29kZQ0KICAgICAgICAgICAgIGZvciBvbmUgb3IgbW9yZSB1cHN0cmVhbSBj aGFubmVscy4NCiAgICAgICAgICAgICBFbnRyaWVzIGluIHRoaXMgdGFibGUgYXJlIGNyZWF0ZWQg YnkgdGhlIG9wZXJhdG9yLiBJbml0aWFsDQogICAgICAgICAgICAgZGVmYXVsdCBlbnRyaWVzIG1h eSBiZSBjcmVhdGVkIGF0IHN5c3RlbSBpbml0aWFsaXphdGlvbg0KICAgICAgICAgICAgIHRpbWUu IE5vIGluZGl2aWR1YWwgb2JqZWN0cyBoYXZlIHRvIGJlIHNwZWNpZmllZCBpbiBvcmRlcg0KICAg ICAgICAgICAgIHRvIGNyZWF0ZSBhbiBlbnRyeSBpbiB0aGlzIHRhYmxlLg0KICAgICAgICAgICAg IE5vdGUgdGhhdCBzb21lIG9iamVjdHMgZG8gbm90IGhhdmUgREVGVkFMcywgYnV0IGRvIGhhdmUN CiAgICAgICAgICAgICBjYWxjdWxhdGVkIGRlZmF1bHRzIGFuZCBuZWVkIG5vdCBiZSBzcGVjaWZp ZWQgZHVyaW5nIHJvdw0KICAgICAgICAgICAgIGNyZWF0aW9uLg0KICAgICAgICAgICAgIFRoZXJl IGlzIG5vIHJlc3RyaWN0aW9uIG9uIHRoZSBjaGFuZ2luZyBvZiB2YWx1ZXMgaW4gdGhpcw0KICAg ICAgICAgICAgIHRhYmxlIHdoaWxlIHRoZWlyIGFzc29jaWF0ZWQgcm93cyBhcmUgYWN0aXZlIHdp dGggdGhlIA0KICAgICAgICAgICAgIGV4Y2VwdGlvbiBvZjoNCiAgICAgICAgICAgICANCiAgICAg ICAgICAgICAxLiAgSWYgYSBtb2R1bGF0aW9uIHByb2ZpbGUgaXMgaW4gdXNlIGJ5IG9uZSBvciBt b3JlIHVwc3RyZWFtIA0KICAgICAgICAgICAgICAgICBjaGFubmVscywgdGhlIHZhbHVlIG9mIGRv Y3NJZkNtdHNNb2RDaGFubmVsVHlwZSBNVVNUIE5PVCANCiAgICAgICAgICAgICAgICAgYmUgY2hh bmdlZA0KICAgICAgICAgICAgIDIuICBJZiBhIG1vZHVsYXRpb24gcHJvZmlsZSBpcyBpbiB1c2Ug Ynkgb25lIG9yIG1vcmUgdXBzdHJlYW0gDQogICAgICAgICAgICAgICAgIGNoYW5uZWxzLCBpdCBk b2NzSWZDbXRzTW9kQ29udHJvbCBNVVNUIE5PVCBiZSBzZXQgdG8gDQogICAgICAgICAgICAgICAg ICdkZXN0cm95JyBvciAnbm90SW5TZXJ2aWNlJy4iDQogICAgICAgIElOREVYIHsgZG9jc0lmQ210 c01vZEluZGV4LCBkb2NzSWZDbXRzTW9kSW50ZXJ2YWxVc2FnZUNvZGV9DQogICAgICAgIDo6PSB7 IGRvY3NJZkNtdHNNb2R1bGF0aW9uVGFibGUgMSB9DQoNCg0KZG9jc0lmVXBDaGFubmVsTW9kdWxh dGlvblByb2ZpbGUgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFYICAgICAgVW5zaWduZWQzMg0K ICAgICAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZQ0KICAgICAgICBTVEFUVVMgICAgICBjdXJy ZW50DQogICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiQW4gZW50cnkgaWRlbnRpY2Fs IHRvIHRoZSBkb2NzSWZNb2RJbmRleCBpbiB0aGUNCiAgICAgICAgICAgICBkb2NzSWZDbXRzTW9k dWxhdGlvblRhYmxlIHRoYXQgZGVzY3JpYmVzIHRoaXMgY2hhbm5lbC4NCiAgICAgICAgICAgICBU aGlzIGNoYW5uZWwgaXMgZnVydGhlciBpbnN0YW50aWF0ZWQgdGhlcmUgYnkgYSBncm91cGluZw0K ICAgICAgICAgICAgIG9mIGludGVydmFsIHVzYWdlIGNvZGVzIChJVUNzKSB3aGljaCB0b2dldGhl ciBmdWxseSBkZXNjcmliZSANCiAgICAgICAgICAgICB0aGUgY2hhbm5lbCBtb2R1bGF0aW9uLiBU aGlzIG9iamVjdCByZXR1cm5zIDAgaWYgdGhlDQogICAgICAgICAgICAgZG9jc0lmQ210c01vZHVs YXRpb25UYWJsZSBlbnRyeSBkb2VzIG5vdCBleGlzdCBvcg0KICAgICAgICAgICAgIGRvY3NJZkNt dHNNb2R1bGF0aW9uVGFibGUgaXMgZW1wdHkuIFNlZQ0KICAgICAgICAgICAgIHRoZSBhc3NvY2lh dGVkIGNvbmZvcm1hbmNlIG9iamVjdCBmb3Igd3JpdGUgY29uZGl0aW9ucw0KICAgICAgICAgICAg IGFuZCBsaW1pdGF0aW9ucy4NCiAgICAgICAgICAgICANCiAgICAgICAgICAgICBTZXR0aW5nIHRo aXMgb2JqZWN0IE1VU1QgcmV0dXJuIGFuIGVycm9yIGlmIHRoZSBmb2xsb3dpbmcgDQogICAgICAg ICAgICAgY29uZGl0aW9ucyBhcmUgbm90IHNhdGlzZmllZDoNCiAgICAgICAgICAgICAxLiBBbGwg dGhlIElVQyBlbnRyaWVzIGluIHRoZSBzZWxlY3RlZCBtb2R1bGF0aW9uIHByb2ZpbGUgDQogICAg ICAgICAgICAgTVVTVCBoYXZlIHRoZSBzYW1lIHZhbHVlIG9mIGRvY3NJZkNtdHNNb2RDaGFubmVs VHlwZS4gDQogICAgICAgICAgICAgMi4gQWxsIG9mIHRoZSBtb2R1bGF0aW9uIHBhcmFtZXRlcnMg aW4gdGhlIHNlbGVjdGVkIA0KICAgICAgICAgICAgIG1vZHVsYXRpb24gcHJvZmlsZSBNVVNUIGJl IGNvbnNpc3RlbnQgd2l0aCB0aGUgb3RoZXIgDQogICAgICAgICAgICAgcGFyYW1ldGVycyBpbiB0 aGlzIGRvY3NJZlVwQ2hhbm5lbEVudHJ5LiANCiAgICAgICAgUkVGRVJFTkNFDQogICAgICAgICAg ICAiRGF0YS1PdmVyLUNhYmxlIFNlcnZpY2UgSW50ZXJmYWNlIFNwZWNpZmljYXRpb25zOiBSYWRp bw0KICAgICAgICAgICAgIEZyZXF1ZW5jeSBJbnRlcmZhY2UgU3BlY2lmaWNhdGlvbiBTUC1SRkl2 Mi4wLUkwNC0wMzA3MzAsDQogICAgICAgICAgICAgVGFibGUgOC0xOS4iDQogICAgICAgIDo6PSB7 IGRvY3NJZlVwc3RyZWFtQ2hhbm5lbEVudHJ5IDQgfQ0KDQpkb2NzSWZVcENoYW5uZWxUeXBlIE9C SkVDVC1UWVBFDQogICAgICAgIFNZTlRBWCAgICAgIERvY3Npc1Vwc3RyZWFtVHlwZQ0KICAgICAg ICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAg ICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICJSZWZsZWN0cyB0aGUgVXBzdHJlYW0gY2hh bm5lbCB0eXBlLiANCiAgICAgICAgICAgICBUaGlzIG9iamVjdCByZXR1cm5zIHRoZSB2YWx1ZSBv ZiBkb2NzSWZDbXRzTW9kQ2hhbm5lbFR5cGUNCiAgICAgICAgICAgICBmb3IgdGhlIE1vZHVsYXRp b24gUHJvZmlsZSBzZWxlY3RlZCBpbiANCiAgICAgICAgICAgICBkb2NzSWZVcENoYW5uZWxNb2R1 bGF0aW9uUHJvZmlsZSBmb3IgdGhpcyByb3cuIg0KICAgICAgICBSRUZFUkVOQ0UNCiAgICAgICAg ICAgICJEYXRhLU92ZXItQ2FibGUgU2VydmljZSBJbnRlcmZhY2UgU3BlY2lmaWNhdGlvbnM6IFJh ZGlvDQogICAgICAgICAgICAgRnJlcXVlbmN5IEludGVyZmFjZSBTcGVjaWZpY2F0aW9uIFNQLVJG SXYyLjAtSTA0LTAzMDczMCwNCiAgICAgICAgICAgICBTZWN0aW9uIDYuMi4xLiINCiAgICAgICAg Ojo9IHsgZG9jc0lmVXBzdHJlYW1DaGFubmVsRW50cnkgMTUgfQ0KICAgICAgICANCmRvY3NJZkNt dHNNb2RDaGFubmVsVHlwZSAgICAgICAgICAgICAgT0JKRUNULVRZUEUNCiAgICAgICAgU1lOVEFY ICAgICAgRG9jc2lzVXBzdHJlYW1UeXBlDQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRl DQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04NCiAgICAg ICAgICAgICJEZXNjcmliZXMgdGhlIG1vZHVsYXRpb24gY2hhbm5lbCB0eXBlIGZvciB0aGlzIG1v ZHVsYXRpb24NCiAgICAgICAgICAgICBlbnRyeS4NCiAgICAgICAgICAgICBJbiBvcmRlciB0byBi ZSBjb25zaWRlcmVkIGEgdmFsaWQgbW9kdWxhdGlvbiBwcm9maWxlIGZvciANCiAgICAgICAgICAg ICBhc3NpZ25tZW50IHRvIGFuIHVwc3RyZWFtIGNoYW5uZWwsIGFsbCBlbnRyaWVzIChJVUNzKSBp bg0KICAgICAgICAgICAgIHRoZSBtb2R1bGF0aW9uIHByb2ZpbGUgbXVzdCBoYXZlIHRoZSBzYW1l IGNoYW5uZWwgdHlwZS4iDQogICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgIkRhdGEtT3Zl ci1DYWJsZSBTZXJ2aWNlIEludGVyZmFjZSBTcGVjaWZpY2F0aW9uczogUmFkaW8NCiAgICAgICAg ICAgICBGcmVxdWVuY3kgSW50ZXJmYWNlIFNwZWNpZmljYXRpb24gU1AtUkZJdjIuMC1JMDQtMDMw NzMwLA0KICAgICAgICAgICAgIFRhYmxlIDgtMTkuIg0KICAgICAgICBERUZWQUwgeyB0ZG1hIH0N CiAgICAgICAgOjo9IHsgZG9jc0lmQ210c01vZHVsYXRpb25FbnRyeSAyMSB9ICAgICAgICANCg0K cmV2aXNpb24gMSBBZGRzDQoNCg0KDQpkb2NzSWZVcENoYW5uZWxTdGF0dXMgT0JKRUNULVRZUEUN CiAgICAgICAgU1lOVEFYICAgICAgUm93U3RhdHVzDQogICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQt Y3JlYXRlDQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVTQ1JJUFRJT04N CiAgICAgICAgICAgICJUaGlzIG9iamVjdCBpcyBnZW5lcmFsbHkgaW50ZW5kZWQgdG8gYmUgdXNl ZCBmb3IgdGhlDQogICAgICAgICAgICAgY3JlYXRpb24gb2YgYSB0ZW1wb3JhcnkgdXBzdHJlYW0g cm93IGZvciB0aGUgcHVycG9zZSBvZiANCiAgICAgICAgICAgICBhZGp1c3RpbmcgY2hhbm5lbCBw YXJhbWV0ZXJzIG9mIGEgcGVybWFuZW50IHVwc3RyZWFtIGNoYW5uZWwgDQogICAgICAgICAgICAg cm93LiANCg0KICAgICAgICAgICAgIFRoZSBmb2xsb3dpbmcgcmVzdHJpY3Rpb25zIGFwcGx5IHRv IHRoaXMgb2JqZWN0Og0KICAgICAgICAgICAgIDEpIEVudHJpZXMgd2l0aCBkb2NzSWZVcENoYW5u ZWxTdGF0dXMgc2V0IHRvIGFjdGl2ZSgxKSANCiAgICAgICAgICAgICAgICBhcmUgbG9naWNhbGx5 IGxpbmtlZCB0byBhIHBoeXNpY2FsIGludGVyZmFjZSwgDQogICAgICAgICAgICAgICAgbm90IHRl bXBvcmFyaWx5IGNyZWF0ZWQgdG8gY2xvbmUgcGFyYW1ldGVycw0KICAgICAgICAgICAgIDIpIEEg c3RhdHVzIHRyYW5zaXRpb24gZnJvbSBhY3RpdmUgKDEpIHRvIG5vdEluU2VydmljZSgyKSANCiAg ICAgICAgICAgICAgICBvciBkZXN0cm95ICg2KSBpcyBub3QgcGVybWl0dGVkLg0KICAgICAgICAg ICAgICAgIFRoZSBJbnRlcmZhY2UgTUlCIFtSRkMyODYzXSBpZkFkbWluU3RhdHVzIHNob3VsZCBi ZQ0KICAgICAgICAgICAgICAgIHVzZWQgdG8gdGFrZSBhbiBVcHN0cmVhbSBDaGFubmVsIG9mZmxp bmUuDQogICAgICAgICAgICAgMykgVGVtcG9yYXJ5IHJvd3MgbXVzdCBiZSBjcmVhdGVkIHVzaW5n IGNyZWF0ZUFuZFdhaXQoNSkuDQogICAgICAgICAgICAgNCkgVGhlIG9ubHkgcG9zc2libGUgc3Rh dHVzIGNoYW5nZSBvZiBhIHJvdyBjcmVhdGVkIHVzaW5nDQogICAgICAgICAgICAgICAgY3JlYXRl QW5kV2FpdCg1KSAoaWUgbm90SW5TZXJ2aWNlKDIpIG9yIG5vdFJlYWR5KDMpKSBpcyANCiAgICAg ICAgICAgICAgICB0byBkZXN0cm95KDYpLg0KICAgICAgICAgICAgICAgIFRoZXNlIHRlbXBvcmFy eSByb3dzIG11c3QgbmV2ZXIgYmUgZ2l2ZW4gdGhlIFN0YXR1cyANCiAgICAgICAgICAgICAgICBh Y3RpdmUoMSkuDQoNCiAgICAgICAgICAgICBBIG1hbmRhdG9yeSBwcm9jZWR1cmUgZm9yIGFkanVz dGluZyBhbiBzcGVjaWZpYyByb3cgaXM6DQogICAgICAgICAgICAgMSkgQ3JlYXRlIGEgdGVtcG9y YXJ5IHJvdyB0aHJvdWdoIGFuIFNOTVAgU0VUIHVzaW5nDQogICAgICAgICAgICAgICAgY3JlYXRl QW5kV2FpdCg1KS4gVXNlIGFuIGlmSW5kZXggdmFsdWUgb3V0c2lkZSB0aGUNCiAgICAgICAgICAg ICAgICBvcGVyYXRpb25hbCByYW5nZSBvZiB0aGUgc3lzdGVtLg0KICAgICAgICAgICAgIDIpIFNl dCB0aGUgZG9jc0lmVXBDaGFubmVsQ2xvbmVGcm9tIGZpZWxkIHRvIHRoZSBpZkluZGV4DQogICAg ICAgICAgICAgICAgdmFsdWUgb2YgdGhlIGFjdGl2ZSByb3cgd2hvc2UgcGFyYW1ldGVycyByZXF1 aXJlDQogICAgICAgICAgICAgICAgYWRqdXN0bWVudC4NCiAgICAgICAgICAgICAzKSBBZGp1c3Qg dGhlIHBhcmFtZXRlciB2YWx1ZXMgdXNpbmcgdGhlIG5ldw0KICAgICAgICAgICAgICAgIHRlbXBv cmFyeSByb3cuIEVuc3VyZSBhbGwgcGFyYW1ldGVycyBjb250YWluDQogICAgICAgICAgICAgICAg ZGVzaXJlZCB2YWx1ZXMgYmVmb3JlIHByb2NlZWRpbmcgdG8gc3RlcCA0Lg0KICAgICAgICAgICAg IDQpIFVwZGF0ZSB0aGUgcGVybWFuZW50IHJvdyBieSBzZXR0aW5nIG9iamVjdA0KICAgICAgICAg ICAgICAgIGRvY3NJZlVwQ2hhbm5lbFVwZGF0ZSB0byBUUlVFLiBUaGlzIFNFVCB3aWxsIGZhaWwg aWYNCiAgICAgICAgICAgICAgICB0aGUgYWRqdXN0ZWQgcGFyYW1ldGVycyBhcmUgbm90IGNvbXBh dGlibGUgd2l0aA0KICAgICAgICAgICAgICAgIGVhY2ggb3RoZXIuDQogICAgICAgICAgICAgNSkg RGVsZXRlIHRoZSB0ZW1wb3Jhcnkgcm93IHRocm91Z2ggYW4gU05NUCBTRVQgdXNpbmcNCiAgICAg ICAgICAgICAgICBERUxFVEUuDQogICAgICAgIDo6PSB7IGRvY3NJZlVwc3RyZWFtQ2hhbm5lbEVu dHJ5IDE4IH0NCg0KDQoNCg0KZG9jc0lmVXBDaGFubmVsQ2xvbmVGcm9tIE9CSkVDVC1UWVBFDQog ICAgICAgIFNZTlRBWCAgICAgIEludGVyZmFjZUluZGV4T3JaZXJvDQogICAgICAgIE1BWC1BQ0NF U1MgIHJlYWQtY3JlYXRlDQogICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICAgREVT Q1JJUFRJT04NCiAgICAgICAgICAgICJJbnRlbmRlZCBmb3IgdXNlIHdoZW4gYSB0ZW1wb3Jhcnkg dXBzdHJlYW0gdGFibGUgcm93IGlzIGNyZWF0ZWQgDQogICAgICAgICAgICAgZm9yIHRoZSBwdXJw b3NlIG9mIG1hbmlwdWxhdGluZyBwYXJhbWV0ZXJzIGZvciBhIHBlcm1hbmVudCANCiAgICAgICAg ICAgICB1cHN0cmVhbSBjaGFubmVsLiAgUmVmZXIgdG8gdGhlIGRlc2NyaXB0aW9ucyBvZg0KICAg ICAgICAgICAgIGRvY3NJZlVwQ2hhbm5lbFN0YXR1cyBhbmQgZG9jc0lmVXBDaGFubmVsVXBkYXRl IGZvciBkZXRhaWxzIG9mIA0KICAgICAgICAgICAgIHRoaXMgcHJvY2VkdXJlLg0KDQogICAgICAg ICAgICAgVGhpcyBvYmplY3QgY29udGFpbnMgdGhlIGlmSW5kZXggdmFsdWUgb2YgdGhlIA0KICAg ICAgICAgICAgIHBlcm1hbmVudCB1cHN0cmVhbSByb3cgd2hvc2UgcGFyYW1ldGVycyBhcmUgdG8g YmUgYWRqdXN0ZWQuIFVwb24gDQogICAgICAgICAgICAgc2V0dGluZyB0aGlzIG9iamVjdCwgdGhl IHZhbHVlcyBvZiBkb2NzSWZVcENoYW5uZWxGcmVxdWVuY3ksIA0KICAgICAgICAgICAgIGRvY3NJ ZlVwQ2hhbm5lbFdpZHRoLCBkb2NzSWZVcENoYW5uZWxNb2R1bGF0aW9uUHJvZmlsZSwgDQogICAg ICAgICAgICAgZG9jc0lmVXBDaGFubmVsU2xvdFNpemUsIGRvY3NJZlVwQ2hhbm5lbFJhbmdpbmdC YWNrb2ZmU3RhcnQsIA0KICAgICAgICAgICAgIGRvY3NJZlVwQ2hhbm5lbFJhbmdpbmdCYWNrb2Zm RW5kLCBkb2NzSWZVcENoYW5uZWxUeEJhY2tvZmZTdGFydCwgDQogICAgICAgICAgICAgZG9jc0lm VXBDaGFubmVsVHhCYWNrb2ZmRW5kLCBkb2NzSWZVcENoYW5uZWxTY2RtYUFjdGl2ZUNvZGVzLCAN CiAgICAgICAgICAgICBkb2NzSWZVcENoYW5uZWxTY2RtYUNvZGVzUGVyU2xvdCwgZG9jc0lmVXBD aGFubmVsU2NkbWFGcmFtZVNpemUsIA0KICAgICAgICAgICAgIGRvY3NJZlVwQ2hhbm5lbFNjZG1h SG9wcGluZ1NlZWQsIGRvY3NJZlVwQ2hhbm5lbFR5cGUsIGFuZA0KICAgICAgICAgICAgIGRvY3NJ ZlVwQ2hhbm5lbFByZUVxRW5hYmxlIGZvciB0aGlzIHJvdyBhcmUgcG9wdWxhdGVkIHdpdGggdGhl IA0KICAgICAgICAgICAgIGNvcnJlc3BvbmRpbmcgdmFsdWVzIGZyb20gdGhlIHJvdyByZWZlcmVu Y2VkIGJ5IHRoaXMgb2JqZWN0Lg0KICAgICAgICAgICAgIFNldGluZyB0aGlzIG9iamVjdCB0byBh IG5vbi1leGlzdGVudCBvciB0ZW1wb3JhcnkgdXBzdHJlYW0gd2lsbCANCiAgICAgICAgICAgICBy ZXR1cm4gdGhlIGVycm9yICd3cm9uZ1ZhbHVlJy4NCg0KICAgICAgICAgICAgIFRoaXMgb2JqZWN0 IG11c3QgY29udGFpbiBhIHZhbHVlIG9mIHplcm8gZm9yIHBlcm1hbmVudCANCiAgICAgICAgICAg ICB1cHN0cmVhbSByb3dzLiINCiAgICAgICAgOjo9IHsgZG9jc0lmVXBzdHJlYW1DaGFubmVsRW50 cnkgMTYgfQ0KDQoNCg== ------_=_NextPart_001_01C38F88.E5372656-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Oct 13 19:35:27 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 TAA05376 for ; Mon, 13 Oct 2003 19:35:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9CDS-0007WR-4C for ipcdn-archive@odin.ietf.org; Mon, 13 Oct 2003 19:35:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DNZ6rC028909 for ipcdn-archive@odin.ietf.org; Mon, 13 Oct 2003 19:35:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9CDN-0007W1-Nj; Mon, 13 Oct 2003 19:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9CCm-0007VG-Az for ipcdn@optimus.ietf.org; Mon, 13 Oct 2003 19:34:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05346 for ; Mon, 13 Oct 2003 19:34:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9CCk-00034P-00 for ipcdn@ietf.org; Mon, 13 Oct 2003 19:34:22 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx with esmtp (Exim 4.12) id 1A9CCj-000348-00 for ipcdn@ietf.org; Mon, 13 Oct 2003 19:34:22 -0400 Received: from comcast.net (h00045af3c79a.ne.client2.attbi.com[24.128.28.68]) by comcast.net (rwcrmhc12) with SMTP id <20031013233350014009loghe> (Authid: sawyerwd); Mon, 13 Oct 2003 23:33:50 +0000 Message-ID: <3F8B36AD.C851389E@comcast.net> Date: Mon, 13 Oct 2003 19:35:09 -0400 From: Wilson Sawyer X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipcdn@ietf.org CC: harrie@lisanza.net, bwijnen@lucent.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] DOCSIS subscriber Management MIB: tie to diffpolicy? 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: 7bit I need some advice from the working group on tying the DOCSIS subscriber management MIB to the Diffserv Configuration MIB: > Harrie Hazewinkel wrote: > Maybe in order for a management application to retrieve the default > filter a single object is needed with syntax type 'RowPointer' > that points to the start of the filter in the DIFFSERV-MIB. > For more information look at draft-ietf-snmpconf-diffpolicy-08.txt it > is a draft for diffserv configation there we have templates for > configuration. You could even use the single table there as is. > Just briefly scanning the diffpolicy i-d, it looks kind of cool as a way to document the (DOCSIS) use of the diffserv MIB. It presents us with some trade-offs though: (1) including a reference to it would tie the publication schedule of this i-d to it. Harrie says that it's in IETF last call, so this might be acceptable. (2) replicating the information into the submgt i-d unlinks the publication schedule, but has the usual drawbacks of duplicate MIBs. (3) If omitted, it could still be referenced by the Docsis OSS spec (once published as an RFC with a real MIB root). This would lose the visibility from the submgt i-d document, though. What is the sense of the working group? - Wilson Sawyer _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Oct 14 11:17:27 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 LAA14271 for ; Tue, 14 Oct 2003 11:17:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Qv3-0004s2-Rd for ipcdn-archive@odin.ietf.org; Tue, 14 Oct 2003 11:17:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EFH5bx018719 for ipcdn-archive@odin.ietf.org; Tue, 14 Oct 2003 11:17:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Qv0-0004rf-0A; Tue, 14 Oct 2003 11:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Qus-0004rP-8B for ipcdn@optimus.ietf.org; Tue, 14 Oct 2003 11:16:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14262 for ; Tue, 14 Oct 2003 11:16:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Qur-00041W-00 for ipcdn@ietf.org; Tue, 14 Oct 2003 11:16:53 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A9Quq-00041R-00 for ipcdn@ietf.org; Tue, 14 Oct 2003 11:16:52 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9EFGIY03185 for ; Tue, 14 Oct 2003 10:16:19 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3WN8ZF>; Tue, 14 Oct 2003 17:16:15 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502B4265C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Date: Tue, 14 Oct 2003 17:16:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.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: , Did I review this one before? I need to dive into my archives to check, but it feels like I did. Anyway, here is comments based on my first quick check. I need to look some more into this document, so consider this review incomplete. 1. When compiling (for SYNTAX checking) with SMICng I get: W: f(bpiplus.mi2), (104,22) Revision date not in proper order - most recent comes first 2. WHen I compile (syntax check) with smilint I get: .\DOCS-IETF-BPI2-MIB:3076: [4] {compliance-group-status} warning: current compliance statement `docsBpi2CmtsCompliance' includes obsolete group `docsBpi2ObsoleteObjectsGroup' 3. Checking with checkpage.awk I get: $ /bin/checkpage.awk < drafts/draft-ietf-ipcdn-bpiplus-mib-11.txt Bad chars at 3899 Bad chars at 3907 Bad chars at 4189 -: 3 lines containing non-US-ASCII characters 4. Since this is a very first (formal) publication (as RFC) of this MIB module, the tradition (and guideline) is to have one and only one REVISION clause. I see that you have instructions to RFC editor to remove the extra one. WHy not just remove them now (or move them to an appendix to be removed later). 5. In the following, I see that the DESCRIPTION clause is out of sync with the actual enumrations ??!!: DocsBpkmSAType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of this object is the type of security association. The values of the named-numbers are associated with the BPKM SA-Type attributes: 'primary' corresponds to code '0', 'static' to code '1' 'dynamic' to code '2'. 'none' value must only be used if the SA type has yet to be determined. " REFERENCE "DOCSIS Baseline Privacy Plus Interface specification, Section 4.2.2.24" SYNTAX INTEGER { none(0), primary(1), static(2), dynamic(3) } Or are the "code '0'" different codes at some other place. If that is the case, then maybe the ENUMs should sync up with those codes. no? Technical issues/questions a. I am not sure I understand the relationship between RFC3083 and this I-D. Would a device implement both MIB modules? - If not, does that mean that this MIB Module obsoletes the MIB in 3083? If so it needs to be specified. And if it does obsolte 3083, then the normal process would be to deprecate/obsolete pieces in 3083 that are no longer used and to add new objects that are new, but keep the old one. This method does work too... and I think is acceptable as long as we do so consciously. - If yes, I see a lot of duplication and I wonder if that is good, in fact I doubt it. In any event, it would be wise to document the relationship between these documents better than currently done in the overview section b. I do not understand why one is Unsigned32 and the other Integer32 docsBpi2CmTEKSAId OBJECT-TYPE SYNTAX Unsigned32 (1..16383) docsBpi2CmIpMulticastSAId OBJECT-TYPE SYNTAX Integer32 (0..16383) docsBpi2CmtsAuthPrimarySAId OBJECT-TYPE SYNTAX Integer32 (0..16383) docsBpi2CmtsTEKSAId OBJECT-TYPE SYNTAX Unsigned32 (1..16383) docsBpi2CmtsIpMulticastSAId OBJECT-TYPE SYNTAX Integer32 (0..16383) docsBpi2CmtsMulticastAuthSAId OBJECT-TYPE SYNTAX Unsigned32 (1..16383) Oh well, a couple of TCs seems justified too, maybe a DocsSAId and a DocsSAIdOrNone (or DocsSAIdOrZero) TC c. Administrative comments and NITs: - Why is there a reference to RFC2819? - Since you import from docsIfMib (RFC2670), you must have a normative reference to RFC2670 - Since you import from IF-MIB, you must have a normative reference to RFC2863 - I see no citations to RFC3414 and RFC3415, neither do I see any IMPORTS from those RFCs. So I do not see why they are in the references section at all, let alone in the normative references section - In section 2, I recommend to use "MIB module" instead of "MIB" It occures several times. This to recognize that there is only one (single) MIB that is composed of mul;tiple MIB modules. - docsBpi2ObsoleteObjectsGroup OBJECT-GROUP Pls add to DESCRIPTION why this is/was obsoleted. - Your MODULE-COMPLIANCE says that an implementation is only required to support IPv4. You may want to add to the DESCRIPTION clause(s) why only IPv4 (or why not IPv6) needs to be supported. Thanks, Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Oct 14 12:31:24 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 MAA18193 for ; Tue, 14 Oct 2003 12:31:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9S4d-0000gy-Iw for ipcdn-archive@odin.ietf.org; Tue, 14 Oct 2003 12:31:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EGV3mr002660 for ipcdn-archive@odin.ietf.org; Tue, 14 Oct 2003 12:31:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9S4c-0000gj-07; Tue, 14 Oct 2003 12:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9S3z-0000eW-G2 for ipcdn@optimus.ietf.org; Tue, 14 Oct 2003 12:30:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18142 for ; Tue, 14 Oct 2003 12:30:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9S3x-00053C-00 for ipcdn@ietf.org; Tue, 14 Oct 2003 12:30:21 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A9S3w-00052U-00 for ipcdn@ietf.org; Tue, 14 Oct 2003 12:30:21 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9EGTl10021694; Tue, 14 Oct 2003 10:29:48 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt Date: Tue, 14 Oct 2003 10:29:47 -0600 Message-ID: Thread-Topic: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt Thread-Index: AcOSZlY5L6H4uayBSMuzaTPspJBqYAACX9zQ From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" 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 Thanks Bert,=20 You already did extensive comments in this mib in the past months. As clean (we though) as it becomes you amazingly find more details. :)=20 We will reply shortly with actions. Eduardo -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Tuesday, October 14, 2003 9:16 AM To: Ipcdn (E-mail) Subject: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt Did I review this one before? I need to dive into my archives=20 to check, but it feels like I did. Anyway, here is comments based on my first quick check. I need to look some more into this document, so consider this review incomplete. 1. When compiling (for SYNTAX checking) with SMICng I get: W: f(bpiplus.mi2), (104,22) Revision date not in proper order - most recent comes first 2. WHen I compile (syntax check) with smilint I get: .\DOCS-IETF-BPI2-MIB:3076: [4] {compliance-group-status} warning: current compliance statement `docsBpi2CmtsCompliance' includes obsolete group `docsBpi2ObsoleteObjectsGroup' 3. Checking with checkpage.awk I get: $ /bin/checkpage.awk < drafts/draft-ietf-ipcdn-bpiplus-mib-11.txt Bad chars at 3899 Bad chars at 3907 Bad chars at 4189 -: 3 lines containing non-US-ASCII characters 4. Since this is a very first (formal) publication (as RFC) of this MIB module, the tradition (and guideline) is to have one and only one REVISION clause. I see that you have instructions to RFC editor to remove the extra one. WHy not just remove them now (or move them to an appendix to be removed later). 5. In the following, I see that the DESCRIPTION clause is out of sync with the actual enumrations ??!!: DocsBpkmSAType ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of this object is the type of security association. The values of the named-numbers are associated with the BPKM SA-Type attributes: 'primary' corresponds to code '0', 'static' to code '1' 'dynamic' to code '2'. 'none' value must only be used if the SA type has yet to be determined. " REFERENCE "DOCSIS Baseline Privacy Plus Interface specification, Section 4.2.2.24" SYNTAX INTEGER { none(0), primary(1), static(2), dynamic(3) } Or are the "code '0'" different codes at some other place. If that is the case, then maybe the ENUMs should sync up with those codes. no? Technical issues/questions a. I am not sure I understand the relationship between RFC3083 and this I-D. Would a device implement both MIB modules? - If not, does that mean that this MIB Module obsoletes the MIB in 3083? If so it needs to be specified. And if it does obsolte 3083, then the normal process would be to deprecate/obsolete pieces in 3083 that are no longer used and to add new objects that are new, but keep the old one.=20 This method does work too... and I think is acceptable as long as we do so consciously. - If yes, I see a lot of duplication and I wonder if that is good, in fact I doubt it. In any event, it would be wise to document the relationship between these documents better than currently done in the overview section b. I do not understand why one is Unsigned32 and the other Integer32 docsBpi2CmTEKSAId OBJECT-TYPE SYNTAX Unsigned32 (1..16383) docsBpi2CmIpMulticastSAId OBJECT-TYPE SYNTAX Integer32 (0..16383) docsBpi2CmtsAuthPrimarySAId OBJECT-TYPE SYNTAX Integer32 (0..16383) docsBpi2CmtsTEKSAId OBJECT-TYPE SYNTAX Unsigned32 (1..16383) docsBpi2CmtsIpMulticastSAId OBJECT-TYPE SYNTAX Integer32 (0..16383) docsBpi2CmtsMulticastAuthSAId OBJECT-TYPE SYNTAX Unsigned32 (1..16383) Oh well, a couple of TCs seems justified too, maybe a DocsSAId and a DocsSAIdOrNone (or DocsSAIdOrZero) TC c. Administrative comments and NITs: - Why is there a reference to RFC2819? - Since you import from docsIfMib (RFC2670), you must have a normative reference to RFC2670 - Since you import from IF-MIB, you must have a normative reference to RFC2863 - I see no citations to RFC3414 and RFC3415, neither do I see any IMPORTS from those RFCs. So I do not see why they are in the references section at all, let alone in the normative references section - In section 2, I recommend to use "MIB module" instead of "MIB" It occures several times. This to recognize that there is=20 only one (single) MIB that is composed of mul;tiple MIB modules. - docsBpi2ObsoleteObjectsGroup OBJECT-GROUP Pls add to DESCRIPTION why this is/was obsoleted. - Your MODULE-COMPLIANCE says that an implementation is only required to support IPv4. You may want to add to the DESCRIPTION=20 clause(s) why only IPv4 (or why not IPv6) needs to be supported. Thanks, Bert=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Oct 14 21:22:29 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 VAA12631 for ; Tue, 14 Oct 2003 21:22:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9aMZ-0001VC-Pi for ipcdn-archive@odin.ietf.org; Tue, 14 Oct 2003 21:22:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F1M7Rm005771 for ipcdn-archive@odin.ietf.org; Tue, 14 Oct 2003 21:22:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9aMT-0001Ut-Pd; Tue, 14 Oct 2003 21:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9aLz-0001UV-Nl for ipcdn@optimus.ietf.org; Tue, 14 Oct 2003 21:21:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12606 for ; Tue, 14 Oct 2003 21:21:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9aLw-0004fO-00 for ipcdn@ietf.org; Tue, 14 Oct 2003 21:21:29 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1A9aLw-0004fC-00 for ipcdn@ietf.org; Tue, 14 Oct 2003 21:21:28 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9F1Km10013284; Tue, 14 Oct 2003 19:20:48 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] DOCSIS subscriber Management MIB: tie to diffpolicy? Date: Tue, 14 Oct 2003 19:20:48 -0600 Message-ID: Thread-Topic: [ipcdn] DOCSIS subscriber Management MIB: tie to diffpolicy? Thread-Index: AcOR4r7UeQ7rxtIPQdOn6oGwDFznJwAgs4Iw From: "Eduardo Cardona" To: "Wilson Sawyer" , Cc: , 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 Wilson,=20 good point,=20 I think=20 3) would be ok if the time frame to not depend on the I-d publication.=20 Also extra hints to how to integrate the policy in DOCSIS will be required (?) as a further spec work (requiring subMgt RFC as MUST ) as well as ATPs changes. It might be good to have some sort of annex or appendix in the spec to deal with DiffServ / DiffServ Mib / diffserv PolicyMib DOCSIS requirements and informational hooks. The current submgt ID could be short to accomplish that. I know seems to me that the submgmt mib is disconnected of how to implement the DiffServ Templates and the Policy Mib is the ultimate solution, based on the RO compliances of Diffserv mib, but?=20 Did I understand your motivations? Or maybe a text draft of what you are thinking of would be a good starting point. Thanks=20 Eduardo =20 -----Original Message----- From: Wilson Sawyer [mailto:sawyerwd@comcast.net]=20 Sent: Monday, October 13, 2003 5:35 PM To: ipcdn@ietf.org Cc: harrie@lisanza.net; bwijnen@lucent.com Subject: [ipcdn] DOCSIS subscriber Management MIB: tie to diffpolicy? I need some advice from the working group on tying the DOCSIS subscriber management MIB to the Diffserv Configuration MIB: > Harrie Hazewinkel wrote: > Maybe in order for a management application to retrieve the default=20 > filter a single object is needed with syntax type 'RowPointer' that=20 > points to the start of the filter in the DIFFSERV-MIB. For more=20 > information look at draft-ietf-snmpconf-diffpolicy-08.txt it is a=20 > draft for diffserv configation there we have templates for=20 > configuration. You could even use the single table there as is. > Just briefly scanning the diffpolicy i-d, it looks kind of cool as a way to document the (DOCSIS) use of the diffserv MIB. It presents us with some trade-offs though: (1) including a reference to it would tie the publication schedule of this i-d to it. Harrie says that it's in IETF last call, so this might be acceptable. (2) replicating the information into the submgt i-d unlinks the publication schedule, but has the usual drawbacks of duplicate MIBs. (3) If omitted, it could still be referenced by the Docsis OSS spec (once published as an RFC with a real MIB root). This would lose the visibility from the submgt i-d document, though. What is the sense of the working group? - Wilson Sawyer _______________________________________________ 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 Oct 15 10:03:33 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 KAA00071 for ; Wed, 15 Oct 2003 10:03:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9mF3-00088x-9c for ipcdn-archive@odin.ietf.org; Wed, 15 Oct 2003 10:03:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FE39wx031302 for ipcdn-archive@odin.ietf.org; Wed, 15 Oct 2003 10:03:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9mEv-00088c-Sj; Wed, 15 Oct 2003 10:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9mEY-00088I-3c for ipcdn@optimus.ietf.org; Wed, 15 Oct 2003 10:02:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00046 for ; Wed, 15 Oct 2003 10:02:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9mEV-0004fx-00 for ipcdn@ietf.org; Wed, 15 Oct 2003 10:02:35 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1A9mET-0004ft-00 for ipcdn@ietf.org; Wed, 15 Oct 2003 10:02:33 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h9FE2Umx007707 for ; Wed, 15 Oct 2003 07:02:31 -0700 (MST) Received: from ma07exm01.e6.bcs.mot.com (ma07exm01.e6.bcs.mot.com [10.14.33.191]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h9FE2I3N007561 for ; Wed, 15 Oct 2003 09:02:21 -0500 Received: by ma07exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.2) id <42T69X5R>; Wed, 15 Oct 2003 10:01:56 -0400 Message-ID: <19CD0E423FC1D611893500508B6F0B9CF3985F@ma07exm01.e6.bcs.mot.com> From: Murwin William-LWM008 To: "Docsis-Oss (E-mail) (E-mail)" , "IPCDN (E-mail) (E-mail)" Cc: "Richard Woundy (E-mail)" , Patrick Michael-LZZ007 , "'Eduardo Cardona'" Date: Wed, 15 Oct 2003 10:01:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C39324.2067BDA2" Subject: [ipcdn] Proposed Changes to Section 2.2.2.1 of the DOCS-IETF-QOS-MIB, fro m comments about temp and operational SIDs 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_000_01C39324.2067BDA2 Content-Type: text/plain; charset="iso-8859-1" The following is proposed changes to section 2.2.2.1 of the draft-ietf-ipcdn-qos-mib-09.txt from comments made about temporary and operational SIDs, the sistutation was already taken into account when the draft-ietf-ipcdn-qos-mib-05.txt was sent out, but a couple of changes have been made to avoid future mis-understandings: <> ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 786-7594 ------_=_NextPart_000_01C39324.2067BDA2 Content-Type: application/msword; name="Section2.2.2.1.doc" Content-Disposition: attachment; filename="Section2.2.2.1.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAPwAAAAAAAAAA EAAAQQAAAAEAAAD+////AAAAAD4AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEATSAJBAAA8BK/AAAAAAAAEAAAAAAABAAAgSMAAA4AYmpiauI94j0AAAAAAAAAAAAAAAAAAAAA AAAJBBYAIjgAAIBXAACAVwAAgR8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAANoAAAAAAAAA2gAAANoA AAAAAAAA2gAAAAAAAADaAAAAAAAAANoAAAAAAAAA2gAAABQAAAAAAAAAAAAAAO4AAAAAAAAAhg4A AAAAAACGDgAAAAAAAIYOAAAAAAAAhg4AAAwAAACSDgAARAAAAO4AAAAAAAAAXB0AAPYAAADiDgAA AAAAAOIOAAAAAAAA4g4AAAAAAADiDgAAAAAAAOIOAAAAAAAA4g4AAAAAAADiDgAAAAAAAOIOAAAA AAAAsxwAAAIAAAC1HAAAAAAAALUcAAAAAAAAtRwAAAAAAAC1HAAAAAAAALUcAAAAAAAAtRwAACQA AABSHgAAIAIAAHIgAAC4AAAA2RwAABUAAAAAAAAAAAAAAAAAAAAAAAAA2gAAAAAAAADiDgAAAAAA AAAAAAAAAAAAAAAAAAAAAADiDgAAAAAAAOIOAAAAAAAA4g4AAAAAAADiDgAAAAAAANkcAAAAAAAA ZhQAAAAAAADaAAAAAAAAANoAAAAAAAAA4g4AAAAAAAAAAAAAAAAAAOIOAAAAAAAA7hwAADIAAABm FAAAAAAAAGYUAAAAAAAAZhQAAAAAAADiDgAAMgIAANoAAAAAAAAA4g4AAAAAAADaAAAAAAAAAOIO AAAAAAAAsxwAAAAAAAAAAAAAAAAAAGYUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA4g4AAAAAAACzHAAAAAAAAGYUAADWBQAAZhQAAAAAAAA8GgAA HgAAAGccAAAYAAAA2gAAAAAAAADaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsxwAAAAAAADiDgAAAAAAANYOAAAMAAAAQEZwGSST wwHuAAAAmA0AAIYOAAAAAAAAFBEAAFIDAAB/HAAACAAAAAAAAAAAAAAAsxwAAAAAAAAgHQAAPAAA AFwdAAAAAAAAhxwAACwAAAAqIQAAAAAAAGYUAAAAAAAAKiEAAAAAAACzHAAAAAAAAGYUAAAAAAAA 7gAAAAAAAADuAAAAAAAAANoAAAAAAAAA2gAAAAAAAADaAAAAAAAAANoAAAAAAAAAAgDZAAAAQ3Vy cmVudCBUZXh0IGZyb20gZHJhZnQtaWV0Zi1pcGNkbi1xb3MtbWliLTA4LnR4dDoNDTIuMi4yLjEg IEludGVyb3BlcmF0aW9uIHdpdGggRE9DU0lTIDEuMA0NICAgVGhlIERPQ1NJUyAxLjAgRE9DUy1J Ri1NSUIgWzEwXSBzcGVjaWZpZXMgYSBkb2NzSWZRb3NQcm9maWxlVGFibGUgdG8NICAgZGVzY3Jp YmUgdGhlIHNldCBvZiBDbGFzcyBPZiBTZXJ2aWNlIChDT1MpIHBhcmFtZXRlcnMgYXNzb2NpYXRl ZCB3aXRoDSAgIGEgQ09TICJwcm9maWxlIi4gVGhlIGRvY3NJZkNtU2VydmljZVRhYmxlLCB3aGlj aCBjb250YWlucyBvbmUgZW50cnkNICAgcGVyIFNJRCwgcmVmZXJlbmNlcyB0aGlzIHRhYmxlIHdp dGggYSAgZG9jc0lmQ21TZXJ2aWNlUW9zUHJvZmlsZQ0gICBudW1iZXIuDQ0gICBUaGUgRE9DU0lT IDEuMSBhbmQgMi4wIENNIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGFsbG93cyBhIG1vZGVtIHRvDSAg IHJlZ2lzdGVyIGFzIG9wZXJhdGluZyBlaXRoZXIgd2l0aCBET0NTSVMgMS4wLCBET0NTSVMgMS4x LCBvciBET0NTSVMNICAgMi4wIGZ1bmN0aW9uYWxpdHkuIEZvciBlYXNlIG9mIGV4cHJlc3Npb24s IHdlIGNhbGwgYSBtb2RlbQ0gICByZWdpc3RlcmluZyB3aXRoIERPQ1NJUyAxLjAgZnVuY3Rpb25h bGl0eSBhICJET0NTSVMgMS4wIG1vZGVtIiwNICAgcmVnYXJkbGVzcyBvZiB0aGUgbW9kZW0ncyBj YXBhYmlsaXRpZXMuDQ0gICBBIENNVFMgb3IgQ00gc3VwcG9ydGluZyBib3RoIERPQ1NJUyAxLjAs IERPQ1NJUyAxLjEsIGFuZCBET0NTSVMgMi4wDSAgIGltcGxlbWVudHMgYm90aCB0aGUgdGFibGVz IG9mIFsxMF0gYW5kIHRoZSB0YWJsZXMgb2YgdGhpcyBNSUIuIFRoZQ0gICBpbnRlcm9wZXJhdGlv biBnb2FsIGlzIHRoYXQgYmVmb3JlIG1vZGVtIHJlZ2lzdHJhdGlvbiwgdGhlIERPQ1NJUyAxLjAN ICAgTUlCIFsxMF0gYXBwbGllcy4gQWZ0ZXIgcmVnaXN0cmF0aW9uLCBlaXRoZXIgdGhlIERPQ1NJ UyAxLjAgb3IgRE9DU0lTDSAgIDEuMS8yLjAgTUlCIGFwcGxpZXMsIGRlcGVuZGluZyBvbiB0aGUg bW9kZSB3aXRoIHdoaWNoIHRoZSBtb2RlbQ0gICByZWdpc3RlcmVkLiBUaGUgc3BlY2lmaWMgaW50 ZXJvcGVyYXRpb24gcnVsZXMgYXJlOg0NDSAgICAgMS4gIFdoZW4gYSBDTSBpbml0aWFsbHkgcmFu Z2VzLCB0aGUgQ00gaW1wbGVtZW50cyBhIHJvdyBpbiB0aGUNICAgICAgICAgRE9DUy1JRi1NSUIg ZG9jc0lmQ21TZXJ2aWNlVGFibGUgYW5kIHRoZSBDTVRTIGltcGxlbWVudHMgYSByb3cNICAgICAg ICAgaW4gdGhlIERPQ1MtSUYtTUlCIGRvY3NJZkNtdHNTZXJ2aWNlVGFibGUgY29ycmVzcG9uZGlu ZyB0byB0aGUNICAgICAgICAgZGVmYXVsdCB1cHN0cmVhbSBTZXJ2aWNlIElEICAoU0lEKSB1c2Vk IGZvciAgcHJlLXJlZ2lzdHJhdGlvbg0gICAgICAgICB1cHN0cmVhbSB0cmFmZmljLiBGb3IgaGlz dG9yaWNhbCBjb21wYXRpYmlsaXR5IGEgcm93IG1heSBiZQ0gICAgICAgICBjcmVhdGVkIGZvciB0 aGUgZG9jc0lmUW9zUHJvZmlsZVRhYmxlIHdpdGggZGVmYXVsdCB2YWx1ZXMsDSAgICAgICAgIHdo aWNoIG1heSBiZSByZWZlcmVuY2VkIGJ5IHRoZSBkb2NzSWZDbVNlcnZpY2VUYWJsZSBlbnRyaWVz Lg0NICAgICAyLiAgQm90aCBhIENNVFMgYW5kIENNIGltcGxlbWVudGluZyB0aGlzIE1JQiBNVVNU IE5PVCBpbXBsZW1lbnQNICAgICAgICAgZG9jc1Fvc1BhcmFtU2V0VGFibGUgb3IgZG9jc1Fvc1Nl cnZpY2VGbG93VGFibGUgcm93cyB1bnRpbA0gICAgICAgICBhZnRlciB0aGUgQ00gcmVnaXN0ZXJz IHdpdGggRE9DU0lTIDEuMSBvciAyLjAgbW9kZW0gb3BlcmF0aW9uLg0NDSAgICAgMy4gIFdoZW4g YSBtb2RlbSByZWdpc3RlcnMgd2l0aCB0aGUgQ01UUyBhcyBhICJET0NTSVMgMS4xIiBvcg0gICAg ICAgICAiRE9DU0lTIDIuMCIgbW9kZW0sIGFueSBleGNsdXNpdmVseS1yZWZlcmVuY2VkIHJvdyBp biBET0NTLUlGLQ0gICAgICAgICBNSUIgZG9jc1Fvc1Byb2ZpbGVUYWJsZSByZXByZXNlbnRpbmcg dGhlIG1vZGVtcyB1cHN0cmVhbSBRb3MNICAgICAgICAgcHJvZmlsZSBmb3IgcHJlLXJlZ2lzdHJh dGlvbiB0cmFmZmljIE1VU1QgYmUgcmVtb3ZlZC4NICAgICAgICAgTXVsdGlwbHktcmVmZXJlbmNl ZCByb3dzIG1heSByZW1haW4uIFRoZQ0gICAgICAgICBkb2NzUW9zSWZDbVNlcnZpY2VRb3NQcm9m aWxlIG9iamVjdCBpbiB0aGUgQ00ncyByb3cgb2YNICAgICAgICAgZG9jc0lmQ21TZXJ2aWNlVGFi bGUgTVVTVCBiZSBzZXQgdG8gemVyby4gVGhlDSAgICAgICAgIGRvY3NJZkNtU2VydmljZVRhYmxl IHJvdyBmb3IgdGhlIERPQ1NJUyAxLjEgb3IgRE9DU0lTIDIuMCBtb2RlbQ0gICAgICAgICBjb250 aW51ZXMgdG8gZXhpc3QsIGFuZCB0aGUgdmFyaW91cyBzdGF0aXN0aWMgb2JqZWN0cyBpbiB0aGF0 DSAgICAgICAgIHJvdyBhcmUgaW5jcmVtZW50ZWQuIFRoZSBDTVRTIHNob3VsZCByZXRhaW4gdGhl DSAgICAgICAgIGRvY3NJZkNtdHNTZXJ2aWNlVGFibGUgZW50cnkgZm9yIHRoZSBET0NTSVMgMS4x IG9yIERPQ1NJUyAyLjANICAgICAgICAgQ00uDQ0NICAgICA0LiAgV2hlbiBhIERPQ1NJUyAxLjEg b3IgRE9DU0lTIDIuMCBtb2RlbSByZWdpc3RlcnMsIGJvdGggdGhlIENNVFMNICAgICAgICAgYW5k IENNIHJlcHJlc2VudCBhbGwgc2VydmljZSBmbG93cyBkZXNjcmliZWQgaW4gdGhlIG1vZGVtDSAg ICAgICAgIGNvbmZpZ3VyYXRpb24gZmlsZSBpbiBkb2NzUW9zUGFyYW1TZXRUYWJsZSBhbmQNICAg ICAgICAgZG9jc1Fvc1NlcnZpY2VGbG93VGFibGUuDQ0NICAgICA1LiAgQXQgdGhlIENNVFMsIHRo ZSBEb2NzaXMgMS4wIE1JQiBvYmplY3RzDSAgICAgICAgIGRvY3NJZkNtdHNTZXJ2aWNlSW5QYWNr ZXRzIGFuZCBkb2NzSWZDbXRzU2VydmljZUluT2N0ZXRzIGZvciBhDSAgICAgICAgIFNJRCBhc3Np Z25lZCB0byBhIERvY3NpcyAxLjEgb3IgRG9jc2lzIDIuMCBtb2RlbSBjb3VudCBvbmx5IHRoZQ0g ICAgICAgICBwcmUtcmVnaXN0cmF0aW9uIHBhY2tldHMvYnl0ZXMgb2YgdGhvc2UgbW9kZW1zLg0N DURPQ1NJUyAxLjAgbW9kZW1zIGRvIG5vdCBoYXZlIGVudHJpZXMgaW4gdGhlIERPQ1MtSUVURi1R T1MtTUlCLg0NDVByb3Bvc2VkIFRleHQgZm9yIGRyYWZ0LWlldGYtaXBjZG4tcW9zLW1pYi0wOS50 eHQ6DQ0yLjIuMi4xICBJbnRlcm9wZXJhdGlvbiB3aXRoIERPQ1NJUyAxLjANDSAgIFRoZSBET0NT SVMgMS4wIERPQ1MtSUYtTUlCIFsxMF0gc3BlY2lmaWVzIGEgZG9jc0lmUW9zUHJvZmlsZVRhYmxl IHRvDSAgIGRlc2NyaWJlIHRoZSBzZXQgb2YgQ2xhc3MgT2YgU2VydmljZSAoQ09TKSBwYXJhbWV0 ZXJzIGFzc29jaWF0ZWQgd2l0aA0gICBhIENPUyAicHJvZmlsZSIuIFRoZSBkb2NzSWZDbVNlcnZp Y2VUYWJsZSwgd2hpY2ggY29udGFpbnMgb25lIGVudHJ5DSAgIHBlciBTSUQsIHJlZmVyZW5jZXMg dGhpcyB0YWJsZSB3aXRoIGEgIGRvY3NJZkNtU2VydmljZVFvc1Byb2ZpbGUNICAgbnVtYmVyLg0N ICAgVGhlIERPQ1NJUyAxLjEgYW5kIDIuMCBDTSByZWdpc3RyYXRpb24gcHJvY2VzcyBhbGxvd3Mg YSBtb2RlbSB0bw0gICByZWdpc3RlciBhcyBvcGVyYXRpbmcgZWl0aGVyIHdpdGggRE9DU0lTIDEu MCwgRE9DU0lTIDEuMSwgb3IgRE9DU0lTDSAgIDIuMCBmdW5jdGlvbmFsaXR5LiBGb3IgZWFzZSBv ZiBleHByZXNzaW9uLCB3ZSBjYWxsIGEgbW9kZW0NICAgcmVnaXN0ZXJpbmcgd2l0aCBET0NTSVMg MS4wIGZ1bmN0aW9uYWxpdHkgYSAiRE9DU0lTIDEuMCBtb2RlbSIsDSAgIHJlZ2FyZGxlc3Mgb2Yg dGhlIG1vZGVtJ3MgY2FwYWJpbGl0aWVzLg0NICAgQSBDTVRTIG9yIENNIHN1cHBvcnRpbmcgYm90 aCBET0NTSVMgMS4wLCBET0NTSVMgMS4xLCBhbmQgRE9DU0lTIDIuMA0gICBpbXBsZW1lbnRzIGJv dGggdGhlIHRhYmxlcyBvZiBbMTBdIGFuZCB0aGUgdGFibGVzIG9mIHRoaXMgTUlCLiBUaGUNICAg aW50ZXJvcGVyYXRpb24gZ29hbCBpcyB0aGF0IGJlZm9yZSBtb2RlbSByZWdpc3RyYXRpb24sIHRo ZSBET0NTSVMgMS4wDSAgIE1JQiBbMTBdIGFwcGxpZXMuIEFmdGVyIHJlZ2lzdHJhdGlvbiwgZWl0 aGVyIHRoZSBET0NTSVMgMS4wIG9yIERPQ1NJUw0gICAxLjEvMi4wIE1JQiBhcHBsaWVzLCBkZXBl bmRpbmcgb24gdGhlIG1vZGUgd2l0aCB3aGljaCB0aGUgbW9kZW0NICAgcmVnaXN0ZXJlZC4gVGhl IHNwZWNpZmljIGludGVyb3BlcmF0aW9uIHJ1bGVzIGFyZToNDQ0gICAgIDEuICBXaGVuIGEgQ00g aW5pdGlhbGx5IHJhbmdlcywgdGhlIENNIGltcGxlbWVudHMgYSByb3cgaW4gdGhlDSAgICAgICAg IERPQ1MtSUYtTUlCIGRvY3NJZkNtU2VydmljZVRhYmxlIGFuZCB0aGUgQ01UUyBpbXBsZW1lbnRz IGEgcm93DSAgICAgICAgIGluIHRoZSBET0NTLUlGLU1JQiBkb2NzSWZDbXRzU2VydmljZVRhYmxl IGNvcnJlc3BvbmRpbmcgdG8gdGhlDSAgICAgICAgIGRlZmF1bHQgdXBzdHJlYW0gU2VydmljZSBJ RCAgKFNJRCkgdXNlZCBmb3IgIHByZS1yZWdpc3RyYXRpb24NICAgICAgICAgdXBzdHJlYW0gdHJh ZmZpYy4gRm9yIGhpc3RvcmljYWwgY29tcGF0aWJpbGl0eSBhIHJvdyBtYXkgYmUNICAgICAgICAg Y3JlYXRlZCBmb3IgdGhlIGRvY3NJZlFvc1Byb2ZpbGVUYWJsZSB3aXRoIGRlZmF1bHQgdmFsdWVz LA0gICAgICAgICB3aGljaCBtYXkgYmUgcmVmZXJlbmNlZCBieSB0aGUgZG9jc0lmQ21TZXJ2aWNl VGFibGUgZW50cmllcy4NDSAgICAgMi4gIEJvdGggYSBDTVRTIGFuZCBDTSBpbXBsZW1lbnRpbmcg dGhpcyBNSUIgTVVTVCBOT1QgaW1wbGVtZW50DSAgICAgICAgIGRvY3NRb3NQYXJhbVNldFRhYmxl IG9yIGRvY3NRb3NTZXJ2aWNlRmxvd1RhYmxlIHJvd3MgdW50aWwNICAgICAgICAgYWZ0ZXIgdGhl IENNIHJlZ2lzdGVycyB3aXRoIERPQ1NJUyAxLjEgb3IgMi4wIG1vZGVtIG9wZXJhdGlvbi4NDQ0g ICAgIDMuICBXaGVuIGEgbW9kZW0gcmVnaXN0ZXJzIHdpdGggdGhlIENNVFMgYXMgYSAiRE9DU0lT IDEuMSIgb3INICAgICAgICAgIkRPQ1NJUyAyLjAiIG1vZGVtLCBhbnkgZXhjbHVzaXZlbHktcmVm ZXJlbmNlZCByb3cgaW4gRE9DUy1JRi0NICAgICAgICAgTUlCIGRvY3NRb3NQcm9maWxlVGFibGUg cmVwcmVzZW50aW5nIHRoZSBtb2RlbXMgdXBzdHJlYW0gUW9zDSAgICAgICAgIHByb2ZpbGUgZm9y IHByZS1yZWdpc3RyYXRpb24gdHJhZmZpYyBNVVNUIGJlIHJlbW92ZWQuDSAgICAgICAgIE11bHRp cGx5LXJlZmVyZW5jZWQgcm93cyBtYXkgcmVtYWluLiBUaGUNICAgICAgICAgZG9jc1Fvc0lmQ21T ZXJ2aWNlUW9zUHJvZmlsZSBvYmplY3QgaW4gdGhlIENNJ3Mgcm93IG9mDSAgICAgICAgIGRvY3NJ ZkNtU2VydmljZVRhYmxlIE1VU1QgYmUgc2V0IHRvIHplcm8uIFRoZQ0gICAgICAgICBkb2NzSWZD bVNlcnZpY2VUYWJsZSByb3cgZm9yIHRoZSBET0NTSVMgMS4xIG9yIERPQ1NJUyAyLjAgbW9kZW0N ICAgICAgICAgY29udGludWVzIHRvIGV4aXN0LCBhbmQgdGhlIHZhcmlvdXMgc3RhdGlzdGljIG9i amVjdHMgaW4gdGhhdA0gICAgICAgICByb3cgYXJlIGluY3JlbWVudGVkLiBUaGUgQ01UUyBzaG91 bGQgcmV0YWluIHRoZWENICAgICAgICAgZG9jc0lmQ210c1NlcnZpY2VUYWJsZSBlbnRyeSBmb3Ig dGhlIERPQ1NJUyAxLjEgb3IgRE9DU0lTIDIuMA0gICAgICAgICBDTS4NDQ0gICAgIDQuICBXaGVu IGEgRE9DU0lTIDEuMSBvciBET0NTSVMgMi4wIG1vZGVtIHJlZ2lzdGVycywgYm90aCB0aGUgQ01U Uw0gICAgICAgICBhbmQgQ00gcmVwcmVzZW50IGFsbCBzZXJ2aWNlIGZsb3dzIGRlc2NyaWJlZCBp biB0aGUgbW9kZW0NICAgICAgICAgY29uZmlndXJhdGlvbiBmaWxlIGluIGRvY3NRb3NQYXJhbVNl dFRhYmxlIGFuZA0gICAgICAgICBkb2NzUW9zU2VydmljZUZsb3dUYWJsZS4NDQ0gICAgIDUuICBB dCB0aGUgQ01UUywgdGhlIERvY3NpcyAxLjAgTUlCIG9iamVjdHMNICAgICAgICAgZG9jc0lmQ210 c1NlcnZpY2VJblBhY2tldHMgYW5kIGRvY3NJZkNtdHNTZXJ2aWNlSW5PY3RldHMgZm9yIGENICAg ICAgICAgU0lEIGFzc2lnbmVkIHRvIGEgRG9jc2lzIDEuMSBvciBEb2NzaXMgMi4wIG1vZGVtIGNv dW50IG9ubHkgdGhlDSAgICAgICAgIHByZS1yZWdpc3RyYXRpb24gcGFja2V0cy9ieXRlcyBvZiB0 aG9zZSBtb2RlbXMuDQ0NICAgICA1Ni4gRE9DU0lTIDEuMCBtb2RlbXMgZG8gbm90IGhhdmUgZW50 cmllcyBpbiB0aGUgRE9DUy1JRVRGLVFPUy1NSUIuDQ0NQ2hhbmdlcyB0byBTZWN0aW9uIDggIJNO b3JtYXRpdmUgUmVmZXJlbmNlc5QNDVsxMF0gU3QuIEpvaG5zLCBNLiwgIlJhZGlvIEZyZXF1ZW5j eSAoUkYpIEludGVyZmFjZSBNYW5hZ2VtZW50DSAgICAgICAgSW5mb3JtYXRpb24gQmFzZSBmb3Ig TUNOUy9ET0NTSVMgY29tcGxpYW50IFJGIGludGVyZmFjZXMiLA0gICAgICAgIFJGQyAyNjcwLCBB dWd1c3QgMTk5OS4NDQ0gICAgICAgICAgICAgICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiANICAgICAgICAqIE5PVEVTIFRPIFJGQyBF ZGl0b3IgKHRvIGJlIHJlbW92ZWQgcHJpb3IgdG8gcHVibGljYXRpb24pICogDSAgICAgICAgKiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAq IA0gICAgICAgICogMS4pIFRoZSBJLUQgPGRyYWZ0LWlldGYtaXBjZG4tZG9jcy1yZm1pYnYyLTA3 LnR4dD4gKG9yIGEgKiANICAgICAgICAqIHN1Y2Nlc3NvcikgaXMgZXhwZWN0ZWQgdG8gZXZlbnR1 YWxseSByZXBsYWNlIFJGQyAyNjcwLiAgICogDSAgICAgICAgKiBJZiB0aGF0IGRyYWZ0IChvciBh IHN1Y2Nlc3NvcikgaXMgcHVibGlzaGVkIGFzIGFuIFJGQyAgICAqIA0gICAgICAgICogcHJpb3Ig dG8gb3IgY29uY3VycmVudGx5IHdpdGggdGhpcyBkb2N1bWVudCwgdGhlbiB0aGUgICAgKiANICAg ICAgICAqIG5vcm1hdGl2ZSByZWZlcmVuY2UgWzEwXSBzaG91bGQgYmUgdXBkYXRlZCB0byAgICAg ICAgICAgICogDSAgICAgICAgKiBwb2ludCB0byB0aGUgcmVwbGFjZW1lbnQgUkZDLiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAqIA0gICAgICAgICoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiANDQ0NTk9URToNDUlmIHRoZXJlIGlz IGFueSBpc3N1ZSB3aXRoIGhvdyB0aGUgZG9jc0lmQ210c1NlcnZpY2VUYWJsZSBvciB0aGUgZG9j c0lmQ21TZXJ2aWNlVGFibGUgaGFuZGxlcyB0aGUgdHJhbnNpdGlvbiBiZXR3ZWVuIGEgdGVtcG9y YXJ5IFNJRCBhbmQgYW4gb3BlcmF0aW9uYWwgU0lEIHRoZW4gY2xhcmlmaWNhdGlvbiBvZiB0aGUg b3BlcmF0aW9uIHNob3VsZCBiZSBtYWRlIGluIHRoZSBkZXNjcmlwdGlvbiBmb3IgdGhlc2UgdGFi bGVzIGluIHRoZSBET0NTLUlGLU1JQi4NSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgdGhlcmUgaXMg bm8gc3BlY2lmaWMgZGVzY3JpcHRpb24gdG8gZGF0ZSBmb3Igd2hlbi9ob3cvd2hhdCB0byBhZGQg YW4gZW50cnkgaW4gdGhlIGRvY3NJZkNtdHNTZXJ2aWNlVGFibGUgb3IgZG9jc0lmQ21TZXJ2aWNl VGFibGUsIG9yIHdoYXQgdG8gZHVlIHRvIHdoZW4gYSB0ZW1wb3JhcnkgU0lEIGJlY29tZXMgYW4g b3BlcmF0aW9uYWwgU0lELCBhbmQgdGhlIFNJRCB2YWx1ZXMgcmVtYWluIHRoZSBzYW1lLg1UaHVz IGVhY2ggVmVuZG9yIGhhcyBiZWVuIGltcGxlbWVudGluZyB3aGF0IGl0IGhhcyBwZXJjZWl2ZWQg YXMgdGhlIJNyaWdodCB0aGluZyB0byBkb5QsIGV2ZXIgc2luY2UgRE9DU0lTIDEuMC4gVGhlIGRy YWZ0LWlldGYtaXBjZG4tcW9zLW1pYi0wOS50eHQgZG9lcyBub3Qgc3BlY2lmeSB0aGUgZWZmZWN0 IG9mIGFuIGVudHJ5IHRyYW5zaXRpb25pbmcgdG8gYW4gb3BlcmF0aW9uYWwgU0lEIGZyb20gYSB0 ZW1wb3JhcnkgU0lEIGR1cmluZyByZWdpc3RyYXRpb24gaW4gdGhlIGRvY3NJZkNtdHNTZXJ2aWNl VGFibGUsIGJ1dCByYXRoZXIgc3BlY2lmaWVzIHRoYXQgdGhlcmUgc2hvdWxkIGJlIGFuIGVudHJ5 IGZvciBhIENNIGR1cmluZyByYW5naW5nIGFuZCBhZnRlciByZWdpc3RyYXRpb24gbm8gbWF0dGVy IHdoYXQgdGhlIGVmZmVjdCB3YXMuDSAgDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAMwQAABMQAABHEAAAdxAA AIIQAACmGQAAqRkAAKoZAADtGgAA4hsAAOobAADrGwAA7BsAAC0cAAAuHAAADR0AAA8dAADDHwAA xB8AAMYfAADMHwAAgSMAAPwA/AD1AO7nAO4A5+4A4ADVxL3VtwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAKNQiBXAiBYUoUAAANAQiBBEgBAAVoXnp6ZiEBCIEESAEABWheenpmQ0oUAE9KAwBRSgMA XkoDAGFKFAAUQ0oUAE9KAwBRSgMAXkoDAGFKFAAADQEIgQRIAQAFaFF6emYNAQiBBEgBAAVoTnp6 Zg0ACIFjSAEAZGhOenpmDQAIgWNIAQBkaE16emYGNQiBXAiBFgAEAAAzBAAANAQAAFwEAABdBAAA pQQAAO4EAAA1BQAAeQUAAIQFAACFBQAAyQUAABAGAABOBgAAkQYAALwGAAC9BgAABAcAAEoHAACT BwAA3AcAAB8IAABVCAAAVggAAFcIAACbCAAA4wgAACsJAAByCQAAtwkAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAdAAQAAIEjAAD+AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQG3CQAA+wkAAEEKAABCCgAAhwoAAMsK AAATCwAAFAsAABULAABYCwAAoAsAAOYLAAAlDAAAVwwAAJcMAADODAAAFw0AAF4NAACXDQAA3g0A AOsNAADsDQAA7Q0AADUOAAB4DgAAsA4AANIOAADTDgAA1A4AAAUPAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAHQUPAABNDwAAlg8AAM8PAADQDwAA0Q8A ABEQAAASEAAAExAAAEYQAABHEAAAbxAAAHAQAAC4EAAAAREAAEgRAACMEQAAlxEAAJgRAADcEQAA IxIAAGESAACkEgAAzxIAANASAAAXEwAAXRMAAKYTAADvEwAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAFAAAKJgALRgEAAAEAAAAc7xMAADIUAABoFAAAaRQAAGoUAACuFAAA 9hQAAD4VAACFFQAAyhUAAA4WAABUFgAAVRYAAJoWAADeFgAAJhcAACcXAAAoFwAAaxcAALMXAAD5 FwAAOBgAAGoYAACqGAAA4RgAACoZAABxGQAAqxkAAPIZAAD/GQAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAB3/GQAAABoAAAEaAABJGgAAjBoAAMQaAADm GgAA5xoAAOgaAAAZGwAAYRsAAKobAADjGwAA5BsAAOUbAAAuHAAALxwAADAcAABdHAAAXhwAAJ0c AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAC3AAAAAAAAAAAAAAAAtwAAAAAAAAAAAAAAALQAAAAA AAAAAAAAAAC3AAAAAAAAAAAAAAAAtwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAQBDJAFD AABFxoAAAAEAUXp6ZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAMAAEMkAQABAAAAFJ0cAADgHAAA/xwAAAAdAAABHQAATR0AAJMd AADZHQAAHx4AAGUeAACrHgAA8R4AADcfAAB9HwAAvAAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAAC8 AAAAAAAAAAAAAAAAvAAAAAAAAAAAAAAAAHMAAAAAAAAAAAAAAABzAAAAAAAAAAAAAAAAcwAAAAAA AAAAAAAAAHMAAAAAAAAAAAAAAABzAAAAAAAAAAAAAAAAcwAAAAAAAAAAAAAAAHMAAAAAAAAAAAAA AABzAAAAAAAAAAAAAAAAcwAAAAAAAAAAAAAAAAAAAAAASQAANyQAOCQAQyQBRcaAAAABAF56emYA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABIJABDAABFxoAAAAEAUXp6ZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANfR8AAMMfAADEHwAAxR8AAMYfAADMHwAAtgAA AAAAAAAAAAAAAHEAAAAAAAAAAAAAAABrAAAAAAAAAAAAAAAAawAAAAAAAAAAAAAAAGsAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAYAADckADgkAEgkAABEAABDJAFFxoAAAAEAXnp6ZgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEkAADck ADgkAEMkAUXGgAAAAQBeenpmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASCQAAAXMHwAAzR8AANQgAADVIQAAfiMAAIEjAAC8AAAA AAAAAAAAAAAAvAAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAAC8AAAAAAAAAAAAAAAAvAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAQwAARcaAAAABAFF6emYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABSAAMZBoAR+w0C8gsOA9IbAIByKwCAcjkKAFJJCg BSWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAPAAoAAQBpAA8AAwAAAAAAAAAAADgAAEDx/wIA OAAMAAYATgBvAHIAbQBhAGwAAAACAAAAGABDShgAX0gBBGFKGABtSAkEc0gJBHRICQQyAAFgAQAC ADIADAAJAEgAZQBhAGQAaQBuAGcAIAAxAAAACAABAAYkAUAmAAYANQiBXAiBAAAAAAAAAAAAAAAA AAAAADwAQUDy/6EAPAAMABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBv AG4AdAAAAAAAAAAAAAAAAAAAAAAAgR8AAAoAADgAAAsA/////wAAAAAzAAAANAAAAFwAAABdAAAA pQAAAO4AAAA1AQAAeQEAAIQBAACFAQAAyQEAABACAABOAgAAkQIAALwCAAC9AgAABAMAAEoDAACT AwAA3AMAAB8EAABVBAAAVgQAAFcEAACbBAAA4wQAACsFAAByBQAAtwUAAPsFAABBBgAAQgYAAIcG AADLBgAAEwcAABQHAAAVBwAAWAcAAKAHAADmBwAAJQgAAFcIAACXCAAAzggAABcJAABeCQAAlwkA AN4JAADrCQAA7AkAAO0JAAA1CgAAeAoAALAKAADSCgAA0woAANQKAAAFCwAATQsAAJYLAADPCwAA 0AsAANELAAARDAAAEgwAABMMAABGDAAARwwAAG8MAABwDAAAuAwAAAENAABIDQAAjA0AAJcNAACY DQAA3A0AACMOAABhDgAApA4AAM8OAADQDgAAFw8AAF0PAACmDwAA7w8AADIQAABoEAAAaRAAAGoQ AACuEAAA9hAAAD4RAACFEQAAyhEAAA4SAABUEgAAVRIAAJoSAADeEgAAJhMAACcTAAAoEwAAaxMA ALMTAAD5EwAAOBQAAGoUAACqFAAA4RQAACoVAABxFQAAqxUAAPIVAAD/FQAAABYAAAEWAABJFgAA jBYAAMQWAADmFgAA5xYAAOgWAAAZFwAAYRcAAKoXAADjFwAA5BcAAOUXAAAuGAAALxgAADAYAABd GAAAXhgAAJ0YAADgGAAA/xgAAAAZAAABGQAATRkAAJMZAADZGQAAHxoAAGUaAACrGgAA8RoAADcb AAB9GwAAwxsAAMQbAADFGwAAxhsAAMwbAADNGwAA1BwAANUdAAB+HwAAgx8AAJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAASAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgAgAAAABMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAMBgAAJgAAAAAMAAAAAAAAACAMBgAAJgAAAAAMAAAAAAAAACAMBgAAJgAAAAAMAAAAAAAAACA MBgAAJgAAAAAMAAAAAAAAACAMBgAAJgAAAAAMAAAAAAAAACAMBgAAJgAAAAAMAAAAAAAAACAMBgA AJgAAAAAMAAAAAAAAACAMBgAAJgAAAAAMAAAAAAAAACAMBgAAJgAAAAAMAAAAAAAAACAMBgAAJgA AAAAMAAAAAAAAACAMBgAAJgAAAAAMAAAAAAAAACAMBgAAJgAAAAAMAAAAAAAAACAMBgAAJgAAAAA MAAAAAAAAACAMBgAAJgAAAAAMAAAAAAAAACAMBgAAJgAAAAAMAAAAAAAAACAMBgAAJgAAAAAMAAA AAAAAACAMBgAAJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAAgAAEAACBIwAAEgAAAAAEAAC3 CQAABQ8AAO8TAAD/GQAAnRwAAH0fAADMHwAAgSMAABMAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoA AAAbAAAAAAQAAIEjAAAUAAAAAAAAAIwAAAChAAAABgEAABoBAABfAQAAeAEAALAEAADEBAAA/wQA ABUFAADQBQAA5QUAACMGAAA3BgAAkAYAAKQGAACoBgAAvwYAAK0HAADABwAA4gcAAOUHAABgCAAA fAgAAIsIAACPCAAAoAgAALQIAADXCAAA6wgAAKAJAAC2CQAAlwoAAKsKAAC5CgAA0AoAAO4KAAD0 CgAADgsAACgLAAAtCwAARgsAAGgLAABuCwAAdgsAAHwLAACfDAAAtAwAABkNAAAtDQAAcg0AAIsN AADDEAAA1xAAABIRAAAoEQAA4xEAAPgRAAA2EgAAShIAAKMSAAC3EgAAuxIAANISAADAEwAA0xMA APUTAAD4EwAAcxQAAI8UAACeFAAAohQAALMUAADHFAAA6hQAAP4UAAC0FQAAyhUAAKsWAAC/FgAA zRYAAOQWAADwGwAABhwAAA4cAAAiHAAAPh0AAFQdAABYHQAAbB0AAOUeAAD7HgAAgx8AAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHAAAAAAA0AAAASwAAAKgAAACwAAAA8QAAAPIAAAA4AQAAOwEAAHwBAACCAQAAzAEA ANQBAAATAgAAJQIAAFECAABcAgAAlAIAAJ4CAADNAgAA3AIAAAcDAAARAwAATQMAAFsDAAAiBAAA LAQAAOwEAADuBAAANAUAADsFAAB7BQAAgwUAAMAFAADHBQAABAYAAAkGAACQBgAApAYAANQGAADZ BgAAeQcAAI8HAADvBwAA9gcAAC4IAABBCAAAYAgAAHwIAACgCAAAtAgAANcIAADrCAAAIAkAACkJ AABnCQAAagkAAKAJAAC2CQAAPgoAAEEKAACBCgAAjgoAALkKAADQCgAADgsAACgLAACfCwAAogsA AEcMAABeDAAAuwwAAMMMAAAEDQAABQ0AAEsNAABODQAAjw0AAJUNAADfDQAA5w0AACYOAAA4DgAA ZA4AAG8OAACnDgAAsQ4AAOAOAADvDgAAGg8AACQPAABgDwAAbg8AADUQAAA/EAAA/xAAAAERAABH EQAAThEAAI4RAACWEQAA0xEAANoRAAAXEgAAHBIAAKMSAAC3EgAA5xIAAOwSAACMEwAAohMAAAIU AAAJFAAAQRQAAFQUAABzFAAAjxQAALMUAADHFAAA6hQAAP4UAAAzFQAAPBUAAHoVAAB9FQAAtBUA AMoVAABSFgAAVRYAAJUWAACiFgAAzRYAAOQWAAApGgAAMhoAALUaAAC6GgAA+xoAAAQbAABBGwAA RhsAAIMfAAAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwD//xIAAAANAEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIAVQBEADoAXABQAHIAbwBmAGkA bABlAHMAXABsAHcAbQAwADAAOABcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEAXABN AGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMA YQB2AGUAIABvAGYAIABEAG8AYwB1AG0AZQBuAHQAMQAuAGEAcwBkAA0AQQBkAG0AaQBuAGkAcwB0 AHIAYQB0AG8AcgAtAEQAOgBcAFAAcgBvAGYAaQBsAGUAcwBcAGwAdwBtADAAMAA4AFwARABlAHMA awB0AG8AcABcAFMAZQBjAHQAaQBvAG4AMgAuADIALgAyAC4AMQAuAGQAbwBjAA0AQQBkAG0AaQBu AGkAcwB0AHIAYQB0AG8AcgBWAEQAOgBcAFAAcgBvAGYAaQBsAGUAcwBcAGwAdwBtADAAMAA4AFwA QQBwAHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBv AHIAZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFMAZQBjAHQA aQBvAG4AMgAuADIALgAyAC4AMQANAEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIALQBEADoAXABQ AHIAbwBmAGkAbABlAHMAXABsAHcAbQAwADAAOABcAEQAZQBzAGsAdABvAHAAXABTAGUAYwB0AGkA bwBuADIALgAyAC4AMgAuADEALgBkAG8AYwANAEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIAVgBE ADoAXABQAHIAbwBmAGkAbABlAHMAXABsAHcAbQAwADAAOABcAEEAcABwAGwAaQBjAGEAdABpAG8A bgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBj AG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABTAGUAYwB0AGkAbwBuADIALgAyAC4AMgAuADEA DQBBAGQAbQBpAG4AaQBzAHQAcgBhAHQAbwByAFYARAA6AFwAUAByAG8AZgBpAGwAZQBzAFwAbAB3 AG0AMAAwADgAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEAdABhAFwATQBpAGMAcgBvAHMA bwBmAHQAXABXAG8AcgBkAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBm ACAAUwBlAGMAdABpAG8AbgAyAC4AMgAuADIALgAxAA0AQQBkAG0AaQBuAGkAcwB0AHIAYQB0AG8A cgAtAEQAOgBcAFAAcgBvAGYAaQBsAGUAcwBcAGwAdwBtADAAMAA4AFwARABlAHMAawB0AG8AcABc AFMAZQBjAHQAaQBvAG4AMgAuADIALgAyAC4AMQAuAGQAbwBjAA0AQQBkAG0AaQBuAGkAcwB0AHIA YQB0AG8AcgBWAEQAOgBcAFAAcgBvAGYAaQBsAGUAcwBcAGwAdwBtADAAMAA4AFwAQQBwAHAAbABp AGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABcAEEA dQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFMAZQBjAHQAaQBvAG4AMgAu ADIALgAyAC4AMQANAEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIALQBEADoAXABQAHIAbwBmAGkA bABlAHMAXABsAHcAbQAwADAAOABcAEQAZQBzAGsAdABvAHAAXABTAGUAYwB0AGkAbwBuADIALgAy AC4AMgAuADEALgBkAG8AYwABALo3ii0oBRzH/w//D/8P/w//D/8P/w//D/8PEAAGAAAAAAABAAAA AAAAAAAAAAAAAAAAAAADGAAAD4SUAhGEmP4VxgUAAZQCBl6ElAJghJj+bygAAgAAAC4AAQAAAASA AQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EZAURhJj+FcYFAAFkBQZehGQFYISY/gIAAQAuAAEAAAAC ggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhDQIEYRM/xXGBQABNAgGXoQ0CGCETP8CAAIALgABAAAA AIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QECxGEmP4VxgUAAQQLBl6EBAtghJj+AgADAC4AAQAA AASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E1A0RhJj+FcYFAAHUDQZehNQNYISY/gIABAAuAAEA AAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhKQQEYRM/xXGBQABpBAGXoSkEGCETP8CAAUALgAB AAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4R0ExGEmP4VxgUAAXQTBl6EdBNghJj+AgAGAC4A AQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+ERBYRhJj+FcYFAAFEFgZehEQWYISY/gIABwAu AAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhBQZEYRM/xXGBQABFBkGXoQUGWCETP8CAAgA LgABAAAAujeKLQAAAAAAAAAAAAAAAP///////wEAAAAAAP//AQAAABIAPlNURhkACQQbAAkEDwAJ BBkACQQbAAkEDwAJBBkACQQbAAkE/0ABgAEAZR8AAGUfAADwinQAFwEXAWUfAAAAAAAAZR8AAAAA AAACEAAAAAAAAACBHwAAoAAACABAAAD//wIAAAAHAFUAbgBrAG4AbwB3AG4ADQBBAGQAbQBpAG4A aQBzAHQAcgBhAHQAbwByAP//AgAIAAAAAAAAAAAAAAAAAAAAAAAAAAEA//8CAAAAAAAAAP//AAAC AP//AAAAAP//AAACAP//AAAAAAQAAABHFpABAAACAgYDBQQFAgMEhzoAIAAAAAAAAAAAAAAAAP8B AAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAA AAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEhzoAIAAA AAAAAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAPzWQAQAAAgcDCQICBQIEBId6ACAAAACACAAA AAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAACIABABxCMgYAPDQAgAAaAEAAAAA QXp6Znh6emYAAAAABAA3AAAAjgQAAPoZAAABAA0AAAAEAAMQNwAAAAAAAAAAAAAAAQABAAAAAQAA AAAAAAAhAwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIB6AFtAC0AIGBMjAAABAAGQBk AAAAGQAAAOYfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAyg1EA8BAA3wMAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAgAAAD//xIAAAAAAAAALQBDAHUAcgByAGUAbgB0ACAAVABlAHgAdAAgAGYAcgBvAG0A IABkAHIAYQBmAHQALQBpAGUAdABmAC0AaQBwAGMAZABuAC0AcQBvAHMALQBtAGkAYgAtADAAOAAA AAAAAAANAEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIADQBBAGQAbQBpAG4AaQBzAHQAcgBhAHQA bwByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAA AKQBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAADQAAAABAAAANwAAAAFAAAA9AAAAAYAAAAAAQAA BwAAAAwBAAAIAAAAIAEAAAkAAAA4AQAAEgAAAEQBAAAKAAAAYAEAAAwAAABsAQAADQAAAHgBAAAO AAAAhAEAAA8AAACMAQAAEAAAAJQBAAATAAAAnAEAAAIAAADkBAAAHgAAAC4AAABDdXJyZW50IFRl eHQgZnJvbSBkcmFmdC1pZXRmLWlwY2RuLXFvcy1taWItMDgALjAeAAAAAQAAAAB1cnIeAAAADgAA AEFkbWluaXN0cmF0b3IAcm8eAAAAAQAAAABkbWkeAAAAAQAAAABkbWkeAAAACwAAAE5vcm1hbC5k b3QAbx4AAAAOAAAAQWRtaW5pc3RyYXRvcgBybx4AAAACAAAANABtaR4AAAATAAAATWljcm9zb2Z0 IFdvcmQgOS4wAHJAAAAAAAr0rgcAAABAAAAAAA52YRyTwwFAAAAAABhqECSTwwEDAAAAAQAAAAMA AACOBAAAAwAAAPoZAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 AAD+/wAABQACAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAAAcAQAADAAA AAEAAABoAAAADwAAAHAAAAAFAAAAhAAAAAYAAACMAAAAEQAAAJQAAAAXAAAAnAAAAAsAAACkAAAA EAAAAKwAAAATAAAAtAAAABYAAAC8AAAADQAAAMQAAAAMAAAA/gAAAAIAAADkBAAAHgAAAAkAAABN b3Rvcm9sYQAAZQADAAAANwAAAAMAAAANAAAAAwAAAOYfAAADAAAA7Q4JAAsAAAAAAAAACwAAAAAA AAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAuAAAAQ3VycmVudCBUZXh0IGZyb20gZHJhZnQtaWV0 Zi1pcGNkbi1xb3MtbWliLTA4AAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAAAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIA AAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAA ABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAP7///8eAAAA HwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAt AAAA/v///y8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAD+////NwAAADgAAAA5AAAAOgAAADsA AAA8AAAAPQAAAP7////9////QAAAAP7////+/////v////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////9SAG8AbwB0 ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA FgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAADwKH4ZJJPDAUIAAACA AAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAOAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAHQAAACohAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEFAAAA//////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIjgAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYA bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4AAAAAEAAAAAAAAAUARABvAGMA dQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4 AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANgAAAAAQ AAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABIAAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAagAAAAAAAABPAGIAagBlAGMAdABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABAP///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAA8Ch+GSSTwwHwKH4ZJJPDAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////8BAP7/AwoAAP// //8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABNU1dvcmRE b2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------_=_NextPart_000_01C39324.2067BDA2-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Oct 15 19:58:26 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 TAA00070 for ; Wed, 15 Oct 2003 19:58:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9vWk-0008DO-SN for ipcdn-archive@odin.ietf.org; Wed, 15 Oct 2003 19:58:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FNw2uu031557 for ipcdn-archive@odin.ietf.org; Wed, 15 Oct 2003 19:58:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9vWj-0008Cl-DF; Wed, 15 Oct 2003 19:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9vWF-0008CK-Lf for ipcdn@optimus.ietf.org; Wed, 15 Oct 2003 19:57:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00042 for ; Wed, 15 Oct 2003 19:57:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9vWD-0005Wx-00 for ipcdn@ietf.org; Wed, 15 Oct 2003 19:57:29 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1A9vWD-0005WT-00 for ipcdn@ietf.org; Wed, 15 Oct 2003 19:57:29 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9FNuuSw019013; Wed, 15 Oct 2003 16:56:56 -0700 (PDT) Received: from milu-w2k.cisco.com (dhcp-171-71-51-93.cisco.com [171.71.51.93]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANE56155; Wed, 15 Oct 2003 16:56:55 -0700 (PDT) Message-Id: <4.3.2.7.2.20031015165535.031df680@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 Oct 2003 16:56:55 -0700 To: Murwin William-LWM008 From: Minnie Lu Cc: "Docsis-Oss (E-mail) (E-mail)" , "IPCDN (E-mail) (E-mail)" , "Richard Woundy (E-mail)" , Patrick Michael-LZZ007 , "'Eduardo Cardona'" In-Reply-To: <19CD0E423FC1D611893500508B6F0B9CF3985F@ma07exm01.e6.bcs.mo t.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] Re: Proposed Changes to Section 2.2.2.1 of the DOCS-IETF-QOS-MIB, fro m comments about temp and operational SIDs 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 a lot ! William. Minnie At 10:01 AM 10/15/2003 -0400, Murwin William-LWM008 wrote: >The following is proposed changes to section 2.2.2.1 of the >draft-ietf-ipcdn-qos-mib-09.txt from comments made about temporary and >operational SIDs, the sistutation was already taken into account when the >draft-ietf-ipcdn-qos-mib-05.txt was sent out, but a couple of changes have >been made to avoid future mis-understandings: > > <> > >______________________________ >William Murwin >Broadband Communications Sector >Motorola Inc. >Email: W.Murwin@motorola.com >Tel: (508) 786-7594 > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Oct 16 17:52:22 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 RAA26693 for ; Thu, 16 Oct 2003 17:52:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAG2M-0005an-VI for ipcdn-archive@odin.ietf.org; Thu, 16 Oct 2003 17:52:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GLq2xt021476 for ipcdn-archive@odin.ietf.org; Thu, 16 Oct 2003 17:52:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAG2J-0005aA-Qn; Thu, 16 Oct 2003 17:51:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAG2A-0005Zy-Bk for ipcdn@optimus.ietf.org; Thu, 16 Oct 2003 17:51:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26653 for ; Thu, 16 Oct 2003 17:51:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAG27-0003M6-00 for ipcdn@ietf.org; Thu, 16 Oct 2003 17:51:47 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AAG26-0003Lb-00 for ipcdn@ietf.org; Thu, 16 Oct 2003 17:51:47 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9GLpF10019026 for ; Thu, 16 Oct 2003 15:51:15 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt Date: Thu, 16 Oct 2003 15:51:14 -0600 Message-ID: Thread-Topic: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt Thread-Index: AcOSZlY5L6H4uayBSMuzaTPspJBqYAACX9zQAG+2NNA= From: "Jean-Francois Mule" To: "Eduardo Cardona" Cc: "Ipcdn (E-mail)" 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 Eduardo, Thank you for the response.=20 While we are at it, can we take care of the following nits: - 1 editorial comment received during WGLC: = http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00843.h= tml (see Stu's comments. Re: revision, let's remove all the older = revisions per AD review.) - some normative references are out of date Please consider the following changes: :s/SP-RFIv1.1-I07-010829/SP-RFIv1.1-I10-030730 & date :s/SP-BPI+-I09-020830/SP-BPI+_I10-030730 & date :s/SP-BPI-I03-010829/"ANSI/SCTE 22-2 2002" & date and update reference & link to ANSI or SCTE site: http://www.scte.org/documents/pdf/ANSISCTE2222002DSS0203.pdf etc. (please cross check all the refs) Thanks, Jean-Fran=E7ois > -----Original Message----- > From: Eduardo Cardona=20 > Sent: Tuesday, October 14, 2003 10:30 AM > To: Wijnen, Bert (Bert); Ipcdn (E-mail) > Subject: RE: [ipcdn] AD (MIB Dcotor) review of:=20 > draft-ietf-ipcdn-bpiplus-mib-11.txt >=20 >=20 > Thanks Bert,=20 >=20 > You already did extensive comments in this mib in the past months. >=20 > As clean (we though) as it becomes you amazingly find more=20 > details. :)=20 >=20 > We will reply shortly with actions. >=20 >=20 > Eduardo _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Oct 20 15:18:26 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 PAA14223 for ; Mon, 20 Oct 2003 15:18:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfXY-0001A8-VE for ipcdn-archive@odin.ietf.org; Mon, 20 Oct 2003 15:18:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KJI42Q004467 for ipcdn-archive@odin.ietf.org; Mon, 20 Oct 2003 15:18:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfXV-00019p-Ny; Mon, 20 Oct 2003 15:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfWu-00013P-3l for ipcdn@optimus.ietf.org; Mon, 20 Oct 2003 15:17:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13806 for ; Mon, 20 Oct 2003 15:17:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABfWs-0004EP-00 for ipcdn@ietf.org; Mon, 20 Oct 2003 15:17:22 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1ABfWr-0004DI-00 for ipcdn@ietf.org; Mon, 20 Oct 2003 15:17:22 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9KJGo10018017 for ; Mon, 20 Oct 2003 13:16:50 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Oct 2003 13:16:50 -0600 Message-ID: Thread-Topic: IETF#58 - IPCDN meeting on Tuesday 11/11, 1pm Thread-Index: AcOSZksFrirfTVpzRz2yFPA9sduIvgE2CMKQ From: "Jean-Francois Mule" To: "Ipcdn (E-mail)" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] IETF#58 - IPCDN meeting on Tuesday 11/11, 1pm 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, FYI - our meeting at IETF#58 is scheduled on: TUESDAY, November 11, 2003 1300-1400 Afternoon Sessions I See http://www.ietf.org/meetings/agenda_58.html=20 Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Oct 20 21:31:25 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 VAA18419 for ; Mon, 20 Oct 2003 21:31:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABlMW-0002GG-PY for ipcdn-archive@odin.ietf.org; Mon, 20 Oct 2003 21:31:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L1V4Cb008688 for ipcdn-archive@odin.ietf.org; Mon, 20 Oct 2003 21:31:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABlMU-0002Fv-J4; Mon, 20 Oct 2003 21:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABlMH-0002CR-Jq for ipcdn@optimus.ietf.org; Mon, 20 Oct 2003 21:30:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18333 for ; Mon, 20 Oct 2003 21:30:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABlME-0005Ms-00 for ipcdn@ietf.org; Mon, 20 Oct 2003 21:30:46 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ABlME-0005MK-00 for ipcdn@ietf.org; Mon, 20 Oct 2003 21:30:46 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9L1UD820382 for ; Mon, 20 Oct 2003 20:30:13 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3WQY1D>; Tue, 21 Oct 2003 03:30:12 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502B42F76@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Date: Tue, 21 Oct 2003 03:30:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: [ipcdn] FW: WG Review: IP over DVB (ipdvb) 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: , IPCDN folk, please check if this has overlap or conflicts with your WG. Thanks, Bert -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: maandag 20 oktober 2003 22:02 Cc: new-work@ietf.org; ip-dvb@erg.abdn.ac.uka.cnri.reston.va.us Subject: WG Review: IP over DVB (ipdvb) A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by October 27th. IP over DVB (ipdvb) ------------------- Current Status: Proposed Working Group Description of Working Group: The MPEG-2 Transport Stream provides a transmission network that has become widely use to support digital TV broadcast, including: DVB, ATSC, ISDB-T. These, and related standards, define a set of commercially available components that are increasingly being used to provide a general-purpose packet transmission network. MPEG-2 Transport networks are being used to build IP networks to supplement broadcast TV/audio services and also provide one-way and two-way IP-only subnetworks. There is a need to define an efficient standardised encapsulation for IPv4 and IPv6 datagrams, and to recommend procedures for supporting protocols. Examples include dynamic address resolution, multicast group membership reporting and possibly management information tables and MIBs. Documents will be defined that describe protocols required to build a complete IPv4/IPv6 unicast/multicast services, and the mappings required to perform dynamic address resolution. The primary purpose of this working group is to develop a set of Internet Drafts and where appropriate to progress these as either Internet Informational RFCs or Standards track RFCs. The current list of work items is: 1. Issue an Internet Draft specifying Requirements and Framework for supporting IP services via MPEG-2 transmission networks. Such requirements should consider the range of platforms currently (or anticipated to be) in use. This draft will be submitted to the IESG for possible publication as an Informational RFC. 2. The working group will investigate and design an efficient encapsulation method for IPv4/IPv6, and advance this via the IESG to a standards-track RFC. The design needs to consider the need for MAC addresses, the potential need for synchronisation between streams, support for IPv6 and multicast services, and support for multiple gateways (feeds). 3. The working group will consider the options for unicast and multicast address resolution. A working group Internet Draft will define a framework and recommend appropriate address resolution mechanisms for IPv4 and IPv6 using both the existing Multi-Protocol Encapsulation and any new encapsulation developed by the working group. Consideration will be paid to existing standards, and the cases for IPv6 and IPv4 will be described. This document will be submitted to the IESG for publication as an Informational RFC. 4. A working group Internet Draft will be written to recommend a set of dynamic address resolution procedures for IPv6. It will describe the protocol and syntax of the information exchanged. This work may be based on an extension to the Neighbor Discovery (ND) protocol to support MPEG-2 transmission, and include specific optimisations for broadcast networks. This document will be submitted to the IESG for publication as a standards-track RFC. 5. If there is a need for further supporting protocols, it will consider a possible recharter under the guidance of the IESG. Examples in this area include, the negotiation/association of IP QoS with MPEG-2 transport streams, address resolution for IPv4, and the need for SNMP MIBs. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Oct 20 22:41:26 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 WAA19688 for ; Mon, 20 Oct 2003 22:41:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABmSI-0005mf-ML for ipcdn-archive@odin.ietf.org; Mon, 20 Oct 2003 22:41:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L2f6RH022230 for ipcdn-archive@odin.ietf.org; Mon, 20 Oct 2003 22:41:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABmSD-0005j6-Uh; Mon, 20 Oct 2003 22:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABmRu-0005Zn-VL for ipcdn@optimus.ietf.org; Mon, 20 Oct 2003 22:40:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19661 for ; Mon, 20 Oct 2003 22:40:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABmRr-0005sn-00 for ipcdn@ietf.org; Mon, 20 Oct 2003 22:40:39 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1ABmRq-0005sc-00 for ipcdn@ietf.org; Mon, 20 Oct 2003 22:40:38 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9L2e710026285 for ; Mon, 20 Oct 2003 20:40:07 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Oct 2003 20:40:07 -0600 Message-ID: Thread-Topic: FYI: Update references Thread-Index: AcOXeP5aYAVKdc0qTYOacinojjpTAAAA24dA From: "Jean-Francois Mule" To: "Ipcdn (E-mail)" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] FYI: Update references 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 Forwarding this to the list for all mib authors. Thank you Eduardo. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Monday, October 20, 2003 8:14 PM To: Eduardo Cardona; Murwin William-LWM008; Wilson Sawyer; Jean-Francois Mule; Woundy, Richard Cc: Wijnen, Bert (Bert) Subject: RE: Update references Inline Thanks, Bert=20 > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: dinsdag 21 oktober 2003 1:10 > To: Murwin William-LWM008; Wilson Sawyer; Jean-Francois Mule; Woundy,=20 > Richard > Cc: Wijnen, Bert (Bert) > Subject: Update references >=20 >=20 >=20 > Hi All > As current editors of MIB drafts, >=20 > I noticed that from latest Bert's comments in BPI+ mib that in general > we missed the 3.5. References Sections requirement of=20 > draft-ietf-ops-mib-review-guidelines-02.txt See the list below >=20 > One Question For Bert, >=20 > I am doing some updates of few closed issues in RFIv2 MIB for IPCDN=20 > chairs, and I added in the normative references an entry because of=20 > IMPORT IANAifType-MIB >=20 > Would that be ok? or should I use an independent section IANA=20 > Considerations as in RFC 2932? >=20 If all you do is IMPORT from the IANAifTypeMIB, then all you need to do is add a normative reference to the web page that points to that IANA maintained MIB module. See for example RFC3292 [17] IANAifType - MIB DEFINITIONS, http://www.iana.org, January 2001. > I am a little bit confused with the OPS mib guidelines section 3.5 and > section 3.7. In the example of 3.7, RFC 2932 the IANA references are=20 > updates of an existing IANA document so I have no clear what is=20 > defining a IANA namespace and reference an IANA document ( like in=20 > IMPORTS) >=20 > This is the reference I added. >=20 >=20 > [IANA] "Protocol Numbers and Assignment Services",IANA, available=20 > at http://www.iana.org/assignments/ianaiftype-mib. >=20 >=20 That is even better than what I showed above If you just do an IMPORT, you are not defining new IAN guidelines. So no specific IANA considerations are needed. >=20 >=20 > The list below shows my compilation of IMPORTS clauses from QOS, BPI,=20 > CABLE, RFI and SUBMGT MIBs modules In overall, the first three=20 > references are covered for the boilerplate template, the others must=20 > be added in the Reference section >=20 > - I see in few cases the -- comments of the RFC as a guide in the=20 > imports; better avoid them since the Reference notes may overlook=20 > those changes and will be a long term typo in RFCs >=20 > DOCS-CABLE-DEVICE-MIB has almost references to all current drafts It=20 > will need extensive notes >=20 > IMPORTS > FROM SNMPv2-SMI --RFC2578 > FROM SNMPv2-TC --RFC2579 > FROM SNMPv2-CONF --RFC2580 > FROM SNMP-FRAMEWORK-MIB --RFC3411 > FROM IF-MIB --RFC2863 > FROM DOCS-IF-MIB --RFC2670 with note for new coming RFC=20 > FROM INET-ADDRESS-MIB --RFC3291 with note for new bis draft > FROM DIFFSERV-DSCP-TC -- RFC3289 > FROM IANAifType-MIB -- IANA reference preferable with link to=20 > the URL. > FROM RMON2-MIB --RFC 2021 >=20 >=20 looks good to me >=20 >=20 > Example of notes : for the normative section > RFC 3291 > ************************************************************ > * NOTES TO RFC Editor (to be removed prior to publication) * > * * > * 1.) The I-D (or a * > * successor) is expected to eventually replace RFC 3291. * > * If that draft (or a successor) is published as an RFC * > * prior to or concurrently with this document, then the * > * normative reference [RFC3291] should be updated to * > * point to the replacement RFC, and the reference tag * > * [RFC3291] should be updated to match. * > * * > ************************************************************ >=20 > Most inminent, using the same template... ( have the most > dependencies) > RFC 2760 - draft 08 if published before your drafts. >=20 > ************************************************************ > * NOTES TO RFC Editor (to be removed prior to publication) * > * * > * 1.) The I-D (or a * > * successor) is expected to eventually replace RFC 2670. * > * If that draft (or a successor) is published as an RFC * > * prior to or concurrently with this document, then the * > * normative reference [RFC2670] should be updated to * > * point to the replacement RFC, and the reference tag * > * [RFC2670] should be updated to match. * > * * > ************************************************************ >=20 >=20 > Etc. >=20 Looks good too. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Oct 22 06:23:22 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 GAA02519 for ; Wed, 22 Oct 2003 06:23:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACG8u-0006Ip-Ee for ipcdn-archive@odin.ietf.org; Wed, 22 Oct 2003 06:23:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MAN4pN024223 for ipcdn-archive@odin.ietf.org; Wed, 22 Oct 2003 06:23:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACG8q-0006Hi-J8; Wed, 22 Oct 2003 06:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACG8L-0006EC-Im for ipcdn@optimus.ietf.org; Wed, 22 Oct 2003 06:22:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02499 for ; Wed, 22 Oct 2003 06:22:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACG8H-0003FD-00 for ipcdn@ietf.org; Wed, 22 Oct 2003 06:22:25 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1ACG8G-0003EL-00 for ipcdn@ietf.org; Wed, 22 Oct 2003 06:22:24 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9MALr10028307 for ; Wed, 22 Oct 2003 04:21:54 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: WAS :[ipcdn] Proposed Changes to Section 2.2.2.1 of the DOCS-IETF-QOS-MIB, from comments about temp and operational SIDs / Now RFI Section requirements Date: Wed, 22 Oct 2003 04:21:53 -0600 Message-ID: Thread-Topic: WAS :[ipcdn] Proposed Changes to Section 2.2.2.1 of the DOCS-IETF-QOS-MIB, from comments about temp and operational SIDs / Now RFI Section requirements Thread-Index: AcOM71F/otL0VKOhTNq9zzqYoDqX+gLSj7LgABMU2SA= From: "Eduardo Cardona" To: 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 Forwarding to ipcdn list not included in below email Eduardo -----Original Message----- From: Eduardo Cardona=20 Sent: Tuesday, October 21, 2003 7:31 PM To: 'Murwin William-LWM008' Cc: Michael W. Patrick (E-mail); Minnie Lu; Jean-Francois Mule; Richard_Woundy@cable.comcast.com Subject: WAS :[ipcdn] Proposed Changes to Section 2.2.2.1 of the DOCS-IETF-QOS-MIB, from comments about temp and operational SIDs / Now RFI Section requirements=20 Hi IPCDN folks =20 To be ready for RFI mib draft 08 Here is the proposed text for RFI mib to 1.0/1.1/2.0 relationships=20 Management Interoperability of DOCSIS 1.0, 1.1 and 2.0 =20 The MIB module contained in this document updates RFC 2670,=20 primarly to handle the requirements of DOCSIS 2.0 [4] as described in the section 3 Overview. In the same way RFC 2670 contains the management=20 requirements for DOCSIS 1.0 and DOCSIS 1.1.=20 DOCSIS 1.1, [3] and adopted for DOCSIS 2.0 by [4], define a different service queuing mechanism known as QOS (ie see SNMP management module requirements for DOCSIS 2.0 in [5]). The management requirements of COS associated to RFC 2670 and=20 this document are the tables docsIfQosProfileTable,=20 docsIfCmServiceTable and docsIfCmtsServiceTable and the specifics=20 CM/CMTS support for DOCSIS 1.0, 1.1 and 2.0 are defined in their=20 Particular management specifications and MIB requirements associated=20 To [2], [3] and [4] respectively and out of scope of this document. As William pointed in the email of the subject and hearing vendors concers to restrict at this late implementation time something that could be used havely for MSOs when the spec was silent about (eg docsIfCmtsServiceTable US counters for all type of registered CMs ) Below are some extra notes=20 Let us know if it is adecuate or better not include anything in the MIB=20 Item 5 in Qos MIB 2.2.2.1 is no longer applicable in William's edits and with the notes below is may be undesirable to be added to RFI MIB=20 Question, Is the proposed "Management Interoperability of DOCSIS 1.0, 1.1 and 2.0" section needed? QoS is above RFI mib and is already defining (items 1..4 ) interoperability for 1.1 and 2.0 CMs, 1.0 only capable devices won't handle QOS mib and the OSSI spec has "enough" mib requirements. See some extra previouly recollected notes: # issue 14=20 =20 QOS-MIB current spec requirement D04 (DOCSIS 1.1 and 2.0) does not have item 5 in=20 section 2.2.2.1 Interoperation with DOCSIS 1.0 =20 draft 08 has item 5 and draft 09 coming proposal will remove item 5 again =20 from DOCS-IETF-QOS-MIB section 2.2.2.1 Interoperation with DOCSIS 1.0, item 5 =20 5. At the CMTS, the Docsis 1.0 MIB objects docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets for a SID assigned to a Docsis 1.1 or Docsis 2.0 modem count only the pre-registration packets/bytes of those modems. =20 =20 =20 The rationale for removing this note is : see (William Murwin) email about its=20 proposal for draft 09 DOCSIS 1.0 and early 1.1 MSOs followed different paths to support specific needs, per=20 MSOs request, related objects in docsIfCmtsServiceTable are critical for user usage tracking.=20 Placing requirements in QOS MIB and RFI MIB at this late stage is=20 going to create confusion. Therefore, the initial though of placing=20 item 5 in DOCS-IF-MIB is not a convenient path. =20 Instead a generic requirement of RFI MIB requirements which could be=20 accomplished with a mapping e.g device sysDescr to a sort of=20 AGENT-CAPABILITY vendor/MSO/CERTWave compliance module would be more=20 appropiate. Such AGENT-CAPABILITY structures do not exist, OSSI specs=20 might handle some of them like appendix A and other non-defined=20 relationships that makes current implementation not broken by any new proposal like item 5 mentioned above =20 For RFI mib v2=20 A proposed general section describing DOCSIS 1.0 1.1 and 2.0 relationships (see text above) also a glosary set of terms to able to handle easily for a lector the=20 1.x very common word in objects text descriptions =20 Any intentional direct mention to SNMP management framework of QOS is avoided=20 in the section below and relay in RFI spec mandatory reference to OSSI spec and then QOS mib. =20 Let us know it the text below is adecuate COB Thrusday Oct 23 2003, or if we avoid the section. Thanks Eduardo =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Oct 24 09:07:26 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 JAA28997 for ; Fri, 24 Oct 2003 09:07:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD1ek-0004EK-8y for ipcdn-archive@odin.ietf.org; Fri, 24 Oct 2003 09:07:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OD75P1016219 for ipcdn-archive@odin.ietf.org; Fri, 24 Oct 2003 09:07:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD1ee-0004Bj-3r; Fri, 24 Oct 2003 09:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD1eV-000442-Bj for ipcdn@optimus.ietf.org; Fri, 24 Oct 2003 09:06:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28969 for ; Fri, 24 Oct 2003 09:06:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD1eT-00032O-00 for ipcdn@ietf.org; Fri, 24 Oct 2003 09:06:49 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AD1eT-00031y-00 for ipcdn@ietf.org; Fri, 24 Oct 2003 09:06:49 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9OD6G10017775; Fri, 24 Oct 2003 07:06:16 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt Date: Fri, 24 Oct 2003 07:06:16 -0600 Message-ID: Thread-Topic: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt Thread-Index: AcOSZlY5L6H4uayBSMuzaTPspJBqYAHFXHkQ From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" 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 Thanks again for all the comments=20 Summary of actions for new draft 1. Agree, fixed 2. WHen I compile (syntax check) with smilint I get: .\DOCS-IETF-BPI2-MIB:3076: [4] {compliance-group-status} warning: current compliance statement `docsBpi2CmtsCompliance' includes obsolete group `docsBpi2ObsoleteObjectsGroup' >>> Will remove docsBpi2ObsoleteObjectsGroup from CMTS compliance module as GROUP clause Rename GROUP-OBJECT docsBpi2ObsoleteObjectsGroup as docsBpi2CmtsObsoleteObjectsGroup 3. Agree done 4. Agree done, 5. Agree done Technical issues/questions a. I am not sure I understand the relationship between RFC3083 and this I-D. Would a device implement both MIB modules? - If not, =20 >>>=20 Yes and No. Specs and MIBS are for capability compliances BPI + is an enhancement of the BPI protocol, but BPI+ became a different protocol. Will propose to add a section in Overview (MIB Module Implementation) to point to the specs references) Something among: =20 BPI compliant devices support rfc 3083 (CM/CMTS) BPI+ compliant devices support BPIPlus MIB BPI+, CM/CMTS. =20 Particularly, the CM, if instructed (configured) to=20 fall back to DOCSIS "1.0 mode" will support BPI compliant <<< - If yes, I see a lot of duplication and I wonder if that is good, in fact I doubt it. >>> IT does not seems to be good for the duplication as yoou pointed=20 but the added objects ( 50+) in BPI+ look "very disorganized" if you add all of them at the end of the respective tables, specially where peer objects=20 are at initial tables OIDs=20 The bottom line, consider BPI and BPI + as different protocols, then independent MIBS are needed Two cases as examples =20 BPI has only one Auth key, so Param1 of Auth key, now should (?) match OLD Auth key BPI+;=20 NEW Auth Key is exclusive of BPI+ Some parameters ranges ( protocol FSM fninite state machine) were extended out of the original range which would imply objects deprecation=20 An operator would have many capable 1.1/2.0 CMs but still manage them as 1.0 configured network in other words, CM operating as 1.0 modems with a 1.0 management system. It will imply support both MIBS simultaneously for management and only one operational mode Similar case as will happen with Ipv4/v6 transitions, IpForward MIB,=20 a vendor new box support v4/v6 dual stack but the box can also be configured to support only IPv4 stack Operator has legacy ipv4 boxes managemnt system but not IPv6 deployments. What mib is going an operator to use? IMO, will use old Ipv4 Ipforward =20 Same case are DOCSIS transitions, the mib selection is a device specification requirements, based on operator requests, RFPs, etc. ( in this case MSO by CL standards). I would agree that a whole grain of Compliance statements would be good, but all those details are in the DOCSIS specs, The section I will add will show all this references : here is a draft.... 2.2 MIB Module implementation This section describe the overall implementation framework of BPI+ MIB module to clarify the relation with BPI MIB [RFC3083]. BPI/BPI+ MIB requirements depends both on the device specification compliance and additionally for CM, of its DOCSIS operational mode when connected to a partcular CMTS type 2.2.1 DOCSIS Specification Compliance Classification DOCSIS currently defines three kinds of interoperable specification compliance devices based on the DOCSIS RFI specifications: DOCSIS 1.0 CM/CMTS defined in [3] DOCSIS 1.1 CM/CMTS defined in [4] DOCSIS 2.0 CM/CMTS defined in [5] 2.2.2 DOCSIS Operational Modes DOCSIS operational mode refers to the CM specification compliance set of functionalities and the interoperability requirements to connect to a specific CMTS type (2.0, 1.1, 1.0). In general this document calls DOCSIS 1.1 mode a configuration where a DOCSIS 2.0/1.1 CM can interoperate with a 1.1 CMTS; in the same way, a DOCSIS 1.0 mode is a configuration where a DOCSIS 2.0/1.1/1.0 CM can interoperate with a 1.0 CMTS. In the CMTS side a 2.0 CMTS can support simultaneously CMs configured in either DOCSIS 2.0, 1.1 or 1.0 mode. For the scope of the BPI+ requirements DOCSIS 2.0 mode is equivalent to DOCSIS 1.1 mode (*) 2.2.3 BPI/BPI+ MIB implementation:=20 Based on CM perational modes and CM/CMTS specification compliances below is a summary of Baseline Privacy Interface MIB modules requirements (BPI and BPI+) 1. DOCSIS 1.0 CM/CMTS only implements BPI MIB per [6],=20 2. DOCSIS 2.0 and 1.1 CMTS only implements BPI+ MIB per [8]=20 and[7] respectively 3. DOCSIS 2.0 and 1 1 CM in DOCSIS 1.0 mode implements BPI MIB=20 plus the BPI+ MIB objects associated with Authentication of=20 Downloaded Images 4. DOCSIS 2.0 and 1.1 CM in DOCSIS 1.1 mode (*) implements only=20 BPI+ MIB 5. DOCSIS 2.0 and 1.1 CM BPI MIB requirements are in [8] and [7]=20 respectively <<< b. I do not understand why one is Unsigned32 and the other Integer32 docsBpi2CmTEKSAId OBJECT-TYPE SYNTAX Unsigned32 (1..16383) docsBpi2CmIpMulticastSAId OBJECT-TYPE SYNTAX Integer32 (0..16383) docsBpi2CmtsAuthPrimarySAId OBJECT-TYPE SYNTAX Integer32 (0..16383) docsBpi2CmtsTEKSAId OBJECT-TYPE SYNTAX Unsigned32 (1..16383) docsBpi2CmtsIpMulticastSAId OBJECT-TYPE SYNTAX Integer32 (0..16383) docsBpi2CmtsMulticastAuthSAId OBJECT-TYPE SYNTAX Unsigned32 (1..16383) Oh well, a couple of TCs seems justified too, maybe a DocsSAId and a DocsSAIdOrNone (or DocsSAIdOrZero) TC >>>=20 Before the above list (integer32 vs Unsigned32) all were integer32 A previous discussion and revision recommended for indexes to use Unsigned32=20 ------------------------ > - docsBpi2CmIpMulticastIndex OBJECT-TYPE > SYNTAX Integer32 (1..1000) > It is valid. But for INDEX objects we prefer Unsigned32 with > a range. see again the mib review guidelines doc > I think this occurs a few more time in this MIB module. > As I say, it is valid, but since your still working on this > MIB module, might as well use the recommended method. -> certainly. fixed all integer32 INDEX objects syntax to Unsigned32. This includes the following objects: docsBpi2CmTEKSAId docsBpi2CmIpMulticastIndex docsBpi2CmCryptoSuiteIndex docsBpi2CmtsTEKSAId docsBpi2CmtsIpMulticastIndex docsBpi2CmtsMulticastAuthSAId docsBpi2CmtsCACertIndex -------------------------- The change in indexes does not interfere with the wire compatibility of already implemented systems, The changes in the columnar values will.. =20 The two Textual conventions can be used ( will try to get those on time today) 1..16383 Unsinged are all index 0..16383 are columnar values=20 optimally SAIds are in range 0 (unknown) 1 to 16383 range 1 to 16383 is needed for Indexing tables ( only known SAIds can create entries) Which is all consistent DocsSAId and=20 DocsSAIdOrZero (maybe) <<<< - Why is there a reference to RFC2819? >>> Agree , should be RFC 2021 RMON2-MIB; done - Since you import from docsIfMib (RFC2670), you must have a normative reference to RFC2670 >>> Agree, done - Since you import from IF-MIB, you must have a normative reference to RFC2863 >>> Agree, done - I see no citations to RFC3414 and RFC3415, neither do I see any IMPORTS from those RFCs. So I do not see why they are in the references section at all, let alone in the normative references section >>> Agree, done - In section 2, I recommend to use "MIB module" instead of "MIB" It occures several times. This to recognize that there is=20 only one (single) MIB that is composed of mul;tiple MIB modules. >>> Agree, done (~ 5 places ?) - docsBpi2ObsoleteObjectsGroup OBJECT-GROUP Pls add to DESCRIPTION why this is/was obsoleted. =20 >>> will do, proposed text below:=20 Before was : docsBpi2ObsoleteObjectsGroup docsBpi2CmtsObsoleteObjectsGroup OBJECT-GROUP OBJECTS { docsBpi2CmtsAuthCmGraceTime, docsBpi2CmtsTEKGraceTime } STATUS obsolete DESCRIPTION "This is a collection of obsolete CMTS BPI+ objects. The MIB objects in this group were conceived in early=20 draft versions of this document, and kept to maintain a continuous and uniform OID structure with pre-RFC field implementations. Particularly, the objects reports Grace Time timeouts; a=20 CMTS does not require knowledge of those Security=20 associations parameters, which are sole CM responsibility." ::=3D { docsBpi2Groups 4 } <<< - Your MODULE-COMPLIANCE says that an implementation is only required to support IPv4. You may want to add to the DESCRIPTION=20 clause(s) why only IPv4 (or why not IPv6) needs to be supported. >>> will add (borrow from MTA MIB; ) =20 " Support for address types other than 'ipv4(1)' =20 is not presently specified and therefore, is not =20 required. It may be defined in future versions of =20 this MIB module."=20 <<< Thanks Eduardo -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Tuesday, October 14, 2003 9:16 AM To: Ipcdn (E-mail) Subject: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt Did I review this one before? I need to dive into my archives=20 to check, but it feels like I did. Anyway, here is comments based on my first quick check. I need to look some more into this document, so consider this review incomplete. 1. When compiling (for SYNTAX checking) with SMICng I get: W: f(bpiplus.mi2), (104,22) Revision date not in proper order - most recent comes first 2. WHen I compile (syntax check) with smilint I get: .\DOCS-IETF-BPI2-MIB:3076: [4] {compliance-group-status} warning: current compliance statement `docsBpi2CmtsCompliance' includes obsolete group `docsBpi2ObsoleteObjectsGroup' 3. Checking with checkpage.awk I get: $ /bin/checkpage.awk < drafts/draft-ietf-ipcdn-bpiplus-mib-11.txt Bad chars at 3899 Bad chars at 3907 Bad chars at 4189 -: 3 lines containing non-US-ASCII characters 4. Since this is a very first (formal) publication (as RFC) of this MIB module, the tradition (and guideline) is to have one and only one REVISION clause. I see that you have instructions to RFC editor to remove the extra one. WHy not just remove them now (or move them to an appendix to be removed later). 5. In the following, I see that the DESCRIPTION clause is out of sync with the actual enumrations ??!!: DocsBpkmSAType ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of this object is the type of security association. The values of the named-numbers are associated with the BPKM SA-Type attributes: 'primary' corresponds to code '0', 'static' to code '1' 'dynamic' to code '2'. 'none' value must only be used if the SA type has yet to be determined. " REFERENCE "DOCSIS Baseline Privacy Plus Interface specification, Section 4.2.2.24" SYNTAX INTEGER { none(0), primary(1), static(2), dynamic(3) } Or are the "code '0'" different codes at some other place. If that is the case, then maybe the ENUMs should sync up with those codes. no? Technical issues/questions a. I am not sure I understand the relationship between RFC3083 and this I-D. Would a device implement both MIB modules? - If not, does that mean that this MIB Module obsoletes the MIB in 3083? If so it needs to be specified. And if it does obsolte 3083, then the normal process would be to deprecate/obsolete pieces in 3083 that are no longer used and to add new objects that are new, but keep the old one.=20 This method does work too... and I think is acceptable as long as we do so consciously. - If yes, I see a lot of duplication and I wonder if that is good, in fact I doubt it. In any event, it would be wise to document the relationship between these documents better than currently done in the overview section b. I do not understand why one is Unsigned32 and the other Integer32 docsBpi2CmTEKSAId OBJECT-TYPE SYNTAX Unsigned32 (1..16383) docsBpi2CmIpMulticastSAId OBJECT-TYPE SYNTAX Integer32 (0..16383) docsBpi2CmtsAuthPrimarySAId OBJECT-TYPE SYNTAX Integer32 (0..16383) docsBpi2CmtsTEKSAId OBJECT-TYPE SYNTAX Unsigned32 (1..16383) docsBpi2CmtsIpMulticastSAId OBJECT-TYPE SYNTAX Integer32 (0..16383) docsBpi2CmtsMulticastAuthSAId OBJECT-TYPE SYNTAX Unsigned32 (1..16383) Oh well, a couple of TCs seems justified too, maybe a DocsSAId and a DocsSAIdOrNone (or DocsSAIdOrZero) TC c. Administrative comments and NITs: - Why is there a reference to RFC2819? - Since you import from docsIfMib (RFC2670), you must have a normative reference to RFC2670 - Since you import from IF-MIB, you must have a normative reference to RFC2863 - I see no citations to RFC3414 and RFC3415, neither do I see any IMPORTS from those RFCs. So I do not see why they are in the references section at all, let alone in the normative references section - In section 2, I recommend to use "MIB module" instead of "MIB" It occures several times. This to recognize that there is=20 only one (single) MIB that is composed of mul;tiple MIB modules. - docsBpi2ObsoleteObjectsGroup OBJECT-GROUP Pls add to DESCRIPTION why this is/was obsoleted. - Your MODULE-COMPLIANCE says that an implementation is only required to support IPv4. You may want to add to the DESCRIPTION=20 clause(s) why only IPv4 (or why not IPv6) needs to be supported. Thanks, Bert=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Oct 24 18:15:22 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 SAA03773 for ; Fri, 24 Oct 2003 18:15:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADAD2-00006f-6M for ipcdn-archive@odin.ietf.org; Fri, 24 Oct 2003 18:15:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OMF3TH000400 for ipcdn-archive@odin.ietf.org; Fri, 24 Oct 2003 18:15:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADAD0-00005R-JL; Fri, 24 Oct 2003 18:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADACZ-0008Qu-F6 for ipcdn@optimus.ietf.org; Fri, 24 Oct 2003 18:14:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03575 for ; Fri, 24 Oct 2003 18:14:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADACW-0005TX-00 for ipcdn@ietf.org; Fri, 24 Oct 2003 18:14:32 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1ADACV-0005S4-00 for ipcdn@ietf.org; Fri, 24 Oct 2003 18:14:32 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9OME010006456; Fri, 24 Oct 2003 16:14:00 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt Date: Fri, 24 Oct 2003 16:13:57 -0600 Message-ID: Thread-Topic: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt Thread-Index: AcOSZlY5L6H4uayBSMuzaTPspJBqYAHFXHkQAD8NsOA= From: "Jean-Francois Mule" To: "Eduardo Cardona" , "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" 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 Eduardo, A quick comment regarding the relationship between the BPI+ and BPI MIB = modules.=20 If you decide to add some informative text to explain it, I would = recommend keeping it short and only stating the compliance in terms of = DOCSIS 1.0/1.1/2.0, see more below. The considerations on operational = modes - even though it is valuable information - are outside any = implementation consideration for this MIB and they are a given due to = the fact that a 2.0 CM can run in 1.0 mode and this depends on operator = config & CMTS. Refer to appendix C of the BPI+ specification (a normative ref) for more = details on interop between bpi and bpi+. You wrote: ... snipped > 2.2 MIB Module implementation How about a single section called "Relationship between BPI+ and BPI = MIBs" > This section describe the overall implementation framework of=20 > BPI+ MIB module to clarify the relation with BPI MIB=20 > [RFC3083]. BPI/BPI+ MIB requirements depends both on the=20 > device specification compliance and additionally for CM, of=20 > its DOCSIS operational mode when connected to a partcular CMTS type The pb I have with this sentence is that the actual CM requirements = (what a CM must implement) do not depend on the operational mode.=20 >=20 > 2.2.1 DOCSIS Specification Compliance Classification > DOCSIS currently defines three kinds of interoperable=20 > specification compliance devices based on the DOCSIS RFI=20 > specifications: DOCSIS 1.0 CM/CMTS defined in [3] DOCSIS 1.1=20 > CM/CMTS defined in [4] DOCSIS 2.0 CM/CMTS defined in [5] >=20 > 2.2.2 DOCSIS Operational Modes >=20 > DOCSIS operational mode refers to the CM specification=20 > compliance set of functionalities and the interoperability=20 > requirements to connect to a specific CMTS type (2.0, 1.1,=20 > 1.0). In general this document calls DOCSIS 1.1 mode a=20 > configuration where a DOCSIS 2.0/1.1 CM can interoperate with=20 > a 1.1 CMTS; in the same way, a DOCSIS 1.0 mode is a=20 > configuration where a DOCSIS 2.0/1.1/1.0 CM can interoperate=20 > with a 1.0 CMTS. In the CMTS side a 2.0 CMTS can support=20 > simultaneously CMs configured in either DOCSIS 2.0, 1.1 or=20 > 1.0 mode. For the scope of the > BPI+ requirements DOCSIS 2.0 mode is equivalent to DOCSIS 1.1 mode (*) >=20 >=20 > 2.2.3 BPI/BPI+ MIB implementation:=20 The section below is very confusing and I strongly recommend to = reference the BPI+ spec without trying to put too much details in the = MIB. MIB implementers will have to read the spec (hopefully ;). >=20 > Based on CM perational modes and CM/CMTS specification=20 > compliances below is a summary of Baseline Privacy Interface=20 > MIB modules requirements (BPI and BPI+) 1. DOCSIS 1.0=20 > CM/CMTS only implements BPI MIB per [6],=20 > 2. DOCSIS 2.0 and 1.1 CMTS only implements BPI+ MIB per [8]=20 > and[7] respectively > 3. DOCSIS 2.0 and 1 1 CM in DOCSIS 1.0 mode implements BPI MIB=20 > plus the BPI+ MIB objects associated with Authentication of=20 > Downloaded Images > 4. DOCSIS 2.0 and 1.1 CM in DOCSIS 1.1 mode (*) implements only=20 > BPI+ MIB > 5. DOCSIS 2.0 and 1.1 CM BPI MIB requirements are in [8] and [7]=20 > respectively How about something like this: ------------ 2.2 Relationship between BPI+ and BPI MIBs This section describes the relationship between the BPI+ MIB module = defined in this document and the BPI MIB module defined in RFC 3083 = [RFC3083]. The BPI+ protocol interface is an enhancement to the BPI = protocol and it is a distinct protocol from BPI. The associated BPI+ = managed objects should be considered separate from the BPI MIB objects = defined in RFC 3083. DOCSIS 1.1 and 2.0 systems must implement the BPI+ specification. For = more information regarding the interoperability between BPI and BPI+ = systems, refer to appendix C of the BPI+ specification [xxx]. ------------ Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Oct 24 21:20:23 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 VAA08265 for ; Fri, 24 Oct 2003 21:20:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADD63-0001ug-A2 for ipcdn-archive@odin.ietf.org; Fri, 24 Oct 2003 21:20:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9P1K39n007338 for ipcdn-archive@odin.ietf.org; Fri, 24 Oct 2003 21:20:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADD62-0001u5-AH; Fri, 24 Oct 2003 21:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADD5T-0001s0-IT for ipcdn@optimus.ietf.org; Fri, 24 Oct 2003 21:19:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08243 for ; Fri, 24 Oct 2003 21:19:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADD5Q-0007CF-00 for ipcdn@ietf.org; Fri, 24 Oct 2003 21:19:24 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1ADD5Q-0007C9-00 for ipcdn@ietf.org; Fri, 24 Oct 2003 21:19:24 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9P1Iq10019260; Fri, 24 Oct 2003 19:18:53 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt Date: Fri, 24 Oct 2003 19:18:52 -0600 Message-ID: Thread-Topic: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt Thread-Index: AcOSZlY5L6H4uayBSMuzaTPspJBqYAHFXHkQAD8NsOAAAr0ToA== From: "Eduardo Cardona" To: "Jean-Francois Mule" , "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" 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 Thanks Jean-Francois,=20 I Agree the vendors read all specs RFI, BPI, OSSI to implement the = protocols and BPI MIBs=20 I will use your proposed wording with some sligth variations.=20 Some additional comments below the --- section --- ----------------------------- To your suggestion: - Remove the must statements to make that informational and refer to the = specs - Because the title BPI+ vs BPI MIBs, your text does not really refers = to=20 BPI MIBs relationships just BPI specs (?),=20 - Also the reference to RFC 3083 in Appendix F of BPI+ spec=20 is not cited in the spec text (our fault), so, BPI+ spec does not = reference=20 to BPI MIB (CM requirements) when OSSI does, so I added a couple = of=20 references in your text to close the loop. Please suggest any changes you would like Proposed text: 2.2 Relationship between BPI+ and BPI MIBs This section describes the relationship between the BPI+ MIB module = defined in this document and the BPI MIB module defined in RFC 3083 = [RFC3083]. The BPI+ protocol interface is an enhancement to the BPI = protocol and it is a distinct protocol from BPI. The associated BPI+ = managed objects should be considered separate from the BPI MIB objects = defined in RFC 3083. DOCSIS 1.1 and 2.0 systems implement both BPI+ and BPI protocols to be = backward compatible with 1.0 systems. For more information regarding the = interoperability between BPI and BPI+ systems, refer to appendix C of = [1] and for MIB modules requirements, refers to section 4.6.1, Figure 9 = of [3] and 7.6.1, Table 7-9 of [4] ------------------------------ More notes: The operational mode (config file) defines the BPI protocol to support, = as an example a 1.1/2.0 CM support both BPI and BPI+ protocols and = because a 1.1/2.0 CM in a 1.0 CMTS, the CMTS only knows BPI and won't = understand BPI+ capabilities in the REG-REQ message. =20 The initial proposed text is the complete matrix of combinations for mib = implementation, and I agree that a reader will have a terrible headacke = reading that, with no more options that going to the specs. The problem is summarized as : Graphically is more digestable=20 Indeed mode of operation ( config file for (1.0 operational mode style) 1.1 and 2.0 CM will load = all BPI MIB and ( SSD of BPI+ ) Config file for (1.1 operational mode style) 1.1 and 2.0 CM will load = all BPI+ only *SSD (secure Software Download only for 1.1/2.0 systems) is not really = part of the BPI+ protocol, but it is a security feature of DOCSIS, which = is the only security spec available in DOCSIS, then SSD was incorporated = to BPI+ spec and MIBs. see OSSIv1.1=20 http://www.cablemodem.com/downloads/specs/SP-OSSIv1.1-I07-030730.pdf 4.6.1 Coexistence and MIBs=20 Figure 9. CM DOCSIS Mode and MIBs Requirement =20 Or in OSSIv2.0 spec=20 http://www.cablemodem.com/downloads/specs/SP-OSSIv2.0-I04-030730.pdf Section 7.6.1 Coexistence and MIBs Table 7-9 DOCSIS 2.0 CM Modes and MIB Requirements -----Original Message----- From: Jean-Francois Mule=20 Sent: Friday, October 24, 2003 4:14 PM To: Eduardo Cardona; Wijnen, Bert (Bert); Ipcdn (E-mail) Subject: RE: [ipcdn] AD (MIB Dcotor) review of: = draft-ietf-ipcdn-bpiplus-mib-11.txt Eduardo, A quick comment regarding the relationship between the BPI+ and BPI MIB = modules.=20 If you decide to add some informative text to explain it, I would = recommend keeping it short and only stating the compliance in terms of = DOCSIS 1.0/1.1/2.0, see more below. The considerations on operational = modes - even though it is valuable information - are outside any = implementation consideration for this MIB and they are a given due to = the fact that a 2.0 CM can run in 1.0 mode and this depends on operator = config & CMTS. Refer to appendix C of the BPI+ specification (a normative ref) for more = details on interop between bpi and bpi+. You wrote: ... snipped > 2.2 MIB Module implementation How about a single section called "Relationship between BPI+ and BPI = MIBs" > This section describe the overall implementation framework of > BPI+ MIB module to clarify the relation with BPI MIB > [RFC3083]. BPI/BPI+ MIB requirements depends both on the > device specification compliance and additionally for CM, of=20 > its DOCSIS operational mode when connected to a partcular CMTS type The pb I have with this sentence is that the actual CM requirements = (what a CM must implement) do not depend on the operational mode.=20 >=20 > 2.2.1 DOCSIS Specification Compliance Classification > DOCSIS currently defines three kinds of interoperable > specification compliance devices based on the DOCSIS RFI=20 > specifications: DOCSIS 1.0 CM/CMTS defined in [3] DOCSIS 1.1=20 > CM/CMTS defined in [4] DOCSIS 2.0 CM/CMTS defined in [5] >=20 > 2.2.2 DOCSIS Operational Modes >=20 > DOCSIS operational mode refers to the CM specification > compliance set of functionalities and the interoperability=20 > requirements to connect to a specific CMTS type (2.0, 1.1,=20 > 1.0). In general this document calls DOCSIS 1.1 mode a=20 > configuration where a DOCSIS 2.0/1.1 CM can interoperate with=20 > a 1.1 CMTS; in the same way, a DOCSIS 1.0 mode is a=20 > configuration where a DOCSIS 2.0/1.1/1.0 CM can interoperate=20 > with a 1.0 CMTS. In the CMTS side a 2.0 CMTS can support=20 > simultaneously CMs configured in either DOCSIS 2.0, 1.1 or=20 > 1.0 mode. For the scope of the > BPI+ requirements DOCSIS 2.0 mode is equivalent to DOCSIS 1.1 mode (*) >=20 >=20 > 2.2.3 BPI/BPI+ MIB implementation: The section below is very confusing and I strongly recommend to = reference the BPI+ spec without trying to put too much details in the = MIB. MIB implementers will have to read the spec (hopefully ;). >=20 > Based on CM perational modes and CM/CMTS specification > compliances below is a summary of Baseline Privacy Interface=20 > MIB modules requirements (BPI and BPI+) 1. DOCSIS 1.0=20 > CM/CMTS only implements BPI MIB per [6],=20 > 2. DOCSIS 2.0 and 1.1 CMTS only implements BPI+ MIB per [8]=20 > and[7] respectively > 3. DOCSIS 2.0 and 1 1 CM in DOCSIS 1.0 mode implements BPI MIB=20 > plus the BPI+ MIB objects associated with Authentication of=20 > Downloaded Images > 4. DOCSIS 2.0 and 1.1 CM in DOCSIS 1.1 mode (*) implements only=20 > BPI+ MIB > 5. DOCSIS 2.0 and 1.1 CM BPI MIB requirements are in [8] and [7]=20 > respectively How about something like this: ------------ 2.2 Relationship between BPI+ and BPI MIBs This section describes the relationship between the BPI+ MIB module = defined in this document and the BPI MIB module defined in RFC 3083 = [RFC3083]. The BPI+ protocol interface is an enhancement to the BPI = protocol and it is a distinct protocol from BPI. The associated BPI+ = managed objects should be considered separate from the BPI MIB objects = defined in RFC 3083. DOCSIS 1.1 and 2.0 systems must implement the BPI+ specification. For = more information regarding the interoperability between BPI and BPI+ = systems, refer to appendix C of the BPI+ specification [xxx]. ------------ Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Oct 24 23:22:55 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 XAA10480 for ; Fri, 24 Oct 2003 23:22:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADF0Y-0001r9-AM for ipcdn-archive@odin.ietf.org; Fri, 24 Oct 2003 23:22:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9P3MSlQ007110 for ipcdn-archive@odin.ietf.org; Fri, 24 Oct 2003 23:22:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADF08-0001pb-Lu; Fri, 24 Oct 2003 23:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADEzf-0001oe-BM for ipcdn@optimus.ietf.org; Fri, 24 Oct 2003 23:21:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10463 for ; Fri, 24 Oct 2003 23:21:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADEzd-0000Hq-00 for ipcdn@ietf.org; Fri, 24 Oct 2003 23:21:33 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1ADEzc-0000HS-00 for ipcdn@ietf.org; Fri, 24 Oct 2003 23:21:32 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9P3L110026688 for ; Fri, 24 Oct 2003 21:21:01 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt Date: Fri, 24 Oct 2003 21:21:01 -0600 Message-ID: Thread-Topic: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt Thread-Index: AcOSZlY5L6H4uayBSMuzaTPspJBqYAHFXHkQAD8NsOAAAr0ToAAI+XhA From: "Jean-Francois Mule" To: "Eduardo Cardona" , "Ipcdn (E-mail)" 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 Eduardo wrote: > Please suggest any changes you would like >=20 > Proposed text: >=20 >=20 > 2.2 Relationship between BPI+ and BPI MIBs > This section describes the relationship between the BPI+ MIB=20 > module defined in this document and the BPI MIB module=20 > defined in RFC 3083 [RFC3083]. The BPI+ protocol interface is=20 > an enhancement to the BPI protocol and it is a distinct=20 > protocol from BPI. The associated BPI+ managed objects should=20 > be considered separate from the BPI MIB objects defined in RFC 3083. >=20 > DOCSIS 1.1 and 2.0 systems implement both BPI+ and BPI=20 > protocols to be backward compatible with 1.0 systems. For=20 > more information regarding the interoperability between BPI=20 > and BPI+ systems, refer to appendix C of [1] and for MIB=20 > modules requirements, refers to section 4.6.1, Figure 9 of=20 > [3] and 7.6.1, Table 7-9 of [4] Looks good to me. Jean-Fran=E7ois _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Sat Oct 25 00:45:23 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 AAA12951 for ; Sat, 25 Oct 2003 00:45:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADGIR-0002M9-Go for ipcdn-archive@odin.ietf.org; Sat, 25 Oct 2003 00:45:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9P4j3ax009035 for ipcdn-archive@odin.ietf.org; Sat, 25 Oct 2003 00:45:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADGIQ-0002LV-Mb; Sat, 25 Oct 2003 00:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADGIF-0002JQ-18 for ipcdn@optimus.ietf.org; Sat, 25 Oct 2003 00:44:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12927 for ; Sat, 25 Oct 2003 00:44:39 -0400 (EDT) From: perozbabu@mototech.com.tw Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADGIC-0000xn-00 for ipcdn@ietf.org; Sat, 25 Oct 2003 00:44:48 -0400 Received: from 211-23-55-85.hinet-ip.hinet.net ([211.23.55.85] helo=relay.mototech.com.tw) by ietf-mx with smtp (Exim 4.12) id 1ADGIB-0000we-00 for ipcdn@ietf.org; Sat, 25 Oct 2003 00:44:47 -0400 Received: from mototech.com.tw ([10.12.1.9]) by AccSMTP/NT 2.5 [10.12.1.6]; Sat, 25 Oct 2003 12:43:16 +0800 To: ipcdn@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Sat, 25 Oct 2003 12:40:02 +0800 X-MIMETrack: Serialize by Router on NS1/Mototech(Release 5.0.9 |November 16, 2001) at 2003/10/25 12:40:02 PM MIME-Version: 1.0 Content-type: text/plain; charset=Big5 Subject: [ipcdn] Re: IPCDN digest, Vol 1 #489 - 1 msg 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: , Dr. sir, I am Peroz [software engineer] and need some doc. on CMS-MTA and CMS simulator[TCLSIM]. I am doing a project on Packetcable-ctp testing. It is On-net-TO-On-net. I want to do basic testing. dial tone,phone ring enabling ..etc.... Is it possible for you to give some solution on this. Please I need a response desperately. Regards Peroz. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Sat Oct 25 10:06:27 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 KAA05699 for ; Sat, 25 Oct 2003 10:06:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADP3N-0001c5-7w for ipcdn-archive@odin.ietf.org; Sat, 25 Oct 2003 10:06:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9PE65NX006198 for ipcdn-archive@odin.ietf.org; Sat, 25 Oct 2003 10:06:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADP3K-0001bj-Kq; Sat, 25 Oct 2003 10:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADP3D-0001b5-Rt for ipcdn@optimus.ietf.org; Sat, 25 Oct 2003 10:05:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05623 for ; Sat, 25 Oct 2003 10:05:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADP3B-0005MP-00 for ipcdn@ietf.org; Sat, 25 Oct 2003 10:05:53 -0400 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1ADP3B-0005ME-00 for ipcdn@ietf.org; Sat, 25 Oct 2003 10:05:53 -0400 Received: from comcast.net (h00045af3c79a.ne.client2.attbi.com[24.128.28.68]) by comcast.net (sccrmhc11) with SMTP id <2003102514052201100665f5e> (Authid: sawyerwd); Sat, 25 Oct 2003 14:05:22 +0000 Message-ID: <3F9A837F.514DCCF6@comcast.net> Date: Sat, 25 Oct 2003 10:06:55 -0400 From: Wilson Sawyer X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipcdn@ietf.org CC: harrie@lisanza.net, bwijnen@lucent.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] Submission of draft 13 of Subscriber Management MIB; responses to Harrie 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: 7bit I've submitted a revised draft of the subscriber management MIB for i-d publication - look for it in the usual places in the next few days. It contains a several changes suggested by Bert and others, but the bulk of the changes were in response to the suggestions from Harrie Hazewinkel (8-Sept). I'm grateful to Harrie for taking the time to provide such a detailed review; point-by-point responses are included below. Respectfully submitted, Wilson Sawyer -----Original Message----- > From: Harrie Hazewinkel [mailto:harrie@lisanza.net] > Sent: maandag 8 september 2003 12:43 > To: Wijnen, Bert (Bert); Wilson.Sawyer@arrisi.com > Cc: Harrie Hazewinkel > Subject: review: draft-ietf-ipcdn-mib.txt > > > HI, > > Hereby my MIB review. While reading I added comments in-line in the > document. > (Sorry, if a big part of the draft is copied, but provides context I > hope.) > > Some general (summary of) comments are: > 1) the formatting of the description clauses could improve readability. I've broken up some of the larger description clauses to try to improve this. > 2) adding a small description in the description clause helps, while > now (sometimes) directly the meaning of the values is given. I've added this for some objects; for others, a statement of what the object *is* seemed to obscure the more rigorous statement of what its values *do*. > 3) the DIFFSERV-MIB (classifier) connections seems odd to me. > I do not beleive it is correct, also since the text speaks of > OIDs and that is no where used (only Integer). > IMHO, the docsSubMgtCmFilterTable could work like the > diffServDataPathTable > and with Rowpointer for is objects and the docsSubMgtFilterGroupTable > becomes redandant or could acts as a pool of filter available (but then > needs RowPointers as weel). This sounds simpler to me and does the job. > Please correct, me if I am wrong or ask if more info is needed. > (Below I have more specifics of this). (Bert made a similar point.) The Description clauses and parts of the text were misleading, and I think I've corrected them. > Hope this helps, > Harrie > > > > Abstract > > > > This memo defines a portion of the Management Information Base (MIB) > > for use with network management protocols in the Internet community. > > In particular, it defines a set of managed objects for SNMP-based > > management of Data-over-Cable Service Interface Specification > > (DOCSIS)-compliant Cable Modem Termination Systems. These managed > > objects facilitate protection of the cable network from misuse by > > subscribers. > > Not sure, but is not a subset of managed objects addressed here? > Maybe it is useful to mention it extends the other MIBs. text added to do so. > > This memo is a product of the IPCDN working group within the > > Internet > > Engineering Task Force. Comments are solicited and should be > > addressed to the working group's mailing list at ipcdn@ietf.org > > and/or the author. > > This goes out of the abstract, I presume?? > It is mostly part of the 'Status of the memo' which > gets changed when it turns into an RFC. moved to "Status". > > 2. Overview > > > > This MIB provides a set of objects required for the management of > > DOCSIS Cable Modem Termination Systems (CMTS). The specification is > > derived in part from the operational model described in the DOCSIS > > Radio Frequency Interface Specification [DOCSRFI]. These managed > > objects facilitate protection of the cable network from misuse by > > subscribers. > > What kind of 'misuse'? Maybe it is useful to define the kinds of > misuse is ment here. text added. > > The following figure illustrates the operational and physical > > deployment relationships between elements in a cable modem network. > > This MIB resides at the CMTS, which is the first point in the public > > data network at which the cable operator controls physical access. > > The CMTS (possibly assisted by other IP services devices) acts as a > > network edge, separating the physical outside-plant cable television > > network from the operator's IP network. > > > > > > | operator's IP network > > +------+ --------------------- > > | CMTS | operator's cable head-end > > +------+ --------------------- > > | > > +--------+--------+ CATV physical network > > | | | > > +----+ +----+ +----+ ------------------ > > | CM | | CM | | CM | subscriber premises > > +----+ +----+ +----+ ------------------ > > | | | subscriber host or network > > > > > > This MIB controls IP packet forwarding to and from each cable modem, > > at the CMTS. Different modems may be accorded different treatment. > > Maybe time to refer to DIFFSERV?? I didn't add mention of Diffserv here, because (as I hope is reasonably clear later in the document) the use of RFC3289 is as a tool to achieve certain filtering objectives - other aspects of the diffserv framework are incidental to this purpose. So I really don't want to dive into a topic like "the CMTS's place in the differv framework". > > Much of this MIB duplicates capabilities found in the DOCSIS Cable > > Device MIB [RFC2669]. > > Why duplication? Is it not possible to use those managed objects? > Otherwise, I beleive it is a good idea to mention why they are > duplicated. oops. Some text that explained this in an earlier draft was omitted when 3289 was adopted as the filtering representation. Text worked back in. > > While it is expected that the Cable Device MIB > > will be used to prevent unwanted traffic from entering the cable > > network, it is also possible that a malicious user might tamper with > > cable modem software, disabling its filtering policies. This MIB > > provides a more secure mechanism, since physical access to the CMTS > > is controlled by the network operator. > > Actually, I do not believe this MIB provides the 'secure mechanism', but > merely the managed objects to manage that 'secure mechanism'. > IMHO, it gives a not fully correct impression. There's always a correctness vs. clarity tradeoff. Adding "managed objects" anywhere in that sentence makes it more difficult to read. Unless you (or others) think that the existing text is actually misleading, I'd rather leave it as is. > > In particular, this MIB provides two capabilities: first, to limit > > the IP addresses behind a modem, and, second, to provide protocol > > filtering to and from a modem. The first duplicates the capabilities > > of the docsDevCpe group [RFC2669]. This provides for either learned > > or provisioned subscriber premises host IP addresses behind a cable > > modem. > > The second?? Which is below the 'filtering', but mention it as such. > It helps the reader. text slightly reworked to provide better linkage. > > The filtering capability makes use of the Classification, Counting, > > and Drop facilities of the Differentiated Services MIB [RFC3289]. In > > order to provide different filtering for various classes of > > subscribers, this MIB defines the docsSubMgtFilterGroupTable which > > specifies which filters are to apply to each subscriber packet. > > This > > table is used by RFC3289 as a first pass of classification, to then > > choose a second pass of classification using the > > Here I am getting confused from the text. > 'This table is used by RFC3289...' makes me believe this extends the > MIB defined in RFC 3289. But my understanding is that you want to use > the 'filtering' of the DIFFSERV-MIB in this MIB, right. > I suggest to rewrite this paragraph to reflect this. Strengthened the first sentence to make this clearer. > > diffServMultiFieldClfrTable: > > > > diffServDataPathStart --> diffServClfrEntry(1) > > diffServClfrElementSpecific(1) --> docsSubMgtFilterGroupIndex > > diffServClfrElementNext(1) --> diffServClfrEntry(2) > > diffServClfrElementSpecific(2)--> diffServMultiFieldClfrEntry > > diffServClfrElementNext(2) --> difServActionEntry (count or algDrop) > > > > > > Rather than maintaining a separate list of filters for each modem at > > the CMTS, it is assumed that large numbers of modems will share > > filtering characteristics. Therefore, DOCSIS signaling defines > > filter > > groups by which cable modems share common filter lists. > > I am not sure, but if I understand it correctly what you want the above > section > needs to be improved. > What I understand (in short) is this MIB does 2 things 1) limit IP > addresses > of a modem and 2) does filtering. The first part is also done by > RFC2669 and > is here duplicated. The second part is filtering as defined in RFC3289 > (where it > is DIFFSERV focussed). not sure whether the miscellaneous text changes have addressed this point or not. > > 2.1. Structure of the MIB > > > > This MIB is structured in four tables: > > > > o The docsSubMgtCpeControlTable controls the acceptance of > > subscriber host addresses behind a cable modem. > > > > o The docsSubMgtCpeIpTable monitors the subscriber host addresses > > which the CMTS believes to exist behind the cable modem. > > > > o The docsSubMgtCmFilterTable binds a cable modem to a set of > > filters in diffServMultiFieldClfrTable. > > > > o The docsSubMgtFilterGroupTable provides the OIDs by which > > the diffServClfrElementTable selects a filter group. > > > > The docsSubMgtCpeControlTable and docsSubMgtCmFilterTable AUGMENT > > the > > docsIfCmtsCmStatusTable from [RFC2670]. Similarly, > > docsSubMgtCpeIpTable expands this table (an additional index is > > used). As such, each entry in these tables is bound to a registered > > cable modem, as perceived by the CMTS. > > I would break to above in a section for each of the tables above. > It took me sometime to realize that the above paragraph covers the > first three tables. Or just extend the 'points' since it is > not that much text anyway. The above paragraph is needed to provide the linkage and overarching structure between these tables (back to docsSubMgtCpeIpTable), rather than describing attributes of each table. > > 2.1.1. docsSubMgtFilterGroupTable > > > > The docsSubMgtFilterGroupTable is unusual in that it might be viewed > > not so much as an array of single-object entries as an array of > > OBJECT-IDENTIFIER conventions. Each instance of > > docsSubMgtFilterGroupIndex serves as an OID reference for > > diffServClfrElementSpecific. The index value corresponds to the > > filter group identifier signaled by the cable modem [DOCSRFI]. An > > entry exists in this Table if a reference to it exists in > > diffServClfrElementSpecific. > > When looking in the MIB I do not see the OID reference. > See also there. reworked. Bert made a similar point. > > As such, contrary to common practice, the index for the table is > > read-only, and is both the Entry's index and its only value. > > Not needed here. Only later in the OBJECT-TYPE. I do not > know the access here at all. Maybe, but I think it helps to emphasize that this object is inferred from its reference in diffServClfrElementSpecific, rather than being the configuration knob. > > 2.2. Management requirements > > > > The DOCSIS cable modem provisioning model [DOCSRFI] requires that > > cable modems use TFTP to acquire a list of parameters. The modem > > then > > passes many of these parameters to the CMTS in the DOCSIS > > Registration message. The parameter values are digitally signed by > > the creator of the TFTP contents, and the signature is verified by > > the CMTS. In general, then, the CMTS need not itself be configured > > with the attributes of its cable modems. It will acquire these > > values > > through the Registration process that is secured by the digital > > signature. > > > > Cable modem subscriber management, as described here, modifies this > > process slightly for reasons of data reduction and ease of > > administrative control. In the case of filtering management, for > > What is ment by 'filtering management'? > Is it 'management of the filtering mechanism' or filtering the > management > traffic'? > > > example, the tables are maintained through SNMP at the CMTS, and the > > modem registration merely signals the index values for the rows that > > apply to that modem. > > > > 2.2.1. Interaction with DOCSIS provisioning for CPE address control > > > > Rows in docsSubMgtCpeControlTable are created by the CMTS for each > > modem as a result of the DOCSIS registration process. The DOCSIS > > registration attributes may include items semantically equivalent to > > those in the DocsDevCpe branch of the DOCSIS Cable Device MIB > > [RFC2669]: > > > > o docsDevCpeEnroll > > o docsDevCpeIpMax > > o docsDevCpeIp > > > > Successful DOCSIS registration shall have the effect of setting the > > corresponding fields in the docsSubMgtCpeControlTable and the > > docsSubMgtCpeIpTable. If not present, the default at registration > > shall be to set docsSubMgtCpeControlActive to false. > > I believe something in this sentence is wrong/missing. > 'default' -> 'default behavior' (both wrong and missing). Fixed. > > Rows in docsSubMgtCpeIpTable are created through any of three ways: > > DOCSIS registration (as described above), learning by the CMTS, or > > through some unspecified administrative mechanism on the CMTS. > > Maybe adding below numbers? Like,.. > 1) DOCSIS registration (as described above), 2) learning by the CMTS, > 3) or through some unspecified administrative mechanism on the CMTS. in this cases, I think that numbers would impede readability. > > The > > docsDevCpeIpMax table bound applies only to the first two. > > > > The CMTS may learn addresses by simply snooping source IP addresses > > from each cable modem. Other learning mechanisms (for example, ARP > > Suggestion, > 'from each cable modem' -> 'from traffic originating from each cable > modem' added. > > snooping) may be used. The learning mechanism is not defined by this > > document. > > > > 2.2.2. Interaction with DOCSIS provisioning for filtering > > > > Rows in docsSubMgtCmFilterTable are created by the CMTS for each > > modem as a result of the DOCSIS registration process. The DOCSIS > > registration attributes may include four indices (see section > > C.1.1.18.3 of [DOCSRFI]): > > > > o one identifying the upstream filter group for packets > > originating from the cable modem (i.e., those packets whose > > source MAC address matches that of the cable modem). > > o one identifying the upstream filter group for packets > > originating from subscribers attached to the cable modem (i.e., > > those packets whose source MAC address does not match that of > > the cable modem). > > o one identifying the downstream filter group for packets > > destined to the cable modem (i.e., those packets whose > > destination MAC address matches that of the cable modem). > > o one identifying the downstream filter group for packets > > destined to subscribers attached to the cable modem (i.e., > > those packets whose destination MAC address does not match > > that of the cable modem). > > > > Successful registration shall have the effect of setting > > docsSubMgtCmFilterDownstream, docsSubMgtCmFilterUpstream, > > docsSubMgtSubFilterDownstream, and docsSubMgtSubFilterUpstream, for > > that modem (just as if set through the SNMP protocol). If the DOCSIS > > attributes are not present, the effect shall be to use the default > > entry (diffServClfrElementSpecific=zeroDotZero) specified in the > > diffServClfrElementTable. > > (diffServClfrElementSpecific=zeroDotZero) is not a default entry. > zeroDotZero is a default value for the diffServClfrElementSpecific > when no filtering is done or known. > I also believe that is no filtering is done the values of > docsSubMgtCmFilterDownstream, docsSubMgtCmFilterUpstream, > docsSubMgtSubFilterDownstream, and docsSubMgtSubFilterUpstream can be > zero. > There is no need for a reference into DIFFSERV-MIB filters/classifiers > then. > > Not sure if I am correct here, if so the text needs some changes I > guess. The intent is to specify a default filtering behavior when unsignalled, not no-filtering. some clarification added to the text. > > 2.2.3. Distinguishing Modem from Subscriber Traffic > > > > All traffic originating from or destined to a subscriber site is > > potentially suspect, and subject to suppression by the network > > operator. This is true even if the traffic is ostensibly sourced or > > sunk by the cable modem itself, rather than the subscriber hosts > > behind the modem. To provide more nuanced administrative control, > > this document allows separate filter policies for modems and hosts. > > For example, modem policies may limit modems to server-subnet-only > > access, while allowing a different scope to subscribers. > > > > The CMTS chooses the filter set to apply based solely on the MAC > > address (source MAC upstream, destination MAC downstream). If the > > MAC > > address matches that of the modem, then the > > docsSubMgtCmFilterUp/Downstream pair is used; otherwise the > > docsSubMgtSubFilterUp/Downstream pair is applied. > > > > If the CM acts as a router rather than as a DOCSIS bridging > > forwarder, then the network operator will only use the > > docsSubMgtCmFilterUp/Downstream pair. > > > > 2.3. Relationship to the Differentiated Services MIB [RFC3289] > > > > DOCSIS CMTSs rely on the classification, counting, and drop > > facilities of the Differentiated Services MIB to screen subscriber > > packets for IP, TCP, and UDP characteristics. It is expected that > > any > > implementation of this MIB also include at least the following from > > RFC 3289: > > > > o diffServDataPathTable > > I am not sure why this table is needed. Be aware that this table has > ifDerection, but the direction as such is not equal as used here. > Here we have 'upstream/downstream'. As a result or we need to specify > a mapping here, or we can directly use the 'diffServDataPathStart' > mechanism to add in the MIB here defined the RowPointer that points > to an diffSrvrClfrEntry. Added definitions of upstream and downstream, to make it clear that they correspond to ingress and egress w.r.t. the DOCSIS interface. > > o diffServClfrTable > > o diffServClfrElementTable > > o diffServMultiFieldClfrTable > > o diffServActionTable > > o diffServCountActTable > > o diffServAlgDropTable (diffServAlgDropType=alwaysDrop) > > > > The corresponding "next-free" objects are also required. > > > > The use of other facilities from RFC 3289 is not precluded, but is > > beyond the scope of this specification. > > > > 2.3.1. Using the Filter Group to Extend Packet Classification > > > > The base capability of RFC 3289 assumes that all packets on the same > > direction of the same interface will be classified by the same > > criteria. Filter Groups, introduced in this document, expand on RFC > > 3289 to allow various subscribers to receive different > > classification > > (filtering) treatment. One way to view filter groups is as sub- > > interfaces within the physical DOCSIS channel. Another way to view > > them is as values of a field logically prepended to the packet prior > > to classification: > > > > [filter group][docsis MAC header][IP header]... > > > > Of course this 'logical' field has no existence outside of the CMTS. > > > > The diffServClfrTable and diffServClfrElementTable are then used > > twice: the first classifiers select among filter groups, using OIDs > > from docsSubMgtFilterGroupTable. The 'next' action on matching a > > filter group is to select a diffServClfrEntry which now classifies > > on > > IP/TCP/UDP criteria (the diffServMultiFieldClfrTable_. The 'next' > > action on this second match may be a 'count' (and accept), a 'drop', > > or some other feature from RFC 3289. > > IMHO, the approach described here as filtering needs to be move to > the introduction where one speaks of 'filtering'. There is no > need to specify the managed objects then, but just the approach, > which is [filter group][docsis MAC header][IP header]... > It will clarify way more (as a non DOCSIS expert) and guides the > reader towards what is accomplished. I couldn't figure out a good place to move it up to. This example is just meant to be illustrative in any case - there are a number of other ways to visualize the classification process. > > 2.3.2. Interface Usage > > > > For purposes of DOCSIS subscriber management, only the DOCSIS MAC > > cable interface(s) are used. The interface appears as the index to > > diffServDataPathEntry, which is the starting point for diffserv MIB > > table traversal. > > Somehow one can figure it out, but since there is a mismatch by the > words/terms used the mapping 'egress/ingress' to 'down/upstream' > needs to be defined. > > > The use of the diffserv MIB for other purposes, both on the DOCSIS > > MAC interfaces and on other network interfaces, is not precluded by > > this document. > > > > 2.4. Filtering and the Tiny Fragment Attack > > [snip] > Is this section not for the security consideration?? maybe, but since the topic of this mib is public network protection from subscribers, and since that includes TCP header filtering, I thought it better to give it more prominence than it would receive in the Security section. > > 3. Definitions > > > > DOCS-IETF-SUBMGT-MIB DEFINITIONS ::= BEGIN > > In this MIB module I would format the DESCRIPTIONs a bit better, by > adding emtpy lines between pieces of text. Now it is sometimes a bit > difficult to read. > > Also sometimes object directly define what each value means, but not > a small generic description of the object itself. For instance, > docsSubMgtCpeControlActive is a good example of this. > > > IMPORTS > > InetAddressType, > > InetAddress > > FROM INET-ADDRESS-MIB > > Needs a normative reference of the RFC 2851 of the imported MIB. fixed. > > DESCRIPTION > > "This is the CMTS centric subscriber management MIB for > > DOCSIS compliant CMTS. > > Maybe extend it a bit more. added some text. > > docsSubMgtCpeControlTable OBJECT-TYPE > > SYNTAX SEQUENCE OF DocsSubMgtCpeControlEntry > > MAX-ACCESS not-accessible > > > > STATUS current > > DESCRIPTION > > "This table AUGMENTs the docsIfCmtsCmStatusTable and adds > > The 'and' makes it look like it is doing two things, but it is infact > doing > 1 thing, 'AUGMENTING a table with 4 objects' fixed > > four WRITEable objects which reflect the state of subscriber > > management on a particular CM." > > ::= { docsSubMgtObjects 1 } > > > > docsSubMgtCpeControlEntry OBJECT-TYPE > > SYNTAX DocsSubMgtCpeControlEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "A row in the docsSubMgtCpeControlTable. All values are set > > at successful modem registration, either from the system > > default, > > or from objects included in the DOCSIS registration request sent > > upstream to the CMTS from the CM. The contents of this entry are > > meaningless unless the corresponding docsIfCmtsCmStatusValue is > > registrationComplete(6). The persistence of this row is > > determined solely by the lifespan of the corresponding > > docsIfCmtsCmStatusEntry (normally StorageType=volatile)." > > AUGMENTS { docsIfCmtsCmStatusEntry } > > Since 'docsIfCmtsCmStatusValue' is not imported a REFERENCE would > be usefull in order to find that object. added. > > ::= {docsSubMgtCpeControlTable 1 } > > > docsSubMgtCpeControlMaxCpeIp OBJECT-TYPE > > SYNTAX Integer32(0..2147483647) > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "The number of simultaneous IP addresses permitted behind > > the CM. If this is set to zero, all CPE traffic from the CM is > > dropped. If the provisioning object corresponding to > > docsSubMgtCpeIpTable includes more CPE IP address entries for > > this modem than the value of this object, then this object is > > set to the count of the number of rows in docsSubMgtCpeIpTable > > that have the same docsIfCmtsCmStatusIndex value. > > The above sentence is hardly to understand and I believe it > just want to express that "the value equals the amount of rows > in docsSubMgtCpeIpTable that have the same docsIfCmtsCmStatusIndex > value" written by my predecessor after rancorous debate. While it may be awkward, I'm reluctant to touch it. > > (E.g. if the > > CM has 5 IP addresses specified for it, this value is 5). This > > limit applies to learned and docsis-provisioned entries, but > > does not limit entries added through some administrative > > process at the CMTS. If not set through DOCSIS provisioning, > > this object defaults to docsSubMgtCpeMaxIpDefault. Note that > > this object is only meaningful if docsSubMgtCpeControlActive > > is true." > > Is a DEF-VAL not useful. I am only not sure how this can be done. > DEF-VAL does not allow a reference to a value. :-(( > > > ::= { docsSubMgtCpeControlEntry 1 } > > > docsSubMgtCpeControlLearnable OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "If this is set to true, the CMTS may learn up to > > docsSubMgtMaxCpeIp addresses (less any DOCSIS-provisioned > > entries) related to this CM. Those IP addresses are added (by > > internal process) to the docsSubMgtCpeIpTable. The nature of the > > learning mechanism is not specified here. > > IMHO, '(by internal process)' is also part of the 'The nature ...' > As a result it is redundant and maybe deleted. this was meant to emphasize that the learning mechanism (ARP gleaning, source gleaning, ... ) is not specified. > > If not set through > > DOCSIS provisioning, this object defaults to > > docsSubMgtCpeLearnableDefault. Note that this object is only > > meaningful if docsSubMgtCpeControlActive is true." > > ::= { docsSubMgtCpeControlEntry 3 } > > > > docsSubMgtCpeControlReset OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "This object always returns false on read. If this object > > is > > set to true, the rows with 'learned' addresses in > > docsSubMgtCpeIpTable for this CM are deleted from that table." > > Does this count for all addreses 'learned' or only those addresse > 'learned' > to which this augmented entry applies. > Maybe usefull to specify. ? There's no distinction. There is only one augmented entry per cable modem. > > ::= { docsSubMgtCpeControlEntry 4 } > > > > docsSubMgtCpeControlLastReset OBJECT-TYPE > > SYNTAX TimeStamp > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value of sysUpTime when docsSubMgtCpeControlReset was > > last set true. Zero if never reset." > > DEF-VAL { 0 } added. > > ::= { docsSubMgtCpeControlEntry 5 } > > > > docsSubMgtCpeMaxIpDefault OBJECT-TYPE > > SYNTAX Integer32(0..2147483647) > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "The default value for docsSubMgtCpeControlMaxCpeIp if not > > signaled in the DOCSIS Registration request. Upon initial CMTS > > initialization, this defaults to 16." > > Use "DEF-VAL { 16 }" to indicate the 'this defaults to 16' the text is > redundant then. fixed. > > ::= { docsSubMgtObjects 2 } > > > > docsSubMgtCpeActiveDefault OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "The default value for docsSubMgtCpeControlActive if not > > signaled in the DOCSIS Registration request. Upon initial CMTS > > initialization, this defaults to false." > > DEF-VAL { false } fixed. > > ::= { docsSubMgtObjects 3 } > > > > docsSubMgtCpeLearnableDefault OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "The default value for docsSubMgtCpeControlLearnable if not > > signaled in the DOCSIS Registration request. Upon initial CMTS > > initialization, this defaults to true." > > DEF-VAL { true } fixed > > ::= { docsSubMgtObjects 4 } > > > > docsSubMgtCpeIpTable OBJECT-TYPE > > SYNTAX SEQUENCE OF DocsSubMgtCpeIpEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "A table of CPE IP addresses known on a per CM basis." > > ::= { docsSubMgtObjects 5 } > > > > docsSubMgtCmFilterTable OBJECT-TYPE > > SYNTAX SEQUENCE OF DocsSubMgtCmFilterEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "Binds filter groups to modems. This table identifies for > > each modem the upstream and downstream filter groups that apply > > to packets for that modem. Zero is used as a distinguished value > > to mean no filter group." > > 'Zero ....group.' makes no sense to me here. fixed. > > ::= { docsSubMgtObjects 6 } > > > > docsSubMgtCmFilterEntry OBJECT-TYPE > > SYNTAX DocsSubMgtCmFilterEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "Binds a filter group to each direction of traffic for a > > modem. The filters in this entry apply if > > docsSubMgtCpeControlActive is true. The contents of this entry > > are meaningless unless the corresponding > > Since 'docsIfCmtsCmStatusValue' is not imported a REFERENCE would > be usefull in order to find that object. added. > > is registrationComplete(6). The persistence of this row is > > determined solely by the lifespan of the corresponding > > docsIfCmtsCmStatusEntry (normally StorageType=volatile)." > > AUGMENTS { docsIfCmtsCmStatusEntry } > > ::= {docsSubMgtCmFilterTable 1 } > > > > > > docsSubMgtSubFilterDownstream OBJECT-TYPE > > SYNTAX Integer32(0..2147483647) > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "The filter group applied to traffic destined for > > subscribers > > attached to the referenced CM. This is set upon row creation to > > either zero (use default classification), or to the value in the > > What is considered default classification? (Also for > docsSubMgtSubFilterUpstream, > docsSubMgtCmFilterDownstream, docsSubMgtCmFilterUpstream) added clarifying text. > > docsSubMgtFilterGroupTable OBJECT-TYPE > > SYNTAX SEQUENCE OF DocsSubMgtFilterGroupEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "Provides a collection of OIDs to which > > diffServClfrElementSpecific refers. This table provides filter > > group indices which can be compared with those signaled during > > Docsis registration. A packet matches an entry from this table > > if the packet originated from or is destined to a cable modem > > which registered this index as one of its four filter groups > > (see docsSubMgtCmFilterTable) and if the packet direction and > > MAC address select the use of this index among the four." > > I am not seeing the use of this table and seems to me connected in > a strange way to the diffServClfrElementEntry. It speaks of a > collection of > OIDs, but the table has only Integer. This is confusing. the descriptions of this (and the subsequent 2 OBJECT-TYPES) was changed. > Not sure, yet what the best way is in order to change this table. > (I am thinking about it, but any extra explaination of the > auther could enlighten it for me). > > Some option, I am thinking of deleting this table, use the > diffServClfrTable > directly and change the docsSubMgtSubFilterDownstream, > docsSubMgtSubFilterUpstream, > docsSubMgtCmFilterDownstream, docsSubMgtCmFilterUpstream into > RowPointers. > That table would then function like the diffServDataPathTable. > > > docsSubMgtFilterGroupIndex OBJECT-TYPE > > SYNTAX Integer32(0..2147483647) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "Provides an OID to which diffServClfrElementSpecific > > Why using the SYNTAX-TYPE Interger32? I would believe this must be an > RowPointer. > > > refers. A packet matches this entry if the packet's cable modem > > registered this index value as one of its four filter groups > > and if the packet direction and MAC address select the use of > > this index among the four. > > Not sure, but is here a pointer to the 'diffServClfrElementSpecific' > what is needed followed > > > Because this is the only field in > > this table, it is read-only, contrary to the usual SNMP custom > > of making indices not-accessible." > > Cool, this is usefull. Many would ask 'Why?'. > > > ::= { docsSubMgtFilterGroupEntry 1 } > > > > > > docsSubMgtBasicCompliance MODULE-COMPLIANCE > > Would be the creation of a 'FullCompliance' and 'ReadOnlyCompliance' > make sense? I don't think so. In general, CMTSs must pass a qualification test conducted by CableLabs which enforces minimum requirements. Those requirements have always mandated full configuration access through SNMP. I don't think a read-only compliance serves a useful purpose. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Oct 27 11:23:24 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 LAA23342 for ; Mon, 27 Oct 2003 11:23:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEA93-00043G-Qt for ipcdn-archive@odin.ietf.org; Mon, 27 Oct 2003 11:23:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RGN5Nw015552 for ipcdn-archive@odin.ietf.org; Mon, 27 Oct 2003 11:23:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEA8z-000425-6e; Mon, 27 Oct 2003 11:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEA83-0003ys-L5 for ipcdn@optimus.ietf.org; Mon, 27 Oct 2003 11:22:03 -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 LAA23272 for ; Mon, 27 Oct 2003 11:21:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEA82-0007bZ-00 for ipcdn@ietf.org; Mon, 27 Oct 2003 11:22:02 -0500 Received: from coral.tci.com ([198.178.8.81] helo=peacock.tci.com) by ietf-mx with esmtp (Exim 4.12) id 1AEA81-0007a7-00 for ipcdn@ietf.org; Mon, 27 Oct 2003 11:22:01 -0500 Received: from entexchimc04.broadband.att.com (entexchimc04.broadband.att.com [147.191.90.11]) by peacock.tci.com (8.12.9/8.12.9) with ESMTP id h9RGLUTa006147 for ; Mon, 27 Oct 2003 09:21:30 -0700 (MST) Received: by entexchimc04.broadband.att.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Oct 2003 09:21:29 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC0B652044@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "IPCDN WG (E-mail)" Date: Mon, 27 Oct 2003 09:21:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] Recent updates to the IPCDN website (October 27) 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, I made the following updates to the IPCDN website, www.ipcdn.org. First, I updated the list of internet-drafts, due to the many new drafts recently submitted (BPI+ MIB, Cable Device MIB, DOCSIS 2.0 RF MIB, DOCSIS QoS MIB, Subscriber Management MIB, PacketCable/IPCablecom Management Event MIB, MTA MIB, and NCS Signaling MIB): Note: the DOCSIS 2.0 RF MIB was submitted just after the IETF internet-drafts submission deadline, so it will be longer until it is updated on the IETF website than the other drafts. Second, I updated the IPCDN Hints page for additional MIB guidelines (MIB review tools, textual conventions, SMIv2 errata), and to clean up the document templates (Word, NROFF, and XML): Third, I updated the list of meetings to include the Minneapolis meeting date (November 11): -- Richard Woundy, IPCDN Co-Chair _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Oct 27 16:53:22 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 QAA16312 for ; Mon, 27 Oct 2003 16:53: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 1AEFIO-0005Zf-9V for ipcdn-archive@odin.ietf.org; Mon, 27 Oct 2003 16:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RLr4Ws021398 for ipcdn-archive@odin.ietf.org; Mon, 27 Oct 2003 16:53:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFIK-0005YY-HB; Mon, 27 Oct 2003 16:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFI7-0005XA-1n for ipcdn@optimus.ietf.org; Mon, 27 Oct 2003 16:52:47 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16136; Mon, 27 Oct 2003 16:52:33 -0500 (EST) Message-Id: <200310272152.QAA16136@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 16:52:33 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-qos-mib-09.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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QOS MIB) Author(s) : M. Patrick, W. Murwin Filename : draft-ietf-ipcdn-qos-mib-09.txt Pages : 85 Date : 2003-10-27 This document defines a basic set of managed objects for SNMP-based management of extended QOS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) standard version 1.1 and 2.0. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-09.txt 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. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-qos-mib-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-qos-mib-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27171255.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-qos-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-qos-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171255.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Oct 27 17:11:22 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 RAA19631 for ; Mon, 27 Oct 2003 17:11: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 1AEFZo-0007hz-Bq for ipcdn-archive@odin.ietf.org; Mon, 27 Oct 2003 17:11:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RMB4DY029622 for ipcdn-archive@odin.ietf.org; Mon, 27 Oct 2003 17:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFZm-0007h3-Je; Mon, 27 Oct 2003 17:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFZ1-0007X2-DY for ipcdn@optimus.ietf.org; Mon, 27 Oct 2003 17:10:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19181; Mon, 27 Oct 2003 17:10:02 -0500 (EST) Message-Id: <200310272210.RAA19181@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 17:10:02 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-13.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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management Author(s) : W. Sawyer Filename : draft-ietf-ipcdn-subscriber-mib-13.txt Pages : 24 Date : 2003-10-27 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the author. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-13.txt 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. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-subscriber-mib-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-subscriber-mib-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27171307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-subscriber-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-subscriber-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171307.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Oct 27 17:42:25 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 QAA16311 for ; Mon, 27 Oct 2003 16:53: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 1AEFIO-0005Ze-99 for ipcdn-archive@odin.ietf.org; Mon, 27 Oct 2003 16:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RLr4W0021401 for ipcdn-archive@odin.ietf.org; Mon, 27 Oct 2003 16:53:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFIK-0005Yg-PN; Mon, 27 Oct 2003 16:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFIE-0005XN-4Y for ipcdn@optimus.ietf.org; Mon, 27 Oct 2003 16:52:54 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16177; Mon, 27 Oct 2003 16:52:40 -0500 (EST) Message-Id: <200310272152.QAA16177@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 16:52:40 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-13.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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management Author(s) : W. Sawyer Filename : draft-ietf-ipcdn-subscriber-mib-13.txt Pages : 24 Date : 2003-10-27 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the author. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-13.txt 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. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-subscriber-mib-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-subscriber-mib-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27171307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-subscriber-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-subscriber-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171307.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Oct 27 17:42:25 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 QAA16313 for ; Mon, 27 Oct 2003 16:53: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 1AEFIO-0005Zg-9t for ipcdn-archive@odin.ietf.org; Mon, 27 Oct 2003 16:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RLr4PC021400 for ipcdn-archive@odin.ietf.org; Mon, 27 Oct 2003 16:53:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFIK-0005YI-8t; Mon, 27 Oct 2003 16:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFI0-0005X2-8f for ipcdn@optimus.ietf.org; Mon, 27 Oct 2003 16:52:40 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16113; Mon, 27 Oct 2003 16:52:27 -0500 (EST) Message-Id: <200310272152.QAA16113@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 16:52:27 -0500 Subject: [ipcdn] I-D ACTION: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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems Author(s) : R. Woundy Filename : draft-ietf-ipcdn-device-mibv2-06.txt Pages : 79 Date : 2003-10-27 This memo is a draft revision of the standards track RFC-2669. Please see 'Revision Descriptions' below for a description of changes. This document will obsolete RFC-2669 when accepted. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS compliant Cable Modems and Cable Modem Termination Systems. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the author. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-06.txt 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. 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". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27171243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-device-mibv2-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171243.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Oct 27 17:59:16 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 RAA19629 for ; Mon, 27 Oct 2003 17:11: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 1AEFZo-0007i0-Cb for ipcdn-archive@odin.ietf.org; Mon, 27 Oct 2003 17:11:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RMB4gG029618 for ipcdn-archive@odin.ietf.org; Mon, 27 Oct 2003 17:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFZm-0007gv-8X; Mon, 27 Oct 2003 17:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFYy-0007We-Gg for ipcdn@optimus.ietf.org; Mon, 27 Oct 2003 17:10:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19170; Mon, 27 Oct 2003 17:09:59 -0500 (EST) Message-Id: <200310272209.RAA19170@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 17:09:59 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-qos-mib-09.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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QOS MIB) Author(s) : M. Patrick, W. Murwin Filename : draft-ietf-ipcdn-qos-mib-09.txt Pages : 85 Date : 2003-10-27 This document defines a basic set of managed objects for SNMP-based management of extended QOS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) standard version 1.1 and 2.0. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-09.txt 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. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-qos-mib-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-qos-mib-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27171255.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-qos-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-qos-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171255.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Oct 27 17:59:16 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 RAA19630 for ; Mon, 27 Oct 2003 17:11: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 1AEFZo-0007hu-9I for ipcdn-archive@odin.ietf.org; Mon, 27 Oct 2003 17:11:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RMB4sf029620 for ipcdn-archive@odin.ietf.org; Mon, 27 Oct 2003 17:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFZl-0007gm-TI; Mon, 27 Oct 2003 17:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFYu-0007WW-0U for ipcdn@optimus.ietf.org; Mon, 27 Oct 2003 17:10:08 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19159; Mon, 27 Oct 2003 17:09:55 -0500 (EST) Message-Id: <200310272209.RAA19159@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 17:09:54 -0500 Subject: [ipcdn] I-D ACTION: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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems Author(s) : R. Woundy Filename : draft-ietf-ipcdn-device-mibv2-06.txt Pages : 79 Date : 2003-10-27 This memo is a draft revision of the standards track RFC-2669. Please see 'Revision Descriptions' below for a description of changes. This document will obsolete RFC-2669 when accepted. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS compliant Cable Modems and Cable Modem Termination Systems. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the author. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-06.txt 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. 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". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27171243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-device-mibv2-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171243.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Oct 30 16:36:26 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 QAA14441 for ; Thu, 30 Oct 2003 16:36: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 1AFKSc-0005KF-KW for ipcdn-archive@odin.ietf.org; Thu, 30 Oct 2003 16:36:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ULa6FI020471 for ipcdn-archive@odin.ietf.org; Thu, 30 Oct 2003 16:36:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFKSY-0005J8-17; Thu, 30 Oct 2003 16:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFKSM-0005Hy-DL for ipcdn@optimus.ietf.org; Thu, 30 Oct 2003 16:35: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 QAA14180 for ; Thu, 30 Oct 2003 16:35:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFKSK-0002rd-00 for ipcdn@ietf.org; Thu, 30 Oct 2003 16:35:48 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AFKSJ-0002rY-00 for ipcdn@ietf.org; Thu, 30 Oct 2003 16:35:47 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by manatick with esmtp (Exim 4.24) id 1AFKSJ-0001LP-KX for ipcdn@ietf.org; Thu, 30 Oct 2003 16:35: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 h9ULZf10013165; Thu, 30 Oct 2003 14:35:42 -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 Date: Thu, 30 Oct 2003 14:35:41 -0700 Message-ID: Thread-Topic: Size of docsDevSwFilename in draft-ietf-ipcdn-device-mibv2-06.txt Thread-Index: AcOdJvKYuHE/G81hRC60LrpeKfcbiACBhzLw From: "Jean-Francois Mule" To: "Woundy, Richard" Cc: X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Size of docsDevSwFilename in 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: , Content-Transfer-Encoding: quoted-printable Rich, 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. 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 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. 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. If unknown, the value of this object is the empty string." ::=3D { docsDevSoftware 2 } Comments appreciated. Jean-Fran=E7ois=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 >=20 >=20 > 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. >=20 > 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. >=20 > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mi bv2-06.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. 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". 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 Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-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. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Oct 31 13:02: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 NAA10839 for ; Fri, 31 Oct 2003 13:02: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 1AFdb0-0005BP-Nd for ipcdn-archive@odin.ietf.org; Fri, 31 Oct 2003 13:02:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VI22r7019917 for ipcdn-archive@odin.ietf.org; Fri, 31 Oct 2003 13:02:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFdaz-0005Aq-RJ; Fri, 31 Oct 2003 13:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFdaQ-00058T-9n for ipcdn@optimus.ietf.org; Fri, 31 Oct 2003 13:01:26 -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 NAA10790 for ; Fri, 31 Oct 2003 13:01:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFdaO-0004Jx-00 for ipcdn@ietf.org; Fri, 31 Oct 2003 13:01:24 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 1AFdaN-0004JR-00 for ipcdn@ietf.org; Fri, 31 Oct 2003 13:01:23 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9VI0lxI014024; Fri, 31 Oct 2003 10:00:47 -0800 (PST) Received: from cisco.com (dhcp-171-71-186-184.cisco.com [171.71.186.184]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANS99382; Fri, 31 Oct 2003 10:00:46 -0800 (PST) Message-ID: <3FA2A34E.2010404@cisco.com> Date: Fri, 31 Oct 2003 10:00:46 -0800 From: Azlina Ahmad Reply-To: azlina@cisco.com Organization: CIsco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jean-Francois Mule CC: "Woundy, Richard" , ipcdn@ietf.org Subject: Re: [ipcdn] Size of docsDevSwFilename in draft-ietf-ipcdn-device-mibv2-06.txt References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sj-core-1.cisco.com id h9VI0lxI014024 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 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 fo= r 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 implementatio= n to 64 for those devices so that there is no requirement change for DOCS= IS >=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=20 > ietf-announce-request with the word unsubscribe in the body of the mess= age. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the use= rname "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.o= rg/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 implem= entation to automatically retrieve the ASCII version of the Internet-Draf= t. >=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 Fri Oct 31 19:17:20 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 TAA26343 for ; Fri, 31 Oct 2003 19:17: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 1AFjRv-0008NJ-6d for ipcdn-archive@odin.ietf.org; Fri, 31 Oct 2003 19:17:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA10H3PE032194 for ipcdn-archive@odin.ietf.org; Fri, 31 Oct 2003 19:17:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFjRt-0008N6-Ev; Fri, 31 Oct 2003 19:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFjRX-0008Lc-ER for ipcdn@optimus.ietf.org; Fri, 31 Oct 2003 19:16: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 TAA26312 for ; Fri, 31 Oct 2003 19:16:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFjRV-0001lq-00 for ipcdn@ietf.org; Fri, 31 Oct 2003 19:16:37 -0500 Received: from [202.97.224.98] (helo=mail.hl.cn) by ietf-mx with smtp (Exim 4.12) id 1AFjRU-0001ll-00 for ipcdn@ietf.org; Fri, 31 Oct 2003 19:16:37 -0500 Received: from mail.hl.cn([127.0.0.1]) by mail.hl.cn(AIMC 2.9.5.6) with SMTP id jm43fa35653; Sat, 01 Nov 2003 08:05:15 +0800 Received: from asgard.ietf.org([132.151.6.40]) by mail.hl.cn(AIMC 2.9.5.6) with SMTP id jma53f9e31de; Tue, 28 Oct 2003 14:05:00 +0800 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AEHRf-0005Ls-0e for ietf-announce-list@asgard.ietf.org; Mon, 27 Oct 2003 19:10:47 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AEFID-00015W-4O for all-ietf@asgard.ietf.org; Mon, 27 Oct 2003 16:52:53 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16177; Mon, 27 Oct 2003 16:52:40 -0500 (EST) Message-Id: <200310272152.QAA16177@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 16:52:40 -0500 Precedence: bulk X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-ietf-announce@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-13.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management Author(s) : W. Sawyer Filename : draft-ietf-ipcdn-subscriber-mib-13.txt Pages : 24 Date : 2003-10-27 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the author. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-13.txt 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. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-subscriber-mib-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-subscriber-mib-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27171307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-subscriber-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-subscriber-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171307.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn