Re: [CARD Editorial Issue] IANA Considerations Section

James Kempf wrote:

>In general, ICMP messages do not have options. Messages that are part of
>Neighbor Discovery (RFC 2461/62) ICMP messages do have options, however.
>  
>
Fast-MIPv6 messages are ICMP-style as well, and they carry options.

>In this case, there is no need for IETF concensus to assign suboption types
>to a new ICMP message. They can just be assigned in the draft.
>  
>
This is right assuming the case to keep CARD protocol operation 
stand-alone. In case of carrying
CARD protocol messages as options with the Fast-MIPv6 RtSolPr ot PrRtAdv 
respectively,
there should not be a conflict in options' types.

>If you want to have the option types come out of the ND space, then the IANA
>considerations should say that.
>  
>
That's another issue: In case we allow other protocols to carry CARD 
specific options, as currently
discussed for Fast-MIPv6, actually we could allow some ND protocol 
messages to carry them as well,
like the Router Solicitation and Advertisement. This is to be discussed now.
If this should be supported, we can take this over to the IANA section.

>Also, IETF concensus is not needed to assign a new port number. IANA can do
>that.
>
Ok, we can change this in the draft.

marco

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

-