Subject: Re: [magma] draft-ietf-magma-mgmd-mib-06.txt comments

From: Brian Haberman <[email-masked]>
Date: Mon, 12 Sep 2005 11:35:40 -0400

Hi Karl,
      Sorry for taking so long to respond on these points.  Julian is out
on extended vacation and I volunteered to take over editorship as
we try to get this document to the IESG.  I have responded to your
comments in-line...

On Aug 24, 2005, at 13:43, Karl Schmidt wrote:

>
> Julian,
>
> Thanks for your changes to the MGMD MIB as the issues I brought up 
> were addressed. I have a few comments on the new MIB.
>
> 1. The mgmdHostInterfaceVersion3Robustness object should have the 
> robustness range of (1..255).

Why?  Section 9.1 of RFC 3810 does not impose such an upper limit.

>
> 2. Based on the mgmdRouterInterfaceEntry sequence, the 
> mgmdRouterInterfaceStartupQueryInterval object should be defined as { 
> mgmdRouterInterfaceEntry 18 } and the 
> mgmdRouterInterfaceStartupQueryCount object should be defined as { 
> mgmdRouterInterfaceEntry 17 }.

Sure.  That can be re-ordered to match.

>
> 3. The mgmdRouterInterfaceStartupQueryInterval should default to 1/4 
> the default query interval (31) rather than the default query interval 
> value (125).

Yes.

>
> 4. The mgmdRouterInterfaceQueryInterval and 
> mgmdRouterInterfaceStartupQueryInterval ranges must be modified to 
> start at 1 so that they are non-zero as mentioned in the description. 
> You probably should remove that statement from the description once 
> this is done as it would now be enforced syntactically.

OK.

>
> 5. The description for mgmdRouterCacheExcludeModeExpiryTimer should 
> have the word node changed to router.

OK.

>
> 6. Ths mgmdHostSrcListExpire object has no meaning and should be 
> removed as hosts don't keep source timers or keep include & exclude 
> lists simultaneously.

I will have to go back and check again, but this timer may be associated
with the multicast address timer mentioned in bullet 2 of section 6.3 in
3810.

>
> 7. The mgmdRouterSrcListExpire object description should indicate the 
> purpose of the source timer for included sources rather than 
> describing the object as just a boolean state.
>

This is another variable that I need to go back and check on.  My
hazy recollection was that this timer was meant to be used in
conjunction with the filter mode to determine whether data should
be forwarded on the record (Section 7.3 of 3810).

Regards,
Brian

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

---

From: Karl Schmidt <[email-masked]>
Date: Mon, 12 Sep 2005 12:25:31 -0500

Hi Brian,

Thanks for your response.

With regards to the range of the mgmdHostInterfaceVersion3Robustness the 
reason I thought the range should be added is to match the range of the 
mgmdRouterInterfaceRobustness. Robustness is meant to be a system wide 
concept where all routers and hosts have the same value. This effectively 
tunes the number of router or host packets that may be dropped and still 
not have the router lose it's membership state. I guess if we don't want 
mgmdHostInterfaceVersion3Robustness to have a range then 
mgmdRouterInterfaceRobustness should not have a range too. However, the 1 
- 255 range has been around since RFC 2933 and has not been an issue as 
far as I know of.

It looks like the reference to RFC 3810 for the mgmdHostSrcListExpire 
object is for the backoff timer used when responding to queries. Timer 
expiration for this value will not expire the host source but rather is 
the time before a membership report needs to be sent out for this source. 
I guess we can arguably track the state of this timer but the object 
should be renamed and similar objects would probably need to be added for 
the other timers mentioned in section 6.3. I'd recommend not tracking 
these though as they doesn't add much value for a system manager and are 
non-trival to implement.

The mgmdRouterSrcListExpire was added for 2 purposes. The first purpose 
was to track the amount of time before a source expires. The second was an 
overloaded use (that the protocol specs also uses) to determine if the 
source should be excluded or included depending on if the value is 0 or 
non-0. I just wanted the description changed a bit so that it addresses 
the first purpose.

I'd love to see this draft go to RFC soon, so please let me know if you 
need more clarification.

Regards,
Karl

Brian Haberman <[email-masked]> 
09/12/2005 10:35 AM

To
Karl Schmidt <[email-masked]>
cc
[email-masked]
Subject
Re: [magma] draft-ietf-magma-mgmd-mib-06.txt comments

Hi Karl,

Yes.

OK.

OK.

Regards,
Brian