Re: AD evaluation comments on draft-ietf-midcom-mib-07

Juergen Quittek wrote:
> Hi Magnus,
> 
> --On 27.07.2006 18:42 Uhr +0200 Magnus Westerlund wrote:
> 
>> Hi,
>>
>> Thanks for the quick reply. I do have some follow up below.
>> When these have been resolved please submit a new document.
>> Then I should be able to put it on IETF last call so it will
>> be ready to go to IESG when I am back from my vacation.
>>
>>
>> Juergen Quittek wrote:
>>>>
>>>> 1. midcomGroupLifetime:
>>>>
>>>> I wonder why this object is defined as providing the longest
>>>> time until something expires. Would not the MIDCOM client be
>>>> more interested in the shortest time until something in the
>>>> group expires?
>>>
>>> Groups in the MIDOCOM MIB only exist conceptually.
>>> There are no explicit group instances containing any state
>>> beyond the the state contained in members.
>>>
>>> Please see the DESCRIPTION clause of midcomGroupTable:
>>>
>>>         Entries in this table are created or removed
>>>         implicitly when entries in the midcomRuleTable are
>>>         created or removed, respectively.  A group entry
>>>         in this table only exists as long as there are
>>>         member rules of this group in the midcomRuleTable.
>>>
>>> Groups are instantiated by instantiating the first member
>>> and they are removed by removing the last remaining member.
>>> Therefore, the lifetime of the group is the maximum of all member
>>> lifetimes.
>>>
>>
>> Yes, you are correct that the groups lifetime is the maximum of
>> the included rules. However from a usability point of view it seems
>> that the minimum would be better. However if the WG thinks this is
>> fine, then I will not persist with my point of view.
> 
> When we discussed this in the WG, there was consensus that
> groups provide shortcuts to actions on all members.
> 
> We consider a group to be existent as long as there is a member.
> Hence, object midcomGroupLifetime contains the (expected) lifetime
> of the group.
> 
> I see no problem with adding another object that provides what
> you suggest, maybe called groupShortestMemberLifetime.
> But so far, the group has not seen the need for it.
> 

Okay, lets leave things as they are. I think my case is in most cases 
not relevant as it will be the MIDCOM client that has created the group 
and can easily keep track of the shortest itself. And in extreme cases 
when it doesn't have this state it can easily either retrieve it or set 
the midcomGroupLifetime to be certain that all rules in the group has 
the same lifetime.

I am fine with the other changes you propose. Please submit a new draft 
with these changes.

Thanks

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email protected]