I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary ------- No discussion of operational or management aspects is provided. At the least, this document should provide a discussion of the applicability of the objects of the SCTP MIB module [RFC 3873] when SCTP is carried in DTLS. The dependency of parts of that module on IP addresses is a major consideration. It would be desirable to provide a discussion of setup and management for the DTLS layer, since security is a key aspect of that protocol. DTLS documentation [RFCs 4347 and 6347] themselves fail to provide this information -- one has to go to the corresponding TLS documentation and infer the requirements. SCTP authors tend to think in terms of APIs presented to applications rather than potential configuration data to link application requirements to SCTP options. It may be desirable to review the scalability of this architectural decision as the number of implementations of applications of SCTP grows. Tom Taylor Operational Considerations Checklist ------------------------------------ 1. Deployment No discussion of deployment or management is provided. The reviewer's view is that the dominating deployability concerns are those relating to DTLS, which are indirectly covered to some extent in RFC 5246 (TLS 1.2). See Operational Considerations Checklist Item 9 for a discussion of one aspect of scalability (at implementation time rather than deployment time). 2. Installation and initial setup There is no discussion of installation and initial setup. See Operational Considerations Checklist item 9 regarding configuration. 3. Migration Path Not applicable. 4. Requirements on other protocols Dominated by the requirements on DTLS itself, which are spelled out explicitly, and those associated with the use of DTLS, which must be inferred. These latter include the protocol requirements for certificate validation. 5. Impact on network operation Not discussed. None foreseen by the reviewer. 6. Testing and Verification Not discussed. To some extent the SCTP MIB module [RFC 3873] could be used for this purpose. 7. Management interoperability Aspects of the SCTP MIB module have a strong dependency on the availability of IP addresses. A discussion of the applicability of this module in the case of SCTP over DTLS should be provided. 8. Fault or threshold conditions that should be reported Not discussed. SCTP and DTLS individually have reportable conditions. The combination does not present any significant new conditions in the reviewer's mind. 9. Configuration Not discussed. SCTP can be carried over several transports, to which this document adds DTLS. Historically and within the present document, the designers of SCTP have tended to think in terms of APIs and implementation rather than configuration. The implication is that the application is written to invoke the particular SCTP options, including transport, that it requires. The obvious architectural question is then whether this approach is wasteful of implementation resources as the number of implementations of SCTP applications increases, compared with the use of configuration data to link application requirements to SCTP options. Management Considerations Checklist ----------------------------------- No discussion of management considerations is present. As mentioned above, this document should at least provide a discussion of the applicability of the objects in the SCTP MIB module [RFC 3873] when SCTP runs over DTLS. It would also be desirable to summarize the management of certificate distribution and validation for the DTLS layer. Editorial/nits -------------- 1) IDNits complains that normative DTLS reference RFC 4347 is obsolete. The current reference is RFC 6347. The Shepherd's write-up indicates that DTLS version was a point of WG discussion for several months, so this was deliberate. (Support of RFC 4347 is mandatory, support of the latest version of DTLS a SHOULD.) [No action required.] draft-ietf-tsvwg-sctp-prpolicies has a later version than shown in the document. 2) IDNits complains about presence of URLs that don't use a documentation domain. I suspect the offending text is actually the sentence: "Therefore it is RECOMMENDED to set the SCTP parameter path.max.retrans to association.max.retrans." in Sec. 6.1, which refers to SCTP protocol parameters. [Hence no action required.] 3) Abstract, final two sentences: OLD Using the encapsulation method described in this document, SCTP is agnostic about the protocols being used below DTLS, explicit IP addresses can not be used in the SCTP control chunks. As a consequence, the SCTP associations are single homed. SUGGESTED Using the encapsulation method described in this document, SCTP is unaware ^^^^^^^ of the protocols being used below DTLS; hence explicit IP addresses ^^ ^^^^^^^ cannot be used in the SCTP control chunks. As a consequence, the ^^ SCTP in DTLS associations can only be single homed. ^^^^^^^ ^^^^^^^^^^^ 4) Final line of final bullet of Sec. 6.1: s/its/their/ 5) Sec. 6.2: OLD The padding extension defined in [RFC4820] MUST be supported and used for probe packets when performing path MTU discovery as specified in [RFC4821] by the SCTP layer. PROPOSED When the SCTP layer performs path MTU discovery as specified in [RFC4821], the padding extension defined in [RFC4820] MUST be supported and used for probe packets. 6) Sec. 6.3: OLD ... only wildcard addresses MUST be used in ASCONF chunks. PROPOSED ... ASCONF chunks MUST use wildcard addresses only. 7) Sec. 8, last paragraph, middle sentence: OLD The processing of these messages for SCTP carried over a connection-less lower layer like IP, IPv6 or UDP is required to protect nodes not supporting SCTP. PROPOSED When SCTP is carried over a connection-less lower layer like IPv4, IPv6, or UDP, processing of these messages is required to protect other nodes not supporting SCTP.