From psamp-bounces@ietf.org Tue Mar 28 04:56:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOAwa-0007D6-2U; Tue, 28 Mar 2006 04:56:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOAwY-00078p-WC
	for psamp@ietf.org; Tue, 28 Mar 2006 04:56:55 -0500
Received: from ihemail1.lucent.com ([192.11.222.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOAwX-0001wJ-O6
	for psamp@ietf.org; Tue, 28 Mar 2006 04:56:54 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com
	[135.85.76.62])
	by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2S9unuK005827; 
	Tue, 28 Mar 2006 03:56:50 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id <H3GDXA58>; Tue, 28 Mar 2006 11:56:48 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509AA143E@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: psamp@ietf.org
Date: Tue, 28 Mar 2006 11:56:48 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: "Juergen Quittek \(E-mail\)" <quittek@ccrle.nec.de>
Subject: [PSAMP] PSAMP mailing list is moving.
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" <psamp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/psamp>,
	<mailto:psamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/psamp>
List-Post: <mailto:psamp@ietf.org>
List-Help: <mailto:psamp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/psamp>,
	<mailto:psamp-request@ietf.org?subject=subscribe>
Errors-To: psamp-bounces@ietf.org

We are moving the WG mailing list from 

  old:   psamp@ops.ietf.org
  New:   psamp@ietf.org

All subscription have been moved to the new list as well.

You list administrator is Juergen.

If you get this message, pls start posting to the new 
email address. The old one is being dismantled as we speak.

Bert

_______________________________________________
PSAMP mailing list
PSAMP@ietf.org
https://www1.ietf.org/mailman/listinfo/psamp



From psamp-bounces@ietf.org Thu Mar 30 15:50:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP46H-0006s8-R8; Thu, 30 Mar 2006 15:50:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FP46G-0006s3-MY
	for psamp@ietf.org; Thu, 30 Mar 2006 15:50:36 -0500
Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP46G-0007QJ-2g
	for psamp@ietf.org; Thu, 30 Mar 2006 15:50:36 -0500
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id
	k2UKoZO26769; Thu, 30 Mar 2006 22:50:35 +0200 (CEST)
Received: from [10.61.81.195] (ams-clip-vpn-dhcp4548.cisco.com [10.61.81.195])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id
	k2UKoUC04254; Thu, 30 Mar 2006 22:50:30 +0200 (CEST)
Message-ID: <442C4496.5010200@cisco.com>
Date: Thu, 30 Mar 2006 22:50:30 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
References: <44233D08.5080108@cisco.com>	<200603240939.16597.Thomas.Dietz@netlab.nec.de>
	<442BF1B5.3020507@cisco.com>
In-Reply-To: <442BF1B5.3020507@cisco.com>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 8cb9b411340046bf4080a729180a0672
Cc: psamp@ietf.org, ipfix <ipfix@net.doit.wisc.edu>
Subject: [PSAMP] Re: [ipfix] Re: Source ID -> Observation Domain Id? -> New
 Definition proposals
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" <psamp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/psamp>,
	<mailto:psamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/psamp>
List-Post: <mailto:psamp@ietf.org>
List-Help: <mailto:psamp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/psamp>,
	<mailto:psamp-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0928019968=="
Errors-To: psamp-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0928019968==
Content-Type: multipart/alternative;
	boundary="------------010900090802060008010502"

This is a multi-part message in MIME format.
--------------010900090802060008010502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id
	k2UKoZO26769

[re-posting to include the new psamp mailing list]

Regards, Benoit.
> Dear all,
>
> Considering also that we proposed to change the "Source ID" to "Observa=
tion Domain ID", we have to change the two definitions (Observation Domai=
n and Source ID) in all the IPFIX and PSAMP drafts.
>
> Here is the old "Observation Domain" definition
>
>    An Observation Domain is the largest set of Observation Points for=20
>    which Flow information can be aggregated by a Metering Process. =20
>    Each Observation Domain presents itself using a unique ID to the=20
>    Collecting Process to identify the IPFIX Messages it generates.  For=
=20
>    example, a router line card may be an observation domain if it is=20
>    composed of several interfaces, each of which is an Observation=20
>    Point.  Every Observation Point is associated with an Observation=20
>    Domain.=20
> Here is the new "Observation Domain" proposal.
>
>       An Observation Domain is the largest set of Observation Points fo=
r
>       which Flow information can be aggregated by a Metering Process.
>       For example, a router line card may be an Observation Domain if i=
t
>       is composed of several interfaces, each of which is an Observatio=
n
>       Point. In the IPFIX Message it generates, the Observation Domain
>       includes its Observation Domain ID, which is a unique per=20
> Exporting Process.
>       That way, the Collecting Process can identify the specific=20
> Observation
>       Domain from the Exporter that sends the IPFIX Messages. Every
>       Observation Point is associated with an Observation Domain.
>
> Here is the old "Source ID" definition
>    Source ID=20
>            A 32-bit identifier of the Observation Domain that is=20
>            locally unique to the Exporting Process.  The Exporting=20
>            Process uses the Source ID to uniquely identify to the=20
>            Collecting Process the Observation Domain that metered the=20
>            Flows.  Collecting Processes SHOULD use the combination the=20
>            combination of the Exporter (exporterIPv4Address,=20
>            exporterIPv6Address, or exportingProcessId) and the Source=20
>            ID field to separate different export streams originating=20
>            from the same Exporting Process.  The Source ID SHOULD be 0=20
>            when no specific Source ID is relevant for the entire IPFIX=20
>            Message.  For example, when exporting the Exporting Process=20
>            Statistics, or in case of hierarchy of Collector when=20
>            aggregated data records are exported.  The Source ID MUST be=
=20
>            zero when the IPFIX Message contains data records with=20
>            different Source ID values defined as scopes.=20
> Here is the new "Observation Domain ID" definition
>            A 32-bit identifier of the Observation Domain that is=20
>            locally unique to the Exporting Process.  The Exporting=20
>            Process uses the Observation Domain ID to uniquely identify =
to the=20
>            Collecting Process the Observation Domain that metered the=20
>            Flows.  Collecting Processes SHOULD use the combination the=20
>            combination of the Exporter (exporterIPv4Address,=20
>            exporterIPv6Address, or exportingProcessId) and the Observat=
ion
>            Domain ID field to separate different export streams origina=
ting=20
>            from the same Exporting Process.  The Observation Domain ID =
SHOULD be 0=20
>            when no specific Observation Domain ID is relevant for the e=
ntire IPFIX=20
>            Message.  For example, when exporting the Exporting Process=20
>            Statistics, or in case of hierarchy of Collector when=20
>            aggregated data records are exported. =20
>
> The last sentence of the definition, on which Bert had also a comment, =
has been removed from the definition:
>  =20
>
>     - sect 3.1 under SOurce ID
>     I do not understand the last sentence. WHat does it mean?
>     pls clarify in text.
>
> It's now part of the section "3.4.2.1 Scope". I agree that having this =
sentence was not too clear, as the readers don't know the notion of scope=
 at this stage of the draft.
> =20
>            The Source ID MUST be=20
>            zero when the IPFIX Message contains data records with=20
>            different Source ID values defined as scopes.=20
>
> Feedback?
> Note: I will post the next version of the protocol draft by tomorrow, a=
s agreed.
>
> Regards, Benoit.
>> Benoit,
>>
>> I also agree. It makes things even clearer.
>>
>> Regards, Thomas
>>
>> Am Freitag, 24. M=E4rz 2006 01:27 schrieb Benoit Claise:
>>  =20
>>> Dear all,
>>>
>>> During his review, Bert was confused by the sourceId being the unique=
 Id
>>> for the observation domain
>>>
>>>
>>> 	- [IPFIX-ARCH] sect 5.4 last line
>>> 	  s/Source ID/Domain ID/ ??
>>> 	  Or should the section title be somthing about "Source" ??
>>> 	  I am getting a bit confused about DOmain and Source ID I guess?
>>> 	  Protocol doc does indeed speak about SOurce ID.
>>>
>>> I agree that this confusing, and should be changed. However, this mus=
t be
>>> changed in ALL IPFIX and PSAMP documents. Information model: sourceId=
 ->
>>> observationDomainId
>>> Protocol: Source ID -> Observation Domain ID
>>>
>>> Any objections before starting to change the documents?
>>>
>>> Regards, Benoit.
>>>    =20
>


--------------010900090802060008010502
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
[re-posting to include the new psamp mailing list]<br>
<br>
Regards, Benoit.<br>
<blockquote cite="mid442BF1B5.3020507@cisco.com" type="cite">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <pre>Dear all,

Considering also that we proposed to change the "Source ID" to "Observation Domain ID", we have to change the two definitions (Observation Domain and Source ID) in all the IPFIX and PSAMP drafts.

Here is the old "Observation Domain" definition

   An Observation Domain is the largest set of Observation Points for 
   which Flow information can be aggregated by a Metering Process.  
   Each Observation Domain presents itself using a unique ID to the 
   Collecting Process to identify the IPFIX Messages it generates.  For 
   example, a router line card may be an observation domain if it is 
   composed of several interfaces, each of which is an Observation 
   Point.  Every Observation Point is associated with an Observation 
   Domain. </pre>
Here is the new "Observation Domain" proposal.<br>
  <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; An Observation Domain is the largest set of Observation Points
for
  <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; which Flow information can be aggregated by a Metering Process.
  <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For example, a router line card may be an Observation Domain if
it
  <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is composed of several interfaces, each of which is an
Observation
  <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Point. In the IPFIX Message it generates, the Observation Domain <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; includes its Observation Domain ID, which is a unique per
Exporting Process.<br>
&nbsp;&nbsp;&nbsp; &nbsp; That way, the Collecting Process can identify the specific
Observation <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Domain from the Exporter that sends the IPFIX Messages. Every <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Observation Point is associated with an Observation Domain. <br>
  <br>
  <pre>Here is the old "Source ID" definition</pre>
  <pre>   Source ID 
           A 32-bit identifier of the Observation Domain that is 
           locally unique to the Exporting Process.  The Exporting 
           Process uses the Source ID to uniquely identify to the 
           Collecting Process the Observation Domain that metered the 
           Flows.  Collecting Processes SHOULD use the combination the 
           combination of the Exporter (exporterIPv4Address, 
           exporterIPv6Address, or exportingProcessId) and the Source 
           ID field to separate different export streams originating 
           from the same Exporting Process.  The Source ID SHOULD be 0 
           when no specific Source ID is relevant for the entire IPFIX 
           Message.  For example, when exporting the Exporting Process 
           Statistics, or in case of hierarchy of Collector when 
           aggregated data records are exported.  The Source ID MUST be 
           zero when the IPFIX Message contains data records with 
           different Source ID values defined as scopes. </pre>
  <pre>Here is the new "Observation Domain ID" definition
           A 32-bit identifier of the Observation Domain that is 
           locally unique to the Exporting Process.  The Exporting 
           Process uses the Observation Domain ID to uniquely identify to the 
           Collecting Process the Observation Domain that metered the 
           Flows.  Collecting Processes SHOULD use the combination the 
           combination of the Exporter (exporterIPv4Address, 
           exporterIPv6Address, or exportingProcessId) and the Observation
           Domain ID field to separate different export streams originating 
           from the same Exporting Process.  The Observation Domain ID SHOULD be 0 
           when no specific Observation Domain ID is relevant for the entire IPFIX 
           Message.  For example, when exporting the Exporting Process 
           Statistics, or in case of hierarchy of Collector when 
           aggregated data records are exported.  

The last sentence of the definition, on which Bert had also a comment, has been removed from the definition:
  </pre>
  <blockquote>- sect 3.1 under SOurce ID<br>
I do not understand the last sentence. WHat does it mean?<br>
pls clarify in text.<br>
  </blockquote>
  <pre>It's now part of the section "3.4.2.1 Scope". I agree that having this sentence was not too clear, as the readers don't know the notion of scope at this stage of the draft.
 
           The Source ID MUST be 
           zero when the IPFIX Message contains data records with 
           different Source ID values defined as scopes. 

Feedback?
Note: I will post the next version of the protocol draft by tomorrow, as agreed.

Regards, Benoit.</pre>
  <blockquote cite="mid200603240939.16597.Thomas.Dietz@netlab.nec.de"
 type="cite">
    <pre wrap="">Benoit,

I also agree. It makes things even clearer.

Regards, Thomas

Am Freitag, 24. M&auml;rz 2006 01:27 schrieb Benoit Claise:
  </pre>
    <blockquote type="cite">
      <pre wrap="">Dear all,

During his review, Bert was confused by the sourceId being the unique Id
for the observation domain


	- [IPFIX-ARCH] sect 5.4 last line
	  s/Source ID/Domain ID/ ??
	  Or should the section title be somthing about "Source" ??
	  I am getting a bit confused about DOmain and Source ID I guess?
	  Protocol doc does indeed speak about SOurce ID.

I agree that this confusing, and should be changed. However, this must be
changed in ALL IPFIX and PSAMP documents. Information model: sourceId -&gt;
observationDomainId
Protocol: Source ID -&gt; Observation Domain ID

Any objections before starting to change the documents?

Regards, Benoit.
    </pre>
    </blockquote>
  </blockquote>
  <br>
</blockquote>
<br>
</body>
</html>

--------------010900090802060008010502--


--===============0928019968==
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

--===============0928019968==--




From psamp-bounces@ietf.org Fri Mar 31 02:43:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPEIQ-0004NF-RB; Fri, 31 Mar 2006 02:43:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FPEIQ-0004MP-E3
	for psamp@ietf.org; Fri, 31 Mar 2006 02:43:50 -0500
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPEIK-0002SM-Qs
	for psamp@ietf.org; Fri, 31 Mar 2006 02:43:45 -0500
Received: from n-dietz.office (mito.netlab.nec.de [195.37.70.39])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 4AE0F1BAC4D;
	Fri, 31 Mar 2006 09:41:33 +0200 (CEST)
From: Thomas Dietz <Thomas.Dietz@netlab.nec.de>
To: Benoit Claise <bclaise@cisco.com>
Date: Fri, 31 Mar 2006 09:43:36 +0200
User-Agent: KMail/1.9.1
References: <44233D08.5080108@cisco.com>
	<200603240939.16597.Thomas.Dietz@netlab.nec.de>
	<442BF1B5.3020507@cisco.com>
In-Reply-To: <442BF1B5.3020507@cisco.com>
Organization: Network Laboratories, NEC Europe Ltd.
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200603310943.37129.Thomas.Dietz@netlab.nec.de>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Cc: psamp <psamp@ietf.org>, ipfix <ipfix@net.doit.wisc.edu>
Subject: [PSAMP] Re: Source ID -> Observation Domain Id? -> New Definition
	proposals
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" <psamp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/psamp>,
	<mailto:psamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/psamp>
List-Post: <mailto:psamp@ietf.org>
List-Help: <mailto:psamp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/psamp>,
	<mailto:psamp-request@ietf.org?subject=subscribe>
Errors-To: psamp-bounces@ietf.org

Dear Benoit,

the text is fine. I just pointed at some wording issues inside.

Regards,

Thomas

Am Donnerstag, 30. M=E4rz 2006 16:56 schrieb Benoit Claise:
> Dear all,
>
> Considering also that we proposed to change the "Source ID" to "Observati=
on
> Domain ID", we have to change the two definitions (Observation Domain and
> Source ID) in all the IPFIX and PSAMP drafts.
>
> Here is the old "Observation Domain" definition
>
>    An Observation Domain is the largest set of Observation Points for
>    which Flow information can be aggregated by a Metering Process.
>    Each Observation Domain presents itself using a unique ID to the
>    Collecting Process to identify the IPFIX Messages it generates.  For
>    example, a router line card may be an observation domain if it is
>    composed of several interfaces, each of which is an Observation
>    Point.  Every Observation Point is associated with an Observation
>    Domain.
>
> Here is the new "Observation Domain" proposal.
>
>       An Observation Domain is the largest set of Observation Points for
>       which Flow information can be aggregated by a Metering Process.
>       For example, a router line card may be an Observation Domain if it
>       is composed of several interfaces, each of which is an Observation
>       Point. In the IPFIX Message it generates, the Observation Domain
>       includes its Observation Domain ID, which is a unique per
                                                    ^^^ is unique per

> Exporting Process.
>       That way, the Collecting Process can identify the specific
> Observation
>       Domain from the Exporter that sends the IPFIX Messages. Every
>       Observation Point is associated with an Observation Domain.
>
> Here is the old "Source ID" definition
>
>    Source ID
>            A 32-bit identifier of the Observation Domain that is
>            locally unique to the Exporting Process.  The Exporting
>            Process uses the Source ID to uniquely identify to the
>            Collecting Process the Observation Domain that metered the
>            Flows.  Collecting Processes SHOULD use the combination the
>            combination of the Exporter (exporterIPv4Address,
>            exporterIPv6Address, or exportingProcessId) and the Source
>            ID field to separate different export streams originating
>            from the same Exporting Process.  The Source ID SHOULD be 0
>            when no specific Source ID is relevant for the entire IPFIX
>            Message.  For example, when exporting the Exporting Process
>            Statistics, or in case of hierarchy of Collector when
>            aggregated data records are exported.  The Source ID MUST be
>            zero when the IPFIX Message contains data records with
>            different Source ID values defined as scopes.
>
> Here is the new "Observation Domain ID" definition
>            A 32-bit identifier of the Observation Domain that is
>            locally unique to the Exporting Process.  The Exporting
>            Process uses the Observation Domain ID to uniquely identify to
> the Collecting Process the Observation Domain that metered the Flows.=20
> Collecting Processes SHOULD use the combination the combination of the
                                  ^^^^^^^^^^^^^^^^ delete once  =20

> Exporter (exporterIPv4Address,
>            exporterIPv6Address, or exportingProcessId) and the Observation
>            Domain ID field to separate different export streams originati=
ng
>            from the same Exporting Process.  The Observation Domain ID
> SHOULD be 0 when no specific Observation Domain ID is relevant for the
> entire IPFIX Message.  For example, when exporting the Exporting Process
> Statistics, or in case of hierarchy of Collector when
>            aggregated data records are exported.
>
> The last sentence of the definition, on which Bert had also a comment, has
> been removed from the definition:
>
>     - sect 3.1 under SOurce ID
>     I do not understand the last sentence. WHat does it mean?
>     pls clarify in text.
>
> It's now part of the section "3.4.2.1 Scope". I agree that having this
> sentence was not too clear, as the readers don't know the notion of scope
> at this stage of the draft.
>
>            The Source ID MUST be
>            zero when the IPFIX Message contains data records with
>            different Source ID values defined as scopes.
>

I guess you already changed "Source ID" to "Observation Domain ID" here...

> Feedback?
> Note: I will post the next version of the protocol draft by tomorrow, as
> agreed.
>
> Regards, Benoit.
>
> > Benoit,
> >
> > I also agree. It makes things even clearer.
> >
> > Regards, Thomas
> >
> > Am Freitag, 24. M=E4rz 2006 01:27 schrieb Benoit Claise:
> >> Dear all,
> >>
> >> During his review, Bert was confused by the sourceId being the unique =
Id
> >> for the observation domain
> >>
> >>
> >> 	- [IPFIX-ARCH] sect 5.4 last line
> >> 	  s/Source ID/Domain ID/ ??
> >> 	  Or should the section title be somthing about "Source" ??
> >> 	  I am getting a bit confused about DOmain and Source ID I guess?
> >> 	  Protocol doc does indeed speak about SOurce ID.
> >>
> >> I agree that this confusing, and should be changed. However, this must
> >> be changed in ALL IPFIX and PSAMP documents. Information model: source=
Id
> >> -> observationDomainId
> >> Protocol: Source ID -> Observation Domain ID
> >>
> >> Any objections before starting to change the documents?
> >>
> >> Regards, Benoit.

=2D-=20
Thomas Dietz
Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany

_______________________________________________
PSAMP mailing list
PSAMP@ietf.org
https://www1.ietf.org/mailman/listinfo/psamp



From psamp-bounces@ietf.org Fri Mar 31 02:48:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPENB-0006tr-8J; Fri, 31 Mar 2006 02:48:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FPEN8-0006tR-Uw
	for psamp@ietf.org; Fri, 31 Mar 2006 02:48:42 -0500
Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPEN8-0002fh-9I
	for psamp@ietf.org; Fri, 31 Mar 2006 02:48:42 -0500
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id
	k2V7mat06353; Fri, 31 Mar 2006 09:48:36 +0200 (CEST)
Received: from [144.254.7.92] (dhcp-peg3-vl30-144-254-7-92.cisco.com
	[144.254.7.92])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id
	k2V7mZC07480; Fri, 31 Mar 2006 09:48:35 +0200 (CEST)
Message-ID: <442CDED2.5040702@cisco.com>
Date: Fri, 31 Mar 2006 09:48:34 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Thomas Dietz <Thomas.Dietz@netlab.nec.de>
References: <44233D08.5080108@cisco.com>	<200603240939.16597.Thomas.Dietz@netlab.nec.de>
	<442BF1B5.3020507@cisco.com>
	<200603310943.37129.Thomas.Dietz@netlab.nec.de>
In-Reply-To: <200603310943.37129.Thomas.Dietz@netlab.nec.de>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae
Cc: psamp <psamp@ietf.org>, ipfix <ipfix@net.doit.wisc.edu>
Subject: [PSAMP] Re: Source ID -> Observation Domain Id? -> New Definition
	proposals
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" <psamp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/psamp>,
	<mailto:psamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/psamp>
List-Post: <mailto:psamp@ietf.org>
List-Help: <mailto:psamp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/psamp>,
	<mailto:psamp-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1567024372=="
Errors-To: psamp-bounces@ietf.org

This is a multi-part message in MIME format.
--===============1567024372==
Content-Type: multipart/alternative;
	boundary="------------020308020205050106000803"

This is a multi-part message in MIME format.
--------------020308020205050106000803
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id
	k2V7mat06353

Thanks Thomas,

Corrected.

Regards, Benoit.
> Dear Benoit,
>
> the text is fine. I just pointed at some wording issues inside.
>
> Regards,
>
> Thomas
>
> Am Donnerstag, 30. M=E4rz 2006 16:56 schrieb Benoit Claise:
>  =20
>> Dear all,
>>
>> Considering also that we proposed to change the "Source ID" to "Observ=
ation
>> Domain ID", we have to change the two definitions (Observation Domain =
and
>> Source ID) in all the IPFIX and PSAMP drafts.
>>
>> Here is the old "Observation Domain" definition
>>
>>    An Observation Domain is the largest set of Observation Points for
>>    which Flow information can be aggregated by a Metering Process.
>>    Each Observation Domain presents itself using a unique ID to the
>>    Collecting Process to identify the IPFIX Messages it generates.  Fo=
r
>>    example, a router line card may be an observation domain if it is
>>    composed of several interfaces, each of which is an Observation
>>    Point.  Every Observation Point is associated with an Observation
>>    Domain.
>>
>> Here is the new "Observation Domain" proposal.
>>
>>       An Observation Domain is the largest set of Observation Points f=
or
>>       which Flow information can be aggregated by a Metering Process.
>>       For example, a router line card may be an Observation Domain if =
it
>>       is composed of several interfaces, each of which is an Observati=
on
>>       Point. In the IPFIX Message it generates, the Observation Domain
>>       includes its Observation Domain ID, which is a unique per
>>    =20
>                                                     ^^^ is unique per
>
>  =20
>> Exporting Process.
>>       That way, the Collecting Process can identify the specific
>> Observation
>>       Domain from the Exporter that sends the IPFIX Messages. Every
>>       Observation Point is associated with an Observation Domain.
>>
>> Here is the old "Source ID" definition
>>
>>    Source ID
>>            A 32-bit identifier of the Observation Domain that is
>>            locally unique to the Exporting Process.  The Exporting
>>            Process uses the Source ID to uniquely identify to the
>>            Collecting Process the Observation Domain that metered the
>>            Flows.  Collecting Processes SHOULD use the combination the
>>            combination of the Exporter (exporterIPv4Address,
>>            exporterIPv6Address, or exportingProcessId) and the Source
>>            ID field to separate different export streams originating
>>            from the same Exporting Process.  The Source ID SHOULD be 0
>>            when no specific Source ID is relevant for the entire IPFIX
>>            Message.  For example, when exporting the Exporting Process
>>            Statistics, or in case of hierarchy of Collector when
>>            aggregated data records are exported.  The Source ID MUST b=
e
>>            zero when the IPFIX Message contains data records with
>>            different Source ID values defined as scopes.
>>
>> Here is the new "Observation Domain ID" definition
>>            A 32-bit identifier of the Observation Domain that is
>>            locally unique to the Exporting Process.  The Exporting
>>            Process uses the Observation Domain ID to uniquely identify=
 to
>> the Collecting Process the Observation Domain that metered the Flows.=20
>> Collecting Processes SHOULD use the combination the combination of the
>>    =20
>                                   ^^^^^^^^^^^^^^^^ delete once  =20
>
>  =20
>> Exporter (exporterIPv4Address,
>>            exporterIPv6Address, or exportingProcessId) and the Observa=
tion
>>            Domain ID field to separate different export streams origin=
ating
>>            from the same Exporting Process.  The Observation Domain ID
>> SHOULD be 0 when no specific Observation Domain ID is relevant for the
>> entire IPFIX Message.  For example, when exporting the Exporting Proce=
ss
>> Statistics, or in case of hierarchy of Collector when
>>            aggregated data records are exported.
>>
>> The last sentence of the definition, on which Bert had also a comment,=
 has
>> been removed from the definition:
>>
>>     - sect 3.1 under SOurce ID
>>     I do not understand the last sentence. WHat does it mean?
>>     pls clarify in text.
>>
>> It's now part of the section "3.4.2.1 Scope". I agree that having this
>> sentence was not too clear, as the readers don't know the notion of sc=
ope
>> at this stage of the draft.
>>
>>            The Source ID MUST be
>>            zero when the IPFIX Message contains data records with
>>            different Source ID values defined as scopes.
>>
>>    =20
>
> I guess you already changed "Source ID" to "Observation Domain ID" here=
...
>
>  =20
>> Feedback?
>> Note: I will post the next version of the protocol draft by tomorrow, =
as
>> agreed.
>>
>> Regards, Benoit.
>>
>>    =20
>>> Benoit,
>>>
>>> I also agree. It makes things even clearer.
>>>
>>> Regards, Thomas
>>>
>>> Am Freitag, 24. M=E4rz 2006 01:27 schrieb Benoit Claise:
>>>      =20
>>>> Dear all,
>>>>
>>>> During his review, Bert was confused by the sourceId being the uniqu=
e Id
>>>> for the observation domain
>>>>
>>>>
>>>> 	- [IPFIX-ARCH] sect 5.4 last line
>>>> 	  s/Source ID/Domain ID/ ??
>>>> 	  Or should the section title be somthing about "Source" ??
>>>> 	  I am getting a bit confused about DOmain and Source ID I guess?
>>>> 	  Protocol doc does indeed speak about SOurce ID.
>>>>
>>>> I agree that this confusing, and should be changed. However, this mu=
st
>>>> be changed in ALL IPFIX and PSAMP documents. Information model: sour=
ceId
>>>> -> observationDomainId
>>>> Protocol: Source ID -> Observation Domain ID
>>>>
>>>> Any objections before starting to change the documents?
>>>>
>>>> Regards, Benoit.
>>>>        =20
>
>  =20


--------------020308020205050106000803
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id
	k2V7mat06353

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content=3D"text/html;charset=3DISO-8859-15"
 http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#ffffff" text=3D"#000000">
Thanks Thomas,<br>
<br>
Corrected.<br>
<br>
Regards, Benoit.<br>
<blockquote cite=3D"mid200603310943.37129.Thomas.Dietz@netlab.nec.de"
 type=3D"cite">
  <pre wrap=3D"">Dear Benoit,

the text is fine. I just pointed at some wording issues inside.

Regards,

Thomas

Am Donnerstag, 30. M=E4rz 2006 16:56 schrieb Benoit Claise:
  </pre>
  <blockquote type=3D"cite">
    <pre wrap=3D"">Dear all,

Considering also that we proposed to change the "Source ID" to "Observati=
on
Domain ID", we have to change the two definitions (Observation Domain and
Source ID) in all the IPFIX and PSAMP drafts.

Here is the old "Observation Domain" definition

   An Observation Domain is the largest set of Observation Points for
   which Flow information can be aggregated by a Metering Process.
   Each Observation Domain presents itself using a unique ID to the
   Collecting Process to identify the IPFIX Messages it generates.  For
   example, a router line card may be an observation domain if it is
   composed of several interfaces, each of which is an Observation
   Point.  Every Observation Point is associated with an Observation
   Domain.

Here is the new "Observation Domain" proposal.

      An Observation Domain is the largest set of Observation Points for
      which Flow information can be aggregated by a Metering Process.
      For example, a router line card may be an Observation Domain if it
      is composed of several interfaces, each of which is an Observation
      Point. In the IPFIX Message it generates, the Observation Domain
      includes its Observation Domain ID, which is a unique per
    </pre>
  </blockquote>
  <pre wrap=3D""><!---->                                                 =
   ^^^ is unique per

  </pre>
  <blockquote type=3D"cite">
    <pre wrap=3D"">Exporting Process.
      That way, the Collecting Process can identify the specific
Observation
      Domain from the Exporter that sends the IPFIX Messages. Every
      Observation Point is associated with an Observation Domain.

Here is the old "Source ID" definition

   Source ID
           A 32-bit identifier of the Observation Domain that is
           locally unique to the Exporting Process.  The Exporting
           Process uses the Source ID to uniquely identify to the
           Collecting Process the Observation Domain that metered the
           Flows.  Collecting Processes SHOULD use the combination the
           combination of the Exporter (exporterIPv4Address,
           exporterIPv6Address, or exportingProcessId) and the Source
           ID field to separate different export streams originating
           from the same Exporting Process.  The Source ID SHOULD be 0
           when no specific Source ID is relevant for the entire IPFIX
           Message.  For example, when exporting the Exporting Process
           Statistics, or in case of hierarchy of Collector when
           aggregated data records are exported.  The Source ID MUST be
           zero when the IPFIX Message contains data records with
           different Source ID values defined as scopes.

Here is the new "Observation Domain ID" definition
           A 32-bit identifier of the Observation Domain that is
           locally unique to the Exporting Process.  The Exporting
           Process uses the Observation Domain ID to uniquely identify to
the Collecting Process the Observation Domain that metered the Flows.=20
Collecting Processes SHOULD use the combination the combination of the
    </pre>
  </blockquote>
  <pre wrap=3D""><!---->                                  ^^^^^^^^^^^^^^^=
^ delete once  =20

  </pre>
  <blockquote type=3D"cite">
    <pre wrap=3D"">Exporter (exporterIPv4Address,
           exporterIPv6Address, or exportingProcessId) and the Observatio=
n
           Domain ID field to separate different export streams originati=
ng
           from the same Exporting Process.  The Observation Domain ID
SHOULD be 0 when no specific Observation Domain ID is relevant for the
entire IPFIX Message.  For example, when exporting the Exporting Process
Statistics, or in case of hierarchy of Collector when
           aggregated data records are exported.

The last sentence of the definition, on which Bert had also a comment, ha=
s
been removed from the definition:

    - sect 3.1 under SOurce ID
    I do not understand the last sentence. WHat does it mean?
    pls clarify in text.

It's now part of the section "3.4.2.1 Scope". I agree that having this
sentence was not too clear, as the readers don't know the notion of scope
at this stage of the draft.

           The Source ID MUST be
           zero when the IPFIX Message contains data records with
           different Source ID values defined as scopes.

    </pre>
  </blockquote>
  <pre wrap=3D""><!---->
I guess you already changed "Source ID" to "Observation Domain ID" here...

  </pre>
  <blockquote type=3D"cite">
    <pre wrap=3D"">Feedback?
Note: I will post the next version of the protocol draft by tomorrow, as
agreed.

Regards, Benoit.

    </pre>
    <blockquote type=3D"cite">
      <pre wrap=3D"">Benoit,

I also agree. It makes things even clearer.

Regards, Thomas

Am Freitag, 24. M=E4rz 2006 01:27 schrieb Benoit Claise:
      </pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">Dear all,

During his review, Bert was confused by the sourceId being the unique Id
for the observation domain


	- [IPFIX-ARCH] sect 5.4 last line
	  s/Source ID/Domain ID/ ??
	  Or should the section title be somthing about "Source" ??
	  I am getting a bit confused about DOmain and Source ID I guess?
	  Protocol doc does indeed speak about SOurce ID.

I agree that this confusing, and should be changed. However, this must
be changed in ALL IPFIX and PSAMP documents. Information model: sourceId
-&gt; observationDomainId
Protocol: Source ID -&gt; Observation Domain ID

Any objections before starting to change the documents?

Regards, Benoit.
        </pre>
      </blockquote>
    </blockquote>
  </blockquote>
  <pre wrap=3D""><!---->
  </pre>
</blockquote>
<br>
</body>
</html>

--------------020308020205050106000803--


--===============1567024372==
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

--===============1567024372==--