[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ipcdn] DOCSIS subscriber Management MIB: tie to diffpolicy?



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:sawyerwd@comcast.net] 
Sent: Monday, October 13, 2003 5:35 PM
To: ipcdn@ietf.org
Cc: harrie@lisanza.net; bwijnen@lucent.com
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
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn


_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn