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

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 4 Jan 2016 22:32:21 +0000

I must admit that I too am torn as UML can be a good way to express the
IM.  However, imho no matter what we choose, the interpretation has to be
expressed in English so that the IM representation is well understood by
all.  That is, we really need to focus on the content and intent (which I
believe must be in written [english] prose anyway).

Š.hmmm, so I guess given that argument I would lean to option 5 (English)Š.

	Nancy.

On 12/29/15, 11:45 AM, "sacm on behalf of Leif Johansson"
<[email-masked] on behalf of [email-masked]> wrote:

>On 2015-12-29 20:28, Wolfkiel, Joseph L CIV DISA ID (US) wrote:
>> I'm not wedded to UML.  If throwing my vote to plain English would make
>>this move along, I'm fine with it.
>> 
>
>How are you going to represent UML in an I-D? Publish under the new
>format rules and do SVG?
>
>Lets just make sure the mechanics of playing with the arrows take
>more time and energy than the content.
>
>	Cheers Leif
>
>_______________________________________________
>sacm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sacm

---

From: Chris Inacio <[email-masked]>
Date: Tue, 5 Jan 2016 22:01:16 +0000

Can we do the preference list voting thing?  (Just for fun at this point…  :)  Let’s use the Aussie system…   https://en.wikipedia.org/wiki/Instant-runoff_voting

5
2
1
3
4

--
Chris Inacio
[email-masked]

> On Jan 4, 2016, at 5:32 PM, Nancy Cam-Winget (ncamwing) <[email-masked]> wrote:
> 
>

---

From: David Harrington <[email-masked]>
Date: Tue, 5 Jan 2016 22:32:10 -0500

What are the numbers again?
I know 5 is english, my preference but i forget what each of the others represent. 

David Harrington
[email-masked]
603-828-1401

> On Jan 5, 2016, at 5:01 PM, Chris Inacio <[email-masked]> wrote:
> 
>

---

From: Chris Inacio <[email-masked]>
Date: Wed, 6 Jan 2016 20:15:27 +0000

no good can come from my editorializing about what these things are, but I’m doing it anyway…

I’m annotating my list.

> On Jan 5, 2016, at 10:32 PM, David Harrington <[email-masked]> wrote:
> 
>> 5 - English (a bit of prose + a bit of do whatever works/you like)
>> 2 - LMAP ADT text (describes ADTs in semi structured english text)
>> 1 - EMAN UML in text (UML in semi structured english text)
>> 3 - UML
>> 4 - ER diagrams
>> 
>> 
>> 

cheers
--
Chris Inacio
[email-masked]

---

From: John Strassner <[email-masked]>
Date: Thu, 7 Jan 2016 01:13:43 +0000

Take at look at draft-strassner-supa-generic-policy-info-model-03, section 3 (symbology) as one possible example.

regards,
John
	
-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Leif Johansson
Sent: Tuesday, December 29, 2015 11:46 AM
To: [email-masked]
Subject: Re: [sacm] Consensus Call: Choosing an IM Expression Syntax

On 2015-12-29 20:28, Wolfkiel, Joseph L CIV DISA ID (US) wrote:
> I'm not wedded to UML.  If throwing my vote to plain English would make this move along, I'm fine with it.
> 

	Cheers Leif

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 7 Jan 2016 10:34:40 +0000

Hi,

At IETF 94 I pointed to the WG a possible option 6 ('IPFIX' - as per RFC 7102) which would be my preference. This was not included in the Consensus Call. It still would be my preference. 

From the other 5 options my preference is for option 2 ('LMAP') followed by 5 ('English').

I do not know of any successful use of UML in the IETF. There are several different reasons for this. 

Regards,

Dan

---

From: "Haynes, Dan" <[email-masked]>
Date: Thu, 7 Jan 2016 14:37:03 +0000

Hi Dan,

Regarding the IPFIX option, I think you were referring to RFC7012 (https://www.rfc-editor.org/rfc/rfc7012.txt) correct?

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.)?

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).
 
Thanks,

Danny
-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, January 07, 2016 5:35 AM
To: [email-masked]
Subject: Re: [sacm] Consensus Call: Choosing an IM Expression Syntax

Hi,

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 7 Jan 2016 15:38:46 +0000

Hi Dan,

See in-line. 

DanR

> From: Haynes, Dan [mailto:[email-masked]]
> Sent: Thursday, January 07, 2016 4:37 PM
> To: Romascanu, Dan (Dan); [email-masked]
> 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 ) 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) 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

---

From: Chris Inacio <[email-masked]>
Date: Thu, 7 Jan 2016 16:13:13 +0000

Having worked on IPFIX and implemented it as well - I’d be perfectly happy to work in that model.  :)

--
Chris Inacio
[email-masked]

> On Jan 7, 2016, at 10:38 AM, Romascanu, Dan (Dan) <[email-masked]> wrote:
> 
> Hi Dan,
> 
> See in-line. 
> 
> DanR
>

---

From: "Haynes, Dan" <[email-masked]>
Date: Thu, 7 Jan 2016 19:11:43 +0000

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:[email-masked]] 
Sent: Thursday, January 07, 2016 10:39 AM
To: Haynes, Dan <[email-masked]>; [email-masked]
Subject: RE: [sacm] Consensus Call: Choosing an IM Expression Syntax

Hi Dan,

See in-line. 

DanR

> 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.)?
> 

 
> 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).
> 

Regards,

Dan

---

From: Ira McDonald <[email-masked]>
Date: Thu, 7 Jan 2016 14:15:15 -0500

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/highnorthinc
mailto: [email-masked]
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 <[email-masked]> wrote:

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

---

From: Adam Montville <[email-masked]>
Date: Fri, 8 Jan 2016 15:37:43 -0600

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 <[email-masked]> wrote:
> 
> Hi,
> 
> PS - The SUPA spec is well worth reading.  Henk and Danny - recommended for a really
> 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: [email-masked] <mailto:[email-masked]>
> On Thu, Jan 7, 2016 at 2:11 PM, Haynes, Dan <[email-masked] <mailto:[email-masked]>> wrote:
> From: Romascanu, Dan (Dan) [mailto:[email-masked] <mailto:[email-masked]>]
> To: Haynes, Dan <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> > From: Haynes, Dan [mailto:[email-masked] <mailto:[email-masked]>]
> > To: Romascanu, Dan (Dan); [email-masked] <mailto:[email-masked]>
> > (https://www.rfc-editor.org/rfc/rfc7012.txt <https://www.rfc-editor.org/rfc/rfc7012.txt> ) correct?
> >
> 
> 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
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
>