Hi Rajeev,
Rajeev Koodli wrote:
I agree. We had this requirement in an earlier version of the CARD draft as part of theHi Jim,
I was going over the CARD protocol, mainly with the piggybacking of
CARD Options using the FMIPv6 proxy messages. For piggybacking
to work, the Type value for CARD Request and CARD Reply Must Not
collide with the "Option-Type" assignments in FMIPv6. Currently, there
are only 3 values assigned in FMIPv6.
The "Seamoby IANA Allocations" draft leaves CARD Request and Reply
with TBD9 and TBD10. I think we should request them to assign
9, 10 or some higher number like that. We do not need to co-ordinate the
Sub-options assignments.
The initial discovery of piggybacking capability is required at the very beginning withoutAlso, why not send a RtSolPr with the CARD Request Option and Sub-options and see if the router replies, instead of using a probing mechanism to discover "piggybacking". I know this is too late, but a thought nevertheless.
Thanks and regards, marco
Regards,
-Rajeev
James Kempf wrote:
I've edited draft-08 for CARD inserting a few suggested changes by Marco and Ajoy. Candidate 2 is available at:
http://www.geocities.com/kempf42/draft-ietf-seamoby-card-protocol-08-cand2.txt
Please take a look. If I don't hear anything from anyone by next Fri., Sept. 10, I will send the draft to the IESG.
jak
_______________________________________________
Seamoby mailing list
Seamoby at ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby
_______________________________________________
Seamoby mailing list
Seamoby at ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby
_______________________________________________ Seamoby mailing list Seamoby at ietf.org https://www1.ietf.org/mailman/listinfo/seamoby