Re: [Dots] draft-andreasen-dots-info-data-model-01 feedback

[Flemming Andreasen <[e-mail]>]

On 11/11/16 9:50 AM, Roman D. Danyliw wrote:
>
> Hello Flemming and Tiru!
>
> (chair hat off)
>
> In reading through draft-andreasen-dots-info-data-model-01, I had the 
> following comments/questions:
>
> (1) The title suggests that the goal is for an information _and_ data 
> model to be documented.  I didn’t see much distinction made between 
> the two in the text.  Is the thinking to cover both?
>
I'm not so sure at this point. We have a number of protocol draft 
proposals at this point, each of which basically include their own data 
model. The idea with this draft was to come up with a protocol agnostic 
way of representing the information that was needed for DOTS, so 
contrary to my original claim, it is probably headed more in the way of 
an information model draft.


> (2) I really like the enumeration of information elements in Section 
> 3.4 and think this will be helpful for the authors of the solutions 
> drafts.  I struggled with the Section 3.2 a bit and may not fully 
> understand what you had in mind.  My thinking for an information model 
> document would be enumerating and describing information elements; and 
> where appropriate, the interrelationship between them.  The current 
> text seems to go one step further with protocol semantics and abstract 
> message formats.  I would have considered these out of scope for an 
> information model.
>
I found it difficult to come up with what information elements we want 
to have without some kind of "information exchange model" in mind and 
hence what you see in Section 3.2 is an attempt at a protocol agnostic 
way of describing this in the form of a logical API, while adhering to 
the overall requirements and architecture (e.g. signal channel with 
request/response for some exchanges while others need to work 
unidirectionally, plus a data channel). The API can map to any 
underlying protocol you desire (e.g. HTTP, COAP, protobufs, or something 
else running on top of your favorite transport) and there are no 
assumptions or requirements around exactly how that mapping is done 
(e.g. 1:1 in terms of messages or not).


> (3) In Section 3.1, the parameters categorized as mandatory, optional 
> and extensions.  Is the text implying that these are three mutually 
> exclusive categories?  For example, an extension, when used, cannot 
> have mandatory fields?
>
I suppose an extension can always define its own internal structure with 
some parts mandatory and some not, but the intent was that a particular 
extension is either supported by a particular implementation or not.

> (4) Section 3.1 - 3.3 discuss message parameters.  Section 3.4 
> enumerates information elements.  The link between parameters and 
> information elements is never explicitly stated.
>
We'll fix that in the next version.


Thanks for the comments Roman

-- Flemming


> Roman
>