RE: [MIB-DOCTORS] IETF Ops Area interested in context-aware approach?

[added David Levi]

I do not understand you.
contextName is ONE of the paramters as input to the
  isAccessAllowed ASI which is the interface to VACM.
See the figure in sect 3.1. on page 8 of RFC315.

Bert

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] 
> Sent: donderdag 22 februari 2007 17:01
> To: Wijnen, Bert (Bert)
> Cc: mib-doctors@ietf.org; Romascanu, Dan ((Dan)); 
> david.kessens@nokia.com
> Subject: Re: [MIB-DOCTORS] IETF Ops Area interested in 
> context-aware approach?
> 
> 
> 	Because it is not granular enough. Using the VACM 
> allows you to be more precise about which (disjoint perhaps) 
> pieces of the tree can be accessed by a particular context. 
> So what you really need is a combination of contextName + VACM access.
> 
> 	--Tom
> 
> 
> > IF you want to use contextNames for multiple instntiations of a MIB 
> > module, then pls explain to me why the standardized 
> approach specified 
> > in the SNMPv3 RFCs is not sufficient or not working?
> >
> > Bert
> >
> >> -----Original Message-----
> >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> >> Sent: donderdag 22 februari 2007 16:01
> >> To: mib-doctors@ietf.org; Romascanu, Dan ((Dan)); 
> >> david.kessens@nokia.com
> >> Subject: [MIB-DOCTORS] IETF Ops Area interested in context-aware 
> >> approach?
> >>
> >>
> >> [CC: list pruned to ADs and MIB doctor list]
> >>
> >> 	In the meantime, is the IETF's ops area interested in 
> producing a 
> >> document (perhaps informational) on how one can do 
> multiple-contexts 
> >> using the existing VACM?  Cisco has deployed/patented a technology 
> >> whereby we can do per-context addressing down to the 
> object/instance 
> >> level using only the standard VACM and v2c/v3 security 
> features. If 
> >> you guys think this would be useful for the IETF, I believe that 
> >> Cisco would be interested in giving it to the IETF on the 
> same terms 
> >> that we did recently in IPFIX with Netflow.
> >>
> >> 	I think this would solve a lot of problems related to 
> having to hack 
> >> older MIBs to add one or more extra index values, as well as doing 
> >> this for new ones. The issue there is that one index may not be 
> >> future-proof. Recently, for instance, multi-topology routing came 
> >> out, which in effect, requires THREE indexes. Fortunately, the 
> >> approach I am referring to above doesn't rely on the MIB tables' 
> >> indexes per se to allow for per-context addressing, so we 
> were able 
> >> to use the same approach to address the now 3 levels of virtual 
> >> indexing needed. The approach I describe should work for arbitrary 
> >> indexing too, BTW.
> >>
> >> 	--Tom
> >>
> >>
> >>
> >>
> >>
> >> On Feb 22, 2007:9:36 AM, at 9:36 AM, Romascanu, Dan ((Dan)) wrote:
> >>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> >>>> Sent: Thursday, February 22, 2007 4:19 PM
> >>>> To: Romascanu, Dan (Dan)
> >>>> Cc: david.kessens@nokia.com; Vach Kompella; A Kiran Koushik S; 
> >>>> Townsley Mark; Shane Amante; Wijnen, Bert (Bert); David Levi
> >>>> Subject: Re: l2vpn mib interaction with RFC
> >>>>
> >>>>
> >>>> On Feb 22, 2007:12:56 AM, at 12:56 AM, Romascanu, Dan
> >> ((Dan)) wrote:
> >>>>
> >>>>> Tom,
> >>>>>
> >>>>> 1) I agree with the editors. What are the arguments of 
> those who 
> >>>>> suggest copying objects from one MIB module into the L2VPN
> >>>> MIB rather
> >>>>> than re-using them?
> >>>>
> >>>> 	The arguments in favor are simply that this is the most
> >> expeditious
> >>>> and easiest way of supporting many instances of VPLS bridge 
> >>>> information.
> >>>
> >>> - expeditious and easiest for whom? For the people who write the 
> >>> standard, for those who write implementations or for those
> >> who deploy?
> >>> - maybe I mis-understood you - by 'copy' you mean take the
> >> objects in
> >>> the bridge tables with their semantics and adding and index (or
> >>> more) to
> >>> multiplex among VPN instances?
> >>>
> >>>>
> >>>>> 2) As per RFC 4663 further development of the Bridge MIB
> >>>> modules was
> >>>>> transferred to the IEEE 802.1 Working Group. The IEEE WG is
> >>>> developing
> >>>>> separate MIB modules for new IEEE 802.1 protocols like
> >> IEEE 802.1ag
> >>>>> (Connectivity Fault Management  a.k.a. OAM) and is 
> extending the 
> >>>>> original Bridge MIB modules as project IEEE 802.1ap now at
> >>>> its first
> >>>>> Task Group ballot. IEEE 802.1ap is actually including
> >>>> re-indexation. I
> >>>>> would suggest that you look at what the IEEE are doing. I
> >> copy Bert
> >>>>> who is also participating in the IEEE 802.1 and David Levi
> >>>> who is the
> >>>>> editor of the MIB module in IEEE 802.1ap.
> >>>>
> >>>> 	What are the timelines for this work, and what is the plan for 
> >>>> multiple-contexts in these MIBs?
> >>>
> >>> The projected completion date for the standard is July
> >> 2008. I would
> >>> suggest that you have a look at the proposal now in TG
> >> ballot, because
> >>> what you ask for ('multiple-contexts'  may or may not be
> >> in, it is not
> >>> however a goal but rather means for something else I think.
> >>>
> >>> Dan
> >>>
> >>>
> >>>>
> >>>> 	--Tom
> >>
> >> _______________________________________________
> >> MIB-DOCTORS mailing list
> >> MIB-DOCTORS@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/mib-doctors
> >>
> 

_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www1.ietf.org/mailman/listinfo/mib-doctors