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

[Benoit Claise <[e-mail]>]

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.
> 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 <[e-mail]> 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 [e-mail])
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core
> .
>