From exim@www1.ietf.org Thu Dec 4 11:15:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02959 for ; Thu, 4 Dec 2003 11:15:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARw8C-0008ET-Hd for ipcdn-archive@odin.ietf.org; Thu, 04 Dec 2003 11:15:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4GF8gr031641 for ipcdn-archive@odin.ietf.org; Thu, 4 Dec 2003 11:15:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARw86-0008DO-F6; Thu, 04 Dec 2003 11:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARw7B-00087X-8T for ipcdn@optimus.ietf.org; Thu, 04 Dec 2003 11:14:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02902 for ; Thu, 4 Dec 2003 11:13:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARw7A-000447-00 for ipcdn@ietf.org; Thu, 04 Dec 2003 11:14:04 -0500 Received: from sys4.smerdon.livonia.mi.us ([208.176.108.155] helo=umcc.ais.org) by ietf-mx with smtp (Exim 4.12) id 1ARw79-00043t-00 for ipcdn@ietf.org; Thu, 04 Dec 2003 11:14:04 -0500 Received: from sys4.smerdon.livonia.mi.us([208.176.108.155]) (1406 bytes) by umcc.ais.org via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Thu, 4 Dec 2003 11:14:02 -0500 (EST) (Smail-3.2.0.111 2000-Feb-17 #1 built 2002-Nov-3) Date: Thu, 4 Dec 2003 11:14:01 -0500 (EST) From: Shahram Esfahani To: ipcdn@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ipcdn] Update to RFC2669 (Resend) Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi folks, I never got a response for anyone so I am resending my question/comments. In light of the recent virus/worm attacks on cable subscribers, has the IETF considered updating RFC2669 to include rate-limiting? Many MSOs combated the network impacts of the virus/worm infections by configuring ACLs on their CMTS. However, the traffic characteristics of these infected users reveled numerous ICMP echo requests being sent upstream -- in the magnitude of hundreds per second. Having just a few infected users in a MAC domain can put unnecessary stress on the CMTS to issue grants and flood the domain with ARP requests. A better solution to these CMTS-centric ACLs would be to rate-limit this type of traffic on the cable modem. Rate-limiting can also be applied to other traffic besides ICMP. For example, some MSOs have expressed concerns about very aggressive IP stacks sending DHCP packets too quickly causing server strain. Your thoughts about this? Thanks and regards, Shahram _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Dec 4 16:49:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18631 for ; Thu, 4 Dec 2003 16:49:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS1LM-0002fL-RT for ipcdn-archive@odin.ietf.org; Thu, 04 Dec 2003 16:49:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4Ln49g010244 for ipcdn-archive@odin.ietf.org; Thu, 4 Dec 2003 16:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS1LI-0002f3-Ue; Thu, 04 Dec 2003 16:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS1L5-0002en-9C for ipcdn@optimus.ietf.org; Thu, 04 Dec 2003 16:48:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18610 for ; Thu, 4 Dec 2003 16:48:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS1L3-000219-00 for ipcdn@ietf.org; Thu, 04 Dec 2003 16:48:45 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AS1L1-00020U-00 for ipcdn@ietf.org; Thu, 04 Dec 2003 16:48:43 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hB4LlpoK014860; Thu, 4 Dec 2003 14:47:51 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BAB0.43C275E2" Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Date: Thu, 4 Dec 2003 14:47:51 -0700 Message-ID: Thread-Topic: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcO6rRmPtySoJXHeRMqNqPOJ/PLpGQAApjjw From: "Jean-Francois Mule" To: , "Greg White" Cc: "Dan Rice @ Stargus" , "DOCSIS OSS Majordomo List" , , , , "Minnie Lu" , "Owner DOCSIS OSS Majordomo List" X-Approved: ondar Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3BAB0.43C275E2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks David for your comments. Up to the author/editor (David Raftus/Eduardo) to decide what to do and whether to incorporate in draft 09. =20 Note well: You all realize that we cannot move the IPCDN DOCSIS MIB drafts along the IETF process if we keep getting more and more *technical* comments, even after the WG last calls and other comment deadlines... =20 Jean-Francois. =20 =20 =20 =20 -----Original Message----- From: David.White@arrisi.com [mailto:David.White@arrisi.com]=20 Sent: Thursday, December 04, 2003 2:21 PM To: Greg White Cc: Dan Rice @ Stargus; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) =09 =09 A few points that I hope are not too late:=20 =09 docsIfCmtsModControl=20 It might be acceptable to delay enforcing the same channel type across all IUCs until the modulation profile gets assigned to an upstream. That is, one could freely modify the mod prof channel types as long as the modulation profile is assigned to an upstream. This would remove any requirements on the RowStatus being notInService(2). I'm bringing this up now because I'm looking at the command line implementation of this logic and taking individual IUCs out of service is more cumbersome than just de-assigning the modulation profile from the upstream, especially since the modulation profile will have to be de-assigned or the upstream taken out of service anyways since individual (and probably required IUCs) are being taken out of service, thus preventing proper operation of the upstream channel.=20 =09 docsIfCmtsModChannelType=20 It might not be necessary or desirable to force all IUCs within a modulation profile to have the same channel type. I believe I have a clearer understanding of the way the mixed-mode tdmaAndAtdma upstream channel type works. I believe the reason for using such an upstream channel would be to allow both DOCSIS 1.x tdma-only and DOCSIS 2.0 atdma-capable modems of operation on the same upstream. As such, IUCs 1, 3-6, and possibly 2 would need to be eiher tdma or tdmaAndAtdma. Otherwise, tdma-only modems would not be able to operate. Likewise, it would seem that IUCs 9, 10, and possibly 11 would be required and would need to be atdma or tdmaAndAtdma, but following the rules for atdma.=20 =09 Going further, it seems that IUCs 1-6, when set to tdmaAndAtdma, should follow the rules for tdma. Otherwise, if they follow the atdma rules, then tdmaAndAtdma for IUCs 1-6 is pointless, since tdma-only modems will not be able to operate. Likewise, if IUCs 9-11 are set to tdmaAndAtdma, then they should follow the rules for atdma.=20 =09 To illustrate, I believe that the following modulation profile sets, one for each channel type, should be allowed:=20 =09 1) tdma upstream channel=20 IUC chanType=20 1 tdma or tdmaAndAtdma (must follow tdma rules)=20 2 tdma or tdmaAndAtdma (must follow tdma rules) - this IUC is optional=20 3 tdma or tdmaAndAtdma (must follow tdma rules)=20 4 tdma or tdmaAndAtdma (must follow tdma rules)=20 5 tdma or tdmaAndAtdma (must follow tdma rules)=20 6 tdma or tdmaAndAtdma (must follow tdma rules)=20 9 ignored - IUC not used=20 10 ignored - IUC not used=20 11 ignored - IUC not used=20 =09 2) atdma upstream channel=20 IUC chanType=20 1 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)=20 2 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules) - this IUC is optional=20 3 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)=20 4 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)=20 5 ignored - IUC not used=20 6 ignored - IUC not used=20 9 atdma or tdmaAndAtdma (must follow atdma rules)=20 10 atdma or tdmaAndAtdma (must follow atdma rules)=20 11 atdma or tdmaAndAtdma (must follow atdma rules) - this IUC is optional=20 =09 3) tdmaAndAtdma upstream channel=20 IUC chanType=20 1 tdma or tdmaAndAtdma (must follow tdma rules)=20 2 tdma or tdmaAndAtdma (must follow tdma rules) - this IUC is optional=20 3 tdma or tdmaAndAtdma (must follow tdma rules)=20 4 tdma or tdmaAndAtdma (must follow tdma rules)=20 5 tdma or tdmaAndAtdma (must follow tdma rules)=20 6 tdma or tdmaAndAtdma (must follow tdma rules)=20 9 atdma or tdmaAndAtdma (must follow atdma rules)=20 10 atdma or tdmaAndAtdma (must follow atdma rules)=20 11 atdma or tdmaAndAtdma (must follow atdma rules) - this IUC is optional=20 =09 4) scdma upstream channel=20 IUC chanType=20 1 scdma=20 2 scdma - this IUC is optional=20 3 scdma=20 4 scdma=20 5 ignored - IUC not used=20 6 ignored - IUC not used=20 9 scdma=20 10 scdma=20 11 scdma - this IUC is optional=20 =09 I have included modulation profile channel type tdmaAndAtdma for completeness' sake only. Note that the same results can be achieved without the tdmaAndAtdma modulation profile channel type, even though an usptream channel type of tdmaAndAtmda is still desirable. Thus, we could reduce the complexity and confusion of the modulation profile table by removing the tdmaAndAtdma modulation profile channel type altogether. Also note that modulation profile 3 (for the tdmaAndAtdma upstream channel) could be used on a tdma-only upstream channel, assuming the UCD and mapper algorithms on the CMTS ignore IUCs 9-11.=20 =09 What do you think ?=20 =09 Thanks,=20 David White=20 ARRIS Cadant C4 CMTS=20 Software Engineer=20 =09 =09 =09 =09 =09 "Greg White" =20 Sent by: owner-docsis-oss@cablelabs.com=20 10/10/2003 12:56 PM=20 =20 To: "Dan Rice @ Stargus" , "Minnie Lu" =20 cc: , "DOCSIS OSS Majordomo List" , , , =20 Fax to: =20 Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) What I had interpreted Minnie's suggestion to be was that ChannelType consistency was enforced across all modulation profile rows with a Status of 'active', regardless of whether they were assigned to an upstream channel or not. Setting Status to 'notInService' is not allowed for propfiles assigned to an upstream channel, nor is changing ChannelType. =09 So, the operation Minnie suggested only applies to profiles that have been created and set 'active', but are not assigned to any upstream channel. =09 Does that clarify? =09 -Greg =09 =09 -----Original Message----- From: Dan Rice @ Stargus=20 Sent: Friday, October 10, 2003 7:59 AM To: Greg White; Minnie Lu Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) =09 =09 Sorry for chiming in 11th hour, but want to make sure I understand minnie's suggestion for active entries. I believe the suggestion is that for active entries you change the row status to not in service. What would we expect to happen to the upstream currently assigned this modulation profile while it is notInService? Would the existing active assignment continue to be valid for the upstream using it until all IUC rows became active again with the changes in them? =09 Also if the changes are to docsIfCmtsModChannelType wouldn't you have to edit all IUC rows before checking to see if this is valid? I guess when you started going in and making each IUC active that would be the point to check it? Could you guarantee that all IUCs are committed at the same time since they would "immediately" be committed to the active upstream channel entries with pointers to the docsIfCmtsModIndex? =09 Thanks for the clarifications. - Dan =09 -----Original Message----- From: Greg White [mailto:g.white@CableLabs.com]=20 Sent: Wednesday, October 08, 2003 7:20 PM To: Minnie Lu Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) =09 That sounds like a workable alternative. If no one disagrees, I will make that change to the proposal. =09 -Greg =09 =09 -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Wednesday, October 08, 2003 3:09 PM To: Greg White Cc: Minnie Lu; David.White@arrisi.com; DOCSIS OSS Majordomo List;=20 Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) =09 =09 Hi, Greg, =09 Then how about enforce this rule for "active" entries ? So in the case you=20 mentioned, user can change the row status to notInService first or at the=20 same time changing the channel type. When user changed all the entries' =09 channel type to be the same, use can put the entries in active again. I =09 personally think it affects a lot when the channel type is changed, so a =09 little more steps should be ok. To me, if there is an error, better catch=20 it as earlier as possible. =09 "All the active entries in a modulation profile (i.e. all active entries =09 that share a common docsIfCmtsModIndex) MUST have the same value of docsIfCmtsModChannelType." =09 Thanks a lot ! Minnie =09 At 02:12 PM 10/8/2003 -0600, Greg White wrote: >Minnie, > >I didn't want to prevent a user from changing their mind regarding >channel type when creating a new modulation profile. Suppose you >started out setting channel type to atdma and, after completing a few >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make >you start from scratch (or do a simultaneous set across all IUCs), you >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Hi, Greg, > > Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the >modulation profile is not assigned to any upstreams. So the error could >be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please review >the > >attached proposal and provide comments. > >=20 > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , , , > > > "DOCSIS OSS Majordomo List" , "Owner DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same > > >ModChannelType. Also, based on the exchange here it seems that there >is > > >some support for the additional restriction that UpChannelType and > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change > > >UpChannelType to match ModChannelType whenever > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about the > >case that some modulation profile is used by some upstream channel, and > >user change the modulation profile channel type ? Does it mean that >the > >upstream channel type would be changed automatically, too ? If yes, I >am > >afraid that there might be some user who forget the modulation profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The > >modulation profile channel type and upstream channel type are in two > >different MIB tables.=20 > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type be > >changed ? Maybe this is a confusing point which needs to be clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > > >upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation profile > > >entries with the same docsIfCmtsModIndex will have to have the same > > >docsIfCmtsModChannelType. Otherwise, you would not be able to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid, no >? > > >The way to patch it up would be to make all of the IUCs tdmaAndAtdma, > > >correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List"=20 > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects > > > > docsIfCmtsModByteInterleaverBlockSize and > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma for > > > > modulation profiles that could not be met with a pair of tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line of > > > >thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations. Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of having >the > > > >MIB reporting something that doesn't exactly reflect what is > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the > > > > modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data for > > > > consistency. Furthermore, it would seem possible to compare the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > =09 =09 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn =09 =09 =09 =09 =09 ------_=_NextPart_001_01C3BAB0.43C275E2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Thanks David for your comments. Up to the author/editor (David=20 Raftus/Eduardo) to decide what to do and whether to incorporate in draft = 09.
 
Note well:
You all realize that we cannot move the IPCDN DOCSIS MIB drafts = along the=20 IETF process if we keep getting more and more *technical* = comments,=20 even after the WG last calls and other comment = deadlines...
 
Jean-Francois.
 
 
 
 
-----Original Message-----
From:=20 David.White@arrisi.com [mailto:David.White@arrisi.com] =
Sent:=20 Thursday, December 04, 2003 2:21 PM
To: Greg = White
Cc: Dan=20 Rice @ Stargus; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com;=20 ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS = Majordomo=20 List
Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was = RE:=20 DOCSIS 2.0 : rules for assigning modulation profiles to upstream=20 channels)


A = few points=20 that I hope are not too late:

docsIfCmtsModControl
It=20 might be acceptable to delay enforcing the same channel type across = all IUCs=20 until the modulation profile gets assigned to an upstream. That is, = one could=20 freely modify the mod prof channel types as long as the modulation = profile is=20 assigned to an upstream. This would remove any requirements on the = RowStatus=20 being notInService(2). I'm bringing this up now because I'm looking at = the=20 command line implementation of this logic and taking individual IUCs = out of=20 service is more cumbersome than just de-assigning the modulation = profile from=20 the upstream, especially since the modulation profile will have to be=20 de-assigned or the upstream taken out of service anyways since = individual (and=20 probably required IUCs) are being taken out of service, thus = preventing proper=20 operation of the upstream channel.

docsIfCmtsModChannelType
It might not be necessary or desirable to force all IUCs = within a=20 modulation profile to have the same channel type. I believe I have a = clearer=20 understanding of the way the mixed-mode tdmaAndAtdma upstream channel = type=20 works. I believe the reason for using such an upstream channel would = be to=20 allow both DOCSIS 1.x tdma-only and DOCSIS 2.0 atdma-capable modems of = operation on the same upstream. As such, IUCs 1, 3-6, and possibly 2 = would=20 need to be eiher tdma or tdmaAndAtdma. Otherwise, tdma-only modems = would not=20 be able to operate. Likewise, it would seem that IUCs 9, 10, and = possibly 11=20 would be required and would need to be atdma or tdmaAndAtdma, but = following=20 the rules for atdma.

Going=20 further, it seems that IUCs 1-6, when set to tdmaAndAtdma, should = follow the=20 rules for tdma. Otherwise, if they follow the atdma rules, then = tdmaAndAtdma=20 for IUCs 1-6 is pointless, since tdma-only modems will not be able to = operate.=20 Likewise, if IUCs 9-11 are set to tdmaAndAtdma, then they should = follow the=20 rules for atdma.

To = illustrate, I=20 believe that the following modulation profile sets, one for each = channel type,=20 should be allowed:

1) = tdma=20 upstream channel
IUC = chanType=20
  1 tdma or tdmaAndAtdma (must = follow tdma=20 rules)
  2 tdma or = tdmaAndAtdma=20 (must follow tdma rules) - this IUC is optional
  3 tdma or tdmaAndAtdma (must follow tdma rules) =
  4 tdma or tdmaAndAtdma (must follow = tdma=20 rules)
  5 tdma or = tdmaAndAtdma=20 (must follow tdma rules)
  6 tdma or=20 tdmaAndAtdma (must follow tdma rules)
  9 ignored - IUC not used
 10 ignored - IUC not used
 11 ignored - IUC not used

2) atdma upstream channel
IUC chanType
  = 1 atdma or=20 tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules) =
  2 atdma or tdmaAndAtdma (if = tdmaAndAtdma, must=20 follow tdma rules) - this IUC is optional
  3 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow = tdma=20 rules)
  4 atdma or = tdmaAndAtdma (if=20 tdmaAndAtdma, must follow tdma rules)
  5 ignored - IUC not used
  6 ignored - IUC not used
  9 atdma or tdmaAndAtdma (must follow atdma = rules)=20
 10 atdma or tdmaAndAtdma (must = follow=20 atdma rules)
 11 atdma = or=20 tdmaAndAtdma (must follow atdma rules) - this IUC is optional=20

3) tdmaAndAtdma upstream=20 channel
IUC chanType =
  1  tdma or tdmaAndAtdma (must = follow=20  tdma rules)
  2 =  tdma or=20 tdmaAndAtdma (must follow  tdma rules) - this IUC is = optional=20
  3  tdma or tdmaAndAtdma = (must follow=20  tdma rules)
  4 =  tdma or=20 tdmaAndAtdma (must follow  tdma rules)
  5  tdma or tdmaAndAtdma (must follow  tdma=20 rules)
  6  tdma or = tdmaAndAtdma (must follow  tdma rules)
  9 atdma or tdmaAndAtdma (must follow atdma = rules)=20
 10 atdma or tdmaAndAtdma (must = follow=20 atdma rules)
 11 atdma = or=20 tdmaAndAtdma (must follow atdma rules) - this IUC is optional=20

4) scdma upstream = channel=20
IUC chanType
  1 scdma
  2 scdma -=20 this IUC is optional
  3 = scdma
  4 scdma =
  5 ignored - IUC not used =
  6 ignored - IUC not used =
  9 scdma
 10 scdma
 11 scdma -=20 this IUC is optional

I = have=20 included modulation profile channel type tdmaAndAtdma for = completeness' sake=20 only. Note that the same results can be achieved without the = tdmaAndAtdma=20 modulation profile channel type, even though an usptream channel type = of=20 tdmaAndAtmda is still desirable. Thus, we could reduce the complexity = and=20 confusion of the modulation profile table by removing the tdmaAndAtdma = modulation profile channel type altogether.  Also note that = modulation=20 profile 3 (for the tdmaAndAtdma upstream channel) could be used on a = tdma-only=20 upstream channel, assuming the UCD and mapper algorithms on the CMTS = ignore=20 IUCs 9-11.

What do you = think=20 ?

Thanks, =
David White
ARRIS Cadant C4 CMTS
Software=20 Engineer




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

10/10/2003 12:56 PM =

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



What I had interpreted Minnie's suggestion to be was that=20 ChannelType
consistency was enforced across all modulation profile = rows=20 with a
Status of 'active', regardless of whether they were assigned = to=20 an
upstream channel or not.  Setting Status to 'notInService' = is=20 not
allowed for propfiles assigned to an upstream channel, nor is=20 changing
ChannelType.

So, the operation Minnie suggested = only=20 applies to profiles that have
been created and set 'active', but = are not=20 assigned to any upstream
channel.

Does that=20 clarify?

-Greg


-----Original Message-----
From: = Dan Rice=20 @ Stargus
Sent: Friday, October 10, 2003 7:59 AM
To: Greg = White; Minnie=20 Lu
Cc: David.White@arrisi.com; DOCSIS OSS Majordomo=20 List;
Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com;=20 ipcdn@ietf.org
Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 = (was RE:=20 DOCSIS 2.0 :
rules for assigning modulation profiles to upstream=20 channels)


Sorry for chiming in 11th hour, but want to make = sure I=20 understand
minnie's suggestion for active entries.  I believe = the=20 suggestion is
that for active entries you change the row status to = not in=20 service.
What would we expect to happen to the upstream currently = assigned=20 this
modulation profile while it is notInService?  Would the = existing=20 active
assignment continue to be valid for the upstream using it = until all=20 IUC
rows became active again with the changes in them?

Also = if the=20 changes are to docsIfCmtsModChannelType wouldn't you have to
edit = all IUC=20 rows before checking to see if this is valid?  I guess = when
you=20 started going in and making each IUC active that would be the = point
to=20 check it?  Could you guarantee that all IUCs are committed at = the
same=20 time since they would "immediately" be committed to the = active
upstream=20 channel entries with pointers to the docsIfCmtsModIndex?

Thanks = for the=20 clarifications. - Dan

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

That sounds like a workable alternative.  If no = one=20 disagrees, I will
make that change to the=20 proposal.

-Greg


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


Hi, Greg,

Then how about enforce this rule = for=20 "active" entries ? So in the case
you
mentioned, user can = change the=20 row status to notInService first or at
the
same time changing = the=20 channel type.  When user changed all the entries'

channel = type to=20 be the same, use can put the entries in active again.=20  I

personally think it affects a lot when the channel type = is=20 changed, so a

little more steps should be ok.  To me, if = there is=20 an error, better
catch
it as earlier as possible.

"All = the=20 active entries in a modulation profile (i.e. all active = entries

that=20 share a
common docsIfCmtsModIndex) MUST have the same value=20 of
docsIfCmtsModChannelType."

Thanks a lot = !
Minnie

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


_______________________________________________
IPCDN = mailing=20 = list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



=00 ------_=_NextPart_001_01C3BAB0.43C275E2-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Dec 4 17:13:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20246 for ; Thu, 4 Dec 2003 17:13:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS1iY-0003nI-GY for ipcdn-archive@odin.ietf.org; Thu, 04 Dec 2003 17:13:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4MD24l014561 for ipcdn-archive@odin.ietf.org; Thu, 4 Dec 2003 17:13:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS1iW-0003md-PV; Thu, 04 Dec 2003 17:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS1hp-0003lM-UG for ipcdn@optimus.ietf.org; Thu, 04 Dec 2003 17:12:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20216 for ; Thu, 4 Dec 2003 17:12:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS1hn-0002rn-00 for ipcdn@ietf.org; Thu, 04 Dec 2003 17:12:15 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AS1hm-0002rc-00 for ipcdn@ietf.org; Thu, 04 Dec 2003 17:12:14 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hB4MBfoK017544; Thu, 4 Dec 2003 15:11:42 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RFMIBv2 ID-nits: references Date: Thu, 4 Dec 2003 15:11:41 -0700 Message-ID: Thread-Topic: [ipcdn] RFMIBv2 ID-nits: references Thread-Index: AcO6rRmPtySoJXHeRMqNqPOJ/PLpGQAAzjaA From: "Jean-Francois Mule" To: , "Eduardo Cardona" , Cc: X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Check ID nits and other comments made by mib doctors in other drafts. http://www.ietf.org/ID-nits.html There are normative references that are not even mentioned once and not = used as IMPORTs in the document: [1] Woundy, R., "Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems", RFC3083, March 2001. [9] "Adapted MIB-definitions and a clarification for MPEG-related=20 issues for EuroDOCSIS cable modem systems v1.01", tComLabs,=20 May 2000., available at http://www.tcomlabs.com.=20 Suggestions: - call this reference in the text or just remove it; - I cannot find the named reference under http://www.tcomlabs.com ; if = you keep it, then we need a better link, especially if it remains = normative. Also, should [6] be made informative instead of normative? (a) it's a book=20 (b) the DOCSIS specs are referenced normatively and that's where a = normative reference on QPSK should be. [6] Proakis, John G., "Digital Communications, 3rd Edition",=20 McGraw-Hill, New York, New York, 1995, ISBN 0-07-051726-6=20 Thanks, Jean-Fran=E7ois PS: also, CableLabs is working on a stable HTTP URL for our = specifications so the http://www.cablemodem.com URL will most likely = have to be updated. More on the actual URL soon. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Dec 4 17:29:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20883 for ; Thu, 4 Dec 2003 17:29:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS1y2-0004g2-EY for ipcdn-archive@odin.ietf.org; Thu, 04 Dec 2003 17:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4MT2nh017958 for ipcdn-archive@odin.ietf.org; Thu, 4 Dec 2003 17:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS1y1-0004f7-61; Thu, 04 Dec 2003 17:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS0v5-0001Ql-Cd for ipcdn@optimus.ietf.org; Thu, 04 Dec 2003 16:21:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15648 for ; Thu, 4 Dec 2003 16:21:39 -0500 (EST) From: David.White@arrisi.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS0v3-0000kR-00 for ipcdn@ietf.org; Thu, 04 Dec 2003 16:21:53 -0500 Received: from [63.86.74.179] (helo=mars.ARRISI.COM) by ietf-mx with esmtp (Exim 4.12) id 1AS0ux-0000ja-00 for ipcdn@ietf.org; Thu, 04 Dec 2003 16:21:48 -0500 To: "Greg White" Cc: "Dan Rice @ Stargus" , "DOCSIS OSS Majordomo List" , Greg.Gohman@arrisi.com, ipcdn@ietf.org, Larry.Spaete@arrisi.com, "Minnie Lu" , owner-docsis-oss@cablelabs.com Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: Date: Thu, 4 Dec 2003 16:21:20 -0500 X-MIMETrack: Serialize by Router on Mars/Arris(Release 5.0.11 |July 24, 2002) at 12/04/2003 04:21:48 PM, Serialize complete at 12/04/2003 04:21:48 PM Content-Type: multipart/alternative; boundary="=_alternative 00754F4D85256DF2_=" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 00754F4D85256DF2_= Content-Type: text/plain; charset="us-ascii" A few points that I hope are not too late: docsIfCmtsModControl It might be acceptable to delay enforcing the same channel type across all IUCs until the modulation profile gets assigned to an upstream. That is, one could freely modify the mod prof channel types as long as the modulation profile is assigned to an upstream. This would remove any requirements on the RowStatus being notInService(2). I'm bringing this up now because I'm looking at the command line implementation of this logic and taking individual IUCs out of service is more cumbersome than just de-assigning the modulation profile from the upstream, especially since the modulation profile will have to be de-assigned or the upstream taken out of service anyways since individual (and probably required IUCs) are being taken out of service, thus preventing proper operation of the upstream channel. docsIfCmtsModChannelType It might not be necessary or desirable to force all IUCs within a modulation profile to have the same channel type. I believe I have a clearer understanding of the way the mixed-mode tdmaAndAtdma upstream channel type works. I believe the reason for using such an upstream channel would be to allow both DOCSIS 1.x tdma-only and DOCSIS 2.0 atdma-capable modems of operation on the same upstream. As such, IUCs 1, 3-6, and possibly 2 would need to be eiher tdma or tdmaAndAtdma. Otherwise, tdma-only modems would not be able to operate. Likewise, it would seem that IUCs 9, 10, and possibly 11 would be required and would need to be atdma or tdmaAndAtdma, but following the rules for atdma. Going further, it seems that IUCs 1-6, when set to tdmaAndAtdma, should follow the rules for tdma. Otherwise, if they follow the atdma rules, then tdmaAndAtdma for IUCs 1-6 is pointless, since tdma-only modems will not be able to operate. Likewise, if IUCs 9-11 are set to tdmaAndAtdma, then they should follow the rules for atdma. To illustrate, I believe that the following modulation profile sets, one for each channel type, should be allowed: 1) tdma upstream channel IUC chanType 1 tdma or tdmaAndAtdma (must follow tdma rules) 2 tdma or tdmaAndAtdma (must follow tdma rules) - this IUC is optional 3 tdma or tdmaAndAtdma (must follow tdma rules) 4 tdma or tdmaAndAtdma (must follow tdma rules) 5 tdma or tdmaAndAtdma (must follow tdma rules) 6 tdma or tdmaAndAtdma (must follow tdma rules) 9 ignored - IUC not used 10 ignored - IUC not used 11 ignored - IUC not used 2) atdma upstream channel IUC chanType 1 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules) 2 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules) - this IUC is optional 3 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules) 4 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules) 5 ignored - IUC not used 6 ignored - IUC not used 9 atdma or tdmaAndAtdma (must follow atdma rules) 10 atdma or tdmaAndAtdma (must follow atdma rules) 11 atdma or tdmaAndAtdma (must follow atdma rules) - this IUC is optional 3) tdmaAndAtdma upstream channel IUC chanType 1 tdma or tdmaAndAtdma (must follow tdma rules) 2 tdma or tdmaAndAtdma (must follow tdma rules) - this IUC is optional 3 tdma or tdmaAndAtdma (must follow tdma rules) 4 tdma or tdmaAndAtdma (must follow tdma rules) 5 tdma or tdmaAndAtdma (must follow tdma rules) 6 tdma or tdmaAndAtdma (must follow tdma rules) 9 atdma or tdmaAndAtdma (must follow atdma rules) 10 atdma or tdmaAndAtdma (must follow atdma rules) 11 atdma or tdmaAndAtdma (must follow atdma rules) - this IUC is optional 4) scdma upstream channel IUC chanType 1 scdma 2 scdma - this IUC is optional 3 scdma 4 scdma 5 ignored - IUC not used 6 ignored - IUC not used 9 scdma 10 scdma 11 scdma - this IUC is optional I have included modulation profile channel type tdmaAndAtdma for completeness' sake only. Note that the same results can be achieved without the tdmaAndAtdma modulation profile channel type, even though an usptream channel type of tdmaAndAtmda is still desirable. Thus, we could reduce the complexity and confusion of the modulation profile table by removing the tdmaAndAtdma modulation profile channel type altogether. Also note that modulation profile 3 (for the tdmaAndAtdma upstream channel) could be used on a tdma-only upstream channel, assuming the UCD and mapper algorithms on the CMTS ignore IUCs 9-11. What do you think ? Thanks, David White ARRIS Cadant C4 CMTS Software Engineer "Greg White" Sent by: owner-docsis-oss@cablelabs.com 10/10/2003 12:56 PM To: "Dan Rice @ Stargus" , "Minnie Lu" cc: , "DOCSIS OSS Majordomo List" , , , Fax to: Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) What I had interpreted Minnie's suggestion to be was that ChannelType consistency was enforced across all modulation profile rows with a Status of 'active', regardless of whether they were assigned to an upstream channel or not. Setting Status to 'notInService' is not allowed for propfiles assigned to an upstream channel, nor is changing ChannelType. So, the operation Minnie suggested only applies to profiles that have been created and set 'active', but are not assigned to any upstream channel. Does that clarify? -Greg -----Original Message----- From: Dan Rice @ Stargus Sent: Friday, October 10, 2003 7:59 AM To: Greg White; Minnie Lu Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Sorry for chiming in 11th hour, but want to make sure I understand minnie's suggestion for active entries. I believe the suggestion is that for active entries you change the row status to not in service. What would we expect to happen to the upstream currently assigned this modulation profile while it is notInService? Would the existing active assignment continue to be valid for the upstream using it until all IUC rows became active again with the changes in them? Also if the changes are to docsIfCmtsModChannelType wouldn't you have to edit all IUC rows before checking to see if this is valid? I guess when you started going in and making each IUC active that would be the point to check it? Could you guarantee that all IUCs are committed at the same time since they would "immediately" be committed to the active upstream channel entries with pointers to the docsIfCmtsModIndex? Thanks for the clarifications. - Dan -----Original Message----- From: Greg White [mailto:g.white@CableLabs.com] Sent: Wednesday, October 08, 2003 7:20 PM To: Minnie Lu Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) That sounds like a workable alternative. If no one disagrees, I will make that change to the proposal. -Greg -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com] Sent: Wednesday, October 08, 2003 3:09 PM To: Greg White Cc: Minnie Lu; David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Hi, Greg, Then how about enforce this rule for "active" entries ? So in the case you mentioned, user can change the row status to notInService first or at the same time changing the channel type. When user changed all the entries' channel type to be the same, use can put the entries in active again. I personally think it affects a lot when the channel type is changed, so a little more steps should be ok. To me, if there is an error, better catch it as earlier as possible. "All the active entries in a modulation profile (i.e. all active entries that share a common docsIfCmtsModIndex) MUST have the same value of docsIfCmtsModChannelType." Thanks a lot ! Minnie At 02:12 PM 10/8/2003 -0600, Greg White wrote: >Minnie, > >I didn't want to prevent a user from changing their mind regarding >channel type when creating a new modulation profile. Suppose you >started out setting channel type to atdma and, after completing a few >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make >you start from scratch (or do a simultaneous set across all IUCs), you >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Hi, Greg, > > Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the >modulation profile is not assigned to any upstreams. So the error could >be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please review >the > >attached proposal and provide comments. > > > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , , , > > > "DOCSIS OSS Majordomo List" , "Owner DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same > > >ModChannelType. Also, based on the exchange here it seems that there >is > > >some support for the additional restriction that UpChannelType and > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change > > >UpChannelType to match ModChannelType whenever > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about the > >case that some modulation profile is used by some upstream channel, and > >user change the modulation profile channel type ? Does it mean that >the > >upstream channel type would be changed automatically, too ? If yes, I >am > >afraid that there might be some user who forget the modulation profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The > >modulation profile channel type and upstream channel type are in two > >different MIB tables. > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type be > >changed ? Maybe this is a confusing point which needs to be clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > > >upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation profile > > >entries with the same docsIfCmtsModIndex will have to have the same > > >docsIfCmtsModChannelType. Otherwise, you would not be able to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid, no >? > > >The way to patch it up would be to make all of the IUCs tdmaAndAtdma, > > >correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List" > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects > > > > docsIfCmtsModByteInterleaverBlockSize and > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma for > > > > modulation profiles that could not be met with a pair of tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line of > > > >thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations. Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of having >the > > > >MIB reporting something that doesn't exactly reflect what is > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the > > > > modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data for > > > > consistency. Furthermore, it would seem possible to compare the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --=_alternative 00754F4D85256DF2_= Content-Type: text/html; charset="us-ascii"
A few points that I hope are not too late:

docsIfCmtsModControl
It might be acceptable to delay enforcing the same channel type across all IUCs until the modulation profile gets assigned to an upstream. That is, one could freely modify the mod prof channel types as long as the modulation profile is assigned to an upstream. This would remove any requirements on the RowStatus being notInService(2). I'm bringing this up now because I'm looking at the command line implementation of this logic and taking individual IUCs out of service is more cumbersome than just de-assigning the modulation profile from the upstream, especially since the modulation profile will have to be de-assigned or the upstream taken out of service anyways since individual (and probably required IUCs) are being taken out of service, thus preventing proper operation of the upstream channel.

docsIfCmtsModChannelType
It might not be necessary or desirable to force all IUCs within a modulation profile to have the same channel type. I believe I have a clearer understanding of the way the mixed-mode tdmaAndAtdma upstream channel type works. I believe the reason for using such an upstream channel would be to allow both DOCSIS 1.x tdma-only and DOCSIS 2.0 atdma-capable modems of operation on the same upstream. As such, IUCs 1, 3-6, and possibly 2 would need to be eiher tdma or tdmaAndAtdma. Otherwise, tdma-only modems would not be able to operate. Likewise, it would seem that IUCs 9, 10, and possibly 11 would be required and would need to be atdma or tdmaAndAtdma, but following the rules for atdma.

Going further, it seems that IUCs 1-6, when set to tdmaAndAtdma, should follow the rules for tdma. Otherwise, if they follow the atdma rules, then tdmaAndAtdma for IUCs 1-6 is pointless, since tdma-only modems will not be able to operate. Likewise, if IUCs 9-11 are set to tdmaAndAtdma, then they should follow the rules for atdma.

To illustrate, I believe that the following modulation profile sets, one for each channel type, should be allowed:

1) tdma upstream channel
IUC chanType
  1 tdma or tdmaAndAtdma (must follow tdma rules)
  2 tdma or tdmaAndAtdma (must follow tdma rules) - this IUC is optional
  3 tdma or tdmaAndAtdma (must follow tdma rules)
  4 tdma or tdmaAndAtdma (must follow tdma rules)
  5 tdma or tdmaAndAtdma (must follow tdma rules)
  6 tdma or tdmaAndAtdma (must follow tdma rules)
  9 ignored - IUC not used
 10 ignored - IUC not used
 11 ignored - IUC not used

2) atdma upstream channel
IUC chanType
  1 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)
  2 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules) - this IUC is optional
  3 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)
  4 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)
  5 ignored - IUC not used
  6 ignored - IUC not used
  9 atdma or tdmaAndAtdma (must follow atdma rules)
 10 atdma or tdmaAndAtdma (must follow atdma rules)
 11 atdma or tdmaAndAtdma (must follow atdma rules) - this IUC is optional

3) tdmaAndAtdma upstream channel
IUC chanType
  1  tdma or tdmaAndAtdma (must follow  tdma rules)
  2  tdma or tdmaAndAtdma (must follow  tdma rules) - this IUC is optional
  3  tdma or tdmaAndAtdma (must follow  tdma rules)
  4  tdma or tdmaAndAtdma (must follow  tdma rules)
  5  tdma or tdmaAndAtdma (must follow  tdma rules)
  6  tdma or tdmaAndAtdma (must follow  tdma rules)
  9 atdma or tdmaAndAtdma (must follow atdma rules)
 10 atdma or tdmaAndAtdma (must follow atdma rules)
 11 atdma or tdmaAndAtdma (must follow atdma rules) - this IUC is optional

4) scdma upstream channel
IUC chanType
  1 scdma
  2 scdma - this IUC is optional
  3 scdma
  4 scdma
  5 ignored - IUC not used
  6 ignored - IUC not used
  9 scdma
 10 scdma
 11 scdma - this IUC is optional

I have included modulation profile channel type tdmaAndAtdma for completeness' sake only. Note that the same results can be achieved without the tdmaAndAtdma modulation profile channel type, even though an usptream channel type of tdmaAndAtmda is still desirable. Thus, we could reduce the complexity and confusion of the modulation profile table by removing the tdmaAndAtdma modulation profile channel type altogether.  Also note that modulation profile 3 (for the tdmaAndAtdma upstream channel) could be used on a tdma-only upstream channel, assuming the UCD and mapper algorithms on the CMTS ignore IUCs 9-11.

What do you think ?

Thanks,
David White
ARRIS Cadant C4 CMTS
Software Engineer




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

10/10/2003 12:56 PM

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



What I had interpreted Minnie's suggestion to be was that ChannelType
consistency was enforced across all modulation profile rows with a
Status of 'active', regardless of whether they were assigned to an
upstream channel or not.  Setting Status to 'notInService' is not
allowed for propfiles assigned to an upstream channel, nor is changing
ChannelType.

So, the operation Minnie suggested only applies to profiles that have
been created and set 'active', but are not assigned to any upstream
channel.

Does that clarify?

-Greg


-----Original Message-----
From: Dan Rice @ Stargus
Sent: Friday, October 10, 2003 7:59 AM
To: Greg White; Minnie Lu
Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List;
Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org
Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 :
rules for assigning modulation profiles to upstream channels)


Sorry for chiming in 11th hour, but want to make sure I understand
minnie's suggestion for active entries.  I believe the suggestion is
that for active entries you change the row status to not in service.
What would we expect to happen to the upstream currently assigned this
modulation profile while it is notInService?  Would the existing active
assignment continue to be valid for the upstream using it until all IUC
rows became active again with the changes in them?

Also if the changes are to docsIfCmtsModChannelType wouldn't you have to
edit all IUC rows before checking to see if this is valid?  I guess when
you started going in and making each IUC active that would be the point
to check it?  Could you guarantee that all IUCs are committed at the
same time since they would "immediately" be committed to the active
upstream channel entries with pointers to the docsIfCmtsModIndex?

Thanks for the clarifications. - Dan

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

That sounds like a workable alternative.  If no one disagrees, I will
make that change to the proposal.

-Greg


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


Hi, Greg,

Then how about enforce this rule for "active" entries ? So in the case
you
mentioned, user can change the row status to notInService first or at
the
same time changing the channel type.  When user changed all the entries'

channel type to be the same, use can put the entries in active again.  I

personally think it affects a lot when the channel type is changed, so a

little more steps should be ok.  To me, if there is an error, better
catch
it as earlier as possible.

"All the active entries in a modulation profile (i.e. all active entries

that share a
common docsIfCmtsModIndex) MUST have the same value of
docsIfCmtsModChannelType."

Thanks a lot !
Minnie

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


_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

--=_alternative 00754F4D85256DF2_=-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Dec 4 18:02:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23074 for ; Thu, 4 Dec 2003 18:02:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2Tz-00065M-HW for ipcdn-archive@odin.ietf.org; Thu, 04 Dec 2003 18:02:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4N23jJ023367 for ipcdn-archive@odin.ietf.org; Thu, 4 Dec 2003 18:02:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2Tx-00064P-Pt; Thu, 04 Dec 2003 18:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2Th-00062X-EW for ipcdn@optimus.ietf.org; Thu, 04 Dec 2003 18:01:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22923 for ; Thu, 4 Dec 2003 18:01:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS2Te-0003y1-00 for ipcdn@ietf.org; Thu, 04 Dec 2003 18:01:42 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AS2PK-0003tz-00 for ipcdn@ietf.org; Thu, 04 Dec 2003 17:57:14 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by manatick with esmtp (Exim 4.24) id 1AS290-00075M-73 for ipcdn@ietf.org; Thu, 04 Dec 2003 17:40:22 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hB4MeEoK020495; Thu, 4 Dec 2003 15:40:14 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RFMIBv2 ID-nits: references Date: Thu, 4 Dec 2003 15:40:14 -0700 Message-ID: Thread-Topic: [ipcdn] RFMIBv2 ID-nits: references Thread-Index: AcO6rRmPtySoJXHeRMqNqPOJ/PLpGQAAzjaAAAGXaCA= From: "Matthew Schmitt" To: "Jean-Francois Mule" , , "Eduardo Cardona" , Cc: X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable FYI, I did manage to locate the referenced document on www.tcomlabs.com. = The direct link is = http://www.tcomlabs.com/Euro-DOCSIS/Documents/Add-Euro-DOCSIS_spec.pdf. = Via their website, you can get to the file by first clicking on the = Euro-DOCSIS link, then clicking on the Euro-DOCSIS 1.0 link (the link to = that page is www.tcomlabs.com/Euro-DOCSIS/Euro-DOCSIS1.0.htm). On that = page, it's the document listed as "Additional document: .pdf". Matt -----Original Message----- From: Jean-Francois Mule=20 Sent: Thursday, December 04, 2003 3:12 PM To: david.raftus@Terayon.com; Eduardo Cardona; deketelaere@tComLabs.com Cc: ipcdn@ietf.org Subject: [ipcdn] RFMIBv2 ID-nits: references Check ID nits and other comments made by mib doctors in other drafts. http://www.ietf.org/ID-nits.html There are normative references that are not even mentioned once and not = used as IMPORTs in the document: [1] Woundy, R., "Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems", RFC3083, March 2001. [9] "Adapted MIB-definitions and a clarification for MPEG-related=20 issues for EuroDOCSIS cable modem systems v1.01", tComLabs,=20 May 2000., available at http://www.tcomlabs.com.=20 Suggestions: - call this reference in the text or just remove it; - I cannot find the named reference under http://www.tcomlabs.com ; if = you keep it, then we need a better link, especially if it remains = normative. Also, should [6] be made informative instead of normative? (a) it's a book=20 (b) the DOCSIS specs are referenced normatively and that's where a = normative reference on QPSK should be. [6] Proakis, John G., "Digital Communications, 3rd Edition",=20 McGraw-Hill, New York, New York, 1995, ISBN 0-07-051726-6=20 Thanks, Jean-Fran=E7ois PS: also, CableLabs is working on a stable HTTP URL for our = specifications so the http://www.cablemodem.com URL will most likely = have to be updated. More on the actual URL soon. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Dec 4 18:15:01 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20882 for ; Thu, 4 Dec 2003 17:29:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS1y2-0004gV-G8 for ipcdn-archive@odin.ietf.org; Thu, 04 Dec 2003 17:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4MT26N017955 for ipcdn-archive@odin.ietf.org; Thu, 4 Dec 2003 17:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS1y1-0004fJ-HY; Thu, 04 Dec 2003 17:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS1wn-0004dX-Hx for ipcdn@optimus.ietf.org; Thu, 04 Dec 2003 17:27:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20824 for ; Thu, 4 Dec 2003 17:27:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS1wk-000376-00 for ipcdn@ietf.org; Thu, 04 Dec 2003 17:27:42 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AS1wh-00036C-00 for ipcdn@ietf.org; Thu, 04 Dec 2003 17:27:40 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hB4MQOoK019239; Thu, 4 Dec 2003 15:26:25 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BAB5.A6BFF513" Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Date: Thu, 4 Dec 2003 15:26:24 -0700 Message-ID: Thread-Topic: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) Thread-Index: AcO6rRmPtySoJXHeRMqNqPOJ/PLpGQAApjjwAABcwQA= From: "Greg White" To: "Jean-Francois Mule" , Cc: "Dan Rice @ Stargus" , "DOCSIS OSS Majordomo List" , , , , "Minnie Lu" X-Approved: ondar Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3BAB5.A6BFF513 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David, =20 Thanks for taking the time to detail your thoughts on this. Here is what I think: =20 docsIfCmtsModControl Your suggestion is a valid one, matches the original proposal, and is arguably simpler. However, I don't believe that the current method is broken, and it has some benefits. For one, it allows for consistency checking while the profile is being built, where ModControl would not be allowed to become "Active" if the ChannelType did not match that of other active rows. This helps limit the amount of debugging the operator needs to go through to find the invalid parameter. If the consistency check is only done when the profile is assigned to an upstream channel, the operator has to comb through all (potentially 9) rows to find out what parameter(s) are in error. =20 docsIfCmtsModChannelType I have to admit that this seems like deja vu. Is this not exactly the same point you raised in your email on Aug 21? I think the argument then was that it was just simpler conceptually to have modulation profiles created specifically for the channel type, hence all rows in a profile have matching ModChannelType, and ModChannelType has to match UpChannelType. =20 -Greg =20 =20 =20 =20 -----Original Message----- From: Jean-Francois Mule=20 Sent: Thursday, December 04, 2003 2:48 PM To: David.White@arrisi.com; Greg White Cc: Dan Rice @ Stargus; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) =09 =09 Thanks David for your comments. Up to the author/editor (David Raftus/Eduardo) to decide what to do and whether to incorporate in draft 09. =20 Note well: You all realize that we cannot move the IPCDN DOCSIS MIB drafts along the IETF process if we keep getting more and more *technical* comments, even after the WG last calls and other comment deadlines... =20 Jean-Francois. =20 =20 =20 =20 -----Original Message----- From: David.White@arrisi.com [mailto:David.White@arrisi.com]=20 Sent: Thursday, December 04, 2003 2:21 PM To: Greg White Cc: Dan Rice @ Stargus; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) =09 =09 A few points that I hope are not too late:=20 =09 docsIfCmtsModControl=20 It might be acceptable to delay enforcing the same channel type across all IUCs until the modulation profile gets assigned to an upstream. That is, one could freely modify the mod prof channel types as long as the modulation profile is assigned to an upstream. This would remove any requirements on the RowStatus being notInService(2). I'm bringing this up now because I'm looking at the command line implementation of this logic and taking individual IUCs out of service is more cumbersome than just de-assigning the modulation profile from the upstream, especially since the modulation profile will have to be de-assigned or the upstream taken out of service anyways since individual (and probably required IUCs) are being taken out of service, thus preventing proper operation of the upstream channel.=20 =09 docsIfCmtsModChannelType=20 It might not be necessary or desirable to force all IUCs within a modulation profile to have the same channel type. I believe I have a clearer understanding of the way the mixed-mode tdmaAndAtdma upstream channel type works. I believe the reason for using such an upstream channel would be to allow both DOCSIS 1.x tdma-only and DOCSIS 2.0 atdma-capable modems of operation on the same upstream. As such, IUCs 1, 3-6, and possibly 2 would need to be eiher tdma or tdmaAndAtdma. Otherwise, tdma-only modems would not be able to operate. Likewise, it would seem that IUCs 9, 10, and possibly 11 would be required and would need to be atdma or tdmaAndAtdma, but following the rules for atdma.=20 =09 Going further, it seems that IUCs 1-6, when set to tdmaAndAtdma, should follow the rules for tdma. Otherwise, if they follow the atdma rules, then tdmaAndAtdma for IUCs 1-6 is pointless, since tdma-only modems will not be able to operate. Likewise, if IUCs 9-11 are set to tdmaAndAtdma, then they should follow the rules for atdma.=20 =09 To illustrate, I believe that the following modulation profile sets, one for each channel type, should be allowed:=20 =09 1) tdma upstream channel=20 IUC chanType=20 1 tdma or tdmaAndAtdma (must follow tdma rules)=20 2 tdma or tdmaAndAtdma (must follow tdma rules) - this IUC is optional=20 3 tdma or tdmaAndAtdma (must follow tdma rules)=20 4 tdma or tdmaAndAtdma (must follow tdma rules)=20 5 tdma or tdmaAndAtdma (must follow tdma rules)=20 6 tdma or tdmaAndAtdma (must follow tdma rules)=20 9 ignored - IUC not used=20 10 ignored - IUC not used=20 11 ignored - IUC not used=20 =09 2) atdma upstream channel=20 IUC chanType=20 1 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)=20 2 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules) - this IUC is optional=20 3 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)=20 4 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)=20 5 ignored - IUC not used=20 6 ignored - IUC not used=20 9 atdma or tdmaAndAtdma (must follow atdma rules)=20 10 atdma or tdmaAndAtdma (must follow atdma rules)=20 11 atdma or tdmaAndAtdma (must follow atdma rules) - this IUC is optional=20 =09 3) tdmaAndAtdma upstream channel=20 IUC chanType=20 1 tdma or tdmaAndAtdma (must follow tdma rules)=20 2 tdma or tdmaAndAtdma (must follow tdma rules) - this IUC is optional=20 3 tdma or tdmaAndAtdma (must follow tdma rules)=20 4 tdma or tdmaAndAtdma (must follow tdma rules)=20 5 tdma or tdmaAndAtdma (must follow tdma rules)=20 6 tdma or tdmaAndAtdma (must follow tdma rules)=20 9 atdma or tdmaAndAtdma (must follow atdma rules)=20 10 atdma or tdmaAndAtdma (must follow atdma rules)=20 11 atdma or tdmaAndAtdma (must follow atdma rules) - this IUC is optional=20 =09 4) scdma upstream channel=20 IUC chanType=20 1 scdma=20 2 scdma - this IUC is optional=20 3 scdma=20 4 scdma=20 5 ignored - IUC not used=20 6 ignored - IUC not used=20 9 scdma=20 10 scdma=20 11 scdma - this IUC is optional=20 =09 I have included modulation profile channel type tdmaAndAtdma for completeness' sake only. Note that the same results can be achieved without the tdmaAndAtdma modulation profile channel type, even though an usptream channel type of tdmaAndAtmda is still desirable. Thus, we could reduce the complexity and confusion of the modulation profile table by removing the tdmaAndAtdma modulation profile channel type altogether. Also note that modulation profile 3 (for the tdmaAndAtdma upstream channel) could be used on a tdma-only upstream channel, assuming the UCD and mapper algorithms on the CMTS ignore IUCs 9-11.=20 =09 What do you think ?=20 =09 Thanks,=20 David White=20 ARRIS Cadant C4 CMTS=20 Software Engineer=20 =09 =09 =09 =09 =09 "Greg White" =20 Sent by: owner-docsis-oss@cablelabs.com=20 10/10/2003 12:56 PM=20 =20 To: "Dan Rice @ Stargus" , "Minnie Lu" =20 cc: , "DOCSIS OSS Majordomo List" , , , =20 Fax to: =20 Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels)=09 What I had interpreted Minnie's suggestion to be was that ChannelType consistency was enforced across all modulation profile rows with a Status of 'active', regardless of whether they were assigned to an upstream channel or not. Setting Status to 'notInService' is not allowed for propfiles assigned to an upstream channel, nor is changing ChannelType. =09 So, the operation Minnie suggested only applies to profiles that have been created and set 'active', but are not assigned to any upstream channel. =09 Does that clarify? =09 -Greg =09 =09 -----Original Message----- From: Dan Rice @ Stargus=20 Sent: Friday, October 10, 2003 7:59 AM To: Greg White; Minnie Lu Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) =09 =09 Sorry for chiming in 11th hour, but want to make sure I understand minnie's suggestion for active entries. I believe the suggestion is that for active entries you change the row status to not in service. What would we expect to happen to the upstream currently assigned this modulation profile while it is notInService? Would the existing active assignment continue to be valid for the upstream using it until all IUC rows became active again with the changes in them? =09 Also if the changes are to docsIfCmtsModChannelType wouldn't you have to edit all IUC rows before checking to see if this is valid? I guess when you started going in and making each IUC active that would be the point to check it? Could you guarantee that all IUCs are committed at the same time since they would "immediately" be committed to the active upstream channel entries with pointers to the docsIfCmtsModIndex? =09 Thanks for the clarifications. - Dan =09 -----Original Message----- From: Greg White [mailto:g.white@CableLabs.com]=20 Sent: Wednesday, October 08, 2003 7:20 PM To: Minnie Lu Cc: David.White@arrisi.com; DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) =09 That sounds like a workable alternative. If no one disagrees, I will make that change to the proposal. =09 -Greg =09 =09 -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Wednesday, October 08, 2003 3:09 PM To: Greg White Cc: Minnie Lu; David.White@arrisi.com; DOCSIS OSS Majordomo List;=20 Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels) =09 =09 Hi, Greg, =09 Then how about enforce this rule for "active" entries ? So in the case you=20 mentioned, user can change the row status to notInService first or at the=20 same time changing the channel type. When user changed all the entries' =09 channel type to be the same, use can put the entries in active again. I =09 personally think it affects a lot when the channel type is changed, so a =09 little more steps should be ok. To me, if there is an error, better catch=20 it as earlier as possible. =09 "All the active entries in a modulation profile (i.e. all active entries =09 that share a common docsIfCmtsModIndex) MUST have the same value of docsIfCmtsModChannelType." =09 Thanks a lot ! Minnie =09 At 02:12 PM 10/8/2003 -0600, Greg White wrote: >Minnie, > >I didn't want to prevent a user from changing their mind regarding >channel type when creating a new modulation profile. Suppose you >started out setting channel type to atdma and, after completing a few >IUCs, realized that you really wanted tdmaAndAtdma. Rather than make >you start from scratch (or do a simultaneous set across all IUCs), you >could just update the channel type on each row. > >I understand your view as well. > >If there is a consensus to change the text, I am not strongly opposed. > >-Greg > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: David.White@arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List; >Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com; ipcdn@ietf.org >Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for >assigning modulation profiles to upstream channels) > > >Hi, Greg, > > Thanks a lot to you and Eduardo for this proposal ! > >docsIfCmtsModChannelType : > "... > In order to be considered a valid modulation profile for > assignment to an upstream channel, all entries (IUCs) in > the modulation profile must have the same channel type." > > In addition to do the checking at the time the modulation profile is >assigned to some upstream, I think that the checking could also be done >when user create/modify an entry of docsIfCmtsModulationEntry even the >modulation profile is not assigned to any upstreams. So the error could >be >caught earlier. So I would suggest to enhance the description as the >ECO >(OSS2-O-03092) > >"All the entries in a modulation profile (i.e. all entries that share a >common docsIfCmtsModIndex) MUST have the same value of >docsIfCmtsModChannelType." > >If I miss anything, please let me know. >Thanks a lot! >Minnie > >At 04:22 PM 10/7/2003 -0600, Greg White wrote: > >All, > > > >As a final issue to resolve in the RFMIBv2 before draft-08, I would >like > >to propose that we complete the clarification of the relationship >between > >the ChannelType parameters in modulation profiles and upstream >channels. > > > >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which > >clarifies part of the relationship by adding requirements to the OSSI > >spec. I would like to suggest that we propagate those requirements to >the > >MIB descriptions. > > > >Also, I would like to propose that we make docsIfUpChannelType a >read-only > >object for active rows in the Upstream Channel Table. The value >reported > >would be taken from the modulation profile pointed to by > >docsIfUpChannelModulationProfile. > > > >Attached is a detailed proposal that Eduardo and I wrote to frame the >issue. > > > >In order not to delay draft-08, we would like to have consensus from >the > >community and working group by this Friday, October 10. Please review >the > >attached proposal and provide comments. > >=20 > >Many thanks, > >Greg > >-----Original Message----- > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; Greg.Gohman@arrisi.com; Greg White; > >Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > >upstream channels > > > >Minnie, > > I am emphathetic to your concerns. I ran across the same issue > > > while implementing cross-checks for the 2.0 modulation and upstream >data. > > I found it made the code far simpler to lead the user down the path of > > > "define the channel type first, then build everything around that" >kind > > of configuration model. I am then able to check the settings of the >other > > parameters against the channel type. After a modulation profile or > > upstream channel has already been provisioned, changing just the >channel > > type becomes difficult, as many parameters are incompatible with other > > > channel types. I allow it, but don't recommend it. > > > >My 2 cents, > >David > > > > > > > > > > > >Minnie Lu > > > >08/25/2003 07:01 PM > > > > To: "Greg White" > > cc: , "Minnie Lu" > > , , , > > > "DOCSIS OSS Majordomo List" , "Owner DOCSIS >OSS > > Majordomo List" > > Fax to: > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > profiles to upstream channels > > > > > > > > > > > >Hi, Greg, > > > > Please see my response inline. > > Thanks a lot ! > > Minnie > >At 02:29 PM 8/25/2003 -0600, Greg White wrote: > > >The email exchange between Steve and Alberto notwithstanding, I think >it > > >does make sense to enforce that all entries in a modulation profile >(i.e. > > >all entries that share a common docsIfCmtsModIndex) have the same > > >ModChannelType. Also, based on the exchange here it seems that there >is > > >some support for the additional restriction that UpChannelType and > > >ModChannelType always match. With those two restrictions, there >clearly > > >is a need for all defined values of ModChannelType. > > > > > >Since this has been a point of confusion at least twice now, does >anyone > > >have a concern with making these two items part of the specification? > > > > > > >[milu]: I agree with you. > > > > >A further point, how does the CMTS enforce the match between >UpChannelType > > >and ModChannelType? One implementation may automatically change > > >UpChannelType to match ModChannelType whenever > > >docsIfUpChannelModulationProfile is set. Another might reject the >change > > >if the two don't already match, and require the use of the > > >docsIfUpChannelCloneFrom mechanism to change the channel type. I'd >argue > > >that the first implementation makes more sense, and ought to be made >a > > >SHOULD in the spec, but I'd like to hear other views. > > > > > > >[milu]: I think this needs to be thought over carefully. How about the > >case that some modulation profile is used by some upstream channel, and > >user change the modulation profile channel type ? Does it mean that >the > >upstream channel type would be changed automatically, too ? If yes, I >am > >afraid that there might be some user who forget the modulation profile >is > >being used and change the channel type without knowing the upstream >channel > >type for some upstream channels are changed at the same time. The > >modulation profile channel type and upstream channel type are in two > >different MIB tables.=20 > > > > Actually, I am always puzzled when the modulation profile is being >used > >by some upstream channels, could the modulation profile channel type be > >changed ? Maybe this is a confusing point which needs to be clarified, >too. > > > > Thanks a lot for your help ! > > Minnie > > > > > > > > > > > > >-Greg > > >-----Original Message----- > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com > > >Cc: DOCSIS OSS Majordomo List; Greg White; milu@cisco.com; Owner >DOCSIS > > >OSS Majordomo List > > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to > > >upstream channels > > > > > >Minnie, > > > Sounds good to me. This would make verifying the consistency >of > > > the data in the modulation profiles and the upstream channels far >easier. > > >So, if I understand correctly, this means that all modulation profile > > >entries with the same docsIfCmtsModIndex will have to have the same > > >docsIfCmtsModChannelType. Otherwise, you would not be able to use >that > > >modulation profile set on any upstream channel. So, this modulation > > >profile set with different docsIfCmtsModChannelTypes from an e-mail >thread > > >between Alberto and Steve from almost a year ago would be invalid, no >? > > >The way to patch it up would be to make all of the IUCs tdmaAndAtdma, > > >correct ? > > > > > >Thanks, > > >David > > > > > >--- end David's e-mail --- > > >--- start e-mail exchange between Alberto and Steve --- > > > > > >Hi Steve > > > > > >Sorry for the delay in responding > > > > > >Your configuration settings for operation in multiple mode is correct >and > > >will support tdma, tdmaAndAtdma and Atdma. > > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with >UCD > > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and >IUCs > > >5&6 are not used. Your interpretation of the spec in the example >described > > >is accurate. > > > > > >Alberto Campos > > >a.campos@cablelabs.com > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:smalenfant@com21.com] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: 'docsis-20@cablelabs.com' > > >Subject: Correlation between docsIfUpChannelType and > > >docsIfCmtsModChannelT ype > > > > > > > > > > > >We are having some discussion internally here, and would like to >clarify > > >things about the modulation profile. > > >Let's take an example, expecting all parameters are good : > > > > > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. > > >set IUC 5 docsIfCmtsModChannelType to tdma. > > >set IUC 6 docsIfCmtsModChannelType to tdma. > > >set IUC 9 docsIfCmtsModChannelType to Atdma. > > >set IUC 10 docsIfCmtsModChannelType to Atdma. > > > > > >Would this burst profile be good for docsIfUpChannelType tdma, >tdmaAndAtdma > > >and Atdma? > > > > > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. > > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 >inside > > >UCD type 2. > > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. > > > > > > > > > > > > > > > > > >Minnie Lu > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > >08/21/2003 07:15 PM > > > > > > To: David.White@arrisi.com, "Greg White" > > > > > > cc: "DOCSIS OSS Majordomo List"=20 > > > , milu@cisco.com > > > Fax to: > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > profiles to upstream channels > > > > > > > > > > > > > > > > > >Hi, David and Greg, > > > > > > I like Greg's "Perhaps it is simpler just to require that >ModChannelType > > >match UpChannelType.". > > > > > > I don't think that "we could just drop tdmaAndAtdma for > > >ModChannelType". Please keep in mind that when assigning the >modulation > > >profile to some upstream via SNMP docsIfUpChannelModulationProfile, >it uses > > >only the docsIfModIndex and only one docsIfModIndex can be assigned >to some > > >upstream channel. > > > > > > If I miss anything, please correct me. > > > Thanks! > > > Minnie > > > > > >At 10:53 AM 8/21/2003 -0400, David.White@arrisi.com wrote: > > > > > > >Greg, > > > > IUCs 1, 2, 3, and 4 are used for both tdma and atdma >channels. > > > > However, the modulation profiles objects > > > > docsIfCmtsModByteInterleaverBlockSize and > > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma >channels. So, > > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these >objects > > set, > > > > it assumably could not be used on a tdma-only upstream channel. >Hence, > > > > the whole purpose of even having ModChannelType - to verify >consistency > > > > within the modulation profile - is weakened. This has the >unintended > > side > > > > effect of requiring any assignment of modulation profiles with >IUCs > > 1, 2, > > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to see >if the > > > > Interleaver parameters have been set before assigning it to a >tdma-only > > > > upstream channel. Hence, my gripe with tdmaAndAtdma for modulation > > > profiles. > > > > I can't think of any need/requirement for tdmaAndAtdma for > > > > modulation profiles that could not be met with a pair of tdma and >atdma > > > > modulation profile. In other words, I don't think allowing >tdmaAndAtdma > > > > for ModChannelType really buys us anything. I'm thinking we could >just > > > > drop tdmaAndAtdma for ModChannelType (making it a > > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of >confusion. > > > > For the mixed-mode channels, where UpChannelType is > > tdmaAndAtdma, > > > > the modulation profile set could look like so: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >For tdma-only upstream channels, the modulation profile set could >be: > > > > > > > >IUC 1 tdma > > > >IUC 2 tdma > > > >IUC 3 tdma > > > >IUC 4 tdma > > > >IUC 5 tdma > > > >IUC 6 tdma > > > > > > > >Likewise, for atdma-only upstream channel, the modulation profile >set > > > >could be: > > > > > > > >IUC 1 atdma > > > >IUC 2 atdma > > > >IUC 3 atdma > > > >IUC 4 atdma > > > >IUC 9 atdma > > > >IUC 10 atdma > > > >IUC 11 atdma > > > > > > > >As far as I know, there is no hard limit on the number of the >modulation > > > >profile sets that the CMTS and CM can support. I'm really liking >your > > "not > > > >sure the benefits of flexibility outweigh disadvantages..." line of > > > >thinking. tdmaAndAtdma for modulation profiles has my head >spinning. > > > > > > > >Thanks, > > > >David > > > > > > > > > > > > > > > >"Greg White" > > > >Sent by: owner-docsis-oss@cablelabs.com > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: , "DOCSIS OSS=20 Majordomo >List" > > > > > > > > cc: > > > > Fax to: > > > > Subject: RE: DOCSIS 2.0 : rules for assigning >modulation > > > > profiles to upstream channels > > > > > > > > > > > >David, > > > > > > > >I agree with all of your clearly legal/illegal combinations. Among >the > > > >four that cause you consternation, I would break them done like >this: > > > > > > > >illegal: > > > >tdma, atdma > > > >atdma, tdma > > > > > > > >potentially legal: > > > >tdma, tdmaAndAtdma > > > >atdma, tdmaAndAtdma > > > > > > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and >possibly > > 11, > > > >so cannot be used for a tdma channel. Similarly a tdma modulation >profile > > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma >channel. > > > > > > > >A tdmaAndAtdma modulation profile will include IUCs 1,3,4,5,6,9,10, >and > > > >possibly 11, so could potentially be used for a tdma or an atdma >channel > > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS >ignored the > > > >IUCs that don't apply to the channel type. I'm not sure that the > > > >advantages of that flexibility outweigh the disadvantages of having >the > > > >MIB reporting something that doesn't exactly reflect what is > > > >configured. Perhaps it is simpler just to require that >ModChannelType > > > >match UpChannelType. > > > > > > > >-Greg > > > > > > > > > > > > ----Original Message----- > > > >From: David.White@arrisi.com [mailto:David.White@arrisi.com] > > > >Sent: Tuesday, August 19, 2003 9:37 AM > > > >To: DOCSIS OSS Majordomo List > > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to >upstream > > > >channels > > > > > > > > > > > >DOCSIS 2.0 Community, > > > > It seems that the DocsisUpstreamType objects in both the > > > > modulation profile table and the upstream channel table exist, in >part, > > > > to provide the equipment vendor a way to cross-check the data for > > > > consistency. Furthermore, it would seem possible to compare the >two > > > > DocsisUpstreamType objects when assigning an upstream to a >modulation > > > > profile to make sure the assignment is compatible. For instance, >the > > > > following combination of docsIfUpChannelType, >docsIfCmtsModChannelType > > > > would clearly be illegal: > > > > > > > >scdma, tdma > > > >scdma, atdma > > > >scdma, tdmaAndAtdma > > > > > > > >tdma, scdma > > > >atdma, scdma > > > >tdmaAndAtdma, scdma > > > > > > > > > > > >It is also pretty clear the following are legal: > > > > > > > >tdma, tdma > > > >atdma, atdma > > > >scdma, scdma > > > >tdmaAndAtdma, tdmaAndAtdma > > > > > > > > > > > >However, it is the following cases that are causing me >consternation: > > > > > > > >tdma, atdma > > > >tdma, tdmaAndAtdma > > > >atdma, tdma > > > >atdma, tdmaAndAtdma > > > > > > > > > > > >If ALL of these are legal, then I do not understand the point of > > > >tdmaAndAtdma, other than to cause confusion, especially for >modulation > > > >profiles. > > > > > > > >Thanks, > > > >David White > > > >ARRIS Cadant C4 CMTS > > > > > > > > > =09 =09 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn =09 =09 =09 =09 =09 ------_=_NextPart_001_01C3BAB5.A6BFF513 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
David,
 
Thanks=20 for taking the time to detail your thoughts on this.  Here is what = I=20 think:
 
docsIfCmtsModControl
Your=20 suggestion is a valid one, matches the original proposal, and is = arguably=20 simpler. However, I don't believe that the current method is = broken,=20 and it has some benefits.  For one, it allows for consistency = checking=20 while the profile is being built, where ModControl would = not be=20 allowed to become "Active" if the ChannelType did not match that of = other active=20 rows.  This helps limit the amount of debugging the operator needs = to go=20 through to find the invalid parameter.  If the consistency check is = only=20 done when the profile is assigned to an upstream channel, the operator = has to=20 comb through all (potentially 9) rows to find out what parameter(s) are = in=20 error.
 
docsIfCmtsModChannelType
I have=20 to admit that this seems like deja vu.  Is this not exactly the = same point=20 you raised in your email on Aug 21?  I think the argument then was = that it=20 was just simpler conceptually to have modulation profiles created = specifically=20 for the channel type, hence all rows in a profile have matching = ModChannelType,=20 and ModChannelType has to match UpChannelType.
 
-Greg
 
 
 
 
-----Original Message-----
From: = Jean-Francois=20 Mule
Sent: Thursday, December 04, 2003 2:48 = PM
To:=20 David.White@arrisi.com; Greg White
Cc: Dan Rice @ Stargus; = DOCSIS=20 OSS Majordomo List; Greg.Gohman@arrisi.com; ipcdn@ietf.org;=20 Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo=20 List
Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was = RE:=20 DOCSIS 2.0 : rules for assigning modulation profiles to upstream=20 channels)

Thanks David for your comments. Up to the author/editor = (David=20 Raftus/Eduardo) to decide what to do and whether to incorporate in = draft=20 09.
 
Note well:
You all realize that we cannot move the IPCDN DOCSIS MIB = drafts along=20 the IETF process if we keep getting more and = more *technical*=20 comments, even after the WG last calls and other comment=20 deadlines...
 
Jean-Francois.
 
 
 
 
-----Original Message-----
From:=20 David.White@arrisi.com [mailto:David.White@arrisi.com] =
Sent:=20 Thursday, December 04, 2003 2:21 PM
To: Greg = White
Cc:=20 Dan Rice @ Stargus; DOCSIS OSS Majordomo List; = Greg.Gohman@arrisi.com;=20 ipcdn@ietf.org; Larry.Spaete@arrisi.com; Minnie Lu; Owner DOCSIS OSS = Majordomo List
Subject: RE: [ipcdn] RE: Channel Types in = RFMIBv2=20 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to = upstream=20 channels)


A = few points=20 that I hope are not too late:

docsIfCmtsModControl
It might be acceptable to delay enforcing the same channel = type=20 across all IUCs until the modulation profile gets assigned to an = upstream.=20 That is, one could freely modify the mod prof channel types as long = as the=20 modulation profile is assigned to an upstream. This would remove any = requirements on the RowStatus being notInService(2). I'm bringing = this up=20 now because I'm looking at the command line implementation of this = logic and=20 taking individual IUCs out of service is more cumbersome than just=20 de-assigning the modulation profile from the upstream, especially = since the=20 modulation profile will have to be de-assigned or the upstream taken = out of=20 service anyways since individual (and probably required IUCs) are = being=20 taken out of service, thus preventing proper operation of the = upstream=20 channel.

docsIfCmtsModChannelType
It might not be necessary or desirable to force all IUCs = within a=20 modulation profile to have the same channel type. I believe I have a = clearer=20 understanding of the way the mixed-mode tdmaAndAtdma upstream = channel type=20 works. I believe the reason for using such an upstream channel would = be to=20 allow both DOCSIS 1.x tdma-only and DOCSIS 2.0 atdma-capable modems = of=20 operation on the same upstream. As such, IUCs 1, 3-6, and possibly 2 = would=20 need to be eiher tdma or tdmaAndAtdma. Otherwise, tdma-only modems = would not=20 be able to operate. Likewise, it would seem that IUCs 9, 10, and = possibly 11=20 would be required and would need to be atdma or tdmaAndAtdma, but = following=20 the rules for atdma.

Going=20 further, it seems that IUCs 1-6, when set to tdmaAndAtdma, should = follow the=20 rules for tdma. Otherwise, if they follow the atdma rules, then = tdmaAndAtdma=20 for IUCs 1-6 is pointless, since tdma-only modems will not be able = to=20 operate. Likewise, if IUCs 9-11 are set to tdmaAndAtdma, then they = should=20 follow the rules for atdma.

To=20 illustrate, I believe that the following modulation profile sets, = one for=20 each channel type, should be allowed:

1) tdma upstream channel
IUC chanType
  1 tdma or=20 tdmaAndAtdma (must follow tdma rules)
  2 tdma or tdmaAndAtdma (must follow tdma rules) - = this IUC is=20 optional
  3 tdma or = tdmaAndAtdma=20 (must follow tdma rules)
  4 tdma=20 or tdmaAndAtdma (must follow tdma rules)
  5 tdma or tdmaAndAtdma (must follow tdma = rules)=20
  6 tdma or tdmaAndAtdma = (must follow=20 tdma rules)
  9 = ignored - IUC not=20 used
 10 ignored - IUC = not=20 used
 11 ignored - IUC = not=20 used

2) atdma = upstream=20 channel
IUC chanType =
  1 atdma or tdmaAndAtdma (if = tdmaAndAtdma, must=20 follow tdma rules)
  2 = atdma or=20 tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules) - this IUC is = optional
  3 atdma or = tdmaAndAtdma=20 (if tdmaAndAtdma, must follow tdma rules)
  4 atdma or tdmaAndAtdma (if tdmaAndAtdma, must = follow tdma=20 rules)
  5 ignored - = IUC not=20 used
  6 ignored - IUC = not=20 used
  9 atdma or = tdmaAndAtdma=20 (must follow atdma rules)
 10=20 atdma or tdmaAndAtdma (must follow atdma rules)
 11 atdma or tdmaAndAtdma (must follow = atdma rules)=20 - this IUC is optional

3)=20 tdmaAndAtdma upstream channel
IUC=20 chanType
  1 =  tdma or=20 tdmaAndAtdma (must follow  tdma rules)
  2  tdma or tdmaAndAtdma (must follow  tdma = rules) -=20 this IUC is optional
  = 3=20  tdma or tdmaAndAtdma (must follow  tdma rules) =
  4  tdma or tdmaAndAtdma (must = follow=20  tdma rules)
  5 =  tdma=20 or tdmaAndAtdma (must follow  tdma rules)
  6  tdma or tdmaAndAtdma (must follow  tdma = rules)
  9 atdma or = tdmaAndAtdma=20 (must follow atdma rules)
 10=20 atdma or tdmaAndAtdma (must follow atdma rules)
 11 atdma or tdmaAndAtdma (must follow = atdma rules)=20 - this IUC is optional

4)=20 scdma upstream channel
IUC=20 chanType
  1 = scdma=20
  2 scdma - this IUC is = optional=20
  3 scdma
  4 scdma
  5 ignored=20 - IUC not used
  6 = ignored - IUC=20 not used
  9 = scdma=20
 10 scdma
 11 scdma - this IUC is optional

I have included modulation profile = channel type=20 tdmaAndAtdma for completeness' sake only. Note that the same results = can be=20 achieved without the tdmaAndAtdma modulation profile channel type, = even=20 though an usptream channel type of tdmaAndAtmda is still desirable. = Thus, we=20 could reduce the complexity and confusion of the modulation profile = table by=20 removing the tdmaAndAtdma modulation profile channel type = altogether.=20  Also note that modulation profile 3 (for the tdmaAndAtdma = upstream=20 channel) could be used on a tdma-only upstream channel, assuming the = UCD and=20 mapper algorithms on the CMTS ignore IUCs 9-11.

What do you think ?

Thanks,
David=20 White
ARRIS Cadant C4 = CMTS=20
Software Engineer=20




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

10/10/2003 12:56 PM =

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



What I had interpreted Minnie's = suggestion to be=20 was that ChannelType
consistency was enforced across all = modulation=20 profile rows with a
Status of 'active', regardless of whether = they were=20 assigned to an
upstream channel or not.  Setting Status to=20 'notInService' is not
allowed for propfiles assigned to an = upstream=20 channel, nor is changing
ChannelType.

So, the operation = Minnie=20 suggested only applies to profiles that have
been created and set = 'active', but are not assigned to any = upstream
channel.

Does that=20 clarify?

-Greg


-----Original Message-----
From: = Dan=20 Rice @ Stargus
Sent: Friday, October 10, 2003 7:59 AM
To: = Greg White;=20 Minnie Lu
Cc: David.White@arrisi.com; DOCSIS OSS Majordomo=20 List;
Greg.Gohman@arrisi.com; Larry.Spaete@arrisi.com;=20 ipcdn@ietf.org
Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 = (was RE:=20 DOCSIS 2.0 :
rules for assigning modulation profiles to upstream=20 channels)


Sorry for chiming in 11th hour, but want to = make sure I=20 understand
minnie's suggestion for active entries.  I = believe the=20 suggestion is
that for active entries you change the row status = to not in=20 service.
What would we expect to happen to the upstream currently = assigned this
modulation profile while it is notInService? =  Would=20 the existing active
assignment continue to be valid for the = upstream=20 using it until all IUC
rows became active again with the changes = in=20 them?

Also if the changes are to docsIfCmtsModChannelType = wouldn't=20 you have to
edit all IUC rows before checking to see if this is = valid?=20  I guess when
you started going in and making each IUC = active that=20 would be the point
to check it?  Could you guarantee that = all IUCs=20 are committed at the
same time since they would "immediately" be=20 committed to the active
upstream channel entries with pointers to = the=20 docsIfCmtsModIndex?

Thanks for the clarifications. -=20 Dan

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

That sounds like a workable alternative.  If = no one=20 disagrees, I will
make that change to the=20 proposal.

-Greg


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


Hi, Greg,

Then how about enforce this = rule for=20 "active" entries ? So in the case
you
mentioned, user can = change the=20 row status to notInService first or at
the
same time changing = the=20 channel type.  When user changed all the = entries'

channel type=20 to be the same, use can put the entries in active again.=20  I

personally think it affects a lot when the channel = type is=20 changed, so a

little more steps should be ok.  To me, if = there=20 is an error, better
catch
it as earlier as = possible.

"All the=20 active entries in a modulation profile (i.e. all active = entries

that=20 share a
common docsIfCmtsModIndex) MUST have the same value=20 of
docsIfCmtsModChannelType."

Thanks a lot = !
Minnie

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


_______________________________________________
IPCDN = mailing=20 = list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



=00 ------_=_NextPart_001_01C3BAB5.A6BFF513-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Dec 4 18:50:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26253 for ; Thu, 4 Dec 2003 18:50:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3ER-0008J3-Vp for ipcdn-archive@odin.ietf.org; Thu, 04 Dec 2003 18:50:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4No356031925 for ipcdn-archive@odin.ietf.org; Thu, 4 Dec 2003 18:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3EQ-0008Ik-UU; Thu, 04 Dec 2003 18:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3EJ-0008I8-6w for ipcdn@optimus.ietf.org; Thu, 04 Dec 2003 18:49:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26245 for ; Thu, 4 Dec 2003 18:49:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS3EE-0004pR-00 for ipcdn@ietf.org; Thu, 04 Dec 2003 18:49:50 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AS3ED-0004p6-00 for ipcdn@ietf.org; Thu, 04 Dec 2003 18:49:49 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hB4NnGoK026919; Thu, 4 Dec 2003 16:49:16 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RFMIBv2 ID-nits: references Date: Thu, 4 Dec 2003 16:49:15 -0700 Message-ID: Thread-Topic: [ipcdn] RFMIBv2 ID-nits: references Thread-Index: AcO6rRmPtySoJXHeRMqNqPOJ/PLpGQAAzjaAAAGXaCAAAlahgA== From: "Jean-Francois Mule" To: "Matthew Schmitt" , , "Eduardo Cardona" , Cc: X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Ok thanks Matt. But now that I read the tComLabs document, I still have a pb with = keeping this reference (and by now, I have found it in the text in the = REFERENCE clause of some objects). When you look at the document, it overwrites mib definitions for = rfc2670.docsIfDownChannelInterleave and rfc2670.docsIfDownChannelAnnex = (2 object defs from the old RFC 2670). The object definitions contained = in RF MIB v2 draft 08 are correct. =3D> so what we need in the RF MIB v2 is actually a normative reference = to the Euro-DOCSIS specification that mandates the interleaving formats = or ITU-T J83. Comments? Jean-Fran=E7ois=20 > -----Original Message----- > From: Matthew Schmitt=20 > Sent: Thursday, December 04, 2003 3:40 PM > To: Jean-Francois Mule; david.raftus@Terayon.com; Eduardo=20 > Cardona; deketelaere@tComLabs.com > Cc: ipcdn@ietf.org > Subject: RE: [ipcdn] RFMIBv2 ID-nits: references >=20 >=20 > FYI, I did manage to locate the referenced document on=20 > www.tcomlabs.com. The direct link is=20 > http://www.tcomlabs.com/Euro-DOCSIS/Documents/Add-Euro-DOCSIS_ > spec.pdf. Via their website, you can get to the file by=20 > first clicking on the Euro-DOCSIS link, then clicking on the=20 > Euro-DOCSIS 1.0 link (the link to that page is=20 > www.tcomlabs.com/Euro-DOCSIS/Euro-DOCSIS1.0.htm). On that=20 > page, it's the document listed as "Additional document: .pdf". >=20 > Matt >=20 > -----Original Message----- > From: Jean-Francois Mule=20 > Sent: Thursday, December 04, 2003 3:12 PM > To: david.raftus@Terayon.com; Eduardo Cardona;=20 > deketelaere@tComLabs.com > Cc: ipcdn@ietf.org > Subject: [ipcdn] RFMIBv2 ID-nits: references >=20 >=20 >=20 > Check ID nits and other comments made by mib doctors in other drafts. > http://www.ietf.org/ID-nits.html >=20 > There are normative references that are not even mentioned=20 > once and not used as IMPORTs in the document: > [1] Woundy, R., "Baseline Privacy Interface Management > Information Base for DOCSIS Compliant Cable Modems > and Cable Modem Termination Systems", RFC3083, March 2001. > [9] "Adapted MIB-definitions and a clarification for MPEG-related=20 > issues for EuroDOCSIS cable modem systems v1.01", tComLabs,=20 > May 2000., available at http://www.tcomlabs.com.=20 > Suggestions: > - call this reference in the text or just remove it; > - I cannot find the named reference under=20 > http://www.tcomlabs.com ; if you keep it, then > we need a=20 > better link, especially if it remains normative. >=20 >=20 > Also, should [6] be made informative instead of normative? > (a) it's a book=20 > (b) the DOCSIS specs are referenced normatively and that's=20 > where a normative reference on QPSK should be. > [6] Proakis, John G., "Digital Communications, 3rd Edition",=20 > McGraw-Hill, New York, New York, 1995, ISBN 0-07-051726-6=20 >=20 > Thanks, > Jean-Fran=E7ois > PS: also, CableLabs is working on a stable HTTP URL for our=20 > specifications so the http://www.cablemodem.com URL will most=20 > likely have to be updated. More on the actual URL soon. >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Dec 5 02:19:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23258 for ; Fri, 5 Dec 2003 02:19:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASAEy-000741-0B for ipcdn-archive@odin.ietf.org; Fri, 05 Dec 2003 02:19:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB57J3av027153 for ipcdn-archive@odin.ietf.org; Fri, 5 Dec 2003 02:19:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASAEu-00073m-Ek; Fri, 05 Dec 2003 02:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASADy-00072H-OA for ipcdn@optimus.ietf.org; Fri, 05 Dec 2003 02:18:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23124 for ; Fri, 5 Dec 2003 02:17:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASADv-0003i3-00 for ipcdn@ietf.org; Fri, 05 Dec 2003 02:17:59 -0500 Received: from apate.telenet-ops.be ([195.130.132.57]) by ietf-mx with esmtp (Exim 4.12) id 1ASADu-0003hu-00 for ipcdn@ietf.org; Fri, 05 Dec 2003 02:17:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by apate.telenet-ops.be (Postfix) with SMTP id 7B6A637E6C for ; Fri, 5 Dec 2003 08:17:53 +0100 (MET) Received: from tcomlabs.com (D5E0060A.kabel.telenet.be [213.224.6.10]) by apate.telenet-ops.be (Postfix) with SMTP id 3616837E99 for ; Fri, 5 Dec 2003 08:17:53 +0100 (MET) Received: (qmail 28113 invoked from network); 5 Dec 2003 07:16:45 -0000 Received: from localhost (HELO tComGateway.tComlabs.com) (127.0.0.1) by tcomlabs.com with SMTP; 5 Dec 2003 07:16:45 -0000 Received: from ([10.5.5.6]) by tComGateway.tComLabs.com (MailMonitor for SMTP v1.2.2 ) ; Fri, 5 Dec 2003 08:16:45 +0100 (CET) Message-ID: <005501c3baff$1ebd38d0$0605050a@WIMSLAPTOP> From: "Wim De Ketelaere" To: "Jean-Francois Mule" , "Matthew Schmitt" , , "Eduardo Cardona" Cc: References: Subject: Re: [ipcdn] RFMIBv2 ID-nits: references Date: Fri, 5 Dec 2003 08:12:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, I have no problem removing the MIBs from the document on our website if t= he final Euro-DOCSIS specifics are present in the MIB-RFC ! I believe you can reference to appendix N (1.0/1.1) and F (2.0), or just reference to the "European Specific Implementation" (cfr. language used in beginning 1.1 RFI-specification). Just let me know ! Thanks, Best regards, Wim ----- Original Message ----- From: "Jean-Francois Mule" To: "Matthew Schmitt" ; ; "Eduardo Cardona" ; Cc: Sent: Friday, December 05, 2003 12:49 AM Subject: RE: [ipcdn] RFMIBv2 ID-nits: references Ok thanks Matt. But now that I read the tComLabs document, I still have a pb with keeping this reference (and by now, I have found it in the text in the REFERENCE clause of some objects). When you look at the document, it overwrites mib definitions for rfc2670.docsIfDownChannelInterleave and rfc2670.docsIfDownChannelAnnex (2 object defs from the old RFC 2670). The object definitions contained in R= F MIB v2 draft 08 are correct. =3D> so what we need in the RF MIB v2 is actually a normative reference t= o the Euro-DOCSIS specification that mandates the interleaving formats or ITU-T J83. Comments? Jean-Fran=E7ois > -----Original Message----- > From: Matthew Schmitt > Sent: Thursday, December 04, 2003 3:40 PM > To: Jean-Francois Mule; david.raftus@Terayon.com; Eduardo > Cardona; deketelaere@tComLabs.com > Cc: ipcdn@ietf.org > Subject: RE: [ipcdn] RFMIBv2 ID-nits: references > > > FYI, I did manage to locate the referenced document on > www.tcomlabs.com. The direct link is > http://www.tcomlabs.com/Euro-DOCSIS/Documents/Add-Euro-DOCSIS_ > spec.pdf. Via their website, you can get to the file by > first clicking on the Euro-DOCSIS link, then clicking on the > Euro-DOCSIS 1.0 link (the link to that page is > www.tcomlabs.com/Euro-DOCSIS/Euro-DOCSIS1.0.htm). On that > page, it's the document listed as "Additional document: .pdf". > > Matt > > -----Original Message----- > From: Jean-Francois Mule > Sent: Thursday, December 04, 2003 3:12 PM > To: david.raftus@Terayon.com; Eduardo Cardona; > deketelaere@tComLabs.com > Cc: ipcdn@ietf.org > Subject: [ipcdn] RFMIBv2 ID-nits: references > > > > Check ID nits and other comments made by mib doctors in other drafts. > http://www.ietf.org/ID-nits.html > > There are normative references that are not even mentioned > once and not used as IMPORTs in the document: > [1] Woundy, R., "Baseline Privacy Interface Management > Information Base for DOCSIS Compliant Cable Modems > and Cable Modem Termination Systems", RFC3083, March 2001. > [9] "Adapted MIB-definitions and a clarification for MPEG-related > issues for EuroDOCSIS cable modem systems v1.01", tComLabs, > May 2000., available at http://www.tcomlabs.com. > Suggestions: > - call this reference in the text or just remove it; > - I cannot find the named reference under > http://www.tcomlabs.com ; if you keep it, then > we need a > better link, especially if it remains normative. > > > Also, should [6] be made informative instead of normative? > (a) it's a book > (b) the DOCSIS specs are referenced normatively and that's > where a normative reference on QPSK should be. > [6] Proakis, John G., "Digital Communications, 3rd Edition", > McGraw-Hill, New York, New York, 1995, ISBN 0-07-051726-6 > > Thanks, > Jean-Fran=E7ois > PS: also, CableLabs is working on a stable HTTP URL for our > specifications so the http://www.cablemodem.com URL will most > likely have to be updated. More on the actual URL soon. > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Dec 5 12:51:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16018 for ; Fri, 5 Dec 2003 12:51:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASK6X-0005lw-Rw for ipcdn-archive@odin.ietf.org; Fri, 05 Dec 2003 12:51:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5Hp1NQ022169 for ipcdn-archive@odin.ietf.org; Fri, 5 Dec 2003 12:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASK6W-0005lC-VO; Fri, 05 Dec 2003 12:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASK6N-0005kk-Rv for ipcdn@optimus.ietf.org; Fri, 05 Dec 2003 12:50:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16012 for ; Fri, 5 Dec 2003 12:50:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASK6L-0006BB-00 for ipcdn@ietf.org; Fri, 05 Dec 2003 12:50:49 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1ASK6L-0006Aw-00 for ipcdn@ietf.org; Fri, 05 Dec 2003 12:50:49 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hB5HoGoK024260; Fri, 5 Dec 2003 10:50:16 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RFMIBv2 ID-nits: references Date: Fri, 5 Dec 2003 10:50:15 -0700 Message-ID: Thread-Topic: [ipcdn] RFMIBv2 ID-nits: references Thread-Index: AcO6/+zM2alDgI2dRBShQvcpl/u2lAAOyr7g From: "Eduardo Cardona" To: "Wim De Ketelaere" , "Jean-Francois Mule" , "Matthew Schmitt" , Cc: X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all,=20 I am agree with Wim,=20 Moreover, the current pre-draft 9 ( not available publicly yet) includes = "EuroDOCSIS" in the glossary and references Annex F of DOCSIS 2.0 RFI = spec. (back as originally in RFIv2 MIB early drafts 00 and 01).=20 The reference [9] was before (since draft 02 which rferences DOCSIS 2.0 = RFI W04 to hold the requirement of docsIfDownChannelInterleave and = docsIfDownChannelAnnex,=20 At that time Annex F did not have those requirements. As Wim said, with pretty much all EuroDocsis requirements in RFI spec, = the EuroDOCSIS keyword would be enough to refer to the European = requirements. Following all your suggestions would remove reference [9] and put to = the ipcdn consideration=20 - Redefines docsIfDownChannelInterleave definition as : Original (draft 02-08): docsIfDownChannelInterleave OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), taps8Increment16(3), taps16Increment8(4), taps32Increment4(5), taps64Increment2(6), taps128Increment1(7), taps12increment17(8) } MAX-ACCESS read-write STATUS current DESCRIPTION "The Forward Error Correction (FEC) interleaving used for this downstream channel. Values are defined as follows: taps8Increment16(3): protection 5.9/4.1 usec, latency .22/.15 msec taps16Increment8(4): protection 12/8.2 usec, latency .48/.33 msec taps32Increment4(5): protection 24/16 usec, latency .98/.68 msec taps64Increment2(6): protection 47/33 usec, latency 2/1.4 msec taps128Increment1(7): protection 95/66 usec, latency 4/2.8 msec taps12increment17(8): protection 18/14 usec, latency 0.43/0.32 msec taps12increment17 is implemented in conformance with EuroDOCSIS document 'Adapted MIB-definitions - and a clarification for MPEG-related issues - for EuroDOCSIS cable modem systems' by tComLabs and should only be used for a EuroDOCSIS MAC interface. If the interface is down, this object either returns the configured value (CMTS), the most current value (CM), or the value of unknown(1). The value of other(2) is returned if the interleave is known but not defined in the above list. See the associated conformance object for write conditions and limitations. See the reference for the FEC configuration described by the setting of this object." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I04-030730, Table 6-13." ::=3D { docsIfDownstreamChannelEntry 5 }=20 Proposed for draft 09 docsIfDownChannelInterleave OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), taps8Increment16(3), taps16Increment8(4), taps32Increment4(5), taps64Increment2(6), taps128Increment1(7), taps12increment17(8) } MAX-ACCESS read-write STATUS current DESCRIPTION "The Forward Error Correction (FEC) interleaving used for this downstream channel. Values are defined as follows: taps8Increment16(3): protection 5.9/4.1 usec, latency .22/.15 msec taps16Increment8(4): protection 12/8.2 usec, latency .48/.33 msec taps32Increment4(5): protection 24/16 usec, latency .98/.68 msec taps64Increment2(6): protection 47/33 usec, latency 2/1.4 msec taps128Increment1(7): protection 95/66 usec, latency 4/2.8 msec taps12increment17(8): protection 18/14 usec, latency 0.43/0.32 msec =20 The value 'taps12increment17' is supported by EuroDOCSIS cable systems only and the others by DOCSIS cable systems. If the interface is down, this object either returns the configured value (CMTS), the most current value (CM), or the value of unknown(1). The value of other(2) is returned if the interleave is known but not defined in the above list. See the associated conformance object for write conditions and limitations. See the reference for the FEC configuration described by the setting of this object." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I04-030730, Table 6-15." ::=3D { docsIfDownstreamChannelEntry 5 }=20 Note in the coming draft 09 references will be updated to the current = RFIv2.0 I04 spec=20 e.g 6-13 in previous drafts is now 6-15. In this particular case the Annex F table F-11 is the equivalent to = table 6-15 but in the references I am inclined to leave only the DOCSIS = references. The RFI spec is clear in how to implement euroDOCSIS based = on the DOCSIS spec and Annex F "overrides". For docsIfDownChannelAnnex, I got input from greg White and the propose = text would be : Plass adding normative references to ITU-J83 and EN 300 429 OLD: docsIfDownChannelAnnex OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), annexA(3), annexB(4), annexC(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the conformance of the implementation to important regional cable standards. annexA : Annex A from ITU-J83 is used,=20 annexB : Annex B from ITU-J83 is used. annexC : Annex C from ITU-J83 is used.=20 AnnexB is used for DOCSIS implementations" REFERENCE "Document Adapted MIB-definitions and a clarification for MPEG-related issues for EuroDOCSIS cable modem systems v1.01, tComLabs, May 2000, Section 2.2" ::=3D { docsIfDownstreamChannelEntry 7 } NEW: docsIfDownChannelAnnex OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), annexA(3), annexB(4), annexC(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the conformance of the implementation to important regional cable standards. annexA : Annex A from ITU-J83 is used. equivalent to EN 300 429 annexB : Annex B from ITU-J83 is used. annexC : Annex C from ITU-J83 is used."=20 REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I04-030730, Sections 6.3.1, H.3.1." ::=3D { docsIfDownstreamChannelEntry 7 } New References: [EN 300 429] ETSI Standard EN 300 429, Version 1.2.1: Digital Video = Broadcasting (DVB), Framing structure, channel coding and modulation for cable systems, = April 1998. [ITU-T J.83] ITU-T Recommendation J.83 (4/97), Digital multi-programme = systems for television sound and data services for cable distribution. Let me know any comments Eduardo Below are the section texts for convenience: ------------ H.3.1 Downstream Data The Downstream Data Interface carries data from the MAC to the PHY for = transmission on the Downstream. All signals on the interface are synchronous with respect to a clock driven = by the PHY and received by the MAC. Four bits of data are transferred on each clock. The frequency of this = clock is proportional to the Downstream bit rate. Its precise frequency is a function of the Downstream Symbol Rate, = the modulation type (64QAM or 256QAM), and the physical layer framing in use (ITU-T Recommendations = J.83 Annex A or ITU-T Recommendations J.83 Annex B). -------------- 6.3.1 Downstream Protocol The downstream PMD sublayer MUST conform to ITU-T Recommendations J.83, = Annex B for Low-Delay Video Applications [ITU-T J.83-B], with the exceptions called out in = Section 6.3.2. Note: Any reference in this document to the transmission of television = in the forward channel that is not consistent with [EN 300 429] is = outside the normative scope as only [EN 300 429] is used for digital = multi-program TV distribution by cable in European applications. See = Section 1 (1.1 Scope). --------------- F.6.3.1 Downstream protocol The downstream PMD sublayer MUST conform to [EN 300 429]. -----Original Message----- From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com]=20 Sent: Friday, December 05, 2003 12:12 AM To: Jean-Francois Mule; Matthew Schmitt; david.raftus@Terayon.com; = Eduardo Cardona Cc: ipcdn@ietf.org Subject: Re: [ipcdn] RFMIBv2 ID-nits: references Hi all, I have no problem removing the MIBs from the document on our website if = the final Euro-DOCSIS specifics are present in the MIB-RFC ! I believe you can reference to appendix N (1.0/1.1) and F (2.0), or just = reference to the "European Specific Implementation" (cfr. language used = in beginning 1.1 RFI-specification). Just let me know ! Thanks, Best regards, Wim ----- Original Message ----- From: "Jean-Francois Mule" To: "Matthew Schmitt" ; = ; "Eduardo Cardona" ; = Cc: Sent: Friday, December 05, 2003 12:49 AM Subject: RE: [ipcdn] RFMIBv2 ID-nits: references Ok thanks Matt. But now that I read the tComLabs document, I still have a pb with = keeping this reference (and by now, I have found it in the text in the = REFERENCE clause of some objects). When you look at the document, it overwrites mib definitions for = rfc2670.docsIfDownChannelInterleave and rfc2670.docsIfDownChannelAnnex = (2 object defs from the old RFC 2670). The object definitions contained = in RF MIB v2 draft 08 are correct. =3D> so what we need in the RF MIB v2 is actually a normative reference = to the Euro-DOCSIS specification that mandates the interleaving formats = or ITU-T J83. Comments? Jean-Fran=E7ois > -----Original Message----- > From: Matthew Schmitt > Sent: Thursday, December 04, 2003 3:40 PM > To: Jean-Francois Mule; david.raftus@Terayon.com; Eduardo Cardona;=20 > deketelaere@tComLabs.com > Cc: ipcdn@ietf.org > Subject: RE: [ipcdn] RFMIBv2 ID-nits: references > > > FYI, I did manage to locate the referenced document on=20 > www.tcomlabs.com. The direct link is=20 > http://www.tcomlabs.com/Euro-DOCSIS/Documents/Add-Euro-DOCSIS_ > spec.pdf. Via their website, you can get to the file by first=20 > clicking on the Euro-DOCSIS link, then clicking on the Euro-DOCSIS 1.0 = > link (the link to that page is=20 > www.tcomlabs.com/Euro-DOCSIS/Euro-DOCSIS1.0.htm). On that page, it's=20 > the document listed as "Additional document: .pdf". > > Matt > > -----Original Message----- > From: Jean-Francois Mule > Sent: Thursday, December 04, 2003 3:12 PM > To: david.raftus@Terayon.com; Eduardo Cardona;=20 > deketelaere@tComLabs.com > Cc: ipcdn@ietf.org > Subject: [ipcdn] RFMIBv2 ID-nits: references > > > > Check ID nits and other comments made by mib doctors in other drafts. > http://www.ietf.org/ID-nits.html > > There are normative references that are not even mentioned once and=20 > not used as IMPORTs in the document: > [1] Woundy, R., "Baseline Privacy Interface Management > Information Base for DOCSIS Compliant Cable Modems > and Cable Modem Termination Systems", RFC3083, March 2001. > [9] "Adapted MIB-definitions and a clarification for MPEG-related > issues for EuroDOCSIS cable modem systems v1.01", tComLabs, > May 2000., available at http://www.tcomlabs.com. > Suggestions: > - call this reference in the text or just remove it; > - I cannot find the named reference under http://www.tcomlabs.com ;=20 > if you keep it, then > we need a better link, especially if it remains = > normative. > > > Also, should [6] be made informative instead of normative? > (a) it's a book > (b) the DOCSIS specs are referenced normatively and that's where a=20 > normative reference on QPSK should be. > [6] Proakis, John G., "Digital Communications, 3rd Edition", > McGraw-Hill, New York, New York, 1995, ISBN 0-07-051726-6 > > Thanks, > Jean-Fran=E7ois > PS: also, CableLabs is working on a stable HTTP URL for our=20 > specifications so the http://www.cablemodem.com URL will most likely=20 > have to be updated. More on the actual URL soon. > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Dec 5 13:45:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17842 for ; Fri, 5 Dec 2003 13:45:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASKwr-0008Q5-6d for ipcdn-archive@odin.ietf.org; Fri, 05 Dec 2003 13:45:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5Ij5q7032359 for ipcdn-archive@odin.ietf.org; Fri, 5 Dec 2003 13:45:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASKwp-0008Ph-3m; Fri, 05 Dec 2003 13:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASKwJ-0008P6-Gz for ipcdn@optimus.ietf.org; Fri, 05 Dec 2003 13:44:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17837 for ; Fri, 5 Dec 2003 13:44:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASKwF-0007PO-00 for ipcdn@ietf.org; Fri, 05 Dec 2003 13:44:27 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1ASKwF-0007Ob-00 for ipcdn@ietf.org; Fri, 05 Dec 2003 13:44:27 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hB5IhboM029330; Fri, 5 Dec 2003 11:43:55 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RFMIBv2 ID-nits: references Date: Fri, 5 Dec 2003 11:43:42 -0700 Message-ID: Thread-Topic: [ipcdn] RFMIBv2 ID-nits: references Thread-Index: AcO6/+zM2alDgI2dRBShQvcpl/u2lAAOyr7gAAkf3UA= From: "Jean-Francois Mule" To: "Eduardo Cardona" , "Wim De Ketelaere" , "Matthew Schmitt" Cc: X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Your proposal works for me, thank you all for addressing this nit. Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Dec 5 13:49:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18001 for ; Fri, 5 Dec 2003 13:49:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASL0f-00006O-40 for ipcdn-archive@odin.ietf.org; Fri, 05 Dec 2003 13:49:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5In1LW000369 for ipcdn-archive@odin.ietf.org; Fri, 5 Dec 2003 13:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASL0e-00005m-N7; Fri, 05 Dec 2003 13:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASKzx-000050-7S for ipcdn@optimus.ietf.org; Fri, 05 Dec 2003 13:48:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17927 for ; Fri, 5 Dec 2003 13:48:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASKzu-0007Um-00 for ipcdn@ietf.org; Fri, 05 Dec 2003 13:48:14 -0500 Received: from astra.telenet-ops.be ([195.130.132.58]) by ietf-mx with esmtp (Exim 4.12) id 1ASKzt-0007Ui-00 for ipcdn@ietf.org; Fri, 05 Dec 2003 13:48:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by astra.telenet-ops.be (Postfix) with SMTP id E889B38032 for ; Fri, 5 Dec 2003 19:48:12 +0100 (MET) Received: from tcomlabs.com (D5E0060A.kabel.telenet.be [213.224.6.10]) by astra.telenet-ops.be (Postfix) with SMTP id CBFB737FDF for ; Fri, 5 Dec 2003 19:48:09 +0100 (MET) Received: (qmail 7437 invoked from network); 5 Dec 2003 18:47:01 -0000 Received: from localhost (HELO tComGateway.tComlabs.com) (127.0.0.1) by tcomlabs.com with SMTP; 5 Dec 2003 18:47:01 -0000 Received: from ([10.5.5.6]) by tComGateway.tComLabs.com (MailMonitor for SMTP v1.2.2 ) ; Fri, 5 Dec 2003 19:47:01 +0100 (CET) Message-ID: <04d801c3bb5f$8bddec10$0605050a@WIMSLAPTOP> From: "Wim De Ketelaere" To: "Eduardo Cardona" , "Jean-Francois Mule" , "Matthew Schmitt" , Cc: References: Subject: Re: [ipcdn] RFMIBv2 ID-nits: references Date: Fri, 5 Dec 2003 19:42:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, Just one comment: We always use Euro-DOCSIS instead of EuroDOCSIS as this was the agreed up= on name within the certification board,... Thanks, Best regards, Wim ----- Original Message ----- From: "Eduardo Cardona" To: "Wim De Ketelaere" ; "Jean-Francois Mule" ; "Matthew Schmitt" ; Cc: Sent: Friday, December 05, 2003 6:50 PM Subject: RE: [ipcdn] RFMIBv2 ID-nits: references Hi all, I am agree with Wim, Moreover, the current pre-draft 9 ( not available publicly yet) includes "EuroDOCSIS" in the glossary and references Annex F of DOCSIS 2.0 RFI spe= c. (back as originally in RFIv2 MIB early drafts 00 and 01). The reference [9] was before (since draft 02 which rferences DOCSIS 2.0 R= FI W04 to hold the requirement of docsIfDownChannelInterleave and docsIfDownChannelAnnex, At that time Annex F did not have those requirements. As Wim said, with pretty much all EuroDocsis requirements in RFI spec, th= e EuroDOCSIS keyword would be enough to refer to the European requirements. Following all your suggestions would remove reference [9] and put to the ipcdn consideration - Redefines docsIfDownChannelInterleave definition as : Original (draft 02-08): docsIfDownChannelInterleave OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), taps8Increment16(3), taps16Increment8(4), taps32Increment4(5), taps64Increment2(6), taps128Increment1(7), taps12increment17(8) } MAX-ACCESS read-write STATUS current DESCRIPTION "The Forward Error Correction (FEC) interleaving used for this downstream channel. Values are defined as follows: taps8Increment16(3): protection 5.9/4.1 usec, latency .22/.15 msec taps16Increment8(4): protection 12/8.2 usec, latency .48/.33 msec taps32Increment4(5): protection 24/16 usec, latency .98/.68 msec taps64Increment2(6): protection 47/33 usec, latency 2/1.4 msec taps128Increment1(7): protection 95/66 usec, latency 4/2.8 msec taps12increment17(8): protection 18/14 usec, latency 0.43/0.32 msec taps12increment17 is implemented in conformance with EuroDOCSIS document 'Adapted MIB-definitions - and a clarification for MPEG-related issues - for EuroDOCSIS cable modem systems' by tComLabs and should only be used for a EuroDOCSIS MAC interface. If the interface is down, this object either returns the configured value (CMTS), the most current value (CM), or the value of unknown(1). The value of other(2) is returned if the interleave is known but not defined in the above list. See the associated conformance object for write conditions and limitations. See the reference for the FEC configuration described by the setting of this object." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I04-030730, Table 6-13." ::=3D { docsIfDownstreamChannelEntry 5 } Proposed for draft 09 docsIfDownChannelInterleave OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), taps8Increment16(3), taps16Increment8(4), taps32Increment4(5), taps64Increment2(6), taps128Increment1(7), taps12increment17(8) } MAX-ACCESS read-write STATUS current DESCRIPTION "The Forward Error Correction (FEC) interleaving used for this downstream channel. Values are defined as follows: taps8Increment16(3): protection 5.9/4.1 usec, latency .22/.15 msec taps16Increment8(4): protection 12/8.2 usec, latency .48/.33 msec taps32Increment4(5): protection 24/16 usec, latency .98/.68 msec taps64Increment2(6): protection 47/33 usec, latency 2/1.4 msec taps128Increment1(7): protection 95/66 usec, latency 4/2.8 msec taps12increment17(8): protection 18/14 usec, latency 0.43/0.32 msec The value 'taps12increment17' is supported by EuroDOCSIS cable systems only and the others by DOCSIS cable systems. If the interface is down, this object either returns the configured value (CMTS), the most current value (CM), or the value of unknown(1). The value of other(2) is returned if the interleave is known but not defined in the above list. See the associated conformance object for write conditions and limitations. See the reference for the FEC configuration described by the setting of this object." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I04-030730, Table 6-15." ::=3D { docsIfDownstreamChannelEntry 5 } Note in the coming draft 09 references will be updated to the current RFIv2.0 I04 spec e.g 6-13 in previous drafts is now 6-15. In this particular case the Annex F table F-11 is the equivalent to table 6-15 but in the references I am inclined to leave only the DOCSIS references. The RFI spec is clear in how to implement euroDOCSIS based o= n the DOCSIS spec and Annex F "overrides". For docsIfDownChannelAnnex, I got input from greg White and the propose t= ext would be : Plass adding normative references to ITU-J83 and EN 300 429 OLD: docsIfDownChannelAnnex OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), annexA(3), annexB(4), annexC(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the conformance of the implementation to important regional cable standards. annexA : Annex A from ITU-J83 is used, annexB : Annex B from ITU-J83 is used. annexC : Annex C from ITU-J83 is used. AnnexB is used for DOCSIS implementations" REFERENCE "Document Adapted MIB-definitions and a clarification for MPEG-related issues for EuroDOCSIS cable modem systems v1.01, tComLabs, May 2000, Section 2.2" ::=3D { docsIfDownstreamChannelEntry 7 } NEW: docsIfDownChannelAnnex OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), annexA(3), annexB(4), annexC(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the conformance of the implementation to important regional cable standards. annexA : Annex A from ITU-J83 is used. equivalent to EN 300 429 annexB : Annex B from ITU-J83 is used. annexC : Annex C from ITU-J83 is used." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I04-030730, Sections 6.3.1, H.3.1." ::=3D { docsIfDownstreamChannelEntry 7 } New References: [EN 300 429] ETSI Standard EN 300 429, Version 1.2.1: Digital Video Broadcasting (DVB), Framing structure, channel coding and modulation for cable systems, April 1998. [ITU-T J.83] ITU-T Recommendation J.83 (4/97), Digital multi-programme systems for television sound and data services for cable distribution. Let me know any comments Eduardo Below are the section texts for convenience: ------------ H.3.1 Downstream Data The Downstream Data Interface carries data from the MAC to the PHY for transmission on the Downstream. All signals on the interface are synchronous with respect to a clock driven b= y the PHY and received by the MAC. Four bits of data are transferred on each clock. The frequency of this cl= ock is proportional to the Downstream bit rate. Its precise frequency is a function of the Downstream Symbol Rate, = the modulation type (64QAM or 256QAM), and the physical layer framing in use (ITU-T Recommendations J.8= 3 Annex A or ITU-T Recommendations J.83 Annex B). -------------- 6.3.1 Downstream Protocol The downstream PMD sublayer MUST conform to ITU-T Recommendations J.83, Annex B for Low-Delay Video Applications [ITU-T J.83-B], with the exceptions called out in Sect= ion 6.3.2. Note: Any reference in this document to the transmission of television in the forward channel that is not consistent with [EN 300 429] is outside t= he normative scope as only [EN 300 429] is used for digital multi-program TV distribution by cable in European applications. See Section 1 (1.1 Scope)= . --------------- F.6.3.1 Downstream protocol The downstream PMD sublayer MUST conform to [EN 300 429]. -----Original Message----- From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com] Sent: Friday, December 05, 2003 12:12 AM To: Jean-Francois Mule; Matthew Schmitt; david.raftus@Terayon.com; Eduard= o Cardona Cc: ipcdn@ietf.org Subject: Re: [ipcdn] RFMIBv2 ID-nits: references Hi all, I have no problem removing the MIBs from the document on our website if t= he final Euro-DOCSIS specifics are present in the MIB-RFC ! I believe you can reference to appendix N (1.0/1.1) and F (2.0), or just reference to the "European Specific Implementation" (cfr. language used i= n beginning 1.1 RFI-specification). Just let me know ! Thanks, Best regards, Wim ----- Original Message ----- From: "Jean-Francois Mule" To: "Matthew Schmitt" ; ; "Eduardo Cardona" ; Cc: Sent: Friday, December 05, 2003 12:49 AM Subject: RE: [ipcdn] RFMIBv2 ID-nits: references Ok thanks Matt. But now that I read the tComLabs document, I still have a pb with keeping this reference (and by now, I have found it in the text in the REFERENCE clause of some objects). When you look at the document, it overwrites mib definitions for rfc2670.docsIfDownChannelInterleave and rfc2670.docsIfDownChannelAnnex (2 object defs from the old RFC 2670). The object definitions contained in R= F MIB v2 draft 08 are correct. =3D> so what we need in the RF MIB v2 is actually a normative reference t= o the Euro-DOCSIS specification that mandates the interleaving formats or ITU-T J83. Comments? Jean-Fran=E7ois > -----Original Message----- > From: Matthew Schmitt > Sent: Thursday, December 04, 2003 3:40 PM > To: Jean-Francois Mule; david.raftus@Terayon.com; Eduardo Cardona; > deketelaere@tComLabs.com > Cc: ipcdn@ietf.org > Subject: RE: [ipcdn] RFMIBv2 ID-nits: references > > > FYI, I did manage to locate the referenced document on > www.tcomlabs.com. The direct link is > http://www.tcomlabs.com/Euro-DOCSIS/Documents/Add-Euro-DOCSIS_ > spec.pdf. Via their website, you can get to the file by first > clicking on the Euro-DOCSIS link, then clicking on the Euro-DOCSIS 1.0 > link (the link to that page is > www.tcomlabs.com/Euro-DOCSIS/Euro-DOCSIS1.0.htm). On that page, it's > the document listed as "Additional document: .pdf". > > Matt > > -----Original Message----- > From: Jean-Francois Mule > Sent: Thursday, December 04, 2003 3:12 PM > To: david.raftus@Terayon.com; Eduardo Cardona; > deketelaere@tComLabs.com > Cc: ipcdn@ietf.org > Subject: [ipcdn] RFMIBv2 ID-nits: references > > > > Check ID nits and other comments made by mib doctors in other drafts. > http://www.ietf.org/ID-nits.html > > There are normative references that are not even mentioned once and > not used as IMPORTs in the document: > [1] Woundy, R., "Baseline Privacy Interface Management > Information Base for DOCSIS Compliant Cable Modems > and Cable Modem Termination Systems", RFC3083, March 2001. > [9] "Adapted MIB-definitions and a clarification for MPEG-related > issues for EuroDOCSIS cable modem systems v1.01", tComLabs, > May 2000., available at http://www.tcomlabs.com. > Suggestions: > - call this reference in the text or just remove it; > - I cannot find the named reference under http://www.tcomlabs.com ; > if you keep it, then > we need a better link, especially if it remains > normative. > > > Also, should [6] be made informative instead of normative? > (a) it's a book > (b) the DOCSIS specs are referenced normatively and that's where a > normative reference on QPSK should be. > [6] Proakis, John G., "Digital Communications, 3rd Edition", > McGraw-Hill, New York, New York, 1995, ISBN 0-07-051726-6 > > Thanks, > Jean-Fran=E7ois > PS: also, CableLabs is working on a stable HTTP URL for our > specifications so the http://www.cablemodem.com URL will most likely > have to be updated. More on the actual URL soon. > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Dec 5 15:13:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22354 for ; Fri, 5 Dec 2003 15:13:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASMJy-0003SM-7h for ipcdn-archive@odin.ietf.org; Fri, 05 Dec 2003 15:13:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5KD2qT013282 for ipcdn-archive@odin.ietf.org; Fri, 5 Dec 2003 15:13:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASMJx-0003Ry-17; Fri, 05 Dec 2003 15:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASMJW-0003R6-RD for ipcdn@optimus.ietf.org; Fri, 05 Dec 2003 15:12:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22267 for ; Fri, 5 Dec 2003 15:12:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASMJV-00013F-00 for ipcdn@ietf.org; Fri, 05 Dec 2003 15:12:33 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1ASMJU-000134-00 for ipcdn@ietf.org; Fri, 05 Dec 2003 15:12:32 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hB5KBxoK008881; Fri, 5 Dec 2003 13:12:00 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RFMIBv2 ID-nits: references Date: Fri, 5 Dec 2003 13:11:59 -0700 Message-ID: Thread-Topic: [ipcdn] RFMIBv2 ID-nits: references Thread-Index: AcO7YFtWZ6+eRGNSTiS/0khixlrdyAXh3E0g From: "Eduardo Cardona" To: "Wim De Ketelaere" , "Jean-Francois Mule" , "Matthew Schmitt" , Cc: X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thanks Wim,=20 Jean-Francois also pointed that to me, It will be corrected Eduardo -----Original Message----- From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com]=20 Sent: Friday, December 05, 2003 11:43 AM To: Eduardo Cardona; Jean-Francois Mule; Matthew Schmitt; = david.raftus@Terayon.com Cc: ipcdn@ietf.org Subject: Re: [ipcdn] RFMIBv2 ID-nits: references Hi all, Just one comment: We always use Euro-DOCSIS instead of EuroDOCSIS as this was the agreed = upon name within the certification board,... Thanks, Best regards, Wim ----- Original Message ----- From: "Eduardo Cardona" To: "Wim De Ketelaere" ; "Jean-Francois Mule" = ; "Matthew Schmitt" ; = Cc: Sent: Friday, December 05, 2003 6:50 PM Subject: RE: [ipcdn] RFMIBv2 ID-nits: references Hi all, I am agree with Wim, Moreover, the current pre-draft 9 ( not available publicly yet) includes = "EuroDOCSIS" in the glossary and references Annex F of DOCSIS 2.0 RFI = spec. (back as originally in RFIv2 MIB early drafts 00 and 01). The reference [9] was before (since draft 02 which rferences DOCSIS 2.0 = RFI W04 to hold the requirement of docsIfDownChannelInterleave and = docsIfDownChannelAnnex, At that time Annex F did not have those = requirements. As Wim said, with pretty much all EuroDocsis requirements in RFI spec, = the EuroDOCSIS keyword would be enough to refer to the European = requirements. Following all your suggestions would remove reference [9] and put to = the ipcdn consideration - Redefines docsIfDownChannelInterleave definition as : Original (draft 02-08): docsIfDownChannelInterleave OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), taps8Increment16(3), taps16Increment8(4), taps32Increment4(5), taps64Increment2(6), taps128Increment1(7), taps12increment17(8) } MAX-ACCESS read-write STATUS current DESCRIPTION "The Forward Error Correction (FEC) interleaving used for this downstream channel. Values are defined as follows: taps8Increment16(3): protection 5.9/4.1 usec, latency .22/.15 msec taps16Increment8(4): protection 12/8.2 usec, latency .48/.33 msec taps32Increment4(5): protection 24/16 usec, latency .98/.68 msec taps64Increment2(6): protection 47/33 usec, latency 2/1.4 msec taps128Increment1(7): protection 95/66 usec, latency 4/2.8 msec taps12increment17(8): protection 18/14 usec, latency 0.43/0.32 msec taps12increment17 is implemented in conformance with EuroDOCSIS document 'Adapted MIB-definitions - and a clarification for MPEG-related issues - for EuroDOCSIS cable modem systems' by tComLabs and should only be used for a EuroDOCSIS MAC interface. If the interface is down, this object either returns the configured value (CMTS), the most current value (CM), or the value of unknown(1). The value of other(2) is returned if the interleave is known but not defined in the above list. See the associated conformance object for write conditions and limitations. See the reference for the FEC configuration described by the setting of this object." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I04-030730, Table 6-13." ::=3D { docsIfDownstreamChannelEntry 5 } Proposed for draft 09 docsIfDownChannelInterleave OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), taps8Increment16(3), taps16Increment8(4), taps32Increment4(5), taps64Increment2(6), taps128Increment1(7), taps12increment17(8) } MAX-ACCESS read-write STATUS current DESCRIPTION "The Forward Error Correction (FEC) interleaving used for this downstream channel. Values are defined as follows: taps8Increment16(3): protection 5.9/4.1 usec, latency .22/.15 msec taps16Increment8(4): protection 12/8.2 usec, latency .48/.33 msec taps32Increment4(5): protection 24/16 usec, latency .98/.68 msec taps64Increment2(6): protection 47/33 usec, latency 2/1.4 msec taps128Increment1(7): protection 95/66 usec, latency 4/2.8 msec taps12increment17(8): protection 18/14 usec, latency 0.43/0.32 msec The value 'taps12increment17' is supported by EuroDOCSIS cable systems only and the others by DOCSIS cable systems. If the interface is down, this object either returns the configured value (CMTS), the most current value (CM), or the value of unknown(1). The value of other(2) is returned if the interleave is known but not defined in the above list. See the associated conformance object for write conditions and limitations. See the reference for the FEC configuration described by the setting of this object." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I04-030730, Table 6-15." ::=3D { docsIfDownstreamChannelEntry 5 } Note in the coming draft 09 references will be updated to the current = RFIv2.0 I04 spec e.g 6-13 in previous drafts is now 6-15. In this particular case the Annex F table F-11 is the equivalent to = table 6-15 but in the references I am inclined to leave only the DOCSIS = references. The RFI spec is clear in how to implement euroDOCSIS based = on the DOCSIS spec and Annex F "overrides". For docsIfDownChannelAnnex, I got input from greg White and the propose = text would be : Plass adding normative references to ITU-J83 and EN 300 = 429 OLD: docsIfDownChannelAnnex OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), annexA(3), annexB(4), annexC(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the conformance of the implementation to important regional cable standards. annexA : Annex A from ITU-J83 is used, annexB : Annex B from ITU-J83 is used. annexC : Annex C from ITU-J83 is used. AnnexB is used for DOCSIS implementations" REFERENCE "Document Adapted MIB-definitions and a clarification for MPEG-related issues for EuroDOCSIS cable modem systems v1.01, tComLabs, May 2000, Section 2.2" ::=3D { docsIfDownstreamChannelEntry 7 } NEW: docsIfDownChannelAnnex OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), annexA(3), annexB(4), annexC(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the conformance of the implementation to important regional cable standards. annexA : Annex A from ITU-J83 is used. equivalent to EN 300 429 annexB : Annex B from ITU-J83 is used. annexC : Annex C from ITU-J83 is used." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I04-030730, Sections 6.3.1, H.3.1." ::=3D { docsIfDownstreamChannelEntry 7 } New References: [EN 300 429] ETSI Standard EN 300 429, Version 1.2.1: Digital Video = Broadcasting (DVB), Framing structure, channel coding and modulation for = cable systems, April 1998. [ITU-T J.83] ITU-T Recommendation J.83 (4/97), Digital multi-programme = systems for television sound and data services for cable distribution. Let me know any comments Eduardo Below are the section texts for convenience: ------------ H.3.1 Downstream Data The Downstream Data Interface carries data from the MAC to the PHY for = transmission on the Downstream. All signals on the interface are = synchronous with respect to a clock driven by the PHY and received by = the MAC. Four bits of data are transferred on each clock. The frequency = of this clock is proportional to the Downstream bit rate. Its precise = frequency is a function of the Downstream Symbol Rate, the modulation = type (64QAM or 256QAM), and the physical layer framing in use (ITU-T = Recommendations J.83 Annex A or ITU-T Recommendations J.83 Annex B). -------------- 6.3.1 Downstream Protocol The downstream PMD sublayer MUST conform to ITU-T Recommendations J.83, = Annex B for Low-Delay Video Applications [ITU-T J.83-B], with the = exceptions called out in Section 6.3.2. Note: Any reference in this document to the transmission of television = in the forward channel that is not consistent with [EN 300 429] is = outside the normative scope as only [EN 300 429] is used for digital = multi-program TV distribution by cable in European applications. See = Section 1 (1.1 Scope). --------------- F.6.3.1 Downstream protocol The downstream PMD sublayer MUST conform to [EN 300 429]. -----Original Message----- From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com] Sent: Friday, December 05, 2003 12:12 AM To: Jean-Francois Mule; Matthew Schmitt; david.raftus@Terayon.com; = Eduardo Cardona Cc: ipcdn@ietf.org Subject: Re: [ipcdn] RFMIBv2 ID-nits: references Hi all, I have no problem removing the MIBs from the document on our website if = the final Euro-DOCSIS specifics are present in the MIB-RFC ! I believe you can reference to appendix N (1.0/1.1) and F (2.0), or just = reference to the "European Specific Implementation" (cfr. language used = in beginning 1.1 RFI-specification). Just let me know ! Thanks, Best regards, Wim ----- Original Message ----- From: "Jean-Francois Mule" To: "Matthew Schmitt" ; = ; "Eduardo Cardona" ; = Cc: Sent: Friday, December 05, 2003 12:49 AM Subject: RE: [ipcdn] RFMIBv2 ID-nits: references Ok thanks Matt. But now that I read the tComLabs document, I still have a pb with = keeping this reference (and by now, I have found it in the text in the = REFERENCE clause of some objects). When you look at the document, it overwrites mib definitions for = rfc2670.docsIfDownChannelInterleave and rfc2670.docsIfDownChannelAnnex = (2 object defs from the old RFC 2670). The object definitions contained = in RF MIB v2 draft 08 are correct. =3D> so what we need in the RF MIB v2 is actually a normative reference = to the Euro-DOCSIS specification that mandates the interleaving formats = or ITU-T J83. Comments? Jean-Fran=E7ois > -----Original Message----- > From: Matthew Schmitt > Sent: Thursday, December 04, 2003 3:40 PM > To: Jean-Francois Mule; david.raftus@Terayon.com; Eduardo Cardona;=20 > deketelaere@tComLabs.com > Cc: ipcdn@ietf.org > Subject: RE: [ipcdn] RFMIBv2 ID-nits: references > > > FYI, I did manage to locate the referenced document on=20 > www.tcomlabs.com. The direct link is=20 > http://www.tcomlabs.com/Euro-DOCSIS/Documents/Add-Euro-DOCSIS_ > spec.pdf. Via their website, you can get to the file by first=20 > clicking on the Euro-DOCSIS link, then clicking on the Euro-DOCSIS 1.0 = > link (the link to that page is=20 > www.tcomlabs.com/Euro-DOCSIS/Euro-DOCSIS1.0.htm). On that page, it's=20 > the document listed as "Additional document: .pdf". > > Matt > > -----Original Message----- > From: Jean-Francois Mule > Sent: Thursday, December 04, 2003 3:12 PM > To: david.raftus@Terayon.com; Eduardo Cardona;=20 > deketelaere@tComLabs.com > Cc: ipcdn@ietf.org > Subject: [ipcdn] RFMIBv2 ID-nits: references > > > > Check ID nits and other comments made by mib doctors in other drafts. > http://www.ietf.org/ID-nits.html > > There are normative references that are not even mentioned once and=20 > not used as IMPORTs in the document: > [1] Woundy, R., "Baseline Privacy Interface Management > Information Base for DOCSIS Compliant Cable Modems > and Cable Modem Termination Systems", RFC3083, March 2001. > [9] "Adapted MIB-definitions and a clarification for MPEG-related > issues for EuroDOCSIS cable modem systems v1.01", tComLabs, > May 2000., available at http://www.tcomlabs.com. > Suggestions: > - call this reference in the text or just remove it; > - I cannot find the named reference under http://www.tcomlabs.com ;=20 > if you keep it, then > we need a better link, especially if it remains = > normative. > > > Also, should [6] be made informative instead of normative? > (a) it's a book > (b) the DOCSIS specs are referenced normatively and that's where a=20 > normative reference on QPSK should be. > [6] Proakis, John G., "Digital Communications, 3rd Edition", > McGraw-Hill, New York, New York, 1995, ISBN 0-07-051726-6 > > Thanks, > Jean-Fran=E7ois > PS: also, CableLabs is working on a stable HTTP URL for our=20 > specifications so the http://www.cablemodem.com URL will most likely=20 > have to be updated. More on the actual URL soon. > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Dec 11 14:57:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17387 for ; Thu, 11 Dec 2003 14:57:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWvo-0005Te-6J for ipcdn-archive@odin.ietf.org; Thu, 11 Dec 2003 14:57:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBJv46g021031 for ipcdn-archive@odin.ietf.org; Thu, 11 Dec 2003 14:57:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWvk-0005SE-B5; Thu, 11 Dec 2003 14:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWvf-0005Rd-33 for ipcdn@optimus.ietf.org; Thu, 11 Dec 2003 14:56:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17255 for ; Thu, 11 Dec 2003 14:56:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUWvc-00066z-00 for ipcdn@ietf.org; Thu, 11 Dec 2003 14:56:52 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AUWvb-000652-00 for ipcdn@ietf.org; Thu, 11 Dec 2003 14:56:51 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBBJuGg11998 for ; Thu, 11 Dec 2003 13:56:17 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 11 Dec 2003 20:56:01 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155031D6F35@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Date: Thu, 11 Dec 2003 20:55:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] Minutes from IETF58 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Need to be submitted to minutes@ietf.org no later than Friday 19th of December. Current status: No materials submitted See: http://www.ietf.org/proceedings/03nov/index.html Thanks, Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Dec 16 15:34:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02449 for ; Tue, 16 Dec 2003 15:34:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLtM-0003sd-J6 for ipcdn-archive@odin.ietf.org; Tue, 16 Dec 2003 15:34:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGKY4uA014911 for ipcdn-archive@odin.ietf.org; Tue, 16 Dec 2003 15:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLtJ-0003s2-Ny; Tue, 16 Dec 2003 15:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLtB-0003rK-LE for ipcdn@optimus.ietf.org; Tue, 16 Dec 2003 15:33:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02353 for ; Tue, 16 Dec 2003 15:33:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWLtA-0001NT-00 for ipcdn@ietf.org; Tue, 16 Dec 2003 15:33:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWLt9-0001NL-00 for ipcdn@ietf.org; Tue, 16 Dec 2003 15:33:51 -0500 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1AWLt9-0001NH-00 for ipcdn@ietf.org; Tue, 16 Dec 2003 15:33:51 -0500 Received: from h-68-164-76-94.snvacaid.dynamic.covad.net ([68.164.76.94] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AWLt7-0001Xo-00 for ipcdn@ietf.org; Tue, 16 Dec 2003 12:33:49 -0800 Message-ID: <000a01c3c414$4cf94360$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <000a01c3b0cf$ce0a3480$7f1afea9@oemcomputer> Date: Tue, 16 Dec 2003 12:36:36 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ipcdn] Additional MIB reviewer comments on draft-ietf-ipcdn-device-mibv2-06.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - I ran smidiff on the MIB module in draft-ietf-ipcdn-device-mibv2-06.txt As a result of its complaints, I have a few more comments. 1) MIB review guidelines suggest old: REVISION "9908190000Z" new: REVISION "199908190000Z" 2) Has optionality of timezone in docsDevDateTime caused any problems? 3) The default value of docsDevNmAccessIpMask was changed from 0xffffffff to 0x00000000. This appears to be legal, but I'd like to confirm that the change is intentional. 4) The change to the SYNTAX of docsDevNmAccessCommunity does not seem to be among the kinds of changes permitted by RFC 2578 section 10.2. However, one *might* stretch section 4.9 of the MIB review guidelines to allow it. I suggest an alternative that does not require pushing the limits of 2578: use the SYNTAX clause in the conformance statement (OBJECT clause) for this OBJECT-TYPE to reach the same goal. 5) docsDevNmAccessInterfaces: same as comment (4) 6) docDevEvReporting: the conformance material should be updated with an OBJECT clause with a SYNTAX calling out the old set of bit values. See MIB review guidlines section 4.9 on page 28 of the current i-d. 7) smidiff complains that the new bit, "localVolatile", doesn't start a new byte. I can't find where the guidelines would require this, but I believe the rationale for the complaint is to make it easier for a management system to determine whether a system supports the new bit. 8) The change to the SYNTAX of docsDevFilterLLCIfIndex isn't legal. The old syntax permitted the value zero; the new one doesn't. 9) typo in docsDevFilterControl: delete superfluous "is" in "If is docsDevFilterIpContinue is set to true, continue" 10) The changes to the DESCRIPTION of docsDevFilterPolicyTable seem pretty extensive, removing a lot of explanatory material. Have there really been no semantic changes? 11) The change to the DESCRIPTION of docsDevFilterPolicyEntry appears to be a semantic change. If so, it probably should not be allowed. 12) The DESCRIPTION of docsDevFilterTosOrMask needs to be clearer about what it's referring to when it says "the above bits", "these bits" and "that value." 13) is the change of the initial value of docsDevCpeIpMax from 1 to -1 a semantic/behavioural change or just fixing a typo? Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Dec 17 09:16:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08299 for ; Wed, 17 Dec 2003 09:16:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWcT6-0003lA-CU for ipcdn-archive@odin.ietf.org; Wed, 17 Dec 2003 09:16:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHEG4GF014429 for ipcdn-archive@odin.ietf.org; Wed, 17 Dec 2003 09:16:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWcT4-0003kP-Sq; Wed, 17 Dec 2003 09:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWcSP-0003jV-5l for ipcdn@optimus.ietf.org; Wed, 17 Dec 2003 09:15:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08239 for ; Wed, 17 Dec 2003 09:15:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWcSN-0004Co-00 for ipcdn@ietf.org; Wed, 17 Dec 2003 09:15:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWcSM-0004Ch-00 for ipcdn@ietf.org; Wed, 17 Dec 2003 09:15:19 -0500 Received: from pacdcoavas04.cable.comcast.com ([208.17.33.53] helo=cable.comcast.com) by ietf-mx with esmtp (Exim 4.12) id 1AWcSM-0004CB-00 for ipcdn@ietf.org; Wed, 17 Dec 2003 09:15:18 -0500 Message-ID: From: "Woundy, Richard" To: "'IPCDN (E-mail) '" Cc: "'Jean-Francois Mule '" , "Woundy, Richard" Subject: RE: [ipcdn] Minutes from IETF58 Date: Tue, 16 Dec 2003 22:54:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=DATE_IN_PAST_06_12 autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Folks, Please review for accuracy the materials below from the IPCDN WG meeting in Minneapolis last month, and submit corrections to me by close of business day Wednesday December 17th. WG Meeting minutes: Presentation slides: I plan to submit these materials on Thursday December 18th. I want to extend my thanks to Azlina Ahmad and Greg Nakanishi for providing the basis for the meeting notes. The delay until now in preparing the minutes is all due to me. -- Rich -----Original Message----- From: ipcdn-admin@ietf.org To: Ipcdn (E-mail) Sent: 12/11/2003 2:55 PM Subject: [ipcdn] Minutes from IETF58 Need to be submitted to minutes@ietf.org no later than Friday 19th of December. Current status: No materials submitted See: http://www.ietf.org/proceedings/03nov/index.html Thanks, Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Dec 18 22:40:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09314 for ; Thu, 18 Dec 2003 22:40:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXBUn-0003Iy-Tc for ipcdn-archive@odin.ietf.org; Thu, 18 Dec 2003 22:40:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJ3e9MO012680 for ipcdn-archive@odin.ietf.org; Thu, 18 Dec 2003 22:40:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXBUi-0003IH-Q5; Thu, 18 Dec 2003 22:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXBTu-0003HX-RF for ipcdn@optimus.ietf.org; Thu, 18 Dec 2003 22:39:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09299 for ; Thu, 18 Dec 2003 22:39:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXBTr-0002nT-00 for ipcdn@ietf.org; Thu, 18 Dec 2003 22:39:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXBTq-0002nM-00 for ipcdn@ietf.org; Thu, 18 Dec 2003 22:39:11 -0500 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1AXBTq-0002nJ-00 for ipcdn@ietf.org; Thu, 18 Dec 2003 22:39:10 -0500 Received: from h-68-164-153-62.snvacaid.dynamic.covad.net ([68.164.153.62] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AXBTq-00042o-00 for ipcdn@ietf.org; Thu, 18 Dec 2003 19:39:10 -0800 Message-ID: <002501c3c5e2$0feee0e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <7D5D48D2CAA3D84C813F5B154F43B15502FB8827@nl0006exch001u.nl.lucent.com> <001801c3b2b4$e07aafa0$7f1afea9@oemcomputer> Subject: Re: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv2-06.txt Date: Thu, 18 Dec 2003 19:42:00 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - In draft-ietf-ipcdn-device-mibv2-06.txt, the following appears: docsDevFilterPolicyObsoleteGroup OBJECT-GROUP OBJECTS { docsDevFilterPolicyType, docsDevFilterPolicyAction } STATUS obsolete DESCRIPTION "These objects were removed from the policy mapping table with the introduction of external policy action tables prior to publication as RFC 2669." ::= { docsDevGroupsV2 9 } Given what is actually in RFC 2669, I'm having trouble making sense of the DESCRIPTION. What is the motivation for this OBJECT-GROUP? Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Dec 19 08:22:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08383 for ; Fri, 19 Dec 2003 08:22:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXKZt-000064-Bb for ipcdn-archive@odin.ietf.org; Fri, 19 Dec 2003 08:22:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJDM1Pm000365 for ipcdn-archive@odin.ietf.org; Fri, 19 Dec 2003 08:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXKZr-00005Z-Sl; Fri, 19 Dec 2003 08:21:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXKZp-00005D-Jr for ipcdn@optimus.ietf.org; Fri, 19 Dec 2003 08:21:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08356 for ; Fri, 19 Dec 2003 08:21:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXKZo-0002uR-00 for ipcdn@ietf.org; Fri, 19 Dec 2003 08:21:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXKZn-0002uK-00 for ipcdn@ietf.org; Fri, 19 Dec 2003 08:21:56 -0500 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx with esmtp (Exim 4.12) id 1AXKZn-0002u1-00 for ipcdn@ietf.org; Fri, 19 Dec 2003 08:21:55 -0500 Message-ID: From: "Woundy, Richard" To: "'Randy Presuhn'" Cc: ipcdn@ietf.org Subject: RE: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv 2-06.txt Date: Fri, 19 Dec 2003 08:18:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Randy, Good question. Those two MIB objects (docsDevFilterPolicyType, docsDevFilterPolicyAction) were defined in the original preparation of RFC 2669, but those MIB objects were commented out prior to RFC publication. The purpose of this object group is to identify those MIB objects so that the OIDs would not accidentally be reassigned. If there is a better approach for the draft to take, let me know. -- Rich P.S. I am working on the responses to your many other comments on this draft. Most of them need to be transcribed to email. Sorry about the awful delays. :^( -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Randy Presuhn Sent: Thursday, December 18, 2003 10:42 PM To: ipcdn@ietf.org Subject: Re: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv2-06.txt Hi - In draft-ietf-ipcdn-device-mibv2-06.txt, the following appears: docsDevFilterPolicyObsoleteGroup OBJECT-GROUP OBJECTS { docsDevFilterPolicyType, docsDevFilterPolicyAction } STATUS obsolete DESCRIPTION "These objects were removed from the policy mapping table with the introduction of external policy action tables prior to publication as RFC 2669." ::= { docsDevGroupsV2 9 } Given what is actually in RFC 2669, I'm having trouble making sense of the DESCRIPTION. What is the motivation for this OBJECT-GROUP? Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Dec 19 13:31:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19023 for ; Fri, 19 Dec 2003 13:31:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXPP0-0005OC-1z for ipcdn-archive@odin.ietf.org; Fri, 19 Dec 2003 13:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJIV6qs020693 for ipcdn-archive@odin.ietf.org; Fri, 19 Dec 2003 13:31:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXPOw-0005N4-C6; Fri, 19 Dec 2003 13:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXPOe-0005Gm-Jc for ipcdn@optimus.ietf.org; Fri, 19 Dec 2003 13:30:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18958 for ; Fri, 19 Dec 2003 13:30:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXPOc-0003af-00 for ipcdn@ietf.org; Fri, 19 Dec 2003 13:30:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXPOb-0003aY-00 for ipcdn@ietf.org; Fri, 19 Dec 2003 13:30:42 -0500 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1AXPOb-0003aQ-00 for ipcdn@ietf.org; Fri, 19 Dec 2003 13:30:41 -0500 Received: from h-68-164-156-202.snvacaid.dynamic.covad.net ([68.164.156.202] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AXPOW-0004kY-00 for ipcdn@ietf.org; Fri, 19 Dec 2003 10:30:36 -0800 Message-ID: <003201c3c65e$9920e080$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv2-06.txt Date: Fri, 19 Dec 2003 10:33:28 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - > From: "Woundy, Richard" > To: "'Randy Presuhn'" > Cc: > Sent: Friday, December 19, 2003 5:18 AM > Subject: RE: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv2-06.txt ... > Those two MIB objects (docsDevFilterPolicyType, docsDevFilterPolicyAction) > were defined in the original preparation of RFC 2669, but those MIB objects > were commented out prior to RFC publication. The purpose of this object > group is to identify those MIB objects so that the OIDs would not > accidentally be reassigned. This seems really bizarre. If they were taken out prior to publication, then those object identifiers were never really assigned. > If there is a better approach for the draft to take, let me know. ... I'm still trying to figure out what the real objective was. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Dec 19 16:24:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27738 for ; Fri, 19 Dec 2003 16:24:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS6S-0003lN-Ad for ipcdn-archive@odin.ietf.org; Fri, 19 Dec 2003 16:24:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJLO8dh014447 for ipcdn-archive@odin.ietf.org; Fri, 19 Dec 2003 16:24:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS6Q-0003jj-DS; Fri, 19 Dec 2003 16:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXRVL-0002h3-N6 for ipcdn@optimus.ietf.org; Fri, 19 Dec 2003 15:45:47 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25857; Fri, 19 Dec 2003 15:45:45 -0500 (EST) Message-Id: <200312192045.PAA25857@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 19 Dec 2003 15:45:45 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-docs-rfmibv2-09.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces Author(s) : D. Raftus Filename : draft-ietf-ipcdn-docs-rfmibv2-09.txt Pages : 128 Date : 2003-12-19 This memo is a draft revision of the standards track RFC-2670. Please see 'Section 9 Changes from RFC2670' for a description of modifications. This document or its successor will obsolete RFC-2670 when accepted. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS compliant Radio Frequency (RF) interfaces. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-docs-rfmibv2-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-19145655.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-docs-rfmibv2-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-19145655.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Sat Dec 20 12:13:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13670 for ; Sat, 20 Dec 2003 12:13:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXkfA-0002tZ-Uo for ipcdn-archive@odin.ietf.org; Sat, 20 Dec 2003 12:13:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBKHDCQl011125 for ipcdn-archive@odin.ietf.org; Sat, 20 Dec 2003 12:13:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXkf0-0002pK-Vp; Sat, 20 Dec 2003 12:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXkeZ-0002mp-Fg for ipcdn@optimus.ietf.org; Sat, 20 Dec 2003 12:12:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13604 for ; Sat, 20 Dec 2003 12:12:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXkeY-0007Ww-00 for ipcdn@ietf.org; Sat, 20 Dec 2003 12:12:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXkeX-0007Wp-00 for ipcdn@ietf.org; Sat, 20 Dec 2003 12:12:33 -0500 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx with esmtp (Exim 4.12) id 1AXkeW-0007TP-00 for ipcdn@ietf.org; Sat, 20 Dec 2003 12:12:32 -0500 Message-ID: From: "Woundy, Richard" To: "'Randy Presuhn'" Cc: ipcdn@ietf.org Subject: RE: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv 2-06.txt Date: Sat, 20 Dec 2003 12:08:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Randy, I am not the author of RFC 2669, where the two objects were defined but commented out. Here is what is in RFC 2669: -- docsDevFilterPolicyType ::= { docsDevFilterPolicyEntry 3} Removed -- docsDevFilterPolicyAction ::= { docsDevFilterPolicyEntry 4 } removed I was the author of this draft back in March 2001, when I originally added the "really bizarre group". I think I added it due to comments from a MIB doctor about how to handle these commented-out MIB objects, but I can't find those specific comments in my mail archives anymore. This was two employers and over 2 1/2 years ago. So what do you want me to do with respect to these commented-out objects from RFC 2669 in this internet-draft? 1. Leave the commented-out objects from RFC 2669 in the internet-draft as-is? (This option seemed to cause heartburn to a previous MIB doctor, at least.) 2. Delete the commented objects from the internet-draft? (This leaves an OID numbering hole in the internet-draft, with potentially no explanation.) 3. Use the "really bizarre group" to obsolete the non-existant objects, per the current internet-draft? (This explains that there are useless objects/OIDs from RFC 2669, but admittedly it is "bizarre".) 4. Do something else. (Tell me what.) This discussion is about never-implemented -- and never-will-be-implemented -- MIB objects. All I care about is consistent, rationale guidance. -- Rich -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Randy Presuhn Sent: Friday, December 19, 2003 1:33 PM To: ipcdn@ietf.org Subject: Re: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv2-06.txt Hi - > From: "Woundy, Richard" > To: "'Randy Presuhn'" > Cc: > Sent: Friday, December 19, 2003 5:18 AM > Subject: RE: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv2-06.txt ... > Those two MIB objects (docsDevFilterPolicyType, docsDevFilterPolicyAction) > were defined in the original preparation of RFC 2669, but those MIB objects > were commented out prior to RFC publication. The purpose of this object > group is to identify those MIB objects so that the OIDs would not > accidentally be reassigned. This seems really bizarre. If they were taken out prior to publication, then those object identifiers were never really assigned. > If there is a better approach for the draft to take, let me know. ... I'm still trying to figure out what the real objective was. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Sat Dec 20 15:45:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19185 for ; Sat, 20 Dec 2003 15:45:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXnyB-0000FY-VV for ipcdn-archive@odin.ietf.org; Sat, 20 Dec 2003 15:45:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBKKj3P7000940 for ipcdn-archive@odin.ietf.org; Sat, 20 Dec 2003 15:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXny9-0000Ej-JD; Sat, 20 Dec 2003 15:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXnxr-0000EQ-SF for ipcdn@optimus.ietf.org; Sat, 20 Dec 2003 15:44:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19182 for ; Sat, 20 Dec 2003 15:44:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXnxf-0005xk-00 for ipcdn@ietf.org; Sat, 20 Dec 2003 15:44:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXnwl-0005xd-00 for ipcdn@ietf.org; Sat, 20 Dec 2003 15:43:35 -0500 Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by ietf-mx with esmtp (Exim 4.12) id 1AXnwl-0005xX-00 for ipcdn@ietf.org; Sat, 20 Dec 2003 15:43:35 -0500 Received: from h-68-164-85-31.snvacaid.dynamic.covad.net ([68.164.85.31] helo=oemcomputer) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AXnvm-0003DZ-00; Sat, 20 Dec 2003 12:42:35 -0800 Message-ID: <000a01c3c73a$3522a780$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: "Mreview \(E-mail\)" References: Subject: Re: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv2-06.txt Date: Sat, 20 Dec 2003 12:45:30 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - > From: "Woundy, Richard" > To: "'Randy Presuhn'" > Cc: > Sent: Saturday, December 20, 2003 9:08 AM > Subject: RE: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv2-06.txt > > Randy, > > I am not the author of RFC 2669, where the two objects were defined but > commented out. Here is what is in RFC 2669: > -- docsDevFilterPolicyType ::= { docsDevFilterPolicyEntry 3} Removed > -- docsDevFilterPolicyAction ::= { docsDevFilterPolicyEntry 4 } removed > > I was the author of this draft back in March 2001, when I originally added > the "really bizarre group". I think I added it due to comments from a MIB > doctor about how to handle these commented-out MIB objects, but I can't find > those specific comments in my mail archives anymore. This was two employers > and over 2 1/2 years ago. > > So what do you want me to do with respect to these commented-out objects > from RFC 2669 in this internet-draft? > 1. Leave the commented-out objects from RFC 2669 in the internet-draft > as-is? (This option seemed to cause heartburn to a previous MIB doctor, at > least.) > 2. Delete the commented objects from the internet-draft? (This leaves an OID > numbering hole in the internet-draft, with potentially no explanation.) > 3. Use the "really bizarre group" to obsolete the non-existant objects, per > the current internet-draft? (This explains that there are useless > objects/OIDs from RFC 2669, but admittedly it is "bizarre".) > 4. Do something else. (Tell me what.) > > This discussion is about never-implemented -- and never-will-be-implemented > -- MIB objects. All I care about is consistent, rationale guidance. ... Thanks for the clear description of the history. Since the objects have never been implemented, and never will be implemented, and never even appeared in an RFC, there is no value in "preserving" the object identifiers. The rules for extending tables (RFC 2578 section 10.7 (7)) would put any new assignments at the end, so I don't see any way in which those two object identifiers could ever be re-used, since they're in the middle of the row. The only question is what to do about the hole in the numbering. I think creating bogus objects and a bogus group to explain the numbering gap does not make sense. I have seen tools that whine about numbering gaps, but I haven't been able to find anything in the SMI or MIB review guidelines that would suggest that gaps are actually a problem. The current texts in RFC 2669 and in draft-ietf-ipcdn-device-mibv2-06.txt confused, rather than enlighted me. The question at the bottom of it all is this: how much of the pre-RFC history do you really want/need to preserve here? I think the least confusing solution would be to simply say: > -- { docsDevFilterPolicyEntry 3} Skipped > -- { docsDevFilterPolicyEntry 4 } Skipped I'm cc-ing the MIB review mailing list to give other MIB reviewers opportunity to comment. Perhaps someone else has a better rationale for doing it one way or another, or can cite a recommendation I've missed. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Sat Dec 20 16:17:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20057 for ; Sat, 20 Dec 2003 16:17:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXoTA-00016c-AQ for ipcdn-archive@odin.ietf.org; Sat, 20 Dec 2003 16:17:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBKLH47M004233 for ipcdn-archive@odin.ietf.org; Sat, 20 Dec 2003 16:17:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXoT9-000160-5p; Sat, 20 Dec 2003 16:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXoSs-000146-Q2 for ipcdn@optimus.ietf.org; Sat, 20 Dec 2003 16:16:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20014 for ; Sat, 20 Dec 2003 16:16:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXoSr-0006rL-00 for ipcdn@ietf.org; Sat, 20 Dec 2003 16:16:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXoSq-0006rE-00 for ipcdn@ietf.org; Sat, 20 Dec 2003 16:16:44 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXoSp-0006r6-00 for ipcdn@ietf.org; Sat, 20 Dec 2003 16:16:44 -0500 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id hBKLGhX21793; Sat, 20 Dec 2003 13:16:43 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sat, 20 Dec 2003 13:16:42 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ipcdn@ietf.org cc: "Mreview (E-mail)" Subject: Re: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv2-06.txt In-Reply-To: <000a01c3c73a$3522a780$7f1afea9@oemcomputer> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , On Sat, 20 Dec 2003, Randy Presuhn wrote: [ ... description of development history deleted ... ] > Thanks for the clear description of the history. > > Since the objects have never been implemented, and never will be > implemented, and never even appeared in an RFC, there is no value > in "preserving" the object identifiers. Agree. > The rules for extending tables (RFC 2578 section 10.7 (7)) would > put any new assignments at the end, so I don't see any way in > which those two object identifiers could ever be re-used, > since they're in the middle of the row. Agree here too (but the section reference should be 10.2(7)) > The only question is what to do about the hole in the numbering. > > I think creating bogus objects and a bogus group to explain the > numbering gap does not make sense. Agree emphatically. > I have seen tools that whine about numbering gaps, but I haven't > been able to find anything in the SMI or MIB review guidelines > that would suggest that gaps are actually a problem. That's true. When I see gaps in a MIB module I am reviewing I usually suggest to reassign the OIDs unless folks have a reason not to, but I hasten to add that this is only a suggestion and not a requirement of the SMIv2 documents or of the reviewer guidelines. > The current texts in RFC 2669 and in > draft-ietf-ipcdn-device-mibv2-06.txt confused, rather than > enlighted me. The question at the bottom of it all is this: > how much of the pre-RFC history do you really want/need to > preserve here? I think the least confusing solution would > be to simply say: > > > -- { docsDevFilterPolicyEntry 3} Skipped > > -- { docsDevFilterPolicyEntry 4 } Skipped Sounds good to me. //cmh _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn