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

From: Jari Arkko <[email-masked]>
Date: Mon, 09 Aug 2010 15:01:30 +0300

Will there be an update soon?

Jari

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Tue, 10 Aug 2010 01:31:47 +0900

Jari,
    I will get the update ready by the 16th.

Glenn

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sat, 21 Aug 2010 10:39:10 +0900

Hi,
    A revised version of the draft-ietf-netlmm-pmipv6-mib has
been posted to the IETF repository.

Filename:	 draft-ietf-netlmm-pmipv6-mib
Revision:	 03
Title:		 Proxy Mobile IPv6 Management Information Base
Creation_date:	 2010-08-20
WG ID:		 netlmm
Number_of_pages: 63

The issues and corresponding actions are in the attached text file.

Glenn
     I-X stands for Issue-X and R-X stands for Response to Issue-X
As fo now there are 20 issues. The summary is given below.

Details of Issues and responses ==============================>
I-1.
>>> >>> - 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?

R-1.
 -> This is a MAG table. Text has been added to clarify which table is where.

I-2.
>> >>
>>> >>> - 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?
R-2. Fixed the text 
                                       contains the Home Network
                                       Prefixes assigned to interfaces
                                       of all mobile nodes attached to
                                       the MAG.

I-2.1.
>> >> Same issue in pmip6LmaHomeNetworkPrefixTable.

R-2.1.
 -> This table has HNPs of all mobile nodes anchored on a LMA.
   (This table has "pmip6MagBLlMnIdentifier" in Indexes.)
   Fixed the text. 
                                       contains the list of Home
                                       Network Prefixes assigned to
                                       the connected interfaces of the
                                       mobiles nodes anchored on a LMA.

I-3.
>>> >>>         - 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?

R-3.
-> This is a LMA table. Text has been added to clarify which table is where.

I-4.
>> >>
>>> >>>     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.

R-4.
->  Fixed the DESCRIPTION and REFERENCE
        "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. Various forms of identifiers can be used to
         identify a mobile node (MN).  Two examples are a Network
         Access Identifier (NAI) [RFC4282] and an opaque identifier
         applicable to a particular application.
        "
    REFERENCE
        "RFC 4283: Section 3"

I-5.
>> >>
>>> >>>     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?

R-5.
-> Fixed the REFERENCE

I-6.
>> >>
>>> >>>     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.

R-6.
-> Fixed the DESCRIPTION. The scope is that of the current mobile nodes.

I-7.
>> >>
>>> >>>     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...

R-7.
-> Fixed the SYNTAX 
   There are 7 3GPP/3GPP2 items. We have to add those as (6) -- (12).
     0    Reserved          (0)
     1    Virtual           (1)
     2    PPP               (2)
     3    IEEE 802.3        (3)
     4    IEEE 802.11a/b/g  (4)
     5    IEEE 802.16e      (5)
     6    3GPP GERAN        (6)
     7    3GPP UTRAN        (7)
     8    3GPP E-UTRAN      (8)
     9    3GPP2 eHRPD       (9)
     10   3GPP2 HRPD        (10)
     11   3GPP2 1xRTT       (11)
     12   3GPP2 UMB         (12)

I-8.
>> >>
>>> >>>         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.
>> >>
I-9.
>> >> (Same issue in pmip6Binding table)
>> >>

R-8,9
-> that is the way it is done in MIBS (MIPv6MIB, NeMoMIB).
   The MIB itself is not constrained to work for any specified InetAddress
   type. However it defines a compliance e.g. pmip6CoreCompliance
   where only IPv6 address types are required to be implemented.

I-10
>>> >>>         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?

R-10.
-> The DESCRIPTION is fixed. 
                   activated   -- The Proxy-CoA is ready to establish
                                  a tunnel. This state SHOULD be indicated
                                  when the MAG is up but has no mobile node.
I-11.
>> >>
>>> >>>         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?

R-11.
-> Fixed the DESCRIPTION.
             "A table representing the Home Network Prefixes
              assigned to the connected interfaces of mobile nodes
              attached to the MAG.

I-12.
>> >>
>>> >>>         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?
>> >>
R-12.  The InetAddress type allows strings of length 0-255 octets. The maximum
       length of an index is 128 octets. So, use of inappropriate InetAddress
       types in the index would lead to problems. Thus a warning is added to
       the description clauses. But, if the address type is IPv6 as explained
       in R-8 then we have only 16 octets, and it will not really be a problem.

I-13.
>> >> (Same issue in pmip6LmaLMAAEntry and pmip6LmaHomeNetworkPrefixEntry)
>> >>

R-13.
-> See R-12.

I-14.
>>> >>>         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...

R-14.
-> DESCRIPTION fixed.
             "The lifetime parameter (in seconds) that will be advertised
              in Router Advertisements by the MAG for this Home Network 
              Prefix.
             "

I-15.
>> >>
>>> >>>         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?

R-15.
-> This abbreviation is consistent with "RFC 4295" (mip6MnBLTable).

I-16.
>> >>
>>> >>>          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.
R-16. We already have mip6MnBLMaxSeq [RFC4295] this should do. 
I-17.
>> >> (Same issue in pmip6Binding table)

R-17
-> We already have mip6BindingMaxSeq [RFC4295] this should do. 

I-18.
>> >>
>>> >>>         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?

R-18.
->
   This table AUGMENTS the "Mobile IPv6 MIB" table. So effectively all
   Binding cache entries will be there. But, the augmented part will have
   information only for FLAG=1 entries. If Flag=0 the remaining entries
   of this table will not be available/accessible. 
   The DESCRIPTION is updated.
I-19.
>> >>
>>> >>>     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.

R-19.
-> Typo fixed. nemoStatus -> pmip6Status

I-20
>> >> 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.
R-20.
-> Done.
   Added Display hints for the textual conventions that
   are causing warnings from the updated MIB compiler.

Summary of Responses/Actions ==========================================>

     R-1  : This is a MAG table. Text has been added to clarify which table 
            is where.
     R-2  : Fixed the text.       
     R-2.1: Fixed the text.  
     R-3  : This is a LMA table. Text has been added to clarify which table 
            is where.
     R-4  : Fixed the DESCRIPTION and REFERENCE
     R-5  : Fixed the REFERENCE
     R-6  : Fixed the DESCRIPTION.
     R-7  : There are 7 3GPP/3GPP2 items. Add those as (6) -- (12)
            Fixed the Object SYNTAX
     R-8  : That is the way it is done in MIBS (MIPv6MIB, NeMoMIB).
            The MIB itself is not constrained to work for any specified InetAddress
            type. However it defines a compliance e.g. pmip6CoreCompliance
            where only IPv6 address types are required to be implemented. 
     R-9  : Same as for I-8.
     R-10 : The DESCRIPTION is fixed.
     R-11 : The DESCRIPTION is fixed.
     R-12 : The InetAddress type allows strings of length 0-255 octets. The maximum 
            length of an index is 128 octets. So, use of inappropriate InetAddress 
            types in the index would lead to problems. Thus a warning is added to 
            the description clauses. But, if the address type is IPv6 as explained 
            in I-8 then we have only 16 octets, and it will not really be a problem.
     R-13 : Same as for I-12
     R-14 : DESCRIPTION fixed
             "The lifetime parameter (in seconds) that will be advertised
              in Router Advertisements by the MAG for this Home Network
              Prefix.
             "
     R-15 : Consistent with RFC4295
     R-16 : We already have mip6MnBLMaxSeq [RFC4295] this should do. 
     R-17 : We already have mip6BindingMaxSeq [RFC4295] this should do. 
     R-18 : The DESCRIPTION is updated.
     R-19 : Fix Typo nemoStatus -> pmip6Status.
     R-20 : Added Display hints for the textual conventions that
            are causing warnings from the updated MIB compiler.