Re: [dtn] Robert Wilton's Block on charter-ietf-dtn-01-00: (with BLOCK and COMMENT)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Ed, Zahed,

Yes, that works for me.

Thanks,
Rob


From: Zaheduzzaman Sarker <[e-mail]>
Sent: 02 November 2021 16:20
To: Rob Wilton (rwilton) <[e-mail]>; Birrane, Edward J. <[e-mail]>; Rick Taylor <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: Robert Wilton's Block on charter-ietf-dtn-01-00: (with BLOCK and COMMENT)

Hi Rob,

For now I think just changing to “DTN Management Architecture”, will do the trick here. Later the WG can come up with more appropriate names to the technologies required to be extend or designed.

Will that work??

BR
Zahed

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, November 2, 2021 6:09:57 PM
To: Zaheduzzaman Sarker <[e-mail]<mailto:[e-mail]>>; Birrane, Edward J. <[e-mail]<mailto:[e-mail]>>; Rick Taylor <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: Robert Wilton's Block on charter-ietf-dtn-01-00: (with BLOCK and COMMENT)

Hi Zahed,

Looks good to me.

For the milestones, please rename "Asynchronous Management Architecture" to something closer to "Path Delay/Disruption Tolerant Management Architecture".

The key point being that the "regular" network management architectures are already evolving in an eventual consistency and asynchronous messages direction.  E.g., push based telemetry is becoming preferred to synchronous get requests (because it perceived to give better performance and more immediate data).  Netconf requests are currently synchronous w.r.t. to updating the candidate/running configuration datastores, but there is no strong reason why this has to be case.  Many devices also synchronously (or even semi-synchronously apply the configuration), but the protocol does not mandate or require this, and NMDA (RFC 8342) leans in the direction of the configuration being applied asynchronously.

Thanks,
Rob


-----Original Message-----
From: Zaheduzzaman Sarker <[e-mail]<mailto:[e-mail]>>
Sent: 30 October 2021 20:15
To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>; Birrane, Edward J. <[e-mail]<mailto:[e-mail]>>; Rick Taylor <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Robert Wilton's Block on charter-ietf-dtn-01-00: (with BLOCK and COMMENT)

Hi Rob,

I think the updated rechartering text (https://datatracker.ietf.org/doc/charter-ietf-dtn/ ) addresses your comments and reflects the way forward. Please have a look.

BR
Zahed

On 2021-09-24, 12:29, "Rob Wilton (rwilton)" <[e-mail]<mailto:[e-mail]>> wrote:

    Hi Zahed,

    Sorry for the delayed response, but yes, I think that this is a good way forward.

    Regards,
    Rob


    -----Original Message-----
    From: Birrane, Edward J. <[e-mail]<mailto:[e-mail]>>
    Sent: 21 September 2021 14:34
    To: Zaheduzzaman Sarker <[e-mail]<mailto:[e-mail]>>; Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>; Rick Taylor <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>
    Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
    Subject: RE: Robert Wilton's Block on charter-ietf-dtn-01-00: (with BLOCK and COMMENT)

    Zahed,

      This all sounds very reasonable to me.

    -Ed


    ---
    Edward J. Birrane, III, Ph.D. (he/him/his)
    Embedded Applications Group Supervisor
    Space Exploration Sector
    Johns Hopkins Applied Physics Laboratory
    (W) 443-778-7423 / (F) 443-228-3839


    > -----Original Message-----
    > From: Zaheduzzaman Sarker <[e-mail]<mailto:[e-mail]>>
    > Sent: Thursday, September 16, 2021 6:22 AM
    > To: Birrane, Edward J. <[e-mail]<mailto:[e-mail]>>; Rob Wilton (rwilton)
    > <[e-mail]<mailto:[e-mail]>>; Rick Taylor <[e-mail]<mailto:[e-mail]>>; The
    > IESG <[e-mail]<mailto:[e-mail]>>
    > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
    > Subject: [EXT] Re: Robert Wilton's Block on charter-ietf-dtn-01-00: (with
    > BLOCK and COMMENT)
    >
    > APL external email warning: Verify sender
    > [e-mail]<mailto:[e-mail]> before clicking links or attachments
    >
    > Hi All,
    >
    > Thanks to Rob for his great review and to Rick , Ed for their responses to the
    > comments. I think things got a bit clarified and I would like to propose
    > multiple actions to way forward -
    >
    > - clearly there are some confusions on what is specific to DTN and what can
    > be solved with existing technologies. I am sure in DTN we don't want to come
    > up with a generic solution problem for the OPS. Hence,  we write clear text in
    > the charter that DTN will only focus on issues related specifically to DTN and
    > will constantly consult with NETCONF and NETMOD to analyze the solution
    > based on DTN requirements.
    >
    > - for AMA draft, we take it back to the WG, update with gap analysis and
    > specify DTN requirements. It might also be the case that the term
    > "asynchronous" is creating some confusion, I may need some bikeshedding.
    > Even this document has been worked under the current charter, we
    > continue the work under the new charter and use this document to
    > communicate the DTN requirement with OPS area. So this goes under a new
    > work item.
    >
    > - The new charter takes on naming, addressing and OPS topics, hence it is
    > better that we have eyes from the experts on those from early on. For that
    > in DTN, we make the "early review" a habit.  Also try to recruit WG
    > consultant/advisor(s) from OPS, Routing and INT area if possible. We have
    > been talking with those area experts in the previous occasions hence we
    > might already have an idea who the advisors could be. I can work with the
    > chairs and other ADs for finding interested experts. Another way to find
    > them could be that we work on gap analysis and requirements and then have
    > a joint interim with OPS and other related areas. Then we also have fair
    > chance to see the interests from other areas and get opinions straight.
    >
    > - Routing is still out of scope of the current charter, but we point in the
    > charter that we will be talking with rtgwg, when we discuss topics that relate
    > to routing.
    >
    > If this plan sounds reasonable then I will work the DTN chair to reflect this in
    > the charter text. So, please send your opinion(s).
    >
    > BR
    > Zahed
    >
    >
    > On 2021-09-14, 15:36, "iesg on behalf of Birrane, Edward J." <iesg-
    > [e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:
    >
    >     Rob, Rick,
    >
    >       Thank you for this discussion, and my apologies for not being able to
    > chime in sooner.
    >
    >       Rob brings up an excellent point, which is that the "gap analysis" portion
    > of the existing AMA document was written prior to the standardization of
    > RESTConf, changes to YANG for IoT, COAP, and others.   However, we have
    > been tracking those changes and (we think) we understand where our needs
    > are unique in the DTN community.
    >
    >       Some of our devices are very, very low on resources. Not simply "IoT"
    > devices, but distributed sensors with environmental energy harvesting,
    > spacecraft, and microcontrollers. In these cases, lack of compute and lack of
    > regular power/comms is what makes their operation require delay-
    > disruption tolerance.  We are quite excited, still, about the novelty of some
    > of our approach in the areas of:
    >
    >       - No end-to-end communication. Once configured, a node needs to
    > manage itself.
    >       - A predicate autonomy model (time and state) and not based on
    > scripting.
    >       - Very terse encodings. I get significant push back adding just 1-2 bytes to
    > an entire message, much less a single ID.
    >
    >       Which is not to say we can't have areas of cooperation and coordination!
    >
    >       - I know of at least one group that is using COAP to carry AMP messages -
    > they are solving different parts of the problem.
    >       - A masters thesis a few years back was done on the differences between
    > the "AMP" model and the YANG module, and that student build a YANG-
    > AMP bridge and demonstrated it at IETF104
    > (https://datatracker.ietf.org/meeting/104/materials/slides-104-dtn-
    > ampnetconf-interop-01).
    >       - There was some effort put into a YANG model of some of the AMP work
    > (https://datatracker.ietf.org/doc/html/draft-bsipos-dtn-amp-yang-01)
    >
    >       Some of these are, of course, dated. But... I am fairly confident that as we
    > go forward we can better identify and deconflict the parts of this approach
    > which are unique to the DTN community.  As Rick mentioned, when we
    > engaged with other working groups, the message we received at the time
    > was that the work was interesting, but very niche and not something
    > particularly applicable outside of the DTN community. And I don't think that
    > overall sentiment has changed - this is a common DTN management
    > problem, but not a common network management problem.
    >
    >       For the charter and initial work, I suggest a few things to help us be much
    > more clear about how to avoid any kind of duplication or inefficiency:
    >
    >       1. The AMA document needs a refresh to include an improved "gap
    > analysis" of items that came up in the past few years. When we had originally
    > written AMA we moved on to other work but this is a great place to coalesce
    > our understanding. I suggest the re-write of the AMA get early OPs review.
    >
    >       2. Clarifications to the charter text that any management work on DTNs is
    > done in ways which are unique to DTN problems and not in areas where
    > existing mechanisms are sufficient. DTN really does have unique problems
    > and I think it would not take very long to clarify them.
    >
    >       3. Clear text in the charter of example working groups that should be
    > included in these communications. It has always been our intention (and
    > desire!) to get more OPs area expertise in understanding our constrained
    > approach. We have, to date, been far less successful in getting our approach
    > seen as having enough impact outside of DTN to warrant significant cycles
    > from other groups who are, understandably, quite busy.
    >
    >       -Ed
    >
    >     ---
    >     Edward J. Birrane, III, Ph.D. (he/him/his)
    >     Embedded Applications Group Supervisor
    >     Space Exploration Sector
    >     Johns Hopkins Applied Physics Laboratory
    >     (W) 443-778-7423 / (F) 443-228-3839
    >
    >
    >
    >     > -----Original Message-----
    >     > From: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>
    >     > Sent: Tuesday, September 14, 2021 7:45 AM
    >     > To: Rick Taylor <[e-mail]<mailto:[e-mail]>>; The IESG
    > <[e-mail]<mailto:[e-mail]>>
    >     > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
    >     > Subject: [EXT] RE: Robert Wilton's Block on charter-ietf-dtn-01-00: (with
    >     > BLOCK and COMMENT)
    >     >
    >     > APL external email warning: Verify sender [e-mail]<mailto:[e-mail]> before
    > clicking
    >     > links or attachments
    >     >
    >     > Hi Rick,
    >     >
    >     > Thanks for the extra information.
    >     >
    >     > I've put some more comments inline ...
    >     >
    >     > Bringing my conclusion to the top, for this DTN charter cycle I would
    > suggest
    >     > that it would be helpful for the management aspects of DTN to focus on:
    >     >
    >     > - Documenting the specific requirements for network management in
    > DTN
    >     > networks.
    >     > - Understanding what aspects of those requirements are not met by
    > current
    >     > network management protocols (NETCONF, RESTCONF, CORECONF),
    > YANG.
    >     > - An understanding of whether it would be feasible to extend the
    > existing
    >     > network management protocols to cover those requirements.
    >     > - Good communication with NETCONF, NETMOD, and CORE WGs as these
    >     > requirements are developed.
    >     >
    >     > I think that once the shape of the solution is better understood it will
    >     > become clear how specific the solution is to DTN and also where is the
    > best
    >     > place to progress the work.
    >     >
    >     >
    >     > > -----Original Message-----
    >     > > From: Rick Taylor <[e-mail]<mailto:[e-mail]>>
    >     > > Sent: 13 September 2021 10:33
    >     > > To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>; The IESG
    > <[e-mail]<mailto:[e-mail]>>
    >     > > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
    >     > > Subject: RE: Robert Wilton's Block on charter-ietf-dtn-01-00: (with
    >     > > BLOCK and
    >     > > COMMENT)
    >     > >
    >     > > Hi Rob,
    >     > >
    >     > > Thanks for the comments.  I think your block is justified as we need
    >     > > to have this discussion, and hopefully I can clarify a few points.
    >     > >
    >     > > Comments inline...
    >     > >
    >     > > > -----Original Message-----
    >     > > > From: Robert Wilton via Datatracker [mailto:[e-mail]]
    >     > > > Sent: 09 September 2021 10:37
    >     > > > To: The IESG
    >     > > > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
    >     > > > Subject: Robert Wilton's Block on charter-ietf-dtn-01-00: (with
    >     > > > BLOCK and
    >     > > > COMMENT)
    >     > > >
    >     > > > Robert Wilton has entered the following ballot position for
    >     > > > charter-ietf-dtn-01-00: 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-dtn/
    >     > > >
    >     > > >
    >     > > >
    >     > > > --------------------------------------------------------------------
    >     > > > --
    >     > > > BLOCK:
    >     > > > --------------------------------------------------------------------
    >     > > > --
    >     > > >
    >     > > > Sorry for putting a block on this charter, but the charter for this
    >     > > > WG seems to be moving significantly into the network management
    >     > space.
    >     > > >
    >     > > > In particular, this work seems to be predicated on the assumption
    >     > > > that it better to define a custom management protocol and data
    >     > > > modelling language for the DTN use case rather than reusing, or
    >     > > > extending, the existing network management work defined in
    > NETMOD
    >     > > > and NETCONF
    >     > > WGs.
    >     > > > This may be the right answer, but it not intuitively obvious to me
    >     > > > that this is the case (some further details provided in the comment
    >     > > > section).
    >     > >
    >     > > I think you're half right here.  We have evidence that management
    >     > > protocols designed for an end-to-end connected environment do not
    > work
    >     > > in a deeply delayed/disrupted network.  For example the New Horizons
    >     > > probe floating past Pluto runs a management stack that is a precursor
    >     > > to the work we are attempting to standardise in the WG.  That being
    >     > > said, although the existing OPS area protocols appear unsuitable, the
    >     > > data-modelling is most definitely not.
    >     >
    >     > Okay.
    >     >
    >     > I think that it would really helpful to enumerate what the DTN specific
    >     > network management requirements, and whether they can be sensibly
    >     > satisfied by extending the existing network management protocols,
    > noting
    >     > that there has already been some interest in extending network
    >     > management protocols to support asynchronous messages (but these
    > would
    >     > probably still expect to see responses in the order of minutes rather than
    >     > hours).
    >     >
    >     > >
    >     > > What we would like to do is to re-use all the great work from NETMOD,
    >     > > but use an alternate transport and processing model more suitable for
    >     > > end-to- end disconnected environments.  We are all absolutely agreed
    >     > > that this does not mean discarding/ignoring all of NETCONF/NETMOD
    > and
    >     > > rolling our own management stack, but it does mean some parts have
    > to be
    >     > different.
    >     >
    >     > Some parts being different is fine/expected.
    >     >
    >     > But I'm still not quite sure whether what you require for the DTN use
    > case
    >     > couldn't be accomplished by say extending NETCONF to support
    >     > asynchronous messages, and a binary encoding, and a delay tolerant
    >     > transport.  Also, with Alvaro mentioning MANET, I'm trying to understand
    >     > whether what is being proposed is specific to DTN, or more general.
    >     >
    >     > Note, the desire to add asynchronous configuration operations has come
    > up
    >     > before for NETCONF in draft-ietf-netmod-opstate-reqs-04 (also
    > referenced
    >     > below).
    >     > There have also been some discussions about adding binary encoding
    >     > support to NETCONF (draft-mahesh-netconf-binary-encoding-01).
    >     >
    >     > I.e., it looks like there is already some interest is enhancing NETCONF to
    >     > cover some of your requirements, but it is not clear to me whether that
    >     > would mean that NETCONF would cover all of them.
    >     >
    >     > >
    >     > > >
    >     > > > (1) There needs to be more discussion with relevant WGs (NETCONF,
    >     > > > NETMOD, CORE) to understand whether the existing network
    >     > management
    >     > > > protocols and data modelling language could cover the DTN use case,
    >     > > > or be reasonably extended to do so.
    >     > >
    >     > > Yes, there does.  We have attempted to engage with those groups, but
    >     > > as with all IETF WG's they are busy and focussed on their own topics,
    >     > > and turning up with a weird corner cases is disruptive.  Ed and I have
    >     > > had extensive discussions with Dean Bogdanovic over the years, which
    >     > > has helped us understand what is re-useable and what is not - and
    >     > > there is a great deal of cross over with the timed/event-driven config
    >     > > change proposals that reappear constantly in NETMOD - however, we
    > have
    >     > > failed to attract enough attention to get the work adopted within the
    > OPS
    >     > area.
    >     >
    >     > I think that providing regular updates to NETMOD and perhaps
    >     > NETCONF/OPSAWG would be helpful.
    >     >
    >     > >
    >     > > >
    >     > > > (2) If there is consensus that the existing IETF management stack
    >     > > > can be reasonably extended to cover the DTN use case, then there
    >     > > > should be discussion about where that work is done, which would
    >     > > > depend on the specific nature of the work.
    >     > >
    >     > > The same argument has been put forward by Alvaro concerning
    > Routing in
    >     > > DTNs.  Yes, there is definite cross-over here, however, we have a
    >     > > really productive (small) WG that is focussed and keen to continue
    >     > > working on these topics, and would rather not dilute the enthusiasm by
    >     > > moving this work into another area.  This does not preclude constant
    >     > > communication and peer-review with the relevant WGs in other areas,
    >     > > but we believe for this charter cycle the authoring should remain in
    >     > > the DTN WG, even if Transport isn't really the correct area.  In the
    >     > > future, yes, let's split the work into the correct areas, but
    >     > > currently we do not have the huge interest to support such
    > fragmentation.
    >     >
    >     > I find it hard to know where the work should be done, because I don't
    > have a
    >     > good feel about what shape the solution should take.
    >     >
    >     > >
    >     > > To this end, we are adding a mandate to the end of the charter to
    >     > > force the WG to work closely with the relevant areas on each
    >     > > cross-over topic, and for management that is definitely NETMOD.
    >     >
    >     > I think that this will be NETMOD for the use of YANG, and possible
    > NETCONF
    >     > for your new management protocols, or extensions to the existing
    > NETCONF
    >     > management protocols.
    >     >
    >     > >
    >     > > >
    >     > > > (3) Otherwise, if the consensus is that an entirely separate
    >     > > > management stack is appropriate, then I think that the solution
    >     > > > needs to be tightly constrained to the DTN use case, and not framed
    >     > > > as a generic asynchronous management architecture.
    >     > >
    >     > > We don't believe it is appropriate, and I am actively pushing back
    >     > > against a bespoke solution for DTNs.  We must be able to re-use YANG
    >     > > modelling, and best-practice from NETCONF, even if XML-over-SSH is
    > not
    >     > > the correct transport.  In my mind AMA could be rebranded as
    > DTNCONF:
    >     > > fundamentally the round-trip time and the transport is the issue - the
    >     > > rest is 'just' good old data modelling.
    >     > >
    >     > > >
    >     > > > Rob
    >     > > >
    >     > > >
    >     > > > --------------------------------------------------------------------
    >     > > > --
    >     > > > COMMENT:
    >     > > > --------------------------------------------------------------------
    >     > > > --
    >     > > >
    >     > > > Looking at the charter, and specifically at draft-ietf-dtn-ama-01,
    >     > > > Asynchronous Management Architecture (which is in DTN WGLC), it
    >     > > > seems to be built on the following assumptions:
    >     > > >  - network management is generally synchronous
    >     > >
    >     > > Not necessarily 'synchronous', that might have been a bad choice of
    >     > > word, but definitely end-to-end connected:  I can send 'do this' and
    >     > > pretty promptly I can get an acknowledgement.  In a DTN, this
    > assumption
    >     > does not hold.
    >     >
    >     > I believe that some network management architecture for managing
    > 'regular'
    >     > networks is effectively also moving in this direction.
    >     >
    >     > E.g., if a controller is trying to update the configuration for 10k devices,
    > then
    >     > trying to manage that a distributed transaction, or synchronously update
    >     > each device, isn't the best model.
    >     >
    >     >
    >     > >
    >     > > >
    >     > > >  - A different data modelling language (i.e., not YANG) is required
    >     > > > to model  asynchronous management data
    >     > >
    >     > > Fair criticism.  The original work was done in isolation and was based
    >     > > on an SNMP-like approach.  Since then much work has gone into
    > moving
    >     > > to a more NETMOD transactional approach, but there is still work to
    >     > > do.  At their core the current drafts expect a tree-like data model
    >     > > that can be modified, so mapping to YANG is entirely feasible, and
    >     > > this an area where we definitely need help.
    >     > >
    >     > > >
    >     > > >  - There are no efficient encodings of management data modelled in
    >     > YANG.
    >     > >
    >     > > I'm not sure this is correct.  I think the original authors looked at
    >     > > NETCONF
    >     > > 1.0 and worried when they saw lots of XML on the wire.
    >     >
    >     > Yes, but as above, there has already been some interest in whether
    > adding a
    >     > binary encoding to NETCONF could make sense.
    >     >
    >     >
    >     > >
    >     > > >
    >     > > > But I don't think that these assumptions necessarily hold:
    >     > > >  - NMDA, RFC 8342, was architected with a goal of supporting an
    >     > > > eventual  consistency model (specifically, supporting a temporal
    >     > > > separation between  sending the desired configuration to a device
    >     > > > and the device enacting that
    >     > > >  configuration)
    >     > >
    >     > > We (I) am unaware of this work, and I suppose that underlines the
    > need
    >     > > for better communication between the WGs.  This 'temporal
    > separation'
    >     > > is an important part of management in DTNs (where the round-trip
    > time
    >     > > may be hours), but there is a need for autonomy as well which may go
    >     > > further that RFC 8342 (I need to go read it).
    >     >
    >     > I would suggest that you also have a look at:
    >     > draft-openconfig-netmod-opstate-01 - the background precursor to this
    >     > work draft-ietf-netmod-opstate-reqs-04, which also covered
    > requirements
    >     > for asynchronous configuration operations.
    >     >
    >     > If you have questions on this, then let me know.
    >     >
    >     >
    >     > >
    >     > > >
    >     > > >  - In addition to NETCONF, there are also the RESTCONF and CoAP
    >     > > > management  interface protocols that could be considered.
    >     > >
    >     > > We have looked at both RESTCONF and CoAP.  RESTCONF suffers the
    > same
    >     > > problems as NETCONF because it requires a bidirectional end-to-end
    >     > > connection, but the CBOR encodings in CoAP are really useful - the
    >     > > numbering system is odd, but there is a lot that can be reused.
    >     >
    >     > The key points of the numbering system is:
    >     >  - scope the IDs globally rather than relative to the parent.
    >     >  - encode them efficiently (because CBOR encodes smaller numbers in
    > less
    >     > bytes).
    >     >
    >     > In theory, for streaming telemetry data, you could end up sending this as
    > a
    >     > set of tuples of the form (global-id, keys, value), where the global-id
    >     > represents the path, the keys are to any list items in the path from the
    > root
    >     > of the schema to the leaf being returned.
    >     >
    >     >
    >     > >
    >     > > >
    >     > > >  - YANG Push, RFC 8641, allows for subscriptions to be notified of
    >     > > > when data  changes, or periodic updates.  I.e., entirely push rather
    >     > > > than
    >     > > pull.
    >     > >
    >     > > We have spent a lot of time with Eric Voit as he was first proposing
    >     > > YANG- Push.  The concepts are similar, and there are lots of parts
    >     > > that can be re- used, but it's more of a 'call me back when something
    >     > changes' model (i.e.
    >     > > just restarting the end-to-end connection) than what is needed in a
    > DTN.
    >     > > What we really need is YANG-Post, i.e. "send me a mail when
    > something
    >     > > happened, telling me what you just did"
    >     >
    >     > YANG Push is the latter, i.e., either a receiver, or through configuration, a
    >     > client makes a subscription on the server that says:
    >     >  - send me the new data, whenever any of these data nodes (or their
    >     > children) change (perhaps dampened)
    >     >  - or periodically send me the new data for these data nodes (or their
    >     > children).
    >     >
    >     > A client would not be expected to make a get request when it is notified
    > of
    >     > new data, there is no need, since the notifications already contain all of
    > the
    >     > relevant data.  Putting aside the underlying transport, the data flow from
    >     > server to the receivers is logically asynchronous, it is just a stream of data.
    >     >
    >     > >
    >     > > >
    >     > > >  - YANG just models data and that should have no bearing on whether
    >     > > > the  protocol mechanisms used to move that data are synchronous or
    >     > > > asynchronous.
    >     > >
    >     > > Completely agree.
    >     > >
    >     > > >
    >     > > >  - The CBOR and CBOR SID encodings of YANG data encode the data in
    > a
    >     > > > compact  binary format.
    >     > >
    >     > > Completely agree. I personally think the CBOR-SID numbering is a bit
    >     > > weird for IOT reasons, but there is definite opportunities to align.
    >     > > The DTN stack is built on CBOR, so it should be a no-brainer.
    >     > >
    >     > > In conclusion:  I think you raise a good list of points that should be
    >     > > discussed before anything DTN management related is standardised.
    >     > > Some we have considered, some we have not, but either way we must
    >     > make
    >     > > sure that there is good communication and peer-review between the
    >     > > WGs/Areas.  As I've said above, purely to keep up the good
    > momentum we
    >     > > have in the current DTN WG, I do not want to split the work out - but
    >     > > it should be considered when the WG next re-charters.  In the
    > meantime
    >     > > we will mandate that the management documents must receive early
    >     > > review by the OPS area, and the chairs will ensure that WG does not
    >     > > disappear off to make bespoke management solutions, as long as the
    >     > > relevant OPS Area WGs can find the cycles to help us avoid mistakes?
    >     > > Ironically Alvaro has also expressed an interest in seeing the AMA
    >     > > work done in the Routing Area, as it addresses some charter items for
    >     > > the MANET working group - so we really are spanning many areas here
    > -
    >     > > but I firmly believe we need to grow more before we can consider
    >     > reorganisation.
    >     >
    >     > Yes, hopefully that aligns somewhat with my suggestion at the top of my
    >     > reply?
    >     >
    >     > Thanks,
    >     > Rob
    >     >
    >     >
    >     > >
    >     > > Cheers,
    >     > >
    >     > > Rick