Subject: [PSAMP] FW: Last Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP) Protocol Specifications) to Proposed Standard

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 5 Nov 2007 10:48:13 +0100

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. 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. 

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. 

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

-----Original Message-----
From: The IESG [mailto:[email-masked]] 
Sent: Monday, October 22, 2007 4:46 PM
To: IETF-Announce
Cc: [email-masked]
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
[email-masked] mailing lists by 2007-11-05. Exceptionally, comments may
be sent to [email-masked] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

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

---

From: Benoit Claise <[email-masked]>
Date: Fri, 09 Nov 2007 14:17:14 +0100

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.
> 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
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       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

> 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].

> 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. 

> least figure C which is a key architecture diagram be kept on one page.
Ok. I will take care of that.

Regards, Benoit.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 9 Nov 2007 17:50:32 +0100

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. 
 
Dan

________________________________

	From: Benoit Claise [mailto:[email-masked]] 
	Sent: Friday, November 09, 2007 3:17 PM
	To: Romascanu, Dan (Dan)
	Cc: [email-masked]; [email-masked]; 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.

	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.

	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.

	Regards, Benoit.

		Dan

		-----Original Message-----
		From: The IESG [mailto:[email-masked]] 
		Sent: Monday, October 22, 2007 4:46 PM
		To: IETF-Announce
		Cc: [email-masked]
		Subject: Last Call: draft-ietf-psamp-protocol (Packet
Sampling (PSAMP)
		
		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
		[email-masked] mailing lists by 2007-11-05.
Exceptionally, comments may
		be sent to [email-masked] instead. In either case, please
retain the
		beginning of the Subject line to allow automated
sorting.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 30 Nov 2007 12:53:30 +0100

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:[email-masked]]
>     *Sent:* Friday, November 09, 2007 3:17 PM
>     *To:* Romascanu, Dan (Dan)
>     *Cc:* [email-masked]; [email-masked]; IANA
>     *Subject:* Re: [PSAMP] FW: Last Call: draft-ietf-psamp-protocol
>     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)