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

From: Barry Leiba <[email-masked]>
Date: Wed, 3 Feb 2016 17:38:22 -0500

Benoît, can you have a look at this version?:
> 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

Barry

On Sun, Jan 31, 2016 at 11:11 AM, Carsten Bormann <[email-masked]> wrote:
> 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)
>
>>>>> - "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.
>
> 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?)
>
>>>> 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 was alluding to the COOL work here.)
>
>>> (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.
>
> 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
>>> there are YANG specifics for constrained node networks, then it's a
>>> different data model language.
>
> 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.
>
>>> To illustrate my point: shall we see RFC 7223bis, A YANG Data Model for
>>> Interface Management for constrained networks?
>
> We already have RFC 7388, and we'd rather get more integration with the
> YANG world than less.
>
>>>
>>> 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 ...
>
> 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.)
>
>>> And LWM2M?
>>>
>>> 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
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Benoit Claise <[email-masked]>
Date: Thu, 4 Feb 2016 14:52:16 +0100

Hi Barry,

Can we please use the tool 
(https://datatracker.ietf.org/doc/charter-ietf-core/history/) so that I 
can do a quick diff.

Regards, B.
> .

---

From: Barry Leiba <[email-masked]>
Date: Thu, 4 Feb 2016 08:59:06 -0500

> (https://datatracker.ietf.org/doc/charter-ietf-core/history/) so that I can
> do a quick diff.

Sorry; done -- please check it.

b