[EMAIL PROTECTED] wrote:
Please look at section 2.1 (Message General Format). The section
adds type 100, 101, 200 and 201 for private experimentation. Also
section 6 (IANA consideration) describes a policy on allocating
reclaimable ICMP type and code values.
Hi,
Not sure we can use 100,101,200 or 201. From the draft:
It is
expected that multiple concurrent experiments will be done with the
same type values.
Beyond very limited usage within a lab or a specific site, I don't
believe these can be used safely. For example, I hear rumors about
impending FMIPv6 deployments, in which case these codes would not
really work.
So we're left with:
Any wide scale and/or uncontrolled usage should
obtain real allocations as defined in section 6.
We're certainly in this category. But you also define
Type 255 for future assignment in case of shortage. What
we're proposing is a way of doing such extended typing.
Is this going to help your work ??
Well, it supports our work, because we can obtain a new assignment.
Nothing to add to your draft.
I think the question is more the other way around:
Given that we're adopting our format for our own
protocols, would this be useful for others as well?
I don't believe the ICMPv6 draft needs to be modified in this
respect, though. We're just suggesting a new assignment and
how to handle it (as allowed by your draft). So we currently fall within
item #2 of your IANA considerations section (assignments with the
reclaimable tag), and moving soon to item #1 (permanent
assignment), because CARD/CTP and FMIPv6 will be going soon to experimental
RFC's.
Please review the relevent sections of the draft and let me know if
making any changes to the draft will solve your purpose.
I did notice the absence of RFC2434 language in your draft, and
I'd suggest using it for clarity and consistency with other IANA
sections or documents (e.g., rfc2780).
For example, in your IANA section,
item 3 seems to map to "specification required" or "IESG approval".
I'm not as clear with respect to item 1. At first sight,
it would seem to map to "standards action", but actually it
differs as you specifically include non-standards track documents
(e.g., experimental). It is because of your support for experimental
RFC's that our seamoby/FMIPv6 assignment is supported.
-gabriel
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
