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
Hi 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. Also, 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. 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.(Continue reading)
Hi Rajeev, > 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. > Since the CARD ICMP options and the FMIP options are being assigned out of the same ICMP option numbering space, there should be no need to request any particular assignment from IANA. They will co-ordinate such that there is no clash between the two. Off the top of my head, I can't think why any particular numbers for CARD should be preferred to any others, but if there's something I'm missing, we can send a special request to IANA for particular numbers. > Also, 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. > I'd prefer not to change the draft at this point. As of this weekend, we have agreement from Alex Zinn to remove his Discuss and Allison is ready to send it to the draft to the RFC Editor for publication as soon as we submit(Continue reading)
James Kempf wrote: > > Since the CARD ICMP options and the FMIP options are being assigned out of > the same ICMP option numbering space, there should be no need to request any > particular assignment from IANA. They will co-ordinate such that there is no > clash between the two. Off the top of my head, I can't think why any > particular numbers for CARD should be preferred to any others, but if > there's something I'm missing, we can send a special request to IANA for > particular numbers. > I was not aware that IANA will take care of this. FMIPv6 defines a registry for the options. I just want to make sure that piggybacking, fwiw, is still possible. -Rajeev > > > Also, 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. > > > > I'd prefer not to change the draft at this point. As of this weekend, we > have agreement from Alex Zinn to remove his Discuss and Allison is ready to > send it to the draft to the RFC Editor for publication as soon as we submit > version 8.(Continue reading)
Hi Rajeev, Rajeev Koodli wrote: >Hi 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. > > I agree. We had this requirement in an earlier version of the CARD draft as part of the IANA considerations section. Since these have been shortened for CTP and CARD and incorporated into the consolidated Seamoby IANA allocations document, we should of course keep mentioning this to avoid conflicts. >Also, 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. >(Continue reading)
RSS Feed