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

Ajoy,

I see no problem with keeping the Context ID field in the Router Certificate
option if you think it is important, even though it isn't necessary for
certs if there will be only one cert per message. It is only one byte and if
we are allowing multiple messages for large chains, there should be enough
room.

Agree with keeping the same sequence number, and we can make the header bit
in the CARD Reply indicate the last message.

            jak

----- Original Message ----- 
From: "Singh Ajoy-ASINGH1" <[email protected]>
To: "'James Kempf '" <[email protected]>; <[email protected]>;
"'Marco Liebsch '" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, May 27, 2004 10:03 PM
Subject: RE: [Seamoby] 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
>