RE: DOCSIS subscriber Management MIB: tie to diffpolicy?
"Eduardo Cardona" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
Wilson, good point, I think 3) would be ok if the time frame to not depend on the I-d publication. Also extra hints to how to integrate the policy in DOCSIS will be required (?) as a further spec work (requiring subMgt RFC as MUST ) as well as ATPs changes. It might be good to have some sort of annex or appendix in the spec to deal with DiffServ / DiffServ Mib / diffserv PolicyMib DOCSIS requirements and informational hooks. The current submgt ID could be short to accomplish that. I know seems to me that the submgmt mib is disconnected of how to implement the DiffServ Templates and the Policy Mib is the ultimate solution, based on the RO compliances of Diffserv mib, but? Did I understand your motivations? Or maybe a text draft of what you are thinking of would be a good starting point. Thanks Eduardo -----Original Message----- From: Wilson Sawyer [mailto:[email protected]] Sent: Monday, October 13, 2003 5:35 PM To: [email protected] Cc: [email protected]; [email protected] Subject: [ipcdn] DOCSIS subscriber Management MIB: tie to diffpolicy? I need some advice from the working group on tying the DOCSIS subscriber management MIB to the Diffserv Configuration MIB: > Harrie Hazewinkel wrote: > Maybe in order for a management application to retrieve the default > filter a single object is needed with syntax type 'RowPointer' that > points to the start of the filter in the DIFFSERV-MIB. For more > information look at draft-ietf-snmpconf-diffpolicy-08.txt it is a > draft for diffserv configation there we have templates for > configuration. You could even use the single table there as is. > Just briefly scanning the diffpolicy i-d, it looks kind of cool as a way to document the (DOCSIS) use of the diffserv MIB. It presents us with some trade-offs though: (1) including a reference to it would tie the publication schedule of this i-d to it. Harrie says that it's in IETF last call, so this might be acceptable. (2) replicating the information into the submgt i-d unlinks the publication schedule, but has the usual drawbacks of duplicate MIBs. (3) If omitted, it could still be referenced by the Docsis OSS spec (once published as an RFC with a real MIB root). This would lose the visibility from the submgt i-d document, though. What is the sense of the working group? - Wilson Sawyer _______________________________________________ IPCDN mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ipcdn