|
Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
2009-09-14 15:05:26
Hi Ahmad,
Please see inline for my suggested text for the retransmission issue.
Otherwise, I agree this closes the open issues.
Thanks!
Ben.
On Sep 12, 2009, at 3:23 AM, Ahmad Muhanna wrote:
Hi Ben,
Hopefully we can close on all of the open issues.
Please see inline.
Regards,
Ahmad
-----Original Message-----
From: Ben Campbell [mailto:ben(_at_)estacado(_dot_)net]
Subject: Re: Gen-ART LC and Telechat Review of
draft-ietf-mext-binding-revocation-10
This is a followup on revision 12, since it came out
before I got to
revision 11:
Overall, I think this revision is much better. Most of my concerns
have been addressed, but I have a few minor ones remaining.
Specific comments:
-- Section 10.1, 2nd bullet:
I don't think we resolved my concern about the SHOULD in the last
sentence. To recap, I think that needs to either be a MUST, or the
draft should offer guidance about the reasoning for the SHOULD and
the consequences of not following it. I'm picking on this one in
particular because it seems like not sending a BRA when
the A bit was
set is likely to cause retransmissions on the part of the
initiator.
[Ahmad]
If the MN does NOT have a binding in its BUL for the HoA
address that
is included in the Type 2 Routing header, the mobile node
should not
respond back (that was specifically discussed in details on the wg
ml).
It is like instructing the MN to delete a session that does
not exist.
Although, the (A) bit is set, it is up to the mobile node
whether to
send a BRA or not. I do not believe we need to mandate that via a
MUST.
I am sure some handset vendors will not like that at all.
Did the work group consider that if a MN doesn't respond, it
can expect to get a bunch of retransmissions--each of which
it will need to parse, check for bindings, etc.; possibly
eating more resources than responding in the first place would have?
I could understand if the concern was that the MN might get
irrelevant (or even malicious) BRIs from arbitrary sources,
but since they should only be arriving from trusted peers
over established SAs, I find the choice surprising.
But in any case, my concern was that it should be a MUST _or_
it should have discussion of the consequences of not doing
it. A line or two mentioning why this is a should, under what
circumstances it makes sense to not respond, and most
importantly pointing out the potential for needless
retransmission would help.
[Ahmad]
Yes we discussed that, but there are cases when the MN is not able to
send a BRA, for example, losing coverage, etc. "SHOULD" still a very
strong requirement, the node MUST do it unless there is a very good
valid reason not to.
But, please see below.
Also, the last sentence does not seem to make grammatical
sense after
the edits.
Thx, here is the new text, please let me know if you are
okay with it.
o If the Acknowledge (A) bit is set in the Binding Revocation
Indication and its Binding Update List contains an
entry for the
IP address in the Type 2 routing header, the mobile node MUST
send
a Binding Revocation Acknowledgement. However, in all other
cases
when the Acknowledge (A) bit is set in the BRI, the mobile node
SHOULD sends a Binding Revocation Acknowledgement following
Section 10.2.
That's better, depending on the resolution of the SHOULD
discussion above.
[Ahmad]
Here is the text with the proposed addition as suggested above:
o If the Acknowledge (A) bit is set in the Binding Revocation
Indication and its Binding Update List contains an entry for the
IP address in the Type 2 routing header, the mobile node MUST
send
a Binding Revocation Acknowledgement. However, in all other
cases
when the Acknowledge (A) bit is set in the BRI, the mobile node
SHOULD sends a Binding Revocation Acknowledgement following
Section
10.2. In the case when the MN does not send a BRA message in
response
to a BRI with the Acknowledge (A) bit is set, the MN may
receive a
retransmit of the BRI message.
Is that acceptable?
Mostly. I would say "one or more" retransmissions, as they are likely
to get several. Also, keep in mind this causes additional work for the
initiator, who would have to retransmit in the first case. Perhaps
something to the effect of:
"Note that anytime the MN does not send an requested acknowledgement
to a BRI, the initiator is likely to retransmit the BRI multiple
times. This causes additional load on the initiator who sends the
retransmissions, as well as on the MN that will receive and process
them."
-- Same section, 4th bullet:
This one still seems to ignore the A bit value. Given the
other edits, am I correct in assuming that you expect a BRA
if the A bit was set, otherwise a silent discard?
[Ahmad]
I believe we discussed this a little before. It is a fatal
error and
the
MN should never receive a BRI with the (P) bit set. That why this
behavior is the same regardless of the (A) bit is set or not. If you
feel that some clarification about the (A) bit needs to be
added, I
can
say,
...... regardless if the Acknowledge (A) bit is set or not,
the mobile
node MUST silently discard the BRI message.
From previous discussion, I thought we had converged on the
idea that
the A-bit should always be authoritative, rather than having
the A-bit
treatment change due to context. Again, my concern is that
the sender
is likely to retransmit multiple times if you don't respond.
[Ahmad]
Yes, the (A) bit is authoritative when it is used according to this
specification. If used in violation of this specification, then we
should have the choice to NOT allow it to be that authoritative!
Again, this is a fatal error that is NOT supposed to happen. But, what
about if we recommend to the MN to send a BRA with code "Revocation
Function NOT Supported"
I like the idea of recommending sending the BRA with a non-supported
code.
-- Section 11, (InitMINDelayBRIs) (I think I commented on
this, but can't find the resolution)
Did you intend for the _default_ to be a range (between .5
and 1 sec), or did you mean to say the default was 1 second,
and it must not be configured to less than .5 seconds? I
suspect the latter, but it's not clear from the text.
[Ahmad]
Sure, will fix this as follows:
Initial Minimum Delay Between BRI messages (InitMINDelayBRIs)
This variable specifies the initial delay timeout in seconds
before the revoking mobility entity retransmits a BRI message.
The default is 1 second but not to be configured less than 0.5
seconds.
That's better, thanks!
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
|
|