Re: [core] Benoit Claise's Block on charter-ietf-core-01-01: (with BLOCK)

[Barry Leiba <[e-mail]>]

Carsten and CORE working group:
This has been sitting unresolved since October.  Can we wrap this up
now, and get the recharter finished?  I need text changes for Benoît's
block position, and also rewording of the dependency on DICE
(Stephen's comments).

Please put this on the high priority list and let's take care of this
right away.

Thanks,
Barry
---------------------------
Key to reading this:
>>> and > are Benoît; >> are Carsten
---------------------------
On Thu, Oct 22, 2015 at 4:34 AM, Benoit Claise <[e-mail]> wrote:
>
>> Hi Benoit,
>>
>> these are indeed useful clarifications.

>>> Two points I would like to discuss.
>>>
>>> - "CoRE will also develop a way to make RESTCONF-style management
>>> functions
>>> available via CoAP that is appropriate for constrained node networks.
>>> This
>>> will require very close coordination with NETCONF and other operations
>>> and
>>> management working groups."
>>>
>>> What is the goal of this coordination with NETCONF?
>>> Could RESTCONF be reused? If not, why not?
>>> If yes, will RESTCONF need to be modified?

>> We want to coordinate with the NETCONF WG to ensure that the result of
>> our work makes sense as a part of the overall NETCONF family.

> Thanks. The coordination objectives should be mentioned in the charter.

>> The basis for COMI is RESTCONF, but there will be a need for some
>> streamlining.

> Can you expand on this, or point to a draft section/email thread.

>> It is not clear whether this will lead to modifications
>> of RESTCONF itself; more likely COMI will just be a dialect that is
>> applicable to very constrained devices.  There are different approaches
>> on the question whether the YANG models have to take some specific care
>> about being used in COMI,

> (I've not been following the core mailing list and I don't know which
> specifics you speak about)
> I hope you will not go that path.
> This would be a failure from an OPS point of view: we need a single YANG
> data model language, and not another data model language. In the end, if
> there are YANG specifics for constrained node networks, then it's a
> different data model language.
> To illustrate my point: shall we see RFC 7223bis, A YANG Data Model for
> Interface Management for constrained networks?
>
> Unless I miss something on the above, this should even mentioned in the core
> charter.
>
>     CoRE will also develop a way to make RESTCONF-style management
>     functions available, based on YANG, via CoAP that is appropriate for
>     constrained
>     node networks.
>
>     +
>
>     No YANG specifics for constrained nodes network ...

>> or whether COMI covers all kinds of
>> RESTCONF-capable YANG models, possibly with varying degrees of
>> efficiency based on how COMI-aware their design is.

>>> - What is the data model (language) used for the resources? For example,
>>> RESTCONF uses YANG

>> YANG.

>>> Maybe, this information is in this paragraph
>>>
>>> CoRE will work on related data formats, such as alternative
>>> representations
>>> of RFC 6690 link format and RFC 7390 group communication information.
>>> The
>>> working group will complete the SenML specification, again with
>>> consideration to its adoption in OMA LWM2M.
>>>
>>> However, I have no clue what the second sentence means.

>> This paragraph is not about management information, but about formats
>> for the actual content data (e.g., SenML is used to represent [time
>> series of] sensor data) and application interaction.

> thanks.
> And LWM2M?
>
> Do we need to expand a bit on those in the charter? I guess so