Subject: Re: [PSAMP] WG Last call for draft-ietf-psamp-info-07

From: "Tom Petch" <[email-masked]>
Date: Tue, 4 Dec 2007 20:41:02 +0100

Juergen

I have reviewed this document and while I do not know if my review counts as
solid, I do find this I-D less than solid, in several regards.

When providing an update to the catalog of everything you could want to know
about the Internet, as maintained by IANA, I want the instructions to be as
simple and as clear as possible eg

"This creates a new registry, name ..., entries of format ...., initial contents
in section ..., rules for the creation of new entries ..."

"This adds the following new entries to the registry ... as defined in RFC... "

In this regard, Section 10 leaves me underwhelmed.

For example,

   "Appendix B defines an XML schema ...
   This schema introduces a new namespace, which will be
   assigned by IANA according to [RFC3688]."

What is the name etc of this namespace?  RFC3688 requires you to provide
information.  In fact, there is no Appendix B to the document, and even if there
were, I would be inclined to discount anything contained there since the
appendices are defined as not normative.

Or in s.8.2.4

"selectorAlgorithm ... This list will be maintained by IANA. IANA can update
this Information Element as long as there's a new RFC "

Mmm, I doubt it, not unless the IANA Considerations tell them to - which they
don't - and to take the initial contents from 8.2.4.  And "update by RFC" is not
a recognised term - see RFC2434 and/or the Narten I-D that is replacing it

And then there is the registry referred to as 'PSAMP selection method' which
IANA is asked to set up in
   draft-ietf-psamp-protocol-08.txt
Has that got any bearing on this, with its FCFS and Expert Review?

Or again

"This document specifies an initial set of PSAMP Information Elements
   as specified in [I-D.ietf-psamp-sample-tech], as an extension to the
   IPFIX Information Elements"

Several problems; you do not know precisely what the name of the registry is
because draft-ietf-ipfix-info-15.txt does not say precisely; and the use of "an
initial set" strongly suggests that this is the start of a new registry, rather
than an update to an existing one.  And what is that reference to
ietf-psamp-sample-tech ?  Are the definitions in section 8 or aren't they?

If IANA were to fail to carry out these instructions as the authors would wish,
then my sympathy would be with IANA.

More generally, I have reservations about the non normative nature of the
Appendices.  This I-D is for machine consumption, it is Appendix A that is going
to be extracted and imported, the text will be largely unread.  Yet it is
non-normative; if there is a discrepancy, how will people ever know to look at
the text for the correct, normative definitions (given that most users are
unfamiliar with the concept of RFC Errata)?

And then there is Intellectual Property, Note Well and all that, which enables
the IETF (Trust) to publish an RFC and allow it to be translated, reproduced but
not adulterated.  When the appendix is extracted, then the notices that form
part of the RFC will not be taken with it; this should not reduce the protection
it has but does remove the visible sign thereof

Again, given that this appendix will be extracted and consumed independent of
the rest of the I-D, references to RFCxxxx become hard to follow, even
meaningless to some.

Some of you may recognise that these last issues I raise have been with us for
some time and solutions have been devised for them, ie I am thinking of MIB
Modules and the guidelines in RFC4181.  To me this is just another MIB Module,
albeit in XML, and I think that the wisdom of RFC4181 should apply.

I also appreciate that most of what I say applies to
draft-ietf-ipfix-info-15
and that since that I-D is in the RFC Editor's Queue, everyone is ok with it;
well, no, not quite.

Finally, there are two dozen or so places where I find the English somewhat
unusual, not exactly incomprehensible but strange to read and perhaps open to
misunderstanding.

Tom Petch

----- Original Message -----
From: "Juergen Quittek" <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 22, 2007 9:14 AM
Subject: Re: [PSAMP] WG Last call for draft-ietf-psamp-info-07

> Dear all,
>
> The WGLC on this document lasts until the end of this week.
>
> However, I will not close the call without knowing of at least
> three solid reviews from non-authors.
>
> Please have a look at it and tell us what you think.
>
> Thanks,
>
>     Juergen
>
>
> On 12.10.2007 12:56 Uhr  "Juergen Quittek" <[email-masked]> wrote:
>
> > Dear all,
> >
> > A new revision of the PSAMP information model has been posted today.
> > Already the previous version was pretty stable.  For the new version
> > the authors have applied only minor fixes.
> >
> > Now it's time for working group last call on this document.
> >
> > Please read the draft and send us your comments to this list.
> > Please also send a message if you have read the draft and are fine
> > with it.
> >
> > WG last call starts today and will end on Friday, October 26.
> >
> > Thanks,
> >
> >     Juergen
> >
> >
> > --On 12.10.07 05:00 -0400 [email-masked] wrote:
> >
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories.
> >> This draft is a work item of the Packet Sampling Working Group of the IETF.
> >>
> >>
> >> Title           : Information Model for Packet Sampling Exports
> >> Author(s)       : T. Dietz, et al.
> >> Filename        : draft-ietf-psamp-info-07.txt
> >> Pages           : 48
> >> Date            : 2007-10-12
> >>
> >> This memo defines an information model for the Packet Sampling
> >> (PSAMP) protocol.  It is used by the PSAMP protocol for encoding
> >> sampled packet data and information related to the sampling process.
> >> As the PSAMP protocol is based on the IPFIX protocol, this
> >> information model is an extension to the IPFIX information
> >> model.Conventions used in this document
> >>
> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> >> document are to be interpreted as described in RFC 2119 [RFC2119].
> >>
> >> A URL for this Internet-Draft is:
> >> http://www.ietf.org/internet-drafts/draft-ietf-psamp-info-07.txt
> >>
> >> To remove yourself from the I-D Announcement list, send a message to
> >> [email-masked] with the word unsubscribe in the body of
> >> the message.
> >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> >> to change your subscription settings.
> >>
> >> Internet-Drafts are also available by anonymous FTP. Login with the
> >> username "anonymous" and a password of your e-mail address. After
> >> logging in, type "cd internet-drafts" and then
> >> "get draft-ietf-psamp-info-07.txt".
> >>
> >> A list of Internet-Drafts directories can be found in
> >> http://www.ietf.org/shadow.html
> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >> Internet-Drafts can also be obtained by e-mail.
> >>
> >> Send a message to:
> >> [email-masked].
> >> In the body type:
> >> "FILE /internet-drafts/draft-ietf-psamp-info-07.txt".
> >>
> >> NOTE:   The mail server at ietf.org can return the document in
> >> MIME-encoded form by using the "mpack" utility.  To use this
> >> feature, insert the command "ENCODING mime" before the "FILE"
> >> command.  To decode the response(s), you will need "munpack" or
> >> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> >> exhibit different behavior, especially when dealing with
> >> "multipart" MIME messages (i.e. documents which have been split
> >> up into multiple messages), so check your local documentation on
> >> how to manipulate these messages.
> >>
> >> Below is the data which will enable a MIME compliant mail reader
> >> implementation to automatically retrieve the ASCII version of the
> >> Internet-Draft.
> >
> >
>
>
> _______________________________________________
> PSAMP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/psamp

_______________________________________________
PSAMP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/psamp

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 5 Dec 2007 14:57:31 +0100

Juergen

My other comments, mostly editorial (and I see that some have already been
pointed out).

1.  Introduction

   A standard way for the export and storage ...

Suggest 'A standardised way for export and storage ...

   The definition of the PSAMP information and data model is based on
   the IP Flow Information eXport (IPFIX) protocol
   [I-D.ietf-ipfix-protocol].

ipfix-info would seem a more relevant reference for the information and data
model

2.  PSAMP Documents Overview

   This Document: "Information Model for Packet Sampling Exports" (this
   document),

Suggest
   This document, "Information Model for Packet Sampling Exports",

what happened to the psamp-mib I-D? I see no mention of it.

3.  Terminology

   ...
   copied over in this document.
Suggest
   copied into this document.

3.1.  IPFIX Terminology

   The IPFIX terminology section has been entirely copied over from
   [I-D.ietf-ipfix-protocol], except for the IPFIX Exporting Process
   term, which is defined more precisely in the PSAMP terminology
   section.

The choice of what to duplicate in this I-D seems odd.  Of course there is a
balance to be struck; duplicating data makes it easier to access, while risking
the copies getting out of step, and vice versa, as section 6 of this I-D points
out.  I would have preferred to have had the material in sections 5 and 6
duplicated and not the Terminology of section 3; the latter is likely to be
familiar to those who have got this far, the former not.

4.  Relationship between PSAMP and IPFIX

   As described in the PSAMP protocol draft [I-D.ietf-psamp-protocol]

Hopefully this will not remain a draft:-)

         Refer to the Security Considerations section
   for a fuller discussion.

The Security Considerations seem rather short, not exactly a fuller discussion.

   5.  Properties of a PSAMP Information Element

   The PSAMP Information Elements are in accordance with the definitions
   of IPFIX.  Therefore we do not repeat the properties in this draft.
   Refer to sections 2.1 through 2.3 of the IPFIX Information Model
   [I-D.ietf-ipfix-info].

Suggest

   PSAMP Information Elements are defined in accordance with sections 2.1
   to 2.3 of the IPFIX Information Model [I-D.ietf-ipfix-info] to which
   reference should be made for more information.

6.  Type Space

             To avoid duplicated work and to keep
   consistency between IPFIX and PSAMP,

Suggest
   To ensure consistency between IPFIX and PSAMP,

7.  Overloading Information Elements

        e.g. for including in scope
   info and depicting the contents of composites.

Suggest
         e.g. for including in scope information or for depicting the
   contents of composite selectors.

(I know exactly what composites are, they are exotic materials used in the
aerospace and motor industries:-)

8.  The PSAMP Information Elements

data type semantics seem to be omitted from most definitions; unclear why

group=common appears in the XML but not in the current text -  what is it?

   Each Information Element specified in section 8.2 below is allocated
   a unique identifier in accordance with section 5 of the IPFIX
   information model [I-D.ietf-ipfix-info].

section 4 would seem a better reference for unique identifiers

8.2.4.  selectorAlgorithm

      This list will be maintained by IANA.  IANA can update this
      Information Element as long as there's a new RFC specifying the
      algorithm and any new Information Elements which are required.

See previous post

8.2.5.  samplingPacketInterval

   Description:

      This Information Element specifies the number of packets that are
      consecutively sampled.  For example a value of 100 means that 100
      contiguous packets are sampled.

Suggest being consistent with contiguous/consecutive; they are not (quite)
synonyms.

8.2.12.  dataLinkFrameSize

   Description:

      This Information Element specifies the size of the sampled data
      link frame, and SHOULD be checked before analysing higher layer
      protocols.

What is included in the link frame?  This is a fraught question to which I do
not see a right answer but one that each context should clarify eg is padding
included, bit stuffing, Ethernet preamble, CRC, ....

8.2.16.  mplsLabelStackSection

      With sufficient length, this element also reports octets from the
      MPLS payload, subject to [RFC2804].  See the Security
      Considerations section.

      See [RFC3031] for the specification of MPLS packets.

      See [RFC3032] for the specification of the MPLS label stack.

See previous post; the XML, if not this text, will be extracted and used
independently of the RFC whereupon such as [MPLSREF] becomes hard, impossible
even, to understand.

8.2.22.  observationTimeSeconds

Given multiple, different time precisions, is there any guidance on which to use
when - I looked for it in psamp-tech to no avail.

9.  Security Considerations

Section 4 points here for a 'fuller discussion' which this hardly seems to
qualify as.

is traffic analysis a perceived threat? If not, why not?

              to guarantee the
   integrity and confidentiality of the exported information.

Authentication? that does get a mention in psamp-framework

            Such
   protocols are defined in separate documents, specifically the PSAMP
   protocol document [I-D.ietf-psamp-protocol].

Well, no actually, that just points to ipfix-protocol

10.  IANA Considerations

Much already said, but

        New assignments
   for PSAMP Information Elements will be administered according to
   rules explained in the "IANA Consideration"

Suggest
          Considerations

                                         ...  section of the IPFIX
   Information Model document [I-D.ietf-ipfix-info].

which is unfortunate as it refers to s2.3 for naming, but omits any reference to
s2.1 or s2.2.  I suggest an explicit reference to sections 2.1, 2.2 and 2.3 of
ipfix-info

Finally, I find it a shame that this I-D makes references to other I-Ds in the
form [I-D.ietf-psamp-protocol] I much prefer the [IPFIX-ARCH] style as used on
the other PSAMP doucments.

Solid review?  up to you to judge that one.

Tom Petch

---

From: "Thomas Dietz" <[email-masked]>
Date: Wed, 19 Dec 2007 14:57:18 +0100

Dear Tom,

find my comments inline.

-- 
Thomas Dietz                       E-mail: [email-masked]
NEC Europe Ltd.                    Phone:  +49 6221 4342-128
NEC Laboratories Europe            Fax:    +49 6221 4342-155
Network Research Division
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.nw.neclab.eu

NEC Europe Limited                 Registered in England 2832014
Registered Office: NEC House, 1 Victoria Road, London W3 6BL

> -----Original Message-----
> From: Tom Petch [mailto:[email-masked]]
> Sent: Dienstag, 4. Dezember 2007 20:41
> To: Juergen Quittek; [email-masked]

I agree that the wording could be clearer here.

> appendices are defined as not normative.

As you said there is no Appendix B because this paragraph is a left-over
from IPFIX. So you need to complain this to IPFIX, too.

> Has that got any bearing on this, with its FCFS and Expert Review?

I think the new protocol draft (09) is very clear on that. The information
model draft will be updated accordingly.

> ietf-psamp-sample-tech ?  Are the definitions in section 8 or aren't

Agreed that the link to [I-D.ietf-psamp-sample-tech] is somewhat misleading
here. Nevertheless, I think the sentence clearly states "as an
extension...". And yes the definitions are in section 8.

> then my sympathy would be with IANA.

Well, the sense of a WG last call is to make things clearer (which is
already done in the protocol draft).

> unfamiliar with the concept of RFC Errata)?

Well, people implementing an RFC should read it at least once. It is stated
clearly that Appendix A is not normative. Nevertheless, section 8 is created
from the XML document in Appendix A, so there will be no discrepancy between
Appendix and normative text.

> it has but does remove the visible sign thereof

To solve this we could include an XML comment similar to the one used in MIB
modules giving the copyright etc.

> the rest of the I-D, references to RFCxxxx become hard to follow, even

Well, as stated above, given the fact that somebody implements an RFC he
must be used to IETF procedures and RFCs otherwise he will hardly understand
what he is doing. Thus he will know how to retrieve an RFC.

> albeit in XML, and I think that the wisdom of RFC4181 should apply.

Agreed, see above.

> unusual, not exactly incomprehensible but strange to read and perhaps

Agreed, those will be address regarding your second e-mail and all the
others pointing out these issues.

Best Regards,

Thomas

---

From: "Thomas Dietz" <[email-masked]>
Date: Wed, 19 Dec 2007 16:08:18 +0100

Dear Tom,

I applied your editorial changes and just want to comment a few other issues
inline...

> Sent: Mittwoch, 5. Dezember 2007 14:58

The problem with the MIB is that this document is delayed until the IPFIX
MIB is ready. I am not sure if the WG wants to hold back the Information
Model until the MIB is ready???

> group=common appears in the XML but not in the current text -  what is

The group=common is only a grouping for elements logically for automatically
processing it in the command chain and does not have any significance for
the draft.

> s2.1 or s2.2.  I suggest an explicit reference to sections 2.1, 2.2 and

I hope the new section fits better...

> the other PSAMP doucments.

The references are automatically created by xml2rfc in that way. Anyway, I
don't consider any style of reference as a SHAME... The style of these
references is irrelevant since they are gone in the final RFC anyway!!!

Best Regards,

Thomas

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 21 Dec 2007 11:17:34 +0100

Picking up on the MIB point, I would not want this I-D delayed because the MIB
I-D is an abeyance, but, on the assumption that the MIB I-D will progress
eventually (because the IETF require it), then I would include a sentence on it
and an informative reference to the MIB I-D, work in progress, as ever.  This
I-D can then progress to RFC without delay.

Tom Petch

----- Original Message -----
From: "Thomas Dietz" <[email-masked]>
To: "Tom Petch" <[email-masked]>; "Juergen Quittek"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, December 19, 2007 4:08 PM
Subject: RE: [PSAMP] WG Last call for draft-ietf-psamp-info-07