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

Hi, Dan,

Thanks a lot for your review ! Please see my response inline.
Thanks!
Minnie

At 04:31 PM 10/10/2003 -0400, Dan Rice wrote:
>Thanks for getting me up to speed.
>
>It appears to me that I could still change an element in an active IUC
>as long as I don't change the docsIfCmtsModChannelType, can you please
>confirm?

[milu]: I think so as long as all the attributes are consistent with each 
other.

>Also it says
>" The maximum number of modulation profiles that a CMTS can support in
>docsIfCmtsModulationTable is vendor -specific"
>
>Would there be resistance to setting a minimum number of modulation
>profiles that a CMTS MUST support?  If not, than something like 2 times
>the number of upstream interfaces would be more than enough. - Dan

[milu]:  I don't think the spec or mib need to define a minimum number of 
modulation profiles that a CMTS MUST support.  If a CMTS vendor support the 
number less then the CMTS vendor's customer need, I think the customer will 
compliant or this CMTS will not be chosen by customers.:-)

Thanks a lot !
Minnie


>-----Original Message-----
>From: Minnie Lu [mailto:[email protected]]
>Sent: Friday, October 10, 2003 2:25 PM
>To: Dan Rice
>Cc: Greg White; Minnie Lu; [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)
>
>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