Hi Alexey,

Thanks again for your comments.  Responses inline.

On Thu, Feb 8, 2018 at 9:16 AM, Kathleen Moriarty
<kathleen.moriarty.i...@gmail.com> wrote:
> On Thu, Feb 8, 2018 at 8:53 AM, Alexey Melnikov <aamelni...@fastmail.fm> 
> wrote:
>> 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/
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> 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?

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

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

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!

> Thanks for your helpful comments, Alexey.  We will make these updates
> in a revision after the telechat.
> --
> Best regards,
> Kathleen


Best regards,

OPSAWG mailing list

Reply via email to