Subject: [sacm] Questions on the syntax for IM

From: "Jim Schaad" <[email-masked]>
Date: Sat, 19 Mar 2016 17:45:32 -0700

1.  Is the order of elements prescriptive or are the elements expressible in
any order?

2.  Is it intentional that the syntax is identical between Attributes and
Objects?  Is there supposed to be a way to distinguish between the two of
them?

3.  Once defined, I assume that an Object can be used in the dataType field
of an object or an attribute.  This is not true for an attribute.  Is this
correct?

4.  These sentences in section 3.2 do not make sense to me.  What did you
mean to say?  

Objects are complex Information Elements that can be created using one of
the following IPFIX constructs that are defined in Section 3.1 of [RFC7012].
[RFC7013] that can be used to model objects.

Jim

---

From: "Haynes, Dan" <[email-masked]>
Date: Mon, 21 Mar 2016 19:01:12 +0000

Hi Jim,

Good questions!

1. They can be expressed in any order unless the "ordered" dataTypeSemantic is used.  See Section 11.4.6 of RFC6313 for more information.  I think this will give data model designers the most flexibility too, but, I would love to hear others thoughts on it.

2. Yes, I kept the syntax identical with the exception of the respective description properties asking for additional information like a high-level diagram.  I thought having a single syntax would make life easier. The way I was thinking to distinguish between the two is that Attributes use simple data types (string, float, etc.) whereas Objects use structured data types (basicList, subTemplateList, and subTemplateMultiList). Please let me know if it doesn't make things easier. Also, if we need something more concrete, one possibility would be to add a new property to the syntax that says whether the Information Element is an Attribute or Object.

3. I was thinking Attributes would always use one of the simple data types (string, float, etc.) and Objects would always use one of the structured data types (basicList, subTemplateList, etc.) both of which could be extended over time as needed. However, I wasn't really thinking you would use an Object as a data type for defining new Attributes and Objects. Can you give an example of when you might want to do this? On a related note, I should also add that Objects can be composed of other Attributes and Objects via the structured data types (basicList, subTemplateList, etc.) and a high-level diagram. The SoftwareVersion, SoftwareInstance, and NetworkInterface Information Elements are examples of this although you probably already saw them :).  

4. Sorry about that.  I should have removed that second sentence.  It should read: "Objects are complex Information Elements that can be created using one of the following IPFIX constructs that are defined in Section 3.1 of [RFC7012].".  With that said, in the future, we may want to reference out to RFC7013 for best practices on creating new Information Elements.

Hope this helps!

Thanks,

Danny

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Saturday, March 19, 2016 8:46 PM
To: [email-masked]
Subject: [sacm] Questions on the syntax for IM

1.  Is the order of elements prescriptive or are the elements expressible in any order?

2.  Is it intentional that the syntax is identical between Attributes and Objects?  Is there supposed to be a way to distinguish between the two of them?

3.  Once defined, I assume that an Object can be used in the dataType field of an object or an attribute.  This is not true for an attribute.  Is this correct?

4.  These sentences in section 3.2 do not make sense to me.  What did you mean to say?  

Objects are complex Information Elements that can be created using one of the following IPFIX constructs that are defined in Section 3.1 of [RFC7012].
[RFC7013] that can be used to model objects.

Jim

_______________________________________________
sacm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sacm

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 21 Mar 2016 14:29:02 -0700

> From: Haynes, Dan [mailto:[email-masked]]
> Sent: Monday, March 21, 2016 12:01 PM
> To: Jim Schaad <[email-masked]>; [email-masked]
> Subject: RE: [sacm] Questions on the syntax for IM
> 
> Hi Jim,
> 
> Good questions!
> 
> 1. They can be expressed in any order unless the "ordered"
dataTypeSemantic is
> used.  See Section 11.4.6 of RFC6313 for more information.  I think this
will give
> data model designers the most flexibility too, but, I would love to hear
others
> thoughts on it.

My mistake I was not clear on what I was asking.

Are the order of the elements of the IPFIX definition ordered?  That is does
the elementID need to come first.

> 
> 2. Yes, I kept the syntax identical with the exception of the respective
> description properties asking for additional information like a high-level
> diagram.  I thought having a single syntax would make life easier. The way
I was
> thinking to distinguish between the two is that Attributes use simple data
types
> (string, float, etc.) whereas Objects use structured data types
(basicList,
> subTemplateList, and subTemplateMultiList). Please let me know if it
doesn't
> make things easier. Also, if we need something more concrete, one
possibility
> would be to add a new property to the syntax that says whether the
Information
> Element is an Attribute or Object.

Having a distinction of some type between them will be useful if we change
our mind about allowing complex types (as opposed to objects).

> 
> 3. I was thinking Attributes would always use one of the simple data types
> (string, float, etc.) and Objects would always use one of the structured
data
> types (basicList, subTemplateList, etc.) both of which could be extended
over
> time as needed. However, I wasn't really thinking you would use an Object
as a
> data type for defining new Attributes and Objects. Can you give an example
of
> when you might want to do this? On a related note, I should also add that
> Objects can be composed of other Attributes and Objects via the structured
data
> types (basicList, subTemplateList, etc.) and a high-level diagram. The
> SoftwareVersion, SoftwareInstance, and NetworkInterface Information
> Elements are examples of this although you probably already saw them :).

In part we are looking at how semantics are defined.

I define an object which is an IPAddress.  This is would be a list of
IPAddressElement.  An IPAddressElement is one of (IPV4 address, IP V6
address, MAC Address, ...)

An IPV4 address is an attribute because it is a leaf node.

Is an IPAddress an attribute of a Computer?  This depends in part on how one
looks at it.  I think of attributes as being somehow named while objects are
not.  Thus a Computer could have an External IP Address and an Internal IP
Address.  To me these are two different attributes of a computer but this
might not be the same way that you think of them.

Jim

> 
> 4. Sorry about that.  I should have removed that second sentence.  It
should
> read: "Objects are complex Information Elements that can be created using
one
> of the following IPFIX constructs that are defined in Section 3.1 of
[RFC7012].".
> With that said, in the future, we may want to reference out to RFC7013 for
best
> practices on creating new Information Elements.
> 
> Hope this helps!
> 
> Thanks,
> 
> Danny
> 
> 1.  Is the order of elements prescriptive or are the elements expressible
in any
> order?
Objects?  Is
> there supposed to be a way to distinguish between the two of them?
> 
> 3.  Once defined, I assume that an Object can be used in the dataType
field of an
> object or an attribute.  This is not true for an attribute.  Is this
correct?
> 4.  These sentences in section 3.2 do not make sense to me.  What did you
mean
> to say?
the
> following IPFIX constructs that are defined in Section 3.1 of [RFC7012].

---

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 22 Mar 2016 18:02:34 +0000

Hi Jim,

Comments inline below.

> the elementID need to come first.

No, I don't think the elements of the IPFIX definition need to be ordered (e.g. elementId does not need to come first) although we may want to pick an order for consistency and to improve the readability of the Information Elements in the document.  

> > 2. Yes, I kept the syntax identical with the exception of the
> > respective description properties asking for additional information
> > like a high-level diagram.  I thought having a single syntax would
> > make life easier. The way
> I was

Seems reasonable.  As a side note, IPFIX has a "group" property (See Section 5 of RFC5102), where they group Information Elements into a variety of categories (identifiers, IP header fields, flow timestamps, etc.).  In RFC6313, they also introduce a "structured-data" group (see Appendix A).  

This also seems like it is starting to get into a discussion that we need to have regarding how we indicate special things about Information Elements as first discussed during the SACM Virtual Interim Meeting (https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/39).  Maybe, we should hold off on this until we have that discussion?  What do you think?  We should be kicking that discussion off by the end of the week.

> > 3. I was thinking Attributes would always use one of the simple data
> > types (string, float, etc.) and Objects would always use one of the
> > structured
> data
> > when you might want to do this? On a related note, I should also add
> > that Objects can be composed of other Attributes and Objects via the
> > structured
> data
> Is an IPAddress an attribute of a Computer?  This depends in part on how
> one looks at it.  I think of attributes as being somehow named while objects
> are not.  Thus a Computer could have an External IP Address and an Internal
> IP Address.  To me these are two different attributes of a computer but this

Yes, you are right.  It does depend on how you look at it.  The alternate approach, using your example, would be to simply define the IPAddress element and allowing the data model designers to use that Information Element as it makes sense for them (internal, external, etc.).  However, that might give them too much flexibility.  How have others been thinking of this?  Is there a preference one way or another?  Is there another way to look at this?

Thanks,

Danny