Subject: RE: Open issues on PSAMP framework

From: Juergen Quittek <[email-masked]>
Date: Thu, 01 Jul 2004 15:54:15 +0200

Nick,

Thanks for compiling the list.  Please find my comments inline

--On 24.06.2004 1:27 h -0400 [email-masked] wrote:

> Juergen,
>
> Here is a list of the major open issues raised in the messages that you
> referenced, plus proposals for their resolution. In some cases
> alternative resolutions are proposed.
>
> I encourage mailing list participant to send comments to the list so
> that we can converge.
>
> A number of smaller stylistic issues raised are not listed, but will be
> taken into account in the revision.
>
> Nick
>
> ---
>
>
> FW-0: Document type.
> The AD and WG Chairs have agreed that the framework document will be
> informational.  RESOLVED
>
> FW-1: References to other PSAMP documents.
> Proposal: Include a section describing the role of the other wg
> documents. Use more informative labels for references:  [PSAMP-PROTO]
> protocol document, [PSAMP-MIB] MIB document, [PSAMP-TECH] sampling
> techniques, [PSAMP-INFO] information model document.
>
> Question: can the other PSAMP drafts be included as normative references
> while they are yet to be completed?

Yes, they can.

Giving an overview of the documents that are influenced by the
framework is a good idea.  But referencing them in any way will most
probably make the document stuck in the RFC editor queue until
all references also achieve RFC status. This might be a challenge
for the patience of the authors, but it is not bad in general.
Since the other documents will reference the framework in turn,
then all PSAMP documents would be published at once.

I would prefer referencing the other documents as RFCs with placeholders
for the so far unknown numbers.

> FW-2: Terminology section.
> Proposal: arrange items in alphabetic order. Use initial upper cases for
> terms.

Fine with me.  But I do not see strong reasons for one way or another.
This should be decided by the editors.

> FW-3: Requirements.
> Proposal: emphasize high level generic requirements (current Section 3)
> vs. detailed requirements (following sections). Because document is
> informational, use lower cast must, should and may.

> FW-4: Architecture.
> Proposal: separate out a new architecture section. (The current section
> 2 attempts too much by describing architecture by means of the
> terminology list). Arrange architecture diagram on a single page.
> Include new diagrams of components of measurement process.

I support the proposal.

> FW-5: Packet selection terminology (Sec 4.1).
> The normative selection terminology reference for PSAMP will be
> [PSAMP-TECH]. Some, but not all, terms from [PSAMP-TECH] are used in the
> framework draft.

> Alternative Proposals:
> . FW-5a: Duplicate all terminology from [PSAMP-TECH]
> . FW-5b: Duplicate only those terms used in the framework document
> . FW-5c: Duplicate no terms and refer to [PSAMP-TECH] for definitions

I do not like alternative a.  I am fine with b and c.
b makes this document easier to read on its own.
c avoids consistency checking.
I have a weak preference for b.

> FW-6: Packet Selection Operations (Sec 4.2)
> The normative selection operation reference for PSAMP will be
> [PSAMP-TECH]. Operations defined in [PSAMP-TECH] are also summarized in
> the framework draft.
> Proposal: retain current summary descriptions of selection operations.
> Omit material from 4.2 on applications of hash based sampling; this now
> occurs in [PSAMP-TECH].

Fine with me.

> FW-7: Packet Report and Packet Interpretation.
>
> While PSAMP will use IPFIX, the PSAMP terms (packet report and packet
> interpretation) are not used in IPFIX. But the meaning appears
> compatible with IPFIX (see Major Point 9 in
> https://psg.com/lists/psamp/psamp.2004/msg00024.html )
>
> Alternate Proposals:
> FW-7a: retain psamp terminology, add section on correspondence with
> IPFIX
> FW-7b: omit psamp terminology and convert to IPFIX. This is probably
> best long term. But would slow down convergence of the document since
> (i) it would be a major change, and (ii) IPFIX is still in flux.

I have a clear preference for alternative a.

PSAMP uses the IPFIX protocol, but the IPFIX terminology is not useful
in some sections of the PSAMP documents.  I would rather like a clean
and consistent set of PSAMP documents than a terminology mix.

Maybe, we should request the IPFIX group to generalize their
terminology in a way that fits both groups?

> FW-8: Transport Protocol.
> Proposal: Section 7 to undergo major updates to reflect (i) choice of
> IPFIX for PSAMP; (ii) apparent compatibility of IPFIX export protocol
> choices (see
> http://ipfix.doit.wisc.edu/archive/2377.html) with psamp requirements.
> Section 7.7 on collector based rate reconfiguration will be omitted.
>
> Question: is SCTP-PR a MUST in IPFIX?

Yes, it is.

> FW-9: Proposal: Omit Section 4.6
>
> FW-10: Packet reports. Proposal: definition in Section 2 to be modified
> to include e.q. sequence numbers.
>
> FW-11: Input sequence numbers.
> Proposal: include input sequence numbers for each selector in a
> composite.
>
> FW-12: Selection State.
> Proposal: selection state to be associated with a packet (e.g. for
> reporting) is post-processing of the packet.
>
> FW-13: Style.
> Proposal: Streamline document to retain basic motivation while pruning
> longer justifications (e.g. Section 10) .
>
> FW-14: PSAMP device.
> Proposal: define analogously to IPFIX.

Sounds like a good choice.

Thanks,

    Juergen

>> -----Original Message-----
>> From: Juergen Quittek [mailto:[email-masked]]
>> Sent: Thursday, May 13, 2004 3:54 AM
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]; Duffield,Nicholas G (Nick);
>> Greenberg,Albert G (Albert); [email-masked];
>> [email-masked]; Rexford,Jennifer L (Jennifer); [email-masked]
>> Subject: Open issues on PSAMP framework
>>
>> Dear all,
>>
>> I really would like to close WG last call on the PSAMP framework soon.
>>
>> Still there is a non-trivial list of open issues that have not been
>> closed on the mailing list.  I am referring to issues raised in the
>> following messages:
>>
>>     https://psg.com/lists/psamp/psamp.2004/msg00024.html
>>     https://psg.com/lists/psamp/psamp.2004/msg00025.html
>>     https://psg.com/lists/psamp/psamp.2004/msg00026.html  (and
> follow-ups)
>>     https://psg.com/lists/psamp/psamp.2004/msg00030.html
>>
>> Please have a look at these issues and help finishing the Document!
>>
>> Nick, at least you as document editor (or one of your seven
> co-authors)
>> should reply on the raised issues and suggest a solution for each one.
>>
>> Thanks,
>>
>>     Juergen
>> --
>> Juergen Quittek        [email-masked]        Tel: +49 6221
> 90511-15
>> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221
> 90511-55
>> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
> http://www.ccrle.nec.de
>>
>
>

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