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

[Barry Leiba <[e-mail]>]

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

Sorry; done -- please check it.

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
>>
>> .
>>
>