Re: [netext] Gen-ART LC review: draft-ietf-netext-update-notifications-07

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

Hi Robert,

We seem to have missed this change. Will fix it in the next rev.

Regards
Sri


On 9/24/13 10:57 AM, "Robert Sparks" <[e-mail]> wrote:

>Hi Suresh -
>
>It doesn't look like any of these changes made it into -08?
>
>RjS
>
>On 8/22/13 4:51 PM, Robert Sparks wrote:
>> On 8/22/13 4:06 PM, Suresh Krishnan wrote:
>>> Hi Robert,
>>>    Thanks a lot for the review. We will include the changes in the next
>>> revision we submit. Please see proposed changes inline.
>>>
>>> On 08/22/2013 02:05 PM, Robert Sparks wrote:
>>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>>> Gen-ART, please see the FAQ at
>>>>
>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>>
>>>> Please resolve these comments along with any other Last Call comments
>>>> you may receive.
>>>>
>>>> Document: draft-ietf-netext-update-notifications-07
>>>> Reviewer: Robert Sparks
>>>> Review Date: 2013-08-22
>>>> IETF LC End Date: 2013-08-29
>>>> IESG Telechat date: not scheduled
>>>>
>>>> Summary: This draft is ready for publication as Proposed Standard
>>>>
>>>> I had to read through this text several times to convince myself
>>>> implementers could figure out what order they were required to take
>>>> steps in vs where they had flexibility:
>>>>
>>>>     o  Upon accepting the Update Notification message, the mobile
>>>> access
>>>>        gateway MUST process the message and perform the actions
>>>> based on
>>>>        the Notification Reason.
>>>>        *  If the (A) flag in the message is set to a value of (1), the
>>>>           mobile access gateway MUST first send an Update Notification
>>>>           Acknowledgement message and set the status code field
>>>> according
>>>>           to the result of processing the Update Notification message.
>>>>
>>>> In particular, it's not immediately obvious if there is tension
>>>>between
>>>> that "MUST first" and having "the result of processing" available.
>>>> Please consider rewording to make it clearer that this "result of
>>>> processing" is not intended to include waiting for the result of some
>>>> action processing this notification message might trigger.
>>> I think we can lose the word first without losing anything. Does the
>>> following rewording work for you?
>> Yes, thanks!
>>>
>>> OLD:
>>> If the (A) flag in the message is set to a value of (1), the mobile
>>> access gateway MUST first send an Update Notification Acknowledgement
>>> message and set the status code field according to the result of
>>> processing the Update Notification message.
>>>
>>> NEW:
>>> If the (A) flag in the message is set to a value of (1), the mobile
>>> access gateway MUST send an Update Notification Acknowledgement message
>>> with the status code field set based on the result of processing the
>>> Update Notification message.
>>>
>>>> It might help readers understand the intended usual case
>>>>retransmission
>>>> mechanics if the expected default values listed in section 7 were
>>>> called
>>>> out earlier in the document.
>>> Sure. Will call out the defaults at first use.
>>>
>>> Thanks
>>> Suresh
>>>
>>
>