[midcom] RE: Last Call: 'Definitions of Managed Objects for Middlebox Communication' to Proposed Standard (draft-ietf-midcom-mib)
"Romascanu, Dan \(Dan\)" <dromasca@avaya.com> Mon, 07 August 2006 17:53 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA9Hp-0004ck-Rz; Mon, 07 Aug 2006 13:53:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA5gL-0000ZF-F0; Mon, 07 Aug 2006 10:02:13 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA4ZH-000325-8R; Mon, 07 Aug 2006 08:50:51 -0400
Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GA4Vs-0001qm-Q9; Mon, 07 Aug 2006 08:47:22 -0400
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k77CfqhU006038; Mon, 7 Aug 2006 08:41:53 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 07 Aug 2006 15:47:11 +0300
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0AFECB45@is0004avexu1.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Last Call: 'Definitions of Managed Objects for Middlebox Communication' to Proposed Standard (draft-ietf-midcom-mib)
Thread-Index: Aca3IFkphxgcN7+9QMmb2v9ih8IrXQC33a9w
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: iesg@ietf.org, ietf@ietf.org
X-Scanner: InterScan AntiVirus for Sendmail
X-Spam-Score: -2.5 (--)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
X-Mailman-Approved-At: Mon, 07 Aug 2006 13:53:09 -0400
Cc: midcom@ietf.org
Subject: [midcom] RE: Last Call: 'Definitions of Managed Objects for Middlebox Communication' to Proposed Standard (draft-ietf-midcom-mib)
X-BeenThere: midcom@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: midcom.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=subscribe>
Errors-To: midcom-bounces@ietf.org
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. ? 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' 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? 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. 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? 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. 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. 8 . There is no DEFVAL for midcomRuleFlowDirection 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. 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. > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Thursday, August 03, 2006 8:09 PM > To: IETF-Announce > Cc: midcom@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@ietf.org or ietf@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@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom
- [midcom] Last Call: 'Definitions of Managed Objec… The IESG
- [midcom] RE: Last Call: 'Definitions of Managed O… Romascanu, Dan (Dan)
- Re: [midcom] RE: Last Call: 'Definitions of Manag… Pyda Srisuresh
- RE: [midcom] RE: Last Call: 'Definitions of Manag… Pyda Srisuresh
- Re: [midcom] RE: Last Call: 'Definitions of Manag… Magnus Westerlund
- Re: [midcom] RE: Last Call: 'Definitions of Manag… Pyda Srisuresh
- Re: [midcom] RE: Last Call: 'Definitions of Manag… Juergen Quittek