> 2/ S2.5, first paragraph: Regarding the port number field
being
> "optional" in the UDP header, I believe the term "optional"
here
> refers to whether or not the field is populated with a non-zero
port
> number or left at 0 in the UDP header. "Optional" does not
imply that
> the field may or may not be present; it is always
present. Maybe what
> you really want to say something like "If the
source port of the UDP
> header contains a non-zero, positive value,
replies SHOULD be addressed
> to that port number. If the source
port of the UDP header contains a 0
> value, it is an indication to the
target that any response to a C12.22
> Request Message SHALL be sent to
the requester's registered port number,
> or if unknown, then response
SHALL be sent to the default port (1153)."
>
As you suggested, here is he updated paragraph with an added introductory
sentence:
2.5. Use of UDP Source Port 0
When sending messages via UDP, the sender MAY set the source port to
either a non-zero value or to zero. If the sender?s source port of the
UDP header contains a non-zero value then replies SHOULD be sent to that port
number. If the sender?s source port in the UDP header contains a zero
(0) value, it is an indication to the receiving target node that any responses
to the C12.22 Message initiator SHALL be sent to the initiator?s registered
port number, or if the port number was not registered (not specified in the
ANSI C12.22 EPSEM Registration Service), then it SHALL be sent to the default
port (1153).
> 3/ S2.5, second paragraph: It says that "...response to a C12.22
Request
> Message SHALL be sent to the requester's registered port number
..." How
> does a recipient know what the requester's registered port
number is?
> Is this information carried somewhere in the C12.22
protocol? Is it
> always 1153?
>
It is carried in certain ANSI C12.22 EPSEM Service messages, such as the
C12.22 Messages that contain a Registration Service request or a Resolve Service
response, thus made available to the inquiring node.
> 4/ S2.5: Do you need to say anything at all about TCP (i.e.,
responses
> for TCP are sent on the same connection, etc.)? This is
covered in
> more detail in S3.1.1.3 and S3.1.1.4, so I am not sure if it
will
> help to mention something in S2.5 or just leave things as they
are...
>
This section discusses the use of port 0 strictly by UDP The use of port 0
is not applicable (to the best of my knowledge) in the context of a TCP
connection.
Perhaps a final sentence in S2.5 is in order as follows:
Further details of C12.22?s use of UDP, and of TCP, are given in
Section 3. IP Message Transport.
> 5/ S3.1.1.3, top of page 12:
> s/SHALL not
automatically/SHALL NOT automatically/
>
1) Section 3.1.1.3 is on page 13 not page 12
2) The text we submitted
and the text posted contain a ?SHALL NOT? and no ?SHALL
not?. There may be some conversion error on your side or you may be
looking at an earlier attempted submission.
> Also, same section, same
paragraph, three lines down:
> s/Multi-channel
IP/Multi-channel TCP/
>
Good catch. The sentence should be changed to:
The C12.22 Host SHALL implement Multi-channel TCP in order to accept
incoming TCP connections (see Section 3.1.1.4. Multi-channel TCP for
details).
> 6/ S3.1.1.5, second paragraph: The text says, "When used
>
bi-directionally, any established TCP connection MAY be used
> to send and
received (sic) C12.22 APDUs." However, nothing is
> said about what
sort of messages are exchanged; i.e., it is clear
> that when A opens up a
TCP connection to B, A can send a C12.22
> request and B sends a C12.22
response on the same connection
> (normal TCP behavior.)
However, is it the case that B can send
> a new C12.22 request to A over
that same TCP connection? Or
> should B open up a new connection for
requests that it
> originates?
>
Agreed, this first sentence needs to be made clearer. We suggest the
following:
When TCP connections are used bi-directionally, any new or
established TCP connection between the two C12.22 IP Nodes MAY be used
equivalently by the C12.22 IP Nodes to send and to receive ANSI C12.22
APDUs.
> 7/ S3.1.1.5, third paragraph says that:
>
> When used uni-directionally, an established TCP
connection SHALL
> be used by the initiator of that
connection strictly to send
> C12.22 APDUs and by the
target node (who accepted the connection)
> strictly to
received C12.22 APDUs.
>
> Does that mean that the target node must
only use the TCP connection to
> receive APDUs but cannot send a C12.22
response over that same TCP
> connection? (see also comment 6
above.)
>
Your comment is correct. To clarify, we suggest inserting a sentence
(bolded below) so that the paragraph now reads:
When used uni-directionally, an established TCP connection SHALL be
used by the initiator of that connection strictly to send
C12.22 APDUs and
by the target node (who accepted the connection) strictly to received C12.22
APDUs. If the target wishes to send a C12.22 APDU back to the
initiator, it MUST establish a new uni-directional TCP connection, or use an
existing uni-directional TCP that it had previously initiated.
> 8/ S3.1.1.5, paragraphs three and four: Is
"uni-directionally
> TCP" and "uni-directional TCP" refer to the same
concept? I am not
> sure.
This is a typographic error. The first sentence in paragraph 3 should
read ?uni-directional TCP,? not ?uni-directionally
TCP.?
> In paragraph four of this section, you state that
>
"uni-directional TCP" is not the recommended mode of operation
> since it
is not defined in ANSI C12.22. However, in the paragraph
> right
above -- the third paragraph -- you provide guidance on how
> to increase
interoperability of uni-directional TCP ("It is
> RECOMMENDED, for
increased interoperability ... on that connection.")
> If it is not
recommended, why bother with increasing interoperability?
> Or conversely,
if we want to increase interoperability, then we may
> as well make it a
recommended behavior.
>
The following is the proposed correction text for paragraph 3.
It is known that some C12.22 implementations have been deployed using
uni-directional TCP. When used uni-directionally, an established TCP
connection SHALL be used by the initiator of that connection to send C12.22
APDUs and by the target node (who accepted the connection) to receive C12.22
APDUs. It is RECOMMENDED, for increased interoperability, that the
initiator of the connection also accept incoming C12.22 APDUs on that
connection in case the target node attempts to use the connection
bi-directionally.
> On a different vein, in paragraph four of this section,
>
s/it is not the RECOMMENDED mode of operation/however, it is NOT
>
RECOMMENDED/
>
> (i.e., the NOT should be capitalized if you want
negative normative
> behavior to be associated with the
RECOMMENDED.)
>
Agreed.
Old wording:
Uni-directional TCP is a special mode of operation; it is not the
RECOMMENDED mode of operation because it is not defined in ANSI
C12.22.
to be replaced with:
Uni-directional TCP is a special mode of operation; it is NOT
RECOMMENDED because it is not defined in 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, thus could become a burden
when a large number of connections is required.
> 9/ The security consideration leaves most of the work to
ANSI
> C12.22 and C12.19 (neither of which I have read.) I suspect
that
> enforcing cryptographic security mechanisms (playback,
>
message authentication, etc.) are accounted for; however, I did
> not see
any explicit reference to establishing the identity of
> the C12.22 IP
Node that sends a C12.22 Request Message to other
> C12.22 IP Nodes.
I presume this may be taken care by
> "...ANSI C12.19 [2] role-based data
access and secured
> register mechanisms.", but just wanted to make
sure.
>
That is correct; it is covered by the ANSI standards and NIST standards,
where the identity of the source C12.22 IP Node is based on its unique
(registered) ApTitle and a unique (registered) Electronic Serial Number and a
unique (registered) Device Class. Also the security protocol is NIST approved.
In addition new security mechanisms may be registered as older ones become
obsolete.
> Nits
> 1/ S2.6, second paragraph:
> s/to
read efficiently/to efficiently read
>
Agreed. This should be changed to ?to efficiently
read.?
> 2/ S2.6, second paragraph: Where is "ApTitle" defined?
>
?ApTitle? is defined in Section 1.2. Definitions.