From ageraldnaveen@gmail.com Sat Dec 12 00:29:59 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134641A1BEE for ; Sat, 12 Dec 2015 00:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYbvEPtPXVPH for ; Sat, 12 Dec 2015 00:29:58 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB031A1B8B for ; Sat, 12 Dec 2015 00:29:57 -0800 (PST) Received: by obc18 with SMTP id 18so98989820obc.2 for ; Sat, 12 Dec 2015 00:29:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sudLEz9wzKQXgnngpVUmTVr565vQNgxyejLF4eOcgog=; b=DZkVEtNJUOhv1ULYs3ZurMWlOrPIed26PAjTSCvXfYavJOluu17SdTdyqIxAXVNiWx kfBIF2HNdS+7hZieZEr9r7xn4vZUFKYivQ2NLg38Hc//EHq27OUgXjNtiAmSpuLLs9Za CCHHC4znw6B0FE7BeKY+upuYKQHzN5cBpWE/LafDxy0PshZ7jW9dPgwsQ5vNIDoek7G8 gb7zSR4SyLN0RII1iXCSuSlud3FoPlXhkawdehRiPqzXQGIKt9Y5qzBBs1gQ0ba8N5qn w1sAEqYkDdDhxIJk3LS5vx6NbRqiQFeHOBxVOCEy1a3qxm8G+RRgq0OeNpKES3KZHs/Y DbKw== MIME-Version: 1.0 X-Received: by 10.60.41.73 with SMTP id d9mr17478728oel.27.1449908997263; Sat, 12 Dec 2015 00:29:57 -0800 (PST) Received: by 10.182.130.81 with HTTP; Sat, 12 Dec 2015 00:29:57 -0800 (PST) Date: Sat, 12 Dec 2015 13:59:57 +0530 Message-ID: From: Gerald Naveen A To: ipfix@ietf.org Content-Type: multipart/alternative; boundary=089e013cba48bd1a040526af3e7f Archived-At: X-Mailman-Approved-At: Tue, 15 Dec 2015 04:23:03 -0800 Subject: [IPFIX] basicList clarification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 08:40:45 -0000 --089e013cba48bd1a040526af3e7f Content-Type: text/plain; charset=UTF-8 Hi all, It is my understanding from the RFCs that basicList type is an encoding for list of IPFIX Information Elements. To create the template much more strongly typed, we have defined a custom (enterprise) Information Element with a new ID (say X), which is defined as a basicList of specific items (eg., InterfaceName). My question to you all is: Is it mandatory that we have a separate information element called InterfaceName (say ID Y) and define X as a basicList of Y ? For our need, it is enough for us, that we define X as a basicList of string (as X is already strongly defined). But string is a type, not info element. We would like to retain X (instead of defining a template directly with a standard basicList). And we don't have any other need to define a new Information Element Y. I realize that the basicList encoding has a information-element ID of the item in payload -- is this mandatory? Or for a strongly typed item X, we could expect the IPFIX parser to be aware of contents (interface name) by contract? Pls let me know if my question is unclear. Thanks in advance. - Gerald Naveen --089e013cba48bd1a040526af3e7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

It is m= y understanding from the RFCs that basicList type is an encoding for list o= f IPFIX Information Elements.

To create the template much more= strongly typed, we have defined a custom (enterprise) Information Element = with a new ID (say X), which is defined as a basicList of specific items (e= g., InterfaceName).

My question to you all is: Is it mandatory= that we have a separate information element called InterfaceName (say ID Y= ) and define X as a basicList of Y ? For our need, it is enough for us, tha= t we define X as a basicList of string (as X is already strongly defined). = But string is a type, not info element.

We would like to retai= n X (instead of defining a template directly with a standard basicList). An= d we don't have any other need to define a new Information Element Y.
I realize that the basicList encoding has a information-element ID of= the item in payload -- is this mandatory? Or for a strongly typed item X, = we could expect the IPFIX parser to be aware of contents (interface name) b= y contract?

Pls let me know if my question is unclear.

Thanks in advance.
- Gerald Naveen
--089e013cba48bd1a040526af3e7f-- From nobody Tue Dec 15 05:14:27 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D3A1A8895 for ; Tue, 15 Dec 2015 05:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrHGk62JVVYN for ; Tue, 15 Dec 2015 05:14:24 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186991A8886 for ; Tue, 15 Dec 2015 05:14:24 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id n186so164360821wmn.1 for ; Tue, 15 Dec 2015 05:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=BoPpTh9Z53qlPTprXkJ9EkIO8WaDAOn2QKuXqXNIQHY=; b=Q0SzcZexKQ99NRRW6/cox6iVMQs17QLeAmryhtV9vcmrocnd3f7sb+eIgWOYW6GGhv 480xWJEgbAG7LSJr69Ic1Q1JDPmEeVZdFb2e6vzFLa8rNSwASI5U+da5fu1aO8Ebvw1+ 71wZM19GMeCcVXkUOijbQGqQy8/422drTp/dmqDOANYIqscNjCFOclexvMTcrqI4itCK F54onWCBRMsPO3dDl+wB3p9TsrhI+HMAXfo7AkcEHVQAkOfynX2ZAt+5+jX+kZprGmQ1 7RZtfBP5lQAoTrT6eY8l0USooXr+mnpshtIirteHfeHKaoG732gE+SWpOjt09ltFa1Ma iE3g== X-Received: by 10.28.49.65 with SMTP id x62mr4807073wmx.49.1450185262658; Tue, 15 Dec 2015 05:14:22 -0800 (PST) Received: from [172.27.212.109] (83-244-158-130.cust-83.exponential-e.net. [83.244.158.130]) by smtp.googlemail.com with ESMTPSA id q7sm1404949wjz.12.2015.12.15.05.14.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Dec 2015 05:14:21 -0800 (PST) Message-ID: <5670122C.9090806@gmail.com> Date: Tue, 15 Dec 2015 13:14:20 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Gerald Naveen A , ipfix@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040507070602010909070607" Archived-At: Subject: Re: [IPFIX] basicList clarification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 13:14:26 -0000 This is a multi-part message in MIME format. --------------040507070602010909070607 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Gerald, > Hi all, > > It is my understanding from the RFCs that basicList type is an > encoding for list of IPFIX Information Elements. Yes, where the list contains zero or more instances of a single IE. > To create the template much more strongly typed, we have defined a > custom (enterprise) Information Element with a new ID (say X), which > is defined as a basicList of specific items (eg., InterfaceName). > > My question to you all is: Is it mandatory that we have a separate > information element called InterfaceName (say ID Y) and define X as a > basicList of Y ? Yes, that's how the protocol is defined. > For our need, it is enough for us, that we define X as a basicList of > string (as X is already strongly defined). But string is a type, not > info element. > > We would like to retain X (instead of defining a template directly > with a standard basicList). And we don't have any other need to define > a new Information Element Y. Y defines the list elements which tells the Collector that the list contains strings, and it defines the semantics of those strings - eg whether they contain interface names, user names, a list of selectorNames, or a list of Application names. Then a basicList of Y tells the Collector that you're exporting zero or more of them. Perhaps you should define Y as a single instance of X (so Y is well defined), then redefine X as a basicList of Y. Or if you don't want/need to define both X and Y, then use the basicList IE #291 to export a basicList of (strongly defined) Y. > I realize that the basicList encoding has a information-element ID of > the item in payload -- is this mandatory? Yes. The encoding would not be interoperable without it. > Or for a strongly typed item X, we could expect the IPFIX parser to be > aware of contents (interface name) by contract? No. Every collector which implements RFC 6313 (IPFIX Structured Data) should be able to decode a basicList of Y. However, the mechanism which you propose requires the collector to have special knowledge of the internals of X, which is not scalable. In short, such an Exporter would not be interoperable with all Collectors. P. > Pls let me know if my question is unclear. > > Thanks in advance. > - Gerald Naveen The custom IE which you've defined must contain meta-data about the list such as an element count, element lengths, delimiters or separators. It creates a new way of encoding list information which the collector must also understand in addtion to the basicList encoding, which is not useful. In short, you should not create list type elements; instead, use the basicList mechanism. > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------040507070602010909070607 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Gerald,

Hi all,

It is my understanding from the RFCs that basicList type is an encoding for list of IPFIX Information Elements.

Yes, where the list contains zero or more instances of a single IE.


To create the template much more strongly typed, we have defined a custom (enterprise) Information Element with a new ID (say X), which is defined as a basicList of specific items (eg., InterfaceName).

My question to you all is: Is it mandatory that we have a separate information element called InterfaceName (say ID Y) and define X as a basicList of Y ?

Yes, that's how the protocol is defined.


For our need, it is enough for us, that we define X as a basicList of string (as X is already strongly defined). But string is a type, not info element.

We would like to retain X (instead of defining a template directly with a standard basicList). And we don't have any other need to define a new Information Element Y.

Y defines the list elements which tells the Collector that the list contains strings, and it defines the semantics of those strings - eg whether they contain interface names, user names, a list of selectorNames, or a list of Application names. Then a basicList of Y tells the Collector that you're exporting zero or more of them.

Perhaps you should define Y as a single instance of X (so Y is well defined), then redefine X as a basicList of Y. Or if you don't want/need to define both X and Y, then use the basicList IE #291 to export a basicList of (strongly defined) Y.


I realize that the basicList encoding has a information-element ID of the item in payload -- is this mandatory?

Yes. The encoding would not be interoperable without it.


Or for a strongly typed item X, we could expect the IPFIX parser to be aware of contents (interface name) by contract?

No. Every collector which implements RFC 6313 (IPFIX Structured Data) should be able to decode a basicList of Y. However, the mechanism which you propose requires the collector to have special knowledge of the internals of X, which is not scalable. In short, such an Exporter would not be interoperable with all Collectors.

P.


Pls let me know if my question is unclear.

Thanks in advance.
- Gerald Naveen


The custom IE which you've defined must contain meta-data about the list such as an element count, element lengths, delimiters or separators. It creates a new way of encoding list information which the collector must also understand in addtion to the basicList encoding, which is not useful. In short, you should not create list type elements; instead, use the basicList mechanism.




_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------040507070602010909070607-- From nobody Tue Dec 15 07:04:22 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39B11A8AB9 for ; Tue, 15 Dec 2015 07:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXi4CTsfb2Lq for ; Tue, 15 Dec 2015 07:04:18 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1BF91A8AAD for ; Tue, 15 Dec 2015 07:04:17 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id o62so1589638oif.3 for ; Tue, 15 Dec 2015 07:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dljP3/P7Hxixl4SA0EppY124k6DjimLIjAevCVSUiv0=; b=qxxdT7Pb0DYVbkCiQM/R0tef4VaWAy1ux+BAVW8pdi+R/f2L02lqfFY+Y5ydO596iN fQsd8nav26xJLJrI/ZLhyqu1FsU+k0Z7xFA+4H3UIUEPsRPMJfILyw7MiEzQ6/ht9K7M x2+4fWhqh07rHmeMO72Jdh0zqAXmGEaWBF+6gKZuBrPGUZw+AhWLvIyxmojeQQj6fXd2 KK8w+mY4USL0ROq1XZB8nq+g1QjxNFc9zk7fMXsJiZxaZlrIwAadCNkfe6AacRebzsLc iDo0DbSTtFdlNthcwhnz9nGg0hmNlMpkNaQdNnuBUvxRTZWrBcK39B3ub4Yh2LPzE3zr 8RXQ== MIME-Version: 1.0 X-Received: by 10.202.87.201 with SMTP id l192mr5494806oib.81.1450191857130; Tue, 15 Dec 2015 07:04:17 -0800 (PST) Received: by 10.182.130.81 with HTTP; Tue, 15 Dec 2015 07:04:17 -0800 (PST) In-Reply-To: <5670122C.9090806@gmail.com> References: <5670122C.9090806@gmail.com> Date: Tue, 15 Dec 2015 20:34:17 +0530 Message-ID: From: Gerald Naveen A To: Paul Aitken Content-Type: multipart/alternative; boundary=001a113de314804b510526f11a87 Archived-At: Cc: ipfix@ietf.org Subject: Re: [IPFIX] basicList clarification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 15:04:21 -0000 --001a113de314804b510526f11a87 Content-Type: text/plain; charset=UTF-8 Hi Paul, Thanks for the responses. It clarifies for most part; while I would also like to clarify few things on my question. (tagged [Gerald] inline) So it appears we would need to define Y as IE and mark X as basicList of Y. Thanks again On Tue, Dec 15, 2015 at 6:44 PM, Paul Aitken wrote: > Gerald, > > Hi all, > > It is my understanding from the RFCs that basicList type is an encoding > for list of IPFIX Information Elements. > > > Yes, where the list contains zero or more instances of a single IE. > > > To create the template much more strongly typed, we have defined a custom > (enterprise) Information Element with a new ID (say X), which is defined as > a basicList of specific items (eg., InterfaceName). > > My question to you all is: Is it mandatory that we have a separate > information element called InterfaceName (say ID Y) and define X as a > basicList of Y ? > > > Yes, that's how the protocol is defined. > > > For our need, it is enough for us, that we define X as a basicList of > string (as X is already strongly defined). But string is a type, not info > element. > > We would like to retain X (instead of defining a template directly with a > standard basicList). And we don't have any other need to define a new > Information Element Y. > > > Y defines the list elements which tells the Collector that the list > contains strings, and it defines the semantics of those strings - eg > whether they contain interface names, user names, a list of selectorNames, > or a list of Application names. Then a basicList of Y tells the Collector > that you're exporting zero or more of them. > [Gerald] This is definitely a choice. However, as I mentioned, this makes the template weakly typed (ie., the element is just #291 basicList). We would like to enforce stronger types at the template itself (this was the motive behind defining X) > > Perhaps you should define Y as a single instance of X (so Y is well > defined), then redefine X as a basicList of Y. Or if you don't want/need to > define both X and Y, then use the basicList IE #291 to export a basicList > of (strongly defined) Y. > [Gerald] Yes, this is also a choice; but we don't need Y for any other reason except to fit into the basicList detail. So wanted to know if that can be avoided. I got my answer: No (if strongly typed templates). > > I realize that the basicList encoding has a information-element ID of the > item in payload -- is this mandatory? > > > Yes. The encoding would not be interoperable without it. > > > Or for a strongly typed item X, we could expect the IPFIX parser to be > aware of contents (interface name) by contract? > > > No. Every collector which implements RFC 6313 (IPFIX Structured Data) > should be able to decode a basicList of Y. However, the mechanism which you > propose requires the collector to have special knowledge of the internals > of X, which is not scalable. In short, such an Exporter would not be > interoperable with all Collectors. > [Gerald] X is not a different encoding. X is a basicList (sort of more strongly typed. ie., X is a basicList of Y). So the encoding is just the same as #291 standard basicList. But when the template declares a element as X, it is clearly typed even without having to look into the data (or it also doesn't let the exporter send X of Z on the same template). > P. > > > Pls let me know if my question is unclear. > > Thanks in advance. > - Gerald Naveen > > > > The custom IE which you've defined must contain meta-data about the list > such as an element count, element lengths, delimiters or separators. It > creates a new way of encoding list information which the collector must > also understand in addtion to the basicList encoding, which is not useful. > In short, you should not create list type elements; instead, use the > basicList mechanism. > [Gerald] Agree. We aren't trying to redefine basicList encoding for sure. > > > > _______________________________________________ > IPFIX mailing listIPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix > > > --001a113de314804b510526f11a87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

Thanks for the responses. = It clarifies for most part; while I would also like to clarify few things o= n my question. (tagged [Gerald] inline)

So it appears we would= need to define Y as IE and mark X as basicList of Y.

Thanks again

On Tue, Dec 15, 201= 5 at 6:44 PM, Paul Aitken <pjaitken@gmail.com> wrote:
=20 =20 =20
Gerald,

Hi all,

It is my understanding from the RFCs that basicList type is an encoding for list of IPFIX Information Elements.

 Yes, where the list contains zero or more instances of a single IE.


To create the template much more strongly typed, we have defined a custom (enterprise) Information Element with a new ID (say X), which is defined as a basicList of specific items (eg., InterfaceName).

My question to you all is: Is it mandatory that we have a separate information element called InterfaceName (say ID Y) and define X as a basicList of Y ?

Yes, that's how the protocol is defined.


For our need, it is enough for us, that we define X as a basicList of string (as X is already strongly defined). But string is a type, not info element.

We would like to retain X (instead of defining a template directly with a standard basicList). And we don't have any other need to define a new Information Element Y.

 Y defines the list elements which tells the Collector that the list contains strings, and it defines the semantics of those strings - eg whether they contain interface names, user names, a list of selectorNames, or a list of Application names. Then a basicList of Y tells the Collector that you're exporting zero or more of them.
=
[Gerald] This is definitely a choice. However, as I= mentioned, this makes the template weakly typed (ie., the element is just = #291 basicList). We would like to enforce stronger types at the template it= self (this was the motive behind defining X)

Perhaps you should define Y as a single instance of X (so Y is well defined), then redefine X as a basicList of Y. Or if you don't want/need to define both X and Y, then use the basicList IE #291 to export a basicList of (strongly defined) Y.
=
[Gerald] Yes, this is also a choice; but we don'= ;t need Y for any other reason except to fit into the basicList detail. So = wanted to know if that can be avoided. I got my answer: No (if strongly typ= ed templates).

I realize that the basicList encoding has a information-element ID of the item in payload -- is this mandatory?

 Yes. The encoding would not be interoperable without it.


Or for a strongly typed item X, we could expect the IPFIX parser to be aware of contents (interface name) by contract?

 No. Every collector which implements RFC 6313 (IPFIX Structured Data) should be able to decode a basicList of Y. However, the mechanism which you propose requires the collector to have special knowledge of the internals of X, which is not scalable. In short, such an Exporter would not be interoperable with all Collectors.
[Gerald] X is not a different encoding. X is a basicLi= st (sort of more strongly typed. ie., X is a basicList of Y). So the encodi= ng is just the same as #291 standard basicList. But when the template decla= res a element as X, it is clearly typed even without having to look into th= e data (or it also doesn't let the exporter send X of Z on the same tem= plate).
=C2=A0
P.


Pls let me know if my question is unclear.

Thanks in advance.
- Gerald Naveen


 The custom IE which you've defined must contain meta-data about the list such as an element count, element lengths, delimiters or separators. It creates a new way of encoding list information which the collector must also understand in addtion to the basicList encoding, which is not useful. In short, you should not create list type elements; instead, use the basicList mechanism.
[Gerald] Agree. We aren't trying to redefine basicList encodin= g for sure. 



_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/ipfix


--001a113de314804b510526f11a87-- From nobody Tue Dec 15 15:25:03 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FAE1B2C7B for ; Tue, 15 Dec 2015 15:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJnweaaFSJ-X for ; Tue, 15 Dec 2015 15:24:56 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D531B2C8D for ; Tue, 15 Dec 2015 15:24:56 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id l126so15796153wml.0 for ; Tue, 15 Dec 2015 15:24:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=N1V7cETpYKgK6JpEF/f7MTX+kIhd2gvm9L/HwbZWObo=; b=y8l/g0WPSVVPAuVcgxWNXQqa5LKinl9uUJD9KYf1COdlyHesCgOFdvYAMFW8vLDgKE IKFsBFwBosAepTCfcnCElbyZp+XywwCQOBqz0jT1P3ATUgJF9qkooemB5K+IUKJkkABr GxIldublei0ItkLdMKcebrgWNvLVv9rzzgkThmDiEDIjEyMovVBE4TBQLbGODjP6giZR jVi25mwXqmYFhe0UBBFVEue6sc/I6TcTKj05nhzF3hubVbHZH8N0Cxyx8of91PBLaKpP sta2QzlEn5noMCF/DCkJolJFw06cwKIGkYPHLz8pePP3F3xJ2LUCluWqsfCfT6tGit61 WSlA== X-Received: by 10.28.68.213 with SMTP id r204mr7578231wma.35.1450221894815; Tue, 15 Dec 2015 15:24:54 -0800 (PST) Received: from [192.168.1.73] (host86-169-97-185.range86-169.btcentralplus.com. [86.169.97.185]) by smtp.googlemail.com with ESMTPSA id xs9sm3387876wjc.43.2015.12.15.15.24.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Dec 2015 15:24:53 -0800 (PST) To: Gerald Naveen A References: <5670122C.9090806@gmail.com> From: Paul Aitken Message-ID: <5670A144.10708@gmail.com> Date: Tue, 15 Dec 2015 23:24:52 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010306040702000802010805" Archived-At: Cc: ipfix@ietf.org Subject: Re: [IPFIX] basicList clarification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 23:25:00 -0000 This is a multi-part message in MIME format. --------------010306040702000802010805 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Gerald, > Hi Paul, > > Thanks for the responses. It clarifies for most part; while I would > also like to clarify few things on my question. (tagged [Gerald] inline) See [PJ] inline... > So it appears we would need to define Y as IE and mark X as basicList > of Y. What you're proposing is possible if there's a good reason. However we want to avoid unnecessary duplication of existing IEs into new "list of" IEs as much as possible, so you should only create X if there's a strong justification (eg it models an existing object). > Thanks again > > On Tue, Dec 15, 2015 at 6:44 PM, Paul Aitken > wrote: > > Gerald, > >> Hi all, >> >> It is my understanding from the RFCs that basicList type is an >> encoding for list of IPFIX Information Elements. > > Yes, where the list contains zero or more instances of a single IE. > > >> To create the template much more strongly typed, we have defined >> a custom (enterprise) Information Element with a new ID (say X), >> which is defined as a basicList of specific items (eg., >> InterfaceName). >> >> My question to you all is: Is it mandatory that we have a >> separate information element called InterfaceName (say ID Y) and >> define X as a basicList of Y ? > > Yes, that's how the protocol is defined. > > >> For our need, it is enough for us, that we define X as a >> basicList of string (as X is already strongly defined). But >> string is a type, not info element. >> >> We would like to retain X (instead of defining a template >> directly with a standard basicList). And we don't have any other >> need to define a new Information Element Y. > > Y defines the list elements which tells the Collector that the > list contains strings, and it defines the semantics of those > strings - eg whether they contain interface names, user names, a > list of selectorNames, or a list of Application names. Then a > basicList of Y tells the Collector that you're exporting zero or > more of them. > > [Gerald] This is definitely a choice. However, as I mentioned, this > makes the template weakly typed (ie., the element is just #291 > basicList). We would like to enforce stronger types at the template > itself (this was the motive behind defining X) [PJ] This was an objection from the Collector side when we were writing the IPFIX Structured Data draft, because the collector can no longer tell what information it's going to receive ahead of time (just "a list"); it has to check each Data Record to know what information the list contains. On the other hand, since the basicList is essentially a wrapper around any other IE, it's not necessary to create new strongly-defined list IEs for each of the existing (and potentially all future) IEs. > Perhaps you should define Y as a single instance of X (so Y is > well defined), then redefine X as a basicList of Y. Or if you > don't want/need to define both X and Y, then use the basicList IE > #291 to export a basicList of (strongly defined) Y. > > [Gerald] Yes, this is also a choice; but we don't need Y for any other > reason except to fit into the basicList detail. So wanted to know if > that can be avoided. I got my answer: No (if strongly typed templates). [PJ] Strongly typed templates would require a new "list of" IE for every existing (and future) IE that was to become a list, which is incredibly wasteful. >> I realize that the basicList encoding has a information-element >> ID of the item in payload -- is this mandatory? > > Yes. The encoding would not be interoperable without it. > [PJ] Here I understood the question to be whether the IE ID field was required in the basicList encoding - ie, it seemed that you were proposing a new encoding where, since X is already strong defined as a basicList of Y, there's no need to include Y in the export. >> Or for a strongly typed item X, we could expect the IPFIX parser >> to be aware of contents (interface name) by contract? > > No. Every collector which implements RFC 6313 (IPFIX Structured > Data) should be able to decode a basicList of Y. However, the > mechanism which you propose requires the collector to have special > knowledge of the internals of X, which is not scalable. In short, > such an Exporter would not be interoperable with all Collectors. > > [Gerald] X is not a different encoding. X is a basicList (sort of more > strongly typed. ie., X is a basicList of Y). So the encoding is just > the same as #291 standard basicList. But when the template declares a > element as X, it is clearly typed even without having to look into the > data (or it also doesn't let the exporter send X of Z on the same > template). [PJ] What you're proposing is possible and may be useful in some circumstances. For example, for the MIB export draft, we've defined new IEs (#443, #444) which are subTemplateLists, in order to give strong typing information because the IE contains a row from a table. (See https://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-10 and http://www.iana.org/assignments/ipfix/ipfix.xhtml) P. > >> Pls let me know if my question is unclear. >> >> Thanks in advance. >> - Gerald Naveen > > > The custom IE which you've defined must contain meta-data about > the list such as an element count, element lengths, delimiters or > separators. It creates a new way of encoding list information > which the collector must also understand in addtion to the > basicList encoding, which is not useful. In short, you should not > create list type elements; instead, use the basicList mechanism. > > [Gerald] Agree. We aren't trying to redefine basicList encoding for sure. > > >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > --------------010306040702000802010805 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Gerald,

Hi Paul,

Thanks for the responses. It clarifies for most part; while I would also like to clarify few things on my question. (tagged [Gerald] inline)

See [PJ] inline...


So it appears we would need to define Y as IE and mark X as basicList of Y.

What you're proposing is possible if there's a good reason. However we want to avoid unnecessary duplication of existing IEs into new "list of" IEs as much as possible, so you should only create X if there's a strong justification (eg it models an existing object).


Thanks again

On Tue, Dec 15, 2015 at 6:44 PM, Paul Aitken <pjaitken@gmail.com> wrote:
Gerald,

Hi all,

It is my understanding from the RFCs that basicList type is an encoding for list of IPFIX Information Elements.

 Yes, where the list contains zero or more instances of a single IE.


To create the template much more strongly typed, we have defined a custom (enterprise) Information Element with a new ID (say X), which is defined as a basicList of specific items (eg., InterfaceName).

My question to you all is: Is it mandatory that we have a separate information element called InterfaceName (say ID Y) and define X as a basicList of Y ?

 Yes, that's how the protocol is defined.


For our need, it is enough for us, that we define X as a basicList of string (as X is already strongly defined). But string is a type, not info element.

We would like to retain X (instead of defining a template directly with a standard basicList). And we don't have any other need to define a new Information Element Y.

 Y defines the list elements which tells the Collector that the list contains strings, and it defines the semantics of those strings - eg whether they contain interface names, user names, a list of selectorNames, or a list of Application names. Then a basicList of Y tells the Collector that you're exporting zero or more of them.
[Gerald] This is definitely a choice. However, as I mentioned, this makes the template weakly typed (ie., the element is just #291 basicList). We would like to enforce stronger types at the template itself (this was the motive behind defining X)

[PJ] This was an objection from the Collector side when we were writing the IPFIX Structured Data draft, because the collector can no longer tell what information it's going to receive ahead of time (just "a list"); it has to check each Data Record to know what information the list contains. On the other hand, since the basicList is essentially a wrapper around any other IE, it's not necessary to create new strongly-defined list IEs for each of the existing (and potentially all future) IEs.


Perhaps you should define Y as a single instance of X (so Y is well defined), then redefine X as a basicList of Y. Or if you don't want/need to define both X and Y, then use the basicList IE #291 to export a basicList of (strongly defined) Y.
[Gerald] Yes, this is also a choice; but we don't need Y for any other reason except to fit into the basicList detail. So wanted to know if that can be avoided. I got my answer: No (if strongly typed templates).

[PJ] Strongly typed templates would require a new "list of" IE for every existing (and future) IE that was to become a list, which is incredibly wasteful.


I realize that the basicList encoding has a information-element ID of the item in payload -- is this mandatory?

 Yes. The encoding would not be interoperable without it.

[PJ] Here I understood the question to be whether the IE ID field was required in the basicList encoding - ie, it seemed that you were proposing a new encoding where, since X is already strong defined as a basicList of Y, there's no need to include Y in the export.


Or for a strongly typed item X, we could expect the IPFIX parser to be aware of contents (interface name) by contract?

 No. Every collector which implements RFC 6313 (IPFIX Structured Data) should be able to decode a basicList of Y. However, the mechanism which you propose requires the collector to have special knowledge of the internals of X, which is not scalable. In short, such an Exporter would not be interoperable with all Collectors.
[Gerald] X is not a different encoding. X is a basicList (sort of more strongly typed. ie., X is a basicList of Y). So the encoding is just the same as #291 standard basicList. But when the template declares a element as X, it is clearly typed even without having to look into the data (or it also doesn't let the exporter send X of Z on the same template).

[PJ] What you're proposing is possible and may be useful in some circumstances. For example, for the MIB export draft, we've defined new IEs (#443, #444) which are subTemplateLists, in order to give strong typing information because the IE contains a row from a table.

(See https://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-10 and http://www.iana.org/assignments/ipfix/ipfix.xhtml)

P.


Pls let me know if my question is unclear.

Thanks in advance.
- Gerald Naveen


 The custom IE which you've defined must contain meta-data about the list such as an element count, element lengths, delimiters or separators. It creates a new way of encoding list information which the collector must also understand in addtion to the basicList encoding, which is not useful. In short, you should not create list type elements; instead, use the basicList mechanism.
[Gerald] Agree. We aren't trying to redefine basicList encoding for sure. 



_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix



--------------010306040702000802010805-- From nobody Wed Dec 16 14:41:11 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422051A9059 for ; Wed, 16 Dec 2015 14:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyF7JBVrjPke for ; Wed, 16 Dec 2015 14:41:07 -0800 (PST) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929A21A9056 for ; Wed, 16 Dec 2015 14:41:06 -0800 (PST) Received: from PLXRDC01.plxr.local ([::1]) by PLXRDC01.plxr.local ([::1]) with mapi id 14.03.0266.001; Wed, 16 Dec 2015 17:41:05 -0500 From: Andrew Feren To: Paul Aitken , Gerald Naveen A Thread-Topic: [IPFIX] basicList clarification Thread-Index: AQHRNzNbwHz1ucln+0aHb7haeiYjWZ7MWm8AgAAeuICAAIvcAIABIjeb Date: Wed, 16 Dec 2015 22:41:05 +0000 Message-ID: <8E7542283B89BB4DB672EB49CEE5AAB7595C1F74@PLXRDC01.plxr.local> References: <5670122C.9090806@gmail.com> , <5670A144.10708@gmail.com> In-Reply-To: <5670A144.10708@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.14.173] Content-Type: multipart/alternative; boundary="_000_8E7542283B89BB4DB672EB49CEE5AAB7595C1F74PLXRDC01plxrloc_" MIME-Version: 1.0 Archived-At: Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] basicList clarification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 22:41:10 -0000 --_000_8E7542283B89BB4DB672EB49CEE5AAB7595C1F74PLXRDC01plxrloc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paul and Gerald, I have slightly mixed feelings on this, but my current bias is towards not = requiring a second IE. I plan to look at this a bit more closely, but here= are a few thoughts. see [ACF] inline... ________________________________ From: IPFIX [ipfix-bounces@ietf.org] on behalf of Paul Aitken [pjaitken@gma= il.com] Sent: Tuesday, December 15, 2015 6:24 PM To: Gerald Naveen A Cc: ipfix@ietf.org Subject: Re: [IPFIX] basicList clarification Gerald, Hi Paul, Thanks for the responses. It clarifies for most part; while I would also li= ke to clarify few things on my question. (tagged [Gerald] inline) See [PJ] inline... So it appears we would need to define Y as IE and mark X as basicList of Y. What you're proposing is possible if there's a good reason. However we want= to avoid unnecessary duplication of existing IEs into new "list of" IEs as= much as possible, so you should only create X if there's a strong justific= ation (eg it models an existing object). Thanks again On Tue, Dec 15, 2015 at 6:44 PM, Paul Aitken > wrote: Gerald, Hi all, It is my understanding from the RFCs that basicList type is an encoding for= list of IPFIX Information Elements. Yes, where the list contains zero or more instances of a single IE. To create the template much more strongly typed, we have defined a custom (= enterprise) Information Element with a new ID (say X), which is defined as = a basicList of specific items (eg., InterfaceName). My question to you all is: Is it mandatory that we have a separate informat= ion element called InterfaceName (say ID Y) and define X as a basicList of = Y ? Yes, that's how the protocol is defined. For our need, it is enough for us, that we define X as a basicList of strin= g (as X is already strongly defined). But string is a type, not info elemen= t. We would like to retain X (instead of defining a template directly with a s= tandard basicList). And we don't have any other need to define a new Inform= ation Element Y. Y defines the list elements which tells the Collector that the list contain= s strings, and it defines the semantics of those strings - eg whether they = contain interface names, user names, a list of selectorNames, or a list of = Application names. Then a basicList of Y tells the Collector that you're ex= porting zero or more of them. [Gerald] This is definitely a choice. However, as I mentioned, this makes t= he template weakly typed (ie., the element is just #291 basicList). We woul= d like to enforce stronger types at the template itself (this was the motiv= e behind defining X) [PJ] This was an objection from the Collector side when we were writing the= IPFIX Structured Data draft, because the collector can no longer tell what= information it's going to receive ahead of time (just "a list"); it has to= check each Data Record to know what information the list contains. On the = other hand, since the basicList is essentially a wrapper around any other I= E, it's not necessary to create new strongly-defined list IEs for each of t= he existing (and potentially all future) IEs. [ACF] From the collector side I still prefer strongly typed templates. The= re may be some middle ground possible like an option template that reports = the range of expected values for a template with a basicList (or other gene= ric structure). I started a draft on this a while back, but it got back bu= rnered. Might be time to dust it off again. Perhaps you should define Y as a single instance of X (so Y is well defined= ), then redefine X as a basicList of Y. Or if you don't want/need to define= both X and Y, then use the basicList IE #291 to export a basicList of (str= ongly defined) Y. [Gerald] Yes, this is also a choice; but we don't need Y for any other reas= on except to fit into the basicList detail. So wanted to know if that can b= e avoided. I got my answer: No (if strongly typed templates). [PJ] Strongly typed templates would require a new "list of" IE for every ex= isting (and future) IE that was to become a list, which is incredibly waste= ful. [ACF] I think there can be different considerations for lists in standard = space and list IEs with a PEN. I realize that the basicList encoding has a information-element ID of the i= tem in payload -- is this mandatory? Yes. The encoding would not be interoperable without it. [PJ] Here I understood the question to be whether the IE ID field was requi= red in the basicList encoding - ie, it seemed that you were proposing a new= encoding where, since X is already strong defined as a basicList of Y, the= re's no need to include Y in the export. [ACF] I think the quibble here is whether Y needs an IE if it is only used = as a list. If an IE already exists you can use it. Requiring Y becomes wa= steful (to borrow your earlier word) in a different way. Assume there are = many lists of A, B, C, D and X. There isn't a need to ever export A, B, C,= D or X as any thing other than a list. The second IE isn't really needed. Or for a strongly typed item X, we could expect the IPFIX parser to be awar= e of contents (interface name) by contract? No. Every collector which implements RFC 6313 (IPFIX Structured Data) shoul= d be able to decode a basicList of Y. However, the mechanism which you prop= ose requires the collector to have special knowledge of the internals of X,= which is not scalable. In short, such an Exporter would not be interoperab= le with all Collectors. [Gerald] X is not a different encoding. X is a basicList (sort of more stro= ngly typed. ie., X is a basicList of Y). So the encoding is just the same a= s #291 standard basicList. But when the template declares a element as X, i= t is clearly typed even without having to look into the data (or it also do= esn't let the exporter send X of Z on the same template). [PJ] What you're proposing is possible and may be useful in some circumstan= ces. For example, for the MIB export draft, we've defined new IEs (#443, #4= 44) which are subTemplateLists, in order to give strong typing information = because the IE contains a row from a table. (See https://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-10 an= d http://www.iana.org/assignments/ipfix/ipfix.xhtml) [ACF] A different compromise might be some generic IEs, for exampe, a strin= g IE. Then you could have a list of aNames or bNames. Each of which put t= he (currently non existent) string IE ID as the ID in the strongly typed li= st. Of course that opens the door to generic basicList of generic strings.= Having a single list encoding is nice, but leaving out the ID probably is= n't any worse than fixed length vs var length strings. I reserve the right to change my opinions as I reread 6313, -Andrew P. Pls let me know if my question is unclear. Thanks in advance. - Gerald Naveen The custom IE which you've defined must contain meta-data about the list su= ch as an element count, element lengths, delimiters or separators. It creat= es a new way of encoding list information which the collector must also und= erstand in addtion to the basicList encoding, which is not useful. In short= , you should not create list type elements; instead, use the basicList mech= anism. [Gerald] Agree. We aren't trying to redefine basicList encoding for sure. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --_000_8E7542283B89BB4DB672EB49CEE5AAB7595C1F74PLXRDC01plxrloc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Paul and Gerald,

I have slightly mixed feelings on this, but my current bias is towards not = requiring a second IE.  I plan to look at this a bit more closely, but= here are a few thoughts.

see [ACF] inline...


From: IPFIX [ipfix-bounces@ietf.org] on= behalf of Paul Aitken [pjaitken@gmail.com]
Sent: Tuesday, December 15, 2015 6:24 PM
To: Gerald Naveen A
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] basicList clarification

Gerald,

Hi Paul,

Thanks for the responses. It clarifies for most part; while I would also li= ke to clarify few things on my question. (tagged [Gerald] inline)

See [PJ] inline...


So it appears we would need to define Y as IE and mark X a= s basicList of Y.

What you're proposing is possible if there's a good reason. However we want= to avoid unnecessary duplication of existing IEs into new "list of&qu= ot; IEs as much as possible, so you should only create X if there's a stron= g justification (eg it models an existing object).


Thanks again

On Tue, Dec 15, 2015 at 6:44 PM, Paul Aitken <pjaitken@gmail.= com> wrote:
Gerald,

Hi all,

It is my understanding from the RFCs that basicList type is an encoding for= list of IPFIX Information Elements.

Yes, where the list contains zero or more instances of a single IE.<= span class=3D"">


To create the template much more strongly typed, we have defined a cus= tom (enterprise) Information Element with a new ID (say X), which is define= d as a basicList of specific items (eg., InterfaceName).

My question to you all is: Is it mandatory that we have a separate informat= ion element called InterfaceName (say ID Y) and define X as a basicList of = Y ?

Yes, that's how the protocol is defined.


For our need, it is enough for us, that we define X as a basicList of = string (as X is already strongly defined). But string is a type, not info e= lement.

We would like to retain X (instead of defining a template directly with a s= tandard basicList). And we don't have any other need to define a new Inform= ation Element Y.

Y defines the list elements which tells the Collector that the list = contains strings, and it defines the semantics of those strings - eg whethe= r they contain interface names, user names, a list of selectorNames, or a l= ist of Application names. Then a basicList of Y tells the Collector that you're exporting zero or more of t= hem.
[Gerald] This is definitely a choice. However, as I mentioned, this ma= kes the template weakly typed (ie., the element is just #291 basicList). We= would like to enforce stronger types at the template itself (this was the = motive behind defining X)

[PJ] This was an objection from the Collector side when we were writing the= IPFIX Structured Data draft, because the collector can no longer tell what= information it's going to receive ahead of time (just "a list");= it has to check each Data Record to know what information the list contains. On the other hand, since the basicList= is essentially a wrapper around any other IE, it's not necessary to create= new strongly-defined list IEs for each of the existing (and potentially al= l future) IEs.

[ACF] From the collector side I still prefer strongly typed templates. = ; There may be some middle ground possible like an option template that rep= orts the range of expected values for a template with a basicList (or other= generic structure).  I started a draft on this a while back, but it got back burnered.   Might be time = to dust it off again.


Perhaps you should define Y as a single instance o= f X (so Y is well defined), then redefine X as a basicList of Y. Or if you = don't want/need to define both X and Y, then use the basicList IE #291 to e= xport a basicList of (strongly defined) Y.
[Gerald] Yes, this is also a choice; but we don't need Y for any other= reason except to fit into the basicList detail. So wanted to know if that = can be avoided. I got my answer: No (if strongly typed templates).

[PJ] Strongly typed templates would require a new "list of" IE fo= r every existing (and future) IE that was to become a list, which is incred= ibly wasteful.

[ACF]  I think there can be different considerations for lists in stan= dard space and list IEs with a PEN.

I realize that the basicList encoding has a information-element ID of = the item in payload -- is this mandatory?

Yes. The encoding would not be interoperable without it.

[PJ] Here I understood the question to be whether the IE ID field was requi= red in the basicList encoding - ie, it seemed that you were proposing a new= encoding where, since X is already strong defined as a basicList of Y, the= re's no need to include Y in the export.

[ACF] I think the quibble here is whether Y needs an IE if it is only used = as a list.  If an IE already exists you can use it.  Requiring Y = becomes wasteful (to borrow your earlier word) in a different way.  As= sume there are many lists of A, B, C, D and X.  There isn't a need to ever export A, B, C, D or X as any thing other than = a list.  The second IE isn't really needed.

Or for a strongly typed item X, we could expect the IPFIX parser to be= aware of contents (interface name) by contract?

No. Every collector which implements RFC 6313 (IPFIX Structured Data= ) should be able to decode a basicList of Y. However, the mechanism which y= ou propose requires the collector to have special knowledge of the internal= s of X, which is not scalable. In short, such an Exporter would not be interoperable with all Collectors.
[Gerald] X is not a different encoding. X is a basicList (sort of more= strongly typed. ie., X is a basicList of Y). So the encoding is just the s= ame as #291 standard basicList. But when the template declares a element as= X, it is clearly typed even without having to look into the data (or it also doesn't let the exporter send X o= f Z on the same template).

[PJ] What you're proposing is possible and may be useful in some circumstan= ces. For example, for the MIB export draft, we've defined new IEs (#443, #4= 44) which are subTemplateLists, in order to give strong typing information = because the IE contains a row from a table.

(See https://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-10 and= http://www.iana.org/assignments/ipfix/ipfix.xhtml)

[ACF] A different compromise might be some generic IEs, for exampe, a strin= g IE.  Then you could have a list of aNames or bNames.  Each of w= hich put the (currently non existent) string IE ID as the ID in the strongl= y typed list.  Of course that opens the door to generic basicList of generic strings.  Having a single list encodi= ng is nice, but leaving out the ID probably isn't any worse than fixed leng= th vs var length strings.

I reserve the right to change my opinions as I reread 6313,
-Andrew

P.


Pls let me know if my question is unclear.

Thanks in advance.
- Gerald Naveen


The custom IE which you've defined must contain meta-data about the = list such as an element count, element lengths, delimiters or separators. I= t creates a new way of encoding list information which the collector must a= lso understand in addtion to the basicList encoding, which is not useful. In short, you should not create l= ist type elements; instead, use the basicList mechanism.
[Gerald] Agree. We aren't trying to redefine basicList encoding for su= re. 



_______________________________________________=0A=
IPFIX mailing list=0A=
IPFIX@ietf.org=0A=
h=
ttps://www.ietf.org/mailman/listinfo/ipfix=0A=



--_000_8E7542283B89BB4DB672EB49CEE5AAB7595C1F74PLXRDC01plxrloc_--