Shepherd writeup
rfc8272-04


ISE write-up for: draft-schmitt-ipfix-tiny-03

Abstract:
  'This document specifies the TinyIPFIX protocol that serves for
   transmitting smart metering data in constrained networks such as
   6LoWPAN [RFC4944].  TinyIPFIX is derived from IPFIX [RFC7011] and
   adopted to the needs of constrained networks.  This document
   specifies how the TinyIPFIX Data and Template Records are transmitted
   in constrained networks such as 6LoWPAN and how TinyIPFIX data can be
   converted into unTinyIPFIX data in a proxy device.'

This draft has no IANA Considerations.

This draft presents the work of a fairly long-running research project as
THE, Zurich, see "TinyIPFIX", Schmitt, Kothmayr, Ertl, Wen and Braun and 
Carle, Computer Communications, 2016.  

It was reviewed for me by Tanja Zseby and Paul Aitken.

The authors have made the changes suggested by the reviewers, as well as those
requested by the ISE.

- - - - -

Tanja Zseby's review:

Comments on draft-schmitt-ipfix-tiny-00

General remarks
- I like the idea of using IPFIX for sensor data very much and think the draft provides a very useful contribution. One challenge may be that there have been many protocols proposed (and also standardized) for sensor data export. It would be useful to include some references and point out the advantages of using TinyIPFIX.

- The term “smart meter” is usually associated with meters in the power grid, but the approach is suitable for sensors in general. In addition: Due to its suitability for constrained environments TinyIPFIX might be also an excellent protocol choice for “stupid” meters (e.g., meters with restricted functionality). So I would suggest to reconsider the title (e.g., “TinyIPFIX for sensor data export” or “TinyIPFIX for 6LoWPAN devices”).

- I would suggest to include a table or list to show/summarize the differences between standard (full) IPFIX and TinyIPFIX. Also since several fields are shortened, the consequences should be explicitly shown (e.g., maximum number of packets with unique seq. no. compared to full IPFIX, etc.) and maybe some references why in certain environments this would be OK.

- The use of UDP and unidirectional communication heavily restricts the applicability of the protocol. That is ok, but it may be useful to provide more application examples.

Specific sections
- Section 3.1:  “IRIS mote from Crossbow”: I would mention at least one further vendor/references.
- Section 3.3: “protocol can also be used to transmit data in other networks”:  It should be clarified what is specific to 6LoWPAN (addresses?) and would need to be changed if other networks are use.
- Section 3.4: Should clarify what is the target environment and potential differences. E.g., sensors located in one administrative network vs. data transmitted over wide area.
- Section 3.4: If TinyIPFIX is used over the Internet, UDP may be problematic due to the lack of congestion control.
- Section 3.4: TCP and SCTP “NOT RECOMMENDED” seems quite strict for me. I would rather put a MAY and just give advice to readers that performance may be reduced (depending on sensor types, data and network).
- Section 3.4: The use of UDP and unidirectional communication heavily restricts the applicability of the protocol. Are all configuration parameters, timing, templates etc. set manually in advance and never changed? Or do you consider further interfaces to the sensor? Would the examples (Duck Island, Golden Gate) work with the restrictions?
- Section 3.4: Occasional loss of some sensor data may be acceptable for some applications but loss of template messages and the resulting loss of many subsequent sensor data can be more severe because applications may not have enough data to extrapolate. So I would explicitly separate these two restrictions (e.g., occasional random loss and bursty loss). 
- Section 3.4: “Smart Meters can be queried”: not if they only support unidirectional communication
- Section 5: “Smart Meter (S.M.) queries its internal sensors”: Does it mean a smart meter is considered as a set of sensors? Should be clarified.
- Section 5: “may also aggregate the incoming data with its own measurement”: What is meant here? It sounds like the collector is doing own measurements?
- Section 6.1. Can different header formats be mixed in subsequent IPFIX records?
- Section 6.1: Not getting exporting timestamps is a further restriction and may be added to the list in section 4. If added on application layer this increases the messages.
- 6.2: should explain why Set ID 3 should not be used
- Section 7.1., export time: How does the collector know whether the time was added by the sensor or by the Mediator?
- Section 7.1., sequence number: expanded here means just putting the value in a larger field, correct?

Typos
- Section2,  TinyIPFIX Smart Meter: tempering should be tampering
- Section 4, point 3. “several into” should be  “several measurements into”
- Section 6.1. “thre” should be “three”
- Section 6.1. “WSN settings the also”: remove “the”
- Section 6.1. “Figure 10where” blank missing
- Section 6.1.  containts should be contains
- Section 7: “counterparts in IPFIX” period missing- Several times: “an TinyIPFIX Exporter” should be rather “a TinyIPFIX Exporter”?

- - - - -

Paul Aitken's review:

I've reviewed draft-schmitt-ipfix-tiny-01.

General comments:

* Some good ideas, but needs some work.
* Although Brian is listed as a co-author, I must wonder whether he's actually read the draft?
* Over-emphasis of 6LoWPAN, smart meters, and wireless. The ideas would seem to apply equally to other low-powered networks and to wired devices, so the draft should specify a generic protocol which can be used for these, but isn't constrained by them. eg, non smart-meter devices should also be able to use this protocol without having to re-write the document to s/smart meter/other device/.
* An obvious optimisation is to pre-share the IPFIX templates, thus removing the need to export them at all (just export the usual IPFIX data records). This solves several issues in the draft. I've written draft-aitken-ipfix-pre-defined-templates because the idea was potentially patentable (my employer won't be pursing this). The two drafts could be merged or developed in parallel, but I've little time to devote to this.



Nits: multiple issues to be resolved.
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-schmitt-ipfix-tiny-01.txt


Spelling:

   s/RFC7101/RFC7011/ throughout!

   TinyIPFIX is derived from IPFIX [RFC7101] and adopted to the needs of

   constrained networks.  This documents specifies how the TinyIPFIX

   wireless senor nodes, motes or any other kind of small constraint

   12.1. Norminative References

   where data is transmitted autonomically from the meters

   A TinyIPFIX IFPIX Message starts with a TinyIPFIX Message Header,

   The first part has a fixed length of thre octets and consists of the

   containts Data Record for Template 256.  This places special

   Lookup extended SetID field, shiftig enabled.

   Multiple different capitalisations of "6lowpan" :
        9 x 6LoWPAN
        4 x 6LowPAN
        1 x 6lowpan

   Figure 14: TinyIPFIX Dta Field Specifier


Copyright:

* Is this the most appropriate copyright statement? Specifically, "Code Components extracted from this document" - there are none.


Abstract:

   This document specifies the TinyIPFIX protocol that serves for
   transmitting smart metering data in6LoWPAN networks  [RFC4944 <https://tools.ietf.org/html/rfc4944>].
   TinyIPFIX is derived from IPFIX [RFC7101 <https://tools.ietf.org/html/rfc7101>] and adopted to the needs of
   constrained networks.  This documents specifies how the TinyIPFIX
   Data and Template Records are transmitted in6LoWPAN networks  and how
   TinyIPFIX data can be converted into unTinyIPFIX data in a proxy
   device.

* The protocol is more widely useful than just 6LoWPAN, so consider "in constrained networks such as 6LoWPAN".


Section 1.  Introduction

   Smart meters that form a constrained wireless network need an
   application layer protocol that allows the efficient transmission of
   metering data from the devices tosome kind of  central analysis
   device.

* "to a central analysis device."

   The devices are often battery powered and are expected to run for a
   long time without having the possibilityto re-charge  themselves.

* "of recharging"


Section 2.  Terminology

* Should define "TinyIPFIX" (eg, "the protocol specified in this document") and "unTinyIPFIX" (which is presumably IPFIX per RFC 7011). Consider "regular IPFIX [RFC7011]" for clarity.

* Swap around the last two sentences of this paragraph, and remove the struck-through "IPFIX":

   Most of the terms used in this draft are defined in [RFC7101 <https://tools.ietf.org/html/rfc7101>].  All
   these terms are written with their first letter being capitalized.
   Most of the terms that are defined for IPFIX can be used to describe
   TinyIPFIX.  The term "TinyIPFIX" is used in front of the IPFIX term
   to distinguish between the IPFIX version and the TinyIPFIX version.
   This draft uses the term IPFIX to refer to IPFIX as perRFC 7101 <https://tools.ietf.org/html/rfc7101>  and
   the term TinyIPFIX for the IPFIX version defined in this draft.

* Move "The term smart meter is used" paragraph after the IPFIX paragraphs, just before the "TinyIPFIX Exporting Process" definition.

   TinyIPFIX Exporter

      A TinyIPFIX Exporter is asmart metering  device that contains at
      least one TinyIPFIX Exporting Process.

* There's no need to say "smart metering" here, since the TI Exporter could be hosted on any kind of device. Smart metering is just one example of a possible application. Compare with the TI Device definition, which says "device" without specifing "smart metering".

   TinyIPFIX Device

      A TinyIPFIX Device is a device that contains one or more TinyIPFIX
      Collector or one or more TinyIPFIX Exporter.

* It's more usual to pluralise: "Collectors ... Exporters".

   TinyIPFIX Smart Meter

      A TinyIPFIX Smart Meter is a device that contains the
      functionality of aTinyIPFIX device.  It is usually equipped with
      one or more sensors that meter a physical quantity, like power
      consumption, temperature, or physical tempering with the device.
      Every TinyIPFIX Smart Meter MUST at least contain a TinyIPFIX
      Exporting Process.  It MAY contain a TinyIPFIX Collecting Process
      in order to work as aTinyIPFIX Proxy  or Concentrator.


* Capitalise "TinyIPFIX device" since it's a defined term (and in fact the only use of that term).

* Uses "TinyIPFIX Proxy" which hasn't been defined yet.

* Consider "TinyIPFIX Proxy or TinyIPFIX Concentrator".

* Per the introduction, "In order to save energy, smart meters often power off their wireless networking device". Therefore a Smart Meter is not an appropriate device to act as an Proxy or Concentrator.

   TinyIPFIX Message

      The TinyIPFIX Message is a message originated by a TinyIPFIX
      Exporter.  It is composed of a TinyIPFIX Message Header and one or
      more TinyIPFIX Sets.  The TinyIPFIX Message Format is defined in
      Section 6.


* Uses "TinyIPFIX Sets" which hasn't been defined yet.

   TinyIPFIX Data Record

      A TinyIPFIX Data Record equals a Data Record in [RFC7101 <https://tools.ietf.org/html/rfc7101>].  The
      term is used to distinguish between IPFIX and TinyIPFIX throughout
      the  document.

* "this"

   TinyIPFIX Template Record

      A TinyIPFIX Template Record is similar to a Template Record.   The
      xxx  Template Record Header is substituted with a TinyIPFIX Template
      Record Headerand is otherwise equal to a Template Record.  See
      Section 6.3.

* Say "similar to an IPFIX Template Record" and/or xref RFC 7011. Also at xxx.
"... and is otherwise equal to a Template Record" seems to say that (IPFIX) Template Record == (IPFIX) Template Record.

   TinyIPFIX Intermediate Process

      A TinyIPFIX Intermediate Process is anIPFIX  Intermediate Process that
      can handle TinyIPFIX Messages.

* Add "IPFIX" as indicated for consistency with the following "TinyIPFIX Proxy" and "TinyIPFIX Concentrator" definitions.

   TinyIPFIX Concentrator

      A TinyIPFIX Concentrator is an IPFIX Concentrator that can handle
      TinyIPFIX Messages.

* "IPFIX Concentrator" is not a defined term.


3.2.  Energy constraints

   transmitting application data under such circumstances.  As the
   communication is unidirectional, a meter can completely power down
   its radio frequency transceivers as long as it does not have any data
   tosent.  If the metering device is able to keep a few measurements
   in memory, and if real time metering is not a requirement, the
   TinyIPFIX Data Records can be pushed less frequently.  Therefore,
   saving some more energy on the radio frequency transceivers.

* "send".

* Join the last sentence: "... can be pushed less frequently, therefore saving ..."


3.3.  Packet size constraints

   TinyIPFIX is mainly targeted for the use in 6LoWPAN networks, which
   are based on IEEE 802.15.4 [RFC4944 <https://tools.ietf.org/html/rfc4944>].However, the protocol can also be used to transmit data in other networks.

* No it can't, because the TinyIPFIX Transport Session requires 6LowPAN addresses:

   A TinyIPFIX Transport Session is defined by the communication between
   a TinyIPFIX Exporter (*identified by an 6LowPAN-Address*, the Transport
   Protocol, and the Transport Port) and a TinyIPFIX Collector
   (identified by the same properties).



   IEEE 802.15.4 defines a
   maximum frame size of 127 octets,which usually leaves 102 octets  for
   user data.

* Why? Briefly explain the other 25 octets. eg, "A header size of 25 octets leaves 102 octets ...".

   TinyIPFIX enhances IPFIX by a header compression scheme,which allows to reduce the overhead from header sizes significantly.

* "which allows the header size overhead to be significantly reduced."


3.4.  Transport protocol constraints

   This transport protocol recommendation is not suitable for TinyIPFIX.
   A header compression scheme that allowsto compress  an IPv6 header
   from 40 octets down to 2 octets is defined in 6LoWPAN.

* "compression of ..."

* If TI isn't being used over 6LoWPAN, can that header compression scheme still be used? (Per 3.3 / "the protocol can also be used to transmit data in other networks.").


4.  Application scenarios for TinyIPFIX

   TinyIPFIX is derived from IPFIX [RFC7101 <https://tools.ietf.org/html/rfc7101>] and is therefore a
   unidirectional push protocol.


* Underlying transport protocols (TCP, SCTP) may be bi-directional.

   Hence, TinyIPFIX only fits for application
   scenarios where meters transmit data to one or more Collectors.


* As opposed to scenarios where the Collector polls the meters.

   If TinyIPFIX is used over UDP, as recommended, packet loss can occur.
   Furthermore, if an initial Template Message gets lost, and is
   therefore unknown to the Collector, all TinyIPFIX Data Sets that
   reference this Template cannot be decoded.  Hence, all these Messages
   are lostif they are not cached by the Collector.


* It's dangerous for the Collector to cache Messages pending the receipt of a re-transmitted Template, because it's impossible to know whether the newly received Template is identical to the original (ie, re-sent) or is a new template using the same ID as the original (ie, re-defined). Therefore, IPFIX Collectors generally discard such Records.

* However, in the case of multiple monitoring devices, isn't it likely that they all use the same Templates? In fact, the Templates can be well known and defined in advance, so there's no need to transmit them at all. Templates are only required when the fields in the data records may vary, eg if devices are monitoring different parameters, or if certain measurements may sometimes be unavailable and must therefore be omitted from the exported data. See draft-aitken-ipfix-pre-defined-templates.

   One
   application for IPFIX can be long term monitoring of large physical


* s/can be/is/

   Deploying TinyIPFIX in such scenarios seems to be a good fit.

* "TinyIPFIX is a good fit for such scenarios".

   1.  The application must require a push protocol.  It is not possible
       to request data from a smart meter.  The TinyIPFIX Smart Meter
       decides for itself when to send its metering data.


* Not true; it may be possible to request data from (another type of) smart meter. "It is not possible to request data from a TinyIPFIX Smart Meter."

   3.  Ifreal-time  is not required,  the application might benefit from
       accumulated  several measurements into a single TinyIPFIX Message.


* "If real-time reporting is not required"?

* "accumulating".

       TinyIPFIX easily allows the aggregationof several into  a single
       TinyIPFIX Message (or a single packet).


* Missing noun, eg "Of several measurements into" ?

* "accumulate" and "aggregate" seem to be used interchangeably here. Beware that IPFIX aggregation means something quite different per RFC 7015. Therefore, it'd be better to use "accumulate" when the sense is "addition of multiple records", and review the use of "aggregation" throughout sections 4 and 5.


Figure 1

* s/TinyIPFIX S.M./TinyIPFIX Device/
* show multiple Exporters feeding into the Collector.
* draw the figure consistently downwards or rightwards, because that's the way people read. Flowing upwards is confusing because it puts the last things first.

   A TinyIPFIX Smart Meter (S.M.) queries its internal sensors to
   retrieve the sensor data.  It then encodes the results into a
   TinyIPFIX Message and exports this TinyIPFIX Message to one or more
   TinyIPFIX Collectors.


* Technically, the SM uses a TinyIPFIX Exporting Process to encode the TinyIPFIX Message, and a TinyIPFIX Exporter to manage the export.


   A second way to deploy TinyIPFIX Smart Meter can employ aggregation
   on TinyIPFIX Messages during their journey through the constrained
   network as shown in Figure 2.  This aggregation can be performed by
   special TinyIPFIX Smart Meter that act as TinyIPFIX Concentrators.
   Such devices must have enough resources to perform the aggregation.


* This doesn't read well.

* Per earlier feedback, a constrained Smart Meter is not a good choice for a Concentrator.


Figure 2

* s/TinyIPFIX S.M./TinyIPFIX Device/
* What's the significance of the (1) in "Collector(1)" ?
* s/Aggregation on/Aggregation of/
* I'd prefer the figure to flow vertically downwards, eg:

  +-------------------------+     +-------------------------+
  |       Smart Meter       |     |       Smart Meter       |
  +-------------------------+ ... +-------------------------+
  |    TinyIPFIX Device     |     |    TinyIPFIX Device     |
  |   [Exporting Process]   |     |   [Exporting Process]   |
  +-------------------------+     +-------------------------+
                       |               |
                       |               | TinyIPFIX
                       |               |
                       v               v
                  +-------------------------+
                  | TinyIPFIX Concentrator  |
                  |  [Collecting  Process]  |
                  |  [Exporting Process]    |
                  +-------------------------+
                               |
                               | TinyIPFIX
                               |
                               v
                  +-------------------------+
                  |        Collector        |
                  | [Collecting Process(es)]|
                  +-------------------------+


                    Figure 2: Aggregation of TinyIPFIX


Under Figure 2:

   TinyIPFIX Smart Meters send their data to TinyIPFIX Concentrator
   which needs to have enough storage space to store the incoming data.
   It may also aggregate the incoming data with its own measurement data.   The aggregated data can then be re-exported again to one or
   more Collectors.


* No, this mixes up the functions of a TinyIPFIX Concentrator and a Smart Meter. If the Concentrator is hosted in a Smart Meter (which I've already said is a bad idea), then the the Concentrator can be viewed as receiving data from multiple Smart Meters - one locally, and some remotely.

* ie, it can be modelled as so (compare with the figure above) :

  +-------------------------+     +-------------------------+
  |   Remote Smart Meter    |     |    Local Smart Meter    |
  +-------------------------+     +-------------------------+
  |    TinyIPFIX Device     |     |    TinyIPFIX Device     |
  |   [Exporting Process]   |     |   [Exporting Process]   |
  +-------------------------+     +-------------------------+
                       |               |
                       |               | TinyIPFIX
                       |               |
                       v               v
                  +-------------------------+
                  | TinyIPFIX Concentrator  |
                  |  [Collecting  Process]  |
                  +-------------------------+


   The TinyIPFIX Smart Meters transmit their TinyIPFIX Messages to one
   node, e.g. the base station, which translates the TinyIPFIX Messages
   to IPFIX Messages.  The IPFIX Messages can then be exported into an
   existing IPFIX infrastructure.  The Mediation process from TinyIPFIX
   to IPFIX is described inSection 7 <https://tools.ietf.org/html/draft-schmitt-ipfix-tiny-01#section-7>.


* Say, "In this deployment, The TinyIPFIX Smart Meters transmit ..." to make it clear that this isn't a general requirement.
Again it'd be good to flow the figure vertically.

* The figure 3 title is wrong. Perhaps it should say "TinyIPFIX Mediation".


6.  TinyIPFIX Message Format

   A TinyIPFIX IFPIX Message starts with a TinyIPFIX Message Header,
   followed by one or more TinyIPFIX Sets.  The TinyIPFIX Sets can be
   any  of the possible two types: TinyIPFIX Template Set and TinyIPFIX
   Data Set.  A TinyIPFIX Message MUST only contain one type of
   TinyIPFIX Set.  The format of the TinyIPFIX Message is shown in
   Figure 4

* s/any/either/

* missing period in the last line.


Figure 5: This figure has been incorrectly copied from Figure F in RFC 7011. The numbering is offset, and the figure is one bit short:

Figure 5:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Version Number              |        Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Whereas Figure F in RFC7011:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Version Number          |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Below Figure 5:

   TinyIPFIX introduces a TinyIPFIX Message Header that
   has a smaller size.  The TinyIPFIX header consists of a fixed part of
   three octets and a variable length "Remaining Header" as shown in
   Figure 6.

* The division into two parts is important, but unclear from Figure 6.

* s/Remaining/Variable/

* It would be better to say, "The TinyIPFIX header consists of a fixed part of three octets as shown in Figure 6, followed by a variable part as shown in Figures 7 through 10 below.



Figures 6 - 10:

* These are 16 bits wide and double-spaced, making them inconsistent with Figure 5, 11, 13, 14, and all the IPFIX figures. To avoid confusion, it'd be better to format these as 32 bits wide.

* The existing numbering is from 00 to 16, implying that the figures are 17 bits wide.

* Redraw these consistently with existing IPFIX figures, eg:

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|E| SetID |      Length       |    Sequence   |
   |1|2| Lookup|                   |     Number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


             Figure 6: Format of the Fixed Part of the TinyIPFIX Message header


Figure 6: note the change in title (above), since the existing figure only describes the TinyIPFIX Message header Format in a specific circumstance (ie, when E1 = E2 = 1, per Figure 10).


   Thefirst  part has a fixed length ofthre  octets and consists of the
   "E1" field (1 bit), the "E2" field (1 bit), the "SetID Lookup" field
   (4 bit), the "Length" field (10 bit), and the "Sequence Number" field
   (8 bit).  Thesecond part (the "Remaining Header")  has a variable
   length.  Its length is defined by the "E1" and "E2"field  in the
   fixed headerpart.  The four variants are illustrated in the figures
   below.


* s/bit/bits/

* "The fixed part has a length of three octets and consists of the "E1" field (1 bit), the "E2" field (1 bit), the "SetID Lookup" field (4 bits), the "Length" field (10 bits), and the "Sequence Number" field (8 bits). The variable part has a variable length defined by the "E1" and "E2" fields in the fixed header. The four variants are illustrated in Figures 7, 8, 9, and 10 below."


Figure 10:

Since E1 controls the Ext. SetID field and E2 controls the Ext. Sequence Number field, and since E1 comes ahead of E2, the fields in Figure 10 should logically be Ext. Sequence Number followed by Ext. SetID.


E1 and E2

      The bits marked "E1" and "E2" control the presence of thefile
      "Ext.  SetID" and the length of the field "Ext.  Sequence Number"
      respectively.

* s/file/field/

* It's not "the length of the field" that's being controlled, but its presence.

* Please break out the following four cases into separate paragraphs for easier reading:

      In case E1 = E2 = 0 the TinyIPFIX message header
      has the formatas  shown in Figure 7.  No Ext. Sequence Number and
      Ext. SetIDare required.

* "has the format shown" or, "is formatted as shown"

* Not only are the fields "not required", they MUST NOT be present.

      In case E1 = 1, custom SetIDs can be
      specified in the extended SetID field (cf.  Figure 8.)  When
      evaluated, the value specified in the extended SetID field is
      shifted left by 8 bits to prevent collisions with the reserved
      SetIDs 0-255.  To reference these, shifting can be disabled by
      setting all SetID lookup bits to 1.

* "When E1 = 1, the extended SetID field MUST be present. Custom SetIDs can be specified in this field"

* Append: "setting all SetID lookup bits to 1 (see "SetID Lookup" below)."


      Depending on the application
      sampling rates might be larger than in typicalWSNs and, thus,
      they may have a large quantity of records per packet. In order to
      make TinyIPFIX applicable for those cases E2 = 1 is set (cf.
      Figure 9.)  This means the Ext. Sequence Number field is available
      offering 8-bit more sequence numbers as usual.

* WSN is not defined.

* s/is available/MUST be present/, or "In this case the Extended Sequence Number field MUST be present ..."

* Don't write contractions such as "Ext." in the text. There's plenty of room to spell things out. Many readers may not have English as a first language, so make it as easy as possible for them to understand.


      Depending on the
      WSN settings the also the combination E1 = E2 = 1 is possible
      resulting in the maximum TinyIPFIX Message header shown in
      Figure10where  Ext. Sequence Number field and Ext. SetID field are
      required.

* s/are required/MUST both be present/

* Spell out Ext. in full.


SetID Lookup

      This field acts as a lookup field for the SetIDs and provides
      shortcuts to often used SetIDs.So far  only four values are
      defined: Value = 0 meansLookup  extended SetID field,Shifting
      enabled.  Value = 1 means SetID = 2 and message contains a
      Template definition.  Value = 2 means SetID = 256 and message
      containts  Data Record for Template 256.  This places special
      importance on a single template ID, but since most sensor nodes
      only define a single template directly after booting and continue
      to stream data with this template ID during the whole session
      lifetime, this shorthand is useful for this case.  Value = 3-14
      means SetIDs are reserved for future extensions.  Value = 15 means
      Lookup  extended SetID field,shiftig  enabled.


* If this becomes an RFC, in 25 years time "so far" won't make sense.

* This should be an IPFIX sub-registry (with the associated IANA action) so the list can be extended in future.

* Please split out the values into separate paragraphs so they're easy to pick out visually.

* De-capitalise "Lookup" and "Shifting".


   Since TinyIPFIX packets are always transported via a network
   protocol, which specifies the source of the packet, the "Observation
   Domain" can be equated with the source of a TinyIPFIX packetand the field can be dropped from the header.


* "can be" sounds like it's optional. "Therefore this IPFIX field has been removed from the TinyIPFIX header".

   Should applications require
   several Observation Domains the information can be included in the
   TinyIPFIX data message.


* How would that be done? I'd like to see an example.

   The version field has been dropped since the
   SetID lookup field provides room for future extensions.

* "The IPFIX version field has been removed ..."

   The
   specification of a 32 bit time stamp in seconds would require the
   time synchronization across a wireless sensor network and produces
   too much overhead.  Thus, the "Export Time" field is dropped.  If
   applications should require the specification of time it can be sent
   as part of the TinyIPFIX data message.


* s/is dropped/has been removed/

* Since records are transmitted unreliably, it would be a good idea to recommend inclusion of an observationTime* field per record.



6.2.  TinyIPFIX Set

   A TinyIPFIX Set is a set of TinyIPFIX Template or TinyIPFIX Data
   Records.  Depending on the TinyIPFIX Record type, the TinyIPFIX Set
   can either be a TinyIPFIX Template Set or a TinyIPFIX Data Set.
   Every TinyIPFIX Setis started  with a TinyIPFIX Set Header and is
   followed by one or more TinyIPFIX Records.

* s/is started/starts/


Figure 11: the numbering is offset and incorrectly indicates 17 bits. It should be numbered from 00 to 15 like so:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Tiny Set ID  |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      Figure 11: TinyIPFIX Set Header


* The meaning of "Comp." in "Comp. Set ID" is never stated. There's no need for it, so remove it.
* Or, call it the "Tiny Set ID".

      The "TinyIPFIX Set ID" (Comp.  Set ID) identifies the type of data
      that is transported in the TinyIPFIX Set.  A TinyIPFIX Template
      Set is identified by TinyIPFIX Set ID 2.This corresponds to the Set IDs that are used by Sets in IPFIX.   TinyIPFIX Set ID number 3
      MUST NOT be used.  All values from 4 to 127 are reserved for
      future use.  Values above 127 are used for TinyIPFIX Data Sets.


* "This corresponds to the Template Set ID that is used by IPFIX [RFC7011]."

* Say why Set ID 3 must not be used. To avoid an interoperability loophole, say what a collector should do if it's received.


Figure 13: the numbering is offset and incorrectly indicates 17 bits. It should be numbered from 00 to 15 like so:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Template ID  |  Field Count  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

* The meaning of "Comp." in "Comp. Temp ID" is never stated. There's no need for it, so remove it.


8. Template Management

   As with IPFIX, TinyIPFIX templates management depends on the
   transport protocol used.  If TCP or SCTP is used, it can be ensured
   that TinyIPFIX Templates are delivered reliably.  If UDP is used,
   reliability cannot be guaranteed, and template loss can occur.  If a
   Template is lost on its way to the Collector,all following  TinyIPFIX
   Data Records that refer to this TinyIPFIX Template cannot be decoded.

* "all the following".

   Template withdrawals are not supported in TinyIPFIX.  This is
   generally not a problem, because most sensor nodes only define a
   single template directly after booting.


* Template withdrawal should be available within the same constraints as IPFIX, ie not over UDP.

* If "most sensor nodes only define a single template directly after booting", and that's a standard template (ie, invariant across devices) then there's a huge opportunity for to reduce the protocol overhead and increase reliability by eliminating transmission of standard templates. ie, allow the exporter and collector to pre-share the template definitions. See
draft-aitken-ipfix-pre-defined-templates.


6.4.  Field Specifier Format

   The following text has been copied from
   [RFC7101 <https://tools.ietf.org/html/rfc7101>] for completeness.


* No, the text has not been copied directly - an important modification has been inserted which could easily be overlooked if the above statement was taken at face value.

   Field Length

      The length of the corresponding encoded Information Element, in
      octets.  Refer to [RFC7012 <https://tools.ietf.org/html/rfc7012>].The value 65535 is illegal as there are no variable size encoded elements as they are defined in IPFIX.


* Say "The value 65535 is illegal in TinyIPFIX" and explain why.


7.  TinyIPFIX Mediation

   There are two types of TinyIPFIX Intermediate Processes.  The first
   one can occur on the transition between aconstraint  6LoWPAN and the
   non-constrained network.  This mediation changes the network and
   transport protocol from 6LowPAN/UDP to IP/(SCTP|TCP|UDP) and is shown
   in Figure 16.


* "constrained".
* It might not be a 6LowPAN network.
* It might not be using UDP.


Figures 16 and 17:

* Remove "S.M." because the Exporting Process could be in other kinds of devices too. SM is just one example.
* Remove "6LowPAN" because the TI protocol is applicable to other kinds of network too.
* Remove "UDP" because TCP and SCTP are also possible.
* Remove "(1)".
* All that's left is generic protocol translation?


   Templates MUST be managed the same way as in theconstraint
   environment


* "constrained"

   This mediation can also be performed by an IPFIX Collector before
   parsing the IPFIX message as shown in Figure 18.  There is no need
   for aTinyIPFIX IPFIX parser  if such a mediation process can be
   employed in front of analready  existing IPFIX collector.


* What is a "TinyIPFIX IPFIX parser" ?
* remove "already".

Figure 18: Remove (1).

   The TinyIPFIX Mediation Process has to translate the TinyIPFIX
   Message Header, the TinyIPFIX Set Headers and the TinyIPFIX Template
   Record Header into their counterparts inIPFIX Afterwards, the new
   IPFIX Message Length needs to be calculated and inserted into the
   IPFIX Message header.

* Missing period in "IPFIX Afterwards".


7.1.  Expanding the Message header

   The fields of the IPFIX Message Header that are shown in Figure 5can be determined as follows:


* "can be determined from a TinyIPFIX Message Header as follows".


Export Time

If the "Export Time" in the TinyIPFIX Message Header has a length of 4 octets, the value from the TinyIPFIX Message Header MUST be used for the IPFIX Message Header. If it was omitted, the "Export Time" MUST be generated by the Mediator.

Per section 6.1, the "Export Time" field is dropped - so the Export Time MUST be generated by the Mediator.

      If the IPFIX Message is
      exported again, the "Export Time" field MUST contain the time in
      seconds since 0000 UTC Jan 1, 1970,at which the IPFIX Message leaves the Exporter.   If the Message is passed to an IPFIX
      Collector for decoding directly, the "Export Time" field is the
      time in seconds since 0000 UTC Jan 1 1970 at which the TinyIPFIX
      Message has been received by the TinyIPFIX Exporter.


It would be more useful if the "Export Time" field was always the time ... at which the TinyIPFIX Message has been received by the TinyIPFIX Exporter. Updating to the current time loses some information.

Also, consider if both cases are true: the Mediator converts received TinyIPFIX into IPFIX and provides the data to a local Collector - and also re-exports the data to a remote backup collector. This would require updating the Export Time field for the remote export, which could lead to inconsistencies between the local and remote data (eg, if the collectors are aggregating hourly or daily data, and the updated timestamp put the data into the next hour or next day).


7.2.  Translating the Set Headers

   Set ID

      The field needs to be expanded from one octet to two octets.  If
      the Set ID is below 128, no recalculation needs to be performed.
      This is because all IDs below 128 are reserved for special
      messages and match the IDs used in IPFIX.  The TinyIPFIX Set IDs
      starting with 128  identify TinyIPFIX Data Sets.  Therefore, every
      TinyIPFIX Set IDabove 127  needs to be incremented by 128 because
      IPFIX Data Set IDs arelocated  above 255.


* This is the same case, so use consistent terminology to avoid confusion.
* s/located/numbered/


   Set Length

      The field needs to be expanded from one octet to two octets.  It
      needs to be recalculated by adding a value of 2octet  to match the
      additional size of the Set Header.  For each TinyIPFIX Template
      Record that is contained in the TinyIPFIX Set, 2 more octets need
      to be added to the length.

* "octets"


8.1. TCP / SCTP

   If TCP or SCTP is anoption  and can be used for the transmission of


* Better not to say "option" because it could be confused with IPFIX options. eg, "If TCP or SCTP is used ..."

   TinyIPFIX, Template Management MUST be performed as defined in
   [RFC7101] for IPFIX, with the exception of template withdrawals,
   which are not supported in TinyIPFIX.  Template withdrawals MUST NOT
   be sent byTinyIPFIX exporters.


* If you must rule out template withdrawals, then explain why.
* Capitalise "Exporters" because its a defined term?

   TinyIPFIX Templates are not expected to change over
   time in TinyIPFIX.  Hence, a TinyIPFIX Template that has been sent
   once MAY NOT be withdrawn and MUST NOT expire.

* This begins to explain why template withdrawals are disallowed. Discuss this earlier.

* Anyway, since templates are not expected to change, they should be pre-shared - making template withdrawal impossible. See draft-aitken-ipfix-pre-defined-templates.

   As UDP is used, reliable transport of TinyIPFIX Templates cannot be
   guaranteed and TinyIPFIX Templates can be lost.  A TinyIPFIX Exporter
   MUST expect TinyIPFIX Template loss.  It MUST therefore re-send its
   TinyIPFIX Templates periodically.  A TinyIPFIX Template MUST be re-
   send after a fixed number of N TinyIPFIX Messages that contained
   TinyIPFIX Data Sets that referred to this TinyIPFIX Template.

* This whole issue would be avoided if the exporter and collector pre-shared templates. See draft-aitken-ipfix-pre-defined-templates.

   The
   number N MUST be configured by the application developer.


* No, it should be configurable by the end user according to his tolerance for data loss. One user may require 1:1 (ie, a template per message), where another may want as few templates as possible to conserve bandwidth.

* Again, the issue can be avoided entirely if the exporter and collector pre-shared templates.

- - - - -

Back