|
RE: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
2009-09-17 12:23:50
Hello Ben,
Thinking about this a little more, I think that you also would accept if
we remove the text causing grief all together:) In other words, what
about if we reword the text as below:
OLD TEXT:
=========
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, the mobile node
MUST do so according to Section 10.2.
NEW TEXT:
=========
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.
This way we do not need to add the clarification note.
What do you think?
Please let me know and many thanks again!
Regards,
Ahmad
-----Original Message-----
From: Muhanna, Ahmad (RICH1:2H10)
Sent: Monday, September 14, 2009 2:06 PM
To: 'Ben Campbell'
Cc: Khalil, Mohamed (RICH2:2S20); sgundave(_at_)cisco(_dot_)com;
pyegani(_at_)juniper(_dot_)net; General Area Review Team;
ietf(_at_)ietf(_dot_)org;
Jari Arkko; marcelo(_at_)it(_dot_)uc3m(_dot_)es; Laganier, Julien
Subject: RE: Gen-ART LC and Telechat Review of
draft-ietf-mext-binding-revocation-10
Hi Ben,
I am fine with your proposed text.
Many thanks for your review and comments.
Regards,
Ahmad
-----Original Message-----
From: Ben Campbell [mailto:ben(_at_)estacado(_dot_)net]
Sent: Monday, September 14, 2009 2:02 PM
To: Muhanna, Ahmad (RICH1:2H10)
Cc: Khalil, Mohamed (RICH2:2S20); sgundave(_at_)cisco(_dot_)com;
pyegani(_at_)juniper(_dot_)net; General Area Review Team;
ietf(_at_)ietf(_dot_)org; Jari
Arkko; marcelo(_at_)it(_dot_)uc3m(_dot_)es; Laganier, Julien
Subject: Re: Gen-ART LC and Telechat Review of
draft-ietf-mext-binding-revocation-10
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
|
|