I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document specifies a protocol (or an update to a protocol) that provides end-to-end reliable transport of bulk data objects or streams over multicast routing and forwarding services. It also provides a congestion control scheme. It is designed to permit different upper layer services to utilize its services in different ways. I got to this review late, so I went straight to the security considerations first. I found the security requirements wishy-washy. Per BCP61, MUSTs are for implementers, SHOULDs are for deployers. There are few MUSTs or REQUIREDs to guide implementators what MUST be present for interoperable security capabilities in an compliant implementation. There are lots of SHOULDs, RECOMMENDEDs, MAY, can be, is possible, is expected, optionally, etc. in the "Baseline Secure NORM Operation". On the other hand, there are lots of SHALLs and REQUIREDs for how deployers MUST configure their security. I am not sure how interoperable the security for this "standard" will be because there are so many allowable options for how one does security. This protocol is not a security protocol. It is a protocol that utilizes lower layer security services, so maybe this "wishy-washy" approach is the correct approach to serve the real-world needs of NORM implementers and deployers. But I would feel more comfortable with something a bit more solid in terms of what MUST be present for security capabilities in compliant implementations. It might help a lot to separate the security considerations into what MUST be implemented for interoperability, and how deployments SHOULD be configured, and then talk about optional extensions or alternatives. As currently written, I am not sure I could figure out just what an implementer MUST support. David Harrington dbharrington at comcast.net ietfdbh at comcast.net dharrington at huawei.com