Senthil,
[Senthil2] There is already an entry in IPFIX IANA registry for
natEvent. There are 3 events (create/delete/pool exhausted) defined
there. So I will add text to point to IPFIX IANA registry.
I assume I have to add the additional events to the IANA
considerations section of this draft to have IANA assign these.
However, I am not clear how do I request these new values for
natEvent. Is the following the right format to ask for the new values?
Name : natEvent
Description: This Information Element identifies an Instance of the
NAT that runs on a NAT middlebox function after the packet passed the
Observation Point.
Abstract Data Type: unsigned8
Data Type Semantics: identifier
Element ID : 230
New values requested : The values 4-16 are requested as described in Table
2.
Reference:
See RFC 3022 [RFC3022] for the definition of NAT. See RFC
3234 [RFC3234] for the definition of middleboxes.
For clarity, it might help to break your IANA Considerations into two
sub-sections: New Information Elements, and Modified Information
Elements. Obviously this one is the only entry in the latter section.
The description is wrong! Use the existing #230 description.
Please list the values from Table 2 here directly because this text will
be extracted into IANA's registry, so it has to make sense stand-alone,
outside of the RFC-to-be.
So you should also add "See [thisRFC] for the definitions of values
4-16." to the Reference section.
One concern I have is how to resolve the apparent conflict between the
existing natEvent create/delete values which seem to be generic, and
your proposed interpretations in Table 2 which are NAT44 specific. For
backwards compatibility, it might be better to recognise that values 1
and 2 may have been used historically for any kind of NAT create/delete,
and assign new values for the NAT44 and NAT64 specific events. You could
even request that the old create and delete events now be considered as
deprecated.
P.