Skip to main content

DTN Management Architecture
draft-ietf-dtn-dtnma-13

Revision differences

Document history

Date Rev. By Action
2024-03-21
13 Erik Kline Changed action holders to Erik Kline
2024-03-18
13 Liz Flynn Shepherding AD changed to Erik Kline
2024-03-18
13 Edward Birrane New version available: draft-ietf-dtn-dtnma-13.txt
2024-03-18
13 Edward Birrane New version accepted (logged-in submitter: Edward Birrane)
2024-03-18
13 Edward Birrane Uploaded new revision
2024-02-28
12 Edward Birrane New version available: draft-ietf-dtn-dtnma-12.txt
2024-02-28
12 Edward Birrane New version accepted (logged-in submitter: Edward Birrane)
2024-02-28
12 Edward Birrane Uploaded new revision
2024-02-21
11 Roman Danyliw
[Ballot comment]
Thank you for addressing my DISCUSS and most of my COMMENT feedback.

** [Per -10] Section 4.7.  I had trouble understanding the thesis …
[Ballot comment]
Thank you for addressing my DISCUSS and most of my COMMENT feedback.

** [Per -10] Section 4.7.  I had trouble understanding the thesis of this section.  Can the difference between “stand-alone”, “deterministic” and “engine-based” behavior be clarified?  For example, what is the difference between the engine-based behavior having “configurable behavior” without mobile code and stand-along operation having “pre-configuration [which] allows DAs to operate without regular contact with other nodes?

I appreciate the explanation in  https://mailarchive.ietf.org/arch/msg/dtn/ctmHmKmut8hW_KhqslzFm08emDs/ that these three behaviors are complimentary and perhaps overlapping.  This clarification would be useful to add to the document.
2024-02-21
11 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2024-02-19
11 (System) Changed action holders to Zaheduzzaman Sarker (IESG state changed)
2024-02-19
11 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-02-19
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2024-02-19
11 Edward Birrane New version available: draft-ietf-dtn-dtnma-11.txt
2024-02-19
11 Edward Birrane New version accepted (logged-in submitter: Edward Birrane)
2024-02-19
11 Edward Birrane Uploaded new revision
2024-02-15
10 (System) Changed action holders to Edward Birrane, Sarah Heiner, Emery Annis (IESG state changed)
2024-02-15
10 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2024-02-15
10 Robert Wilton
[Ballot discuss]
Hi,

I have concerns with how this document is framed that I think rises to the level of a DISCUSS.

(1) p 0, …
[Ballot discuss]
Hi,

I have concerns with how this document is framed that I think rises to the level of a DISCUSS.

(1) p 0, sec

                      DTN Management Architecture
                        draft-ietf-dtn-dtnma-10

I have raised a discuss because of how this document is framed:

- It explains some of the requirements that are specific to managing devices in DTNs.  For me, the key one really being the unreliable availability of the network meaning synchronous RPCs are not a great idea, and there is a stronger emphasis on remote agents.

- It then critiques the existing IETF network management architecture, but this description seems to be incorrect and inaccurate in various places.

- It then uses that critique as a justification as to why the existing IETF network management solutions cannot be used out of the box to meet the requirements of the DTN architecture.  Whilst I agree that this is true - I also think that with a relatively small amount of work, or enhancements (many of which are in the process of being pursued for other reasons), it would be possible to extend the existing IETF network management architecture to work for DTN.  I.e., I don't regard the existing text in sections 5 and 6 to really justify a new management architecture rather that reusing and extending what is already there.  This doesn't mean that a new architecture is not justified, only that I think that this document currently doesn't really do a good job of making the case.  Hence, I wonder whether the real justification is because the proposed management architecture is much closer to how these devices are managed today and hence it is less of shift in mindset?

- Finally, I haven't reviewed the proposed architecture in great detail, but I think that the command based aspect of it, is potentially inferior to the intent based approach in regular network management architecture, that I believe is a more robust approach.


(2) p 0, sec

  This document describes a DTN management architecture (DTNMA)
  suitable for managing devices in any challenged environment but, in
  particular, those communicating using the DTN Bundle Protocol (BP).
  Operating over BP requires an architecture that neither presumes
  synchronized transport behavior nor relies on query-response
  mechanisms.  Implementations compliant with this DTNMA should expect
  to successfully operate in extremely challenging conditions, such as
  over uni-directional links and other places where BP is the preferred
  transport.

As per my other comments, because I believe that the existing IETF network management architecture already does, or is mostly on the path to supporting many of the requirements, then if a new management architecture is required here, then I think that its scope should be narrowed to only work over the BP protocol.

Specifically, I think that it is much better for the wider industry to converge on using the existing NETCONF/RESTCONF/CORECONF + YANG(XML, JSON, CBOR+/-SIDs) architecture where possible rather than fragmenting to different competing solutions.
2024-02-15
10 Robert Wilton
[Ballot comment]
(3) p 4, sec 1.2.  Requirements Language

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", …
[Ballot comment]
(3) p 4, sec 1.2.  Requirements Language

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in [RFC2119].

Please update this to use the newer requirements text in RFC 8174.


(4) p 18, sec 5.2.  XML-Based Protocols

  Several network management protocols, including NETCONF [RFC6241],
  RESTCONF [RFC8040], and CORECONF [I-D.ietf-core-comi], share the same
  XML information set [xml-infoset] to describe the abstract data model
  necessary to manage the configuration of network devices.  Each
  protocol, however, provides a different encoding of that XML
  information set.

I don't think that it is correct to describe these protocols to be XML based, and to list them under an "XML-Based Protocol" section.

Whilst it was correct that NETCONF and YANG were originally standardised for using XML, they have, or are, all somewhat evolving beyond that:

- YANG already has JSON, and CBOR+/-SIDs encodings in addition to XML.

- RESTCONF is HTML based rather than XML, and already supports XML and JSON encodings of the YANG data, with CBOR surely to follow.

- NETCONF is still XML based, but really the RPCs are defined in YANG, and we are already considering enhancing a future version of NETCONF to support a CBOR based encoding, primarily for streamed operational data.

- CORECONF isn't XML based, but instead uses a CoAP based tight encoding of HTML verbs with CBOR encoding of the YANG data.


(5) p 18, sec 5.2.1.  The YANG Data Model

  *  YANG notifications [RFC8639] and YANG-Push notifications [RFC8641]
      allow a client to subscribe to the delivery of specific containers
      or data nodes defined in the model, either on a periodic or "on
      change" basis.  These notification events can be filtered
      according to XPath [xpath] or subtree [RFC6241] filtering as
      described in [RFC8639] Section 2.2.

Today, some of YANG Push is quite heavy weight, i.e., the resync requirement, and some of the on-change requirements, but I suspect that a future lighter version of YANG Push may happen (that is closer to how gNMI telemetry works).


(6) p 19, sec 5.2.1.  The YANG Data Model

  1.  Size.  Data nodes within a YANG model are referenced by a
      verbose, string-based path of the module, sub-module, container,
      and any data nodes such as lists, leaf-lists, or leaves, without
      any explicit hierarchical organization based on data or object
      type.  Existing efforts to make compressed identifies for YANG
      objects (such as SIDs) are still relatively verbose (~8 bytes per
      item) and do not natively support ways to glob multiple SIDs.

On the wire, I would expect CBOR SIDs to probably average of being 2 bytes each, depending on how the models are structured.  The CBOR SID encoding only encodes the difference between child node SID and its parent node SID, so if the models are structured sensibly, and CBOR SIDs are allocated sensibly, then they will generally only be 1 or 2 bytes long.


(7) p 19, sec 5.2.1.  The YANG Data Model

  2.  Protocol Coupling.  A significant amount of existing YANG tooling
      presumes the use of YANG with a specific management protocol.

I don't think that this is correct.  E.g., OpenConfig uses YANG but doesn't use NETCONF - instead they have defined their own transport protocol using gRPC (called gNMI), which also serves as an alternative to YANG Push.


(8) p 19, sec 5.2.1.  The YANG Data Model

      RPC execution is strictly limited to those issued by the client.

This is basically true but not entirely relevant, in that there is no restriction that a management client cannot be run as an agent on the device.  Some vendor implementations support this, to serve similar purposes desired by this architecture.  I.e., for an agent on the device to act on predicable events that occur on the device without interaction with a main management controller, either for simplicity or latency issues (e.g., take some action within a few msecs of when an interface goes down).


(9) p 19, sec 5.2.1.  The YANG Data Model

        Commands are
      executed immediately and sequentially as they are received by the
      server, and there is no method to autonomously execute RPCs
      triggered by specific events or conditions.

Please see https://www.ietf.org/archive/id/draft-ietf-netmod-eca-policy-01.txt.  This document is adopted, but currently expired.  It would be worth checking with the authors on its current status, but there is already interest in standardising a data model for agents on a device to act as you describe (or at least similarly to what you describe).


(10) p 19, sec 5.2.2.  XML-Based Management Protocols

  NETCONF [RFC6241], RESTCONF [RFC8040], and CORECONF
  [I-D.ietf-core-comi] each provide the mechanisms to install,
  manipulate, and delete the configuration of network devices.  These
  network management protocols use the same XML information set, but
  provide different encodings of the abstract data model it describes.

I don't really understand what you mean by the same XML information set.  The data is modelled in YANG and encoded in XML, JSON, CBOR (with or without SIDs).  Even in the conventional network management space, it is plausible that over time there will be a migration away from XML towards JSON + CBOR.


(11) p 19, sec 5.2.2.1.  NETCONF

  NETCONF is a stateful, XML-based protocol that provides a RPC syntax
  to retrieve, edit, copy, or delete any data nodes or exposed
  functionality on a server.  It requires that underlying transport
  protocols support long-lived, reliable, low-latency, sequenced data
  delivery sessions.

NETCONF is defined and used this way, but I don't think that this has to be its fundamental nature.  E.g., some controllers open a new NETCONF connection to make a configuration change and then close it again, and such are not really relying on any sort of long-lived connection.  Further, the NMDA architecture, RFC 8342, is designed around the concept of decoupling changing the configuration to enacting that configuration change, and monitoring it through subscriptions rather than in the RPC reply.  I.e., the architecture is already migrating towards a path when the synchronous reply to a NETCONF edit operation may not be all that important.


(12) p 20, sec 5.2.2.2.  RESTCONF

  RESTCONF is a stateless RESTful protocol based on HTTP.  RESTCONF
  configures or retrieves individual data elements or containers within
  YANG data models by passing JSON over REST.  This JSON encoding is
  used to GET, POST, PUT, PATCH, or DELETE data nodes within YANG
  modules.

As per above, RESTCONF supports XML or JSON, and very likely CBOR in future, which would likely be a small update.


(13) p 20, sec 5.2.2.2.  RESTCONF

  RESTCONF is a stateless protocol because it presumes that it is
  running over a stateful secure transport (HTTP over TLS).  Also,
  RESTCONF presumes that a single pull of information can be made in a
  single round-trip.  In this way, RESTCONF is only stateless between
  queries - not internal to a single query.

Yes, but mechanisms like YANG Push can somewhat be used to mitigate this.  E.g., already in the gNMI world, there is a move a way from synchronous get requests to asynchronous requests (once or periodic) where the request is made and the results are then streamed back (either to the client, or somewhere else) at some point in the future.  These operations are asynchronous with respect to the caller.


(14) p 21, sec 6.  Motivation for New Features

  Management mechanisms that provide DTNMA desirable properties do not
  currently exist.

This is true - but I still believe that small enhancements, some of which are already planned may well get you to where you need to go without starting from scratch with an entirely new management architecture.


(15) p 21, sec 6.  Motivation for New Features

  1.  Open Loop Control.  Freedom from a request-response architecture,
      API, or other presumption of timely round-trip communications.
      This is particularly important when managing networks that are
      not built over an HTTP or TCP/TLS infrastructure.

As per above, the existing network management architecture supports this by allowing management clients to run on the device (and potentially expose their own North-bound management interfaces).


(16) p 21, sec 6.  Motivation for New Features

  2.  Standard Autonomy Model.  An autonomy model that allows for
      standard expressions of policy to guarantee deterministic
      behavior across devices and vendor implementations.

As per above, there is already some work happening in this area.


(17) p 21, sec 6.  Motivation for New Features

  3.  Compressible Model Structure.  A data model that allows for very
      compact encodings by defining and exploiting common elements of
      data schemas.

As per above, YANG CBOR SIDs already allow for a pretty compact encoding.  This may still be too high for a use case, but there is a clear tradeoff here between flexibility vs encoding size.  E.g., if know the exact schema that is being encoded, and if the server sends all values, then it potentially doesn't need to encode the keys.  But this requires client and server being exactly in sync w.r.t. the data model, so it is probably less resilient to failures.


(18) p 22, sec 7.  Reference Model

  There are a multitude of ways in which both existing and emerging
  network management protocols, APIs, and applications can be
  integrated for use in challenged environments.  However, expressing
  the needed behaviors of the DTNMA in the context of any of these pre-
  existing elements risks conflating systems requirements, operational
  assumptions, and implementation design constraints.

This is true.  But if you want to properly justify why a new architecture is needed, then I still think that it worth looking at what an architecture would look like extending the existing management infrastructure that IETF supports.  Of course, there are benefits in having a targeted architecture specifically for your use-case, but there are also big benefits in reusing much of what is already there, or focussing the changes on the specific pieces that you need (and that then other use cases may also benefit from).


(19) p 23, sec 7.1.  Important Concepts

  The DTNMA differs from some other management architectures in three
  significant ways, all related to the need for a device to self-manage
  when disconnected from a managing device.
  1.  Pre-shared Definitions.  Managing and managed devices should
      operate using pre-shared data definitions and models.  This
      implies that static definitions should be standardized whenever
      possible and that managing and managed devices may need to
      negotiate definitions during periods of connectivity.

This appears to be broadly the same with the regular NETCONF YANG management architecture, and is also one of the goals with the IETF YANG packages and versioning work (https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages).  I.e., so that the device can efficiently share a reference to its schema with a management client without needing to download the full schema for YANG library.


(20) p 23, sec 7.1.  Important Concepts

  2.  Agent Self-Management.  A managed device may find itself
      disconnected from its managing device.  In many challenged
      networking scenarios, a managed device may spend the majority of
      its time without a regular connection to a managing device.  In
      these cases, DAs manage themselves by applying pre-shared
      policies received from managing devices.

As per my previous comments, I think that existing management clients are already starting to do this.  Perhaps a key difference here is that in regular network management, the agents would likely only provide an assistance role than perhaps being the primary configuration management mechanism.


(21) p 23, sec 7.1.  Important Concepts

  3.  Command-Based Interface.  Managing devices communicate with
      managed devices through a command-based interface.  Instead of
      exchanging variables, objects, or documents, a managing device
      issues commands to be run by a managed device.  These commands
      may create or update variables, change data stores, or impact the
      managed device in ways similar to other network management
      approaches.  The use of commands is, in part, driven by the need
      for DAs to receive updates from both remote management devices
      and local autonomy.

Okay, this one we don't do, but then I'm not convinced that it is a great way of managing remote devices.  Mostly, the existing network management is moving towards intent based configuration.  I.e., where the data model expresses the desired configuration state for the device, and the device is responsible, on its own, to take whatever necessary steps are required to transition from the current state to reach that desired state.  It feels to me that this is more robust that sending a sequence of commands, because if the device isn't in the anticipated state, or if some of those commands fail, then it risks leaving the device is an unknown and unexpected state.  I think that sending commands should probably be restricted to fixing stuff when it is broken rather than as a mainline configuration mechanism.
2024-02-15
10 Robert Wilton [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton
2024-02-15
10 Éric Vyncke
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-dtn-dtnma-10

Thank you for the work put into this document. I am afraid that I had …
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-dtn-dtnma-10

Thank you for the work put into this document. I am afraid that I had no time to make a detailed review of such a well-written document (easy to read and understand).

I am balloting ABSTAIN due to the absence of ops-dir review for such a document is concerning; moreover, I was unable to find any mention of this document on the OPSAWG mailing list archive (hoping to be corrected).

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Rick Taylor for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Other thanks to Don Eastlake, the Internet directorate reviewer (at my request), please consider this *very detailed* int-dir review:
https://datatracker.ietf.org/doc/review-ietf-dtn-dtnma-10-intdir-telechat-eastlake-2024-02-14/ (and I have read the quick reply by Ed Birrane, thank you Ed)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Lack of OPS review

The absence of ops-dir review for such a document is concerning. I was unable to find any mention of this document on the OPSAWG mailing list archive (hoping to be corrected).

## Section 1.2

Consider removing it as suggested by another AD: there is little point of having normative language in an informational draft.

## Section 4.4

Isn't there any de/compression algorithms where most of the processing is done by the compressor making the decompressor life easier (e.g., most MPEG encoding if not mistaken).

There are also compression algorithm that do not require a dynamic dictionary to be built, e.g., the outcome of the SCHC WG.

Should the above be mentioned ?

## Section 5.1

I sincerely wonder whether in 2024 the following statement is true `The de facto example of a pull architecture is the Simple Network Management Protocol (SNMP)`.

## Section 5.2.1

In the same vein as the above comment, I also wonder whether the SID encoding of YANG models (and a specific serialisation/encoding of YANG modules can be defined for DTN) is not equivalent to the BER ASN.1 encoding rule. It would be better if this document was quantitative rather than qualitative on this topic.

There is also 'streaming telemetry' using YANG modules, which would fit the "push" model.

## Section 10

Just a remark, the level of details in section 10 seems to be much detailed than in other sections.
2024-02-15
10 Éric Vyncke [Ballot Position Update] New position, Abstain, has been recorded for Éric Vyncke
2024-02-14
10 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2024-02-14
10 John Scudder
[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-dtn-dtnma-10
CC @jgscudder

Thanks for this interesting and well-written document. I have a few questions and …
[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-dtn-dtnma-10
CC @jgscudder

Thanks for this interesting and well-written document. I have a few questions and comments, below.

## COMMENTS

### Section 1.2, boilerplate

Please use the current BCP 14 boilerplate. Alternatively, you could remove the sole use of an RFC 2119 keyword (MUST, in Section 12) and then you'd be able to simply delete Section 1.2.

### Section 4.3 and elsewhere, no state compression?

“Once pushed, information might still be queued pending connectivity of the DA to the network.”

Given the potential network capacity constraints, I'd have thought state compression of some kinds of pending information might be very desirable. Generally, there are categories of information where one wants the latest news, and anything older is OBE, so it's a waste of (scarce!) resources to queue and transmit it. Admittedly “might” implies “... and might not” so the quoted sentence doesn’t preclude anything. Later mentions of “queued” and in particular the second paragraph of Section 8.4 and the example in Section 10.3 lead me to think that state compression may be deliberately excluded, though. Is it?

### Section 4.4, no advantage

“There is no advantage to minimizing node processing time in a challenged network?”

I don’t question that you’ve selected the right tradeoff, but *no* advantage? Surely processing time correlates with energy consumption, and energy may be one of the commodities in short supply?

### Section 4.7, why is initial configuration difficult?

“The initial configuration (and periodic update) of a DA autonomy engine remains difficult in a challenged network”

Why is initial configuration difficult? Presumably at the time of manufacture the DA is not in a challenged environment.

### Section 5.2.1, "glob" is not a well-defined term

“ways to glob multiple SIDs”

Perhaps a less colloquial term than “glob“?

### Section 5.2.2.3, CORECONF ain't as stale as you say

“Currently, the CORECONF draft [I-D.ietf-core-comi] is archived and expired since 2021.”

Appears to no longer be true, there was a new revision 13 March 2023 and four more since then. I think you can delete this paragraph.

### Section 8.4 and elsewhere, (not) associating report with a control/action

At several places throughout the document, you make assertions similar to this one from Section 8.4: “nor should a given report be associated with a specific control or autonomy action on a given managed device”. Why is it important to specifically exclude this? Presumably, if it were deemed useful to know this information, a report could be annotated with it, at its point of production.

### Section 9.5 and elsewhere, command vs. control

I spent a while puzzling over “command” vs “control” before I finally got to the NOTE in Section 9.5. (Even after reading it I’m still having some difficulty internalizing it, but that’s probably on me.) I suggest a forward reference the first time you introduce “command”, maybe from Section 7.1 point 3, and/or introduce a definition in Section 2, possibly with a forward reference from both the “Command” and “Control” definitions to Section 9.5.

While we’re talking about Section 9.5, you use “CTRL” here twice, without definition. Presumably, you just mean “control”, in which case, I suggest so replacing it.

### Section 10.6, notation question

“Further, DM A sends a policy to DA B to report on the value of V0 every second (step 1).”

The notation you've used to show this is,

    |------------------PROD(EDD1&EDD2,V0)-->|        |        |

I would have expected "PROD(1s, V0)", following the model of the other expressions, given you've said in the prose the PROD is time-based ("every second").

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
2024-02-14
10 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2024-02-14
10 Donald Eastlake Request for Telechat review by INTDIR Completed: On the Right Track. Reviewer: Donald Eastlake.
2024-02-13
10 Martin Duke
[Ballot comment]
Thanks to Joe Touch for the TSVART review.

A couple of comments on the use cases:
(10.3) In Figure 4, shouldn't Agent B …
[Ballot comment]
Thanks to Joe Touch for the TSVART review.

A couple of comments on the use cases:
(10.3) In Figure 4, shouldn't Agent B send 3 RPTs in Step 5, instead of 2?

(10.5) What would have if Managers A and B requested the same report from Agent A? Would the agent be expected to provide the same data for robustness, or to only one to preserve resources at the agent?
2024-02-13
10 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2024-02-12
10 Roman Danyliw
[Ballot discuss]
** The text would benefit from a refinement of the explanation of the security boundary of the DTNMA.

Consider the following statements:
(a) …
[Ballot discuss]
** The text would benefit from a refinement of the explanation of the security boundary of the DTNMA.

Consider the following statements:
(a) Section 1.1 says “Network features such as naming, addressing, routing, and security are out of scope of the DTNMA.  It is presumed that any operational network communicating DTNMA messages would implement these services for any payloads carried by that network.”

(b) Section 4.7 says “The DTNMA does not require a specific underlying transport protocol, network infrastructure, or network services.  Therefore, mechanisms for authentication, authorization, and accounting must be present in a      standard way at DAs and DMs to provide these functions if the      underlying network does not.”

(c) Section 7.3.2.3 says “DAs should ensure, when possible, that externally generated data values have the proper syntax (e.g., data type and ranges) and any required integrity and confidentiality.

-- Statement-(a) seems to rule out elements of security as being part of DTNMA.  However, the text subsequently makes various statements about DTNMA ensuring security properties (e.g., statement-(b) and statement-(c))

-- In clarifying this scope, can the distinction between the DTNMA and the “operational network communicating DTNMA” or a “DTNMA implementation” be explained?  Is the operational network part of the architecture? Is an implementation an instantiation of the architecture?  I ask because the following statements also seem to discuss security properties:

Section 8.5 says “It is expected that transport protocols used in any DTNMA implementation support security services such as integrity and confidentiality.”

Section 12 says “As such, security at the transport layer is expected to address the questions of authentication, integrity, and  confidentiality.”
2024-02-12
10 Roman Danyliw
[Ballot comment]
** Section 1.
      |  NOTE: These challenges may be caused by physical impairments
      |  such as long …
[Ballot comment]
** Section 1.
      |  NOTE: These challenges may be caused by physical impairments
      |  such as long signal propagation and frequent link disruption,
      |  or by other factors such as quality-of-service prioritization,
      |  service-level agreements, and other consequences of traffic
      |  management and scheduling.

Could these challenges be caused by an active attacker too?

** Section 1.* What is intent on describing the relationship between DTNA and BP?  There seem to be multiple slightly different statements.  Specifically:

-- Section 1.0 says “However, the DTNMA should operate in any environment in which the Bundle Protocol (BPv7) [RFC9171] is deployed.”

-- Section 1.1 says “The fact that the DTNMA must operate in any environment that deploys BP does not mean that the DTNMA requires the use of BP to operate.”

--  Section 4.1 says “The DTNMA must run in every environment in which BP bundles may be used, even though the DTNMA does not require the use of BP for its transport.”

Is it intentional for the first statement to be weaker statement than the second and third.

** Section 2.  Editorial. Consider harmonizing the implicit definition of DTN management from Section 1 with the one used here.

-- Section 1 says “Device management in these environments must occur without human interactivity, without system-in-the-loop synchronous function, and without requiring a synchronous underlying transport layer.”

-- Section 2 (here) says “DTN Management: Management that does not depend on stateful connections, timely data exchange of management messages, or closed-loop control.”

e.g., “system-in-the-loop synchronous function” vs. “closed-loop control”

** Section 2.
  *  Data Report Schemas: Named, ordered collection of data names that
      represent the schema of a Data Report.

What are “data names”?  I would have expected a data schema to define the format and semantics of the fields of a data report.

** Section 3.1
  *  The existence of external infrastructure, software, systems, or
      processes such as a Domain Name Service (DNS) or a Certificate
      Authority (CA) cannot be guaranteed.

What is “external software”?

** Section 4.1.
      |  NOTE: The DTNMA must run in every environment in which BP
      |  bundles may be used, even though the DTNMA does not require the
      |  use of BP for its transport.

I don’t understand the constraint/requirement this statement is making.  What governs where “BP may used”?  Couldn’t that be “everywhere” meaning the DTNMA needs to also run “everywhere”?

** Section 4.4.  This section seems very vague to the degree of not provide actionable design guidance. How “efficient” is an encoding seems light it might depend entirely on the deployment environment.  It also appears that that there are assumption being made about hardware capabilities (or lack thereof) when discussion the complexity of encoding or use of compression.

** Section 4.4
  There is no advantage to minimizing node processing time in a
  challenged network.

Is there sometimes a relationship between processing time and power use?  Isn’t power usage relevant in challenged networked?

** Section 4.4
      Design strategies for
      |  compact encodings involve using structured data instead of
      |  large hash values, reusable, hierarchical data models, and
      |  exploiting common structures in data models.

Doesn’t the advice here to not use “large hash values, reusable hierarchical data models …” conflict with the guidance in Section 4.2 (“Data models in the DTNMA should allow for the construction of both cohesive models and hierarchically related models.”)

** Section 4.5

  Elements within the DTNMA should be uniquely identifiable so that
  they can be individually manipulated.

-- What is the relationship between then “element” defined here and a “managed device” used in previous definitions?

-- Didn’t Section 1.1 says “Network features such as naming ... are out of scope of the DTNMA.”

** Section 4.5.  Per the algorithm on approximating an associative array lookup, I would have benefit from more text that explained why a universal ID would have helped the situation.

** Section 4.6.  Is the run-time data definition just a design consideration of the schemas being used?

** Section 4.7.  I had trouble understanding the thesis of this section.  Can the difference between “stand-alone”, “deterministic” and “engine-based” behavior be clarified?  For example, what is the difference between the engine-based behavior having “configurable behavior” without mobile code and stand-along operation having “pre-configuration [which] allows DAs to operate without regular contact with other nodes?

** Section 4.7

      |  NOTE: The deterministic automation of the DTNMA can monitor and
      |  control AI/ML management applications on a managed device.
      |  Using multiple levels of autonomy is a well-known method to
      |  balance the flexibility of a highly autonomous system with the
      |  reduced risk of a deterministic system.

I can’t tell if this is an aspiration or required design property of a system.  Can such confidence be asserted generically (i.e., The deterministic automation of the DTNMA can monitor and control AI/ML management applications on a managed device)?  I recommend removing this aside.

** Section 7.3.2.2.
      The
      generation of a report is independent of whether there exists
      any connectivity between a DA and a DM.  It is assumed that
      reports are queued on an agent pending transmit
      opportunities.

What part of the DA is responsible for sending the Reports? 

I observer that Section 7.3.4.2 describing the DM has: “Report Collectors DMs receive reports from DAs in an asynchronous manner. Should there be symmetry?

** Section 7.3.2.
      DAs should
      ensure, when possible, that externally generated data values
      have the proper syntax (e.g., data type and ranges) and any
      required integrity and confidentiality.

-- Is this assurance of integrity and confidentiality before it is pushed to the DM?
-- Are there authenticity checks?

** Section 8.5

** Section 8.5
  It is expected that
  transport protocols used in any DTNMA implementation support security
  services such as integrity and confidentiality.

Is authenticity a relevant security property?  I ask because Section 12 says “… security at the transport layer is expected to address the questions of authentication, integrity, and confidentiality.”?

** Section 9.1

  Determinism allows for the forensic reconstruction of device behavior
  as part of debugging or recovery efforts.

Isn’t determinism also important to ensure predictable behavior?

** Section 9.1

      |  NOTE: The use of predicate logic and a stimulus-response system
      |  does not conflict with the use of higher-level autonomous
      |  function or the incorporation of machine learning.  The DTNMA
      |  recommended autonomy model allows for the use of higher levels
      |  of autonomous function as moderated and controlled by a more
      |  deterministic base autonomy system.


  The DTNMA autonomy model is a rule-based model in which individual
  rules associate a pre-identified stimulus with a pre-configured
  response to that stimulus.

I am having trouble following what multi-tiered autonomy system is being referenced here and where that fits in the DTNMA.  Is that a DA or a DM?  The text below the notes seems to make a statement that the DTNMA autonomy model is rule based.

** Section 12. 

-- Would the data validation role played by the DA (Section 7.3.2.3) be critical to mention here as this would drive action in the “agent autonomy engine”?

-- Section 3.2.1 mentions “support a many-to-many association amongst managing and managed device”.  Is that handled by pre-provisioning or is there some kind of authorization and authentication model where a managed device can always determine who is authorized to manage it?
2024-02-12
10 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2024-02-08
10 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2024-02-07
10 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2024-02-07
10 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Nagendra Nainar was marked no-response
2024-02-01
10 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Donald Eastlake
2024-02-01
10 Brian Haberman Assignment of request for Telechat review by INTDIR to Brian Haberman was rejected
2024-02-01
10 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Brian Haberman
2024-01-31
10 Éric Vyncke Requested Telechat review by INTDIR
2024-01-29
10 Cindy Morgan Placed on agenda for telechat - 2024-02-15
2024-01-29
10 Zaheduzzaman Sarker Ballot has been issued
2024-01-29
10 Zaheduzzaman Sarker [Ballot Position Update] New position, Yes, has been recorded for Zaheduzzaman Sarker
2024-01-29
10 Zaheduzzaman Sarker Created "Approve" ballot
2024-01-29
10 Zaheduzzaman Sarker IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2024-01-29
10 Zaheduzzaman Sarker Ballot writeup was changed
2024-01-29
10 Zaheduzzaman Sarker Changed consensus to Yes from Unknown
2024-01-29
10 Edward Birrane New version available: draft-ietf-dtn-dtnma-10.txt
2024-01-29
10 Edward Birrane New version accepted (logged-in submitter: Edward Birrane)
2024-01-29
10 Edward Birrane Uploaded new revision
2024-01-26
09 (System) Changed action holders to Zaheduzzaman Sarker (IESG state changed)
2024-01-26
09 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-01-26
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2024-01-26
09 Edward Birrane New version available: draft-ietf-dtn-dtnma-09.txt
2024-01-26
09 Edward Birrane New version accepted (logged-in submitter: Edward Birrane)
2024-01-26
09 Edward Birrane Uploaded new revision
2024-01-22
08 (System) Changed action holders to Edward Birrane, Sarah Heiner, Emery Annis (IESG state changed)
2024-01-22
08 Zaheduzzaman Sarker IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2024-01-12
08 Joseph Touch Request for Last Call review by TSVART Completed: Not Ready. Reviewer: Joseph Touch. Sent review to list. Submission of review completed at an earlier date.
2024-01-12
08 Joseph Touch Request for Last Call review by TSVART Completed: Not Ready. Reviewer: Joseph Touch.
2024-01-03
08 Stewart Bryant Request for Last Call review by GENART Completed: Ready. Reviewer: Stewart Bryant. Sent review to list.
2023-12-29
08 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2023-12-21
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2023-12-15
08 David Mandelberg Request for Last Call review by SECDIR Completed: Ready. Reviewer: David Mandelberg. Sent review to list. Submission of review completed at an earlier date.
2023-12-15
08 David Mandelberg Request for Last Call review by SECDIR Completed: Ready. Reviewer: David Mandelberg.
2023-12-15
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to David Mandelberg
2023-12-14
08 Jean Mahoney Request for Last Call review by GENART is assigned to Stewart Bryant
2023-12-13
08 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2023-12-13
08 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dtn-dtnma-08, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dtn-dtnma-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2023-12-13
08 Barry Leiba Request for Last Call review by ARTART is assigned to Pete Resnick
2023-12-12
08 Magnus Westerlund Request for Last Call review by TSVART is assigned to Joseph Touch
2023-12-11
08 Cindy Morgan IANA Review state changed to IANA - Review Needed
2023-12-11
08 Cindy Morgan
The following Last Call announcement was sent out (ends 2023-12-25):

From: The IESG
To: IETF-Announce
CC: draft-ietf-dtn-dtnma@ietf.org, dtn-chairs@ietf.org, dtn@ietf.org, rick.taylor@ori.co, zahed.sarker.ietf@gmail.com …
The following Last Call announcement was sent out (ends 2023-12-25):

From: The IESG
To: IETF-Announce
CC: draft-ietf-dtn-dtnma@ietf.org, dtn-chairs@ietf.org, dtn@ietf.org, rick.taylor@ori.co, zahed.sarker.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DTN Management Architecture) to Informational RFC


The IESG has received a request from the Delay/Disruption Tolerant Networking
WG (dtn) to consider the following document: - 'DTN Management Architecture'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-12-25. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Delay-Tolerant Networking (DTN) architecture describes a type of
  challenged network in which communications may be significantly
  affected by long signal propagation delays, frequent link
  disruptions, or both.  The unique characteristics of this environment
  require a unique approach to network management that supports
  asynchronous transport, autonomous local control, and a small
  footprint (in both resources and dependencies) so as to deploy on
  constrained devices.

  This document describes a DTN management architecture (DTNMA)
  suitable for managing devices in any challenged environment but, in
  particular, those communicating using the DTN Bundle Protocol (BP).
  Operating over BP requires an architecture that neither presumes
  synchronized transport behavior nor relies on query-response
  mechanisms.  Implementations compliant with this DTNMA should expect
  to successfully operate in extremely challenging conditions, such as
  over uni-directional links and other places where BP is the preferred
  transport.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dtn-dtnma/



No IPR declarations have been submitted directly on this I-D.




2023-12-11
08 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2023-12-11
08 Zaheduzzaman Sarker Last call was requested
2023-12-11
08 Zaheduzzaman Sarker Ballot approval text was generated
2023-12-11
08 Zaheduzzaman Sarker Ballot writeup was generated
2023-12-11
08 (System) Changed action holders to Zaheduzzaman Sarker (IESG state changed)
2023-12-11
08 Zaheduzzaman Sarker IESG state changed to Last Call Requested from Publication Requested
2023-12-11
08 Zaheduzzaman Sarker Last call announcement was generated
2023-12-10
08 Edward Birrane New version available: draft-ietf-dtn-dtnma-08.txt
2023-12-10
08 Edward Birrane New version accepted (logged-in submitter: Edward Birrane)
2023-12-10
08 Edward Birrane Uploaded new revision
2023-11-10
07 Rick Taylor
Document History
======================

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it …
Document History
======================

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?
---
Over the course of development of the DTNMA document since its adoption as a WG document in August 2019, the document has received broad working group agreement.



2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?
---
There was no controversy about specific points from within the working group, but external review by the OPs area identified some controversy around naming causing the document to be renamed "Delay-Tolerant Network Management Architecture" from the "Asynchronous Management Architecture".


3. Has anyone threatened an appeal or otherwise indicated extreme discontent?
---
There have been no received threats of appeal or other extreme discontent.



4. For protocol documents, are there existing implementations of the contents of the document?
---
As an informational document, there are no existing implementations. However, there are exiting open-source implementations of protocols conformant to this informational architecture.



Additional Reviews
======================

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.
---
As an informational architecture document, this document does not closely interact with other technologies. However, as a management architecture an early review was requested by the OPS Area. This review was published on 6/26/2023 by Jurgen Schonwalder and can be found at: https://mailarchive.ietf.org/arch/msg/dtn/QQ1lr9r8ytHP7Z7iFHWgzJHYEkA/.

Recommendations from that review were incorporated into the -06 and -07 version of this document.



6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
---
As an informational architecture document, there is no requirement for this review.



7. If the document contains a YANG module..
---
As an informational architecture document, there is no included YANG module.



8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.
---
As an informational architecture document, there is no included formal language.



Document Shepherd Checks
======================

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?
---
Yes.  This document has been extensively discussed, reviewed and reworked in the WG over 4 years.  It's publication is blocking several personal drafts and working group documents. This document covers the architecture for a major working group charter item.



10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?
---
There are no identified common issues relating to either the "Transport" (TSV) or "Operations and Management" (ops) areas.



11a. What type of RFC publication is being requested on the IETF stream?
---
This document is requested to be published as an Informational document.



11b. Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?
---
The information in this document is solely information and not normative. All data tracker attributes reflect this status.



12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79?
---
The three authors of this document confirm that there is no asserion of intellectual property rights.



13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.
---
The document has 3 authors who have each confirmed their willingness to be listed as such.


14. Document any remaining I-D nits in this document.
---
There are no nits on this document.



15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.
---
As an informative document there are no normative references.



16. List any normative references that are not freely available to anyone.
---
As an informative document there are no normative references.



17. Are there any normative downward references...
---
As an informative document there are no normative references.



18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
---
As an informative document there are no normative references.



19. Will publication of this document change the status of any existing RFCs?
---
This document will not change the status of any existing RFC.



20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.
---
As an informational document, there are no registrations identified to be managed by IANA.



21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.
---
As an informational document, there are no registrations identified to be managed by IANA.

2023-11-10
07 Rick Taylor Responsible AD changed to Zaheduzzaman Sarker
2023-11-10
07 Rick Taylor IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2023-11-10
07 Rick Taylor IESG state changed to Publication Requested from I-D Exists
2023-11-10
07 Rick Taylor Document is now in IESG state Publication Requested
2023-11-10
07 Rick Taylor
Document History
======================

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it …
Document History
======================

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?
---
Over the course of development of the DTNMA document since its adoption as a WG document in August 2019, the document has received broad working group agreement.



2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?
---
There was no controversy about specific points from within the working group, but external review by the OPs area identified some controversy around naming causing the document to be renamed "Delay-Tolerant Network Management Architecture" from the "Asynchronous Management Architecture".


3. Has anyone threatened an appeal or otherwise indicated extreme discontent?
---
There have been no received threats of appeal or other extreme discontent.



4. For protocol documents, are there existing implementations of the contents of the document?
---
As an informational document, there are no existing implementations. However, there are exiting open-source implementations of protocols conformant to this informational architecture.



Additional Reviews
======================

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.
---
As an informational architecture document, this document does not closely interact with other technologies. However, as a management architecture an early review was requested by the OPS Area. This review was published on 6/26/2023 by Jurgen Schonwalder and can be found at: https://mailarchive.ietf.org/arch/msg/dtn/QQ1lr9r8ytHP7Z7iFHWgzJHYEkA/.

Recommendations from that review were incorporated into the -06 and -07 version of this document.



6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
---
As an informational architecture document, there is no requirement for this review.



7. If the document contains a YANG module..
---
As an informational architecture document, there is no included YANG module.



8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.
---
As an informational architecture document, there is no included formal language.



Document Shepherd Checks
======================

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?
---
Yes.  This document has been extensively discussed, reviewed and reworked in the WG over 4 years.  It's publication is blocking several personal drafts and working group documents. This document covers the architecture for a major working group charter item.



10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?
---
There are no identified common issues relating to either the "Transport" (TSV) or "Operations and Management" (ops) areas.



11a. What type of RFC publication is being requested on the IETF stream?
---
This document is requested to be published as an Informational document.



11b. Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?
---
The information in this document is solely information and not normative. All data tracker attributes reflect this status.



12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79?
---
The three authors of this document confirm that there is no asserion of intellectual property rights.



13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.
---
The document has 3 authors who have each confirmed their willingness to be listed as such.


14. Document any remaining I-D nits in this document.
---
There are no nits on this document.



15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.
---
As an informative document there are no normative references.



16. List any normative references that are not freely available to anyone.
---
As an informative document there are no normative references.



17. Are there any normative downward references...
---
As an informative document there are no normative references.



18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
---
As an informative document there are no normative references.



19. Will publication of this document change the status of any existing RFCs?
---
This document will not change the status of any existing RFC.



20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.
---
As an informational document, there are no registrations identified to be managed by IANA.



21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.
---
As an informational document, there are no registrations identified to be managed by IANA.

2023-11-09
07 Edward Birrane Notification list changed to rick.taylor@ori.co because the document shepherd was set
2023-11-09
07 Edward Birrane Document shepherd changed to Rick Taylor
2023-11-09
07 Edward Birrane Intended Status changed to Informational from None
2023-11-02
07 Adam Wiethuechter Added to session: IETF-118: dtn  Tue-1200
2023-10-23
07 Sarah Heiner New version available: draft-ietf-dtn-dtnma-07.txt
2023-10-23
07 (System) New version approved
2023-10-23
07 (System) Request for posting confirmation emailed to previous authors: Edward Birrane , Emery Annis , Sarah Heiner , dtn-chairs@ietf.org
2023-10-23
07 Sarah Heiner Uploaded new revision
2023-09-11
06 Edward Birrane IETF WG state changed to In WG Last Call from WG Document
2023-07-21
06 Adam Wiethuechter Added to session: IETF-117: dtn  Wed-1630
2023-07-09
06 Edward Birrane New version available: draft-ietf-dtn-dtnma-06.txt
2023-07-09
06 Edward Birrane New version accepted (logged-in submitter: Edward Birrane)
2023-07-09
06 Edward Birrane Uploaded new revision
2023-03-25
05 Edward Birrane Added to session: IETF-116: dtn  Tue-0030
2023-03-12
05 Sarah Heiner New version available: draft-ietf-dtn-dtnma-05.txt
2023-03-12
05 Sarah Heiner New version accepted (logged-in submitter: Sarah Heiner)
2023-03-12
05 Sarah Heiner Uploaded new revision
2023-01-09
04 Edward Birrane New version available: draft-ietf-dtn-dtnma-04.txt
2023-01-09
04 Edward Birrane New version accepted (logged-in submitter: Edward Birrane)
2023-01-09
04 Edward Birrane Uploaded new revision
2022-10-24
03 Sarah Heiner New version available: draft-ietf-dtn-dtnma-03.txt
2022-10-24
03 Sarah Heiner New version accepted (logged-in submitter: Sarah Heiner)
2022-10-24
03 Sarah Heiner Uploaded new revision
2022-10-05
02 Edward Birrane New version available: draft-ietf-dtn-dtnma-02.txt
2022-10-05
02 Edward Birrane New version accepted (logged-in submitter: Edward Birrane)
2022-10-05
02 Edward Birrane Uploaded new revision
2022-07-10
01 Edward Birrane New version available: draft-ietf-dtn-dtnma-01.txt
2022-07-10
01 Edward Birrane New version accepted (logged-in submitter: Edward Birrane)
2022-07-10
01 Edward Birrane Uploaded new revision
2022-03-06
00 Edward Birrane This document now replaces draft-ietf-dtn-ama instead of None
2022-03-06
00 Edward Birrane New version available: draft-ietf-dtn-dtnma-00.txt
2022-03-06
00 (System) WG -00 approved
2022-03-06
00 Edward Birrane Set submitter to ""Edward J. Birrane" ", replaces to draft-ietf-dtn-ama and sent approval email to group chairs: dtn-chairs@ietf.org
2022-03-06
00 Edward Birrane Uploaded new revision