RE: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels)

Hi, Dan,

In the original proposal of Greg and Eduardo (also in OSS2-O-03092), there 
are more rules.  Please see Greg and Eduardo's original proposal for more 
details.  Here please allow me to list the ones in OSS2-O-03092.  (I added 
the word  'active' in the first sentence of the original OSS2-O-03092.)

All the active entries in a modulation profile (i.e. all active entries 
that share a common docsIfCmtsModIndex) MUST have the same value of 
docsIfCmtsModChannelType.  When assigning a modulation profile to an 
upstream channel, the value of docsIfUpChannelType and the value of 
docsIfCmtsModChannelType MUST match.
If a modulation profile is in use by one or more upstream channels, the 
value of docsIfCmtsModChannelType MUST NOT be changed.  Also, if a 
modulation profile is in use by one or more upstream channels, it MUST NOT 
be destroyed.  Before destroying a modulation profile, or changing the 
value of docsIfCmtsModChannelType for a profile, the user will need to 
ensure that it is not currently in use by any upstream channel.
The maximum number of modulation profiles that a CMTS can support in 
docsIfCmtsModulationTable is vendor -specific.

Now we are discussing how and when to enforce it as cleaner and easier way.

Thanks!
Minnie

At 01:26 PM 10/10/2003 -0400, Dan Rice wrote:


>-----Original Message-----
>From: Greg White [mailto:[email protected]]
>Sent: Friday, October 10, 2003 12:56 PM
>To: Dan Rice; 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)
>
>What I had interpreted Minnie's suggestion to be was that ChannelType
>consistency was enforced across all modulation profile rows with a
>Status of 'active', regardless of whether they were assigned to an
>upstream channel or not.  Setting Status to 'notInService' is not
>allowed for propfiles assigned to an upstream channel, nor is changing
>ChannelType.
>
>So, the operation Minnie suggested only applies to profiles that have
>been created and set 'active', but are not assigned to any upstream
>channel.
>
>Does that clarify?
>[DJR] Yes that sounds good. Thank You Greg
>Can I also extend your answer to infer one or both of the following:
>
>         1) Changing of the channel type is not allowed for any set of
>iuc rows while their modulation profile is assigned to an active
>upstream channel.
>         2) Changing any of the modulation profile attributes is not
>allowed while it is assigned to an active upstream channel?
>
>-Greg
>
>
>-----Original Message-----
>From: Dan Rice @ Stargus
>Sent: Friday, October 10, 2003 7:59 AM
>To: Greg White; Minnie Lu
>Cc: [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