Subject: RE: [ipcdn] RE: Changes for next RFI v2 MIB (draft 10)

From: "Eduardo Cardona" <[email-masked]>
Date: Tue, 13 Apr 2004 10:51:13 -0600

Thanks Tom, 

Will fix them

Eduardo

-----Original Message-----
From: Keske Tom-LTK002 [mailto:[email-masked]] 
Sent: Tuesday, April 13, 2004 8:32 AM
To: [email-masked]'
Subject: [ipcdn] RE: Changes for next RFI v2 MIB (draft 10)

All,

Thanks very much, Eduardo. I think that this
looks reasonable.  There is a very minor spelling 
error in a number of places, where it
has "dependant", and should say "dependent". 
 
   < Persistence of read-create entries is implementation
   < dependant.

Regards, Tom Keske

.------------------------------------------------------------.
|     Thomas R. Keske              IP Network Systems        |
|                                                            |
|     Motorola, Broadband Communications Sector              |
|     111 Locke Dr.                                          |
|     Marlborough, MA, 01752                                 |
|                                                            |
|     Tel: (508) 786-7687    Email: [email-masked]     |
`------------------------------------------------------------'
> 
> 
> > -----Original Message-----
> > From: Donati Andrew-MGIA0477
> > Sent: Tuesday, April 13, 2004 8:48 AM
> > To: Murwin William-LWM008; Patrick Michael-LZZ007; Wang 
> > Daohong-MGIA0610; Keske Tom-LTK002; Scully Brian-LBS002; Ryan 
> > Dan-LDR001; Mowry Gary-LGM005; Hamblin William-MGIA0504; 
> > Potvin Donald-MGIA0574; Liberman Alex-MGIA0537; Gulbas 
> Aysun-MGIA0497
> > Cc: Dua Anirudh-MGIA0481; Jaroug Souhail-LSJ001
> > Subject: FW: Changes for next RFI v2 MIB (draft 10)
> > 
> > 
> > All,
> > 
> > Here are proposed changes in the docs RFI MIB to review.
> > 
> > This allows us to legally designate one or more default
> > modulation profiles 
> > as "read-only" (Objects in row can neither be changed nor 
> > deleted - Not Writable) or 
> > "permanent" (Objects in row can be changed but not deleted).  
> > 
> > Note that in this document they allow 'permanent' as "need
> > not allow write-access to any columnar objects in the row."  
> > So it seems 
> > that "permanent" and "read-only" can have the same functional 
> > behavior.
> > 
> > Thanks,
> > Andy
> > 
> > -----Original Message-----
> > From: Eduardo Cardona [mailto:[email-masked]]
> > Sent: Monday, April 12, 2004 6:52 PM
> > To: Donati Andrew-MGIA0477; [email-masked]
> > Subject: Changes for next RFI v2 MIB (draft 10)
> > 
> > 
> > Hi Andrew, all,
> > 
> > Please review the attached with the proposed changes for the
> > StorageType issues to see of they cover all concerns.
> > 
> > In summary, there are eight proposed changes
> > 
> > Changes 1,2,3,4 are related to the issue brough by Andrew
> > Donati by adding StorageType object to the Modulation profile table
> > 
> > Changes 5,6,7,8 are clarifications to accommodate the OPS MIB
> > revision guidelines sections 4.6.2 and 4.6.4, quite related 
> > to the problem raised for the storageType case.
> > 
> > During the WG Last call for technical issues, there were no
> > other items pointing our attention.
> > 
> > Let the WG know any question or comments by COB Wednesday
> > before submiting the draft to IETF.
> > 
> > 
> > Eduardo
> > 
> 

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

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

---

From: "Eduardo Cardona" <[email-masked]>
Date: Wed, 14 Apr 2004 12:10:22 -0600

Thanks, 

I though it was a either StorageType support or capabilities.
I see how the combination of both StorageType and Capabilities in RFC
3434 defines all options with the advantage of a short COMPLIANCE
statement.

Although the solution work, I see more (theoretical) advantages in the
AGENT-CAPABILITIES variation if broadly adopted and implemented ( I
doubt not) to solve the problem at the class (SMI) level rather than at
the managed object level. I mean  supporting VARIATION clauses that
update dynamically the Device profile Object model and operations to
execute (expose) rather than having the management application writing
code on a MIB table basis to discover them. 

It is not fat to be a trade-off dilemma

I will try to came up with a revision of the proposed changes based on
all the feedback.

If anyone else has comments, please post the list

Eduardo     

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Wednesday, April 14, 2004 11:17 AM
To: [email-masked]
Subject: Re: [ipcdn] Changes for next RFI v2 MIB (draft 10)

Hi -

> From: "Eduardo Cardona" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, April 14, 2004 9:32 AM
> Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)

... (lots of agreement, questions to the WG, and explanations deleted)
...

>> There is no need for there to be any writeable objects in a table 
>> with a StorageType object.  One could also use a "capabilities" 
>> object outside the table to report whether this information can be 
>> retained. For an example of total over-engineering, one could have a 
>> single read-only BITS object with one bit for each of these tables, 
>> reporting whether the implementation maintains the data persistently.
> <edo1>
> Any example or I assume all new MIB designs consider the StorageType 
> by default.
>
> </edo1>
...

The work with which I am most familiar has been very explicit about
persistence, either mandating it in DESCRIPTIONs or using StorageType to
report / control it as needed.  However, using a scalar to report
capabilities, including persistance behaviour, has a long history,
especially in the rmonmib working group.  For an example chosen at
random, see "hcAlarmCapabilities" in RFC 3434.

Randy

---

From: Minnie Lu <[email-masked]>
Date: Wed, 14 Apr 2004 16:00:10 -0700

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

---

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 15 Apr 2004 04:42:20 -0600

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-masked]] 
	Sent: Wed 4/14/2004 5:00 PM 
	To: Eduardo Cardona 
	Cc: [email-masked]; [email-masked] 
	Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)

	Hi. Eduardo,

	
	
	Thanks a lot !
	Minnie

---

From: "Matthew Schmitt" <[email-masked]>
Date: Thu, 15 Apr 2004 08:42:31 -0600

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-masked]; [email-masked]
	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.

	             '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-masked]] 
		Sent: Wed 4/14/2004 5:00 PM 
		To: Eduardo Cardona 
		Cc: [email-masked]; [email-masked] 
		Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft
10)

		Hi. Eduardo,

		
		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

---

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 15 Apr 2004 09:06:58 -0600

Hi all, 

I have some questions regarding the MIB object docsIfCmRangingTimeout 

Both the RFI MIB and OSSI spec SP-OSSIv2.0-I05-040407 Annex A page 96
show docsIfCmRangingTimeout  with syntax read-write ( the only CM
read-write object in RFI MIB).

The questions are 
Is this object really need to be read-write? 
particularly if there is any management case where read-write is used.
Currently there is no Compliance statement to allow read-only access, is
that needed?

Is there any instance (in general) when the T3 timer is being adjusted
by the CM and retained in Memory after CM reboots ?, or would be ok to
explicitly not require persistence without incurring in spec changes?
(just a clarification)

I am Not planning to deprecate the object but The new revision of RF MIB
is being updated to address IETF OPS MIB revision guidelines related to
persistence and would be good to precise CM usage of the object. 

See ipcdn mailing list for current discussion about draft 10 updates 
http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/threads.h
tml

I will post OSSI DOCSIS reflector with a second revision of the changes
as well as IPCDN list soon

Thanks

Eduardo 

PD: In Annex A of OSSI spec the obsolete object above
docsIfCmRangingTimeout should be docsIfCmRangingRespTimeout. ( being
tracked to include in an Omnibus ECR)

---

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 15 Apr 2004 14:17:07 -0600

Hi Andre, 
 
I share your appreciations.
 
are there any other sort of considerations from other parties?
 
Thanks
 
Eduardo

-----Original Message-----
From: Lejeune, Andre [mailto:[email-masked]] 
Sent: Thursday, April 15, 2004 9:32 AM
To: Eduardo Cardona; [email-masked]; DOCSIS OSS Majordomo List; DOCSIS
Macup Majordomo List

I believe this object should have been defined as read-only as there is
no advantage in having it read-write. Moreover, the RFI specification,
in Annex B, defines a min and max value for it. I do not see how such a
timeout can take multiple values. There should have been a unique value
for it.

Andre 

-----Original Message----- 
From: Eduardo Cardona [mailto:[email-masked]] 
Sent: Thursday, April 15, 2004 11:07 AM 
To: [email-masked]; DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo 
List 

Hi all, 

The questions are 

that needed? 

tml 

Thanks 

Eduardo

---

From: "Lejeune, Andre" <[email-masked]>
Date: Thu, 15 Apr 2004 08:32:14 -0700

I believe this object should have been defined as read-only as there is no
advantage in having it read-write. Moreover, the RFI specification, in Annex
B, defines a min and max value for it. I do not see how such a timeout can
take multiple values. There should have been a unique value for it.

Andre

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]]
Sent: Thursday, April 15, 2004 11:07 AM
To: [email-masked]; DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo
List

Hi all, 

The questions are 

Thanks

Eduardo

---

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 26 Apr 2004 12:50:52 -0400

Andre,
 
My apologies, this email was stuck in a "potential spam" queue for IPCDN for
way too long...
 
-- Rich

-----Original Message-----
From: Lejeune, Andre [mailto:[email-masked]]
Sent: Thursday, April 15, 2004 11:32 AM
To: Eduardo Cardona; [email-masked]; DOCSIS OSS Majordomo List; DOCSIS Macup
Majordomo List

Andre 

-----Original Message----- 
From: Eduardo Cardona [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, April 15, 2004 11:07 AM 
To: [email-masked]; DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo 
List 
Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) 

Hi all, 

The questions are 

See ipcdn mailing list for current discussion about draft 10 updates 
http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/threads.h
<http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/threads.h>  
tml 

Thanks 

Eduardo