Hi Alexey, Thanks again for your comments. Responses inline.
On Thu, Feb 8, 2018 at 9:16 AM, Kathleen Moriarty <[email protected]> wrote: > On Thu, Feb 8, 2018 at 8:53 AM, Alexey Melnikov <[email protected]> > 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/ >> >> >> >> ---------------------------------------------------------------------- >> 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? 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 >> 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, Kathleen _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
