Subject: [sacm] Review of draft-ietf-sacm-information-model-07

From: Jim Schaad <[email-masked]>
Date: Thu, 29 Sep 2016 14:50:31 -0700

I am feeling really stupid from a lack of sleep, so it seems a good time to
start a review on this.

In section 4 - I am not sure that I understand the basic difference between
an attribute and a subject.  Is section 7 defining attributes or subjects or
both?  Are attributes only the simple data types?

Do you really mean for subjects to be circular?  I can understand the idea
of making a tree, but making a circle seems to me to be a bad idea.  If you
want circles it would seem to better to say use either SACM statements or
something else.

Are the names associated with subjects the name of the subject or the name
of the subject instance?  

What is it that defines an IE as being an IE?  Are Content Elements and SACM
statements part of the IE or are they something completely different?  If
they are not, in some sense Information Elements, then what are the rules
for DMs when looking at them?  Are they part of the DM or not?  There are
only requirements on mapping IEs and not for mapping of other things.

Change the title for figure 1 or make it clearer which is the attribute and
which is the subject in text someplace.  Maybe divide into two figures would
be clearer about what is going on. 

Are you defining meta-data IM elements or are you making them separate?  If
yes, need to modify IE template.  If not, then need to be able to identify
them and list them someplace.

Where are the list of relationships and what they mean defined?

Kill Categories - there is no need to make them as separate items they are
just an enumerated list. - ergo a subject.

Jim

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 30 Sep 2016 10:28:16 +0200

Hello Jim,

some comments inline:

> both?  Are attributes only the simple data types?

At the moment, section 7 mixes Attributes and Subjects and I think it is 
already panned to separate those two in sub-sections again.

The (editors' version) of the terminology draft contains compact 
definitions for Attribute and Subject. If those also do not clarify your 
understanding, this has to be fixed!

> want circles it would seem to better to say use either SACM statements or

Representing a network path, for example, can benefit from circular 
nesting of Subjects. While this would allow for infinite nested 
subjects, 7.25. default-depth is there to mitigate that misuse, I think.
> Are the names associated with subjects the name of the subject or the name

This is up to the date model, I presume? If the "name of the container 
type" is not transfered in an instance, the members of the instance must 
contain a composition of Attributes and Subjects that enable an 
unambiguous matching of that instance to its corresponding type. Another 
approach would be to include an Attributes that contains the name of the 
Subject as its content (resulting in the name of the Subject "type" 
being transfered).

Maybe text is missing here that highlights that it must always be 
possible to match an instance of a Subject to its corresponding type 
unambiguously?

> only requirements on mapping IEs and not for mapping of other things.

Yes, Statements and Content-Elements are Information Elements. 
Technically they constitute "top-level" IE that function as envelopes 
that can contain any other IE and bundle them with their metadata, e.g. 
data provenance.

> be clearer about what is going on.

If in Figure 1, it is not evident which one is which, maybe we have done 
a bad job in composing text to explain a thing as trivial as Attributes 
and Subjects. We can annotate which is which in the Figure of course 
(and will, I guess). But the more fundamental problem, I think, is that 
we were not able to convey this quite simple concept in the text leading 
to Figure 1! This also has to be fixed!

> them and list them someplace.

The same question is on my mind. Some IE in section 7 contain an 
"metadata: true" field. Does this mean we are switching to explicitly 
defined "content IE" and "metadata IE"? This would result in a number of 
"redundant" IE as some can be interpreted both as data or as data about 
data - depending on context (i.e., if the are placed in metadata 
subjects or not).

There are some IE that are probably always metadata, such as time 
stamps, though.

> Where are the list of relationships and what they mean defined?

This is a big todo at the moment and we are working on that!

> just an enumerated list. - ergo a subject.

There is a big difference between a Category (implicit is-a 
relationship) and a Subject (implicit has-a relationship). If we use 
Subjects for both - how do you know which relationship it is? An 
approach to use Subjects for this could be to annotate them with a 
characteristic similar to structure (e.g.: list, orderedlist, and in 
this case: category, composite)?

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

---

From: Jim Schaad <[email-masked]>
Date: Fri, 30 Sep 2016 22:49:46 -0700

> -----Original Message-----
> From: Henk Birkholz [mailto:[email-masked]]
> Sent: Friday, September 30, 2016 1:28 AM
> To: [email-masked]
> Cc: Jim Schaad <[email-masked]>
> Subject: Re: [sacm] Review of draft-ietf-sacm-information-model-07
> 
> Hello Jim,
> 
> some comments inline:
> 
> > I am feeling really stupid from a lack of sleep, so it seems a good
> > time to start a review on this.
> >
> > In section 4 - I am not sure that I understand the basic difference
> > between an attribute and a subject.  Is section 7 defining attributes
> > or subjects or both?  Are attributes only the simple data types?
> 
already
> panned to separate those two in sub-sections again.
> 
definitions for
> Attribute and Subject. If those also do not clarify your understanding,
this has to
> be fixed!

Based on the current definition, my best guess is that an attribute has a
data type which is a simple data type and a subject is one with a structured
data type.  This appears to me to be a difference without a distinction
which is probably which I don't understand the difference between them.  To
me the address of a building is an attribute whether expressed as a single
string with CRLFs or as an ordered list of strings.  I think that to you the
fact that the data is expressed differently means it goes from being an
attribute to being a subject.

> subjects, 7.25. default-depth is there to mitigate that misuse, I think.

What IE are you using for this?  Also I don't understand how default-depth
would be an IE, but that is not of importance at this time.

> possible to match an instance of a Subject to its corresponding type

simplest IE structure comprised of a unique attribute name and an attribute
value.

My problem is that you state here a unique attribute name.  I am unsure if
this name is based on the attribute or based on the instance of the
attribute.  Similar language exists for subjects.  I think that the language
could be stated in a clearer way so that it is not ambiguous.

> that can contain any other IE and bundle them with their metadata, e.g.

This would mean that a template exists for them in the document?

> to Figure 1! This also has to be fixed!

Pointing to the figure from the text would be reasonable from my perspective
as well.

> There are some IE that are probably always metadata, such as time

Bad example, but I understand what you are saying.  I think that given that
some of the metadata is going to be "special" those items potentially need
to be highlighted as such because if I am thinking of doing SWIDs only, then
I still need to deal with all of the metadata types that can occur and might
not correctly identify them.

> this case: category, composite)?

Given the example in the text I would not have had a different relationship
for that than for subject.  It could be that you might feel better if I said
make all Categories be attributes however.

The example of 
NetworkAddress = list( macAddress | ipv4Address | ipv6Address |
typedNetworAddress )

>From my definition above this would be a subject.  However it could just as
easily be an attribute except for the question of tagging NetworkAddress.
I.e. is this something that exists in the serialization or is it just a
CHOICE which is invisible unless the choice itself is ambiguous.   

Jim