Last Call Review of draft-ietf-dhc-triggered-reconfigure-05
review-ietf-dhc-triggered-reconfigure-05-genart-lc-sparks-2013-04-30-00
| Request | Review of | draft-ietf-dhc-triggered-reconfigure |
|---|---|---|
| Requested revision | No specific revision (document currently at 07) | |
| Type | Last Call Review | |
| Team | General Area Review Team (Gen-ART) (genart) | |
| Deadline | 2013-05-06 | |
| Requested | 2013-04-25 | |
| Authors | Mohamed Boucadair , Xavier Pougnard | |
| Draft last updated | 2013-04-30 | |
| Completed reviews |
Genart Last Call review of -05
by
Robert Sparks
(diff)
Genart Last Call review of -06 by Robert Sparks (diff) |
|
| Assignment | Reviewer | Robert Sparks |
| State | Completed | |
| Review |
review-ietf-dhc-triggered-reconfigure-05-genart-lc-sparks-2013-04-30
|
|
| Reviewed revision | 05 (document currently at 07) | |
| Result | On the Right Track | |
| Completed | 2013-04-30 |
review-ietf-dhc-triggered-reconfigure-05-genart-lc-sparks-2013-04-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 resolve these comments along with any other Last Call
comments
you may receive.
Document:
draft-ietf-dhc-triggered-reconfigure-05
Reviewer:
Robert Sparks
Review Date: April 26, 2013
IETF LC End Date:
May 6, 2013
IESG Telechat date: May 16, 2013
Summary:
This draft is on the right track but has open issues, described in
the review.
Major issues:
Overall, this document is solid, but I think there is a bug in
section 6.3.
I could be wrong, but If I'm right, this paragraph:
When retransmission is required, the relay may decide to
correct the content of RECONFIGURE-REQUEST message it issues
(e.g., update the Client Identifier list). This decision is local
to the relay (e.g., it may be based on observed events such as one
or more clients were reconfigured on their own).
introduces a race-condition that could lead to an erroneous state.
If a relay's first message included client A, then the
retransmission included clients A and B, but that retransmission
crosses with a success RECONFIGURE-REPLY to the request that only
included client A, the relay will think it succeeded in asking A and
B to be reconfigured.
Minor issues:
This sentence:
Furthermore, means to recover state in failure events
must be supported, but are not discussed in this document.
places a requirement on a relay (even though it's not using a 2119
MUST). Is there some other document that defines this requirement
that you can reference? If not, the requirement should be discussed
in this document. Alternatively, you could change the sentence to
talk about the consequences of not having a proprietary means for
recovering state.
Nits/editorial comments: