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

[Robert Sparks <[e-mail]>]

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