Subject: [magma] Allowing Read-create access in MGMD MIB

From: Julian Chesterfield <[email-masked]>
Date: Thu, 03 Feb 2005 17:53:01 +0000

I'm finalising the MGMD MIB (combined IGMP and MLD MIBs) and would like 
to generate some feedback from the list regarding the need to have 
Read-create CacheStatus objects. Specifically, these objects enable 
addition and deletion of rows in the RouterCache and HostCache tables, 
effectively manipulating state in the end host or router. There is 
currently a read-create cachestatus object in the IGMPv2 (MLDv1) MIB 
(rfc2933), however it is not clearly defined how this should be used.

After some discussion with Brian Haberman and James Lingard, the general 
consensus is that the potential end system interactions are too 
complicated to allow actual row creation and deletion, although 
adjustment of certain objects within a row could be allowed. My personal 
view is that if such functionality is absoloutely required, a better 
approach might be to define an 'MGMD Sender MIB' which would allow 
creation and deletion of group membership sockets/processes on an end 
system in order to indirectly control the MGMD MIB state. Such a MIB 
could, for example, define a multicast 'ping' functionality to actually 
source traffic, or just a passive 'receive' functionality to join a 
group and specify explicit source includes or excludes etc...

Can members of the list indicate whether the read-create access is 
necessary, and if so, how it is currently handled? If read-create status 
is to be allowed on these objects, then can folks present some views on 
how the following should be managed:

- When a row is created on a host, should the host begin generating 
membership reports? How long should the state be maintained on the host 
given that there is no controlling application socket to generate or 
receive traffic.

- When a row is created on a router, assuming there are no locally 
connected hosts sending membership reports, should the router initialise 
the standard timers and delete the state once they expire, or should 
there be a special value for 'mgmdRouterCacheExpiryTime' which keeps 
state alive indefinitely?

Any feedback much appreciated, we'd like to move this MIB through to 
last call soon.

Thanks!
Julian Chesterfield

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Brian Haberman <[email-masked]>
Date: Mon, 7 Feb 2005 12:34:23 -0500

All,
      The silence is deafening.  Unless someone speaks up by
Feb. 16, I will direct Julian to change the objects mentioned
below to read-only.

Regards,
Brian

On Feb 3, 2005, at 12:53, Julian Chesterfield wrote:

> I'm finalising the MGMD MIB (combined IGMP and MLD MIBs) and would 
> like to generate some feedback from the list regarding the need to 
> have Read-create CacheStatus objects. Specifically, these objects 
> enable addition and deletion of rows in the RouterCache and HostCache 
> tables, effectively manipulating state in the end host or router. 
> There is currently a read-create cachestatus object in the IGMPv2 
> (MLDv1) MIB (rfc2933), however it is not clearly defined how this 
> should be used.
>
> After some discussion with Brian Haberman and James Lingard, the 
> general consensus is that the potential end system interactions are 
> too complicated to allow actual row creation and deletion, although 
> adjustment of certain objects within a row could be allowed. My 
> personal view is that if such functionality is absoloutely required, a 
> better approach might be to define an 'MGMD Sender MIB' which would 
> allow creation and deletion of group membership sockets/processes on 
> an end system in order to indirectly control the MGMD MIB state. Such 
> a MIB could, for example, define a multicast 'ping' functionality to 
> actually source traffic, or just a passive 'receive' functionality to 
> join a group and specify explicit source includes or excludes etc...
>
> necessary, and if so, how it is currently handled? If read-create 
> status is to be allowed on these objects, then can folks present some 
> views on how the following should be managed:
>
> membership reports? How long should the state be maintained on the 
> host given that there is no controlling application socket to generate 
> or receive traffic.
>
> connected hosts sending membership reports, should the router 
> initialise the standard timers and delete the state once they expire, 
> or should there be a special value for 'mgmdRouterCacheExpiryTime' 
> which keeps state alive indefinitely?
>