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

Some comments: ( I missed the last meeting and latest discussions, I apologize for that)

#issue 1

a) I probably missed the DEFVAL added

Normally a configuration will try to allow access to RFI CATV (bit1) interface only ( as DS interface and US interfaces – bit 2 and 3 are not set)

My preferred DEFVAL would be DEFVAL { ‘c0000000’h }

As today ‘00000001’h is pointing to interface 32 which I do not think is part of any CM implementation

b) OK with the text, but also recognize that the object is already deprecated

Issue #2

Agree

Issue #3

in docsDevFilterLLCTable: (you mean docsDevEvReporting )

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.

Currently the specs require (for backup ) a message send as a notification and traps need to be send to local log

I see that the recommendation is to not require that, so just to confirm that our specs need to align with that

Draft 09 says:

           SYNTAX BITS {

               local(0),

               traps(1),

               syslog(2),

               localVolatile(8),

               stdInterface(9)

From early 2002 CMs (DOCSIS 1.0 ) support ( see early drafts 03 CD MIB v2 )

           SYNTAX BITS {

               localNonvolatile(0), --> local(0)

               traps(1),

               syslog(2),

               localVolatile(3)

Would it be needed a note for compatibility ?

Same kind of notes for the requirement of local /localVolatile when configured notifications and/or syslog (back to DOCSIS 1.0)

My concern is that normally those values are set through config files rather than SNMP SETs , which are going to be hard to map capabilities/behavior for provisioning systems

Issue #4

As today ( I missed the discussions)

I do not see in operations (but probably in theory) that CMs currently persist those values, because prior to registration the CM does not forward CM traffic (moot point of the tables applicability ), and if the config file comes with same entries it will fail the registration process e.g. createAndGo for an existing entries

I would say “SHOULD NOT” , (otherwise specified) , there could be options in the future to streamline the provisioning process and reduce CM unavailable time in case of a forced reboot by Management system, just not to close the door if I understand the suggestion of using “SHOULD NOT”

Thanks

Eduardo

From: Jean-Francois Mule
Sent: Monday, August 15, 2005 4:20 PM
To: ipcdn at ietf.org
Subject: [ipcdn] cable dev mib draft09 - WG consensus requested on proposedchanges

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