Telechat Review of draft-ietf-netext-update-notifications-08
review-ietf-netext-update-notifications-08-genart-telechat-sparks-2013-09-30-00
| Request | Review of | draft-ietf-netext-update-notifications |
|---|---|---|
| Requested revision | No specific revision (document currently at 12) | |
| Type | Telechat Review | |
| Team | General Area Review Team (Gen-ART) (genart) | |
| Deadline | 2013-09-24 | |
| Requested | 2013-09-19 | |
| Authors | Suresh Krishnan , Sri Gundavelli , Marco Liebsch , Hidetoshi Yokota , Jouni Korhonen | |
| Draft last updated | 2013-09-30 | |
| Completed reviews |
Genart Last Call review of -07
by
Robert Sparks
(diff)
Genart Telechat review of -08 by Robert Sparks (diff) Opsdir Early review of -12 by Carlos Pignataro |
|
| Assignment | Reviewer | Robert Sparks |
| State | Completed | |
| Review |
review-ietf-netext-update-notifications-08-genart-telechat-sparks-2013-09-30
|
|
| Reviewed revision | 08 (document currently at 12) | |
| Result | Ready | |
| Completed | 2013-09-30 |
review-ietf-netext-update-notifications-08-genart-telechat-sparks-2013-09-30-00
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:
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.
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.