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

[Rick Taylor <[e-mail]>]

Hi All,

+1 to "DTN Management Architecture"

Rick

> -----Original Message-----
> From: Birrane, Edward J. [mailto:[e-mail]]
> Sent: 02 November 2021 16:12
> To: Rob Wilton (rwilton); Zaheduzzaman Sarker; Rick Taylor; The IESG
> Cc: [e-mail]; [e-mail]
> Subject: RE: Robert Wilton's Block on charter-ietf-dtn-01-00: (with BLOCK and
> COMMENT)
> 
> Rob,
> 
>   Yes, I'm happy to rename this, and we are working on some names that
> better reflect the challenged/DTN environment. For the charter, I think just
> saying DTN Management Architecture is a fine placeholder.
> 
> -Ed
> 
> 
> -----Original Message-----
> From: Rob Wilton (rwilton) <[e-mail]>
> Sent: Tuesday, November 2, 2021 12:10 PM
> To: Zaheduzzaman Sarker <[e-mail]>; Birrane,
> Edward J. <[e-mail]>; Rick Taylor
> <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [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] before clicking
> links or attachments
> 
> 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]>
> Sent: 30 October 2021 20:15
> 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,
> 
> 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]> 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]>
>     Sent: 21 September 2021 14:34
>     To: Zaheduzzaman Sarker <[e-mail]>; Rob
> Wilton (rwilton) <[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)
> 
>     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]>
>     > Sent: Thursday, September 16, 2021 6:22 AM
>     > To: Birrane, Edward J. <[e-mail]>; Rob Wilton
> (rwilton)
>     > <[e-mail]>; Rick Taylor <[e-mail]>;
> The
>     > IESG <[e-mail]>
>     > Cc: [e-mail]; [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] 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] on behalf of [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]>
>     >     > Sent: Tuesday, September 14, 2021 7:45 AM
>     >     > To: Rick Taylor <[e-mail]>; The IESG
>     > <[e-mail]>
>     >     > Cc: [e-mail]; [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] 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]>
>     >     > > Sent: 13 September 2021 10:33
>     >     > > To: Rob Wilton (rwilton) <[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,
>     >     > >
>     >     > > 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]; [e-mail];
> [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
>