some comments to version 7 of the CARD draft

James,
thanks for editing the latest CARD draft to address IESG comments.

Please find below some comments.

marco

----
section 4. CARD protocol operation
end of 3rd paragraph refers to a RESOLVER ERROR.
This status code is associated only with a L2-ID, not with a
signaling message. 
Proposal to modify:
"The current AR returns replies based on its CAR table (see 
Section 4.1), and returns a L2-ID with a status code
indicating RESOLVER ERROR (see Section 5.1.3.1) if this particular
L2-ID cannot be resolved.  (if this is meant with your new text here)

----
section 4. CARD protocol operation
6th paragraph: "The MN can additionally request from the AR 
a certificate chain..."
Same as above, the RESOLVER ERROR status code is available only in 
a L2-ID sub-option. 
Proposal A: Add a similar status code indication in a Trusted Anchor
sub-option, which could come back to the mobile and indicate that 
no cert chain has been found for the trausted anchor.
Proposal B: Remove the RESOLVER ERROR indication here.

Furthermore, the trusted anchor sub-option should not have a Context-ID,
since this anchor is associated with a mobile terminal, not with 
a CAR. So, here it makes no sense. 

last paragraph: correct typo:
"...The peer returns a CAR/+D+/ Reply message..."

This paragraph breaks the two paragraphs about use of the
Requirements and Preferences sub-option. 
Proposal: Move it to one paragraph later, where the examples
about Requirement and Preferences finish.

----
4.3.1 Current Access Router Operation
end of first paragraph: "An AR uses SCTP for CARD transport..."
Well, there is a dedicated section (5.2.1 Protocol Transport).
Use of SCTP is new, maybe important, maybe too heavyweight. Since
there is already 5.2.1, it should not be mentioned too often... 
Proposal: Delete this reference to SCTP here.

end of 2nd paragraph: "The receiving AR MUST increment the sequence
number of the CARD by one in the CARD Reply" 
Isn't it better to use the same sequence number in the Reply as received
in the Request to allow the requesting entity to associate the Reply
to a previiously sent request? This was actually the case in previous
version.

Here, I cannot say to which IESG comment this kind of modification
is related.

----
4.4 MN-AR Transport
This looks inconsistent and sections on protocol transport
should be covered either by chapter 4 or 5. Now it is split.
Proposal: Move this section to 5.1.1, similar to how it is
done for the AR-AR transport in 5.2.1.

Why has the retransmission scheme and the assocated protocol
constants changed? Use of exponential bakoff is ok.

These changes, I cannot associate with any IESG comment. 

----
5.1.1 CARD Main header format
Text about Valid Options:
"Router Certificate:
...in the chain for the AR or for a CAR from a trusted anchor to
the router..."
Shouldn't the cert be sent to the mobile?

----
5.1.3 Sub-options format
Table about interfaces:
Why is the Trusted Anchor sub-option used on the AR-AR interface?
I think it's used only between a MN and its AR.
Propoal: Remove the X for this interface (if my assumption is
correct)

----
5.2.1 Protocol Transport
UDP has been entirely replaced by SCTP. Well, I saw John's
mail about interoperability, but SCTP looks quite heavyweight
in some cases, at least if capability parameters are updated
very frequently.
Proposal: Shouldn't we add a paragraph that says:
Other transport protocols might perform better in some cases,
but appropriate failure recovery mechanisms must be specified if
not implicitely supported by this transport protocol... 

Use of SCTP has been proposed on the list, but cannot be associated 
with any IESG comment. 

----
5.1.3.6 Trusted anchor sub-option
As said above, use of a Context-ID is not required here.
Proposal: Remove Context-ID

----
5.1.3.7 Router Certificate Sub-option
This is probably the most critical issue:
The TLV-encoding of this option indicates length as units of
octets. Maybe 254 bytes are not really sufficient for a certificate.
Proposal: Difficult, if we change length unit to "units of 
8 octets", this might conflict with the overall length indicator
of the CARD Request/Reply, which is also in units of 8 octets.

----
6.3
General question w.r.t the protection of MN-AR CARD messages:
If CARD Reply messages are authenticated using the SEND
signature, how are CARD Requests authenticated by the ARs?