Re: [dtn] Concluding IETF last call on DTN

[Brian Sipos <[e-mail]>]

Magnus,
One last minor item I found for BPSec was related to redundancy between "absent parameters" vs "empty parameters" which adds complexity and encoded size, but it's not a problem just an inefficiency.

https://mailarchive.ietf.org/arch/msg/dtn/uZyOwAZISfmwBToaZZ29v73e0es/
________________________________
From: dtn <[e-mail]> on behalf of Magnus Westerlund <magnus.westerlund=[e-mail]>
Sent: Monday, January 25, 2021 09:12
To: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [dtn] Concluding IETF last call on DTN

IESG and DTN WG,

So the second IETF last call for the three DTN documents have concluded. As
reminder this second IETF last call was to verify the community consensus on the
changes that has been applied to the document since the first IETF last call.
Below are detailed indication of what has happened during this IETF last call if
any AD want to check the changes. The one people maybe want to check are BPSec.
However, I will wait at least until the Informal before approving these.


BPbis:
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dtn-bpbis%2F&amp;data=04%7C01%7CBSipos%40rkf-eng.com%7C7700fccf98ac44a895a208d8c13b4b4f%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637471807719520776%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=gcNMgwOXD2LqfhA8xPP%2B6X6jTn48xDvAYg7I2c4kx6I%3D&amp;reserved=0

This document received one question for clarificaiton from IANA which has been
asnwered and should be incorporated into the document.

It also received a comments from Brian Sipos about Appendix B typos:
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdtn%2Fw9GgBS87SqsQswA_WbY7eiWaWTE%2F&amp;data=04%7C01%7CBSipos%40rkf-eng.com%7C7700fccf98ac44a895a208d8c13b4b4f%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637471807719530772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=7oVFvUItH6bjuZ%2FAztthakKfFZPChV1l15ewYEPyLvw%3D&amp;reserved=0

So I have requested update to address these two minor issues.

BPSec:
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dtn-bpsec%2F&amp;data=04%7C01%7CBSipos%40rkf-eng.com%7C7700fccf98ac44a895a208d8c13b4b4f%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637471807719530772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=BOder058i6iGOJYKLknyb5Y%2FMJgHqkoiRtXQIwNIqyc%3D&amp;reserved=0

The IETF last call was slightly more interesting as some issues was found, which
after WG discussion resulted in that a new version was pushed out during the
IETF last call. The changes where:

1. Moving to determenistic CBOR encoding and referencing RFC 8949 instead of the
replaced RFC 7049.

2. Mandating Security Source field being always present: Discussion from this
email: https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdtn%2F0J9Kr2C23Fh47QJEaZVKn0rVBnE%2F&amp;data=04%7C01%7CBSipos%40rkf-eng.com%7C7700fccf98ac44a895a208d8c13b4b4f%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637471807719530772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=kSiGEfHl%2FAfZF71b4yi3rtWKw%2F7%2BD8G3VNGo2JTN8R0%3D&amp;reserved=0

3. Mandating that security contexts makes it clear on how to handle the CRC
field in the bundle header if modifying what the CRC covers.

4. Removal of inconsistency in abstract security block:
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdtn%2FLT6Xww1FQhU4mzrkPReFnaVacLU%2F&amp;data=04%7C01%7CBSipos%40rkf-eng.com%7C7700fccf98ac44a895a208d8c13b4b4f%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637471807719530772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ZoqCQQGdQEgxB2qIdjsa%2BuVlnV3koOsa%2BHaAwJA%2BhN8%3D&amp;reserved=0

5. Clarification of the need for policies when to send Status reports related to
security blocks.

So these changes can be seen in this diff:

https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-dtn-bpsec-25%26url2%3Ddraft-ietf-dtn-bpsec-26&amp;data=04%7C01%7CBSipos%40rkf-eng.com%7C7700fccf98ac44a895a208d8c13b4b4f%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637471807719530772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=f0lZ1hLXxZ%2BEK7EXDwLyoh1qYn0EpW6b%2BZNa1c1aFtk%3D&amp;reserved=0

These changes have been reviewed by the WG for 2 weeks, and was available for
the last 10 days of the IETF last call.

TCPClv4:
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dtn-tcpclv4%2F&amp;data=04%7C01%7CBSipos%40rkf-eng.com%7C7700fccf98ac44a895a208d8c13b4b4f%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637471807719530772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=S45IrdQAxm6BXtyWX%2B69Y9CYfMP9hIVOyH3ZgikHgo4%3D&amp;reserved=0

No comments other than IANA is OK during the IETF last call.
Ben needs to clear his discuss.

Cheers

Magnus