Subject: [sacm] IM Issue #1 from IETF 96 - IE Template Specification

From: "Haynes, Dan" <[email-masked]>
Date: Wed, 20 Jul 2016 08:37:18 +0000

We discussed a few open issues during the first SACM session at IETF 96 and I wanted to follow up on the list to see if I could get some additional feedback.  Please review each question and let me know if you have any feedback on the proposed resolutions.

QUESTION:
Do we need an additional property to capture flags or other substructures (e.g. lists) rather than capturing this information in the description and datatype properties?

DISCUSSION:
During the meeting, there was no feedback on this issue.

PROPOSED RESOLUTION:
Given that embedding these structures in the description and datatype properties makes parsing it more difficult, I would like to propose that we add a new property (let's call it "structure" - feel free to propose a better name :)) to specify this additional information. The new property will also call out to text that specifies how these structures should be represented so that tools can parse them (e.g. grammar structure for lists, etc.).

QUESTION:
Should we update the status property from "current"/"deprecated" to "added in version X"/"deprecated in version Y"?

DISCUSSION:
During the meeting, it was noted that IPFIX defines a revision and date property that may be able to fill this need although they are not currently used in the SACM IM.  There was some discussion around the meaning of these properties with respect to publishing new RFCs. It was also clarified that IPFIX adopted the IANA registry "Expert Review" model where an expert is responsible for vetting new entries without the need to publish a new RFC.

PROPOSED RESOLUTION:
Given the need for SACM to evolve as endpoints change, I would like to propose that SACM leverage the revision and date properties with the expectation that we will work towards an "expert review" model.  We may also want to consider modifying the revision property to follow something like semver.org rather than a simple integer revision.

Let me know if you have any questions.

Thanks,

Danny

---

From: Chris Inacio <[email-masked]>
Date: Wed, 20 Jul 2016 09:12:51 +0000

Danny,

I think being able to support some ability to structure data in the IM is key. It was grafted on later in IPFIX, and while that’s workable, it’s definitely not well liked.

Understanding that this is an information model and not a data model (nor a protocol); I vote that we stick to those higher constructs we need describing data associations: {ordered, un-ordered}, {child, parent}, etc.

Then how that gets transmitted, deals with fragmentation, message formats, etc. becomes a data-model / protocol issue.

--
Chris Inacio
[email-masked]<mailto:[email-masked]>

From: Haynes, Dan <[email-masked]><mailto:[email-masked]>
Date: July 20, 2016 at 10:37:32 AM
To: [email-masked] <[email-masked]><mailto:[email-masked]>
Subject:  [sacm] IM Issue #1 from IETF 96 - IE Template Specification

QUESTION:

DISCUSSION:

PROPOSED RESOLUTION:
Given that embedding these structures in the description and datatype properties makes parsing it more difficult, I would like to propose that we add a new property (let’s call it “structure” – feel free to propose a better name :)) to specify this additional information. The new property will also call out to text that specifies how these structures should be represented so that tools can parse them (e.g. grammar structure for lists, etc.).

QUESTION:
Should we update the status property from “current”/”deprecated” to “added in version X”/”deprecated in version Y”?

DISCUSSION:
During the meeting, it was noted that IPFIX defines a revision and date property that may be able to fill this need although they are not currently used in the SACM IM.  There was some discussion around the meaning of these properties with respect to publishing new RFCs. It was also clarified that IPFIX adopted the IANA registry “Expert Review” model where an expert is responsible for vetting new entries without the need to publish a new RFC.

PROPOSED RESOLUTION:
Given the need for SACM to evolve as endpoints change, I would like to propose that SACM leverage the revision and date properties with the expectation that we will work towards an “expert review” model.  We may also want to consider modifying the revision property to follow something like semver.org rather than a simple integer revision.

Thanks,

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

---

From: Adam Montville <[email-masked]>
Date: Wed, 20 Jul 2016 13:20:28 +0200

> On Jul 20, 2016, at 10:37 AM, Haynes, Dan <[email-masked]> wrote:
> 

I think some folks might need additional context to provide opinions here.   In Section 4 of the information model draft we talk about the structure of Information Elements, and the structure basically says we’re going to capture (or make available) the following fields for IEs:

elementId
enterpriseId
name
dataType
status
description

> Given that embedding these structures in the description and datatype properties makes parsing it more difficult, I would like to propose that we add a new property (let’s call it “structure” – fee…

Do we have some examples of why/when this would be needed?  I’ve had some conversations offline that are leading me to believe that we should make IEs as simple and concise as possible.  Then, if we feel that we need another attribute of an IE to augment that which would otherwise be put in the dataType field, then we might consider making the IEs even more granular, so that we don’t need the additional structure.  (Note: These offline conversations were really at the data model level, but may apply equally to the information model level.)

> Given the need for SACM to evolve as endpoints change, I would like to propose that SACM leverage the revision and date properties with the expectation that we will work towards an “expert review” model.  We may also want to consider modifying the revision property to follow something like semver.org <http://semver.org/> rather than a simple integer revision.

I don’t like the idea of embedding too many semantics into a single table, so things like “added in version X”/“deprecated in version Y” seem like something we would decompose into a status tuple if we went in that direction.

With respect to semver.org, I think it might be useful to consider how we would use that specification in the context of SACM registries (the semver.org specification is written for software).

> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>

---

From: "Haynes, Dan" <[email-masked]>
Date: Wed, 20 Jul 2016 12:26:31 +0000

Hi Chris,

Can you clarify which “higher level” constructs you are talking about?

Thanks,

Danny

From: Chris Inacio [mailto:[email-masked]]
Sent: Wednesday, July 20, 2016 11:13 AM
To: Haynes, Dan <[email-masked]>; [email-masked]
Subject: Re: [sacm] IM Issue #1 from IETF 96 - IE Template Specification

Danny,

From: Haynes, Dan <[email-masked]><mailto:[email-masked]>
Date: July 20, 2016 at 10:37:32 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject:  [sacm] IM Issue #1 from IETF 96 - IE Template Specification

QUESTION:

DISCUSSION:

PROPOSED RESOLUTION:

QUESTION:

DISCUSSION:

PROPOSED RESOLUTION:

Thanks,

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

---

From: "Haynes, Dan" <[email-masked]>
Date: Wed, 20 Jul 2016 15:37:23 +0000

Hi Adam,

Comments inline below.

Thanks,

Danny

From: Adam Montville [mailto:[email-masked]]
Sent: Wednesday, July 20, 2016 1:20 PM
To: Haynes, Dan <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] IM Issue #1 from IETF 96 - IE Template Specification

On Jul 20, 2016, at 10:37 AM, Haynes, Dan <[email-masked]<mailto:[email-masked]>> wrote:

QUESTION:

DISCUSSION:

elementId
enterpriseId
name
dataType
status
description

PROPOSED RESOLUTION:

[danny] interfaceFlags contains an example of a table of flag values in the description property. networkInterface is an example of a list construct definition which was originally in the description property and right now captured in the datatype property.  We wanted to break it out because Jim started to write some code that would present the IEs in a human-friendly way and so we could auto-generate the content rather than always having to do it by hand.  Separating it out just makes it easier to parse.  Jim feel free to correct me if I am wrong.

QUESTION:

DISCUSSION:

PROPOSED RESOLUTION:
Given the need for SACM to evolve as endpoints change, I would like to propose that SACM leverage the revision and date properties with the expectation that we will work towards an “expert review” model.  We may also want to consider modifying the revision property to follow something like semver.org<http://semver.org/> rather than a simple integer revision.

With respect to semver.org<http://semver.org>, I think it might be useful to consider how we would use that specification in the context of SACM registries (the semver.org<http://semver.org> specification is written for software).

[danny] Yeah, a status tuple would probably be better. At the end of the day, I think this is really an operational issue for once we have a registry.  We might be able to punt on this for now until just before the IM gets submitted for review/publication since that’s when we would have our first official IEs.

Thanks,

Danny

---

From: Chris Inacio <[email-masked]>
Date: Wed, 20 Jul 2016 17:57:25 +0000

So I read the list section a bit closer and I think it covers it.  As long as you can infinitely nest the lists (ordered and unordered) I think there aren’t really any structures that can’t be handled.

If we’re leaving the lists structure along with the relationships elements in, then I ‘m good.  I got the impression from the question that those would be removed.

From: Haynes, Dan <[email-masked]><mailto:[email-masked]>
Date: July 20, 2016 at 2:26:42 PM
To: Chris Inacio <[email-masked]><mailto:[email-masked]>, [email-masked] <[email-masked]><mailto:[email-masked]>
Subject:  RE: [sacm] IM Issue #1 from IETF 96 - IE Template Specification

Hi Chris,

Thanks,

Danny

Danny,

QUESTION:

DISCUSSION:

PROPOSED RESOLUTION:

QUESTION:

DISCUSSION:

PROPOSED RESOLUTION:

Thanks,

Danny

---

From: Chris Inacio <[email-masked]>
Date: Wed, 20 Jul 2016 18:01:58 +0000

Inline

From: Haynes, Dan <[email-masked]><mailto:[email-masked]>
Date: July 20, 2016 at 5:37:43 PM
To: Adam Montville <[email-masked]><mailto:[email-masked]>
Cc: [email-masked] <[email-masked]><mailto:[email-masked]>
Subject:  Re: [sacm] IM Issue #1 from IETF 96 - IE Template Specification

Hi Adam,

Comments inline below.

Thanks,

Danny

QUESTION:

DISCUSSION:

elementId
enterpriseId
name
dataType
status
description

PROPOSED RESOLUTION:

QUESTION:

DISCUSSION:

PROPOSED RESOLUTION:

But if we use that, can you assign relevant meaning:

major - incompatible change

minor - additions to the IE / protocol - otherwise compatible with the same major number

patch - functionally the same, improvements in understanding/documentation; e.g. the fix of a definition of an IE

[inacio] but can’t you just accomplish this with a list as a result?  If you really need tuples, that’s a list of n-element lists - right?

Thanks,

Danny

---

From: "Haynes, Dan" <[email-masked]>
Date: Thu, 21 Jul 2016 08:10:44 +0000

Ok, thanks for the clarification.  Did anyone else have thoughts on these changes?

Thanks,

Danny

From: Chris Inacio [mailto:[email-masked]]
Sent: Wednesday, July 20, 2016 7:57 PM
To: Haynes, Dan <[email-masked]>; [email-masked]
Subject: RE: [sacm] IM Issue #1 from IETF 96 - IE Template Specification

From: Haynes, Dan <[email-masked]><mailto:[email-masked]>
Date: July 20, 2016 at 2:26:42 PM
To: Chris Inacio <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject:  RE: [sacm] IM Issue #1 from IETF 96 - IE Template Specification

Hi Chris,

Thanks,

Danny

From: Chris Inacio [mailto:[email-masked]]
Sent: Wednesday, July 20, 2016 11:13 AM
To: Haynes, Dan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] IM Issue #1 from IETF 96 - IE Template Specification

Danny,

QUESTION:

DISCUSSION:

PROPOSED RESOLUTION:

QUESTION:

DISCUSSION:

PROPOSED RESOLUTION:

Thanks,

Danny

---

From: "Haynes, Dan" <[email-masked]>
Date: Thu, 21 Jul 2016 08:17:33 +0000

More comments inline.

Thanks,

Danny

From: Chris Inacio [mailto:[email-masked]]
Sent: Wednesday, July 20, 2016 8:02 PM
To: Haynes, Dan <[email-masked]>; Adam Montville <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] IM Issue #1 from IETF 96 - IE Template Specification

Inline

Cc: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

Hi Adam,

Comments inline below.

Thanks,

Danny

From: Adam Montville [mailto:[email-masked]]
Sent: Wednesday, July 20, 2016 1:20 PM
To: Haynes, Dan <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] IM Issue #1 from IETF 96 - IE Template Specification

QUESTION:

DISCUSSION:

elementId
enterpriseId
name
dataType
status
description

PROPOSED RESOLUTION:

QUESTION:

DISCUSSION:

PROPOSED RESOLUTION:

[danny] I think you could, but, this is just metadata about an IE so it’s not clear to me that you would want to express it as an IE.

Thanks,

Danny

---

From: Jim Schaad <[email-masked]>
Date: Thu, 21 Jul 2016 12:54:41 +0200

Both of these resolutions seem reasonable to me until we have different
information.

From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Wednesday, July 20, 2016 10:37 AM
To: [email-masked]
Subject: [sacm] IM Issue #1 from IETF 96 - IE Template Specification

We discussed a few open issues during the first SACM session at IETF 96 and
I wanted to follow up on the list to see if I could get some additional
feedback.  Please review each question and let me know if you have any
feedback on the proposed resolutions.

QUESTION:

Do we need an additional property to capture flags or other substructures
(e.g. lists) rather than capturing this information in the description and
datatype properties?

DISCUSSION:

PROPOSED RESOLUTION: 

Given that embedding these structures in the description and datatype
properties makes parsing it more difficult, I would like to propose that we
add a new property (let's call it "structure" - feel free to propose a
better name :)) to specify this additional information. The new property
will also call out to text that specifies how these structures should be
represented so that tools can parse them (e.g. grammar structure for lists,
etc.).

QUESTION: 

Should we update the status property from "current"/"deprecated" to "added
in version X"/"deprecated in version Y"?

DISCUSSION:

During the meeting, it was noted that IPFIX defines a revision and date
property that may be able to fill this need although they are not currently
used in the SACM IM.  There was some discussion around the meaning of these
properties with respect to publishing new RFCs. It was also clarified that
IPFIX adopted the IANA registry "Expert Review" model where an expert is
responsible for vetting new entries without the need to publish a new RFC.  

PROPOSED RESOLUTION:

Given the need for SACM to evolve as endpoints change, I would like to
propose that SACM leverage the revision and date properties with the
expectation that we will work towards an "expert review" model.  We may also
want to consider modifying the revision property to follow something like
semver.org rather than a simple integer revision.  

Thanks,

Danny