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

[Suresh Krishnan <[e-mail]>]

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:[e-mail]]
> Sent: September-24-13 1:57 PM
> To: Suresh Krishnan
> Cc: General Area Review Team; [e-mail]; draft-ietf-netext-update-
> [e-mail]
> Subject: Re: [netext] Gen-ART LC review: draft-ietf-netext-update-
> notifications-07
> 
> 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
> >>
> >