[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [midcom] RE: Last Call: 'Definitions of Managed Objects forMiddlebox Communication' to Proposed Standard (draft-ietf-midcom-mib)

Dear Dan,

We are very sorry for the late reply on your comments and on Suresh's
replies.  The reason is that we (Martin and Juergen) wanted to discuss
them and did not find time to do so until today, because of our vacation
and business trip schedules.

Please find our replies inline.

If you are fine with them, we will post a new version of the I-D.

Thanks,

  Martin and Juergen


--On 28.08.2006 8:00 Uhr +0200 Pyda Srisuresh wrote:


Dan,

Thank you for your detailed comments. Sorry for the delayed response. I was
away on vacation and just got back. Please see my responses below inline.

regards,
suresh

--- "Romascanu, Dan (Dan)" <dromasca at avaya.com> wrote:

1. Is the 'strict' SNMP terminology intentionally avoided in Section 4.2
and associated diagrams, and why? Meaning why do we say 'SNMP get
message' instead of 'SNMP GetRequest PDU', etc. ?


[suresh] The objective of section 4.2 was essentially to indicate how the
MIDCOM transactions can be mapped to SNMP. I.e., make the description of
MIDCOM transactions to SNMP mapping easy to underdtand. Terms like "SNMP get
message" and "SNMP put message" are simply easier for the reader to relate
while talking about transactions.

2. Section 5.3.1
> The MIDCOM MIB module does not require a middlebox to implement
   further specific MIB modules for supported middlebox functions, such
   as, for example, the NAT MIB module [RFC4008].

This should probably be 'further specific middlebox (NAT devices,
firewall) MIB modules'
   as, for example, the NAT MIB module [RFC4008].

[suresh] OK; with a minor tweak to your suggested text as follows.
s/"(NAT devices, firewall)"/"(NAT, Firewll)/

3. Object midcomRuleAdminStatus

>     midcomRuleAdminStatus OBJECT-TYPE
       SYNTAX      INTEGER {
                       reserve(1),
                       enable(2),
                       notSet(3)
                   }
...
 When retrieved, the object returns the last set value. If
            no value has been set, it returns one of the two possible
            values."
       DEFVAL { notSet }

I do not understand what are the 'two possible values'. What happens of
a retrieval happens before the object is set for the first time?

[suresh] Oops... Will change the text to read as follows.

When retrieved, the object returns the last set value. If
no value has been set, it returns the default value of notset(3).

4. Several DESCRIPTION clauses (e.g. midcomRuleAdminStatus,
midcomRuleStorageType) include SNMP-specific error messages when
describing the behavior of the object. This is OK, as the MIDCOM-MIB is
designed to be used with SNMP as MIDCOM protocol, yet I would include a
note on this subject because this is not customary within other MIB
documents which are written with a protocol-independent orientation.

[suresh] I will leave to Juergen or Martin to comment on this. 

We assume that you refer to error code 'inconsistentValue' that we
mention in several DESCRIPTION clauses.

We think this is still customary in recent MIB modules from where we
got the idea to use this error code.  See, for example, RFCs 4001,
4087, 4131, 4149, 4268, 4368, 4444, and 4546.

5. What happens with the object midcomRuleObjectTime when
midcomRuleObjectType is permanent(4)? The DESCRIPTION clause of the type
object suggests that time is read-only. With DEFVAL 0 this means
automatic destruction of the row at the end of the transaction. Is this
the desired behavior, or did I mis-understand something?

[suresh] Yes, I believe, that is the desired behaviour. 

This is a good catch.  We did not consider storage type 'permanent'
well when writing the DESCRIPTION clause.

If the storage time is permanent, the value should never become 0.
In this case, we suggest this object to have a permanent value of 4294967295.

We propose appending the following paragraph to the DESCRIPTION clause:

       "If object midcomRuleStorageType indicates that the policy
        rule has storage type permanent(4), then this object has
        a constant value of 4294967295."

Note, however, the DESCRIPTION for midcomRuleStorageType says that attempts to
set this object to permanent will always fail with an inconsistentValue error.
And, the default value for this object is volatile(2).


6. I do not feel comfortable with the DESCRIPTION clause of
midcomRuleError RECOMMENDing values for this object without defining
what behavior each message is supposed to cover. This type of object is
not interoperable, and this would be made clear if it was said that
these are examples rather than RECOMMENDations.

[suresh] I am OK with listing the error strings as examples, rather than as
recommendations. I will leave to Juergen or Martin to further comment on this.


The errors a re well defined in the MIDCOM protocol semantics (RFC 3989,
sections 2.3.9 and 2.3.10).
We suggest appending to the DESCRIPTION clause:

       "The semantics of these error messages and the corresponding
        behavior of the MIDCOM MIB implementation are specified
        in sections 2.3.9 and 2.3.10 of RFC 3989."

and adding a reference clause

   REFERENCE
       "RFC 3989, sections 2.3.9 and 2.3.10"

7. Another side-effect of the midcomRuleObjectType being permanent(4) is
that the permanent rules cannot be applied to interfaces, so they can be
only global. Same about transport protocol and other read-write objects.

[suresh] As I said earlier, attempts to set midcomRuleStorageType to permanent
will always fail with an inconsistentValue error.


As stated in the DESCRIPTION clause of midcomRuleStorageType, a permanent(4)
row has all write access to other objects in the row disabled.

8 . There is no DEFVAL for midcomRuleFlowDirection

[suresh] Right, that was intentional. 

We added

    DEFVAL { outbound }

as Suresh had suggested in another email.

9.
>          Valid values for midcomRuleTransportProtocol
            other than zero are defined at:
            http://www.iana.org/assignments/protocol-numbers

Does this need a new type of registry from IANA? There is nothing in the
IANA considerations about this.


[suresh] Well, nothing specific to MIDCOM MIB per se. IANA assigns IP protocol
numbers independently, right.


10. What notification needs to be sent when midcomConfigIfEnabled is set
to false? Neither the DESCRIPTION of the object nor the one of the
notifications do provide any clue.

[suresh] The DESCRIPTION for midcomConfigIfEnabled does say the following.

   Setting
   this object to false(2) immediately stops middlebox
   support at the indexed IP interface.  This implies that
   all policy rules that use NAT or firewall resources at
   the indexed IP interface are terminated immediately.
   In this case, The MIDCOM agent MUST send notifications
   to all MIDCOM clients that have access to one of the
   terminated rules.

As for the rule termination event, please refer section 7.9. 

The notifications to be sent are of type midcomUnsolicitedRuleEvent.
Suggestion: s/notifications/midcomUnsolicitedRuleEvent

Thanks,

  Martin and Juergen


regards,
suresh


> -----Original Message-----
> From: The IESG [mailto:iesg-secretary at ietf.org]
> Sent: Thursday, August 03, 2006 8:09 PM
> To: IETF-Announce
> Cc: midcom at ietf.org
> Subject: Last Call: 'Definitions of Managed Objects for
> Middlebox Communication' to Proposed Standard (draft-ietf-midcom-mib)
>
> The IESG has received a request from the Middlebox
> Communication WG to consider  the following document:
>
> - 'Definitions of Managed Objects for Middlebox Communication '
>    <draft-ietf-midcom-mib-08.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action.  Please send any
> comments to the iesg at ietf.org or ietf at ietf.org mailing lists
> by 2006-08-17.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-08.txt
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce at ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>

_______________________________________________
midcom mailing list
midcom at ietf.org
https://www1.ietf.org/mailman/listinfo/midcom




_______________________________________________
midcom mailing list
midcom at ietf.org
https://www1.ietf.org/mailman/listinfo/midcom




_______________________________________________
midcom mailing list
midcom at ietf.org
https://www1.ietf.org/mailman/listinfo/midcom