From psamp-bounces@ietf.org Mon Nov 05 04:49: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 1IoyZr-00074e-3M; Mon, 05 Nov 2007 04:49:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoyZo-0006yG-5B; Mon, 05 Nov 2007 04:49:00 -0500 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IoyZn-00016o-K3; Mon, 05 Nov 2007 04:49:00 -0500 X-IronPort-AV: E=Sophos;i="4.21,371,1188792000"; d="scan'208";a="71027997" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Nov 2007 04:48:56 -0500 X-IronPort-AV: E=Sophos;i="4.21,371,1188792000"; d="scan'208";a="127831157" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Nov 2007 04:48:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Nov 2007 10:48:13 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP) Protocol Specifications) to Proposed Standard Thread-Index: AcgUvUqV/ZpvfIXfTxOEw4qbp6KTjAK0VbMw From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: psamp@ietf.org, IANA Subject: [PSAMP] FW: Last Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP) Protocol Specifications) to Proposed Standard 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 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. 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. 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 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 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. 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 ' 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=3Dview_id&dTag= =3D 10963&rfc_flag=3D0 _______________________________________________ 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 From psamp-bounces@ietf.org Mon Nov 05 11:00:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip4NU-0003Wq-83; Mon, 05 Nov 2007 11:00:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip4NS-0003Vs-Ks; Mon, 05 Nov 2007 11:00:38 -0500 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip4NR-0001pi-A9; Mon, 05 Nov 2007 11:00:38 -0500 X-IronPort-AV: E=Sophos;i="4.21,373,1188792000"; d="scan'208";a="81021771" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 05 Nov 2007 11:00:37 -0500 X-IronPort-AV: E=Sophos;i="4.21,373,1188792000"; d="scan'208";a="127951488" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Nov 2007 11:00:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Nov 2007 16:59:53 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-psamp-sample-tech (Sampling and Filtering Techniques for IP Packet Selection) to Proposed Standard Thread-Index: AcgUvU8v75qx0EeGROqlErYwJi1ClgLAUONA From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: psamp@ietf.org Subject: [PSAMP] FW: Last Call: draft-ietf-psamp-sample-tech (Sampling and Filtering Techniques for IP Packet Selection) to Proposed Standard 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 Please find below my technical and editorial comments:=20 Technical 1. Section 3.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 2. Taking into account the observation at the previous point, why do filters defined in section 6.1 for property match operations refer only to the IP header and do not cover also the sub-IP header?=20 3. The Security Consideration section should be explicit about the need for confidentiality of the sampling configuration information and authentication of the entities that configure this information. Even if the methods of configuration are out of the scope of this document, mentioning the basic security expectations for the configuration information will help for selecting the appropriate tools and protocols for this purpose. 4. This being a document that targets Proposed Standard it looks strange that the other PSAMP and IPFIX documents are only mentioned as Informational references. The document reuses terminology and refers to the architecture described in PSAMP-FW and I would expect that at list this be considered essential for the understanding of this document.=20 Editorial 1. It would be useful for the Abstract and/or title to mention that this document is part of the PSAMP family of documents. This helps people searching in the RFC index in the future to identify easier the document and where it belongs.=20 2. 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 Sampling. In order to avoid comments about this capitalization style I suggest to explain this convention in the terminology section. It may also be useful to make this capitalization consistent with other PSAMP document, for example Flow is capitalized in draft-psamp-proto, but not here=20 3. In the table in Section 4 - need to explain what x and (x) mean 4. the list of filters for the Selection Process in Section 6.1, page 18-19 what do (iv) and (v) mean? Are these packets that failed Ingress filtering as per RFC2827 (iv) and packets that were detected as out of spec for (v)? Making this clear would help Dan =20 -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org]=20 Sent: Monday, October 22, 2007 4:47 PM To: IETF-Announce Cc: psamp@ietf.org Subject: Last Call: draft-ietf-psamp-sample-tech (Sampling and Filtering Techniques for IP Packet Selection) to Proposed Standard=20 The IESG has received a request from the Packet Sampling WG (psamp) to consider the following document: - 'Sampling and Filtering Techniques for IP Packet Selection ' 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. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Fri Nov 09 08:17:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqTkA-0007VE-B8; Fri, 09 Nov 2007 08:17:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqTk8-0007Qx-Fh; Fri, 09 Nov 2007 08:17:52 -0500 Received: from no-more.cisco.com ([64.104.206.251] helo=av-tac-apt.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqTk6-0001pS-7N; Fri, 09 Nov 2007 08:17:52 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-apt.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id lA9DHLA15915; Sat, 10 Nov 2007 00:17:21 +1100 (EST) Received: from [10.61.81.223] (ams3-vpn-dhcp4576.cisco.com [10.61.81.223]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id lA9DHFI15474; Fri, 9 Nov 2007 14:17:15 +0100 (CET) Message-ID: <47345DDA.3070805@cisco.com> Date: Fri, 09 Nov 2007 14:17:14 +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: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2f0065339d489fe5a2873ea9ad776d1a Cc: psamp@ietf.org, ietf@ietf.org, IANA 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="===============1418495125==" Errors-To: psamp-bounces@ietf.org This is a multi-part message in MIME format. --===============1418495125== Content-Type: multipart/alternative; boundary="------------080308030001070302040308" This is a multi-part message in MIME format. --------------080308030001070302040308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 > --------------080308030001070302040308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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

--------------080308030001070302040308-- --===============1418495125== 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 --===============1418495125==-- From psamp-bounces@ietf.org Fri Nov 09 11:51: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 1IqX52-000632-9y; Fri, 09 Nov 2007 11:51:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqX50-0005x3-Qc for psamp@ietf.org; Fri, 09 Nov 2007 11:51:38 -0500 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqX4y-0001Va-8C for psamp@ietf.org; Fri, 09 Nov 2007 11:51:38 -0500 X-IronPort-AV: E=Sophos;i="4.21,396,1188792000"; d="scan'208,217";a="82188688" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 09 Nov 2007 11:51:33 -0500 X-IronPort-AV: E=Sophos;i="4.21,396,1188792000"; d="scan'208,217";a="123591970" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 09 Nov 2007 11:50:57 -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: Fri, 9 Nov 2007 17:50:32 +0100 Message-ID: In-Reply-To: <47345DDA.3070805@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: Acgi0vy8prelRJ91RHySlLvVtwjvxAAHYBhg References: <47345DDA.3070805@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" X-Spam-Score: 0.0 (/) X-Scan-Signature: dd530fb5c702ad6eef32cae6dcb86145 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="===============0533127127==" Errors-To: psamp-bounces@ietf.org This is a multi-part message in MIME format. --===============0533127127== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C822F0.A501A4E9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C822F0.A501A4E9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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.=20 =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. 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 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce =09 _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp =20 ------_=_NextPart_001_01C822F0.A501A4E9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
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 I-D. =
 
Dan
 
 
 
 

From: Benoit Claise = [mailto:bclaise@cisco.com]=20
Sent: Friday, November 09, 2007 3:17 PM
To: = Romascanu,=20 Dan (Dan)
Cc: ietf@ietf.org; psamp@ietf.org; = IANA
Subject:=20 Re: [PSAMP] FW: Last Call: draft-ietf-psamp-protocol (Packet Sampling = (PSAMP)=20 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=20 before the Transport Area directors have reviewed the doc (they asked = for an=20 extended deadline)
Please quickly evaluate if you agree with the = proposed=20 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 = information=20 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, = 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_01C822F0.A501A4E9-- --===============0533127127== 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 --===============0533127127==-- From psamp-bounces@ietf.org Thu Nov 22 11:45:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFAt-0006Ij-Lg; Thu, 22 Nov 2007 11:45:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFAr-0006Da-My; Thu, 22 Nov 2007 11:45:09 -0500 Received: from no-more.cisco.com ([64.104.206.251] helo=av-tac-apt.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvFAq-0004tp-LE; Thu, 22 Nov 2007 11:45:09 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-apt.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id lAMGj1j11747; Fri, 23 Nov 2007 03:45:03 +1100 (EST) Received: from [10.61.82.26] (ams3-vpn-dhcp4635.cisco.com [10.61.82.26]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id lAMGiqI14391; Thu, 22 Nov 2007 17:44:58 +0100 (CET) Message-ID: <4745B204.70400@cisco.com> Date: Thu, 22 Nov 2007 17:44:52 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "ipfix@ietf.org" , psamp@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: Subject: [PSAMP] IPFIX and PSAMP status 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="===============0578758493==" Errors-To: psamp-bounces@ietf.org This is a multi-part message in MIME format. --===============0578758493== Content-Type: multipart/alternative; boundary="------------060609030806030705000702" This is a multi-part message in MIME format. --------------060609030806030705000702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I made this little summary for myself, to understand what the next bottleneck(s) is/are in IPFIX and as a consequence in PSAMP Then I thought about sharing this info, as it might be useful for others as well... _IPFIX_ Drafts in the RFC-editor queue: _STATE_ _DEPENDENCIES_ draft-ietf-ipfix-info AUTH, but I replied so will become EDIT IPFIX-PROTO: in queue draft-ietf-ipfix-protocol EDIT IPIFX-INFO: in queue draft-ietf-ipfix-biflow EDIT IPFIX-PROTO, IPFIX-INFO: in queue draft-ietf-ipfix-architecture EDIT IPFIX-PROTO, IPFIX-INFO, IPFIX-AS: in queue draft-ietf-ipfix-as MISSREF IPFIX-INFO, IPFIX-PROTO: in queue Missing PSAMP-INFO draft-ietf-ipfix-reducing-redundancy MISSREF IPFIX-PROTO, IPFIX-INFO: in queue Missing PSAMP-PROTO Drafts not yet in the RFC-editor queue: _STATUS_ _DEPENDENCIES___ draft-ietf-ipfix-implementation-guidelines In last call, version posted IPFIX-PROTO, IPFIX-INFO: in queue (but missed the deadline) draft-ietf-ipfix-testing In last call, new version posted IPFIX-PROTO, IPFIX-INFO, IPFIX-ARCH, IPFIX-AS: in queue draft-ietf-ipfix-mib One more version needed before the last call IPFIX-PROTO, IPFIX-INFO: in queue _PSAMP_ Drafts not yet in the RFC-editor queue: _STATUS_ __ draft-ietf-psamp-framework IESG review draft-ietf-psamp-sample-tech IESG review draft-ietf-psamp-protocol IESG review, Received some feedback from Dan and Suresh Krishnan, addressed already Will receive some more feedback from the transport area directors draft-ietf-psamp-info WG Last call Juergen: "I will not close the call without knowing of at least three solid reviews from non-authors" In conclusion: the next bottleneck is [PSAMP-INFO]. Some more reviews would be appreciated in order to have the first series of IPFIX RFCs Regards, Benoit. --------------060609030806030705000702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

I made this little summary for myself, to understand what the next bottleneck(s) is/are in IPFIX and as a consequence in PSAMP
Then I thought about sharing this info, as it might be useful for others as well...

IPFIX
Drafts in the RFC-editor queue:
                                                                    STATE                                                          DEPENDENCIES
    draft-ietf-ipfix-info                                    AUTH, but I replied so will become EDIT      IPFIX-PROTO: in queue
    draft-ietf-ipfix-protocol                             EDIT                                                             IPIFX-INFO: in queue
    draft-ietf-ipfix-biflow                                EDIT                                                              IPFIX-PROTO, IPFIX-INFO: in queue
    draft-ietf-ipfix-architecture                        EDIT                                                              IPFIX-PROTO, IPFIX-INFO, IPFIX-AS: in queue
    draft-ietf-ipfix-as                                      MISSREF                                                      IPFIX-INFO, IPFIX-PROTO: in queue
                                                                                                                                          Missing PSAMP-INFO
    draft-ietf-ipfix-reducing-redundancy         MISSREF                                                      IPFIX-PROTO, IPFIX-INFO: in queue
                                                                                                                                         Missing PSAMP-PROTO

Drafts not yet in the RFC-editor queue:
                                                                    STATUS                                                      DEPENDENCIES
    draft-ietf-ipfix-implementation-guidelines   In last call, version posted                             IPFIX-PROTO, IPFIX-INFO: in queue
                                                                    (but missed the deadline)
    draft-ietf-ipfix-testing                                In last call, new version posted                      IPFIX-PROTO, IPFIX-INFO,
                                                                                                                                        IPFIX-ARCH, IPFIX-AS: in queue
    draft-ietf-ipfix-mib                                    One more version needed before the last call IPFIX-PROTO, IPFIX-INFO: in queue


PSAMP
Drafts not yet in the RFC-editor queue:
                                                                    STATUS                                                     
    draft-ietf-psamp-framework                     IESG review
    draft-ietf-psamp-sample-tech                   IESG review
    draft-ietf-psamp-protocol                         IESG review,
                                                                    Received some feedback from Dan and Suresh Krishnan, addressed already
                                                                    Will receive some more feedback from the transport area directors
    draft-ietf-psamp-info                                WG Last call
                                                                    Juergen: "I will not close the call without knowing of at least
                                                                                 three solid reviews from non-authors"

In conclusion: the next bottleneck is [PSAMP-INFO].
Some more reviews would be appreciated in order to have the first series of IPFIX RFCs

Regards, Benoit.

--------------060609030806030705000702-- --===============0578758493== 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 --===============0578758493==-- From psamp-bounces@ietf.org Sat Nov 24 20:07:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw5yP-0006Gm-03; Sat, 24 Nov 2007 20:07:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw5yN-0006Gd-Tf for psamp@ietf.org; Sat, 24 Nov 2007 20:07:47 -0500 Received: from mail.nttv6.net ([192.16.178.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iw5yM-0003QZ-K7 for psamp@ietf.org; Sat, 24 Nov 2007 20:07:47 -0500 Received: from [127.0.0.1] (mail.nttv6.net [192.68.245.115] (may be forged)) by mail.nttv6.net (8.14.1/8.14.1) with ESMTP id lAP17hZd046964; Sun, 25 Nov 2007 10:07:44 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sun, 25 Nov 2007 10:07:45 +0900 From: kobayashi atsushi To: Juergen Quittek Subject: Re: [PSAMP] WG Last call for draft-ietf-psamp-info-07 In-Reply-To: References: <17649B3411A298A0393020E1@n-quittek2.office> Message-Id: <20071125100349.4D24.AKOBA@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.30.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.68.245.115]); Sun, 25 Nov 2007 10:07:44 +0900 (JST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 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: , Errors-To: psamp-bounces@ietf.org Dear all, I have reviewed the PSAMP information model draft. Sorry for late reply. I listed up some my comments, as follows. --- Section 8.2.13-17: If insufficient octets are available for the length specified in the Template, the Information Element MUST NOT be padded. Even if these section elements are variable length type, why do we need to consider the padding? If this description means note about using as fixed length type, I hope additional explanation. --- Section 8.2.15: On the Collector side, I wonder how to recognize frame type of dataLinkFrameSection. In particular, it needs to recognize PPP and EtherFrame. --- Section 8.2.33: This Information Element contains a boolean value which is TRUE if the output from this hash Selector has been configured to be included in the packet report as a packet digest, else FALSE. I understood it as follows. If the value of "hashDigestOutput" is "TRUE", the Selector adds in its "digestHashValue" in exporting packet report. If I didn't misread it, I cannot image the situation on using "FALSE". PSAMP Protocol says that "hashDigestOutput" of each Sector MUST be included in the packet report. psamp-protocol section 6.4.1: If there is more than one digest function then each hash value MUST be included in the same order as they appear in the selection sequence. If there are no digest functions in the selection sequence no element for the digest needs to be sent. --- Section 8.2.27-34: Other configurable Information Elements include the description as a example in a similar way. For example, this Information Element may used to describe the configuration of a Hash based Filtering. Best Regards, Atsushi KOBAYASHI On Mon, 22 Oct 2007 17:14:44 +0900 Juergen Quittek wrote: > 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 > --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Fri Nov 30 06:53:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy4RD-0004yj-O6; Fri, 30 Nov 2007 06:53:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy4RC-0004yY-Rh for psamp@ietf.org; Fri, 30 Nov 2007 06:53:42 -0500 Received: from no-more.cisco.com ([64.104.206.251] helo=av-tac-apt.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy4RA-0003lk-Bw for psamp@ietf.org; Fri, 30 Nov 2007 06:53:42 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-apt.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id lAUBrYe29951; Fri, 30 Nov 2007 22:53:34 +1100 (EST) Received: from [10.61.81.242] (ams3-vpn-dhcp4595.cisco.com [10.61.81.242]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id lAUBrUI22876; Fri, 30 Nov 2007 12:53:30 +0100 (CET) Message-ID: <474FF9BA.9020109@cisco.com> Date: Fri, 30 Nov 2007 12:53:30 +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> In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 78a8240bd7a9c0d7033035fffd7b84c6 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="===============0413832128==" Errors-To: psamp-bounces@ietf.org This is a multi-part message in MIME format. --===============0413832128== Content-Type: multipart/alternative; boundary="------------060907040104080009080907" This is a multi-part message in MIME format. --------------060907040104080009080907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 >> > --------------060907040104080009080907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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


--------------060907040104080009080907-- --===============0413832128== 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 --===============0413832128==--