Ballot for draft-ietf-dtn-dtnma-14

Comment (2024-02-14 for -10) Sent

# 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

Comment (2024-02-21 for -11) Sent

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.

Comment (2024-02-15 for -10) Sent

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

Discuss [Treat as non-blocking comment] (2024-02-15 for -10) Sent

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.

No Objection (2024-02-13 for -10) Sent

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?

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

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