Subject: [Seamoby] [CARD Editorial Issue] IANA Considerations Section

From: "James Kempf" <[email-masked]>
Date: Tue, 1 Jul 2003 15:20:15 -0700

In general, ICMP messages do not have options. Messages that are part of
Neighbor Discovery (RFC 2461/62) ICMP messages do have options, however.

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.

If you want to have the option types come out of the ND space, then the IANA
considerations should say that.

Also, IETF concensus is not needed to assign a new port number. IANA can do
that.

            jak

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

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 02 Jul 2003 12:55:31 +0200

>Neighbor Discovery (RFC 2461/62) ICMP messages do have options, however.
Fast-MIPv6 messages are ICMP-style as well, and they carry options.

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

>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
Ok, we can change this in the draft.

marco

>            jak

-

---

From: "James Kempf" <[email-masked]>
Date: Wed, 2 Jul 2003 08:51:37 -0700

> Fast-MIPv6 messages are ICMP-style as well, and they carry options.

Please show me in RFC 2463 where general ICMP messages are allowed to carry
options.

RFC 2461 does define options for the specific case of neighbor discovery
ICMP messages, in Section 4.6. And, I believe the RtSolPr/PrRtAdv messages
are intended to be a subset of those messages.

> there should not be a conflict in options' types.

So does RFC 2461 say that IETF concensus is required to assign option
numbers for ND options?

            jak