Subject: [OPSAWG] Alexey Melnikov's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)

From: Alexey Melnikov <[email-masked]>
Date: Thu, 08 Feb 2018 05:53:50 -0800

Alexey Melnikov has entered the following ballot position for
draft-mm-wg-effect-encrypt-17: No Objection

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

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This document is not perfect, but I found it to be generally useful. This
version is much improved.

When you talk about logging, maybe mentioning "protocol trace logging" or "PDU
logging" as a useful tool for troubleshooting that can be provided by both
client and server endpoints?

DMARC (RFC 7489) should probably be mentioned in Section 5.1 where you mention
ARF.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 8 Feb 2018 09:16:34 -0500

> https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/

Thanks for your helpful comments, Alexey.  We will make these updates
in a revision after the telechat.

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 9 Feb 2018 23:09:06 -0500

Hi Alexey,

Thanks again for your comments.  Responses inline.

>> https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/

Great suggestion.  The following has been added to the last paragraph
of section 2.1.2 that discusses the types of logging that would be
helpful.

NEW:
A gap exists for vendors where built-in diagnostics and serviceability
is not adequate to provide detailed logging and debugging capabilities
that, when possible, can access cleartext network parameters. In
addition to traditional logging and debugging methods, packet tracing
and inspection along the service path provides operators the
visibility to continue to diagnose problems reported both internally
and by their customers. Logging of service path upon exit for routing
overlay protocols will assist with policy management and
troubleshooting capabilities for traffic flows on encrypted networks.
Protocol trace logging and protocol data unit (PDU) logging should
also be considered to improve visibility to monitor and troubleshoot
application level traffic. Additional work on this gap would assist
network operators to better troubleshoot and manage networks with
increasing amounts of encrypted traffic.

>> DMARC (RFC 7489) should probably be mentioned in Section 5.1 where you mention

The following has been added taking text from the DMARC abstract,
please let us know if you'd like to see any changes or additional text
since the ARF ext is a bit more detailed:

Another effort, Domain-based Message Authentication, Reporting, and
Conformance (DMARC) RFC7489 is a mechanism for policy distribution
that enables increasingly strict handling of messages that fail
authentication checks, ranging from no action, through altered
delivery, up to message rejection.

Thank you!

-- 

Best regards,
Kathleen