From psamp-bounces@ietf.org Sat Dec 01 21:54:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyexo-0000LK-2T; Sat, 01 Dec 2007 21:53:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyexm-0000KF-MH for psamp@ietf.org; Sat, 01 Dec 2007 21:53:46 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iyexk-0004pp-Fl for psamp@ietf.org; Sat, 01 Dec 2007 21:53:46 -0500 X-IronPort-AV: E=Sophos;i="4.23,239,1194238800"; d="scan'208,217";a="82756095" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 01 Dec 2007 21:53:43 -0500 X-IronPort-AV: E=Sophos;i="4.23,239,1194238800"; d="scan'208,217";a="135948699" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Dec 2007 21:53:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PSAMP] FW: Last Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP) Protocol Specifications) to Proposed Standard Date: Sun, 2 Dec 2007 03:53:35 +0100 Message-ID: In-Reply-To: <474FF9BA.9020109@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PSAMP] FW: Last Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP) Protocol Specifications) to Proposed Standard Thread-Index: AcgzR7vgaQj//RwkTJih4O0uYj8/uQBRjdIw References: <47345DDA.3070805@cisco.com> <474FF9BA.9020109@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" X-Spam-Score: 0.0 (/) X-Scan-Signature: ecc3a678f36d06d556925e6a5174d2ac Cc: psamp@ietf.org X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0649111041==" Errors-To: psamp-bounces@ietf.org This is a multi-part message in MIME format. --===============0649111041== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8348E.87C39909" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8348E.87C39909 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Benoit, =20 The TSV Area Director sent us the message below on 11/21, which I forwarded to Juergen. Basically the TSV review did not find any major issues.=20 =20 Dan =20 =20 ------------- =20 Juergen, You can consider now the PSAMP documents Last Call period closed.=20 Please let me know if any of these need a revision following the comments received during LC.=20 Thanks and Regards, Dan =20 =20 -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com ] Sent: Wednesday, November 21, 2007 10:52 AM To: Romascanu, Dan (Dan) Cc: Magnus Westerlund Subject: tsv-dir review of the psamp documents Hi, Dan, Mark Allman has reviewed the set of psamp documents and says that he only found nits. So from our side, these are ready to hit the IESG.=20 Thanks for giving us the extra time for this review! Lars =20 ------------------------ =20 =20 =20 =20 =20 ________________________________ From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Friday, November 30, 2007 1:54 PM To: Romascanu, Dan (Dan) Cc: psamp@ietf.org Subject: Re: [PSAMP] FW: Last Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP) Protocol Specifications) to Proposed Standard =09 =09 Dan, =09 Benoit, =20 The comments resolutions that you suggest seem appropriate to me.=20 =20 It's fine to wait for the transport area experts comments before issuing a revised I-D. Any news on that front?=20 Based on IPFIX and PSAMP status http://www1.ietf.org/mail-archive/web/ipfix/current/msg04203.html, [PSAMP-PROTO] is one of the bottleneck. The next one is [PSAMP-INFO], for which we've got 2 reviews already. A third one is missing. =09 Regards, Benoit. =09 =09 =20 Dan =20 =20 =20 =20 ________________________________ From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Friday, November 09, 2007 3:17 PM To: Romascanu, Dan (Dan) Cc: ietf@ietf.org; psamp@ietf.org; IANA Subject: Re: [PSAMP] FW: Last Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP) Protocol Specifications) to Proposed Standard =09 =09 Dan, =09 Thanks for your review. I will address all your comments for in the next version. However, I don't plan to have a new version before the Transport Area directors have reviewed the doc (they asked for an extended deadline) Please quickly evaluate if you agree with the proposed changes. See inline. =09 Here are my comments. They are quite a few, it may be because it's a good document.=20 =09 Technical:=20 =09 1. Section 3.2.1 - Packet Content. The definition includes in the packet header the link layer header. This deserves at least a note, which should draw the attention on the fact that some if the Observation Point is located at the interface of an IP router the link header information may not be available.=20 OLD =09 Packet Content=20 =20 The Packet Content denotes the union of the packet header (which=20 includes link layer, network layer and other encapsulation headers)=20 and the packet payload.=20 =09 NEW =09 Packet Content=20 =20 The Packet Content denotes the union of the packet header (which=20 includes link layer, network layer and other encapsulation headers)=20 and the packet payload. Note that, depending on the Observation Point, the link layer information might not be available. =20 Moreover, all examples later in the document use only IP header IE, it would be useful to change or add one example to show sub-IP header information. =20 Changing the section " 6.4.1 Basic Packet Report " =09 OLD =09 Here is an example of a basic Packet Report, with a=20 SelectionSequenceId value of 9 and ipHeaderPacketSection Information=20 Element of 12 bytes, 0x4500 005B A174 0000 FF11 832E, encoded with a=20 fixed length field.=20 =20 IPFIX Template Record:=20 =20 0 1 2 3=20 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=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Set ID =3D 2 | Length =3D 24 |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Template ID =3D 260 | Field Count =3D 4 |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | selectionSequenceId =3D 301 | Field Length =3D 4 |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | digestHashValue =3D 326 | Field Length =3D 4 | =20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | ipHeaderPacketSection =3D 313 | Field Length =3D 12 |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |observationTimeMicroseconds=3D324| Field Length =3D 4 |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 NEW =09 Here is an example of a basic Packet Report, with a=20 SelectionSequenceId value of 9 and dataLinkFrameSection Information=20 Element of 12 bytes, 0x4500 005B A174 0000 FF11 832E, encoded with a=20 fixed length field.=20 =20 IPFIX Template Record:=20 =20 0 1 2 3=20 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=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Set ID =3D 2 | Length =3D 24 |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Template ID =3D 260 | Field Count =3D 4 |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | selectionSequenceId =3D 301 | Field Length =3D 4 |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | digestHashValue =3D 326 | Field Length =3D 4 | =20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | dataLinkFrameSection =3D 315 | Field Length =3D 12 |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |observationTimeMicroseconds=3D324| Field Length =3D 4 |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 2. Section 8.2 - PSAMP IANA considerations mention the need of a group of experts to advise on new PSAMP selection methods. This seems a little overkill to me, as I do not expect this advise to be required too often in the future. One designated expert to work with IANA would seem to me sufficient, of curse in doing his work he may consult with a team, but this needs not be mentioned here.=20 =20 Note: this was done to be inline with IPFIX information model draft: =09 New assignments for IPFIX Information Elements will be administered by IANA through Expert Review [RFC2434], i.e. review by one of a group of experts designated by an IETF Area Director. However, I understand your point. =09 Changes to the section " 8.2 PSAMP Related Considerations " =09 OLD: =09 New assignments for the PSAMP selection method will be administered=20 by IANA, on a First Come First Served basis [RFC2434], subject to=20 Expert Review [RFC2434], i.e. review by one of a group of experts=20 designated by an IETF Operations and Management Area Director.=20 NEW: =09 New assignments for the PSAMP selection method will be administered=20 by IANA, on a First Come First Served basis [RFC2434], subject to=20 Expert Review [RFC2434]. Editorial =09 1. The document is using a capitalization convention where all terms defined or mentioned in Section 3 are being written capitalized. This includes quite common and often used terms like Sample or Flow. In order to avoid comments about this capitalization style I suggest to explain this convention in the terminology section.=20 =20 OLD =09 3. Terminology=20 =20 As the IPFIX export protocol is used to export the PSAMP information,=20 the relevant IPFIX terminology from [IPFIX-PROTO] is copied over in=20 this document. The terminology summary table in section 3.1 gives a=20 quick overview of the relationships between the different IPFIX=20 terms. The PSAMP terminology defined here is fully consistent with=20 all terms listed in [PSAMP-TECH] and [PSAMP-FMWK] but only=20 definitions that are relevant to the PSAMP protocol appear here. =20 Section 5.4 applies the PSAMP terminology to the IPFIX protocol=20 terminology.=20 NEW =09 =09 3. Terminology=20 =20 As the IPFIX export protocol is used to export the PSAMP information,=20 the relevant IPFIX terminology from [IPFIX-PROTO] is copied over in=20 this document. All terms defined in this section have their first=20 letter capitalized when used in this document. The terminology=20 summary table in section 3.1 gives a quick overview of the=20 relationships between the different IPFIX terms. The PSAMP=20 terminology defined here is fully consistent with all terms listed in [PSAMP-TECH] and [PSAMP-FMWK] but only definitions that are=20 relevant to the PSAMP protocol appear here. Section 5.4 applies=20 the PSAMP terminology to the IPFIX protocol terminology.=20 2. Many of the figures get fragmented at print. Now I know that it's difficult to avoid this in a document with about 20 figures, and doing .np before each figure would be quite a waste, but I suggest that at least figure C which is a key architecture diagram be kept on one page. =20 Ok. I will take care of that. =09 Regards, Benoit. =09 Dan =09 =09 =09 =20 =09 -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org]=20 Sent: Monday, October 22, 2007 4:46 PM To: IETF-Announce Cc: psamp@ietf.org Subject: Last Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP) Protocol Specifications) to Proposed Standard=20 =09 The IESG has received a request from the Packet Sampling WG (psamp) to consider the following document: =09 - 'Packet Sampling (PSAMP) Protocol Specifications ' as a Proposed Standard =09 The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-11-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. =09 The file can be obtained via =09 http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-08.txt =09 =09 IESG discussion can be tracked via =09 https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 10963&rfc_flag=3D0 =09 =09 =09 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org =09 https://www1.ietf.org/mailman/listinfo/ietf-announce =09 =09 _______________________________________________ PSAMP mailing list PSAMP@ietf.org =09 https://www1.ietf.org/mailman/listinfo/psamp =20 ------_=_NextPart_001_01C8348E.87C39909 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Benoit,
 
The TSV Area Director sent us the message = below on=20 11/21, which I forwarded to Juergen. Basically the TSV = review did not=20 find any major issues.
 
Dan
 
 
-------------
 

Juergen,

You can consider now the PSAMP documents Last Call period closed. =

Please let me know if any of these need a revision following the = comments=20 received during LC.

Thanks and Regards,

Dan

 

 

-----Original Message-----

From: Lars Eggert [mailto:lars.eggert@nokia.com]

Sent: Wednesday, November 21, 2007 10:52 AM

To: Romascanu, Dan (Dan)

Cc: Magnus Westerlund

Subject: tsv-dir review of the psamp = documents

Hi, Dan,

Mark Allman has reviewed the set of psamp documents = and says=20 that he only found nits. So from our side, these are ready to hit the = IESG.=20

Thanks for giving us the extra time for this = review!

Lars

 

------------------------=

 
 
 
 
 

From: Benoit Claise = [mailto:bclaise@cisco.com]=20
Sent: Friday, November 30, 2007 1:54 PM
To: = Romascanu,=20 Dan (Dan)
Cc: psamp@ietf.org
Subject: Re: [PSAMP] = FW: Last=20 Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP) Protocol=20 Specifications) to Proposed Standard

Dan,
Benoit,
 
The comments resolutions that you suggest = seem=20 appropriate to me.
 
It's fine to wait for the transport area = experts=20 comments before issuing a revised=20 I-D.
Any news on that = front?=20
Based on IPFIX and PSAMP status http://www1.ietf.org/mail-archive/web/ipfix/current/msg04203.html, = [PSAMP-PROTO] is one of the bottleneck.
The next one is = [PSAMP-INFO], for=20 which we've got 2 reviews already. A third one is = missing.

Regards,=20 Benoit.
 
Dan
 
 
 
 

From: Benoit Claise [mailto:bclaise@cisco.com]=20
Sent: Friday, November 09, 2007 3:17 PM
To:=20 Romascanu, Dan (Dan)
Cc: ietf@ietf.org; psamp@ietf.org; = IANA
Subject:=20 Re: [PSAMP] FW: Last Call: draft-ietf-psamp-protocol (Packet = Sampling=20 (PSAMP) Protocol Specifications) to Proposed=20 Standard

Dan,

Thanks for your review. I = will=20 address all your comments for in the next version. However, I = don't plan=20 to have a new version before the Transport Area directors have = reviewed=20 the doc (they asked for an extended deadline)
Please quickly = evaluate=20 if you agree with the proposed changes. See inline.
Here are my comments. They are quite =
a few, it may be because it's a
good document.=20

Technical:=20

1. Section 3.2.1 - Packet Content. The definition includes in the packet
header the link layer header. This deserves at least a note, which
should draw the attention on the fact that some if the Observation Point
is located at the interface of an IP router the link header information
may not be available.
OLD
   Packet Content=20
        =20
   The Packet Content denotes the union of the packet header (which=20
   includes link layer, network layer and other encapsulation headers)=20
   and the packet payload.=20

NEW

   Packet Content=20
        =20
   The Packet Content denotes the union of the packet header (which=20
   includes link layer, network layer and other encapsulation headers)=20
   and the packet payload. Note that, depending on =
the Observation Point,
   the link layer information might not be available.
    
Moreover, all examples later in the =
document use
only IP header IE, it would be useful to change or add one example to
show sub-IP header information.
Changing the section " 6.4.1 Basic Packet Report=20 "

OLD
   Here is an example of a basic Packet =
Report, with a=20
   SelectionSequenceId value of 9 and ipHeaderPacketSection Information=20
   Element of 12 bytes, 0x4500 005B A174 0000 FF11 832E, encoded with a=20
   fixed length field.=20
   =20
    IPFIX Template Record:=20
   =20
    0                   1                   2                   3=20
    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=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |           Set ID =3D 2          |         Length =3D 24           | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |        Template ID =3D 260      |        Field Count =3D 4        | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |   selectionSequenceId =3D 301   |        Field Length =3D 4       | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |      digestHashValue =3D 326    |        Field Length =3D 4       | =
=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |  ipHeaderPacketSection =3D 313  |        Field Length =3D 12      | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |observationTimeMicroseconds=3D324|        Field Length =3D 4       | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
NEW
   Here is an example of a basic Packet Report, =
with a=20
   SelectionSequenceId value of 9 and dataLinkFrameSection Information=20
   Element of 12 bytes, 0x4500 005B A174 0000 FF11 832E, encoded with a=20
   fixed length field.=20
   =20
    IPFIX Template Record:=20
   =20
    0                   1                   2                   3=20
    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=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |           Set ID =3D 2          |         Length =3D 24           | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |        Template ID =3D 260      |        Field Count =3D 4        | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |   selectionSequenceId =3D 301   |        Field Length =3D 4       | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |      digestHashValue =3D 326    |        Field Length =3D 4       | =
=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |  dataLinkFrameSection =3D 315   |      =
  Field Length =3D 12      |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |observationTimeMicroseconds=3D324|        Field Length =3D 4       | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
    
2. Section 8.2 - PSAMP IANA =
considerations mention the need of a group
of experts to advise on new PSAMP selection methods. This seems a little
overkill to me, as I do not expect this advise to be required too often
in the future. One designated expert to work with IANA would seem to me
sufficient, of curse in doing his work he may consult with a team, but
this needs not be mentioned here.=20
Note: this was done to be inline with IPFIX=20 information model draft:
   New assignments for IPFIX =
Information Elements will be administered
   by IANA through Expert Review [RFC2434], i.e. review by one of a
   group of experts designated by an IETF Area Director.
However, I = understand your point.

Changes to the section " 8.2 PSAMP = Related=20 Considerations "

OLD:
   New assignments for the =
PSAMP selection method will be administered=20
   by IANA, on a First Come First Served basis [RFC2434], subject to=20
   Expert Review [RFC2434], i.e. review by one of a group of experts=20
   designated by an IETF Operations and Management Area Director. =
NEW:
   New assignments for the PSAMP selection method =
will be administered=20
   by IANA, on a First Come First Served basis [RFC2434], subject to=20
   Expert Review [RFC2434].
Editorial

1. The document is using a capitalization convention where all terms
defined or mentioned in Section 3 are being written capitalized. This
includes quite common and often used terms like Sample or Flow. In order
to avoid comments about this capitalization style I suggest to explain
this convention in the terminology section.=20
OLD
 3.    Terminology=20
   =20
   As the IPFIX export protocol is used to export the PSAMP information, =

   the relevant IPFIX terminology from [IPFIX-PROTO] is copied over in=20
   this document.  The terminology summary table in section 3.1 gives a=20
   quick overview of the relationships between the different IPFIX=20
   terms.  The PSAMP terminology defined here is fully consistent with=20
   all terms listed in [PSAMP-TECH] and [PSAMP-FMWK] but only=20
   definitions that are relevant to the PSAMP protocol appear here.  =20
   Section 5.4 applies the PSAMP terminology to the IPFIX protocol=20
   terminology.
NEW

 3.    Terminology=20
   =20
   As the IPFIX export protocol is used to export the PSAMP information, =

   the relevant IPFIX terminology from [IPFIX-PROTO] is copied over in=20
   this document.  All terms defined in this =
section have their first=20
   letter capitalized when used in this document.  The =
terminology=20
   summary table in section 3.1 gives a quick overview of the=20
   relationships between the different IPFIX terms.  The PSAMP=20
   terminology defined here is fully consistent with all terms listed
   in [PSAMP-TECH] and [PSAMP-FMWK] but only definitions that are=20
   relevant to the PSAMP protocol appear here.  Section 5.4 applies=20
   the PSAMP terminology to the IPFIX protocol terminology. 
2. Many of the figures get fragmented =
at print. Now I know that it's
difficult to avoid this in a document with about 20 figures, and doing
.np before each figure would be quite a waste, but I suggest that at
least figure C which is a key architecture diagram be kept on one page.
Ok. I will take care of that.

Regards,=20 Benoit.
Dan



=20

-----Original Message-----
From: The IESG [mailto:iesg-secretary@ietf.org]=20
Sent: Monday, October 22, 2007 4:46 PM
To: IETF-Announce
Cc: psamp@ietf.org
Subject: Last Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP)
Protocol Specifications) to Proposed Standard=20

The IESG has received a request from the Packet Sampling WG (psamp) to
consider the following document:

- 'Packet Sampling (PSAMP) Protocol Specifications '
   <draft-ietf-psamp-protocol-08.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by =
2007-11-05. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, =
please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-08.txt=



IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?comma=
nd=3Dview_id&dTag=3D
10963&rfc_flag=3D0


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www=
1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
PSAMP mailing list
PSAMP@ietf.org
https://www1.ietf.o=
rg/mailman/listinfo/psamp
  =


= ------_=_NextPart_001_01C8348E.87C39909-- --===============0649111041== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp --===============0649111041==-- From psamp-bounces@ietf.org Tue Dec 04 14:21:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdKt-0000xu-2K; Tue, 04 Dec 2007 14:21:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdKr-0000xf-5n for psamp@ietf.org; Tue, 04 Dec 2007 14:21:37 -0500 Received: from ams-iport-2.cisco.com ([144.254.224.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzdKq-00073R-8C for psamp@ietf.org; Tue, 04 Dec 2007 14:21:37 -0500 X-IronPort-AV: E=Sophos;i="4.23,249,1194217200"; d="scan'208";a="471443" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-2.cisco.com with ESMTP; 04 Dec 2007 21:34:52 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB4JLZTJ032326; Tue, 4 Dec 2007 20:21:35 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB4JLY3Z012513; Tue, 4 Dec 2007 19:21:34 GMT Received: from [10.61.82.23] (ams3-vpn-dhcp4632.cisco.com [10.61.82.23]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA06700; Tue, 4 Dec 2007 19:21:32 GMT From: Andrew Johnson To: psamp , "Benoit Claise (bclaise)" , Paul Aitken , dietz@nw.neclab.eu, dressler@informatik.uni-erlangen.de, carle@informatik.uni-tuebingen.de Content-Type: text/plain Date: Tue, 04 Dec 2007 19:26:54 +0000 Message-Id: <1196796414.4378.61.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2-2.1mdv2007.1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6449; t=1196796095; x=1197660095; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20[Fwd=3A=20Preview=3A=20Review=20comments=20for=20=20draft-iet f-psamp-info-07] |Sender:=20; bh=+zGvfaVL1w2miJvARJyev/wyKEAblJbO1mMq4O0MdKA=; b=u/z/F9dUJW9ZTPKTiGxrjOEywhGta2CYC5Mua7fACOAyorE4IHBc9NNFBvF1fpvpnqN/pWh9 BLl29oDn3vZ5An7QAx31anOHt/DdGERdAU+z6rjxbzIEq050DkuGFVCm; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: Subject: [PSAMP] [Fwd: Preview: Review comments for draft-ietf-psamp-info-07] X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org Dear Authors I have read PSAMP-INFO and you can find my comments below. Overall the document is fine and my comments are mostly minor editorial ones. I do have a concern over the dateTime types that is probably best cleared up in IPFIX-INFO, but if it's too late for that, then something should be added to the description of the new dateTime IEs here. regards Andrew Section 1 ========= paragraph 3: "from a XML document" should be "from an XML document". paragraph 4: "served as source" should be "served as the source". Section 2 ========= "This Document: "Information Model for Packet Sampling Exports" (this document), defines an information and data model for PSAMP." There is no need to say "this document" twice. Remove the second mention of this. Section 3.1 =========== Only the used terminology definitions have been copied from the IPFIX INFO document, however "exporters" are mentioned in the Appendix, but not defined. Section 3.2 =========== "An Observed Packet Stream denotes the packets that flow past the Observation Point." Considering "Flow" is formally defined, consider rewording to avoid any confusion. Perhaps to: "An Observed Packet Stream denotes the packets that are seen at the Observation Point." The same comment applies to the definition of "Packet Stream". Section 8.2 =========== The table would have less ugly wrapping, and be 3 lines shorter, drawn as follows: +-----+-------------------------+-----+-----------------------------+ | ID | Name | ID | Name | +-----+-------------------------+-----+-----------------------------+ | 301 | selectionSequenceId | 318 | SelectorIdTotalPacketsObser | | | | | ved | | 302 | selectorId | 319 | SelectorIdTotalPacketsSelec | | | | | ted | | 303 | informationElementId | 320 | fixedError | | 304 | selectorAlgorithm | 321 | relativeError | | 305 | samplingPacketInterval | 322 | observationTimeSeconds | | | | | | | 306 | samplingPacketSpace | 323 | observationTimeMilliseconds | | 307 | samplingTimeInterval | 324 | observationTimeMicroseconds | | 308 | samplingTimeSpace | 325 | observationTimeNanoseconds | | 309 | samplingSize | 326 | digestHashValue | | 310 | samplingPopulation | 327 | hashIPPayloadOffset | | 311 | samplingProbability | 328 | hashIPPayloadSize | | 312 | dataLinkFrameSize | 329 | hashOutputRangeMin | | 313 | ipHeaderPacketSection | 330 | hashOutputRangeMax | | | | | | | 314 | ipPayloadPacketSection | 331 | hashSelectedRangeMin | | | | | | | 315 | dataLinkFrameSection | 332 | hashSelectedRangeMax | | 316 | mplsLabelStackSection | 333 | hashDigestOutput | | | | | | | 317 | mplsPayloadPacketSectio | 334 | hashInitialiserValue | | | n | | | +-----+-------------------------+-----+-----------------------------+ Why the blank lines? They don't seem to be used to group elements, can they be removed? Section 8.2.1 ============= "a subset of packets" should be "a subset of the packets", or just "a subset". Section 8.2.4 ============= "Some parameters for these algorithms are not covered by this information model since they very much depend on the underlying hardware." Are the parameters really dependant on hardware, or just the particular PSAMP implementation? Section 8.2.13 - 17 =================== "If insufficient octets are available for the length specified in the Template, the Information Element MUST NOT be padded." This isn't very clear. I believe the intention is that a new Template must be created with a shorter length for the field. The IE itself wouldn't be padded, the data would. Perhaps rewrite as: "The data for this field MUST NOT be padded. If insufficient octets are available for the length specified in the Template, then a new Template MUST be used." Section 8.2.22 - 25 =================== "Description: This Information Element specifies the absolute time in seconds of an observation. Abstract Data Type: dateTimeSeconds" I'm not sure what that description means exactly, and time data types in IPFIX don't seem to be well defined either: "The type "dateTimeSeconds" represents a time value in units of seconds normalized to the GMT time zone." So what does that mean? I still don't know exactly what I should put as the value for this field. >From IPFIX INFO, section 5.9: "Time stamps ... are absolute and have a well defined fixed time base, such as, for example, the number of seconds since 0000 UTC Jan 1st 1970." This is known as "epoch time". Unix time or POSIX time has an epoch of 0000 UTC Jan 1st 1970. NTP uses 0000 UTC Jan 1st 1900. The epoch for the IPFIX timestamps is not provided in the Information Elements or the data types. I think the intention is that the 0000 UTC Jan 1st 1970 wasn't supposed to be just an example, but was going to be the actual epoch defined in the data types. Alternatively, each Information Element definition has to define the epoch. If the exact encoding is provided elsewhere then a reference should be provided as it is for the float types. Section 8.2.33 ============== Again, this is more an issue with the definition of the data type in IPFIX INFO: "The type "boolean" represents a binary value. The only allowed values are "true" and "false"." It isn't clear what to actually send to represent true and false. I would guess all zero's for false, and probably anything else for true, but it should be specified. Again, if the exact encoding is provided elsewhere then a reference should be provided as it is for the float types. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Tue Dec 04 15:42:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izeae-0005C3-8K; Tue, 04 Dec 2007 15:42:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izead-0005By-L1 for psamp@ietf.org; Tue, 04 Dec 2007 15:41:59 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izeab-0000lY-CF for psamp@ietf.org; Tue, 04 Dec 2007 15:41:59 -0500 Received: from pc6 (1Cust162.tnt3.lnd4.gbr.da.uu.net [62.188.132.162]) by ranger.systems.pipex.net (Postfix) with SMTP id E8E42E00048C; Tue, 4 Dec 2007 20:41:53 +0000 (GMT) Message-ID: <067701c836ad$a469d320$0601a8c0@pc6> From: "Tom Petch" To: "Juergen Quittek" , References: Subject: Re: [PSAMP] WG Last call for draft-ietf-psamp-info-07 Date: Tue, 4 Dec 2007 20:41:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -104.0 (---------------------------------------------------) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org 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" To: 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" 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 Internet-Drafts@ietf.org 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 > >> i-d-announce-request@ietf.org 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: > >> mailserv@ietf.org. > >> 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 > PSAMP@ietf.org > https://www1.ietf.org/mailman/listinfo/psamp _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Wed Dec 05 08:23:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzuDl-0003FM-4T; Wed, 05 Dec 2007 08:23:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzaR2-0003Ri-E3 for psamp@ietf.org; Tue, 04 Dec 2007 11:15:48 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzaR1-00027q-83 for psamp@ietf.org; Tue, 04 Dec 2007 11:15:48 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id B58B928000303 for ; Tue, 4 Dec 2007 17:15:46 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+-XLKKUQtvC for ; Tue, 4 Dec 2007 17:15:46 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 95CFF28000302 for ; Tue, 4 Dec 2007 17:15:41 +0100 (CET) Received: from [10.1.2.8] ([10.1.2.8]) by mx1.office with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Dec 2007 17:15:41 +0100 Message-ID: <47557D93.9000301@CS.Uni-Goettingen.DE> Date: Tue, 04 Dec 2007 17:17:23 +0100 From: Sven Anderson Organization: University of Goettingen, Germany User-Agent: Thunderbird 2.0.0.6 (X11/20070801) MIME-Version: 1.0 To: psamp@ietf.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Dec 2007 16:15:41.0461 (UTC) FILETIME=[EA53CC50:01C83690] X-Spam-Score: 0.0 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 X-Mailman-Approved-At: Wed, 05 Dec 2007 08:23:23 -0500 Subject: [PSAMP] Review: draft-ietf-psamp-info-07 X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org Hi, here are my few comments on draft-ietf-psamp-info-07. (I hope not too late?) As I'm not reading the PSAMP mailing lists, I'm not aware of what might have been discussed already. So ignore accordingly. Cheers, Sven > Internet-Draft PSAMP Information Model October 2007 > > > 1. Introduction > > Packet sampling techniques are required for various measurement > scenarios. The packet sampling (PSAMP) protocol provides mechanisms "Packet Sampling" is uppercase in the abstract. In general there are both "sampling" and "Sampling" in the document. Same is true for "Filtering". > for packet selection using different filtering and sampling > techniques. A standard way for the export and storage is required. > The definition of the PSAMP information and data model is based on > the IP Flow Information eXport (IPFIX) protocol > [I-D.ietf-ipfix-protocol]. The PSAMP protocol document > [I-D.ietf-psamp-protocol] specifies how to use the IPFIX protocol in > the PSAMP context. > > This document examines the IPFIX information model > [I-D.ietf-ipfix-info] and extends it to meet the PSAMP requirements. > Therefore, the structure of this document is strongly based on the > IPFIX document. It complements the PSAMP protocol specification by > providing an appropriate PSAMP information model. The main part of > this document, section 8, defines the list of Information Elements to > be transmitted by the PSAMP protocol. Sections 6 and 5 describe the 6 and 5, not 5 and 6? > data types and Information Element properties used within this > document and their relationship to the IPFIX information model. > > The main body of section 8 was generated from a XML document. The > XML-based specification of the PSAMP Information Elements can be used > for automatically checking syntactical correctness of the > specification. Furthermore it can be used - in combination with the > IPFIX information model - for automated code generation. The > resulting code can be used in PSAMP protocol implementations to deal > with processing PSAMP information elements. > > For that reason, the XML document that served as source for section 8 > is attached to this document in Appendix A. > > Note that although partially generated from the attached XML > documents, the main body of this document is normative while the > appendices are informational. > > > > > > > > > > > > > > > > Dietz, et al. draft-ietf-psamp-info-07.txt [Page 5] [...] > Internet-Draft PSAMP Information Model October 2007 > > > 8. The PSAMP Information Elements > > This section describes the Information Elements used by the PSAMP > protocol. > > 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]. The assignments are > controlled by IANA as an extension of the IPFIX Information Model. Is this correct English? Isn't it more like "For each Information Element specified in section 8.2 below a unique identifier is allocated in accordance with section 5 of the IPFIX information model." > The Information Elements specified by the IPFIX information model > [I-D.ietf-ipfix-info] are used by the PSAMP protocol where > applicable. To avoid inconsistencies between the IPFIX and the PSAMP > information and data models, only those Information Elements that are > not already described by the IPFIX information model are defined > here. > > 8.1. PSAMP Usage of IPFIX Attributes > > This section lists additional Information Elements that are needed in > the PSAMP context and introduces their usage. > > List of additional PSAMP Information Elements: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dietz, et al. draft-ietf-psamp-info-07.txt [Page 17] [...] > Internet-Draft PSAMP Information Model October 2007 > > > 2 Systematic time-based Sampling > > 3 Random n-out-of-N Sampling > > 4 Uniform probabilistic Sampling > > 5 Property match Filtering > > 6 Hash based Filtering using BOB > > 7 Hash based Filtering using IPSX > > 8 Hash based Filtering using CRC So a simple pattern match (instead of a hash) is 5 as well? > > The parameters for most of these algorithms are defined in this > information model. Some parameters for these algorithms are not > covered by this information model since they very much depend on > the underlying hardware. > > 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. "as long as there's _no_ new RFC..." or "until there's a new RFC..." Right? > > Abstract Data Type: unsigned16 > > Data Type Semantics: identifier > > ElementId: 304 > > Status: current > > 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. > > For example, this Information Element may be used to describe the > configuration of a systematic count-based sampling Selector. I think this name will lead to misunderstandings. Although mathematically correct, the term "interval" is too general and is also used for a time space or other kind of spaces. So I'm sure many people will assume that this is the packet based sampling rate, without reading this document. I would suggest something like: samplingPacketQuantity samplingPacketExtent samplingPacketAmount samplingPacketRange > > Abstract Data Type: unsigned32 > > ElementId: 305 > > > > > > > Dietz, et al. draft-ietf-psamp-info-07.txt [Page 20] > > Internet-Draft PSAMP Information Model October 2007 > > > Status: current > > Units: packets > > 8.2.6. samplingPacketSpace > > Description: > > This Information Element specifies the number of packets between > two "samplingPacketInterval"s. A value of 100 means that the next > interval starts after 100 packets (which are not sampled) when the > current "samplingPacketInterval" is over. > > For example, this Information Element may be used to describe the > configuration of a systematic count-based sampling Selector. > > Abstract Data Type: unsigned32 > > ElementId: 306 > > Status: current > > Units: packets > > 8.2.7. samplingTimeInterval > > Description: > > This Information Element specifies the time interval in > microseconds during which all arriving packets are sampled. > > For example, this Information Element may be used to describe the > configuration of a systematic time-based sampling Selector. > Same as for samplingPacketInterval. I think samplingTimeRange or samplingTimeExtent is better. > Abstract Data Type: dateTimeMicroseconds > > ElementId: 307 > > Status: current > > Units: microseconds > > 8.2.8. samplingTimeSpace > > > > > > > > > Dietz, et al. draft-ietf-psamp-info-07.txt [Page 21] [...] > Internet-Draft PSAMP Information Model October 2007 > > > 10. IANA Considerations > > 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 [I-D.ietf-ipfix-info]. New assignments > for PSAMP Information Elements will be administered according to > rules explained in the "IANA Consideration" section of the IPFIX > Information Model document [I-D.ietf-ipfix-info]. > > Note that the PSAMP Information Element IDs were initially started at > the value 301, in order to leave a gap for any ongoing IPFIX work > requiring new Information Elements. It is expected that this gap in > the Information Element numbering will be filled in by IANA with new > IPFIX Information Elements. Shouldn't it be explicitly stated, that PSAMP shares the same IE number space with IPFIX? In theory it is also possible to heritage all the definitions, but have separate number spaces. > > Appendix B defines an XML schema which may be used to create > consistent machine readable extensions to the IPFIX information > model. This schema introduces a new namespace, which will be > assigned by IANA according to [RFC3688]. > > The selectorAlgorithm registry is maintained by IANA and can be > updated as long as specifications of the new method(s) and any new > Information Elements are provided. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dietz, et al. draft-ietf-psamp-info-07.txt [Page 34] _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Wed Dec 05 09:15:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izv1p-0007Ln-3K; Wed, 05 Dec 2007 09:15:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izv1n-0007LS-BW for psamp@ietf.org; Wed, 05 Dec 2007 09:15:07 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izv1l-0006ri-JS for psamp@ietf.org; Wed, 05 Dec 2007 09:15:07 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1159C28000303 for ; Wed, 5 Dec 2007 15:15:05 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+d6tigSn0Bp for ; Wed, 5 Dec 2007 15:15:05 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0148628000302 for ; Wed, 5 Dec 2007 15:14:59 +0100 (CET) Received: from 10.1.1.104 ([10.1.1.104]) by mx1.office ([10.1.1.23]) with Microsoft Exchange Server HTTP-DAV ; Wed, 5 Dec 2007 14:14:59 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 05 Dec 2007 15:15:08 +0100 From: Juergen Quittek To: IETF PSAMP Working Group Message-ID: Thread-Topic: WG last call on PSAMP-INFO closed Thread-Index: Acg3ST1Ce8PKQqM8EdynfAAWy4a5Gw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [PSAMP] WG last call on PSAMP-INFO closed X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org Dear reviewers of draft-ietf-psamp-info-07, Thank you very much for reading the draft and sending us your comments. Now, after receiving three more reviews I close WG last call on draft-ietf-psamp-info-07 and ask the editors to revise the document based on the comments received. Thanks, Juergen _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Wed Dec 05 10:05:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzvoW-0001lJ-9x; Wed, 05 Dec 2007 10:05:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzvoV-0001ky-0y for psamp@ietf.org; Wed, 05 Dec 2007 10:05:27 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzvoT-0005PH-Nn for psamp@ietf.org; Wed, 05 Dec 2007 10:05:26 -0500 Received: from pc6 (1Cust178.tnt30.lnd3.gbr.da.uu.net [62.188.122.178]) by astro.systems.pipex.net (Postfix) with SMTP id D6460E0002FE; Wed, 5 Dec 2007 15:05:20 +0000 (GMT) Message-ID: <00f901c83747$ca83cc60$0601a8c0@pc6> From: "Tom Petch" To: "Juergen Quittek" , References: Subject: Re: [PSAMP] WG Last call for draft-ietf-psamp-info-07 Date: Wed, 5 Dec 2007 14:57:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 Cc: X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org 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 ----- Original Message ----- From: "Juergen Quittek" To: 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" 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 Internet-Drafts@ietf.org 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 > >> i-d-announce-request@ietf.org 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: > >> mailserv@ietf.org. > >> 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 > PSAMP@ietf.org > https://www1.ietf.org/mailman/listinfo/psamp _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Mon Dec 10 18:12:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1rnE-0005zq-Hx; Mon, 10 Dec 2007 18:12:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1rnD-0005zl-CC for psamp@ietf.org; Mon, 10 Dec 2007 18:12:07 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1rnA-0002fP-VG for psamp@ietf.org; Mon, 10 Dec 2007 18:12:07 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id lBANC1x29497; Tue, 11 Dec 2007 00:12:01 +0100 (CET) Received: from [10.61.81.158] (ams3-vpn-dhcp4511.cisco.com [10.61.81.158]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id lBANC0B29480; Tue, 11 Dec 2007 00:12:00 +0100 (CET) Message-ID: <475DC7C0.9050403@cisco.com> Date: Tue, 11 Dec 2007 00:12:00 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Subject: Re: [PSAMP] FW: Last Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP) Protocol Specifications) to Proposed Standard References: <47345DDA.3070805@cisco.com> <474FF9BA.9020109@cisco.com> In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 662324ecda47446db09bfd0a0092c4ba Cc: psamp@ietf.org X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2131010648==" Errors-To: psamp-bounces@ietf.org This is a multi-part message in MIME format. --===============2131010648== Content-Type: multipart/alternative; boundary="------------040303020302030100070109" This is a multi-part message in MIME format. --------------040303020302030100070109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dan, A new version of the draft has been posted right now. Note: a new version was easier as I also had to apply a few changes for IANA. According to our discussion last week, this draft should make for next telechat agenda. Regards, Benoit. > */Benoit,/* > *//* > */The TSV Area Director sent us the message below on 11/21, which I > forwarded to Juergen. Basically the TSV review did not find any major > issues. /* > *//* > */Dan/* > *//* > *//* > */-------------/* > *//* > > Juergen, > > You can consider now the PSAMP documents Last Call period closed. > > Please let me know if any of these need a revision following the > comments received during LC. > > Thanks and Regards, > > Dan > > > > > > -----Original Message----- > > From: Lars Eggert [_mailto:lars.eggert@nokia.com_] > > Sent: Wednesday, November 21, 2007 10:52 AM > > To: Romascanu, Dan (Dan) > > Cc: Magnus Westerlund > > Subject: tsv-dir review of the psamp documents > > Hi, Dan, > > Mark Allman has reviewed the set of psamp documents and says that he > only found nits. So from our side, these are ready to hit the IESG. > > Thanks for giving us the extra time for this review! > > Lars > > > > */------------------------/* > > *//* > *//* > > > > > ------------------------------------------------------------------------ > *From:* Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Friday, November 30, 2007 1:54 PM > *To:* Romascanu, Dan (Dan) > *Cc:* psamp@ietf.org > *Subject:* Re: [PSAMP] FW: Last Call: draft-ietf-psamp-protocol > (Packet Sampling (PSAMP) Protocol Specifications) to Proposed Standard > > Dan, >> */Benoit,/* >> *//* >> */The comments resolutions that you suggest seem appropriate to >> me. /* >> *//* >> */It's fine to wait for the transport area experts comments >> before issuing a revised I-D./* > Any news on that front? > Based on IPFIX and PSAMP status > http://www1.ietf.org/mail-archive/web/ipfix/current/msg04203.html, > [PSAMP-PROTO] is one of the bottleneck. > The next one is [PSAMP-INFO], for which we've got 2 reviews > already. A third one is missing. > > Regards, Benoit. >> *//* >> *//* >> */Dan/* >> *//* >> >> >> >> >> ------------------------------------------------------------------------ >> *From:* Benoit Claise [mailto:bclaise@cisco.com] >> *Sent:* Friday, November 09, 2007 3:17 PM >> *To:* Romascanu, Dan (Dan) >> *Cc:* ietf@ietf.org; psamp@ietf.org; IANA >> *Subject:* Re: [PSAMP] FW: Last Call: >> draft-ietf-psamp-protocol (Packet Sampling (PSAMP) Protocol >> Specifications) to Proposed Standard >> >> Dan, >> >> Thanks for your review. I will address all your comments for >> in the next version. However, I don't plan to have a new >> version before the Transport Area directors have reviewed the >> doc (they asked for an extended deadline) >> Please quickly evaluate if you agree with the proposed >> changes. See inline. >>> Here are my comments. They are quite a few, it may be because it's a >>> good document. >>> >>> Technical: >>> >>> 1. Section 3.2.1 - Packet Content. The definition includes in the packet >>> header the link layer header. This deserves at least a note, which >>> should draw the attention on the fact that some if the Observation Point >>> is located at the interface of an IP router the link header information >>> may not be available. >> OLD >> >> Packet Content >> >> The Packet Content denotes the union of the packet header (which >> includes link layer, network layer and other encapsulation headers) >> and the packet payload. >> >> NEW >> >> Packet Content >> >> The Packet Content denotes the union of the packet header (which >> includes link layer, network layer and other encapsulation headers) >> and the packet payload. Note that, depending on the Observation Point, >> the link layer information might not be available. >> >> >>> Moreover, all examples later in the document use >>> only IP header IE, it would be useful to change or add one example to >>> show sub-IP header information. >>> >> Changing the section " 6.4.1 Basic Packet Report " >> >> OLD >> >> Here is an example of a basic Packet Report, with a >> SelectionSequenceId value of 9 and ipHeaderPacketSection Information >> Element of 12 bytes, 0x4500 005B A174 0000 FF11 832E, encoded with a >> fixed length field. >> >> IPFIX Template Record: >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 24 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 260 | Field Count = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | selectionSequenceId = 301 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | digestHashValue = 326 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ipHeaderPacketSection = 313 | Field Length = 12 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |observationTimeMicroseconds=324| Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> NEW >> >> Here is an example of a basic Packet Report, with a >> SelectionSequenceId value of 9 and dataLinkFrameSection Information >> Element of 12 bytes, 0x4500 005B A174 0000 FF11 832E, encoded with a >> fixed length field. >> >> IPFIX Template Record: >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 24 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 260 | Field Count = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | selectionSequenceId = 301 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | digestHashValue = 326 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | dataLinkFrameSection = 315 | Field Length = 12 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |observationTimeMicroseconds=324| Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >>> 2. Section 8.2 - PSAMP IANA considerations mention the need of a group >>> of experts to advise on new PSAMP selection methods. This seems a little >>> overkill to me, as I do not expect this advise to be required too often >>> in the future. One designated expert to work with IANA would seem to me >>> sufficient, of curse in doing his work he may consult with a team, but >>> this needs not be mentioned here. >>> >> Note: this was done to be inline with IPFIX information model >> draft: >> >> New assignments for IPFIX Information Elements will be administered >> by IANA through Expert Review [RFC2434], i.e. review by one of a >> group of experts designated by an IETF Area Director. >> >> However, I understand your point. >> >> Changes to the section " 8.2 PSAMP Related Considerations " >> >> OLD: >> >> New assignments for the PSAMP selection method will be administered >> by IANA, on a First Come First Served basis [RFC2434], subject to >> Expert Review [RFC2434], i.e. review by one of a group of experts >> designated by an IETF Operations and Management Area Director. >> >> NEW: >> >> New assignments for the PSAMP selection method will be administered >> by IANA, on a First Come First Served basis [RFC2434], subject to >> Expert Review [RFC2434]. >> >>> Editorial >>> >>> 1. The document is using a capitalization convention where all terms >>> defined or mentioned in Section 3 are being written capitalized. This >>> includes quite common and often used terms like Sample or Flow. In order >>> to avoid comments about this capitalization style I suggest to explain >>> this convention in the terminology section. >>> >> OLD >> >> 3. Terminology >> >> As the IPFIX export protocol is used to export the PSAMP information, >> the relevant IPFIX terminology from [IPFIX-PROTO] is copied over in >> this document. The terminology summary table in section 3.1 gives a >> quick overview of the relationships between the different IPFIX >> terms. The PSAMP terminology defined here is fully consistent with >> all terms listed in [PSAMP-TECH] and [PSAMP-FMWK] but only >> definitions that are relevant to the PSAMP protocol appear here. >> Section 5.4 applies the PSAMP terminology to the IPFIX protocol >> terminology. >> >> NEW >> >> 3. Terminology >> >> As the IPFIX export protocol is used to export the PSAMP information, >> the relevant IPFIX terminology from [IPFIX-PROTO] is copied over in >> this document. All terms defined in this section have their first >> letter capitalized when used in this document. The terminology >> summary table in section 3.1 gives a quick overview of the >> relationships between the different IPFIX terms. The PSAMP >> terminology defined here is fully consistent with all terms listed >> in [PSAMP-TECH] and [PSAMP-FMWK] but only definitions that are >> relevant to the PSAMP protocol appear here. Section 5.4 applies >> the PSAMP terminology to the IPFIX protocol terminology. >> >>> 2. Many of the figures get fragmented at print. Now I know that it's >>> difficult to avoid this in a document with about 20 figures, and doing >>> .np before each figure would be quite a waste, but I suggest that at >>> least figure C which is a key architecture diagram be kept on one page. >>> >> Ok. I will take care of that. >> >> Regards, Benoit. >>> Dan >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: The IESG [mailto:iesg-secretary@ietf.org] >>> Sent: Monday, October 22, 2007 4:46 PM >>> To: IETF-Announce >>> Cc: psamp@ietf.org >>> Subject: Last Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP) >>> Protocol Specifications) to Proposed Standard >>> >>> The IESG has received a request from the Packet Sampling WG (psamp) to >>> consider the following document: >>> >>> - 'Packet Sampling (PSAMP) Protocol Specifications ' >>> as a Proposed Standard >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2007-11-05. Exceptionally, comments may >>> be sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> The file can be obtained via >>> http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-08.txt >>> >>> >>> IESG discussion can be tracked via >>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag= >>> 10963&rfc_flag=0 >>> >>> >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ietf-announce >>> >>> _______________________________________________ >>> PSAMP mailing list >>> PSAMP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/psamp >>> >> > --------------040303020302030100070109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dan,

A new version of the draft has been posted right now.
Note: a new version was easier as I also had to apply a few changes for IANA.
According to our discussion last week, this draft should make for next telechat agenda.

Regards, Benoit.
Benoit,
 
The TSV Area Director sent us the message below on 11/21, which I forwarded to Juergen. Basically the TSV review did not find any major issues.
 
Dan
 
 
-------------
 

Juergen,

You can consider now the PSAMP documents Last Call period closed.

Please let me know if any of these need a revision following the comments received during LC.

Thanks and Regards,

Dan

 

 

-----Original Message-----

From: Lars Eggert [mailto:lars.eggert@nokia.com]

Sent: Wednesday, November 21, 2007 10:52 AM

To: Romascanu, Dan (Dan)

Cc: Magnus Westerlund

Subject: tsv-dir review of the psamp documents

Hi, Dan,

Mark Allman has reviewed the set of psamp documents and says that he only found nits. So from our side, these are ready to hit the IESG.

Thanks for giving us the extra time for this review!

Lars

 

------------------------

 
 
 
 
 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Friday, November 30, 2007 1:54 PM
To: Romascanu, Dan (Dan)
Cc: psamp@ietf.org
Subject: Re: [PSAMP] FW: Last Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP) Protocol Specifications) to Proposed Standard

Dan,
Benoit,
 
The comments resolutions that you suggest seem appropriate to me.
 
It's fine to wait for the transport area experts comments before issuing a revised I-D.
Any news on that front?
Based on IPFIX and PSAMP status http://www1.ietf.org/mail-archive/web/ipfix/current/msg04203.html, [PSAMP-PROTO] is one of the bottleneck.
The next one is [PSAMP-INFO], for which we've got 2 reviews already. A third one is missing.

Regards, Benoit.
 
Dan
 
 
 
 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Friday, November 09, 2007 3:17 PM
To: Romascanu, Dan (Dan)
Cc: ietf@ietf.org; psamp@ietf.org; IANA
Subject: Re: [PSAMP] FW: Last Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP) Protocol Specifications) to Proposed Standard

Dan,

Thanks for your review. I will address all your comments for in the next version. However, I don't plan to have a new version before the Transport Area directors have reviewed the doc (they asked for an extended deadline)
Please quickly evaluate if you agree with the proposed changes. See inline.
Here are my comments. They are quite a few, it may be because it's a
good document. 

Technical: 

1. Section 3.2.1 - Packet Content. The definition includes in the packet
header the link layer header. This deserves at least a note, which
should draw the attention on the fact that some if the Observation Point
is located at the interface of an IP router the link header information
may not be available.
OLD
   Packet Content 
         
   The Packet Content denotes the union of the packet header (which 
   includes link layer, network layer and other encapsulation headers) 
   and the packet payload. 

NEW

   Packet Content 
         
   The Packet Content denotes the union of the packet header (which 
   includes link layer, network layer and other encapsulation headers) 
   and the packet payload. Note that, depending on the Observation Point,
   the link layer information might not be available.
    
Moreover, all examples later in the document use
only IP header IE, it would be useful to change or add one example to
show sub-IP header information.
Changing the section " 6.4.1 Basic Packet Report "

OLD
   Here is an example of a basic Packet Report, with a 
   SelectionSequenceId value of 9 and ipHeaderPacketSection Information 
   Element of 12 bytes, 0x4500 005B A174 0000 FF11 832E, encoded with a 
   fixed length field. 
    
    IPFIX Template Record: 
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |           Set ID = 2          |         Length = 24           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |        Template ID = 260      |        Field Count = 4        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   selectionSequenceId = 301   |        Field Length = 4       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |      digestHashValue = 326    |        Field Length = 4       |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |  ipHeaderPacketSection = 313  |        Field Length = 12      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |observationTimeMicroseconds=324|        Field Length = 4       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW
   Here is an example of a basic Packet Report, with a 
   SelectionSequenceId value of 9 and dataLinkFrameSection Information 
   Element of 12 bytes, 0x4500 005B A174 0000 FF11 832E, encoded with a 
   fixed length field. 
    
    IPFIX Template Record: 
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |           Set ID = 2          |         Length = 24           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |        Template ID = 260      |        Field Count = 4        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   selectionSequenceId = 301   |        Field Length = 4       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |      digestHashValue = 326    |        Field Length = 4       |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |  dataLinkFrameSection = 315   |        Field Length = 12      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |observationTimeMicroseconds=324|        Field Length = 4       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
2. Section 8.2 - PSAMP IANA considerations mention the need of a group
of experts to advise on new PSAMP selection methods. This seems a little
overkill to me, as I do not expect this advise to be required too often
in the future. One designated expert to work with IANA would seem to me
sufficient, of curse in doing his work he may consult with a team, but
this needs not be mentioned here.
Note: this was done to be inline with IPFIX information model draft:
   New assignments for IPFIX Information Elements will be administered
   by IANA through Expert Review [RFC2434], i.e. review by one of a
   group of experts designated by an IETF Area Director.
However, I understand your point.

Changes to the section " 8.2 PSAMP Related Considerations "

OLD:
   New assignments for the PSAMP selection method will be administered 
   by IANA, on a First Come First Served basis [RFC2434], subject to 
   Expert Review [RFC2434], i.e. review by one of a group of experts 
   designated by an IETF Operations and Management Area Director.
NEW:
   New assignments for the PSAMP selection method will be administered 
   by IANA, on a First Come First Served basis [RFC2434], subject to 
   Expert Review [RFC2434].
Editorial

1. The document is using a capitalization convention where all terms
defined or mentioned in Section 3 are being written capitalized. This
includes quite common and often used terms like Sample or Flow. In order
to avoid comments about this capitalization style I suggest to explain
this convention in the terminology section.
OLD
 3.    Terminology 
    
   As the IPFIX export protocol is used to export the PSAMP information, 
   the relevant IPFIX terminology from [IPFIX-PROTO] is copied over in 
   this document.  The terminology summary table in section 3.1 gives a 
   quick overview of the relationships between the different IPFIX 
   terms.  The PSAMP terminology defined here is fully consistent with 
   all terms listed in [PSAMP-TECH] and [PSAMP-FMWK] but only 
   definitions that are relevant to the PSAMP protocol appear here.   
   Section 5.4 applies the PSAMP terminology to the IPFIX protocol 
   terminology.
NEW

 3.    Terminology 
    
   As the IPFIX export protocol is used to export the PSAMP information, 
   the relevant IPFIX terminology from [IPFIX-PROTO] is copied over in 
   this document.  All terms defined in this section have their first 
   letter capitalized when used in this document.  The terminology 
   summary table in section 3.1 gives a quick overview of the 
   relationships between the different IPFIX terms.  The PSAMP 
   terminology defined here is fully consistent with all terms listed
   in [PSAMP-TECH] and [PSAMP-FMWK] but only definitions that are 
   relevant to the PSAMP protocol appear here.  Section 5.4 applies 
   the PSAMP terminology to the IPFIX protocol terminology. 
2. Many of the figures get fragmented at print. Now I know that it's
difficult to avoid this in a document with about 20 figures, and doing
.np before each figure would be quite a waste, but I suggest that at
least figure C which is a key architecture diagram be kept on one page.
Ok. I will take care of that.

Regards, Benoit.
Dan



 

-----Original Message-----
From: The IESG [mailto:iesg-secretary@ietf.org] 
Sent: Monday, October 22, 2007 4:46 PM
To: IETF-Announce
Cc: psamp@ietf.org
Subject: Last Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP)
Protocol Specifications) to Proposed Standard 

The IESG has received a request from the Packet Sampling WG (psamp) to
consider the following document:

- 'Packet Sampling (PSAMP) Protocol Specifications '
   <draft-ietf-psamp-protocol-08.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2007-11-05. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-08.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
10963&rfc_flag=0


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
PSAMP mailing list
PSAMP@ietf.org
https://www1.ietf.org/mailman/listinfo/psamp



--------------040303020302030100070109-- --===============2131010648== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp --===============2131010648==-- From psamp-bounces@ietf.org Tue Dec 18 16:15:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4jmv-0001XO-0P; Tue, 18 Dec 2007 16:15:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4jmn-0001Lu-KS; Tue, 18 Dec 2007 16:15:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4jmm-0005t4-Tz; Tue, 18 Dec 2007 16:15:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 7D85B175C6; Tue, 18 Dec 2007 21:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J4jmH-0000rd-Vn; Tue, 18 Dec 2007 16:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 18 Dec 2007 16:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: psamp@ietf.org Subject: [PSAMP] I-D ACTION:draft-ietf-psamp-protocol-09.txt X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org --NextPart 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 : Packet Sampling (PSAMP) Protocol Specifications Author(s) : B. Claise Filename : draft-ietf-psamp-protocol-09.txt Pages : 43 Date : 2007-12-18 This document specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Collecting Process. For export of packet information the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well and the means provided by the IPFIX protocol are sufficient. The document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org 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-protocol-09.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-psamp-protocol-09.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-18150847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-psamp-protocol-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-psamp-protocol-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-18150847.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp --NextPart-- From psamp-bounces@ietf.org Wed Dec 19 08:57:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zQU-0006b4-Qf; Wed, 19 Dec 2007 08:57:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zQT-0006WG-5p for psamp@ietf.org; Wed, 19 Dec 2007 08:57:33 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4zQQ-00063t-3d for psamp@ietf.org; Wed, 19 Dec 2007 08:57:33 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6161928000351; Wed, 19 Dec 2007 14:57:29 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4g4Mlyf2gDZ; Wed, 19 Dec 2007 14:57:29 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3BBB92800034F; Wed, 19 Dec 2007 14:57:19 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [PSAMP] WG Last call for draft-ietf-psamp-info-07 Date: Wed, 19 Dec 2007 14:57:18 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF3925F3@mx1.office> In-Reply-To: <067701c836ad$a469d320$0601a8c0@pc6> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [PSAMP] WG Last call for draft-ietf-psamp-info-07 Thread-Index: Acg2tij2IBWaAtb6Qp6OyZpENObhOwLjIrBA References: <067701c836ad$a469d320$0601a8c0@pc6> From: "Thomas Dietz" To: "Tom Petch" , "Juergen Quittek" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 Cc: X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0639838178==" Errors-To: psamp-bounces@ietf.org This is a multipart message in MIME format. --===============0639838178== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0048_01C8424F.73541900" This is a multipart message in MIME format. ------=_NextPart_000_0048_01C8424F.73541900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Tom, find my comments inline. -- Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu 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:nwnetworks@dial.pipex.com] > Sent: Dienstag, 4. Dezember 2007 20:41 > To: Juergen Quittek; psamp@ietf.org > Subject: Re: [PSAMP] WG Last call for draft-ietf-psamp-info-07 > > 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... " > I agree that the wording could be clearer here. > 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. > 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. > 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? > I think the new protocol draft (09) is very clear on that. The information model draft will be updated accordingly. > 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? > 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. > If IANA were to fail to carry out these instructions as the authors > would wish, > 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). > 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)? > 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. > 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 > To solve this we could include an XML comment similar to the one used in MIB modules giving the copyright etc. > 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. > 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. > 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. > Agreed, see above. > 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. > Agreed, those will be address regarding your second e-mail and all the others pointing out these issues. Best Regards, Thomas > Tom Petch > > > ----- Original Message ----- > From: "Juergen Quittek" > To: > 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" > 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 Internet-Drafts@ietf.org 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 > > >> i-d-announce-request@ietf.org 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: > > >> mailserv@ietf.org. > > >> 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 > > PSAMP@ietf.org > > https://www1.ietf.org/mailman/listinfo/psamp > > > _______________________________________________ > PSAMP mailing list > PSAMP@ietf.org > https://www1.ietf.org/mailman/listinfo/psamp ------=_NextPart_000_0048_01C8424F.73541900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggM5MIICoqADAgECAhBD3kUGfpHtO7Zw5BdS Zkm1MA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTkwMDAw MDBaFw0wOTEwMTIyMzU5NTlaMEMxETAPBgNVBAoTCFZlcmlTaWduMS4wLAYDVQQLEyVWZXJpU2ln biBDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIENBMIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKB gQDcKpmdbjP8u0F2xDkejfd255APdFVhYXI8+DdLGx8I6TAdcMUWiWAzRkh/xtCaPXaYw6HBrFLR F7kUBGmGXGFPs2Vli2Oi7iF8Qa+tckDDTZGzSb6Y+1fHWi6wS6fvCSTzgZ04xZLaSqeYUanYMHYt atavL37bESqF+2VgWkXoGwIBA6OBsDCBrTAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHFwIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0 BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcyLmNybDALBgNV HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4GBAImQvq5zldxCHk2g j+8C+6loWwvtLEWziOuOTs80iqY1DoOM0LQTL+uqlfw2fmiFnPw3WVPKuQwGhOE7ZAcLITREdYg3 NsW1WA2oODuvoGG4fGwXn+H/4dpDqEKGAl1K7ZyQjRKqTMJuA5gfQ69+m0m1tHSjbq1qW+svscua HqaaMIIDZjCCAs+gAwIBAgIQRuECOhCAVuaaKKVALy7ycDANBgkqhkiG9w0BAQQFADBDMREwDwYD VQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNpZ24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVh bCBDQTAeFw0wNzEwMjQwMDAwMDBaFw0wODEwMjMyMzU5NTlaMIHdMRswGQYDVQQKDBJORUMgRXVy b3BlIExpbWl0ZWQxRjBEBgNVBAsMPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMgSW5j b3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTkxNTAzBgNVBAsMLENvbXBhbnkgLSBORUMgTGFib3Jh dG9yaWVzIEV1cm9wZSBIZWlkZWxiZXJnMRUwEwYDVQQDDAxUaG9tYXMgRGlldHoxKDAmBgkqhkiG 9w0BCQEWGXRob21hcy5kaWV0ekBudy5uZWNsYWIuZXUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALC4yWRsqDAwBYKjb3zoUfE18Tj5pOb+b2u/jmoeW6I3KKtzQxSIcW6qGrkrks0px63VYr72 6VF72Qhv4K31ntSOOLVOgz/yUXu2TBqsGxzcpjHD9LIJPK2LbEoo8m4t5mcVQReNhvrsCFukpYZn tb6xoCmmFfxcXeZh48Rhn4wVAgMBAAGjgb8wgbwwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMBEGCWCGSAGG+EIBAQQEAwIHgDBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vb25z aXRlY3JsLnZlcmlzaWduLmNvbS9PblNpdGVQdWJsaWMvTGF0ZXN0Q1JMLmNybDANBgkqhkiG9w0B AQQFAAOBgQAeld8hZLp3F1TtzJkmSe1io5guKbUqux6y0l//Ya5ESWBOpApe3vweWAsZYbn3dw0U F73oKpjuW6qdSNJizqtngj9is0DLLqH3u2PG3zksB7oy4hYPKejEuq4HXz3/bIxZSwvl7S9XL0Ce tSXJji+Rh4wFkL3GLZkWrlXPO+Y5tTGCApkwggKVAgEBMFcwQzERMA8GA1UEChMIVmVyaVNpZ24x LjAsBgNVBAsTJVZlcmlTaWduIENsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbm miilQC8u8nAwCQYFKw4DAhoFAKCCAZgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDcxMjE5MTM1NzE4WjAjBgkqhkiG9w0BCQQxFgQUUw6N1LCVI1T04jbyOC7QJozN ppwwZgYJKwYBBAGCNxAEMVkwVzBDMREwDwYDVQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNp Z24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBDQQIQRuECOhCAVuaaKKVALy7ycDBnBgkqhkiG 9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBoBgsqhkiG9w0BCRACCzFZ oFcwQzERMA8GA1UEChMIVmVyaVNpZ24xLjAsBgNVBAsTJVZlcmlTaWduIENsYXNzIDIgT25TaXRl IEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbmmiilQC8u8nAwDQYJKoZIhvcNAQEBBQAEgYAquEnF92D4 /Kx2lE4GTTV83Ji6zTgxE5EdudZd7Qaoiolfe9rBt08wVexQYlTgQZugbaiKJIj+q8vCblLRb8dX akLQ1TKZ/vat31R6reUgqoXIEVEgGFreviki7CNnE5u/8sAAe6XbNhlgyTRpmYSJTwSEm1oNfpzJ EnVvR8D+igAAAAAAAA== ------=_NextPart_000_0048_01C8424F.73541900-- --===============0639838178== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp --===============0639838178==-- From psamp-bounces@ietf.org Wed Dec 19 10:08:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50XB-0004p0-F0; Wed, 19 Dec 2007 10:08:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50XA-0004ou-I1 for psamp@ietf.org; Wed, 19 Dec 2007 10:08:32 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J50X7-0007nj-SE for psamp@ietf.org; Wed, 19 Dec 2007 10:08:32 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6F04428000351; Wed, 19 Dec 2007 16:08:29 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FvXv+UzP2no; Wed, 19 Dec 2007 16:08:29 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 48F432800034F; Wed, 19 Dec 2007 16:08:19 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [PSAMP] WG Last call for draft-ietf-psamp-info-07 Date: Wed, 19 Dec 2007 16:08:18 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF392604@mx1.office> In-Reply-To: <00f901c83747$ca83cc60$0601a8c0@pc6> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [PSAMP] WG Last call for draft-ietf-psamp-info-07 Thread-Index: Acg3UE9ddJTNpRwzTPyCpjjR9oQ8OQK/6bCA References: <00f901c83747$ca83cc60$0601a8c0@pc6> From: "Thomas Dietz" To: "Tom Petch" , "Juergen Quittek" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 43ca87c8fcef5d9f6e966e1c3917103e Cc: X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1789883399==" Errors-To: psamp-bounces@ietf.org This is a multipart message in MIME format. --===============1789883399== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_004D_01C84259.5E853590" This is a multipart message in MIME format. ------=_NextPart_000_004D_01C84259.5E853590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Tom, I applied your editorial changes and just want to comment a few other issues inline... -- Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu 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:nwnetworks@dial.pipex.com] > Sent: Mittwoch, 5. Dezember 2007 14:58 > To: Juergen Quittek; psamp@ietf.org > Subject: Re: [PSAMP] WG Last call for draft-ietf-psamp-info-07 > > 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. > 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??? > > 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? 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. > > 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 > I hope the new section fits better... > 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. > 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 > Solid review? up to you to judge that one. > > Tom Petch > > ----- Original Message ----- > From: "Juergen Quittek" > To: > 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" > 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 Internet-Drafts@ietf.org 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 > > >> i-d-announce-request@ietf.org 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: > > >> mailserv@ietf.org. > > >> 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 > > PSAMP@ietf.org > > https://www1.ietf.org/mailman/listinfo/psamp > > > _______________________________________________ > PSAMP mailing list > PSAMP@ietf.org > https://www1.ietf.org/mailman/listinfo/psamp ------=_NextPart_000_004D_01C84259.5E853590 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggM5MIICoqADAgECAhBD3kUGfpHtO7Zw5BdS Zkm1MA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTkwMDAw MDBaFw0wOTEwMTIyMzU5NTlaMEMxETAPBgNVBAoTCFZlcmlTaWduMS4wLAYDVQQLEyVWZXJpU2ln biBDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIENBMIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKB gQDcKpmdbjP8u0F2xDkejfd255APdFVhYXI8+DdLGx8I6TAdcMUWiWAzRkh/xtCaPXaYw6HBrFLR F7kUBGmGXGFPs2Vli2Oi7iF8Qa+tckDDTZGzSb6Y+1fHWi6wS6fvCSTzgZ04xZLaSqeYUanYMHYt atavL37bESqF+2VgWkXoGwIBA6OBsDCBrTAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHFwIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0 BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcyLmNybDALBgNV HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4GBAImQvq5zldxCHk2g j+8C+6loWwvtLEWziOuOTs80iqY1DoOM0LQTL+uqlfw2fmiFnPw3WVPKuQwGhOE7ZAcLITREdYg3 NsW1WA2oODuvoGG4fGwXn+H/4dpDqEKGAl1K7ZyQjRKqTMJuA5gfQ69+m0m1tHSjbq1qW+svscua HqaaMIIDZjCCAs+gAwIBAgIQRuECOhCAVuaaKKVALy7ycDANBgkqhkiG9w0BAQQFADBDMREwDwYD VQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNpZ24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVh bCBDQTAeFw0wNzEwMjQwMDAwMDBaFw0wODEwMjMyMzU5NTlaMIHdMRswGQYDVQQKDBJORUMgRXVy b3BlIExpbWl0ZWQxRjBEBgNVBAsMPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMgSW5j b3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTkxNTAzBgNVBAsMLENvbXBhbnkgLSBORUMgTGFib3Jh dG9yaWVzIEV1cm9wZSBIZWlkZWxiZXJnMRUwEwYDVQQDDAxUaG9tYXMgRGlldHoxKDAmBgkqhkiG 9w0BCQEWGXRob21hcy5kaWV0ekBudy5uZWNsYWIuZXUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALC4yWRsqDAwBYKjb3zoUfE18Tj5pOb+b2u/jmoeW6I3KKtzQxSIcW6qGrkrks0px63VYr72 6VF72Qhv4K31ntSOOLVOgz/yUXu2TBqsGxzcpjHD9LIJPK2LbEoo8m4t5mcVQReNhvrsCFukpYZn tb6xoCmmFfxcXeZh48Rhn4wVAgMBAAGjgb8wgbwwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMBEGCWCGSAGG+EIBAQQEAwIHgDBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vb25z aXRlY3JsLnZlcmlzaWduLmNvbS9PblNpdGVQdWJsaWMvTGF0ZXN0Q1JMLmNybDANBgkqhkiG9w0B AQQFAAOBgQAeld8hZLp3F1TtzJkmSe1io5guKbUqux6y0l//Ya5ESWBOpApe3vweWAsZYbn3dw0U F73oKpjuW6qdSNJizqtngj9is0DLLqH3u2PG3zksB7oy4hYPKejEuq4HXz3/bIxZSwvl7S9XL0Ce tSXJji+Rh4wFkL3GLZkWrlXPO+Y5tTGCApkwggKVAgEBMFcwQzERMA8GA1UEChMIVmVyaVNpZ24x LjAsBgNVBAsTJVZlcmlTaWduIENsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbm miilQC8u8nAwCQYFKw4DAhoFAKCCAZgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDcxMjE5MTUwODE4WjAjBgkqhkiG9w0BCQQxFgQUb6hJmfu3eGXWd3bmjTetEVCB nVcwZgYJKwYBBAGCNxAEMVkwVzBDMREwDwYDVQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNp Z24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBDQQIQRuECOhCAVuaaKKVALy7ycDBnBgkqhkiG 9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBoBgsqhkiG9w0BCRACCzFZ oFcwQzERMA8GA1UEChMIVmVyaVNpZ24xLjAsBgNVBAsTJVZlcmlTaWduIENsYXNzIDIgT25TaXRl IEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbmmiilQC8u8nAwDQYJKoZIhvcNAQEBBQAEgYB/yd1C4mg3 RZKj5oUF+lMUhlr6zCWDFDTUKkj84s5V1w/4lrfIhV+gAHqjOpOnRCQhxfJNKkzltAJBU0Xh0Mhr gnCs0JmMZZgnhZC7+fSmlJPVVq/nhr2JzYwHnrcyRY4VxBx+ElmIaM03c0fG2tenNCp29TniO/+g Xl+6ueHceQAAAAAAAA== ------=_NextPart_000_004D_01C84259.5E853590-- --===============1789883399== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp --===============1789883399==-- From psamp-bounces@ietf.org Fri Dec 21 06:18:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5fts-0007ZN-00; Fri, 21 Dec 2007 06:18:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ftq-0007Ys-UG for psamp@ietf.org; Fri, 21 Dec 2007 06:18:42 -0500 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5ftq-0006mI-0g for psamp@ietf.org; Fri, 21 Dec 2007 06:18:42 -0500 Received: from pc6 (1Cust209.tnt108.lnd4.gbr.da.uu.net [62.188.170.209]) by galaxy.systems.pipex.net (Postfix) with SMTP id 47261E000AD2; Fri, 21 Dec 2007 11:18:39 +0000 (GMT) Message-ID: <01e801c843ba$b82268e0$0601a8c0@pc6> From: "Tom Petch" To: "Thomas Dietz" , "Juergen Quittek" , References: <00f901c83747$ca83cc60$0601a8c0@pc6> <5F6519BF2DE0404D99B7C75607FF76FF392604@mx1.office> Subject: Re: [PSAMP] WG Last call for draft-ietf-psamp-info-07 Date: Fri, 21 Dec 2007 11:17:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org 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" To: "Tom Petch" ; "Juergen Quittek" ; Sent: Wednesday, December 19, 2007 4:08 PM Subject: RE: [PSAMP] WG Last call for draft-ietf-psamp-info-07 > Dear Tom, > > I applied your editorial changes and just want to comment a few other issues > inline... > > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > Sent: Mittwoch, 5. Dezember 2007 14:58 > > To: Juergen Quittek; psamp@ietf.org > > Subject: Re: [PSAMP] WG Last call for draft-ietf-psamp-info-07 > > > > Juergen > > > > > > 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. > > > > 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??? > > > > > 3. Terminology > > > > ... > > copied over in this document. > > Suggest > > copied into this document. > > > > > > 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? > > 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. > > > > > 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 > > > > 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 > > > > I hope the new section fits better... > > > 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. > > > > 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 > > _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp