Subject: RE: [ipfix] AD review for: draft-ietf-ipfix-protocol-19.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 6 Apr 2006 01:38:21 +0200

Thanks. Basically I am happy with all you answers.

Some (minor) additional remarks inline

> -----Original Message-----
> From: Benoit Claise [mailto:[email-masked]]
> Sent: Friday, March 31, 2006 00:30
> To: Wijnen, Bert (Bert)
> Cc: 'Ipfix Wg' (E-mail) (E-mail); David Kessens (E-mail); Dan 
> Romascanu
> (E-mail)
> Subject: Re: [ipfix] AD review for: draft-ietf-ipfix-protocol-19.txt
> 
> 
> Bert, all,
> 
> Thanks for your comments. See inline.
> For clarity purposes, I removed the obvious editorial 
> improvements, which have been inserted already. 
> 
> Note that I made the following changes:
> - I modified all occurrences of Source ID to Observation Domain ID.
> - As proposed by Brian Trammell, I clarified:
> 
> Add to the end of 10.2.4.1 Association Establishment: 
> "Each SCTP stream over which TLS [TLS] will be used MUST be 
> established as a fully reliable bidirectional stream as 
> required by RFC 3436." 
> 
> Insert a new third paragraph to 10.2.4.2 Association Teardown: 
> "If TLS [TLS] is used, the Process initiating association 
> teardown SHOULD send a close_notify alert over each TLS 
> stream before closing the SCTP association." 
> 
> Append to the second paragraph to 10.2.4.3 Stream: 
> "Only fully reliable bidirectional streams are available if 
> TLS [TLS] as used, as required by RFC 3436." 
> 
>           [RFC3436] added as a normative reference
> 
> - Sect 3.
>   States that Template Sets MUST be sent periodically when 
> UDP is used.
>   What if TCP or or SCTP are used? Might want to state what expected
>   behaviour is in those cases as well.
>   
> I agree this is confusing, as we don't know yet at this stage 
> that UDP is a MAY.
> Since these are examples, since the first two examples don't 
> discuss any transport protocol issues and since the transport 
> protocol is explained at length in the section 10, I have 
> removed the sentences. 
> 
> 
> - sect 3.1 under SOurce ID
>   I do not understand the last sentence. WHat does it mean?
>   pls clarify in text.
>   
> As proposed in http://ipfix.doit.wisc.edu/archive/3145.html, 
> I moved it into the section "3.4.2.1 Scope... where it 
> naturally belongs 
> 
> 
> - Page 16 under padding
>   s/zero (0) octets/zero (0) valued octets/
>   or "octets with a value of zero (o)" ??
>   
> Done. "the padding octet(s) MUST be composed of zero (0) 
> valued octets. " 
>   Last sentence under "padding" may need a period or semicolon in
>   the middle of the sentence?
>   
> Done.
> 
> - Sect 5/6 speak about ...DeltaUSeconds, but I cannot find 
> that term in
>   INFO spec. It talks about ...DeltaMicroSeconds. Is that 
> what you mean?
>   
> Corrected already. Someone mentioned it on the mailing
> 
> - sect 6.1.3
>   I'd like to see a reference to the IEEE spec for floats.
>   
> Corrected already. This was discussed on the mailing list.
> 
>  6.1.3   float32 
>     
>    The float32 data type is encoded as an IEEE 
> single-precision 32-bit 
>    floating point-type, as specified in [IEEE.754.1985].   
> 
>  6.1.4   float64 
>     
>    The float64 data type is encoded as an IEEE 
> double-precision 64-bit 
>    floating point-type, as specified in [IEEE.754.1985]. 
> 
> - sect 6.1.5 
>   I am not sure that by saying "it is expected that strings 
> will be coded
>   in UTF-8 format" will guanrantee interoiperability?
>   Maybe better use MUST (RFC2119) language.
> 
> I have right now:
> 
> The data type string represents a finite length string of 
> valid characters of the Unicode character encoding set.  The 
> string data type MUST be encoded in UTF-8 format.  The string 
> is sent as an array of octets using an information element of 
> fixed or variable length. The length of the information 
> element specifies the length of the octetarray.
> Since this is required for interoperability, I think the 
> "MUST" is more appropriate. So I changed all definitions in 
> 6.1.X: from "is encoded" to "MUST be encoded"
> 
> 
> Note: we have the same sentence in [IPFIX-INFO]:
> 
>    It is expected that strings
>    will be encoded in UTF-8 format, which is identical in encoding for
>    ASCII characters, but also accommodates other Unicode multi-byte
>    characters.
> 
> I think this should be removed, as the information model 
> should not tell how to encode the data.
> 
> 
> 
> 
> 
>   Last sentence of 6.1.5 talks about "NUL" characters. That 
> again seems
>   to be ASCII language. Maybe better state "zero valued octets" .
>   
> Following some discussions, the sentence "In case of fixed 
> length Information Element, if padding is required, padding 
> MUST be composed of NUL character(s)." has been removed. All 
> padding related info is now in the padding section.
> 
> - sect 6.1.6
>   YOu might want to add a sentence how long this can serve us.
>   I believ it is something like 146 years,
>   
> 136 years. Added.
> 
> The data type dateTimeSeconds represents a time value in 
> units of seconds normalised to the GMT timezone.  It MUST be 
> encoded in a 32-bit integer containing the number of seconds 
> since 0000 UTC Jan 1st 1970. The 32-bit integer allows the 
> time encoding up to 136 years. 
> 
> 
> - sect 6.2 speaks about signed64/unsigned64 and also for 32 and 16.
>   Where are those types defined??
>   
> Previous text:
> 
>  6.1.1   Integral Data Types 
>     
>    Integral data types - octet, unsigned16, unsigned32 and 
> unsigned64 - 
>    are encoded using the default canonical format in network byte 
>    order. 
> 
> New text:
> 
>  6.1.1   Integral Data Types 
>     
>    Integral data types - octet, signed octet, unsigned16, 
> signed16, unsigned32
>    signed32, signed64 and unsigned64 - are encoded using the 
> default canonical 
>    format in network byte order.  Signed Integral data types 
> are represented in
>    two's complement notation.
> 
> 
> - one but last para on page 33
>   "sufficient time" should be defined/explained somewhat don't
>   you think so?
>   
> I added the last sentence.
> "The Template Withdraw Message MUST not be sent until 
> sufficient time has elapsed to allow the Collecting Process 
> to receive and process the last Data Record using this 
> Template information. This time MUST be configurable.  A 
> suitable default value is 5 seconds after the last Data 
> Record has been sent.
> 
> 
> 
> - I wonder if the one but last para of section 9 is a nice opening
>   for DoS attacks?
>   
> The sentence is: "If the Collecting Process receives a 
> Template Withdraw message for a Template Record it has not 
> received before, it MUST reset the SCTP association, discard 
> the IPFIX Message, and SHOULD log the error as it does for 
> malformed IPFIX Messages."
> 
> The point is that we need that statement because it means 
> that the collector is confused about its own status. And the 
> only solution is to shutdown the SCTP association, so that 
> the exporter will resend all the templates with a new SCTP 
> association.
> 
> - sect 10.2.6
>   Where/how is the treshold specified?
>   Same for sect 10.4.1.1
>   
> I'm not sure how to answer the questions:
>     Where? on the exporter

So you could add that

>     How? based on the user appreciation. This is exactly why 
> we have a MAY statement.
> We could say "exceeds a locally configured threshold. By 
> default this time is foo secs." However, I have no clue what 
> the value of foo should be.
> If the statements are too vague without the default value, I 
> simply propose to remove them.
> 

So does nobody have an idea what "foo" would be?

> - sect 10.3.7
>   It is unclear to me how/where the template lifetimes are specified,
>   defined or configured.
>   
> We wrote the following sentence:
>    The Template lifetime at 
>    the Collecting Process MUST be at least 3 times higher that the 
>    Template refresh timeout configured on the Exporting Process.  
> Isn't it enough?
> 

I guess I missed that on my first review. So OK

> 
> - sect 11.4 last para
>   I guess that just depends of who/where the attacker is, no?
>   WHat if it is an internal ISP employee?
>   
> Old text:
> 
>    The use of a dedicated network prevents IPFIX Messages from being 
>    inspected by an attacker. 
> 
> New text:
>    The use of a dedicated network prevents IPFIX Messages from being 
>    inspected by an external attacker. 
> 

at least that is clearer. Hope security ADs are OK with that too.

> - sect 12.1
>   I do not think the IPfix version number is an IANA controlled thing.
>   I also think you want that to be changebale only by an IETF standards
>   action (as opposed to just IETF consensus). Afetr all you want this
>   protocol to be stds track. 
>   
> It was actually the intend behind the sentence:
> 
>    "Changes in either IPFIX Version Number or IPFIX Set ID assignments 
>    require an IETF Consensus, i.e. they are to be made via RFCs 
>    approved by the IESG."
> 
> Should we simply erase the section 12.1?
> Or make clearer?
>    "Changes in either IPFIX Version Number or IPFIX Set ID assignments 
>    are not controlled by IANA, but by an RFC approved by the IESG." 
> 

I think if you make it "Standards Action" instead of "IETF Consensus" that
you cover it best and that that also represents what you say is intended.

> - sect 12.2 seems to be IPFIX-INFO material and not protocol 
> material??
>   
> Section 12.2 erased.
> 
> 
> - Sect 12.1
>   The "IPFIX Set ID" starts (I think) a new registry. So you MUST
>   describe under IANA considerations how to set it up and what the
>   rules are for new assignements. You have that text (more or less) in
>   sect 3.3.2, but you must spell it out here for IANA as well.
>   
> New section "12.x Set ID"
> 
> Set ID value identifies the IPFIX Set. Set ID values of 0 and 
> 1 are not used for historical reasons [RFC3954]. A value of 2 
> is reserved for the Template Set. A value of 3 is reserved 
> for the Option Template Set. All other values from 4 to 255 
> are reserved for future use. Values above 255 are used for Data Sets. 
> The new Set ID values are defined as "Specification Required" 
> [RFC 2434] prior to the assignment by IANA.
> 

If you do "Specification Required", does that mean RFC?
Or some vendor specific document?
Or some other SDO?
Or what?

Even if the specification is available, do you want some expert review?
IANA does not have the subjetc matter expertise to judge if a specification
iw well enough to justify a new assignment.

> 
>   Then you have a set of Set IDs that get assigned by this document
>   and you should list them clearly for IANA so they can do the initial
>   population of the registry.
> 
> - It seems to me that sect 13 is more an APPENDIX and so non-normative?
>   Might be good to then list it as appendix and state that it is 
>   non-normative.
>   
> I moved the appendix just before the reference section.
> ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt 
> doesn't mention that we should mention something about non-normative 
> ... unless I missed something?

It is just best to be explicit if such a section is or is not normative.
We have done so in many earlier RFCs.

The below is all fine

Bert

-----------

- Refrences.
  - is 1889 really normative?
  
Moved to informative

  !! Missing citation for Informative reference:
  P060 L046:    [RFC3955] Leinen, S., "Evaluation of Candidate Protocols for IP Flow
  
Removed this reference.

- sect 3.1 remove one of the two words "format" 
  
  You migth also want to add a sentence to explain why the version
  field is 0x000a for this version.
  
I inserted this proposal

Version
Version of Flow Record format exported in this message.  The value of this field is 0x000a for the current version, incrementing by one the version used in the NetFlow services export version 9 [RFC3954].

- page 33
  s/Disused/Unused/ ??
Let me copy the entire paragraph:
   Disused Templates SHOULD be deleted. Before reusing a Template ID 
   the disused Template MUST be deleted.  In order to delete an 
   allocated Template, the Template is withdrawn through the use of a 
   Template Withdraw Message.  

The term "unused" is already applied in this section with a different meaning.
For example "an unused Template ID MUST be used". This means: allocate a new Template ID.
However, in the sentence you pointed out: we want to say: the templates that are not used anymore.
I propose:
	"The Templates that are not used anymore SHOULD be deleted. Before reusing a Template ID, the Template MUST be deleted"

Thanks again for your comments.  

Regards, Benoit.

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Brian Trammell <[email-masked]>
Date: Wed, 5 Apr 2006 22:27:56 -0400

Benoit,

One minor typographical edit, below

>> TLS [TLS] as used, as required by RFC 3436."
              is used

Regards,

Brian

---

From: Sven Anderson <[email-masked]>
Date: Thu, 06 Apr 2006 17:32:42 +0200

Hi all,

I will take the opportunity to ask two questions of understanding. Maybe
someone can take a short moment to help me out.

>>    Template refresh timeout configured on the Exporting Process.  

How can the Collecting Process make this sure? I can't remember, that
there was a way for the Exporting Process to tell the Template refresh
timeout. So this is a "MUST" in a protocol specification which is not
covered by the protocol itself? (If I decide to use IPFIX without a
parallel configuration protocol, this "MUST" goes to the administrator?)

>> for the Option Template Set. All other values from 4 to 255 

Side note: You are mixing "Option Template Records", "Options Template
Records" and "Options Templates Records" all over the document. Is this
intended?

I never really understood the purpose of Option Template Records and
Scopes. Isn't every Flow Key, that is, everything but counters, a kind of
scope? When I have two linecards, it doesn't make a difference, if I have
two Metering Processes on each of them, "tagging" the flows with a
lineCardId (where you could use Scopes), or if I have one Metering
Process, and the Flows have a normal lineCardID Flow Key. It will result
in the same Flows. So for what exactly do you _need_ scopes?

Thanks and cheers,

Sven

-- 
Sven Anderson
Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de
Georg-August-Universitaet Goettingen
Lotzestr. 16-18, 37083 Goettingen, Germany

---

From: Benoit Claise <[email-masked]>
Date: Thu, 27 Apr 2006 11:13:21 +0200

Thanks Brian, corrected.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 27 Apr 2006 11:11:32 +0200

Hi Bert,

Due the a rare problem with the copyright year in the protocol draft 
version 20 (problem that I haven't spot at the posting time, before my 
vacation), the was not posted until a few days ago. Sorry for the 
inconvenience.
Note: the problem was not discovered by idnits and the idnits author has 
been notified.

Only keeping the ongoing comments in your email below.
>> I'm not sure how to answer the questions:
Previous sentence:

   The Exporter MAY log an alarm if the time to establish the association 
   exceeds a specified threshold. 

New sentence:
   The Exporter MAY log an alarm if the time to establish the association 
   exceeds a specified threshold, configurable on the Exporter.

> So does nobody have an idea what "foo" would be?
It depends so much on the capabilities of the SCTP exponential backoff 
feature, that we were thinking to leave open... instead of fixing an 
arbitrary value.
> you cover it best and that that also represents what you say is intended.
It makes sense to me now. (re-read RFC 2434 in the mean time)

Previous sentence:

New sentence:

   "Changes in either IPFIX Version Number or IPFIX Set ID assignments 
   require an Standards Action [RFC 2434], i.e. they are to be made via Standards 
   Track RFCs approved by the IESG."

> iw well enough to justify a new assignment.
Taking into consideration the previous remark, here is the new IANA 
section (no more sub-sections)

Considerations for assigning them are discussed in this section, using 
the example policies as set out in the "Guidelines for IANA 
Considerations" document IANA-RFC [RFC2434].

IPFIX Messages use two fields with assigned values.  These are the IPFIX 
Version Number, indicating which version of the IPFIX Protocol was used 
to export an IPFIX Message, and the IPFIX Set ID, indicating the type 
for each set of information within an IPFIX Message.  Set ID values of 0 
and 1 are not used for historical reasons [RFC3954].  A value of 2 is 
reserved for the Template Set.  A value of 3 is reserved for the Option 
Template Set.  All other values from 4 to 255 are reserved for future 
use. Values above 255 are used for Data Sets. 

Changes in either IPFIX Version Number or IPFIX Set ID assignments 
require an Standards Action [RFC 2434], i.e. they are to be made via 
Standards Track RFCs approved by the IESG.

> We have done so in many earlier RFCs.
New initial sentence for this section

This appendix, which is a not a normative reference, contains IPFIX 
encoding examples.

Thanks again for your feedback.
Let me post a new version of the draft by today.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 27 Apr 2006 11:31:41 +0200

Hi Sven,
> parallel configuration protocol, this "MUST" goes to the administrator?)
In case of UDP, you must have a lifetime on the Collector. This lifetime 
MUST be bigger than the refresh time by a factor of 3 in case some UDP 
packets are missed.
That's right the spec. doesn't specify how to export the refresh 
timeout, even if that could be done easily with an option template 
record... We choose not to describe in order not to overload the spec. 
with yet another option template record. Most of the time, leaving the 
default value for the template refresh timeout on all the exporters 
would logically point to the value of the template lifetime on the 
collector.
> Records" and "Options Templates Records" all over the document. Is this
No. "Options Template Records" is the right one.
Corrected. Thanks.
> in the same Flows. So for what exactly do you _need_ scopes?
A good example of the scope is described at 
draft-boschi-ipfix-reducing-redundancy-01 
<https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=14385>

Regards, Benoit.