[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes
Eduardo,
Thanks for your response and input.
More inline.
Jean-François
Eduardo wrote:
> #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 }
That is if we were to keep the DEFVAL.
Do you have any objection to deleting the DEFVAL clause? Per the wg meeting minutes, that was the proposal. Can you clarify your preference? Note that the DEFVAL was not present in the to-be-obsoleted RFC and given the issues raised by Randy, the preference so far is no defval, add text per the meeting notes.
> As today '00000001'h is pointing to interface 32 which I do not think
> is part of any CM implementation
That is yet another reason for getting rid of it.
> b) OK with the text, but also recognize that the object is already
> deprecated
Ok, the clarification text should take the deprecation of the object into consideration.
> Issue #2
>
> Agree
ok
> Issue #3
>
>
>
> in docsDevFilterLLCTable: (you mean docsDevEvReporting )
Yes - sorry for the confusion.
Thanks for the input, I think you provide some elements of rationale behind the added text which based on Rich's email from 7/24 was not clear we had.
>
> 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
Is this requirement in section 7.4.2.3 of http://www.cablemodem.com/downloads/specs/CM-SP-OSSIv2.0-I09-050812.pdf?
Section 7.4.2.3 does establish default reporting modes based on the event priority. If this is the right text, is the requirement pretty much the translation of the "error" events row, row #4?
In not, just so that everyone can read this DOCSIS requirement, can you point to the DOCSIS spec, section number or paste the relevant txt in email?
> I see that the recommendation is to not require that, so just to
> confirm that our specs need to align with that
Ok so the point of the added text was to align the MIB object setting with the above requirement more formerly.
Note that if the text is deleted, you can still mandate the same behavior (all the text deletion does is move the MUST requirement away from the CM SNMP agent to the CM config file and sysadmins who must must make sure the 2 set commands are in the config file).
The proposed text deletion does not prohibit the DOCSIS spec and you can still have the Docsis requirements right?
Now Randy, what was your comment about? about the fact that with local(0) you have persistency? Based on the above explanation, and the fact that the DOCSIS spec pretty much makes it a MUST for CM to do that, can you elaborate on (or summarize) the issues and is there a better way to word this behavior? Or do we still prefer a deletion of the text, leaving this legacy requirement outside of the MIB?
We need to get closure on this mib module soon. Thx for everyone's help to resolve this.
> 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 ?
There does seem to be 2 distinct requests from you here:
a) ensure DOCSIS specs are inline with cd mib v2/rfc2669bis:
see above, I think we are ok there, even with the text deletion but Randy who raised the comment or Rich and Kevin should speak up.
b) providing some "compatibility" with an old version of the CD mib Internet-Draft. Is this correct?
On the latter, note that all we care about (here in IETF) is backward compatibility with RFC 2669. I'm not sure what kind of note you are looking for. Can you propose something?
> Same kind of notes for the requirement of local /localVolatile when
> configured notifications and/or syslog (back to DOCSIS 1.0)
Can we leave this out of the MIB? Based on the table 7-3, I think this is hard to do and now is not the time to add brand new text unless we can just fix the current one.
> 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
I don't understand the above issue.
> 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"
So you agree with current consensus, thanks.
>
>
> 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
_______________________________________________
IPCDN mailing list
IPCDN at ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn