Subject: Re: [nemo] WG Last Call for NEMO MIB

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 04 Sep 2007 17:46:31 -0700

It's been over a month with no comments received yet. Last chance for 
making comments on the MIB.

TJ

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 05 Sep 2007 13:57:23 +0200

> making comments on the MIB.

TJ I've made some comments on March 14th, acknowledged by first author, 
but not all reflected in the current draft... :-(

The diff between the draft I reviewed and the draft-03 is at:
https://www3.tools.ietf.org/wg/nemo/draft-ietf-nemo-mib/draft-ietf-nemo-mib-03-from-02.wdiff.html

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Subject: RE: [nemo] Re:Comments on draft-ietf-nemo-mib-02.txt
From: "Sri Gundavelli"<[email-masked]>
To: "'Alexandru Petrescu'"<[email-masked]>, <[email-masked]>
Date: Wed, 14 Mar 2007 23:42:24 -0700

Hi Alex,

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 6:57 AM
To: [email-masked]
Subject: [nemo] Re:Comments on draft-ietf-nemo-mib-02.txt

Hi Sri, I have some comments on the NEMO-MIB draft, a WG item.

[email-masked] wrote:
  > 	Title		: NEMO Management Information Base
> 	Author(s)	: S. Gundavelli, et al.
> 	Filename	: draft-ietf-nemo-mib-02.txt
> 	Pages		: 34
> 	Date		: 2006-10-25
> 	
> This memo defines a portion of the Management Information Base (MIB),
>    the network mobility support (NEMO) MIB, for use with network
>    management protocols in the Internet community.  In particular, the
>    NEMO MIB will be used to monitor and control a mobile ipv6 node with
>    NEMO functionality.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-nemo-mib-02.txt

>        nemoActiveRoamingIfIndex OBJECT-TYPE
>              SYNTAX      InterfaceIndex
>              MAX-ACCESS  read-only
>              STATUS      current
>              DESCRIPTION
>                      "The interface index of the current active
>                       roaming interface.
>                      "
>              REFERENCE
>                  "RFC3963 : Section 5.5"
>              ::= { nemoSystem 14 }

Can we call it "egress" interface, instead of "roaming" interface, 
because rfc3963 nemov6 and NEMOv4 draft in MIP4 WG both call it "egress" 
interface.

[Sri] Ok.

>         nemoDynamicHADiscovery  OBJECT-TYPE
>              SYNTAX      TruthValue
>              MAX-ACCESS  read-write
>              STATUS      current
>              DESCRIPTION
>                      "This object indicates whether or not the mobile
>                       router should attempt to make dynamic home agent
>                       address discovery(DHAAD).
>                      "
>              ::= { nemoRegistration 5 }

Can we have a related OBJECT-TYPE that flags the use of DHAAD upon each 
handover.  I mean, a flag value would enforce performing DHAAD upon each 
new CoA obtention, another flag value would enforce perfoming DHAAD now 
only (not upon each handover time).  Is this something feasible?  Or 
needed at all?  I need such kind of conditioning of the DHAAD behaviour 
in my implementation.

[Sri] Possible. Too many knobs. But, we can do that.

>        nemoHomeNetworkPrefixTable   OBJECT-TYPE
>              SYNTAX      SEQUENCE OF NemoHomeNetworkPrefixEntry
>              MAX-ACCESS  not-accessible
>              STATUS      current
>              DESCRIPTION
>                      "A table representing the potential home networks
>                       that the mobile router can use
>                      "
>              ::= { nemoRegistration 12 }

Who would use this table and where?  On MR?  Who fills it?  DHCP?

[Sri] Plan to remove it. Its a feature, but we decided to remove this.

>         nemoPrefixTable   OBJECT-TYPE
>              SYNTAX      SEQUENCE OF NemoPrefixEntry
>              MAX-ACCESS  not-accessible
>              STATUS      current
>              DESCRIPTION
>                      "A table representing the NEMO prefixes.
>                      "
>              ::= { nemoConfiguration 2 }

I think this table should also contain the Home Address for each Home 
Network Prefix, no?  All MIB entries for the Prefix Table don't seem to 
include the HoA, am I right.

[Sri] Why should the HoA be prefix specific. The MIB is on the MR
and so there is only one HoA, per-3963.

>          nemoOpNotSupported  OBJECT-TYPE
>              SYNTAX      Counter32
>              MAX-ACCESS  read-only
>              STATUS      current
>              DESCRIPTION
>                      "The total number of Binding Update requests
>                       rejected by the home agent with status code in the
>                       Binding Acknowledgement indicating
>                       'Mobile Router Operation not permitted'
>                       (Code 140).

Can we call this nemoOpNotPermitted instead of notSupported, to reflect 
the IANA number name better.

[Sri] Ok.

>    [RFC3775] Johnson, D., Perkins, C. and Arkko J., Mobility Support in
>    IPv6q RFC 3775, June 2004.

Typo q.

[Sri] Sure. Will fix it.

Finally, what would you think about doing same kind of document but for 
MIP4 WG (who does NEMOv4).  This MIB-NEMOv6 has several IPv6-related 
text that could be changed for IPv4 relatively easily (I think?).

[Sri] There is a 2206bis ...may be it can go there. You should talk to those
authors.

Thanks for the review.

Sri

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 06 Sep 2007 18:16:35 +0200

Hi Alex,

So in order to avoid everyone digging into the archives, what are the 
comments you gave which have not been considered ? Then, next question I 
will ask to MIB authors is why they haven't considered these ?

Thierry.

Alexandru Petrescu wrote:
> ------------------------------------------------------------------------
> 
> Subject:
> RE: [nemo] Re:Comments on draft-ietf-nemo-mib-02.txt
> From:
> To:
> "'Alexandru Petrescu'"<[email-masked]>, <[email-masked]>
> 
> To:
> "'Alexandru Petrescu'"<[email-masked]>, <[email-masked]>
> 
> 
> Hi Alex,
>  
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 6 Sep 2007 09:23:53 -0700

Hi Thierry,

Glen did the edit for this revision. Alex had suggested
some new knobs/objects. But, the general thought was to
keep the objects low, as there were too many objects
and so could not be added. The base MIB structure is
to stay close to 3963 and the suggested objects that are
not directly specified as config settings in that draft
were added at discretion.

Sri 

> From: Thierry Ernst [mailto:[email-masked]] 
> Sent: Thursday, September 06, 2007 9:17 AM
> To: 'ml-nemo WG'
> Cc: Alexandru Petrescu; T.J. Kniveton
> Subject: Re: [nemo] WG Last Call for NEMO MIB
> 
> 
> Hi Alex,
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Sep 2007 14:34:05 +0200

Thierry Ernst wrote:
>  comments you gave which have not been considered ?

Right... sorry, it was attached to that mail.  In short:

-call it "egress" instead of "roaming" interface, as per terminology in
  rfc3963 and nemov4 draft.
-agreed to remove the nemoHomeNetworkPrefixTable
-call it nemoOpNotPermitted instead of NotSupported, as per rfc
  terminology.
-typo 'q' in 'IPv6q".

And yes, I've suggested a new knob for triggering DHAAD upon each
handover, Sri said too many knobs, and then I said ok, I can do it
locally configured.

But I've also suggested that the nemoPrefixTable should contain a Home
Address for each prefix, and Sri said there's only one HoA for each MR.
  A thing to which I disagree completely.

Alex

> Then, next question I will ask to MIB authors is why they haven't
> considered these ?
> 
> Thierry.
> 
> 
>>> It's been over a month with no comments received yet. Last chance
>>> for making comments on the MIB.
>> 
>> TJ I've made some comments on March 14th, acknowledged by first 
>> author, but not all reflected in the current draft... :-(
>> 
>>  This email has been scanned by the MessageLabs Email Security
>> System. For more information please visit
>> http://www.messagelabs.com/email 
>> Subject: RE: [nemo] Re:Comments on draft-ietf-nemo-mib-02.txt From:
>>  "Sri Gundavelli"<[email-masked]> Date: Wed, 14 Mar 2007
>> 23:42:24 -0700 To: "'Alexandru
>> Petrescu'"<[email-masked]>, <[email-masked]>
>> 
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Wednesday, March 14,
>> 2007 6:57 AM To: [email-masked] Subject: [nemo] Re:Comments on
>> draft-ietf-nemo-mib-02.txt
>> 
>>> Title        : NEMO Management Information Base Author(s)    : S.
>>> Gundavelli, et al. Filename    : draft-ietf-nemo-mib-02.txt Pages
>>> : 34 Date        : 2006-10-25
>>> 
>>> This memo defines a portion of the Management Information Base
>>> (MIB), the network mobility support (NEMO) MIB, for use with
>>> network management protocols in the Internet community.  In
>>> particular, the NEMO MIB will be used to monitor and control a
>>> mobile ipv6 node with NEMO functionality.
>>> 
>>> nemoActiveRoamingIfIndex OBJECT-TYPE SYNTAX      InterfaceIndex 
>>> MAX-ACCESS  read-only STATUS      current DESCRIPTION "The
>>> interface index of the current active roaming interface. " 
>>> REFERENCE "RFC3963 : Section 5.5" ::= { nemoSystem 14 }
>> 
>>  because rfc3963 nemov6 and NEMOv4 draft in MIP4 WG both call it 
>> "egress" interface.
>> 
>> 
>> [Sri] Ok.
>> 
>> 
>> 
>> 
>>> nemoDynamicHADiscovery  OBJECT-TYPE SYNTAX      TruthValue 
>>> MAX-ACCESS  read-write STATUS      current DESCRIPTION "This
>>> object indicates whether or not the mobile router should attempt
>>> to make dynamic home agent address discovery(DHAAD). " ::= {
>>> nemoRegistration 5 }
>> 
>> Can we have a related OBJECT-TYPE that flags the use of DHAAD upon
>>  each handover.  I mean, a flag value would enforce performing
>> DHAAD upon each new CoA obtention, another flag value would enforce
>>  perfoming DHAAD now only (not upon each handover time).  Is this 
>> something feasible?  Or needed at all?  I need such kind of 
>> conditioning of the DHAAD behaviour in my implementation.
>> 
>> 
>>> nemoHomeNetworkPrefixTable   OBJECT-TYPE SYNTAX      SEQUENCE OF
>>> NemoHomeNetworkPrefixEntry MAX-ACCESS  not-accessible STATUS
>>> current DESCRIPTION "A table representing the potential home
>>> networks that the mobile router can use " ::= { nemoRegistration
>>> 12 }
>> 
>>> nemoPrefixTable   OBJECT-TYPE SYNTAX      SEQUENCE OF
>>> NemoPrefixEntry MAX-ACCESS  not-accessible STATUS      current 
>>> DESCRIPTION "A table representing the NEMO prefixes. " ::= {
>>> nemoConfiguration 2 }
>> 
>> I think this table should also contain the Home Address for each
>> Home Network Prefix, no?  All MIB entries for the Prefix Table
>> don't seem to include the HoA, am I right.
>> 
>> 
>>> nemoOpNotSupported  OBJECT-TYPE SYNTAX      Counter32 MAX-ACCESS
>>> read-only STATUS      current DESCRIPTION "The total number of
>>> Binding Update requests rejected by the home agent with status
>>> code in the Binding Acknowledgement indicating 'Mobile Router
>>> Operation not permitted' (Code 140).
>> 
>> Can we call this nemoOpNotPermitted instead of notSupported, to 
>> reflect the IANA number name better.
>> 
>> [Sri] Ok.
>> 
>> 
>> 
>>> [RFC3775] Johnson, D., Perkins, C. and Arkko J., Mobility Support
>>> in IPv6q RFC 3775, June 2004.
>> 
>> Typo q.
>> 
>> 
>> 
>> [Sri] Sure. Will fix it.
>> 
>> 
>> 
>> 
>> Finally, what would you think about doing same kind of document but
>>  for MIP4 WG (who does NEMOv4).  This MIB-NEMOv6 has several 
>> IPv6-related text that could be changed for IPv4 relatively easily
>> (I think?).
>> 
>> [Sri] There is a 2206bis ...may be it can go there. You should talk
>> to those authors.
>> 
>> 
>> Thanks for the review.
>> 
>> Sri
>> 
>