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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 25 Aug 2009 12:19:43 -0500

[ 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@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 27 Aug 2009 09:07:45 -0500

Avygdor Moise wrote:
> Dear Mr. Gurbani,
>  
> Thank you for the very clear and detailed comments.
> We reviewed your comments and compiled resolutions to each comment.
> Our proposed remedies and explanations inserted in-line, each after your 
> relevant comment.
>  
> We shall await your follow-up instructions.

Dear Avy: Please see inline for one follow-up.
Other than the feedback below, I am perfectly happy with
the resolution you proposed for all other issues my review
had raised.

vkg> 5/ S3.1.1.3, top of page 12:
vkg>   s/SHALL not automatically/SHALL NOT automatically/
avy>
avy> There seem to be a difference in the text that you refer to and the 
text
avy> that is posted at
avy> 
http://tools.ietf.org/search/draft-c1222-transport-over-ip-00#section-3.1.1.3, 

avy> as submitted.
avy>
avy> 1) Section 3.1.1.3 is on page 13 not page 12
avy> 2) The text we submitted and the text posted contain a “SHALL NOT”
avy> and  no  “SHALL not”.  There may be some conversion error on your side
avy> or you may be looking at an earlier attempted submission.

Ah, I see what the problem was...I had received -01 of your
draft as an attachment from Gen-ART coordinator to review.
So, while the section numbers match, the page count may
be different between -00 (which is in the IETF archives)
and -01 (which appears NOT to be in the IETF archives.)

The "SHALL not" problem I point out above occurs in -01,
in the fourth line of S3.1.1.3 (which happens to be on the
top of page 12 in -01.)

Hope that helps.

Ciao,

- vijay

---

From: "Avygdor Moise" <[email-masked]>
Date: Wed, 26 Aug 2009 20:25:18 -0600

Dear Mr. Gurbani,

Thank you for the very clear and detailed comments.
We reviewed your comments and compiled resolutions to each comment.
Our proposed remedies and explanations inserted in-line, each after your relevant comment.

Thanks,
Avy

Avygdor Moise, Ph.D. 
Future DOS R&D Inc. 
#303, 6707 Elbow Drive S.W. 
Calgary, Alberta, Canada T2V 0E5 
Tel: 403-616-8634
Fax: 403-203-7071
e-mail: [email-masked]
web: http://www.fdos.ca 
 
----- Original Message ----- 
From: "Vijay K. Gurbani" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: "General Area Review Team" <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 25, 2009 11:19 AM
Subject: [UPDATED] Gen-ART review of draft-c1222-transport-over-ip-00.txt

> will the "right" thing happen if the port were set to 0?  (I hope I am

The "Native Address" is an encoded capture of the actual IP address and Port number that is always present in the IP header inside a C12.22 Message. Therefore, the port number is always present in the IP header, exactly as dictated by IP encoding rules. However, for efficiency reasons it may not be stored inside the application message area when the port number is zero.

The following is the proposed updated paragraph:

  2.2. IP Native Address

  The IP address and the port number used by a C12.22 Node on a C12.22 Network Segment are referred to as a Native Address.  The Native Address of a C12.22 IP Node SHALL include an IP Address (version 4 or version 6) and a port number, which is assumed to be zero if not present in the encapsulated IP Native Addresses inside an ANSI C12.22 Message. The "Native Address" is an encoded capture of the actual IP address and Port number that is always present in the IP header inside a C12.22 Message. 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 local 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)

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

> Is this information carried somewhere in the C12.22 protocol?  Is it
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.

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

>   s/SHALL not automatically/SHALL NOT automatically/
There seem to be a difference in the text that you refer to and the text that is posted at http://tools.ietf.org/search/draft-c1222-transport-over-ip-00#section-3.1.1.3, as submitted.

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.

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

> should B open up a new connection for requests that it
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.

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

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

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

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

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

---

From: "Avygdor Moise" <[email-masked]>
Date: Thu, 27 Aug 2009 12:10:57 -0600

Dear Mr. Gurbani,

If I am not mistaken, the -01 document was actually an earlier submission, 
named name "rfcxxx-c1222-obver-IP,txt". It was pointed to me by Ms. Cindy 
Morgan that our first submission  should have been a -00, so we renamed  the 
original submission to "draft-c1222-transort-over-ip-00.txt" and updated the 
content to address initial concerns, such as the use of "NOT" vs. "not" and 
other matters of style.

So if you look at 
http://tools.ietf.org/search/draft-c1222-transport-over-ip-00, which is 
dated August 21, 2009 and you should not find any references to "not", as it 
passes all tests for style.

However, to be on the safe side we shall ensure that the following text is 
entered as written below for Section 3.1.1.3

... "The loss or closure of the connection SHALL NOT automatically result in 
the termination
   of the C12.22 associations between the peer nodes. " ...

I will wait for guidance for submitting the recommended corrections.

Thanks again

Avy
---------------------------
Avygdor Moise, Ph.D.
Future DOS R&D Inc.
#303, 6707 Elbow Drive S.W.
Calgary, Alberta,
Canada T2V 0E5
Tel: 403-616-8634
Fax: 403-203-7071
e-mail: [email-masked]
web: http://www.fdos.ca

----- Original Message ----- 
From: "Vijay K. Gurbani" <[email-masked]>
To: "Avygdor Moise" <[email-masked]>
Cc: "General Area Review Team" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Thursday, August 27, 2009 8:07 AM
Subject: Re: [UPDATED] Gen-ART review of 
draft-c1222-transport-over-ip-00.txt