Document: draft-c1222-transport-over-ip-03 Reviewer: Spencer Dawkins Review Date: 2010-06-15 IETF LC End Date: 2010-07-01 IESG Telechat date: 2010-07-01 Summary: This draft is almost ready for publication as an Informational RFC. I have some minor questions, tagged in the review below. 1. Introduction The ANSI C12.22 standard [1] provides a set of application layer messaging services that are applicable for the enterprise and End Device components of an Advanced Metering Infrastructure (AMI) for the SmartGrid. The messaging services are tailored for, but not limited to, the exchange of the data Tables Elements defined and co- published in ANSI C12.19 [2], IEEE P1377 [3], and MC12.19 [4]. Spencer (nit, clarity): If you could add a sentence about the relationship between [2], [3], and [4], that might be helpful to readers who are familiar with one of these, but not with the others. Even saying whether these are the same specification published by different SDOs would be helpful to me. 1.2. Definitions Active-listen UDP Active-listen UDP is a temporary process used by a local C12.22 IP Node to expect and receive incoming C12.22 Messages from a foreign C12.22 IP Node using the UDP protocol. The local C12.22 IP Node SHALL solicit the incoming C12.22 Messages from the foreign C12.22 IP Node using the foreign C12.22 IP Node's registered Native IP Address. The local C12.22 IP Node MAY exit Active-listen UDP process when it has received all of the expected C12.22 Messages or a C12.22 Message timeout has occurred. The local C12.22 IP Node SHALL receive all C12.22 Response Messages solicited from the foreign C12.22 IP Node that arrive at the local port number that matches the source port number used to solicit the C12.22 Messages from the foreign C12.22 IP Node. Spencer (minor): I'm not accustomed to seeing normative text in definitions (and there are several instances in this section). If the ADs are OK with that, I'm OK (don't change it unless someone raises it as a comment in the tracker), but I wanted to make sure Russ noticed this. 2.2. Native IP Address The IP address of the C12.22 IP Node SHOULD be configured before the C12.22 IP Node attempts to send or receive any C12.22 Message on its C12.22 IP Network Segment. If the port number is not explicitly configured by the controlling application, it SHALL be set to the default port number, 1153 (see Section 2.4. Standardized Port Numbers). Spencer (minor): "SHOULD be configured"? OK, but at a minimum, you should say something about when it's acceptable to send C12.22 application-level messages without a configured IP address, and how that works (source IP address is all zeros? something else? I'm confused here). I'm kind of expecting that other reviewers would say MUST... 2.6. IP Multicast IPv6 C12.22 IP Nodes SHOULD use the minimum scope needed, when initiating IP multicast messages to reach another C12.22 IP Node on the C12.22 Network. This practice is RECOMMENDED in order to limit Spencer (minor): I don't think this is a 2119 RECOMMENDED - it's just a statement of fact. "... allows the sender to limit unnecessary propagation ..."? unnecessary propagation of C12.22 IP multicast Messages. 3.2.1. TCP and UDP Port Use General rules: 5. A C12.22 IP Node that implements [CL=1] SHOULD set the source port number in outbound UDP C12.22 Messages to its registered port number. 6. A C12.22 IP Node that implements [CL=1] MAY set the source port number in outbound UDP C12.22 Messages to a different UDP source port number if the target UDP C12.22 IP Node is reachable using direct messaging (as defined in [1]). Spencer (nit, clarity): rule 6 explains why rule 5 is not a SHALL - it would be easier for this reader if the two were combined. 3.2.6. TCP and C12.22 Message Directionality Uni-directional use of TCP is a special mode of operation; it is NOT RECOMMENDED because multiple one-way channel communication is not described by ANSI C12.22, and it utilizes one-half of the TCP connection capability. As a result it doubles the number of TCP connections used to communicate C12.22 Messages, and thus could become a burden when a large number of connections is required. While this mode of operation is not explicitly supported in the ANSI C12.22 standard, it MAY be made possible through mutual operating agreements. The means by which nodes are configured to enact the uni-directional use of TCP is not defined in this specification or in the ANSI C12.22 standard; it is left for future consideration. Spencer (nit, clarity): This is saying "NOT RECOMMENDED but might work", right? I would be more comfortable saying that than "MAY be made possible thought mutual operating agreements" ... 3.3. Using IP Broadcast/Multicast If a C12.22 IP Node is configured to accept IP broadcast and multicast messages, it SHALL join the "All C1222 Nodes" multicast group (see Section 2.6. IP Multicast), and SHALL use the default port 1153. In addition it SHALL accept IP Network directed or limited (local scope) broadcast messages sent to port 1153. Note that successful communication using network directed broadcast requires configuration of network routers, which by default are not supposed to forward directed broadcasts as per RFC 2644 [19]. Spencer (minor): I'm reading "not supposed to" as "SHOULD NOT" in this draft text. My read of http://tools.ietf.org/html/rfc2644 is slightly stronger - "network routers, which SHALL NOT forward directed broadcasts unless specifically configured to do so, as per RFC 2644 [19]". 3.4.2. Sending Large C12.22 APDUs Using UDP When sending a large C12.22 Message via UDP, whereby the ACSE PDU size exceeds the UDP datagram maximum data length (65527 bytes), the initiating C12.22 IP Node SHALL segment the ACSE PDU in accordance with ANSI C12.22 Datagram Segmentation and Reassembly algorithm, such that each APDU segment fits within the UDP data field. Spencer (minor): If you're matching something that's already deployed, fine, but if you have an opportunity to set a lower bound than 65527 bytes for invoking application-level segmentation and reassembly, I'd suggest thinking about that. Losing fragments means you retransmit the entire IP packet (no surprise there), and more fragmentation means you're taking up more reassembly buffers on NATs, if this protocol is really intended to traverse the Internet... 6.2. Informative References [Will be added as appropriate] Spencer (smiles): ... probably time to do this, or else remove the section ...