James,
I also have a basic question on the partitioning of the ICMP code space into error and informational messages, as described in Section 2.1 of your draft.
The partitioning of the ICMP type values has been around in all of the ICMPv6 RFCs. This draft is updating RFC2463 currently at Draft Standard.
While this partioning is valid for the types you describe in the draft, I think it misses the additional function of ICMP in IPv6 involving signaling on the local link that may cause state changes in the node. "Error" and "informational" to me don't imply any state change in the node. Such state change is caused by, for example, RS with a Link Address option (router's Neighbor Cache is updated), ND for DAD (could cause tentative IP address to become confirmed or not), and, in the current case, Seamoby CTP (initiate transfer of feature context between routers) and FMIP (initiate local routing change and update router Neighbor Cache with mobile node's IP address).
I tend to agree that many of the assignments in the "informational" part of ICMPv6 type values are doing more than providing information. I think the "informational" term at best only apples to the functions in the ICMP specification and not the other protocols using the type assignments. It might have been clearer if we used a different word than "informational", but I personally don't see very much value changing it at this point in time.
Bob
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
