I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
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
...
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
