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

James,
Please find my inline comments.
Regards,
Ajoy 

-----Original Message-----
From: [email protected]
To: Marco Liebsch
Cc: [email protected]
Sent: 5/25/04 4:49 PM
Subject: Re: [Seamoby] 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.

AJOY->I tend to agree with Marco on this issue. Can't we continue to keep context-id even when only one Router Certificate sub-option is being sent in a CARD Reply Message due to size limitation? I propose to keep the content of CARD Request message unchanged as described in the current draft.  When AR is not able to accommodate the content of all the sub-options generated for a given CARD Request message in a single CARD Reply message, it may send multiple CARD Reply Messages (as proposed by James). But all the CARD Reply messages generated for a given CARD Request should have same sequence number. Also, we may add a bit in the CARD Reply Message header that may indicate the last CARD Reply associated with a given CARD Request message.  Any Comments?



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



_______________________________________________
Seamoby mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/seamoby