Re: CARD: Modification in resolution to issues #49 and #51

Marco,

> Why do you propose to drop the context-ID? It allows assignment of L2-ID
> with an IP address
> sub-option and with a capability container. If a capability container
> for a CAR is transmitted in a
> subsequent reply message (according to the mechanism proposed below,
> this allows the mobile
> to identify which L2-ID, IP and Capability Container info belongs to
> which CAR.
> If you propose to convey only information of one CAR in one CARD Reply
> message
> and it's for sure that no further information for this CAR comes in
> subsequent reply messages,
> the Context-ID can at least identify information that belongs together.
> And if the cert in not sent in a reply message, multiple CARs' info can be
> conveyed in one reply. Here you need the context-ID. So, you should not
> drop it.
>

I'm not proposing to drop the Context-ID in general, just for the Router
Certificate sub-option. The full proposal is: one and only one certificate
per CARD reply, along with the L2-ID sub-option sent in the request, and the
corresponding router's Address sub-option. If there are more certs than one,
they are sent in subsequent CARD reply messages, until the full chain is
sent. The last cert has a flag set indicating it is the last message.

> >- If more than one certificate is required, the router sends multiple
CARD
> >Reply Messages.
> >
> >
>
> >- Add a flag indicating if the certificate is the last one to be sent.
The
> >host should be able to deduce this by whether the chain is complete.
> >
> >
> >
> What's the rule here for setting sequence numbers in multiple CARD
> Replies? Should be the same
> for all replies associated with one request, right?
>

Yes. Perhaps the flag should indicate that the message is one of a sequence,
rather than the last one. This would allow the MN to know it must wait for
the rest (though it would know that from the chain in any case).

> >In addtion, the following modification is advisable, since X.500 names
used
> >for certificates can be long:
> >
> >- Modify the units for the Trusted Anchor option from octets to 8 octets.
> >
> >issue-#51: Version number needed.
> >
> >The TLV format of the ND options won't allow the version number to be put
> >into the lower bits of the option type, since the type is assigned by
IANA.
> >
> >The following is a modification of the resolution to meet these
constraints;
> >
> >- Put the 3 bit version number immediately after the T and L fields,
which
> >are specified by RFC 2461.
> >
> >
> >
> Why exactly 3 bit for the version number?  The first 32 bit will look like
> Type(8bit), Length(8bit), version(3bit),reserved(5bit), P,C,A(flags,
> each 1bit), reserved(5bit)...
>
> alternatively use 8 bit for the version number, which is redundant, but
> assigns a byte for
> a nuber identifier. This would look like
> Type(8bit), Length(8bit), version(8bit), P,C,A(flags, each 1bit),
> reserved(5bit)...
>

We could do that. The inter-router CARD messages had 4 bits, but we could
make it 8 as well. I only made it 3 because I can't see CARD going to more
than 8 versions (most protocols usually max out at 3 versions). The basic
reason is that CTP has a 3 bit version number that is part of the message
type (no ICMP option constraints there) so I thought to do the same here for
consistency.

            jak