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

Minnie,
    Just to re-emphasize what Eduardo said, part of the problem with MAY
NOT is that the English language and spec language interpretations can
be different.  In spec parlance, MAY means something is optional,
therefore MAY NOT is exactly equivalent (from a spec perspective) to
MAY.  However, in general English language usage, MAY NOT can mean the
same thing as "you're not allowed to" aka MUST NOT.  As a result, it's
generally a very good idea to avoid usage of that term.
    Thanks.

Matt

	-----Original Message-----
	From: Eduardo Cardona 
	Sent: Thursday, April 15, 2004 4:42 AM
	To: Minnie Lu
	Cc: [email protected]; [email protected]
	Subject: RE: [ipcdn] 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>
		>...