RE: cable dev mib draft09 - WG consensus requested on proposed changes

Based on the lack of response to this email, I presume the answer to issue #4 is MUST NOT. That is, "docsDevFilterLLCTable" and most other tables MUST NOT persist their table entries. I am comfortable with that approach, since I believe that is how DOCSIS cable modems implement these tables at the current time, and how most operators expect their cable modems to behave.
 
I am going to attempt to post an official -10 draft by this Friday October 7, based on the CD MIB draft changes recommended below. It is a month later than I originally expected. :^(
 
But hopefully there is time to review, and if necessary, post a "final" draft version before the Monday October 24 deadline before the Vancouver IETF.
 
-- Rich

	-----Original Message-----
	From: Jean-Francois Mule [mailto:[email protected]] 
	Sent: Monday, September 05, 2005 1:35 PM
	To: Nakanishi Greg-MGI8179; [email protected]
	Cc: Woundy, Richard; Marez Kevin-MGI1375
	Subject: RE: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes
	
	

	Thanks Greg for reviewing the proposed changes. 

	3 weeks have passed since August 15: we have reached WG consensus on the proposed changes.

	 

	One comment was received from Greg on issue #4, to consider the stronger 'MUST NOT' rather than 'SHOULD NOT'. I personally prefer SHOULD NOT as it is already quite strong of a requirement and it allows a device to remain complaint if the implementer has a good reason not to implement the MUST NOT.

	Rich, Kevin, others - any preference? 

	if noone else responds by September 9, 9am ET, I propose we go with Greg's preference: MUST NOT.

	 

	Jean-François

	IPCDN co-chair

	 

	
________________________________


	From: Nakanishi Greg-MGI8179 [mailto:[email protected]] 
	Sent: Thursday, September 01, 2005 10:44 AM
	To: Jean-Francois Mule; [email protected]
	Subject: RE: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes

	 

	I concur with the proposed resolution.

	 

	For Issue 4, my preference is that 'MUST NOT' be used, rather than 'SHOULD NOT'.  I think a device will run into operational problems if it maintains these table entries across reboots.  When the device reboots, the config log will attempt to create rows in these tables and will fail if the rows already exists.

	 

	greg

	 

	
________________________________


	From: [email protected] [mailto:[email protected]] On Behalf Of Jean-Francois Mule
	Sent: Monday, August 15, 2005 3:20 PM
	To: [email protected]
	Subject: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes

	Folks,

	   As you may have read in meeting notes from last week, we spent the IETF 63 meeting discussing the closure of open issues on the CD mib v2.

	   The meeting notes proposed some changes to get final (yes, final) closure on this mib.

	Please review the text below and please speak up if you have some concerns (it's also welcome that you express your agreement).

	Thanks,

	Jean-François

	[extract from ipcdn minutes]

	3.1/ DOCSIS Cable Device MIB version 2

	     draft-ietf-ipcdn-device-mibv2-09.txt

	     Editors: Kevin Marez & Rich Woundy

	http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt

	We spent most of the meeting reviewing the 4 top remaining issues, see

	summary sent by Rich and Kevin in:

	http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html

	 

	+ ISSUE #1: DEFVAL for docsDevNmAccessInterfaces 

	Raised by Randy, the issue is, in the defval we have a 4 octet value

	=> How can systems with interfaces in a number not multiple

	of 8 interpret the DEFVAL value. Are bits ignored?

	Randy commented that he would be ok if there was some mention like

	'octets containing bits corresponding to non-existent interfaces are

	ignored.' That said, if there are implementations that would reject a

	SET, then we need to say something about that.

	Rich commented that the DEFVAL was added due to prior MIB doctor

	comment and that the object is now deprecated. Bert asked whether

	there was any concern deleting the DEFVAL.

	Proposal for wg review:

	 a) in docsDevNmAccessInterfaces, delete DEFVAL { '00000001'h }

	 b) consider the following (NICE TO HAVE kind of fix)

	    adding a sentence to say something like:

	    bits set corresponding to non-existing interfaces is

	    implementation specific (to warn the mgmt admin/apps that no

	    assumptions should be made on existing implementations of this

	    object. (Randy's suggestion)

	 

	+ ISSUE #2: docsDevNmAccessStatus

	-- Also, we should change the DESCRIPTION of docsDevCpeStatus

	-- and docsDevCpeInetRowStatus to document how the agent adds rows.

	See issue raised by Randy and the email summary provided by Rich for

	the context around this issue #2.

	We had some discussions around the persistency of those tables, the

	fact that the CM config file drives the row creation at boot-up and

	the fact that they are read-create tables so admins can also create

	entries as Bert pointed out.

	In most cases (except for docsDevEvControlTable), entries do not

	persist across CM reboots. Even in the case of docsDevEvControlTable,

	after some discussion, we believe that the entries are cleared and

	"recreated" after the CM reads the config file. That is the common

	understanding.

	Bert said: add a statement ("this is a deprecated table, this is

	vendor specific as to what vendors do with this table, mgmt app cannot

	expect a certain behavior").

	+ ISSUE #3: docsDevEvReporting and local(0) rows

	Comment close: ID authors agree with Randy's comment re: local(0) rows

	MUST persist. Text will be revised.

	in docsDevFilterLLCTable:

	             Any attempt to SET the traps(1) or syslog(2) bits

	             without setting the local(0) or localVolatile(8)

	             bits MUST result in an error being generated.

	Proposal:

	   DELETE above text if nobody complains after reading the meeting

	   notes

	+ ISSUE #4: docsDevFilterLLCTable 

	Issue is around text for the level of requirements on table

	persistence. Agree with Rich's text proposal:

	  |"Table entries MUST NOT persist across reboots for cable modems."

	Rich also proposed to apply this requirement to:

	  NmAccess, FilterLLC, FilterIp, Policy, Tos,

	  Cpe and InetCpe tables.

	It was suggested to use SHOULD NOT rather than MUST NOT but other than

	that, proposal is ok.

	 

	+ Other items on CD Device MIB:

	Randy added for consideration:

	wherever we have this "must not persist" langage in table definitions,

	it would be a plus to indicate that they may come back as entries may

	reappear when CM reboots and comes up with config file. Or consider

	adding this in the front paper as a consideration for users of the

	MIBs if that is too many little edits in the MIB objects.

	Proposal:

	  add a note on persistence model explaining the persistance of some

	mib objects and the CM re-creating them upon config file reloading.

	A comment was made that in general, we should indicate the persistency

	model in each object rather than in the compliance section.

	Bert also commented on the compliance sections: if different

	requirements apply to CM and CMTS, suggestion is to make 2 different

	compliances. Rich added that the new compliance statement is designed

	like that.

	# AI: [authors: Kevin Marez & Rich Woundy]

	# Authors to summarize list of agreed changed and the technical

	# changes in the text per wg consensus and issue new draft after AD

	# review comments are in. 

	# Due by early September?

	# AD review by Bert due by August 15

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