Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-update-notifications-08: (with DISCUSS and COMMENT)

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi Stephen,

Thanks for the reviews.


> 5.2: What happens if the IPsec SA is re-negotiated

Renegotiation of IPSec SA should result in updated SPD and PAD entries at
both the peers. Wondering, if MAG/LMA entities need to be aware of this,
or assume IKEv2/IPsec layer is handling that. SA Renegotiation could
potentially occur in the base protocol without this extension as well. I'm
thinking, as long as the SPD entries cover the new MH type, the
handling/validation is happening at the correct layers and no new checks
are needed. 




> - 4.1: What does "ANI-PARAMS-REQUESTED" mean? Probably all these reasons
>need an explanation and/or (forward) reference.


This is a request for updated Access Network Identifier parameters.
Section 6.1 has some text for each of the NR codes.

*  If the Notification Reason is set to a value of (4) "ANI-
         PARAMS-REQUESTED", then the mobile access gateway MUST send a
         Proxy Binding Update message to the local mobility anchor with
         the Access Network Identifier Option [RFC6757
<http://tools.ietf.org/html/rfc6757>].  The Access
         Network Identifier option MUST reflect the current access
         network parameters for that mobility session as known to the
         mobile access gateway at the time of sending the Proxy Binding
         Update message.





Regards
Sri



On 9/24/13 3:38 AM, "Stephen Farrell" <[e-mail]> wrote:

>Stephen Farrell has entered the following ballot position for
>draft-ietf-netext-update-notifications-08: Discuss
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>
>5.2: What happens if the IPsec SA is re-negotiated
>automatically? Isn't there a potential layering/sync problem
>so that these notifications couldn't ever be verified since a
>new SA would be in use? I think you just need to say the same
>or an automatically renegotiated SA (not sure what's the
>right terminology, sorry). I think 6.1 has the same issue and
>maybe other bits too. That kind of check also seems to
>imply that the interface between the MAG or LMA and the
>IPsec code needs to know that the right SA is being used
>which could be tricky. What's really done here?
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>
>- 4.1: What does "ANI-PARAMS-REQUESTED" mean? Probably all
>these reasons need an explanation and/or (forward) reference.
>
>