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

[Barry Leiba <[e-mail]>]

Benoît, this is still on your queue.  Can you check this right away,
please?  Thanks.

Barry

On Thu, Feb 4, 2016 at 1:59 PM, Barry Leiba <[e-mail]> wrote:
>> 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
>>>
>>> .
>>>
>>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core