headers
RFC Errata System | 25 May 13:48
Favicon

[IPFIX] [Technical Errata Reported] RFC6313 (3232)


The following errata report has been submitted for RFC6313,
"Export of Structured Data in IP Flow Information Export (IPFIX)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6313&eid=3232

--------------------------------------
Type: Technical
Reported by: Paul Aitken <paitken <at> cisco.com>

Section: 4.5.3

Original Text
-------------
   In the exceptional case of zero instances in the
   subTemplateMultiList, no data is encoded, only the Semantic field and
   Template ID field(s), and the Data Record Length field is set to
   zero.

Corrected Text
--------------
   In the exceptional case of zero instances in the
   subTemplateMultiList, no data is encoded, only the Semantic field and
   Template ID field(s), and the Data Records Length field is set to
   four.

Notes
-----
(Continue reading)

Permalink | Reply | 0 comments |
headers
Romascanu, Dan (Dan | 24 May 17:00
Favicon

[IPFIX] WGLC Comments on draft-ietf-ipfix-ie-doctors

Hi,

Please find below my Working Group Last Call comments on
draft-ietf-ipfix-ie-doctors-02:

1. Editorial cleaning - The I-D needs a serious round of editorial
cleaning performed by a native English speaker. 

2. Section 4.3 talks about the need to designate an expert to advice to
IANA on Netflow v9 matters. This request is not however mentioned in the
IANA Considerations section. 

3. It is not clear to me what is the goal of the following piece of
process described in Section 4.9: 

>  In order to support transition from experimental registration to IANA
   registration, the IANA registry provides an optional "enterprise-
   specific IE reference" column for each Information Element.  In cases
   of promoted enterprise-specific Information Elements, this column in
   the registry SHOULD contain the private enterprise and Information
   Element numbers of the enterprise-specific version of the Information
   Element.

If I understand well, an IE shows up in the IANA registry only when a
standard IE is added to the registry. What 'transition' is being
supported here, and how is it supported by a back reference to a
proprietary enterprise registry? 

4. In Section 5.2, the following change in an IE is considered to be
interoperable:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Romascanu, Dan (Dan | 22 May 14:21
Favicon

Re: [IPFIX] [new-work] WG Review: Recharter of Behavior Engineering forHindrance Avoidance (behave)

Hi, 

Two comments: 

1. If I got it right, Information Elements will be defined specifically
to meet logging requirements. It would be good to be explicit on this in
the deliverables list as well. 

2. It is not clear what the plans are concerning the MIB module(s). Will
there be two separate MIB modules to be used as needed with the existing
MIB module defined in RFC 4008? Or eventually there will be one MIB
module that updates the one defined in 4008 and adds NAT64 and CGNs
capabilities. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: new-work-bounces <at> ietf.org [mailto:new-work-bounces <at> ietf.org] On
> Behalf Of IESG Secretary
> Sent: Tuesday, May 15, 2012 8:53 PM
> To: new-work <at> ietf.org
> Subject: [new-work] WG Review: Recharter of Behavior Engineering
> forHindrance Avoidance (behave)
> 
> A modified charter has been submitted for the Behavior Engineering for
> Hindrance Avoidance (behave) working group in the Transport Area of
the
> IETF.  The IESG has not made any determination as yet.  The modified
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jan Novak (janovak | 22 May 10:58
Picon
Favicon

[IPFIX] Comments on draft-akhter-opsawg-perfmon-ipfix-02

Hi Amer,

I have reviewed your draft draft-akhter-opsawg-perfmon-ipfix-02.txt.

There seems to be a lot of text overlap with your methodology
document - section 1,3, 4 could probably be abbreviated or omitted
leaving the document just with raw IPFIX IE specifications or just
add the IE specification as sub-sections or a new section into
the first document ?? 

Section 2 uses definitions from RFC5610 - I think those you use there
are defined in RFC5102 as DataTypeSemantic, units and range while
RFC5610 specifies how this information should be exported - here
you are defining the IE itself so you should use the definitions
from RFC5102

Also the methodology documents already speaks in terms of IPFIX
IEs while you are trying to specify some performance metrics - the
methodology could have names and an exact definitions of the metric
and then a reference which IE represents the particular metric

RFC5102 section 2.1 specifies a template for IEs with a MUST
so the MUST entries should be literally followed in your IEs spec
- namely name, elementID, description, dataType and status.

RFC5102 section 2.1 specifies MAY entries for the template - like
DataTypeSemantic, units, name - might be preferable to follow the
naming as well

You interchanged ElementId with name - ElementId should be the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Al Morton | 13 May 19:06
Picon
Favicon

[IPFIX] Comments on draft-akhter-opsawg-perfmon-method-02

Hi Aamer,

I finally made some time to review one of your drafts:
http://tools.ietf.org/html/draft-akhter-opsawg-perfmon-method-02

and comments follow below.  Not sure exactly which list
will be best, so I CC'd ipfix and opsawg.

hope this helps,
Al

-=-=-=-=-=-=-=-=-=-=-=-=-=-

Main Comments:

1. Packet Loss Calculation Method (4.1.1)
Each metric has a paragraph labeled Calculation Method, but
they contain a useful discussion of the possible issues instead.
Many details are left to the implementor, with the likely outcome
that different implementations will produce different results.
For example, "synchronization" is mentioned many times, but what
does this process entail? Try to minimize interpretation,
perhaps by including a high-level step-by-step procedure for
processing each arriving packet, both during initiation
(synchronization, when the first few packets arrive) and
steady-state processing (which involves using the info from sync).
Since this draft is proposed for the Standards Track, it
really needs to provide definitions that will stand-up to
scrutiny of multiple implementations.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nevil Brownlee | 12 May 20:05
Picon
Picon
Favicon

[IPFIX] Constraints for IPFIX session at IETF-84 in Vancuover


Hi all:

Registration for Vancouver is now open, and it's time to ask for an
IPFIX WD session.  I usually do this by copying the list of constraints
from last time.  However, this time it seems a good idea to ask the WG!

If you have any other WGs you really need to attend, please email me
and tell me by next Wednesday (16 May).

Thanks, Nevil

--

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

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
Permalink | Reply | 0 comments |
headers
Nevil Brownlee | 25 Apr 18:07
Picon
Picon
Favicon

[IPFIX] WG Last calls for Aggregation and MIB-Doctors drafts


Hi all:

At the IPFIX meeting during IETF-83, we said that two drafts need WGLCs:

   draft-ietf-ipfix-a9n-03
     This is the aggregation draft; it now has two IPR disclosures,
     so it needs a new WGLC.

   draft-ietf-ipfix-ie-doctors-02
     This is now ready for its WGLC.

Please read these drafts, and send reviews and/or comments to the list.
If you suggest improvements, please send text!
Reviews are, of course, most appreciated - but simple posts saying
"I support this" are fine too.

These WGLCs start today, and will end on 27 May 2012.

Cheers, Nevil

--

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

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Romascanu, Dan (Dan | 24 Apr 11:48
Favicon

Re: [IPFIX] AD review of draft-ietf-ipfix-flow-selection-tech-10.txt

Hi Salvatore,

Thank you for addressing the issues raised in my review. 

Regards,

Dan

> -----Original Message-----
> From: Salvatore D'Antonio [mailto:salvatore.dantonio <at> uniparthenope.it]
> Sent: Monday, April 23, 2012 6:17 PM
> To: Romascanu, Dan (Dan); 'IETF IPFIX Working Group'
> Subject: R: [IPFIX] AD review of draft-ietf-ipfix-flow-selection-tech-
> 10.txt
> 
> Dear Dan,
> 
> The new version of the Internet Draft on Flow Selection Techniques has
> been
> published.
> 
> Answers to yours comments inline.
> 
> -----Messaggio originale-----
> Da: ipfix-bounces <at> ietf.org [mailto:ipfix-bounces <at> ietf.org] Per conto di
> Romascanu, Dan (Dan)
> Inviato: mercoledì 21 marzo 2012 17:42
> A: IETF IPFIX Working Group
> Oggetto: [IPFIX] AD review of draft-ietf-ipfix-flow-selection-tech-
> 10.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
internet-drafts | 23 Apr 16:38
Picon
Favicon

[IPFIX] I-D Action: draft-ietf-ipfix-flow-selection-tech-11.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the IP Flow Information Export Working Group of the IETF.

	Title           : Flow Selection Techniques
	Author(s)       : Salvatore D'Antonio
                          Tanja Zseby
                          Christian Henke
                          Lorenzo Peluso
	Filename        : draft-ietf-ipfix-flow-selection-tech-11.txt
	Pages           : 36
	Date            : 2012-04-23

   Flow selection is the process of selecting a subset of flows from all
   observed flows.  The Flow Selection Process may be located at an
   observation point, or on an IPFIX Mediator.  Flow selection reduces
   the effort of post-processing flow data and transferring Flow
   Records.  This document describes motivations for flow selection and
   presents flow selection techniques.  It provides an information model
   for configuring flow selection techniques and discusses what
   information about a flow selection process should be exported.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-11.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Feren | 11 Apr 17:30
Favicon

[IPFIX] draft-claise-export-application-info-in-ipfix-05

First a few editorial notes.

Page 6 [top paragraph]

"available at [CISCO], only the layer 7 ones cannot compiled"
should be
"available at [CISCO], only the layer 7 ones cannot be compiled "

Page 12
"protocol encoding may encoded with 3 bytes. In such a case, "
should be
"protocol encoding may be encoded with 3 bytes. In such a case,"

Page 27 section 6.6

        the reporting application wants to determine whether or the
        default HTTP port 80 or 8080 was used, it must export the
        destination port (destinationTransportPort at [IANA-IPFIX])
        in the corresponding IPFIX record. 

should be something like

        the reporting application wants to determine whether or not the
        default HTTP port 80 or 8080 was used, the
        destination port (destinationTransportPort at [IANA-IPFIX])
        must also be exported in the corresponding IPFIX record. 


Now a few other notes.

Maybe it is just me, but on page 8 I have no idea what is meant by

        The Selector ID term is in sync with the selectorId
        Information Element, specified in the PSAMP Protocol
        [RFC5476]. 


     7.1.8. p2pTechnology
     7.1.9. tunnelTechnology
     7.1.10. encryptedTechnology

specify y, 2, n, 2, u, and 0 in addition to the "yes", "no", and "unassigned" values found at http://www.iana.org/assignments/ipfix/ipfix.xml

Are all of these valid values?  If yes should the IANA entries be updated?

-Andrew
_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
Permalink | Reply | 1 comment |
headers
Paul Ashley | 11 Apr 02:12
Picon

[IPFIX] AUTO: Paul Ashley is out of the office (returning 16/04/2012)


I am out of the office until 16/04/2012.

I am out of the office.  I will have no access to my email.

For ISS client issues, please email Andrew Sallaway (andrewms <at> au1.ibm.com)

For ISS product development issues, please email John Court
(johnwcrt <at> au1.ibm.com).

For urgent issues,  please send me a text message to 0421 611 853.

Note: This is an automated response to your message  "IPFIX Digest, Vol 64,
Issue 3" sent on 11/4/2012 5:00:08.

This is the only notification you will receive while this person is away.

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
Permalink | Reply | 0 comments |

Gmane