Subject: New version of the protocol draft draft-ietf-psamp-protocol-03.txt

From: Benoit Claise <[email-masked]>
Date: Fri, 23 Dec 2005 14:36:09 +0100

Dear all,

As promised during the last IETF meeting in Vancouver, a new version of the PSAMP protocol draft has just been posted.

Many issues have been closed:

   PROTO-01 [PSAMP-FMWK] mentions the optional Export Packets 
   compression (see section 8.5) Should we mention this in this 
   document? 
    
   PROTO-02 From a protocol point of view, there a no differences 
   between the Field Match Filtering and the Router State Filtering as 
   defined in [PSAMP-TECH]. The only difference concerns the I.E. on 
   which we do the filtering... part of the packet in one case, not part 
   of the packet in the other case. Proposal: merge the 2 methods in 
   [PSAMP-TECH] 

   PROTO-03 The second open issue is concerned with reporting the 
   sequential order of sampling and filtering. => order of the scope. 
   We spot a new problem: we could export twice the hash value. How to 
   distinguish them? How to know that the hash value 1 corresponds to a 
   specific definition specified in an Option Template. 

   PROTO-05 Transport protocol: SCTP and/or UDP and/or TCP. Nothing is 
   mentioned at this stage. [PSAMP-FMWK] and PSAMP charter specifically 
   mention UDP. 
    
   PROTO-06 Even if the notion of Associations ID is mentioned in 
   [PSAMP-TECH], maybe a term such as SelectionPath or PathID would be 
   more appropriate. 

   PROTO-07 Even if [PSAMP-TECH] section 7.1 and 7.2 describes that "The 
   ASSOCIATIONS field describes the Observation Point and optionally the 
   IPFIX processes to which the packet Selector is associated. Values: 
   <STREAM ID, IPFIX Metering process ID, IPFIX Exporting process ID, 
   IDs of other associated processes>", we can't see an example where 
   the IPFIX process(es) ID would be required. Don't we have enough with 
   the list of Selector IDs?  

   PROTO-09 "The algorithm specific Information Elements, defining 
   configuration parameters for match-based and router state filtering, 
   are taken from the full range of available IPFIX Information Elements 
   [IPFIX-INFO]". What about the ones from [PSAMP-INFO]? In other words, 
   are they I.E.s in [PSAMP-INFO] that we could use for the match-based 
   and router state filtering? 

   PROTO-13 The solution in this document is based on the fact that 
   https://psg.com/lists/psamp/psamp.2005/msg00050.html is taken into 
   account. That means: no range for the filtering 

Note that some open issues have been listed in this version of the draft

   PROTO-16 IANA considerations section to be completed. 
   Two questions: 
   1. I'm not too sure whether we should mandate a new IETF RFC for the 
   new selection method description? 
   2. I'm not too sure whether we should mandate new IANA-registered 
   information elements for the new selection method? 
       In other words, can we have proprietary selection method in the 
   selectorAlgorithm Information Element?  
       
   PROTO-17 "Encrypted Packets: Selectors that interpret packet fields 
   must be configurable to ignore (i.e. not select) encrypted packets, 
   when they are detected". "Since packet encryption alters the meaning 
   of encrypted fields, field match filtering must be configurable to 
   ignore encrypted packets, when detected." I guess we will need extra 
   text for this. 
    
   PROTO-18 "The exporting process must have an export rate limit, 
   configurable per Exporting Process". I guess we need extra text for 
   this. 
    
   PROTO-19 "the timestamp of observation of the packet at the 
   Observation Point. The timestamp should be reported to microsecond 
   resolution." Nothing is mentioned in this draft regarding this issue. 
    
   PROTO-20 Hash based filtering to be completed.  

Regarding the action items, some have been closed:

   PROTO-102 insert double spaces after the end of each sentence. 

   PROTO-103 Should briefly discuss the fact that PSAMP is OK with IPFIX 
   requirements in terms of time (uSec precision) 

   PROTO-105 Section 6 about "PSAMP requirements": check if any changes 
   with the version 5 of [PSAMP-FMWK]. This draft is based on ietf-
   psamp-framework-04.txt. 

   PROTO-107 All the examples in section 7 should contain the 
   Information Element ID instead of the Information Element name. 
   Example: Option 3 =   samp.PacketSpace  
   Corrected Example: Option 3 = 305   

However, there are still a couple of action items:

   PROTO-101 See EDITOR'S NOTE 
    
   PROTO-104 Fix the terminology sections, as a last step before 
   publication 
 
   PROTO-106 Extend security considerations by a discussion on exported  
   Payload. Consider whether [PSAMP-INFO] or [PSAMP-PROTO] or both 
   is/are the place(s). 
    
   PROTO-107 Provide the equivalent for variable length I.E. 
   Here is an example of a basic Packet Report, with a SelectionPath 
   value of 9 (will be explained later on) and ipPacketSection 
   Information Element of 12 bytes, encoded with a fixed length. 
   To be put in section 7.3.1 
 
   PROTO-108 Have a statement that this protocol specification  
   meets all requirements for the PSAMP protocol stated in the framework  
   except ... An then have a list of bullets, where at minimum there is 
   stated "not yet covered" or a longer explanation why it is not 
   covered. This would be replacement for the long list of requirements 
   in section 6.1 

The goal is to post a final draft version, with all open issues solved, by the IETF deadline (should be around the beginning of March).

Regards, Benoit.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>