[no subject]

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

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

            jak



_______________________________________________
Seamoby mailing list
Seamoby at ietf.org
<a  href="https://www1.ietf.org/mailman/listinfo/seamoby";>https://www1.ietf.org/mailman/listinfo/seamoby</a>



</pre>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<hr>
<ul><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><a name="02777" href="msg02777.html">[Seamoby] Re: further comments on CARD version 8</a></strong>
<ul><li><em>From:</em> Marco Liebsch &lt;marco.liebsch@ccrle.nec.de&gt;</li></ul></li>
</ul></li></ul>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<ul>
<li>Prev by Date:
<strong><a href="msg02772.html">Re: [Seamoby] use of CTP for PANA: first issue</a></strong>
</li>
<li>Next by Date:
<strong><a href="msg02775.html">[Seamoby] CTP Draft will be published!!!!!!</a></strong>
</li>
<li>Previous by thread:
<strong><a href="msg02772.html">Re: [Seamoby] use of CTP for PANA: first issue</a></strong>
</li>
<li>Next by thread:
<strong><a href="msg02777.html">[Seamoby] Re: further comments on CARD version 8</a></strong>
</li>
<li>Index(es):
<ul>
<li><a href="maillist.html#02773"><strong>Date</strong></a></li>
<li><a href="threads.html#02773"><strong>Thread</strong></a></li>
</ul>
</li>
</ul>

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
</body>
</html>