RE: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels)
"Jean-Francois Mule" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
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. 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... Jean-Francois. -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Thursday, December 04, 2003 2:21 PM To: Greg White Cc: Dan Rice @ Stargus; DOCSIS OSS Majordomo List; [email protected]; [email protected]; [email protected]; 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) 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" <[email protected]> Sent by: [email protected] 10/10/2003 12:56 PM To: "Dan Rice @ Stargus" <[email protected]>, "Minnie Lu" <[email protected]> cc: <[email protected]>, "DOCSIS OSS Majordomo List" <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]> 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: [email protected]; DOCSIS OSS Majordomo List; [email protected]; [email protected]; [email protected] 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:[email protected]] Sent: Wednesday, October 08, 2003 7:20 PM To: Minnie Lu Cc: [email protected]; DOCSIS OSS Majordomo List; [email protected]; [email protected]; [email protected] 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:[email protected]] Sent: Wednesday, October 08, 2003 3:09 PM To: Greg White Cc: Minnie Lu; [email protected]; DOCSIS OSS Majordomo List; [email protected]; [email protected]; [email protected] 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:[email protected]] >Sent: Wednesday, October 08, 2003 12:48 PM >To: Greg White >Cc: [email protected]; Minnie Lu; DOCSIS OSS Majordomo List; >[email protected]; [email protected]; [email protected] >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: [email protected] [mailto:[email protected]] > >Sent: Monday, August 25, 2003 5:59 PM > >To: Minnie Lu > >Cc: DOCSIS OSS Majordomo List; [email protected]; Greg White; > >[email protected]; 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 <[email protected]> > > > >08/25/2003 07:01 PM > > > > To: "Greg White" <[email protected]> > > cc: <[email protected]>, "Minnie Lu" > > <[email protected]>, <[email protected]>, <[email protected]>, > > > "DOCSIS OSS Majordomo List" <[email protected]>, "Owner DOCSIS >OSS > > Majordomo List" <[email protected]> > > 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: [email protected] [mailto:[email protected]] > > >Sent: Monday, August 25, 2003 11:07 AM > > >To: Minnie Lu; [email protected]; [email protected] > > >Cc: DOCSIS OSS Majordomo List; Greg White; [email protected]; 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 > > >[email protected] > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Steve Malenfant [mailto:[email protected]] > > >Sent: Monday, September 30, 2002 9:39 AM > > >To: '[email protected]' > > >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 <[email protected]> > > >Sent by: [email protected] > > > > > >08/21/2003 07:15 PM > > > > > > To: [email protected], "Greg White" > > > <[email protected]> > > > cc: "DOCSIS OSS Majordomo List" > > > <[email protected]>, [email protected] > > > 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, [email protected] 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" <[email protected]> > > > >Sent by: [email protected] > > > > > > > >08/20/2003 07:35 PM > > > > > > > > To: <[email protected]>, "DOCSIS OSS Majordomo >List" > > > > <[email protected]> > > > > 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: [email protected] [mailto:[email protected]] > > > >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 [email protected] https://www1.ietf.org/mailman/listinfo/ipcdn