Re: further comments on CARD version 8

James Kempf wrote:

>Marco,
>
>Many thanks for your detailed comments. This is the kind of review that
>really helps improve the quality of IETF documents.
>Most of the comments were editorial and I incorporated them without change.
>
>There were two technical comments:
>
>  
>
>>same paragraph:
>>Question: How does the MN know about a lost message in a sequence of
>>CARD Reply messages? In case of retransmission, is the full block
>>retransmitted?
>>
>>    
>>
>
>Good question.
>
>I added back in the description of the L-flag. It is set on the last message
>of a multi-message reply. In addition, I added the following text to Section
>4.2.1:
>
>    A MN uses exponential backoff to retransmit the CARD Request
>    in the event a CARD Reply is not received within CARD_REQUEST_RETRY
>    seconds. The retransmitted CARD Request MUST have the same sequence
>number
>    as the original.With the exception of certification paths, which are
>large by nature, an
>    AR SHOULD attempt to limit the information in a CARD Reply to a single
>message.
>    Should that not be possible, the AR MAY send the reply in multiple
>messages. The
>    last message of a reply MUST always have the L-flag set in the CARD
>Reply option to
>    indicate that the message is the last for the associated sequence
>number. An AR
>    retransmitting the CARD Request MUST always send the full CARD Reply.
>  
>
ARs do not retransmit CARD Requests but CARD Replies. What about:
" An AR retransmitting replies to a CARD Request MUST always send the 
full CARD Reply sequence."

Well, obviously keeping the protocol simple is a design goal. For that 
it's fine to
retransmit the full sequence. However, this does not solve the issue to 
allow MN's
detecting a particluar lost message in a reply sequence. Hence, what 
about the following:
Allow ARs, which reply a sequence of CARD Reply messages to a CARD 
Request, to
increase Sequence Numbers of CARD Replies, but starting the with the 
same sequence number
as in the request. With the help of the L-flag this allows detection of 
the sequences' end
AND of a missing segment in between. Further, this still allows 
correlation of Requests with
Replies on the MN, since the first Reply matches the Request's sequence 
number.

Only remaining issue is in case the first CARD Reply message of a 
sequence gets lost, but the second is
received, having the sequence number incremented. This should be ignored 
then by the MN and
the CARD Request should be retransmitted according to the procedure 
described in section 4.2.1.

Did I miss something?
What do you think?


>The Trusted
>    Anchor sub-option and the Router Certificate sub-option provide a means
>whereby the
>    MN can request specific certificates in a certification path, in the
>event that the CARD Reply
>    carrying a certification path spans multiple messages and one of them is
>lost. However, a
>    request for specific certificates that were not received in the initial
>CARD Reply MUST
>    be treated as a new request by the MN and MUST use a different sequence
>number.
>
>Does this sound OK?
>
>  
>
>>In general: setting of sequence numbers:
>>Is it correct that the MN should randomly choose whereas the
>>AR should start with 0 and increment? Is this how you want it?
>>
>>    
>>
>
>Yes. The AR-AR interface may involve periodic updates, and there will be a
>longer term relationship. Theoretically, the sequence number could be
>dropped on the AR-AR interface, because SCTP takes care of it, but it's kept
>in for consistency. With the MN-AR interface, the MN may handover to another
>AR, then come back. Maintaining sequential sequence numbers under those
>conditions is awkward.
>
>Do you see any problem with this?
>
>  
>
Ok, thanks for clarification.

marco

>I'll add these two issues to the issue tracker.
>
>            jak
>
>
>  
>