RE: Changes for next RFI v2 MIB (draft 10)

Hi Minnie, 
 
If I understand the intial Randy's comment, RFC 2119 defines MAY and OPTIONAL as "truly optional". In a general context "MAY" and "MAY NOT" becomes the same. Not being "MAY NOT" an IETF keyword, I see the MIB doctors reluctance to use it.
 
In the other hand, the reason for the default entries is a vendor feature outside the spec requirements. In the vendor side, this feature would make sense to "require" (vendor design  - not spec requirement)
 - SHOULD be read-only
 - SHOULD NOT create new Interval Usage Codes.
 
Another vendor may opt to offer default entries as "custom" entries which may be nonVolatile and adjustable or removed  as part of a factory configuration, that's why I think that shold be leve in context as informational. 
 
In spec words the optional MAY make those vendor requirements informational, in fact the ECN says the creation of IUCs "MAY result in error", which is mere informational.
 
trying to avoid the "MAY NOT"  if possible, 
 

             Initial default entries MAY be created at system 

             initialization time which could report for a value 

             'permanent' or 'readOnly' for docsIfCmtsModStorageType.

             A CMTS MAY restrict the creation of additional Interval

             Usage Codes for a modulation profile being defined at 

             Initialization time.

 
Thanks
Eduardo
 
 
 
 
 

	-----Original Message----- 
	From: Minnie Lu [mailto:[email protected]] 
	Sent: Wed 4/14/2004 5:00 PM 
	To: Eduardo Cardona 
	Cc: [email protected]; [email protected] 
	Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)
	
	

	Hi. Eduardo,
	
	Thanks for efforts to make this MIB better.
	
	 > A CMTS may not allow the creation of additional Interval Usage Codes
	 > for a modulation profile being defined at Initialization time.
	
	Does "may not" here mean "MUST NOT" or "MAY"?
	<edo>
	A bit clear saying :
	"A CMTS MAY allow...."
	</edo>
	...
	I think it is 'A CMTS MAY NOT allow ...."  In the ECN OSSIv2.0-N-04.0121,
	The CMTS MAY have pre-defined modulation profiles (entries in the DOCS-IF-MIB
	docsIfCmtsModulationTable) with the purpose of being used by
	operators as is or as templates to define other modulation profiles. CMTS
	pre-defined modulation profiles entries MAY be read-only to prevent users
	from accidental modifications. Adding or creating entries with new
	docsIfCmtsModIntervalUsageCode values and the same docsIfCmtsModIndex
	values as the pre-defined modulation profiles MAY result in error.
	
	Thanks a lot !
	Minnie
	
	At 07:25 PM 4/13/2004 -0600, Eduardo Cardona wrote:
	
	> > A CMTS may not allow the creation of additional Interval Usage Codes
	> > for a modulation profile being defined at Initialization time.
	>
	>Does "may not" here mean "MUST NOT" or "MAY"?
	><edo>
	>A bit clear saying :
	>"A CMTS MAY allow...."
	></edo>
	>...