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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 09 Sep 2021 02:37:21 -0700

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).

(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.

(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.

(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.

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

 - A different data modelling language (i.e., not YANG) is required to model
 asynchronous management data

 - There are no efficient encodings of management data modelled in YANG.

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)

 - In addition to NETCONF, there are also the RESTCONF and CoAP management
 interface protocols that could be considered.

 - YANG Push, RFC 8641, allows for subscriptions to be notified of when data
 changes, or periodic updates.  I.e., entirely push rather than pull.

 - YANG just models data and that should have no bearing on whether the
 protocol mechanisms used to move that data are synchronous or asynchronous.

 - The CBOR and CBOR SID encodings of YANG data encode the data in a compact
 binary format.

---

From: Rick Taylor <[email-masked]>
Date: Mon, 13 Sep 2021 09:33:06 +0000

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:[email-masked]]
> Sent: 09 September 2021 10:37
> To: The IESG
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Robert Wilton's Block on charter-ietf-dtn-01-00: (with BLOCK and
> COMMENT)
> 

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.

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.

> modelling language could cover the DTN use case, or be reasonably extended

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.

> about where that work is done, which would depend on the specific nature

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.

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.

> to the DTN use case, and not framed as a generic asynchronous management

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

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.

>  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.

>  sending the desired configuration to a device and the device enacting that

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).

>  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.

>  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"

>  protocol mechanisms used to move that data are synchronous or

Completely agree.

>  - The CBOR and CBOR SID encodings of YANG data encode the data in a

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.

Cheers,

Rick

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 14 Sep 2021 11:45:14 +0000

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.

> From: Rick Taylor <[email-masked]>
> Sent: 13 September 2021 10:33
> To: Rob Wilton (rwilton) <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]
> 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...
> 
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> >
> > 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
> >
> >
> > 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:
> 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.
> 
> >
> 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.

> >  - 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

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 14 Sep 2021 13:35:59 +0000

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

> From: Rob Wilton (rwilton) <[email-masked]>
> Sent: Tuesday, September 14, 2021 7:45 AM
> To: Rick Taylor <[email-masked]>; The IESG <[email-masked]>
> Subject: [EXT] RE: Robert Wilton's Block on charter-ietf-dtn-01-00: (with
> BLOCK and COMMENT)
> 
> APL external email warning: Verify sender [email-masked] before clicking
> links or attachments
> 
> Hi Rick,
> 
> 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:
> 
> - 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.
> 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.
> 
> 
> > 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...
> >
> > > 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.)
> > >
> > >
> > >
> > > 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.
> > 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.
> 
> 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.
> 
> >
> > >
> > > 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.
> 
> > > (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.
> >
> > 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.
> 
> >
> > >
> > > 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
> > >
> > >
> > > Asynchronous Management Architecture (which is in DTN WGLC), it
> > > seems to be built on the following assumptions:
> > 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.
> >
> > >
> Yes, but as above, there has already been some interest in whether adding a
> binary encoding to NETCONF could make sense.
> 
> 
> >
> > >
> > > 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).
> 
> 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.
> 
> 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.
> 
> 
> >
> > >
> > 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.
> YANG Push is the latter, i.e., either a receiver, or through configuration, a
> client makes a subscription on the server that says:
> 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.
> 
> >
> > >
> > 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.
>

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Thu, 16 Sep 2021 10:21:32 +0000

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." <[email-masked] on behalf of [email-masked]> wrote:

    Rob, Rick,

      -Ed

    ---

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 21 Sep 2021 13:33:51 +0000

Zahed,

  This all sounds very reasonable to me.

-Ed

---

> From: Zaheduzzaman Sarker <[email-masked]>
> Sent: Thursday, September 16, 2021 6:22 AM
> To: Birrane, Edward J. <[email-masked]>; Rob Wilton (rwilton)
> <[email-masked]>; Rick Taylor <[email-masked]>; The
> IESG <[email-masked]>
> Subject: [EXT] Re: Robert Wilton's Block on charter-ietf-dtn-01-00: (with
> BLOCK and COMMENT)
> 
> APL external email warning: Verify sender
> [email-masked] 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-
> [email-masked] on behalf of [email-masked]> wrote:
> 
>     Rob, Rick,
> 
>       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:
> 
>       - Very terse encodings. I get significant push back adding just 1-2 bytes to
> an entire message, much less a single ID.
> 
>       - 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
> 
>     ---
>     > - Documenting the specific requirements for network management in
> DTN
>     > networks.
>     >  - encode them efficiently (because CBOR encodes smaller numbers in
> less
>     > bytes).
>     >

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 24 Sep 2021 10:29:01 +0000

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. <[email-masked]> 
Sent: 21 September 2021 14:34
To: Zaheduzzaman Sarker <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>; Rick Taylor <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: Robert Wilton's Block on charter-ietf-dtn-01-00: (with BLOCK and COMMENT)

Zahed,

-Ed

---

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Fri, 24 Sep 2021 10:34:02 +0000

Thanks Rob, thanks Ed.

Then we should proceed to execute this plan.

BR
Zahed

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

    Hi Zahed,

    Regards,
    Rob

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

    Zahed,

    -Ed

    ---