[MEXT] [Fwd: RE: Last Call: draft-ietf-mext-nemo-mib (NEMO Management Information Base) to Proposed Standard]

[marcelo bagnulo braun <marcelo at it.uc3m.es>]

-------- Mensaje original --------
Asunto: 	RE: Last Call: draft-ietf-mext-nemo-mib (NEMO Management 
Information Base) to Proposed Standard
Fecha: 	Wed, 21 Jan 2009 14:53:10 +0100
De: 	Romascanu, Dan (Dan) <dromasca at avaya.com>
Para: 	<ietf at ietf.org>
CC: 	mext at ietf.org
Referencias: 	<20090113161148.4F49A3A6981 at core3.amsl.com>



This review is a super-set of the MIB Doctor review by Bert Wijnen. 

This document is not completely ready for being taken into discussion by
the IESG. Although there is no major issue with the current version of
the document the issues described at #3, #7, #8 and #10 must be fixed.
Correcting the other issues raised in the comments is recommended. 


1. Section 2.2 (implementation guidance) is incomplete. It should
mention the need to support ifTable from IF-MIB as InterfaceIndex is
IMPORTed. Also better rename it 'Relationship to other MIB modules'. 

2. Compilation is OK - running SMICng (strict checking) results in:

  W: f(nemo.mi2), (221,5) Row "nemoMrBLEntry" has indexing that may
create variables with more than 128
sub-ids
W: f(nemo.mi2), (404,5) Row "nemoHaMobileNetworkPrefixEntry" has
indexing that may create variables w
ith more than 128 sub-ids
W: f(nemo.mi2), (540,5) Row "nemoBindingCacheEntry" has indexing that
may create variables with more
than 128 sub-ids
W: f(nemo.mi2), (1092,5) Row "nemoHaCounterEntry" has indexing that may
create variables with more th
an 128 sub-ids

Two are AUGEMENTS, the other two do have a warning in the DESCIRPITON
clauses, so OK.

3. The Object nemoMrPrefixRegMode is writable but there is no
description of the expected persistency behavior. 

For read-write object nemoStatus:
                  The value of this object SHOULD remain unchanged
                  across reboots of the managed entity.
A SHOULD does not really help a management station as it cannot count
for sure on persistency.

4. 
     nemoNotifications        OBJECT IDENTIFIER ::= { nemoMIB 0 }
     nemoObjects              OBJECT IDENTIFIER ::= { nemoMIB 1 }
     nemoConformance          OBJECT IDENTIFIER ::= { nemoMIB 3 }

Why the Conformance is not under { nemoMIB 2 } as recommended by
RFC4181?

5. I see a few times:
       SYNTAX INTEGER {
                 implicitMode       (1),
                 explicitMode       (2)
              }
Candidate for a TC. But not a fatal flaw of course

6. I think that according the guidelines in RFC4181, this one

   nemoHaMobileNetworkPrefixSeqNo OBJECT-TYPE
       SYNTAX      Integer32 (1..1024)

would better be an Unsigned32. Again, not a fatal flaw.

7.     nemoBindingMrFlag OBJECT-TYPE
       SYNTAX      TruthValue
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "true(1) indicates that the binding cache entry is from
                an entity acting as a mobile router.
                false(0) implies that the binding cache entry is from
                an entity acting as a mobile node.
               "

But the TC in RFC2579 says:
TruthValue ::= TEXTUAL-CONVENTION
   STATUS       current
   DESCRIPTION
           "Represents a boolean value."
   SYNTAX       INTEGER { true(1), false(2) }

So it should be false(2) and not false(0) in the DESCRIPTION clause. 

8. The document must have normative references to RFC 2863 and RFC 4001
as the MIB module defined in this document IMPORTs objects from the MIB
modules defined in these RFCs.

9. No need to carry commented objects in the IMPORTS section.

10. The REVISION date is in the future - points to November 12 and not
to January 12. 

11. It would be useful to add UNITS clauses to the Counter objects. 

Dan





> -----Original Message-----
> From: ietf-announce-bounces at ietf.org 
> [mailto:ietf-announce-bounces at ietf.org] On Behalf Of The IESG
> Sent: Tuesday, January 13, 2009 6:12 PM
> To: IETF-Announce
> Cc: mext at ietf.org
> Subject: Last Call: draft-ietf-mext-nemo-mib (NEMO Management 
> Information Base) to Proposed Standard 
>
> The IESG has received a request from the Mobility EXTensions 
> for IPv6 WG
> (mext) to consider the following document:
>
> - 'NEMO Management Information Base '
>    <draft-ietf-mext-nemo-mib-04.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 
> substantive comments to the ietf at ietf.org mailing lists by 
> 2009-01-27. Exceptionally, comments may be sent to 
> iesg at ietf.org instead. In either case, please retain the 
> beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-mib-04.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_id&dTag=16994&rfc_flag=0
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce at ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext