Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

Robert Sparks <rjsparks@xxxxxxxxxxx> · Mon, 29 Apr 2013 08:45:18 -0500

On 4/29/13 12:59 AM, mohamed.boucadair@xxxxxxxxxx wrote:
Robert,

Ted suggested a wording which is better than the one I proposed. I made the following changes my local copy:

(1)

OLD:
    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).

NEW:
    The relay MAY remove clients from the client identifier list in
    subsequent retransmissions, but MUST NOT add clients to the client
    identifier list.

(2)

OLD:
    Furthermore, means to recover state in failure events must be
    supported, but are not discussed in this document.

NEW:
    Furthermore, means to recover state in failure events (e.g.,
    [RFC5460]) must be supported, but are not discussed in this document.

Is this better?
1 is better.

2 is an improvement, I might say "such as" instead of e.g. to even more
strongly avoid someone thinking you are _requiring_ implementation of
RFC5460.  Even then, it's still not clear whether you're trying to say

"Something that doesn't do this is does not conform to this specification"

or

"Something that doesn't do this isn't as good a tool as it can be and 
may create a condition that operators and users will not like much."

You chose not to use MUST in that sentence. Can you make it less likely 
that someone will assume you meant to?

Cheers,
Med

-----Message d'origine-----
De : Bernie Volz (volz) [mailto:volz@xxxxxxxxx]
Envoyé : samedi 27 avril 2013 06:24
À : Robert Sparks; BOUCADAIR Mohamed OLNC/OLN
Cc : dhcwg@xxxxxxxx; General Area Review Team; ietf@xxxxxxxx; draft-ietf-
dhc-triggered-reconfigure@xxxxxxxxxxxxxx
Objet : RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-
reconfigure-05

Robert:

The reason to allow this is that otherwise client A will be unnecessarily
reconfigured many times. (It is also possible that a client might Renew on
its own just as this is happening and thus it can also be removed from the
Reconfigure.)

I think the text should be cleaned up to indicate that allowing removal of
already reconfigured clients is recommended (to prevent unnecessary
reconfigures) when retransmitting the Reconfigure-Request.

Note that if clients are added, that is not a retransmission but requires a
"new" message (new XID).

- Bernie

-----Original Message-----
From: dhcwg-bounces@xxxxxxxx [mailto:dhcwg-bounces@xxxxxxxx] On Behalf Of
Robert Sparks
Sent: Friday, April 26, 2013 12:19 PM
To: mohamed.boucadair@xxxxxxxxxx
Cc: dhcwg@xxxxxxxx; General Area Review Team; ietf@xxxxxxxx; draft-ietf-
dhc-triggered-reconfigure@xxxxxxxxxxxxxx
Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-
reconfigure-05

On 4/26/13 10:58 AM, mohamed.boucadair@xxxxxxxxxx wrote:
Dear Robert,

Thank you for the review.
Please see inline.

Cheers,
Med
________________________________________
De : dhcwg-bounces@xxxxxxxx [dhcwg-bounces@xxxxxxxx] de la part de
Robert Sparks [rjsparks@xxxxxxxxxxx] Date d'envoi : vendredi 26 avril
2013 17:42 À : dhcwg@xxxxxxxx; ietf@xxxxxxxx; General Area Review
Team; draft-ietf-dhc-triggered-reconfigure@xxxxxxxxxxxxxx
Objet : [dhcwg] Gen-art review:
draft-ietf-dhc-triggered-reconfigure-05

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><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.
Med: This example does not apply for that text.
Really? What text constrains how you change what's in the retransmission?
   In fact, the example should be the other way around. Perhaps, this can
be made clearer if we change "(e.g., update the Client Identifier list)" to
"(e.g., remove a client from the Client Identifier list)".
If I understand you correctly, you need more than just changing a
parenthetical e.g.. I think you're saying that you are constraining the
message changes to be such that if anything earlier in the retransmission
sequence succeeded, the request in the retransmission would also have
succeeded. But why do you need that much complexity? Do you have it already
with any other request?
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?
Med: I'm not aware of any; but if there is one we can cite it.

   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.
Med: Will consider that option if you think this is really needed.

Nits/editorial comments:
_______________________________________________
dhcwg mailing list
dhcwg@xxxxxxxx
https://www.ietf.org/mailman/listinfo/dhcwg