From ipcdn-bounces@ietf.org Mon Oct 03 17:35:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMXyH-0002L8-Gs; Mon, 03 Oct 2005 17:35:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMXyC-0002J7-8a for ipcdn@megatron.ietf.org; Mon, 03 Oct 2005 17:35:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16881 for ; Mon, 3 Oct 2005 17:35:33 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMY6j-0001F1-VA for ipcdn@ietf.org; Mon, 03 Oct 2005 17:44:26 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j93LZEBJ016059; Mon, 3 Oct 2005 15:35: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: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Date: Mon, 3 Oct 2005 15:35:14 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F010FAE52@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKAACga3IAAAh6FUAACaROgB9+1Q8A= From: "Eduardo Cardona" To: "Ipcdn (E-mail)" , "Wijnen, Bert (Bert)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Hi IPCDN participants, Here is an update on one of the pending items from Bert's review: After consultations with DOCSIS vendors, I am proposing the clarifications required to define the size constraints for docsIfCmtsCmStatusEqualizationData and docsIfSigQEqualizationData Please review the details and send your comments. You will find in this email a summary of the proposed changes as well as a log of comments provided by vendors to place the discussion in the context of the IPCDN participants.=20 Please comment on the proposals and make the appropriate comments=20 Item a) Item c) Item d) Comments and pick an alternative from b-1)=20 and=20 b-2) ---- =20 CM/CMTS Equalizer Data:=20 Summary: docsIfSigQEqualizationData and docsIfCmtsCmStatusEqualizationData have OCTET STRING with no constraints in the object size (RFC 2669), in fact the format of the pre-equalizers was never normalized and left vendor specific In draft 06 of RFIv2.0 It was added a size constraint of 512 octets but no special reason was defined: Some basic Math will indicate that up to 64 taps ( RFI requirements) and 4 bytes per tap will indicate 256 bytes, still uncertain why 512 was selected. Even though the selection of 256 (or 512) does not seem to be accurate number considering some possible byte controls to indicate: - Taps could be T, T/2 or T/4 spaced.=20 - Forward Taps and Reverse Taps could have different numbers - Not required by the spec : Reverse Taps (DS equalizers) could be also T, T/2 and T/4 spaced - Any need to indicate main tap position ( or the highest value is enough indication of that=20 The discussions held with RF experts identified the following management requirements :=20 =20 1) CM DS post-equalization have been defined in docsIfSigQEqualizationData=20 2) CM Upstream pre-equalizer ( not to be defined in this version of the MIB) something to reflect the CMTS RNG-RSP equalizer value=20 CMTS equalization Data: 3) Equalization in the Upstream has relative importance for CMTS CM path, docsIfCmtsCmStatusEqualizationData Meanings: When Pre-eq is off, the value will indicate the CM-CMTS path RF distortions.=20 When re-eq is on, the value indicates how well pre-equalization is working as the value of all should be close to zero with the exception of the main tap 4) The equalization data per US interface defined as an average value in docsIfSigQEqualizationData=20 This concept is confusing since there is no in the RFI spec a methodology to calculate that average.=20 It could include :=20 - CMs with different configuration: pre-eq on|off,=20 - Different number of Taps per CM,=20 - Tap spacing per CM The average formula should've being=20 The recommendation is to remove that requirement Proposed resolution: a)=20 Use the same format as in the CM equalization data for 1) and 3) for=20 CM docsIfSigQEqualizationData and docsIfCmtsCmStatusEqualizationData b)=20 remove the CMTS requirement for docsIfSigQEqualizationData - Future spec efforts will work to define more meaningful values for CMTS US that could lead to objects that defines MER measurements prior and after channel signal compensation or mitigation by the CMTS c) Description of docsIfCmtsCmStatusEqualizationData d) CM upstream pre-equalizer Perhaps in further revisions of the DOCSIS specification and RFI MIB updates =20 Proposal details : a)=20 -- Add a new textual Convention DocsEqualizerData ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type represents the equalizer data as measured at the receiver interface. The format of the equalizer follows a similar structure Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI=20 v1.1 specification with slight modifications as follows : 1 byte Number of forward taps per symbol 1 byte Number of reverse taps per symbol 1 byte Number of forward taps 1 byte Number of reverse taps =20 Following are the equalizer coefficients: First forward taps coefficients : 2 bytes F1 (real), 2 bytes F1 (imag) ... 2 bytes Fn (real), 2 bytes Fn (imag) =20 Then reverse taps coefficients : 2 bytes D1 (real), 2 bytes D1 (imag) ... 2 bytes Dm (real), 2 bytes Dm (imag) The equalizers coefficient are considered signed 16 bit integers in the range -32768 (0x8000) to 32767 (0x7FFF). =20 DOCSIS specifications requires up to a maximum of=20 64 equalizer taps , therefore, this object size can get up 260 bytes (4 + 4x64). The minimum object size (other than zero) for a t-spaced Tab with a minimum of 8 symbols will be 36 (4 + 4x8)" SYNTAX OCTET STRING(SIZE 0|36..260)) alternative b-1)=20 docsIfSigQEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. =20 At the CMTS, this object is not applicable and might return a zero-length OCTET STRING. Note that previous CMTS=20 implementations may instantiate this object in two ways: - An equalization value different of the zero-length octet string to indicate an equalization average for the upstream channel. Those values have vendor=20 dependent interpretation. - Return a zero-length OCTET STRING as described below. =20 A returned zero-length OCTET STRING indicate the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::=3D { docsIfSignalQualityEntry 7 } --Note: same compliance statements as in draft 13 alternative b-2)=20 docsIfSigQEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. =20 At the CMTS, this object is not applicable and is not=20 instantiated. Note that previous CMTS implementations=20 may instantiate this object in two ways: - An equalization value different of the zero-length octet string to indicate an equalization average for the upstream channel. Those values have vendor=20 dependent interpretation. - Return a zero-length OCTET STRING as described below. =20 A returned zero-length OCTET STRING indicate the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::=3D { docsIfSignalQualityEntry 7 } -- Changes in compliance statements:=20 docsIfBasicGroupV2 OBJECT-GROUP OBJECTS { docsIfDownChannelId, -- ... snip ... -- delete -- docsIfSigQEqualizationData, --- ...snip ... } STATUS current DESCRIPTION "Group of objects implemented in both cable modems and cable modem termination systems." ::=3D { docsIfGroups 5 } docsIfCmGroupV2 OBJECT-GROUP OBJECTS { docsIfCmCmtsAddress, -- ... snip ... docsIfCmServiceExtTxSlotsDed, -- Add docsIfSigQEqualizationData --- ...snip ... } STATUS current DESCRIPTION "Group of objects implemented in cable modems." ::=3D { docsIfGroups 6 } c) docsIfCmtsCmStatusEqualizationData OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..512)) MAX-ACCESS read-only STATUS current DESCRIPTION "Equalization data for this CM as measured by the CMTS. Returns the zero-length OCTET STRING if the value is=20 unknown or if there is no equalization data available or defined." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I07-041210, Figure 8-23." ::=3D { docsIfCmtsCmStatusEntry 8 } Summary of comments received in a vendor internal discussion Copied for IPCDN participants background=20 ------------------ =20 Hal Roberts - ADC Colleagues, =20 While we are looking at this question we should make sure we end up with precise definitions of the equalization coefficient format for DOCSIS 3.0 for both the CMTS and the CM. Note that DOCSIS 3.0 Enhanced Signal Quality Monitoring goals include: =20 - Pre-Equalization (Already in spec)=20 * Review language to make sure output is standardized for processing.=20 =20 docsIfSigQEqualizationData For the cable modem "the equalization data for the downstream channel" has an unambiguous meaning. So for the cable modem it is the tap format which must be made unambiguous (this should be agreed upon by cable modem and/or cable modem chip manufacturers). With regard to the CMTS, the MIB docsIfSigQEqualizationData is supposed to provide the 'average' equalization data for the upstream channel as seen by the CMTS. This is an ambiguous statement. There is no 'average' equalization data since the equalization coefficients uniquely apply to each upstream path from each CM to the CMTS receiver. These coefficients are complex numbers, so in what way does one average them? If one can define a formula that results in a single real number from each set of coefficients as they come from the CMTS for each CM then one could envision averaging these numbers into something approaching a meaningful assessment of the linear distortions on a given upstream channel. (Tom Kolze has just such a formula and we have found it to be an accurate estimate of the MER of a channel due to distortions alone. Tom may be willing to share this with the working group). =20 Therefore I think that the definition of 'average equalization data for the upstream channel' must be clarified or the CMTS portion of the MIB should be removed. =20 docsIfCmtsCmStatusEqualizationData With regard to the MIB docsIfCmtsCmStatusEqualizationData, when pre-equalization is on there is little or no meaning to the equalization coefficients from the CMTS (even on a per-cable-modem basis rather than per channel). If pre-equalization is working correctly there should be very little residual channel distortion left and the coefficients will no longer have any relationship to the channel characteristics. Possibly the only use for these coefficients when pre-equalization is on, is to actually see if pre-equalization is doing the job. =20 On the other hand, when pre-equalization is turned off, docsIfCmtsCmStatusEqualizationData will accurately reflect distortions on the RF path between the given cable modem and the CMTS receiver. =20 Therefore I think that agreeing on the format of this MIB is what is necessary. One other suggestion, the text "Equalization data for this CM" might be clearer if it stated "Equalization data for this CM, as measured by the CMTS" =20 Hal =20 =20 docsIfSigQEqualizationData OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. At the CMTS, returns the average equalization data for the upstream channel. Returns an empty string if the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::=3D { docsIfSignalQualityEntry 7 } =20 ------------------------ =20 Andre Lejeune - ATI We report the docsIfSigQEqualizationData for our CM in the following format: =20 F1 (real) 16 bits, F1 (imag) 16 bits F2 (real) 16 bits, F2 (imag) 16 bits ... Fn (real) 16 bits, Fn (imag) 16 bits =20 The number of taps is deduced from the length of the octet string. ------------------------ =20 David Hull - Conexant=20 The DS equalizer has never been specified in terms of its exact implementation. This has been left to the individual silicon vendor; therefore they are all a bit different. Some implementations use T spaced all the way through and (I believe) some implementations may use fractional spacing for the front end (prior to the reference tap). Not all implementations have the same length of DS equalizer or the same center tap position (relative to the overall length) either. If all we want to do is compute the frequency response by a DFT on the tap weights, I don't think it matters what the CT position is but the length and the tap spacing would need to be conveyed if fractional spacing is used. ------------------------ =20 Andre Lejeune - ATI I am sorry I took some time to respond. I clearly needed to discuss this internally before continuing on the subject. =20 The format I sent earlier was for our modem. But now I realize that even our own solution will be changing and the format below won't be appropriate. I agree that more information needs to be carried in this MIB. A solution proposed by Mike Grimwood is to use the format from DOCSIS 1.1, figure 6.23 (without the type and length), which allows for Main Tap Location, Spacing, number of FF and FB taps. Even that may not be sufficient, if I properly understand Dave below, if different fractional spacing is used for the different taps. I'll let Dave explain this further if he thinks it is necessary. The main tap location is not absolutely required, as it generally can be easily derived, but could be useful under certain error conditions: =20 Main Tap Location (1 byte) Number of forward taps per symbol (1 byte) Number of forward taps (1 byte) Number of reverse taps (1 byte) F1 (real) 16 bits, F1 (imag) 16 bits F2 (real) 16 bits, F2 (imag) 16 bits ... Fn (real) 16 bits, Fn (imag) 16 bits D1 (real) 16 bits, D1 (imag) 16 bits D2 (real) 16 bits, D2 (imag) 16 bits ... Dn (real) 16 bits, Dn (imag) 16 bits =20 ------------------------ =20 Hal Roberts - ADC=20 To summarize: 1. Equalization MIBS from the CM - We need well defined MIBs from the CM for both the downstream post-equalizer and the upstream pre-equalizer values. If no uniform format for the downstream taps can be defined due to proprietary implementations, perhaps the vendors can simply provide a 'frequency response or impulse response' as calculated from the equalizer (but in a uniform format). For the upstream taps it should be easy to provide a uniform tap format as it is already mostly defined in the RFI. 2. Equalization MIBS from the CMTS when Pre-equalization is OFF - As mentioned before, an average equalization data from the CMTS on a per upstream channel basis is not defined and could take a number of meanings. Without an unambiguous definition of channel based equalization data, it would be better to remove this part of the definition as it simply leads to mass confusion. Note that equalization MIBs from the CMTS on a per CM basis do have significant value for plant monitoring and debug purposes. These merely need to be defined in format; this format could be the same format as in the pre-equalizer MIB from the CM as they are representing the same plant characteristic. 3. Equalization MIBS from the CMTS when Pre-equalization is ON - These have no significant value other than seeing if pre-equalization is operating properly. When pre-equalization is operating properly then the CMTS should see little or no plant distortion and the equalizer coefficients should be close to all-zeros except for the main tap for all modems. Hal ------------------------ =20 David Hull -Conexant=20 With regard to #1, the definition in Fig 6-22 of the DOCSIS 1.1 spec that Andre referred to seems good enough but I would allow the number of taps per symbol to be defined independently for the forward section AND the reverse section just in case someone implemented the two sections with different tap spacing. Short of officially "specifying" the DS equalizer like we have done for the upstream one, I don't see too much more that could be done. ------------------------ =20 Hal Roberts - ADC=20 Dave, =20 It may be elsewhere in the spec or it may be obvious but I think we need to have more detail, for example the numbers should be represented in a specific numerical format perhaps: =20 "Standard twos-complement format, from -32768 (0x8000) to 32767 (0x7FFF)" =20 as an example. =20 Hal ------------------------ =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Oct 03 19:09:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMZQg-0008QB-Gm; Mon, 03 Oct 2005 19:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMZQc-0008MW-8z for ipcdn@megatron.ietf.org; Mon, 03 Oct 2005 19:09:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27453 for ; Mon, 3 Oct 2005 19:08:59 -0400 (EDT) Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMZZ9-0005Ps-Sr for ipcdn@ietf.org; Mon, 03 Oct 2005 19:17:53 -0400 Received: from ([10.20.9.172]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.13970014; Mon, 03 Oct 2005 19:08:32 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Oct 2005 19:08:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes Date: Mon, 3 Oct 2005 19:08:31 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73016B1166@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes Thread-Index: AcWvFGt4c8fo+pUeS+yrWKff3hNg3gDKlXgABYvyNLA= From: "Woundy, Richard" To: "Jean-Francois Mule" , "Nakanishi Greg-MGI8179" , X-OriginalArrivalTime: 03 Oct 2005 23:08:31.0854 (UTC) FILETIME=[5F77D0E0:01C5C86F] X-Spam-Score: 0.4 (/) X-Scan-Signature: 1b2066b7e944cd0f55ca6d7a2077c2e4 Cc: Marez Kevin-MGI1375 , "Woundy, Richard" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0368290560==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============0368290560== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C86F.5F14086D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C86F.5F14086D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Based on the lack of response to this email, I presume the answer to = issue #4 is MUST NOT. That is, "docsDevFilterLLCTable" and most other = tables MUST NOT persist their table entries. I am comfortable with that = approach, since I believe that is how DOCSIS cable modems implement = these tables at the current time, and how most operators expect their = cable modems to behave. =20 I am going to attempt to post an official -10 draft by this Friday = October 7, based on the CD MIB draft changes recommended below. It is a = month later than I originally expected. :^( =20 But hopefully there is time to review, and if necessary, post a "final" = draft version before the Monday October 24 deadline before the Vancouver = IETF. =20 -- Rich -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Monday, September 05, 2005 1:35 PM To: Nakanishi Greg-MGI8179; ipcdn@ietf.org Cc: Woundy, Richard; Marez Kevin-MGI1375 Subject: RE: [ipcdn] cable dev mib draft09 - WG consensus requested on = proposed changes =09 =09 Thanks Greg for reviewing the proposed changes.=20 3 weeks have passed since August 15: we have reached WG consensus on = the proposed changes. =20 One comment was received from Greg on issue #4, to consider the = stronger 'MUST NOT' rather than 'SHOULD NOT'. I personally prefer SHOULD = NOT as it is already quite strong of a requirement and it allows a = device to remain complaint if the implementer has a good reason not to = implement the MUST NOT. Rich, Kevin, others - any preference?=20 if noone else responds by September 9, 9am ET, I propose we go with = Greg's preference: MUST NOT. =20 Jean-Fran=E7ois IPCDN co-chair =20 =09 ________________________________ From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com]=20 Sent: Thursday, September 01, 2005 10:44 AM To: Jean-Francois Mule; ipcdn@ietf.org Subject: RE: [ipcdn] cable dev mib draft09 - WG consensus requested on = proposed changes =20 I concur with the proposed resolution. =20 For Issue 4, my preference is that 'MUST NOT' be used, rather than = 'SHOULD NOT'. I think a device will run into operational problems if it = maintains these table entries across reboots. When the device reboots, = the config log will attempt to create rows in these tables and will fail = if the rows already exists. =20 greg =20 =09 ________________________________ From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf = Of Jean-Francois Mule Sent: Monday, August 15, 2005 3:20 PM To: ipcdn@ietf.org Subject: [ipcdn] cable dev mib draft09 - WG consensus requested on = proposed changes Folks, As you may have read in meeting notes from last week, we spent the = IETF 63 meeting discussing the closure of open issues on the CD mib v2. The meeting notes proposed some changes to get final (yes, final) = closure on this mib. Please review the text below and please speak up if you have some = concerns (it's also welcome that you express your agreement). Thanks, Jean-Fran=E7ois [extract from ipcdn minutes] 3.1/ DOCSIS Cable Device MIB version 2 draft-ietf-ipcdn-device-mibv2-09.txt Editors: Kevin Marez & Rich Woundy = http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt We spent most of the meeting reviewing the 4 top remaining issues, see summary sent by Rich and Kevin in: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html =20 + ISSUE #1: DEFVAL for docsDevNmAccessInterfaces=20 Raised by Randy, the issue is, in the defval we have a 4 octet value =3D> How can systems with interfaces in a number not multiple of 8 interpret the DEFVAL value. Are bits ignored? Randy commented that he would be ok if there was some mention like 'octets containing bits corresponding to non-existent interfaces are ignored.' That said, if there are implementations that would reject a SET, then we need to say something about that. Rich commented that the DEFVAL was added due to prior MIB doctor comment and that the object is now deprecated. Bert asked whether there was any concern deleting the DEFVAL. Proposal for wg review: a) in docsDevNmAccessInterfaces, delete DEFVAL { '00000001'h } b) consider the following (NICE TO HAVE kind of fix) adding a sentence to say something like: bits set corresponding to non-existing interfaces is implementation specific (to warn the mgmt admin/apps that no assumptions should be made on existing implementations of this object. (Randy's suggestion) =20 + ISSUE #2: docsDevNmAccessStatus -- Also, we should change the DESCRIPTION of docsDevCpeStatus -- and docsDevCpeInetRowStatus to document how the agent adds rows. See issue raised by Randy and the email summary provided by Rich for the context around this issue #2. We had some discussions around the persistency of those tables, the fact that the CM config file drives the row creation at boot-up and the fact that they are read-create tables so admins can also create entries as Bert pointed out. In most cases (except for docsDevEvControlTable), entries do not persist across CM reboots. Even in the case of docsDevEvControlTable, after some discussion, we believe that the entries are cleared and "recreated" after the CM reads the config file. That is the common understanding. Bert said: add a statement ("this is a deprecated table, this is vendor specific as to what vendors do with this table, mgmt app cannot expect a certain behavior"). + ISSUE #3: docsDevEvReporting and local(0) rows Comment close: ID authors agree with Randy's comment re: local(0) rows MUST persist. Text will be revised. in docsDevFilterLLCTable: Any attempt to SET the traps(1) or syslog(2) bits without setting the local(0) or localVolatile(8) bits MUST result in an error being generated. Proposal: DELETE above text if nobody complains after reading the meeting notes + ISSUE #4: docsDevFilterLLCTable=20 Issue is around text for the level of requirements on table persistence. Agree with Rich's text proposal: |"Table entries MUST NOT persist across reboots for cable modems." Rich also proposed to apply this requirement to: NmAccess, FilterLLC, FilterIp, Policy, Tos, Cpe and InetCpe tables. It was suggested to use SHOULD NOT rather than MUST NOT but other than that, proposal is ok. =20 + Other items on CD Device MIB: Randy added for consideration: wherever we have this "must not persist" langage in table definitions, it would be a plus to indicate that they may come back as entries may reappear when CM reboots and comes up with config file. Or consider adding this in the front paper as a consideration for users of the MIBs if that is too many little edits in the MIB objects. Proposal: add a note on persistence model explaining the persistance of some mib objects and the CM re-creating them upon config file reloading. A comment was made that in general, we should indicate the persistency model in each object rather than in the compliance section. Bert also commented on the compliance sections: if different requirements apply to CM and CMTS, suggestion is to make 2 different compliances. Rich added that the new compliance statement is designed like that. # AI: [authors: Kevin Marez & Rich Woundy] # Authors to summarize list of agreed changed and the technical # changes in the text per wg consensus and issue new draft after AD # review comments are in.=20 # Due by early September? # AD review by Bert due by August 15 ------_=_NextPart_001_01C5C86F.5F14086D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message=
Based=20 on the lack of response to this email, I presume the answer to issue #4 = is MUST=20 NOT. That is, "docsDevFilterLLCTable" and most other tables MUST = NOT=20 persist their table entries. I am comfortable with that approach, since = I=20 believe that is how DOCSIS cable modems implement these tables at the = current=20 time, and how most operators expect their cable modems to=20 behave.
 
I am=20 going to attempt to post an official -10 draft by this Friday October 7, = based=20 on the CD MIB draft changes recommended below. It is a month later than = I=20 originally expected. :^(
 
But=20 hopefully there is time to review, and if necessary, post a "final" = draft=20 version before the Monday October 24 deadline before the Vancouver=20 IETF.
 
--=20 Rich
-----Original Message-----
From: = Jean-Francois=20 Mule [mailto:jf.mule@cablelabs.com]
Sent: Monday, September = 05,=20 2005 1:35 PM
To: Nakanishi Greg-MGI8179;=20 ipcdn@ietf.org
Cc: Woundy, Richard; Marez=20 Kevin-MGI1375
Subject: RE: [ipcdn] cable dev mib draft09 - = WG=20 consensus requested on proposed changes

Thanks Greg=20 for reviewing the proposed changes.

3 = weeks have=20 passed since August 15: we have reached WG consensus on the proposed=20 changes.

 

One = comment=20 was received from Greg on issue #4, to consider the stronger =91MUST = NOT=92 rather=20 than =91SHOULD NOT=92. I personally prefer SHOULD NOT as it is already = quite=20 strong of a requirement and it allows a device to remain complaint if = the=20 implementer has a good reason not to implement the MUST=20 NOT.

Rich, Kevin,=20 others - any preference?

if = noone else=20 responds by September 9, 9am ET, I propose we go with Greg=92s = preference: MUST=20 NOT.

 

Jean-Fran=E7ois

IPCDN=20 co-chair

 

From:=20 Nakanishi Greg-MGI8179=20 [mailto:gnakanishi@motorola.com]
Sent: Thursday, September 01, = 2005 10:44=20 AM
To: = Jean-Francois Mule; = ipcdn@ietf.org
Subject: RE: [ipcdn] cable dev = mib=20 draft09 - WG consensus requested on proposed=20 changes

 

I concur = with the=20 proposed resolution.

 

For Issue = 4, my=20 preference is that 'MUST NOT' be used, rather than 'SHOULD NOT'.  = I think=20 a device will run into operational problems if it maintains these = table=20 entries across reboots.  When the device reboots, the config log = will=20 attempt to create rows in these tables and will fail if the rows = already=20 exists.

 

greg

 

From:=20 ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Jean-Francois Mule
Sent: Monday, August 15, 2005 = 3:20=20 PM
To:=20 ipcdn@ietf.org
Subject:=20 [ipcdn] cable dev mib draft09 - WG consensus requested on proposed=20 changes

Folks,

   As = you may=20 have read in meeting notes from last week, we spent = the IETF 63 = meeting=20 discussing the closure of open issues on the CD mib=20 v2.

   The = meeting=20 notes proposed some changes to get final (yes, final) closure on this=20 mib.

Please review=20 the text below and = please=20 speak up if you have some concerns (it's also welcome that you express = your=20 agreement).

Thanks,

Jean-Fran=E7ois

[extract from = ipcdn=20 minutes]

3.1/ DOCSIS = Cable Device=20 MIB version 2

    =20 draft-ietf-ipcdn-device-mibv2-09.txt

    =20 Editors: Kevin Marez & Rich Woundy

http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv= 2-09.txt

We spent most of = the=20 meeting reviewing the 4 top remaining issues, = see

summary sent by = Rich and=20 Kevin in:

http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html

 

+ ISSUE #1: = DEFVAL for=20 docsDevNmAccessInterfaces

Raised by Randy, = the issue=20 is, in the defval we have a 4 octet value

=3D> How can = systems with=20 interfaces in a number not multiple

of 8 interpret = the DEFVAL=20 value. Are bits ignored?

Randy commented = that he=20 would be ok if there was some mention = like

'octets = containing bits=20 corresponding to non-existent interfaces = are

ignored.' That = said, if=20 there are implementations that would reject = a

SET, then we = need to say=20 something about that.

Rich commented = that the=20 DEFVAL was added due to prior MIB doctor

comment and that = the=20 object is now deprecated. Bert asked = whether

there was any = concern=20 deleting the DEFVAL.

Proposal=20 for wg review:

 a)=20 in docsDevNmAccessInterfaces, delete DEFVAL { '00000001'h=20 }

 b)=20 consider the following (NICE TO HAVE kind of=20 fix)

   =20 adding a sentence to say something = like:

   =20 bits set corresponding to non-existing interfaces=20 is

   =20 implementation specific (to warn the mgmt admin/apps that=20 no

   =20 assumptions should be made on existing implementations of=20 this

   =20 object. (Randy's suggestion)

 

+ ISSUE #2:=20 docsDevNmAccessStatus

-- Also, we = should change=20 the DESCRIPTION of docsDevCpeStatus

-- and=20 docsDevCpeInetRowStatus to document how the agent adds=20 rows.

See issue raised = by Randy=20 and the email summary provided by Rich = for

the context = around this=20 issue #2.

We had some = discussions=20 around the persistency of those tables, = the

fact that the CM = config=20 file drives the row creation at boot-up = and

the fact that = they are=20 read-create tables so admins can also = create

entries as Bert = pointed=20 out.

In most cases = (except for=20 docsDevEvControlTable), entries do not

persist across = CM reboots.=20 Even in the case of = docsDevEvControlTable,

after some = discussion, we=20 believe that the entries are cleared and

"recreated" = after the CM=20 reads the config file. That is the common

understanding.

Bert=20 said: add a statement ("this is a deprecated table, this=20 is

vendor=20 specific as to what vendors do with this table, mgmt app=20 cannot

expect=20 a certain behavior").

+ ISSUE #3:=20 docsDevEvReporting and local(0) rows

Comment close: = ID authors=20 agree with Randy's comment re: local(0) = rows

MUST persist. = Text will be=20 revised.

in=20 docsDevFilterLLCTable:

           &= nbsp;=20 Any attempt to SET the traps(1) or syslog(2) = bits

           &= nbsp;=20 without setting the local(0) or = localVolatile(8)

           &= nbsp;=20 bits MUST result in an error being = generated.

Proposal:

  =20 DELETE above text if nobody complains after reading the=20 meeting

  =20 notes

+ ISSUE #4:=20 docsDevFilterLLCTable

Issue is around = text for=20 the level of requirements on table

persistence. Agree=20 with Rich's text proposal:

 =20 |"Table entries MUST NOT persist across reboots for cable=20 modems."

Rich=20 also proposed to apply this requirement = to:

 =20 NmAccess, FilterLLC, FilterIp, Policy, = Tos,

 =20 Cpe and InetCpe tables.

It was=20 suggested to use SHOULD NOT rather than MUST NOT but other=20 than

that,=20 proposal is ok.

 

+ Other items on = CD Device=20 MIB:

Randy added for=20 consideration:

wherever we have = this=20 "must not persist" langage in table = definitions,

it would be a = plus to=20 indicate that they may come back as entries = may

reappear when CM = reboots=20 and comes up with config file. Or = consider

adding this in = the front=20 paper as a consideration for users of the

MIBs if that is = too many=20 little edits in the MIB objects.

Proposal:

  add a = note on=20 persistence model explaining the persistance of=20 some

mib objects and = the CM=20 re-creating them upon config file = reloading.

A comment was = made that in=20 general, we should indicate the = persistency

model in each = object=20 rather than in the compliance section.

Bert also = commented on the=20 compliance sections: if different

requirements = apply to CM=20 and CMTS, suggestion is to make 2 = different

compliances. = Rich added=20 that the new compliance statement is = designed

like=20 that.

# AI: [authors: = Kevin=20 Marez & Rich Woundy]

# Authors to = summarize=20 list of agreed changed and the technical

# changes in the = text per=20 wg consensus and issue new draft after AD

# review = comments are in.=20

# Due by early=20 September?

# AD review by = Bert due by=20 August = 15

------_=_NextPart_001_01C5C86F.5F14086D-- --===============0368290560== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0368290560==-- From ipcdn-bounces@ietf.org Fri Oct 07 17:21:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENzec-0002Zy-Gl; Fri, 07 Oct 2005 17:21:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENzeY-0002Zl-4J for ipcdn@megatron.ietf.org; Fri, 07 Oct 2005 17:21:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25352 for ; Fri, 7 Oct 2005 17:21:15 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENznu-00052Y-Qe for ipcdn@ietf.org; Fri, 07 Oct 2005 17:30:59 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j97LKx7M005613; Fri, 7 Oct 2005 15:20:59 -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] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Date: Fri, 7 Oct 2005 15:20:59 -0600 Message-ID: Thread-Topic: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Thread-Index: AcWkSL5Ywu1ad9A3S76MtFLa52WFRAADmRVwCcspCxA= From: "Sumanth Channabasappa" To: "Eugene Nechamkin" , "Randy Presuhn" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Greg, Randy, Eugene, Thanks for the comments. A few clarifications inline: #1: - The description makes mention of throttling events using SNMP and Syslog. What about the local log? Are events written to the local log not subject to throttling? =20 [s] The objective of the MIB Objects belonging to 'pktcDevEventThrottle' was to limit the throttling of events to the network (esp. in power-up-after-a-blackout scenario), not locally. Regarding local logging of events: - the MTAs are currently required to store 2^31 events (in the local log) and if we have questions regarding the size we should change the index value 'pktcDevEvLogIndex' (suggestions anyone, MTA vendors?) - Further, if we want to throttle local logging, we should probably define a new MIB Object for local events only (since the throttling conditions would vary between network and local storage) - thoughts? #2: - pktcDevEventDescrText and pktcDevEventDescrClass - These objects are read-write. It seems odd to me that these objects would be writable. Is it really intended that these are writable objects? [s] Yes, this is intended since an operator could change the 'Description of an event' to better suit 'Operational specific values' (via SNMP or by using the configuration file at bootstrapping time). E.g. MSO XYZ could change a lengthy description such as 'Error in TFTP response to the MTA due to XYZ' into a shortened string such as 'TFTP-ERR:XYZ'. >>> FYI <<< I am working on a couple of other comments, but the following (mostly from Greg and some internal) have been incorporated as-is: There are a number of places in the document that makes reference to "PacketCable device". Shouldn't this be "PacketCable or IPCablecom device"? Or more simply "MTA device". The naming convention we've been using on other MIB modules in IPCDN adds "-IETF-" to the module name to distinguish it from the corresponding MIB module being developed in CableLabs. So, it this case, the MIB module name should be something like "PKTC-IETF-EVENT-MIB". I think the ORGANIZATION clause should be IPCDN rather than CableLabs. The DESCRIPTION clause is missing the mandatory copyright notice. pktcDevEnvetReportStatus - The last sentence of the DESCRIPTION clause states "... Defined by PacketCable by default." Should this just PacketCable or PacketCable and IPCablecom. pktcDevEvThrottleAdminStatus - "A value of stopAtThreshold(3) causes event message transmission to cease at the threshold, and not resume until directed to do so." How is the device directed to resume sending event messages? pktcDevEvThrottleInterval - The DEFVAL clause should be on a separate line for readability. pktcDevEventDescrTable - Should the reference to "PacketCable" be "PacketCable/IPCablecom"? pktcDevEventDescrId - "The event identifier can either be PacketCable defined or vendor-specific." Would be good to provide a reference to the PacketCable spec where the events are defined. pktcDevEventDescrReporting - Should define what each one of the bit values mean. pktcDevEvLogCorrelationId - "...per section 5.4.5 of [3]" Reference [3] doesn't exist in the references section. pktcDevEvLogCorrelationId "This MIB Object contains the correlation ID=20 generated by the MTA during the initiation of the last provisioning flow, within or following which the event occurred.=20 For information on the generation of correlation ids, refer to the corresponding PacketCable/IPCableCom Device Provisioning specifications." [PKT-SP-EVEMIB1.5] - There is an odd character after the "PacketCable" Reference section - There are number of reference in the body of the text that do not exist in the references section. Need to make sure all reference are cited. The ones I found are PKT-SP-PROV, PKT-SP-MIB-MTA, PKT-SP-MGCP, RFC3435, PKT-SP-CODEC, and RFC2119. Security Considerations - Per the MIB Guidelines, need to explicit discuss all MIB objects, even if to only state that there are no security issues with the object. - There is no MIB Object defined as 'pktcDevEventThrottle 3' (we have MIB Objects for 2 and 4) - The Reference in the description of the MIB Object 'pktcDevEvLogCorrelationId' seems to be out of place. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Oct 11 13:59:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPOPd-0001ad-Ed; Tue, 11 Oct 2005 13:59:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPOPb-0001aX-Je for ipcdn@megatron.ietf.org; Tue, 11 Oct 2005 13:59:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18426 for ; Tue, 11 Oct 2005 13:59:37 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPOZk-0002yK-Lz for ipcdn@ietf.org; Tue, 11 Oct 2005 14:10:09 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j9BHxHUf012209; Tue, 11 Oct 2005 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 Subject: RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Date: Tue, 11 Oct 2005 11:59:17 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F01178837@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKAACga3IAAAh6FUAACaROgB9+1Q8ABj7jfcA== From: "Eduardo Cardona" To: "Eduardo Cardona" , "Ipcdn (E-mail)" , "Wijnen, Bert (Bert)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 876202f9cbc0933cffbc58102e40f8f2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Does anyone get the chance to review the proposed clarifications ?=20 Please reply with comments by the end of the week=20 Thanks Eduardo -----Original Message----- From: Eduardo Cardona=20 Sent: Monday, October 03, 2005 3:35 PM To: Ipcdn (E-mail); Wijnen, Bert (Bert); david.raftus@ati.com Subject: RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Hi IPCDN participants, Here is an update on one of the pending items from Bert's review: After consultations with DOCSIS vendors, I am proposing the clarifications required to define the size constraints for docsIfCmtsCmStatusEqualizationData and docsIfSigQEqualizationData Please review the details and send your comments. You will find in this email a summary of the proposed changes as well as a log of comments provided by vendors to place the discussion in the context of the IPCDN participants.=20 Please comment on the proposals and make the appropriate comments=20 Item a) Item c) Item d) Comments and pick an alternative from b-1)=20 and=20 b-2) ---- =20 CM/CMTS Equalizer Data:=20 Summary: docsIfSigQEqualizationData and docsIfCmtsCmStatusEqualizationData have OCTET STRING with no constraints in the object size (RFC 2669), in fact the format of the pre-equalizers was never normalized and left vendor specific In draft 06 of RFIv2.0 It was added a size constraint of 512 octets but no special reason was defined: Some basic Math will indicate that up to 64 taps ( RFI requirements) and 4 bytes per tap will indicate 256 bytes, still uncertain why 512 was selected. Even though the selection of 256 (or 512) does not seem to be accurate number considering some possible byte controls to indicate: - Taps could be T, T/2 or T/4 spaced.=20 - Forward Taps and Reverse Taps could have different numbers - Not required by the spec : Reverse Taps (DS equalizers) could be also T, T/2 and T/4 spaced - Any need to indicate main tap position ( or the highest value is enough indication of that=20 The discussions held with RF experts identified the following management requirements :=20 =20 1) CM DS post-equalization have been defined in docsIfSigQEqualizationData=20 2) CM Upstream pre-equalizer ( not to be defined in this version of the MIB) something to reflect the CMTS RNG-RSP equalizer value=20 CMTS equalization Data: 3) Equalization in the Upstream has relative importance for CMTS CM path, docsIfCmtsCmStatusEqualizationData Meanings: When Pre-eq is off, the value will indicate the CM-CMTS path RF distortions.=20 When re-eq is on, the value indicates how well pre-equalization is working as the value of all should be close to zero with the exception of the main tap 4) The equalization data per US interface defined as an average value in docsIfSigQEqualizationData=20 This concept is confusing since there is no in the RFI spec a methodology to calculate that average.=20 It could include :=20 - CMs with different configuration: pre-eq on|off,=20 - Different number of Taps per CM,=20 - Tap spacing per CM The average formula should've being=20 The recommendation is to remove that requirement Proposed resolution: a)=20 Use the same format as in the CM equalization data for 1) and 3) for=20 CM docsIfSigQEqualizationData and docsIfCmtsCmStatusEqualizationData b)=20 remove the CMTS requirement for docsIfSigQEqualizationData - Future spec efforts will work to define more meaningful values for CMTS US that could lead to objects that defines MER measurements prior and after channel signal compensation or mitigation by the CMTS c) Description of docsIfCmtsCmStatusEqualizationData d) CM upstream pre-equalizer Perhaps in further revisions of the DOCSIS specification and RFI MIB updates =20 Proposal details : a)=20 -- Add a new textual Convention DocsEqualizerData ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type represents the equalizer data as measured at the receiver interface. The format of the equalizer follows a similar structure Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI=20 v1.1 specification with slight modifications as follows : 1 byte Number of forward taps per symbol 1 byte Number of reverse taps per symbol 1 byte Number of forward taps 1 byte Number of reverse taps =20 Following are the equalizer coefficients: First forward taps coefficients : 2 bytes F1 (real), 2 bytes F1 (imag) ... 2 bytes Fn (real), 2 bytes Fn (imag) =20 Then reverse taps coefficients : 2 bytes D1 (real), 2 bytes D1 (imag) ... 2 bytes Dm (real), 2 bytes Dm (imag) The equalizers coefficient are considered signed 16 bit integers in the range -32768 (0x8000) to 32767 (0x7FFF). =20 DOCSIS specifications requires up to a maximum of=20 64 equalizer taps , therefore, this object size can get up 260 bytes (4 + 4x64). The minimum object size (other than zero) for a t-spaced Tab with a minimum of 8 symbols will be 36 (4 + 4x8)" SYNTAX OCTET STRING(SIZE 0|36..260)) alternative b-1)=20 docsIfSigQEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. =20 At the CMTS, this object is not applicable and might return a zero-length OCTET STRING. Note that previous CMTS=20 implementations may instantiate this object in two ways: - An equalization value different of the zero-length octet string to indicate an equalization average for the upstream channel. Those values have vendor=20 dependent interpretation. - Return a zero-length OCTET STRING as described below. =20 A returned zero-length OCTET STRING indicate the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::=3D { docsIfSignalQualityEntry 7 } --Note: same compliance statements as in draft 13 alternative b-2)=20 docsIfSigQEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. =20 At the CMTS, this object is not applicable and is not=20 instantiated. Note that previous CMTS implementations=20 may instantiate this object in two ways: - An equalization value different of the zero-length octet string to indicate an equalization average for the upstream channel. Those values have vendor=20 dependent interpretation. - Return a zero-length OCTET STRING as described below. =20 A returned zero-length OCTET STRING indicate the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::=3D { docsIfSignalQualityEntry 7 } -- Changes in compliance statements:=20 docsIfBasicGroupV2 OBJECT-GROUP OBJECTS { docsIfDownChannelId, -- ... snip ... -- delete -- docsIfSigQEqualizationData, --- ...snip ... } STATUS current DESCRIPTION "Group of objects implemented in both cable modems and cable modem termination systems." ::=3D { docsIfGroups 5 } docsIfCmGroupV2 OBJECT-GROUP OBJECTS { docsIfCmCmtsAddress, -- ... snip ... docsIfCmServiceExtTxSlotsDed, -- Add docsIfSigQEqualizationData --- ...snip ... } STATUS current DESCRIPTION "Group of objects implemented in cable modems." ::=3D { docsIfGroups 6 } c) docsIfCmtsCmStatusEqualizationData OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..512)) MAX-ACCESS read-only STATUS current DESCRIPTION "Equalization data for this CM as measured by the CMTS. Returns the zero-length OCTET STRING if the value is=20 unknown or if there is no equalization data available or defined." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I07-041210, Figure 8-23." ::=3D { docsIfCmtsCmStatusEntry 8 } Summary of comments received in a vendor internal discussion Copied for IPCDN participants background=20 ------------------ =20 Hal Roberts - ADC Colleagues, =20 While we are looking at this question we should make sure we end up with precise definitions of the equalization coefficient format for DOCSIS 3.0 for both the CMTS and the CM. Note that DOCSIS 3.0 Enhanced Signal Quality Monitoring goals include: =20 - Pre-Equalization (Already in spec)=20 * Review language to make sure output is standardized for processing.=20 =20 docsIfSigQEqualizationData For the cable modem "the equalization data for the downstream channel" has an unambiguous meaning. So for the cable modem it is the tap format which must be made unambiguous (this should be agreed upon by cable modem and/or cable modem chip manufacturers). With regard to the CMTS, the MIB docsIfSigQEqualizationData is supposed to provide the 'average' equalization data for the upstream channel as seen by the CMTS. This is an ambiguous statement. There is no 'average' equalization data since the equalization coefficients uniquely apply to each upstream path from each CM to the CMTS receiver. These coefficients are complex numbers, so in what way does one average them? If one can define a formula that results in a single real number from each set of coefficients as they come from the CMTS for each CM then one could envision averaging these numbers into something approaching a meaningful assessment of the linear distortions on a given upstream channel. (Tom Kolze has just such a formula and we have found it to be an accurate estimate of the MER of a channel due to distortions alone. Tom may be willing to share this with the working group). =20 Therefore I think that the definition of 'average equalization data for the upstream channel' must be clarified or the CMTS portion of the MIB should be removed. =20 docsIfCmtsCmStatusEqualizationData With regard to the MIB docsIfCmtsCmStatusEqualizationData, when pre-equalization is on there is little or no meaning to the equalization coefficients from the CMTS (even on a per-cable-modem basis rather than per channel). If pre-equalization is working correctly there should be very little residual channel distortion left and the coefficients will no longer have any relationship to the channel characteristics. Possibly the only use for these coefficients when pre-equalization is on, is to actually see if pre-equalization is doing the job. =20 On the other hand, when pre-equalization is turned off, docsIfCmtsCmStatusEqualizationData will accurately reflect distortions on the RF path between the given cable modem and the CMTS receiver. =20 Therefore I think that agreeing on the format of this MIB is what is necessary. One other suggestion, the text "Equalization data for this CM" might be clearer if it stated "Equalization data for this CM, as measured by the CMTS" =20 Hal =20 =20 docsIfSigQEqualizationData OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. At the CMTS, returns the average equalization data for the upstream channel. Returns an empty string if the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::=3D { docsIfSignalQualityEntry 7 } =20 ------------------------ =20 Andre Lejeune - ATI We report the docsIfSigQEqualizationData for our CM in the following format: =20 F1 (real) 16 bits, F1 (imag) 16 bits F2 (real) 16 bits, F2 (imag) 16 bits ... Fn (real) 16 bits, Fn (imag) 16 bits =20 The number of taps is deduced from the length of the octet string. ------------------------ =20 David Hull - Conexant=20 The DS equalizer has never been specified in terms of its exact implementation. This has been left to the individual silicon vendor; therefore they are all a bit different. Some implementations use T spaced all the way through and (I believe) some implementations may use fractional spacing for the front end (prior to the reference tap). Not all implementations have the same length of DS equalizer or the same center tap position (relative to the overall length) either. If all we want to do is compute the frequency response by a DFT on the tap weights, I don't think it matters what the CT position is but the length and the tap spacing would need to be conveyed if fractional spacing is used. ------------------------ =20 Andre Lejeune - ATI I am sorry I took some time to respond. I clearly needed to discuss this internally before continuing on the subject. =20 The format I sent earlier was for our modem. But now I realize that even our own solution will be changing and the format below won't be appropriate. I agree that more information needs to be carried in this MIB. A solution proposed by Mike Grimwood is to use the format from DOCSIS 1.1, figure 6.23 (without the type and length), which allows for Main Tap Location, Spacing, number of FF and FB taps. Even that may not be sufficient, if I properly understand Dave below, if different fractional spacing is used for the different taps. I'll let Dave explain this further if he thinks it is necessary. The main tap location is not absolutely required, as it generally can be easily derived, but could be useful under certain error conditions: =20 Main Tap Location (1 byte) Number of forward taps per symbol (1 byte) Number of forward taps (1 byte) Number of reverse taps (1 byte) F1 (real) 16 bits, F1 (imag) 16 bits F2 (real) 16 bits, F2 (imag) 16 bits ... Fn (real) 16 bits, Fn (imag) 16 bits D1 (real) 16 bits, D1 (imag) 16 bits D2 (real) 16 bits, D2 (imag) 16 bits ... Dn (real) 16 bits, Dn (imag) 16 bits =20 ------------------------ =20 Hal Roberts - ADC=20 To summarize: 1. Equalization MIBS from the CM - We need well defined MIBs from the CM for both the downstream post-equalizer and the upstream pre-equalizer values. If no uniform format for the downstream taps can be defined due to proprietary implementations, perhaps the vendors can simply provide a 'frequency response or impulse response' as calculated from the equalizer (but in a uniform format). For the upstream taps it should be easy to provide a uniform tap format as it is already mostly defined in the RFI. 2. Equalization MIBS from the CMTS when Pre-equalization is OFF - As mentioned before, an average equalization data from the CMTS on a per upstream channel basis is not defined and could take a number of meanings. Without an unambiguous definition of channel based equalization data, it would be better to remove this part of the definition as it simply leads to mass confusion. Note that equalization MIBs from the CMTS on a per CM basis do have significant value for plant monitoring and debug purposes. These merely need to be defined in format; this format could be the same format as in the pre-equalizer MIB from the CM as they are representing the same plant characteristic. 3. Equalization MIBS from the CMTS when Pre-equalization is ON - These have no significant value other than seeing if pre-equalization is operating properly. When pre-equalization is operating properly then the CMTS should see little or no plant distortion and the equalizer coefficients should be close to all-zeros except for the main tap for all modems. Hal ------------------------ =20 David Hull -Conexant=20 With regard to #1, the definition in Fig 6-22 of the DOCSIS 1.1 spec that Andre referred to seems good enough but I would allow the number of taps per symbol to be defined independently for the forward section AND the reverse section just in case someone implemented the two sections with different tap spacing. Short of officially "specifying" the DS equalizer like we have done for the upstream one, I don't see too much more that could be done. ------------------------ =20 Hal Roberts - ADC=20 Dave, =20 It may be elsewhere in the spec or it may be obvious but I think we need to have more detail, for example the numbers should be represented in a specific numerical format perhaps: =20 "Standard twos-complement format, from -32768 (0x8000) to 32767 (0x7FFF)" =20 as an example. =20 Hal ------------------------ =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Oct 12 18:18:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPovQ-0001Dt-Ud; Wed, 12 Oct 2005 18:18:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPovP-0001AI-KU for ipcdn@megatron.ietf.org; Wed, 12 Oct 2005 18:18:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08900 for ; Wed, 12 Oct 2005 18:18:11 -0400 (EDT) Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPp5m-0006yq-3K for ipcdn@ietf.org; Wed, 12 Oct 2005 18:29:00 -0400 Received: from 10.10.64.121 by mms1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 12 Oct 2005 15:17:42 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Wed, 12 Oct 2005 12:32:01 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BZK56892; Wed, 12 Oct 2005 12:31:57 -0700 (PDT) Received: from ltatladolas (dhcp-10-24-16-25.atlanta.broadcom.com [10.24.16.25]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id MAA29701; Wed, 12 Oct 2005 12:31:56 -0700 (PDT) Message-ID: <200510121931.MAA29701@mon-irva-10.broadcom.com> From: "Margo Dolas" To: "'Eduardo Cardona'" , "'Ipcdn (E-mail)'" , "'Wijnen, Bert (Bert)'" , david.raftus@ati.com Subject: RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Date: Wed, 12 Oct 2005 15:31:53 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKAACga3IAAAh6FUAACaROgB9+1Q8ABj7jfcAAuytRw In-Reply-To: <5259D0D7419C6149B347837A2E64F46F01178837@srvxchg.cablelabs.com> X-WSS-ID: 6F53549C2OO1099048-545-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b6435b1bfa5977f2eb96dc7e52434b6d Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Eduardo, Thanks for going to the effort of clarifying these objects! I only have one comment. The creation of the DocsEqualizerData convention is good, but would it be possible to change the definition to match that of the RNG-RSP from DOCSIS1.1, removing the number of reverse taps per symbol and adding the main tap location? It's unnecessary to specify the number of reverse taps per symbol, since it would be a T-spaced DFE. The main tap location is important (at least for the upstream) because it refers to the position of the zero delay tap for a ranging consideration. DocsEqualizerData ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type represents the equalizer data as measured at the receiver interface. The format of the equalizer follows a similar structure Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI v1.1 specification with slight modifications as follows : 1 byte Main Tap Location 1 byte Number of forward taps per symbol 1 byte Number of forward taps 1 byte Number of reverse taps ... In terms of options (b-1) and (b-2), I don't have a strong preference, but a small preference for (b-2). Margo -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Eduardo Cardona Sent: Tuesday, October 11, 2005 1:59 PM To: Eduardo Cardona; Ipcdn (E-mail); Wijnen, Bert (Bert); david.raftus@ati.com Subject: RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Does anyone get the chance to review the proposed clarifications ? Please reply with comments by the end of the week Thanks Eduardo -----Original Message----- From: Eduardo Cardona Sent: Monday, October 03, 2005 3:35 PM To: Ipcdn (E-mail); Wijnen, Bert (Bert); david.raftus@ati.com Subject: RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Hi IPCDN participants, Here is an update on one of the pending items from Bert's review: After consultations with DOCSIS vendors, I am proposing the clarifications required to define the size constraints for docsIfCmtsCmStatusEqualizationData and docsIfSigQEqualizationData Please review the details and send your comments. You will find in this email a summary of the proposed changes as well as a log of comments provided by vendors to place the discussion in the context of the IPCDN participants. Please comment on the proposals and make the appropriate comments Item a) Item c) Item d) Comments and pick an alternative from b-1) and b-2) ---- CM/CMTS Equalizer Data: Summary: docsIfSigQEqualizationData and docsIfCmtsCmStatusEqualizationData have OCTET STRING with no constraints in the object size (RFC 2669), in fact the format of the pre-equalizers was never normalized and left vendor specific In draft 06 of RFIv2.0 It was added a size constraint of 512 octets but no special reason was defined: Some basic Math will indicate that up to 64 taps ( RFI requirements) and 4 bytes per tap will indicate 256 bytes, still uncertain why 512 was selected. Even though the selection of 256 (or 512) does not seem to be accurate number considering some possible byte controls to indicate: - Taps could be T, T/2 or T/4 spaced. - Forward Taps and Reverse Taps could have different numbers - Not required by the spec : Reverse Taps (DS equalizers) could be also T, T/2 and T/4 spaced - Any need to indicate main tap position ( or the highest value is enough indication of that The discussions held with RF experts identified the following management requirements : 1) CM DS post-equalization have been defined in docsIfSigQEqualizationData 2) CM Upstream pre-equalizer ( not to be defined in this version of the MIB) something to reflect the CMTS RNG-RSP equalizer value CMTS equalization Data: 3) Equalization in the Upstream has relative importance for CMTS CM path, docsIfCmtsCmStatusEqualizationData Meanings: When Pre-eq is off, the value will indicate the CM-CMTS path RF distortions. When re-eq is on, the value indicates how well pre-equalization is working as the value of all should be close to zero with the exception of the main tap 4) The equalization data per US interface defined as an average value in docsIfSigQEqualizationData This concept is confusing since there is no in the RFI spec a methodology to calculate that average. It could include : - CMs with different configuration: pre-eq on|off, - Different number of Taps per CM, - Tap spacing per CM The average formula should've being The recommendation is to remove that requirement Proposed resolution: a) Use the same format as in the CM equalization data for 1) and 3) for CM docsIfSigQEqualizationData and docsIfCmtsCmStatusEqualizationData b) remove the CMTS requirement for docsIfSigQEqualizationData - Future spec efforts will work to define more meaningful values for CMTS US that could lead to objects that defines MER measurements prior and after channel signal compensation or mitigation by the CMTS c) Description of docsIfCmtsCmStatusEqualizationData d) CM upstream pre-equalizer Perhaps in further revisions of the DOCSIS specification and RFI MIB updates Proposal details : a) -- Add a new textual Convention DocsEqualizerData ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type represents the equalizer data as measured at the receiver interface. The format of the equalizer follows a similar structure Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI v1.1 specification with slight modifications as follows : 1 byte Number of forward taps per symbol 1 byte Number of reverse taps per symbol 1 byte Number of forward taps 1 byte Number of reverse taps Following are the equalizer coefficients: First forward taps coefficients : 2 bytes F1 (real), 2 bytes F1 (imag) ... 2 bytes Fn (real), 2 bytes Fn (imag) Then reverse taps coefficients : 2 bytes D1 (real), 2 bytes D1 (imag) ... 2 bytes Dm (real), 2 bytes Dm (imag) The equalizers coefficient are considered signed 16 bit integers in the range -32768 (0x8000) to 32767 (0x7FFF). DOCSIS specifications requires up to a maximum of 64 equalizer taps , therefore, this object size can get up 260 bytes (4 + 4x64). The minimum object size (other than zero) for a t-spaced Tab with a minimum of 8 symbols will be 36 (4 + 4x8)" SYNTAX OCTET STRING(SIZE 0|36..260)) alternative b-1) docsIfSigQEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. At the CMTS, this object is not applicable and might return a zero-length OCTET STRING. Note that previous CMTS implementations may instantiate this object in two ways: - An equalization value different of the zero-length octet string to indicate an equalization average for the upstream channel. Those values have vendor dependent interpretation. - Return a zero-length OCTET STRING as described below. A returned zero-length OCTET STRING indicate the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::= { docsIfSignalQualityEntry 7 } --Note: same compliance statements as in draft 13 alternative b-2) docsIfSigQEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. At the CMTS, this object is not applicable and is not instantiated. Note that previous CMTS implementations may instantiate this object in two ways: - An equalization value different of the zero-length octet string to indicate an equalization average for the upstream channel. Those values have vendor dependent interpretation. - Return a zero-length OCTET STRING as described below. A returned zero-length OCTET STRING indicate the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::= { docsIfSignalQualityEntry 7 } -- Changes in compliance statements: docsIfBasicGroupV2 OBJECT-GROUP OBJECTS { docsIfDownChannelId, -- ... snip ... -- delete -- docsIfSigQEqualizationData, --- ...snip ... } STATUS current DESCRIPTION "Group of objects implemented in both cable modems and cable modem termination systems." ::= { docsIfGroups 5 } docsIfCmGroupV2 OBJECT-GROUP OBJECTS { docsIfCmCmtsAddress, -- ... snip ... docsIfCmServiceExtTxSlotsDed, -- Add docsIfSigQEqualizationData --- ...snip ... } STATUS current DESCRIPTION "Group of objects implemented in cable modems." ::= { docsIfGroups 6 } c) docsIfCmtsCmStatusEqualizationData OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..512)) MAX-ACCESS read-only STATUS current DESCRIPTION "Equalization data for this CM as measured by the CMTS. Returns the zero-length OCTET STRING if the value is unknown or if there is no equalization data available or defined." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I07-041210, Figure 8-23." ::= { docsIfCmtsCmStatusEntry 8 } Summary of comments received in a vendor internal discussion Copied for IPCDN participants background ------------------ Hal Roberts - ADC Colleagues, While we are looking at this question we should make sure we end up with precise definitions of the equalization coefficient format for DOCSIS 3.0 for both the CMTS and the CM. Note that DOCSIS 3.0 Enhanced Signal Quality Monitoring goals include: - Pre-Equalization (Already in spec) * Review language to make sure output is standardized for processing. docsIfSigQEqualizationData For the cable modem "the equalization data for the downstream channel" has an unambiguous meaning. So for the cable modem it is the tap format which must be made unambiguous (this should be agreed upon by cable modem and/or cable modem chip manufacturers). With regard to the CMTS, the MIB docsIfSigQEqualizationData is supposed to provide the 'average' equalization data for the upstream channel as seen by the CMTS. This is an ambiguous statement. There is no 'average' equalization data since the equalization coefficients uniquely apply to each upstream path from each CM to the CMTS receiver. These coefficients are complex numbers, so in what way does one average them? If one can define a formula that results in a single real number from each set of coefficients as they come from the CMTS for each CM then one could envision averaging these numbers into something approaching a meaningful assessment of the linear distortions on a given upstream channel. (Tom Kolze has just such a formula and we have found it to be an accurate estimate of the MER of a channel due to distortions alone. Tom may be willing to share this with the working group). Therefore I think that the definition of 'average equalization data for the upstream channel' must be clarified or the CMTS portion of the MIB should be removed. docsIfCmtsCmStatusEqualizationData With regard to the MIB docsIfCmtsCmStatusEqualizationData, when pre-equalization is on there is little or no meaning to the equalization coefficients from the CMTS (even on a per-cable-modem basis rather than per channel). If pre-equalization is working correctly there should be very little residual channel distortion left and the coefficients will no longer have any relationship to the channel characteristics. Possibly the only use for these coefficients when pre-equalization is on, is to actually see if pre-equalization is doing the job. On the other hand, when pre-equalization is turned off, docsIfCmtsCmStatusEqualizationData will accurately reflect distortions on the RF path between the given cable modem and the CMTS receiver. Therefore I think that agreeing on the format of this MIB is what is necessary. One other suggestion, the text "Equalization data for this CM" might be clearer if it stated "Equalization data for this CM, as measured by the CMTS" Hal docsIfSigQEqualizationData OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. At the CMTS, returns the average equalization data for the upstream channel. Returns an empty string if the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::= { docsIfSignalQualityEntry 7 } ------------------------ Andre Lejeune - ATI We report the docsIfSigQEqualizationData for our CM in the following format: F1 (real) 16 bits, F1 (imag) 16 bits F2 (real) 16 bits, F2 (imag) 16 bits ... Fn (real) 16 bits, Fn (imag) 16 bits The number of taps is deduced from the length of the octet string. ------------------------ David Hull - Conexant The DS equalizer has never been specified in terms of its exact implementation. This has been left to the individual silicon vendor; therefore they are all a bit different. Some implementations use T spaced all the way through and (I believe) some implementations may use fractional spacing for the front end (prior to the reference tap). Not all implementations have the same length of DS equalizer or the same center tap position (relative to the overall length) either. If all we want to do is compute the frequency response by a DFT on the tap weights, I don't think it matters what the CT position is but the length and the tap spacing would need to be conveyed if fractional spacing is used. ------------------------ Andre Lejeune - ATI I am sorry I took some time to respond. I clearly needed to discuss this internally before continuing on the subject. The format I sent earlier was for our modem. But now I realize that even our own solution will be changing and the format below won't be appropriate. I agree that more information needs to be carried in this MIB. A solution proposed by Mike Grimwood is to use the format from DOCSIS 1.1, figure 6.23 (without the type and length), which allows for Main Tap Location, Spacing, number of FF and FB taps. Even that may not be sufficient, if I properly understand Dave below, if different fractional spacing is used for the different taps. I'll let Dave explain this further if he thinks it is necessary. The main tap location is not absolutely required, as it generally can be easily derived, but could be useful under certain error conditions: Main Tap Location (1 byte) Number of forward taps per symbol (1 byte) Number of forward taps (1 byte) Number of reverse taps (1 byte) F1 (real) 16 bits, F1 (imag) 16 bits F2 (real) 16 bits, F2 (imag) 16 bits ... Fn (real) 16 bits, Fn (imag) 16 bits D1 (real) 16 bits, D1 (imag) 16 bits D2 (real) 16 bits, D2 (imag) 16 bits ... Dn (real) 16 bits, Dn (imag) 16 bits ------------------------ Hal Roberts - ADC To summarize: 1. Equalization MIBS from the CM - We need well defined MIBs from the CM for both the downstream post-equalizer and the upstream pre-equalizer values. If no uniform format for the downstream taps can be defined due to proprietary implementations, perhaps the vendors can simply provide a 'frequency response or impulse response' as calculated from the equalizer (but in a uniform format). For the upstream taps it should be easy to provide a uniform tap format as it is already mostly defined in the RFI. 2. Equalization MIBS from the CMTS when Pre-equalization is OFF - As mentioned before, an average equalization data from the CMTS on a per upstream channel basis is not defined and could take a number of meanings. Without an unambiguous definition of channel based equalization data, it would be better to remove this part of the definition as it simply leads to mass confusion. Note that equalization MIBs from the CMTS on a per CM basis do have significant value for plant monitoring and debug purposes. These merely need to be defined in format; this format could be the same format as in the pre-equalizer MIB from the CM as they are representing the same plant characteristic. 3. Equalization MIBS from the CMTS when Pre-equalization is ON - These have no significant value other than seeing if pre-equalization is operating properly. When pre-equalization is operating properly then the CMTS should see little or no plant distortion and the equalizer coefficients should be close to all-zeros except for the main tap for all modems. Hal ------------------------ David Hull -Conexant With regard to #1, the definition in Fig 6-22 of the DOCSIS 1.1 spec that Andre referred to seems good enough but I would allow the number of taps per symbol to be defined independently for the forward section AND the reverse section just in case someone implemented the two sections with different tap spacing. Short of officially "specifying" the DS equalizer like we have done for the upstream one, I don't see too much more that could be done. ------------------------ Hal Roberts - ADC Dave, It may be elsewhere in the spec or it may be obvious but I think we need to have more detail, for example the numbers should be represented in a specific numerical format perhaps: "Standard twos-complement format, from -32768 (0x8000) to 32767 (0x7FFF)" as an example. Hal ------------------------ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 13 16:28:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9ge-0004ke-5H; Thu, 13 Oct 2005 16:28:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9gc-0004kW-QL for ipcdn@megatron.ietf.org; Thu, 13 Oct 2005 16:28:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15533 for ; Thu, 13 Oct 2005 16:28:19 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ9rB-0008W2-U5 for ipcdn@ietf.org; Thu, 13 Oct 2005 16:39:19 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j9DKS4c8022882 for ; Thu, 13 Oct 2005 14:28:04 -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: [ipcdn] DRAFT Agenda for the IETF#64 IPCDN meetin in Vancouver Date: Thu, 13 Oct 2005 14:28:04 -0600 Message-ID: Thread-Topic: [ipcdn] DRAFT Agenda for the IETF#64 IPCDN meetin in Vancouver Thread-Index: AcWNOBVZCR63P7O9TZGRiirLXFOlsxC23ziwAACnNrAAB3N3QA== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Folks, Rich and I would like to propose following the same wg meeting format as = last time: no slide deck and general updates, just a working session to = address open issues on active drafts. We have 5 I-Ds left, and are expecting 2 more ID updates before the = meeting (Cable Device mib v10 and MTA MIB v7). Below is a proposed agenda for your review, let us know if you plan to = attend and have any modifications to the agenda. Rich and Jean-Fran=E7ois IPCDN Co-chairs ----------------------------------------------------------------------- IP over Cable Data Network WG (ipcdn) IETF #64 THURSDAY, November 10, 2005, from 1510-1610=20 (Afternoon Session II) =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Chairs: Richard Woundy Jean-Francois Mule =20 AGENDA: =20 I. Agenda Bashing II. Administration =20 III. IPCDN DOCSIS mibs =20 o DOCSIS Cable Device MIB version 2 (ID update pending) draft-ietf-ipcdn-device-mibv2-10.txt Editors: Kevin Marez & Rich Woundy=20 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-10.txt o RF MIB v2 draft-ietf-ipcdn-docs-rfmibv2-13.txt Editor: Eduardo Cardona = http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-13.txt IV. IPCablecom/PacketCable Submissions o MTA MIB draft-ietf-ipcdn-pktc-mtamib-07.txt (ID update pending) = http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-07.txt o Signaling MIB draft-ietf-ipcdn-pktc-signaling-09.txt=20 =20 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-09.tx= t=20 o Management Event MIB draft-ietf-ipcdn-pktc-eventmess-04.txt =20 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-04.tx= t V. Next steps -- Richard Woundy and Jean-Francois Mule, IPCDN co-chairs _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sun Oct 16 19:06:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERHac-0006yi-Jm; Sun, 16 Oct 2005 19:06:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERHab-0006yX-2a for ipcdn@megatron.ietf.org; Sun, 16 Oct 2005 19:06:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01413 for ; Sun, 16 Oct 2005 19:06:41 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERHlo-0000mR-0w for ipcdn@ietf.org; Sun, 16 Oct 2005 19:18:24 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9GN6Qg3005694; Sun, 16 Oct 2005 18:06:27 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Oct 2005 01:06:25 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508568152@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eduardo Cardona , "Ipcdn (E-mail)" , david.raftus@ati.com Subject: RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Date: Mon, 17 Oct 2005 01:06:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9d7e8d783239e9f0c425c823a9c950ff Cc: "Randy Presuhn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Sorry that it took a while to respond. I think the most important 2 things are: - Have a CLEAR description of the MIB objects, so that implementers (both at the agent and at the manager side) know what to do and/or what to expect. The discussion below is clearly helping to go for a solution in that direction. - From a MIB doctor perspective, your proposals look OK. It is important though to have those vendors that have been providing input DO take a look at your proposed changes and agree as to what the best solution is and to make sure that that is what they have (or plan to) implement(ed). One thing I wondered. Is the max length not 4+8*64 instead of 4+4*64? If not, then I do not understand the DESCRIPTION clause of the TC. Bert > -----Original Message----- > From: ipcdn-bounces@ietf.org > [mailto:ipcdn-bounces@ietf.org]On Behalf Of > Eduardo Cardona > Sent: Tuesday, October 11, 2005 13:59 > To: Eduardo Cardona; Ipcdn (E-mail); Wijnen, Bert (Bert); > david.raftus@ati.com > Subject: RE: [ipcdn] RE: AD > re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: > docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData > > > Does anyone get the chance to review the proposed clarifications ? > > Please reply with comments by the end of the week > > Thanks > > Eduardo > > > > -----Original Message----- > From: Eduardo Cardona > Sent: Monday, October 03, 2005 3:35 PM > To: Ipcdn (E-mail); Wijnen, Bert (Bert); david.raftus@ati.com > Subject: RE: [ipcdn] RE: AD > re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: > docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData > > Hi IPCDN participants, > > Here is an update on one of the pending items from Bert's review: > After consultations with DOCSIS vendors, I am proposing the > clarifications required to define the size constraints for > docsIfCmtsCmStatusEqualizationData and docsIfSigQEqualizationData > > Please review the details and send your comments. > > You will find in this email a summary of the proposed changes > as well as > a log of comments provided by vendors to place the discussion in the > context of the IPCDN participants. > > > Please comment on the proposals and make the appropriate comments > Item a) > Item c) > Item d) > Comments and pick an alternative from > b-1) > and > b-2) > > > > ---- > > CM/CMTS Equalizer Data: > > > Summary: > docsIfSigQEqualizationData and > docsIfCmtsCmStatusEqualizationData have > OCTET STRING with no constraints in the object size (RFC > 2669), in fact > the format of the pre-equalizers was never normalized and left vendor > specific > In draft 06 of RFIv2.0 It was added a size constraint of 512 > octets but > no special reason was defined: > Some basic Math will indicate that up to 64 taps ( RFI > requirements) and > 4 bytes per tap will indicate 256 bytes, still uncertain why 512 was > selected. > > Even though the selection of 256 (or 512) does not seem to be accurate > number considering some possible byte controls to indicate: > - Taps could be T, T/2 or T/4 spaced. > - Forward Taps and Reverse Taps could have different numbers > - Not required by the spec : Reverse Taps (DS equalizers) > could be also > T, T/2 and T/4 spaced > - Any need to indicate main tap position ( or the highest value is > enough indication of that > > The discussions held with RF experts identified the following > management > requirements : > > 1) CM DS post-equalization have been defined in > docsIfSigQEqualizationData > > 2) CM Upstream pre-equalizer ( not to be defined in this > version of the > MIB) something to reflect the CMTS RNG-RSP equalizer value > > CMTS equalization Data: > 3) Equalization in the Upstream has relative importance for CMTS CM > path, docsIfCmtsCmStatusEqualizationData > Meanings: > When Pre-eq is off, the value will indicate the CM-CMTS path RF > distortions. > When re-eq is on, the value indicates how well pre-equalization is > working as the value of all should be close to zero with the exception > of the main tap > > 4) The equalization data per US interface defined as an > average value in > docsIfSigQEqualizationData > This concept is confusing since there is no in the RFI spec a > methodology to calculate that average. > It could include : > - CMs with different configuration: pre-eq on|off, > - Different number of Taps per CM, > - Tap spacing per CM > The average formula should've being > The recommendation is to remove that requirement > > > Proposed resolution: > a) > Use the same format as in the CM equalization data for 1) and 3) for > CM docsIfSigQEqualizationData and docsIfCmtsCmStatusEqualizationData > > b) > remove the CMTS requirement for docsIfSigQEqualizationData > - Future spec efforts will work to define more meaningful values for > CMTS US that could lead to objects that defines MER measurements prior > and after channel signal compensation or mitigation by the CMTS > > c) Description of docsIfCmtsCmStatusEqualizationData > > d) > CM upstream pre-equalizer Perhaps in further revisions of the DOCSIS > specification and RFI MIB updates > > > Proposal details : > > a) > > -- Add a new textual Convention > DocsEqualizerData ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "This data type represents the equalizer data > as measured at the receiver interface. > The format of the equalizer follows a similar structure > Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI > v1.1 specification with slight modifications as > follows : > 1 byte Number of forward taps per symbol > 1 byte Number of reverse taps per symbol > 1 byte Number of forward taps > 1 byte Number of reverse taps > > Following are the equalizer coefficients: > First forward taps coefficients : > 2 bytes F1 (real), 2 bytes F1 (imag) > ... > 2 bytes Fn (real), 2 bytes Fn (imag) > > Then reverse taps coefficients : > 2 bytes D1 (real), 2 bytes D1 (imag) > ... > 2 bytes Dm (real), 2 bytes Dm (imag) > > The equalizers coefficient are considered signed 16 bit > integers in the range -32768 (0x8000) to 32767 (0x7FFF). > > DOCSIS specifications requires up to a maximum of > 64 equalizer taps , therefore, this object size can get up > 260 bytes (4 + 4x64). > The minimum object size (other than zero) for a t-spaced Tab > with a minimum of 8 symbols will be 36 (4 + 4x8)" > SYNTAX OCTET STRING(SIZE 0|36..260)) > > > alternative b-1) > > docsIfSigQEqualizationData OBJECT-TYPE > SYNTAX DocsEqualizerData > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "At the CM, returns the equalization data for the > downstream > channel. > > At the CMTS, this object is not applicable and > might return > > a zero-length OCTET STRING. Note that previous CMTS > implementations may instantiate this object in two ways: > - An equalization value different of the zero-length > octet string to indicate an equalization average for > the upstream channel. Those values have vendor > dependent interpretation. > - Return a zero-length OCTET STRING as described below. > > A returned zero-length OCTET STRING indicate the value > is unknown or if there is no equalization data available > or defined." > REFERENCE > "DOCSIS Radio Frequency Interface Specification, > Figure 6-23." > ::= { docsIfSignalQualityEntry 7 } > > --Note: same compliance statements as in draft 13 > > > alternative b-2) > > docsIfSigQEqualizationData OBJECT-TYPE > SYNTAX DocsEqualizerData > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "At the CM, returns the equalization data for the > downstream > channel. > > At the CMTS, this object is not applicable and is not > instantiated. Note that previous CMTS implementations > may instantiate this object in two ways: > - An equalization value different of the zero-length > octet string to indicate an equalization average for > the upstream channel. Those values have vendor > dependent interpretation. > - Return a zero-length OCTET STRING as described below. > > A returned zero-length OCTET STRING indicate the value > is unknown or if there is no equalization data available > or defined." > REFERENCE > "DOCSIS Radio Frequency Interface Specification, > Figure 6-23." > ::= { docsIfSignalQualityEntry 7 } > > -- Changes in compliance statements: > docsIfBasicGroupV2 OBJECT-GROUP > OBJECTS { > docsIfDownChannelId, > -- ... snip ... > -- delete > -- docsIfSigQEqualizationData, > --- ...snip ... > } > STATUS current > DESCRIPTION > "Group of objects implemented in both cable modems and > cable modem termination systems." > ::= { docsIfGroups 5 } > > > docsIfCmGroupV2 OBJECT-GROUP > OBJECTS { > docsIfCmCmtsAddress, > -- ... snip ... > docsIfCmServiceExtTxSlotsDed, > -- Add > docsIfSigQEqualizationData > --- ...snip ... > } > STATUS current > DESCRIPTION > "Group of objects implemented in cable modems." > ::= { docsIfGroups 6 } > > c) > docsIfCmtsCmStatusEqualizationData OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (0..512)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Equalization data for this CM as measured by the CMTS. > Returns the zero-length OCTET STRING if the value is > unknown or if there is no equalization data available > or defined." > REFERENCE > "Data-Over-Cable Service Interface Specifications: Radio > Frequency Interface Specification SP-RFIv2.0-I07-041210, > Figure 8-23." > ::= { docsIfCmtsCmStatusEntry 8 } > > > > > Summary of comments received in a vendor internal discussion > Copied for IPCDN participants background > > ------------------ > Hal Roberts - ADC > > Colleagues, > > While we are looking at this question we should make sure we > end up with > precise definitions of the equalization coefficient format for DOCSIS > 3.0 for both the CMTS and the CM. Note that DOCSIS 3.0 Enhanced Signal > Quality Monitoring goals include: > > - Pre-Equalization (Already in spec) > * Review language to make sure output is standardized for > processing. > > docsIfSigQEqualizationData > For the cable modem "the equalization data for the downstream channel" > has an unambiguous meaning. So for the cable modem it is the > tap format > which must be made unambiguous (this should be agreed upon by cable > modem and/or cable modem chip manufacturers). > With regard to the CMTS, the MIB docsIfSigQEqualizationData > is supposed > to provide the 'average' equalization data for the upstream channel as > seen by the CMTS. This is an ambiguous statement. There is no > 'average' > equalization data since the equalization coefficients > uniquely apply to > each upstream path from each CM to the CMTS receiver. These > coefficients > are complex numbers, so in what way does one average them? If one can > define a formula that results in a single real number from each set of > coefficients as they come from the CMTS for each CM then one could > envision averaging these numbers into something approaching a > meaningful > assessment of the linear distortions on a given upstream channel. (Tom > Kolze has just such a formula and we have found it to be an accurate > estimate of the MER of a channel due to distortions alone. Tom may be > willing to share this with the working group). > > Therefore I think that the definition of 'average > equalization data for > the upstream channel' must be clarified or the CMTS portion of the MIB > should be removed. > > docsIfCmtsCmStatusEqualizationData > With regard to the MIB docsIfCmtsCmStatusEqualizationData, when > pre-equalization is on there is little or no meaning to the > equalization > coefficients from the CMTS (even on a per-cable-modem basis > rather than > per channel). If pre-equalization is working correctly there should be > very little residual channel distortion left and the coefficients will > no longer have any relationship to the channel > characteristics. Possibly > the only use for these coefficients when pre-equalization is on, is to > actually see if pre-equalization is doing the job. > > On the other hand, when pre-equalization is turned off, > docsIfCmtsCmStatusEqualizationData will accurately reflect distortions > on the RF path between the given cable modem and the CMTS receiver. > > Therefore I think that agreeing on the format of this MIB is what is > necessary. One other suggestion, the text "Equalization data for this > CM" might be clearer if it stated "Equalization data for this CM, as > measured by the CMTS" > > Hal > > > docsIfSigQEqualizationData OBJECT-TYPE > SYNTAX OCTET STRING > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "At the CM, returns the equalization data for the > downstream > channel. At the CMTS, returns the average equalization > data for the upstream channel. Returns an empty string > if the value is unknown or if there is no equalization > data available or defined." > REFERENCE > "DOCSIS Radio Frequency Interface Specification, > Figure 6-23." > ::= { docsIfSignalQualityEntry 7 } > > ------------------------ > > Andre Lejeune - ATI > > We report the docsIfSigQEqualizationData for our CM in the following > format: > > F1 (real) 16 bits, F1 (imag) 16 bits > F2 (real) 16 bits, F2 (imag) 16 bits > ... > Fn (real) 16 bits, Fn (imag) 16 bits > > The number of taps is deduced from the length of the octet string. > > > ------------------------ > > David Hull - Conexant > > The DS equalizer has never been specified in terms of its exact > implementation. This has been left to the individual silicon vendor; > therefore they are all a bit different. Some implementations use T > spaced all the way through and (I believe) some > implementations may use > fractional spacing for the front end (prior to the reference > tap). Not > all implementations have the same length of DS equalizer or the same > center tap position (relative to the overall length) either. > If all we > want to do is compute the frequency response by a DFT on the tap > weights, I don't think it matters what the CT position is but > the length > and the tap spacing would need to be conveyed if fractional spacing is > used. > > ------------------------ > > Andre Lejeune - ATI > > > I am sorry I took some time to respond. I clearly needed to > discuss this > internally before continuing on the subject. > > The format I sent earlier was for our modem. But now I > realize that even > our own solution will be changing and the format below won't be > appropriate. I agree that more information needs to be carried in this > MIB. A solution proposed by Mike Grimwood is to use the format from > DOCSIS 1.1, figure 6.23 (without the type and length), which > allows for > Main Tap Location, Spacing, number of FF and FB taps. Even > that may not > be sufficient, if I properly understand Dave below, if different > fractional spacing is used for the different taps. I'll let > Dave explain > this further if he thinks it is necessary. The main tap > location is not > absolutely required, as it generally can be easily derived, > but could be > useful under certain error conditions: > > Main Tap Location (1 byte) > Number of forward taps per symbol (1 byte) > Number of forward taps (1 byte) > Number of reverse taps (1 byte) > F1 (real) 16 bits, F1 (imag) 16 bits > F2 (real) 16 bits, F2 (imag) 16 bits > ... > Fn (real) 16 bits, Fn (imag) 16 bits > > D1 (real) 16 bits, D1 (imag) 16 bits > D2 (real) 16 bits, D2 (imag) 16 bits > ... > Dn (real) 16 bits, Dn (imag) 16 bits > > ------------------------ > Hal Roberts - ADC > > To summarize: > 1. Equalization MIBS from the CM - We need well defined MIBs from > the CM for both the downstream post-equalizer and the upstream > pre-equalizer values. If no uniform format for the downstream taps can > be defined due to proprietary implementations, perhaps the vendors can > simply provide a 'frequency response or impulse response' as > calculated > from the equalizer (but in a uniform format). For the upstream taps it > should be easy to provide a uniform tap format as it is already mostly > defined in the RFI. > 2. Equalization MIBS from the CMTS when Pre-equalization is OFF - > As mentioned before, an average equalization data from the > CMTS on a per > upstream channel basis is not defined and could take a number of > meanings. Without an unambiguous definition of channel based > equalization data, it would be better to remove this part of the > definition as it simply leads to mass confusion. Note that > equalization > MIBs from the CMTS on a per CM basis do have significant > value for plant > monitoring and debug purposes. These merely need to be defined in > format; this format could be the same format as in the > pre-equalizer MIB > from the CM as they are representing the same plant characteristic. > 3. Equalization MIBS from the CMTS when Pre-equalization is ON - > These have no significant value other than seeing if > pre-equalization is > operating properly. When pre-equalization is operating > properly then the > CMTS should see little or no plant distortion and the equalizer > coefficients should be close to all-zeros except for the main tap for > all modems. > Hal > > ------------------------ > David Hull -Conexant > > With regard to #1, the definition in Fig 6-22 of the DOCSIS 1.1 spec > that Andre referred to seems good enough but I would allow > the number of > taps per symbol to be defined independently for the forward > section AND > the reverse section just in case someone implemented the two sections > with different tap spacing. Short of officially "specifying" the DS > equalizer like we have done for the upstream one, I don't see too much > more that could be done. > > ------------------------ > Hal Roberts - ADC > > Dave, > > It may be elsewhere in the spec or it may be obvious but I > think we need > to have more detail, for example the numbers should be > represented in a > specific numerical format perhaps: > > "Standard twos-complement format, from -32768 (0x8000) to 32767 > (0x7FFF)" > > as an example. > > Hal > > ------------------------ > > > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Oct 17 08:54:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERUVE-0007IG-Gq; Mon, 17 Oct 2005 08:54:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERUVD-0007IA-7I for ipcdn@megatron.ietf.org; Mon, 17 Oct 2005 08:54:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10245 for ; Mon, 17 Oct 2005 08:54:00 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERUgW-00051u-Uc for ipcdn@ietf.org; Mon, 17 Oct 2005 09:05:49 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j9HCrjWV012136; Mon, 17 Oct 2005 06:53:46 -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: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Date: Mon, 17 Oct 2005 06:53:45 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F01178DC0@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Thread-Index: AcXSpkfcP9orw9nlRryqOxKO4x5RXgAcdmiw From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: ba231eeb0ba293f319cac22693e776bc Content-Transfer-Encoding: quoted-printable Cc: "Randy Presuhn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Thanks Bert for the review I am also expecting validation from vendor at the least this week so I can publish D-14 by the end of the week=20 To your question : 4+4*64 or 4+8*64 The total number of taps ( forward and reverse ) are up to 64=20 Your interpretation of 8*64 seems to indicate to me you are assuming: Forward taps =3D Reverse Taps (Always) and up to 64 taps To make that clear, few text suggestions to the TEXTUAL-CONVENTION are below =20 ... 1 byte Number of forward taps: n 1 byte Number of reverse taps: m ... DOCSIS specifications requires up to a maximum of=20 64 equalizer taps (n + m); therefore, this object size=20 can get up 260 bytes (4 + 4x64). =20 Thanks Eduardo -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Sunday, October 16, 2005 5:06 PM To: Eduardo Cardona; Ipcdn (E-mail); david.raftus@ati.com Cc: Randy Presuhn (E-mail) Subject: RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Sorry that it took a while to respond. I think the most important 2 things are: - Have a CLEAR description of the MIB objects, so that implementers (both at the agent and at the manager side) know what to do and/or what to expect. The discussion below is clearly helping to go for a solution in that direction. - From a MIB doctor perspective, your proposals look OK. It is=20 important though to have those vendors that have been providing input DO take a look at your proposed changes and agree as to what the best solution is and to make sure that that is what they have (or plan to) implement(ed). One thing I wondered. Is the max length not 4+8*64 instead of 4+4*64? If not, then I do not understand the DESCRIPTION clause of the TC. Bert > -----Original Message----- > From: ipcdn-bounces@ietf.org=20 > [mailto:ipcdn-bounces@ietf.org]On Behalf Of > Eduardo Cardona > Sent: Tuesday, October 11, 2005 13:59 > To: Eduardo Cardona; Ipcdn (E-mail); Wijnen, Bert (Bert); > david.raftus@ati.com > Subject: RE: [ipcdn] RE: AD > re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: > docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData >=20 >=20 > Does anyone get the chance to review the proposed clarifications ?=20 >=20 > Please reply with comments by the end of the week=20 >=20 > Thanks >=20 > Eduardo >=20 >=20 >=20 > -----Original Message----- > From: Eduardo Cardona=20 > Sent: Monday, October 03, 2005 3:35 PM > To: Ipcdn (E-mail); Wijnen, Bert (Bert); david.raftus@ati.com > Subject: RE: [ipcdn] RE: AD > re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: > docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData >=20 > Hi IPCDN participants, >=20 > Here is an update on one of the pending items from Bert's review: > After consultations with DOCSIS vendors, I am proposing the > clarifications required to define the size constraints for > docsIfCmtsCmStatusEqualizationData and docsIfSigQEqualizationData >=20 > Please review the details and send your comments. >=20 > You will find in this email a summary of the proposed changes=20 > as well as > a log of comments provided by vendors to place the discussion in the > context of the IPCDN participants.=20 >=20 >=20 > Please comment on the proposals and make the appropriate comments=20 > Item a) > Item c) > Item d) > Comments and pick an alternative from > b-1)=20 > and=20 > b-2) >=20 >=20 >=20 > ---- =20 >=20 > CM/CMTS Equalizer Data:=20 >=20 >=20 > Summary: > docsIfSigQEqualizationData and =20 > docsIfCmtsCmStatusEqualizationData have > OCTET STRING with no constraints in the object size (RFC=20 > 2669), in fact > the format of the pre-equalizers was never normalized and left vendor > specific > In draft 06 of RFIv2.0 It was added a size constraint of 512=20 > octets but > no special reason was defined: > Some basic Math will indicate that up to 64 taps ( RFI=20 > requirements) and > 4 bytes per tap will indicate 256 bytes, still uncertain why 512 was > selected. >=20 > Even though the selection of 256 (or 512) does not seem to be accurate > number considering some possible byte controls to indicate: > - Taps could be T, T/2 or T/4 spaced.=20 > - Forward Taps and Reverse Taps could have different numbers > - Not required by the spec : Reverse Taps (DS equalizers)=20 > could be also > T, T/2 and T/4 spaced > - Any need to indicate main tap position ( or the highest value is > enough indication of that=20 >=20 > The discussions held with RF experts identified the following=20 > management > requirements :=20 > =20 > 1) CM DS post-equalization have been defined in > docsIfSigQEqualizationData=20 >=20 > 2) CM Upstream pre-equalizer ( not to be defined in this=20 > version of the > MIB) something to reflect the CMTS RNG-RSP equalizer value=20 >=20 > CMTS equalization Data: > 3) Equalization in the Upstream has relative importance for CMTS CM > path, docsIfCmtsCmStatusEqualizationData > Meanings: > When Pre-eq is off, the value will indicate the CM-CMTS path RF > distortions.=20 > When re-eq is on, the value indicates how well pre-equalization is > working as the value of all should be close to zero with the exception > of the main tap >=20 > 4) The equalization data per US interface defined as an=20 > average value in > docsIfSigQEqualizationData=20 > This concept is confusing since there is no in the RFI spec a > methodology to calculate that average.=20 > It could include :=20 > - CMs with different configuration: pre-eq on|off,=20 > - Different number of Taps per CM,=20 > - Tap spacing per CM > The average formula should've being=20 > The recommendation is to remove that requirement >=20 >=20 > Proposed resolution: > a)=20 > Use the same format as in the CM equalization data for 1) and 3) for=20 > CM docsIfSigQEqualizationData and docsIfCmtsCmStatusEqualizationData >=20 > b)=20 > remove the CMTS requirement for docsIfSigQEqualizationData > - Future spec efforts will work to define more meaningful values for > CMTS US that could lead to objects that defines MER measurements prior > and after channel signal compensation or mitigation by the CMTS >=20 > c) Description of docsIfCmtsCmStatusEqualizationData >=20 > d) > CM upstream pre-equalizer Perhaps in further revisions of the DOCSIS > specification and RFI MIB updates > =20 >=20 > Proposal details : >=20 > a)=20 >=20 > -- Add a new textual Convention > DocsEqualizerData ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "This data type represents the equalizer data > as measured at the receiver interface. > The format of the equalizer follows a similar structure > Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI=20 > v1.1 specification with slight modifications as > follows : > 1 byte Number of forward taps per symbol > 1 byte Number of reverse taps per symbol > 1 byte Number of forward taps: n > 1 byte Number of reverse taps: m > =20 > Following are the equalizer coefficients: > First forward taps coefficients : > 2 bytes F1 (real), 2 bytes F1 (imag) > ... > 2 bytes Fn (real), 2 bytes Fn (imag) > =20 > Then reverse taps coefficients : > 2 bytes D1 (real), 2 bytes D1 (imag) > ... > 2 bytes Dm (real), 2 bytes Dm (imag) >=20 > The equalizers coefficient are considered signed 16 bit > integers in the range -32768 (0x8000) to 32767 (0x7FFF). > =20 > DOCSIS specifications requires up to a maximum of=20 > 64 equalizer taps (N + M), therefore, this object size=20 can get up 260 bytes (4 + 4x64). > The minimum object size (other than zero) for a t-spaced Tab > with a minimum of 8 symbols will be 36 (4 + 4x8)" > SYNTAX OCTET STRING(SIZE 0|36..260)) >=20 >=20 > alternative b-1)=20 >=20 > docsIfSigQEqualizationData OBJECT-TYPE > SYNTAX DocsEqualizerData > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "At the CM, returns the equalization data for the=20 > downstream > channel. > =20 > At the CMTS, this object is not applicable and=20 > might return >=20 > a zero-length OCTET STRING. Note that previous CMTS=20 > implementations may instantiate this object in two ways: > - An equalization value different of the zero-length > octet string to indicate an equalization average for > the upstream channel. Those values have vendor=20 > dependent interpretation. > - Return a zero-length OCTET STRING as described below. > =20 > A returned zero-length OCTET STRING indicate the value > is unknown or if there is no equalization data available > or defined." > REFERENCE > "DOCSIS Radio Frequency Interface Specification, > Figure 6-23." > ::=3D { docsIfSignalQualityEntry 7 } >=20 > --Note: same compliance statements as in draft 13 >=20 >=20 > alternative b-2)=20 >=20 > docsIfSigQEqualizationData OBJECT-TYPE > SYNTAX DocsEqualizerData > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "At the CM, returns the equalization data for the=20 > downstream > channel. > =20 > At the CMTS, this object is not applicable and is not=20 > instantiated. Note that previous CMTS implementations=20 > may instantiate this object in two ways: > - An equalization value different of the zero-length > octet string to indicate an equalization average for > the upstream channel. Those values have vendor=20 > dependent interpretation. > - Return a zero-length OCTET STRING as described below. > =20 > A returned zero-length OCTET STRING indicate the value > is unknown or if there is no equalization data available > or defined." > REFERENCE > "DOCSIS Radio Frequency Interface Specification, > Figure 6-23." > ::=3D { docsIfSignalQualityEntry 7 } >=20 > -- Changes in compliance statements:=20 > docsIfBasicGroupV2 OBJECT-GROUP > OBJECTS { > docsIfDownChannelId, > -- ... snip ... > -- delete > -- docsIfSigQEqualizationData, > --- ...snip ... > } > STATUS current > DESCRIPTION > "Group of objects implemented in both cable modems and > cable modem termination systems." > ::=3D { docsIfGroups 5 } >=20 >=20 > docsIfCmGroupV2 OBJECT-GROUP > OBJECTS { > docsIfCmCmtsAddress, > -- ... snip ... > docsIfCmServiceExtTxSlotsDed, > -- Add > docsIfSigQEqualizationData > --- ...snip ... > } > STATUS current > DESCRIPTION > "Group of objects implemented in cable modems." > ::=3D { docsIfGroups 6 } >=20 > c) > docsIfCmtsCmStatusEqualizationData OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (0..512)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Equalization data for this CM as measured by the CMTS. > Returns the zero-length OCTET STRING if the value is=20 > unknown or if there is no equalization data available > or defined." > REFERENCE > "Data-Over-Cable Service Interface Specifications: Radio > Frequency Interface Specification SP-RFIv2.0-I07-041210, > Figure 8-23." > ::=3D { docsIfCmtsCmStatusEntry 8 } >=20 >=20 >=20 >=20 > Summary of comments received in a vendor internal discussion > Copied for IPCDN participants background=20 >=20 > ------------------ =20 > Hal Roberts - ADC >=20 > Colleagues, > =20 > While we are looking at this question we should make sure we=20 > end up with > precise definitions of the equalization coefficient format for DOCSIS > 3.0 for both the CMTS and the CM. Note that DOCSIS 3.0 Enhanced Signal > Quality Monitoring goals include: > =20 > - Pre-Equalization (Already in spec)=20 > * Review language to make sure output is standardized for > processing.=20 > =20 > docsIfSigQEqualizationData > For the cable modem "the equalization data for the downstream channel" > has an unambiguous meaning. So for the cable modem it is the=20 > tap format > which must be made unambiguous (this should be agreed upon by cable > modem and/or cable modem chip manufacturers). > With regard to the CMTS, the MIB docsIfSigQEqualizationData=20 > is supposed > to provide the 'average' equalization data for the upstream channel as > seen by the CMTS. This is an ambiguous statement. There is no=20 > 'average' > equalization data since the equalization coefficients=20 > uniquely apply to > each upstream path from each CM to the CMTS receiver. These=20 > coefficients > are complex numbers, so in what way does one average them? If one can > define a formula that results in a single real number from each set of > coefficients as they come from the CMTS for each CM then one could > envision averaging these numbers into something approaching a=20 > meaningful > assessment of the linear distortions on a given upstream channel. (Tom > Kolze has just such a formula and we have found it to be an accurate > estimate of the MER of a channel due to distortions alone. Tom may be > willing to share this with the working group). > =20 > Therefore I think that the definition of 'average=20 > equalization data for > the upstream channel' must be clarified or the CMTS portion of the MIB > should be removed. > =20 > docsIfCmtsCmStatusEqualizationData > With regard to the MIB docsIfCmtsCmStatusEqualizationData, when > pre-equalization is on there is little or no meaning to the=20 > equalization > coefficients from the CMTS (even on a per-cable-modem basis=20 > rather than > per channel). If pre-equalization is working correctly there should be > very little residual channel distortion left and the coefficients will > no longer have any relationship to the channel=20 > characteristics. Possibly > the only use for these coefficients when pre-equalization is on, is to > actually see if pre-equalization is doing the job. > =20 > On the other hand, when pre-equalization is turned off, > docsIfCmtsCmStatusEqualizationData will accurately reflect distortions > on the RF path between the given cable modem and the CMTS receiver. > =20 > Therefore I think that agreeing on the format of this MIB is what is > necessary. One other suggestion, the text "Equalization data for this > CM" might be clearer if it stated "Equalization data for this CM, as > measured by the CMTS" > =20 > Hal > =20 > =20 > docsIfSigQEqualizationData OBJECT-TYPE > SYNTAX OCTET STRING > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "At the CM, returns the equalization data for the=20 > downstream > channel. At the CMTS, returns the average equalization > data for the upstream channel. Returns an empty string > if the value is unknown or if there is no equalization > data available or defined." > REFERENCE > "DOCSIS Radio Frequency Interface Specification, > Figure 6-23." > ::=3D { docsIfSignalQualityEntry 7 } > =20 > ------------------------ =20 >=20 > Andre Lejeune - ATI >=20 > We report the docsIfSigQEqualizationData for our CM in the following > format: > =20 > F1 (real) 16 bits, F1 (imag) 16 bits > F2 (real) 16 bits, F2 (imag) 16 bits > ... > Fn (real) 16 bits, Fn (imag) 16 bits > =20 > The number of taps is deduced from the length of the octet string. >=20 >=20 > ------------------------ =20 >=20 > David Hull - Conexant=20 >=20 > The DS equalizer has never been specified in terms of its exact > implementation. This has been left to the individual silicon vendor; > therefore they are all a bit different. Some implementations use T > spaced all the way through and (I believe) some=20 > implementations may use > fractional spacing for the front end (prior to the reference=20 > tap). Not > all implementations have the same length of DS equalizer or the same > center tap position (relative to the overall length) either. =20 > If all we > want to do is compute the frequency response by a DFT on the tap > weights, I don't think it matters what the CT position is but=20 > the length > and the tap spacing would need to be conveyed if fractional spacing is > used. >=20 > ------------------------ =20 >=20 > Andre Lejeune - ATI >=20 >=20 > I am sorry I took some time to respond. I clearly needed to=20 > discuss this > internally before continuing on the subject. > =20 > The format I sent earlier was for our modem. But now I=20 > realize that even > our own solution will be changing and the format below won't be > appropriate. I agree that more information needs to be carried in this > MIB. A solution proposed by Mike Grimwood is to use the format from > DOCSIS 1.1, figure 6.23 (without the type and length), which=20 > allows for > Main Tap Location, Spacing, number of FF and FB taps. Even=20 > that may not > be sufficient, if I properly understand Dave below, if different > fractional spacing is used for the different taps. I'll let=20 > Dave explain > this further if he thinks it is necessary. The main tap=20 > location is not > absolutely required, as it generally can be easily derived,=20 > but could be > useful under certain error conditions: > =20 > Main Tap Location (1 byte) > Number of forward taps per symbol (1 byte) > Number of forward taps (1 byte) > Number of reverse taps (1 byte) > F1 (real) 16 bits, F1 (imag) 16 bits > F2 (real) 16 bits, F2 (imag) 16 bits > ... > Fn (real) 16 bits, Fn (imag) 16 bits >=20 > D1 (real) 16 bits, D1 (imag) 16 bits > D2 (real) 16 bits, D2 (imag) 16 bits > ... > Dn (real) 16 bits, Dn (imag) 16 bits > =20 > ------------------------ =20 > Hal Roberts - ADC=20 >=20 > To summarize: > 1. Equalization MIBS from the CM - We need well defined MIBs from > the CM for both the downstream post-equalizer and the upstream > pre-equalizer values. If no uniform format for the downstream taps can > be defined due to proprietary implementations, perhaps the vendors can > simply provide a 'frequency response or impulse response' as=20 > calculated > from the equalizer (but in a uniform format). For the upstream taps it > should be easy to provide a uniform tap format as it is already mostly > defined in the RFI. > 2. Equalization MIBS from the CMTS when Pre-equalization is OFF - > As mentioned before, an average equalization data from the=20 > CMTS on a per > upstream channel basis is not defined and could take a number of > meanings. Without an unambiguous definition of channel based > equalization data, it would be better to remove this part of the > definition as it simply leads to mass confusion. Note that=20 > equalization > MIBs from the CMTS on a per CM basis do have significant=20 > value for plant > monitoring and debug purposes. These merely need to be defined in > format; this format could be the same format as in the=20 > pre-equalizer MIB > from the CM as they are representing the same plant characteristic. > 3. Equalization MIBS from the CMTS when Pre-equalization is ON - > These have no significant value other than seeing if=20 > pre-equalization is > operating properly. When pre-equalization is operating=20 > properly then the > CMTS should see little or no plant distortion and the equalizer > coefficients should be close to all-zeros except for the main tap for > all modems. > Hal >=20 > ------------------------ =20 > David Hull -Conexant=20 >=20 > With regard to #1, the definition in Fig 6-22 of the DOCSIS 1.1 spec > that Andre referred to seems good enough but I would allow=20 > the number of > taps per symbol to be defined independently for the forward=20 > section AND > the reverse section just in case someone implemented the two sections > with different tap spacing. Short of officially "specifying" the DS > equalizer like we have done for the upstream one, I don't see too much > more that could be done. >=20 > ------------------------ =20 > Hal Roberts - ADC=20 >=20 > Dave, > =20 > It may be elsewhere in the spec or it may be obvious but I=20 > think we need > to have more detail, for example the numbers should be=20 > represented in a > specific numerical format perhaps: > =20 > "Standard twos-complement format, from -32768 (0x8000) to 32767 > (0x7FFF)" > =20 > as an example. > =20 > Hal >=20 > ------------------------ =20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Oct 17 10:32:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERW2P-0006KY-NP; Mon, 17 Oct 2005 10:32:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERW2L-0006EY-JU for ipcdn@megatron.ietf.org; Mon, 17 Oct 2005 10:32:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15664 for ; Mon, 17 Oct 2005 10:32:18 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERWDg-0007tH-LS for ipcdn@ietf.org; Mon, 17 Oct 2005 10:44:09 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9HEWAUH014580; Mon, 17 Oct 2005 09:32:11 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Oct 2005 16:32:10 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508568432@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eduardo Cardona , "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" , david.raftus@ati.com Subject: RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Date: Mon, 17 Oct 2005 16:32:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: dabfd8cc2c196ec56401c44f64d155c2 Cc: "Randy Presuhn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Thanks, that would make it clearer I think. Bert > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: Monday, October 17, 2005 08:54 > To: Wijnen, Bert (Bert); Ipcdn (E-mail); david.raftus@ati.com > Cc: Randy Presuhn (E-mail) > Subject: RE: [ipcdn] RE: AD > re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: > docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData > > > Thanks Bert for the review > > I am also expecting validation from vendor at the least this week so I > can publish D-14 by the end of the week > > To your question : > 4+4*64 or 4+8*64 > The total number of taps ( forward and reverse ) are up to 64 > > Your interpretation of 8*64 seems to indicate to me you are assuming: > Forward taps = Reverse Taps (Always) and up to 64 taps > > To make that clear, few text suggestions to the TEXTUAL-CONVENTION are > below > ... > 1 byte Number of forward taps: n > 1 byte Number of reverse taps: m > ... > DOCSIS specifications requires up to a maximum of > 64 equalizer taps (n + m); therefore, this object size > can get up 260 bytes (4 + 4x64). > > > Thanks > > Eduardo > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Sunday, October 16, 2005 5:06 PM > To: Eduardo Cardona; Ipcdn (E-mail); david.raftus@ati.com > Cc: Randy Presuhn (E-mail) > Subject: RE: [ipcdn] RE: AD > re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: > docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData > > Sorry that it took a while to respond. > > I think the most important 2 things are: > - Have a CLEAR description of the MIB objects, so that implementers > (both at the agent and at the manager side) know what to do and/or > what to expect. The discussion below is clearly helping to go > for a solution in that direction. > - From a MIB doctor perspective, your proposals look OK. It is > important though to have those vendors that have been providing > input DO take a look at your proposed changes and agree as to > what the best solution is and to make sure that that is what > they have (or plan to) implement(ed). > > One thing I wondered. Is the max length not 4+8*64 instead of 4+4*64? > If not, then I do not understand the DESCRIPTION clause of the TC. > > Bert > > > -----Original Message----- > > From: ipcdn-bounces@ietf.org > > [mailto:ipcdn-bounces@ietf.org]On Behalf Of > > Eduardo Cardona > > Sent: Tuesday, October 11, 2005 13:59 > > To: Eduardo Cardona; Ipcdn (E-mail); Wijnen, Bert (Bert); > > david.raftus@ati.com > > Subject: RE: [ipcdn] RE: AD > > re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: > > docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData > > > > > > Does anyone get the chance to review the proposed clarifications ? > > > > Please reply with comments by the end of the week > > > > Thanks > > > > Eduardo > > > > > > > > -----Original Message----- > > From: Eduardo Cardona > > Sent: Monday, October 03, 2005 3:35 PM > > To: Ipcdn (E-mail); Wijnen, Bert (Bert); david.raftus@ati.com > > Subject: RE: [ipcdn] RE: AD > > re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: > > docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData > > > > Hi IPCDN participants, > > > > Here is an update on one of the pending items from Bert's review: > > After consultations with DOCSIS vendors, I am proposing the > > clarifications required to define the size constraints for > > docsIfCmtsCmStatusEqualizationData and docsIfSigQEqualizationData > > > > Please review the details and send your comments. > > > > You will find in this email a summary of the proposed changes > > as well as > > a log of comments provided by vendors to place the discussion in the > > context of the IPCDN participants. > > > > > > Please comment on the proposals and make the appropriate comments > > Item a) > > Item c) > > Item d) > > Comments and pick an alternative from > > b-1) > > and > > b-2) > > > > > > > > ---- > > > > CM/CMTS Equalizer Data: > > > > > > Summary: > > docsIfSigQEqualizationData and > > docsIfCmtsCmStatusEqualizationData have > > OCTET STRING with no constraints in the object size (RFC > > 2669), in fact > > the format of the pre-equalizers was never normalized and > left vendor > > specific > > In draft 06 of RFIv2.0 It was added a size constraint of 512 > > octets but > > no special reason was defined: > > Some basic Math will indicate that up to 64 taps ( RFI > > requirements) and > > 4 bytes per tap will indicate 256 bytes, still uncertain why 512 was > > selected. > > > > Even though the selection of 256 (or 512) does not seem to > be accurate > > number considering some possible byte controls to indicate: > > - Taps could be T, T/2 or T/4 spaced. > > - Forward Taps and Reverse Taps could have different numbers > > - Not required by the spec : Reverse Taps (DS equalizers) > > could be also > > T, T/2 and T/4 spaced > > - Any need to indicate main tap position ( or the highest value is > > enough indication of that > > > > The discussions held with RF experts identified the following > > management > > requirements : > > > > 1) CM DS post-equalization have been defined in > > docsIfSigQEqualizationData > > > > 2) CM Upstream pre-equalizer ( not to be defined in this > > version of the > > MIB) something to reflect the CMTS RNG-RSP equalizer value > > > > CMTS equalization Data: > > 3) Equalization in the Upstream has relative importance for CMTS CM > > path, docsIfCmtsCmStatusEqualizationData > > Meanings: > > When Pre-eq is off, the value will indicate the CM-CMTS path RF > > distortions. > > When re-eq is on, the value indicates how well pre-equalization is > > working as the value of all should be close to zero with > the exception > > of the main tap > > > > 4) The equalization data per US interface defined as an > > average value in > > docsIfSigQEqualizationData > > This concept is confusing since there is no in the RFI spec a > > methodology to calculate that average. > > It could include : > > - CMs with different configuration: pre-eq on|off, > > - Different number of Taps per CM, > > - Tap spacing per CM > > The average formula should've being > > The recommendation is to remove that requirement > > > > > > Proposed resolution: > > a) > > Use the same format as in the CM equalization data for 1) > and 3) for > > CM docsIfSigQEqualizationData and docsIfCmtsCmStatusEqualizationData > > > > b) > > remove the CMTS requirement for docsIfSigQEqualizationData > > - Future spec efforts will work to define more meaningful values for > > CMTS US that could lead to objects that defines MER > measurements prior > > and after channel signal compensation or mitigation by the CMTS > > > > c) Description of docsIfCmtsCmStatusEqualizationData > > > > d) > > CM upstream pre-equalizer Perhaps in further revisions of the DOCSIS > > specification and RFI MIB updates > > > > > > Proposal details : > > > > a) > > > > -- Add a new textual Convention > > DocsEqualizerData ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "This data type represents the equalizer data > > as measured at the receiver interface. > > The format of the equalizer follows a similar structure > > Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI > > v1.1 specification with slight modifications as > > follows : > > 1 byte Number of forward taps per symbol > > 1 byte Number of reverse taps per symbol > > 1 byte Number of forward taps: n > > 1 byte Number of reverse taps: m > > > > Following are the equalizer coefficients: > > First forward taps coefficients : > > 2 bytes F1 (real), 2 bytes F1 (imag) > > ... > > 2 bytes Fn (real), 2 bytes Fn (imag) > > > > Then reverse taps coefficients : > > 2 bytes D1 (real), 2 bytes D1 (imag) > > ... > > 2 bytes Dm (real), 2 bytes Dm (imag) > > > > The equalizers coefficient are considered signed 16 bit > > integers in the range -32768 (0x8000) to 32767 (0x7FFF). > > > > DOCSIS specifications requires up to a maximum of > > 64 equalizer taps (N + M), therefore, this object size > can get up 260 bytes (4 + 4x64). > > The minimum object size (other than zero) for a > t-spaced Tab > > with a minimum of 8 symbols will be 36 (4 + 4x8)" > > SYNTAX OCTET STRING(SIZE 0|36..260)) > > > > > > alternative b-1) > > > > docsIfSigQEqualizationData OBJECT-TYPE > > SYNTAX DocsEqualizerData > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "At the CM, returns the equalization data for the > > downstream > > channel. > > > > At the CMTS, this object is not applicable and > > might return > > > > a zero-length OCTET STRING. Note that previous CMTS > > implementations may instantiate this object in > two ways: > > - An equalization value different of the zero-length > > octet string to indicate an equalization average for > > the upstream channel. Those values have vendor > > dependent interpretation. > > - Return a zero-length OCTET STRING as described below. > > > > A returned zero-length OCTET STRING indicate the value > > is unknown or if there is no equalization data > available > > or defined." > > REFERENCE > > "DOCSIS Radio Frequency Interface Specification, > > Figure 6-23." > > ::= { docsIfSignalQualityEntry 7 } > > > > --Note: same compliance statements as in draft 13 > > > > > > alternative b-2) > > > > docsIfSigQEqualizationData OBJECT-TYPE > > SYNTAX DocsEqualizerData > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "At the CM, returns the equalization data for the > > downstream > > channel. > > > > At the CMTS, this object is not applicable and is not > > instantiated. Note that previous CMTS implementations > > may instantiate this object in two ways: > > - An equalization value different of the zero-length > > octet string to indicate an equalization average for > > the upstream channel. Those values have vendor > > dependent interpretation. > > - Return a zero-length OCTET STRING as described below. > > > > A returned zero-length OCTET STRING indicate the value > > is unknown or if there is no equalization data > available > > or defined." > > REFERENCE > > "DOCSIS Radio Frequency Interface Specification, > > Figure 6-23." > > ::= { docsIfSignalQualityEntry 7 } > > > > -- Changes in compliance statements: > > docsIfBasicGroupV2 OBJECT-GROUP > > OBJECTS { > > docsIfDownChannelId, > > -- ... snip ... > > -- delete > > -- docsIfSigQEqualizationData, > > --- ...snip ... > > } > > STATUS current > > DESCRIPTION > > "Group of objects implemented in both cable modems and > > cable modem termination systems." > > ::= { docsIfGroups 5 } > > > > > > docsIfCmGroupV2 OBJECT-GROUP > > OBJECTS { > > docsIfCmCmtsAddress, > > -- ... snip ... > > docsIfCmServiceExtTxSlotsDed, > > -- Add > > docsIfSigQEqualizationData > > --- ...snip ... > > } > > STATUS current > > DESCRIPTION > > "Group of objects implemented in cable modems." > > ::= { docsIfGroups 6 } > > > > c) > > docsIfCmtsCmStatusEqualizationData OBJECT-TYPE > > SYNTAX OCTET STRING (SIZE (0..512)) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "Equalization data for this CM as measured by the CMTS. > > Returns the zero-length OCTET STRING if the value is > > unknown or if there is no equalization data available > > or defined." > > REFERENCE > > "Data-Over-Cable Service Interface Specifications: Radio > > Frequency Interface Specification SP-RFIv2.0-I07-041210, > > Figure 8-23." > > ::= { docsIfCmtsCmStatusEntry 8 } > > > > > > > > > > Summary of comments received in a vendor internal discussion > > Copied for IPCDN participants background > > > > ------------------ > > Hal Roberts - ADC > > > > Colleagues, > > > > While we are looking at this question we should make sure we > > end up with > > precise definitions of the equalization coefficient format > for DOCSIS > > 3.0 for both the CMTS and the CM. Note that DOCSIS 3.0 > Enhanced Signal > > Quality Monitoring goals include: > > > > - Pre-Equalization (Already in spec) > > * Review language to make sure output is standardized for > > processing. > > > > docsIfSigQEqualizationData > > For the cable modem "the equalization data for the > downstream channel" > > has an unambiguous meaning. So for the cable modem it is the > > tap format > > which must be made unambiguous (this should be agreed upon by cable > > modem and/or cable modem chip manufacturers). > > With regard to the CMTS, the MIB docsIfSigQEqualizationData > > is supposed > > to provide the 'average' equalization data for the upstream > channel as > > seen by the CMTS. This is an ambiguous statement. There is no > > 'average' > > equalization data since the equalization coefficients > > uniquely apply to > > each upstream path from each CM to the CMTS receiver. These > > coefficients > > are complex numbers, so in what way does one average them? > If one can > > define a formula that results in a single real number from > each set of > > coefficients as they come from the CMTS for each CM then one could > > envision averaging these numbers into something approaching a > > meaningful > > assessment of the linear distortions on a given upstream > channel. (Tom > > Kolze has just such a formula and we have found it to be an accurate > > estimate of the MER of a channel due to distortions alone. > Tom may be > > willing to share this with the working group). > > > > Therefore I think that the definition of 'average > > equalization data for > > the upstream channel' must be clarified or the CMTS portion > of the MIB > > should be removed. > > > > docsIfCmtsCmStatusEqualizationData > > With regard to the MIB docsIfCmtsCmStatusEqualizationData, when > > pre-equalization is on there is little or no meaning to the > > equalization > > coefficients from the CMTS (even on a per-cable-modem basis > > rather than > > per channel). If pre-equalization is working correctly > there should be > > very little residual channel distortion left and the > coefficients will > > no longer have any relationship to the channel > > characteristics. Possibly > > the only use for these coefficients when pre-equalization > is on, is to > > actually see if pre-equalization is doing the job. > > > > On the other hand, when pre-equalization is turned off, > > docsIfCmtsCmStatusEqualizationData will accurately reflect > distortions > > on the RF path between the given cable modem and the CMTS receiver. > > > > Therefore I think that agreeing on the format of this MIB is what is > > necessary. One other suggestion, the text "Equalization > data for this > > CM" might be clearer if it stated "Equalization data for this CM, as > > measured by the CMTS" > > > > Hal > > > > > > docsIfSigQEqualizationData OBJECT-TYPE > > SYNTAX OCTET STRING > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "At the CM, returns the equalization data for the > > downstream > > channel. At the CMTS, returns the average equalization > > data for the upstream channel. Returns an empty string > > if the value is unknown or if there is no equalization > > data available or defined." > > REFERENCE > > "DOCSIS Radio Frequency Interface Specification, > > Figure 6-23." > > ::= { docsIfSignalQualityEntry 7 } > > > > ------------------------ > > > > Andre Lejeune - ATI > > > > We report the docsIfSigQEqualizationData for our CM in the following > > format: > > > > F1 (real) 16 bits, F1 (imag) 16 bits > > F2 (real) 16 bits, F2 (imag) 16 bits > > ... > > Fn (real) 16 bits, Fn (imag) 16 bits > > > > The number of taps is deduced from the length of the octet string. > > > > > > ------------------------ > > > > David Hull - Conexant > > > > The DS equalizer has never been specified in terms of its exact > > implementation. This has been left to the individual > silicon vendor; > > therefore they are all a bit different. Some implementations use T > > spaced all the way through and (I believe) some > > implementations may use > > fractional spacing for the front end (prior to the reference > > tap). Not > > all implementations have the same length of DS equalizer or the same > > center tap position (relative to the overall length) either. > > If all we > > want to do is compute the frequency response by a DFT on the tap > > weights, I don't think it matters what the CT position is but > > the length > > and the tap spacing would need to be conveyed if fractional > spacing is > > used. > > > > ------------------------ > > > > Andre Lejeune - ATI > > > > > > I am sorry I took some time to respond. I clearly needed to > > discuss this > > internally before continuing on the subject. > > > > The format I sent earlier was for our modem. But now I > > realize that even > > our own solution will be changing and the format below won't be > > appropriate. I agree that more information needs to be > carried in this > > MIB. A solution proposed by Mike Grimwood is to use the format from > > DOCSIS 1.1, figure 6.23 (without the type and length), which > > allows for > > Main Tap Location, Spacing, number of FF and FB taps. Even > > that may not > > be sufficient, if I properly understand Dave below, if different > > fractional spacing is used for the different taps. I'll let > > Dave explain > > this further if he thinks it is necessary. The main tap > > location is not > > absolutely required, as it generally can be easily derived, > > but could be > > useful under certain error conditions: > > > > Main Tap Location (1 byte) > > Number of forward taps per symbol (1 byte) > > Number of forward taps (1 byte) > > Number of reverse taps (1 byte) > > F1 (real) 16 bits, F1 (imag) 16 bits > > F2 (real) 16 bits, F2 (imag) 16 bits > > ... > > Fn (real) 16 bits, Fn (imag) 16 bits > > > > D1 (real) 16 bits, D1 (imag) 16 bits > > D2 (real) 16 bits, D2 (imag) 16 bits > > ... > > Dn (real) 16 bits, Dn (imag) 16 bits > > > > ------------------------ > > Hal Roberts - ADC > > > > To summarize: > > 1. Equalization MIBS from the CM - We need well defined MIBs from > > the CM for both the downstream post-equalizer and the upstream > > pre-equalizer values. If no uniform format for the > downstream taps can > > be defined due to proprietary implementations, perhaps the > vendors can > > simply provide a 'frequency response or impulse response' as > > calculated > > from the equalizer (but in a uniform format). For the > upstream taps it > > should be easy to provide a uniform tap format as it is > already mostly > > defined in the RFI. > > 2. Equalization MIBS from the CMTS when Pre-equalization is OFF - > > As mentioned before, an average equalization data from the > > CMTS on a per > > upstream channel basis is not defined and could take a number of > > meanings. Without an unambiguous definition of channel based > > equalization data, it would be better to remove this part of the > > definition as it simply leads to mass confusion. Note that > > equalization > > MIBs from the CMTS on a per CM basis do have significant > > value for plant > > monitoring and debug purposes. These merely need to be defined in > > format; this format could be the same format as in the > > pre-equalizer MIB > > from the CM as they are representing the same plant characteristic. > > 3. Equalization MIBS from the CMTS when Pre-equalization is ON - > > These have no significant value other than seeing if > > pre-equalization is > > operating properly. When pre-equalization is operating > > properly then the > > CMTS should see little or no plant distortion and the equalizer > > coefficients should be close to all-zeros except for the > main tap for > > all modems. > > Hal > > > > ------------------------ > > David Hull -Conexant > > > > With regard to #1, the definition in Fig 6-22 of the DOCSIS 1.1 spec > > that Andre referred to seems good enough but I would allow > > the number of > > taps per symbol to be defined independently for the forward > > section AND > > the reverse section just in case someone implemented the > two sections > > with different tap spacing. Short of officially "specifying" the DS > > equalizer like we have done for the upstream one, I don't > see too much > > more that could be done. > > > > ------------------------ > > Hal Roberts - ADC > > > > Dave, > > > > It may be elsewhere in the spec or it may be obvious but I > > think we need > > to have more detail, for example the numbers should be > > represented in a > > specific numerical format perhaps: > > > > "Standard twos-complement format, from -32768 (0x8000) to 32767 > > (0x7FFF)" > > > > as an example. > > > > Hal > > > > ------------------------ > > > > > > > > > > > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Oct 18 11:07:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERt3b-0003PY-O6; Tue, 18 Oct 2005 11:07:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERt3Z-0003PI-KT for ipcdn@megatron.ietf.org; Tue, 18 Oct 2005 11:07:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08425 for ; Tue, 18 Oct 2005 11:07:05 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERtF7-0000ag-Dq for ipcdn@ietf.org; Tue, 18 Oct 2005 11:19:10 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j9IF6tRB001569; Tue, 18 Oct 2005 09:06:55 -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: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Date: Tue, 18 Oct 2005 09:06:55 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F0117904E@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKAACga3IAAAh6FUAACaROgB9+1Q8ABj7jfcAAuytRwAQxUCqA= From: "Eduardo Cardona" To: "Margo Dolas" , "Ipcdn (E-mail)" , "Wijnen, Bert (Bert)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: d1013c8bad83fa4e4ccb34a7376b19d5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Hi Margo,=20 Sorry, I missed your response,=20 I think you have a good point,=20 Some management applications may decide to just look at the main tap and ignore the others to simplify the parsing and processing of the values. Early discussions with PHY experts, they where divided if main tap pointer was needed or not -- It can be determined as the biggest magnitude of the coefficient series. Your suggestion is clear for the US equalization. For DS, David Hull had a point of making the CM handling of coefficients open to CM implementations. See his comments ( bottom of this email, copied for convenience below ).=20 Therefore, in the interest of leaving the header an even number ( and a multiple of four) it was considered not requiring the Main tap location David Hull -Conexant=20 "With regard to #1, the definition in Fig 6-22 of the DOCSIS 1.1 spec that Andre referred to seems good enough but I would allow the number of taps per symbol to be defined independently for the forward section AND the reverse section just in case someone implemented the two sections with different tap spacing. Short of officially "specifying" the DS equalizer like we have done for the upstream one, I don't see too much more that could be done." Shall we consider two TEXTUAL-CONVENTIONS=20 One for US and one for DS ?=20 DocsUpstreamEqualizerData -- No Main Tap 1 byte Number of forward taps per symbol 1 byte Number of reverse taps per symbol 1 byte Number of forward taps 1 byte Number of reverse taps DocsDownstreamEqualizerData 1 byte Main Tap Location 1 byte Number of forward taps per symbol 1 byte Number of forward taps 1 byte Number of reverse taps Or should we just add the extra byte of the main tap in the current TEXTUAL CONVENTION (SIZE 261) DocsEqualizerData=20 1 byte Main Tap Location 1 byte Number of forward taps per symbol 1 byte Number of reverse taps per symbol -- 1 for US equalizers 1 byte Number of forward taps 1 byte Number of reverse taps Thanks Eduardo -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com]=20 Sent: Wednesday, October 12, 2005 1:32 PM To: Eduardo Cardona; 'Ipcdn (E-mail)'; 'Wijnen, Bert (Bert)'; david.raftus@ati.com Subject: RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Eduardo, Thanks for going to the effort of clarifying these objects! I only have one comment. The creation of the DocsEqualizerData convention is good, but would it be possible to change the definition to match that of the RNG-RSP from DOCSIS1.1, removing the number of reverse taps per symbol and adding the main tap location? It's unnecessary to specify the number of reverse taps per symbol, since it would be a T-spaced DFE. The main tap location is important (at least for the upstream) because it refers to the position of the zero delay tap for a ranging consideration. DocsEqualizerData ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type represents the equalizer data as measured at the receiver interface. The format of the equalizer follows a similar structure Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI=20 v1.1 specification with slight modifications as follows : 1 byte Main Tap Location 1 byte Number of forward taps per symbol 1 byte Number of forward taps 1 byte Number of reverse taps ... In terms of options (b-1) and (b-2), I don't have a strong preference, but a small preference for (b-2). Margo =20 -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Eduardo Cardona Sent: Tuesday, October 11, 2005 1:59 PM To: Eduardo Cardona; Ipcdn (E-mail); Wijnen, Bert (Bert); david.raftus@ati.com Subject: RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Does anyone get the chance to review the proposed clarifications ?=20 Please reply with comments by the end of the week=20 Thanks Eduardo -----Original Message----- From: Eduardo Cardona Sent: Monday, October 03, 2005 3:35 PM To: Ipcdn (E-mail); Wijnen, Bert (Bert); david.raftus@ati.com Subject: RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Hi IPCDN participants, Here is an update on one of the pending items from Bert's review: After consultations with DOCSIS vendors, I am proposing the clarifications required to define the size constraints for docsIfCmtsCmStatusEqualizationData and docsIfSigQEqualizationData Please review the details and send your comments. You will find in this email a summary of the proposed changes as well as a log of comments provided by vendors to place the discussion in the context of the IPCDN participants.=20 Please comment on the proposals and make the appropriate comments Item a) Item c) Item d) Comments and pick an alternative from b-1) and b-2) ---- =20 CM/CMTS Equalizer Data:=20 Summary: docsIfSigQEqualizationData and docsIfCmtsCmStatusEqualizationData have OCTET STRING with no constraints in the object size (RFC 2669), in fact the format of the pre-equalizers was never normalized and left vendor specific In draft 06 of RFIv2.0 It was added a size constraint of 512 octets but no special reason was defined: Some basic Math will indicate that up to 64 taps ( RFI requirements) and 4 bytes per tap will indicate 256 bytes, still uncertain why 512 was selected. Even though the selection of 256 (or 512) does not seem to be accurate number considering some possible byte controls to indicate: - Taps could be T, T/2 or T/4 spaced.=20 - Forward Taps and Reverse Taps could have different numbers - Not required by the spec : Reverse Taps (DS equalizers) could be also T, T/2 and T/4 spaced - Any need to indicate main tap position ( or the highest value is enough indication of that=20 The discussions held with RF experts identified the following management requirements :=20 =20 1) CM DS post-equalization have been defined in docsIfSigQEqualizationData=20 2) CM Upstream pre-equalizer ( not to be defined in this version of the MIB) something to reflect the CMTS RNG-RSP equalizer value=20 CMTS equalization Data: 3) Equalization in the Upstream has relative importance for CMTS CM path, docsIfCmtsCmStatusEqualizationData Meanings: When Pre-eq is off, the value will indicate the CM-CMTS path RF distortions. When re-eq is on, the value indicates how well pre-equalization is working as the value of all should be close to zero with the exception of the main tap 4) The equalization data per US interface defined as an average value in docsIfSigQEqualizationData This concept is confusing since there is no in the RFI spec a methodology to calculate that average.=20 It could include :=20 - CMs with different configuration: pre-eq on|off, - Different number of Taps per CM, - Tap spacing per CM The average formula should've being The recommendation is to remove that requirement Proposed resolution: a) Use the same format as in the CM equalization data for 1) and 3) for CM docsIfSigQEqualizationData and docsIfCmtsCmStatusEqualizationData b) remove the CMTS requirement for docsIfSigQEqualizationData - Future spec efforts will work to define more meaningful values for CMTS US that could lead to objects that defines MER measurements prior and after channel signal compensation or mitigation by the CMTS c) Description of docsIfCmtsCmStatusEqualizationData d) CM upstream pre-equalizer Perhaps in further revisions of the DOCSIS specification and RFI MIB updates =20 Proposal details : a)=20 -- Add a new textual Convention DocsEqualizerData ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type represents the equalizer data as measured at the receiver interface. The format of the equalizer follows a similar structure Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI=20 v1.1 specification with slight modifications as follows : 1 byte Number of forward taps per symbol 1 byte Number of reverse taps per symbol 1 byte Number of forward taps 1 byte Number of reverse taps =20 Following are the equalizer coefficients: First forward taps coefficients : 2 bytes F1 (real), 2 bytes F1 (imag) ... 2 bytes Fn (real), 2 bytes Fn (imag) =20 Then reverse taps coefficients : 2 bytes D1 (real), 2 bytes D1 (imag) ... 2 bytes Dm (real), 2 bytes Dm (imag) The equalizers coefficient are considered signed 16 bit integers in the range -32768 (0x8000) to 32767 (0x7FFF). =20 DOCSIS specifications requires up to a maximum of=20 64 equalizer taps , therefore, this object size can get up 260 bytes (4 + 4x64). The minimum object size (other than zero) for a t-spaced Tab with a minimum of 8 symbols will be 36 (4 + 4x8)" SYNTAX OCTET STRING(SIZE 0|36..260)) alternative b-1)=20 docsIfSigQEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. =20 At the CMTS, this object is not applicable and might return a zero-length OCTET STRING. Note that previous CMTS=20 implementations may instantiate this object in two ways: - An equalization value different of the zero-length octet string to indicate an equalization average for the upstream channel. Those values have vendor=20 dependent interpretation. - Return a zero-length OCTET STRING as described below. =20 A returned zero-length OCTET STRING indicate the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::=3D { docsIfSignalQualityEntry 7 } --Note: same compliance statements as in draft 13 alternative b-2)=20 docsIfSigQEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. =20 At the CMTS, this object is not applicable and is not=20 instantiated. Note that previous CMTS implementations=20 may instantiate this object in two ways: - An equalization value different of the zero-length octet string to indicate an equalization average for the upstream channel. Those values have vendor=20 dependent interpretation. - Return a zero-length OCTET STRING as described below. =20 A returned zero-length OCTET STRING indicate the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::=3D { docsIfSignalQualityEntry 7 } -- Changes in compliance statements:=20 docsIfBasicGroupV2 OBJECT-GROUP OBJECTS { docsIfDownChannelId, -- ... snip ... -- delete -- docsIfSigQEqualizationData, --- ...snip ... } STATUS current DESCRIPTION "Group of objects implemented in both cable modems and cable modem termination systems." ::=3D { docsIfGroups 5 } docsIfCmGroupV2 OBJECT-GROUP OBJECTS { docsIfCmCmtsAddress, -- ... snip ... docsIfCmServiceExtTxSlotsDed, -- Add docsIfSigQEqualizationData --- ...snip ... } STATUS current DESCRIPTION "Group of objects implemented in cable modems." ::=3D { docsIfGroups 6 } c) docsIfCmtsCmStatusEqualizationData OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..512)) MAX-ACCESS read-only STATUS current DESCRIPTION "Equalization data for this CM as measured by the CMTS. Returns the zero-length OCTET STRING if the value is=20 unknown or if there is no equalization data available or defined." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I07-041210, Figure 8-23." ::=3D { docsIfCmtsCmStatusEntry 8 } Summary of comments received in a vendor internal discussion Copied for IPCDN participants background=20 ------------------ Hal Roberts - ADC Colleagues, =20 While we are looking at this question we should make sure we end up with precise definitions of the equalization coefficient format for DOCSIS 3.0 for both the CMTS and the CM. Note that DOCSIS 3.0 Enhanced Signal Quality Monitoring goals include: =20 - Pre-Equalization (Already in spec)=20 * Review language to make sure output is standardized for processing.=20 =20 docsIfSigQEqualizationData For the cable modem "the equalization data for the downstream channel" has an unambiguous meaning. So for the cable modem it is the tap format which must be made unambiguous (this should be agreed upon by cable modem and/or cable modem chip manufacturers). With regard to the CMTS, the MIB docsIfSigQEqualizationData is supposed to provide the 'average' equalization data for the upstream channel as seen by the CMTS. This is an ambiguous statement. There is no 'average' equalization data since the equalization coefficients uniquely apply to each upstream path from each CM to the CMTS receiver. These coefficients are complex numbers, so in what way does one average them? If one can define a formula that results in a single real number from each set of coefficients as they come from the CMTS for each CM then one could envision averaging these numbers into something approaching a meaningful assessment of the linear distortions on a given upstream channel. (Tom Kolze has just such a formula and we have found it to be an accurate estimate of the MER of a channel due to distortions alone. Tom may be willing to share this with the working group). =20 Therefore I think that the definition of 'average equalization data for the upstream channel' must be clarified or the CMTS portion of the MIB should be removed. =20 docsIfCmtsCmStatusEqualizationData With regard to the MIB docsIfCmtsCmStatusEqualizationData, when pre-equalization is on there is little or no meaning to the equalization coefficients from the CMTS (even on a per-cable-modem basis rather than per channel). If pre-equalization is working correctly there should be very little residual channel distortion left and the coefficients will no longer have any relationship to the channel characteristics. Possibly the only use for these coefficients when pre-equalization is on, is to actually see if pre-equalization is doing the job. =20 On the other hand, when pre-equalization is turned off, docsIfCmtsCmStatusEqualizationData will accurately reflect distortions on the RF path between the given cable modem and the CMTS receiver. =20 Therefore I think that agreeing on the format of this MIB is what is necessary. One other suggestion, the text "Equalization data for this CM" might be clearer if it stated "Equalization data for this CM, as measured by the CMTS" =20 Hal =20 =20 docsIfSigQEqualizationData OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. At the CMTS, returns the average equalization data for the upstream channel. Returns an empty string if the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::=3D { docsIfSignalQualityEntry 7 } =20 ------------------------ =20 Andre Lejeune - ATI We report the docsIfSigQEqualizationData for our CM in the following format: =20 F1 (real) 16 bits, F1 (imag) 16 bits F2 (real) 16 bits, F2 (imag) 16 bits ... Fn (real) 16 bits, Fn (imag) 16 bits =20 The number of taps is deduced from the length of the octet string. ------------------------ =20 David Hull - Conexant=20 The DS equalizer has never been specified in terms of its exact implementation. This has been left to the individual silicon vendor; therefore they are all a bit different. Some implementations use T spaced all the way through and (I believe) some implementations may use fractional spacing for the front end (prior to the reference tap). Not all implementations have the same length of DS equalizer or the same center tap position (relative to the overall length) either. If all we want to do is compute the frequency response by a DFT on the tap weights, I don't think it matters what the CT position is but the length and the tap spacing would need to be conveyed if fractional spacing is used. ------------------------ =20 Andre Lejeune - ATI I am sorry I took some time to respond. I clearly needed to discuss this internally before continuing on the subject. =20 The format I sent earlier was for our modem. But now I realize that even our own solution will be changing and the format below won't be appropriate. I agree that more information needs to be carried in this MIB. A solution proposed by Mike Grimwood is to use the format from DOCSIS 1.1, figure 6.23 (without the type and length), which allows for Main Tap Location, Spacing, number of FF and FB taps. Even that may not be sufficient, if I properly understand Dave below, if different fractional spacing is used for the different taps. I'll let Dave explain this further if he thinks it is necessary. The main tap location is not absolutely required, as it generally can be easily derived, but could be useful under certain error conditions: =20 Main Tap Location (1 byte) Number of forward taps per symbol (1 byte) Number of forward taps (1 byte) Number of reverse taps (1 byte) F1 (real) 16 bits, F1 (imag) 16 bits F2 (real) 16 bits, F2 (imag) 16 bits ... Fn (real) 16 bits, Fn (imag) 16 bits D1 (real) 16 bits, D1 (imag) 16 bits D2 (real) 16 bits, D2 (imag) 16 bits ... Dn (real) 16 bits, Dn (imag) 16 bits =20 ------------------------ Hal Roberts - ADC=20 To summarize: 1. Equalization MIBS from the CM - We need well defined MIBs from the CM for both the downstream post-equalizer and the upstream pre-equalizer values. If no uniform format for the downstream taps can be defined due to proprietary implementations, perhaps the vendors can simply provide a 'frequency response or impulse response' as calculated from the equalizer (but in a uniform format). For the upstream taps it should be easy to provide a uniform tap format as it is already mostly defined in the RFI. 2. Equalization MIBS from the CMTS when Pre-equalization is OFF - As mentioned before, an average equalization data from the CMTS on a per upstream channel basis is not defined and could take a number of meanings. Without an unambiguous definition of channel based equalization data, it would be better to remove this part of the definition as it simply leads to mass confusion. Note that equalization MIBs from the CMTS on a per CM basis do have significant value for plant monitoring and debug purposes. These merely need to be defined in format; this format could be the same format as in the pre-equalizer MIB from the CM as they are representing the same plant characteristic. 3. Equalization MIBS from the CMTS when Pre-equalization is ON - These have no significant value other than seeing if pre-equalization is operating properly. When pre-equalization is operating properly then the CMTS should see little or no plant distortion and the equalizer coefficients should be close to all-zeros except for the main tap for all modems. Hal ------------------------ David Hull -Conexant=20 With regard to #1, the definition in Fig 6-22 of the DOCSIS 1.1 spec that Andre referred to seems good enough but I would allow the number of taps per symbol to be defined independently for the forward section AND the reverse section just in case someone implemented the two sections with different tap spacing. Short of officially "specifying" the DS equalizer like we have done for the upstream one, I don't see too much more that could be done. ------------------------ Hal Roberts - ADC=20 Dave, =20 It may be elsewhere in the spec or it may be obvious but I think we need to have more detail, for example the numbers should be represented in a specific numerical format perhaps: =20 "Standard twos-complement format, from -32768 (0x8000) to 32767 (0x7FFF)" =20 as an example. =20 Hal ------------------------ =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 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Oct 18 15:42:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxLv-0004D5-Mg; Tue, 18 Oct 2005 15:42:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxLs-0004Cu-J3 for ipcdn@megatron.ietf.org; Tue, 18 Oct 2005 15:42:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24034 for ; Tue, 18 Oct 2005 15:42:16 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERxXS-0008JY-3G for ipcdn@ietf.org; Tue, 18 Oct 2005 15:54:23 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j9IJgBl6011775; Tue, 18 Oct 2005 13:42:11 -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: ADre-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Date: Tue, 18 Oct 2005 13:42:11 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F0117914B@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE: ADre-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKAACga3IAAAh6FUAACaROgB9+1Q8ABj7jfcAAuytRwAQxUCqAAJ1q4cA== From: "Eduardo Cardona" To: "Margo Dolas" , "Ipcdn (E-mail)" , "Wijnen, Bert (Bert)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d231d878f8d68d85cf12b60d23450ce Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Making a quick poll for preferred options=20 IPCDN participants, please provide your preferences and/or comments=20 a-1) Eduardo a-2) a-3) b-1)=20 b-2) Margo, Eduardo See expansion of a) cases below. Note: c) is a text clarification : Equalization data for this CM "as measured by the CMTS." I assume every one will agree with that One correction for Item c)=20 The original proposal was intended to say=20 docsIfCmtsCmStatusEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData docsIfCmtsCmStatusEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData MAX-ACCESS read-only STATUS current DESCRIPTION "Equalization data for this CM as measured by the CMTS. Returns the zero-length OCTET STRING if the value is=20 unknown or if there is no equalization data available or defined." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I07-041210, Figure 8-23." ::=3D { docsIfCmtsCmStatusEntry 8 } Margos's comments bring three alternatives that can think for item a) =20 a-1) -- Add Main Tap=20 DocsEqualizerData ::=3D TEXTUAL-CONVENTION 1 byte Main Tap Location 1 byte Number of forward taps per symbol 1 byte Number of reverse taps per symbol 1 byte Number of forward taps 1 byte Number of reverse taps =20 a-2) -- do not consider David Hull's flexibility for Reverse Coefficient spacing for DS equalizer: use straight DOCSIS 1.1 MAC message format DocsEqualizerData ::=3D TEXTUAL-CONVENTION 1 byte Main Tap Location 1 byte Number of forward taps per symbol 1 byte Number of forward taps 1 byte Number of reverse taps =20 a-3) Separate US and DS equalization "formalize DS equalizer format"=20 docsIfCmtsCmStatusEqualizationData OBJECT-TYPE SYNTAX DocsUpstreamEqualizerData docsIfSigQEqualizationData OBJECT-TYPE SYNTAX DocsDownstreamEqualizerData For a-3) deciding the format of US and DS Equalizer TCs it is likely that they will fall either to a-1) or a-2) to manage them in a standard way, it means no special advantage. -----Original Message----- From: Eduardo Cardona=20 Sent: Tuesday, October 18, 2005 9:07 AM To: Margo Dolas; Ipcdn (E-mail); Wijnen, Bert (Bert); david.raftus@ati.com Subject: RE: [ipcdn] RE: ADre-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:docsIfCmtsCmStatus EqualizationData & docsIfSigQEqualizationData Hi Margo,=20 Sorry, I missed your response,=20 I think you have a good point,=20 Some management applications may decide to just look at the main tap and ignore the others to simplify the parsing and processing of the values. Early discussions with PHY experts, they where divided if main tap pointer was needed or not -- It can be determined as the biggest magnitude of the coefficient series. Your suggestion is clear for the US equalization. For DS, David Hull had a point of making the CM handling of coefficients open to CM implementations. See his comments ( bottom of this email, copied for convenience below ).=20 Therefore, in the interest of leaving the header an even number ( and a multiple of four) it was considered not requiring the Main tap location David Hull -Conexant=20 "With regard to #1, the definition in Fig 6-22 of the DOCSIS 1.1 spec that Andre referred to seems good enough but I would allow the number of taps per symbol to be defined independently for the forward section AND the reverse section just in case someone implemented the two sections with different tap spacing. Short of officially "specifying" the DS equalizer like we have done for the upstream one, I don't see too much more that could be done." Shall we consider two TEXTUAL-CONVENTIONS=20 One for US and one for DS ?=20 DocsUpstreamEqualizerData -- No Main Tap 1 byte Number of forward taps per symbol 1 byte Number of reverse taps per symbol 1 byte Number of forward taps 1 byte Number of reverse taps DocsDownstreamEqualizerData 1 byte Main Tap Location 1 byte Number of forward taps per symbol 1 byte Number of forward taps 1 byte Number of reverse taps Or should we just add the extra byte of the main tap in the current TEXTUAL CONVENTION (SIZE 261) DocsEqualizerData=20 1 byte Main Tap Location 1 byte Number of forward taps per symbol 1 byte Number of reverse taps per symbol -- 1 for US equalizers 1 byte Number of forward taps 1 byte Number of reverse taps Thanks Eduardo -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com]=20 Sent: Wednesday, October 12, 2005 1:32 PM To: Eduardo Cardona; 'Ipcdn (E-mail)'; 'Wijnen, Bert (Bert)'; david.raftus@ati.com Subject: RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Eduardo, Thanks for going to the effort of clarifying these objects! I only have one comment. The creation of the DocsEqualizerData convention is good, but would it be possible to change the definition to match that of the RNG-RSP from DOCSIS1.1, removing the number of reverse taps per symbol and adding the main tap location? It's unnecessary to specify the number of reverse taps per symbol, since it would be a T-spaced DFE. The main tap location is important (at least for the upstream) because it refers to the position of the zero delay tap for a ranging consideration. DocsEqualizerData ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type represents the equalizer data as measured at the receiver interface. The format of the equalizer follows a similar structure Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI=20 v1.1 specification with slight modifications as follows : 1 byte Main Tap Location 1 byte Number of forward taps per symbol 1 byte Number of forward taps 1 byte Number of reverse taps ... In terms of options (b-1) and (b-2), I don't have a strong preference, but a small preference for (b-2). Margo =20 -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Eduardo Cardona Sent: Tuesday, October 11, 2005 1:59 PM To: Eduardo Cardona; Ipcdn (E-mail); Wijnen, Bert (Bert); david.raftus@ati.com Subject: RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Does anyone get the chance to review the proposed clarifications ?=20 Please reply with comments by the end of the week=20 Thanks Eduardo -----Original Message----- From: Eduardo Cardona Sent: Monday, October 03, 2005 3:35 PM To: Ipcdn (E-mail); Wijnen, Bert (Bert); david.raftus@ati.com Subject: RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Hi IPCDN participants, Here is an update on one of the pending items from Bert's review: After consultations with DOCSIS vendors, I am proposing the clarifications required to define the size constraints for docsIfCmtsCmStatusEqualizationData and docsIfSigQEqualizationData Please review the details and send your comments. You will find in this email a summary of the proposed changes as well as a log of comments provided by vendors to place the discussion in the context of the IPCDN participants.=20 Please comment on the proposals and make the appropriate comments Item a) Item c) Item d) Comments and pick an alternative from b-1) and b-2) ---- =20 CM/CMTS Equalizer Data:=20 Summary: docsIfSigQEqualizationData and docsIfCmtsCmStatusEqualizationData have OCTET STRING with no constraints in the object size (RFC 2669), in fact the format of the pre-equalizers was never normalized and left vendor specific In draft 06 of RFIv2.0 It was added a size constraint of 512 octets but no special reason was defined: Some basic Math will indicate that up to 64 taps ( RFI requirements) and 4 bytes per tap will indicate 256 bytes, still uncertain why 512 was selected. Even though the selection of 256 (or 512) does not seem to be accurate number considering some possible byte controls to indicate: - Taps could be T, T/2 or T/4 spaced.=20 - Forward Taps and Reverse Taps could have different numbers - Not required by the spec : Reverse Taps (DS equalizers) could be also T, T/2 and T/4 spaced - Any need to indicate main tap position ( or the highest value is enough indication of that=20 The discussions held with RF experts identified the following management requirements :=20 =20 1) CM DS post-equalization have been defined in docsIfSigQEqualizationData=20 2) CM Upstream pre-equalizer ( not to be defined in this version of the MIB) something to reflect the CMTS RNG-RSP equalizer value=20 CMTS equalization Data: 3) Equalization in the Upstream has relative importance for CMTS CM path, docsIfCmtsCmStatusEqualizationData Meanings: When Pre-eq is off, the value will indicate the CM-CMTS path RF distortions. When re-eq is on, the value indicates how well pre-equalization is working as the value of all should be close to zero with the exception of the main tap 4) The equalization data per US interface defined as an average value in docsIfSigQEqualizationData This concept is confusing since there is no in the RFI spec a methodology to calculate that average.=20 It could include :=20 - CMs with different configuration: pre-eq on|off, - Different number of Taps per CM, - Tap spacing per CM The average formula should've being The recommendation is to remove that requirement Proposed resolution: a) Use the same format as in the CM equalization data for 1) and 3) for CM docsIfSigQEqualizationData and docsIfCmtsCmStatusEqualizationData b) remove the CMTS requirement for docsIfSigQEqualizationData - Future spec efforts will work to define more meaningful values for CMTS US that could lead to objects that defines MER measurements prior and after channel signal compensation or mitigation by the CMTS c) Description of docsIfCmtsCmStatusEqualizationData d) CM upstream pre-equalizer Perhaps in further revisions of the DOCSIS specification and RFI MIB updates =20 Proposal details : a)=20 -- Add a new textual Convention DocsEqualizerData ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type represents the equalizer data as measured at the receiver interface. The format of the equalizer follows a similar structure Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI=20 v1.1 specification with slight modifications as follows : 1 byte Number of forward taps per symbol 1 byte Number of reverse taps per symbol 1 byte Number of forward taps 1 byte Number of reverse taps =20 Following are the equalizer coefficients: First forward taps coefficients : 2 bytes F1 (real), 2 bytes F1 (imag) ... 2 bytes Fn (real), 2 bytes Fn (imag) =20 Then reverse taps coefficients : 2 bytes D1 (real), 2 bytes D1 (imag) ... 2 bytes Dm (real), 2 bytes Dm (imag) The equalizers coefficient are considered signed 16 bit integers in the range -32768 (0x8000) to 32767 (0x7FFF). =20 DOCSIS specifications requires up to a maximum of=20 64 equalizer taps , therefore, this object size can get up 260 bytes (4 + 4x64). The minimum object size (other than zero) for a t-spaced Tab with a minimum of 8 symbols will be 36 (4 + 4x8)" SYNTAX OCTET STRING(SIZE 0|36..260)) alternative b-1)=20 docsIfSigQEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. =20 At the CMTS, this object is not applicable and might return a zero-length OCTET STRING. Note that previous CMTS=20 implementations may instantiate this object in two ways: - An equalization value different of the zero-length octet string to indicate an equalization average for the upstream channel. Those values have vendor=20 dependent interpretation. - Return a zero-length OCTET STRING as described below. =20 A returned zero-length OCTET STRING indicate the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::=3D { docsIfSignalQualityEntry 7 } --Note: same compliance statements as in draft 13 alternative b-2)=20 docsIfSigQEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. =20 At the CMTS, this object is not applicable and is not=20 instantiated. Note that previous CMTS implementations=20 may instantiate this object in two ways: - An equalization value different of the zero-length octet string to indicate an equalization average for the upstream channel. Those values have vendor=20 dependent interpretation. - Return a zero-length OCTET STRING as described below. =20 A returned zero-length OCTET STRING indicate the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::=3D { docsIfSignalQualityEntry 7 } -- Changes in compliance statements:=20 docsIfBasicGroupV2 OBJECT-GROUP OBJECTS { docsIfDownChannelId, -- ... snip ... -- delete -- docsIfSigQEqualizationData, --- ...snip ... } STATUS current DESCRIPTION "Group of objects implemented in both cable modems and cable modem termination systems." ::=3D { docsIfGroups 5 } docsIfCmGroupV2 OBJECT-GROUP OBJECTS { docsIfCmCmtsAddress, -- ... snip ... docsIfCmServiceExtTxSlotsDed, -- Add docsIfSigQEqualizationData --- ...snip ... } STATUS current DESCRIPTION "Group of objects implemented in cable modems." ::=3D { docsIfGroups 6 } c) docsIfCmtsCmStatusEqualizationData OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..512)) MAX-ACCESS read-only STATUS current DESCRIPTION "Equalization data for this CM as measured by the CMTS. Returns the zero-length OCTET STRING if the value is=20 unknown or if there is no equalization data available or defined." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I07-041210, Figure 8-23." ::=3D { docsIfCmtsCmStatusEntry 8 } Summary of comments received in a vendor internal discussion Copied for IPCDN participants background=20 ------------------ Hal Roberts - ADC Colleagues, =20 While we are looking at this question we should make sure we end up with precise definitions of the equalization coefficient format for DOCSIS 3.0 for both the CMTS and the CM. Note that DOCSIS 3.0 Enhanced Signal Quality Monitoring goals include: =20 - Pre-Equalization (Already in spec)=20 * Review language to make sure output is standardized for processing.=20 =20 docsIfSigQEqualizationData For the cable modem "the equalization data for the downstream channel" has an unambiguous meaning. So for the cable modem it is the tap format which must be made unambiguous (this should be agreed upon by cable modem and/or cable modem chip manufacturers). With regard to the CMTS, the MIB docsIfSigQEqualizationData is supposed to provide the 'average' equalization data for the upstream channel as seen by the CMTS. This is an ambiguous statement. There is no 'average' equalization data since the equalization coefficients uniquely apply to each upstream path from each CM to the CMTS receiver. These coefficients are complex numbers, so in what way does one average them? If one can define a formula that results in a single real number from each set of coefficients as they come from the CMTS for each CM then one could envision averaging these numbers into something approaching a meaningful assessment of the linear distortions on a given upstream channel. (Tom Kolze has just such a formula and we have found it to be an accurate estimate of the MER of a channel due to distortions alone. Tom may be willing to share this with the working group). =20 Therefore I think that the definition of 'average equalization data for the upstream channel' must be clarified or the CMTS portion of the MIB should be removed. =20 docsIfCmtsCmStatusEqualizationData With regard to the MIB docsIfCmtsCmStatusEqualizationData, when pre-equalization is on there is little or no meaning to the equalization coefficients from the CMTS (even on a per-cable-modem basis rather than per channel). If pre-equalization is working correctly there should be very little residual channel distortion left and the coefficients will no longer have any relationship to the channel characteristics. Possibly the only use for these coefficients when pre-equalization is on, is to actually see if pre-equalization is doing the job. =20 On the other hand, when pre-equalization is turned off, docsIfCmtsCmStatusEqualizationData will accurately reflect distortions on the RF path between the given cable modem and the CMTS receiver. =20 Therefore I think that agreeing on the format of this MIB is what is necessary. One other suggestion, the text "Equalization data for this CM" might be clearer if it stated "Equalization data for this CM, as measured by the CMTS" =20 Hal =20 =20 docsIfSigQEqualizationData OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. At the CMTS, returns the average equalization data for the upstream channel. Returns an empty string if the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::=3D { docsIfSignalQualityEntry 7 } =20 ------------------------ =20 Andre Lejeune - ATI We report the docsIfSigQEqualizationData for our CM in the following format: =20 F1 (real) 16 bits, F1 (imag) 16 bits F2 (real) 16 bits, F2 (imag) 16 bits ... Fn (real) 16 bits, Fn (imag) 16 bits =20 The number of taps is deduced from the length of the octet string. ------------------------ =20 David Hull - Conexant=20 The DS equalizer has never been specified in terms of its exact implementation. This has been left to the individual silicon vendor; therefore they are all a bit different. Some implementations use T spaced all the way through and (I believe) some implementations may use fractional spacing for the front end (prior to the reference tap). Not all implementations have the same length of DS equalizer or the same center tap position (relative to the overall length) either. If all we want to do is compute the frequency response by a DFT on the tap weights, I don't think it matters what the CT position is but the length and the tap spacing would need to be conveyed if fractional spacing is used. ------------------------ =20 Andre Lejeune - ATI I am sorry I took some time to respond. I clearly needed to discuss this internally before continuing on the subject. =20 The format I sent earlier was for our modem. But now I realize that even our own solution will be changing and the format below won't be appropriate. I agree that more information needs to be carried in this MIB. A solution proposed by Mike Grimwood is to use the format from DOCSIS 1.1, figure 6.23 (without the type and length), which allows for Main Tap Location, Spacing, number of FF and FB taps. Even that may not be sufficient, if I properly understand Dave below, if different fractional spacing is used for the different taps. I'll let Dave explain this further if he thinks it is necessary. The main tap location is not absolutely required, as it generally can be easily derived, but could be useful under certain error conditions: =20 Main Tap Location (1 byte) Number of forward taps per symbol (1 byte) Number of forward taps (1 byte) Number of reverse taps (1 byte) F1 (real) 16 bits, F1 (imag) 16 bits F2 (real) 16 bits, F2 (imag) 16 bits ... Fn (real) 16 bits, Fn (imag) 16 bits D1 (real) 16 bits, D1 (imag) 16 bits D2 (real) 16 bits, D2 (imag) 16 bits ... Dn (real) 16 bits, Dn (imag) 16 bits =20 ------------------------ Hal Roberts - ADC=20 To summarize: 1. Equalization MIBS from the CM - We need well defined MIBs from the CM for both the downstream post-equalizer and the upstream pre-equalizer values. If no uniform format for the downstream taps can be defined due to proprietary implementations, perhaps the vendors can simply provide a 'frequency response or impulse response' as calculated from the equalizer (but in a uniform format). For the upstream taps it should be easy to provide a uniform tap format as it is already mostly defined in the RFI. 2. Equalization MIBS from the CMTS when Pre-equalization is OFF - As mentioned before, an average equalization data from the CMTS on a per upstream channel basis is not defined and could take a number of meanings. Without an unambiguous definition of channel based equalization data, it would be better to remove this part of the definition as it simply leads to mass confusion. Note that equalization MIBs from the CMTS on a per CM basis do have significant value for plant monitoring and debug purposes. These merely need to be defined in format; this format could be the same format as in the pre-equalizer MIB from the CM as they are representing the same plant characteristic. 3. Equalization MIBS from the CMTS when Pre-equalization is ON - These have no significant value other than seeing if pre-equalization is operating properly. When pre-equalization is operating properly then the CMTS should see little or no plant distortion and the equalizer coefficients should be close to all-zeros except for the main tap for all modems. Hal ------------------------ David Hull -Conexant=20 With regard to #1, the definition in Fig 6-22 of the DOCSIS 1.1 spec that Andre referred to seems good enough but I would allow the number of taps per symbol to be defined independently for the forward section AND the reverse section just in case someone implemented the two sections with different tap spacing. Short of officially "specifying" the DS equalizer like we have done for the upstream one, I don't see too much more that could be done. ------------------------ Hal Roberts - ADC=20 Dave, =20 It may be elsewhere in the spec or it may be obvious but I think we need to have more detail, for example the numbers should be represented in a specific numerical format perhaps: =20 "Standard twos-complement format, from -32768 (0x8000) to 32767 (0x7FFF)" =20 as an example. =20 Hal ------------------------ =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 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Oct 18 17:59:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERzUI-00027P-C6; Tue, 18 Oct 2005 17:59:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERzUG-00027G-Ez for ipcdn@megatron.ietf.org; Tue, 18 Oct 2005 17:59:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02754 for ; Tue, 18 Oct 2005 17:59:04 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERzfp-0005w2-Eu for ipcdn@ietf.org; Tue, 18 Oct 2005 18:11:12 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j9ILwxkN013507 for ; Tue, 18 Oct 2005 15:58:59 -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] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Date: Tue, 18 Oct 2005 15:58:59 -0600 Message-ID: Thread-Topic: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Thread-Index: AcWkSL5Ywu1ad9A3S76MtFLa52WFRAADmRVwCcspCxACKqCEIA== From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Folks, I haven't received any comments on the clarifications requested (dated 10/07, enclosed in this email). Can I assume acceptance (status quo) on #1 and #2?=20 Other than the clarifications, I am planning to check with the co-authors (and others in IPCDN) about Greg's comments regarding the MIB structure not conforming to the recommendations of RFC4181. The rest I believe, have been addressed as recommended. Pending any other last minute comments, I plan to submit draft-05 by the end of this work-week (to meet the deadline). - S -----Original Message----- From: Sumanth Channabasappa=20 Sent: Friday, October 07, 2005 3:21 PM To: Eugene Nechamkin; Randy Presuhn; ipcdn@ietf.org Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Greg, Randy, Eugene, Thanks for the comments. A few clarifications inline: #1: - The description makes mention of throttling events using SNMP and Syslog. What about the local log? Are events written to the local log not subject to throttling? =20 [s] The objective of the MIB Objects belonging to 'pktcDevEventThrottle' was to limit the throttling of events to the network (esp. in power-up-after-a-blackout scenario), not locally. Regarding local logging of events: - the MTAs are currently required to store 2^31 events (in the local log) and if we have questions regarding the size we should change the index value 'pktcDevEvLogIndex' (suggestions anyone, MTA vendors?) - Further, if we want to throttle local logging, we should probably define a new MIB Object for local events only (since the throttling conditions would vary between network and local storage) - thoughts? #2: - pktcDevEventDescrText and pktcDevEventDescrClass - These objects are read-write. It seems odd to me that these objects would be writable. Is it really intended that these are writable objects? [s] Yes, this is intended since an operator could change the 'Description of an event' to better suit 'Operational specific values' (via SNMP or by using the configuration file at bootstrapping time). E.g. MSO XYZ could change a lengthy description such as 'Error in TFTP response to the MTA due to XYZ' into a shortened string such as 'TFTP-ERR:XYZ'. >>> FYI <<< I am working on a couple of other comments, but the following (mostly from Greg and some internal) have been incorporated as-is: There are a number of places in the document that makes reference to "PacketCable device". Shouldn't this be "PacketCable or IPCablecom device"? Or more simply "MTA device". The naming convention we've been using on other MIB modules in IPCDN adds "-IETF-" to the module name to distinguish it from the corresponding MIB module being developed in CableLabs. So, it this case, the MIB module name should be something like "PKTC-IETF-EVENT-MIB". I think the ORGANIZATION clause should be IPCDN rather than CableLabs. The DESCRIPTION clause is missing the mandatory copyright notice. pktcDevEnvetReportStatus - The last sentence of the DESCRIPTION clause states "... Defined by PacketCable by default." Should this just PacketCable or PacketCable and IPCablecom. pktcDevEvThrottleAdminStatus - "A value of stopAtThreshold(3) causes event message transmission to cease at the threshold, and not resume until directed to do so." How is the device directed to resume sending event messages? pktcDevEvThrottleInterval - The DEFVAL clause should be on a separate line for readability. pktcDevEventDescrTable - Should the reference to "PacketCable" be "PacketCable/IPCablecom"? pktcDevEventDescrId - "The event identifier can either be PacketCable defined or vendor-specific." Would be good to provide a reference to the PacketCable spec where the events are defined. pktcDevEventDescrReporting - Should define what each one of the bit values mean. pktcDevEvLogCorrelationId - "...per section 5.4.5 of [3]" Reference [3] doesn't exist in the references section. pktcDevEvLogCorrelationId "This MIB Object contains the correlation ID=20 generated by the MTA during the initiation of the last provisioning flow, within or following which the event occurred.=20 For information on the generation of correlation ids, refer to the corresponding PacketCable/IPCableCom Device Provisioning specifications." [PKT-SP-EVEMIB1.5] - There is an odd character after the "PacketCable" Reference section - There are number of reference in the body of the text that do not exist in the references section. Need to make sure all reference are cited. The ones I found are PKT-SP-PROV, PKT-SP-MIB-MTA, PKT-SP-MGCP, RFC3435, PKT-SP-CODEC, and RFC2119. Security Considerations - Per the MIB Guidelines, need to explicit discuss all MIB objects, even if to only state that there are no security issues with the object. - There is no MIB Object defined as 'pktcDevEventThrottle 3' (we have MIB Objects for 2 and 4) - The Reference in the description of the MIB Object 'pktcDevEvLogCorrelationId' seems to be out of place. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Oct 18 22:00:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES3FM-0002eZ-40; Tue, 18 Oct 2005 22:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES3FL-0002e6-AT for ipcdn@megatron.ietf.org; Tue, 18 Oct 2005 22:00:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12780 for ; Tue, 18 Oct 2005 21:59:55 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES3Qy-0002go-Pk for ipcdn@ietf.org; Tue, 18 Oct 2005 22:12:05 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id j9J28w5m009632 for ; Tue, 18 Oct 2005 19:08:58 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j9J28lgd009855 for ; Tue, 18 Oct 2005 21:08:48 -0500 (CDT) Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id <40DGCM8S>; Tue, 18 Oct 2005 18:59:47 -0700 Message-ID: From: Nakanishi Greg-MGI8179 To: Sumanth Channabasappa , ipcdn@ietf.org Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Date: Tue, 18 Oct 2005 18:59:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Sumanth, Regarding item #1... Are MTAs really required to store 2^31 events? That seems like a lot. I'd be surprised that an MTA has that much memory. If it can store 2^31 events, I suppose throttling isn't as important. Otherwise, assuming memory is much more limited, I would think the ability to throttle is desirable. Having a separate object to control local throttling seems OK to me. greg -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Sumanth Channabasappa Sent: Tuesday, October 18, 2005 2:59 PM To: ipcdn@ietf.org Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Folks, I haven't received any comments on the clarifications requested (dated 10/07, enclosed in this email). Can I assume acceptance (status quo) on #1 and #2? Other than the clarifications, I am planning to check with the co-authors (and others in IPCDN) about Greg's comments regarding the MIB structure not conforming to the recommendations of RFC4181. The rest I believe, have been addressed as recommended. Pending any other last minute comments, I plan to submit draft-05 by the end of this work-week (to meet the deadline). - S -----Original Message----- From: Sumanth Channabasappa Sent: Friday, October 07, 2005 3:21 PM To: Eugene Nechamkin; Randy Presuhn; ipcdn@ietf.org Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Greg, Randy, Eugene, Thanks for the comments. A few clarifications inline: #1: - The description makes mention of throttling events using SNMP and Syslog. What about the local log? Are events written to the local log not subject to throttling? [s] The objective of the MIB Objects belonging to 'pktcDevEventThrottle' was to limit the throttling of events to the network (esp. in power-up-after-a-blackout scenario), not locally. Regarding local logging of events: - the MTAs are currently required to store 2^31 events (in the local log) and if we have questions regarding the size we should change the index value 'pktcDevEvLogIndex' (suggestions anyone, MTA vendors?) - Further, if we want to throttle local logging, we should probably define a new MIB Object for local events only (since the throttling conditions would vary between network and local storage) - thoughts? #2: - pktcDevEventDescrText and pktcDevEventDescrClass - These objects are read-write. It seems odd to me that these objects would be writable. Is it really intended that these are writable objects? [s] Yes, this is intended since an operator could change the 'Description of an event' to better suit 'Operational specific values' (via SNMP or by using the configuration file at bootstrapping time). E.g. MSO XYZ could change a lengthy description such as 'Error in TFTP response to the MTA due to XYZ' into a shortened string such as 'TFTP-ERR:XYZ'. >>> FYI <<< I am working on a couple of other comments, but the following (mostly from Greg and some internal) have been incorporated as-is: There are a number of places in the document that makes reference to "PacketCable device". Shouldn't this be "PacketCable or IPCablecom device"? Or more simply "MTA device". The naming convention we've been using on other MIB modules in IPCDN adds "-IETF-" to the module name to distinguish it from the corresponding MIB module being developed in CableLabs. So, it this case, the MIB module name should be something like "PKTC-IETF-EVENT-MIB". I think the ORGANIZATION clause should be IPCDN rather than CableLabs. The DESCRIPTION clause is missing the mandatory copyright notice. pktcDevEnvetReportStatus - The last sentence of the DESCRIPTION clause states "... Defined by PacketCable by default." Should this just PacketCable or PacketCable and IPCablecom. pktcDevEvThrottleAdminStatus - "A value of stopAtThreshold(3) causes event message transmission to cease at the threshold, and not resume until directed to do so." How is the device directed to resume sending event messages? pktcDevEvThrottleInterval - The DEFVAL clause should be on a separate line for readability. pktcDevEventDescrTable - Should the reference to "PacketCable" be "PacketCable/IPCablecom"? pktcDevEventDescrId - "The event identifier can either be PacketCable defined or vendor-specific." Would be good to provide a reference to the PacketCable spec where the events are defined. pktcDevEventDescrReporting - Should define what each one of the bit values mean. pktcDevEvLogCorrelationId - "...per section 5.4.5 of [3]" Reference [3] doesn't exist in the references section. pktcDevEvLogCorrelationId "This MIB Object contains the correlation ID generated by the MTA during the initiation of the last provisioning flow, within or following which the event occurred. For information on the generation of correlation ids, refer to the corresponding PacketCable/IPCableCom Device Provisioning specifications." [PKT-SP-EVEMIB1.5] - There is an odd character after the "PacketCable" Reference section - There are number of reference in the body of the text that do not exist in the references section. Need to make sure all reference are cited. The ones I found are PKT-SP-PROV, PKT-SP-MIB-MTA, PKT-SP-MGCP, RFC3435, PKT-SP-CODEC, and RFC2119. Security Considerations - Per the MIB Guidelines, need to explicit discuss all MIB objects, even if to only state that there are no security issues with the object. - There is no MIB Object defined as 'pktcDevEventThrottle 3' (we have MIB Objects for 2 and 4) - The Reference in the description of the MIB Object 'pktcDevEvLogCorrelationId' seems to be out of place. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Oct 18 22:32:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES3kp-0001EY-9Q; Tue, 18 Oct 2005 22:32:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES3ko-0001ET-2r for ipcdn@megatron.ietf.org; Tue, 18 Oct 2005 22:32:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14278 for ; Tue, 18 Oct 2005 22:32:26 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES3wQ-0003Qq-LS for ipcdn@ietf.org; Tue, 18 Oct 2005 22:44:36 -0400 Received: from h-68-165-2-93.snvacaid.dynamic.covad.net ([68.165.2.93] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1ES3kk-00056X-00 for ipcdn@ietf.org; Tue, 18 Oct 2005 22:32:30 -0400 Message-ID: <029901c5d455$db8bad40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Date: Tue, 18 Oct 2005 19:36:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Hi - > From: "Sumanth Channabasappa" > To: > Sent: Tuesday, October 18, 2005 2:58 PM > Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt ... > I haven't received any comments on the clarifications requested (dated > 10/07, enclosed in this email). Can I assume acceptance (status quo) on > #1 and #2? You must have missed my response from two months ago: |From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of |Randy Presuhn |Sent: Thursday, August 18, 2005 3:59 PM |To: ipcdn@ietf.org |Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt | |Hi - | |> From: "Sumanth Channabasappa" |> To: "Jean-Francois Mule" ; "Nakanishi |> Greg-MGI8179" ; |> Sent: Thursday, August 18, 2005 11:46 AM |> Subject: RE: [ipcdn] Comments on |> draft-ietf-ipcdn-pktc-eventmess-04.txt |... |> 8) pktcDevEvThrottleAdminStatus |> - The description makes mention of throttling events using SNMP and |> Syslog. What about the local log? Are events written to the local |> log not subject to throttling? |... | |I'd suggest that if we don't leave it up to the implementation, that it would |be best for throttling to affect all destinations equally. Swamped logs are |the same kind of problem, whether on the local system or a remote one. | |Randy The code issuing a notification, which is where the DESCRIPTION clause would lead implementors to put the throttling logic, would in a reasonably modular environment have no knowledge of whether it is going to a local log, delivery over some protocol, or whatever. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Oct 19 12:35:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESGuX-0008TR-LG; Wed, 19 Oct 2005 12:35:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESGuW-0008TM-O8 for ipcdn@megatron.ietf.org; Wed, 19 Oct 2005 12:35:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27235 for ; Wed, 19 Oct 2005 12:35:19 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESH6I-0000SA-C9 for ipcdn@ietf.org; Wed, 19 Oct 2005 12:47:38 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j9JGZ9B9025686; Wed, 19 Oct 2005 10:35:10 -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: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfUpchannelStatus Date: Wed, 19 Oct 2005 10:35:09 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F0117926B@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfUpchannelStatus Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKAACga3IALAdxt0A== From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Content-Transfer-Encoding: quoted-printable Cc: "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org IPCDN participants,=20 Bert W. and Randy P. in their review of the RFI MIB pointed a non-standard behavior for the defined cloning mechanism of upstream Interfaces:=20 Please review the draft changes below My intention is to publish a draft this weekend so it will be available for review of the Vancouver IETF meeting, any comments are welcome - I will work on other edits and formats Issue: After clonningFrom a temporary interface ( which never comes active)=20 The MIB requires to set the Update object to 'true' and update the target physical interface The problem IETF sees is that a non-active rows are non-existing rows, therefore the update set to copy back the parameters to the physical interface is not conventional approach (not visible to use such parameters) Based on internal emails with Bert and Jean-Francois, it was suggested to add an extra step in the process after the cloneFrom command and parameters are adjusted: A set to RowStatus 'active' will validate that the values are acceptable for the target physical interface, then the update 'true' command is executed to copy the parameters from the temporary interface to the physical interface Finally the manager can delete the temporary entry with a RowStatus set to 'destroy' Also a new descriptive section 3.1.5 was added to present the offline upstream parameters handling =20 Below are the snapshots of the changes: =20 3.1.5. Offline Upstream Parameters Handling 3.1.5.1. Overview This section describes the offline configuration of the DOCSIS 2.0 upstream logical interface parameters. The purpose of this feature is to guarantee that upstream logical interface parameters such as modulation profile, channel type, mini-slot Size and SCDMA attributes are consistent prior to commit changes to an active upstream logical interface. This mechanism can reduce possible downtime of the upstream interface by minimizing SNMP SET operations to in-service upstream interfaces. This mechanism is supported by CMTSs and is not applicable to CMs. 3.1.5.2. Operation This mechanism uses three upstream channel MIB objects defined for DOCSIS 2.0 CMTS implementations: docsIfUpChannelStatus - The RowStatus object for the creation of temporary interfaces in the upstream interface table. A temporary entry is used to modify, validate and commit upstream parameters of a physical interface. In the CMTS, a physical upstream interfaces refers to an upstream logical channels interfaces. docsIfUpChannelCloneFrom - This object has the function to associate a physical interface with a temporary interface with the purpose of updating the upstream parameters of the physical interface. docsIfUpChannelUpdate - This object is the commit object that transfer the validated upstream parameters from the temporary interface to the physical interface. The offline upstream parameters handling operation is as follows: o A temporary interface is create with docsIfUpChannelStatus set to 'createAndWait', which turns the new create entry status to 'notReady'. o A SET to docsIfUpChannelCloneFrom in the temporary interface to the physical interface ifIndex value performs two actions: * Create the association of the physical interface to the temporary interface. * Copy the original upstream parameters from the physical interface to the temporary interface which turns its status to 'notInService'. o The operator modifies the temporary interface parameters to the desired values. o At this point, a SET to 'active' to the RowStatus of the temporary interface is successful if all parameters in the temporary interface are valid for the associated physical interface; otherwise, the temporary entry remains with status 'notInservice' and the SET returns error 'commitFailed'. o When the temporary interface status is 'active' a SET to docsIfUpChannelUpdate to 'true' transfer the temporary interface parameters values to the physical interface. o After completion of the update operations, the temporary interface is destroyed setting the docsIfUpChannelStatus to 'destroy'. 3.1.5.3. Relation of docsIfUpChannelStatus and ifMib The main purpose of docsIfUpChannelStatus is the creation of temporary interfaces for offline handling of the configuration of physical interfaces; It does not manage the creation or control of physical interfaces. To maintain a consistent operation and status report of interfaces, this object does not control or reflect administrative and operational status of the physical interfaces. ----------------- =20 Then the Objects changes:=20 Entry=20 CloneFrom Update Status docsIfUpstreamChannelEntry OBJECT-TYPE SYNTAX DocsIfUpstreamChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "List of attributes for a single upstream channel. For DOCSIS 2.0 CMTSs, an entry in this table exists for each ifEntry with an ifType of docsCableUpstreamChannel (205). For DOCSIS 1.x CM/CMTSs and DOCSIS 2.0 CMs, an entry in this table exists for each ifEntry with an ifType of docsCableUpstream (129). For DOCSIS 2.0 CMTSs two classes of interfaces can be defined for this table: o Upstream Physical Interfaces: The traditional DOCSIS 1.x CMTS upstream interface ifType 129 and the DOCSIS 2.0 ifType 205 that are functional. In other words, interfaces that represents upstream receivers within an RF MAC interface. Entries of physical interfaces are exposed to the management interface with their corresponding ifStack hierarchy and are not administratively created by this table. o Upstream Temporary Interfaces: A fictitious interface created with the purpose of manipulating the parameters of a physical interface parameters offline, then validate values consistency prior to update the target physical interface. This mechanism helps to minimize service disruption originated in situations where a group of interface parameters values need to be inconsistent each other in SET operations. Instead, a temporary buffer (temporary interface) is provided to allow the CMTS to validate the parameters offline." INDEX { ifIndex } ::=3D { docsIfUpstreamChannelTable 1 } docsIfUpChannelCloneFrom OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "Intended for use when a temporary upstream row entry is created to manipulate and update parameters of a physical interface. This object contains the ifIndex value of the physical interface row entry whose parameters are to be adjusted. Upon setting this object to the ifIndex value of a physical interface the values of the objects listed below from the ifIndex referenced are copied to this entry: docsIfUpChannelFrequency, docsIfUpChannelWidth, docsIfUpChannelModulationProfile, docsIfUpChannelSlotSize, docsIfUpChannelRangingBackoffStart, docsIfUpChannelRangingBackoffEnd, docsIfUpChannelTxBackoffStart, docsIfUpChannelTxBackoffEnd, docsIfUpChannelScdmaActiveCodes, docsIfUpChannelScdmaCodesPerSlot, docsIfUpChannelScdmaFrameSize, docsIfUpChannelScdmaHoppingSeed, docsIfUpChannelType, and docsIfUpChannelPreEqEnable Setting this object to a non-existent or temporary upstream returns an error 'wrongValue'. This object MUST contain a value of zero for physical interfaces entries." ::=3D { docsIfUpstreamChannelEntry 16 } docsIfUpChannelUpdate OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Used to perform the copy of adjusted parameters from the temporary upstream row to the physical upstream row indicated by the docsIfUpChannelCloneFrom object. The transfer is initiated through an SNMP SET to 'true' of this object. A failed SET to 'true' returns error 'commitFailed' if docsIfUpChannelStatus value is 'notInService', which means, the adjusted parameter values are not compatible each other or had not been yet validated. Reading this object always return 'false'." ::=3D { docsIfUpstreamChannelEntry 17 } docsIfUpChannelStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is only used for the creation of a temporary upstream row with the purpose of adjusting channel parameters of a physical upstream channel entry. The following restrictions apply to this object: 1. This object is not writable for physical interfaces. 2. Temporary interface entries are created only by SET to RowStatus createandWait(5). 3. ifAdminStatus from the Interface MIB RFC 2863 is used to take a physical upstream channel offline consistent with DOCSIS 1.x operation indicated in RFC 2670. In addition: o ifAdminStatus 'down' is reflected in this object as status 'notInService'. o ifOperSatus 'down' while ifAdminStatus 'up' is reflected in this object as status 'notInservice'. 4. Temporary created rows MUST be set to 'active' with the purpose of validate the upstream parameters consistency prior to transfer the parameters to the physical interface. 5. Temporary entries MUST NOT persist at reinitialization of the managed system. Below is a mandatory procedure for adjusting an upstream physical interface : 1. Create a temporary interface entry through an SNMP SET using 'createAndWait'. At this point, the RowStatus report a value 'notReady'. Manager entity uses an ifIndex value outside the operational range of the managed system for temporary interfaces. 2. Set the docsIfUpChannelCloneFrom object to the ifIndex value of the physical row whose parameters require adjustment. Now docsIfUpChannelStatus reports 'notInService'. 3. Adjust the parameter values using the new temporary row. 4. Validate that all parameters are consistent by setting docsIfUpChannelStatus to 'active'. A Failure to set the RowStatus to 'active' returns error 'commitFailed' which means the parameters are not compatible with the target physical interface. 5. With docsIfUpChannelStatus 'active' trasfer the parameters to the target physical interface by setting the object docsIfUpChannelUpdate to 'true' 5. Delete the temporary row with a SET to docsIfUpChannelStatus to 'destroy'." ::=3D { docsIfUpstreamChannelEntry 18 } -- Compliance statements set back to similar wording as D-12=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Oct 19 13:08:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHQI-0004ZA-JT; Wed, 19 Oct 2005 13:08:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHQC-0004VS-SD for ipcdn@megatron.ietf.org; Wed, 19 Oct 2005 13:08:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29050 for ; Wed, 19 Oct 2005 13:08:02 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESHbx-0001PC-9z for ipcdn@ietf.org; Wed, 19 Oct 2005 13:20:21 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j9JH81FL006296; Wed, 19 Oct 2005 11:08: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Date: Wed, 19 Oct 2005 11:08:01 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F01179298@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Thread-Index: AcXUUUbS/FC+lQtZQ9iw/Sk5/rrd+gAfe0eQ From: "Eduardo Cardona" To: "Nakanishi Greg-MGI8179" , "Sumanth Channabasappa" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Normally the open maximum size is used to indicate that entries can use any index number, it does not indicate the maximum size, It means 2^32 -1 really indicates that the size is vendor dependent. Whatever value is good in size today it might not be for a different size product ( e.g. consider DHCP leases for a home residential gateway vs a ISP DHCP server) what is the index boundary ?=20 Product specifications should be the ones to carry MAX physical table sizes not the MIB specification though. Eduardo -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com]=20 Sent: Tuesday, October 18, 2005 8:00 PM To: Sumanth Channabasappa; ipcdn@ietf.org Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Sumanth, Regarding item #1... Are MTAs really required to store 2^31 events? That seems like a lot. I'd be surprised that an MTA has that much memory.=20 If it can store 2^31 events, I suppose throttling isn't as important. Otherwise, assuming memory is much more limited, I would think the ability to throttle is desirable. Having a separate object to control local throttling seems OK to me. greg =20 -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Sumanth Channabasappa Sent: Tuesday, October 18, 2005 2:59 PM To: ipcdn@ietf.org Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Folks, I haven't received any comments on the clarifications requested (dated 10/07, enclosed in this email). Can I assume acceptance (status quo) on #1 and #2?=20 Other than the clarifications, I am planning to check with the co-authors (and others in IPCDN) about Greg's comments regarding the MIB structure not conforming to the recommendations of RFC4181. The rest I believe, have been addressed as recommended. Pending any other last minute comments, I plan to submit draft-05 by the end of this work-week (to meet the deadline). - S -----Original Message----- From: Sumanth Channabasappa Sent: Friday, October 07, 2005 3:21 PM To: Eugene Nechamkin; Randy Presuhn; ipcdn@ietf.org Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Greg, Randy, Eugene, Thanks for the comments. A few clarifications inline: #1: - The description makes mention of throttling events using SNMP and Syslog. What about the local log? Are events written to the local log not subject to throttling? =20 [s] The objective of the MIB Objects belonging to 'pktcDevEventThrottle' was to limit the throttling of events to the network (esp. in power-up-after-a-blackout scenario), not locally. Regarding local logging of events: - the MTAs are currently required to store 2^31 events (in the local log) and if we have questions regarding the size we should change the index value 'pktcDevEvLogIndex' (suggestions anyone, MTA vendors?) - Further, if we want to throttle local logging, we should probably define a new MIB Object for local events only (since the throttling conditions would vary between network and local storage) - thoughts? #2: - pktcDevEventDescrText and pktcDevEventDescrClass - These objects are read-write. It seems odd to me that these objects would be writable. Is it really intended that these are writable objects? [s] Yes, this is intended since an operator could change the 'Description of an event' to better suit 'Operational specific values' (via SNMP or by using the configuration file at bootstrapping time). E.g. MSO XYZ could change a lengthy description such as 'Error in TFTP response to the MTA due to XYZ' into a shortened string such as 'TFTP-ERR:XYZ'. >>> FYI <<< I am working on a couple of other comments, but the following (mostly from Greg and some internal) have been incorporated as-is: There are a number of places in the document that makes reference to "PacketCable device". Shouldn't this be "PacketCable or IPCablecom device"? Or more simply "MTA device". The naming convention we've been using on other MIB modules in IPCDN adds "-IETF-" to the module name to distinguish it from the corresponding MIB module being developed in CableLabs. So, it this case, the MIB module name should be something like "PKTC-IETF-EVENT-MIB". I think the ORGANIZATION clause should be IPCDN rather than CableLabs. The DESCRIPTION clause is missing the mandatory copyright notice. pktcDevEnvetReportStatus - The last sentence of the DESCRIPTION clause states "... Defined by PacketCable by default." Should this just PacketCable or PacketCable and IPCablecom. pktcDevEvThrottleAdminStatus - "A value of stopAtThreshold(3) causes event message transmission to cease at the threshold, and not resume until directed to do so." How is the device directed to resume sending event messages? pktcDevEvThrottleInterval - The DEFVAL clause should be on a separate line for readability. pktcDevEventDescrTable - Should the reference to "PacketCable" be "PacketCable/IPCablecom"? pktcDevEventDescrId - "The event identifier can either be PacketCable defined or vendor-specific." Would be good to provide a reference to the PacketCable spec where the events are defined. pktcDevEventDescrReporting - Should define what each one of the bit values mean. pktcDevEvLogCorrelationId - "...per section 5.4.5 of [3]" Reference [3] doesn't exist in the references section. pktcDevEvLogCorrelationId "This MIB Object contains the correlation ID=20 generated by the MTA during the initiation of the last provisioning flow, within or following which the event occurred.=20 For information on the generation of correlation ids, refer to the corresponding PacketCable/IPCableCom Device Provisioning specifications." [PKT-SP-EVEMIB1.5] - There is an odd character after the "PacketCable" Reference section - There are number of reference in the body of the text that do not exist in the references section. Need to make sure all reference are cited. The ones I found are PKT-SP-PROV, PKT-SP-MIB-MTA, PKT-SP-MGCP, RFC3435, PKT-SP-CODEC, and RFC2119. Security Considerations - Per the MIB Guidelines, need to explicit discuss all MIB objects, even if to only state that there are no security issues with the object. - There is no MIB Object defined as 'pktcDevEventThrottle 3' (we have MIB Objects for 2 and 4) - The Reference in the description of the MIB Object 'pktcDevEvLogCorrelationId' seems to be out of place. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Oct 19 13:22:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHdY-0001mz-6S; Wed, 19 Oct 2005 13:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHdV-0001mf-Rg for ipcdn@megatron.ietf.org; Wed, 19 Oct 2005 13:21:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29699 for ; Wed, 19 Oct 2005 13:21:48 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESHpH-0001mr-RJ for ipcdn@ietf.org; Wed, 19 Oct 2005 13:34:08 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j9JHLlD7009475; Wed, 19 Oct 2005 11:21:47 -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] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Date: Wed, 19 Oct 2005 11:21:47 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F011792A6@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Thread-Index: AcXUVYzYX5siWHngQ6aYfWhUc4n6sQAdqFyA From: "Eduardo Cardona" To: "Randy Presuhn" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org That is probably a problem inherited from RFC 2669 where those objects were derived docsDevEvThrottleAdminStatus OBJECT-TYPE SYNTAX INTEGER { unconstrained(1), maintainBelowThreshold(2), stopAtThreshold(3), inhibited(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "Controls the transmission of traps and syslog messages with respect to the trap pacing threshold.=20 .... I believe an event is throttle by the rate of events the system is handling not the manifestation of them as outputs (I think this is Randy's point)=20 Then, the dispatch flag (AND/OR local/syslog/snmp notif) is applied to whatever target protocols are intended after the event rate throttling In other words, throttling only regulates the rate of events to be handled over dispatchers, the manifestation of "events on the wire" depends on how targets are configured. As an example in SNMPv3 a notification may match in the snmpNotifyTable n targets as traps and/or informs: Some figures:=20 If you wan to throttle one event per minute and you have a match of 2 trap targets and 1 Inform target (receiver off) with 3 retries You can see up to 5 notifications on the wire per minute. ( not the 1 per minute you have though it will) =20 Unfortunately RFC 2669 had a monolithic perception of things and was before SNMPv3 multiple targets were adopted. We didn't mentioned in DOCSIS what happen with local log explicitly probably following the rationale of the Throttle MIB objects, but I believe that is inappropriate. There is no MUST requirements that says local-log events MUST not be throttle. , so that's probably the rationale of leave local-log throttle as vendor dependent (?)=20 Or just normalize explicitly the requirement for local-log also be throttled ( I can think on that option as my preference, others may have a different perception) Eduardo =20 -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Tuesday, October 18, 2005 8:36 PM To: ipcdn@ietf.org Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Hi - > From: "Sumanth Channabasappa" > To: > Sent: Tuesday, October 18, 2005 2:58 PM > Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt ... > I haven't received any comments on the clarifications requested (dated > 10/07, enclosed in this email). Can I assume acceptance (status quo) on > #1 and #2?=20 You must have missed my response from two months ago: |From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of |Randy Presuhn |Sent: Thursday, August 18, 2005 3:59 PM |To: ipcdn@ietf.org |Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt | |Hi - | |> From: "Sumanth Channabasappa" |> To: "Jean-Francois Mule" ; "Nakanishi=20 |> Greg-MGI8179" ; |> Sent: Thursday, August 18, 2005 11:46 AM |> Subject: RE: [ipcdn] Comments on=20 |> draft-ietf-ipcdn-pktc-eventmess-04.txt |... |> 8) pktcDevEvThrottleAdminStatus |> - The description makes mention of throttling events using SNMP and=20 |> Syslog. What about the local log? Are events written to the local=20 |> log not subject to throttling? |... | |I'd suggest that if we don't leave it up to the implementation, that it would |be best for throttling to affect all destinations equally. Swamped logs are |the same kind of problem, whether on the local system or a remote one. | |Randy The code issuing a notification, which is where the DESCRIPTION clause would lead implementors to put the throttling logic, would in a reasonably modular environment have no knowledge of whether it is going to a local log, delivery over some protocol, or whatever. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Oct 19 15:37:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJkq-0004rM-W3; Wed, 19 Oct 2005 15:37:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJkp-0004q8-3N for ipcdn@megatron.ietf.org; Wed, 19 Oct 2005 15:37:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08835 for ; Wed, 19 Oct 2005 15:37:27 -0400 (EDT) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESJwa-0006GX-Ep for ipcdn@ietf.org; Wed, 19 Oct 2005 15:49:48 -0400 Received: from h-64-105-136-185.snvacaid.dynamic.covad.net ([64.105.136.185] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1ESJkj-0001pM-00 for ipcdn@ietf.org; Wed, 19 Oct 2005 15:37:33 -0400 Message-ID: <006701c5d4e5$0f5d4fe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <5259D0D7419C6149B347837A2E64F46F01179298@srvxchg.cablelabs.com> Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Date: Wed, 19 Oct 2005 12:41:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Content-Transfer-Encoding: 7bit X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Hi - If you really want to model log behaviour, I suggest using http://www.ietf.org/rfc/rfc3014.txt or at least borrowing its concepts. Randy ----- Original Message ----- From: "Eduardo Cardona" To: "Nakanishi Greg-MGI8179" ; "Sumanth Channabasappa" ; Sent: Wednesday, October 19, 2005 10:08 AM Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Normally the open maximum size is used to indicate that entries can use any index number, it does not indicate the maximum size, It means 2^32 -1 really indicates that the size is vendor dependent. Whatever value is good in size today it might not be for a different size product ( e.g. consider DHCP leases for a home residential gateway vs a ISP DHCP server) what is the index boundary ? Product specifications should be the ones to carry MAX physical table sizes not the MIB specification though. Eduardo -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] Sent: Tuesday, October 18, 2005 8:00 PM To: Sumanth Channabasappa; ipcdn@ietf.org Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Sumanth, Regarding item #1... Are MTAs really required to store 2^31 events? That seems like a lot. I'd be surprised that an MTA has that much memory. If it can store 2^31 events, I suppose throttling isn't as important. Otherwise, assuming memory is much more limited, I would think the ability to throttle is desirable. Having a separate object to control local throttling seems OK to me. greg -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Sumanth Channabasappa Sent: Tuesday, October 18, 2005 2:59 PM To: ipcdn@ietf.org Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Folks, I haven't received any comments on the clarifications requested (dated 10/07, enclosed in this email). Can I assume acceptance (status quo) on #1 and #2? Other than the clarifications, I am planning to check with the co-authors (and others in IPCDN) about Greg's comments regarding the MIB structure not conforming to the recommendations of RFC4181. The rest I believe, have been addressed as recommended. Pending any other last minute comments, I plan to submit draft-05 by the end of this work-week (to meet the deadline). - S -----Original Message----- From: Sumanth Channabasappa Sent: Friday, October 07, 2005 3:21 PM To: Eugene Nechamkin; Randy Presuhn; ipcdn@ietf.org Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Greg, Randy, Eugene, Thanks for the comments. A few clarifications inline: #1: - The description makes mention of throttling events using SNMP and Syslog. What about the local log? Are events written to the local log not subject to throttling? [s] The objective of the MIB Objects belonging to 'pktcDevEventThrottle' was to limit the throttling of events to the network (esp. in power-up-after-a-blackout scenario), not locally. Regarding local logging of events: - the MTAs are currently required to store 2^31 events (in the local log) and if we have questions regarding the size we should change the index value 'pktcDevEvLogIndex' (suggestions anyone, MTA vendors?) - Further, if we want to throttle local logging, we should probably define a new MIB Object for local events only (since the throttling conditions would vary between network and local storage) - thoughts? #2: - pktcDevEventDescrText and pktcDevEventDescrClass - These objects are read-write. It seems odd to me that these objects would be writable. Is it really intended that these are writable objects? [s] Yes, this is intended since an operator could change the 'Description of an event' to better suit 'Operational specific values' (via SNMP or by using the configuration file at bootstrapping time). E.g. MSO XYZ could change a lengthy description such as 'Error in TFTP response to the MTA due to XYZ' into a shortened string such as 'TFTP-ERR:XYZ'. >>> FYI <<< I am working on a couple of other comments, but the following (mostly from Greg and some internal) have been incorporated as-is: There are a number of places in the document that makes reference to "PacketCable device". Shouldn't this be "PacketCable or IPCablecom device"? Or more simply "MTA device". The naming convention we've been using on other MIB modules in IPCDN adds "-IETF-" to the module name to distinguish it from the corresponding MIB module being developed in CableLabs. So, it this case, the MIB module name should be something like "PKTC-IETF-EVENT-MIB". I think the ORGANIZATION clause should be IPCDN rather than CableLabs. The DESCRIPTION clause is missing the mandatory copyright notice. pktcDevEnvetReportStatus - The last sentence of the DESCRIPTION clause states "... Defined by PacketCable by default." Should this just PacketCable or PacketCable and IPCablecom. pktcDevEvThrottleAdminStatus - "A value of stopAtThreshold(3) causes event message transmission to cease at the threshold, and not resume until directed to do so." How is the device directed to resume sending event messages? pktcDevEvThrottleInterval - The DEFVAL clause should be on a separate line for readability. pktcDevEventDescrTable - Should the reference to "PacketCable" be "PacketCable/IPCablecom"? pktcDevEventDescrId - "The event identifier can either be PacketCable defined or vendor-specific." Would be good to provide a reference to the PacketCable spec where the events are defined. pktcDevEventDescrReporting - Should define what each one of the bit values mean. pktcDevEvLogCorrelationId - "...per section 5.4.5 of [3]" Reference [3] doesn't exist in the references section. pktcDevEvLogCorrelationId "This MIB Object contains the correlation ID generated by the MTA during the initiation of the last provisioning flow, within or following which the event occurred. For information on the generation of correlation ids, refer to the corresponding PacketCable/IPCableCom Device Provisioning specifications." [PKT-SP-EVEMIB1.5] - There is an odd character after the "PacketCable" Reference section - There are number of reference in the body of the text that do not exist in the references section. Need to make sure all reference are cited. The ones I found are PKT-SP-PROV, PKT-SP-MIB-MTA, PKT-SP-MGCP, RFC3435, PKT-SP-CODEC, and RFC2119. Security Considerations - Per the MIB Guidelines, need to explicit discuss all MIB objects, even if to only state that there are no security issues with the object. - There is no MIB Object defined as 'pktcDevEventThrottle 3' (we have MIB Objects for 2 and 4) - The Reference in the description of the MIB Object 'pktcDevEvLogCorrelationId' seems to be out of place. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Oct 19 16:25:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESKN9-0007ch-7v; Wed, 19 Oct 2005 16:17:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESKN6-0007cA-TR for ipcdn@megatron.ietf.org; Wed, 19 Oct 2005 16:17:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17977 for ; Wed, 19 Oct 2005 16:17:02 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESKYt-0001Z1-83 for ipcdn@ietf.org; Wed, 19 Oct 2005 16:29:24 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j9JKH1Fe027597 for ; Wed, 19 Oct 2005 14:17: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Date: Wed, 19 Oct 2005 14:17:00 -0600 Message-ID: Thread-Topic: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Thread-Index: AcXUVXaAMVA8PYDhTpqKu7vSnwKcCgAaPjpA From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Randy, Thanks and no, I did not miss your response. However, the MIB is geared towards 'management events' (and their management) and the resulting 'notifications' are only a reporting feature. Thus, MTAs are required to: - store all relevant event information in the logs (storage allowing) - send only critical (or desired) notifications, created upon event generation to the external systems (syslog, SNMP) Now, implementations could, as you suggested, have notifications generated agnostic of the destination.=20 However, in this case, the 'event generation and storage' is required (it may overwrite earlier events, but current events are always stored), with an option to convert them into 'notifications', if configured.=20 Further, given the disparity between the Service Provider Network elements (few) and the clients on which this MIB will be implemented(many), the throttling requirements for 'notifications sent to the network' were imposed. Currently, there has been no intention or requirement to throttle events that can be stored locally. Thanks for the pointer on RFC3014 - I shall take a look at it and see if we can borrow any concepts. Greg, Barring the max size discussion (I should have clarified further, thanks Eduardo), do we really see a need for throttling local events (would it serve any purpose if the latest events are always stored)? =20 - S -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Tuesday, October 18, 2005 8:36 PM To: ipcdn@ietf.org Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Hi - > From: "Sumanth Channabasappa" > To: > Sent: Tuesday, October 18, 2005 2:58 PM > Subject: RE: [ipcdn] Comments on=20 > draft-ietf-ipcdn-pktc-eventmess-04.txt ... > I haven't received any comments on the clarifications requested (dated > 10/07, enclosed in this email). Can I assume acceptance (status quo)=20 > on > #1 and #2?=20 You must have missed my response from two months ago: |From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf=20 |Of Randy Presuhn |Sent: Thursday, August 18, 2005 3:59 PM |To: ipcdn@ietf.org |Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt | |Hi - | |> From: "Sumanth Channabasappa" |> To: "Jean-Francois Mule" ; "Nakanishi=20 |> Greg-MGI8179" ; |> Sent: Thursday, August 18, 2005 11:46 AM |> Subject: RE: [ipcdn] Comments on |> draft-ietf-ipcdn-pktc-eventmess-04.txt |... |> 8) pktcDevEvThrottleAdminStatus |> - The description makes mention of throttling events using SNMP and=20 |> Syslog. What about the local log? Are events written to the local=20 |> log not subject to throttling? |... | |I'd suggest that if we don't leave it up to the implementation, that it |would be best for throttling to affect all destinations equally. =20 |Swamped logs are the same kind of problem, whether on the local system or a remote one. | |Randy The code issuing a notification, which is where the DESCRIPTION clause would lead implementors to put the throttling logic, would in a reasonably modular environment have no knowledge of whether it is going to a local log, delivery over some protocol, or whatever. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Oct 19 17:18:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESLKD-0002F2-I2; Wed, 19 Oct 2005 17:18:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESLKC-0002Em-7b for ipcdn@megatron.ietf.org; Wed, 19 Oct 2005 17:18:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04378 for ; Wed, 19 Oct 2005 17:18:07 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESLW0-0007zn-9s for ipcdn@ietf.org; Wed, 19 Oct 2005 17:30:28 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id j9JLI9Hv010914 for ; Wed, 19 Oct 2005 14:18:10 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j9JLRAc8020935 for ; Wed, 19 Oct 2005 16:27:10 -0500 (CDT) Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id <40DGCX6V>; Wed, 19 Oct 2005 14:18:07 -0700 Message-ID: From: Nakanishi Greg-MGI8179 To: Sumanth Channabasappa , ipcdn@ietf.org Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Date: Wed, 19 Oct 2005 14:18:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Sumanth, My opinion is that throttling should to be supported for the local log. If the local log is small, there is a potential for the log to get filled up with a flood of events and earlier events that may be important for analysis gets overwritten. That being said, I can see that historically (in DOCSIS and PacketCable) local log throttling was not specified. I don't have particularly strong feelings about this, but I think local log throttling would be a desirable feature. greg -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Sumanth Channabasappa Sent: Wednesday, October 19, 2005 1:17 PM To: ipcdn@ietf.org Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Randy, Thanks and no, I did not miss your response. However, the MIB is geared towards 'management events' (and their management) and the resulting 'notifications' are only a reporting feature. Thus, MTAs are required to: - store all relevant event information in the logs (storage allowing) - send only critical (or desired) notifications, created upon event generation to the external systems (syslog, SNMP) Now, implementations could, as you suggested, have notifications generated agnostic of the destination. However, in this case, the 'event generation and storage' is required (it may overwrite earlier events, but current events are always stored), with an option to convert them into 'notifications', if configured. Further, given the disparity between the Service Provider Network elements (few) and the clients on which this MIB will be implemented(many), the throttling requirements for 'notifications sent to the network' were imposed. Currently, there has been no intention or requirement to throttle events that can be stored locally. Thanks for the pointer on RFC3014 - I shall take a look at it and see if we can borrow any concepts. Greg, Barring the max size discussion (I should have clarified further, thanks Eduardo), do we really see a need for throttling local events (would it serve any purpose if the latest events are always stored)? - S -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 18, 2005 8:36 PM To: ipcdn@ietf.org Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Hi - > From: "Sumanth Channabasappa" > To: > Sent: Tuesday, October 18, 2005 2:58 PM > Subject: RE: [ipcdn] Comments on > draft-ietf-ipcdn-pktc-eventmess-04.txt ... > I haven't received any comments on the clarifications requested (dated > 10/07, enclosed in this email). Can I assume acceptance (status quo) > on > #1 and #2? You must have missed my response from two months ago: |From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf |Of Randy Presuhn |Sent: Thursday, August 18, 2005 3:59 PM |To: ipcdn@ietf.org |Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt | |Hi - | |> From: "Sumanth Channabasappa" |> To: "Jean-Francois Mule" ; "Nakanishi |> Greg-MGI8179" ; |> Sent: Thursday, August 18, 2005 11:46 AM |> Subject: RE: [ipcdn] Comments on |> draft-ietf-ipcdn-pktc-eventmess-04.txt |... |> 8) pktcDevEvThrottleAdminStatus |> - The description makes mention of throttling events using SNMP and |> Syslog. What about the local log? Are events written to the local |> log not subject to throttling? |... | |I'd suggest that if we don't leave it up to the implementation, that it |would be best for throttling to affect all destinations equally. |Swamped logs are the same kind of problem, whether on the local system or a remote one. | |Randy The code issuing a notification, which is where the DESCRIPTION clause would lead implementors to put the throttling logic, would in a reasonably modular environment have no knowledge of whether it is going to a local log, delivery over some protocol, or whatever. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 20 18:00:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESiSQ-0001Uy-Pv; Thu, 20 Oct 2005 18:00:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESiSO-0001Ua-W2 for ipcdn@megatron.ietf.org; Thu, 20 Oct 2005 18:00:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16412 for ; Thu, 20 Oct 2005 18:00:07 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESiRO-0008Iq-W9 for ipcdn@ietf.org; Thu, 20 Oct 2005 17:59:18 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j9KLkXYW021693; Thu, 20 Oct 2005 15:46: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:ADre-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:docsIfCmtsCmStatusEqualizationData& docsIfSigQEqualizationData Date: Thu, 20 Oct 2005 15:46:33 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F0117947D@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE:ADre-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:docsIfCmtsCmStatusEqualizationData& docsIfSigQEqualizationData Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKAACga3IAAAh6FUAACaROgB9+1Q8ABj7jfcAAuytRwAQxUCqAAJ1q4cABqGH8A From: "Eduardo Cardona" To: "Ipcdn (E-mail)" , "Wijnen, Bert (Bert)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Comments from a vendor Thanks Eduardo -----Original Message----- From: Brecher, Liran Sent: Wednesday, October 19, 2005 11:13 AM To: Eduardo Cardona Cc: Pollak, Lucy Subject: RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Eduardo, I would vote for a-2 are but a-1 is OK as well. Don't see a reason for a-3. Thanks, Liran a-1) Eduardo (Liran?) a-2) Liran a-3) b-1) b-2) Margo, Eduardo Options:=20 =3D=3D=3D=3D=3D=3D=3D=3D a-1) -- Add Main Tap DocsEqualizerData ::=3D TEXTUAL-CONVENTION 1 byte Main Tap Location 1 byte Number of forward taps per symbol 1 byte Number of reverse taps per symbol 1 byte Number of forward taps 1 byte Number of reverse taps =20 a-2) -- do not consider David Hull's flexibility for Reverse Coefficient spacing for DS equalizer: use straight DOCSIS 1.1 MAC message format DocsEqualizerData ::=3D TEXTUAL-CONVENTION 1 byte Main Tap Location 1 byte Number of forward taps per symbol 1 byte Number of forward taps 1 byte Number of reverse taps =20 a-3) Separate US and DS equalization "formalize DS equalizer format"=20 docsIfCmtsCmStatusEqualizationData OBJECT-TYPE SYNTAX DocsUpstreamEqualizerData docsIfSigQEqualizationData OBJECT-TYPE SYNTAX DocsDownstreamEqualizerData alternative b-1)=20 docsIfSigQEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. =20 At the CMTS, this object is not applicable and might return a zero-length OCTET STRING. Note that previous CMTS=20 implementations may instantiate this object in two ways: - An equalization value different of the zero-length octet string to indicate an equalization average for the upstream channel. Those values have vendor=20 dependent interpretation. - Return a zero-length OCTET STRING as described below. =20 A returned zero-length OCTET STRING indicate the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::=3D { docsIfSignalQualityEntry 7 } --Note: same compliance statements as in draft 13 alternative b-2)=20 docsIfSigQEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, returns the equalization data for the downstream channel. =20 At the CMTS, this object is not applicable and is not=20 instantiated. Note that previous CMTS implementations=20 may instantiate this object in two ways: - An equalization value different of the zero-length octet string to indicate an equalization average for the upstream channel. Those values have vendor=20 dependent interpretation. - Return a zero-length OCTET STRING as described below. =20 A returned zero-length OCTET STRING indicate the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::=3D { docsIfSignalQualityEntry 7 } _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 20 18:17:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESiix-00044C-Ey; Thu, 20 Oct 2005 18:17:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESiit-000436-QN for ipcdn@megatron.ietf.org; Thu, 20 Oct 2005 18:17:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17780 for ; Thu, 20 Oct 2005 18:17:06 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESirL-00036f-5O for ipcdn@ietf.org; Thu, 20 Oct 2005 18:26:03 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j9KMDRFv028998; Thu, 20 Oct 2005 16:13:28 -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] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Date: Thu, 20 Oct 2005 16:13:27 -0600 Message-ID: Thread-Topic: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Thread-Index: AcXU8pufgoRYhv1sRCmDcgvjcYVA2QA0NNEg From: "Sumanth Channabasappa" To: "Nakanishi Greg-MGI8179" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Greg, Thanks for the thoughts and unless vendors/implementors feel strongly about local throttling, I would be inclined to leave it out scope for now (akin to other IPCDN MIBs - as you rightly indicated).=20 - S=20 -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com]=20 Sent: Wednesday, October 19, 2005 3:18 PM To: Sumanth Channabasappa; ipcdn@ietf.org Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Sumanth, My opinion is that throttling should to be supported for the local log. If the local log is small, there is a potential for the log to get filled up with a flood of events and earlier events that may be important for analysis gets overwritten. =20 That being said, I can see that historically (in DOCSIS and PacketCable) local log throttling was not specified. I don't have particularly strong feelings about this, but I think local log throttling would be a desirable feature. greg -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Sumanth Channabasappa Sent: Wednesday, October 19, 2005 1:17 PM To: ipcdn@ietf.org Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Randy, Thanks and no, I did not miss your response. However, the MIB is geared towards 'management events' (and their management) and the resulting 'notifications' are only a reporting feature. Thus, MTAs are required to: - store all relevant event information in the logs (storage allowing) - send only critical (or desired) notifications, created upon event generation to the external systems (syslog, SNMP) Now, implementations could, as you suggested, have notifications generated agnostic of the destination.=20 However, in this case, the 'event generation and storage' is required (it may overwrite earlier events, but current events are always stored), with an option to convert them into 'notifications', if configured.=20 Further, given the disparity between the Service Provider Network elements (few) and the clients on which this MIB will be implemented(many), the throttling requirements for 'notifications sent to the network' were imposed. Currently, there has been no intention or requirement to throttle events that can be stored locally. Thanks for the pointer on RFC3014 - I shall take a look at it and see if we can borrow any concepts. Greg, Barring the max size discussion (I should have clarified further, thanks Eduardo), do we really see a need for throttling local events (would it serve any purpose if the latest events are always stored)? =20 - S -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 18, 2005 8:36 PM To: ipcdn@ietf.org Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Hi - > From: "Sumanth Channabasappa" > To: > Sent: Tuesday, October 18, 2005 2:58 PM > Subject: RE: [ipcdn] Comments on > draft-ietf-ipcdn-pktc-eventmess-04.txt ... > I haven't received any comments on the clarifications requested (dated > 10/07, enclosed in this email). Can I assume acceptance (status quo)=20 > on > #1 and #2?=20 You must have missed my response from two months ago: |From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf=20 |Of Randy Presuhn |Sent: Thursday, August 18, 2005 3:59 PM |To: ipcdn@ietf.org |Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt | |Hi - | |> From: "Sumanth Channabasappa" |> To: "Jean-Francois Mule" ; "Nakanishi=20 |> Greg-MGI8179" ; |> Sent: Thursday, August 18, 2005 11:46 AM |> Subject: RE: [ipcdn] Comments on |> draft-ietf-ipcdn-pktc-eventmess-04.txt |... |> 8) pktcDevEvThrottleAdminStatus |> - The description makes mention of throttling events using SNMP and=20 |> Syslog. What about the local log? Are events written to the local=20 |> log not subject to throttling? |... | |I'd suggest that if we don't leave it up to the implementation, that it |would be best for throttling to affect all destinations equally. =20 |Swamped logs are the same kind of problem, whether on the local system or a remote one. | |Randy The code issuing a notification, which is where the DESCRIPTION clause would lead implementors to put the throttling logic, would in a reasonably modular environment have no knowledge of whether it is going to a local log, delivery over some protocol, or whatever. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Oct 26 15:53:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrLS-0006dD-TC; Wed, 26 Oct 2005 15:53:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrHu-0005Ns-7m; Wed, 26 Oct 2005 15:50:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17915; Wed, 26 Oct 2005 15:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUrUx-0007VD-9L; Wed, 26 Oct 2005 16:03:48 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUrHf-00073r-Go; Wed, 26 Oct 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 26 Oct 2005 15:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-device-mibv2-10.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org --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 Data-Over-Cable Service Interface Specification Compliant Cable Modems and Cable Modem Termination Systems Author(s) : R. Woundy, K. Marez Filename : draft-ietf-ipcdn-device-mibv2-10.txt Pages : 93 Date : 2005-10-26 This memo is a revision of the standards track RFC 2669. Please see "Revision Descriptions" below for a description of changes. This document obsoletes RFC 2669. 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-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-device-mibv2-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-26143717.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-device-mibv2-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26143717.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart-- From ipcdn-bounces@ietf.org Thu Oct 27 10:51:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV96K-0003xe-Ne; Thu, 27 Oct 2005 10:51:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV953-0003VN-Fk; Thu, 27 Oct 2005 10:50:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04012; Thu, 27 Oct 2005 10:49:56 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV9IH-0004XB-Ry; Thu, 27 Oct 2005 11:03:57 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EV94s-0000Ji-Vy; Thu, 27 Oct 2005 10:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 27 Oct 2005 10:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-docs-rfmibv2-14.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org --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, E. Cardona Filename : draft-ietf-ipcdn-docs-rfmibv2-14.txt Pages : 148 Date : 2005-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 the Radio Frequency (RF) interfaces for systems compliant with the Data Over Cable Service Interface Specifications (DOCSIS). This document revises and obsoletes RFC 2670. Please see section 6 for a description of the changes from RFC 2670. Note to RFC Editor (Remove this paragraph prior to publication) 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-docs-rfmibv2-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-docs-rfmibv2-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-27102224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-docs-rfmibv2-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27102224.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart-- From ipcdn-bounces@ietf.org Thu Oct 27 10:52:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV96r-0004Fw-Cp; Thu, 27 Oct 2005 10:52:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV957-0003Xc-Va; Thu, 27 Oct 2005 10:50:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04050; Thu, 27 Oct 2005 10:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV9II-0004XZ-Bi; Thu, 27 Oct 2005 11:03:57 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EV94t-0000L0-Gd; Thu, 27 Oct 2005 10:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 27 Oct 2005 10:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-07.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org --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-07.txt Pages : 60 Date : 2005-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 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-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-pktc-mtamib-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-pktc-mtamib-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: <2005-10-27104055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-pktc-mtamib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-pktc-mtamib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27104055.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart-- From ipcdn-bounces@ietf.org Thu Oct 27 15:51:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDmC-0007zn-Rp; Thu, 27 Oct 2005 15:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDlI-0007dy-Jm; Thu, 27 Oct 2005 15:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25328; Thu, 27 Oct 2005 15:49:51 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVDye-0000de-80; Thu, 27 Oct 2005 16:03:57 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EVDlC-0006Q5-QW; Thu, 27 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 27 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-eventmess-05.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org --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 Event MIB for PacketCable/IPCablecom MTAs Author(s) : W. De Ketelaere, et al. Filename : draft-ietf-ipcdn-pktc-eventmess-05.txt Pages : 29 Date : 2005-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 provides a common data and format representation for events generated by PacketCable and IPCablecom compliant Multimedia Terminal Adapter devices. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2. The set of objects are consistent with the SNMP framework and existing SNMP standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-pktc-eventmess-05.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-eventmess-05.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: <2005-10-27113226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-pktc-eventmess-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-pktc-eventmess-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27113226.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart-- From ipcdn-bounces@ietf.org Thu Oct 27 17:38:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVFRu-00029q-2h; Thu, 27 Oct 2005 17:38:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVECZ-0003Oe-S0 for ipcdn@megatron.ietf.org; Thu, 27 Oct 2005 16:18:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03590 for ; Thu, 27 Oct 2005 16:18:02 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVEPt-0003qv-40 for ipcdn@ietf.org; Thu, 27 Oct 2005 16:32:11 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j9RKHvRC004461; Thu, 27 Oct 2005 14:17:57 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: [ipcdn] Changes in draft-ietf-ipcdn-pktc-mtamib-07.txt Date: Thu, 27 Oct 2005 14:17:57 -0600 Message-ID: Thread-Topic: [ipcdn] Changes in draft-ietf-ipcdn-pktc-mtamib-07.txt Thread-Index: AcXbCyqCMRF6/P7DTwad3bdLTMvBUwAKCpTA From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.2 (/) X-Scan-Signature: bdbc17c32641a4eb183bfe81e6711d09 X-Mailman-Approved-At: Thu, 27 Oct 2005 17:38:12 -0400 Cc: bwijnen@lucent.com, enechamkin@broadcom.com, "Richard Woundy @ Comcast" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1707978130==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============1707978130== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DB33.8540FB91" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DB33.8540FB91 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 This note summarizes the comments received on MTA MIB draft06 (from Bert's AD review and wg participants) and the changes made in draft07. =20 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-07.txt =20 Thanks, Eugene and Jean-Francois. =20 --- --- Summary of responses to MTA MIB draft 06 comments --- draft-ietf-ipcdn-pktc-mtamib-06.txt --- from AD and wg participants =20 Bert wrote: # Comment 1 > - $ idnits draft-ietf-ipcdn-pktc-mtamib-06.txt > idnits 1.74 >=20 > draft-ietf-ipcdn-pktc-mtamib-06.txt: >=20 > Checking nits according to http://www.ietf.org/ID-Checklist.html: > Checking conformance with RFC 3978/3979 boilerplate... > * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure > Acknowledgement. > (The document uses RFC 3667 boilerplate or RFC 3978-like > boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May > 2005, > submission of drafts without verbatim RFC 3978 boilerplate is not > accepted.) >=20 > So if you do a new revision, pls make sure you take care of above. > If you use xml2rfc, then it is taken care of automagically by the > latest version (I think) ok, fixed. Will run the latest idnits tool before submission, just like we did for draft06 (the boilerplate was updated since draft06 submission). =20 =20 # Comment 2 > - References: >=20 > !! Contains embedded space: > P050 L006: [ETSI TS 101 909-8] ETSI TS 101 909-8: "Access and > Terminals (AT); >=20 > !! Contains embedded space: > P050 L014: [EN 300 001] EN 300 001 V1.5.1 (1998-10):"European > Standard >=20 > !! Contains embedded space: > P050 L022: [EN 300 659-1] EN 300 659-1: "Public Switched > Telephone Network >=20 > !! Contains embedded space: > P005 L029: - the ETSI MTA MIB [ETSI TS 101 909-8]. The ETSI > MTA MIB >=20 > !! Contains embedded space: > P005 L031: defined in [EN 300 001] and [EN 300 659-1]. >=20 > !! Contains embedded space: > P005 L031: defined in [EN 300 001] and [EN 300 659-1]. >=20 > Not sure if sapces in citations are really forbidden. > But I know the RFC-Editor checking tool has trouble with it. ok - fixed, removed white spaces. =20 =20 # Comment 3 > !! Missing Reference for citation: [RFC2119] > P003 L011: interpreted as described in RFC 2119 [RFC2119]. ok fixed, added reference. =20 =20 # Comment 4 > !! Missing citation for Normative reference: > P047 L040: [RFC2863] McCloghrie, K., Kastenholz, F., "The > Interfaces Group ok, the reference is mostly because of the IMPORT of the IF-MIB. Proposed resolution: reference to [RFC2863] is introduced as comments in the MIB module: added "-- [RFC2863]" to mib module =20 =20 # Comment 5 > !! Missing citation for Informative reference: > P049 L042: [RFC3410] Case, J., Mundy, R., Partain, D. and B. > Stewart, No action taken. [RFC3410] - the citation is not missing, it is present in the text. See: section 1, end of 1st sentence. =20 =20 # Comment 6 > !! Missing citation for Normative reference: > P047 L043: [RFC3411] Harrington, D., Presuhn, R., and Wijnen, > B., "An ok. This normative reference is required because of the IMPORTs. Resolution: added RFC citations as comments in the MIB module definition as follows: IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Unsigned32, Counter32, NOTIFICATION-TYPE, mib-2 FROM SNMPv2-SMI -- [RFC2578] RowStatus, TruthValue FROM SNMPv2-TC -- [RFC2579] OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- [RFC4001] sysDescr FROM SNMPv2-MIB -- [RFC3418] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] docsDevSoftwareGroupV2 FROM DOCS-CABLE-DEVICE-MIB -- [RFCxxxx] -- ************************************************************ -- * NOTES TO RFC Editor (to be removed prior to publication) * -- * * -- * The I-D * -- * is expected to become RFC before this draft. * -- * Please replace RFCxxxx with the RFC number of the IPCDN * -- * Cable Device MIBv2 and remove this note * -- * * -- ************************************************************ =20 DocsX509ASN1DEREncodedCertificate, docsBpi2CodeDownloadGroup FROM DOCS-IETF-BPI2-MIB -- [RFC4131] =20 ifPhysAddress FROM IF-MIB; -- [RFC2863] =20 =20 # Comment 7 > !! Missing Reference for citation: [RFC3495] > P004 L025: Configuration DHCP specifications, RFC 3495 > [RFC3495] and RFC 3594 No action taken. RFC3495 - Reference is not missing it's present in the Normative References. =20 =20 # Comment 8 > !! Missing Reference for citation: [RFC3594] > P004 L026: [RFC3594]. > P048 L027: [RFC3594] P. Duffy, "PacketCable Security Ticket > Control Sub-Option No action taken. RFC3594 - Reference is not missing it's present in the Normative References. =20 =20 # Comment 9 > !! Missing Reference for citation: [RFC3617] > P048 L031: [RFC3617] E. Lear, "Uniform Resource Identifier (URI) > Scheme and No action taken. RFC3617 - Reference is not missing it's present in the Normative References. =20 =20 # Comment 10 > !! Missing Reference for citation: [RFCxxxx] > P009 L016: module (DOCS-CABLE-DEVICE-MIB [RFCxxxx]). No action taken. RFCxxxx - Reference is not missing it's present in the Normative References. =20 =20 # Comment 11 > My tool may have gotten a bit confused in that it is seeing the > refernce > as a citation instead of the oterhway around. In that case there is > no citation. Pls check carefully ok, did another check before submitting the ID. We also updated some of the PacketCable and other IETF references: - Updated reference to PacketCable MTA MIB Specification - Updated reference to PacketCable Provisioning Specification - Updated reference to PacketCable Security Specification =20 =20 # Comment 12 > - what is the persistency behaviour of the various read-write objects? > pktcMtaDevEnabled > ... etc .. Resolution: updated a number of MIB objects, see below. Out of all the read-write objects, none of the values set in those objects should persist, except for pktcMtaDevResetKrbTickets. =20 a) We added the following text for non-persistent object values: =3D> for e.g., for pktcMtaDevResetNow, add: If a value is written into an instance of pktcMtaDevResetNow, the agent MUST NOT retain the supplied value across MTA re-initializations or reboots." Similar text for pktcMtaDevEnabled, pktcMtaDevProvisioningTimer, pktcMtaDevServerDns1, pktcMtaDevServerDns2, pktcMtaDevTimeServer, pktcMtaDevConfigFile, pktcMtaDevProvConfigHash, pktcMtaDevProvConfigKey. b) Added text indicating persistence of object value only for pktcMtaDevResetKrbTickets: If a value is written into an instance of pktcMtaDevResetKrbTickets, the agent MUST retain the supplied value across an MTA re-initialization or reboot. =20 =20 # Comment 13 > - For pktcMtaDevEnabled a better name woul probably be > pktcMtaDevAdministrativelyEnabled > And how is the NMS going to see what the real Operational status is? > Is a AdminStatus and OperStatus (as in IF-MIB) not more appropriate? Resolution: see additional email thread on the ipcdn list in Sept 2005. The following text was added: The MTA must execute all actions required to enable or disable the telephony services for all endpoints immediately upon receipt of an SNMP SET operation. =20 =20 # Comment 14 > - For > pktcMtaDevTypeIdentifier OBJECT-TYPE > SYNTAX SnmpAdminString > I see that it is an identifier as per DHCP option 60 (RFC2132. > There it is specified as a "string of octets". How are we sure that > such a "string of octets" is a valid SnmpAdminString? Resolution: added clarification text, see below. We traced this assurance to a requirement in the PacketCable MTA Device Provisioning spec (see normative ref in the draft): Section 8.2 says: 8.2 DHCP Option 60: Vendor Client Identifier "Option code 60 contains a string identifying Capabilities of the MTA. The MTA- MUST send the following ASCII Coded String in DHCP Option -----> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ code 60: "pktc1.0:xxxxxx". Where xxxxxx MUST be an ASCII representation of the hexadecimal encoding of the MTA TLV Encoded Capabilities, as defined in Section 10." The following text was added per the subsequent email request from Bert: =20 ... The DHCP option 60 value contains an ASCII encoded string identifying Capabilities of the MTA as defined in the PacketCable MTA Device Provisioning Specification. =20 =20 # Comment 15 > There are other such objects too I think > pktcMtaDevSerialNumber > pktcMtaDevSwCurrentVers > etc. Resolution: below is the list of objects with some analysis to justify the object syntax. =20 pktcMtaDevSerialNumber object value =3D=3D DHCP option 43 sub-option 4 value. see the PKT-SP-PROV spec, section 8.5, it says: "The sub-option 4 contains the device serial number represented as an ASCII string." Resolution: No action required, leave as-is. =20 pktcMtaDevSwCurrentVers object value =3D=3D DHCP option 43 sub-option 6 value. see the PKT-SP-PROV spec, section 8.5, it says: "The sub-option 6 contains the software version number represented as an ASCII string." Resolution: No action required, leave as-is. =20 pktcMtaDevSnmpEntity object value =3D=3D DHCP option 122 sub-option 3 value [RFC 3495] in the form of an FQDN SnmpAdminString is therefore ok. Resolution: No action required, leave as-is. =20 pktcMtaDevProvKerbRealmName object value =3D=3D DHCP option 122 sub-option 6 value [RFC 3495] =3D=3D> GeneralStrings encoded per RFC1510 The Packetcable Security Specification adds a requirement for those names to be all UPPERCASE (note that this is consistent with RFC4120 section 6.1, quote: "When establishing a new realm name based on an internet domain name it is recommended by convention that the characters be converted to uppercase.") =20 In addition, as noted below, the Kerberos protocol (RFC1510, RFC4120) defines the RealmName to be of ASN.1 type "GeneralString". This type has numerous interop problems (RFC4120, section 5.2.1). The newer version of Kerberos protocol (RFC4120) requires that the RealmName follows a new type "KerberosString" which effectively constrains the value of the GeneralString to only contain characters in IA5String. KerberosString ::=3D GeneralString (IA5String) The "IA5String" type is defined in ISO/IEC646:1991 and also known as US-ASCII. Hence, based on the above analysis, "DisplayString" and "SnmpAdminString" seem to be the closest mapping in SMI. The co-authors are shared on whether to change the current SYNTAX from SnmpAdminstring to DisplayString. Note that there are a couple of other objects related to DHCP but they are not strings. Resolution: based on the above and the subsequent discussions, the co-authors prefer to leave the object as-is. =20 =20 # Comment 16 > - Where are the suboptions of DHCP option 43 defined? in PKT-SP-PROV a normative reference in the MTA MIB ID http://www.packetcable.com/downloads/specs/PKT-SP-PROV-I11-050812.pdf section 8.5 Resolution: added the following text: The list of sub-options for DHCP option 43 are defined in the PacketCable MTA Device Provisioning Specification. =20 =20 # Comment 17 > are they all valid SnmpAdminStrings as you seem to assume for > several of them? Resolution: no action based on the above analysis, I think our use is legitime, if not, please let us know. =20 =20 =20 # Comment 18 > A REFERENCE clause migth help too. Yes, agree. Resolution: added text and reference in the 2 objects referencing DHCP option 43: The list of sub-options for DHCP option 43 are defined in the PacketCable MTA Device Provisioning Specification. REFERENCE " PacketCable MTA Device Provisioning Specification." =20 =20 # Comment 19 > - You have pktcMtaDevServerAddressType and then follow some 5 > objects of InetAddress SYNTAX. The latter 5 objects MUST specify > which object of SYNTAX InetAddressType controls their format. Resolution: no action This is already the case in draft06. We don't understand the comment. For eg, pktcMtaDevServerDhcp1 states: The type of this address is determined by the value of the pktcMtaDevServerAddressType object. same for pktcMtaDevServerDhcp2, pktcMtaDevServerDns1, pktcMtaDevServerDns2, and pktcMtaDevTimeServer. =20 =20 # Comment 20 > I also wonder if in the future all these servers need to be > of the same InetAddressType, and so I wonder if it is wise > to use just one object to identify the format of the 5 > different server addresses. Good point. Resolution: Define 3 Internet Address types: one for 2 DHCP server objects one for 2 DNS server objects 1 for Time Server object. The InetAddressType objects inthe pktcMtaDevServer table now look like: pktcMtaDevDhcpServerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the Internet address type for the PacketCable DHCP servers specified in MTA MIB." DEFVAL { ipv4 } ::=3D { pktcMtaDevServer 1} =20 pktcMtaDevDnsServerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the Internet address type for the PacketCable DNS servers specified in MTA MIB." DEFVAL { ipv4 } ::=3D { pktcMtaDevServer 17} =20 =20 pktcMtaDevTimeServerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the Internet address type for the PacketCable Time servers specified in MTA MIB." DEFVAL { ipv4 } ::=3D { pktcMtaDevServer 18} =20 The description text in the affected objects was updated accordingly. =20 =20 =20 # Comment 21 > - Mmm do we expect we can get away with pktcMtaDevProvConfigKey > once the Security ADs take a look? Resolution: - change the syntax of pktcMtaDevProvConfigKey to be 32 octets (256) or may be more - add a new TC PktcMtaDevProvEncryptAlg and put the list: none(0), des64CbcMode(1), t3Des128CbcMode(2), aes128CbcMode(3), aes256CbcMode(4) - add a new object named pktcMtaDevProvConfigEncryptAlg to specify the encryption algorithm of type PktcMtaDevProvEncryptAlg - add DEFVAL des64CbcMode - add a compliance statement to only require des64CbcMode for compliant PacketCable 1.0 implementations. The above proposal is inline with the Security AD comments on the BPI+ encryption algorithms and ok with us. =20 =20 # Comment 22 > - The comment lines on page 26 probably better go into some > object DESCRIPTION clause, no? Resolution: moved the comment into the description clauses and pasted the same text in all of the 3 relevant objects (pktcMtaDevProvUnsolicitedKeyMaxTimeout, pktcMtaDevProvUnsolicitedKeyNomTimeout, pktcMtaDevProvUnsolicitedKeyMaxRetries). =20 =20 # Comment 23 > - pktcMtaDevRealmOrgName > Is this really an SnmpAdminString of max size 64? We confirmed the 2 points: per RFC2459: - Organization Name MUST be of "UTF8String" (for all certs after Dec 31, 2003). - upper boundery is 64 for Organization name. Given that a signle char can take up to 6 octets in SnmpAdminString, we proposed to increase the max limit to 255. CONCLUSION: "SnmpAdminString" type is the closest mapping to "UTF8String" Hence, leave the SYNTAX "as is" - SnmpAdminString. Resolution: Increased upper bound limit. =20 =20 # Comment 24 > - Page 44 > OBJECT pktcMtaDevServerAddressType > SYNTAX InetAddressType > DESCRIPTION > " Support for address types other than 'ipv4(1)' > is not presently specified and therefore, is not > required. It may be defined in future versions of > this MIB module." > In order to say so in machine readable form, yopu do: > OBJECT pktcMtaDevServerAddressType > SYNTAX InetAddressType { ipv4(1) } > DESCRIPTION > " Support for address types other than 'ipv4(1)' > is not presently specified and therefore, is not > required. It may be defined in future versions of > this MIB module." ok, will be reflected in all applicable objects. =20 =20 # Comment 25 > You then also add the InetAddress objects with alength of 4. > You have done this in other MIB modules, so you should know I think. Resolution: Changes reflected in all applicable objects. OBJECT pktcMtaDevServerDhcp1 SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 Addresses. Other address types support may be defined in future versions of this MIB module." OBJECT pktcMtaDevServerDhcp2 SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 Addresses. Other address types support may be defined in future versions of this MIB module." OBJECT pktcMtaDevServerDns1 SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 Addresses. Other address types support may be defined in future versions of this MIB module." OBJECT pktcMtaDevServerDns2 SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 Addresses. Other address types support may be defined in future versions of this MIB module." OBJECT pktcMtaDevTimeServer SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 Addresses. Other address types support may be defined in future versions of this MIB module." =20 =20 # Comment 26 > and is a similar refinement for pktcMtaBasicSmtaCompliance also not > needed/wanted? Resolution: agree. Added to the S-MTA compliance group. =20 =20 # Comment 27 > - Refrence RFC3291 can now be repalced by RFC4001 ok, fixed. =20 =20 # Comment 28 > I suspect we need another serious and close review. We as co-authors would really like to understand the next steps in more details. This draft has passed WGLC, has had at least 2 if not 3 MIB doctor reviews and now your complete review. =20 =20 =20 > Bert Thanks again for all the comments =20 The following are comments received on the draft from Randy Presuhn and other IPCDN WG participants. =20 # Comment 29 > - object pktcMtaDevProvUnsolicitedKeyMaxTimeout > is a read-only object and has text in the DESCRIPTION clause about=20 > If this object is set to a zero value, the MTA MUST return > an 'inconsistentValue' in response to SNMP SET operations. > That seems conflicting, no? Resolution: deleted: If this object is set to a zero value, the MTA MUST return an 'inconsistentValue' in response to SNMP SET operations. =20 # Comment 30 > - Same for pktcMtaDevProvUnsolicitedKeyNomTimeout Resolution: deleted: If this object is set to a zero value, the MTA MUST return an 'inconsistentValue' in response to SNMP SET operations. =20 # Comment 31 > - I wonder if for an object like pktcMtaDevProvKerbRealmName=20 > it is wise to use SnmpAdminString while the content MUST be > uppercase ASCII ?? Resolution: based on the above and the subsequent discussions, the co-authors prefer to leave the object as-is. See comment #15. The Kerberos protocol (RFC1510, RFC4120) defines the RealmName to be of ASN.1 type "GeneralString". This type has numerous interop problems (RFC4120, section 5.2.1). The newer version of Kerberos protocol (RFC4120) requires that the RealmName follows a new type "KerberosString" which effectively constrains the value of the GeneralString to only contain characters in IA5String. KerberosString ::=3D GeneralString (IA5String) The "IA5String" type is defined in ISO/IEC646:1991 and also known as US-ASCII. Hence, based on the above analysis, "DisplayString" and "SnmpAdminString" seem to be the closest mapping in SMI. =20 =20 # Comment 32 > - Same for pktcMtaDevRealmName Resolution: based on the above and the subsequent discussions, the co-authors prefer to leave the object as-is. =20 =20 # Comment 33 > - Why is=20 > pktcMtaDevRealmAvailSlot OBJECT-TYPE > SYNTAX Unsigned32 (0..64) >=20 > While=20 > pktcMtaDevRealmIndex OBJECT-TYPE > SYNTAX Unsigned32 (1..32) >=20 > Should they not be both limited to 64 or 32 (i.e. same value) ?? Agree. Resolution: change pktcMtaDevRealmIndex's SYNTAX to SYNTAX Unsigned32 (1..64) =20 # Comment 34 > - Same for > pktcMtaDevCmsAvailSlot OBJECT-TYPE > SYNTAX Unsigned32 (0..128) > and > pktcMtaDevCmsIndex OBJECT-TYPE > SYNTAX Unsigned32 (1..64) Resolution: change pktcMtaDevCmsIndex's SYNTAX to SYNTAX Unsigned32 (1..128) =20 =20 # Comment 35 > - I wonder why: >=20 > pktcMtaNotificationPrefix OBJECT IDENTIFIER ::=3D { pktcMtaMib 2 } > pktcMtaNotification OBJECT IDENTIFIER ::=3D { > pktcMtaNotificationPrefix 0 } >=20 > is not specified as: >=20 > pktcMtaNotifications OBJECT IDENTIFIER ::=3D { pktcMtaMib 0 } >=20 > as suggested in the mib-review-guideleines. > It is not forbidden. I just wonder Resolution: change text to follow mib design guidelines as follows: pktcMtaNotifications OBJECT IDENTIFIER ::=3D { pktcMtaMib 0 } The text looks like this now: =20 pktcMtaNotification OBJECT IDENTIFIER ::=3D { pktcIetfMtaMib 0 } pktcMtaMibObjects OBJECT IDENTIFIER ::=3D { pktcIetfMtaMib 1 } pktcMtaDevBase OBJECT IDENTIFIER ::=3D { pktcMtaMibObjects 1 } pktcMtaDevServer OBJECT IDENTIFIER ::=3D { pktcMtaMibObjects 2 } pktcMtaDevSecurity OBJECT IDENTIFIER ::=3D { pktcMtaMibObjects 3 } pktcMtaDevErrors OBJECT IDENTIFIER ::=3D { pktcMtaMibObjects 4 } pktcMtaConformance OBJECT IDENTIFIER ::=3D { pktcIetfMtaMib 2 } =20 =20 # Comment 36 > - I wonder why > pktcMtaBasicCompliance MODULE-COMPLIANCE >=20 > STATUS current > DESCRIPTION > " The compliance statement for MTA devices that implement > PacketCable or IPCablecom requirements. >=20 > This compliance statement applies to MTA implementations > that support PacketCable 1.0 or IPCablecom requirements, > which are not IPv6-capable at the time of this > RFC publication." >=20 > MODULE -- Unconditionally mandatory groups for MTAs >=20 > MANDATORY-GROUPS { > pktcMtaGroup, > pktcMtaNotificationGroup > } >=20 > OBJECT pktcMtaDevServerAddressType > SYNTAX InetAddressType > DESCRIPTION > " Support for address types other than 'ipv4(1)' > is not presently specified and therefore, is not > required. It may be defined in future versions of > this MIB module." > ::=3D { pktcMtaCompliances 1 } >=20 > Does not have the following: >=20 > MANDATORY-GROUPS { > pktcMtaGroup, > pktcMtaNotificationGroup > } >=20 > OBJECT pktcMtaDevServerAddressType > SYNTAX InetAddressType { ipv4(1) } > DESCRIPTION > " Support for address types other than 'ipv4(1)' > is not presently specified and therefore, is not > required. It may be defined in future versions of > this MIB module." > OBJECT pktcMtaDevServerDhcp1 > SYNTAX InetAddress SIZE (4) > SESCRIPTION > " Support for address formats other than 'ipv4(1)' > is not presently specified and therefore, is not > required. It may be defined in future versions of > this MIB module." >=20 > .... and similar swtuff for the other InetAddress objects >=20 > ::=3D { pktcMtaCompliances 1 } ok, addressed. =20 =20 # Comment 37 > - Same for the pktcMtaBasicSmtaCompliance spec. Agree, fixed. =20 =20 # Comment 38 > - At various places in your MIB module you have FQDNs present. > I wonder if it would not be wise (for interoperability) to=20 > specify WHEN such FQDNs are supposed to be resolved to IP addresses. Agree. Resolution: added new text as follows: for pktcMtaDevFQDN: The MTA FQDN is used to uniquely identify the device to the PacketCable back office elements. (on this one, the MTA does not resolve it, just uses it). =20 pktcMtaDevSnmpEntity The MTA must resolve the FQDN value before its very first network interaction with the SNMP entity during the provisioning phase as specified in the PacketCable MTA Device Provisioning specification. =20 pktcMtaDevCmsFqdn The MTA must resolve the CMS FQDN as required by the corresponding PacketCable Specifications." REFERENCE " PacketCable MTA Device Provisioning Specification; PacketCable Security Specification; PacketCable Network-Based Call Signaling Protocol Specification." =20 # Comment 39 --- Other comments on MTA MIB draft06 Bert wrote: > I also see that various comments/questions were posted to the > IPCDN WG mailing list, so those need to be answered too. ok, see Comments 40 and above for the log of other issues. We believe draft07 does address all comments received to date. If we missed any, let us know. =20 =20 # Comment 40 >From Randy http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01600.html Duplicate of Comment 31. =20 # Comment 41 >From Randy, thread with subject title "[ipcdn] pktcMtaDevProvConfigKey" Initial pointer: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01537.html =20 Resolution: add the following text in the description: The value of this object is provided along with the configuration file information (pktcMtaDevConfigFile) and hash (pktcMtaDevProvConfigHash) by the Provisioning Server via SNMP SET once the configuration file has been created as defined by the PacketCable Security specification. =20 If the configuration file the MTA receives is not encrypted, the length of this object value is zero. If the file is encrypted, then the algorithm is DES in CBC mode and the length of this object value is 64 bits (an IV of zero is used to encrypt the file as specified in the PacketCable Security specification). =20 and change the MUST into SHOULD as proposed below: This object must not be used in non secure provisioning mode. In non secure provisioning modes, the MTA SHOULD return an 'inconsistentValue' in response to SNMP SET operations, and, the MTA SHOULD return a zero-length string in response to SNMP GET operations. (this to address potential issues with some agent implementations like AgentX). =20 =20 # Comment 42 Comment from Thomas Anders: delete > This object value is used as an index into the > pktcMtaDevRealmTable. in the description clause of pktcMtaDevProvKerbRealmName. =20 > end. =20 =20 =20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Thursday, October 27, 2005 8:50 AM > To: i-d-announce@ietf.org > Cc: ipcdn@ietf.org > Subject: I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-07.txt >=20 > 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. >=20 > 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-07.txt > Pages : 60 > Date : 2005-10-27 >=20 > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it defines a basic set of managed objects for > SNMP-based management of PacketCable and IPCablecom compliant > Multimedia Terminal Adapter devices. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib- > 07.txt >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ipcdn-pktc-mtamib-07.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipcdn-pktc-mtamib-07.txt". >=20 > 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. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------_=_NextPart_001_01C5DB33.8540FB91 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
All,
 
   This note summarizes the =
comments received on MTA MIB draft06 =
(from
Bert’s AD review and wg participants) =
and the changes made in draft07.

 

http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-= 07.txt

 

Thanks,
Eugene =
and Jean-Francois.
 
---
--- Summary of responses to MTA MIB draft 06 =
comments
---      &=
nbsp;     =
draft-ietf-ipcdn-pktc-mtamib-06.txt
---  from AD and wg = participants
 
Bert =
wrote:
# Comment =
1
> - $ idnits =
draft-ietf-ipcdn-pktc-mtamib-06.txt
>   idnits =
1.74
> =

>   =
draft-ietf-ipcdn-pktc-mtamib-06.txt:
<=
font
size=3D2 color=3Dteal face=3D"Courier New">> =

>   Checking nits =
according to http://www.ietf.org/ID-Ch=
ecklist.html:
>     =
Checking conformance with RFC 3978/3979 =
boilerplate...
>   * The document =
seems to lack an RFC 3978 Section 5.1 IPR =
Disclosure
>     =
Acknowledgement.
>     (The =
document uses RFC 3667 boilerplate or RFC =
3978-like
>     =
boilerplate instead of verbatim RFC 3978 boilerplate.  After 6 =
May
> =
2005,
>     =
submission of drafts without verbatim RFC 3978 boilerplate is =
not
>     =
accepted.)
> =

>   So if you do a =
new revision, pls make sure you take care of =
above.
>   If you use =
xml2rfc, then it is taken care of automagically by =
the
>   latest version (I =
think)
ok, =
fixed.
Will run =
the latest idnits tool before submission, just like we =
did
for =
draft06 (the boilerplate was updated since draft06 =
submission).
 
 
# Comment =
2
> - =
References:
> =

>    !! Contains =
embedded space:
>    P050 =
L006:    [ETSI TS 101 909-8] ETSI TS 101 909-8: =
"Access and
> Terminals =
(AT);
> =

>    !! Contains =
embedded space:
>    P050 L014:    [EN 300 =
001] EN 300 001 V1.5.1 (1998-10):"European
> =
Standard
> =

>    !! Contains =
embedded space:
>    P050 =
L022:    [EN 300 659-1] EN 300 659-1: "Public =
Switched
> Telephone =
Network
> =

>    !! Contains =
embedded space:
>    P005 =
L029:      - the ETSI MTA MIB [ETSI TS 101 =
909-8]. The ETSI
> MTA =
MIB
> =

>    !! Contains =
embedded space:
>    P005 =
L031:        defined in [EN 300 001] =
and [EN 300 659-1].
> =

>    !! Contains =
embedded space:
>    P005 =
L031:        defined in [EN 300 001] =
and [EN 300 659-1].
> =

>   Not sure if =
sapces in citations are really =
forbidden.
>   But I know the =
RFC-Editor checking tool has trouble with =
it.
ok - =
fixed, removed white spaces.
 
 
# Comment =
3
>     !! =
Missing Reference for citation: =
[RFC2119]
>     P003 =
L011:    interpreted as described in RFC 2119 =
[RFC2119].
ok fixed, =
added reference.
 
 
# Comment =
4
>     !! =
Missing citation for Normative =
reference:
>     P047 =
L040:    [RFC2863] McCloghrie, K., Kastenholz, F., =
"The
> Interfaces =
Group
ok, the =
reference is mostly because of the IMPORT of the =
IF-MIB.
Proposed =
resolution: reference to [RFC2863] is introduced as =
comments
in the =
MIB module:
 added =
"-- [RFC2863]" to mib =
module
 
 
# Comment =
5
>     !! =
Missing citation for Informative =
reference:
>     P049 =
L042:    [RFC3410] Case, J., Mundy, R., Partain, D. and =
B.
> =
Stewart,
No action =
taken.
   [RFC3410] - the citation is not =
missing, it is present in the =
text.
       &nbs=
p;       See: section 1, end of 1st =
sentence.
 
 
# Comment =
6
>     !! =
Missing citation for Normative =
reference:
>     P047 =
L043:    [RFC3411] Harrington, D., Presuhn, R., and =
Wijnen,
> B., =
"An
ok. This =
normative reference is required because of the =
IMPORTs.
Resolution: added RFC citations as comments =
in the MIB module
definition as =
follows:
IMPORTS
    =
MODULE-IDENTITY,
    =
OBJECT-TYPE,
    =
OBJECT-IDENTITY,
    =
Unsigned32,
    =
Counter32,
    =
NOTIFICATION-TYPE,
    =
mib-2
       &nbs=
p;  FROM =
SNMPv2-SMI          &nb=
sp;         -- =
[RFC2578]
    =
RowStatus,
    =
TruthValue
       &nbs=
p;  FROM =
SNMPv2-TC          &nbs=
p;          -- =
[RFC2579]
    =
OBJECT-GROUP,
    =
MODULE-COMPLIANCE,
    =
NOTIFICATION-GROUP
       &nbs=
p;  FROM =
SNMPv2-CONF          &n=
bsp;        -- =
[RFC2580]
    =
InetAddressType,
    =
InetAddress
       &nbs=
p;  FROM =
INET-ADDRESS-MIB         &nb=
sp;    -- =
[RFC4001]
    =
sysDescr
       &nbs=
p;  FROM =
SNMPv2-MIB          &nb=
sp;         -- =
[RFC3418]
    =
SnmpAdminString
       &nbs=
p;  FROM =
SNMP-FRAMEWORK-MIB         &=
nbsp;  -- [RFC3411]
    =
docsDevSoftwareGroupV2
       &nbs=
p;  FROM =
DOCS-CABLE-DEVICE-MIB         -- =
[RFCxxxx]
    -- =
************************************************************
    -- * NOTES TO RFC Editor =
(to be removed prior to publication) =
*
    -- =
*            =
            &=
nbsp;           &n=
bsp;           &nb=
sp;         =
*
    -- =
*     The I-D =
<draft-ietf-ipcdn-device-mibv2-10.txt>     =
;  *
    -- * is expected to become =
RFC before this =
draft.           &=
nbsp; *
    -- * Please replace =
RFCxxxx with the RFC number of the IPCDN  =
*
    -- * Cable Device MIBv2 =
and remove this =
note           &nb=
sp;      =
*
    -- =
*            =
            &=
nbsp;           &n=
bsp;    =
            &=
nbsp;    *
    -- =
************************************************************
 
    =
DocsX509ASN1DEREncodedCertificate,
    =
docsBpi2CodeDownloadGroup
       &nbs=
p;  FROM =
DOCS-IETF-BPI2-MIB         &=
nbsp;  -- [RFC4131]
 
    =
ifPhysAddress
       &nbs=
p;  FROM =
IF-MIB;           =
            -- =
[RFC2863]
 
 
# Comment =
7
>     !! =
Missing Reference for citation: =
[RFC3495]
>     P004 =
L025:    Configuration DHCP specifications, RFC =
3495
> [RFC3495] and RFC =
3594
No action =
taken.
   RFC3495 - Reference is not =
missing it's present in the Normative =
References.
 
 
# Comment =
8
>    !! Missing =
Reference for citation: =
[RFC3594]
>    P004 =
L026:    =
[RFC3594].
>    P048 =
L027:    [RFC3594] P. Duffy, "PacketCable Security =
Ticket
> Control =
Sub-Option
No action =
taken.
  =
RFC3594 - Reference is not missing it's present in the Normative =
References.
 
 
# Comment =
9
>    !! Missing =
Reference for citation: =
[RFC3617]
>    P048 =
L031:    [RFC3617] E. Lear, "Uniform Resource =
Identifier (URI)
> Scheme =
and
No action =
taken.
   RFC3617 - Reference is not =
missing it's present in the Normative =
References.
 
 
# Comment =
10
>    !! Missing =
Reference for citation: =
[RFCxxxx]
>    P009 L016:    module =
(DOCS-CABLE-DEVICE-MIB [RFCxxxx]).
No action =
taken.
   RFCxxxx - Reference is not =
missing it's present in the Normative =
References.
 
 
# Comment =
11
>   My tool may have =
gotten a bit confused in that it is seeing =
the
>   =
refernce
>   as a citation =
instead of the oterhway around. In that case there =
is
>   no citation. Pls =
check carefully
ok, did =
another check before submitting the =
ID.
We also =
updated some of the PacketCable and other IETF =
references:
   - Updated reference to =
PacketCable MTA MIB =
Specification
   - Updated reference to =
PacketCable Provisioning =
Specification
   - Updated reference to =
PacketCable Security =
Specification
 
 
# Comment =
12
> - what is the persistency =
behaviour of the various read-write =
objects?
>     =
pktcMtaDevEnabled
>     ... =
etc ..
Resolution: updated a number of MIB objects, =
see below.
Out of =
all the read-write objects, none of the values set in =
those
objects =
should persist, except for =
pktcMtaDevResetKrbTickets.
 
a) We =
added the following text for non-persistent =
object
values:
 =3D> =
for e.g., for pktcMtaDevResetNow, =
add:
       &nbs=
p;  If a value is written into an instance =
of
 =
         pktcMtaDevResetNow,=
 the agent MUST NOT retain the =
supplied
       &nbs=
p;  value across MTA re-initializations or =
reboots."
Similar =
text for pktcMtaDevEnabled, =
pktcMtaDevProvisioningTimer,
pktcMtaDevServerDns1, pktcMtaDevServerDns2, =
pktcMtaDevTimeServer,
pktcMtaDevConfigFile, =
pktcMtaDevProvConfigHash,
pktcMtaDevProvConfigKey.
b) Added =
text indicating persistence of object value only =
for
pktcMtaDevResetKrbTickets:
       &nbs=
p;  If a value is written into an instance =
of
       &nbs=
p;  pktcMtaDevResetKrbTickets, the agent MUST retain =
the
       &nbs=
p;  supplied value across an MTA re-initialization =
or
       &nbs=
p;  reboot.
 
 
# Comment =
13
> - For pktcMtaDevEnabled a =
better name woul probably be
>     &=
nbsp; =
pktcMtaDevAdministrativelyEnabled
>   And how is the =
NMS going to see what the real Operational status =
is?
>   Is a AdminStatus =
and OperStatus (as in IF-MIB) not more =
appropriate?
Resolution: see additional email thread on =
the ipcdn list in Sept
 2005. =
The following text was added:
       &nbs=
p;   The MTA must execute all actions required =
to
       &nbs=
p;   enable or disable the telephony services for =
all
       &nbs=
p;   endpoints immediately upon receipt of an SNMP =
SET
       &nbs=
p;   operation.
 
 
# Comment =
14
> - =
For
>     =
pktcMtaDevTypeIdentifier     =
OBJECT-TYPE
>     &=
nbsp;  SYNTAX      =
SnmpAdminString
>   I see that it is =
an identifier as per DHCP option 60 =
(RFC2132.
>   There it is =
specified as a "string of octets". How are we sure =
that
>   such a =
"string of octets" is a valid =
SnmpAdminString?
Resolution: added clarification text, see =
below.
We traced =
this assurance to a requirement in the PacketCable =
MTA
Device =
Provisioning spec (see normative ref in the =
draft):
Section =
8.2 says:
 8.2 DHCP =
Option 60: Vendor Client =
Identifier
"Option code 60 contains a string =
identifying Capabilities of the =
MTA.
The MTA- =
MUST send the following ASCII Coded String in DHCP =
Option
----->        =
;         =
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
code 60: =
"pktc1.0:xxxxxx". Where xxxxxx MUST be an =
ASCII
representation of the hexadecimal encoding of =
the MTA TLV Encoded
Capabilities, as defined in Section =
10."
The =
following text was added per the subsequent email request =
from
Bert:
 
       &nbs=
p;  =
...           &nbs=
p;  The
       &nbs=
p;  DHCP option 60 value contains an ASCII encoded =
string
       &nbs=
p;  identifying Capabilities of the MTA as defined in =
the
       &nbs=
p;  PacketCable MTA Device Provisioning =
Specification.
 
 
# Comment =
15
>   There are other =
such objects too I think
> =
pktcMtaDevSerialNumber
> =
pktcMtaDevSwCurrentVers
> =
etc.
Resolution: below is the list of objects with =
some analysis to justify
the =
object syntax.
 
pktcMtaDevSerialNumber
  =
object value =3D=3D DHCP option 43 sub-option 4 =
value.
  =
see the PKT-SP-PROV spec, section 8.5, it =
says:
  =
"The sub-option 4 contains the device serial number represented =
as
   an ASCII =
string."
Resolution: No action required, leave =
as-is.
 
pktcMtaDevSwCurrentVers
  =
object value =3D=3D DHCP option 43 sub-option 6 =
value.
  =
see the PKT-SP-PROV spec, section 8.5, it =
says:
  =
"The sub-option 6 contains the software =
version
   number represented as an ASCII =
string."
Resolution: No action required, leave =
as-is.
 
pktcMtaDevSnmpEntity<=
/pre>
  =
object value =3D=3D DHCP option 122 sub-option 3 value [RFC =
3495]
       &nbs=
p;          in the form of =
an FQDN
  =
SnmpAdminString is therefore =
ok.
Resolution: No action required, leave =
as-is.
 
pktcMtaDevProvKerbRealmName<=
/font>
  =
object value =3D=3D DHCP option 122 sub-option 6 value [RFC =
3495]
       &nbs=
p;          =3D=3D> =
GeneralStrings encoded per =
RFC1510
  =
The Packetcable Security Specification adds a requirement for =
those
  =
names to be all UPPERCASE (note that this is consistent with =
RFC4120
  =
section 6.1, quote:
   "When establishing a new =
realm name based on an internet =
domain
   name it is recommended by =
convention that the characters be =
converted
   to =
uppercase.")
 
In =
addition, as noted below, the Kerberos protocol (RFC1510, =
RFC4120)
defines =
the RealmName to be of ASN.1 type "GeneralString". This =
type
has =
numerous interop problems (RFC4120, section =
5.2.1).
The newer =
version of Kerberos protocol (RFC4120) requires that =
the
RealmName =
follows a new type "KerberosString" which =
effectively
constrains the value of the GeneralString to =
only contain characters
in =
IA5String.
     KerberosString  =
::=3D GeneralString (IA5String)
The =
"IA5String" type is defined in ISO/IEC646:1991 and also =
known
as =
US-ASCII.
Hence, =
based on the above analysis, "DisplayString" =
and
"SnmpAdminString" seem to be the =
closest mapping in SMI. The
co-authors are shared on whether to change =
the current SYNTAX from
SnmpAdminstring to =
DisplayString.
Note that =
there are a couple of other objects related to DHCP but they are not =
strings.
Resolution: based on the above and the =
subsequent discussions, the
co-authors prefer to leave the object =
as-is.
 
 
# Comment =
16
> - Where are the suboptions of =
DHCP option 43 defined?
in =
PKT-SP-PROV a normative reference in the MTA MIB =
ID
http://www.packetcable.com/downloads/specs/PKT-SP-PROV-I11-050812.p=
df
section =
8.5
Resolution: added the following =
text:
       &nbs=
p;  The list of sub-options =
for
       &nbs=
p;  DHCP option 43 are defined in the PacketCable MTA =
Device
       &nbs=
p;  Provisioning =
Specification.
 
 
# Comment =
17
>   are they all =
valid SnmpAdminStrings as you seem to assume =
for
>   several of =
them?
Resolution: no =
action
based on =
the above analysis, I think our use is legitime, if =
not,
please =
let us know.
 
 
 
# Comment =
18
>   A REFERENCE =
clause migth help too.
Yes, =
agree.
Resolution: added text and reference in the 2 =
objects referencing DHCP
option =
43:
       &nbs=
p;  The list of sub-options for DHCP =
option
       &nbs=
p;  43 are defined in the PacketCable MTA =
Device
       &nbs=
p;  Provisioning =
Specification.
   =
 REFERENCE
        =
" PacketCable MTA Device Provisioning =
Specification."
 
 
# Comment =
19
> - You have =
pktcMtaDevServerAddressType and then follow some =
5
>   objects of =
InetAddress SYNTAX. The latter 5 objects MUST =
specify
>   which object of =
SYNTAX InetAddressType controls their =
format.
Resolution: no =
action
This is =
already the case in draft06. We don't understand the =
comment.
For eg, =
pktcMtaDevServerDhcp1 states:
       &nbs=
p;  The type of this address is determined by the value =
of
       &nbs=
p;  the pktcMtaDevServerAddressType =
object.
same for =
pktcMtaDevServerDhcp2, =
pktcMtaDevServerDns1,
pktcMtaDevServerDns2, and =
pktcMtaDevTimeServer.
 
 
# Comment =
20
>   I also wonder if =
in the future all these servers need to =
be
>   of the same =
InetAddressType, and so I wonder if it is =
wise
>   to use just one =
object to identify the format of the =
5
>   different server =
addresses.
Good =
point.
Resolution:
   Define 3 Internet Address =
types:
        =
one for 2 DHCP server objects
        =
one for 2 DNS server objects
        1 =
for Time Server object.
The =
InetAddressType objects inthe pktcMtaDevServer table now =
look
like:
pktcMtaDevDhcpServerAddressType  =
OBJECT-TYPE
    =
SYNTAX      =
InetAddressType
    MAX-ACCESS  =
read-only
    =
STATUS      =
current
    =
DESCRIPTION
        =
" This object contains the Internet address type for =
the
       &nbs=
p;  PacketCable DHCP servers specified in MTA =
MIB."
    DEFVAL { ipv4 =
}
    ::=3D { pktcMtaDevServer =
1}
 
pktcMtaDevDnsServerAddressType  =
OBJECT-TYPE
    =
SYNTAX      =
InetAddressType
    MAX-ACCESS  =
read-only
    =
STATUS      =
current
    =
DESCRIPTION
        =
" This object contains the Internet address type for =
the
       &nbs=
p;  PacketCable DNS servers specified in MTA =
MIB."
    DEFVAL { ipv4 =
}
    ::=3D { pktcMtaDevServer =
17}
 
 
pktcMtaDevTimeServerAddressType  =
OBJECT-TYPE
    =
SYNTAX      =
InetAddressType
    MAX-ACCESS  =
read-only
    =
STATUS      =
current
    =
DESCRIPTION
        =
" This object contains the Internet address type for =
the
       &nbs=
p;  PacketCable Time servers specified in MTA =
MIB."
    DEFVAL { ipv4 =
}
    ::=3D { pktcMtaDevServer =
18}
 
The =
description text in the affected objects was updated =
accordingly.
 
 
 
# Comment =
21
> - Mmm do we expect we can get =
away with =
pktcMtaDevProvConfigKey
>   once the Security =
ADs take a look?
Resolution:
  - =
change the syntax of pktcMtaDevProvConfigKey to be 32 octets =
(256)
    or may be =
more
        - =
add a new TC PktcMtaDevProvEncryptAlg and put the =
list:
       &nbs=
p;            =
;       none(0),
       &nbs=
p;            =
;       =
des64CbcMode(1),
       &nbs=
p;            =
;       =
t3Des128CbcMode(2),
       &nbs=
p;            =
;       =
aes128CbcMode(3),
       &nbs=
p;            =
;       =
aes256CbcMode(4)
      - add a =
new object named pktcMtaDevProvConfigEncryptAlg to =
specify
       the =
encryption algorithm of type =
PktcMtaDevProvEncryptAlg
      - add DEFVAL =
des64CbcMode
     - add a compliance =
statement to only require des64CbcMode =
for
       =
compliant PacketCable 1.0 =
implementations.
The above =
proposal is inline with the Security AD comments on the =
BPI+
encryption algorithms and ok with =
us.
 
 
# Comment =
22
> - The comment lines on page =
26 probably better go into some
>   object =
DESCRIPTION clause, no?
Resolution: moved the comment into the =
description clauses and pasted
the same =
text in all of the 3 relevant =
objects
(pktcMtaDevProvUnsolicitedKeyMaxTimeout,<=
/o:p>
pktcMtaDevProvUnsolicitedKeyNomTimeout,
pktcMtaDevProvUnsolicitedKeyMaxRetries).<=
/o:p>
 
 
# Comment =
23
> - =
pktcMtaDevRealmOrgName
>   Is this really an =
SnmpAdminString of max size 64?
We =
confirmed the 2 points:
per =
RFC2459:
   - Organization Name MUST be of =
"UTF8String" (for all certs =
after
     Dec 31, =
2003).
   - upper boundery is 64 for =
Organization name. Given that a =
signle
     char can take up to =
6 octets in SnmpAdminString, we proposed =
to
     increase the max =
limit to 255.
CONCLUSION: "SnmpAdminString" type =
is the closest mapping to =
"UTF8String"
       &nbs=
p;        Hence, leave the SYNTAX =
"as is" - =
SnmpAdminString.
Resolution:
        = Increased upper bound limit.
 
 
# Comment =
24
> - Page =
44
>     &=
nbsp;      OBJECT  =
pktcMtaDevServerAddressType
>     &=
nbsp;          =
SYNTAX   =
   InetAddressType
>     &=
nbsp;          =
DESCRIPTION
>     &=
nbsp;           &n=
bsp;  " Support for address types other than =
'ipv4(1)'
>     &=
nbsp;           &n=
bsp;    is not presently specified and therefore, is =
not
>     &=
nbsp;           &n=
bsp;    required. It may be defined in future versions =
of
>     &=
nbsp;           &n=
bsp;    this MIB =
module."
>   In order to say =
so in machine readable form, yopu =
do:
>     &=
nbsp;      OBJECT  =
pktcMtaDevServerAddressType
>     &=
nbsp;          =
SYNTAX      InetAddressType { ipv4(1) =
}
>     &=
nbsp;          =
DESCRIPTION
>     &=
nbsp;           &n=
bsp;  " Support for address types other than =
'ipv4(1)'
>     &=
nbsp;           &n=
bsp;    is not presently specified and therefore, is =
not
>     &=
nbsp;           &n=
bsp;    required. It may be defined in future versions =
of
>     &=
nbsp;      =
          this MIB =
module."
ok, will =
be reflected in all applicable =
objects.
 
 
# Comment =
25
>   You then also add =
the InetAddress objects with alength of =
4.
>   You have done =
this in other MIB modules, so you should know I =
think.
Resolution:
   Changes reflected in all = applicable objects.
        =
OBJECT    =
pktcMtaDevServerDhcp1
       &nbs=
p;    SYNTAX  InetAddress =
(SIZE(4))
       &nbs=
p;    =
DESCRIPTION
       &nbs=
p;         "An =
implementation is only required to support =
IPv4
       &nbs=
p;    Addresses. Other address types support may be =
defined in
       &nbs=
p;    future versions of this MIB =
module."
        =
OBJECT    =
pktcMtaDevServerDhcp2
       &nbs=
p;    SYNTAX  InetAddress =
(SIZE(4))
       &nbs=
p;    =
DESCRIPTION
       &nbs=
p;         "An =
implementation is only required to support =
IPv4
       &nbs=
p;    Addresses. Other address types support may be =
defined in
       &nbs=
p;    future versions of this MIB =
module."
        =
OBJECT    =
pktcMtaDevServerDns1
       &nbs=
p;    SYNTAX  InetAddress =
(SIZE(4))
       &nbs=
p;    =
DESCRIPTION
       &nbs=
p;         "An =
implementation is only required to support =
IPv4
       &nbs=
p;    Addresses. Other address types support may be =
defined in
       &nbs=
p;    future versions of this MIB =
module."
        =
OBJECT    =
pktcMtaDevServerDns2
       &nbs=
p;    SYNTAX  InetAddress =
(SIZE(4))
       &nbs=
p;    =
DESCRIPTION
       =
          "An =
implementation is only required to support =
IPv4
       &nbs=
p;    Addresses. Other address types support may be =
defined in
       &nbs=
p;    future versions of this MIB =
module."
        =
OBJECT    =
pktcMtaDevTimeServer
       &nbs=
p;    SYNTAX  InetAddress =
(SIZE(4))
       &nbs=
p;    =
DESCRIPTION
       &nbs=
p;         "An =
implementation is only required to support =
IPv4
       &nbs=
p;    Addresses. Other address types support may be =
defined in
       &nbs=
p;    future versions of this MIB =
module."
 
 
# Comment =
26
>   and is a similar =
refinement for pktcMtaBasicSmtaCompliance also =
not
>   =
needed/wanted?
Resolution: agree. Added to the S-MTA =
compliance group.
 
 
# Comment =
27
> - Refrence RFC3291 can now be =
repalced by RFC4001
ok, =
fixed.
 
 
# Comment =
28
> I suspect we need another =
serious and close review.
We as =
co-authors would really like to understand the next steps =
in
more =
details. This draft has passed WGLC, has had at least 2 if not =
3
MIB =
doctor reviews and now your complete =
review.
 
 
 
> =
Bert
Thanks =
again for all the comments
 
The =
following are comments received on the draft from Randy =
Presuhn
and other =
IPCDN WG participants.
 
# Comment =
29
> - object =
pktcMtaDevProvUnsolicitedKeyMaxTimeout
>   is a read-only = object and has text in the DESCRIPTION clause about = 
>     &=
nbsp;        If this object is set to =
a zero value, the MTA MUST =
return
>     &=
nbsp;        an 'inconsistentValue' =
in response to SNMP SET =
operations.
>   That seems =
conflicting, no?
Resolution:
deleted:     If this = object is set to a zero value, the MTA MUST = return
       &nbs=
p;     an 'inconsistentValue' in response to SNMP =
SET operations.
 
# Comment =
30
> - Same for =
pktcMtaDevProvUnsolicitedKeyNomTimeout
Resolution:deleted:     If this = object is set to a zero value, the MTA MUST = return
       &nbs=
p;     an 'inconsistentValue' in response to SNMP =
SET operations.
 
# Comment =
31
> - I wonder if for an object =
like pktcMtaDevProvKerbRealmName =

>   it is wise to use =
SnmpAdminString while the content MUST =
be
>   uppercase ASCII =
??
Resolution: based on the above and the =
subsequent discussions, the
co-authors prefer to leave the object =
as-is.
See =
comment #15.
The =
Kerberos protocol (RFC1510, RFC4120) defines the RealmName to =
be
of ASN.1 =
type "GeneralString". This type has numerous interop =
problems
(RFC4120, =
section 5.2.1).
The newer =
version of Kerberos protocol (RFC4120) requires that =
the
RealmName =
follows a new type "KerberosString" which =
effectively
constrains the value of the GeneralString to =
only contain characters
in =
IA5String.
     KerberosString  =
::=3D GeneralString (IA5String)
The =
"IA5String" type is defined in ISO/IEC646:1991 and also =
known
as =
US-ASCII.
Hence, =
based on the above analysis, "DisplayString" =
and
"SnmpAdminString" seem to be the =
closest mapping in SMI.
 
 
# Comment =
32
> - Same for =
pktcMtaDevRealmName
Resolution: based on the above and the =
subsequent discussions, the
co-authors prefer to leave the object =
as-is.
 
 
# Comment =
33
> - Why is =

>    =
pktcMtaDevRealmAvailSlot   =
OBJECT-TYPE
>     &=
nbsp;  SYNTAX      Unsigned32 =
(0..64)
> =

>   While =

>    =
pktcMtaDevRealmIndex  =
OBJECT-TYPE
>     &=
nbsp;  SYNTAX      Unsigned32 =
(1..32)
> =

>   Should they not =
be both limited to 64 or 32 (i.e. same value) =
??
Agree.
Resolution:
  = change pktcMtaDevRealmIndex's SYNTAX = to
       =
SYNTAX      Unsigned32 =
(1..64)
 
# Comment =
34
> - Same =
for
>    =
pktcMtaDevCmsAvailSlot   =
OBJECT-TYPE
>     &=
nbsp;  SYNTAX      Unsigned32 =
(0..128)
>   =
and
>    =
pktcMtaDevCmsIndex  =
OBJECT-TYPE
>     &=
nbsp;  SYNTAX      Unsigned32 =
(1..64)
Resolution:
  = change pktcMtaDevCmsIndex's SYNTAX = to
       =
SYNTAX       Unsigned32 =
(1..128)
 
 
# Comment =
35
> - I wonder =
why:
> =

>    =
pktcMtaNotificationPrefix OBJECT IDENTIFIER ::=3D { pktcMtaMib 2 =
}
>    =
pktcMtaNotification OBJECT IDENTIFIER ::=3D =
{
>    =
pktcMtaNotificationPrefix 0 }
> =

>   is not specified =
as:
> =

>    =
pktcMtaNotifications OBJECT IDENTIFIER ::=3D { pktcMtaMib 0 =
}
> =

>   as suggested in =
the mib-review-guideleines.
>   It is not =
forbidden. I just wonder
Resolution:
  = change text to follow mib design guidelines as = follows:
   pktcMtaNotifications OBJECT =
IDENTIFIER ::=3D { pktcMtaMib 0 =
}
The text =
looks like this now:
 
pktcMtaNotification OBJECT IDENTIFIER ::=3D { =
pktcIetfMtaMib 0 }
pktcMtaMibObjects  OBJECT IDENTIFIER =
::=3D { pktcIetfMtaMib 1 }
pktcMtaDevBase     OBJECT =
IDENTIFIER ::=3D { pktcMtaMibObjects 1 =
}
pktcMtaDevServer   OBJECT =
IDENTIFIER ::=3D { pktcMtaMibObjects 2 =
}
pktcMtaDevSecurity OBJECT IDENTIFIER ::=3D { =
pktcMtaMibObjects 3 }
pktcMtaDevErrors   OBJECT =
IDENTIFIER ::=3D { pktcMtaMibObjects 4 =
}
pktcMtaConformance  OBJECT IDENTIFIER =
::=3D { pktcIetfMtaMib 2 }
 
 
# Comment 36
> - I wonder =
why
>    =
pktcMtaBasicCompliance =
MODULE-COMPLIANCE
> =

>     &=
nbsp;  STATUS      =
current
>     &=
nbsp;  DESCRIPTION
>     &=
nbsp;      " The compliance statement for =
MTA devices that implement
>     &=
nbsp;        PacketCable or =
IPCablecom requirements.
> =

>     &=
nbsp;        This compliance =
statement applies to MTA =
implementations
>     &=
nbsp;        that support PacketCable =
1.0 or IPCablecom requirements,
>     &=
nbsp;        which are not =
IPv6-capable at the time of =
this
>      =
        RFC =
publication."
> =

>     &=
nbsp;  MODULE  -- Unconditionally mandatory groups for =
MTAs
> =

>     &=
nbsp;      MANDATORY-GROUPS =
{
>     &=
nbsp;          =
pktcMtaGroup,
>     &=
nbsp;          =
pktcMtaNotificationGroup
>     &=
nbsp;      =
}
> =

>     &=
nbsp;      OBJECT  =
pktcMtaDevServerAddressType
>     &=
nbsp;          =
SYNTAX      =
InetAddressType
>     &=
nbsp;          =
DESCRIPTION
>     &=
nbsp;           &n=
bsp;  " Support for address types other than =
'ipv4(1)'
>     &=
nbsp;           &n=
bsp;    is not presently specified and therefore, is =
not
>     &=
nbsp;           &n=
bsp;    required. It may be defined in future versions =
of
>     &=
nbsp;           &n=
bsp;    this MIB =
module."
>     &=
nbsp;  ::=3D { pktcMtaCompliances 1 =
}
> =

>   Does not have the =
following:
> =

>     &=
nbsp;      MANDATORY-GROUPS =
{
>     &=
nbsp;          =
pktcMtaGroup,
>     &=
nbsp;          =
pktcMtaNotificationGroup
>     &=
nbsp;      =
}
> =

>     &=
nbsp;      OBJECT  =
pktcMtaDevServerAddressType
>     &=
nbsp;          =
SYNTAX      InetAddressType { ipv4(1) =
}
>     &=
nbsp;          =
DESCRIPTION
>     &=
nbsp;           &n=
bsp;  " Support for address types other than =
'ipv4(1)'
>     &=
nbsp; =
            &=
nbsp;  is not presently specified and therefore, is =
not
>     &=
nbsp;           &n=
bsp;    required. It may be defined in future versions =
of
>     &=
nbsp;           &n=
bsp;    this MIB =
module."
>     &=
nbsp;      OBJECT =
pktcMtaDevServerDhcp1
>     &=
nbsp;          =
SYNTAX     InetAddress SIZE =
(4)
>     &=
nbsp;          =
SESCRIPTION
>     &=
nbsp;           &n=
bsp;  " Support for address formats other than =
'ipv4(1)'
>     &=
nbsp;           &n=
bsp;    is not presently specified and therefore, is =
not
>     &=
nbsp;           &n=
bsp;    required. It may be defined in future versions =
of
>     &=
nbsp;           &n=
bsp;    this MIB =
module."
> =

>     &=
nbsp;      .... and similar swtuff for the =
other InetAddress objects
> =

>     &=
nbsp;  ::=3D { pktcMtaCompliances 1 =
}
ok, =
addressed.
 
 
# Comment =
37
> - Same for the =
pktcMtaBasicSmtaCompliance =
spec.
Agree, =
fixed.
 
 
# Comment =
38
> - At various places in your =
MIB module you have FQDNs =
present.
>   I wonder if it =
would not be wise (for interoperability) to =

>   specify WHEN such =
FQDNs are supposed to be resolved to IP =
addresses.
Agree.
Resolution: added new text as =
follows:
  =
for pktcMtaDevFQDN:
       &nbs=
p;  The MTA FQDN is used to uniquely identify =
the
       &nbs=
p;  device to the PacketCable back office =
elements.
  =
(on this one, the MTA does not resolve it, just uses =
it).
 
pktcMtaDevSnmpEntity<=
/pre>
       &nbs=
p; The MTA must resolve the FQDN value before its very =
first
       &nbs=
p; network interaction with the SNMP entity during =
the
       &nbs=
p; provisioning phase as specified in the PacketCable MTA =
Device
       &nbs=
p; Provisioning specification.
 
pktcMtaDevCmsFqdn
       &nbs=
p;   The MTA must resolve the CMS FQDN as =
required
       &nbs=
p;   by the corresponding PacketCable =
Specifications."
    =
REFERENCE
        =
" PacketCable MTA Device Provisioning =
Specification;
       &nbs=
p;  PacketCable Security =
Specification;
       &nbs=
p;  PacketCable Network-Based Call Signaling =
Protocol
       &nbs=
p;  Specification."
 
# Comment =
39
--- Other comments on MTA MIB =
draft06
Bert =
wrote:
> I also see that various =
comments/questions were posted to =
the
> IPCDN WG mailing list, so =
those need to be answered too.
ok, see =
Comments 40 and above for the log of other issues. We =
believe
draft07 =
does address all comments received to date. If we missed =
any,
let us =
know.
 
 
# Comment =
40
From =
Randy
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01600.html
Duplicate =
of Comment 31.
 
# Comment =
41
From =
Randy, thread with subject title "[ipcdn] =
pktcMtaDevProvConfigKey"
Initial =
pointer:
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01537.html
 
Resolution: add the following text in the =
description:
       &nbs=
p;  The value of this object is provided along with =
the
       &nbs=
p;  configuration file information =
(pktcMtaDevConfigFile)
       &nbs=
p;  and hash (pktcMtaDevProvConfigHash) by the =
Provisioning
       &nbs=
p;  Server via SNMP SET once the configuration file has =
been
       &nbs=
p;  created as defined by the PacketCable =
Security
       &nbs=
p;  specification.
 
       &nbs=
p;  If the configuration file the MTA receives is =
not
       &nbs=
p;  encrypted, the length of this object value is =
zero.
       &nbs=
p;  If the file is encrypted, then the algorithm is DES =
in
       &nbs=
p;  CBC mode and the length of this object value is 64 =
bits
       &nbs=
p;  (an IV of zero is used to encrypt the file as =
specified
       &nbs=
p;  in the PacketCable Security =
specification).
 
and =
change the MUST into SHOULD as proposed =
below:
       &nbs=
p;  This object must not be used in non secure =
provisioning
       &nbs=
p;  mode.  In non secure provisioning modes, the MTA =
SHOULD
       &nbs=
p;  return an 'inconsistentValue' in response to SNMP =
SET
       &nbs=
p;  operations, and, the MTA SHOULD return a =
zero-length
       &nbs=
p;  string in response to SNMP GET =
operations.
 (this to =
address potential issues with some agent =
implementations
like =
AgentX).
 
 
# Comment =
42
Comment =
from Thomas Anders:
delete
>     &=
nbsp;       This object value is used as =
an index into the
>     &=
nbsp;       =
pktcMtaDevRealmTable.
in the =
description clause of =
pktcMtaDevProvKerbRealmName.
 
> =
end.
 



 



 



> -----Original Message-----



> From: Internet-Drafts@ietf.org =
[mailto:Internet-Drafts@ietf.org]



> Sent: Thursday, October 27, 2005 8:50 AM



> To: i-d-announce@ietf.org



> Cc: ipcdn@ietf.org



> Subject: I-D =
ACTION:draft-ietf-ipcdn-pktc-mtamib-07.txt



> 



> 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



> =
            &=
nbsp;           &n=
bsp; Information Base for PacketCable and



> =
            &=
nbsp;           &n=
bsp; IPCablecom compliant devices



>     Author(s)   : E. Nechamkin, J. =
Mule



>     Filename    : =
draft-ietf-ipcdn-pktc-mtamib-07.txt



>     =
Pages       : 60



>     =
Date        : =
2005-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 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-<=
/font>



> 07.txt



> 



> To remove yourself from the I-D Announcement list, send a =
message
to



> i-d-announce-request@ietf.org with the word unsubscribe in =
the
body of



> the message.



> You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce



> to change your subscription settings.



> 



> 



> Internet-Drafts are also available by anonymous FTP. Login =
with
the



> username



> "anonymous" and a password of your e-mail =
address. After
logging in,



> type "cd internet-drafts" and =
then



>     "get =
draft-ietf-ipcdn-pktc-mtamib-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-pktc-mtamib-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_001_01C5DB33.8540FB91-- --===============1707978130== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1707978130==--