Re: [sacm] Consensus Call: Choosing an IM Expression Syntax

Thanks to everyone for chiming in.  After getting some additional opinions on the IPFIX option and conferring with Karen, it seems that we should move forward on the rough consensus to an IPFIX-based notation coupled with English to expressing our IM.  If there are issues down the road with this selection, we can work through them at that point.

Right now, we just need to choose and move on.

Kind regards,

Adam

> On Jan 7, 2016, at 1:15 PM, Ira McDonald <blueroofmusic@gmail.com> wrote:
> 
> Hi,
> 
> OK - I'd like to change my vote.
> 
> I like the IPFIX option best.
> 
> Cheers,
> - Ira
> 
> PS - The SUPA spec is well worth reading.  Henk and Danny - recommended for a really
> good treatment of relationships between classes/objects.
> 
> 
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: blueroofmusic@gmail.com <mailto:blueroofmusic@gmail.com>
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
> 
> 
> On Thu, Jan 7, 2016 at 2:11 PM, Haynes, Dan <dhaynes@mitre.org <mailto:dhaynes@mitre.org>> wrote:
> Thanks for the additional information Dan.  It was exactly what I was looking for.
> 
> Given that, my preferences are as follows:
> 
> 1) Option 6 (IPFIX)
> 2) Option 1 or Option 2
> 3) Option 5
> 4) Option 3 or Option 4
> 
> Thanks,
> 
> Danny
> 
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com <mailto:dromasca@avaya.com>]
> Sent: Thursday, January 07, 2016 10:39 AM
> To: Haynes, Dan <dhaynes@mitre.org <mailto:dhaynes@mitre.org>>; sacm@ietf.org <mailto:sacm@ietf.org>
> Subject: RE: [sacm] Consensus Call: Choosing an IM Expression Syntax
> 
> Hi Dan,
> 
> See in-line.
> 
> DanR
> 
> > -----Original Message-----
> > From: Haynes, Dan [mailto:dhaynes@mitre.org <mailto:dhaynes@mitre.org>]
> > Sent: Thursday, January 07, 2016 4:37 PM
> > To: Romascanu, Dan (Dan); sacm@ietf.org <mailto:sacm@ietf.org>
> > Subject: RE: [sacm] Consensus Call: Choosing an IM Expression Syntax
> >
> > Hi Dan,
> >
> > Regarding the IPFIX option, I think you were referring to RFC7012
> > (https://www.rfc-editor.org/rfc/rfc7012.txt <https://www.rfc-editor.org/rfc/rfc7012.txt> ) correct?
> >
> 
> Of course - sorry for the confusion, thanks for catching it.
> 
> > Just to clarify, are you advocating for defining a set of fields that
> > are required for SACM's IM elements and then defining the IM elements
> > in terms of those fields?  Or, are you more specifically suggesting
> > that we should just use the fields listed in the document (name,
> > elementID, description, datatype, etc.)?
> >
> 
> I was thinking first of all about the Syntax - that's what the Consensus Call is about.
> 
> Leveraging  already defined fields, naming conventions may be an extra advantage but not essential IMO.
> 
> > With that said, I think this format could work well for defining
> > attributes in SACM and it seems pretty easy to work with.  We could
> > probably also leverage many of their naming conventions, etc. and save
> > some more time :).  However, I did not see any examples of compound IM
> > elements that were made up of multiple IM elements defined using this
> > format.  An example from SACM might be a network interface that
> > consists of an IP address, MAC address, flags, etc.  Are there any
> > examples of this (I may have looked in the wrong place)?  Is it
> > something that we would have to figure out and decide on?  Or, is it
> > just something that is addressed at the data model level?  That is,
> > the SACM IM will define the attributes, but, the data models are free
> > to combine them as they see fit (i.e. a data model could decide
> > whether or not they wanted to create a network interface construct that ties together a bunch of attributes).
> >
> 
> IPFIX has several levels of complexity which were developed in successive phases. There is no DM and initially data records were sent as flat lists. This started soon to be seen as a limitation, and RFC 6313 (https://www.rfc-editor.org/rfc/rfc6313.txt <https://www.rfc-editor.org/rfc/rfc6313.txt>) defined the Structured Data IEs to deal with the more complex cases. (see in section 2.3 the example of an IDS mentioned as use case).
> 
> Regards,
> 
> Dan
> 
> 
> _______________________________________________
> sacm mailing list
> sacm@ietf.org <mailto:sacm@ietf.org>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> 
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm