Mr Spencer,
Thank you for the remarks. I will try to respond inline with each of your
comment below.
I hope I did not miss anything.
We shall produce an update shortly (04) that includes the solutions
described below.
Thanks
Avygdor Moise
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.
Please note that we are working on Draft 04 since we have received
additional comments from other reviewers.
In my answers below I will also indicate whether the response is influenced
by an upcoming change in Draft 04.
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.
The following text was added:
"These standards were developed jointly by ANSI (ANSI C12.22 and ANSI
C12.19), by IEEE (IEEE 1377 and IEEE 1703) and Measurement Canada (MC12.19
and MC12.22)."
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.
Note: In response to another comment we replaced the terms "Active-listen
UDP" and "Passive-listen UDP" with "Active-Open UDP" and "Passive-Open UDP"
I agree with you that generally one does not place normative text in
definitions. However, we applied the following editorial generalizations
1) Definitions are normative (i.e. they are binding)
2) If a definition describes a state (i.e. a condition that has an entry
requirement and an exit requirement) and it can be summarized on a single
paragraph then it does not merit the creation of a separate section for the
elaborations
3) Removal of SHALLs and MAY words from definitions can lead to
interoperability problem, so I place them anywhere were applicable.
So, I would rather leave this one alone and not apply a change.
I hope this does not cause problems
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...
Note: The last paragraph in section 2.2 was changes to read
"It is beyond the scope of this specification to define the method of
configuration, the configuration parameters, or any administrative controls
that the system administrator may wish to implement to assign an IP
address."
In regards to the paragraph in question it already states: "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".
So it is never acceptable (or possible) any C12.22 Messages if C12.22 Node
is not on the IP Network.
Clearly I miss something here. Can you elaborate?
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.
We agree with your statements. This RFC helps the implementer by
recommending an algorithm that helps implementers determine the minimum
scope required to reach the closest C12.22 IP Relay on the C12.22 Node's IP
Network Segment.
Is there any change to you wish to see happen as a follow-up to your
comment?
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.
Items 5 and 6 will be combined as follows: "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. When the target UDP C12.22 IP Node
is reached by direct messaging (as defined in [1]) the source port number
MAY set the to a port number that is difference than the registered port."
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" ...
By stating that it is NOT RECOMMENDED is an indication that eventhough it
MAY work we wish to discourage the practice.
If we just say "MAY be made possible" it may decrease interoperability, by
encouraging the practice, which highly undesired.
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]".
Argreed. The text will be changed to "... which by default SHALL NOT forward
directed broadcasts 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]
This explains the upper limit that is imposed on to the Segmentation
Algorithm of ANSI C12.22 by the IP Network. When a node pushes data above
that size it must segment.
However, nodes may choose to segment a much lower limits (which may be
negotiated between peers by the C12.22 Protocol).
----- Original Message -----
From: "Spencer Dawkins" <[email protected]>
To: <[email protected]>
Cc: "General Area Review Team" <[email protected]>
Sent: Wednesday, June 16, 2010 4:53 AM
Subject: Gen-ART Review of draft-c1222-transport-over-ip-03
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
