Re: WGLC reminder - draft-ietf-dmm-hnprenum-02

Hi,

This is comments about draft-ietf-dmm-hnprenum-02
https://tools.ietf.org/html/draft-ietf-dmm-hnprenum-02

The draft is short, and reads very well.  I think it should be further 
pursued.

Here are some comments:

>    o  When the MN obtains the new HNP information, it deletes the old
>       HoA and configures a new HoA with the newly allocated HNP.

It would make sense to delete not only _the_ old HoA but all addresses 
configured within the old HNP.  Because recently the hosts may configure 
more than one address when receiving a Router Advertisement - they may 
also configure at least one 'privacy' address.  All of them should be 
deleted.

>    (1) UPN message
>
>    In the UPN message sent from the LMA to the MAG, the notification
>    reason is set to 2 (UPDATE-SESSION-PARAMETERS).  Besides, the HNP
>    option containing the new HNP and the Mobile Node Identifier option
>    carrying Identifier of MN are contained as Mobility Options of UPN.

Can we see a message format of this?  Is it an ICMP message?  A Mobility 
Header?

Has this message been prototyped, is there a packet dump?

>    In the first Prefix Information option, the old HNP is carried but
>    both the related Valid Lifetime and Preferred Lifetime are set to 0.
>    In the second Prefix Information option, the new HNP is carried with
>    the Valid Lifetime and Preferred Lifetime set to larger than 0.

This reads smart: a unique message to tell the Host to delete the old 
prefix and use the new one.  I agree.

>    (3) DHCP Message
>
>    When the DHCP is used in PMIPv6 to configure the HoA for the MN, a
>    new IPv6 HoA is generated based on the new HNP.  Trigged by the UPN
>    message, the MAG will request the new HoA from the DHCP server first
>    and then the MAG updates the allocated HoA to the MN through the DHCP
>    server-initiated configuration exchange [RFC3315].

I think this is too specific.  It says MAG should request the new HoA 
(but what if MAG is Relay?).  Second it says that the MAG requests an 
address and then the server does server-initiated configuration - this 
is also very specific.

Maybe we can formulate in a different way, in which these specificities 
are just examples in the DHCP behaviour.  Because there are other ways 
in which DHCP can act to achieve the same - e.g. use Prefix Delegation, 
use Relays, and others.

> 7.  Security considerations
>
>    This extension causes no further security problem.  The security
>    considerations in [RFC5213] and [RFC7077] are enough for the basic
>    operation of this draft.

Maybe we should be specific to say that the security of the UPN message 
is ensured by... (something from RFC5213 and/or 5077).

Alex



Le 23/05/2016 à 19:17, Jouni.nosmap a écrit :
> Folks,
>
> Friendly nudge to do reviews on drafts we got now in WGLC.
>
> Jouni
>
> Sent from a smart phone.. Mind the typos..
>
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm
>