Subject: [core] YANG-Push-CoAP problem statement

From: Carsten Bormann <[email-masked]>
Date: Wed, 18 Oct 2017 19:52:20 +0200

There is a new I-D with a problem statement and a rough solution outline for a gap that would need to be closed to make COMI applicable to an additional set of applications. 

It is not a particularly long draft.  Some review from CoRE experts might help us find the best way forward — this is not a lot of new protocol work for CoRE, but of course we want to make sure the tools we already provide for this are used in the best possible way.

Grüße, Carsten

> Begin forwarded message:
> 
> From: [email-masked] <mailto:[email-masked]>
> Subject: I-D Action: draft-birkholz-yang-push-coap-problemstatement-00.txt
> Date: October 18, 2017 at 18:15:55 GMT+2
> To: <[email-masked] <mailto:[email-masked]>>
> Reply-To: [email-masked] <mailto:[email-masked]>
> Archived-At: <https://mailarchive.ietf.org/arch/msg/i-d-announce/nli8rUCRmvXOzeHlW0h7LPFghE0 <https://mailarchive.ietf.org/arch/msg/i-d-announce/nli8rUCRmvXOzeHlW0h7LPFghE0>>
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : YANG Push Operations for CoMI
>        Authors         : Henk Birkholz
>                          Tianran Zhou
>                          Xufeng Liu
>                          Eric Voit
> 	Filename        : draft-birkholz-yang-push-coap-problemstatement-00.txt
> 	Pages           : 11
> 	Date            : 2017-10-18
> 
> Abstract:
>   This document provides a problem statement, derives an initial gap
>   analysis and illustrates a first set of solution approaches in regard
>   to augmenting YANG data stores based on the CoAP Management Interface
>   with YANG Push capabilities.  A binary transfer mechanism for YANG
>   Subscribed Notifications addresses both the requirements of
>   constrained-node networks and the need for semantic interoperability
>   via self-descriptiveness of the corresponding data in motion.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-birkholz-yang-push-coap-problemstatement/ <https://datatracker.ietf.org/doc/draft-birkholz-yang-push-coap-problemstatement/>
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-birkholz-yang-push-coap-problemstatement-00
> https://datatracker.ietf.org/doc/html/draft-birkholz-yang-push-coap-problemstatement-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 18 Oct 2017 20:30:29 +0200

This is what I call a great problem statement. Thank you!

I have checked the outlined approaches and all of them seem viable to me.

I actually started writing a draft on "configured subscriptions" a
long time ago but never published it because it's really short: "A
server (or proxy in the role of a server) MAY send unsolicited
notifications to a client (or proxy in the role of a client) if the
client's interest in receiving notifications for a resource has been
registered with the server using some out-of-band mechanism (such as
manual configuration or a discovery process)." (This probably needs
another sentence about clients that permanently don't respond or
reject all notifications...)

Klaus

On 18 October 2017 at 19:52, Carsten Bormann <[email-masked]> wrote:
> There is a new I-D with a problem statement and a rough solution outline for
> a gap that would need to be closed to make COMI applicable to an additional
> set of applications.
>
> It is not a particularly long draft.  Some review from CoRE experts might
> help us find the best way forward — this is not a lot of new protocol work
> for CoRE, but of course we want to make sure the tools we already provide
> for this are used in the best possible way.
>
> Grüße, Carsten