[RAI] [UPDATED] Gen-ART review of draft-c1222-transport-over-ip-00.txt

["Vijay K. Gurbani" <vkg at alcatel-lucent.com>]

[ This is an updated review with one additional minor issue ]
[ CC to RAI as well ]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:  draft-c1222-transport-over-ip-00.txt
Reviewer: Vijay K. Gurbani
Review Date: Aug 25, 2009
IESG Telechat date: Unknown.

Summary: This draft is on the right track but has open issues,
described in the review.

The draft has 0 major issues, 9 minor issues, and 2 Nits/Editorial
comments.

1/ S2.2 - It is assumed that the port number will be 0 if not present.
However, the question I have is where does this assumption hold?
In a URL or somewhere else?  In URLs, if the port number is not
present, it is set to the default port number assigned to the protocol
identified by the scheme.  Since you talk about configuring IP addresses
of C12.22 hosts, I presume you imply a URL of some sort, of if
not a URL, then a field in a screen is set to the IP address.  However,
will the "right" thing happen if the port were set to 0?  (I hope I am
clear on the comment.)

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)."

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?

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...

5/ S3.1.1.3, top of page 12:
  s/SHALL not automatically/SHALL NOT automatically/

Also, same section, same paragraph, three lines down:
  s/Multi-channel IP/Multi-channel TCP/

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?

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.)

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.  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.

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.)

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.

Nits
1/ S2.6, second paragraph:
  s/to read efficiently/to efficiently read

2/ S2.6, second paragraph: Where is "ApTitle" defined?

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg at {alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/