Gabriel,
At 02:32 AM 6/2/2004, gabriel montenegro wrote:
[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.
Yes, I agree in this case it would be better to get individual assignments.
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.
The thinking behind the assignment strategy in the IANA considerations section of the draft is that the there isn't that many current assignments and if we should get to the point of running out of assignments, it would be easy to extend the space by using the type=255 value.
I am not sure it is necessary to deal with an extension mechanisms at this point in time. As you pointed out there are only 23 current assignments.
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.
Agreed.
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).
It was my understanding that one could use the RFC2434 language, or if one wanted to do something more specific then it wasn't required. I could be wrong about this.
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.
Right, we are proposing an approach that was somewhat different from the RFC2434 language in that the main requirement for an assignment was a published specification, not the documents standardization status.
Bob
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
