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 protected]] > Sent: September-24-13 1:57 PM > To: Suresh Krishnan > Cc: General Area Review Team; [email protected]; draft-ietf-netext-update- > [email protected] > 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 > >> > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
