[MEXT] Review of draft-ietf-mext-nemo-mib-03.txt
Alberto García <alberto@it.uc3m.es> Mon, 01 December 2008 12:28 UTC
Return-Path: <mext-bounces@ietf.org>
X-Original-To: monami6-archive@megatron.ietf.org
Delivered-To: ietfarch-monami6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id A49A328C194;
Mon, 1 Dec 2008 04:28:20 -0800 (PST)
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 325473A63EC
for <mext@core3.amsl.com>; Mon, 1 Dec 2008 04:16:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.461
X-Spam-Level:
X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3,
RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id nobiHH6r8SQo for <mext@core3.amsl.com>;
Mon, 1 Dec 2008 04:16:43 -0800 (PST)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133])
by core3.amsl.com (Postfix) with ESMTP id E06763A6847
for <mext@ietf.org>; Mon, 1 Dec 2008 04:16:42 -0800 (PST)
Received: from bombo (bombo.it.uc3m.es [163.117.139.125])by smtp03.uc3m.es
(Postfix) with ESMTP id 0CF826AFB08;
Mon, 1 Dec 2008 13:16:35 +0100 (CET)
From: =?iso-8859-15?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es>
To: <mext@ietf.org>
Date: Mon, 1 Dec 2008 13:16:37 +0100
Message-ID: <A99C0DB09FED4CD5AC6168F5ADF1C841@bombo>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AclTrqbq6AW3MqrERIaBDOL+vunqFw==
X-imss-version: 2.051
X-imss-result: Passed
X-imss-scanInfo: M:B L:N SM:2
X-imss-tmaseResult: TT:1 TS:-17.2582 TC:1F TRN:86 TV:5.5.1026(16312.007)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
X-Mailman-Approved-At: Mon, 01 Dec 2008 04:28:17 -0800
Subject: [MEXT] Review of draft-ietf-mext-nemo-mib-03.txt
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>,
<mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>,
<mailto:mext-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1135693906=="
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org
Hi,
Marcelo Bagnulo has requested me to review the
draft-ietf-mext-nemo-mib-03.txt from a MIB-expert point of view (sorry, I'm
not a NEMO expert). Here are some comments:
- Page 3, section 2.1, second paragraph. It is not clear what is the
relationship of the first two sentences and the third. Needs some rewrite
- Page 5. remove commented line in IMPORTS section
-- Counter64
- page 16. This is a matter of preferences: I prefer the name of the table
being included in the name of the objects that belong to the table. Most of
the tables you define are according to this rule of thumb.
Then, nemoBindingMrFlag should be nemoBindingCacheMrFlag. The same for
nemoBindingMrMode. Then, it is easy to read
nemoBindingCacheGroup OBJECT-GROUP
OBJECTS {
nemoBindingMrFlag,
nemoBindingMrMode
}
The same consideration is raised for the objects of the nemoHaCounterTable,
defined in page 28 and above.
- Page 18. It is unclear why both { nemoMrEgressIfIndex,
nemoMrEgressIfPriority } must be INDEX of the table. It seems
nemoMrEgressIfIndex is enough. If not, explain in the DESCRIPTION of the
Entry clause why you need nemoMrEgressIfPriority.
- Page 18. In nemoMrEgressIfPriority, s/Unsigned32/ Unsigned32 (0..255) If
finally the priority is included in the INDEX clause, then (RFC 4181, page
14)
"It is acceptable to include zero in the
range when it is semantically significant or when it is used as
the index value for a unique row with special properties. Such
usage SHOULD be clearly documented in the DESCRIPTION clause."
- Page 19. why does nemoMrEgressIfDescription has read-write MAX-ACCESS ?
I don't see the point of this. However, if there is, explain in the
DESCRIPTION clause.
Additionally, it is unclear which string is expected for this object:
describe which kind of description should be included as a value for the
objects.
Finally, which default values or which criteria the agent will follow to set
this description? Include both issues in the DESCRIPTION
- Page 19. why does nemoMrEgressIfRoamHoldDownTime is read-write? Detail in
DESCRIPTION Default values?
What happens with the written information if the agent reboots?
- Page 33. From the DESCRIPTION clause, it is impossible to see the
difference among nemoHaStatsGroup and nemoHaGlobalStatsGroup.
By the way, note some inconsistency in the names for the objects in the
nemoHaStatsGroup (eg. nemoHaBUReque...) and the names in the
nemoHaGlobalStatsGroup (eg. nemoHaBindingAck...). Use always "BU" and "BA"
or "BindingUpdate" and "BindingAck"...
- Page 40. Does the malicious configuration of the
nemoMrEgressIfRoamHoldDownTime object may suppose any kind of vulnerability
for the system?
- Page 41. In the second line there are the names of 3 objects unconnected
to the rest of the text.
Regards,
Alberto Garcia (alberto@it.uc3m.es)
_______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext
- [MEXT] Review of draft-ietf-mext-nemo-mib-03.txt Alberto García