RE: [IPFIX] ipfix reducing redundancy

"Template Withdrawal Messages SHOULD NOT be sent over UDP."

"Template Withdrawal Messages SHOULD NOT be sent over UDP."

Here are  two questions about the ipfix reducing redundancy draft:

Section 5.1 SCTP - The Common Properties Flow Records MUST be sent on a
reliable SCTP stream.
Does this  mean PR-SCTP is not one of the transport protocol choice?  

	OLD: If SCTP is selected as the IPFIX protocol, the SCTP sub-section 
   specifications MUST be respected.

	New: If PR-SCTP is selected as the IPFIX protocol, the SCTP sub-section 
   specifications MUST be respected.

Then the following sentence would make sense in section 5.1:
   "The Common Properties Flow Records MUST be sent on a reliable SCTP 
   stream. "

Regards, Benoit. 

Is there need some description of how to use PR-SCTP in this draft?

Thanks
Yuzhi

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.org/mailman/listinfo/ipfix

Here are  two questions about the ipfix reducing redundancy draft:

Section 5.1 SCTP - The Common Properties Flow Records MUST be sent on a
reliable SCTP stream.
Does this  mean PR-SCTP is not one of the transport protocol choice?  

	OLD: If SCTP is selected as the IPFIX protocol, the SCTP sub-section 
   specifications MUST be respected.

	New: If PR-SCTP is selected as the IPFIX protocol, the SCTP sub-section 
   specifications MUST be respected.

Then the following sentence would make sense in section 5.1:
   "The Common Properties Flow Records MUST be sent on a reliable SCTP 
   stream. "

Regards, Benoit. 

Is there need some description of how to use PR-SCTP in this draft?

Thanks
Yuzhi

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.org/mailman/listinfo/ipfix

Here are  two questions about the ipfix reducing redundancy draft:

Section 5.1 SCTP - The Common Properties Flow Records MUST be sent on a
reliable SCTP stream.
Does this  mean PR-SCTP is not one of the transport protocol choice?  

	OLD: If SCTP is selected as the IPFIX protocol, the SCTP sub-section 
   specifications MUST be respected.

	New: If PR-SCTP is selected as the IPFIX protocol, the SCTP sub-section 
   specifications MUST be respected.

Then the following sentence would make sense in section 5.1:
   "The Common Properties Flow Records MUST be sent on a reliable SCTP 
   stream. "

Regards, Benoit. 

Is there need some description of how to use PR-SCTP in this draft?

Thanks
Yuzhi

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.org/mailman/listinfo/ipfix

Here are  two questions about the ipfix reducing redundancy draft:

Section 5.1 SCTP - The Common Properties Flow Records MUST be sent on a
reliable SCTP stream.
Does this  mean PR-SCTP is not one of the transport protocol choice?  

	OLD: If SCTP is selected as the IPFIX protocol, the SCTP sub-section 
   specifications MUST be respected.

	New: If PR-SCTP is selected as the IPFIX protocol, the SCTP sub-section 
   specifications MUST be respected.

Then the following sentence would make sense in section 5.1:
   "The Common Properties Flow Records MUST be sent on a reliable SCTP 
   stream. "

Regards, Benoit. 

Is there need some description of how to use PR-SCTP in this draft?

Thanks
Yuzhi

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.org/mailman/listinfo/ipfix

- 10.2.4.3: "Data Sets from multiple Observation Domains MUST NOT be transmitted over the same stream; the Collecting Process SHOULD however verify that the Observation Domain ID values are the expected values."   
What is the collecting process supposed to do with other ODID values then? Drop them? --> Specify.

Here is the proposal: 
Any objections on this clarifying sentence?

Regards, Benoit. 

- 10.2.4.3: "Data Sets from multiple Observation Domains MUST NOT be transmitted over the same stream; the Collecting Process SHOULD however verify that the Observation Domain ID values are the expected values."   
What is the collecting process supposed to do with other ODID values then? Drop them? --> Specify.

Here is the proposal: 
Any objections on this clarifying sentence?

Regards, Benoit. 

There are also security concerns; it was suggested since most of our
security concerns are the same as syslog's, we should consider
adopting their approach to security.
Hi Bora:

Seems to me it would be very useful for the WG to have someone write
a set of IPSEC configs that could be used with IPFIX.  Could you
manage to write a few paragraphs that might be used in the Protocol
Draft Security Considerations section, showing *how* one would
set up IPSEC to run IPFIX, especially how to use IPSEC for IPFIX over an
SCTP-PR transport ?

Cheers, Nevil

On Tue, 2006-09-12 at 08:44 -0700, Bora Akyol wrote:

I also wrote quite a bit of IPSEC and IKE code that runs on a large
percentage of routers and switches out there today.

Let me know if you have any specific questions on IPSEC/IKE
configuration and I will see what I can do to help you.

-----------------------------------------------------------------------
   Nevil Brownlee                 Computer Science Department | ITSS
   Phone: +64 9 373 7599 x88941           The University of Auckland
   FAX: +64 9 373 7453      Private Bag 92019, Auckland, New Zealand

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.org/mailman/listinfo/ipfix

There are also security concerns; it was suggested since most of our
security concerns are the same as syslog's, we should consider
adopting their approach to security.
Hi Bora:

Seems to me it would be very useful for the WG to have someone write
a set of IPSEC configs that could be used with IPFIX.  Could you
manage to write a few paragraphs that might be used in the Protocol
Draft Security Considerations section, showing *how* one would
set up IPSEC to run IPFIX, especially how to use IPSEC for IPFIX over an
SCTP-PR transport ?

Cheers, Nevil

On Tue, 2006-09-12 at 08:44 -0700, Bora Akyol wrote:

I also wrote quite a bit of IPSEC and IKE code that runs on a large
percentage of routers and switches out there today.

Let me know if you have any specific questions on IPSEC/IKE
configuration and I will see what I can do to help you.

-----------------------------------------------------------------------
   Nevil Brownlee                 Computer Science Department | ITSS
   Phone: +64 9 373 7599 x88941           The University of Auckland
   FAX: +64 9 373 7453      Private Bag 92019, Auckland, New Zealand

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.org/mailman/listinfo/ipfix

   New Template Records SHOULD be transmitted as soon as they are 
   created. The Exporting Process MAY transmit the Template Set and 
   Options Template Set in advance of any Data Sets that use that 
   (Options) Template ID, to ensure that the Collector has the Template 
   Record before receiving the first Data Record.  Data Records that 
   correspond to a Template Record MAY appear in the same and/or 
   subsequent IPFIX Message(s).   

NEW PARAGRAPH SECTION 8, 6th PARAGRAPH:

   When IPFIX uses UDP as the transport protocol, Template Sets and 
   Option Template Sets MUST be re-sent at regular intervals.  The 
   frequency of (Options) Template transmission MUST be configurable.  
   New Template Records SHOULD be transmitted as soon as they are 
   created, and SHOULD be transmitted before any associated Data Record 
   is transmitted. 

NEW 1ST PARAGRAPH 10.3.6 "template management" for UDP:

OLD 2ND PARAGRAPH 10.3.6 "template management" for UDP:

   In the event of configuration changes, the Exporting Process SHOULD 
   send multiple copies of the new template definitions, in different 
   IPFIX Messages, at an accelerated rate.  In such a case, it MAY 
   transmit the changed Template Record(s) and Options Template 
   Record(s), without any data, in advance to help ensure that the 
   Collector will have the correct template information before 
   receiving the first data.  

NEW 2ND PARAGRAPH 10.3.6 "template management" for UDP:
Regards, Benoit. 
   New Template Records SHOULD be transmitted as soon as they are 
   created. The Exporting Process MAY transmit the Template Set and 
   Options Template Set in advance of any Data Sets that use that 
   (Options) Template ID, to ensure that the Collector has the Template 
   Record before receiving the first Data Record.  Data Records that 
   correspond to a Template Record MAY appear in the same and/or 
   subsequent IPFIX Message(s).   

NEW PARAGRAPH SECTION 8, 6th PARAGRAPH:

   When IPFIX uses UDP as the transport protocol, Template Sets and 
   Option Template Sets MUST be re-sent at regular intervals.  The 
   frequency of (Options) Template transmission MUST be configurable.  
   New Template Records SHOULD be transmitted as soon as they are 
   created, and SHOULD be transmitted before any associated Data Record 
   is transmitted. 

NEW 1ST PARAGRAPH 10.3.6 "template management" for UDP:

OLD 2ND PARAGRAPH 10.3.6 "template management" for UDP:

   In the event of configuration changes, the Exporting Process SHOULD 
   send multiple copies of the new template definitions, in different 
   IPFIX Messages, at an accelerated rate.  In such a case, it MAY 
   transmit the changed Template Record(s) and Options Template 
   Record(s), without any data, in advance to help ensure that the 
   Collector will have the correct template information before 
   receiving the first data.  

NEW 2ND PARAGRAPH 10.3.6 "template management" for UDP:
Regards, Benoit. 
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. 
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. 