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

From: Barry Leiba <[email-masked]>
Date: Tue, 26 Jan 2016 10:11:55 -0500

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 <[email-masked]> 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

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 31 Jan 2016 17:11:58 +0100

Hi Barry,

I'm back in Germany.

I have expunged DICE (which has now closed) by replacing it with a
reference to the security area in general (for DTLS over SMS), with a
reference to the TLS WG (on DTLS specific efficiency work), and simply
striking DICE from the list of WGs to coordinate with.  That should
cover Stephen's comments.

Re Benoit's input (key:
>>>> and >> are Benoît; >>> are Carsten)

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

The main draft is draft-vanderstok-core-comi, and there are some
additional considerations in draft-veillette-core-cool.

(Or did you ask for text/pointers to be in the charter?)

>>> about being used in COMI,

(I was alluding to the COOL work here.)

>> data model language, and not another data model language. 

One objective that has been repeatedly stated in the COMI work is that
any random YANG module should be usable with COMI, but there are still
discussions whether this will be a less efficient mode and/or we should
be leaving out some parts (RPC has been stated as an example).  I think
we have been progressing towards enabling full coverage.  There may,
however, be some considerable efficiency gains that can be reaped by
evolving YANG modules in a specific way.

>> In the end, if

I think this statement reflects the current direction well, however,
there may be some willingness to do additional work (such as COOL's SID
files) in exchange for significant reductions in the message size.

>> Interface Management for constrained networks?

We already have RFC 7388, and we'd rather get more integration with the
YANG world than less.

>>     No YANG specifics for constrained nodes network ...

I somewhat nebulously phrased that as:

  Besides continuing to examine operational and manageability aspects of
  the CoAP protocol itself, 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.  The YANG modeling language is not a target for change in
  this process, however additional supporting mechanisms may be
  employed in specific cases where significant performance gains are
  both attainable and required.

(Maybe this can still be improved.)

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

I have added to the above:

  The working
  group will continue to consider the OMA LWM2M management functions
  as a well-accepted alternative form of management and provide
  support at the CoAP protocol level where required.

That wording is obviously even more up for discussion: WG, please chime
in (potentially after limiting the CC list to [email-masked]).

An edited version charter-ietf-core-01-01 with detailed history is now at
https://svn.tools.ietf.org/svn/wg/core/charter-ietf-core.txt

Grüße, Carsten