From stbryant@cisco.com Thu Jan 2 03:54:35 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0BF1AE214 for ; Thu, 2 Jan 2014 03:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.139 X-Spam-Level: X-Spam-Status: No, score=-8.139 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbP1XirkGvkL for ; Thu, 2 Jan 2014 03:54:32 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 15C561AC421 for ; Thu, 2 Jan 2014 03:54:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25913; q=dns/txt; s=iport; t=1388663664; x=1389873264; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=LBk17oJneQkd+ofgry83bbo3CQ8k8v+9e6u5HDysEVE=; b=Gjwvmb+WW4f5JwBrJ5V/OQUoS0iJQegWDByDVLVQ5tj1Zawt+JYI34ZS +ebwB3bmPemNfNIdxk0KIJQQi1S3ZX15x7WOtRcgF7auCNzMZWU8Fol4N 2nkFHZhoW7lwXGBWWwYef3HYUdpN7Du5x5OTr/u+30X5ZaE1nYqY2EF0A g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFALFSxVKQ/khR/2dsb2JhbAA+GoMLOLlEgQwWdIIlAQEBBAEBARdUCgEQCxgJFg8JAwIBAgEVMAYNAQUCAQGIAA02wgIXjjsRAVAHhDYEmBeSFIMteXg X-IronPort-AV: E=Sophos;i="4.95,590,1384300800"; d="scan'208,217";a="2427281" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 02 Jan 2014 11:54:22 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s02BsMau021355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jan 2014 11:54:22 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s02Bs0k8015984; Thu, 2 Jan 2014 11:54:01 GMT Message-ID: <52C55358.5060402@cisco.com> Date: Thu, 02 Jan 2014 11:54:00 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Brian Trammell References: <20131230151331.29E9F7FC393@rfc-editor.org> <52C19DF7.4050501@plixer.com> <52C232EB.30802@cisco.com>, <535E38C8-A1C0-4FD5-991C-D9A132D97923@tik.ee.ethz.ch> <0BEF0D66-E9DB-40E7-A2E4-ABCBCA5634CB@cisco.com> <52C2BC12.6090108@tik.ee.ethz.ch> In-Reply-To: <52C2BC12.6090108@tik.ee.ethz.ch> Content-Type: multipart/alternative; boundary="------------010503060101040200080302" Cc: "joelja@bogus.com Jaeggli" , Nevil Brownlee , "ipfix@ietf.org Group" , RFC Errata System Subject: Re: [IPFIX] [Technical Errata Reported] RFC7012 (3852) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 11:54:35 -0000 This is a multi-part message in MIME format. --------------010503060101040200080302 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Brian Firstly going back to my original problem, I think that would be better addressed by OLD Definitions of timestamp data types have been clarified. NEW Definitions of timestamp data types have been clarified and the definition of the epochs has been moved to sections 6.1.7 through 6.1.11 of RFC 7011 End Your new text is also helpful. Then there is the problem of the IANA registry pointing to an obsolete RFC, which then takes you to RFC7012 which does not define the IEs. Consider IE 150, the reader is directed to RFC7012 by the registry header, and finds the datatype isdateTimeSeconds (which they dutifully look up in RFC7012 as indicated in the registry) they find the definition of dateTimeSeconds without the epoch and then what... For the definition of the IE to be complete, the reader needs the epoch which arguably now belongs in the registry, but is missing. I think that the root cause is that when we made the registry the definitive definition of the IEs, we did not add sufficient information in the case of the time definitions. Now we have one other issue which I have been puzzling over since you sent the email and can't quite get my head around. You use the term "value" in the ADT context. With for example i.e. 52 (min TTL) it's easy to imagine what "value" means however you represent it. However I am struggling to understand whether it is meaningful to define the "value" of IE 150:"The absolute timestamp of the first packet of this Flow" is without some specific epoch. This issue is addressed in I.E. 1 by specifying the count relative to a previous instance of count, so I think whilst that is a value, the timestamps are not. We may need a call to work though this and another issue I am about to raise on the IPFIX list. - Stewart On 31/12/2013 12:44, Brian Trammell wrote: > hi Stewart, > > Stewart Bryant (stbryant) wrote: >> Certainly something is needed. I was thinking of using IPFIX as an information gathering method in a radio context, and went to look at the definition of the types and could not find the epoch, or even a reference to the epoch. Now part of the problem (which was my fault) was that I did not notice at the time that the elements were defined by the obsolete RFC5102 and went straight to the new RFC. However having the definitions in an obsolete RFC also seems problematic, since it puts the IEs in a strange state. Since RFC 7012 replaces RFC5102 and includes the definitions you would expect the definition in RFC7012 to replace the definition in RFC5102, but those definitions are, as I explained incomplete. > This is intentional. See below. > >> I need to look at this some more when I get back to work, but I am now also concerned that if the epoch can change, the definition of the existing IEs is now unreliable. > The definition of the existing IEs is based upon the definition of the > ADT itself in 7012 as well as the definition of the ADT representation > within the IPFIX protocol in 7011. It is not the intention that reading > 7012 tells you how to encode IEs for use with IPFIX; that's what section > 6.1 of 7011 is for. > >> You will notice in the errata that I did suggest that an alternative resolution would be to include a reference to the epoch text. > The point is that the ADT _explicitly_ does not have a binding to an > epoch, as epochs are only necessary when using integral representations > of timestamps. IPFIX's representations for these ADTs are integral, but > bindings to other representations need not be (see, for example, > draft-trammell-ipfix-text-adt, which recommends ISO8601-style timestamps > for textual representations of IE values). > > I'd suggest instead somehow expanding the present text in 7012 to > reiterate that if you're using IPFIX, the representations of the ADTs > are in 7011: > > OLD para 2 sec 3.1 7012: > > The current encodings of these data types for use with the IPFIX > protocol are defined in [RFC7011]; encodings allowing the use of the > IPFIX Information Elements [IANA-IPFIX] with other protocols may be > defined in the future by referencing this document. > > NEW para 2 sec 3.1 7012: > > The abstract data type definitions in this section are intended > only to define the values which can be taken by Information > Elements of each type. The encodings of these data types for > use with the IPFIX protocol are defined in Section 6.1 of > [RFC7011]; encodings allowing the use of the IPFIX Information > Elements [IANA-IPFIX] with other protocols may be defined in the > future by referencing this document. > > Best regards, > > Brian > > >> Stewart >> >> >> >> Sent from my iPad >> >>> On 31 Dec 2013, at 08:50, "Brian Trammell" wrote: >>> >>> hi Paul, all, >>> >>> +n. >>> >>> The separation between ADTs and ADT encoding between 7012 and 7011 was explicit and purposeful. Specifically, we do _not_ want to exclude other representations of the IPFIX Information Model from being based upon other encodings of these ADTs, whether ISO 8601 (which either has no epoch or epoch 0000-00-00 00:00 UTC, depending on how you count), NTP (1904), Julian day based counting, etc, etc, etc… >>> >>> If there is confusion on this point, I’d suggest adding more explanatory text on this point to Paragraph 2 of the front matter to section 3.1. But as is, I emphatically recommend rejection of this reported erratum. >>> >>> Best regards, >>> >>> Brian >>> >>>> On 31 Dec 2013, at 03:58, Paul Aitken wrote: >>>> >>>> +1 >>>> >>>> If anyone was going to raise an errata on this, it would have been me ;-) >>>> >>>> I've pointed this issue out before, probably more than once - and have been encouraged to read RFC 3444. >>>> >>>> P. >>>> >>>> >>>>> On 30/12/2013 09:23, Andrew Feren wrote: >>>>> The encoding for the time data types is specified RFC 7011 Sections >>>>> 6.1.7 through 6.1.10. >>>>> >>>>> -Andrew >>>>> >>>>>> On 12/30/2013 10:13 AM, RFC Errata System wrote: >>>>>> The following errata report has been submitted for RFC7012, >>>>>> "Information Model for IP Flow Information Export (IPFIX)". >>>>>> >>>>>> -------------------------------------- >>>>>> You may review the report below and at: >>>>>> http://www.rfc-editor.org/errata_search.php?rfc=7012&eid=3852 >>>>>> >>>>>> -------------------------------------- >>>>>> Type: Technical >>>>>> Reported by: Stewart Bryant >>>>>> >>>>>> Section: 3.1.15-17 >>>>>> >>>>>> Original Text >>>>>> ------------- >>>>>> 3.1.15. dateTimeSeconds >>>>>> >>>>>> The type "dateTimeSeconds" represents a time value expressed with >>>>>> second-level precision. >>>>>> >>>>>> 3.1.16. dateTimeMilliseconds >>>>>> >>>>>> The type "dateTimeMilliseconds" represents a time value expressed >>>>>> with millisecond-level precision. >>>>>> >>>>>> 3.1.17. dateTimeMicroseconds >>>>>> >>>>>> The type "dateTimeMicroseconds" represents a time value expressed >>>>>> with microsecond-level precision. >>>>>> >>>>>> 3.1.18. dateTimeNanoseconds >>>>>> >>>>>> The type "dateTimeNanoseconds" represents a time value expressed with >>>>>> nanosecond-level precision. >>>>>> >>>>>> >>>>>> Corrected Text >>>>>> -------------- >>>>>> 3.1.15. dateTimeSeconds >>>>>> >>>>>> The type "dateTimeSeconds" represents a time value in units of >>>>>> seconds based on coordinated universal time (UTC). The choice of an >>>>>> epoch, for example, 00:00 UTC, January 1, 1970, is left to >>>>>> corresponding encoding specifications for this type, for example, the >>>>>> IPFIX protocol specification. Leap seconds are excluded. Note that >>>>>> transformation of values might be required between different >>>>>> encodings if different epoch values are used. >>>>>> >>>>>> 3.1.16. dateTimeMilliseconds >>>>>> >>>>>> The type "dateTimeMilliseconds" represents a time value in units of >>>>>> milliseconds based on coordinated universal time (UTC). The choice >>>>>> of an epoch, for example, 00:00 UTC, January 1, 1970, is left to >>>>>> corresponding encoding specifications for this type, for example, the >>>>>> IPFIX protocol specification. Leap seconds are excluded. Note that >>>>>> transformation of values might be required between different >>>>>> encodings if different epoch values are used. >>>>>> >>>>>> 3.1.17. dateTimeMicroseconds >>>>>> >>>>>> The type "dateTimeMicroseconds" represents a time value in units of >>>>>> microseconds based on coordinated universal time (UTC). The choice >>>>>> of an epoch, for example, 00:00 UTC, January 1, 1970, is left to >>>>>> corresponding encoding specifications for this type, for example, the >>>>>> IPFIX protocol specification. Leap seconds are excluded. Note that >>>>>> transformation of values might be required between different >>>>>> encodings if different epoch values are used. >>>>>> >>>>>> 3.1.18. dateTimeNanoseconds >>>>>> >>>>>> The type "dateTimeNanoseconds" represents a time value in units of >>>>>> nanoseconds based on coordinated universal time (UTC). The choice of >>>>>> an epoch, for example, 00:00 UTC, January 1, 1970, is left to >>>>>> corresponding encoding specifications for this type, for example, the >>>>>> IPFIX protocol specification. Leap seconds are excluded. Note that >>>>>> transformation of values might be required between different >>>>>> encodings if different epoch values are used. >>>>>> >>>>>> >>>>>> Notes >>>>>> ----- >>>>>> Although section 1.1 says : - "Definitions of timestamp data types have been clarified." The edited text has removed the epoch definition, and this does not seem to have been incorporated elsewhere in the RFC. >>>>>> >>>>>> Without a specified epoch, there is no unique definition of the timestamps. >>>>>> >>>>>> My proposal above is to revert to the RFC5102 definitions. RFC7102 is intended to be backwards compatible with RFC5102 and thus the definitions need to be technically identical. Alternatively, if the text is now included elsewhere in RFC7012 or in another RFC, it would be helpful to the reader to provide a reference to the epoch definition in an editorial update to dateTimeX definitions in RFC7102. >>>>>> >>>>>> Instructions: >>>>>> ------------- >>>>>> This errata is currently posted as "Reported". If necessary, please >>>>>> use "Reply All" to discuss whether it should be verified or >>>>>> rejected. When a decision is reached, the verifying party (IESG) >>>>>> can log in to change the status and edit the report, if necessary. >>>>>> >>>>>> -------------------------------------- >>>>>> RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10) >>>>>> -------------------------------------- >>>>>> Title : Information Model for IP Flow Information Export (IPFIX) >>>>>> Publication Date : September 2013 >>>>>> Author(s) : B. Claise, Ed., B. Trammell, Ed. >>>>>> Category : PROPOSED STANDARD >>>>>> Source : IP Flow Information Export >>>>>> Area : Operations and Management >>>>>> Stream : IETF >>>>>> Verifying Party : IESG >>>>>> _______________________________________________ >>>>>> IPFIX mailing list >>>>>> IPFIX@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>> _______________________________________________ >>>>> IPFIX mailing list >>>>> IPFIX@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipfix >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------010503060101040200080302 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Brian

Firstly going back to my original problem, I think that would be
better addressed by

OLD
Definitions of timestamp data types have been clarified.

NEW

Definitions of timestamp data types have been clarified and 
the definition of the epochs has been moved to sections
6.1.7 through 6.1.11 of RFC 7011

End

Your new text is also helpful. 

Then there is the problem of the IANA registry pointing to
an obsolete RFC, which then takes you to RFC7012 which
does not define the IEs.

Consider IE 150, the reader is directed to RFC7012 by the
registry header, and finds the datatype is dateTimeSeconds
(which they dutifully look up in RFC7012 as indicated
in the registry) they find the definition of dateTimeSeconds
without the epoch and then what... For the definition
of the IE to be complete, the reader needs the epoch
which arguably now belongs in the registry, but is missing.
I think that the root cause is that when we made the 
registry the definitive definition of the IEs, we
did not add sufficient information in the case of the 
time definitions.

Now we have one other issue which I have been puzzling
over since you sent the email and can't quite get my
head around. You use the term "value" in the ADT
context. With for example i.e. 52 (min TTL) it's
easy to imagine what "value" means however you 
represent it. However I am struggling to understand
whether it is meaningful to define the "value" of IE 
150: "The absolute timestamp of the first packet of 
this Flow" is without some specific epoch. This
issue is addressed in I.E. 1 by specifying the count
relative to a previous instance of count, so I think
whilst that is a value, the timestamps are not.

We may need a call to work though this and another issue
I am about to raise on the IPFIX list.

- Stewart
On 31/12/2013 12:44, Brian Trammell wrote:
hi Stewart,

Stewart Bryant (stbryant) wrote:

Certainly something is needed. I was thinking of using IPFIX as an information gathering method in a radio context, and went to look at the definition of the types and could not find the epoch, or even a reference to the epoch. Now part of the problem (which was my fault) was that I did not notice at the time that the elements were defined by the obsolete RFC5102 and went straight to the new RFC. However having the definitions in an obsolete RFC also seems problematic, since it puts the IEs in a strange state. Since RFC 7012 replaces RFC5102 and includes the definitions you would expect the definition in RFC7012 to replace the definition in RFC5102, but those definitions are, as I explained incomplete.

This is intentional. See below.


I need to look at this some more when I get back to work, but I am now also concerned that if the epoch can change, the definition of the existing IEs is now unreliable.

The definition of the existing IEs is based upon the definition of the
ADT itself in 7012 as well as the definition of the ADT representation
within the IPFIX protocol in 7011. It is not the intention that reading
7012 tells you how to encode IEs for use with IPFIX; that's what section
6.1 of 7011 is for.


You will notice in the errata that I did suggest that an alternative resolution would be to include a reference to the epoch text.

The point is that the ADT _explicitly_ does not have a binding to an
epoch, as epochs are only necessary when using integral representations
of timestamps. IPFIX's representations for these ADTs are integral, but
bindings to other representations need not be (see, for example,
draft-trammell-ipfix-text-adt, which recommends ISO8601-style timestamps
for textual representations of IE values).

I'd suggest instead somehow expanding the present text in 7012 to
reiterate that if you're using IPFIX, the representations of the ADTs
are in 7011:

OLD para 2 sec 3.1 7012:

   The current encodings of these data types for use with the IPFIX
   protocol are defined in [RFC7011]; encodings allowing the use of the
   IPFIX Information Elements [IANA-IPFIX] with other protocols may be
   defined in the future by referencing this document.

NEW para 2 sec 3.1 7012:

   The abstract data type definitions in this section are intended
   only to define the values which can be taken by Information
   Elements of each type. The encodings of these data types for
   use with the IPFIX protocol are defined in Section 6.1 of
   [RFC7011]; encodings  allowing the use of the IPFIX Information
   Elements [IANA-IPFIX] with other protocols may be defined in the
   future by referencing this document.

Best regards,

Brian



Stewart



Sent from my iPad


On 31 Dec 2013, at 08:50, "Brian Trammell" <trammell@tik.ee.ethz.ch> wrote:

hi Paul, all,

+n.

The separation between ADTs and ADT encoding between 7012 and 7011 was explicit and purposeful. Specifically, we do _not_ want to exclude other representations of the IPFIX Information Model from being based upon other encodings of these ADTs, whether ISO 8601 (which either has no epoch or epoch 0000-00-00 00:00 UTC, depending on how you count), NTP (1904), Julian day based counting, etc, etc, etc…

If there is confusion on this point, I’d suggest adding more explanatory text on this point to Paragraph 2 of the front matter to section 3.1. But as is, I emphatically recommend rejection of this reported erratum.

Best regards,

Brian


On 31 Dec 2013, at 03:58, Paul Aitken <paitken@cisco.com> wrote:

+1

If anyone was going to raise an errata on this, it would have been me ;-)

I've pointed this issue out before, probably more than once - and have been encouraged to read RFC 3444.

P.



On 30/12/2013 09:23, Andrew Feren wrote:
The encoding for the time data types is specified RFC 7011 Sections
6.1.7 through 6.1.10.

-Andrew


On 12/30/2013 10:13 AM, RFC Errata System wrote:
The following errata report has been submitted for RFC7012,
"Information Model for IP Flow Information Export (IPFIX)".

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

--------------------------------------
Type: Technical
Reported by: Stewart Bryant <stbryant@cisco.com>

Section: 3.1.15-17

Original Text
-------------
3.1.15. dateTimeSeconds

  The type "dateTimeSeconds" represents a time value expressed with
  second-level precision.

3.1.16. dateTimeMilliseconds

  The type "dateTimeMilliseconds" represents a time value expressed
  with millisecond-level precision.

3.1.17. dateTimeMicroseconds

  The type "dateTimeMicroseconds" represents a time value expressed
  with microsecond-level precision.

3.1.18. dateTimeNanoseconds

  The type "dateTimeNanoseconds" represents a time value expressed with
  nanosecond-level precision.


Corrected Text
--------------
3.1.15. dateTimeSeconds

  The type "dateTimeSeconds" represents a time value in units of
  seconds based on coordinated universal time (UTC).  The choice of an
  epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.16. dateTimeMilliseconds

  The type "dateTimeMilliseconds" represents a time value in units of
  milliseconds based on coordinated universal time (UTC).  The choice
  of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.17. dateTimeMicroseconds

  The type "dateTimeMicroseconds" represents a time value in units of
  microseconds based on coordinated universal time (UTC).  The choice
  of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.18. dateTimeNanoseconds

  The type "dateTimeNanoseconds" represents a time value in units of
  nanoseconds based on coordinated universal time (UTC).  The choice of
  an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.


Notes
-----
Although section 1.1 says : - "Definitions of timestamp data types have been clarified." The edited text has removed the epoch definition, and this does not seem to have been incorporated elsewhere in the RFC.

Without a specified epoch, there is no unique definition of the timestamps.

My proposal above is to revert to the RFC5102 definitions. RFC7102 is intended to be backwards compatible with RFC5102 and thus the definitions need to be technically identical. Alternatively, if the text is now included elsewhere in RFC7012 or in another RFC, it would be helpful to the reader to provide a reference to the epoch definition in an editorial update to dateTimeX definitions in RFC7102.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10)
--------------------------------------
Title               : Information Model for IP Flow Information Export (IPFIX)
Publication Date    : September 2013
Author(s)           : B. Claise, Ed., B. Trammell, Ed.
Category            : PROPOSED STANDARD
Source              : IP Flow Information Export
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

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

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


    

    

    

    
-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html



  


--------------010503060101040200080302--

From stbryant@cisco.com  Thu Jan  2 05:55:01 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78D61AE153 for ; Thu,  2 Jan 2014 05:55:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.339
X-Spam-Level: 
X-Spam-Status: No, score=-7.339 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pilMn6al88IW for ; Thu,  2 Jan 2014 05:55:00 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 571F61AD8E1 for ; Thu,  2 Jan 2014 05:55:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2824; q=dns/txt; s=iport; t=1388670893; x=1389880493; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=heAXtweghxpC/kZ9yxyjXxEg7IXnNBk/8E9TIRBGEiA=; b=G6LEyVGGpodXVSNbFH3u+ycgDnB02QEEn0ihCuVTwUDDM8AqPBaic0LV k0rZzj+k6/ktk0lcvsEAYPQGnuDVqKVqVwV5k6S6+Nixx8/0kawk9OUhQ xjTAScM7b8RPqo3zOxbINnTxs2OR5F2wPqkyluIqKB/+LiAVjKmxNTDdN Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAEhvxVKQ/khM/2dsb2JhbABOCoMLuwgWdIJkQD0WGAMCAQIBSwEMCAEBiACgPaIfF45BDoULBJgXkhSDLQ
X-IronPort-AV: E=Sophos;i="4.95,590,1384300800";  d="scan'208";a="3100800"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 02 Jan 2014 13:54:50 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s02Dsnhl006182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jan 2014 13:54:49 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s02Dsl0Z020331; Thu, 2 Jan 2014 13:54:48 GMT
Message-ID: <52C56FA7.6070905@cisco.com>
Date: Thu, 02 Jan 2014 13:54:47 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "ipfix@ietf.org Group" , "ipfix-chairs@tools.ietf.org" , ipfix-ads@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] Application of IPFIX to new application spaces.
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Jan 2014 13:55:02 -0000

Whilst I accept that IPFIX is pretty much complete in terms of
addressing it's original goals as a network management
protocol, I have some concerns about it's completeness
as an  observation reporting protocol. I think these need
to be addressed, before declaring completion of the work
programme as a whole.

(In my own time) I am looking at the definition of a protocol
to observe and report the radio noise floor. The purpose
is to map the rise in the radio noise floor due to RF pollution
from domestic and industrial digital systems such as
plasma televisions, and power line (digital) transmission
systems. IPFIX is a good protocol for such mass observations,
and has been used successfully in the radio propagation
monitoring system pskreporter.

In doing this I ran into two problems, firstly there are no
experimental IE types, and thus I cannot prototype the
application without either "camping" on a set of IEs, or
waiting until I am allocated a PEN. For reasons that will
be clear from other work I have done in the IETF, I dislike
the idea of "camping" on code-points. This makes it clear
to me that we need a small, but not trivial set of
experimental IEs that are intended for prototyping but
explicitly excluded from use in production systems.
This needs to be a reasonable number since a new application
space might need a fair number of IEs to be practical.
Thus I think that we need to either allocate some of the
base protocol IEs to experimental, or to have IANA
allocate a PEN specifically to experimental use which
would allow experimentation in new applications spaces
without the need to formally allocate IEs in either the
base IE space, or the PEN space of the organization
(or person) conducting the experiment.

The second problem that I see is the lack of a public registry
for non-network managements applications. Specifically
I am going to need "callsign", "maidenhead locator",
"frequency", "noise power", maybe "field strength", "receiver type"
etc. Now some of those may be of general use (frequency)
but most of them would be cruft in the base protocol IE set
which is set up for networking applications. On the other hand,
I know of at least one PEN space that will have a number of the
terms I need already defined, although these are by
definition private. With the current IE registration structure
the absence of a public registry inevitably means the
redefinition of other than mainstream/network management
terms across a number of private registries. I thus think
it would be useful to introduce a PEN + registry for
"other applications" or introduce the concept of a series
of application specific registries with appropriate  PENs to
identify the application space rather than  the private
enterprise space.

- Stewart



From iesg-secretary@ietf.org  Thu Jan  2 09:33:49 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102EE1AE012; Thu,  2 Jan 2014 09:33:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI_ithZCA5L1; Thu,  2 Jan 2014 09:33:47 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D181AE679; Thu,  2 Jan 2014 09:33:45 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.90
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140102173345.25073.90576.idtracker@ietfa.amsl.com>
Date: Thu, 02 Jan 2014 09:33:45 -0800
Cc: ipfix chair , ipfix mailing list , RFC Editor 
Subject: [IPFIX] Protocol Action: 'Information Elements for Data Link Layer Traffic Measurement' to Proposed Standard (draft-ietf-ipfix-data-link-layer-monitoring-08.txt)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Jan 2014 17:33:49 -0000

The IESG has approved the following document:
- 'Information Elements for Data Link Layer Traffic Measurement'
  (draft-ietf-ipfix-data-link-layer-monitoring-08.txt) as Proposed
Standard

This document is the product of the IP Flow Information Export Working
Group.

The IESG contact persons are Benoit Claise and Joel Jaeggli.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring/




Technical Summary

This document describes Information Elements (IEs) related to data
link layer.  They are used by the IP Flow Information Export (IPFIX)
protocol for encoding measured data link layer traffic information.

The document is intended to be a Proposed Standard.  It describes,
in detail, a set of Information Elements describing link-layer
objects.  These will be particularly to service providers who use
Wide-Area Ethernet or Virtual Ethernet technologies.


Working Group Summary

This draft's -00 version was published in July 2012. Two of its
authors were from a large Japanese provider who needed to monitor and
report on link-layer performance.  Since then it has received ongoing
low-activity-level discussion on the IPFIX list.  It has also been
discussed at each IETF meeting since then; alas, the WG has always
considered this as low-priority work.


Document Quality

Its WGLC was run in October 2012; we realised at that point that we
needed someone from IEEE 802.1 to check that our Ethernet IEs were
correct in their descriptions of the IEEE-defined technologies.
Pat Thaler, IEEE liaison for IETF, has helped develop this document
since then, she confirms that the IEEE-related IEs are correct in
their descriptions.

It has been carefully reviewed by Paul Aitken and Brian Trammell,
both pointed out issues; these have been addressed in successive
versions.

Overall I believe that there is clear consensus within the WG for
this draft.


Personnel

Document shepherd: Nevil Brownlee
Responsible Area Director: Benoit Claise
'The IANA Expert(s) for the registries in this document 
are the IPFIX Information Element (IE) doctors 
( ie-doctors@ietf.org ). The IPFIX IE doctors 
reviewed and approved the IEs in this document.


From trammell@tik.ee.ethz.ch  Fri Jan  3 01:39:44 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F87B1ADF66 for ; Fri,  3 Jan 2014 01:39:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.239
X-Spam-Level: 
X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NI30PUzKgC5R for ; Fri,  3 Jan 2014 01:39:41 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 300591ADF5E for ; Fri,  3 Jan 2014 01:39:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 695F2D9304; Fri,  3 Jan 2014 10:39:32 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id W5sIvSfm+tSq; Fri,  3 Jan 2014 10:39:32 +0100 (MET)
Received: from [10.0.27.113] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9EC86D9302; Fri,  3 Jan 2014 10:39:31 +0100 (MET)
Content-Type: multipart/signed; boundary="Apple-Mail=_990587DD-F94F-4CCD-8930-7F0CF5594EF8"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Brian Trammell 
In-Reply-To: <52C56FA7.6070905@cisco.com>
Date: Fri, 3 Jan 2014 10:39:22 +0100
Message-Id: 
References: <52C56FA7.6070905@cisco.com>
To: "stbryant@cisco.com Bryant" 
X-Mailer: Apple Mail (2.1827)
Cc: ipfix-ads@tools.ietf.org, "ipfix@ietf.org Group" , "ipfix-chairs@tools.ietf.org" 
Subject: Re: [IPFIX] Application of IPFIX to new application spaces.
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Jan 2014 09:39:44 -0000

--Apple-Mail=_990587DD-F94F-4CCD-8930-7F0CF5594EF8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

hi Stewart,

Wanted to reply briefly to two points here inline (will reply in more =
detail later):

On 02 Jan 2014, at 14:54, Stewart Bryant  wrote:

>=20
> Whilst I accept that IPFIX is pretty much complete in terms of
> addressing it's original goals as a network management
> protocol, I have some concerns about it's completeness
> as an  observation reporting protocol. I think these need
> to be addressed, before declaring completion of the work
> programme as a whole.
>=20
> (In my own time) I am looking at the definition of a protocol
> to observe and report the radio noise floor. The purpose
> is to map the rise in the radio noise floor due to RF pollution
> from domestic and industrial digital systems such as
> plasma televisions, and power line (digital) transmission
> systems. IPFIX is a good protocol for such mass observations,
> and has been used successfully in the radio propagation
> monitoring system pskreporter.
>=20
> In doing this I ran into two problems, firstly there are no
> experimental IE types, and thus I cannot prototype the
> application without either "camping" on a set of IEs, or
> waiting until I am allocated a PEN.

I=92m a little puzzled about the hesitation about getting a PEN; indeed, =
in my experience, had you applied for a PEN for this purpose when you =
sent this message initially you=92d have one by now. There is a little =
overhead in managing PEN space for different experiments (see =
https://trammell.ch/pen-35566 for the range registry used for my own =
experimentation) but this is orders of magnitude less work than =
designing and implementing the IEs in the first place.

I could see this being a problem if one were trying to run many =
experiments within the same very large organization with undefined or =
draconian processes for reserving an enterprise-specific IE. But PEN =
space is 2^32-1 large and we haven;t even exhausted the first block of =
2^16, so =93get a new PEN and label it useful for a given experiment=94 =
is probably an acceptable way out of this quandary.

> For reasons that will
> be clear from other work I have done in the IETF, I dislike
> the idea of "camping" on code-points. This makes it clear
> to me that we need a small, but not trivial set of
> experimental IEs that are intended for prototyping but
> explicitly excluded from use in production systems.
> This needs to be a reasonable number since a new application
> space might need a fair number of IEs to be practical.
> Thus I think that we need to either allocate some of the
> base protocol IEs to experimental, or to have IANA
> allocate a PEN specifically to experimental use which
> would allow experimentation in new applications spaces
> without the need to formally allocate IEs in either the
> base IE space, or the PEN space of the organization
> (or person) conducting the experiment.

I agree in principle that allocating a single =93IPFIX Experimentation=94 =
PEN would be one solution to this problem, but it would have to be =
fairly tightly scoped (only for experimental use among EPs and CPs =
implemented and deployed by a single entity within the scope of a single =
experiment; MUST be logged as an error by CPs in production use). And =
I=92d be very concerned that we were basically inviting people to camp =
on a whole new code space =97 requiring experiments to use their own PEN =
space at least keeps experimental IEs that =93leak=94 into production =
from colliding with each other, provided that the PEN owner manages =
their own space competently.

> The second problem that I see is the lack of a public registry
> for non-network managements applications. Specifically
> I am going to need "callsign", "maidenhead locator",
> "frequency", "noise power", maybe "field strength", "receiver type"
> etc. Now some of those may be of general use (frequency)
> but most of them would be cruft in the base protocol IE set
> which is set up for networking applications. On the other hand,
> I know of at least one PEN space that will have a number of the
> terms I need already defined, although these are by
> definition private. With the current IE registration structure
> the absence of a public registry inevitably means the
> redefinition of other than mainstream/network management
> terms across a number of private registries. I thus think
> it would be useful to introduce a PEN + registry for
> "other applications" or introduce the concept of a series
> of application specific registries with appropriate  PENs to
> identify the application space rather than  the private
> enterprise space.

This seems like a very good idea. I=92ll have to think about it some =
more.

Thanks, cheers,

Brian

> __________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


--Apple-Mail=_990587DD-F94F-4CCD-8930-7F0CF5594EF8
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSxoVLAAoJENt3nsOmbNJcE+sIAKlPhbERu4XCeOZmnOvBU1wc
CdiZNAcge5z8o2WIV68R3qofltJZb27QtcAz2+TITEZ8b5OKC3Gmy4FnCjDA5uKX
jnFljRM/5/pgClEuOqtApVrOSFAhzhApRknGlECc/IbG25/FezQaWA6hOJ0o0REF
0OvKvFcy6plBUq00lIyVqueKzh8bpTEf1vu+gs80n3r100IFbMjnqROdX9cj5jKv
l3Kuu2scbcbisxFvJuU+Ox48z4INxgzQtURHECm+x1bEyDK6opmVeiUfHkh4HfiG
Ufl/9UKmUwtllLB6vaYdY+5vYKsGs6NROurqC2zCRnWjwbnXfpsfRCkGiZ0RKNc=
=ej2j
-----END PGP SIGNATURE-----

--Apple-Mail=_990587DD-F94F-4CCD-8930-7F0CF5594EF8--

From trammell@tik.ee.ethz.ch  Fri Jan  3 02:00:38 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910931ADF68 for ; Fri,  3 Jan 2014 02:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.737
X-Spam-Level: 
X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp14Scf8HSOa for ; Fri,  3 Jan 2014 02:00:33 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3B01ADF67 for ; Fri,  3 Jan 2014 02:00:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 04722D9304; Fri,  3 Jan 2014 11:00:25 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OMy9PKu9UDZm; Fri,  3 Jan 2014 11:00:24 +0100 (MET)
Received: from [10.0.27.113] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 806BBD9302; Fri,  3 Jan 2014 11:00:23 +0100 (MET)
Content-Type: multipart/signed; boundary="Apple-Mail=_E295AA1D-D0CC-4A6D-8559-9F83F04EE437"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Brian Trammell 
In-Reply-To: <52C55358.5060402@cisco.com>
Date: Fri, 3 Jan 2014 11:00:21 +0100
Message-Id: 
References: <20131230151331.29E9F7FC393@rfc-editor.org> <52C19DF7.4050501@plixer.com> <52C232EB.30802@cisco.com>, <535E38C8-A1C0-4FD5-991C-D9A132D97923@tik.ee.ethz.ch> <0BEF0D66-E9DB-40E7-A2E4-ABCBCA5634CB@cisco.com> <52C2BC12.6090108@tik.ee.ethz.ch> <52C55358.5060402@cisco.com>
To: "stbryant@cisco.com Bryant" 
X-Mailer: Apple Mail (2.1827)
Cc: "joelja@bogus.com Jaeggli" , Nevil Brownlee , "ipfix@ietf.org Group" , RFC Errata System 
Subject: Re: [IPFIX] [Technical Errata Reported] RFC7012 (3852)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Jan 2014 10:00:38 -0000

--Apple-Mail=_E295AA1D-D0CC-4A6D-8559-9F83F04EE437
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_CF635E12-A250-403D-8127-C980E32B107A"


--Apple-Mail=_CF635E12-A250-403D-8127-C980E32B107A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

hi Stewart,

inline as per tradition=85

On 02 Jan 2014, at 12:54, Stewart Bryant  wrote:

> Brian
>=20
> Firstly going back to my original problem, I think that would be
> better addressed by
>=20
> OLD
> Definitions of timestamp data types have been clarified.
>=20
> NEW
>=20
> Definitions of timestamp data types have been clarified and=20
> the definition of the epochs has been moved to sections
> 6.1.7 through 6.1.11 of RFC 7011
>=20
> End
Okay, good point. this works for me.
> Your new text is also helpful.=20
>=20
> Then there is the problem of the IANA registry pointing to
> an obsolete RFC, which then takes you to RFC7012 which
> does not define the IEs.
>=20
> Consider IE 150, the reader is directed to RFC7012 by the
> registry header, and finds the datatype is dateTimeSeconds
> (which they dutifully look up in RFC7012 as indicated
> in the registry) they find the definition of dateTimeSeconds
> without the epoch and then what... For the definition
> of the IE to be complete, the reader needs the epoch
> which arguably now belongs in the registry, but is missing.
> I think that the root cause is that when we made the=20
> registry the definitive definition of the IEs, we
> did not add sufficient information in the case of the=20
> time definitions.
Okay, I understand your issue better here. We should consider a new =
erratum changing the introduction as well as para 2 section 3.1.
> Now we have one other issue which I have been puzzling
> over since you sent the email and can't quite get my
> head around. You use the term "value" in the ADT
> context. With for example i.e. 52 (min TTL) it's
> easy to imagine what "value" means however you=20
> represent it. However I am struggling to understand
> whether it is meaningful to define the "value" of IE=20
> 150: "The absolute timestamp of the first packet of=20
> this Flow" is without some specific epoch. This
> issue is addressed in I.E. 1 by specifying the count
> relative to a previous instance of count, so I think
> whilst that is a value, the timestamps are not.
But each timestamp value has an underlying real value, a moment in time. =
If you have a sequence of octets, you need both the ADT (7012) as well =
as the encoding (7011) to interpret it.=20

Take, for example, =9309:45:00 UTC on Friday 3 January 2014 CE=94. That =
string, interpreted by a human who makes a couple of basic assumptions =
(implicit selection of Gregorian over Julian calendar given the date, =
selection of a post-Julian solar calendar given the name of the month, =
presence in a negligibly accelerated reference frame with respect to =
Earth, a commonly agreed method of handling/ignoring leap seconds) =
unambiguously represents a single second in time. Which is what =
dateTimeSeconds is meant to do according to the 7012 definition. That =
second in time is the value.

The positive integer 1388742300 encoded as a big-endian unsigned32 is =
the IPFIX encoding of this value. This, as you say, requires an epoch, =
which is given in 7011. Without the epoch, you cannot interpret it at =
all.

The same value encoded as in draft-trammell-ipfix-text-adt would be =
=932014-01-03 09:45:00=94: less efficient that the IPFIX encoding, but =
more readable. There=92s an implicit epoch here as well (=932014=94 in =
this context taken to be years since 1 BCE), but it=92s a different =
epoch from that given in 7011; this is defined by reference, eventually, =
to ISO 8601.

So each instance of an IE of an ADT can take a value, and that value =
exists separate from its encoding. 7011 and 7012 together combine to =
make an unambiguous mapping between the two possible in IPFIX.

Cheers,

Brian

> We may need a call to work though this and another issue
> I am about to raise on the IPFIX list.
>=20
> - Stewart
>=20
> On 31/12/2013 12:44, Brian Trammell wrote:
>> hi Stewart,
>>=20
>> Stewart Bryant (stbryant) wrote:
>>> Certainly something is needed. I was thinking of using IPFIX as an =
information gathering method in a radio context, and went to look at the =
definition of the types and could not find the epoch, or even a =
reference to the epoch. Now part of the problem (which was my fault) was =
that I did not notice at the time that the elements were defined by the =
obsolete RFC5102 and went straight to the new RFC. However having the =
definitions in an obsolete RFC also seems problematic, since it puts the =
IEs in a strange state. Since RFC 7012 replaces RFC5102 and includes the =
definitions you would expect the definition in RFC7012 to replace the =
definition in RFC5102, but those definitions are, as I explained =
incomplete.
>> This is intentional. See below.
>>=20
>>> I need to look at this some more when I get back to work, but I am =
now also concerned that if the epoch can change, the definition of the =
existing IEs is now unreliable.
>> The definition of the existing IEs is based upon the definition of =
the
>> ADT itself in 7012 as well as the definition of the ADT =
representation
>> within the IPFIX protocol in 7011. It is not the intention that =
reading
>> 7012 tells you how to encode IEs for use with IPFIX; that's what =
section
>> 6.1 of 7011 is for.
>>=20
>>> You will notice in the errata that I did suggest that an alternative =
resolution would be to include a reference to the epoch text.
>> The point is that the ADT _explicitly_ does not have a binding to an
>> epoch, as epochs are only necessary when using integral =
representations
>> of timestamps. IPFIX's representations for these ADTs are integral, =
but
>> bindings to other representations need not be (see, for example,
>> draft-trammell-ipfix-text-adt, which recommends ISO8601-style =
timestamps
>> for textual representations of IE values).
>>=20
>> I'd suggest instead somehow expanding the present text in 7012 to
>> reiterate that if you're using IPFIX, the representations of the ADTs
>> are in 7011:
>>=20
>> OLD para 2 sec 3.1 7012:
>>=20
>>    The current encodings of these data types for use with the IPFIX
>>    protocol are defined in [RFC7011]; encodings allowing the use of =
the
>>    IPFIX Information Elements [IANA-IPFIX] with other protocols may =
be
>>    defined in the future by referencing this document.
>>=20
>> NEW para 2 sec 3.1 7012:
>>=20
>>    The abstract data type definitions in this section are intended
>>    only to define the values which can be taken by Information
>>    Elements of each type. The encodings of these data types for
>>    use with the IPFIX protocol are defined in Section 6.1 of
>>    [RFC7011]; encodings  allowing the use of the IPFIX Information
>>    Elements [IANA-IPFIX] with other protocols may be defined in the
>>    future by referencing this document.
>>=20
>> Best regards,
>>=20
>> Brian
>>=20
>>=20
>>> Stewart
>>>=20
>>>=20
>>>=20
>>> Sent from my iPad
>>>=20
>>>> On 31 Dec 2013, at 08:50, "Brian Trammell" =
 wrote:
>>>>=20
>>>> hi Paul, all,
>>>>=20
>>>> +n.
>>>>=20
>>>> The separation between ADTs and ADT encoding between 7012 and 7011 =
was explicit and purposeful. Specifically, we do _not_ want to exclude =
other representations of the IPFIX Information Model from being based =
upon other encodings of these ADTs, whether ISO 8601 (which either has =
no epoch or epoch 0000-00-00 00:00 UTC, depending on how you count), NTP =
(1904), Julian day based counting, etc, etc, etc=85
>>>>=20
>>>> If there is confusion on this point, I=92d suggest adding more =
explanatory text on this point to Paragraph 2 of the front matter to =
section 3.1. But as is, I emphatically recommend rejection of this =
reported erratum.
>>>>=20
>>>> Best regards,
>>>>=20
>>>> Brian
>>>>=20
>>>>> On 31 Dec 2013, at 03:58, Paul Aitken  wrote:
>>>>>=20
>>>>> +1
>>>>>=20
>>>>> If anyone was going to raise an errata on this, it would have been =
me ;-)
>>>>>=20
>>>>> I've pointed this issue out before, probably more than once - and =
have been encouraged to read RFC 3444.
>>>>>=20
>>>>> P.
>>>>>=20
>>>>>=20
>>>>>> On 30/12/2013 09:23, Andrew Feren wrote:
>>>>>> The encoding for the time data types is specified RFC 7011 =
Sections
>>>>>> 6.1.7 through 6.1.10.
>>>>>>=20
>>>>>> -Andrew
>>>>>>=20
>>>>>>> On 12/30/2013 10:13 AM, RFC Errata System wrote:
>>>>>>> The following errata report has been submitted for RFC7012,
>>>>>>> "Information Model for IP Flow Information Export (IPFIX)".
>>>>>>>=20
>>>>>>> --------------------------------------
>>>>>>> You may review the report below and at:
>>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D7012&eid=3D3852
>>>>>>>=20
>>>>>>> --------------------------------------
>>>>>>> Type: Technical
>>>>>>> Reported by: Stewart Bryant 
>>>>>>>=20
>>>>>>> Section: 3.1.15-17
>>>>>>>=20
>>>>>>> Original Text
>>>>>>> -------------
>>>>>>> 3.1.15. dateTimeSeconds
>>>>>>>=20
>>>>>>>   The type "dateTimeSeconds" represents a time value expressed =
with
>>>>>>>   second-level precision.
>>>>>>>=20
>>>>>>> 3.1.16. dateTimeMilliseconds
>>>>>>>=20
>>>>>>>   The type "dateTimeMilliseconds" represents a time value =
expressed
>>>>>>>   with millisecond-level precision.
>>>>>>>=20
>>>>>>> 3.1.17. dateTimeMicroseconds
>>>>>>>=20
>>>>>>>   The type "dateTimeMicroseconds" represents a time value =
expressed
>>>>>>>   with microsecond-level precision.
>>>>>>>=20
>>>>>>> 3.1.18. dateTimeNanoseconds
>>>>>>>=20
>>>>>>>   The type "dateTimeNanoseconds" represents a time value =
expressed with
>>>>>>>   nanosecond-level precision.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Corrected Text
>>>>>>> --------------
>>>>>>> 3.1.15. dateTimeSeconds
>>>>>>>=20
>>>>>>>   The type "dateTimeSeconds" represents a time value in units of
>>>>>>>   seconds based on coordinated universal time (UTC).  The choice =
of an
>>>>>>>   epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>>>>>>   corresponding encoding specifications for this type, for =
example, the
>>>>>>>   IPFIX protocol specification.  Leap seconds are excluded.  =
Note that
>>>>>>>   transformation of values might be required between different
>>>>>>>   encodings if different epoch values are used.
>>>>>>>=20
>>>>>>> 3.1.16. dateTimeMilliseconds
>>>>>>>=20
>>>>>>>   The type "dateTimeMilliseconds" represents a time value in =
units of
>>>>>>>   milliseconds based on coordinated universal time (UTC).  The =
choice
>>>>>>>   of an epoch, for example, 00:00 UTC, January 1, 1970, is left =
to
>>>>>>>   corresponding encoding specifications for this type, for =
example, the
>>>>>>>   IPFIX protocol specification.  Leap seconds are excluded.  =
Note that
>>>>>>>   transformation of values might be required between different
>>>>>>>   encodings if different epoch values are used.
>>>>>>>=20
>>>>>>> 3.1.17. dateTimeMicroseconds
>>>>>>>=20
>>>>>>>   The type "dateTimeMicroseconds" represents a time value in =
units of
>>>>>>>   microseconds based on coordinated universal time (UTC).  The =
choice
>>>>>>>   of an epoch, for example, 00:00 UTC, January 1, 1970, is left =
to
>>>>>>>   corresponding encoding specifications for this type, for =
example, the
>>>>>>>   IPFIX protocol specification.  Leap seconds are excluded.  =
Note that
>>>>>>>   transformation of values might be required between different
>>>>>>>   encodings if different epoch values are used.
>>>>>>>=20
>>>>>>> 3.1.18. dateTimeNanoseconds
>>>>>>>=20
>>>>>>>   The type "dateTimeNanoseconds" represents a time value in =
units of
>>>>>>>   nanoseconds based on coordinated universal time (UTC).  The =
choice of
>>>>>>>   an epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>>>>>>   corresponding encoding specifications for this type, for =
example, the
>>>>>>>   IPFIX protocol specification.  Leap seconds are excluded.  =
Note that
>>>>>>>   transformation of values might be required between different
>>>>>>>   encodings if different epoch values are used.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Notes
>>>>>>> -----
>>>>>>> Although section 1.1 says : - "Definitions of timestamp data =
types have been clarified." The edited text has removed the epoch =
definition, and this does not seem to have been incorporated elsewhere =
in the RFC.
>>>>>>>=20
>>>>>>> Without a specified epoch, there is no unique definition of the =
timestamps.
>>>>>>>=20
>>>>>>> My proposal above is to revert to the RFC5102 definitions. =
RFC7102 is intended to be backwards compatible with RFC5102 and thus the =
definitions need to be technically identical. Alternatively, if the text =
is now included elsewhere in RFC7012 or in another RFC, it would be =
helpful to the reader to provide a reference to the epoch definition in =
an editorial update to dateTimeX definitions in RFC7102.
>>>>>>>=20
>>>>>>> Instructions:
>>>>>>> -------------
>>>>>>> This errata is currently posted as "Reported". If necessary, =
please
>>>>>>> use "Reply All" to discuss whether it should be verified or
>>>>>>> rejected. When a decision is reached, the verifying party (IESG)
>>>>>>> can log in to change the status and edit the report, if =
necessary.
>>>>>>>=20
>>>>>>> --------------------------------------
>>>>>>> RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10)
>>>>>>> --------------------------------------
>>>>>>> Title               : Information Model for IP Flow Information =
Export (IPFIX)
>>>>>>> Publication Date    : September 2013
>>>>>>> Author(s)           : B. Claise, Ed., B. Trammell, Ed.
>>>>>>> Category            : PROPOSED STANDARD
>>>>>>> Source              : IP Flow Information Export
>>>>>>> Area                : Operations and Management
>>>>>>> Stream              : IETF
>>>>>>> Verifying Party     : IESG
>>>>>>> _______________________________________________
>>>>>>> IPFIX mailing list
>>>>>>> IPFIX@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>>> _______________________________________________
>>>>>> IPFIX mailing list
>>>>>> IPFIX@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>> _______________________________________________
>>>> IPFIX mailing list
>>>> IPFIX@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ipfix
>=20
>=20
> --=20
> For corporate legal information go to:
>=20
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>=20


--Apple-Mail=_CF635E12-A250-403D-8127-C980E32B107A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

hi =
Stewart,

inline as per =
tradition=85

On 02 Jan 2014, at 12:54, Stewart =
Bryant <stbryant@cisco.com> =
wrote:


 =20
    
 =20
  

    
Brian

      

      Firstly going back to my original problem, I think that would =
be

      better addressed by

      

      OLD

      
      
Definitions of timestamp data types have =
been clarified.

NEW

Definitions of timestamp data types have been clarified and=20
the definition of the epochs has been moved to sections
6.1.7 through 6.1.11 of RFC 7011

End
Okay, good point. this works for =
me.
Your new text is also helpful.=20

Then there is the problem of the IANA registry pointing to
an obsolete RFC, which then takes you to RFC7012 which
does not define the IEs.

Consider IE 150, the reader is directed to RFC7012 by the
registry header, and finds the datatype is dateTimeSeconds
(which they dutifully look up in RFC7012 as indicated
in the registry) they find the definition of dateTimeSeconds
without the epoch and then what... For the definition
of the IE to be complete, the reader needs the epoch
which arguably now belongs in the registry, but is missing.
I think that the root cause is that when we made the=20
registry the definitive definition of the IEs, we
did not add sufficient information in the case of the=20
time definitions.

Okay, I understand your issue better =
here. We should consider a new erratum changing the introduction as well =
as para 2 section 3.1.
Now we have one other issue which I have been puzzling
over since you sent the email and can't quite get my
head around. You use the term "value" in the ADT
context. With for example i.e. 52 (min TTL) it's
easy to imagine what "value" means however you=20
represent it. However I am struggling to understand
whether it is meaningful to define the "value" of IE =

150: "The absolute timestamp of the first packet of=20=

this Flow" is without some specific epoch. This
issue is addressed in I.E. 1 by specifying the count
relative to a previous instance of count, so I think
whilst that is a value, the timestamps are not.

But each timestamp value has an =
underlying real value, a moment in time. If you have a sequence of =
octets, you need both the ADT (7012) as well as the encoding (7011) to =
interpret it. 

Take, for example, =
=9309:45:00 UTC on Friday 3 January 2014 CE=94. That string, interpreted =
by a human who makes a couple of basic assumptions (implicit selection =
of Gregorian over Julian calendar given the date, selection of a =
post-Julian solar calendar given the name of the month, presence in a =
negligibly accelerated reference frame with respect to Earth, a commonly =
agreed method of handling/ignoring leap seconds) unambiguously =
represents a single second in time. Which is what dateTimeSeconds is =
meant to do according to the 7012 definition. That second in time is the =
value.

The positive integer 1388742300 encoded =
as a big-endian unsigned32 is the IPFIX encoding of this value. This, as =
you say, requires an epoch, which is given in 7011. Without the epoch, =
you cannot interpret it at all.

The same value =
encoded as in draft-trammell-ipfix-text-adt would be =932014-01-03 =
09:45:00=94: less efficient that the IPFIX encoding, but more readable. =
There=92s an implicit epoch here as well (=932014=94 in this context =
taken to be years since 1 BCE), but it=92s a different epoch from that =
given in 7011; this is defined by reference, eventually, to ISO =
8601.

So each instance of an IE of an ADT can =
take a value, and that value exists separate from its encoding. 7011 and =
7012 together combine to make an unambiguous mapping between the two =
possible in =
IPFIX.

Cheers,

Brian
We =
may need a call to work though this and another issue
I am about to raise on the IPFIX list.

- Stewart



      On 31/12/2013 12:44, Brian Trammell wrote:

    

    

      
hi Stewart,

Stewart Bryant (stbryant) wrote:


      

        
Certainly something is needed. I was thinking of =
using IPFIX as an information gathering method in a radio context, and =
went to look at the definition of the types and could not find the =
epoch, or even a reference to the epoch. Now part of the problem (which =
was my fault) was that I did not notice at the time that the elements =
were defined by the obsolete RFC5102 and went straight to the new RFC. =
However having the definitions in an obsolete RFC also seems =
problematic, since it puts the IEs in a strange state. Since RFC 7012 =
replaces RFC5102 and includes the definitions you would expect the =
definition in RFC7012 to replace the definition in RFC5102, but those =
definitions are, as I explained incomplete.


      

      
This is intentional. See below.



      

        
I need to look at this some more when I get back =
to work, but I am now also concerned that if the epoch can change, the =
definition of the existing IEs is now unreliable.


      

      
The definition of the existing IEs is based upon =
the definition of the
ADT itself in 7012 as well as the definition of the ADT representation
within the IPFIX protocol in 7011. It is not the intention that reading
7012 tells you how to encode IEs for use with IPFIX; that's what section
6.1 of 7011 is for.



      

        
You will notice in the errata that I did suggest =
that an alternative resolution would be to include a reference to the =
epoch text.


      

      
The point is that the ADT _explicitly_ does not =
have a binding to an
epoch, as epochs are only necessary when using integral representations
of timestamps. IPFIX's representations for these ADTs are integral, but
bindings to other representations need not be (see, for example,
draft-trammell-ipfix-text-adt, which recommends ISO8601-style timestamps
for textual representations of IE values).

I'd suggest instead somehow expanding the present text in 7012 to
reiterate that if you're using IPFIX, the representations of the ADTs
are in 7011:

OLD para 2 sec 3.1 7012:

   The current encodings of these data types for use with the IPFIX
   protocol are defined in [RFC7011]; encodings allowing the use of the
   IPFIX Information Elements [IANA-IPFIX] with other protocols may be
   defined in the future by referencing this document.

NEW para 2 sec 3.1 7012:

   The abstract data type definitions in this section are intended
   only to define the values which can be taken by Information
   Elements of each type. The encodings of these data types for
   use with the IPFIX protocol are defined in Section 6.1 of
   [RFC7011]; encodings  allowing the use of the IPFIX Information
   Elements [IANA-IPFIX] with other protocols may be defined in the
   future by referencing this document.

Best regards,

Brian




      

        
Stewart



Sent from my iPad



        

          
On 31 Dec 2013, at 08:50, "Brian Trammell" <trammell@tik.ee.ethz.ch> wrote:

hi Paul, all,

+n.

The separation between ADTs and ADT encoding between 7012 and 7011 was =
explicit and purposeful. Specifically, we do _not_ want to exclude other =
representations of the IPFIX Information Model from being based upon =
other encodings of these ADTs, whether ISO 8601 (which either has no =
epoch or epoch 0000-00-00 00:00 UTC, depending on how you count), NTP =
(1904), Julian day based counting, etc, etc, etc=85

If there is confusion on this point, I=92d suggest adding more =
explanatory text on this point to Paragraph 2 of the front matter to =
section 3.1. But as is, I emphatically recommend rejection of this =
reported erratum.

Best regards,

Brian



          

            
On 31 Dec 2013, at 03:58, Paul Aitken <paitken@cisco.com> wrote:

+1

If anyone was going to raise an errata on this, it would have been me =
;-)

I've pointed this issue out before, probably more than once - and have =
been encouraged to read RFC 3444.

P.




            

              
On 30/12/2013 09:23, Andrew Feren wrote:
The encoding for the time data types is specified RFC 7011 Sections
6.1.7 through 6.1.10.

-Andrew



              

                
On 12/30/2013 10:13 AM, RFC Errata System =
wrote:
The following errata report has been submitted for RFC7012,
"Information Model for IP Flow Information Export (IPFIX)".

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


--------------------------------------
Type: Technical
Reported by: Stewart Bryant <stbryant@cisco.com>

Section: 3.1.15-17

Original Text
-------------
3.1.15. dateTimeSeconds

  The type "dateTimeSeconds" represents a time value expressed with
  second-level precision.

3.1.16. dateTimeMilliseconds

  The type "dateTimeMilliseconds" represents a time value expressed
  with millisecond-level precision.

3.1.17. dateTimeMicroseconds

  The type "dateTimeMicroseconds" represents a time value expressed
  with microsecond-level precision.

3.1.18. dateTimeNanoseconds

  The type "dateTimeNanoseconds" represents a time value expressed with
  nanosecond-level precision.


Corrected Text
--------------
3.1.15. dateTimeSeconds

  The type "dateTimeSeconds" represents a time value in units of
  seconds based on coordinated universal time (UTC).  The choice of an
  epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.16. dateTimeMilliseconds

  The type "dateTimeMilliseconds" represents a time value in units of
  milliseconds based on coordinated universal time (UTC).  The choice
  of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.17. dateTimeMicroseconds

  The type "dateTimeMicroseconds" represents a time value in units of
  microseconds based on coordinated universal time (UTC).  The choice
  of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.18. dateTimeNanoseconds

  The type "dateTimeNanoseconds" represents a time value in units of
  nanoseconds based on coordinated universal time (UTC).  The choice of
  an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.


Notes
-----
Although section 1.1 says : - "Definitions of timestamp data types have =
been clarified." The edited text has removed the epoch definition, and =
this does not seem to have been incorporated elsewhere in the RFC.

Without a specified epoch, there is no unique definition of the =
timestamps.

My proposal above is to revert to the RFC5102 definitions. RFC7102 is =
intended to be backwards compatible with RFC5102 and thus the =
definitions need to be technically identical. Alternatively, if the text =
is now included elsewhere in RFC7012 or in another RFC, it would be =
helpful to the reader to provide a reference to the epoch definition in =
an editorial update to dateTimeX definitions in RFC7102.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10)
--------------------------------------
Title               : Information Model for IP Flow Information Export =
(IPFIX)
Publication Date    : September 2013
Author(s)           : B. Claise, Ed., B. Trammell, Ed.
Category            : PROPOSED STANDARD
Source              : IP Flow Information Export
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/=
mailman/listinfo/ipfix


              

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


            

          

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


        

      

      

    

    

    

    
--=20
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html



  




=

--Apple-Mail=_CF635E12-A250-403D-8127-C980E32B107A--

--Apple-Mail=_E295AA1D-D0CC-4A6D-8559-9F83F04EE437
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSxoo1AAoJENt3nsOmbNJctTIIALXb6bmLdrHCB/TvLr6SROtC
tEeqYbD4sPu7jeToWSqKgp9T3y5FBgsInbBKiMimnZG8MLbYP7gZAfgCycuEj1pe
idKfuimRPVAZh7wRwxjbsUwJRmTrA4AOGrn0iLgtzggwzka53QtjUXiQ/0n/ZB73
Txu9RZdzQriHYeQdO/Vsta/980iQZf5zDJ5dT1bw4fUTT7FvN3/CXejQQ3r7YQXn
UDZFGeR+NrFcWnLNCjeMmN+RuakZ7aLQR5NNRQixUH/iZtiOGsPZBpdIkRoE8npY
FYVEE7P8+ErmlW2e/8SidJJilRBLiDsH0qUvf87UUdJ+I1x4vyRwl0Eck7Arr70=
=tS6d
-----END PGP SIGNATURE-----

--Apple-Mail=_E295AA1D-D0CC-4A6D-8559-9F83F04EE437--

From stbryant@cisco.com  Fri Jan  3 04:06:43 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617A81ADF95 for ; Fri,  3 Jan 2014 04:06:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.438
X-Spam-Level: 
X-Spam-Status: No, score=-9.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_zUxv4jc-mV for ; Fri,  3 Jan 2014 04:06:40 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD111ADF91 for ; Fri,  3 Jan 2014 04:06:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13632; q=dns/txt; s=iport; t=1388750793; x=1389960393; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=dYHS946NvM+Vhh0YSA2Gp86uz4UHD1zuKY0q6U5+X+4=; b=hoK2nIRoXe8lGB97/8ZAA6hF4KmW7yb3T4cjuHhyEnwXDY9AgX2lmE4e 1AYudVkIXKDnP1/ThPfslgbWZFR8AzHAJz5EzmHcua+ddWlCjZKgw0N2G wXQW5iGlik+CR0i3R/sYm9lmJ4auzzQsgv09/i/Q/A3tDFPf+HA5sTdtz U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtMGAO6mxlKQ/khR/2dsb2JhbABOCoMLOLENiFSBDRZ0giUBAQEDAXgBEAsYCRYPCQMCAQIBRQYNAQUCAQEXh2EIDcMJF44uDk4HhDYEmBeBMJBkgy0
X-IronPort-AV: E=Sophos;i="4.95,597,1384300800"; d="scan'208,217";a="2472050"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 03 Jan 2014 12:06:31 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s03C6VT2009943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jan 2014 12:06:31 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s03C6Ubk009943; Fri, 3 Jan 2014 12:06:30 GMT
Message-ID: <52C6A7C6.1020703@cisco.com>
Date: Fri, 03 Jan 2014 12:06:30 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Brian Trammell 
References: <52C56FA7.6070905@cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010202070008060700040704"
Cc: ipfix-ads@tools.ietf.org, "ipfix@ietf.org Group" , "ipfix-chairs@tools.ietf.org" 
Subject: Re: [IPFIX] Application of IPFIX to new application spaces.
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Jan 2014 12:06:43 -0000

This is a multi-part message in MIME format.
--------------010202070008060700040704
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

On 03/01/2014 09:39, Brian Trammell wrote:
> hi Stewart,
>
> Wanted to reply briefly to two points here inline (will reply in more detail later):
>
> On 02 Jan 2014, at 14:54, Stewart Bryant  wrote:
>
>> Whilst I accept that IPFIX is pretty much complete in terms of
>> addressing it's original goals as a network management
>> protocol, I have some concerns about it's completeness
>> as an  observation reporting protocol. I think these need
>> to be addressed, before declaring completion of the work
>> programme as a whole.
>>
>> (In my own time) I am looking at the definition of a protocol
>> to observe and report the radio noise floor. The purpose
>> is to map the rise in the radio noise floor due to RF pollution
>> from domestic and industrial digital systems such as
>> plasma televisions, and power line (digital) transmission
>> systems. IPFIX is a good protocol for such mass observations,
>> and has been used successfully in the radio propagation
>> monitoring system pskreporter.
>>
>> In doing this I ran into two problems, firstly there are no
>> experimental IE types, and thus I cannot prototype the
>> application without either "camping" on a set of IEs, or
>> waiting until I am allocated a PEN.
> I’m a little puzzled about the hesitation about getting a PEN; indeed, in my experience, had you applied for a PEN for this purpose when you sent this message initially you’d have one by now. There is a little overhead in managing PEN space for different experiments (see https://trammell.ch/pen-35566 for the range registry used for my own experimentation) but this is orders of magnitude less work than designing and implementing the IEs in the first place.
I brought up the concept of ownership of PENs by individuals
in a couple of IESG discussions on IPFIX, and the opinion that
I get (as I recall from the APPs ADs) is that PENs were never
intended to be assigned to individuals together with surprise
that any had been allocated to individuals. Hence my initial
reluctance. I know that there are some other owned by individuals,
and I  have requested one for the purpose of trying out this
application of the protocol. However I think the concern is
that it would not scale if every individual experimenter
requested their own, much less one per experiment.

>
> I could see this being a problem if one were trying to run many experiments within the same very large organization with undefined or draconian processes for reserving an enterprise-specific IE. But PEN space is 2^32-1 large and we haven;t even exhausted the first block of 2^16, so “get a new PEN and label it useful for a given experiment” is probably an acceptable way out of this quandary.
I think the question is one of whether or not that is best practice.
Sure the space is large, but so was the IPv4 Address space when it
was created :)
>
>> For reasons that will
>> be clear from other work I have done in the IETF, I dislike
>> the idea of "camping" on code-points. This makes it clear
>> to me that we need a small, but not trivial set of
>> experimental IEs that are intended for prototyping but
>> explicitly excluded from use in production systems.
>> This needs to be a reasonable number since a new application
>> space might need a fair number of IEs to be practical.
>> Thus I think that we need to either allocate some of the
>> base protocol IEs to experimental, or to have IANA
>> allocate a PEN specifically to experimental use which
>> would allow experimentation in new applications spaces
>> without the need to formally allocate IEs in either the
>> base IE space, or the PEN space of the organization
>> (or person) conducting the experiment.
> I agree in principle that allocating a single “IPFIX Experimentation” PEN would be one solution to this problem, but it would have to be fairly tightly scoped (only for experimental use among EPs and CPs implemented and deployed by a single entity within the scope of a single experiment; MUST be logged as an error by CPs in production use). And I’d be very concerned that we were basically inviting people to camp on a whole new code space — requiring experiments to use their own PEN space at least keeps experimental IEs that “leak” into production from colliding with each other, provided that the PEN owner manages their own space competently.
Text of the following format needs to be associated with the
space:

Code points in the experimental range MUST be used according to the
guidelines ofRFC 3692    [RFC3692  ].


>
>> The second problem that I see is the lack of a public registry
>> for non-network managements applications. Specifically
>> I am going to need "callsign", "maidenhead locator",
>> "frequency", "noise power", maybe "field strength", "receiver type"
>> etc. Now some of those may be of general use (frequency)
>> but most of them would be cruft in the base protocol IE set
>> which is set up for networking applications. On the other hand,
>> I know of at least one PEN space that will have a number of the
>> terms I need already defined, although these are by
>> definition private. With the current IE registration structure
>> the absence of a public registry inevitably means the
>> redefinition of other than mainstream/network management
>> terms across a number of private registries. I thus think
>> it would be useful to introduce a PEN + registry for
>> "other applications" or introduce the concept of a series
>> of application specific registries with appropriate  PENs to
>> identify the application space rather than  the private
>> enterprise space.
> This seems like a very good idea. I’ll have to think about it some more.
>
> Thanks, cheers,
>
> Brian
>
Thanks

Stewart

--------------010202070008060700040704
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 03/01/2014 09:39, Brian Trammell
      wrote:

    

    

      
hi Stewart,

Wanted to reply briefly to two points here inline (will reply in more detail later):

On 02 Jan 2014, at 14:54, Stewart Bryant <stbryant@cisco.com> wrote:



      

        
Whilst I accept that IPFIX is pretty much complete in terms of
addressing it's original goals as a network management
protocol, I have some concerns about it's completeness
as an  observation reporting protocol. I think these need
to be addressed, before declaring completion of the work
programme as a whole.

(In my own time) I am looking at the definition of a protocol
to observe and report the radio noise floor. The purpose
is to map the rise in the radio noise floor due to RF pollution
from domestic and industrial digital systems such as
plasma televisions, and power line (digital) transmission
systems. IPFIX is a good protocol for such mass observations,
and has been used successfully in the radio propagation
monitoring system pskreporter.

In doing this I ran into two problems, firstly there are no
experimental IE types, and thus I cannot prototype the
application without either "camping" on a set of IEs, or
waiting until I am allocated a PEN.


      

      
I’m a little puzzled about the hesitation about getting a PEN; indeed, in my experience, had you applied for a PEN for this purpose when you sent this message initially you’d have one by now. There is a little overhead in managing PEN space for different experiments (see https://trammell.ch/pen-35566 for the range registry used for my own experimentation) but this is orders of magnitude less work than designing and implementing the IEs in the first place.

    

    I brought up the concept of ownership of PENs by individuals 

    in a couple of IESG discussions on IPFIX, and the opinion that

    I get (as I recall from the APPs ADs) is that PENs were never 

    intended to be assigned to individuals together with surprise

    that any had been allocated to individuals. Hence my initial 

    reluctance. I know that there are some other owned by individuals, 

    and I  have requested one for the purpose of trying out this 

    application of the protocol. However I think the concern is 

    that it would not scale if every individual experimenter 

    requested their own, much less one per experiment.

    

    

      

I could see this being a problem if one were trying to run many experiments within the same very large organization with undefined or draconian processes for reserving an enterprise-specific IE. But PEN space is 2^32-1 large and we haven;t even exhausted the first block of 2^16, so “get a new PEN and label it useful for a given experiment” is probably an acceptable way out of this quandary.

    

    I think the question is one of whether or not that is best practice.

    Sure the space is large, but so was the IPv4 Address space when it

    was created :)

    

      



      

        
For reasons that will
be clear from other work I have done in the IETF, I dislike
the idea of "camping" on code-points. This makes it clear
to me that we need a small, but not trivial set of
experimental IEs that are intended for prototyping but
explicitly excluded from use in production systems.
This needs to be a reasonable number since a new application
space might need a fair number of IEs to be practical.
Thus I think that we need to either allocate some of the
base protocol IEs to experimental, or to have IANA
allocate a PEN specifically to experimental use which
would allow experimentation in new applications spaces
without the need to formally allocate IEs in either the
base IE space, or the PEN space of the organization
(or person) conducting the experiment.


      

      
I agree in principle that allocating a single “IPFIX Experimentation” PEN would be one solution to this problem, but it would have to be fairly tightly scoped (only for experimental use among EPs and CPs implemented and deployed by a single entity within the scope of a single experiment; MUST be logged as an error by CPs in production use). And I’d be very concerned that we were basically inviting people to camp on a whole new code space — requiring experiments to use their own PEN space at least keeps experimental IEs that “leak” into production from colliding with each other, provided that the PEN owner manages their own space competently.

    

    Text of the following format needs to be associated with the

    space:

    
    
Code points in the experimental range MUST be used according to the
guidelines of RFC 3692 [RFC3692].

    

    

      



      

        
The second problem that I see is the lack of a public registry
for non-network managements applications. Specifically
I am going to need "callsign", "maidenhead locator",
"frequency", "noise power", maybe "field strength", "receiver type"
etc. Now some of those may be of general use (frequency)
but most of them would be cruft in the base protocol IE set
which is set up for networking applications. On the other hand,
I know of at least one PEN space that will have a number of the
terms I need already defined, although these are by
definition private. With the current IE registration structure
the absence of a public registry inevitably means the
redefinition of other than mainstream/network management
terms across a number of private registries. I thus think
it would be useful to introduce a PEN + registry for
"other applications" or introduce the concept of a series
of application specific registries with appropriate  PENs to
identify the application space rather than  the private
enterprise space.


      

      
This seems like a very good idea. I’ll have to think about it some more.

Thanks, cheers,

Brian



    

    Thanks

    

    Stewart

  


--------------010202070008060700040704--

From stbryant@cisco.com  Fri Jan  3 04:12:12 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175D11ADF96 for ; Fri,  3 Jan 2014 04:12:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.038
X-Spam-Level: 
X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBq9Xwvw4UYE for ; Fri,  3 Jan 2014 04:12:08 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9FADA1ADF8D for ; Fri,  3 Jan 2014 04:12:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34765; q=dns/txt; s=iport; t=1388751119; x=1389960719; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=Kztbm+E7vOvyTpcKvp5orC7cUHMARYB8Zr75LBkDIus=; b=bdx2dOLWcpwDgK4k48DsoYd0d0vMbmddY5vG1+DV6pmyymVSk8fKO6io sfd54jtk6G1ct44NGr7HyISRU5qgY1cwgZNqHG5NpywivHaXjvA5LEr/s i7ze8TJ7Vr9awbJfyxjjYfw9ELj5Uf8Gg3KCtzQoW7wEL7XsWMqWzGi9D E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAA6oxlKQ/khM/2dsb2JhbAA+GoMLOLlhgQ0WdIIlAQEBAwEBAQEXVAoBEAsYCRYBBwcJAwIBAgEVHxEGDQEFAgEBh3gIDTbCVBeOKBEBUAeENgSYF5IUgy15eA
X-IronPort-AV: E=Sophos;i="4.95,597,1384300800"; d="scan'208,217";a="2472217"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 03 Jan 2014 12:11:58 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s03CBvXe005715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jan 2014 12:11:57 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s03CBbKN010261; Fri, 3 Jan 2014 12:11:37 GMT
Message-ID: <52C6A8F9.7070706@cisco.com>
Date: Fri, 03 Jan 2014 12:11:37 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Brian Trammell 
References: <20131230151331.29E9F7FC393@rfc-editor.org> <52C19DF7.4050501@plixer.com> <52C232EB.30802@cisco.com>, <535E38C8-A1C0-4FD5-991C-D9A132D97923@tik.ee.ethz.ch> <0BEF0D66-E9DB-40E7-A2E4-ABCBCA5634CB@cisco.com> <52C2BC12.6090108@tik.ee.ethz.ch> <52C55358.5060402@cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010507000001050103010401"
Cc: "joelja@bogus.com Jaeggli" , Nevil Brownlee , "ipfix@ietf.org Group" , RFC Errata System 
Subject: Re: [IPFIX] [Technical Errata Reported] RFC7012 (3852)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Jan 2014 12:12:12 -0000

This is a multi-part message in MIME format.
--------------010507000001050103010401
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Brian

We are getting there.

On 03/01/2014 10:00, Brian Trammell wrote:
> hi Stewart,
>
> inline as per tradition…
>
> On 02 Jan 2014, at 12:54, Stewart Bryant  > wrote:
>
>> Brian
>>
>> Firstly going back to my original problem, I think that would be
>> better addressed by
>>
>> OLD
>> Definitions of timestamp data types have been clarified.
>>
>> NEW
>>
>> Definitions of timestamp data types have been clarified and
>> the definition of the epochs has been moved to sections
>> 6.1.7 through 6.1.11 of RFC 7011
>>
>> End
> Okay, good point. this works for me.
>> Your new text is also helpful.
>>
>> Then there is the problem of the IANA registry pointing to
>> an obsolete RFC, which then takes you to RFC7012 which
>> does not define the IEs.
>>
>> Consider IE 150, the reader is directed to RFC7012 by the
>> registry header, and finds the datatype isdateTimeSeconds
>> (which they dutifully look up in RFC7012 as indicated
>> in the registry) they find the definition of dateTimeSeconds
>> without the epoch and then what... For the definition
>> of the IE to be complete, the reader needs the epoch
>> which arguably now belongs in the registry, but is missing.
>> I think that the root cause is that when we made the
>> registry the definitive definition of the IEs, we
>> did not add sufficient information in the case of the
>> time definitions.
> Okay, I understand your issue better here. We should consider a new 
> erratum changing the introduction as well as para 2 section 3.1.
>> Now we have one other issue which I have been puzzling
>> over since you sent the email and can't quite get my
>> head around. You use the term "value" in the ADT
>> context. With for example i.e. 52 (min TTL) it's
>> easy to imagine what "value" means however you
>> represent it. However I am struggling to understand
>> whether it is meaningful to define the "value" of IE
>> 150:"The absolute timestamp of the first packet of
>> this Flow" is without some specific epoch. This
>> issue is addressed in I.E. 1 by specifying the count
>> relative to a previous instance of count, so I think
>> whilst that is a value, the timestamps are not.
> But each timestamp value has an underlying real value, a moment in 
> time. If you have a sequence of octets, you need both the ADT (7012) 
> as well as the encoding (7011) to interpret it.
>
> Take, for example, “09:45:00 UTC on Friday 3 January 2014 CE”. That 
> string, interpreted by a human who makes a couple of basic assumptions 
> (implicit selection of Gregorian over Julian calendar given the date, 
> selection of a post-Julian solar calendar given the name of the month, 
> presence in a negligibly accelerated reference frame with respect to 
> Earth, a commonly agreed method of handling/ignoring leap seconds) 
> unambiguously represents a single second in time. Which is what 
> dateTimeSeconds is meant to do according to the 7012 definition. That 
> second in time is the value.
>
> The positive integer 1388742300 encoded as a big-endian unsigned32 is 
> the IPFIX encoding of this value. This, as you say, requires an epoch, 
> which is given in 7011. Without the epoch, you cannot interpret it at all.
>
> The same value encoded as in draft-trammell-ipfix-text-adt would be 
> “2014-01-03 09:45:00”: less efficient that the IPFIX encoding, but 
> more readable. There’s an implicit epoch here as well (“2014” in this 
> context taken to be years since 1 BCE), but it’s a different epoch 
> from that given in 7011; this is defined by reference, eventually, to 
> ISO 8601.
>
> So each instance of an IE of an ADT can take a value, and that value 
> exists separate from its encoding. 7011 and 7012 together combine to 
> make an unambiguous mapping between the two possible in IPFIX.

I think the key is the last sentence, and so long as we make that clear 
we are good.

Maybe some text of the form "relative to the defined epoch" would sort 
it out. At least
that would remind the reader that they needs to know rather than assume 
the epoch.

- Stewart

>
> Cheers,
>
> Brian
>
>> We may need a call to work though this and another issue
>> I am about to raise on the IPFIX list.
>>
>> - Stewart
>>
>> On 31/12/2013 12:44, Brian Trammell wrote:
>>> hi Stewart,
>>>
>>> Stewart Bryant (stbryant) wrote:
>>>> Certainly something is needed. I was thinking of using IPFIX as an information gathering method in a radio context, and went to look at the definition of the types and could not find the epoch, or even a reference to the epoch. Now part of the problem (which was my fault) was that I did not notice at the time that the elements were defined by the obsolete RFC5102 and went straight to the new RFC. However having the definitions in an obsolete RFC also seems problematic, since it puts the IEs in a strange state. Since RFC 7012 replaces RFC5102 and includes the definitions you would expect the definition in RFC7012 to replace the definition in RFC5102, but those definitions are, as I explained incomplete.
>>> This is intentional. See below.
>>>
>>>> I need to look at this some more when I get back to work, but I am now also concerned that if the epoch can change, the definition of the existing IEs is now unreliable.
>>> The definition of the existing IEs is based upon the definition of the
>>> ADT itself in 7012 as well as the definition of the ADT representation
>>> within the IPFIX protocol in 7011. It is not the intention that reading
>>> 7012 tells you how to encode IEs for use with IPFIX; that's what section
>>> 6.1 of 7011 is for.
>>>
>>>> You will notice in the errata that I did suggest that an alternative resolution would be to include a reference to the epoch text.
>>> The point is that the ADT _explicitly_ does not have a binding to an
>>> epoch, as epochs are only necessary when using integral representations
>>> of timestamps. IPFIX's representations for these ADTs are integral, but
>>> bindings to other representations need not be (see, for example,
>>> draft-trammell-ipfix-text-adt, which recommends ISO8601-style timestamps
>>> for textual representations of IE values).
>>>
>>> I'd suggest instead somehow expanding the present text in 7012 to
>>> reiterate that if you're using IPFIX, the representations of the ADTs
>>> are in 7011:
>>>
>>> OLD para 2 sec 3.1 7012:
>>>
>>>     The current encodings of these data types for use with the IPFIX
>>>     protocol are defined in [RFC7011]; encodings allowing the use of the
>>>     IPFIX Information Elements [IANA-IPFIX] with other protocols may be
>>>     defined in the future by referencing this document.
>>>
>>> NEW para 2 sec 3.1 7012:
>>>
>>>     The abstract data type definitions in this section are intended
>>>     only to define the values which can be taken by Information
>>>     Elements of each type. The encodings of these data types for
>>>     use with the IPFIX protocol are defined in Section 6.1 of
>>>     [RFC7011]; encodings  allowing the use of the IPFIX Information
>>>     Elements [IANA-IPFIX] with other protocols may be defined in the
>>>     future by referencing this document.
>>>
>>> Best regards,
>>>
>>> Brian
>>>
>>>
>>>> Stewart
>>>>
>>>>
>>>>
>>>> Sent from my iPad
>>>>
>>>>> On 31 Dec 2013, at 08:50, "Brian Trammell"  wrote:
>>>>>
>>>>> hi Paul, all,
>>>>>
>>>>> +n.
>>>>>
>>>>> The separation between ADTs and ADT encoding between 7012 and 7011 was explicit and purposeful. Specifically, we do _not_ want to exclude other representations of the IPFIX Information Model from being based upon other encodings of these ADTs, whether ISO 8601 (which either has no epoch or epoch 0000-00-00 00:00 UTC, depending on how you count), NTP (1904), Julian day based counting, etc, etc, etc…
>>>>>
>>>>> If there is confusion on this point, I’d suggest adding more explanatory text on this point to Paragraph 2 of the front matter to section 3.1. But as is, I emphatically recommend rejection of this reported erratum.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Brian
>>>>>
>>>>>> On 31 Dec 2013, at 03:58, Paul Aitken  wrote:
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> If anyone was going to raise an errata on this, it would have been me ;-)
>>>>>>
>>>>>> I've pointed this issue out before, probably more than once - and have been encouraged to read RFC 3444.
>>>>>>
>>>>>> P.
>>>>>>
>>>>>>
>>>>>>> On 30/12/2013 09:23, Andrew Feren wrote:
>>>>>>> The encoding for the time data types is specified RFC 7011 Sections
>>>>>>> 6.1.7 through 6.1.10.
>>>>>>>
>>>>>>> -Andrew
>>>>>>>
>>>>>>>> On 12/30/2013 10:13 AM, RFC Errata System wrote:
>>>>>>>> The following errata report has been submitted for RFC7012,
>>>>>>>> "Information Model for IP Flow Information Export (IPFIX)".
>>>>>>>>
>>>>>>>> --------------------------------------
>>>>>>>> You may review the report below and at:
>>>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=7012&eid=3852
>>>>>>>>
>>>>>>>> --------------------------------------
>>>>>>>> Type: Technical
>>>>>>>> Reported by: Stewart Bryant
>>>>>>>>
>>>>>>>> Section: 3.1.15-17
>>>>>>>>
>>>>>>>> Original Text
>>>>>>>> -------------
>>>>>>>> 3.1.15. dateTimeSeconds
>>>>>>>>
>>>>>>>>    The type "dateTimeSeconds" represents a time value expressed with
>>>>>>>>    second-level precision.
>>>>>>>>
>>>>>>>> 3.1.16. dateTimeMilliseconds
>>>>>>>>
>>>>>>>>    The type "dateTimeMilliseconds" represents a time value expressed
>>>>>>>>    with millisecond-level precision.
>>>>>>>>
>>>>>>>> 3.1.17. dateTimeMicroseconds
>>>>>>>>
>>>>>>>>    The type "dateTimeMicroseconds" represents a time value expressed
>>>>>>>>    with microsecond-level precision.
>>>>>>>>
>>>>>>>> 3.1.18. dateTimeNanoseconds
>>>>>>>>
>>>>>>>>    The type "dateTimeNanoseconds" represents a time value expressed with
>>>>>>>>    nanosecond-level precision.
>>>>>>>>
>>>>>>>>
>>>>>>>> Corrected Text
>>>>>>>> --------------
>>>>>>>> 3.1.15. dateTimeSeconds
>>>>>>>>
>>>>>>>>    The type "dateTimeSeconds" represents a time value in units of
>>>>>>>>    seconds based on coordinated universal time (UTC).  The choice of an
>>>>>>>>    epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>>>>>>>    corresponding encoding specifications for this type, for example, the
>>>>>>>>    IPFIX protocol specification.  Leap seconds are excluded.  Note that
>>>>>>>>    transformation of values might be required between different
>>>>>>>>    encodings if different epoch values are used.
>>>>>>>>
>>>>>>>> 3.1.16. dateTimeMilliseconds
>>>>>>>>
>>>>>>>>    The type "dateTimeMilliseconds" represents a time value in units of
>>>>>>>>    milliseconds based on coordinated universal time (UTC).  The choice
>>>>>>>>    of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>>>>>>>    corresponding encoding specifications for this type, for example, the
>>>>>>>>    IPFIX protocol specification.  Leap seconds are excluded.  Note that
>>>>>>>>    transformation of values might be required between different
>>>>>>>>    encodings if different epoch values are used.
>>>>>>>>
>>>>>>>> 3.1.17. dateTimeMicroseconds
>>>>>>>>
>>>>>>>>    The type "dateTimeMicroseconds" represents a time value in units of
>>>>>>>>    microseconds based on coordinated universal time (UTC).  The choice
>>>>>>>>    of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>>>>>>>    corresponding encoding specifications for this type, for example, the
>>>>>>>>    IPFIX protocol specification.  Leap seconds are excluded.  Note that
>>>>>>>>    transformation of values might be required between different
>>>>>>>>    encodings if different epoch values are used.
>>>>>>>>
>>>>>>>> 3.1.18. dateTimeNanoseconds
>>>>>>>>
>>>>>>>>    The type "dateTimeNanoseconds" represents a time value in units of
>>>>>>>>    nanoseconds based on coordinated universal time (UTC).  The choice of
>>>>>>>>    an epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>>>>>>>    corresponding encoding specifications for this type, for example, the
>>>>>>>>    IPFIX protocol specification.  Leap seconds are excluded.  Note that
>>>>>>>>    transformation of values might be required between different
>>>>>>>>    encodings if different epoch values are used.
>>>>>>>>
>>>>>>>>
>>>>>>>> Notes
>>>>>>>> -----
>>>>>>>> Although section 1.1 says : - "Definitions of timestamp data types have been clarified." The edited text has removed the epoch definition, and this does not seem to have been incorporated elsewhere in the RFC.
>>>>>>>>
>>>>>>>> Without a specified epoch, there is no unique definition of the timestamps.
>>>>>>>>
>>>>>>>> My proposal above is to revert to the RFC5102 definitions. RFC7102 is intended to be backwards compatible with RFC5102 and thus the definitions need to be technically identical. Alternatively, if the text is now included elsewhere in RFC7012 or in another RFC, it would be helpful to the reader to provide a reference to the epoch definition in an editorial update to dateTimeX definitions in RFC7102.
>>>>>>>>
>>>>>>>> Instructions:
>>>>>>>> -------------
>>>>>>>> This errata is currently posted as "Reported". If necessary, please
>>>>>>>> use "Reply All" to discuss whether it should be verified or
>>>>>>>> rejected. When a decision is reached, the verifying party (IESG)
>>>>>>>> can log in to change the status and edit the report, if necessary.
>>>>>>>>
>>>>>>>> --------------------------------------
>>>>>>>> RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10)
>>>>>>>> --------------------------------------
>>>>>>>> Title               : Information Model for IP Flow Information Export (IPFIX)
>>>>>>>> Publication Date    : September 2013
>>>>>>>> Author(s)           : B. Claise, Ed., B. Trammell, Ed.
>>>>>>>> Category            : PROPOSED STANDARD
>>>>>>>> Source              : IP Flow Information Export
>>>>>>>> Area                : Operations and Management
>>>>>>>> Stream              : IETF
>>>>>>>> Verifying Party     : IESG
>>>>>>>> _______________________________________________
>>>>>>>> IPFIX mailing list
>>>>>>>> IPFIX@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>>>> _______________________________________________
>>>>>>> IPFIX mailing list
>>>>>>> IPFIX@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>> _______________________________________________
>>>>> IPFIX mailing list
>>>>> IPFIX@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>
>>
>> -- 
>> For corporate legal information go to:
>>
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>
>


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html


--------------010507000001050103010401
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Brian

      

      We are getting there.

      

      On 03/01/2014 10:00, Brian Trammell wrote:

    

    

      
      hi Stewart,
      


      

      
inline as per tradition…

      


        

          
On 02 Jan 2014, at 12:54, Stewart Bryant <stbryant@cisco.com>
            wrote:

          

          

            
            

              
Brian

                

                Firstly going back to my original problem, I think that
                would be

                better addressed by

                

                OLD

                
                
Definitions of timestamp data types have been clarified.

NEW

Definitions of timestamp data types have been clarified and 
the definition of the epochs has been moved to sections
6.1.7 through 6.1.11 of RFC 7011

End

              

            

          

          
Okay, good point. this works for me.

          

            

              

                
Your new text is also helpful. 

Then there is the problem of the IANA registry pointing to
an obsolete RFC, which then takes you to RFC7012 which
does not define the IEs.

Consider IE 150, the reader is directed to RFC7012 by the
registry header, and finds the datatype is dateTimeSeconds
(which they dutifully look up in RFC7012 as indicated
in the registry) they find the definition of dateTimeSeconds
without the epoch and then what... For the definition
of the IE to be complete, the reader needs the epoch
which arguably now belongs in the registry, but is missing.
I think that the root cause is that when we made the 
registry the definitive definition of the IEs, we
did not add sufficient information in the case of the 
time definitions.


              

            

          

          
Okay, I understand your issue better here. We should
            consider a new erratum changing the introduction as well as
            para 2 section 3.1.

          

            

              

                
Now we have one other issue which I have been puzzling
over since you sent the email and can't quite get my
head around. You use the term "value" in the ADT
context. With for example i.e. 52 (min TTL) it's
easy to imagine what "value" means however you 
represent it. However I am struggling to understand
whether it is meaningful to define the "value" of IE 
150: "The absolute timestamp of the first packet of 
this Flow" is without some specific epoch. This
issue is addressed in I.E. 1 by specifying the count
relative to a previous instance of count, so I think
whilst that is a value, the timestamps are not.


              

            

          

          
But each timestamp value has an underlying real value, a
            moment in time. If you have a sequence of octets, you need
            both the ADT (7012) as well as the encoding (7011) to
            interpret it. 

          


          

          
Take, for example, “09:45:00 UTC on Friday 3 January 2014
            CE”. That string, interpreted by a human who makes a couple
            of basic assumptions (implicit selection of Gregorian over
            Julian calendar given the date, selection of a post-Julian
            solar calendar given the name of the month, presence in a
            negligibly accelerated reference frame with respect to
            Earth, a commonly agreed method of handling/ignoring leap
            seconds) unambiguously represents a single second in time.
            Which is what dateTimeSeconds is meant to do according to
            the 7012 definition. That second in time is the value.

          


          

          
The positive integer 1388742300 encoded as a big-endian
            unsigned32 is the IPFIX encoding of this value. This, as you
            say, requires an epoch, which is given in 7011. Without the
            epoch, you cannot interpret it at all.

          


          

          
The same value encoded as in
            draft-trammell-ipfix-text-adt would be “2014-01-03
            09:45:00”: less efficient that the IPFIX encoding, but more
            readable. There’s an implicit epoch here as well (“2014” in
            this context taken to be years since 1 BCE), but it’s a
            different epoch from that given in 7011; this is defined by
            reference, eventually, to ISO 8601.

          


          

          
So each instance of an IE of an ADT can take a value, and
            that value exists separate from its encoding. 7011 and 7012
            together combine to make an unambiguous mapping between the
            two possible in IPFIX.

        

      

    

    

    I think the key is the last sentence, and so long as we make that
    clear we are good.

    

    Maybe some text of the form "relative to the defined epoch" would
    sort it out. At least

    that would remind the reader that they needs to know rather than
    assume the epoch.

    

    - Stewart

    

    

      

        

          


          

          
Cheers,

          


          

          
Brian

          

          

            

              

                
We may need a call to work though this and another issue
I am about to raise on the IPFIX list.

- Stewart



                On 31/12/2013 12:44, Brian Trammell wrote:

              

              

                
hi Stewart,

Stewart Bryant (stbryant) wrote:


                

                  
Certainly something is needed. I was thinking of using IPFIX as an information gathering method in a radio context, and went to look at the definition of the types and could not find the epoch, or even a reference to the epoch. Now part of the problem (which was my fault) was that I did not notice at the time that the elements were defined by the obsolete RFC5102 and went straight to the new RFC. However having the definitions in an obsolete RFC also seems problematic, since it puts the IEs in a strange state. Since RFC 7012 replaces RFC5102 and includes the definitions you would expect the definition in RFC7012 to replace the definition in RFC5102, but those definitions are, as I explained incomplete.


                

                
This is intentional. See below.



                

                  
I need to look at this some more when I get back to work, but I am now also concerned that if the epoch can change, the definition of the existing IEs is now unreliable.


                

                
The definition of the existing IEs is based upon the definition of the
ADT itself in 7012 as well as the definition of the ADT representation
within the IPFIX protocol in 7011. It is not the intention that reading
7012 tells you how to encode IEs for use with IPFIX; that's what section
6.1 of 7011 is for.



                

                  
You will notice in the errata that I did suggest that an alternative resolution would be to include a reference to the epoch text.


                

                
The point is that the ADT _explicitly_ does not have a binding to an
epoch, as epochs are only necessary when using integral representations
of timestamps. IPFIX's representations for these ADTs are integral, but
bindings to other representations need not be (see, for example,
draft-trammell-ipfix-text-adt, which recommends ISO8601-style timestamps
for textual representations of IE values).

I'd suggest instead somehow expanding the present text in 7012 to
reiterate that if you're using IPFIX, the representations of the ADTs
are in 7011:

OLD para 2 sec 3.1 7012:

   The current encodings of these data types for use with the IPFIX
   protocol are defined in [RFC7011]; encodings allowing the use of the
   IPFIX Information Elements [IANA-IPFIX] with other protocols may be
   defined in the future by referencing this document.

NEW para 2 sec 3.1 7012:

   The abstract data type definitions in this section are intended
   only to define the values which can be taken by Information
   Elements of each type. The encodings of these data types for
   use with the IPFIX protocol are defined in Section 6.1 of
   [RFC7011]; encodings  allowing the use of the IPFIX Information
   Elements [IANA-IPFIX] with other protocols may be defined in the
   future by referencing this document.

Best regards,

Brian




                

                  
Stewart



Sent from my iPad



                  

                    
On 31 Dec 2013, at 08:50, "Brian Trammell" <trammell@tik.ee.ethz.ch> wrote:

hi Paul, all,

+n.

The separation between ADTs and ADT encoding between 7012 and 7011 was explicit and purposeful. Specifically, we do _not_ want to exclude other representations of the IPFIX Information Model from being based upon other encodings of these ADTs, whether ISO 8601 (which either has no epoch or epoch 0000-00-00 00:00 UTC, depending on how you count), NTP (1904), Julian day based counting, etc, etc, etc…

If there is confusion on this point, I’d suggest adding more explanatory text on this point to Paragraph 2 of the front matter to section 3.1. But as is, I emphatically recommend rejection of this reported erratum.

Best regards,

Brian



                    

                      
On 31 Dec 2013, at 03:58, Paul Aitken <paitken@cisco.com> wrote:

+1

If anyone was going to raise an errata on this, it would have been me ;-)

I've pointed this issue out before, probably more than once - and have been encouraged to read RFC 3444.

P.




                      

                        
On 30/12/2013 09:23, Andrew Feren wrote:
The encoding for the time data types is specified RFC 7011 Sections
6.1.7 through 6.1.10.

-Andrew



                        

                          
On 12/30/2013 10:13 AM, RFC Errata System wrote:
The following errata report has been submitted for RFC7012,
"Information Model for IP Flow Information Export (IPFIX)".

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

--------------------------------------
Type: Technical
Reported by: Stewart Bryant <stbryant@cisco.com>

Section: 3.1.15-17

Original Text
-------------
3.1.15. dateTimeSeconds

  The type "dateTimeSeconds" represents a time value expressed with
  second-level precision.

3.1.16. dateTimeMilliseconds

  The type "dateTimeMilliseconds" represents a time value expressed
  with millisecond-level precision.

3.1.17. dateTimeMicroseconds

  The type "dateTimeMicroseconds" represents a time value expressed
  with microsecond-level precision.

3.1.18. dateTimeNanoseconds

  The type "dateTimeNanoseconds" represents a time value expressed with
  nanosecond-level precision.


Corrected Text
--------------
3.1.15. dateTimeSeconds

  The type "dateTimeSeconds" represents a time value in units of
  seconds based on coordinated universal time (UTC).  The choice of an
  epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.16. dateTimeMilliseconds

  The type "dateTimeMilliseconds" represents a time value in units of
  milliseconds based on coordinated universal time (UTC).  The choice
  of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.17. dateTimeMicroseconds

  The type "dateTimeMicroseconds" represents a time value in units of
  microseconds based on coordinated universal time (UTC).  The choice
  of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.18. dateTimeNanoseconds

  The type "dateTimeNanoseconds" represents a time value in units of
  nanoseconds based on coordinated universal time (UTC).  The choice of
  an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.


Notes
-----
Although section 1.1 says : - "Definitions of timestamp data types have been clarified." The edited text has removed the epoch definition, and this does not seem to have been incorporated elsewhere in the RFC.

Without a specified epoch, there is no unique definition of the timestamps.

My proposal above is to revert to the RFC5102 definitions. RFC7102 is intended to be backwards compatible with RFC5102 and thus the definitions need to be technically identical. Alternatively, if the text is now included elsewhere in RFC7012 or in another RFC, it would be helpful to the reader to provide a reference to the epoch definition in an editorial update to dateTimeX definitions in RFC7102.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10)
--------------------------------------
Title               : Information Model for IP Flow Information Export (IPFIX)
Publication Date    : September 2013
Author(s)           : B. Claise, Ed., B. Trammell, Ed.
Category            : PROPOSED STANDARD
Source              : IP Flow Information Export
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


                        

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


                      

                    

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


                  

                

              

              

              

              
-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html



            

          

        

        

      

    

    

    

    
-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html



  


--------------010507000001050103010401--

From trammell@tik.ee.ethz.ch  Fri Jan  3 07:40:07 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A0A1ADEBF for ; Fri,  3 Jan 2014 07:40:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.737
X-Spam-Level: 
X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM-wAL_q4RKE for ; Fri,  3 Jan 2014 07:40:02 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD7A1ADEB7 for ; Fri,  3 Jan 2014 07:40:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 69FD7D9304; Fri,  3 Jan 2014 16:39:54 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jbgm38gEI-nS; Fri,  3 Jan 2014 16:39:54 +0100 (MET)
Received: from [10.0.27.113] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 2A433D9302; Fri,  3 Jan 2014 16:39:53 +0100 (MET)
Content-Type: multipart/signed; boundary="Apple-Mail=_EB3AB264-DDF9-483F-B3C0-1FED2C440F71"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Brian Trammell 
In-Reply-To: <52C6A8F9.7070706@cisco.com>
Date: Fri, 3 Jan 2014 16:39:49 +0100
Message-Id: 
References: <20131230151331.29E9F7FC393@rfc-editor.org> <52C19DF7.4050501@plixer.com> <52C232EB.30802@cisco.com>, <535E38C8-A1C0-4FD5-991C-D9A132D97923@tik.ee.ethz.ch> <0BEF0D66-E9DB-40E7-A2E4-ABCBCA5634CB@cisco.com> <52C2BC12.6090108@tik.ee.ethz.ch> <52C55358.5060402@cisco.com>  <52C6A8F9.7070706@cisco.com>
To: "stbryant@cisco.com Bryant" 
X-Mailer: Apple Mail (2.1827)
Cc: "joelja@bogus.com Jaeggli" , Nevil Brownlee , "ipfix@ietf.org Group" , RFC Errata System 
Subject: Re: [IPFIX] [Technical Errata Reported] RFC7012 (3852)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Jan 2014 15:40:07 -0000

--Apple-Mail=_EB3AB264-DDF9-483F-B3C0-1FED2C440F71
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_12CE84C0-4BC0-417F-909E-422F2719B250"


--Apple-Mail=_12CE84C0-4BC0-417F-909E-422F2719B250
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi Stewart,

On 03 Jan 2014, at 13:11, Stewart Bryant  wrote:

>>=20
>> So each instance of an IE of an ADT can take a value, and that value =
exists separate from its encoding. 7011 and 7012 together combine to =
make an unambiguous mapping between the two possible in IPFIX.
>=20
> I think the key is the last sentence, and so long as we make that =
clear we are good.
>=20
> Maybe some text of the form "relative to the defined epoch" would sort =
it out. At least
> that would remind the reader that they needs to know rather than =
assume the epoch.

This may seem like a tiny little nit to pick, but we thought a _whole =
lot_ about this when moving the epochs out of 5102bis, and I still think =
the reasons therefor are valid. I=92d ask you to reconsider insisting on =
timestamps as relative to a fixed epoch. I=92d rather state instead =
something like "it is the responsibility of the encoding to ensure that =
each representation has an unambiguous mapping to a moment in time (e.g. =
relative to a defined epoch)."

Otherwise we go down the calendar rathole very, very quickly, and we=92ve =
tried very hard not to do that. Indeed, one can define any time =
representation as relative to some epoch, more or less fuzzily. However, =
back to our ISO 8601 example, one can indeed interpret =932014-01-03 =
10:00:00 UTC=94 as a fixed number of years, months, days, hours, and so =
on from the implicit epoch 0001-01-01 00:00:00 UTC. One would be wrong, =
given variability in Julian-Gregorian calendar transitions, policies for =
accounting/ignoring leap seconds, and all those other assumptions one =
has to make when turning a human-readable timestamp (our =93ideal=94 =
value) to some notion of the moment in time it references.

I submit that these differences are largely irrelevant on the timescales =
and for the types of comparisons in event timing =97 whether network =
management related or not =97 that the IPFIX information model is likely =
to be applied to. But if we bake fixed-epoch references into the =
information model we=92re forced to care about them regardless.

Thanks, cheers,

Brian

>>> We may need a call to work though this and another issue
>>> I am about to raise on the IPFIX list.
>>>=20
>>> - Stewart
>>>=20
>>> On 31/12/2013 12:44, Brian Trammell wrote:
>>>> hi Stewart,
>>>>=20
>>>> Stewart Bryant (stbryant) wrote:
>>>>> Certainly something is needed. I was thinking of using IPFIX as an =
information gathering method in a radio context, and went to look at the =
definition of the types and could not find the epoch, or even a =
reference to the epoch. Now part of the problem (which was my fault) was =
that I did not notice at the time that the elements were defined by the =
obsolete RFC5102 and went straight to the new RFC. However having the =
definitions in an obsolete RFC also seems problematic, since it puts the =
IEs in a strange state. Since RFC 7012 replaces RFC5102 and includes the =
definitions you would expect the definition in RFC7012 to replace the =
definition in RFC5102, but those definitions are, as I explained =
incomplete.
>>>> This is intentional. See below.
>>>>=20
>>>>> I need to look at this some more when I get back to work, but I am =
now also concerned that if the epoch can change, the definition of the =
existing IEs is now unreliable.
>>>> The definition of the existing IEs is based upon the definition of =
the
>>>> ADT itself in 7012 as well as the definition of the ADT =
representation
>>>> within the IPFIX protocol in 7011. It is not the intention that =
reading
>>>> 7012 tells you how to encode IEs for use with IPFIX; that's what =
section
>>>> 6.1 of 7011 is for.
>>>>=20
>>>>> You will notice in the errata that I did suggest that an =
alternative resolution would be to include a reference to the epoch =
text.
>>>> The point is that the ADT _explicitly_ does not have a binding to =
an
>>>> epoch, as epochs are only necessary when using integral =
representations
>>>> of timestamps. IPFIX's representations for these ADTs are integral, =
but
>>>> bindings to other representations need not be (see, for example,
>>>> draft-trammell-ipfix-text-adt, which recommends ISO8601-style =
timestamps
>>>> for textual representations of IE values).
>>>>=20
>>>> I'd suggest instead somehow expanding the present text in 7012 to
>>>> reiterate that if you're using IPFIX, the representations of the =
ADTs
>>>> are in 7011:
>>>>=20
>>>> OLD para 2 sec 3.1 7012:
>>>>=20
>>>>    The current encodings of these data types for use with the IPFIX
>>>>    protocol are defined in [RFC7011]; encodings allowing the use of =
the
>>>>    IPFIX Information Elements [IANA-IPFIX] with other protocols may =
be
>>>>    defined in the future by referencing this document.
>>>>=20
>>>> NEW para 2 sec 3.1 7012:
>>>>=20
>>>>    The abstract data type definitions in this section are intended
>>>>    only to define the values which can be taken by Information
>>>>    Elements of each type. The encodings of these data types for
>>>>    use with the IPFIX protocol are defined in Section 6.1 of
>>>>    [RFC7011]; encodings  allowing the use of the IPFIX Information
>>>>    Elements [IANA-IPFIX] with other protocols may be defined in the
>>>>    future by referencing this document.
>>>>=20
>>>> Best regards,
>>>>=20
>>>> Brian
>>>>=20
>>>>=20
>>>>> Stewart
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Sent from my iPad
>>>>>=20
>>>>>> On 31 Dec 2013, at 08:50, "Brian Trammell" =
 wrote:
>>>>>>=20
>>>>>> hi Paul, all,
>>>>>>=20
>>>>>> +n.
>>>>>>=20
>>>>>> The separation between ADTs and ADT encoding between 7012 and =
7011 was explicit and purposeful. Specifically, we do _not_ want to =
exclude other representations of the IPFIX Information Model from being =
based upon other encodings of these ADTs, whether ISO 8601 (which either =
has no epoch or epoch 0000-00-00 00:00 UTC, depending on how you count), =
NTP (1904), Julian day based counting, etc, etc, etc=85
>>>>>>=20
>>>>>> If there is confusion on this point, I=92d suggest adding more =
explanatory text on this point to Paragraph 2 of the front matter to =
section 3.1. But as is, I emphatically recommend rejection of this =
reported erratum.
>>>>>>=20
>>>>>> Best regards,
>>>>>>=20
>>>>>> Brian
>>>>>>=20
>>>>>>> On 31 Dec 2013, at 03:58, Paul Aitken  wrote:
>>>>>>>=20
>>>>>>> +1
>>>>>>>=20
>>>>>>> If anyone was going to raise an errata on this, it would have =
been me ;-)
>>>>>>>=20
>>>>>>> I've pointed this issue out before, probably more than once - =
and have been encouraged to read RFC 3444.
>>>>>>>=20
>>>>>>> P.
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On 30/12/2013 09:23, Andrew Feren wrote:
>>>>>>>> The encoding for the time data types is specified RFC 7011 =
Sections
>>>>>>>> 6.1.7 through 6.1.10.
>>>>>>>>=20
>>>>>>>> -Andrew
>>>>>>>>=20
>>>>>>>>> On 12/30/2013 10:13 AM, RFC Errata System wrote:
>>>>>>>>> The following errata report has been submitted for RFC7012,
>>>>>>>>> "Information Model for IP Flow Information Export (IPFIX)".
>>>>>>>>>=20
>>>>>>>>> --------------------------------------
>>>>>>>>> You may review the report below and at:
>>>>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D7012&eid=3D385=
2
>>>>>>>>>=20
>>>>>>>>> --------------------------------------
>>>>>>>>> Type: Technical
>>>>>>>>> Reported by: Stewart Bryant 
>>>>>>>>>=20
>>>>>>>>> Section: 3.1.15-17
>>>>>>>>>=20
>>>>>>>>> Original Text
>>>>>>>>> -------------
>>>>>>>>> 3.1.15. dateTimeSeconds
>>>>>>>>>=20
>>>>>>>>>   The type "dateTimeSeconds" represents a time value expressed =
with
>>>>>>>>>   second-level precision.
>>>>>>>>>=20
>>>>>>>>> 3.1.16. dateTimeMilliseconds
>>>>>>>>>=20
>>>>>>>>>   The type "dateTimeMilliseconds" represents a time value =
expressed
>>>>>>>>>   with millisecond-level precision.
>>>>>>>>>=20
>>>>>>>>> 3.1.17. dateTimeMicroseconds
>>>>>>>>>=20
>>>>>>>>>   The type "dateTimeMicroseconds" represents a time value =
expressed
>>>>>>>>>   with microsecond-level precision.
>>>>>>>>>=20
>>>>>>>>> 3.1.18. dateTimeNanoseconds
>>>>>>>>>=20
>>>>>>>>>   The type "dateTimeNanoseconds" represents a time value =
expressed with
>>>>>>>>>   nanosecond-level precision.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Corrected Text
>>>>>>>>> --------------
>>>>>>>>> 3.1.15. dateTimeSeconds
>>>>>>>>>=20
>>>>>>>>>   The type "dateTimeSeconds" represents a time value in units =
of
>>>>>>>>>   seconds based on coordinated universal time (UTC).  The =
choice of an
>>>>>>>>>   epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>>>>>>>>   corresponding encoding specifications for this type, for =
example, the
>>>>>>>>>   IPFIX protocol specification.  Leap seconds are excluded.  =
Note that
>>>>>>>>>   transformation of values might be required between different
>>>>>>>>>   encodings if different epoch values are used.
>>>>>>>>>=20
>>>>>>>>> 3.1.16. dateTimeMilliseconds
>>>>>>>>>=20
>>>>>>>>>   The type "dateTimeMilliseconds" represents a time value in =
units of
>>>>>>>>>   milliseconds based on coordinated universal time (UTC).  The =
choice
>>>>>>>>>   of an epoch, for example, 00:00 UTC, January 1, 1970, is =
left to
>>>>>>>>>   corresponding encoding specifications for this type, for =
example, the
>>>>>>>>>   IPFIX protocol specification.  Leap seconds are excluded.  =
Note that
>>>>>>>>>   transformation of values might be required between different
>>>>>>>>>   encodings if different epoch values are used.
>>>>>>>>>=20
>>>>>>>>> 3.1.17. dateTimeMicroseconds
>>>>>>>>>=20
>>>>>>>>>   The type "dateTimeMicroseconds" represents a time value in =
units of
>>>>>>>>>   microseconds based on coordinated universal time (UTC).  The =
choice
>>>>>>>>>   of an epoch, for example, 00:00 UTC, January 1, 1970, is =
left to
>>>>>>>>>   corresponding encoding specifications for this type, for =
example, the
>>>>>>>>>   IPFIX protocol specification.  Leap seconds are excluded.  =
Note that
>>>>>>>>>   transformation of values might be required between different
>>>>>>>>>   encodings if different epoch values are used.
>>>>>>>>>=20
>>>>>>>>> 3.1.18. dateTimeNanoseconds
>>>>>>>>>=20
>>>>>>>>>   The type "dateTimeNanoseconds" represents a time value in =
units of
>>>>>>>>>   nanoseconds based on coordinated universal time (UTC).  The =
choice of
>>>>>>>>>   an epoch, for example, 00:00 UTC, January 1, 1970, is left =
to
>>>>>>>>>   corresponding encoding specifications for this type, for =
example, the
>>>>>>>>>   IPFIX protocol specification.  Leap seconds are excluded.  =
Note that
>>>>>>>>>   transformation of values might be required between different
>>>>>>>>>   encodings if different epoch values are used.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Notes
>>>>>>>>> -----
>>>>>>>>> Although section 1.1 says : - "Definitions of timestamp data =
types have been clarified." The edited text has removed the epoch =
definition, and this does not seem to have been incorporated elsewhere =
in the RFC.
>>>>>>>>>=20
>>>>>>>>> Without a specified epoch, there is no unique definition of =
the timestamps.
>>>>>>>>>=20
>>>>>>>>> My proposal above is to revert to the RFC5102 definitions. =
RFC7102 is intended to be backwards compatible with RFC5102 and thus the =
definitions need to be technically identical. Alternatively, if the text =
is now included elsewhere in RFC7012 or in another RFC, it would be =
helpful to the reader to provide a reference to the epoch definition in =
an editorial update to dateTimeX definitions in RFC7102.
>>>>>>>>>=20
>>>>>>>>> Instructions:
>>>>>>>>> -------------
>>>>>>>>> This errata is currently posted as "Reported". If necessary, =
please
>>>>>>>>> use "Reply All" to discuss whether it should be verified or
>>>>>>>>> rejected. When a decision is reached, the verifying party =
(IESG)
>>>>>>>>> can log in to change the status and edit the report, if =
necessary.
>>>>>>>>>=20
>>>>>>>>> --------------------------------------
>>>>>>>>> RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10)
>>>>>>>>> --------------------------------------
>>>>>>>>> Title               : Information Model for IP Flow =
Information Export (IPFIX)
>>>>>>>>> Publication Date    : September 2013
>>>>>>>>> Author(s)           : B. Claise, Ed., B. Trammell, Ed.
>>>>>>>>> Category            : PROPOSED STANDARD
>>>>>>>>> Source              : IP Flow Information Export
>>>>>>>>> Area                : Operations and Management
>>>>>>>>> Stream              : IETF
>>>>>>>>> Verifying Party     : IESG
>>>>>>>>> _______________________________________________
>>>>>>>>> IPFIX mailing list
>>>>>>>>> IPFIX@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>> _______________________________________________
>>>>>>>> IPFIX mailing list
>>>>>>>> IPFIX@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>>> _______________________________________________
>>>>>> IPFIX mailing list
>>>>>> IPFIX@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>=20
>>>=20
>>> --=20
>>> For corporate legal information go to:
>>>=20
>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>>=20
>>=20
>=20
>=20
> --=20
> For corporate legal information go to:
>=20
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>=20


--Apple-Mail=_12CE84C0-4BC0-417F-909E-422F2719B250
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Hi =
Stewart,

On 03 Jan 2014, at 13:11, Stewart =
Bryant <stbryant@cisco.com> =
wrote:


 =20
    
 =20
  

    

          


          

          
So each instance of an IE of an ADT can take a value, and
            that value exists separate from its encoding. 7011 and 7012
            together combine to make an unambiguous mapping between the
            two possible in IPFIX.

        

      

    

    

    I think the key is the last sentence, and so long as we make that
    clear we are good.

    

    Maybe some text of the form "relative to the defined epoch" would
    sort it out. At least

    that would remind the reader that they needs to know rather than
    assume the epoch.

This may =
seem like a tiny little nit to pick, but we thought a _whole lot_ about =
this when moving the epochs out of 5102bis, and I still think the =
reasons therefor are valid. I=92d ask you to reconsider insisting on =
timestamps as relative to a fixed epoch. I=92d rather state instead =
something like "it is the responsibility of the encoding to ensure that =
each representation has an unambiguous mapping to a moment in time (e.g. =
relative to a defined epoch)."

Otherwise we go =
down the calendar rathole very, very quickly, and we=92ve tried very =
hard not to do that. Indeed, one can define any time representation as =
relative to some epoch, more or less fuzzily. However, back to our ISO =
8601 example, one can indeed interpret =932014-01-03 10:00:00 UTC=94 as =
a fixed number of years, months, days, hours, and so on from the =
implicit epoch 0001-01-01 00:00:00 UTC. One would be wrong, given =
variability in Julian-Gregorian calendar transitions, policies for =
accounting/ignoring leap seconds, and all those other assumptions one =
has to make when turning a human-readable timestamp (our =93ideal=94 =
value) to some notion of the moment in time it =
references.

I submit that these differences are =
largely irrelevant on the timescales and for the types of comparisons in =
event timing =97 whether network management related or not =97 that the =
IPFIX information model is likely to be applied to. But if we bake =
fixed-epoch references into the information model we=92re forced to care =
about them regardless.

Thanks, =
cheers,

Brian

We=
 may need a call to work though this and another issue
I am about to raise on the IPFIX list.

- Stewart



                On 31/12/2013 12:44, Brian Trammell wrote:

              

              

                
hi Stewart,

Stewart Bryant (stbryant) wrote:


                

                  
Certainly something is needed. I was =
thinking of using IPFIX as an information gathering method in a radio =
context, and went to look at the definition of the types and could not =
find the epoch, or even a reference to the epoch. Now part of the =
problem (which was my fault) was that I did not notice at the time that =
the elements were defined by the obsolete RFC5102 and went straight to =
the new RFC. However having the definitions in an obsolete RFC also =
seems problematic, since it puts the IEs in a strange state. Since RFC =
7012 replaces RFC5102 and includes the definitions you would expect the =
definition in RFC7012 to replace the definition in RFC5102, but those =
definitions are, as I explained incomplete.


                

                
This is intentional. See below.



                

                  
I need to look at this some more when I =
get back to work, but I am now also concerned that if the epoch can =
change, the definition of the existing IEs is now unreliable.


                

                
The definition of the existing IEs is =
based upon the definition of the
ADT itself in 7012 as well as the definition of the ADT representation
within the IPFIX protocol in 7011. It is not the intention that reading
7012 tells you how to encode IEs for use with IPFIX; that's what section
6.1 of 7011 is for.



                

                  
You will notice in the errata that I =
did suggest that an alternative resolution would be to include a =
reference to the epoch text.


                

                
The point is that the ADT _explicitly_ =
does not have a binding to an
epoch, as epochs are only necessary when using integral representations
of timestamps. IPFIX's representations for these ADTs are integral, but
bindings to other representations need not be (see, for example,
draft-trammell-ipfix-text-adt, which recommends ISO8601-style timestamps
for textual representations of IE values).

I'd suggest instead somehow expanding the present text in 7012 to
reiterate that if you're using IPFIX, the representations of the ADTs
are in 7011:

OLD para 2 sec 3.1 7012:

   The current encodings of these data types for use with the IPFIX
   protocol are defined in [RFC7011]; encodings allowing the use of the
   IPFIX Information Elements [IANA-IPFIX] with other protocols may be
   defined in the future by referencing this document.

NEW para 2 sec 3.1 7012:

   The abstract data type definitions in this section are intended
   only to define the values which can be taken by Information
   Elements of each type. The encodings of these data types for
   use with the IPFIX protocol are defined in Section 6.1 of
   [RFC7011]; encodings  allowing the use of the IPFIX Information
   Elements [IANA-IPFIX] with other protocols may be defined in the
   future by referencing this document.

Best regards,

Brian




                

                  
Stewart



Sent from my iPad



                  

                    
On 31 Dec 2013, at 08:50, "Brian =
Trammell" <trammell@tik.ee.ethz.ch> wrote:

hi Paul, all,

+n.

The separation between ADTs and ADT encoding between 7012 and 7011 was =
explicit and purposeful. Specifically, we do _not_ want to exclude other =
representations of the IPFIX Information Model from being based upon =
other encodings of these ADTs, whether ISO 8601 (which either has no =
epoch or epoch 0000-00-00 00:00 UTC, depending on how you count), NTP =
(1904), Julian day based counting, etc, etc, etc=85

If there is confusion on this point, I=92d suggest adding more =
explanatory text on this point to Paragraph 2 of the front matter to =
section 3.1. But as is, I emphatically recommend rejection of this =
reported erratum.

Best regards,

Brian



                    

                      
On 31 Dec 2013, at 03:58, Paul =
Aitken <paitken@cisco.com> wrote:

+1

If anyone was going to raise an errata on this, it would have been me =
;-)

I've pointed this issue out before, probably more than once - and have =
been encouraged to read RFC 3444.

P.




                      

                        
On 30/12/2013 09:23, Andrew Feren =
wrote:
The encoding for the time data types is specified RFC 7011 Sections
6.1.7 through 6.1.10.

-Andrew



                        

                          
On 12/30/2013 10:13 AM, RFC =
Errata System wrote:
The following errata report has been submitted for RFC7012,
"Information Model for IP Flow Information Export (IPFIX)".

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


--------------------------------------
Type: Technical
Reported by: Stewart Bryant <stbryant@cisco.com>

Section: 3.1.15-17

Original Text
-------------
3.1.15. dateTimeSeconds

  The type "dateTimeSeconds" represents a time value expressed with
  second-level precision.

3.1.16. dateTimeMilliseconds

  The type "dateTimeMilliseconds" represents a time value expressed
  with millisecond-level precision.

3.1.17. dateTimeMicroseconds

  The type "dateTimeMicroseconds" represents a time value expressed
  with microsecond-level precision.

3.1.18. dateTimeNanoseconds

  The type "dateTimeNanoseconds" represents a time value expressed with
  nanosecond-level precision.


Corrected Text
--------------
3.1.15. dateTimeSeconds

  The type "dateTimeSeconds" represents a time value in units of
  seconds based on coordinated universal time (UTC).  The choice of an
  epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.16. dateTimeMilliseconds

  The type "dateTimeMilliseconds" represents a time value in units of
  milliseconds based on coordinated universal time (UTC).  The choice
  of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.17. dateTimeMicroseconds

  The type "dateTimeMicroseconds" represents a time value in units of
  microseconds based on coordinated universal time (UTC).  The choice
  of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.18. dateTimeNanoseconds

  The type "dateTimeNanoseconds" represents a time value in units of
  nanoseconds based on coordinated universal time (UTC).  The choice of
  an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.


Notes
-----
Although section 1.1 says : - "Definitions of timestamp data types have =
been clarified." The edited text has removed the epoch definition, and =
this does not seem to have been incorporated elsewhere in the RFC.

Without a specified epoch, there is no unique definition of the =
timestamps.

My proposal above is to revert to the RFC5102 definitions. RFC7102 is =
intended to be backwards compatible with RFC5102 and thus the =
definitions need to be technically identical. Alternatively, if the text =
is now included elsewhere in RFC7012 or in another RFC, it would be =
helpful to the reader to provide a reference to the epoch definition in =
an editorial update to dateTimeX definitions in RFC7102.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10)
--------------------------------------
Title               : Information Model for IP Flow Information Export =
(IPFIX)
Publication Date    : September 2013
Author(s)           : B. Claise, Ed., B. Trammell, Ed.
Category            : PROPOSED STANDARD
Source              : IP Flow Information Export
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/=
mailman/listinfo/ipfix


                        

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


                      

                    

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


                  

                

              

              

              

              
--=20
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html



            

          

        

        

      

    

    

    

    
--=20
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html



  




=

--Apple-Mail=_12CE84C0-4BC0-417F-909E-422F2719B250--

--Apple-Mail=_EB3AB264-DDF9-483F-B3C0-1FED2C440F71
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSxtnGAAoJENt3nsOmbNJcOm8H/1RChkV2QjPU3b1s7W/SER8G
yrA7SAj1g4w2ybq5A10ULntaW1Dq+BVVwYc3RwC04cYBTig8SXKc3iraiKUrhxie
KaEzfDj+L2PTDXQQ0sxtfZLGcp7JY2knybSnNQcQFGCyBouMYVqghuhAd+MjnVZD
v725gT+EI/JUeZ0kwwcLf+krmPw3Kn4mV44v2+Pz6UgUcBrmotTm/jesfBiQgJBg
eTNl/rwzomcVhaJcQlrlFRBqRKsXV2Bf30bBcfNPB6w9QG+SggnVQRln0uFWit7S
+AFzUt3XofXJd7tdIejz/iP+Fh3hjPphSWpbEg8VdgDvfBNKY7m0LIRL2WnrfPw=
=Ie4X
-----END PGP SIGNATURE-----

--Apple-Mail=_EB3AB264-DDF9-483F-B3C0-1FED2C440F71--

From stbryant@cisco.com  Fri Jan  3 08:21:46 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85751ADFE1 for ; Fri,  3 Jan 2014 08:21:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.038
X-Spam-Level: 
X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6nOH33pM1oQ for ; Fri,  3 Jan 2014 08:21:41 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 070551ADFE3 for ; Fri,  3 Jan 2014 08:21:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33154; q=dns/txt; s=iport; t=1388766093; x=1389975693; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=8K+beUUWP6HOkJNWaIyOsKlixBjEx7SJ60i/z9qvKkk=; b=AMkbIDSLgxVkbKW/gVTwBw93iGAyThG1saq1nqmmKpomRaEjUODq4rlD CLp+OH5budvKAxRJo+nrAjMhc1/UkZY95/xCGMQ+lKop6P9yAwDTyJzs7 YZWg6o4/eV4dtL+diE8Af5kKkLBRPguTewinDKpp3v91CzxoSgUTMIFoS g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAEDjxlKQ/khL/2dsb2JhbAA+GoMLOLlfgQ0WdIIlAQEBAwEBAQEXVAoBEAsYCRYBBwcJAwIBAgEVHxEGDQEFAgEBh3gIDTbCZRePDgeENwSYF5IUgy15
X-IronPort-AV: E=Sophos;i="4.95,598,1384300800"; d="scan'208,217";a="3149167"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 03 Jan 2014 16:21:31 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s03GLUhI016546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jan 2014 16:21:31 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s03GLATg025307; Fri, 3 Jan 2014 16:21:10 GMT
Message-ID: <52C6E376.2060304@cisco.com>
Date: Fri, 03 Jan 2014 16:21:10 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Brian Trammell 
References: <20131230151331.29E9F7FC393@rfc-editor.org> <52C19DF7.4050501@plixer.com> <52C232EB.30802@cisco.com>, <535E38C8-A1C0-4FD5-991C-D9A132D97923@tik.ee.ethz.ch> <0BEF0D66-E9DB-40E7-A2E4-ABCBCA5634CB@cisco.com> <52C2BC12.6090108@tik.ee.ethz.ch> <52C55358.5060402@cisco.com>  <52C6A8F9.7070706@cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050302040600050000050307"
Cc: "joelja@bogus.com Jaeggli" , Nevil Brownlee , "ipfix@ietf.org Group" , RFC Errata System 
Subject: Re: [IPFIX] [Technical Errata Reported] RFC7012 (3852)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Jan 2014 16:21:46 -0000

This is a multi-part message in MIME format.
--------------050302040600050000050307
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

On 03/01/2014 15:39, Brian Trammell wrote:
> Hi Stewart,
>
> On 03 Jan 2014, at 13:11, Stewart Bryant  > wrote:
>
>>>
>>> So each instance of an IE of an ADT can take a value, and that value 
>>> exists separate from its encoding. 7011 and 7012 together combine to 
>>> make an unambiguous mapping between the two possible in IPFIX.
>>
>> I think the key is the last sentence, and so long as we make that 
>> clear we are good.
>>
>> Maybe some text of the form "relative to the defined epoch" would 
>> sort it out. At least
>> that would remind the reader that they needs to know rather than 
>> assume the epoch.
>
> This may seem like a tiny little nit to pick, but we thought a _whole 
> lot_ about this when moving the epochs out of 5102bis, and I still 
> think the reasons therefor are valid. I’d ask you to reconsider 
> insisting on timestamps as relative to a fixed epoch. I’d rather state 
> instead something like "it is the responsibility of the encoding to 
> ensure that each representation has an unambiguous mapping to a moment 
> in time (e.g. relative to a defined epoch)."

If you are proposing that text, that would work for me.
>
> Otherwise we go down the calendar rathole very, very quickly, and 
> we’ve tried very hard not to do that. Indeed, one can define any time 
> representation as relative to some epoch, more or less fuzzily. 
> However, back to our ISO 8601 example, one can indeed interpret 
> “2014-01-03 10:00:00 UTC” as a fixed number of years, months, days, 
> hours, and so on from the implicit epoch 0001-01-01 00:00:00 UTC. One 
> would be wrong, given variability in Julian-Gregorian calendar 
> transitions, policies for accounting/ignoring leap seconds, and all 
> those other assumptions one has to make when turning a human-readable 
> timestamp (our “ideal” value) to some notion of the moment in time it 
> references.
>
> I submit that these differences are largely irrelevant on the 
> timescales and for the types of comparisons in event timing — whether 
> network management related or not — that the IPFIX information model 
> is likely to be applied to. But if we bake fixed-epoch references into 
> the information model we’re forced to care about them regardless.
No, I am fine with the IM not baking in the epoch, now I understand the 
approach, and the with the other changes that tell the reader that they 
moved. However, I think you do need to help the reader understand the 
importance of understanding the of the epoch (and now you remind me the 
discontinuities). The above sentence will do this.

Stewart

>
> Thanks, cheers,
>
> Brian
>
>>>> We may need a call to work though this and another issue
>>>> I am about to raise on the IPFIX list.
>>>>
>>>> - Stewart
>>>>
>>>> On 31/12/2013 12:44, Brian Trammell wrote:
>>>>> hi Stewart,
>>>>>
>>>>> Stewart Bryant (stbryant) wrote:
>>>>>> Certainly something is needed. I was thinking of using IPFIX as an information gathering method in a radio context, and went to look at the definition of the types and could not find the epoch, or even a reference to the epoch. Now part of the problem (which was my fault) was that I did not notice at the time that the elements were defined by the obsolete RFC5102 and went straight to the new RFC. However having the definitions in an obsolete RFC also seems problematic, since it puts the IEs in a strange state. Since RFC 7012 replaces RFC5102 and includes the definitions you would expect the definition in RFC7012 to replace the definition in RFC5102, but those definitions are, as I explained incomplete.
>>>>> This is intentional. See below.
>>>>>
>>>>>> I need to look at this some more when I get back to work, but I am now also concerned that if the epoch can change, the definition of the existing IEs is now unreliable.
>>>>> The definition of the existing IEs is based upon the definition of the
>>>>> ADT itself in 7012 as well as the definition of the ADT representation
>>>>> within the IPFIX protocol in 7011. It is not the intention that reading
>>>>> 7012 tells you how to encode IEs for use with IPFIX; that's what section
>>>>> 6.1 of 7011 is for.
>>>>>
>>>>>> You will notice in the errata that I did suggest that an alternative resolution would be to include a reference to the epoch text.
>>>>> The point is that the ADT _explicitly_ does not have a binding to an
>>>>> epoch, as epochs are only necessary when using integral representations
>>>>> of timestamps. IPFIX's representations for these ADTs are integral, but
>>>>> bindings to other representations need not be (see, for example,
>>>>> draft-trammell-ipfix-text-adt, which recommends ISO8601-style timestamps
>>>>> for textual representations of IE values).
>>>>>
>>>>> I'd suggest instead somehow expanding the present text in 7012 to
>>>>> reiterate that if you're using IPFIX, the representations of the ADTs
>>>>> are in 7011:
>>>>>
>>>>> OLD para 2 sec 3.1 7012:
>>>>>
>>>>>     The current encodings of these data types for use with the IPFIX
>>>>>     protocol are defined in [RFC7011]; encodings allowing the use of the
>>>>>     IPFIX Information Elements [IANA-IPFIX] with other protocols may be
>>>>>     defined in the future by referencing this document.
>>>>>
>>>>> NEW para 2 sec 3.1 7012:
>>>>>
>>>>>     The abstract data type definitions in this section are intended
>>>>>     only to define the values which can be taken by Information
>>>>>     Elements of each type. The encodings of these data types for
>>>>>     use with the IPFIX protocol are defined in Section 6.1 of
>>>>>     [RFC7011]; encodings  allowing the use of the IPFIX Information
>>>>>     Elements [IANA-IPFIX] with other protocols may be defined in the
>>>>>     future by referencing this document.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Brian
>>>>>
>>>>>
>>>>>> Stewart
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sent from my iPad
>>>>>>
>>>>>>> On 31 Dec 2013, at 08:50, "Brian Trammell"  wrote:
>>>>>>>
>>>>>>> hi Paul, all,
>>>>>>>
>>>>>>> +n.
>>>>>>>
>>>>>>> The separation between ADTs and ADT encoding between 7012 and 7011 was explicit and purposeful. Specifically, we do _not_ want to exclude other representations of the IPFIX Information Model from being based upon other encodings of these ADTs, whether ISO 8601 (which either has no epoch or epoch 0000-00-00 00:00 UTC, depending on how you count), NTP (1904), Julian day based counting, etc, etc, etc…
>>>>>>>
>>>>>>> If there is confusion on this point, I’d suggest adding more explanatory text on this point to Paragraph 2 of the front matter to section 3.1. But as is, I emphatically recommend rejection of this reported erratum.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Brian
>>>>>>>
>>>>>>>> On 31 Dec 2013, at 03:58, Paul Aitken  wrote:
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> If anyone was going to raise an errata on this, it would have been me ;-)
>>>>>>>>
>>>>>>>> I've pointed this issue out before, probably more than once - and have been encouraged to read RFC 3444.
>>>>>>>>
>>>>>>>> P.
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 30/12/2013 09:23, Andrew Feren wrote:
>>>>>>>>> The encoding for the time data types is specified RFC 7011 Sections
>>>>>>>>> 6.1.7 through 6.1.10.
>>>>>>>>>
>>>>>>>>> -Andrew
>>>>>>>>>
>>>>>>>>>> On 12/30/2013 10:13 AM, RFC Errata System wrote:
>>>>>>>>>> The following errata report has been submitted for RFC7012,
>>>>>>>>>> "Information Model for IP Flow Information Export (IPFIX)".
>>>>>>>>>>
>>>>>>>>>> --------------------------------------
>>>>>>>>>> You may review the report below and at:
>>>>>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=7012&eid=3852
>>>>>>>>>>
>>>>>>>>>> --------------------------------------
>>>>>>>>>> Type: Technical
>>>>>>>>>> Reported by: Stewart Bryant
>>>>>>>>>>
>>>>>>>>>> Section: 3.1.15-17
>>>>>>>>>>
>>>>>>>>>> Original Text
>>>>>>>>>> -------------
>>>>>>>>>> 3.1.15. dateTimeSeconds
>>>>>>>>>>
>>>>>>>>>>    The type "dateTimeSeconds" represents a time value expressed with
>>>>>>>>>>    second-level precision.
>>>>>>>>>>
>>>>>>>>>> 3.1.16. dateTimeMilliseconds
>>>>>>>>>>
>>>>>>>>>>    The type "dateTimeMilliseconds" represents a time value expressed
>>>>>>>>>>    with millisecond-level precision.
>>>>>>>>>>
>>>>>>>>>> 3.1.17. dateTimeMicroseconds
>>>>>>>>>>
>>>>>>>>>>    The type "dateTimeMicroseconds" represents a time value expressed
>>>>>>>>>>    with microsecond-level precision.
>>>>>>>>>>
>>>>>>>>>> 3.1.18. dateTimeNanoseconds
>>>>>>>>>>
>>>>>>>>>>    The type "dateTimeNanoseconds" represents a time value expressed with
>>>>>>>>>>    nanosecond-level precision.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Corrected Text
>>>>>>>>>> --------------
>>>>>>>>>> 3.1.15. dateTimeSeconds
>>>>>>>>>>
>>>>>>>>>>    The type "dateTimeSeconds" represents a time value in units of
>>>>>>>>>>    seconds based on coordinated universal time (UTC).  The choice of an
>>>>>>>>>>    epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>>>>>>>>>    corresponding encoding specifications for this type, for example, the
>>>>>>>>>>    IPFIX protocol specification.  Leap seconds are excluded.  Note that
>>>>>>>>>>    transformation of values might be required between different
>>>>>>>>>>    encodings if different epoch values are used.
>>>>>>>>>>
>>>>>>>>>> 3.1.16. dateTimeMilliseconds
>>>>>>>>>>
>>>>>>>>>>    The type "dateTimeMilliseconds" represents a time value in units of
>>>>>>>>>>    milliseconds based on coordinated universal time (UTC).  The choice
>>>>>>>>>>    of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>>>>>>>>>    corresponding encoding specifications for this type, for example, the
>>>>>>>>>>    IPFIX protocol specification.  Leap seconds are excluded.  Note that
>>>>>>>>>>    transformation of values might be required between different
>>>>>>>>>>    encodings if different epoch values are used.
>>>>>>>>>>
>>>>>>>>>> 3.1.17. dateTimeMicroseconds
>>>>>>>>>>
>>>>>>>>>>    The type "dateTimeMicroseconds" represents a time value in units of
>>>>>>>>>>    microseconds based on coordinated universal time (UTC).  The choice
>>>>>>>>>>    of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>>>>>>>>>    corresponding encoding specifications for this type, for example, the
>>>>>>>>>>    IPFIX protocol specification.  Leap seconds are excluded.  Note that
>>>>>>>>>>    transformation of values might be required between different
>>>>>>>>>>    encodings if different epoch values are used.
>>>>>>>>>>
>>>>>>>>>> 3.1.18. dateTimeNanoseconds
>>>>>>>>>>
>>>>>>>>>>    The type "dateTimeNanoseconds" represents a time value in units of
>>>>>>>>>>    nanoseconds based on coordinated universal time (UTC).  The choice of
>>>>>>>>>>    an epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>>>>>>>>>    corresponding encoding specifications for this type, for example, the
>>>>>>>>>>    IPFIX protocol specification.  Leap seconds are excluded.  Note that
>>>>>>>>>>    transformation of values might be required between different
>>>>>>>>>>    encodings if different epoch values are used.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Notes
>>>>>>>>>> -----
>>>>>>>>>> Although section 1.1 says : - "Definitions of timestamp data types have been clarified." The edited text has removed the epoch definition, and this does not seem to have been incorporated elsewhere in the RFC.
>>>>>>>>>>
>>>>>>>>>> Without a specified epoch, there is no unique definition of the timestamps.
>>>>>>>>>>
>>>>>>>>>> My proposal above is to revert to the RFC5102 definitions. RFC7102 is intended to be backwards compatible with RFC5102 and thus the definitions need to be technically identical. Alternatively, if the text is now included elsewhere in RFC7012 or in another RFC, it would be helpful to the reader to provide a reference to the epoch definition in an editorial update to dateTimeX definitions in RFC7102.
>>>>>>>>>>
>>>>>>>>>> Instructions:
>>>>>>>>>> -------------
>>>>>>>>>> This errata is currently posted as "Reported". If necessary, please
>>>>>>>>>> use "Reply All" to discuss whether it should be verified or
>>>>>>>>>> rejected. When a decision is reached, the verifying party (IESG)
>>>>>>>>>> can log in to change the status and edit the report, if necessary.
>>>>>>>>>>
>>>>>>>>>> --------------------------------------
>>>>>>>>>> RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10)
>>>>>>>>>> --------------------------------------
>>>>>>>>>> Title               : Information Model for IP Flow Information Export (IPFIX)
>>>>>>>>>> Publication Date    : September 2013
>>>>>>>>>> Author(s)           : B. Claise, Ed., B. Trammell, Ed.
>>>>>>>>>> Category            : PROPOSED STANDARD
>>>>>>>>>> Source              : IP Flow Information Export
>>>>>>>>>> Area                : Operations and Management
>>>>>>>>>> Stream              : IETF
>>>>>>>>>> Verifying Party     : IESG
>>>>>>>>>> _______________________________________________
>>>>>>>>>> IPFIX mailing list
>>>>>>>>>> IPFIX@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>> _______________________________________________
>>>>>>>>> IPFIX mailing list
>>>>>>>>> IPFIX@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>>>> _______________________________________________
>>>>>>> IPFIX mailing list
>>>>>>> IPFIX@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>
>>>>
>>>> -- 
>>>> For corporate legal information go to:
>>>>
>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>>>
>>>
>>
>>
>> -- 
>> For corporate legal information go to:
>>
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>
>


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html


--------------050302040600050000050307
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 03/01/2014 15:39, Brian Trammell
      wrote:

    

    

      
      Hi Stewart,
      


      

      

        

          
On 03 Jan 2014, at 13:11, Stewart Bryant <stbryant@cisco.com>
            wrote:

          

          

            
            

              

                

                  

                    


                    

                    
So each instance of an IE of an ADT can take a
                      value, and that value exists separate from its
                      encoding. 7011 and 7012 together combine to make
                      an unambiguous mapping between the two possible in
                      IPFIX.

                  

                

              

              

              I think the key is the last sentence, and so long as we
              make that clear we are good.

              

              Maybe some text of the form "relative to the defined
              epoch" would sort it out. At least

              that would remind the reader that they needs to know
              rather than assume the epoch.

            

          

          


          

          
This may seem like a tiny little nit to pick, but we
            thought a _whole lot_ about this when moving the epochs out
            of 5102bis, and I still think the reasons therefor are
            valid. I’d ask you to reconsider insisting on timestamps as
            relative to a fixed epoch. I’d rather state instead
            something like "it is the responsibility of the encoding to
            ensure that each representation has an unambiguous mapping
            to a moment in time (e.g. relative to a defined epoch)."

        

      

    

    

    If you are proposing that text, that would work for me. 

    

      

        

          


          

          
Otherwise we go down the calendar rathole very, very
            quickly, and we’ve tried very hard not to do that. Indeed,
            one can define any time representation as relative to some
            epoch, more or less fuzzily. However, back to our ISO 8601
            example, one can indeed interpret “2014-01-03 10:00:00 UTC”
            as a fixed number of years, months, days, hours, and so on
            from the implicit epoch 0001-01-01 00:00:00 UTC. One would
            be wrong, given variability in Julian-Gregorian calendar
            transitions, policies for accounting/ignoring leap seconds,
            and all those other assumptions one has to make when turning
            a human-readable timestamp (our “ideal” value) to some
            notion of the moment in time it references.

          


          

          
I submit that these differences are largely irrelevant on
            the timescales and for the types of comparisons in event
            timing — whether network management related or not — that
            the IPFIX information model is likely to be applied to. But
            if we bake fixed-epoch references into the information model
            we’re forced to care about them regardless.

        

      

    

    No, I am fine with the IM not baking in the epoch, now I understand
    the approach, and the with the other changes that tell the reader
    that they moved. However, I think you do need to help the reader
    understand the importance of understanding the of the epoch (and now
    you remind me the discontinuities). The above sentence will do this.

    

    Stewart

    

    

      

        

          


          

          
Thanks, cheers,

          


          

          
Brian

          


          

          

            

              

                

                  

                    

                      

                        

                          
We may need a call to work though this and another issue
I am about to raise on the IPFIX list.

- Stewart



                          On 31/12/2013 12:44, Brian Trammell wrote:

                        

                        

                          
hi Stewart,

Stewart Bryant (stbryant) wrote:


                          

                            
Certainly something is needed. I was thinking of using IPFIX as an information gathering method in a radio context, and went to look at the definition of the types and could not find the epoch, or even a reference to the epoch. Now part of the problem (which was my fault) was that I did not notice at the time that the elements were defined by the obsolete RFC5102 and went straight to the new RFC. However having the definitions in an obsolete RFC also seems problematic, since it puts the IEs in a strange state. Since RFC 7012 replaces RFC5102 and includes the definitions you would expect the definition in RFC7012 to replace the definition in RFC5102, but those definitions are, as I explained incomplete.


                          

                          
This is intentional. See below.



                          

                            
I need to look at this some more when I get back to work, but I am now also concerned that if the epoch can change, the definition of the existing IEs is now unreliable.


                          

                          
The definition of the existing IEs is based upon the definition of the
ADT itself in 7012 as well as the definition of the ADT representation
within the IPFIX protocol in 7011. It is not the intention that reading
7012 tells you how to encode IEs for use with IPFIX; that's what section
6.1 of 7011 is for.



                          

                            
You will notice in the errata that I did suggest that an alternative resolution would be to include a reference to the epoch text.


                          

                          
The point is that the ADT _explicitly_ does not have a binding to an
epoch, as epochs are only necessary when using integral representations
of timestamps. IPFIX's representations for these ADTs are integral, but
bindings to other representations need not be (see, for example,
draft-trammell-ipfix-text-adt, which recommends ISO8601-style timestamps
for textual representations of IE values).

I'd suggest instead somehow expanding the present text in 7012 to
reiterate that if you're using IPFIX, the representations of the ADTs
are in 7011:

OLD para 2 sec 3.1 7012:

   The current encodings of these data types for use with the IPFIX
   protocol are defined in [RFC7011]; encodings allowing the use of the
   IPFIX Information Elements [IANA-IPFIX] with other protocols may be
   defined in the future by referencing this document.

NEW para 2 sec 3.1 7012:

   The abstract data type definitions in this section are intended
   only to define the values which can be taken by Information
   Elements of each type. The encodings of these data types for
   use with the IPFIX protocol are defined in Section 6.1 of
   [RFC7011]; encodings  allowing the use of the IPFIX Information
   Elements [IANA-IPFIX] with other protocols may be defined in the
   future by referencing this document.

Best regards,

Brian




                          

                            
Stewart



Sent from my iPad



                            

                              
On 31 Dec 2013, at 08:50, "Brian Trammell" <trammell@tik.ee.ethz.ch> wrote:

hi Paul, all,

+n.

The separation between ADTs and ADT encoding between 7012 and 7011 was explicit and purposeful. Specifically, we do _not_ want to exclude other representations of the IPFIX Information Model from being based upon other encodings of these ADTs, whether ISO 8601 (which either has no epoch or epoch 0000-00-00 00:00 UTC, depending on how you count), NTP (1904), Julian day based counting, etc, etc, etc…

If there is confusion on this point, I’d suggest adding more explanatory text on this point to Paragraph 2 of the front matter to section 3.1. But as is, I emphatically recommend rejection of this reported erratum.

Best regards,

Brian



                              

                                
On 31 Dec 2013, at 03:58, Paul Aitken <paitken@cisco.com> wrote:

+1

If anyone was going to raise an errata on this, it would have been me ;-)

I've pointed this issue out before, probably more than once - and have been encouraged to read RFC 3444.

P.




                                

                                  
On 30/12/2013 09:23, Andrew Feren wrote:
The encoding for the time data types is specified RFC 7011 Sections
6.1.7 through 6.1.10.

-Andrew



                                  

                                    
On 12/30/2013 10:13 AM, RFC Errata System wrote:
The following errata report has been submitted for RFC7012,
"Information Model for IP Flow Information Export (IPFIX)".

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

--------------------------------------
Type: Technical
Reported by: Stewart Bryant <stbryant@cisco.com>

Section: 3.1.15-17

Original Text
-------------
3.1.15. dateTimeSeconds

  The type "dateTimeSeconds" represents a time value expressed with
  second-level precision.

3.1.16. dateTimeMilliseconds

  The type "dateTimeMilliseconds" represents a time value expressed
  with millisecond-level precision.

3.1.17. dateTimeMicroseconds

  The type "dateTimeMicroseconds" represents a time value expressed
  with microsecond-level precision.

3.1.18. dateTimeNanoseconds

  The type "dateTimeNanoseconds" represents a time value expressed with
  nanosecond-level precision.


Corrected Text
--------------
3.1.15. dateTimeSeconds

  The type "dateTimeSeconds" represents a time value in units of
  seconds based on coordinated universal time (UTC).  The choice of an
  epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.16. dateTimeMilliseconds

  The type "dateTimeMilliseconds" represents a time value in units of
  milliseconds based on coordinated universal time (UTC).  The choice
  of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.17. dateTimeMicroseconds

  The type "dateTimeMicroseconds" represents a time value in units of
  microseconds based on coordinated universal time (UTC).  The choice
  of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.18. dateTimeNanoseconds

  The type "dateTimeNanoseconds" represents a time value in units of
  nanoseconds based on coordinated universal time (UTC).  The choice of
  an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.


Notes
-----
Although section 1.1 says : - "Definitions of timestamp data types have been clarified." The edited text has removed the epoch definition, and this does not seem to have been incorporated elsewhere in the RFC.

Without a specified epoch, there is no unique definition of the timestamps.

My proposal above is to revert to the RFC5102 definitions. RFC7102 is intended to be backwards compatible with RFC5102 and thus the definitions need to be technically identical. Alternatively, if the text is now included elsewhere in RFC7012 or in another RFC, it would be helpful to the reader to provide a reference to the epoch definition in an editorial update to dateTimeX definitions in RFC7102.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10)
--------------------------------------
Title               : Information Model for IP Flow Information Export (IPFIX)
Publication Date    : September 2013
Author(s)           : B. Claise, Ed., B. Trammell, Ed.
Category            : PROPOSED STANDARD
Source              : IP Flow Information Export
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


                                  

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


                                

                              

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


                            

                          

                        

                        

                        

                        
-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html



                      

                    

                  

                  

                

              

              

              

              
-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html



            

          

        

        

      

    

    

    

    
-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html



  


--------------050302040600050000050307--

From trammell@tik.ee.ethz.ch  Fri Jan  3 09:54:53 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634981AE021 for ; Fri,  3 Jan 2014 09:54:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.137
X-Spam-Level: 
X-Spam-Status: No, score=-4.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAJOVu_ZU5zM for ; Fri,  3 Jan 2014 09:54:49 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6601ADFFC for ; Fri,  3 Jan 2014 09:54:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 48B26D9303; Fri,  3 Jan 2014 18:54:41 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8cILQTZcdoF6; Fri,  3 Jan 2014 18:54:41 +0100 (MET)
Received: from [10.0.27.113] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 4D2D5D9302; Fri,  3 Jan 2014 18:54:40 +0100 (MET)
Content-Type: multipart/signed; boundary="Apple-Mail=_79C0BEC1-7876-4B72-9189-5D727F6979D0"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Brian Trammell 
In-Reply-To: <52C6A7C6.1020703@cisco.com>
Date: Fri, 3 Jan 2014 18:54:39 +0100
Message-Id: <9825ADB8-DE16-4EDA-9AFA-65DC6D39696C@tik.ee.ethz.ch>
References: <52C56FA7.6070905@cisco.com>  <52C6A7C6.1020703@cisco.com>
To: "stbryant@cisco.com Bryant" 
X-Mailer: Apple Mail (2.1827)
Cc: ipfix-ads@tools.ietf.org, "ipfix@ietf.org Group" , "ipfix-chairs@tools.ietf.org" 
Subject: Re: [IPFIX] Application of IPFIX to new application spaces.
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Jan 2014 17:54:53 -0000

--Apple-Mail=_79C0BEC1-7876-4B72-9189-5D727F6979D0
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_01B775AB-3238-4DB5-A5A3-842F7C656426"


--Apple-Mail=_01B775AB-3238-4DB5-A5A3-842F7C656426
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On 03 Jan 2014, at 13:06, Stewart Bryant  wrote:

> I brought up the concept of ownership of PENs by individuals=20
> in a couple of IESG discussions on IPFIX, and the opinion that
> I get (as I recall from the APPs ADs) is that PENs were never=20
> intended to be assigned to individuals together with surprise
> that any had been allocated to individuals. Hence my initial=20
> reluctance. I know that there are some other owned by individuals,=20
> and I  have requested one for the purpose of trying out this=20
> application of the protocol. However I think the concern is=20
> that it would not scale if every individual experimenter=20
> requested their own, much less one per experiment.

It=92s probably well outside the scope of IANA=92s competence to rule on =
the differences between individuals, sole proprietorships, single member =
LLCs/GmbHs, C/S corporations, AGs/ABs/SAs, unorganized collectives of =
software developers, and so on. Without that competence, it=92s pretty =
difficult to give them guidelines as to what to allow and what to deny =
in terms of individual registrations. So FCFS to anyone who can control =
an email address it is.

If you=92re doing experiments with IPFIX (or, indeed, SNMP) as an =
individual or academic at an organization without a PEN or where it=92s =
difficult to get =93official=94 IPFIX IE number space within that PEN, =
getting your own is the only way to go.

Of course, I=92m probably the worst abuser of this property, having =
requested the first PEN (29305) for an RFC (5103) for the single-record =
biflow hack.=20
>> I could see this being a problem if one were trying to run many =
experiments within the same very large organization with undefined or =
draconian processes for reserving an enterprise-specific IE. But PEN =
space is 2^32-1 large and we haven;t even exhausted the first block of =
2^16, so =93get a new PEN and label it useful for a given experiment=94 =
is probably an acceptable way out of this quandary.
> I think the question is one of whether or not that is best practice.
> Sure the space is large, but so was the IPv4 Address space when it
> was created :)

I share your concern in theory. But practically I cannot imagine a world =
in which the number of IPFIX experiments (plus normal SMI =93enterprises=94=
) is anywhere near on the order of addressable locations in the IPv4 =
number space. We=92re talking tens of PENs, hundreds if we are =
successful in expanding the IPFIX information model to be the One True =
Way the Internet of Things talks about itself.

I realize I=92ve just made a =93nobody needs more than 64k autonomous =
systems=94 statement. And I completely agree that this is somewhat =
outside the original intention of the PEN registry at its creation time, =
but compare this to the difference between the domain name space as it =
was conceived and as it=92s (ab)used today, and I think what I=92m =
proposing is a relatively minor violation, and is indeed not really all =
that different from the PENs-for-application-areas proposal (which I =
quite like as well).
>>> For reasons that will
>>> be clear from other work I have done in the IETF, I dislike
>>> the idea of "camping" on code-points. This makes it clear
>>> to me that we need a small, but not trivial set of
>>> experimental IEs that are intended for prototyping but
>>> explicitly excluded from use in production systems.
>>> This needs to be a reasonable number since a new application
>>> space might need a fair number of IEs to be practical.
>>> Thus I think that we need to either allocate some of the
>>> base protocol IEs to experimental, or to have IANA
>>> allocate a PEN specifically to experimental use which
>>> would allow experimentation in new applications spaces
>>> without the need to formally allocate IEs in either the
>>> base IE space, or the PEN space of the organization
>>> (or person) conducting the experiment.
>> I agree in principle that allocating a single =93IPFIX =
Experimentation=94 PEN would be one solution to this problem, but it =
would have to be fairly tightly scoped (only for experimental use among =
EPs and CPs implemented and deployed by a single entity within the scope =
of a single experiment; MUST be logged as an error by CPs in production =
use). And I=92d be very concerned that we were basically inviting people =
to camp on a whole new code space =97 requiring experiments to use their =
own PEN space at least keeps experimental IEs that =93leak=94 into =
production from colliding with each other, provided that the PEN owner =
manages their own space competently.
> Text of the following format needs to be associated with the
> space:
> Code points in the experimental range MUST be used according to the
> guidelines of RFC 3692 [RFC3692].
Yep, that=92s good and unambiguous, but it still does not address the =
issue of what happens after the termination of the experiment.
>>> The second problem that I see is the lack of a public registry
>>> for non-network managements applications. Specifically
>>> I am going to need "callsign", "maidenhead locator",
>>> "frequency", "noise power", maybe "field strength", "receiver type"
>>> etc. Now some of those may be of general use (frequency)
>>> but most of them would be cruft in the base protocol IE set
>>> which is set up for networking applications. On the other hand,
>>> I know of at least one PEN space that will have a number of the
>>> terms I need already defined, although these are by
>>> definition private.=20
s/private/not necessarily public/ =97 there is nothing keeping an =
operator of a PEN registry from publishing that registry. Indeed, the =
intention of RFC 5610 was to allow such operators to publish such =
registries _inline_ to allow polymorphic collectors / file readers to =
load such registries at runtime.
>>> With the current IE registration structure
>>> the absence of a public registry inevitably means the
>>> redefinition of other than mainstream/network management
>>> terms across a number of private registries. I thus think
>>> it would be useful to introduce a PEN + registry for
>>> "other applications" or introduce the concept of a series
>>> of application specific registries with appropriate  PENs to
>>> identify the application space rather than  the private
>>> enterprise space.

As I noted above, there=92s already precedent for this: PEN 29305 for =
RFC 5103.

We could certainly define a few =93extended application=94 areas, assign =
them PENs, and allocate them via IANA; we=92d just need to add a PEN =
column to the registry, and update 7102. Deciding on an initial list =
might take a while though.

Cheers,

Brian

--Apple-Mail=_01B775AB-3238-4DB5-A5A3-842F7C656426
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On 03 Jan 2014, at 13:06, Stewart =
Bryant <stbryant@cisco.com> =
wrote:


 =20
    
 =20
  

    

    

    I brought up the concept of ownership of PENs by individuals 

    in a couple of IESG discussions on IPFIX, and the opinion that

    I get (as I recall from the APPs ADs) is that PENs were never 

    intended to be assigned to individuals together with surprise

    that any had been allocated to individuals. Hence my initial 

    reluctance. I know that there are some other owned by individuals, =


    and I  have requested one for the purpose of trying out this =


    application of the protocol. However I think the concern is 

    that it would not scale if every individual experimenter 

    requested their own, much less one per =
experiment.

It=92s probably =
well outside the scope of IANA=92s competence to rule on the differences =
between individuals, sole proprietorships, single member LLCs/GmbHs, C/S =
corporations, AGs/ABs/SAs, unorganized collectives of software =
developers, and so on. Without that competence, it=92s pretty difficult =
to give them guidelines as to what to allow and what to deny in terms of =
individual registrations. So FCFS to anyone who can control an email =
address it is.

If you=92re doing experiments =
with IPFIX (or, indeed, SNMP) as an individual or academic at an =
organization without a PEN or where it=92s difficult to get =93official=94=
 IPFIX IE number space within that PEN, getting your own is the only way =
to go.

Of course, I=92m probably the worst =
abuser of this property, having requested the first PEN (29305) for an =
RFC (5103) for the single-record biflow hack. 

    

      
I could see this being a problem if one were trying =
to run many experiments within the same very large organization with =
undefined or draconian processes for reserving an enterprise-specific =
IE. But PEN space is 2^32-1 large and we haven;t even exhausted the =
first block of 2^16, so =93get a new PEN and label it useful for a given =
experiment=94 is probably an acceptable way out of this quandary.

    

    I think the question is one of whether or not that is best =
practice.

    Sure the space is large, but so was the IPv4 Address space when =
it

    was created :)

I share your =
concern in theory. But practically I cannot imagine a world in which the =
number of IPFIX experiments (plus normal SMI =93enterprises=94) is =
anywhere near on the order of addressable locations in the IPv4 number =
space. We=92re talking tens of PENs, hundreds if we are successful in =
expanding the IPFIX information model to be the One True Way the =
Internet of Things talks about itself.

I =
realize I=92ve just made a =93nobody needs more than 64k autonomous =
systems=94 statement. And I completely agree that this is somewhat =
outside the original intention of the PEN registry at its creation time, =
but compare this to the difference between the domain name space as it =
was conceived and as it=92s (ab)used today, and I think what I=92m =
proposing is a relatively minor violation, and is indeed not really all =
that different from the PENs-for-application-areas proposal (which I =
quite like as well).
For reasons that =
will
be clear from other work I have done in the IETF, I dislike
the idea of "camping" on code-points. This makes it clear
to me that we need a small, but not trivial set of
experimental IEs that are intended for prototyping but
explicitly excluded from use in production systems.
This needs to be a reasonable number since a new application
space might need a fair number of IEs to be practical.
Thus I think that we need to either allocate some of the
base protocol IEs to experimental, or to have IANA
allocate a PEN specifically to experimental use which
would allow experimentation in new applications spaces
without the need to formally allocate IEs in either the
base IE space, or the PEN space of the organization
(or person) conducting the experiment.


      

      
I agree in principle that allocating a single =
=93IPFIX Experimentation=94 PEN would be one solution to this problem, =
but it would have to be fairly tightly scoped (only for experimental use =
among EPs and CPs implemented and deployed by a single entity within the =
scope of a single experiment; MUST be logged as an error by CPs in =
production use). And I=92d be very concerned that we were basically =
inviting people to camp on a whole new code space =97 requiring =
experiments to use their own PEN space at least keeps experimental IEs =
that =93leak=94 into production from colliding with each other, provided =
that the PEN owner manages their own space competently.

    

    Text of the following format needs to be associated with the

    space:

    
    
Code points in the experimental range MUST be =
used according to the
guidelines of RFC =
3692 [RFC3692].
Yep, that=92s =
good and unambiguous, but it still does not address the issue of what =
happens after the termination of the experiment.

      

        
The second problem that I see is the lack of a =
public registry
for non-network managements applications. Specifically
I am going to need "callsign", "maidenhead locator",
"frequency", "noise power", maybe "field strength", "receiver type"
etc. Now some of those may be of general use (frequency)
but most of them would be cruft in the base protocol IE set
which is set up for networking applications. On the other hand,
I know of at least one PEN space that will have a number of the
terms I need already defined, although these are by
definition private. =

s/private/not =
necessarily public/ =97 there is nothing keeping an operator of a PEN =
registry from publishing that registry. Indeed, the intention of RFC =
5610 was to allow such operators to publish such registries _inline_ to =
allow polymorphic collectors / file readers to load such registries at =
runtime.
With the current =
IE registration structure
the absence of a public registry inevitably means the
redefinition of other than mainstream/network management
terms across a number of private registries. I thus think
it would be useful to introduce a PEN + registry for
"other applications" or introduce the concept of a series
of application specific registries with appropriate  PENs to
identify the application space rather than  the private
enterprise =
space.

As I noted above, there=92s already precedent for this: PEN 29305 for =
RFC 5103.

We could certainly define a few =
=93extended application=94 areas, assign them PENs, and allocate them =
via IANA; we=92d just need to add a PEN column to the registry, and =
update 7102. Deciding on an initial list might take a while =
though.

Cheers,

Brian
=

--Apple-Mail=_01B775AB-3238-4DB5-A5A3-842F7C656426--

--Apple-Mail=_79C0BEC1-7876-4B72-9189-5D727F6979D0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSxvlfAAoJENt3nsOmbNJc/j4IAM+MfEaKERC09DZN6jiP+//i
HXz9JfUzkaBw4HuEJuFvrulZ6s6s9BPk/YPKYpOSPy0b3v9D1SedYEXmGVo6eFyj
bZCxnKllS6cxgu9A2dNWNqO6656m6SinMTeV1Q6wlMRFQfo0JhFX6iWSPRJ+7cAB
9P1VAQVwyxmAAe1GsMosGfjF3qdgU7sR+4mpw1POOoOSxE9F2MuZ7Jx6M0aSYQFB
kra2n8s0Xxyo1JdvzyL0wh52Hgl07Ii4VrWUZR5KZ9LmIdBB+aIs6fPfGkKVIobU
UEJmVWYO69+E1bZ2n2DGMvZcY+dvkekzjyRIBvJD7mFlzlQd4uhsYZEa2nDBY64=
=HmAg
-----END PGP SIGNATURE-----

--Apple-Mail=_79C0BEC1-7876-4B72-9189-5D727F6979D0--

From paitken@cisco.com  Fri Jan  3 20:57:59 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDB61A1F19 for ; Fri,  3 Jan 2014 20:57:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.038
X-Spam-Level: 
X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dkN7R3u1xn2 for ; Fri,  3 Jan 2014 20:57:55 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 256601A1EF9 for ; Fri,  3 Jan 2014 20:57:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8980; q=dns/txt; s=iport; t=1388811467; x=1390021067; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=9gT+G+IaY5BPtD9CkXrNp27/9Rgm6YruPb2AH9YjQ24=; b=QdBo1Cu/T0MNSiDcpyv4eMgMNGR4kpcA70z+9ULnbmvjyZDb17gHSIjX mvSTtbNYMZKUhGH+/WCf+jFwJt9q9sXq/bpMDfmi14m3+LTnxZVdTZVXC /Q7U+Z/hiKr+OYho3vg3WFTTJ9AvvbTqgH/rC+RrUIGadvOqktl9f4xtj k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FAKOTx1KQ/khR/2dsb2JhbABOCoMLOIkwsE2BDBZ0giUBAQEDAQEBAWsDBwEQCyEUAg8JAwIBAgEVMAYBDAEFAgEBF4dhCA3DORMEjjIOTgeENwSYF4ZFi0+DLQ
X-IronPort-AV: E=Sophos;i="4.95,602,1384300800"; d="scan'208,217";a="3164258"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 04 Jan 2014 04:57:46 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s044vkw8008723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Jan 2014 04:57:46 GMT
Received: from [10.61.97.159] (dhcp-10-61-97-159.cisco.com [10.61.97.159]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s044vi5d024321; Sat, 4 Jan 2014 04:57:44 GMT
Message-ID: <52C794C2.7020503@cisco.com>
Date: Sat, 04 Jan 2014 04:57:38 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Brian Trammell , "stbryant@cisco.com Bryant" 
References: <52C56FA7.6070905@cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080206010504080605010205"
Cc: ipfix-ads@tools.ietf.org, "ipfix@ietf.org Group" , "ipfix-chairs@tools.ietf.org" 
Subject: Re: [IPFIX] Application of IPFIX to new application spaces.
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 04 Jan 2014 04:58:00 -0000

This is a multi-part message in MIME format.
--------------080206010504080605010205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stewart, Brian,

>> For reasons that will
>> be clear from other work I have done in the IETF, I dislike
>> the idea of "camping" on code-points. This makes it clear
>> to me that we need a small, but not trivial set of
>> experimental IEs that are intended for prototyping but
>> explicitly excluded from use in production systems.
>> This needs to be a reasonable number since a new application
>> space might need a fair number of IEs to be practical.
>> Thus I think that we need to either allocate some of the
>> base protocol IEs to experimental, or to have IANA
>> allocate a PEN specifically to experimental use which
>> would allow experimentation in new applications spaces
>> without the need to formally allocate IEs in either the
>> base IE space, or the PEN space of the organization
>> (or person) conducting the experiment.
> I agree in principle that allocating a single "IPFIX Experimentation" PEN would be one solution to this problem, but it would have to be fairly tightly scoped (only for experimental use among EPs and CPs implemented and deployed by a single entity within the scope of a single experiment; MUST be logged as an error by CPs in production use). And I'd be very concerned that we were basically inviting people to camp on a whole new code space --- requiring experiments to use their own PEN space at least keeps experimental IEs that "leak" into production from colliding with each other, provided that the PEN owner manages their own space competently.

+1

I was about to say the same. While the "Experimentation PEN" idea sounds 
good, there are practical dangers:

With my netflow-police hat on, I allocate cisco's NFv9 and IPFIX 
enterprise-specific IDs. I've had to reserve blocks of NFv9 IDs which 
have been used by third parties (external to cisco) in released code 
without telling us (a collector partner was good enough to inform us 
about the potential clash). And in the past we've allocated our own 
experimental IPFIX IDs which were meant to be replaced with IANA IDs 
before release, but got overlooked.

To avoid any issues, I'd rather see experiments done in private PEN space.

P.


>
>> The second problem that I see is the lack of a public registry
>> for non-network managements applications. Specifically
>> I am going to need "callsign", "maidenhead locator",
>> "frequency", "noise power", maybe "field strength", "receiver type"
>> etc. Now some of those may be of general use (frequency)
>> but most of them would be cruft in the base protocol IE set
>> which is set up for networking applications. On the other hand,
>> I know of at least one PEN space that will have a number of the
>> terms I need already defined, although these are by
>> definition private. With the current IE registration structure
>> the absence of a public registry inevitably means the
>> redefinition of other than mainstream/network management
>> terms across a number of private registries. I thus think
>> it would be useful to introduce a PEN + registry for
>> "other applications" or introduce the concept of a series
>> of application specific registries with appropriate  PENs to
>> identify the application space rather than  the private
>> enterprise space.
> This seems like a very good idea. I'll have to think about it some more.
>
> Thanks, cheers,
>
> Brian
>
>> __________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


--------------080206010504080605010205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Stewart, Brian,

    

    

    

      

        
For reasons that will
be clear from other work I have done in the IETF, I dislike
the idea of "camping" on code-points. This makes it clear
to me that we need a small, but not trivial set of
experimental IEs that are intended for prototyping but
explicitly excluded from use in production systems.
This needs to be a reasonable number since a new application
space might need a fair number of IEs to be practical.
Thus I think that we need to either allocate some of the
base protocol IEs to experimental, or to have IANA
allocate a PEN specifically to experimental use which
would allow experimentation in new applications spaces
without the need to formally allocate IEs in either the
base IE space, or the PEN space of the organization
(or person) conducting the experiment.


      

      
I agree in principle that allocating a single “IPFIX Experimentation” PEN would be one solution to this problem, but it would have to be fairly tightly scoped (only for experimental use among EPs and CPs implemented and deployed by a single entity within the scope of a single experiment; MUST be logged as an error by CPs in production use). And I’d be very concerned that we were basically inviting people to camp on a whole new code space — requiring experiments to use their own PEN space at least keeps experimental IEs that “leak” into production from colliding with each other, provided that the PEN owner manages their own space competently.

    

    

    +1

    

    I was about to say the same. While the "Experimentation PEN" idea
    sounds good, there are practical dangers:

    

    With my netflow-police hat on, I allocate cisco's NFv9 and IPFIX
    enterprise-specific IDs. I've had to reserve blocks of NFv9 IDs
    which have been used by third parties (external to cisco) in
    released code without telling us (a collector partner was good
    enough to inform us about the potential clash). And in the past
    we've allocated our own experimental IPFIX IDs which were meant to
    be replaced with IANA IDs before release, but got overlooked.

    

    To avoid any issues, I'd rather see experiments done in private PEN
    space.

    

    P.

    

    

    

      



      

        
The second problem that I see is the lack of a public registry
for non-network managements applications. Specifically
I am going to need "callsign", "maidenhead locator",
"frequency", "noise power", maybe "field strength", "receiver type"
etc. Now some of those may be of general use (frequency)
but most of them would be cruft in the base protocol IE set
which is set up for networking applications. On the other hand,
I know of at least one PEN space that will have a number of the
terms I need already defined, although these are by
definition private. With the current IE registration structure
the absence of a public registry inevitably means the
redefinition of other than mainstream/network management
terms across a number of private registries. I thus think
it would be useful to introduce a PEN + registry for
"other applications" or introduce the concept of a series
of application specific registries with appropriate  PENs to
identify the application space rather than  the private
enterprise space.


      

      
This seems like a very good idea. I’ll have to think about it some more.

Thanks, cheers,

Brian



      

        
__________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


      

      

      

      

      

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


    

    

  


--------------080206010504080605010205--

From ietf-secretariat-reply@ietf.org  Wed Jan  8 08:41:59 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3FE1ADFB2 for ; Wed,  8 Jan 2014 08:41:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70ztwnyo48oJ for ; Wed,  8 Jan 2014 08:41:58 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 565A11ADFB7 for ; Wed,  8 Jan 2014 08:41:56 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: ipfix@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.90.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140108164156.28748.91314.idtracker@ietfa.amsl.com>
Date: Wed, 08 Jan 2014 08:41:56 -0800
From: IETF Secretariat 
X-Mailman-Approved-At: Wed, 08 Jan 2014 12:03:44 -0800
Subject: [IPFIX] Milestones changed for ipfix WG
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jan 2014 16:42:00 -0000

Changed milestone "Submit data link IEs for publication as Standards
track RFC", resolved as "Done".

Changed milestone "Submit IPFIX use at mediators for publication as
Standards track RFC", resolved as "Done".

URL: http://datatracker.ietf.org/wg/ipfix/charter/

From andrewf@plixer.com  Wed Jan  8 12:28:22 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AF51AE192 for ; Wed,  8 Jan 2014 12:28:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.837
X-Spam-Level: 
X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGUEP1V1yAzY for ; Wed,  8 Jan 2014 12:28:16 -0800 (PST)
Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id BA1BD1AE179 for ; Wed,  8 Jan 2014 12:28:15 -0800 (PST)
Received: from [10.1.15.178] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Jan 2014 15:28:05 -0500
Message-ID: <52CDB4D8.6070501@plixer.com>
Date: Wed, 8 Jan 2014 15:28:08 -0500
From: Andrew Feren 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Brian Trammell , "stbryant@cisco.com Bryant" 
References: <52C56FA7.6070905@cisco.com>  <52C6A7C6.1020703@cisco.com> <9825ADB8-DE16-4EDA-9AFA-65DC6D39696C@tik.ee.ethz.ch>
In-Reply-To: <9825ADB8-DE16-4EDA-9AFA-65DC6D39696C@tik.ee.ethz.ch>
Content-Type: multipart/alternative; boundary="------------020308080101010609030709"
Cc: ipfix-ads@tools.ietf.org, "ipfix@ietf.org Group" , "ipfix-chairs@tools.ietf.org" 
Subject: Re: [IPFIX] Application of IPFIX to new application spaces.
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jan 2014 20:28:22 -0000

--------------020308080101010609030709
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Hi Stewart, Brian, all,

Comments inline

On 01/03/2014 12:54 PM, Brian Trammell wrote:
>
> On 03 Jan 2014, at 13:06, Stewart Bryant  > wrote:
>
>> I brought up the concept of ownership of PENs by individuals
>> in a couple of IESG discussions on IPFIX, and the opinion that
>> I get (as I recall from the APPs ADs) is that PENs were never
>> intended to be assigned to individuals together with surprise
>> that any had been allocated to individuals. Hence my initial
>> reluctance. I know that there are some other owned by individuals,
>> and I  have requested one for the purpose of trying out this
>> application of the protocol. However I think the concern is
>> that it would not scale if every individual experimenter
>> requested their own, much less one per experiment.
>
> It's probably well outside the scope of IANA's competence to rule on
> the differences between individuals, sole proprietorships, single
> member LLCs/GmbHs, C/S corporations, AGs/ABs/SAs, unorganized
> collectives of software developers, and so on. Without that
> competence, it's pretty difficult to give them guidelines as to what
> to allow and what to deny in terms of individual registrations. So
> FCFS to anyone who can control an email address it is.
>
> If you're doing experiments with IPFIX (or, indeed, SNMP) as an
> individual or academic at an organization without a PEN or where it's
> difficult to get "official" IPFIX IE number space within that PEN,
> getting your own is the only way to go.

+1

I assume that the point of the experiments is to eventually move beyond
the experiment.  At some point a PEN will likely be needed for the IEs
that proved useful in the experiment.  Might as well get the PEN and
start using it.

>
> Of course, I'm probably the worst abuser of this property, having
> requested the first PEN (29305) for an RFC (5103) for the
> single-record biflow hack. 
>>> I could see this being a problem if one were trying to run many experiments within the same very large organization with undefined or draconian processes for reserving an enterprise-specific IE. But PEN space is 2^32-1 large and we haven;t even exhausted the first block of 2^16, so "get a new PEN and label it useful for a given experiment" is probably an acceptable way out of this quandary.
>> I think the question is one of whether or not that is best practice.
>> Sure the space is large, but so was the IPv4 Address space when it
>> was created :)
>
> I share your concern in theory. But practically I cannot imagine a
> world in which the number of IPFIX experiments (plus normal SMI
> "enterprises") is anywhere near on the order of addressable locations
> in the IPv4 number space. We're talking tens of PENs, hundreds if we
> are successful in expanding the IPFIX information model to be the One
> True Way the Internet of Things talks about itself.
>
> I realize I've just made a "nobody needs more than 64k autonomous
> systems" statement. And I completely agree that this is somewhat
> outside the original intention of the PEN registry at its creation
> time, but compare this to the difference between the domain name space
> as it was conceived and as it's (ab)used today, and I think what I'm
> proposing is a relatively minor violation, and is indeed not really
> all that different from the PENs-for-application-areas proposal (which
> I quite like as well).
>>>> For reasons that will
>>>> be clear from other work I have done in the IETF, I dislike
>>>> the idea of "camping" on code-points. This makes it clear
>>>> to me that we need a small, but not trivial set of
>>>> experimental IEs that are intended for prototyping but
>>>> explicitly excluded from use in production systems.
>>>> This needs to be a reasonable number since a new application
>>>> space might need a fair number of IEs to be practical.
>>>> Thus I think that we need to either allocate some of the
>>>> base protocol IEs to experimental, or to have IANA
>>>> allocate a PEN specifically to experimental use which
>>>> would allow experimentation in new applications spaces
>>>> without the need to formally allocate IEs in either the
>>>> base IE space, or the PEN space of the organization
>>>> (or person) conducting the experiment.
>>> I agree in principle that allocating a single "IPFIX Experimentation" PEN would be one solution to this problem, but it would have to be fairly tightly scoped (only for experimental use among EPs and CPs implemented and deployed by a single entity within the scope of a single experiment; MUST be logged as an error by CPs in production use). And I'd be very concerned that we were basically inviting people to camp on a whole new code space --- requiring experiments to use their own PEN space at least keeps experimental IEs that "leak" into production from colliding with each other, provided that the PEN owner manages their own space competently.
>> Text of the following format needs to be associated with the
>> space:
>> Code points in the experimental range MUST be used according to the
>> guidelines of RFC 3692  [RFC3692 ].
> Yep, that's good and unambiguous, but it still does not address the
> issue of what happens after the termination of the experiment.
>>>> The second problem that I see is the lack of a public registry
>>>> for non-network managements applications. Specifically
>>>> I am going to need "callsign", "maidenhead locator",
>>>> "frequency", "noise power", maybe "field strength", "receiver type"
>>>> etc. Now some of those may be of general use (frequency)
>>>> but most of them would be cruft in the base protocol IE set
>>>> which is set up for networking applications. On the other hand,
>>>> I know of at least one PEN space that will have a number of the
>>>> terms I need already defined, although these are by
>>>> definition private. 
> s/private/not necessarily public/ --- there is nothing keeping an
> operator of a PEN registry from publishing that registry. Indeed, the
> intention of RFC 5610 was to allow such operators to publish such
> registries _inline_ to allow polymorphic collectors / file readers to
> load such registries at runtime.

In fact many PEN/IE registries have in fact been published in one form
or an other, but I sure would love a central location with a parseable
format.  This is not the first time that a desire for a central
enterprise registry has been voiced
(http://www.ietf.org/mail-archive/web/ipfix/current/msg05825.html).

Obviously the owner of each PEN should decide which elements they want
to publish information about and when.  Aside from making my life as a
collector developer easier I think there are other advantages to a
central registry.  One such advantage would be exposing IEs for which
there is significant interest and which are therefore potential
candidates to be standardized.

I have built my own version of a central registry as I encounter new
exports.  Making a quick scan of the DB I see, for example, about 5
different IEs each for HTTP urls, HTTP return codes, and HTTP host.


>>>> With the current IE registration structure
>>>> the absence of a public registry inevitably means the
>>>> redefinition of other than mainstream/network management
>>>> terms across a number of private registries. I thus think
>>>> it would be useful to introduce a PEN + registry for
>>>> "other applications" or introduce the concept of a series
>>>> of application specific registries with appropriate  PENs to
>>>> identify the application space rather than  the private
>>>> enterprise space.
>
> As I noted above, there's already precedent for this: PEN 29305 for
> RFC 5103.
>
> We could certainly define a few "extended application" areas, assign
> them PENs, and allocate them via IANA; we'd just need to add a PEN
> column to the registry, and update 7102. Deciding on an initial list
> might take a while though.

The idea of application PENs is interesting, but I'm not sure I see a
need at this point.  Besides, multiple application registries feels a
bit like the IE categories that existed in 5102 and no one cared to
carry forward to 7012.  As noted at the time (
http://www.ietf.org/mail-archive/web/ipfix/current/msg06621.html) as
applications move up and down layers IEs would need to be redefined.  I
would expect similar categorization issues trying to decide what
application an IE belongs to and very little upside to doing the
categorization.

A single catch all PEN for "other applications" is a little better, but
I don't really see this as much different than just having a registry
where PEN/IE details can be registered/shared.  An advantage of a
registry with various PENs would be that an experimental PEN/IE could be
"promoted" (shared) by adding it to the registry once the experimenter
is ready.

-Andrew

>
> Cheers,
>
> Brian
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


--------------020308080101010609030709
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Stewart, Brian, all,

      

      Comments inline

      

      On 01/03/2014 12:54 PM, Brian Trammell wrote:

    

    

      
      

      

        
On 03 Jan 2014, at 13:06, Stewart Bryant <stbryant@cisco.com>
          wrote:

        

        

          
          

            
 

            I brought up the concept of ownership of PENs by individuals
            

            in a couple of IESG discussions on IPFIX, and the opinion
            that

            I get (as I recall from the APPs ADs) is that PENs were
            never 

            intended to be assigned to individuals together with
            surprise

            that any had been allocated to individuals. Hence my initial
            

            reluctance. I know that there are some other owned by
            individuals, 

            and I  have requested one for the purpose of trying out this
            

            application of the protocol. However I think the concern is
            

            that it would not scale if every individual experimenter 

            requested their own, much less one per experiment.

          

        

        


        

        
It’s probably well outside the scope of IANA’s competence
          to rule on the differences between individuals, sole
          proprietorships, single member LLCs/GmbHs, C/S corporations,
          AGs/ABs/SAs, unorganized collectives of software developers,
          and so on. Without that competence, it’s pretty difficult to
          give them guidelines as to what to allow and what to deny in
          terms of individual registrations. So FCFS to anyone who can
          control an email address it is.

        


        

        
If you’re doing experiments with IPFIX (or, indeed, SNMP)
          as an individual or academic at an organization without a PEN
          or where it’s difficult to get “official” IPFIX IE number
          space within that PEN, getting your own is the only way to go.

      

    

    

    
+1

    


      

    
I assume
        that the point of the experiments is to eventually move beyond
        the experiment.  At some point a PEN will likely be needed for the
        IEs that proved useful in the experiment.  Might as well get the
        PEN and start using it.

        

      

    

      

        


        

        
Of course, I’m probably the worst abuser of this property,
          having requested the first PEN (29305) for an RFC (5103) for
          the single-record biflow hack. 

        

          

            

              
I could see this being a problem if one were trying to run many experiments within the same very large organization with undefined or draconian processes for reserving an enterprise-specific IE. But PEN space is 2^32-1 large and we haven;t even exhausted the first block of 2^16, so “get a new PEN and label it useful for a given experiment” is probably an acceptable way out of this quandary.

            

            I think the question is one of whether or not that is best
            practice.

            Sure the space is large, but so was the IPv4 Address space
            when it

            was created :)

        

        


        

        
I share your concern in theory. But practically I cannot
          imagine a world in which the number of IPFIX experiments (plus
          normal SMI “enterprises”) is anywhere near on the order of
          addressable locations in the IPv4 number space. We’re talking
          tens of PENs, hundreds if we are successful in expanding the
          IPFIX information model to be the One True Way the Internet of
          Things talks about itself.

        


        

        
I realize I’ve just made a “nobody needs more than 64k
          autonomous systems” statement. And I completely agree that
          this is somewhat outside the original intention of the PEN
          registry at its creation time, but compare this to the
          difference between the domain name space as it was conceived
          and as it’s (ab)used today, and I think what I’m proposing is
          a relatively minor violation, and is indeed not really all
          that different from the PENs-for-application-areas proposal
          (which I quite like as well).

        

          

            

              

                
For reasons that will
be clear from other work I have done in the IETF, I dislike
the idea of "camping" on code-points. This makes it clear
to me that we need a small, but not trivial set of
experimental IEs that are intended for prototyping but
explicitly excluded from use in production systems.
This needs to be a reasonable number since a new application
space might need a fair number of IEs to be practical.
Thus I think that we need to either allocate some of the
base protocol IEs to experimental, or to have IANA
allocate a PEN specifically to experimental use which
would allow experimentation in new applications spaces
without the need to formally allocate IEs in either the
base IE space, or the PEN space of the organization
(or person) conducting the experiment.


              

              
I agree in principle that allocating a single “IPFIX Experimentation” PEN would be one solution to this problem, but it would have to be fairly tightly scoped (only for experimental use among EPs and CPs implemented and deployed by a single entity within the scope of a single experiment; MUST be logged as an error by CPs in production use). And I’d be very concerned that we were basically inviting people to camp on a whole new code space — requiring experiments to use their own PEN space at least keeps experimental IEs that “leak” into production from colliding with each other, provided that the PEN owner manages their own space competently.

            

            Text of the following format needs to be associated with the

            space:

            
            
Code points in the experimental range MUST be used according to the
guidelines of RFC 3692 [RFC3692].

          

        

        
Yep, that’s good and unambiguous, but it still does not
          address the issue of what happens after the termination of the
          experiment.

        

          

            

              

                
The second problem that I see is the lack of a public registry
for non-network managements applications. Specifically
I am going to need "callsign", "maidenhead locator",
"frequency", "noise power", maybe "field strength", "receiver type"
etc. Now some of those may be of general use (frequency)
but most of them would be cruft in the base protocol IE set
which is set up for networking applications. On the other hand,
I know of at least one PEN space that will have a number of the
terms I need already defined, although these are by
definition private. 

              

            

          

        

        
s/private/not necessarily public/ — there is nothing
          keeping an operator of a PEN registry from publishing that
          registry. Indeed, the intention of RFC 5610 was to allow such
          operators to publish such registries _inline_ to allow
          polymorphic collectors / file readers to load such registries
          at runtime.

      

    

    

    In fact many PEN/IE registries have in fact been published in one
    form or an other, but I sure would love a central location with a
    parseable format.  This is not the first time that a desire for a
    central enterprise registry has been voiced (http://www.ietf.org/mail-archive/web/ipfix/current/msg05825.html).

    

    Obviously the owner of each PEN should decide which elements they
    want to publish information about and when.  Aside from making my
    life as a collector developer easier I think there are other
    advantages to a central registry.  One such advantage would be
    exposing IEs for which there is significant interest and which are
    therefore potential candidates to be standardized.

    

    I have built my own version of a central registry as I encounter new
    exports.  Making a quick scan of the DB I see, for example, about 5
    different IEs each for HTTP urls, HTTP return codes, and HTTP host.

    

    

    

      

        

          

            

              

                
With the current IE registration structure
the absence of a public registry inevitably means the
redefinition of other than mainstream/network management
terms across a number of private registries. I thus think
it would be useful to introduce a PEN + registry for
"other applications" or introduce the concept of a series
of application specific registries with appropriate  PENs to
identify the application space rather than  the private
enterprise space.

              

            

          

        

        


        

        
As I noted above, there’s already precedent for this: PEN
          29305 for RFC 5103.

        


        

        
We could certainly define a few “extended application”
          areas, assign them PENs, and allocate them via IANA; we’d just
          need to add a PEN column to the registry, and update 7102.
          Deciding on an initial list might take a while though.

      

    

    

    The idea of application PENs is interesting, but I'm not sure I see
    a need at this point.  Besides, multiple application registries
    feels a bit like the IE categories that existed in 5102 and no one
    cared to carry forward to 7012.  As noted at the time (
    
    http://www.ietf.org/mail-archive/web/ipfix/current/msg06621.html)
    as applications move up and down layers IEs would need to be
    redefined.  I would expect similar categorization issues trying to
    decide what application an IE belongs to and very little upside to
    doing the categorization.

    

    A single catch all PEN for "other applications" is a little better,
    but I don't really see this as much different than just having a
    registry where PEN/IE details can be registered/shared.  An
    advantage of a registry with various PENs would be that an
    experimental PEN/IE could be "promoted" (shared) by adding it to the
    registry once the experimenter is ready.

    

    -Andrew

    

    

      

        


        

        
Cheers,

        


        

        
Brian

      

      

      

      

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


    

    

  


--------------020308080101010609030709--

From paitken@cisco.com  Wed Jan  8 15:07:47 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27881AD8EE for ; Wed,  8 Jan 2014 15:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.038
X-Spam-Level: 
X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxqzqh7kDJ-Q for ; Wed,  8 Jan 2014 15:07:44 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 41BC51AD8ED for ; Wed,  8 Jan 2014 15:07:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2899; q=dns/txt; s=iport; t=1389222455; x=1390432055; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=MW8TdTjSA4hpXA4+s/lcc5VzTAzDMTws9UIIFtMpt80=; b=hYUITj8vanDi9cO5Uw05aAHdBOA+dwX73AYr6/nuKCzPwuuBK2Fg227z UlXgAu9pc7PQmHmUxGrd3ryy34+AlLATXkS+gre+lPzt9raKFsjtRPSDt cIHO6p2pZNUjcJZcB0kNDSzUdzIQPereV7fP7k8Fnyk7Oqgrsta/8EFoq k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFADXZzVKQ/khR/2dsb2JhbABZgws4uhaBExZ0giUBAQEDAXgGCwsEHRYPCQMCAQIBRRMIAQGHeAjETBePDBaEIQSYF4ZFi1CDLQ
X-IronPort-AV: E=Sophos;i="4.95,626,1384300800"; d="scan'208,217";a="3356854"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 08 Jan 2014 23:07:34 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s08N7XHs009247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Jan 2014 23:07:34 GMT
Received: from [10.61.98.11] (dhcp-10-61-98-11.cisco.com [10.61.98.11]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s08N7WGT000282 for ; Wed, 8 Jan 2014 23:07:33 GMT
Message-ID: <52CDDA3A.2010900@cisco.com>
Date: Wed, 08 Jan 2014 23:07:38 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: ipfix@ietf.org
References: <52C56FA7.6070905@cisco.com>  <52C6A7C6.1020703@cisco.com> <9825ADB8-DE16-4EDA-9AFA-65DC6D39696C@tik.ee.ethz.ch> <52CDB4D8.6070501@plixer.com>
In-Reply-To: <52CDB4D8.6070501@plixer.com>
Content-Type: multipart/alternative; boundary="------------040302000504080803080206"
Subject: Re: [IPFIX] Application of IPFIX to new application spaces.
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jan 2014 23:07:48 -0000

This is a multi-part message in MIME format.
--------------040302000504080803080206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

PEN/IE registri

> I assume that the point of the experiments is to eventually move 
> beyond the experiment.  At some point a PEN will likely be needed for 
> the IEs that proved useful in the experiment.  Might as well get the 
> PEN and start using it.

Or, at some point the experiemental IEs should be standardised through 
IANA / IE-doctors.


> I have built my own version of a central registry as I encounter new 
> exports.  Making a quick scan of the DB I see, for example, about 5 
> different IEs each for HTTP urls, HTTP return codes, and HTTP host.

The problem is that once you have your own PEN, there's no incentive to 
transition your private IEs into standard IEs.

A PEN/IE registry could be a good way for IE-doctors to discover useful 
/ duplicate IEs, and create standard versions for general consumption.

P.


--------------040302000504080803080206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
PEN/IE registri

      

    

    

      
      
I assume
          that the point of the experiments is to eventually move beyond
          the experiment.  At some point a PEN will likely be needed for
          the IEs that proved useful in the experiment.  Might as well
          get the PEN and start using it.

        

    

    

    Or, at some
      point the experiemental IEs should be standardised through IANA /
      IE-doctors.

      

      

    
    
 I
      have built my own version of a central registry as I encounter new
      exports.  Making a quick scan of the DB I see, for example, about
      5 different IEs each for HTTP urls, HTTP return codes, and HTTP
      host.

    

    

    The problem is that once you have your own PEN, there's no incentive
    to transition your private IEs into standard IEs.

    

    A PEN/IE registry could be a good way for IE-doctors to discover
    useful / duplicate IEs, and create standard versions for general
    consumption.

    

    P.

    

  


--------------040302000504080803080206--

From bclaise@cisco.com  Fri Jan 10 04:56:30 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4406B1ADFFC for ; Fri, 10 Jan 2014 04:56:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.039
X-Spam-Level: 
X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcl0r_rkG2rc for ; Fri, 10 Jan 2014 04:56:29 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id E184F1ADFFB for ; Fri, 10 Jan 2014 04:56:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1079; q=dns/txt; s=iport; t=1389358579; x=1390568179; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=ri3LHqS9T3QBmtiXOj2MwRJqr3Ew7HWt/dPT0rKESB8=; b=CMRR9MSHjAyQvoX3RnP9tI0/NRyDbhuyITaUyZTYcD/HbTGGWU0IRaTf zfYGTdtul5KSmz6gDLJfNQpjIqm61uXg42Hy2KCYeG6IXUUzEOV3649jl P+5Tx0rbiBKTjHE3MdUXo1eivVp8tQ3S7ksa7s7K3xf+j+pONLLpITCDq s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EADbtz1KQ/khN/2dsb2JhbABZgwu7WxZ0gmRAPRYEFAMCAQIBSw0IAQGIAJkBqhQXk0YEmBeGRYtQgW+BPzs
X-IronPort-AV: E=Sophos;i="4.95,638,1384300800";  d="scan'208";a="3443542"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 10 Jan 2014 12:56:18 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0ACuILI030650 for ; Fri, 10 Jan 2014 12:56:18 GMT
Message-ID: <52CFEDF2.9030003@cisco.com>
Date: Fri, 10 Jan 2014 13:56:18 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "ipfix@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] Textual Representation of IPFIX Abstract Data Types (draft-trammell-ipfix-text-adt) as a WG document.
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jan 2014 12:56:30 -0000

Dear all,

The draft-trammell-ipfix-tcpcontrolbits-revision-05 went through the 
IESG, and was approved.
However, there were some IESG questions/push backs related to the AD 
sponsoring of this draft while the WG was still open.
At the time of taking that decision, I was evaluating the process of 
rechartering versus the estimated time for finishing up the last 
chartered item.

Anyway, we now have a similar case with the Textual Representation of 
IPFIX Abstract Data Types (draft-trammell-ipfix-text-adt).
Granted, the procedure would be cleaner if this draft would be run 
through the IPFIX WG, specifically because draft-trammell-ipfix-text-adt 
can be considered IPFIX core (as opposed to 
draft-trammell-ipfix-tcpcontrolbits-revision that is information 
elements related).
This draft "could" fit in the existing charter, under point 2. So no 
rechartering would be necessary.

In discussion with the IPFIX chairs, we propose to adopt 
draft-trammell-ipfix-text-adt as a WG document right now, and to start 
the WGLC.

Regards, Benoit (OPS AD)



From paitken@cisco.com  Fri Jan 10 05:55:09 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE281AE062 for ; Fri, 10 Jan 2014 05:55:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.038
X-Spam-Level: 
X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6TPteNDhr16 for ; Fri, 10 Jan 2014 05:55:06 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id E22CE1AE05C for ; Fri, 10 Jan 2014 05:55:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4765; q=dns/txt; s=iport; t=1389362096; x=1390571696; h=message-id:date:from:mime-version:to:subject; bh=Vr2sNdaY1Mh3HJbnvHInKpj+NtkHheFuplXE3PpuIQw=; b=iaPostAXtFMr8K2jVfECpXht9JVt9hVkWypbcg1r0iSpC2U+awf6YXW5 8pfps8NAo4Sj+5f30jWIAd8vBYZDFSb2nYH4+/cyhEjxEG/JED45xDpax Hasig3oiweTSKN1/tfoeYRB7W2tYesyGwoU7Xd4AphRVVbJ0QMeutIJWk k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAFb6z1KQ/khM/2dsb2JhbABZgws4uyMWdIMkIB0WGAMCAQIBSw0IAQGIAA2YdqoUF5NGBJgXgTCFFYtQgy0
X-IronPort-AV: E=Sophos;i="4.95,638,1384300800"; d="scan'208,217";a="3446151"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 10 Jan 2014 13:54:55 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0ADsssT005052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Jan 2014 13:54:55 GMT
Received: from [10.61.100.1] (dhcp-10-61-100-1.cisco.com [10.61.100.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0ADsroY022166 for ; Fri, 10 Jan 2014 13:54:54 GMT
Message-ID: <52CFFBC8.1020207@cisco.com>
Date: Fri, 10 Jan 2014 13:55:20 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: IETF IPFIX Working Group 
Content-Type: multipart/alternative; boundary="------------090205090301040904010808"
Subject: [IPFIX] updated IPFIX drafts
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jan 2014 13:55:09 -0000

This is a multi-part message in MIME format.
--------------090205090301040904010808
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I updated two drafts during the holidays:


http://tools.ietf.org/html/draft-aitken-ipfix-unobserved-fields-02

         The IPFIX protocol is designed to export information about
         observations, and lacks a method for reporting that observations
         are unavailable. This document discusses several methods for
         reporting when fields are unavailable, reviews the advantages
         and disadvantage of each, and recommends methods which should be
         used.


This is a huge hole in IPFIX which we cannot ignore.

eg
     * how can you report that although you observed 1,000 packets, none 
of them contained an IPv4 source address?
     * how can you report the 15-minute average in the (t < 15mins) 
interval ?

Cisco is already using several of the techniques in this draft.


     http://tools.ietf.org/html/draft-aitken-ipfix-equivalent-ies-01

       This document specifies a method for an
       IPFIX Exporting Process to inform an IPFIX Collecting Process
       of equivalence between different Information Elements, so
       that the Collecting Process can understand the equivalence
       and be enabled to process data across a change of
       Information Elements.


This draft provides a mechanism for exporters to migrate from 
enterprise-specific elements to IANA-standard elements with minimal 
collector impact.

Andrew Feren and I identified a surprisingly large list of existing 
duplicate Information Elements to which this draft applies, thus the update.

P.

--------------090205090301040904010808
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    
    I updated two drafts during the holidays:

    

    

       
    http://tools.ietf.org/html/draft-aitken-ipfix-unobserved-fields-02

    

            The IPFIX protocol is designed to export information about

            observations, and lacks a method for reporting that
    observations

            are unavailable. This document discusses several methods for

            reporting when fields are unavailable, reviews the
    advantages

            and disadvantage of each, and recommends methods which
    should be

            used.

    

    

    This is a huge hole in IPFIX which we cannot ignore.

    

    eg

        * how can you report that although you observed 1,000 packets,
    none of them contained an IPv4 source address?

        * how can you report the 15-minute average in the (t <
    15mins) interval ?

    

    Cisco is already using several of the techniques in this draft.

    

    

        http://tools.ietf.org/html/draft-aitken-ipfix-equivalent-ies-01

    

          This document specifies a method for an

          IPFIX Exporting Process to inform an IPFIX Collecting Process

          of equivalence between different Information Elements, so

          that the Collecting Process can understand the equivalence

          and be enabled to process data across a change of

          Information Elements.

    
    

    

    This draft provides a mechanism for exporters to migrate from
    enterprise-specific elements to IANA-standard elements with minimal
    collector impact.

    

    Andrew Feren and I identified a surprisingly large list of existing
    duplicate Information Elements to which this draft applies, thus the
    update.

    

    P.

  


--------------090205090301040904010808--

From bclaise@cisco.com  Mon Jan 13 07:08:34 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470521AE174 for ; Mon, 13 Jan 2014 07:08:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.038
X-Spam-Level: 
X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEa5EajyfIk3 for ; Mon, 13 Jan 2014 07:08:20 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA1F1ADFB6 for ; Mon, 13 Jan 2014 07:08:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34868; q=dns/txt; s=iport; t=1389625688; x=1390835288; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=MOL4KVPNwlTpDQQuG2zlNOdx8i4ZhflBW68MrCoVpTI=; b=Mm7TwdB8CO4ApXwHYqhORot2Apb2CSHPUo7vcpw97cIX8jtn13Am5Rl7 valJ+oOf+CntQ0lUosKywYGIJ/RT5JrjaiwH0hpBv2W4Mp8uVM9sm18Em 3kArpqJVshdjAOPkxnM14yjCaY7XVEwkSlByrd21+7USYQpr5AZjAmThD 4=;
X-IronPort-AV: E=Sophos;i="4.95,653,1384300800"; d="scan'208,217";a="3568779"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 13 Jan 2014 15:08:07 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0DF86de006647; Mon, 13 Jan 2014 15:08:06 GMT
Message-ID: <52D40156.400@cisco.com>
Date: Mon, 13 Jan 2014 16:08:06 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: stbryant@cisco.com, Brian Trammell 
References: <20131230151331.29E9F7FC393@rfc-editor.org> <52C19DF7.4050501@plixer.com> <52C232EB.30802@cisco.com>, <535E38C8-A1C0-4FD5-991C-D9A132D97923@tik.ee.ethz.ch> <0BEF0D66-E9DB-40E7-A2E4-ABCBCA5634CB@cisco.com> <52C2BC12.6090108@tik.ee.ethz.ch> <52C55358.5060402@cisco.com>  <52C6A8F9.7070706@cisco.com>  <52C6E376.2060304@cisco.com>
In-Reply-To: <52C6E376.2060304@cisco.com>
Content-Type: multipart/alternative; boundary="------------070204060904090405040700"
Cc: "joelja@bogus.com Jaeggli" , Nevil Brownlee , "ipfix@ietf.org Group" , RFC Errata System 
Subject: Re: [IPFIX] [Technical Errata Reported] RFC7012 (3852)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Jan 2014 15:08:34 -0000

This is a multi-part message in MIME format.
--------------070204060904090405040700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Brian, Stewart,

Can you please let me know what's the latest conclusion on this errata, 
and update the errata accordingly.

Regards, Benoit
> On 03/01/2014 15:39, Brian Trammell wrote:
>> Hi Stewart,
>>
>> On 03 Jan 2014, at 13:11, Stewart Bryant > > wrote:
>>
>>>>
>>>> So each instance of an IE of an ADT can take a value, and that 
>>>> value exists separate from its encoding. 7011 and 7012 together 
>>>> combine to make an unambiguous mapping between the two possible in 
>>>> IPFIX.
>>>
>>> I think the key is the last sentence, and so long as we make that 
>>> clear we are good.
>>>
>>> Maybe some text of the form "relative to the defined epoch" would 
>>> sort it out. At least
>>> that would remind the reader that they needs to know rather than 
>>> assume the epoch.
>>
>> This may seem like a tiny little nit to pick, but we thought a _whole 
>> lot_ about this when moving the epochs out of 5102bis, and I still 
>> think the reasons therefor are valid. I'd ask you to reconsider 
>> insisting on timestamps as relative to a fixed epoch. I'd rather 
>> state instead something like "it is the responsibility of the 
>> encoding to ensure that each representation has an unambiguous 
>> mapping to a moment in time (e.g. relative to a defined epoch)."
>
> If you are proposing that text, that would work for me.
>>
>> Otherwise we go down the calendar rathole very, very quickly, and 
>> we've tried very hard not to do that. Indeed, one can define any time 
>> representation as relative to some epoch, more or less fuzzily. 
>> However, back to our ISO 8601 example, one can indeed interpret 
>> "2014-01-03 10:00:00 UTC" as a fixed number of years, months, days, 
>> hours, and so on from the implicit epoch 0001-01-01 00:00:00 UTC. One 
>> would be wrong, given variability in Julian-Gregorian calendar 
>> transitions, policies for accounting/ignoring leap seconds, and all 
>> those other assumptions one has to make when turning a human-readable 
>> timestamp (our "ideal" value) to some notion of the moment in time it 
>> references.
>>
>> I submit that these differences are largely irrelevant on the 
>> timescales and for the types of comparisons in event timing --- 
>> whether network management related or not --- that the IPFIX 
>> information model is likely to be applied to. But if we bake 
>> fixed-epoch references into the information model we're forced to 
>> care about them regardless.
> No, I am fine with the IM not baking in the epoch, now I understand 
> the approach, and the with the other changes that tell the reader that 
> they moved. However, I think you do need to help the reader understand 
> the importance of understanding the of the epoch (and now you remind 
> me the discontinuities). The above sentence will do this.
>
> Stewart
>
>>
>> Thanks, cheers,
>>
>> Brian
>>
>>>>> We may need a call to work though this and another issue
>>>>> I am about to raise on the IPFIX list.
>>>>>
>>>>> - Stewart
>>>>>
>>>>> On 31/12/2013 12:44, Brian Trammell wrote:
>>>>>> hi Stewart,
>>>>>>
>>>>>> Stewart Bryant (stbryant) wrote:
>>>>>>> Certainly something is needed. I was thinking of using IPFIX as an information gathering method in a radio context, and went to look at the definition of the types and could not find the epoch, or even a reference to the epoch. Now part of the problem (which was my fault) was that I did not notice at the time that the elements were defined by the obsolete RFC5102 and went straight to the new RFC. However having the definitions in an obsolete RFC also seems problematic, since it puts the IEs in a strange state. Since RFC 7012 replaces RFC5102 and includes the definitions you would expect the definition in RFC7012 to replace the definition in RFC5102, but those definitions are, as I explained incomplete.
>>>>>> This is intentional. See below.
>>>>>>
>>>>>>> I need to look at this some more when I get back to work, but I am now also concerned that if the epoch can change, the definition of the existing IEs is now unreliable.
>>>>>> The definition of the existing IEs is based upon the definition of the
>>>>>> ADT itself in 7012 as well as the definition of the ADT representation
>>>>>> within the IPFIX protocol in 7011. It is not the intention that reading
>>>>>> 7012 tells you how to encode IEs for use with IPFIX; that's what section
>>>>>> 6.1 of 7011 is for.
>>>>>>
>>>>>>> You will notice in the errata that I did suggest that an alternative resolution would be to include a reference to the epoch text.
>>>>>> The point is that the ADT _explicitly_ does not have a binding to an
>>>>>> epoch, as epochs are only necessary when using integral representations
>>>>>> of timestamps. IPFIX's representations for these ADTs are integral, but
>>>>>> bindings to other representations need not be (see, for example,
>>>>>> draft-trammell-ipfix-text-adt, which recommends ISO8601-style timestamps
>>>>>> for textual representations of IE values).
>>>>>>
>>>>>> I'd suggest instead somehow expanding the present text in 7012 to
>>>>>> reiterate that if you're using IPFIX, the representations of the ADTs
>>>>>> are in 7011:
>>>>>>
>>>>>> OLD para 2 sec 3.1 7012:
>>>>>>
>>>>>>     The current encodings of these data types for use with the IPFIX
>>>>>>     protocol are defined in [RFC7011]; encodings allowing the use of the
>>>>>>     IPFIX Information Elements [IANA-IPFIX] with other protocols may be
>>>>>>     defined in the future by referencing this document.
>>>>>>
>>>>>> NEW para 2 sec 3.1 7012:
>>>>>>
>>>>>>     The abstract data type definitions in this section are intended
>>>>>>     only to define the values which can be taken by Information
>>>>>>     Elements of each type. The encodings of these data types for
>>>>>>     use with the IPFIX protocol are defined in Section 6.1 of
>>>>>>     [RFC7011]; encodings  allowing the use of the IPFIX Information
>>>>>>     Elements [IANA-IPFIX] with other protocols may be defined in the
>>>>>>     future by referencing this document.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>>
>>>>>>> Stewart
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sent from my iPad
>>>>>>>
>>>>>>>> On 31 Dec 2013, at 08:50, "Brian Trammell"  wrote:
>>>>>>>>
>>>>>>>> hi Paul, all,
>>>>>>>>
>>>>>>>> +n.
>>>>>>>>
>>>>>>>> The separation between ADTs and ADT encoding between 7012 and 7011 was explicit and purposeful. Specifically, we do _not_ want to exclude other representations of the IPFIX Information Model from being based upon other encodings of these ADTs, whether ISO 8601 (which either has no epoch or epoch 0000-00-00 00:00 UTC, depending on how you count), NTP (1904), Julian day based counting, etc, etc, etc...
>>>>>>>>
>>>>>>>> If there is confusion on this point, I'd suggest adding more explanatory text on this point to Paragraph 2 of the front matter to section 3.1. But as is, I emphatically recommend rejection of this reported erratum.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Brian
>>>>>>>>
>>>>>>>>> On 31 Dec 2013, at 03:58, Paul Aitken  wrote:
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> If anyone was going to raise an errata on this, it would have been me ;-)
>>>>>>>>>
>>>>>>>>> I've pointed this issue out before, probably more than once - and have been encouraged to read RFC 3444.
>>>>>>>>>
>>>>>>>>> P.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 30/12/2013 09:23, Andrew Feren wrote:
>>>>>>>>>> The encoding for the time data types is specified RFC 7011 Sections
>>>>>>>>>> 6.1.7 through 6.1.10.
>>>>>>>>>>
>>>>>>>>>> -Andrew
>>>>>>>>>>
>>>>>>>>>>> On 12/30/2013 10:13 AM, RFC Errata System wrote:
>>>>>>>>>>> The following errata report has been submitted for RFC7012,
>>>>>>>>>>> "Information Model for IP Flow Information Export (IPFIX)".
>>>>>>>>>>>
>>>>>>>>>>> --------------------------------------
>>>>>>>>>>> You may review the report below and at:
>>>>>>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=7012&eid=3852
>>>>>>>>>>>
>>>>>>>>>>> --------------------------------------
>>>>>>>>>>> Type: Technical
>>>>>>>>>>> Reported by: Stewart Bryant
>>>>>>>>>>>
>>>>>>>>>>> Section: 3.1.15-17
>>>>>>>>>>>
>>>>>>>>>>> Original Text
>>>>>>>>>>> -------------
>>>>>>>>>>> 3.1.15. dateTimeSeconds
>>>>>>>>>>>
>>>>>>>>>>>    The type "dateTimeSeconds" represents a time value expressed with
>>>>>>>>>>>    second-level precision.
>>>>>>>>>>>
>>>>>>>>>>> 3.1.16. dateTimeMilliseconds
>>>>>>>>>>>
>>>>>>>>>>>    The type "dateTimeMilliseconds" represents a time value expressed
>>>>>>>>>>>    with millisecond-level precision.
>>>>>>>>>>>
>>>>>>>>>>> 3.1.17. dateTimeMicroseconds
>>>>>>>>>>>
>>>>>>>>>>>    The type "dateTimeMicroseconds" represents a time value expressed
>>>>>>>>>>>    with microsecond-level precision.
>>>>>>>>>>>
>>>>>>>>>>> 3.1.18. dateTimeNanoseconds
>>>>>>>>>>>
>>>>>>>>>>>    The type "dateTimeNanoseconds" represents a time value expressed with
>>>>>>>>>>>    nanosecond-level precision.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Corrected Text
>>>>>>>>>>> --------------
>>>>>>>>>>> 3.1.15. dateTimeSeconds
>>>>>>>>>>>
>>>>>>>>>>>    The type "dateTimeSeconds" represents a time value in units of
>>>>>>>>>>>    seconds based on coordinated universal time (UTC).  The choice of an
>>>>>>>>>>>    epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>>>>>>>>>>    corresponding encoding specifications for this type, for example, the
>>>>>>>>>>>    IPFIX protocol specification.  Leap seconds are excluded.  Note that
>>>>>>>>>>>    transformation of values might be required between different
>>>>>>>>>>>    encodings if different epoch values are used.
>>>>>>>>>>>
>>>>>>>>>>> 3.1.16. dateTimeMilliseconds
>>>>>>>>>>>
>>>>>>>>>>>    The type "dateTimeMilliseconds" represents a time value in units of
>>>>>>>>>>>    milliseconds based on coordinated universal time (UTC).  The choice
>>>>>>>>>>>    of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>>>>>>>>>>    corresponding encoding specifications for this type, for example, the
>>>>>>>>>>>    IPFIX protocol specification.  Leap seconds are excluded.  Note that
>>>>>>>>>>>    transformation of values might be required between different
>>>>>>>>>>>    encodings if different epoch values are used.
>>>>>>>>>>>
>>>>>>>>>>> 3.1.17. dateTimeMicroseconds
>>>>>>>>>>>
>>>>>>>>>>>    The type "dateTimeMicroseconds" represents a time value in units of
>>>>>>>>>>>    microseconds based on coordinated universal time (UTC).  The choice
>>>>>>>>>>>    of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>>>>>>>>>>    corresponding encoding specifications for this type, for example, the
>>>>>>>>>>>    IPFIX protocol specification.  Leap seconds are excluded.  Note that
>>>>>>>>>>>    transformation of values might be required between different
>>>>>>>>>>>    encodings if different epoch values are used.
>>>>>>>>>>>
>>>>>>>>>>> 3.1.18. dateTimeNanoseconds
>>>>>>>>>>>
>>>>>>>>>>>    The type "dateTimeNanoseconds" represents a time value in units of
>>>>>>>>>>>    nanoseconds based on coordinated universal time (UTC).  The choice of
>>>>>>>>>>>    an epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>>>>>>>>>>    corresponding encoding specifications for this type, for example, the
>>>>>>>>>>>    IPFIX protocol specification.  Leap seconds are excluded.  Note that
>>>>>>>>>>>    transformation of values might be required between different
>>>>>>>>>>>    encodings if different epoch values are used.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Notes
>>>>>>>>>>> -----
>>>>>>>>>>> Although section 1.1 says : - "Definitions of timestamp data types have been clarified." The edited text has removed the epoch definition, and this does not seem to have been incorporated elsewhere in the RFC.
>>>>>>>>>>>
>>>>>>>>>>> Without a specified epoch, there is no unique definition of the timestamps.
>>>>>>>>>>>
>>>>>>>>>>> My proposal above is to revert to the RFC5102 definitions. RFC7102 is intended to be backwards compatible with RFC5102 and thus the definitions need to be technically identical. Alternatively, if the text is now included elsewhere in RFC7012 or in another RFC, it would be helpful to the reader to provide a reference to the epoch definition in an editorial update to dateTimeX definitions in RFC7102.
>>>>>>>>>>>
>>>>>>>>>>> Instructions:
>>>>>>>>>>> -------------
>>>>>>>>>>> This errata is currently posted as "Reported". If necessary, please
>>>>>>>>>>> use "Reply All" to discuss whether it should be verified or
>>>>>>>>>>> rejected. When a decision is reached, the verifying party (IESG)
>>>>>>>>>>> can log in to change the status and edit the report, if necessary.
>>>>>>>>>>>
>>>>>>>>>>> --------------------------------------
>>>>>>>>>>> RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10)
>>>>>>>>>>> --------------------------------------
>>>>>>>>>>> Title               : Information Model for IP Flow Information Export (IPFIX)
>>>>>>>>>>> Publication Date    : September 2013
>>>>>>>>>>> Author(s)           : B. Claise, Ed., B. Trammell, Ed.
>>>>>>>>>>> Category            : PROPOSED STANDARD
>>>>>>>>>>> Source              : IP Flow Information Export
>>>>>>>>>>> Area                : Operations and Management
>>>>>>>>>>> Stream              : IETF
>>>>>>>>>>> Verifying Party     : IESG
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> IPFIX mailing list
>>>>>>>>>>> IPFIX@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>>> _______________________________________________
>>>>>>>>>> IPFIX mailing list
>>>>>>>>>> IPFIX@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>> _______________________________________________
>>>>>>>> IPFIX mailing list
>>>>>>>> IPFIX@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>>
>>>>>
>>>>> -- 
>>>>> For corporate legal information go to:
>>>>>
>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>>>>
>>>>
>>>
>>>
>>> -- 
>>> For corporate legal information go to:
>>>
>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>>
>>
>
>
> -- 
> For corporate legal information go to:
>
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


--------------070204060904090405040700
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Brian, Stewart,

      

      Can you please let me know what's the latest conclusion on this
      errata, and update the errata accordingly.

      

      Regards, Benoit

    

    

      
      
On 03/01/2014 15:39, Brian Trammell
        wrote:

      

      
 Hi Stewart,
        


        

        

          

            
On 03 Jan 2014, at 13:11, Stewart Bryant <stbryant@cisco.com>

              wrote:

            

            

              

                

                  

                    

                      


                      

                      
So each instance of an IE of an ADT can take
                        a value, and that value exists separate from its
                        encoding. 7011 and 7012 together combine to make
                        an unambiguous mapping between the two possible
                        in IPFIX.

                    

                  

                

                

                I think the key is the last sentence, and so long as we
                make that clear we are good.

                

                Maybe some text of the form "relative to the defined
                epoch" would sort it out. At least

                that would remind the reader that they needs to know
                rather than assume the epoch.

              

            

            


            

            
This may seem like a tiny little nit to pick, but we
              thought a _whole lot_ about this when moving the epochs
              out of 5102bis, and I still think the reasons therefor are
              valid. I’d ask you to reconsider insisting on timestamps
              as relative to a fixed epoch. I’d rather state instead
              something like "it is the responsibility of the encoding
              to ensure that each representation has an unambiguous
              mapping to a moment in time (e.g. relative to a defined
              epoch)."

          

        

      

      

      If you are proposing that text, that would work for me. 

      

        

          

            


            

            
Otherwise we go down the calendar rathole very, very
              quickly, and we’ve tried very hard not to do that. Indeed,
              one can define any time representation as relative to some
              epoch, more or less fuzzily. However, back to our ISO 8601
              example, one can indeed interpret “2014-01-03 10:00:00
              UTC” as a fixed number of years, months, days, hours, and
              so on from the implicit epoch 0001-01-01 00:00:00 UTC. One
              would be wrong, given variability in Julian-Gregorian
              calendar transitions, policies for accounting/ignoring
              leap seconds, and all those other assumptions one has to
              make when turning a human-readable timestamp (our “ideal”
              value) to some notion of the moment in time it references.

            


            

            
I submit that these differences are largely irrelevant
              on the timescales and for the types of comparisons in
              event timing — whether network management related or not —
              that the IPFIX information model is likely to be applied
              to. But if we bake fixed-epoch references into the
              information model we’re forced to care about them
              regardless.

          

        

      

      No, I am fine with the IM not baking in the epoch, now I
      understand the approach, and the with the other changes that tell
      the reader that they moved. However, I think you do need to help
      the reader understand the importance of understanding the of the
      epoch (and now you remind me the discontinuities). The above
      sentence will do this.

      

      Stewart

      

      

        

          

            


            

            
Thanks, cheers,

            


            

            
Brian

            


            

            

              

                

                  

                    

                      

                        

                          

                            
We may need a call to work though this and another issue
I am about to raise on the IPFIX list.

- Stewart



                            On 31/12/2013 12:44, Brian Trammell wrote:

                          

                          

                            
hi Stewart,

Stewart Bryant (stbryant) wrote:


                            

                              
Certainly something is needed. I was thinking of using IPFIX as an information gathering method in a radio context, and went to look at the definition of the types and could not find the epoch, or even a reference to the epoch. Now part of the problem (which was my fault) was that I did not notice at the time that the elements were defined by the obsolete RFC5102 and went straight to the new RFC. However having the definitions in an obsolete RFC also seems problematic, since it puts the IEs in a strange state. Since RFC 7012 replaces RFC5102 and includes the definitions you would expect the definition in RFC7012 to replace the definition in RFC5102, but those definitions are, as I explained incomplete.


                            

                            
This is intentional. See below.



                            

                              
I need to look at this some more when I get back to work, but I am now also concerned that if the epoch can change, the definition of the existing IEs is now unreliable.


                            

                            
The definition of the existing IEs is based upon the definition of the
ADT itself in 7012 as well as the definition of the ADT representation
within the IPFIX protocol in 7011. It is not the intention that reading
7012 tells you how to encode IEs for use with IPFIX; that's what section
6.1 of 7011 is for.



                            

                              
You will notice in the errata that I did suggest that an alternative resolution would be to include a reference to the epoch text.


                            

                            
The point is that the ADT _explicitly_ does not have a binding to an
epoch, as epochs are only necessary when using integral representations
of timestamps. IPFIX's representations for these ADTs are integral, but
bindings to other representations need not be (see, for example,
draft-trammell-ipfix-text-adt, which recommends ISO8601-style timestamps
for textual representations of IE values).

I'd suggest instead somehow expanding the present text in 7012 to
reiterate that if you're using IPFIX, the representations of the ADTs
are in 7011:

OLD para 2 sec 3.1 7012:

   The current encodings of these data types for use with the IPFIX
   protocol are defined in [RFC7011]; encodings allowing the use of the
   IPFIX Information Elements [IANA-IPFIX] with other protocols may be
   defined in the future by referencing this document.

NEW para 2 sec 3.1 7012:

   The abstract data type definitions in this section are intended
   only to define the values which can be taken by Information
   Elements of each type. The encodings of these data types for
   use with the IPFIX protocol are defined in Section 6.1 of
   [RFC7011]; encodings  allowing the use of the IPFIX Information
   Elements [IANA-IPFIX] with other protocols may be defined in the
   future by referencing this document.

Best regards,

Brian




                            

                              
Stewart



Sent from my iPad



                              

                                
On 31 Dec 2013, at 08:50, "Brian Trammell" <trammell@tik.ee.ethz.ch> wrote:

hi Paul, all,

+n.

The separation between ADTs and ADT encoding between 7012 and 7011 was explicit and purposeful. Specifically, we do _not_ want to exclude other representations of the IPFIX Information Model from being based upon other encodings of these ADTs, whether ISO 8601 (which either has no epoch or epoch 0000-00-00 00:00 UTC, depending on how you count), NTP (1904), Julian day based counting, etc, etc, etc…

If there is confusion on this point, I’d suggest adding more explanatory text on this point to Paragraph 2 of the front matter to section 3.1. But as is, I emphatically recommend rejection of this reported erratum.

Best regards,

Brian



                                

                                  
On 31 Dec 2013, at 03:58, Paul Aitken <paitken@cisco.com> wrote:

+1

If anyone was going to raise an errata on this, it would have been me ;-)

I've pointed this issue out before, probably more than once - and have been encouraged to read RFC 3444.

P.




                                  

                                    
On 30/12/2013 09:23, Andrew Feren wrote:
The encoding for the time data types is specified RFC 7011 Sections
6.1.7 through 6.1.10.

-Andrew



                                    

                                      
On 12/30/2013 10:13 AM, RFC Errata System wrote:
The following errata report has been submitted for RFC7012,
"Information Model for IP Flow Information Export (IPFIX)".

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

--------------------------------------
Type: Technical
Reported by: Stewart Bryant <stbryant@cisco.com>

Section: 3.1.15-17

Original Text
-------------
3.1.15. dateTimeSeconds

  The type "dateTimeSeconds" represents a time value expressed with
  second-level precision.

3.1.16. dateTimeMilliseconds

  The type "dateTimeMilliseconds" represents a time value expressed
  with millisecond-level precision.

3.1.17. dateTimeMicroseconds

  The type "dateTimeMicroseconds" represents a time value expressed
  with microsecond-level precision.

3.1.18. dateTimeNanoseconds

  The type "dateTimeNanoseconds" represents a time value expressed with
  nanosecond-level precision.


Corrected Text
--------------
3.1.15. dateTimeSeconds

  The type "dateTimeSeconds" represents a time value in units of
  seconds based on coordinated universal time (UTC).  The choice of an
  epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.16. dateTimeMilliseconds

  The type "dateTimeMilliseconds" represents a time value in units of
  milliseconds based on coordinated universal time (UTC).  The choice
  of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.17. dateTimeMicroseconds

  The type "dateTimeMicroseconds" represents a time value in units of
  microseconds based on coordinated universal time (UTC).  The choice
  of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.

3.1.18. dateTimeNanoseconds

  The type "dateTimeNanoseconds" represents a time value in units of
  nanoseconds based on coordinated universal time (UTC).  The choice of
  an epoch, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, for example, the
  IPFIX protocol specification.  Leap seconds are excluded.  Note that
  transformation of values might be required between different
  encodings if different epoch values are used.


Notes
-----
Although section 1.1 says : - "Definitions of timestamp data types have been clarified." The edited text has removed the epoch definition, and this does not seem to have been incorporated elsewhere in the RFC.

Without a specified epoch, there is no unique definition of the timestamps.

My proposal above is to revert to the RFC5102 definitions. RFC7102 is intended to be backwards compatible with RFC5102 and thus the definitions need to be technically identical. Alternatively, if the text is now included elsewhere in RFC7012 or in another RFC, it would be helpful to the reader to provide a reference to the epoch definition in an editorial update to dateTimeX definitions in RFC7102.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10)
--------------------------------------
Title               : Information Model for IP Flow Information Export (IPFIX)
Publication Date    : September 2013
Author(s)           : B. Claise, Ed., B. Trammell, Ed.
Category            : PROPOSED STANDARD
Source              : IP Flow Information Export
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


                                    

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


                                  

                                

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


                              

                            

                          

                          

                          

                          
-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html



                        

                      

                    

                    

                  

                

                

                

                
-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html



              

            

          

          

        

      

      

      

      
-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html



      

      

      

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


    

    

  


--------------070204060904090405040700--

From trammell@tik.ee.ethz.ch  Wed Jan 15 08:36:12 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22FD1AE136 for ; Wed, 15 Jan 2014 08:36:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level: 
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnUziLrYgneJ for ; Wed, 15 Jan 2014 08:36:10 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1018F1AE0EE for ; Wed, 15 Jan 2014 08:36:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D7E1CD930B; Wed, 15 Jan 2014 17:35:57 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ecarBevjqKrb; Wed, 15 Jan 2014 17:35:57 +0100 (MET)
Received: from Zephyr.local (4-172.2-85.cust.bluewin.ch [85.2.172.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 719E7D9303; Wed, 15 Jan 2014 17:35:57 +0100 (MET)
Message-ID: <52D6B8EA.3060604@tik.ee.ethz.ch>
Date: Wed, 15 Jan 2014 17:35:54 +0100
From: Brian Trammell 
User-Agent: Postbox 3.0.8 (Macintosh/20130427)
MIME-Version: 1.0
To: nmrg@irtf.org, "ipfix@ietf.org Group" 
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigCC77DE20EB0EB1BE405ED4DB"
Subject: [IPFIX] TRAC 2014 deadline extension
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jan 2014 16:36:12 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCC77DE20EB0EB1BE405ED4DB
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Greetings, all.

Apologies if you've received multiple copies of this message. The
submission deadline for TRAC 2014 (http://trac2014.ftw.at/) has been
extended till the 31st of January 2014; please see the CFP below.

Cheers,

Brian

-------------------------------------------------------------------------=
-----
CALL FOR PAPERS

TRAC 2014 -- 5th International Workshop on TRaffic Analysis and
Characterization
Technically Sponsored by IEEE and FP7 mPlane
August 4-8 2014
Nicosia, CYPRUS
http://trac2014.ftw.at/


SCOPE

The continued evolution of the Internet is characterized by dramatic
changes in the way users behave, interact with and use the network.
Today's Internet content and applications are increasingly delivered by
ever larger content delivery networks (CDNs) and cloud infrastructures.

Other changes in the Internet, such as the explosion of mobile traffic
and the growing deployment of encryption (e.g. HTTPS Everywhere) demand
new approaches for characterizing and analyzing network traffic.
Malicious and abusive traffic continues to evolve as well, and
techniques for detection must evolve in kind.

The fifth edition of the TRAC workshop continues to serve as a forum for
scientists and engineers in academia and industry to exchange and
discuss their experiences and research results about all aspects of
traffic classification, characterization, and analysis.


TOPICS

The workshop is soliciting high quality papers discussing original and
innovative experimental activities, unpublished and not currently
submitted for publication elsewhere, on topics including (but not
limited) to the following:

* Traffic analysis and characterization algorithms and techniques
* Detection, analysis, and classification of network anomalies
* Platforms for on-line, real-time traffic analysis and characterization
* Evaluation of traffic classification and analysis techniques
* Data-reduction techniques for traffic analysis and visualization
* Privacy-preservation in traffic analysis, classification, and
characterization
* Effects of anonymization on traffic analysis, classification, and
characterization
* Identification and classification of encrypted traffic
* Advanced algorithms for deep packet inspection
* Post-DPI approaches for traffic classification
* Applications of traffic analysis to network security
* Traffic analysis studies on operational networks and large-scale
traffic data sets
* Applications of traffic analysis to network operations and management
* Ultra-high rate (10 - 100Gbit) traffic analysis, classification, and
characterization
* Analysis and characterization of mobile and wireless traffic
* Forwarding-plane support for network measurement and analysis


SUBMISSIONS

Prospective authors are invited to submit their papers using the EDAS
system.
Submitted papers must be no longer than six (6) IEEE style pages
including results, figures and references. Papers will be reviewed by
the standard reviewing procedure.
Accepted papers will be published on the IEEE Xplore Digital Library


IMPORTANT DATES

Paper submission:    January 31, 2014 (extended)
Notifications:             March 15, 2014
Camera-ready:          April 1, 2014


--------------enigCC77DE20EB0EB1BE405ED4DB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCgAGBQJS1rjqAAoJENt3nsOmbNJcnqAH/0GFBu4oNkZ5ZJdkdbF/ipQy
Ei+dsP1eBwErpt1Hnztx7LnJu2ESfktgQInZuCY+Zdiih3mvRc+T9C+gGdzyN4MT
fetxijR3TJ1V3BTgSrDql/x0WBcdUbqvVf5IZDK3X0BhtOduSoQnMkc8kHXw2gdt
I9gWenAzQj4HLCFjiDC4hLMLJPpJtNm2SN4rEUEM8RhVXlgny91Ll17N2HOKLGLg
RDvEWZYD9dx6deOfP4CyvN6v/syBr0pIcDuvfPigKYM7odIt6wGAFgxOH+O7ruXF
IAbuoHRdNGQ4MKeXBrfNfDlD1z3O4tE6XoXtBwgsUFaA9P+iy/nMdtjmUI5imWA=
=7oJp
-----END PGP SIGNATURE-----

--------------enigCC77DE20EB0EB1BE405ED4DB--

From joelja@bogus.com  Wed Jan 15 09:31:50 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BC71AE147 for ; Wed, 15 Jan 2014 09:31:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3wEt0x8ARoL for ; Wed, 15 Jan 2014 09:31:49 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 51AE91AE17A for ; Wed, 15 Jan 2014 09:31:49 -0800 (PST)
Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s0FHVWs7026162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Jan 2014 17:31:33 GMT (envelope-from joelja@bogus.com)
Message-ID: <52D6C5EE.5080805@bogus.com>
Date: Wed, 15 Jan 2014 09:31:26 -0800
From: joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0
MIME-Version: 1.0
To: Nevil Brownlee 
References: <52B35727.1010106@auckland.ac.nz>
In-Reply-To: <52B35727.1010106@auckland.ac.nz>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tL7MdLSn7S4dqVbRiCcGH3hX9RLt5AHAj"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 15 Jan 2014 17:31:33 +0000 (UTC)
Cc: IPFIX Working Group 
Subject: Re: [IPFIX] Shepherd writeup for cisco-ies draft
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jan 2014 17:31:51 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--tL7MdLSn7S4dqVbRiCcGH3hX9RLt5AHAj
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thank you.

missed this
joel

On 12/19/13, 12:29 PM, Nevil Brownlee wrote:
>=20
> Hi Joel:
>=20
> Here's the writeup for the cicso-ies draft.
>=20
> Cheers, Nevil
>=20



--tL7MdLSn7S4dqVbRiCcGH3hX9RLt5AHAj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLWxe4ACgkQ8AA1q7Z/VrK6pwCfTz1yjn+6OWyUce6y0EOGztnm
h8sAnjIjzQsi0O0cp/JIlFz2xfB2/lJq
=ldsu
-----END PGP SIGNATURE-----

--tL7MdLSn7S4dqVbRiCcGH3hX9RLt5AHAj--

From bclaise@cisco.com  Mon Jan 20 03:02:41 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D791A0112 for ; Mon, 20 Jan 2014 03:02:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.336
X-Spam-Level: 
X-Spam-Status: No, score=-7.336 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2IApFPBVbpE for ; Mon, 20 Jan 2014 03:02:38 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 875531A0110 for ; Mon, 20 Jan 2014 03:02:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3917; q=dns/txt; s=iport; t=1390215759; x=1391425359; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=YeP1cTuP8GycvWpTi29d/wcjUbr6JIkioG5rK3QpuF4=; b=RaYe7Gt1XfMIpzctXJiB4vtAmu7F0mMCDQJZGFJaDKRnm4b5MeAARfdd 2olvFFDqBv4jV1iWwBCaRqiMU3LBtORERDSagUDsjc2tXUeYri+oqXzeX oK2VY08ZU5WyNsjddtUi36kzxhMER+qx1fKwlG/9uGpeAndt07fE0RZ+R c=;
X-IronPort-AV: E=Sophos;i="4.95,689,1384300800";  d="scan'208";a="3886367"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 20 Jan 2014 11:02:38 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0KB2bV5002616; Mon, 20 Jan 2014 11:02:37 GMT
Message-ID: <52DD024D.3010908@cisco.com>
Date: Mon, 20 Jan 2014 12:02:37 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: stbryant@cisco.com, "ipfix@ietf.org Group" , "ipfix-chairs@tools.ietf.org" , ipfix-ads@tools.ietf.org
References: <52C56FA7.6070905@cisco.com>
In-Reply-To: <52C56FA7.6070905@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [IPFIX] Application of IPFIX to new application spaces.
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jan 2014 11:02:42 -0000

Stewart,
>
> Whilst I accept that IPFIX is pretty much complete in terms of
> addressing it's original goals as a network management
> protocol, I have some concerns about it's completeness
> as an  observation reporting protocol. I think these need
> to be addressed, before declaring completion of the work
> programme as a whole.
>
> (In my own time) I am looking at the definition of a protocol
> to observe and report the radio noise floor. The purpose
> is to map the rise in the radio noise floor due to RF pollution
> from domestic and industrial digital systems such as
> plasma televisions, and power line (digital) transmission
> systems. IPFIX is a good protocol for such mass observations,
> and has been used successfully in the radio propagation
> monitoring system pskreporter.
>
> In doing this I ran into two problems, firstly there are no
> experimental IE types, and thus I cannot prototype the
> application without either "camping" on a set of IEs, or
> waiting until I am allocated a PEN. For reasons that will
> be clear from other work I have done in the IETF, I dislike
> the idea of "camping" on code-points. This makes it clear
> to me that we need a small, but not trivial set of
> experimental IEs that are intended for prototyping but
> explicitly excluded from use in production systems.
> This needs to be a reasonable number since a new application
> space might need a fair number of IEs to be practical.
> Thus I think that we need to either allocate some of the
> base protocol IEs to experimental, or to have IANA
> allocate a PEN specifically to experimental use which
> would allow experimentation in new applications spaces
> without the need to formally allocate IEs in either the
> base IE space, or the PEN space of the organization
> (or person) conducting the experiment.
I don't believe that allocating experimental IEs is a good idea.
First you need one per type. Unless you use RFC 5610, but if you do some 
experiments, then you most probably don't have RFC 5610. Then, as you 
said, you need multiple ones. How many? would 5 be enough, 10, 50, 100?

If you don't want to "waste" PEN for individual, which I understand, 
then why don't you request an experimental PEN.
Not an IPFIX experimental PEN, just an experimental PEN. This could be 
used for IPFIX, MIB, etc...
This would actually be better than individual PENs, somehow forcing 
people to go with a proper registration.

>
> The second problem that I see is the lack of a public registry
> for non-network managements applications. Specifically
> I am going to need "callsign", "maidenhead locator",
> "frequency", "noise power", maybe "field strength", "receiver type"
> etc. Now some of those may be of general use (frequency)
> but most of them would be cruft in the base protocol IE set
> which is set up for networking applications. On the other hand,
> I know of at least one PEN space that will have a number of the
> terms I need already defined, although these are by
> definition private. With the current IE registration structure
> the absence of a public registry inevitably means the
> redefinition of other than mainstream/network management
> terms across a number of private registries. I thus think
> it would be useful to introduce a PEN + registry for
> "other applications" or introduce the concept of a series
> of application specific registries with appropriate  PENs to
> identify the application space rather than  the private
> enterprise space.
It's true that IPFIX became a generic push mechanism.
We tried this in the past with the groups in 
http://tools.ietf.org/search/rfc5102#section-5
This was removed in RFC 7102.

Regards, Benoit
>
> - Stewart
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix
> .
>


From bclaise@cisco.com  Mon Jan 20 03:35:44 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E206F1A00E0 for ; Mon, 20 Jan 2014 03:35:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.735
X-Spam-Level: 
X-Spam-Status: No, score=-6.735 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwL0bQ9n8aHF for ; Mon, 20 Jan 2014 03:35:40 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD531A0120 for ; Mon, 20 Jan 2014 03:35:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26624; q=dns/txt; s=iport; t=1390217740; x=1391427340; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=dSWRAzCDyXv7vNdgpkVnihiHML+Lm9z67mn2HF6P3m4=; b=FG12Yznss0SccnmA30EZFYMOop3SZuyt2JsMFiMntLTHUORXJX0LNJA1 mC3qcP2ykGPLE6dP/JSzu5RE13BGrLaeU1NFd/co6KzV/s76wpULIFmlR H3/jXA674gNgYYOG/P7pAbN6VIVzL8NaK+ZXutz/bbpjMd7ZjkFgve2wj k=;
X-IronPort-AV: E=Sophos;i="4.95,690,1384300800"; d="scan'208,217";a="3887880"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 20 Jan 2014 11:35:39 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0KBZb2Z012475; Mon, 20 Jan 2014 11:35:38 GMT
Message-ID: <52DD0A09.10807@cisco.com>
Date: Mon, 20 Jan 2014 12:35:37 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Andrew Feren , Brian Trammell , "stbryant@cisco.com Bryant" 
References: <52C56FA7.6070905@cisco.com>  <52C6A7C6.1020703@cisco.com> <9825ADB8-DE16-4EDA-9AFA-65DC6D39696C@tik.ee.ethz.ch> <52CDB4D8.6070501@plixer.com>
In-Reply-To: <52CDB4D8.6070501@plixer.com>
Content-Type: multipart/alternative; boundary="------------060906090709080405070207"
Cc: ipfix-ads@tools.ietf.org, "ipfix@ietf.org Group" , "ipfix-chairs@tools.ietf.org" 
Subject: Re: [IPFIX] Application of IPFIX to new application spaces.
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jan 2014 11:35:45 -0000

This is a multi-part message in MIME format.
--------------060906090709080405070207
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 8/01/2014 21:28, Andrew Feren wrote:
> Hi Stewart, Brian, all,
>
> Comments inline
>
> On 01/03/2014 12:54 PM, Brian Trammell wrote:
>>
>> On 03 Jan 2014, at 13:06, Stewart Bryant > > wrote:
>>
>>> I brought up the concept of ownership of PENs by individuals
>>> in a couple of IESG discussions on IPFIX, and the opinion that
>>> I get (as I recall from the APPs ADs) is that PENs were never
>>> intended to be assigned to individuals together with surprise
>>> that any had been allocated to individuals. Hence my initial
>>> reluctance. I know that there are some other owned by individuals,
>>> and I  have requested one for the purpose of trying out this
>>> application of the protocol. However I think the concern is
>>> that it would not scale if every individual experimenter
>>> requested their own, much less one per experiment.
>>
>> It's probably well outside the scope of IANA's competence to rule on 
>> the differences between individuals, sole proprietorships, single 
>> member LLCs/GmbHs, C/S corporations, AGs/ABs/SAs, unorganized 
>> collectives of software developers, and so on. Without that 
>> competence, it's pretty difficult to give them guidelines as to what 
>> to allow and what to deny in terms of individual registrations. So 
>> FCFS to anyone who can control an email address it is.
>>
>> If you're doing experiments with IPFIX (or, indeed, SNMP) as an 
>> individual or academic at an organization without a PEN or where it's 
>> difficult to get "official" IPFIX IE number space within that PEN, 
>> getting your own is the only way to go.
>
> +1
>
> I assume that the point of the experiments is to eventually move 
> beyond the experiment.  At some point a PEN will likely be needed for 
> the IEs that proved useful in the experiment.  Might as well get the 
> PEN and start using it.
>
>>
>> Of course, I'm probably the worst abuser of this property, having 
>> requested the first PEN (29305) for an RFC (5103) for the 
>> single-record biflow hack.
>>>> I could see this being a problem if one were trying to run many experiments within the same very large organization with undefined or draconian processes for reserving an enterprise-specific IE. But PEN space is 2^32-1 large and we haven;t even exhausted the first block of 2^16, so "get a new PEN and label it useful for a given experiment" is probably an acceptable way out of this quandary.
>>> I think the question is one of whether or not that is best practice.
>>> Sure the space is large, but so was the IPv4 Address space when it
>>> was created :)
>>
>> I share your concern in theory. But practically I cannot imagine a 
>> world in which the number of IPFIX experiments (plus normal SMI 
>> "enterprises") is anywhere near on the order of addressable locations 
>> in the IPv4 number space. We're talking tens of PENs, hundreds if we 
>> are successful in expanding the IPFIX information model to be the One 
>> True Way the Internet of Things talks about itself.
>>
>> I realize I've just made a "nobody needs more than 64k autonomous 
>> systems" statement. And I completely agree that this is somewhat 
>> outside the original intention of the PEN registry at its creation 
>> time, but compare this to the difference between the domain name 
>> space as it was conceived and as it's (ab)used today, and I think 
>> what I'm proposing is a relatively minor violation, and is indeed not 
>> really all that different from the PENs-for-application-areas 
>> proposal (which I quite like as well).
>>>>> For reasons that will
>>>>> be clear from other work I have done in the IETF, I dislike
>>>>> the idea of "camping" on code-points. This makes it clear
>>>>> to me that we need a small, but not trivial set of
>>>>> experimental IEs that are intended for prototyping but
>>>>> explicitly excluded from use in production systems.
>>>>> This needs to be a reasonable number since a new application
>>>>> space might need a fair number of IEs to be practical.
>>>>> Thus I think that we need to either allocate some of the
>>>>> base protocol IEs to experimental, or to have IANA
>>>>> allocate a PEN specifically to experimental use which
>>>>> would allow experimentation in new applications spaces
>>>>> without the need to formally allocate IEs in either the
>>>>> base IE space, or the PEN space of the organization
>>>>> (or person) conducting the experiment.
>>>> I agree in principle that allocating a single "IPFIX Experimentation" PEN would be one solution to this problem, but it would have to be fairly tightly scoped (only for experimental use among EPs and CPs implemented and deployed by a single entity within the scope of a single experiment; MUST be logged as an error by CPs in production use). And I'd be very concerned that we were basically inviting people to camp on a whole new code space --- requiring experiments to use their own PEN space at least keeps experimental IEs that "leak" into production from colliding with each other, provided that the PEN owner manages their own space competently.
>>> Text of the following format needs to be associated with the
>>> space:
>>> Code points in the experimental range MUST be used according to the
>>> guidelines ofRFC 3692    [RFC3692  ].
>> Yep, that's good and unambiguous, but it still does not address the 
>> issue of what happens after the termination of the experiment.
>>>>> The second problem that I see is the lack of a public registry
>>>>> for non-network managements applications. Specifically
>>>>> I am going to need "callsign", "maidenhead locator",
>>>>> "frequency", "noise power", maybe "field strength", "receiver type"
>>>>> etc. Now some of those may be of general use (frequency)
>>>>> but most of them would be cruft in the base protocol IE set
>>>>> which is set up for networking applications. On the other hand,
>>>>> I know of at least one PEN space that will have a number of the
>>>>> terms I need already defined, although these are by
>>>>> definition private.
>> s/private/not necessarily public/ --- there is nothing keeping an 
>> operator of a PEN registry from publishing that registry. Indeed, the 
>> intention of RFC 5610 was to allow such operators to publish such 
>> registries _inline_ to allow polymorphic collectors / file readers to 
>> load such registries at runtime.
>
> In fact many PEN/IE registries have in fact been published in one form 
> or an other, but I sure would love a central location with a parseable 
> format.  This is not the first time that a desire for a central 
> enterprise registry has been voiced 
> (http://www.ietf.org/mail-archive/web/ipfix/current/msg05825.html).
>
> Obviously the owner of each PEN should decide which elements they want 
> to publish information about and when.  Aside from making my life as a 
> collector developer easier I think there are other advantages to a 
> central registry.  One such advantage would be exposing IEs for which 
> there is significant interest and which are therefore potential 
> candidates to be standardized.
I fully understand the need from a collector point of view, and broadly 
for the community interest point of view, but practically, I don't see 
this working. Along the same line of easing the collector live, there is 
RFC 5610, but I don't see the love to implement it.
> I have built my own version of a central registry as I encounter new 
> exports.  Making a quick scan of the DB I see, for example, about 5 
> different IEs each for HTTP urls, HTTP return codes, and HTTP host.
>
>
>>>>> With the current IE registration structure
>>>>> the absence of a public registry inevitably means the
>>>>> redefinition of other than mainstream/network management
>>>>> terms across a number of private registries. I thus think
>>>>> it would be useful to introduce a PEN + registry for
>>>>> "other applications" or introduce the concept of a series
>>>>> of application specific registries with appropriate  PENs to
>>>>> identify the application space rather than  the private
>>>>> enterprise space.
>>
>> As I noted above, there's already precedent for this: PEN 29305 for 
>> RFC 5103.
>>
>> We could certainly define a few "extended application" areas, assign 
>> them PENs, and allocate them via IANA; we'd just need to add a PEN 
>> column to the registry, and update 7102. Deciding on an initial list 
>> might take a while though.
>
> The idea of application PENs is interesting, but I'm not sure I see a 
> need at this point.  Besides, multiple application registries feels a 
> bit like the IE categories that existed in 5102 and no one cared to 
> carry forward to 7012.  As noted at the time ( 
> http://www.ietf.org/mail-archive/web/ipfix/current/msg06621.html) as 
> applications move up and down layers IEs would need to be redefined.  
> I would expect similar categorization issues trying to decide what 
> application an IE belongs to and very little upside to doing the 
> categorization.
Agreed.
What could make sense is to specify a templateRecordName, as a string, 
to have a free-form template name/application/whatever you want.

Regards, Benoit
>
> A single catch all PEN for "other applications" is a little better, 
> but I don't really see this as much different than just having a 
> registry where PEN/IE details can be registered/shared. An advantage 
> of a registry with various PENs would be that an experimental PEN/IE 
> could be "promoted" (shared) by adding it to the registry once the 
> experimenter is ready.
>
> -Andrew
>
>>
>> Cheers,
>>
>> Brian
>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


--------------060906090709080405070207
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 8/01/2014 21:28, Andrew Feren wrote:

    

    

      
      
Hi Stewart, Brian, all,

        

        Comments inline

        

        On 01/03/2014 12:54 PM, Brian Trammell wrote:

      

      
 

        

          
On 03 Jan 2014, at 13:06, Stewart Bryant <stbryant@cisco.com>

            wrote:

          

          

            

              
 

              I brought up the concept of ownership of PENs by
              individuals 

              in a couple of IESG discussions on IPFIX, and the opinion
              that

              I get (as I recall from the APPs ADs) is that PENs were
              never 

              intended to be assigned to individuals together with
              surprise

              that any had been allocated to individuals. Hence my
              initial 

              reluctance. I know that there are some other owned by
              individuals, 

              and I  have requested one for the purpose of trying out
              this 

              application of the protocol. However I think the concern
              is 

              that it would not scale if every individual experimenter 

              requested their own, much less one per experiment.

            

          

          


          

          
It’s probably well outside the scope of IANA’s competence
            to rule on the differences between individuals, sole
            proprietorships, single member LLCs/GmbHs, C/S corporations,
            AGs/ABs/SAs, unorganized collectives of software developers,
            and so on. Without that competence, it’s pretty difficult to
            give them guidelines as to what to allow and what to deny in
            terms of individual registrations. So FCFS to anyone who can
            control an email address it is.

          


          

          
If you’re doing experiments with IPFIX (or, indeed, SNMP)
            as an individual or academic at an organization without a
            PEN or where it’s difficult to get “official” IPFIX IE
            number space within that PEN, getting your own is the only
            way to go.

        

      

      

      
+1

      


        

      
I assume
          that the point of the experiments is to eventually move beyond
          the experiment.  At some point a PEN will likely be needed for
          the IEs that proved useful in the experiment.  Might as well
          get the PEN and start using it.

          

        

      

        

          


          

          
Of course, I’m probably the worst abuser of this
            property, having requested the first PEN (29305) for an RFC
            (5103) for the single-record biflow hack. 

          

            

              

                
I could see this being a problem if one were trying to run many experiments within the same very large organization with undefined or draconian processes for reserving an enterprise-specific IE. But PEN space is 2^32-1 large and we haven;t even exhausted the first block of 2^16, so “get a new PEN and label it useful for a given experiment” is probably an acceptable way out of this quandary.

              

              I think the question is one of whether or not that is best
              practice.

              Sure the space is large, but so was the IPv4 Address space
              when it

              was created :)

          

          


          

          
I share your concern in theory. But practically I cannot
            imagine a world in which the number of IPFIX experiments
            (plus normal SMI “enterprises”) is anywhere near on the
            order of addressable locations in the IPv4 number space.
            We’re talking tens of PENs, hundreds if we are successful in
            expanding the IPFIX information model to be the One True Way
            the Internet of Things talks about itself.

          


          

          
I realize I’ve just made a “nobody needs more than 64k
            autonomous systems” statement. And I completely agree that
            this is somewhat outside the original intention of the PEN
            registry at its creation time, but compare this to the
            difference between the domain name space as it was conceived
            and as it’s (ab)used today, and I think what I’m proposing
            is a relatively minor violation, and is indeed not really
            all that different from the PENs-for-application-areas
            proposal (which I quite like as well).

          

            

              

                

                  
For reasons that will
be clear from other work I have done in the IETF, I dislike
the idea of "camping" on code-points. This makes it clear
to me that we need a small, but not trivial set of
experimental IEs that are intended for prototyping but
explicitly excluded from use in production systems.
This needs to be a reasonable number since a new application
space might need a fair number of IEs to be practical.
Thus I think that we need to either allocate some of the
base protocol IEs to experimental, or to have IANA
allocate a PEN specifically to experimental use which
would allow experimentation in new applications spaces
without the need to formally allocate IEs in either the
base IE space, or the PEN space of the organization
(or person) conducting the experiment.


                

                
I agree in principle that allocating a single “IPFIX Experimentation” PEN would be one solution to this problem, but it would have to be fairly tightly scoped (only for experimental use among EPs and CPs implemented and deployed by a single entity within the scope of a single experiment; MUST be logged as an error by CPs in production use). And I’d be very concerned that we were basically inviting people to camp on a whole new code space — requiring experiments to use their own PEN space at least keeps experimental IEs that “leak” into production from colliding with each other, provided that the PEN owner manages their own space competently.

              

              Text of the following format needs to be associated with
              the

              space:

              
Code points in the experimental range MUST be used according to the
guidelines of RFC 3692 [RFC3692].

            

          

          
Yep, that’s good and unambiguous, but it still does not
            address the issue of what happens after the termination of
            the experiment.

          

            

              

                

                  
The second problem that I see is the lack of a public registry
for non-network managements applications. Specifically
I am going to need "callsign", "maidenhead locator",
"frequency", "noise power", maybe "field strength", "receiver type"
etc. Now some of those may be of general use (frequency)
but most of them would be cruft in the base protocol IE set
which is set up for networking applications. On the other hand,
I know of at least one PEN space that will have a number of the
terms I need already defined, although these are by
definition private. 

                

              

            

          

          
s/private/not necessarily public/ — there is nothing
            keeping an operator of a PEN registry from publishing that
            registry. Indeed, the intention of RFC 5610 was to allow
            such operators to publish such registries _inline_ to allow
            polymorphic collectors / file readers to load such
            registries at runtime.

        

      

      

      In fact many PEN/IE registries have in fact been published in one
      form or an other, but I sure would love a central location with a
      parseable format.  This is not the first time that a desire for a
      central enterprise registry has been voiced (http://www.ietf.org/mail-archive/web/ipfix/current/msg05825.html).

      

      Obviously the owner of each PEN should decide which elements they
      want to publish information about and when.  Aside from making my
      life as a collector developer easier I think there are other
      advantages to a central registry.  One such advantage would be
      exposing IEs for which there is significant interest and which are
      therefore potential candidates to be standardized.

    

    I fully understand the need from a collector point of view, and
    broadly for the community interest point of view, but practically, I
    don't see this working. Along the same line of easing the collector
    live, there is RFC 5610, but I don't see the love to implement it.

    
 I
      have built my own version of a central registry as I encounter new
      exports.  Making a quick scan of the DB I see, for example, about
      5 different IEs each for HTTP urls, HTTP return codes, and HTTP
      host.

      

      

      

        

          

            

              

                

                  
With the current IE registration structure
the absence of a public registry inevitably means the
redefinition of other than mainstream/network management
terms across a number of private registries. I thus think
it would be useful to introduce a PEN + registry for
"other applications" or introduce the concept of a series
of application specific registries with appropriate  PENs to
identify the application space rather than  the private
enterprise space.

                

              

            

          

          


          

          
As I noted above, there’s already precedent for this: PEN
            29305 for RFC 5103.

          


          

          
We could certainly define a few “extended application”
            areas, assign them PENs, and allocate them via IANA; we’d
            just need to add a PEN column to the registry, and update
            7102. Deciding on an initial list might take a while though.

        

      

      

      The idea of application PENs is interesting, but I'm not sure I
      see a need at this point.  Besides, multiple application
      registries feels a bit like the IE categories that existed in 5102
      and no one cared to carry forward to 7012.  As noted at the time (
      http://www.ietf.org/mail-archive/web/ipfix/current/msg06621.html)
      as applications move up and down layers IEs would need to be
      redefined.  I would expect similar categorization issues trying to
      decide what application an IE belongs to and very little upside to
      doing the categorization.

    

    Agreed.

    What could make sense is to specify a templateRecordName, as a
    string, to have a free-form template name/application/whatever you
    want.

    

    Regards, Benoit

    
 

      A single catch all PEN for "other applications" is a little
      better, but I don't really see this as much different than just
      having a registry where PEN/IE details can be registered/shared. 
      An advantage of a registry with various PENs would be that an
      experimental PEN/IE could be "promoted" (shared) by adding it to
      the registry once the experimenter is ready.

      

      -Andrew

      

      

        

          


          

          
Cheers,

          


          

          
Brian

        

        

        

        

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


      

      

      

      

      

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


    

    

  


--------------060906090709080405070207--

From bclaise@cisco.com  Mon Jan 20 03:36:45 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEC31A00E0 for ; Mon, 20 Jan 2014 03:36:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level: 
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACXgTmxL5PlG for ; Mon, 20 Jan 2014 03:36:42 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0604A1A0134 for ; Mon, 20 Jan 2014 03:36:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10214; q=dns/txt; s=iport; t=1390217802; x=1391427402; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=RlKcnnvRK/5E9Ct495dGfCu/6qZYw1z82dHWD/qLfKs=; b=kef5udX3vbWeN7umIsVyZI1sbfT3CoGOzGRElh0euz8/PWx/8kZrFaJM rWFmmnXjHftXqHktPh/geAHbCC3irTTihpGxvJ/PvXxDcMa/h9/WBpH7X UzrHLfntRBS8DfDcHEaNPlJEcOcBRL6eviorDkJg8gT74DYTVHMBQ3Z2v M=;
X-IronPort-AV: E=Sophos;i="4.95,690,1384300800"; d="scan'208,217";a="3218494"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 20 Jan 2014 11:36:41 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0KBafPd021415; Mon, 20 Jan 2014 11:36:41 GMT
Message-ID: <52DD0A49.2010300@cisco.com>
Date: Mon, 20 Jan 2014 12:36:41 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Paul Aitken , Brian Trammell ,  "stbryant@cisco.com Bryant" 
References: <52C56FA7.6070905@cisco.com>  <52C794C2.7020503@cisco.com>
In-Reply-To: <52C794C2.7020503@cisco.com>
Content-Type: multipart/alternative; boundary="------------010708080707080002080001"
Cc: ipfix-ads@tools.ietf.org, "ipfix@ietf.org Group" , "ipfix-chairs@tools.ietf.org" 
Subject: Re: [IPFIX] Application of IPFIX to new application spaces.
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jan 2014 11:36:45 -0000

This is a multi-part message in MIME format.
--------------010708080707080002080001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 4/01/2014 05:57, Paul Aitken wrote:
> Stewart, Brian,
>
>>> For reasons that will
>>> be clear from other work I have done in the IETF, I dislike
>>> the idea of "camping" on code-points. This makes it clear
>>> to me that we need a small, but not trivial set of
>>> experimental IEs that are intended for prototyping but
>>> explicitly excluded from use in production systems.
>>> This needs to be a reasonable number since a new application
>>> space might need a fair number of IEs to be practical.
>>> Thus I think that we need to either allocate some of the
>>> base protocol IEs to experimental, or to have IANA
>>> allocate a PEN specifically to experimental use which
>>> would allow experimentation in new applications spaces
>>> without the need to formally allocate IEs in either the
>>> base IE space, or the PEN space of the organization
>>> (or person) conducting the experiment.
>> I agree in principle that allocating a single "IPFIX Experimentation" PEN would be one solution to this problem, but it would have to be fairly tightly scoped (only for experimental use among EPs and CPs implemented and deployed by a single entity within the scope of a single experiment; MUST be logged as an error by CPs in production use). And I'd be very concerned that we were basically inviting people to camp on a whole new code space --- requiring experiments to use their own PEN space at least keeps experimental IEs that "leak" into production from colliding with each other, provided that the PEN owner manages their own space competently.
>
> +1
>
> I was about to say the same. While the "Experimentation PEN" idea 
> sounds good, there are practical dangers:
>
> With my netflow-police hat on, I allocate cisco's NFv9 and IPFIX 
> enterprise-specific IDs. I've had to reserve blocks of NFv9 IDs which 
> have been used by third parties (external to cisco) in released code 
> without telling us (a collector partner was good enough to inform us 
> about the potential clash). And in the past we've allocated our own 
> experimental IPFIX IDs which were meant to be replaced with IANA IDs 
> before release, but got overlooked.
>
> To avoid any issues, I'd rather see experiments done in private PEN space.
+1

Regards, B.
>
> P.
>
>
>>> The second problem that I see is the lack of a public registry
>>> for non-network managements applications. Specifically
>>> I am going to need "callsign", "maidenhead locator",
>>> "frequency", "noise power", maybe "field strength", "receiver type"
>>> etc. Now some of those may be of general use (frequency)
>>> but most of them would be cruft in the base protocol IE set
>>> which is set up for networking applications. On the other hand,
>>> I know of at least one PEN space that will have a number of the
>>> terms I need already defined, although these are by
>>> definition private. With the current IE registration structure
>>> the absence of a public registry inevitably means the
>>> redefinition of other than mainstream/network management
>>> terms across a number of private registries. I thus think
>>> it would be useful to introduce a PEN + registry for
>>> "other applications" or introduce the concept of a series
>>> of application specific registries with appropriate  PENs to
>>> identify the application space rather than  the private
>>> enterprise space.
>> This seems like a very good idea. I'll have to think about it some more.
>>
>> Thanks, cheers,
>>
>> Brian
>>
>>> __________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipfix
>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


--------------010708080707080002080001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 4/01/2014 05:57, Paul Aitken wrote:

    

    

      
      
Stewart, Brian,

      

      

      

        

          
For reasons that will
be clear from other work I have done in the IETF, I dislike
the idea of "camping" on code-points. This makes it clear
to me that we need a small, but not trivial set of
experimental IEs that are intended for prototyping but
explicitly excluded from use in production systems.
This needs to be a reasonable number since a new application
space might need a fair number of IEs to be practical.
Thus I think that we need to either allocate some of the
base protocol IEs to experimental, or to have IANA
allocate a PEN specifically to experimental use which
would allow experimentation in new applications spaces
without the need to formally allocate IEs in either the
base IE space, or the PEN space of the organization
(or person) conducting the experiment.


        

        
I agree in principle that allocating a single “IPFIX Experimentation” PEN would be one solution to this problem, but it would have to be fairly tightly scoped (only for experimental use among EPs and CPs implemented and deployed by a single entity within the scope of a single experiment; MUST be logged as an error by CPs in production use). And I’d be very concerned that we were basically inviting people to camp on a whole new code space — requiring experiments to use their own PEN space at least keeps experimental IEs that “leak” into production from colliding with each other, provided that the PEN owner manages their own space competently.

      

      

      +1

      

      I was about to say the same. While the "Experimentation PEN" idea
      sounds good, there are practical dangers:

      

      With my netflow-police hat on, I allocate cisco's NFv9 and IPFIX
      enterprise-specific IDs. I've had to reserve blocks of NFv9 IDs
      which have been used by third parties (external to cisco) in
      released code without telling us (a collector partner was good
      enough to inform us about the potential clash). And in the past
      we've allocated our own experimental IPFIX IDs which were meant to
      be replaced with IANA IDs before release, but got overlooked.

      

      To avoid any issues, I'd rather see experiments done in private
      PEN space.

    

    +1

    

    Regards, B.

    
 

      P.

      

      

      

        

        

          
The second problem that I see is the lack of a public registry
for non-network managements applications. Specifically
I am going to need "callsign", "maidenhead locator",
"frequency", "noise power", maybe "field strength", "receiver type"
etc. Now some of those may be of general use (frequency)
but most of them would be cruft in the base protocol IE set
which is set up for networking applications. On the other hand,
I know of at least one PEN space that will have a number of the
terms I need already defined, although these are by
definition private. With the current IE registration structure
the absence of a public registry inevitably means the
redefinition of other than mainstream/network management
terms across a number of private registries. I thus think
it would be useful to introduce a PEN + registry for
"other applications" or introduce the concept of a series
of application specific registries with appropriate  PENs to
identify the application space rather than  the private
enterprise space.


        

        
This seems like a very good idea. I’ll have to think about it some more.

Thanks, cheers,

Brian



        

          
__________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


        

        

        

        

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


      

      

      

      

      

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


    

    

  


--------------010708080707080002080001--

From internet-drafts@ietf.org  Mon Jan 20 04:54:45 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5EB01A0147; Mon, 20 Jan 2014 04:54:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUnw-LIW6mSA; Mon, 20 Jan 2014 04:54:43 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7821A013D; Mon, 20 Jan 2014 04:54:43 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140120125443.14390.21012.idtracker@ietfa.amsl.com>
Date: Mon, 20 Jan 2014 04:54:43 -0800
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jan 2014 12:54:45 -0000

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

        Title           : Textual Representation of IPFIX Abstract Data Typ=
es
        Author          : Brian Trammell
	Filename        : draft-ietf-ipfix-text-adt-00.txt
	Pages           : 11
	Date            : 2014-01-20

Abstract:
   This document defines UTF-8 representations for IPFIX abstract data
   types, to support interoperable usage of the IPFIX Information
   Elements with protocols based on textual encodings.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From Quittek@neclab.eu  Mon Jan 20 06:55:57 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD94D1A0197 for ; Mon, 20 Jan 2014 06:55:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.137
X-Spam-Level: 
X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id behVb0xpdYJn for ; Mon, 20 Jan 2014 06:55:55 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id ED13A1A0198 for ; Mon, 20 Jan 2014 06:55:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A0F651069CD for ; Mon, 20 Jan 2014 15:55:54 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9KXE+IGziTk for ; Mon, 20 Jan 2014 15:55:54 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 833021069CC for ; Mon, 20 Jan 2014 15:55:49 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.144]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 20 Jan 2014 15:55:49 +0100
From: Juergen Quittek 
To: "ipfix@ietf.org" 
Thread-Topic: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-00.txt
Thread-Index: AQHPFd7aGIQrt+amTkexBINEOChw95qNsDXQ
Date: Mon, 20 Jan 2014 14:55:49 +0000
Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E868908508@DAPHNIS.office.hd>
References: <20140120125443.14390.21012.idtracker@ietfa.amsl.com>
In-Reply-To: <20140120125443.14390.21012.idtracker@ietfa.amsl.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.99.69]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jan 2014 14:55:58 -0000

Dear all,
Most of you know this draft as we had it presented at the IPFIX session at =
IETF #86 as potential WG document. The chairs believe that the document is =
already in a very mature state and we want to start WGLC very soon. Would a=
nyone have a concern with progressing this draft to WGLC in this state?
Cheers,
    Juergen

> -----Original Message-----
> From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Montag, 20. Januar 2014 13:55
> To: i-d-announce@ietf.org
> Cc: ipfix@ietf.org
> Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-00.txt
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>  This draft is a work item of the IP Flow Information Export Working Grou=
p of
> the IETF.
>=20
>         Title           : Textual Representation of IPFIX Abstract Data T=
ypes
>         Author          : Brian Trammell
> 	Filename        : draft-ietf-ipfix-text-adt-00.txt
> 	Pages           : 11
> 	Date            : 2014-01-20
>=20
> Abstract:
>    This document defines UTF-8 representations for IPFIX abstract data
>    types, to support interoperable usage of the IPFIX Information
>    Elements with protocols based on textual encodings.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-00
>=20
>=20
> Please note that it may take a couple of minutes from the time of submiss=
ion
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix

From Quittek@neclab.eu  Tue Jan 28 00:32:40 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1994B1A003E for ; Tue, 28 Jan 2014 00:32:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.137
X-Spam-Level: 
X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dD-8eioymPYz for ; Tue, 28 Jan 2014 00:32:37 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1F88E1A0018 for ; Tue, 28 Jan 2014 00:32:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 7610E106A55 for ; Tue, 28 Jan 2014 09:32:34 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2V4+Je+PjVX for ; Tue, 28 Jan 2014 09:32:34 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 5E0091068E5 for ; Tue, 28 Jan 2014 09:32:29 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.144]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 28 Jan 2014 09:32:29 +0100
From: Juergen Quittek 
To: "ipfix@ietf.org" 
Thread-Topic: WGLC for draft-ietf-ipfix-text-adt-00.txt
Thread-Index: Ac8cA3p0pZjwfHlrTDuNa8bqNzG5ng==
Date: Tue, 28 Jan 2014 08:32:28 +0000
Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E868910E0D@DAPHNIS.office.hd>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.2.165]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [IPFIX] WGLC for draft-ietf-ipfix-text-adt-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jan 2014 08:32:40 -0000

Dear all,

This is the working group last call on
draft-ietf-ipfix-text-adt-00.txt.

The call starts today and will last until Friday Feb 14.

A URL for this Internet-Draft is:
http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-00

Please read the draft.
Please send your comments to this mailing list.
Please also send a message if you are fine with the draft as it is.

Thank you,
    Juergen


From paitken@cisco.com  Tue Jan 28 06:34:03 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308021A0420 for ; Tue, 28 Jan 2014 06:34:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.669
X-Spam-Level: 
X-Spam-Status: No, score=-6.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_55=0.6, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-UjeH7jmkqy for ; Tue, 28 Jan 2014 06:33:57 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id ACE021A041B for ; Tue, 28 Jan 2014 06:33:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57921; q=dns/txt; s=iport; t=1390919633; x=1392129233; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=ab5XAaKW6UDAxBZtvPrrrk09jZ5gYKUfj35hDOgizFw=; b=drFZYInQ0boSCLxtAsWTi0mNreLMnL+8VsdFA4OEnwLV7gDifE9c6zlj 829R9C+R9UWYWtmF9rq9OrpMjrgHY79zm6nHE8dPdStgboJHStHiIIo0a mUWBdb/s1JqG+9GbNsNMakRDh+eCq8jMVfJSjRuLMikOs2ytuseUHOggr g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FADK/51KQ/khR/2dsb2JhbABQCoMMOL0ugRAWdIIlAQEBAwEaAV0GCQILEg8WAQENCQMCAQIBCS4OBgEMBgIBAQWHdAgNyV0XBI4OCgEGBAcBJDOEOASUQINogTKFFotXgy2BaAkX
X-IronPort-AV: E=Sophos;i="4.95,736,1384300800"; d="scan'208,217";a="4304524"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 28 Jan 2014 14:33:51 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0SEXo2L010890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jan 2014 14:33:51 GMT
Received: from [10.147.1.39] (dhcp-10-147-1-39.cisco.com [10.147.1.39]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0SEXo9c013810; Tue, 28 Jan 2014 14:33:50 GMT
Message-ID: <52E7BFCE.8080701@cisco.com>
Date: Tue, 28 Jan 2014 14:33:50 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Brian Trammell , "ipfix@ietf.org" 
References: <9AB93E4127C26F4BA7829DEFDCE5A6E868910E0D@DAPHNIS.office.hd>
In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E868910E0D@DAPHNIS.office.hd>
Content-Type: multipart/alternative; boundary="------------080001010103000305030000"
Subject: Re: [IPFIX] WGLC for draft-ietf-ipfix-text-adt-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jan 2014 14:34:03 -0000

This is a multi-part message in MIME format.
--------------080001010103000305030000
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Here's a review of draft-ietf-ipfix-text-adt-00.

P.

>
>
> IPFIX Working Group                                          B. Trammell
> Internet-Draft                                                ETH Zurich
> Intended status: Informational                          January 20, 2014
> Expires: July 24, 2014
>
>
>            Textual Representation of IPFIX Abstract Data Types
>                      draft-ietf-ipfix-text-adt-00.txt
>
> Abstract
>
>     This document defines UTF-8 representations for IPFIX abstract data
>     types, to support interoperable usage of the IPFIX Information
>     Elements with protocols based on textual encodings.
>
> Status of This Memo
>
>     This Internet-Draft is submitted in full conformance with the
>     provisions of BCP 78 and BCP 79.
>
>     Internet-Drafts are working documents of the Internet Engineering
>     Task Force (IETF).  Note that other groups may also distribute
>     working documents as Internet-Drafts.  The list of current Internet-
>     Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>     Internet-Drafts are draft documents valid for a maximum of six months
>     and may be updated, replaced, or obsoleted by other documents at any
>     time.  It is inappropriate to use Internet-Drafts as reference
>     material or to cite them other than as "work in progress."
>
>     This Internet-Draft will expire on July 24, 2014.
>
> Copyright Notice
>
>     Copyright (c) 2014 IETF Trust and the persons identified as the
>     document authors.  All rights reserved.
>
>     This document is subject to BCP 78 and the IETF Trust's Legal
>     Provisions Relating to IETF Documents
>     (http://trustee.ietf.org/license-info) in effect on the date of
>     publication of this document.  Please review these documents
>     carefully, as they describe your rights and restrictions with respect
>     to this document.  Code Components extracted from this document must
>     include Simplified BSD License text as described in Section 4.e of
>     the Trust Legal Provisions and are provided without warranty as
>     described in the Simplified BSD License.
>
>
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 1]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
> Table of Contents
>
>     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
>     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
>     3.  Identifying Information Elements  . . . . . . . . . . . . . .   3
>     4.  Data Type Encodings . . . . . . . . . . . . . . . . . . . . .   3
>       4.1.  octetArray  . . . . . . . . . . . . . . . . . . . . . . .   3
>       4.2.  unsigned8, unsigned16, unsigned32, and unsigned64 . . . .   4
>       4.3.  signed8, signed16, signed32, and signed64 . . . . . . . .   4
>       4.4.  float32 and float64 . . . . . . . . . . . . . . . . . . .   5
>       4.5.  boolean . . . . . . . . . . . . . . . . . . . . . . . . .   6
>       4.6.  macAddress  . . . . . . . . . . . . . . . . . . . . . . .   6
>       4.7.  string  . . . . . . . . . . . . . . . . . . . . . . . . .   6
>       4.8.  dateTime* . . . . . . . . . . . . . . . . . . . . . . . .   7
>       4.9.  ipv4Address . . . . . . . . . . . . . . . . . . . . . . .   7
>       4.10. ipv6Address . . . . . . . . . . . . . . . . . . . . . . .   8
>       4.11. basicList, subTemplateList, and subTemplateMultiList  . .   8
>     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
>     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
>     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
>       7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
>       7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
>     Appendix A.  Example  . . . . . . . . . . . . . . . . . . . . . .   9
>     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11
>
> 1.  Introduction
>
>     The IPFIX Information Model, as defined by the IANA IPFIX Information
>     Element Registry [iana-ipfix-assignments], provides a rich set of
>     Information Elements for description of information aboutnetwork
>     entities and network traffic data,and abstract data types for these
>     Information Elements.  The IPFIX Protocol Specification [RFC7011], in

Perhaps, though it's not limited just to networks ;-)

You're suggesting that the IANA registry is the reference for the ADTs, 
rather than 7012?
7012 isn't mentioned until section 4.


>     turn, defines a big-endian binary encoding for these abstract data
>     types suitable for use with the IPFIX Protocol.

+xref for the protocol spec?


>     However, present and future operations and management protocols and
>     applications may use textual encodings, and generic framing and
>     structure as in JSON or XML.  A definition of canonical textual
>     encodings for the IPFIX abstract data types would allow this set of
>     Information Elements to be used for such applications, and for these
>     applications to interoperate with IPFIX applications at the
>     Information Element definition level.
>
>     Note that templating or other mechanisms for data description for
>     such applications and protocols are application specific, and
>     therefore out of scope for this document: only Information Element
>     identification and data value representation are defined here.
>
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 2]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
> 2.  Terminology
>
>     Capitalized terms defined in the IPFIX Protocol Specification
>     [RFC7011] and the IPFIX Information Model [RFC7012] are used in this
>     document as defined in those documents.  In addition, this document
>     defines the following terminology for its own use:
>
>     Enclosing Context
>        Textual representation of IPFIX data values is applied to use the
>        IPFIX Information Model within some existing textual format (e.g.
>        XML, JSON).   This outer format is referred to as the Enclosing

I can't parse that. Should it be, "A textual representation ..." ?


>        Context within this document.  Enclosing Contexts define escaping
>        and quoting rules for represented data values.
>
> 3.  Identifying Information Elements
>
>     The IPFIX Information Element Registry [iana-ipfix-assignments]
>     defines a set of Information Elementsand  numbered by Information

- "and"


>     Element Identifiers, and named for human-readability.  These
>     Information Element Identifiers are meant for use with the IPFIX
>     protocol, and have little meaning when applying the IPFIX Information
>     Element Registry to textual representations.
>
>     Instead, applications using textual representations of Information
>     ElementsSHOULD  use Information Element names to identify them; see
>     Appendix A for examples illustrating this principle.

It's a SHOULD rather than a MUST. Would the IE identifier numbers be 
equally as valid?


>
> 4.  Data Type Encodings
>
>     Each subsection of this section defines a textual encoding for the
>     abstract data types defined in [RFC7012].  This section uses ABNF
>     [RFC5234], including the Core Rules inAppendix B, to describe the
>     format of textual representations of IPFIX abstract data types.

It's unclear whether that's Appendix B of this document or of 5234.


>
> 4.1.  octetArray
>
>     If the Enclosing Context defines a representation for binary objects,
>     that representation SHOULD be used.
>
>     Otherwise,since the goal of textual representation of Information
>     Elements is readability over compactness,  the values of Information

This goal should be mentioned much earlier!


>     Elements of the octetArray data type are represented as a string of
>     pairs of hexadecimal digits, one pair per byte, in the order the
>     bytes would appear on the wire were the octetArray encoded directly
>     in IPFIX per [RFC7011].  Whitespace may occur between any pair of
>     digits to assist in human readability of the string, but is not
>     necessary, and must be disregarded by any process reading the string.
>     In ABNF:
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 3]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
>     hex-octet = 2HEXDIGIT
>
>     octetarray = 1* (hex-octet [WSP])

There's an implicit assumption of 8-bit bytes here.

An alternative encoding of "0b [10]*" (eg, 0b10101100) might sometimes 
be useful, eg for bitflags


> 4.2.  unsigned8, unsigned16, unsigned32, and unsigned64
>
>     If the Enclosing Context defines a representation for unsigned
>     integers, that representation SHOULD be used.
>
>     In the special case that the unsigned Information Element has
>     identifier semantics, and refers to a set of codepoints, either in an
>     external registry, a sub-registry, or directly in the description of
>     the Information Element, then the name or short description for that
>     codepoint MAY be used to improve readability.
>
>     Otherwise, the values of Information Elements of an unsigned integer
>     type may be represented either as unprefixed base-10 (decimal)
>     strings, or as base-16 (hexadecimal) strings prefixed by '0x'; in
>     ABNF:
>
>     unsigned = 1*DIGIT / '0x' 1*HEXDIG
>
>     Leading zeroes are allowed in either encoding, and do not signify
>     base-8 (octal) encoding.
>
>     The encoded value must be in range for the corresponding abstract
>     data type or Information Element.Out of range values should be
>     interpreted as clipped to the implicit range  for the Information

That would be another use case for the unobserved-fields draft: not 
available, insufficient data, or value is out of range.


>     Element as defined by the abstract data type, or to the explicit
>     range of the Information Element if defined.  Minimum and maximum
>     values for abstract data types are shown in Table 1 below.
>
>                +------------+---------+----------------------+
>                |       type | minimum |              maximum |
>                +------------+---------+----------------------+
>                |  unsigned8 |       0 |                  255 |
>                | unsigned16 |       0 |                65536 |
>                | unsigned32 |       0 |           4294967295 |
>                | unsigned64 |       0 | 18446744073709551615 |
>                +------------+---------+----------------------+
>
>               Table 1: Ranges for unsigned abstract data types

Consider comma-ising the values to make them easier to read?


>
> 4.3.  signed8, signed16, signed32, and signed64
>
>     If the Enclosing Context defines a representation for signed
>     integers, that representation SHOULD be used.
>
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 4]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
>     Otherwise, the values of Information Elements of signed integer types
>     should be represented as optionally-prefixed base-10 (decimal)
>     strings.  In ABNF:
>
>     sign = "+" / "-"
>
>     signed = [sign] 1*DIGIT
>
>     If the sign is omitted, it is assumed to be positive.  Leading zeroes
>     are allowed, and do not signify base-8 (octal) encoding.
>
>     The encoded value must be in range for the corresponding abstract
>     data type or Information Element.  Out of range values should be
>     interpreted as clipped to the implicit range for the Information
>     Element as defined by the abstract data type, or to the explicit
>     range of the Information Element if defined.  Minimum and maximum
>     values for abstract data types are shown in Table 2 below.
>
>          +----------+----------------------+----------------------+
>          |     type |              minimum |              maximum |
>          +----------+----------------------+----------------------+
>          |  signed8 |                 -128 |                 +127 |
>          | signed16 |               -32768 |               +32767 |
>          | signed32 |          -2147483648 |          +2147483647 |
>          | signed64 | -9223372036854775808 | +9223372036854775807 |
>          +----------+----------------------+----------------------+
>
>                Table 2: Ranges for signed abstract data types

Are +0, 0, and -0 all valid?


>
> 4.4.  float32 and float64
>
>     If the Enclosing Context defines a representation for floating point
>     numbers, that representation SHOULD be used.
>
>     Otherwise, the values of Information Elements of float32 or float64
>     types are represented as an optionally sign-prefixed, optionally
>     base-10 exponent-suffixed, floating point decimal number.  In ABNF:
>
>     sign = "+" / "-"
>
>     exponent = 'e' 1*3DIGIT
>
>     right-decimal = '.' 0*DIGIT
>
>     mantissa = 1*DIGIT [right-decimal]
>
>     float = [sign] mantissa [exponent]
>
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 5]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
>     The expressed value is ( mantissa * 10 ^ exponent ).  If the sign is
>     omitted, it is assumed to be positive.  If the exponent is omitted,
>     it is assumed to be zero.  Leading zeroes may appear in the mantissa
>     and/or the exponent.
>
>     Minimum and maximum values for abstract data types are shown in
>     Table3below.

Typo, "3 below".


>
>                 +---------+----------------+----------------+
>                 |    type | minimum abs(x) | maximum abs(x) |
>                 +---------+----------------+----------------+
>                 | float32 |      5.877e-39 |       3.403e38 |
>                 | float64 |    1.1125e-308 |     +1.798e308 |
>                 +---------+----------------+----------------+
>
>            Table 3: Ranges for floating-point abstract data types

It's not clear how you got these values. The minimum is surely zero, and 
the encoding doesn't allow negative exponents. I agree with the maximums.


> 4.5.  boolean
>
>     If the Enclosing Context defines a representation for boolean values,
>     that representation SHOULD be used.
>
>     Otherwise, a true boolean value should be represented with the
>     literal string 1, and a false boolean value with the literal string
>     0.  In ABNF:
>
>     boolean-yes = "1"
>
>     boolean-no = "0"
>
>     boolean = boolean-yes / boolean-no

Why 1/0 rather than true/false or yes/no ?


>
> 4.6.  macAddress
>
>     MAC addresses are represented as IEEE 802 MAC-48 addresses,
>     hexadecimal bytes, most significant byte first, separated by colons.
>     In ABNF, using the hex-octet production from Section 4.1:
>
>     macaddress = hex-octet 5( ":" hex-octet )
>
> 4.7.  string
>
>     As Information Elements of the string type are simply UTF-8 encoded
>     strings, they are represented directly, subject to the escaping and
>     encoding rules of the Enclosing Context.  If the Enclosing Context
>     cannot natively represent UTF-8 characters, the escaping facility
>     provided by the Enclosing Context must be used for non-representable
>     characters.  Additionally, strings containing characters reserved in
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 6]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
>     the Enclosing Context (e.g. markup characters, quotes) must be
>     escaped or quoted according to the rules of the Enclosing Context.
>
> 4.8.  dateTime*
>
>     Timestamp abstract data types are represented generally as in
>     [RFC3339], with two important differences.  First, all IPFIX
>     timestamps are expressed in terms of UTC, so textual representations
>     of these Information Elements areexplictly  in UTC as well.  Time

Typo, "explicitly".


>     zone offsets are therefore not required or supported.  Second, there
>     are four timestamp abstract data types, separated by the precision
>     which they can express.  Fractional seconds must be omitted in
>     dateTimeSeconds, expressed in milliseconds in dateTimeMilliseconds,
>     and so on.
>
>     In ABNF, taken from [RFC3339] and modified:
>
>     date-fullyear   = 4DIGIT
>     date-month      = 2DIGIT  ; 01-12
>     date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31
>     time-hour       = 2DIGIT  ; 00-23
>     time-minute     = 2DIGIT  ; 00-59
>     time-second     = 2DIGIT  ; 00-58, 00-59, 00-60
>     time-msec       = "." 3*DIGIT
>     time-usec       = "." 6*DIGIT
>     time-nsec       = "." 9*DIGIT
>     partial-time    = time-hour ":" time-minute ":" time-second
>
>     datetimeseconds      = full-date "T" partial-time
>     datetimemilliseconds = full-date "T" partial-time "." time-msec
>     datetimemicroseconds = full-date "T" partial-time "." time-usec
>     datetimenanoseconds  = full-date "T" partial-time "." time-nsec
>
> 4.9.  ipv4Address
>
>     IP version 4 addresses are represented in dotted-quad format, most-
>     significant-byte first, as it would in a Uniform Resource Identifier
>     [RFC3986]; the ABNF for an IPv4 address is taken from [RFC3986] and
>     reproduced below:
>
>     dec-octet   = DIGIT                 ; 0-9
>                 / %x31-39 DIGIT         ; 10-99
>                 / "1" 2DIGIT            ; 100-199
>                 / "2" %x30-34 DIGIT     ; 200-249
>                 / "25" %x30-35          ; 250-255
>
>     ipv4address = dec-octet 3("." dec-octet)

Note that the whitespace format here is different from all other uses in 
the document (eg, macaddress and ipv6address). For consistency it should 
be 3( "." dec-octet )


>
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 7]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
> 4.10.  ipv6Address
>
>     IP version 6 addresses are represented as in section 2.2 of
>     [RFC4291], as updated by section 4 of [RFC5952].  The ABNF for an
>     IPv6 address is taken from [RFC3986] and reproduced below:
>
>     ls32        = ( h16 ":" h16 ) / IPv4address
>                 ; least-significant 32 bits of address
>     h16         = 1*4HEXDIG
>                 ; 16 bits of address represented in hexadecimal
>                 ; zeroes to suppressed as in RFC 5952
>
>     ipv6address =                            6( h16 ":" ) ls32
>                 /                       "::" 5( h16 ":" ) ls32
>                 / [               h16 ] "::" 4( h16 ":" ) ls32
>                 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
>                 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
>                 / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
>                 / [ *4( h16 ":" ) h16 ] "::"              ls32
>                 / [ *5( h16 ":" ) h16 ] "::"              h16
>                 / [ *6( h16 ":" ) h16 ] "::"
>
> 4.11.  basicList, subTemplateList, and subTemplateMultiList
>
>     These abstract data types, defined for IPFIX Structured Data
>     [RFC6313], do not represent actual data types; they are instead
>     designed to provide a mechanism by which complex structure can be
>     represented in IPFIX below the template level.  It is assumed that
>     protocols using textual Information Element representation will
>     provide their own structure.  Therefore, Information Elements of
>     these Data Types MUST NOT be used in textual representations.
>
> 5.  Security Considerations
>
>     This document does not present any additional security measures
>     beyond those presented by [RFC7011].

security considerations != security measures.

The text usually reads something like, "No additional security 
considerations are introduced in this document. The same security 
considerations as for the IPFIX protocol [RFC7011] apply."


>
> 6.  IANA Considerations
>
>     This document has no considerations for IANA.
>
> 7.  References
>
> 7.1.  Normative References
>
>     [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
>                Internet: Timestamps", RFC 3339, July 2002.
>
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 8]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
>     [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
>                Resource Identifier (URI): Generic Syntax", STD 66, RFC
>                3986, January 2005.
>
>     [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
>                Architecture", RFC 4291, February 2006.
>
>     [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
>                Specifications: ABNF", STD 68, RFC 5234, January 2008.
>
>     [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
>                Address Text Representation", RFC 5952, August 2010.
>
>     [RFC7011]  Claise, B., Trammell, B., and P. Aitken, "Specification of
>                the IP Flow Information Export (IPFIX) Protocol for the
>                Exchange of Flow Information", STD 77, RFC 7011, September
>                2013.
>
>     [iana-ipfix-assignments]
>                Internet Assigned Numbers Authority, , "IP Flow
>                Information Export Information Elements
>                (http://www.iana.org/assignments/ipfix/ipfix.xml)",
>                November 2012.
>
> 7.2.  Informative References
>
>     [RFC6313]  Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
>                "Export of Structured Data in IP Flow Information Export
>                (IPFIX)", RFC 6313, July 2011.
>
>     [RFC7012]  Claise, B. and B. Trammell, "Information Model for IP Flow
>                Information Export (IPFIX)", RFC 7012, September 2013.
>
>     [RFC7013]  Trammell, B. and B. Claise, "Guidelines for Authors and
>                Reviewers of IP Flow Information Export (IPFIX)
>                Information Elements", BCP 184, RFC 7013, September 2013.
>
> Appendix A.  Example
>
>     In this section, we examine an IPFIX Template and a Data Record
>     defined by that Template, and show how that Data Record would be
>     represented in JSON according to the specification in this document.
>     Note that this is specifically NOT a recommendation for a particular
>     representation, merely an illustration of the encodings in this
>     document.
>
>     Figure 1 shows a Template in IESpec format as defined in section 10.1
>     of [RFC7013].  A Message containing this Template and a Data Record
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 9]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
>     is shown in Figure 2, and a corresponding JSON Object using the text
>     format defined in this document is shown in Figure 3.
>
>           flowStartMilliseconds(152)[8]
>           flowEndMilliseconds(153)[8]
>           octetDeltaCount(1)[4]
>           packetDeltaCount(2)[4]
>           sourceIPv6Address(27)[4]{key}
>           destinationIPv6Address(28)[4]{key}
>           sourceTransportPort(7)[2]{key}
>           destinationTransportPort(11)[2]{key}
>           protocolIdentifier(4)[1]{key}
>           tcpControlBits(6)[1]
>           flowEndReason(136)[1]
>
>                    Figure 1: Sample flow template (IPFIX)

Perhaps, "Sample IPFIX flow template in IESpec format"? Consider 
dropping the "IPFIX", since it's almost meaningless here.


>
>               1         2         3         4         5         6
>     0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | 0x000a        | length 135    | export time 1352140263        | msg
>    | sequence 0                    | domain 1                      | hdr
>    | SetID 2       | length 52     | tid 256       | fields 11     | tmpl
>    | IE 152        | length 8      | IE 153        | length 8      | set
>    | IE 1          | length 4      | IE 2          | length 4      |
>    | IE 27         | length 16     | IE 28         | length 16     |
>    | IE 7          | length 2      | IE 11         | length 2      |
>    | IE 4          | length 1      | IE 6          | length 1      |
>    | IE 136        | length 1      | SetID 256     | length 83     | data
>    | start time                                     1352140261135  | set
>    | end time                                       1352140262880  |
>    | octets                195383  | packets                   88  |
>    | sip6                                                          |
>    |                       2001:0db8:000c:1337:0000:0000:0000:0002 |
>    | dip6                                                          |
>    |                       2001:0db8:000c:1337:0000:0000:0000:0003 |
>    | sp        80  | dp     32991  | prt 6 | tcp 19| fe 3  |
>    +-------------------------------------------------------+

The figure is 63 chars wide rather than 64; each column is 15 chars wide.
It might be clearer to draw the usual 1-bit-per-column, 32-bit-wide figure.


>                Figure 2: IPFIX message containing sample flow

Is it still an IPFIX message?
Should message be capitalised?


>
>
>
>
>
>
>
>
>
>
>
> Trammell                  Expires July 24, 2014                [Page 10]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
>             {
>                 "flowStartMilliseconds": "2012-11-05T18:31:01.135",
>                 "flowEndMilliseconds": "2012-11-05T18:31:02.880",
>                 "octetDeltaCount": 195383,
>                 "packetDeltaCount": 88,
>                 "sourceIPv6Address": "2001:db8:c:1337::2",
>                 "destinationIPv6Address": "2001:db8:c:1337::3",
>                 "sourceTransportPort": 80,
>                 "destinationTransportPort": 32991,
>                 "protocolIdentifier": "tcp",
>                 "tcpControlBits": 19,
>                 "flowEndReason": 3
>             }
>
>                 Figure 3: JSON object containing sample flow

Note that the quoting, and colon/comma format are JSON specific.

P.


>
> Author's Address
>
>     Brian Trammell
>     Swiss Federal Institute of Technology Zurich
>     Gloriastrasse 35
>     8092 Zurich
>     Switzerland
>
>     Phone: +41 44 632 70 13
>     Email: trammell@tik.ee.ethz.ch
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Trammell                  Expires July 24, 2014                [Page 11]


--------------080001010103000305030000
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Dear all,

    

    Here's a review of draft-ietf-ipfix-text-adt-00.

    

    P.

    

    

    

    

      
      


IPFIX Working Group                                          B. Trammell
Internet-Draft                                                ETH Zurich
Intended status: Informational                          January 20, 2014
Expires: July 24, 2014


          Textual Representation of IPFIX Abstract Data Types
                    draft-ietf-ipfix-text-adt-00.txt

Abstract

   This document defines UTF-8 representations for IPFIX abstract data
   types, to support interoperable usage of the IPFIX Information
   Elements with protocols based on textual encodings.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 24, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Trammell                  Expires July 24, 2014                 [Page 1]

Internet-Draft              IPFIX Text Types                January 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Identifying Information Elements  . . . . . . . . . . . . . .   3
   4.  Data Type Encodings . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  octetArray  . . . . . . . . . . . . . . . . . . . . . . .   3
     4.2.  unsigned8, unsigned16, unsigned32, and unsigned64 . . . .   4
     4.3.  signed8, signed16, signed32, and signed64 . . . . . . . .   4
     4.4.  float32 and float64 . . . . . . . . . . . . . . . . . . .   5
     4.5.  boolean . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.6.  macAddress  . . . . . . . . . . . . . . . . . . . . . . .   6
     4.7.  string  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.8.  dateTime* . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.9.  ipv4Address . . . . . . . . . . . . . . . . . . . . . . .   7
     4.10. ipv6Address . . . . . . . . . . . . . . . . . . . . . . .   8
     4.11. basicList, subTemplateList, and subTemplateMultiList  . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Example  . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   The IPFIX Information Model, as defined by the IANA IPFIX Information
   Element Registry [iana-ipfix-assignments], provides a rich set of
   Information Elements for description of information about network
   entities and network traffic data, and abstract data types for these

    

    

      
   Information Elements.  The IPFIX Protocol Specification [RFC7011], in

    

    

    Perhaps, though it's not limited just to networks ;-)

    

    You're suggesting that the IANA registry is the reference for the
    ADTs, rather than 7012?

    7012 isn't mentioned until section 4.

    

    

    

      
   turn, defines a big-endian binary encoding for these abstract data
   types suitable for use with the IPFIX Protocol.

    

    

    +xref for the protocol spec?

    

    

    

      
   However, present and future operations and management protocols and
   applications may use textual encodings, and generic framing and
   structure as in JSON or XML.  A definition of canonical textual
   encodings for the IPFIX abstract data types would allow this set of
   Information Elements to be used for such applications, and for these
   applications to interoperate with IPFIX applications at the
   Information Element definition level.

   Note that templating or other mechanisms for data description for
   such applications and protocols are application specific, and
   therefore out of scope for this document: only Information Element
   identification and data value representation are defined here.




Trammell                  Expires July 24, 2014                 [Page 2]

Internet-Draft              IPFIX Text Types                January 2014


2.  Terminology

   Capitalized terms defined in the IPFIX Protocol Specification
   [RFC7011] and the IPFIX Information Model [RFC7012] are used in this
   document as defined in those documents.  In addition, this document
   defines the following terminology for its own use:

   Enclosing Context
      Textual representation of IPFIX data values is applied to use the
      IPFIX Information Model within some existing textual format (e.g.
      XML, JSON).  This outer format is referred to as the Enclosing

    

    

    I can't parse that. Should it be, "A
    textual representation ..." ?

    

    

    

      
      Context within this document.  Enclosing Contexts define escaping
      and quoting rules for represented data values.

3.  Identifying Information Elements

   The IPFIX Information Element Registry [iana-ipfix-assignments]
   defines a set of Information Elements and numbered by Information

    

    

    - "and"

    

    

    

      
   Element Identifiers, and named for human-readability.  These
   Information Element Identifiers are meant for use with the IPFIX
   protocol, and have little meaning when applying the IPFIX Information
   Element Registry to textual representations.

   Instead, applications using textual representations of Information
   Elements SHOULD use Information Element names to identify them; see
   Appendix A for examples illustrating this principle.

    

    

    It's a SHOULD rather than a MUST. Would the IE identifier numbers be
    equally as valid?

    

    

    

      

4.  Data Type Encodings

   Each subsection of this section defines a textual encoding for the
   abstract data types defined in [RFC7012].  This section uses ABNF
   [RFC5234], including the Core Rules in Appendix B, to describe the
   format of textual representations of IPFIX abstract data types.

    

    

    It's unclear whether that's Appendix B of this document or of 5234.

    

    

    

      

4.1.  octetArray

   If the Enclosing Context defines a representation for binary objects,
   that representation SHOULD be used.

   Otherwise, since the goal of textual representation of Information
   Elements is readability over compactness, the values of Information

    

    

    This goal should be mentioned much earlier!

    

    

    

      
   Elements of the octetArray data type are represented as a string of
   pairs of hexadecimal digits, one pair per byte, in the order the
   bytes would appear on the wire were the octetArray encoded directly
   in IPFIX per [RFC7011].  Whitespace may occur between any pair of
   digits to assist in human readability of the string, but is not
   necessary, and must be disregarded by any process reading the string.
   In ABNF:



Trammell                  Expires July 24, 2014                 [Page 3]

Internet-Draft              IPFIX Text Types                January 2014


   hex-octet = 2HEXDIGIT

   octetarray = 1* (hex-octet [WSP])

    

    

    There's an implicit assumption of 8-bit bytes here.

    

    An alternative encoding of "0b [10]*" (eg, 0b10101100) might
    sometimes be useful, eg for bitflags

    

    

    

      
4.2.  unsigned8, unsigned16, unsigned32, and unsigned64

   If the Enclosing Context defines a representation for unsigned
   integers, that representation SHOULD be used.

   In the special case that the unsigned Information Element has
   identifier semantics, and refers to a set of codepoints, either in an
   external registry, a sub-registry, or directly in the description of
   the Information Element, then the name or short description for that
   codepoint MAY be used to improve readability.

   Otherwise, the values of Information Elements of an unsigned integer
   type may be represented either as unprefixed base-10 (decimal)
   strings, or as base-16 (hexadecimal) strings prefixed by '0x'; in
   ABNF:

   unsigned = 1*DIGIT / '0x' 1*HEXDIG

   Leading zeroes are allowed in either encoding, and do not signify
   base-8 (octal) encoding.

   The encoded value must be in range for the corresponding abstract
   data type or Information Element.  Out of range values should be
   interpreted as clipped to the implicit range for the Information

    

    

    That would be another use case for the unobserved-fields draft: not
    available, insufficient data, or value is out of range.

    

    

    

      
   Element as defined by the abstract data type, or to the explicit
   range of the Information Element if defined.  Minimum and maximum
   values for abstract data types are shown in Table 1 below.

              +------------+---------+----------------------+
              |       type | minimum |              maximum |
              +------------+---------+----------------------+
              |  unsigned8 |       0 |                  255 |
              | unsigned16 |       0 |                65536 |
              | unsigned32 |       0 |           4294967295 |
              | unsigned64 |       0 | 18446744073709551615 |
              +------------+---------+----------------------+

             Table 1: Ranges for unsigned abstract data types

    

    

    Consider comma-ising the values to make them easier to read?

    

    

    

      

4.3.  signed8, signed16, signed32, and signed64

   If the Enclosing Context defines a representation for signed
   integers, that representation SHOULD be used.




Trammell                  Expires July 24, 2014                 [Page 4]

Internet-Draft              IPFIX Text Types                January 2014


   Otherwise, the values of Information Elements of signed integer types
   should be represented as optionally-prefixed base-10 (decimal)
   strings.  In ABNF:

   sign = "+" / "-"

   signed = [sign] 1*DIGIT

   If the sign is omitted, it is assumed to be positive.  Leading zeroes
   are allowed, and do not signify base-8 (octal) encoding.

   The encoded value must be in range for the corresponding abstract
   data type or Information Element.  Out of range values should be
   interpreted as clipped to the implicit range for the Information
   Element as defined by the abstract data type, or to the explicit
   range of the Information Element if defined.  Minimum and maximum
   values for abstract data types are shown in Table 2 below.

        +----------+----------------------+----------------------+
        |     type |              minimum |              maximum |
        +----------+----------------------+----------------------+
        |  signed8 |                 -128 |                 +127 |
        | signed16 |               -32768 |               +32767 |
        | signed32 |          -2147483648 |          +2147483647 |
        | signed64 | -9223372036854775808 | +9223372036854775807 |
        +----------+----------------------+----------------------+

              Table 2: Ranges for signed abstract data types

    

    

    Are +0, 0, and -0 all valid?

    

    

    

      

4.4.  float32 and float64

   If the Enclosing Context defines a representation for floating point
   numbers, that representation SHOULD be used.

   Otherwise, the values of Information Elements of float32 or float64
   types are represented as an optionally sign-prefixed, optionally
   base-10 exponent-suffixed, floating point decimal number.  In ABNF:

   sign = "+" / "-"

   exponent = 'e' 1*3DIGIT

   right-decimal = '.' 0*DIGIT

   mantissa = 1*DIGIT [right-decimal]

   float = [sign] mantissa [exponent]




Trammell                  Expires July 24, 2014                 [Page 5]

Internet-Draft              IPFIX Text Types                January 2014


   The expressed value is ( mantissa * 10 ^ exponent ).  If the sign is
   omitted, it is assumed to be positive.  If the exponent is omitted,
   it is assumed to be zero.  Leading zeroes may appear in the mantissa
   and/or the exponent.

   Minimum and maximum values for abstract data types are shown in
   Table 3below.

    

    

    Typo, "3 below".

    

    

    

      

               +---------+----------------+----------------+
               |    type | minimum abs(x) | maximum abs(x) |
               +---------+----------------+----------------+
               | float32 |      5.877e-39 |       3.403e38 |
               | float64 |    1.1125e-308 |     +1.798e308 |
               +---------+----------------+----------------+

          Table 3: Ranges for floating-point abstract data types

    

    

    It's not clear how you got these values. The minimum is surely zero,
    and the encoding doesn't allow negative exponents. I agree with the
    maximums.

    

    

    

      
4.5.  boolean

   If the Enclosing Context defines a representation for boolean values,
   that representation SHOULD be used.

   Otherwise, a true boolean value should be represented with the
   literal string 1, and a false boolean value with the literal string
   0.  In ABNF:

   boolean-yes = "1"

   boolean-no = "0"

   boolean = boolean-yes / boolean-no

    

    

    Why 1/0 rather than true/false or yes/no ?

    

    

    

      

4.6.  macAddress

   MAC addresses are represented as IEEE 802 MAC-48 addresses,
   hexadecimal bytes, most significant byte first, separated by colons.
   In ABNF, using the hex-octet production from Section 4.1:

   macaddress = hex-octet 5( ":" hex-octet )

4.7.  string

   As Information Elements of the string type are simply UTF-8 encoded
   strings, they are represented directly, subject to the escaping and
   encoding rules of the Enclosing Context.  If the Enclosing Context
   cannot natively represent UTF-8 characters, the escaping facility
   provided by the Enclosing Context must be used for non-representable
   characters.  Additionally, strings containing characters reserved in



Trammell                  Expires July 24, 2014                 [Page 6]

Internet-Draft              IPFIX Text Types                January 2014


   the Enclosing Context (e.g. markup characters, quotes) must be
   escaped or quoted according to the rules of the Enclosing Context.

4.8.  dateTime*

   Timestamp abstract data types are represented generally as in
   [RFC3339], with two important differences.  First, all IPFIX
   timestamps are expressed in terms of UTC, so textual representations
   of these Information Elements are explictly in UTC as well.  Time

    

    

    Typo, "explicitly".

    

    

    

      
   zone offsets are therefore not required or supported.  Second, there
   are four timestamp abstract data types, separated by the precision
   which they can express.  Fractional seconds must be omitted in
   dateTimeSeconds, expressed in milliseconds in dateTimeMilliseconds,
   and so on.

   In ABNF, taken from [RFC3339] and modified:

   date-fullyear   = 4DIGIT
   date-month      = 2DIGIT  ; 01-12
   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31
   time-hour       = 2DIGIT  ; 00-23
   time-minute     = 2DIGIT  ; 00-59
   time-second     = 2DIGIT  ; 00-58, 00-59, 00-60
   time-msec       = "." 3*DIGIT
   time-usec       = "." 6*DIGIT
   time-nsec       = "." 9*DIGIT
   partial-time    = time-hour ":" time-minute ":" time-second

   datetimeseconds      = full-date "T" partial-time
   datetimemilliseconds = full-date "T" partial-time "." time-msec
   datetimemicroseconds = full-date "T" partial-time "." time-usec
   datetimenanoseconds  = full-date "T" partial-time "." time-nsec

4.9.  ipv4Address

   IP version 4 addresses are represented in dotted-quad format, most-
   significant-byte first, as it would in a Uniform Resource Identifier
   [RFC3986]; the ABNF for an IPv4 address is taken from [RFC3986] and
   reproduced below:

   dec-octet   = DIGIT                 ; 0-9
               / %x31-39 DIGIT         ; 10-99
               / "1" 2DIGIT            ; 100-199
               / "2" %x30-34 DIGIT     ; 200-249
               / "25" %x30-35          ; 250-255

   ipv4address = dec-octet 3("." dec-octet)

    

    

    Note that the whitespace format here is different from all other
    uses in the document (eg, macaddress and ipv6address). For
    consistency it should be 3( "." dec-octet )
    

    

    

    

      




Trammell                  Expires July 24, 2014                 [Page 7]

Internet-Draft              IPFIX Text Types                January 2014


4.10.  ipv6Address

   IP version 6 addresses are represented as in section 2.2 of
   [RFC4291], as updated by section 4 of [RFC5952].  The ABNF for an
   IPv6 address is taken from [RFC3986] and reproduced below:

   ls32        = ( h16 ":" h16 ) / IPv4address
               ; least-significant 32 bits of address
   h16         = 1*4HEXDIG
               ; 16 bits of address represented in hexadecimal
               ; zeroes to suppressed as in RFC 5952

   ipv6address =                            6( h16 ":" ) ls32
               /                       "::" 5( h16 ":" ) ls32
               / [               h16 ] "::" 4( h16 ":" ) ls32
               / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
               / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
               / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
               / [ *4( h16 ":" ) h16 ] "::"              ls32
               / [ *5( h16 ":" ) h16 ] "::"              h16
               / [ *6( h16 ":" ) h16 ] "::"

4.11.  basicList, subTemplateList, and subTemplateMultiList

   These abstract data types, defined for IPFIX Structured Data
   [RFC6313], do not represent actual data types; they are instead
   designed to provide a mechanism by which complex structure can be
   represented in IPFIX below the template level.  It is assumed that
   protocols using textual Information Element representation will
   provide their own structure.  Therefore, Information Elements of
   these Data Types MUST NOT be used in textual representations.

5.  Security Considerations

   This document does not present any additional security measures
   beyond those presented by [RFC7011].

    

    

    security considerations != security measures.

    

    The text usually reads something like, "No additional security
    considerations are introduced in this document. The same security
    considerations as for the IPFIX protocol [RFC7011] apply."

    

    

    

      

6.  IANA Considerations

   This document has no considerations for IANA.

7.  References

7.1.  Normative References

   [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
              Internet: Timestamps", RFC 3339, July 2002.




Trammell                  Expires July 24, 2014                 [Page 8]

Internet-Draft              IPFIX Text Types                January 2014


   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
              Address Text Representation", RFC 5952, August 2010.

   [RFC7011]  Claise, B., Trammell, B., and P. Aitken, "Specification of
              the IP Flow Information Export (IPFIX) Protocol for the
              Exchange of Flow Information", STD 77, RFC 7011, September
              2013.

   [iana-ipfix-assignments]
              Internet Assigned Numbers Authority, , "IP Flow
              Information Export Information Elements
              (http://www.iana.org/assignments/ipfix/ipfix.xml)",
              November 2012.

7.2.  Informative References

   [RFC6313]  Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
              "Export of Structured Data in IP Flow Information Export
              (IPFIX)", RFC 6313, July 2011.

   [RFC7012]  Claise, B. and B. Trammell, "Information Model for IP Flow
              Information Export (IPFIX)", RFC 7012, September 2013.

   [RFC7013]  Trammell, B. and B. Claise, "Guidelines for Authors and
              Reviewers of IP Flow Information Export (IPFIX)
              Information Elements", BCP 184, RFC 7013, September 2013.

Appendix A.  Example

   In this section, we examine an IPFIX Template and a Data Record
   defined by that Template, and show how that Data Record would be
   represented in JSON according to the specification in this document.
   Note that this is specifically NOT a recommendation for a particular
   representation, merely an illustration of the encodings in this
   document.

   Figure 1 shows a Template in IESpec format as defined in section 10.1
   of [RFC7013].  A Message containing this Template and a Data Record



Trammell                  Expires July 24, 2014                 [Page 9]

Internet-Draft              IPFIX Text Types                January 2014


   is shown in Figure 2, and a corresponding JSON Object using the text
   format defined in this document is shown in Figure 3.

         flowStartMilliseconds(152)<dateTimeMilliseconds>[8]
         flowEndMilliseconds(153)<dateTimeMilliseconds>[8]
         octetDeltaCount(1)<unsigned64>[4]
         packetDeltaCount(2)<unsigned64>[4]
         sourceIPv6Address(27)<ipv4Address>[4]{key}
         destinationIPv6Address(28)<ipv4Address>[4]{key}
         sourceTransportPort(7)<unsigned16>[2]{key}
         destinationTransportPort(11)<unsigned16>[2]{key}
         protocolIdentifier(4)<unsigned8>[1]{key}
         tcpControlBits(6)<unsigned8>[1]
         flowEndReason(136)<unsigned8>[1]

                  Figure 1: Sample flow template (IPFIX)

    

    

    Perhaps, "Sample IPFIX flow template in IESpec format"? Consider
    dropping the "IPFIX", since it's almost meaningless here.

    

    

    

      

             1         2         3         4         5         6
   0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | 0x000a        | length 135    | export time 1352140263        | msg
  | sequence 0                    | domain 1                      | hdr
  | SetID 2       | length 52     | tid 256       | fields 11     | tmpl
  | IE 152        | length 8      | IE 153        | length 8      | set
  | IE 1          | length 4      | IE 2          | length 4      |
  | IE 27         | length 16     | IE 28         | length 16     |
  | IE 7          | length 2      | IE 11         | length 2      |
  | IE 4          | length 1      | IE 6          | length 1      |
  | IE 136        | length 1      | SetID 256     | length 83     | data
  | start time                                     1352140261135  | set
  | end time                                       1352140262880  |
  | octets                195383  | packets                   88  |
  | sip6                                                          |
  |                       2001:0db8:000c:1337:0000:0000:0000:0002 |
  | dip6                                                          |
  |                       2001:0db8:000c:1337:0000:0000:0000:0003 |
  | sp        80  | dp     32991  | prt 6 | tcp 19| fe 3  |
  +-------------------------------------------------------+


    

    

    The figure is 63 chars wide rather than 64; each column is 15 chars
    wide.

    It might be clearer to draw the usual 1-bit-per-column, 32-bit-wide
    figure.

    

    

    

      
              Figure 2: IPFIX message containing sample flow

    

    

    Is it still an IPFIX message?

    Should message be capitalised?

    

    

    

      











Trammell                  Expires July 24, 2014                [Page 10]

Internet-Draft              IPFIX Text Types                January 2014


           {
               "flowStartMilliseconds": "2012-11-05T18:31:01.135",
               "flowEndMilliseconds": "2012-11-05T18:31:02.880",
               "octetDeltaCount": 195383,
               "packetDeltaCount": 88,
               "sourceIPv6Address": "2001:db8:c:1337::2",
               "destinationIPv6Address": "2001:db8:c:1337::3",
               "sourceTransportPort": 80,
               "destinationTransportPort": 32991,
               "protocolIdentifier": "tcp",
               "tcpControlBits": 19,
               "flowEndReason": 3
           }

               Figure 3: JSON object containing sample flow

    

    

    Note that the quoting, and colon/comma format are JSON specific.

    

    P.

    

    

    

      

Author's Address

   Brian Trammell
   Swiss Federal Institute of Technology Zurich
   Gloriastrasse 35
   8092 Zurich
   Switzerland

   Phone: +41 44 632 70 13
   Email: trammell@tik.ee.ethz.ch

























Trammell                  Expires July 24, 2014                [Page 11]


    

    

  


--------------080001010103000305030000--

From andrewf@plixer.com  Tue Jan 28 07:05:21 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566E71A03B6 for ; Tue, 28 Jan 2014 07:05:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.434
X-Spam-Level: 
X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uq5vP-UbRpqq for ; Tue, 28 Jan 2014 07:05:19 -0800 (PST)
Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2B01A03B7 for ; Tue, 28 Jan 2014 07:05:18 -0800 (PST)
Received: from [10.1.15.178] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 10:05:14 -0500
Message-ID: <52E7C72D.8020208@plixer.com>
Date: Tue, 28 Jan 2014 10:05:17 -0500
From: Andrew Feren 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Paul Aitken , Brian Trammell ,  "ipfix@ietf.org" 
References: <9AB93E4127C26F4BA7829DEFDCE5A6E868910E0D@DAPHNIS.office.hd> <52E7BFCE.8080701@cisco.com>
In-Reply-To: <52E7BFCE.8080701@cisco.com>
Content-Type: multipart/alternative; boundary="------------000801060805040906010304"
Subject: Re: [IPFIX] WGLC for draft-ietf-ipfix-text-adt-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jan 2014 15:05:21 -0000

--------------000801060805040906010304
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Hi all,

On 01/28/2014 09:33 AM, Paul Aitken wrote:
> Dear all,
>
> Here's a review of draft-ietf-ipfix-text-adt-00.
>
> P.
>
>
[ snip ]
>> 4.5.  boolean
>>
>>    If the Enclosing Context defines a representation for boolean values,
>>    that representation SHOULD be used.
>>
>>    Otherwise, a true boolean value should be represented with the
>>    literal string 1, and a false boolean value with the literal string
>>    0.  In ABNF:
>>
>>    boolean-yes = "1"
>>
>>    boolean-no = "0"
>>
>>    boolean = boolean-yes / boolean-no
>
> Why 1/0 rather than true/false or yes/no ?

Also why the departure from 1 for true and 2 for false in RFC 7011.

"
6.1.5.  boolean

   The boolean data type is specified according to the TruthValue in
   [RFC2579].  It is encoded as a single-octet integer per
   Section 6.1.1, with the value 1 for true and value 2 for false.
   Every other value is undefined."

1 and 2 aren't what I would have picked, but changing it up here only
seems to create potential confusion.

As for why not true/false, I'm all in favor of a single encoding, but we
already have IEs where 'Possible values are: { "yes", "y", 1 }, { "no",
"n", 2 } and { "unassigned", "u", 0 }.'  (As an aside does anyone know
why so many options anyways?)

-Andrew

--------------000801060805040906010304
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi all,

      

      On 01/28/2014 09:33 AM, Paul Aitken wrote:

    

    

      
      Dear all,

      

      Here's a review of draft-ietf-ipfix-text-adt-00.

      

      P.

      

      

    

    [ snip ]

    

      

        
4.5.  boolean

   If the Enclosing Context defines a representation for boolean values,
   that representation SHOULD be used.

   Otherwise, a true boolean value should be represented with the
   literal string 1, and a false boolean value with the literal string
   0.  In ABNF:

   boolean-yes = "1"

   boolean-no = "0"

   boolean = boolean-yes / boolean-no

      

      

      Why 1/0 rather than true/false or yes/no ?

    

    

    Also why the departure from 1 for true and 2 for false in RFC 7011.

    

    "

    6.1.5.  boolean

    

       The boolean data type is specified according to the TruthValue in

       [RFC2579].  It is encoded as a single-octet integer per

       Section 6.1.1, with the value 1 for true and value 2 for false.

       Every other value is undefined."

    

    1 and 2 aren't what I would have picked, but changing it up here
    only seems to create potential confusion.

    

    As for why not true/false, I'm all in favor of a single encoding,
    but we already have IEs where 'Possible values are: { "yes", "y", 1
    }, { "no", "n", 2 } and { "unassigned", "u", 0 }.'  (As an aside
    does anyone know why so many options anyways?)

    

    -Andrew

  


--------------000801060805040906010304--

From trammell@tik.ee.ethz.ch  Tue Jan 28 07:47:37 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FCC1A0269 for ; Tue, 28 Jan 2014 07:47:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.735
X-Spam-Level: 
X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwOU9nHJhUBF for ; Tue, 28 Jan 2014 07:47:35 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id BB0FF1A0271 for ; Tue, 28 Jan 2014 07:47:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id DE28AD9304; Tue, 28 Jan 2014 16:47:31 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Up+aZnAb-gMZ; Tue, 28 Jan 2014 16:47:31 +0100 (MET)
Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 550B9D9303; Tue, 28 Jan 2014 16:47:31 +0100 (MET)
Content-Type: multipart/signed; boundary="Apple-Mail=_820E3B06-D900-4686-8D7E-2E44C9261AAF"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Brian Trammell 
In-Reply-To: <52E7C72D.8020208@plixer.com>
Date: Tue, 28 Jan 2014 16:47:31 +0100
Message-Id: 
References: <9AB93E4127C26F4BA7829DEFDCE5A6E868910E0D@DAPHNIS.office.hd> <52E7BFCE.8080701@cisco.com> <52E7C72D.8020208@plixer.com>
To: Andrew Feren 
X-Mailer: Apple Mail (2.1827)
Cc: "ipfix@ietf.org" 
Subject: Re: [IPFIX] WGLC for draft-ietf-ipfix-text-adt-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jan 2014 15:47:38 -0000

--Apple-Mail=_820E3B06-D900-4686-8D7E-2E44C9261AAF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi Andrew, Paul,

I=92ll answer this one first since it=92s easy. :)

On 28 Jan 2014, at 16:05, Andrew Feren  wrote:

> Hi all,
>=20
> On 01/28/2014 09:33 AM, Paul Aitken wrote:
>> Dear all,
>>=20
>> Here's a review of draft-ietf-ipfix-text-adt-00.
>>=20
>> P.
>>=20
>>=20
> [ snip ]
>>> 4.5.  boolean
>>>=20
>>>    If the Enclosing Context defines a representation for boolean =
values,
>>>    that representation SHOULD be used.
>>>=20
>>>    Otherwise, a true boolean value should be represented with the
>>>    literal string 1, and a false boolean value with the literal =
string
>>>    0.  In ABNF:
>>>=20
>>>    boolean-yes =3D "1"
>>>=20
>>>    boolean-no =3D "0"
>>>=20
>>>    boolean =3D boolean-yes / boolean-no
>>=20
>> Why 1/0 rather than true/false or yes/no ?

Internationalization, mainly.=20

> Also why the departure from 1 for true and 2 for false in RFC 7011.

Because these are just wrong. I know we inherited them from SNMP. They =
were wrong there too.

In a textual format, which humans might have occasion to read and write, =
requiring =932=94 to mean =93false=94 is just _asking_ for confusion, =
much more so than departing from the binary encoding of IPFIX.

Cheers,

Brian

> "
> 6.1.5.  boolean
>=20
>    The boolean data type is specified according to the TruthValue in
>    [RFC2579].  It is encoded as a single-octet integer per
>    Section 6.1.1, with the value 1 for true and value 2 for false.
>    Every other value is undefined."
>=20
> 1 and 2 aren't what I would have picked, but changing it up here only =
seems to create potential confusion.
>=20
> As for why not true/false, I'm all in favor of a single encoding, but =
we already have IEs where 'Possible values are: { "yes", "y", 1 }, { =
"no", "n", 2 } and { "unassigned", "u", 0 }.'  (As an aside does anyone =
know why so many options anyways?)
>=20
> -Andrew


--Apple-Mail=_820E3B06-D900-4686-8D7E-2E44C9261AAF
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJS59ETAAoJENt3nsOmbNJcMBEH/3f4r38hxCBah5PiaVXNkmyg
/ZjkdANVsxXNb2PW5q1RReVdpdxI9JC3uRQtVNYiTfdjJZ0vVq7Y6KpvByHJn/8L
8fuY3KBfAnBp5maGSo32HLUy60wagCDj3nI++Y2vMiEhJAwdkSUxSGLMBATEVvP9
H7FIpakbuj5ghQtADRSXfpMU6+WSen3O4pBuAQH/BTD8pEOMuNH/tgdMZtciCChd
xBGvmz/i+e+03SMpbDAt47L9N5+20NypYjhgIMn+03MxomTIxjDwFGwmFsoufwbh
0YN+m0QvrYTT8oqMzkscGgjJVGHQ0vaAxhtPVorKHXV98LJmY90jomudDHgERfY=
=HbYR
-----END PGP SIGNATURE-----

--Apple-Mail=_820E3B06-D900-4686-8D7E-2E44C9261AAF--

From paitken@cisco.com  Tue Jan 28 08:09:44 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D991A023D for ; Tue, 28 Jan 2014 08:09:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level: 
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fOXmz8sXh3F for ; Tue, 28 Jan 2014 08:09:42 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id E9B8E1A027C for ; Tue, 28 Jan 2014 08:09:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4645; q=dns/txt; s=iport; t=1390925379; x=1392134979; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=CvTGEiHazD6QXmYtjuxCr9d1wkukLxC5TLPL5Lqm54o=; b=ExMnh1wHKWU6wmH2mJdiHAV+NDbYb/doQdBleo49WRcuL4f48EfPFUnM mFjf4eS249+DqUdEMhKEK5NYQc6FmG8wGEpnPHM/O4PxxljlO55xHvjvJ 311VLmdTDi4fWkKd8xmIgL/6WRhafOksQVHRekdh/SL05xG0lKXYYgepw A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FAJjV51KQ/khM/2dsb2JhbABagwy6YYMGgRAWdIIlAQEBBHgRCwQUCRYPCQMCAQIBRQYBDAgBAYgByggXjwaEOASYKIZIi1eDLQ
X-IronPort-AV: E=Sophos;i="4.95,736,1384300800"; d="scan'208,217";a="4309351"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 28 Jan 2014 16:09:37 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0SG9btb027638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jan 2014 16:09:37 GMT
Received: from [10.147.1.39] (dhcp-10-147-1-39.cisco.com [10.147.1.39]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0SG9Z3p020556; Tue, 28 Jan 2014 16:09:37 GMT
Message-ID: <52E7D63F.8000404@cisco.com>
Date: Tue, 28 Jan 2014 16:09:35 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Andrew Feren , Brian Trammell , "ipfix@ietf.org" 
References: <9AB93E4127C26F4BA7829DEFDCE5A6E868910E0D@DAPHNIS.office.hd> <52E7BFCE.8080701@cisco.com> <52E7C72D.8020208@plixer.com>
In-Reply-To: <52E7C72D.8020208@plixer.com>
Content-Type: multipart/alternative; boundary="------------050700000708090704050407"
Subject: Re: [IPFIX] WGLC for draft-ietf-ipfix-text-adt-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jan 2014 16:09:44 -0000

This is a multi-part message in MIME format.
--------------050700000708090704050407
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


FYI, 1 and 2 are used for MIB TruthValue.

Also 0 is often used as a "don't know", so 1/2 avoids any ambiguity.

P.


On 28/01/2014 15:05, Andrew Feren wrote:
> Hi all,
>
> On 01/28/2014 09:33 AM, Paul Aitken wrote:
>> Dear all,
>>
>> Here's a review of draft-ietf-ipfix-text-adt-00.
>>
>> P.
>>
>>
> [ snip ]
>>> 4.5.  boolean
>>>
>>>     If the Enclosing Context defines a representation for boolean values,
>>>     that representation SHOULD be used.
>>>
>>>     Otherwise, a true boolean value should be represented with the
>>>     literal string 1, and a false boolean value with the literal string
>>>     0.  In ABNF:
>>>
>>>     boolean-yes = "1"
>>>
>>>     boolean-no = "0"
>>>
>>>     boolean = boolean-yes / boolean-no
>>
>> Why 1/0 rather than true/false or yes/no ?
>
> Also why the departure from 1 for true and 2 for false in RFC 7011.
>
> "
> 6.1.5.  boolean
>
>    The boolean data type is specified according to the TruthValue in
>    [RFC2579].  It is encoded as a single-octet integer per
>    Section 6.1.1, with the value 1 for true and value 2 for false.
>    Every other value is undefined."
>
> 1 and 2 aren't what I would have picked, but changing it up here only 
> seems to create potential confusion.
>
> As for why not true/false, I'm all in favor of a single encoding, but 
> we already have IEs where 'Possible values are: { "yes", "y", 1 }, { 
> "no", "n", 2 } and { "unassigned", "u", 0 }.'  (As an aside does 
> anyone know why so many options anyways?)
>
> -Andrew


--------------050700000708090704050407
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    


      FYI, 1 and 2 are used for MIB TruthValue.

      

      Also 0 is often used as a "don't know", so 1/2 avoids any
      ambiguity.

      

      P.

      

      

      On 28/01/2014 15:05, Andrew Feren wrote:

    

    

      
      
Hi all,

        

        On 01/28/2014 09:33 AM, Paul Aitken wrote:

      

      

        
        Dear all,

        

        Here's a review of draft-ietf-ipfix-text-adt-00.

        

        P.

        

        

      

      [ snip ]

      

        

          
4.5.  boolean

   If the Enclosing Context defines a representation for boolean values,
   that representation SHOULD be used.

   Otherwise, a true boolean value should be represented with the
   literal string 1, and a false boolean value with the literal string
   0.  In ABNF:

   boolean-yes = "1"

   boolean-no = "0"

   boolean = boolean-yes / boolean-no

        

        

        Why 1/0 rather than true/false or yes/no ?

      

      

      Also why the departure from 1 for true and 2 for false in RFC
      7011.

      

      "

      6.1.5.  boolean

      

         The boolean data type is specified according to the TruthValue
      in

         [RFC2579].  It is encoded as a single-octet integer per

         Section 6.1.1, with the value 1 for true and value 2 for false.

         Every other value is undefined."

      

      1 and 2 aren't what I would have picked, but changing it up here
      only seems to create potential confusion.

      

      As for why not true/false, I'm all in favor of a single encoding,
      but we already have IEs where 'Possible values are: { "yes", "y",
      1 }, { "no", "n", 2 } and { "unassigned", "u", 0 }.'  (As an aside
      does anyone know why so many options anyways?)

      

      -Andrew

    

    

  


--------------050700000708090704050407--

From trammell@tik.ee.ethz.ch  Tue Jan 28 08:27:28 2014
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251601A045C for ; Tue, 28 Jan 2014 08:27:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_EPERTEEyZN for ; Tue, 28 Jan 2014 08:27:21 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 059251A0449 for ; Tue, 28 Jan 2014 08:27:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 199B1D9305; Tue, 28 Jan 2014 17:27:18 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sJNYsirPWQ13; Tue, 28 Jan 2014 17:27:17 +0100 (MET)
Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 78443D9303; Tue, 28 Jan 2014 17:27:17 +0100 (MET)
Content-Type: multipart/signed; boundary="Apple-Mail=_9677CE3B-CD71-45C0-938C-EDF02415B696"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Brian Trammell 
In-Reply-To: <52E7BFCE.8080701@cisco.com>
Date: Tue, 28 Jan 2014 17:27:16 +0100
Message-Id: <5800070C-5754-4CEB-A343-9AD65A5543A1@tik.ee.ethz.ch>
References: <9AB93E4127C26F4BA7829DEFDCE5A6E868910E0D@DAPHNIS.office.hd> <52E7BFCE.8080701@cisco.com>
To: Paul Aitken 
X-Mailer: Apple Mail (2.1827)
Cc: "ipfix@ietf.org" 
Subject: Re: [IPFIX] WGLC for draft-ietf-ipfix-text-adt-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jan 2014 16:27:28 -0000

--Apple-Mail=_9677CE3B-CD71-45C0-938C-EDF02415B696
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_1E268C6A-AF62-4490-893A-568EC66F785D"


--Apple-Mail=_1E268C6A-AF62-4490-893A-568EC66F785D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

hi Paul,

many thanks for the review! Will put these on the list for a post-wglc =
-01 revision; have snipped those I accept without comment from the =
following, with commentcomments inline...

On 28 Jan 2014, at 15:33, Paul Aitken  wrote:
>> 1.  Introduction
>>=20
>>    The IPFIX Information Model, as defined by the IANA IPFIX =
Information
>>    Element Registry [iana-ipfix-assignments], provides a rich set of
>>    Information Elements for description of information about network
>>    entities and network traffic data, and abstract data types for =
these
>>    Information Elements.  The IPFIX Protocol Specification [RFC7011], =
in
>=20
> Perhaps, though it's not limited just to networks ;-)

The protocol no, the information model is presently

> You're suggesting that the IANA registry is the reference for the =
ADTs, rather than 7012?
> 7012 isn't mentioned until section 4.

I am, and that=92s incorrect. I=92ll correct this:

The IPFIX Information Model [RFC 7012] provides a set of abstract data =
types for the IPFIX Information Element Registry [IANA-IPFIX], which in =
turn contains a rich set of...
>>    turn, defines a big-endian binary encoding for these abstract data
>>    types suitable for use with the IPFIX Protocol.
>=20
> +xref for the protocol spec?

Hm? Already cited [RFC7011] in this sentence.

>>    However, present and future operations and management protocols =
and
>>    applications may use textual encodings, and generic framing and
>>    structure as in JSON or XML.  A definition of canonical textual
>>    encodings for the IPFIX abstract data types would allow this set =
of
>>    Information Elements to be used for such applications, and for =
these
>>    applications to interoperate with IPFIX applications at the
>>    Information Element definition level.
>>=20
>>    Note that templating or other mechanisms for data description for
>>    such applications and protocols are application specific, and
>>    therefore out of scope for this document: only Information Element
>>    identification and data value representation are defined here.
>>=20
>>=20
>>=20
>>=20
>> Trammell                  Expires July 24, 2014                 [Page =
2]
>> =0C
>> Internet-Draft              IPFIX Text Types                January =
2014
>>=20
>>=20
>> 2.  Terminology
>>=20
>>    Capitalized terms defined in the IPFIX Protocol Specification
>>    [RFC7011] and the IPFIX Information Model [RFC7012] are used in =
this
>>    document as defined in those documents.  In addition, this =
document
>>    defines the following terminology for its own use:
>>=20
>>    Enclosing Context
>>       Textual representation of IPFIX data values is applied to use =
the
>>       IPFIX Information Model within some existing textual format =
(e.g.
>>       XML, JSON).  This outer format is referred to as the Enclosing
>=20
> I can't parse that. Should it be, "A textual representation ...=94 ?

Yes it should. (I tried to write this such that the first sentence could =
be a definition rather than just exposition, but wasn=92t able to come =
up with anything that was less awkward than this.)



>>=20
>>    Instead, applications using textual representations of Information
>>    Elements SHOULD use Information Element names to identify them; =
see
>>    Appendix A for examples illustrating this principle.
>=20
> It's a SHOULD rather than a MUST. Would the IE identifier numbers be =
equally as valid?

Hm. Not equally valid, but not invalid (consider an application =
transcoding IPFIX to JSON that only had number information because some =
lazy exporter vendor didn=92t stick 5610 data in the stream). And I =
didn=92t want to MUST this here because I could also think of situations =
where a text representation handled Information Element values =
positionally. The point here is just to define the ADT representations =
in an interoperable way, not to cover every possible application =
therefor.

>> 4.  Data Type Encodings
>>=20
>>    Each subsection of this section defines a textual encoding for the
>>    abstract data types defined in [RFC7012].  This section uses ABNF
>>    [RFC5234], including the Core Rules in Appendix B, to describe the
>>    format of textual representations of IPFIX abstract data types.
>=20
> It's unclear whether that's Appendix B of this document or of 5234.

Of 5234, will fix.
>>=20
>> 4.1.  octetArray
>>=20
>>    If the Enclosing Context defines a representation for binary =
objects,
>>    that representation SHOULD be used.
>>=20
>>    Otherwise, since the goal of textual representation of Information
>>    Elements is readability over compactness, the values of =
Information
>=20
> This goal should be mentioned much earlier!

Indeed, will move to introduction.
>>    Elements of the octetArray data type are represented as a string =
of
>>    pairs of hexadecimal digits, one pair per byte, in the order the
>>    bytes would appear on the wire were the octetArray encoded =
directly
>>    in IPFIX per [RFC7011].  Whitespace may occur between any pair of
>>    digits to assist in human readability of the string, but is not
>>    necessary, and must be disregarded by any process reading the =
string.
>>    In ABNF:
>>=20
>>=20
>>=20
>> Trammell                  Expires July 24, 2014                 [Page =
3]
>> =0C
>> Internet-Draft              IPFIX Text Types                January =
2014
>>=20
>>=20
>>    hex-octet =3D 2HEXDIGIT
>>=20
>>    octetarray =3D 1* (hex-octet [WSP])
>=20
> There's an implicit assumption of 8-bit bytes here.

Also in the name of the abstract data type: =93octet=94 means group of =
eight bits, so I=92m happy sticking with this assumption.

> An alternative encoding of "0b [10]*" (eg, 0b10101100) might sometimes =
be useful, eg for bitflags

Good point. Flags are usually implemented as unsigned, so we=92d want to =
add binary there too as well.


>> 4.3.  signed8, signed16, signed32, and signed64
>>=20
>>    If the Enclosing Context defines a representation for signed
>>    integers, that representation SHOULD be used.
>>=20
>>=20
>>=20
>>=20
>> Trammell                  Expires July 24, 2014                 [Page =
4]
>> =0C
>> Internet-Draft              IPFIX Text Types                January =
2014
>>=20
>>=20
>>    Otherwise, the values of Information Elements of signed integer =
types
>>    should be represented as optionally-prefixed base-10 (decimal)
>>    strings.  In ABNF:
>>=20
>>    sign =3D "+" / "-"
>>=20
>>    signed =3D [sign] 1*DIGIT
>>=20
>>    If the sign is omitted, it is assumed to be positive.  Leading =
zeroes
>>    are allowed, and do not signify base-8 (octal) encoding.
>>=20
>>    The encoded value must be in range for the corresponding abstract
>>    data type or Information Element.  Out of range values should be
>>    interpreted as clipped to the implicit range for the Information
>>    Element as defined by the abstract data type, or to the explicit
>>    range of the Information Element if defined.  Minimum and maximum
>>    values for abstract data types are shown in Table 2 below.
>>=20
>>         +----------+----------------------+----------------------+
>>         |     type |              minimum |              maximum |
>>         +----------+----------------------+----------------------+
>>         |  signed8 |                 -128 |                 +127 |
>>         | signed16 |               -32768 |               +32767 |
>>         | signed32 |          -2147483648 |          +2147483647 |
>>         | signed64 | -9223372036854775808 | +9223372036854775807 |
>>         +----------+----------------------+----------------------+
>>=20
>>               Table 2: Ranges for signed abstract data types
>=20
> Are +0, 0, and -0 all valid?

As long as they=92re treated to be equal, yes.

>>=20
>> 4.4.  float32 and float64
>>=20
>>    If the Enclosing Context defines a representation for floating =
point
>>    numbers, that representation SHOULD be used.
>>=20
>>    Otherwise, the values of Information Elements of float32 or =
float64
>>    types are represented as an optionally sign-prefixed, optionally
>>    base-10 exponent-suffixed, floating point decimal number.  In =
ABNF:
>>=20
>>    sign =3D "+" / "-"
>>=20
>>    exponent =3D 'e' 1*3DIGIT
>>=20
>>    right-decimal =3D '.' 0*DIGIT
>>=20
>>    mantissa =3D 1*DIGIT [right-decimal]
>>=20
>>    float =3D [sign] mantissa [exponent]

There=92s an error here: exponent should be =91e=92 [sign] 1*3DIGIT (see =
below)
>>=20
>>                +---------+----------------+----------------+
>>                |    type | minimum abs(x) | maximum abs(x) |
>>                +---------+----------------+----------------+
>>                | float32 |      5.877e-39 |       3.403e38 |
>>                | float64 |    1.1125e-308 |     +1.798e308 |
>>                +---------+----------------+----------------+
>>=20
>>           Table 3: Ranges for floating-point abstract data types
>=20
> It's not clear how you got these values. The minimum is surely zero, =
and the encoding doesn't allow negative exponents. I agree with the =
maximums.

minimum nonzero abs(x) is what=92s intended here. These came from IEEE =
754 (via Wikipedia, I think); this needs a cite.
>> 4.5.  boolean
>>=20
>>    If the Enclosing Context defines a representation for boolean =
values,
>>    that representation SHOULD be used.
>>=20
>>    Otherwise, a true boolean value should be represented with the
>>    literal string 1, and a false boolean value with the literal =
string
>>    0.  In ABNF:
>>=20
>>    boolean-yes =3D "1"
>>=20
>>    boolean-no =3D "0"
>>=20
>>    boolean =3D boolean-yes / boolean-no
>=20
> Why 1/0 rather than true/false or yes/no ?

Internationalization. See my other message for my rant =93why not 1/2=94. =
:)


>>=20
>> Appendix A.  Example
>>=20
>>    In this section, we examine an IPFIX Template and a Data Record
>>    defined by that Template, and show how that Data Record would be
>>    represented in JSON according to the specification in this =
document.
>>    Note that this is specifically NOT a recommendation for a =
particular
>>    representation, merely an illustration of the encodings in this
>>    document.
>>=20
>>    Figure 1 shows a Template in IESpec format as defined in section =
10.1
>>    of [RFC7013].  A Message containing this Template and a Data =
Record
>>=20
>>=20
>>=20
>> Trammell                  Expires July 24, 2014                 [Page =
9]
>> =0C
>> Internet-Draft              IPFIX Text Types                January =
2014
>>=20
>>=20
>>    is shown in Figure 2, and a corresponding JSON Object using the =
text
>>    format defined in this document is shown in Figure 3.
>>=20
>>          flowStartMilliseconds(152)[8]
>>          flowEndMilliseconds(153)[8]
>>          octetDeltaCount(1)[4]
>>          packetDeltaCount(2)[4]
>>          sourceIPv6Address(27)[4]{key}
>>          destinationIPv6Address(28)[4]{key}
>>          sourceTransportPort(7)[2]{key}
>>          destinationTransportPort(11)[2]{key}
>>          protocolIdentifier(4)[1]{key}
>>          tcpControlBits(6)[1]
>>          flowEndReason(136)[1]
>>=20
>>                   Figure 1: Sample flow template (IPFIX)
>=20
> Perhaps, "Sample IPFIX flow template in IESpec format"? Consider =
dropping the "IPFIX", since it's almost meaningless here.

Yep.

>>=20
>>              1         2         3         4         5         6
>>    0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>   | 0x000a        | length 135    | export time 1352140263        | =
msg
>>   | sequence 0                    | domain 1                      | =
hdr
>>   | SetID 2       | length 52     | tid 256       | fields 11     | =
tmpl
>>   | IE 152        | length 8      | IE 153        | length 8      | =
set
>>   | IE 1          | length 4      | IE 2          | length 4      |
>>   | IE 27         | length 16     | IE 28         | length 16     |
>>   | IE 7          | length 2      | IE 11         | length 2      |
>>   | IE 4          | length 1      | IE 6          | length 1      |
>>   | IE 136        | length 1      | SetID 256     | length 83     | =
data
>>   | start time                                     1352140261135  | =
set
>>   | end time                                       1352140262880  |
>>   | octets                195383  | packets                   88  |
>>   | sip6                                                          |
>>   |                       2001:0db8:000c:1337:0000:0000:0000:0002 |
>>   | dip6                                                          |
>>   |                       2001:0db8:000c:1337:0000:0000:0000:0003 |
>>   | sp        80  | dp     32991  | prt 6 | tcp 19| fe 3  |
>>   +-------------------------------------------------------+
>=20
> The figure is 63 chars wide rather than 64; each column is 15 chars =
wide.

This is intentional, to get us back to 72-wide with some annotation =
space on the left.

See RFC 6235.

> It might be clearer to draw the usual 1-bit-per-column, 32-bit-wide =
figure.

Which won=92t fit on a page and takes up ridiculous amounts of space for =
the v6 addresses.

>>               Figure 2: IPFIX message containing sample flow
>=20
> Is it still an IPFIX message?
> Should message be capitalised?

Yes, indeed.
>>=20
>> Trammell                  Expires July 24, 2014                [Page =
10]
>> =0C
>> Internet-Draft              IPFIX Text Types                January =
2014
>>=20
>>=20
>>            {
>>                "flowStartMilliseconds": "2012-11-05T18:31:01.135",
>>                "flowEndMilliseconds": "2012-11-05T18:31:02.880",
>>                "octetDeltaCount": 195383,
>>                "packetDeltaCount": 88,
>>                "sourceIPv6Address": "2001:db8:c:1337::2",
>>                "destinationIPv6Address": "2001:db8:c:1337::3",
>>                "sourceTransportPort": 80,
>>                "destinationTransportPort": 32991,
>>                "protocolIdentifier": "tcp",
>>                "tcpControlBits": 19,
>>                "flowEndReason": 3
>>            }
>>=20
>>                Figure 3: JSON object containing sample flow
>=20
> Note that the quoting, and colon/comma format are JSON specific.

Will do (above, in the intro text).

Thanks again! Cheers,

Brian


--Apple-Mail=_1E268C6A-AF62-4490-893A-568EC66F785D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

hi =
Paul,

many thanks for the review! Will put these on =
the list for a post-wglc -01 revision; have snipped those I accept =
without comment from the following, with commentcomments =
inline...

On 28 Jan 2014, at 15:33, Paul Aitken =
<paitken@cisco.com> =
wrote:
1.  Introduction

   The IPFIX Information Model, as defined by the IANA IPFIX Information
   Element Registry [iana-ipfix-assignments], provides a rich set of
   Information Elements for description of information about network
   entities and network traffic data, and =
abstract data types for these

    

    

      
   Information Elements.  The =
IPFIX Protocol Specification [RFC7011], in

    

    

    Perhaps, though it's not limited just to networks =
;-)

The protocol no, the =
information model is presently


    You're suggesting that the IANA registry is the reference for the
    ADTs, rather than 7012?

    7012 isn't mentioned until section =
4.

I am, and that=92s =
incorrect. I=92ll correct this:

The IPFIX =
Information Model [RFC 7012] provides a set of abstract data types for =
the IPFIX Information Element Registry [IANA-IPFIX], which in turn =
contains a rich set of...
   =
turn, defines a big-endian binary encoding for these abstract data
   types suitable for use with the IPFIX Protocol.

    

    

    +xref for the protocol =
spec?

Hm? Already cited =
[RFC7011] in this sentence.


    

      
   However, present and future operations and management =
protocols and
   applications may use textual encodings, and generic framing and
   structure as in JSON or XML.  A definition of canonical textual
   encodings for the IPFIX abstract data types would allow this set of
   Information Elements to be used for such applications, and for these
   applications to interoperate with IPFIX applications at the
   Information Element definition level.

   Note that templating or other mechanisms for data description for
   such applications and protocols are application specific, and
   therefore out of scope for this document: only Information Element
   identification and data value representation are defined here.




Trammell                  Expires July 24, 2014                 [Page 2]
=0C
Internet-Draft              IPFIX Text Types                January 2014


2.  Terminology

   Capitalized terms defined in the IPFIX Protocol Specification
   [RFC7011] and the IPFIX Information Model [RFC7012] are used in this
   document as defined in those documents.  In addition, this document
   defines the following terminology for its own use:

   Enclosing Context
      Textual representation of IPFIX data =
values is applied to use the
      IPFIX Information Model within some existing textual format (e.g.
      XML, JSON).  This outer format is referred to as the =
Enclosing

    

    

    I can't parse that. Should it be, "A
    textual representation ...=94 =
?

Yes it should. (I tried to =
write this such that the first sentence could be a definition rather =
than just exposition, but wasn=92t able to come up with anything that =
was less awkward than =
this.)

<snip>

   Instead, applications using textual representations of Information
   Elements SHOULD use Information =
Element names to identify them; see
   Appendix A for examples illustrating this principle.

    

    

    It's a SHOULD rather than a MUST. Would the IE identifier numbers be
    equally as valid?

Hm. Not =
equally valid, but not invalid (consider an application transcoding =
IPFIX to JSON that only had number information because some lazy =
exporter vendor didn=92t stick 5610 data in the stream). And I didn=92t =
want to MUST this here because I could also think of situations where a =
text representation handled Information Element values positionally. The =
point here is just to define the ADT representations in an interoperable =
way, not to cover every possible application =
therefor.


    

      
4.  Data Type Encodings

   Each subsection of this section defines a textual encoding for the
   abstract data types defined in [RFC7012].  This section uses ABNF
   [RFC5234], including the Core Rules in Appendix=
 B, to describe the
   format of textual representations of IPFIX abstract data types.

    

    

    It's unclear whether that's Appendix B of this document or of =
5234.

Of 5234, will =
fix.

    

      
4.1.  octetArray

   If the Enclosing Context defines a representation for binary objects,
   that representation SHOULD be used.

   Otherwise, since the goal of textual =
representation of Information
   Elements is readability over compactness, the values of =
Information

    

    

    This goal should be mentioned much =
earlier!

Indeed, will move to =
introduction.

    

      
   Elements of the octetArray data type are represented as a =
string of
   pairs of hexadecimal digits, one pair per byte, in the order the
   bytes would appear on the wire were the octetArray encoded directly
   in IPFIX per [RFC7011].  Whitespace may occur between any pair of
   digits to assist in human readability of the string, but is not
   necessary, and must be disregarded by any process reading the string.
   In ABNF:



Trammell                  Expires July 24, 2014                 [Page 3]
=0C
Internet-Draft              IPFIX Text Types                January 2014


   hex-octet =3D 2HEXDIGIT

   octetarray =3D 1* (hex-octet [WSP])

    

    

    There's an implicit assumption of 8-bit bytes =
here.

Also in the name of the =
abstract data type: =93octet=94 means group of eight bits, so I=92m =
happy sticking with this assumption.


    An alternative encoding of "0b [10]*" (eg, 0b10101100) might
    sometimes be useful, eg for =
bitflags

Good point. Flags are =
usually implemented as unsigned, so we=92d want to add binary there too =
as well.

<snap>

    
4.3.  signed8, signed16, signed32, =
and signed64

   If the Enclosing Context defines a representation for signed
   integers, that representation SHOULD be used.




Trammell                  Expires July 24, 2014                 [Page 4]
=0C
Internet-Draft              IPFIX Text Types                January 2014


   Otherwise, the values of Information Elements of signed integer types
   should be represented as optionally-prefixed base-10 (decimal)
   strings.  In ABNF:

   sign =3D "+" / "-"

   signed =3D [sign] 1*DIGIT

   If the sign is omitted, it is assumed to be positive.  Leading zeroes
   are allowed, and do not signify base-8 (octal) encoding.

   The encoded value must be in range for the corresponding abstract
   data type or Information Element.  Out of range values should be
   interpreted as clipped to the implicit range for the Information
   Element as defined by the abstract data type, or to the explicit
   range of the Information Element if defined.  Minimum and maximum
   values for abstract data types are shown in Table 2 below.

        +----------+----------------------+----------------------+
        |     type |              minimum |              maximum |
        +----------+----------------------+----------------------+
        |  signed8 |                 -128 |                 +127 |
        | signed16 |               -32768 |               +32767 |
        | signed32 |          -2147483648 |          +2147483647 |
        | signed64 | -9223372036854775808 | +9223372036854775807 |
        +----------+----------------------+----------------------+

              Table 2: Ranges for signed abstract data types

    

    

    Are +0, 0, and -0 all =
valid?

As long as they=92re =
treated to be equal, yes.


    

      
4.4.  float32 and float64

   If the Enclosing Context defines a representation for floating point
   numbers, that representation SHOULD be used.

   Otherwise, the values of Information Elements of float32 or float64
   types are represented as an optionally sign-prefixed, optionally
   base-10 exponent-suffixed, floating point decimal number.  In ABNF:

   sign =3D "+" / "-"

   exponent =3D 'e' 1*3DIGIT

   right-decimal =3D '.' 0*DIGIT

   mantissa =3D 1*DIGIT [right-decimal]

   float =3D [sign] mantissa [exponent]


There=92s an =
error here: exponent should be =91e=92 [sign] 1*3DIGIT (see =
below)

    

      
               +---------+----------------+----------------+
               |    type | minimum abs(x) | maximum abs(x) |
               +---------+----------------+----------------+
               | float32 |      5.877e-39 |       3.403e38 |
               | float64 |    1.1125e-308 |     +1.798e308 |
               +---------+----------------+----------------+

          Table 3: Ranges for floating-point abstract data types

    

    

    It's not clear how you got these values. The minimum is surely zero,
    and the encoding doesn't allow negative exponents. I agree with the
    maximums.

minimum nonzero =
abs(x) is what=92s intended here. These came from IEEE 754 (via =
Wikipedia, I think); this needs a cite.
4.5.  boolean

   If the Enclosing Context defines a representation for boolean values,
   that representation SHOULD be used.

   Otherwise, a true boolean value should be represented with the
   literal string 1, and a false boolean value with the literal string
   0.  In ABNF:

   boolean-yes =3D "1"

   boolean-no =3D "0"

   boolean =3D boolean-yes / boolean-no

    

    

    Why 1/0 rather than true/false or yes/no =
?

Internationalization. See my =
other message for my rant =93why not 1/2=94. =
:)

<snip>
Appendix A.  Example

   In this section, we examine an IPFIX Template and a Data Record
   defined by that Template, and show how that Data Record would be
   represented in JSON according to the specification in this document.
   Note that this is specifically NOT a recommendation for a particular
   representation, merely an illustration of the encodings in this
   document.

   Figure 1 shows a Template in IESpec format as defined in section 10.1
   of [RFC7013].  A Message containing this Template and a Data Record



Trammell                  Expires July 24, 2014                 [Page 9]
=0C
Internet-Draft              IPFIX Text Types                January 2014


   is shown in Figure 2, and a corresponding JSON Object using the text
   format defined in this document is shown in Figure 3.

         flowStartMilliseconds(152)<dateTimeMilliseconds>[8]
         flowEndMilliseconds(153)<dateTimeMilliseconds>[8]
         octetDeltaCount(1)<unsigned64>[4]
         packetDeltaCount(2)<unsigned64>[4]
         sourceIPv6Address(27)<ipv4Address>[4]{key}
         destinationIPv6Address(28)<ipv4Address>[4]{key}
         sourceTransportPort(7)<unsigned16>[2]{key}
         destinationTransportPort(11)<unsigned16>[2]{key}
         protocolIdentifier(4)<unsigned8>[1]{key}
         tcpControlBits(6)<unsigned8>[1]
         flowEndReason(136)<unsigned8>[1]

                  Figure 1: Sample flow template (IPFIX)

    

    

    Perhaps, "Sample IPFIX flow template in IESpec format"? Consider
    dropping the "IPFIX", since it's almost meaningless =
here.

Yep.


    

      
             1         2         3         4         5         6
   0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | 0x000a        | length 135    | export time 1352140263        | msg
  | sequence 0                    | domain 1                      | hdr
  | SetID 2       | length 52     | tid 256       | fields 11     | tmpl
  | IE 152        | length 8      | IE 153        | length 8      | set
  | IE 1          | length 4      | IE 2          | length 4      |
  | IE 27         | length 16     | IE 28         | length 16     |
  | IE 7          | length 2      | IE 11         | length 2      |
  | IE 4          | length 1      | IE 6          | length 1      |
  | IE 136        | length 1      | SetID 256     | length 83     | data
  | start time                                     1352140261135  | set
  | end time                                       1352140262880  |
  | octets                195383  | packets                   88  |
  | sip6                                                          |
  |                       2001:0db8:000c:1337:0000:0000:0000:0002 |
  | dip6                                                          |
  |                       2001:0db8:000c:1337:0000:0000:0000:0003 |
  | sp        80  | dp     32991  | prt 6 | tcp 19| fe 3  |
  +-------------------------------------------------------+


    

    

    The figure is 63 chars wide rather than 64; each column is 15 chars
    wide.

This is intentional, =
to get us back to 72-wide with some annotation space on the =
left.

See RFC 6235.


    It might be clearer to draw the usual 1-bit-per-column, 32-bit-wide
    figure.

Which won=92t fit =
on a page and takes up ridiculous amounts of space for the v6 =
addresses.


    

      
              Figure 2: IPFIX message containing sample =
flow

    

    

    Is it still an IPFIX message?

    Should message be =
capitalised?

Yes, =
indeed.
Trammell                  Expires July 24, 2014                [Page 10]
=0C
Internet-Draft              IPFIX Text Types                January 2014


           {
               "flowStartMilliseconds": "2012-11-05T18:31:01.135",
               "flowEndMilliseconds": "2012-11-05T18:31:02.880",
               "octetDeltaCount": 195383,
               "packetDeltaCount": 88,
               "sourceIPv6Address": "2001:db8:c:1337::2",
               "destinationIPv6Address": "2001:db8:c:1337::3",
               "sourceTransportPort": 80,
               "destinationTransportPort": 32991,
               "protocolIdentifier": "tcp",
               "tcpControlBits": 19,
               "flowEndReason": 3
           }

               Figure 3: JSON object containing sample flow

    

    

    Note that the quoting, and colon/comma format are JSON =
specific.

Will do (above, in =
the intro text).

Thanks again! =
Cheers,

Brian

=

--Apple-Mail=_1E268C6A-AF62-4490-893A-568EC66F785D--

--Apple-Mail=_9677CE3B-CD71-45C0-938C-EDF02415B696
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJS59pkAAoJENt3nsOmbNJc/lQIAKw+GZAP7ACyPJKRDdcNPAfU
mJzIqbGPPTH5ZU5a1hQ/KWaSY7wRw1dllsmaNqFUuQjIBFtmpbPUegPyCYgP4gEo
cJBpvWGQkerv4oiRVW4uyHG9MKABjhuT+wawLtGYj1dXEjnspGtm8exVHMvESJkH
0uOMgdAWLPHJmpTgW+f7UMT+ETfA9BMKtxTXsz2gGmGjg5vcjOMAy+uEogdNuccM
wHU92YimIc4NYjjtEv2l4j8QlgEr+KJwzGWQhk69MKJIVnww1G/68X8kUEMdzFoc
UqDjMNgx1t7TTUk0xUtSGCsbeONm1eEryHSERNI1QMDW2U8dvJ/PabsFwsMZB7Q=
=o/Yz
-----END PGP SIGNATURE-----

--Apple-Mail=_9677CE3B-CD71-45C0-938C-EDF02415B696--