RE: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation

Hi Ben,
Thanks for the follow up. Please see answers 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.


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.


-- 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.


-- 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.


-- Security Considerations:

I think there is enough potential for confusion about when 
IPSec is required to put some non-normative description of 
when it is and isn't required, along with references to the 
normative requirements.

[Ahmad]
I suppose this is just a comment that does not need clarification or
anything like that. 

Thanks again Ben for your review and comments!


Thanks!

Ben.





On Sep 5, 2009, at 3:04 AM, Ahmad Muhanna wrote:

Hello,

We have updated the draft to address all comments.
A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation

-1
1.txt


In summary, here is a list of the major changes:

1. Enhanced to the security text mainly under section 6.1.

and section

13 (Security Considerations) to address Ben comments. In

addition, we

eliminated the Security Model section based on Ralph's comment.

2. Enhanced the text for MAG authorization and defined a default 
mechanism as specified under section 13, Security Considerations.

3. Addressed Pasi's comments by adding text to clearly specify that 
the current specification uses mobile node identifier

option, MN-ID,

with subtype 1, as stated mainly under section 5.1. In addition, we 
defined the format of "wild card" NAI as per the use of this 
specification, text under section 8.1.1.

4. Addressed all the remaining of Ralph's detailed comments

in several

places of the document.

5. Clarified that the responder sends BRA only if the

Acknowledge (A)

bit is set. Text was tweaked in several places.

6. all nits and editorial comments....

Please let me know if you still have any issue.

Thanks for all of your comments and help!

Regards,
Ahmad

-----Original Message-----
From: Muhanna, Ahmad (RICH1:2H10)
Sent: Thursday, August 27, 2009 1:33 PM
To: 'Ben Campbell'
Cc: Khalil, Mohamed (RICH2:2S20); sgundave(_at_)cisco(_dot_)com; 
kchowdhury(_at_)starentnetworks(_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: [PART-I] Gen-ART LC and Telechat Review of 
draft-ietf-mext-binding-revocation-10

Hi, Ben,

-----Original Message-----

Summary: This draft is on the right track, but there are

open issues.

Additionally, I have a number of editorial comments.

Major issues:

-- I think the security considerations need quite a bit of

work. In

particular, there is very little guidance on authorization for 
sending BRI messages. This seem to me have utility for DoS

attacks,

particularly with the G bit set.
There is mention of reusing existing security associations

if IPSec

is used--but no mention of what to do if IPSec is not used.

[Ahmad]
Binding Revocation is used between two peers to

revoke/terminate a

mobility session(s) that have been created using an IPv6

mobility

protocol signaling (Client Mobile IPv6 or Proxy MIP6).

RFC3775 and

RFC5213, which are the main protocols targeted by this

specification,

specify that "IPsec SHOULD" be used. On the other hand,

there is NO

other standard track specification which specify other security 
mechanisms to secure the IPv6 mobility signaling.

Therefore, Binding

Revocation specification assumes the use of whatever security 
mechanism that currently available to secure the IPv6 mobility 
signaling.


I think there are still a couple of issues here. First, Since the 
underlying RFCs only specify IPSec at SHOULD strength, this draft 
needs to discuss the consequences of not using it for BRI.

Depending

on those consequences, it might be enough to just warn

implementors

that, if you don't use IPSec, certain bad things can happen.

[Ahmad]
It is NOT expected that BRI/BRA will use a different security 
mechanism than what is being used for securing IPv6 mobility 
signaling. Therefore, in order to alert implementors of

the danger if

IPsec is NOT used, IMO, that needs to be discussed in related IPv6 
mobility specifications, e.g., RFC3775 and RFC5213, which

is already

there. On the other hand, it is very difficult to anticipate the 
criteria of other security mechanisms that would possibly

be used in

the future to secure IPv6 mobility signaling and consequently 
BRI/BRA.

OTOH, it might be that BRI has
greater security risks than for 3775/5213, and you might (for
example) need to strengthen the IPSec requirement for BRI.

I admit to not being an expert on 3375/5213, so it may be

true that

BRI is no riskier than the underlying technology--but even

if that is

true I'd like to see some discussion to support it.

[Ahmad]
Both IPv6 mobility signaling and BRI/BRA use the same IPv6 layer 
signaling. I am not sure what impact the underlying

technology has on

BRI./BRA that does not have on BU/BA.


Second, I think that there is probably more guidance needed on 
authorization decisions even if you do use IPSec. For

example, do you

assume that any trusted peer can remove any binding?

[Ahmad]
No. The revoking mobility entity revokes only those mobility
session(s) which are registered with it. No mobility node

can revoke

a mobility session that is registered with a different trusted 
mobility node.

Is a trusted peer only allowed to remove bindings that it

previously

established using the same SA?

[Ahmad]
I believe I addressed this via another comment earlier.

The answer is

NO.

If an SA is
torn down and a new one established, what authorization gets 
inherited, if any?

[Ahmad]
When the SA is torn down and a new one is established, the

new SA is

valid for both BU/BA and BRI/BRA. In other words, the new SA will 
still have the same SPD which allows the BU/BA and BRI/BRA

messages,

etc. If your question is about authorization of Global revocation, 
that authorization should be done separately.

Do you assume that a peer that is trusted to establish

bindings is

trusted for BRI?

[Ahmad]
Of course. The node which initiated or granted the registration 
should have the authority to revoke it.
Do you see any problem there?

Do you need to
provision policies around these, and if so what are the

moving parts?

[Ahmad]
The text under the security section was supposed to

capture this. The

SPD should be updated to allow MH type of 'Binding Revocation 
message'. If it is not enough, let us know what is missing

and we can

add/modify as needed.

(Perhaps it is required by the underlying technology?
If so, that should be mentioned here.)

[Ahmad]
That is not the intention. Please see above.

You mention that
authorization is required if the G-bit is set, but go on to say 
authorization details are out of scope. I think that this

draft needs

to either offer much more guidance on authentication

requirements.

[Ahmad]
We could introduce a simple default mechanism inline with

what we have

in RFC5213.


It's possible that might help--can you point to the

section of 5213

you have in mind?


[Ahmad]
Section 4, paragraph 6.

It might also be enough to have
more discussion on what an implementor needs to think about to do 
authorization correctly. For example, does it make sense to

statically

provision that a trusted peer can remove any binding for

"foo.com"?

[Ahmad]
Sure, static configuration what RFC5213 has under section 4.
However, in our case, is the peer authorized to use Global

Revocation

or not. This is not restricted to a certain realm but the

restriction

as mentioned above to sessions that is hosted at the revoking 
mobility node.

Is authorization policy
dynamically determined by prior actions (i.e. a peer can

revoke all

bindings _it_ established for "foo.com", but not bindings

that another

device established for "foo.com"?

[Ahmad]
That is the very fundamental requirement for this protocol.


Probably more than anything, it would help to discuss the

sort bad

things that this authorization is intended to prevent.


[Ahmad]
Ok. We can elaborate and add some text here. Thx.

It would be helpful if the
Security Considerations section discussed the consequences of 
security failures, possible attacks, etc.

[Ahmad]
This specification do not introduce any security threats on

the top of

what is being discussed in Client MIP6 and Proxy MIP6,

RFC3775 and

RFC5213.


That's a little hard to believe without some supporting

text. Again,

this could be my lack of knowledge of IPv6 mobility

talking. But for

example, do RFC3775 and/or 5213 already have something a

mechanism for

one mobility element to tell another to drop bindings in bulk?


[Ahmad]
Yes. For example, the client which has multiple Bindings

(referenced

by different Binding IDs) could send a single message 
(de-registration, a BU with lifetime zero) and request the server 
(HA) to delete all bindings which belong to this Mobile node.



Minor issues:

-- S3.4.2, paragraph 1: "responds with the appropriate

status code

by sending a Binding Revocation Acknowledgement message"

Always, or just if the A bit is set?

[Ahmad]
This section describes the usecase when Global revocation

is being

used by the MAG; there is no normative text in this section.


Understood (but I had similar questions in the normative

sections).

In addition,
section 10.2.1. which talks about the use of the (G) bit by

the MAG

and
indicates that whenever the (G) bit is set the (A) bit MUST

be set, is

correctly being referenced in this section and mentioned

before the

text
quoted above.


But this text talks about how you form a BRA, not how the

initiator

formed the BRI. Would you expect a responder to just

assume (without

checking) that the A bit was set if it sees a G-bit set?

There's a lot of interaction between these bit settings

that make for

some pretty complicated state transitions. As described,

it expects

the responder to infer the A bit value based on the G-bit

value. It

would be much cleaner to to implement if it were defined so

that the

responder always sends a BRA if the A bit is set, and never

if it is

not.

As a thought experiment, how would you recommend an

implementer to

handle the case where a responder got BRI with the G bit

set and the A

bit not set? (I'm not asking for the draft to specify

that--it's just

a discussion point.)

[Ahmad]
Ok. I guess to close on this issue, It is fair to require that the 
responder send BRA only when the (A) bit is set.
Because, also, if the initiator did not set the (A) bit,

it may very

well not expecting a BRA and possibly NOT saving the BRI as an 
outstanding one to start with. Thanks; will make sure that is 
addressed as a global comment and will make sure that all

places are

fixed.



-S4, paragraph 2: "verify that the mobile access

gateway sending

the binding revocation indication message is authorized

to invoke

global revocation"

How does it make such a verification?

[Ahmad]
By checking the identity of the MAG if it is authorized

for global

revocation or not. Would a reference to section 9.2.1. makes it 
clearer or you think we need to add more clarification.


Actually, this is really more of a 9.2.1 issue. (I reviewed things
linearly.) I think a reference here would help, but note I

had similar

comments about 9.2.1 further down.

[Ahmad]
This should be addressed as part of the authorization

clarification.


-- Section 7.2, last paragraph: "If a mobility node receives a 
Binding Revocation Indication message with a Revocation Trigger 
value that is NOT in line with the Binding Revocation

Indication

message intent, e.g., the Global (G) bit set and the Revocation 
Trigger field vale is a per-MN specific, the receiving mobility 
node SHOULD reject the Binding Revocation Indication message by 
sending a Binding Revocation Acknowledgement message with the 
Status field set to "Revocation Function NOT Supported"."

This paragraph seems to imply some under-specification

around how

to tell the Revocation Trigger value is not in line with the 
initiator's intent.

Also, do you really mean to send "... not supported"?

This really

sounds like more of a "bad request" scenario.

Did you mean to capitalize the final "NOT"?

[Ahmad]
I thought it was a straight forward combination. If the

Global (G) bit

is set, the Revocation trigger field value MUST contain

one of the

Global revocation triggers. If the (G) bit is cleared, the

revocation

trigger MUST contain a per-MN value. Any deviation, means this 
functionality is not supported.


The text indicated those as examples. Are they the only scenarios 
where the trigger value can be out of line with the "intent"?

[Ahmad]
The valid combinations are:

Global Revocation==>>> (G) bit set and Revocation Trigger

= a Global

revocation trigger.
Per-MN Revocation ==>> (G) bit cleared and Revocation Trigger = a 
per-MN revocation trigger.

I guess
part of my problem is that "intent" is a vague term here. The 
important thing is to make sure that all legal combinations are 
specified. I think they may be later on (again, reviewing

linearly),

but they are scattered around the draft.

[Ahmad]
The Global Revocation Triggers are defined under section 6.1.

As far as why having "NOT" in capital letters, some

drafts have the

whole cause value in capital letters, but it is also meant

to say that

this is a bad request.


-- Section 7.3:

RFC3775 already talks about retransmission for Binding Update 
messages. Does this really need to be specified separately?

[Ahmad]
Yes. It is a separate protocol.


Okay.

-- 2nd paragraph: "SHOULD retransmit"

Can you offer guidance on when an implementation might

reasonably

not do this? (i.e. why not a MUST?)

[Ahmad]
Since sending a BRI message is NOT a MUST to start with,

I do not

believe that the retransmission needs to be mandated as a

"MUST". A

strong recommendation using "SHOULD" gives more

flexibility to the

initiator to retransmit based on the need and the scenario

at hand. In

addition, I did not see anywhere in RFC3775 or RFC5213 where 
retransmission is mandated.


A MUST retransmit if you don't get the ack to a BRI does

not in any

way imply MUST send a BRI.

[Ahmad]
A good point; but in RFC3775 and RFC5213 there is no MUST for 
retransmission either.
For example under section 6.9.4 of RFC5213, it says:

"
  2.  If the mobile access gateway fails to receive a

valid matching

      response for a registration or re-registration

message within

the
      retransmission interval, it SHOULD retransmit the

message until

a
      response is received.
"


In this case, my concern is that you have two ways to

decide not to

send a retransmission--one is that the value of

BRIMaxRetriesNumber

could be set sufficiently low (zero, I assume) to prevent 
retransmissions. The second is that the implementator could

choose not

to honor the SHOULD, even if BRIMaxRetriesNumber has a

higher value.

If you want to allow the latter, it would help to have some

guidance

(or examples) about scenarios where this would make

sense, and the

consequences of doing it.


[Ahmad]
I believe 'SHOULD" here is to offer the implementation more 
flexibility. A simple implementation could interpret 'SHOULD'
as always retransmits and moves on and still be compliant to the 
specification. Others may build more complex logics which

should not

be prevented.


-- S8.1, 3rd para after bullets: "home agent SHOULD handle this 
case based on the reason for sending the Binding Revocation 
Indication message and its local policy"

Is this entirely local policy? Is there no guidance to

offer about

how the "reason for sending" the BRI influences this

decision? If

it's really just local policy, then I'm not sure you need a 
normative statement (i.e. you SHOULD do whatever you choose to
do...)


[Ahmad]
The intention here is to make sure that the home agent take in 
consideration the reason for sending the BRI, i.e.,

Revocation Trigger

value and NOT to handle all of the BRI cases by applying

a single

reaction. For example, if the Revocation Trigger value

indicate an

administrative reason, then the HA probably have a lot of

options for

handling such a case. On the other hand, an inter-MAG handover 
Revocation Trigger value would probably require a more careful 
consideration.


A note to that effect would be helpful.

[Ahmad]
Sure, thx.


-- Last para: "SHOULD NOT"

Why not MUST NOT?

[Ahmad]

The problem we are trying to avoid here is: if we use "MUST NOT"
then we
need to specify the behavior of the receiving node in case it 
receives a BRI with all of the BID(s) included. Considering such 
case

as an error

scenario is probably not the best way. Allowing it, then

it is not

"MUST NOT" anymore.


On the contrary, it's not necessary to describe what the

responder has

to do for every possible violation of MUST level

requirements by the

initiator. But it _is_ necessary to do that for violations

of SHOULD

level requirements, because that is much more likely to

happen. So by

making this a SHOULD you've created more work on the part of the 
responder than if it were a MUST.

OTOH, if it really doesn't matter to the responder one way

or another,

then I'm not sure you need either.

BTW, It's not necessary for the responder to treat every MUST 
violation by the sender as an error--Postel's law should

applies here.

I suspect the real requirement is that the _receiver_ MUST

ignore any

BIDs if present, right?


[Ahmad]
No.
In this case, the mobile node may have registered multiple

bindings,

i.e., multiple care-of addresses for the same HoA.
Each bindings is assigned one Binding ID. Let us assume

that the MN

has BIDs(1, 2, 3, and 4) just for the sake of this discussion.

The home agent may send a BRI with [BIDs (1,4)], this

means ONLY BIDs

(1 & 4) are being revoked. 2 & 3 still active.
The home agent may send a BRI with [BIDs (1, 2, 3, & 4)] to revoke 
all of these 4 Bindings (In this case ALL Bindings).
Well, this is NOT recommended, the HA could have sent a

BRI with NO

BID(s) and accomplish the same result.


-- S 10.1.1, third bullet: "MUST send a Binding Revocation 
Acknowledgement"

So the G bit and the revocation trigger field value of

"per-peer

policy" is enough to require a BRA? Wouldn't this only

apply when

the A bit is set? (I know the initiator may have been

required to

set the A bit, but it seems wrong to expect the

responder to infer

that.)

[Ahmad]
This case a little similar to the "SHOULD NOT" case above.

If the (A)

bit is NOT set, what the receiving node should do. The

intention is

for
the MAG (responder) in the case of (G) revocation to always

send the

BRA
message.


This goes back to my previous comment. You require the

responder to

make complex decisions on whether to send a BRA, based on

the A-bit,

the G-bit, the responder role, etc. It would make life much easier
(read: less error prone) for the implementor if you could

make this

entirely dependent on a single flag.

[Ahmad]
Will fix this as pointed earlier.


-- S 11.1, bullet 2: "SHOULD send a Binding Revocation 
Acknowledgement"

Can you document reasons why a responder might not send

the BRA,

and the consequences thereof? In particular, are there

scenarios

where the initiator might go into retries because the responder 
chose not to send a BRA?

[Ahmad]
Sure.
In this bullet it says that if the mobile node receives a

BRI message

and the MN has an entry for the binding defined in the

received BRI,

then the MN MUST send a BRA. In other words, if the MN

successfully

process the BRI and still track this binding and still able

to send a

BRA, then it MUST send a BRA. In all other circumstances,

e.g., the MN

no longer tracking this binding, the MN received the BRI

and before

processing the battery went down and no BRA is sent

anyway, etc. The

whole idea is to make sure that the mandate on the

mobile node is

reasonable and within the mobile node abilities to send a BRA.
Otherwise, we would like to offer the mobile node a

reasonable excuse.

I don't think one needs to worry about scenarios such as "battery 
failed" in deciding to make a requirement a MUST or a

SHOULD. If we

did, it would not be possible to have _any_ MUSTs.

In this particular case, not sending the BRA appears to

do harm, in

that it may induce unnecessary retransmissions on the

sender's part.


-- same paragraph: "In all cases, the mobile node MUST follow 
Section 11.2"

Do you really mean  "in all cases"? This seems to

contradict the

SHOULD in the previous sentence, and the "If the A bit is set"
condition in the first sentence in the paragraph.


[Ahmad]
Yes. The bullet correctly reference section 11.2 which says:

"
11.2.  Sending Binding Revocation Acknowledgement

 When the mobile node receives a Binding Revocation

Indication from

 its home agent, the mobile node processes the received Binding  
Revocation Indication as in Section 11.1.  If the mobile

node is

required to send a Binding Revocation Acknowledgement

message in

response to the received Binding Revocation Indication,

the mobile

 node sends a packet to its home agent containing a Binding 
Revocation  Acknowledgement according to the procedure in Section

7.1 and the

 following:
"

The key text is: "If the mobile node is required to send a

BRA.." That

requirement is defined in the bullet you reference under

section 11.1.

So this is really an editorial issue then. The problem is in the 
phrase "in all cases". Putting "all cases" here, then a

loophole of

"if required" in the referenced section is confusing. I propose 
changing the sentence to say something to the effect of:

"In all cases where the MN sends a BRA, it MUST do so

according to

section 11.1"

[Ahmad]
Sure, will adopt this text.


-- Bullet 3: "mobile node MUST send"

Even if A bit is not set?


[Ahmad]
Please see response to the comment about processing the BRI

when the

(G)
bit is set, as described above.


... and please see my response.

[Ahmad]
Will be resolved as mentioned above.


-- same bullet: "mobile node SHOULD send a Binding Revocation 
Acknowledgement with the status field set to "Binding Does NOT 
Exist""

Even if A bit is not set?

[Ahmad]
:)
As you said earlier, it is inferred that is being set but

if it is not

being set, we need to specify the behavior of the MN. In

this case, it

is very important for the MN to send a BRA message and

inform the HA

that since BRI did not have the HoA IPv4 option, the MN can not 
identify the impacted binding. This is to give the HA an

indication

that it needs to resend BRI with the HoA IPv4 option included.


See my previous response about it being better to make explicit 
decisions on the A bit rather than inferences due to

other bits. In

this particular case, the sender has _already_ violated a

MUST if it

didn't set the A-bit. (And I assume that if it did not set

the A bit,

it probably isn't waiting for a BRA--otherwise it is

doubly broken).

Is it really that important for it to get the BRA under those 
circumstances?

[Ahmad
Will resolve as mentioned earlier above.


-- Bullet 4: "MUST silently discard the Binding Revocation 
Indication message"

Even if A bit is set?

[Ahmad]
In other words, this is a fatal error. When the (P) bit is

set, the MN

binding is for a proxy MIPv6 binding which SHOULD never be

sent to the

MN but to a MAG. In this case, the MN should silently

discard the

message.


-- S11.1, last paragraph: "could be used by the mobile node to 
define what action"

I think this could use some more guidance, if you expect

consistent

behavior across implementations.

[Ahmad]
Thanks. This probably was intentionally left like it is

because, it is

probably very difficult to get all implementations to agree on a 
common behavior. However, the text was meant as a reminder to

implementations

in order to take that in consideration.


Okay.

-- S 11.2, 2nd bullet: "The mobile node MUST set the

Status field

to an appropriate value. The mobile node sets the Status

field to

success to reflect that it has received the Binding Revocation 
Indication and acknowledge that its IP connectivity with

its home

agent has been revoked"

I think this is under-specified. In particular, is the

mobile node

allowed to set failure status values?

[Ahmad]
Yes, it could. E.g., if the MN received a BRI with

Revocation Trigger

value set to: a non supported value or "8  Possible

Out-of Sync BCE

State", the MN could send a BRA with status code set to failure.


Okay--I think adding a sentence or two that at least

indicates that it

sends a successful status on success, and sends an

appropriate error

status if an error occurs would help.

[Ahmad]
Sure, will add a note to that extent.


-- S 12: "BRI Maximum Number of Retries"

Why do you have both a max number of retries _and_ a max

timeout? I

gathered from previous sections that retries stop after

the backoff

hits max_brack-timeout. Did I read that wrong?

[Ahmad]
May be the name is misleading. What the "Maximum BRA

TIMEOUT" means is

the MAX time the initiator waits before it retransmits.

Here is the

text, please let me know if you have any suggestions for

modification.


"
Maximum BRA TIMEOUT (MAX_BRACK_TIMEOUT)

    This variable specifies the maximum delay timeout in seconds
    before the revoking mobility entity retransmits a

BRI message.

    The default is 2 seconds.
"


So it's the maximum interval between any two

retransmission, not the

maximum time before retransmissions stop, right? That is,

once you

reach MAX_BRACK_TIMEOUT you stop backing-off, but you may

continue to

send retransmissions at an interval of MAX_BRACK_TIMEOUT

until you

reach max retries? If so, it might be useful to add

something to the

effect of:

"Once the interval between retransmissions reaches

MAX_BRACK_TIMEOUT,

the exponential back-off will cease. If the total number of 
retransmissions has not yet reached BRIMaxRetriesNumber,

the sender

will continue to retransmit at intervals of

MAX_BRACK_TIMEOUT it does

so."

[Ahmad]
Sure. Thx.

I will respond to the rest of the comments separately in

order to make

it easier for audience to follow.
Many thanks again for the detailed comments.

Regards,
Ahmad


Thanks!

[Ahmad]
Thanks to your detailed review!


Ben.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

RE: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10