RE: WG last call reminder

Mary,

--On 25.02.2005 18:03 h +0100 Mary Barnes wrote:

> Juergen,
>
> The proposed changes look fine.

Thanks.

We will commit the changes (and a few more nits we found) and
post the new version as soon as the I-D repository opens after
the Minneapolis meeting.

Thanks,

    Juergen
-- 
Juergen Quittek        [email protected]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

> Thanks,
> Mary
>
>
> -----Original Message-----
> From: Juergen Quittek [mailto:[email protected]]
> Sent: Thursday, February 24, 2005 10:05 AM
> To: Barnes, Mary [NGC:B601:EXCH]; [email protected]
> Cc: [email protected]; [email protected]; [email protected]
> Subject: RE: [midcom] WG last call reminder
>
>
> Hi Mary,
>
> thank you very much for the comments.
> Please find replies inline.
>
> --On 15.02.2005 20:17 h +0100 Mary Barnes wrote:
>
>> I've reviewed the MIB and have the following comments, primarily NITs, there's only a couple minor point that likely require any discussion at all, so I'll list those first, then list the NITs.  I did not run it through any of the compilation tools;
>
>> I'm assuming you all have done that and of course, I'm not a mibologist, so I focused primarily on the earlier sections.  If the doc has been reviewed by a MIB doctor and its gotten their approval from that perspective, I would say it's ready to go!
>
>>
>> Comments:
>> --------
>> - Page 22, section 5.3.1, 1st para under the bulleted list.  I don't understand what this sentence is trying to say, beyond the obvious that implementing the MIB is optional in NATs and firewalls or should this be "may not support"?:
>
>>
>> "  MIDCOM MIB does not mandate a middlebox to implement MIB modules for
>>    the functions, such as firewall and NAT, the middlebox may support."
>
> What about the following replacement:
>
> "  MIDCOM MIB does not require a middlebox to implement further specific MIB modules for
>    supported middlebox functions, such as, for example, the NAT MIB module [RFCXXYY]."
>
>> - Page 25, section 6, 2nd sentence: "This section gives recommendation for securely configuring the SNMP agent acting as MIDCOM server.", "recommendation" should be plural and I'm not sure why the term "MIDCOM server" is being introduced here, as this
>
>> term is not introduced in section 3.1.  Shouldn't this be "MIDCOM Middlebox"?  Now, I can see that this term is used throughout the MIB itself.  So, perhaps you need to state somewhere in section 3.1 that the term "MIDCOM server" is used to refer to a
>
>> MIDCOM Middlebox which has been configured with an SNMP Agent.
>
> recommendation+s:  Fixed.
> MIDCOM server:     Fixed in Section 3.1.
>
>> - Page 27, section 6.4: suggests that precautions SHOULD be taken for avoiding conflicts concerning simultaneous access and allocation of group and rule indices, but there's no recommendation as to SNMP mechanisms or other suggested mechanisms to avoid
>
>> the conflicts.  I would think there should be a minimum recommendation of a mechanism to implement to avoid the conflicts, examples or a list of possibilities.
>
> OLD:
>
> 6.4.  Simultaneous Access
>
>    If two MIDOCM clients use the same SNMP user ID for accessing the
>    same middlebox, then precautions SHOULD be taken for avoiding
>    conflicts concerning:
>          - simultaneous access to the same rule, where at least one
>            client writes managed objects
>          - allocation of group and rule indices.
>
> NEW:
>
> 6.4.  Simultaneous Access
>
>    Situations with two MIDOCM clients simultaneously modifying the
>    same policy rule should be avoided.  For each entry in the midcomRuleTable
>    there should be only one client at a time that modifies it.
>    If two MIDCOM clients share the same midcomRuleOwner index of the
>    midcomRuleTable, then conflicts can be avoided, for example, by
>        - scheduling access times, as for example in the fail-over case,
>        - using different midcomGroupIndex values per client, or
>        - using non overlapping intervals for values of the midcomRuleIndex
>          per client.
>
>> - Page 64, MidcomConfigFirewallEntry:  There's still a comment for Wes in there, and it appears that this entry is incomplete.
>
> Removed the comment.
> Wes confirmed that the current version is OK.
>
>> Editorial nits:
>> ---------------
>
> We fixed all nits.
>
> Thanks,
>
>     Martin and Juergen
> --
> Juergen Quittek        [email protected]       Tel: +49 6221 90511-15
> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de
>
>
>> - Page 1: Copyright year needs revision (same with the Full Copyright statement at the end).
>>
>> - Page 5, section 3, 4th para: "effected" (n.) should be "affected" (v.)
>>
>> - Page 6, section 4.1, 2nd para: "MIDOCM" typo
>>
>> - Page 8, section 4.2.2, 2nd para: "...SNMP transaction indicate..." should be "...SNMP transactions indicate..."
>>
>> - Page 11, section 4.2.4.: "However, this sections shows..." should be "However, this section shows..."
>>
>> - Page 12, section 4.2.4.1, 2nd para: "MIDOCM" typo
>>
>> - Page 12, section 4.2.4.2, 2nd para: "....this actions is atomic..." should be "....this action is atomic..." OR "...these actions are atomic..."
>
>>
>> - Page 12, section 4.2.4.2, 3rd para: "...are, acceptable,..." should be "...are acceptable..."
>>
>> - Page 13, section 4.2.4.4:  "...single SNMP notifications message..." should be "...single SNMP notification message..."
>
>>
>> - Page 14, section 4.3, 5th para:  "These are enforces when..." should be "These are enforced when..."
>>
>> - Page 15, section 5, 1st para: Capatilize "the" in the first sentence.
>>
>> - Page 19, section 5.2, 2nd para: "...rules in used firewall implementations." should be " ...rules used in firewall implementations."
>
>>
>> - Page 23, section 5.3.1, 3rd from the last para: "effected" (n.) should be "affected" (v.)
>>
>> - Page 23, section 5.3.1, 2nd from the last para, last sentence:
>> "  MIDCOM MIB implementations must take about overruling filter rule
>>    sets and ensure that only desired filer behavior will be achieved." would perhaps read more clearly as:
>> "  MIDCOM MIB implementations must take into consideration overruling of filter rule
>>    sets and ensure that only desired filter behavior will be achieved."
>>
>> - Page 25, section 5.4, 2nd para: "MDICOM-MIB" typo
>>
>> - Page 25, section 5.4, 2nd bullet: superfluous sentence fragment can be removed:  "of the MIDCOM client"
>>
>> - Page 26, section 6.2, 2nd para: "controling" should be "controlling".
>>
>> - Page 27, section 6.3, 3rd para: "...and individual entry..." should be "...an individual entry..."
>>
>> - Page 31, section 7.4, step 6: a reference to section 7.3 would be useful here.
>>
>> - Page 32, section 7.5, step 6: "midcoSolicitedRuleEvent" should be "midcomSolicitedRuleEvent"
>>
>> - Page 32, section 7.6, step 4: a reference to section 7.3 would be useful here.
>>
>> - Page 34, section 8.: "...how MIDCOM client..." should be "...how a MIDCOM client..."
>>
>> - Page 34, section 8.1, 2nd para: "In majority of cases..." should be "In the majority of cases..."
>>
>
>
>