Subject: [ipfix] info-model update: version -10

From: Juergen Quittek <[email-masked]>
Date: Tue, 09 Aug 2005 22:42:51 +0200

Dear all,

I just submitted a new version of the IPFIX info model to the
I-D repository.  Until it gets posted you can preview it at
<ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-info-10.txt>.

Main changes include:
  - rephrased section 2.3, third bullet item:
    removed 'pre' prefix, elaborated 'post' prefix
  - added paragraph 4 of section 5 on the 'post' prefix
  - changed descriptions of all information element with
    'post' prefix
  - reordered information elements with 'post' prefix such
    that all of them immediately follow the corresponding
    unprefixes element (if such an element exists).
  - elaborated description of flowEndReason
  - fixed several minor typos

You can see all changes between version -09 and -10 at
<ftp://ftp.netlab.nec.de/pub/internet-drafts/diff-09-10.html>.

I hope, this is the version that will be submitted to the IETF.
If you think we still need more improvement, then please comment.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

--
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: Sven Anderson <[email-masked]>
Date: Mon, 29 Aug 2005 19:38:25 +0200

Hi Juergen,

>    unprefixes element (if such an element exists).
[...]
> If you think we still need more improvement, then please comment.

On 4th of August I wrote a description of an alternative proposal to the
middlebox issue. I'm wondering that there is no reaction at all to this.
Is it really so much out of question? I'm fine with any reason, why it is
not suitable, but I'd appreciate a short note about the reason. ;-)

Thanks,

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: Tue, 30 Aug 2005 14:44:46 +0200

Hi Juergen,

[sorry for the delay, I was on vacation for 3 weeks]
I have one editorial issue for all the post I.E.s

I see that you put the references to the post specifications in every 
"post" I.E.
If I take for example.

5.3.21  postClassOfServiceIPv4

   Description:
      The definition of this Information Element is identical to the
      definition of Information Element 'classOfServiceIPv4', except for
      the special semantics of the 'post' prefix that is described in
      the third bullet item of section 2.3 and the fourth paragraph of
      section 5.

I'm wondering...
Do you expect that the references will be present for all I.E.? I guess so
Do you expect that the references will be present for future 
IANA-administered I.E? I guess so. Then you need a reference to the RFC 
number.
What will happen when we will have a new RFC number (for example, we 
move from proposed standard to draft standard to internet standard). To 
be consistent, we should reference the newly defined RFC.
What will happen for the already specified I.E. when a new RFC number is 
out? I guess that we can't/don't want to change their descriptions to 
refer to the new RFCs.
So I'm wondering if this isn't too complicated and a source of confusion?

I've always been referring to post as "after packet treatment" 
specifically for this reason.
What about simplifying the postClassOfServiceIPv4 I.E.s to :

5.3.21  postClassOfServiceIPv4

   Description:
      The definition of this Information Element is identical to the
      definition of Information Element 'classOfServiceIPv4', after
      packet treatment.

To make sure there is no ambiguity, the draft could further clarify.

   o  Middleboxes [RFC3234] may change Flow properties, such as the DSCP
      value or the source IP address.  If an IPFIX Observation Point is
      located in the path of a Flow before one or more middleboxes that
      potentially modify packets of the Flow, then it may be desirable
      to report also flow properties after the modification performed by
      the middleboxes.  THIS IS REFERRED TO AS "AFTER PACKET TREATMENT" IN 
      INFORMATION ELEMENT DESCRIPTIONS.

"after packet treatment" is the best term I could come up with. However, if you have a better term in mind, fine with me. 
The main point is to avoid the reference in the description.

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 30 Aug 2005 17:10:27 +0200

Benoit,

> specifically for this reason.

You are right. Bad referencing as I did here is not a good idea.
However, just saying 'after packet treatment' without a reference
to what is meant by packet treatment does neither help.
(For example in the context of a NeTraMet-based IPFIX implementation
"packet treatment" would probably refer to processing the packet
in the packet matching engine.)

>       definition of Information Element 'classOfServiceIPv4', after

Alternative suggestion:

      The definition of this Information Element is identical to the
      definition of Information Element 'classOfServiceIPv4', except
      that it reports a potentially modified value caused by a
      middlebox function after the packet passed the observation point.

> The main point is to avoid the reference in the description.

If you define AFTER PACKET TREATMENT as above, you still need a reference
to this definition.

Thanks,

    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Wed, 31 Aug 2005 09:17:27 +0200

Juergen,

>      middlebox function after the packet passed the observation point.

Fine with me. Thanks.

Regards, Benoit.

>> "after packet treatment" is the best term I could come up with. 
>> However, if you have a better term in mind, fine with me.