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

From: Robert Sparks <[email-masked]>
Date: Tue, 24 Sep 2013 12:57:18 -0500

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

---

From: Robert Sparks <[email-masked]>
Date: Tue, 24 Sep 2013 13:02:54 -0500

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-netext-update-notifications-08
Reviewer: Robert Sparks
Review Date: 2013-09-24
IETF LC End Date: 2013-08-29
IESG Telechat date: 2013-09-26

Summary: This draft is (still) ready for publication as Proposed 
Standard, but there are nits the editors agreed to fix that have not yet 
been addressed.

On 8/22/13 1:05 PM, Robert Sparks wrote:
>     o  Upon accepting the Update Notification message, the mobile access
>        gateway MUST process the message and perform the actions based on
>        the Notification Reason.
>           Acknowledgement message and set the status code field according
> In particular, it's not immediately obvious if there is tension 
> between that "MUST first" and having "the result of processing" available.
> 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.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 26 Sep 2013 04:28:26 +0000

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" <[email-masked]> wrote:

>>>>between
>>>>retransmission

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 26 Sep 2013 06:42:54 +0000

Hi Robert,
  Due to an editorial mixup the changes did not make it to -08.  We apologize for that. We have made the changes to the draft now and will ensure that they are included in the -09 rev or RFC editor notes depending on whether any other changes are needed.

Thanks
Suresh

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: September-24-13 1:57 PM
> To: Suresh Krishnan
> Cc: General Area Review Team; [email-masked]; draft-ietf-netext-update-
> [email-masked]
> Subject: Re: [netext] Gen-ART LC review: draft-ietf-netext-update-
> notifications-07
> 
> Hi Suresh -
> 
> >>    Thanks a lot for the review. We will include the changes in the
> >> next revision we submit. Please see proposed changes inline.
> >>
> >>> Please resolve these comments along with any other Last Call
> >>> comments you may receive.
> >>>
> >>> processing" is not intended to include waiting for the result of
> >>> some action processing this notification message might trigger.
> >> access gateway MUST send an Update Notification Acknowledgement
> >> message with the status code field set based on the result of

---

From: Jari Arkko <[email-masked]>
Date: Thu, 26 Sep 2013 14:21:43 +0300

Thank you Robert very much for your review. And I agree with the issue you raised. Thank you Suresh and others for the revision. But I do wish you'd submit the -09….

Jari