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

From: "Greg White" <[email-masked]>
Date: Tue, 7 Oct 2003 16:22:16 -0600

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-masked] [mailto:[email-masked]] 
	Sent: Monday, August 25, 2003 5:59 PM
	To: Minnie Lu
	Cc: DOCSIS OSS Majordomo List; [email-masked]; Greg
White; [email-masked]; 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-masked]> 

08/25/2003 07:01 PM 

        To:        "Greg White" <[email-masked]> 
        cc:        <[email-masked]>, "Minnie Lu"
<[email-masked]>, <[email-masked]>, <[email-masked]>,
"DOCSIS OSS Majordomo List" <[email-masked]>, "Owner DOCSIS
OSS Majordomo List" <[email-masked]> 
        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-masked] [mailto:[email-masked]]
	>Sent: Monday, August 25, 2003 11:07 AM
	>To: Minnie Lu; [email-masked]; [email-masked]
	>Cc: DOCSIS OSS Majordomo List; Greg White; [email-masked];
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-masked]
	>
	>
	>
	>
	>
	>-----Original Message-----
	>From: Steve Malenfant [mailto:[email-masked]]
	>Sent: Monday, September 30, 2002 9:39 AM
	>To: [email-masked]'
	>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-masked]>
	>Sent by: [email-masked]
	>
	>08/21/2003 07:15 PM
	>
	>         To:        [email-masked], "Greg White" 
	> <[email-masked]>
	>         cc:        "DOCSIS OSS Majordomo List" 
	> <[email-masked]>, [email-masked]
	>         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-masked] 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-masked]>
	> >Sent by: [email-masked]
	> >
	> >08/20/2003 07:35 PM
	> >
	> >         To:        <[email-masked]>, "DOCSIS OSS
Majordomo List"
	> > <[email-masked]>
	> >         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-masked] [mailto:[email-masked]]
	> >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

---

From: "Eduardo Cardona" <[email-masked]>
Date: Tue, 7 Oct 2003 17:33:36 -0600

all IPCDN folks,
 
For the already posted issues, sometimes being silent is not always  the
clear way to say agree, 
The IPCDN chairs will take the final decisions in the issues posted, so
please take your time before Oct 10 to be able to hear your comments.
 
specially the Issues #13, #16 are being heavely debated, just we need
concensus if they are really needed and how.
# 14 is editorial and I left that for the end
 
# 23 already posted by Greg White, is being discussed in DOCSIS
reflector and the MIB is just reflecting the current ECO wording in more
detailed SNMP terms.

 
Thanks
 
Eduardo
 
P.D. I will post the last issue (#14) tomorrow.

 

	-----Original Message-----
	From: Greg White 
	Sent: Tuesday, October 07, 2003 4:22 PM
	To: [email-masked]; Minnie Lu
	Cc: DOCSIS OSS Majordomo List; [email-masked];
[email-masked]; Minnie Lu; [email-masked]
	Subject: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules
for assigning modulation profiles to upstream channels)

	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.  

	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-masked]
[mailto:[email-masked]] 
		Sent: Monday, August 25, 2003 5:59 PM
		To: Minnie Lu
		Cc: DOCSIS OSS Majordomo List; [email-masked];
Greg White; [email-masked]; 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 

		

08/25/2003 07:01 PM 

		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 
		>Since this has been a point of confusion at least twice
now, does anyone 
specification?

		>A further point, how does the CMTS enforce the match
between UpChannelType 
		>and ModChannelType?  One implementation may
automatically change 
		>docsIfUpChannelModulationProfile is set.  Another might
reject the change 
		>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.

		
		>Cc: DOCSIS OSS Majordomo List; Greg White;
[email-masked]; Owner DOCSIS 
		>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 ? 
tdmaAndAtdma, 
		>Your configuration settings for operation in multiple
mode is correct and 
		>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 
		>We are having some discussion internally here, and
would like to clarify
		>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.
		>  I like Greg's "Perhaps it is simpler just to require
that ModChannelType
		>ModChannelType".  Please keep in mind that when
assigning the modulation
		>only the docsIfModIndex and only one docsIfModIndex can
be assigned to some
		> >         IUCs 1, 2, 3, and 4 are used for both tdma
and atdma channels.
		> > 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 
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
		> > DocsisUpstreamTypeStatus object, perhaps ?) to avoid
a lot of confusion.
		> >         For the mixed-mode channels, where
UpChannelType is tdmaAndAtdma,
		> >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.
		> >         To:        <[email-masked]>, "DOCSIS
OSS Majordomo List"
		> >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.
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
		> >configured.  Perhaps it is simpler just to require
that ModChannelType
		> >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
docsIfCmtsModChannelType
		> >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

---

From: "Greg White" <[email-masked]>
Date: Wed, 8 Oct 2003 14:12:37 -0600

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-masked]] 
Sent: Wednesday, October 08, 2003 12:48 PM
To: Greg White
Cc: [email-masked]; Minnie Lu; DOCSIS OSS Majordomo List;
[email-masked]; [email-masked]; [email-masked]
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

>to propose that we complete the clarification of the relationship
between 
>the ChannelType parameters in modulation profiles and upstream
channels.
the 
>MIB descriptions.
read-only 
>object for active rows in the Upstream Channel Table.  The value
reported 
>would be taken from the modulation profile pointed to by 
issue.
the 
>attached proposal and provide comments.
>
>Many thanks,
>Greg
>Cc: DOCSIS OSS Majordomo List; [email-masked]; Greg White; 
>[email-masked]; 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
>
>
>
>
>

> "DOCSIS OSS Majordomo List" <[email-masked]>, "Owner DOCSIS
OSS 
> Majordomo List" <[email-masked]>
>         Fax to:
modulation 
> >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
> >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?
> >
>
UpChannelType
> >and ModChannelType?  One implementation may automatically change
> >docsIfUpChannelModulationProfile is set.  Another might reject the
change
> >docsIfUpChannelCloneFrom mechanism to change the channel type.  I'd
argue
> >that the first implementation makes more sense, and ought to be made
a
>[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.
> >Cc: DOCSIS OSS Majordomo List; Greg White; [email-masked]; 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
> >
> >Your configuration settings for operation in multiple mode is correct
and
> >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
> >We are having some discussion internally here, and would like to
clarify
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.
> >
> >
> >
> >
> >
modulation
ModChannelType
modulation
> >profile to some upstream via SNMP docsIfUpChannelModulationProfile,
it uses
> >only the docsIfModIndex and only one docsIfModIndex can be assigned
to some
channels.
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,
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
tdmaAndAtdma
> > > for ModChannelType really buys us anything. I'm thinking we could
just
> > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of
confusion.
> > >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
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
spinning.
> > >         To:        <[email-masked]>, "DOCSIS OSS Majordomo
List"
modulation
> > >I agree with all of your clearly legal/illegal combinations.  Among
the
> > >four that cause you consternation, I would break them done like
> > >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
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
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
ModChannelType
> > >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
modulation
> > > profile to make sure the assignment is compatible. For instance,
the
docsIfCmtsModChannelType
consternation:
> > >
> > >tdma, atdma
> > >tdma, tdmaAndAtdma
> > >atdma, tdma
> > >atdma, tdmaAndAtdma
> > >
> > >
> > >If ALL of these are legal, then I do not understand the point of
modulation
> > >ARRIS Cadant C4 CMTS

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: Minnie Lu <[email-masked]>
Date: Wed, 08 Oct 2003 11:47:48 -0700

Hi, Greg,

   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)

At 04:22 PM 10/7/2003 -0600, Greg White wrote:
>to propose that we complete the clarification of the relationship between 
>the ChannelType parameters in modulation profiles and upstream channels.
>
>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 
>Attached is a detailed proposal that Eduardo and I wrote to frame the issue.
>
>community and working group by this Friday, October 10.  Please review the 
> while implementing cross-checks for the 2.0 modulation and upstream data. 
> "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 
> upstream channel has already been provisioned, changing just the channel 
> "DOCSIS OSS Majordomo List" <[email-masked]>, "Owner DOCSIS OSS 
> >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.
> >ModChannelType.  Also, based on the exchange here it seems that there is
> >ModChannelType always match.  With those two restrictions, there clearly
> >Since this has been a point of confusion at least twice now, does anyone
> >A further point, how does the CMTS enforce the match between UpChannelType
> >docsIfUpChannelModulationProfile is set.  Another might reject the change
> >docsIfUpChannelCloneFrom mechanism to change the channel type.  I'd argue
> >that the first implementation makes more sense, and ought to be made a
>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
>   Actually, I am always puzzled when the modulation profile is being used
>changed ?  Maybe this is a confusing point which needs to be clarified, too.
>
> >Cc: DOCSIS OSS Majordomo List; Greg White; [email-masked]; Owner DOCSIS
> >OSS Majordomo List
> >         Sounds good to me. This would make verifying the consistency of
> > the data in the modulation profiles and the upstream channels far easier.
> >docsIfCmtsModChannelType. Otherwise, you would not be able to use that
> >profile set with different docsIfCmtsModChannelTypes from an e-mail thread
> >between Alberto and Steve from almost a year ago would be invalid, no ?
> >Your configuration settings for operation in multiple mode is correct and
> >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-masked]
> >
> >
> >
> >
> >
> >We are having some discussion internally here, and would like to clarify
> >Would this burst profile be good for docsIfUpChannelType tdma, tdmaAndAtdma
> >and Atdma?
> >
> >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.
> >  I like Greg's "Perhaps it is simpler just to require that ModChannelType
> >match UpChannelType.".
> >
> >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.
> >
> > >         IUCs 1, 2, 3, and 4 are used for both tdma and atdma channels.
> > > 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
> > > 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
> > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of confusion.
> > >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
> > >thinking. tdmaAndAtdma for modulation profiles has my head spinning.
> > >
> > >Thanks,
> > >David
> > >
> > >
> > >
> > >         To:        <[email-masked]>, "DOCSIS OSS Majordomo List"
> > >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
> > >advantages of that flexibility outweigh the disadvantages of having the
> > >configured.  Perhaps it is simpler just to require that ModChannelType
> > >match UpChannelType.
> > >
> > >-Greg
> > >
> > >
> > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to upstream
> > >channels
> > >
> > >
> > >DOCSIS 2.0 Community,
> > > modulation profile table and the upstream channel table exist, in part,
> > > 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
> > >However, it is the following cases that are causing me consternation:
> > >
> > >tdma, atdma
> > >tdma, tdmaAndAtdma
> > >atdma, tdma
> > >atdma, tdmaAndAtdma
> > >
> > >
> > >tdmaAndAtdma, other than to cause confusion, especially for modulation
> > >profiles.
> > >
> > >Thanks,
> > >David White
> > >ARRIS Cadant C4 CMTS
> >
>
>
>

---

From: "Greg White" <[email-masked]>
Date: Wed, 8 Oct 2003 17:20:12 -0600

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-masked]] 
Sent: Wednesday, October 08, 2003 3:09 PM
To: Greg White
Cc: Minnie Lu; [email-masked]; DOCSIS OSS Majordomo List;
[email-masked]; [email-masked]; [email-masked]
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

Thanks a lot !
Minnie

> >         I am emphathetic to your concerns. I ran across the same
issue
> > >The email exchange between Steve and Alberto notwithstanding, I
think
> > >ModChannelType.  Also, based on the exchange here it seems that
there
specification?
> > >that the first implementation makes more sense, and ought to be
made
profile
> >changed ?  Maybe this is a confusing point which needs to be
clarified,
consistency
profile
tdmaAndAtdma,
> > >Your configuration settings for operation in multiple mode is
correct
modulation
> > > > for ModChannelType really buys us anything. I'm thinking we
could
> > > >         To:        <[email-masked]>, "DOCSIS OSS
Majordomo
> > > >I agree with all of your clearly legal/illegal combinations.
Among
> > > >A tdmaAndAtdma modulation profile will include IUCs
1,3,4,5,6,9,10,
> > > >advantages of that flexibility outweigh the disadvantages of
having

---

From: Minnie Lu <[email-masked]>
Date: Wed, 08 Oct 2003 14:09:05 -0700

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.

Thanks a lot !
Minnie

---

From: [email-masked]
Date: Wed, 8 Oct 2003 17:11:29 -0400

Greg,
        Per your earlier e-mail on this thread:

"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."

I'm assuming "active" mean in-service. Otherwise, we have to be careful 
with this because the channelType is used to verify things like 
channelWidth and whether or not setting of the scdma-specific parameters 
is allowed. Along the same lines, if setting the upstream modulation 
profile index implies that the SNMP agent changes the upChannelType to 
match the modProfChannelType, then the agent must also verify that all of 
the other parameters in the upstream channel are compatible with the 
possibly new channel type.

David

"Greg White" <[email-masked]>
10/08/2003 04:12 PM

        To:     "Minnie Lu" <[email-masked]>
        cc:     <[email-masked]>, "DOCSIS OSS Majordomo List" 
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>
        Fax to: 
        Subject:        RE: Channel Types in RFMIBv2  (was RE: DOCSIS 2.0 : rules for  assigning 
modulation profiles to upstream channels)

Minnie,

-Greg

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 12:48 PM
To: Greg White
Cc: [email-masked]; Minnie Lu; DOCSIS OSS Majordomo List;

Hi, Greg,

between 
channels.
the 
read-only 
reported 
issue.
the 

data. 

kind 
other 
channel 

OSS 
modulation 
it
(i.e.
is
clearly
anyone
UpChannelType
change
argue
a
the
am
is
channel
used
too.
DOCSIS
of
easier.
that
thread
?
and
UCD
IUCs
described
clarify
tdmaAndAtdma
inside
modulation
ModChannelType
modulation
it uses
to some
channels.
channels. So,
objects 
Hence,
consistency
unintended 
IUCs 
if the
tdma-only
atdma
tdmaAndAtdma
just
confusion.
set
modulation
your 
spinning.
List"
modulation
the
possibly 
profile
channel.
and
channel
ignored the
the
ModChannelType
upstream
part,
two
modulation
the
docsIfCmtsModChannelType
modulation

---

From: "Greg White" <[email-masked]>
Date: Wed, 8 Oct 2003 17:35:27 -0600

David,
 
According to the proposed text, docsIfUpChannelType would be read-only
for ALL rows.  
 
For "active" rows (docsIfUpChannelStatus = active(1)) setting
UpChannelModulationProfile would return an error if the channel type of
the profile does not work with the other parameters in the row.  
 
For "cloned" rows (docsIfUpChannelStatus = notInService(2)) no
verification is done on consistency of parameters until
docsIfUpChannelUpdate is set to true.
 
The verification for active rows is indicated in the proposed text for
UpChannelModulationProfile, although it looks like it could be
clarified: 
 
             Setting this object on an "active" row MUST return an error
if the following 
             conditions are not satisfied:
             1. All the IUC entries in the selected modulation profile 
             MUST have the same value of docsIfCmtsModChannelType. 
             2. All of the modulation parameters in the selected 
             modulation profile MUST be consistent with the other 
             parameters in this docsIfUpChannelEntry. 
 
Does that address your concern?
 
-Greg

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] 
	Sent: Wednesday, October 08, 2003 3:11 PM
	To: Greg White
	Cc: DOCSIS OSS Majordomo List; [email-masked];
[email-masked]; [email-masked]; Minnie Lu
	Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 :
rules for assigning modulation profiles to upstream channels)

	Greg, 
	
	"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." 
	
	I'm assuming "active" mean in-service. Otherwise, we have to be
careful with this because the channelType is used to verify things like
channelWidth and whether or not setting of the scdma-specific parameters
is allowed. Along the same lines, if setting the upstream modulation
profile index implies that the SNMP agent changes the upChannelType to
match the modProfChannelType, then the agent must also verify that all
of the other parameters in the upstream channel are compatible with the
possibly new channel type. 
	
	David 

	

10/08/2003 04:12 PM 

        To:        "Minnie Lu" <[email-masked]> 
        cc:        <[email-masked]>, "DOCSIS OSS Majordomo List"
<[email-masked]>, <[email-masked]>,
<[email-masked]>, <[email-masked]> 
        Fax to:         
        Subject:        RE: Channel Types in RFMIBv2  (was RE: DOCSIS
2.0 : rules for  assigning modulation profiles to upstream channels)

	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.

	If there is a consensus to change the text, I am not strongly
opposed.
	
	-Greg
	
	-----Original Message-----
	From: Minnie Lu [mailto:[email-masked]] 
	Sent: Wednesday, October 08, 2003 12:48 PM
	To: Greg White
	Cc: [email-masked]; Minnie Lu; DOCSIS OSS Majordomo
List;
	[email-masked]; [email-masked]; [email-masked]
	Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 :
rules for
	assigning modulation profiles to upstream channels)

	Hi, Greg,

	
	  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."

	>As a final issue to resolve in the RFMIBv2 before draft-08, I
would
	like 
	between 
	channels.
	>There is currently an ECO (OSS2-O-03092) written by Minnie Lu
which 
	the 
	read-only 
	reported 
	>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 
	the 
	>Cc: DOCSIS OSS Majordomo List; [email-masked]; Greg
White; 
profiles to 
	
	data. 
	
	kind 
	other 
	channel 

	OSS 
	modulation 
	it
profile
	(i.e.
same
	is
UpChannelType and
there
	clearly
	> >Since this has been a point of confusion at least twice now,
does
	anyone
specification?
	UpChannelType
change
	> >docsIfUpChannelModulationProfile is set.  Another might
reject the
	change
	argue
	a
about the
channel, and
that
	the
	>upstream channel type would be changed automatically, too ?  If
yes, I
	am
profile
	is
upstream
	channel
The
	>   Actually, I am always puzzled when the modulation profile is
being
	used
type be
clarified, 
	too.
	> >Cc: DOCSIS OSS Majordomo List; Greg White; [email-masked];
Owner
	DOCSIS
profiles to
consistency
	of
	> > the data in the modulation profiles and the upstream
channels far
	easier.
profile
	> >docsIfCmtsModChannelType. Otherwise, you would not be able to
use
	that
modulation
	> >profile set with different docsIfCmtsModChannelTypes from an
e-mail
	thread
	> >between Alberto and Steve from almost a year ago would be
invalid, no
	?
tdmaAndAtdma,
correct
	and
	> >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is
used with
	UCD
	IUCs
	> >5&6 are not used. Your interpretation of the spec in the
example
	described
	> >We are having some discussion internally here, and would like
to
	clarify
	tdmaAndAtdma
	inside
type 29.
	modulation
	ModChannelType
	modulation
	> >profile to some upstream via SNMP
docsIfUpChannelModulationProfile,
	it uses
	> >only the docsIfModIndex and only one docsIfModIndex can be
assigned
	to some
	channels.
	channels. So,
	objects 
channel.
	Hence,
	> > > the whole purpose of even having ModChannelType - to
verify
	consistency
	unintended 
	> > > effect of requiring any assignment of modulation profiles
with
	IUCs 
	> > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check
to see
	if the
	tdma-only
modulation
tdmaAndAtdma for
	> > > modulation profiles that could not be met with a pair of
tdma and
	atdma
	tdmaAndAtdma
	just
of
	confusion.
could
profile
	set
	modulation
	> > >profile sets that the CMTS and CM can support. I'm really
liking
	your 
line of
	spinning.
Majordomo
	List"
	modulation
	> > >I agree with all of your clearly legal/illegal
combinations.  Among
	the
	> > >four that cause you consternation, I would break them done
like
	possibly 
modulation
	profile
	channel.
1,3,4,5,6,9,10,
	and
atdma
	channel
	ignored the
	the
	ModChannelType
profiles to
	upstream
	> > > modulation profile table and the upstream channel table
exist, in
	part,
data for
	> > > consistency. Furthermore, it would seem possible to
compare the
	two
	modulation
	> > > profile to make sure the assignment is compatible. For
instance,
	the
	docsIfCmtsModChannelType
	modulation

---

From: [email-masked]
Date: Thu, 9 Oct 2003 11:35:27 -0400

Greg,
        The main problem I have with this is that it forces the CMTS to 
postpone data checking until possibly the very end when the modulation 
profile is finally assigned. That is, the user may get a wrongValue or 
inconsistentValue while attempting to set the modulation profile because 
one or more already-set parameters do not agree with the ModChannelType. 
What I liked about having the UpChannelType being a configurable and 
"active" (rather than passive) object is that the CMTS verify things like 
ChannelWidth, SlotSize, and the Scdma parameters as they are being set. 
Thus, the error is immediate and pertitent.

However, what I like about your proposal is that it makes it easier to 
transition an upstream channel from tdma, atdma, and tdmaAndAtdma without 
having to change both the modulation profile and UpChannelType at the same 
time.

I'm not rejecting your proposal, but just wanted to voice my concerns.

Thanks,
David

10/08/2003 07:35 PM

        To:     <[email-masked]>
        cc:     "DOCSIS OSS Majordomo List" <[email-masked]>, 
<[email-masked]>, <[email-masked]>, <[email-masked]>, 
"Minnie Lu" <[email-masked]>
        Fax to: 
        Subject:        RE: Channel Types in RFMIBv2  (was RE: DOCSIS 2.0 : rules for  assigning 
modulation profiles to upstream channels)

David,
 
According to the proposed text, docsIfUpChannelType would be read-only for 
ALL rows. 

 
The verification for active rows is indicated in the proposed text for 
UpChannelModulationProfile, although it looks like it could be clarified: 

 
-Greg
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 3:11 PM
To: Greg White
Cc: DOCSIS OSS Majordomo List; [email-masked]; [email-masked]; 
[email-masked]; Minnie Lu
Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning 
modulation profiles to upstream channels)

Greg, 

David 

        To:        "Minnie Lu" <[email-masked]> 
        cc:        <[email-masked]>, "DOCSIS OSS Majordomo List" 
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]> 
        Fax to:         
        Subject:        RE: Channel Types in RFMIBv2  (was RE: DOCSIS 2.0 
: rules for  assigning modulation profiles to upstream channels)

Minnie,

-Greg

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 12:48 PM
To: Greg White
Cc: [email-masked]; Minnie Lu; DOCSIS OSS Majordomo List;

Hi, Greg,

between 
channels.
the 
read-only 
reported 
issue.
the 

data. 

kind 
other 
channel 

OSS 
modulation 
it
(i.e.
is
clearly
anyone
UpChannelType
change
argue
a
the
am
is
channel
used
too.
DOCSIS
of
easier.
that
thread
?
and
UCD
IUCs
described
clarify
tdmaAndAtdma
inside
modulation
ModChannelType
modulation
it uses
to some
channels.
channels. So,
objects 
Hence,
consistency
unintended 
IUCs 
if the
tdma-only
atdma
tdmaAndAtdma
just
confusion.
set
modulation
your 
spinning.
List"
modulation
the
possibly 
profile
channel.
and
channel
ignored the
the
ModChannelType
upstream
part,
two
modulation
the
docsIfCmtsModChannelType
modulation

---

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 9 Oct 2003 13:37:32 -0600

Hi David, Minnie, 

Greg may have other comments.
I think the idea was to define one clear way of configuration rather
than finding possible broken paths

The idea was to pass the role of The UpChannel parameters vs ChannelType
verification to one trigger, the docsIfUpChannelModulationProfile so it
verifies that all the channelTypes are the same (in the mod profile)
All Modulation Parameters are consistent in into their own IUC [ can be
done also as user change an IUC itself -invalid value for that
particulat CMTS-, etc]
Then as the Type is knew from the profile verifies that the ChannelType
is compatible with the UpChannel parameters, if fails nothing haven
change or undo-commit. 

The point is that UpChannel to ModulationProfile is one-to-many so going
in that path eventually the user won't break the Profile that works for
other UpChannels and instead maybe create a one-to-one
UpChannel-to-ModulationProfile  ( by creating a new Profile)

In the current UpChannelChanelType read-create we have, implies
UpChannelModProfile and ChannelType might need to be modified
simultaneously or:

1  UpChannelModProfile to '0'   then 
2  (updates UpChannel Parameters) then 
3  UpChannelType to 'x' and 
  -verify Chnnl-
4  UpChannelModulationProfile to 'y'
  -verify Chnnl UpCh/ModProfile- 
   if failed start again from 1

With the proposal at maximum ( channelType RO) would be  
1  UpChannelModProfile to '0'   then 
2  (updates UpChannel Parameters) then 
3  UpChannelModulationProfile to 'y'
   - do all verifications chnnl/ModProf-  
     if failed redo 2, maybe adjust ModulationProfileTable and 3)

Are there any other updated paths to consider for simplified setup,
other sequence? 
Or maybe be more details in the sequence for the objects ?

Eduardo

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Thursday, October 09, 2003 12:25 PM
To: [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];
[email-masked]; [email-masked]; Minnie Lu; Owner DOCSIS OSS
Majordomo List
Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for
assigning modulation profiles to upstream channels)

Hi, David,

  Your concern sounds very valid. Then it seems to me that

1. either have docsIfUpChannelType is read-only and ask the 
docsIfUpChannelModulationProfile must be assigned first before setting 
other upstream attributes.  For this is one, I don't know user would
like 
it or not.

2. or we still need to keep the  docsIfUpChannelType is read-create, so
it 
can be used to check other upstream attributes consistence without
having 
an modulation profile assigned. The user must make sure both 
docsIfUpChannelModulationProfile and docsIfUpChannelType are the same
when 
trying to set either one of them if docsIfUpChannelModulationProfile is
not 
value 0. If they are not consistent, the set will fail.

Any more possible solution ?

Just some more thoughts.

Thanks a lot !
Minnie

> <[email-masked]>, <[email-masked]>, 
> <[email-masked]>,
> <[email-masked]>, "Minnie Lu" <[email-masked]>
>         Fax to:
2.0 
>for

>docsIfUpChannelModulationProfile."
>
of 
>        Subject:        RE: Channel Types in RFMIBv2  (was RE: DOCSIS
2.0 

> >[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
> >by some upstream channels, could the modulation profile channel type 
> >be changed ?  Maybe this is a confusing point which needs to be 
> >clarified,
>too.
> >
> > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles 
> > >to upstream channels
> > >
> > >Minnie,
> > >profile entries with the same docsIfCmtsModIndex will have to have 
> > >the same docsIfCmtsModChannelType. Otherwise, you would not be able

> > >to use

> > >tdmaAndAtdma, correct ?
> > > >         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
> > > >sure the benefits of flexibility outweigh disadvantages..." line 
> > > >of thinking. tdmaAndAtdma for modulation profiles has my head
>spinning.
> > > >
> > > >Thanks,
> > > >David
> > > >
> > > >
> > > >
Majordomo

> > > > to provide the equipment vendor a way to cross-check the data 
> > > > for consistency. Furthermore, it would seem possible to compare 
> > > > the
>two

---

From: Minnie Lu <[email-masked]>
Date: Thu, 09 Oct 2003 11:25:25 -0700

Hi, David,

1. either have docsIfUpChannelType is read-only and ask the 
docsIfUpChannelModulationProfile must be assigned first before setting 
other upstream attributes.  For this is one, I don't know user would like 
it or not.

2. or we still need to keep the  docsIfUpChannelType is read-create, so it 
can be used to check other upstream attributes consistence without having 
an modulation profile assigned. The user must make sure both 
docsIfUpChannelModulationProfile and docsIfUpChannelType are the same when 
trying to set either one of them if docsIfUpChannelModulationProfile is not 
value 0. If they are not consistent, the set will fail.

Just some more thoughts.

Thanks a lot !
Minnie

At 11:35 AM 10/9/2003 -0400, [email-masked] wrote:

> <[email-masked]>, <[email-masked]>, <[email-masked]>,

---

From: "Greg White" <[email-masked]>
Date: Thu, 9 Oct 2003 16:30:35 -0600

So, first off, there are a number of parameters that must be consistent
across the two tables for the configuration to be valid, and the active
rows in the UpChannelTable *always* have to be valid.  The only possible
exception to this would be if the interface were turned down before the
changes were made, but I don't think that is an operationally useful
scenario to consider, and some (all?) vendors might want to enforce
validity even in that case.

Any active row in the UpChannelTable will be populated by consistent
defaults or stored values when the CMTS is booted, so we only need to
consider *changes* to those rows (i.e. they can't be created from
scratch and so would never have to be populated one-object-at-a-time).
Any change to an active row can be done by two methods: direct change &
cloning.

When a change is made directly, the validation occurs immediately upon
receiving the snmp set.  When using the cloning mechanism, the
validation only occurs when the ChannelUpdate object is set true.  This
proposal does not change either of those aspects.  It only enforces that
UpChannelModulationProfile and UpChannelType are guaranteed to be
consistent with each other.

The whole point of the cloning mechanism was to have a temporary
"scratch" area where an operator could manipulate the values without
having the constraint that they are consistent at every step.  Thus the
consistency verification is only done upon ChannelUpdate.

I don't think that the steps Eduardo suggested are valid, setting
ModulationProfile to '0' on an active row would seem to make the channel
unusable, no?  Setting ModulationProfile to '0' on an inactive row
wouldn't be necessary since there is no consistency checking.

Let me know if I'm completely missing the boat here....

-Greg

-----Original Message-----
From: Eduardo Cardona 
Sent: Thursday, October 09, 2003 1:38 PM
To: 'Minnie Lu'; [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];
[email-masked]; [email-masked]; Owner DOCSIS OSS Majordomo List
Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for
assigning modulation profiles to upstream channels)

Hi David, Minnie, 

The idea was to pass the role of The UpChannel parameters vs ChannelType
verification to one trigger, the docsIfUpChannelModulationProfile so it
verifies that all the channelTypes are the same (in the mod profile) All
Modulation Parameters are consistent in into their own IUC [ can be done
also as user change an IUC itself -invalid value for that particulat
CMTS-, etc] Then as the Type is knew from the profile verifies that the
ChannelType is compatible with the UpChannel parameters, if fails
nothing haven change or undo-commit. 

Eduardo

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Thursday, October 09, 2003 12:25 PM
To: [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];

Hi, David,

Just some more thoughts.

Thanks a lot !
Minnie

>transition an upstream channel from tdma, atdma, and tdmaAndAtdma 
>without having to change both the modulation profile and UpChannelType 
>at the same time.
>
2.0 

>channelWidth and whether or not setting of the scdma-specific 
>parameters is allowed. Along the same lines, if setting the upstream 
>modulation profile index implies that the SNMP agent changes the 
>upChannelType to match the modProfChannelType, then the agent must also

>verify that all of the other parameters in the upstream channel are 
>compatible with the possibly new channel type.
>
>David
>
>
2.0 

Majordomo

---

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 9 Oct 2003 18:37:18 -0600

I agree that turning off is not desired for in-service if the changes
are not incremental or very drastic changes, I did not enforce the "at
maximum" word in both cases (actually I only used that in the second
example). It might be some cases where the interface or implementations
definitely have to be turn off, but will be on maintenance windows,
(season changes -?- school calendar, long weekend?, maintenance
measurements.) very uncommon or at knowledge of consequences by MSOs.

I agree that the primarily intention is minimum service disruption
primarily for spectrum management when changes might be incremental in
robustness parameters or phy channel parameters. 

And as Greg said, one shot change if moving channel from profile A to B.
and seems to me that changes in profile should be compatible to the
current channel PHY and ulterior modification of the channel will be
also, the only problem as today is the double location of ChannelType 

Eduardo

-----Original Message-----
From: Greg White 
Sent: Thursday, October 09, 2003 4:31 PM
To: Eduardo Cardona; 'Minnie Lu'; [email-masked]'
Cc: DOCSIS OSS Majordomo List; [email-masked]';
[email-masked]'; [email-masked]'; Owner DOCSIS OSS Majordomo
List
Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for
assigning modulation profiles to upstream channels)

-Greg

-----Original Message-----
From: Eduardo Cardona 
Sent: Thursday, October 09, 2003 1:38 PM
To: 'Minnie Lu'; [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];

Hi David, Minnie, 

Eduardo

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Thursday, October 09, 2003 12:25 PM
To: [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];

Hi, David,

Just some more thoughts.

Thanks a lot !
Minnie

At 11:35 AM 10/9/2003 -0400, [email-masked] wrote:

>Greg,
>         The main problem I have with this is that it forces the CMTS 
>to  postpone data checking until possibly the very end when the 
>modulation  profile is finally assigned. That is, the user may get a 
>wrongValue or  inconsistentValue while attempting to set the modulation

>profile because  one or more already-set parameters do not agree with 
>the ModChannelType.  What I liked about having the UpChannelType being 
>a configurable and  "active" (rather than passive) object is that the 
>CMTS verify things like  ChannelWidth, SlotSize, and the Scdma 
>parameters as they are being set.  Thus, the error is immediate and 
>pertitent.
>
> <[email-masked]>, <[email-masked]>, "Minnie Lu" 
> <[email-masked]>
>         Fax to:
2.0 

>              Setting this object on an "active" row MUST return an 
> error if the following

2.0 

Majordomo

---

From: "Dan Rice" <[email-masked]>
Date: Fri, 10 Oct 2003 09:59:09 -0400

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-masked]] 
Sent: Wednesday, October 08, 2003 7:20 PM
To: Minnie Lu
Cc: [email-masked]; DOCSIS OSS Majordomo List;
[email-masked]; [email-masked]; [email-masked]
Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 :
rules for assigning modulation profiles to upstream channels)

-Greg

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 3:09 PM
To: Greg White
Cc: Minnie Lu; [email-masked]; DOCSIS OSS Majordomo List;

Hi, Greg,

that share a

Thanks a lot !
Minnie

issue
think
there
specification?
made
the
profile
be
clarified,
to
consistency
profile
tdmaAndAtdma,
correct
modulation
for
could
of
Majordomo
Among
1,3,4,5,6,9,10,
having
for

---

From: "Dan Rice" <[email-masked]>
Date: Fri, 10 Oct 2003 10:17:14 -0400

For my $0.02 I would prefer just having the clone mechanism.  Even
within the upstream channel parameters you must change things in the
right order for them to be correct if you do it while row is active.
This is not just an UpChannelType issue.  For example setting a minislot
size before changing the symbol rate can result in some situations that
CMTSs today will reject. If you reduce the minislot size before
increasing symbol rate, you could no longer send a max packet.

I think if we made the clone method mandatory for both TDMA and SCDMA
and changed the descriptions to be this way than I would be happy
because there is now a deterministic way to make changes and commit
them.  Today in most deployed CMTSs its hard to know how many UCD
changes occur when you make changes to upstream channel today.  It seems
to depend on vendor.  When all you are really shooting for is an end
result this seems the safest and most deterministic route to me.  

I think that many of the cases of making changes to active modulation
profiles and upstream channel settings can make things a little funny if
the commit isn't very defined.  If there are requirements for support of
enough modulation table entries and enough clone rows to accommodate an
active and notInService for each upstream interface this could be a lot
cleaner. Any change that is made is done by creating a new complete
modulation profile (even if its just changing one value, I imagine most
of this will done through software as opposed to hand editing) then
creating a clone upstream channel table entry with pointer to this new
mod profile and associated upstream channel settings, then commit the
changes.

Additionally it would be nice to have the same functionality in the
downstream channel table to be consistent. For example it would be nice
to commit modulation and interleave settings at the same time.

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]] 
Sent: Thursday, October 09, 2003 8:37 PM
To: Greg White; Minnie Lu; [email-masked]
Cc: DOCSIS OSS Majordomo List; [email-masked]; [email-masked];
[email-masked]; Owner DOCSIS OSS Majordomo List
Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 :
rules for assigning modulation profiles to upstream channels)

Eduardo

-----Original Message-----
From: Greg White 
Sent: Thursday, October 09, 2003 4:31 PM
To: Eduardo Cardona; 'Minnie Lu'; [email-masked]'
Cc: DOCSIS OSS Majordomo List; [email-masked]';

-Greg

-----Original Message-----
From: Eduardo Cardona 
Sent: Thursday, October 09, 2003 1:38 PM
To: 'Minnie Lu'; [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];

Hi David, Minnie, 

Eduardo

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Thursday, October 09, 2003 12:25 PM
To: [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];

Hi, David,

Just some more thoughts.

Thanks a lot !
Minnie

2.0 

2.0 

Majordomo

---

From: "Eduardo Cardona" <[email-masked]>
Date: Fri, 10 Oct 2003 09:33:24 -0600

Dan, 

That's a very good point, Currently is up to de Vendor for non-SCDMA, I
think we did not finish the discussion about that last time.

Also, The "active" (a mix with RowStatus 'active' but not necessarily
linked to ifAdmin/OperStatus) was initially though to be the entries
associated to real physical US ports.

The row Status was intended for Clonning process, 
as we know RFC 2670 did not have RowStatus; and for "active", now
RowStatus may have ramifications with RowStatus values not really
defined, like 'notReady' and the connotations of ifAdminStatus,
ifOperStatus that are the currently used, 

To avoid that, I would think that RowStatus object is not instantiated
for "real" mapped entries by ifIndex.
Leaving ifAdminStatus the complete activation/de-activation of entries.
Or 'always' report 'active' regardless of the IfOperStatus, Would be
good to clear that.

The clonning entry, will be the simulation bench to tuning the values,
Will explode the Whole range of RowStatus
'notReady' After creation will indicates the US Channel/Mod profile
setup is not right.
'notInService' all parameters are consistent and can be turn via Update
object to the cloned interface.

Also one thing that could be sticky 
"CloneFrom" object is the pointer to later transfer the values. Alas
"CopyTo"

I may be wrong but just by name references when CloneFrom is set, (as a
clonning process) will copy values of pointed entry to created entry, 

Currently CloneFrom object does not say that. But I believe it does not
limit implementers to think on that,

Just to make sure the object does always the same think

A) Clonning process semantics 
- after createAndWait the first object to set is CloneFrom (copy
parameters into clonning entry)
   - It Might be clarified in the object -
- Adjust objects values
- Set update object to 'true' will success if:  
     before set, RowStatus was 'notInService', 
     and no other error condition is raised by CMTS for the set 

B) Copy Process (CopyTo)
- After createAndWait set arbitrary objects , setting object CloneFrom
does NOT transfer 
  parameters from pointed entry to created entry
- Set update object to 'true' will success if:  
     before set, RowStatus was 'notInService', 
     and no other error condition is raised by CMTS for the set

Being specific will clear a little bit the process in the user/system
thinking doing B) - CMTS does A) - and loosing previous sets if object
"CloneFrom" is set after some others. 

A) is User friendly ( few Sets)
B) is autonomous system efficient, -algorithms always calculates all
'optimal' parameters, so might not need to initialize previous setups
but should be aware of setting first 

For the object Name ( something we might not want to change at this
state) I believe A) is the precisely even though I would prefer 1 but
the correct name should be "CopyTo"

Summary of possible edits:

No RowStatus for 'real' ifIndex associated entries
Explicitly say cloneFrom update values in  created entry from pointed
entry

Let me know any comments

 Eduardo

-----Original Message-----
From: Dan Rice @ Stargus 
Sent: Friday, October 10, 2003 8:17 AM
To: Eduardo Cardona; Greg White; Minnie Lu; [email-masked]
Cc: DOCSIS OSS Majordomo List; [email-masked]; [email-masked];
[email-masked]; 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)

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]] 
Sent: Thursday, October 09, 2003 8:37 PM
To: Greg White; Minnie Lu; [email-masked]
Cc: DOCSIS OSS Majordomo List; [email-masked]; [email-masked];

Eduardo

-----Original Message-----
From: Greg White 
Sent: Thursday, October 09, 2003 4:31 PM
To: Eduardo Cardona; 'Minnie Lu'; [email-masked]'
Cc: DOCSIS OSS Majordomo List; [email-masked]';

-Greg

-----Original Message-----
From: Eduardo Cardona 
Sent: Thursday, October 09, 2003 1:38 PM
To: 'Minnie Lu'; [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];

Hi David, Minnie, 

Eduardo

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Thursday, October 09, 2003 12:25 PM
To: [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];

Hi, David,

Just some more thoughts.

Thanks a lot !
Minnie

2.0 

2.0 

Majordomo

---

From: "Greg White" <[email-masked]>
Date: Fri, 10 Oct 2003 10:47:32 -0600

3 comments in-line.

-----Original Message-----
From: Eduardo Cardona 
Sent: Friday, October 10, 2003 9:33 AM
To: Dan Rice @ Stargus; Greg White; Minnie Lu; [email-masked]
Cc: DOCSIS OSS Majordomo List; [email-masked]; [email-masked];

Dan, 

<GW>  I have always been uncomfortable with the descriptions referring
to SCDMA only.  I don't see any real benefit for the vendor in only
supporting this feature for rows that have a channel type of SCDMA, and
even if they did, how would they handle changes to/from SCDMA mode?  I
would very much be in favor of cleaning up those definitions to remove
the references to SCDMA and the text making support optional for
non-SCDMA rows.

<GW> Isn't the description text for UpChannelStatus clear enough on
this? 

<GW>  I agree, I was surprised to see that there is no mention of what
operation takes place upon setting CloneFrom.  The name certainly
implies (and was the intention I believe) that setting CloneFrom copied
all of the entries from the referenced 'active' row, which implies that
it is the first object to set after row creation.  I'd rather clean up
the description to match that intent, rather than change the object to
'CopyTo'.  I don't think 'CopyTo' would really be more efficient than
'CloneFrom' for an automated NMS.  The only efficiency lost would be
having the CMTS copy 60-odd bytes from one memory location to another
only to potentially have them overwritten by the NMS.  If these
operations were happening on millisecond timescales I would be
concerned, but this is more like a once-a-day, once-a-month, once-a-year
type operation.  Let's keep the changes simple and just update the
description to match the object name and the original intent.

B) Copy Process (CopyTo)

Let me know any comments

 Eduardo

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]] 
Sent: Thursday, October 09, 2003 8:37 PM
To: Greg White; Minnie Lu; [email-masked]
Cc: DOCSIS OSS Majordomo List; [email-masked]; [email-masked];

Eduardo

-----Original Message-----
From: Greg White 
Sent: Thursday, October 09, 2003 4:31 PM
To: Eduardo Cardona; 'Minnie Lu'; [email-masked]'
Cc: DOCSIS OSS Majordomo List; [email-masked]';

-Greg

-----Original Message-----
From: Eduardo Cardona 
Sent: Thursday, October 09, 2003 1:38 PM
To: 'Minnie Lu'; [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];

Hi David, Minnie, 

Eduardo

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Thursday, October 09, 2003 12:25 PM
To: [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];

Hi, David,

Just some more thoughts.

Thanks a lot !
Minnie

2.0 

2.0 

Majordomo

---

From: "Greg White" <[email-masked]>
Date: Fri, 10 Oct 2003 10:56:13 -0600

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: Greg White [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 7:20 PM
To: Minnie Lu
Cc: [email-masked]; DOCSIS OSS Majordomo List;

-Greg

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 3:09 PM
To: Greg White
Cc: Minnie Lu; [email-masked]; DOCSIS OSS Majordomo List;

Hi, Greg,

that share a

Thanks a lot !
Minnie

issue
think
there
specification?
made
the
profile
be
clarified,
to
consistency
profile
tdmaAndAtdma,
correct
modulation
for
could
of
Majordomo
Among
1,3,4,5,6,9,10,
having
for

---

From: "Dan Rice" <[email-masked]>
Date: Fri, 10 Oct 2003 13:26:40 -0400

-----Original Message-----
From: Greg White [mailto:[email-masked]] 
Sent: Friday, October 10, 2003 12:56 PM
To: Dan Rice; Minnie Lu
Cc: [email-masked]; DOCSIS OSS Majordomo List;

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: Greg White [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 7:20 PM
To: Minnie Lu
Cc: [email-masked]; DOCSIS OSS Majordomo List;

-Greg

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 3:09 PM
To: Greg White
Cc: Minnie Lu; [email-masked]; DOCSIS OSS Majordomo List;

Hi, Greg,

that share a

Thanks a lot !
Minnie

issue
think
there
specification?
made
the
profile
be
clarified,
to
consistency
profile
tdmaAndAtdma,
correct
modulation
for
could
of
Majordomo
Among
1,3,4,5,6,9,10,
having
for

---

From: "Dan Rice" <[email-masked]>
Date: Fri, 10 Oct 2003 13:46:50 -0400

Agreements and my preferences below

-----Original Message-----
From: Greg White [mailto:[email-masked]] 
Sent: Friday, October 10, 2003 12:48 PM
To: Eduardo Cardona; Dan Rice; Minnie Lu; [email-masked]
Cc: DOCSIS OSS Majordomo List; [email-masked]; [email-masked];

3 comments in-line.

-----Original Message-----
From: Eduardo Cardona 
Sent: Friday, October 10, 2003 9:33 AM
To: Dan Rice @ Stargus; Greg White; Minnie Lu; [email-masked]
Cc: DOCSIS OSS Majordomo List; [email-masked]; [email-masked];

Dan, 

[DJR] Great this was issue 6, may need an ecr also?

<GW> Isn't the description text for UpChannelStatus clear enough on
this? 
[DJR] I believe this was clear.

[DJR] I am not sure that this entry is super useful for most
applications besides experimenting in the lab.  I think if this entry
just identified the active row you would be changing as opposed to
creating a template for one to tweak that would be more effective. I
think a management system would first create a new mod profile, then
create a clone row including all relevant entries from upstream channel
table, enter the upstream index it is intended to change and then commit
it with UpChannelUpdate assuming all columns in the upstream channel
would be applied in a single commit.  I think it is a little waste of
time to copy the current values when you are going to overwrite them all
anyway.  In addition it makes this 3 transactions instead of 2.  I could
live with it, but not sure I need it

B) Copy Process (CopyTo)

Let me know any comments

 Eduardo

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]] 
Sent: Thursday, October 09, 2003 8:37 PM
To: Greg White; Minnie Lu; [email-masked]
Cc: DOCSIS OSS Majordomo List; [email-masked]; [email-masked];

Eduardo

-----Original Message-----
From: Greg White 
Sent: Thursday, October 09, 2003 4:31 PM
To: Eduardo Cardona; 'Minnie Lu'; [email-masked]'
Cc: DOCSIS OSS Majordomo List; [email-masked]';

-Greg

-----Original Message-----
From: Eduardo Cardona 
Sent: Thursday, October 09, 2003 1:38 PM
To: 'Minnie Lu'; [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];

Hi David, Minnie, 

Eduardo

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Thursday, October 09, 2003 12:25 PM
To: [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];

Hi, David,

Just some more thoughts.

Thanks a lot !
Minnie

2.0 

2.0 

Majordomo

---

From: "Eduardo Cardona" <[email-masked]>
Date: Fri, 10 Oct 2003 12:21:39 -0600

Greg, 

some comments

In my email, my conclusions were

No RowStatus for 'real' ifIndex associated entries (see below)

Explicitly say cloneFrom update values in  created entry from pointed
entry
 -> Agree with you to Clean the CloneFrom Definition, as "cloning :
transfer values from active to cloned" 
    Not changing current "cloneFrom object.
    
    from Dan's comments, that's the Mngmt system approach
(deterministic) 
    The cloneFrom is more as you said experiments, lab testing, vendor
testing, ( human friendly, if a,b,c 
    needs to be replaced for a,b1,c, then update only b1)
    Mngmt systems should imply that first object to set is CloneFrom
Implicitly. And Dan is comfortable with that, other vendors might chime
on that. 

Edo wrote:

RowStatus Says 

             The following restrictions apply to this object:
             1) This object must contain a value of active(1) for
                active rows.

"active rows" is in-service? In other words ifOperStatus = 'up'? Or
non-cloning rows? ifOperstatus = any value- (all ifindex associated
UpChannel)
Specially active(1) for active rows, is a loos definition I believe.

What I was looking at  was to separate in clear  any possible dependency
of ifOperStatus 
I will think 'real' regardless of the ifOperStatus, 
I believe would make sense to set the "Update" object and reject the set
regardless if the interface is up/down (CMTS rules based on templates of
UpCh/Prof capabilities) that way if set 'up' later it won't fail start
again

Text could be clarify as :  
docsIfUpChannelStatus 
.....
             The following restrictions apply to this object:
             1) This object must contain a value of active(1) for
                active rows regardless of its ifOperStatus.
 
Implementers will understand that there is no link in a UPChannel
'active' row with the current operational status 
Cloned entries ( not associated with ifIndex value ) have no
ifOperStatus.
Will imply all verifications are done regardless of the up/down state of
the interface.

-----Original Message-----
From: Greg White [mailto:[email-masked]] 
Sent: Friday, October 10, 2003 12:48 PM
To: Eduardo Cardona; Dan Rice; Minnie Lu; [email-masked]
Cc: DOCSIS OSS Majordomo List; [email-masked]; [email-masked];

3 comments in-line.

-----Original Message-----
From: Eduardo Cardona 
Sent: Friday, October 10, 2003 9:33 AM
To: Dan Rice @ Stargus; Greg White; Minnie Lu; [email-masked]
Cc: DOCSIS OSS Majordomo List; [email-masked]; [email-masked];

Dan, 

To avoid that, I would think that RowStatus object is not instantiated
for "real" mapped entries by ifIndex. Leaving ifAdminStatus the complete
activation/de-activation of entries. Or 'always' report 'active'
regardless of the IfOperStatus, Would be good to clear that.

The clonning entry, will be the simulation bench to tuning the values,
Will explode the Whole range of RowStatus 'notReady' After creation will
indicates the US Channel/Mod profile setup is not right. 'notInService'
all parameters are consistent and can be turn via Update object to the
cloned interface.

B) Copy Process (CopyTo)

Let me know any comments

 Eduardo

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]] 
Sent: Thursday, October 09, 2003 8:37 PM
To: Greg White; Minnie Lu; [email-masked]
Cc: DOCSIS OSS Majordomo List; [email-masked]; [email-masked];

Eduardo

-----Original Message-----
From: Greg White 
Sent: Thursday, October 09, 2003 4:31 PM
To: Eduardo Cardona; 'Minnie Lu'; [email-masked]'
Cc: DOCSIS OSS Majordomo List; [email-masked]';

-Greg

-----Original Message-----
From: Eduardo Cardona 
Sent: Thursday, October 09, 2003 1:38 PM
To: 'Minnie Lu'; [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];

Hi David, Minnie, 

Eduardo

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Thursday, October 09, 2003 12:25 PM
To: [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];

Hi, David,

Just some more thoughts.

Thanks a lot !
Minnie

2.0 

2.0 

Majordomo

---

From: "Greg White" <[email-masked]>
Date: Fri, 10 Oct 2003 14:02:22 -0600

Regarding UpChannelStatus for 'active' rows, there is also the following
statement:

                  4) A status transition from active (1) to destroy (6)
is 
                     not permitted. Entries with docsIfUpChannelStatus
set 
                     to active(1) are logically linked to a physical 
                     interface, not temporarily created to clone
parameters. 
                     The Interface MIB [RFC2863] ifAdminStatus should be

                     used to take an Upstream Channel offline. 

That is what I was referring to. Perhaps it could be improved to say "A
status transition from active(1) to notInService(2) or destroy(6) is not
permitted."

I agree that "... must contain a value of active(1) for active rows." is
not a very good, and is probably a circular, definition.

-Greg

-----Original Message-----
From: Eduardo Cardona 
Sent: Friday, October 10, 2003 12:22 PM
To: Dan Rice @ Stargus; Greg White; Minnie Lu; [email-masked]
Cc: DOCSIS OSS Majordomo List; [email-masked]; [email-masked];

Greg, 

some comments

Explicitly say cloneFrom update values in  created entry from pointed
entry  -> Agree with you to Clean the CloneFrom Definition, as "cloning
: transfer values from active to cloned" 
    Not changing current "cloneFrom object.

Edo wrote:

RowStatus Says 

"active rows" is in-service? In other words ifOperStatus = 'up'? Or
non-cloning rows? ifOperstatus = any value- (all ifindex associated
UpChannel) Specially active(1) for active rows, is a loos definition I
believe.

 
Implementers will understand that there is no link in a UPChannel
'active' row with the current operational status 
Cloned entries ( not associated with ifIndex value ) have no
ifOperStatus. Will imply all verifications are done regardless of the
up/down state of the interface.

-----Original Message-----
From: Greg White [mailto:[email-masked]] 
Sent: Friday, October 10, 2003 12:48 PM
To: Eduardo Cardona; Dan Rice; Minnie Lu; [email-masked]
Cc: DOCSIS OSS Majordomo List; [email-masked]; [email-masked];

3 comments in-line.

-----Original Message-----
From: Eduardo Cardona 
Sent: Friday, October 10, 2003 9:33 AM
To: Dan Rice @ Stargus; Greg White; Minnie Lu; [email-masked]
Cc: DOCSIS OSS Majordomo List; [email-masked]; [email-masked];

Dan, 

B) Copy Process (CopyTo)

Let me know any comments

 Eduardo

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]] 
Sent: Thursday, October 09, 2003 8:37 PM
To: Greg White; Minnie Lu; [email-masked]
Cc: DOCSIS OSS Majordomo List; [email-masked]; [email-masked];

Eduardo

-----Original Message-----
From: Greg White 
Sent: Thursday, October 09, 2003 4:31 PM
To: Eduardo Cardona; 'Minnie Lu'; [email-masked]'
Cc: DOCSIS OSS Majordomo List; [email-masked]';

-Greg

-----Original Message-----
From: Eduardo Cardona 
Sent: Thursday, October 09, 2003 1:38 PM
To: 'Minnie Lu'; [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];

Hi David, Minnie, 

Eduardo

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Thursday, October 09, 2003 12:25 PM
To: [email-masked]
Cc: Greg White; DOCSIS OSS Majordomo List; [email-masked];

Hi, David,

Just some more thoughts.

Thanks a lot !
Minnie

2.0 

2.0 

Majordomo

---

From: "Dan Rice" <[email-masked]>
Date: Fri, 10 Oct 2003 16:31:39 -0400

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?

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

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

opposed.
from
to
> > > I found it made the code far simpler to lead the user down the
path
profile
and
the
> > > >docsIfUpChannelCloneFrom mechanism to change the channel type.
I'd
that
> > >upstream channel type would be changed automatically, too ?  If
yes,
>I
two
being
> > >by some upstream channels, could the modulation profile channel
type
> > > > the data in the modulation profiles and the upstream channels
far
same
modulation
e-mail
> > > >between Alberto and Steve from almost a year ago would be
invalid,
>no
TLV
>5
assigned
channel.
could
profile
liking
> > > > >sure the benefits of flexibility outweigh disadvantages..."
line
modulation
atdma
the
to
the
the
instance,
of

---

From: Minnie Lu <[email-masked]>
Date: Fri, 10 Oct 2003 11:24:42 -0700

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.)

modulation profile is in use by one or more upstream channels, it MUST NOT 

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

Thanks!
Minnie

---

From: Minnie Lu <[email-masked]>
Date: Fri, 10 Oct 2003 15:32:44 -0700

Hi, Dan,

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

>as long as I don't change the docsIfCmtsModChannelType, can you please

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

>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