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

[Benoit Claise <[e-mail]>]

Carsten,

> Hi Benoit,
>
> these are indeed useful clarifications.
>
> Benoit Claise wrote:
>> Benoit Claise has entered the following ballot position for
>> charter-ietf-core-01-01: Block
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/charter-ietf-core/
>>
>>
>>
>> ----------------------------------------------------------------------
>> BLOCK:
>> ----------------------------------------------------------------------
>>
>> 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

Regards, Benoit
>
> Grüße, Carsten
>
> .
>