Re: [netlmm] AD review of draft-ietf-netlmm-pmipv6-mib

"Glenn M. Keeni" <glenn@cysols.com> Tue, 01 June 2010 05:09 UTC

Return-Path: <glenn@cysols.com>
X-Original-To: netlmm@core3.amsl.com
Delivered-To: netlmm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E9D3A6850 for <netlmm@core3.amsl.com>; Mon, 31 May 2010 22:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.71
X-Spam-Level: *
X-Spam-Status: No, score=1.71 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6]
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 0HAOd2QogSMc for <netlmm@core3.amsl.com>; Mon, 31 May 2010 22:09:38 -0700 (PDT)
Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by core3.amsl.com (Postfix) with ESMTP id E280B3A681C for <netlmm@ietf.org>; Mon, 31 May 2010 22:09:37 -0700 (PDT)
Received: from [127.0.0.1] (Bert.win2004.cysol.co.jp [192.168.0.198]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.4/8.14.4) with ESMTP id o5159Biv047218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jun 2010 14:09:15 +0900 (JST) (envelope-from glenn@cysols.com)
Message-ID: <4C0495F5.7090603@cysols.com>
Date: Tue, 01 Jun 2010 14:09:09 +0900
From: "Glenn M. Keeni" <glenn@cysols.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
References: <4C03BDE1.1010508@piuha.net>
In-Reply-To: <4C03BDE1.1010508@piuha.net>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-netlmm-pmipv6-mib@tools.ietf.org, "netlmm@ietf.org" <netlmm@ietf.org>
Subject: Re: [netlmm] AD review of draft-ietf-netlmm-pmipv6-mib
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jun 2010 05:09:41 -0000

Jari,
    Got this. Thanks for the detailed review. I will go through this and
get back to you.

    Cheers
    Glenn
Jari Arkko wrote:
> I have reviewed this draft. Overall, I think it is in good shape, but I did see 
> a number of issues. Please issue a new draft that corrects them and/or adds more 
> clarifying text. The main issues were:
> 
> - at times the document was unclear about where a particular piece of MIB 
> information is held (at the MAG vs. LMA)
> - in several places the document needs to be more explicit
> - some IP address issues
> - not sure I understood the OID limit issue
> 
>> - pmip6MagProxyCOATable          : models the Proxy Care-of
>>                                    Addresses configured on the
>>                                    egress interfaces of the
>>                                    mobile access gateway.
>>   
>  From this description it is unclear where this table is. Is this a MAG or a LMA 
> table?
> 
>> - pmip6MagHomeNetworkPrefixTable : contains the Home Network
>>                                    Prefixes assigned to the
>>                                    mobile node's connected
>>                                    interfaces.
>>   
> 
> Is this "the mobile node"? or all mobile nodes currently attached to this mag? 
> Same issue in pmip6LmaHomeNetworkPrefixTable.
> 
>>        - pmip6LmaLMAATable              : contains the LMA Addresses
>>                                           that are configured on the
>>                                           local mobility anchor. Each
>>                                           LMA Address acts as a
>>                                           transport endpoint of the
>>                                           tunnel between the local
>>                                           mobility anchor and the mobile
>>                                           access gateway.
>>   
>  From this desccription it is unclear from whose point of view this information 
> is presented. Does this table exist at the MAGs or the LMAs?
> 
>>    Pmip6MNIdentifier  ::=  TEXTUAL-CONVENTION
>>        STATUS  current
>>        DESCRIPTION
>>            "The identity of a mobile node in the Proxy Mobile IPv6
>>             domain. This is the stable identifier of a mobile node
>>             that the mobility entities in a Proxy Mobile IPv6 domain
>>             can always acquire and use it for predictably identifying
>>             a mobile node. This is typically an identifier such as
>>             Network Access Identifier (NAI) [RFC4282 <http://tools.ietf.org/html/rfc4282>] or other
>>             identifier such as a Media Access Control (MAC) address.
>>            "
>>        REFERENCE
>>            "RFC 5213 <http://tools.ietf.org/html/rfc5213>: Section 2.2 <http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-2.2>"
>>        SYNTAX  OCTET STRING (SIZE (0..255))
>>
>>   
> This description should be more accurate about the encoding of the identifier. 
> Do you mean that its the same encoding as in RFC 4283? Are there other 
> alternatives than NAIs? Please be more precise. Section 2.2 is not a very good 
> reference in this sense, because it too lacks specificity.
> 
>>    Pmip6MNLlIdentifier ::=  TEXTUAL-CONVENTION
>>        STATUS  current
>>        DESCRIPTION
>>            "An identifier that identifies the attached interface of a
>>             mobile node.  For those interfaces that have a link-layer
>>             identifier, this identifier can be based on that.  The
>>             link-layer identifier in some cases is generated by the
>>             mobile node and conveyed to the mobile access gateway.  This
>>             identifier of the attached interface must be stable as seen
>>             by any of the mobile access gateways in a given Proxy Mobile
>>             IPv6 domain.  In some other cases, there might not be any
>>             link-layer identifier associated with the mobile node's
>>             interface. An identifier value of ALL_ZERO is not considered
>>             a valid identifier and cannot be used as an interface
>>             identifier.
>>            "
>>        REFERENCE
>>            "RFC 5213 <http://tools.ietf.org/html/rfc5213>: Section 2.2 <http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-2.2>"
>>        SYNTAX  OCTET STRING (SIZE (0..255))
>>   
> As above, what is the encoding? Should the reference be Section 8.6 instead?
> 
>>    Pmip6MNIndex ::= TEXTUAL-CONVENTION
>>        DISPLAY-HINT "d"
>>        STATUS       current
>>        DESCRIPTION
>>            "A unique integer value, greater than zero, assigned to each
>>             mobile node in a PMIPv6-Domain by the management system.
>>             It is recommended that values are assigned contiguously
>>             starting from 1.  The value for each mobile node must remain
>>             constant at least from one re-initialization of the entity's
>>             network management system to the next re-initialization.
>>            "
>>        SYNTAX       Integer32 (1..2147483647)
>>
>>   
> 
> 
> Due to roaming, there is an infinite number of potential visited mobile nodes. 
> Are these indexes for the *current* mobile nodes, i.e., those currently attached 
> to the domain? Or something else? Please specify.
> 
>>    Pmip6PBUAccessTechnologyType ::=  TEXTUAL-CONVENTION
>>        STATUS  current
>>        DESCRIPTION
>>            "This specifies the access technology which connects the
>>             mobile node to the access link on the mobile access gateway.
>>            "
>>        REFERENCE
>>            "RFC 5213 <http://tools.ietf.org/html/rfc5213>: Section 8.5 <http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-8.5>"
>>        SYNTAX INTEGER
>>        {
>>                  reserved               (0),
>>                  logicalNetworkInterface(1),
>>                  pointToPointInterface  (2),
>>                  ethernet               (3),
>>                  wirelessLan            (4),
>>                  wimax                  (5)
>>        }
>>   
> 
> Perhaps you should explicitly state that the namespace from RFC 5213 should be used:
> 
> http://www.iana.org/assignments/mobility-parameters/mobility-parameters.txt
> 
> note the 3GPP etc items that do not appear in your list above...
> 
>>        pmip6FixedMagLinkLocalAddressOnAllAccessLinksType OBJECT-TYPE
>>            SYNTAX      InetAddressType
>>            MAX-ACCESS  read-write
>>            STATUS      current
>>            DESCRIPTION
>>                "The InetAddressType of the
>>                 pmip6FixedMagLinkLocalAddressOnAllAccessLinks
>>                 that follows.
>>                "
>>               ::= { pmip6Conf 2 }
>>        pmip6FixedMagLinkLocalAddressOnAllAccessLinks OBJECT-TYPE
>>            SYNTAX      InetAddress
>>            MAX-ACCESS  read-write
>>            STATUS      current
>>            DESCRIPTION
>>                "This variable indicates the link-local address value
>>                 that all the mobile access gateways should use on
>>                 any of the access links shared with any of the
>>                 mobile nodes in that Proxy Mobile IPv6 domain.  If
>>                 this variable is initialized to ALL_ZERO value, it
>>                 implies the use of fixed link-local address mode is
>>                 not enabled for that Proxy Mobile IPv6 domain."
>>            REFERENCE
>>                "RFC 5213 <http://tools.ietf.org/html/rfc5213>: Section 2.2 <http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-2.2>, 6.8, 6.9.1.1, 6.9.3, 9.3"
>>               ::= { pmip6Conf 3 }
>>   
> 
> I'm not sure I understand this. There's an IPv6 link local address, but is there 
> an IPv4 one? If not, why do we need the -Type object? And where is the IPv4 
> default router and DHCP server address stored in? Here there is room for just 
> one address, not two as would expect to require in a dual stack environment... 
> but maybe I'm missing something.
> 
> (Same issue in pmip6Binding table)
> 
>>        pmip6MagProxyCOAState  OBJECT-TYPE
>>            SYNTAX      INTEGER {
>>                                   unknown(1),
>>                                   activated(2),
>>                                   tunneled(3)
>>                           }
>>            MAX-ACCESS  read-only
>>            STATUS      current
>>            DESCRIPTION
>>                "This object indicates the state of the Proxy-CoA:
>>                    unknown     -- The state of the Proxy-CoA
>>                                   cannot be determined.
>>                    activated   -- The Proxy-CoA is ready to establish
>>                                   tunnel
>>                    tunneled    -- The Proxy-CoA is used to set up the
>>                                   bi-directional tunnel.
>>                "
>>            ::= { pmip6MagProxyCOAEntry 3 }
>>   
> 
> Do we use activated or tunneled, if the system is otherwise up but the MAG has 
> no mobile nodes, and has not had to send a Proxy Binding Update yet?
> 
>>        pmip6MagHomeNetworkPrefixTable   OBJECT-TYPE
>>             SYNTAX      SEQUENCE OF PMip6MagHomeNetworkPrefixEntry
>>             MAX-ACCESS  not-accessible
>>             STATUS      current
>>             DESCRIPTION
>>                 "A table representing the Home Network Prefixes
>>                  assigned to the mobile node's connected interfaces.
>>                  This table shows the prefixes registered in the
>>                  binding update list entry.
>>                 "
>>             REFERENCE
>>                 "RFC 5213 <http://tools.ietf.org/html/rfc5213>: Section 2 <http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-2>, 6.1, 6.2"
>>             ::= { pmip6MagConf 2 }
>>   
> 
> The description has been written as if there was just one mobile node and one 
> BUL entry. Please update the specification, I presume that you meant that this 
> table contains ALL prefixes of ALL mobile nodes for which there exists ANY BUL 
> in this MAG?
> 
>>        pmip6MagHomeNetworkPrefixEntry OBJECT-TYPE
>>             SYNTAX      PMip6MagHomeNetworkPrefixEntry
>>             MAX-ACCESS  not-accessible
>>             STATUS      current
>>             DESCRIPTION
>>                 "An entry in the Home Network Prefixes table.
>>
>>                  Implementers need to be aware that if the total
>>                  number of octets in pmip6MagHomeNetworkPrefix
>>                  exceeds 114 then OIDs of column
>>                  instances in this row will have more than 128
>>                  sub-identifiers and cannot be accessed using
>>                  SNMPv1, SNMPv2c, or SNMPv3.
>>   
> 
> I do not understand this. The pmip6MagHomeNetworkPrefix is of type InetAddress, 
> so in this case its length would always be 16, no?
> 
> (Same issue in pmip6LmaLMAAEntry and pmip6LmaHomeNetworkPrefixEntry)
> 
>>        pmip6MagHomeNetworkPrefixLifeTime   OBJECT-TYPE
>>             SYNTAX      Gauge32
>>             UNITS       "seconds"
>>             MAX-ACCESS  read-only
>>             STATUS      current
>>             DESCRIPTION
>>                 "The lifetime (in seconds) granted to the mobile
>>                  node for this registration.
>>                 "
>>             REFERENCE
>>                 "RFC 5213 <http://tools.ietf.org/html/rfc5213>: Section 6.2 <http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-6.2>, 6.7"
>>             ::= { pmip6MagHomeNetworkPrefixEntry 4 }
>>
>>
>>   
> The lifetime in the PBA? The lifetime in the last RA sent out to the mobile 
> node? The remaining lifetime? Please specify...
> 
>>        pmip6MagBLTable OBJECT-TYPE
>>            SYNTAX      SEQUENCE OF Pmip6MagBLEntry
>>            MAX-ACCESS  not-accessible
>>            STATUS      current
>>            DESCRIPTION
>>                "This table corresponds to the Binding Update List(BL)
>>   
> Is there a particular reason to drop the U from the abbreviation?
> 
>>         pmip6MagBLTimeRecentlyAccepted OBJECT-TYPE
>>            SYNTAX      DateAndTime
>>            MAX-ACCESS  read-only
>>            STATUS      current
>>            DESCRIPTION
>>                "The 64-bit timestamp value of the most recently
>>                 accepted Proxy Binding Update message sent for this
>>                 mobile node.  This is the time-of-day on the mobile
>>                 access gateway, when the proxy binding acknowledgement
>>                 message with the Status field set to 0
>>                 was received.  If the Timestamp option is not present
>>                 in the Proxy Binding Update message (i.e., when the
>>                 sequence number based scheme is in use), the value MUST
>>                 be set to ALL_ZERO.
>>                "
>>            REFERENCE
>>                "RFC 5213 <http://tools.ietf.org/html/rfc5213>: Section 5.1 <http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-5.1>, 8.1"
>>            ::= { pmip6MagBLEntry 9 }
>>   
> 
> I'm curious why the last timestamp is in this table, but the last sequence 
> number is not. Sequence numbers and timestamps are equal alternatives in RFC 5213.
> 
> (Same issue in pmip6Binding table)
> 
>>        pmip6BindingPBUFlag OBJECT-TYPE
>>            SYNTAX      TruthValue
>>            MAX-ACCESS  read-only
>>            STATUS      current
>>            DESCRIPTION
>>                "true(1) if the local mobility anchor accepted the
>>                 binding update with Proxy Registration Flag from a
>>                 mobile access gateway.
>>                 false(0) implies that the binding cache is from a
>>                 mobile node.
>>                "
>>            REFERENCE
>>                "RFC 5213 <http://tools.ietf.org/html/rfc5213>: Section 5.1 <http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-5.1>, 8.1"
>>            ::= { pmip6BindingCacheEntry 1 }
>>   
> 
> Please specify what is expected to happen for Flag=0 entries otherwise. Do they 
> even show up in this table, and if they do, how do the values in the entries get 
> filled? Or would a client Mobile IP host simply lead to the creation of another 
> entry in a Mobile IPv6 MIB table, not here?
> 
>>    sensitivity/vulnerability:
>>       nemoStatus: The value of this object is used to enable or disable
>>          the PMIPv6 functionality on a PMIPv6 entity. Access to this MO
>>          may be abused to disrupt the communication that depends on
>>   
> 
> This is the first time that nemoStatus appears in the document.
> 
> When using http://www.ibr.cs.tu-bs.de/bin/smitools.cgi I got these errors:
> 
>> mibs/PMIPV6-MIB:88: [2] {bad-identifier-case} `YYY' should start with a lower case letter
>> mibs/PMIPV6-MIB:88: [2] {object-identifier-not-prefix} Object identifier element `YYY' name only allowed as first element
>> mibs/PMIPV6-MIB:407: [5] {index-exceeds-too-large} warning: index of row `pmip6MagProxyCOAEntry' can exceed OID size limit by 136 subidentifier(s)
>> mibs/PMIPV6-MIB:537: [5] {index-exceeds-too-large} warning: index of row `pmip6MagHomeNetworkPrefixEntry' can exceed OID size limit by 648 subidentifier(s)
>> mibs/PMIPV6-MIB:1462: [5] {index-exceeds-too-large} warning: index of row `pmip6LmaLMAAEntry' can exceed OID size limit by 136 subidentifier(s)
>> mibs/PMIPV6-MIB:1640: [5] {index-exceeds-too-large} warning: index of row `pmip6LmaHomeNetworkPrefixEntry' can exceed OID size limit by 648 subidentifier(s)
>> mibs/PMIPV6-MIB:145: [5] {type-without-format} warning: type `Pmip6MNIdentifier' has no format specification
>> mibs/PMIPV6-MIB:160: [5] {type-without-format} warning: type `Pmip6MNLlIdentifier' has no format specification
>>   
> 
> At least some of these seem real problems. Please fix.
> 
> Jari
>