Subject: Re: [IPFIX] Request new IPFIX information elements for NAT/FW

From: Benoit Claise <[email-masked]>
Date: Mon, 25 Sep 2006 12:19:59 +0200

Paul, 

I think this I.E. list should be inserted by Juergen at 
http://ipfix.netlab.nec.de/infoElements.php?PAGE=Elements, as described 
by 
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-implementation-guidelines-00.txt 

    9.1 Adding new IETF specified Information Elements 
        
       New IPFIX Information Elements that are considered to be of general 
       interest SHOULD be added to the set of IETF specified Information 
       Elements that is maintained by IANA. 
        
       The introduction of new Information Elements in the IANA registry is 
       subject to expert review. As described in [RFC2434] an expert review 
       is performed by one of a group of experts designated by an IETF 
       Operations and Management Area Director. The experts will initially 
       be drawn from the Working Group Chairs and document editors of the 
       IPFIX and PSAMP Working Groups. The group of experts must double 
       check the Information Elements definitions with already defined 
       Information Elements for completeness, accuracy, redundancy, and 
       correct naming following the naming conventions in [IPFIX-INFO] 
       section 2.3. 
        
       The specification of new IPFIX Information Elements MUST use the 
       template specified in [IPFIX-INFO] section 2.1 and MUST be published 
       using a well established and persistent publication medium.  
        
       Until IANA has created this registry, the list of IETF specified 
       Information Elements will be administered by the IPFIX working 
       group. For this purpose, the IPFIX working group maintains a web 
       site at http://ipfix.netlab.nec.de/infoElements.php that shows the 
       current list of IPFIX Information Elements and their specifications 
       and that gives instruction for requesting new Information Elements 
       to be added. The IPFIX Working Group will also take care of the 
       review process for requested new Information Elements until IANA has 
       created the registry and the process described in the previous 
       paragraphs becomes effective. 

I also think that this text should include something such as: "the main 
goal of this procedure is to assign the I.E. id for the in-progress 
implementations, while the definition is optimized" Or any sentence that 
has got the similar goal...

Regards, Benoit.
> Dear all,
>
> We'd like to request the following new IPFIX IE's for NAT and FW:
>
>
> Name:                natOrigInsideAddr
> Description:         The original IPv4 inside address.
> Group:               NAT
> Abstract Data Type:  ipv4Address
> Data Type Semantics: identifier
> Units:               n/a
>
> Name:                natTransInsideAddr
> Description:         The translated IPv4 inside address.
> Group:               NAT
> Abstract Data Type:  ipv4Address
> Data Type Semantics: identifier
> Units:               n/a
>
> Name:                natOrigOutsideAddr
> Description:         The original IPv4 outside address.
> Group:               NAT
> Abstract Data Type:  ipv4Address
> Data Type Semantics: identifier
> Units:               n/a
>
> Name:                natTransOutsideAddr
> Description:         The translated IPv4 outside address.
> Group:               NAT
> Abstract Data Type:  ipv4Address
> Data Type Semantics: identifier
> Units:               n/a
>
> - Also equivalent elements for IPv6 addresses, if deemed necessary.
>
>
> Name:                natOrigInsidePort;
> Description:         The original inside port.
> Group:               NAT
> Abstract Data Type:  unsigned16
> Data Type Semantics: identifier
> Units:               n/a
>
> Name:                natTransInsidePort;
> Description:         The translated inside port.
> Group:               NAT
> Abstract Data Type:  unsigned16
> Data Type Semantics: identifier
> Units:               n/a
>
> - Alternatively, create just one of these and overload 
> sourceTransportPort, clearly indicating whether this should be the 
> original or translated port.
>
>
> Name:                natOrigOutsidePort;
> Description:         The original outside port.
> Group:               NAT
> Abstract Data Type:  unsigned16
> Data Type Semantics: identifier
> Units:               n/a
>
> Name:                natTransOutsidePort;
> Description:         The translated outside port.
> Group:               NAT
> Abstract Data Type:  unsigned16
> Data Type Semantics: identifier
> Units:               n/a
>
> - Alternatively, create just one of these and overload 
> destinationTransportPort, clearly indicating whether this should be 
> the original or translated port.
>
>
> Name:                natEvent
> Description:         Indication of the NAT creation / deletion event.
> Group:               NAT
> Abstract Data Type:  unsigned16
> Data Type Semantics: identifier
> Units:               n/a
>
> Name:                fwInitiatorOctets
> Description:         No. of bytes sent by the initiator.
> Group:               counter
> Abstract Data Type:  unsigned64
> Data Type Semantics: quantity
> Units:               n/a
>
> Name:                fwResponderOctets
> Description:         No. of bytes sent by the responder.
> Group:               counter
> Abstract Data Type:  unsigned64
> Data Type Semantics: quantity
> Units:               n/a
>
> - Also the corresponding delta counters, if deemed necessary.
>
>
> Name:                fwEvent
> Description:         Indication of the FW audit trail event.
> Group:               firewall
> Abstract Data Type:  unsigned8
> Data Type Semantics: identifier
> Units:               n/a
>
>
> Thanks.
>

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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 25 Sep 2006 12:19:59 +0200

Paul, 

        

        

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 27 Sep 2006 10:21:48 +0200

Hi Paul and Benoit,

--On 25.09.2006 12:19 Uhr +0200 Benoit Claise wrote:

> http://ipfix.netlab.nec.de/infoElements.php?PAGE=Elements, as described by

Yes, I will put the proposed IEs these with status 'under discussion'

> implementations, while the definition is optimized" Or any sentence
> that has got the similar goal...

I don't see a problem with reserving some identifiers for proposed IEs
that do not have a reasonable specification yet.  These identifiers would
be excluded from being assigned to other IEs.

But for really assigning IEs we definitely should not circumvent expert
review which requires a clear specification and (a clear plan for)
persistent publication of the proposed IE as described in the IANA
considerations of the info model draft.

Thanks,

    Juergen

> - Alternatively, create just one of these and overload sourceTransportPort, clearly indicating whether this should be the original or translated port.
>
>
> - Alternatively, create just one of these and overload destinationTransportPort, clearly indicating whether this should be the original or translated port.
>
>
> Name:                natEvent

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 27 Sep 2006 10:21:48 +0200

Hi Paul and Benoit,

Thanks,

    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Wed, 27 Sep 2006 11:29:32 +0200

Juergen,
> considerations of the info model draft.
That makes perfect sense to me. Thanks.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 27 Sep 2006 11:29:32 +0200

Juergen,

Regards, Benoit.