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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 2 Dec 2007 03:53:35 +0100

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

-------------
 
Juergen,

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

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

Thanks and Regards,

Dan

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

From: Lars Eggert [mailto:[email-masked]
<mailto:[email-masked]> ]

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

To: Romascanu, Dan (Dan)

Cc: Magnus Westerlund

Subject: tsv-dir review of the psamp documents

Hi, Dan,

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

Thanks for giving us the extra time for this review!

Lars

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

 

________________________________

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

	Dan,

		Benoit,
		 
		The comments resolutions that you suggest seem
appropriate to me. 
		 
		It's fine to wait for the transport area experts
comments before issuing a revised I-D.

	Any news on that front? 
	Based on IPFIX and PSAMP status
http://www1.ietf.org/mail-archive/web/ipfix/current/msg04203.html,
[PSAMP-PROTO] is one of the bottleneck.
	The next one is [PSAMP-INFO], for which we've got 2 reviews
already. A third one is missing.
	
	Regards, Benoit.

		 
		Dan

________________________________

			From: Benoit Claise [mailto:[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.

			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:[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

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

---

From: Benoit Claise <[email-masked]>
Date: Tue, 11 Dec 2007 00:12:00 +0100

Dan,

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

Regards, Benoit.
> */Benoit,/*
> *//* 
> */The TSV Area Director sent us the message below on 11/21, which I 
> issues. /*
> *//* 
> */Dan/*
> *//* 
> *//* 
> */-------------/*
> *//* 
> From: Lars Eggert [_mailto:[email-masked]]
>
> */------------------------/*
>
> *//* 
> *//* 
>  
>  
>  
>
>     ------------------------------------------------------------------------
>     *From:* Benoit Claise [mailto:[email-masked]]
>     *Sent:* Friday, November 30, 2007 1:54 PM
>     *To:* Romascanu, Dan (Dan)
>     *Cc:* [email-masked]
>     *Subject:* Re: [PSAMP] FW: Last Call: draft-ietf-psamp-protocol
>>     */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?
>>     *//*
>>     *//* 
>>     */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:
>>         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
>>         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       | 
>>            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
>>         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.
>>
>>         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.
>>>           
>>>         From: The IESG [mailto:[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
>>>         - '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.
>>>