Mr Spencer,
Again my responses are inline with each of your comment below.
Thanks
Avygdor Moise
----- Original Message -----
From: "Spencer Dawkins" <[email protected]>
To: "Avygdor Moise" <[email protected]>;
<[email protected]>
Cc: "General Area Review Team" <[email protected]>; "Jonathan Brodkin"
<[email protected]>
Sent: Tuesday, June 22, 2010 3:17 PM
Subject: Re: Gen-ART Review of draft-c1222-transport-over-ip-03
Hi, Avygdor,
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
Thanks for responding while I can still remember what I was thinking when
I wrote the review :-)
I deleted anything that we already agree on, below.
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
Yeah - like I said, I just wanted to call Russ's attention to this,
because it's not a common situation. Whatever the ADs think is OK, is OK
with me.
We'll cross our fingers...
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?
"never acceptable" sounds like this ought to be a MUST. If it's a MUST,
implementations that don't do it, don't conform. If it's a SHOULD,
implementations can decide not to do it, and still conform. If this is a
SHOULD, I would expect you to say what the node uses as a source IP
address, at a minimum, if it decides to send packets before configuring
the IP address.
My rule (for myself) is that when you don't do things you MUST do, it's
your fault when it doesn't work, but when you don't do things you SHOULD
do, somebody needs to describe what the other end should do in response -
if it's going to fail in all cases, it really was a MUST.
I'm confused because the IP address is a SHOULD, and the port number is a
SHALL. I would have thought that they were equally important. I'm not an
expert in this field, of course.
O.k. I agree that MUST is better than SHOULD . The new text will state
"The IP address of the C12.22 IP Node MUST be configured before the C12.22
IP Node attempts to send or receive any C12.22 Message on its C12.22 IP
Network Segment."
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?
My suggested change was "this practice allows the sender to limit
unnecessary propagation of C12.22 IP multicast Messages". You've already
got a normative SHOULD in the first sentence (same strength), you don't
need another normative requirement to do the same thing in the second
sentence.
Ok. The text will be changed to:
"This practice allows the sender to limit unnecessary propagation of C12.22
IP multicast Messages."
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.
Ah - in that case, I suggest that you delete the sentence "While this mode
of operation is not explicitly supported in the ANSI C12.22 standard, it
MAY be made possible through mutual operating agreements".
You don't need to say this, and you're just calling the reader's attention
to an undesirable practice that MIGHT work - that's enough to make some
product managers say "oh, you can implement Uni-directional TCP for this,
and tell people to make it work". :-(
Ok. Will delete the text
"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."
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...
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).
I'm not an expert in the application space where you're working, but if
it's anything like the open Internet, there are a lot of reasons to avoid
IP fragmentation when you can do so.
To name two, some NATs drop packets that don't have port numbers
(subsequent fragments don't), and when one fragment is lost for an
application that can't "lose" packets, the entire IP packet has to be
retransmitted. Assuming a 1500-byte-ish 802 link layer, you're saying that
applications don't have to worry until the Message size is bigger than
65527 bytes - that's 44 fragments. If you've already lost one fragment due
to congestion, throwing 44 more packets onto the path seems wrong.
You might wish to consider encouraging use of the C12.22 Protocol to
negotiate lower limits (probably at SHOULD strength), unless you're sure
that the current text won't lead to problems in your application space
(and that your application won't be used on the open Internet).
I see the problem. We are caught between a rock and a hard place.
Most payloads are very small (less than 100 bytes). The reason for the
number 65527 is to instruct the user not to trip on UDP.
The problem you indicate will need to be addressed in C12.22, since it
originates there and if it is a defect in C12.22 then it will be common not
just to IP but other transports that C12.22 may use as well.
I will bring this to the attention of ANSI SC17 and IEEE SCC31 (the
committees) for correction.
Thanks,
Spencer
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
