Subject: [Gen-art] Gen-ART Review of draft-c1222-transport-over-ip-03

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 16 Jun 2010 05:53:49 -0500

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

---

From: "Avygdor Moise" <[email-masked]>
Date: Tue, 22 Jun 2010 13:04:00 -0600

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

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

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

> 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

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

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

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

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

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

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

----- Original Message ----- 
From: "Spencer Dawkins" <[email-masked]>
To: <[email-masked]>
Cc: "General Area Review Team" <[email-masked]>
Sent: Wednesday, June 16, 2010 4:53 AM
Subject: Gen-ART Review of draft-c1222-transport-over-ip-03

> Summary: This draft is almost ready for publication as an Informational 
> RFC. I have some minor questions, tagged in the review below.
>
> 1. Introduction
>
> 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
>
> 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
>
> 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.
>
> 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]".
>
> 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...
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 22 Jun 2010 16:17:42 -0500

Hi, Avygdor,

> We shall produce an update shortly (04) that includes the solutions 

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.

> paragraph then it does not merit the creation of a separate section for 
> the elaborations

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.

> configuration, the configuration parameters, or any administrative 
> controls that the system administrator may wish to implement to assign an 
> IP address."
>

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

>> statement of fact. "... allows the sender to limit unnecessary 
>> propagation ..."?
>>
> scope required to reach the closest C12.22 IP Relay on the C12.22 Node's 
> IP Network Segment.
>

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.

> 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". :-(

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

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

Thanks,

Spencer

---

From: "Avygdor Moise" <[email-masked]>
Date: Tue, 22 Jun 2010 16:48:26 -0600

Mr Spencer,

Again my responses are inline with each of your comment below.

Thanks
Avygdor Moise

----- Original Message ----- 
From: "Spencer Dawkins" <[email-masked]>
To: "Avygdor Moise" <[email-masked]>; 
<[email-masked]>
Cc: "General Area Review Team" <[email-masked]>; "Jonathan Brodkin" 
<[email-masked]>
Sent: Tuesday, June 22, 2010 3:17 PM
Subject: Re: Gen-ART Review of draft-c1222-transport-over-ip-03

> Thanks for responding while I can still remember what I was thinking when 
> I wrote the review :-)
>
>>> 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.
>>>
> 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...

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

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

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

>>> right? I would be more comfortable saying that than "MAY be made 
>>> possible thought mutual operating agreements" ...
>>
>> If we just say "MAY be made possible" it may decrease interoperability, 
>> by encouraging the practice, which highly undesired.
>
> of operation is not explicitly supported in the ANSI C12.22 standard, it 
> MAY be made possible through mutual operating agreements".
>

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

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 22 Jun 2010 18:42:03 -0500

Hi, Avygdor,

We're very close (not that I have a ballot position, but :-) ...

>> 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 
> uni-directional use of TCP is not defined in this specification or in the 
> ANSI C12.22 standard; it is left for future consideration."

You actually deleted two sentences - I wasn't sure about asking you to 
delete the second sentence, but if you're OK with it, I think that's fine.

>>> Algorithm of ANSI C12.22 by the IP Network. When a node pushes data 
>>> above that size it must segment.
>> 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.
>>
> 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 understand. You documented the limit that is KNOWN to fail :-)

I'm understanding from our conversation that you might be communicating with 
a C12.22 endpoint that won't negotiate downward before happily sending you 
maximum-length UDP packets whether you wish they would or not...

Ralph - I might be pushing too hard on this one - could you provide 
guidance?

Thanks again for the quick turnaround on this.

Spencer

---

From: "Avygdor Moise" <[email-masked]>
Date: Tue, 22 Jun 2010 18:03:30 -0600

Spencer ,

Indeed we are close.

See my short comments inline

Thanks
Avygdor
----- Original Message ----- 
From: "Spencer Dawkins" <[email-masked]>
To: "Avygdor Moise" <[email-masked]>; 
Sent: Tuesday, June 22, 2010 5:42 PM

>>> 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
I am fine with that.

>>> it's anything like the open Internet, there are a lot of reasons to 
>>> avoid IP fragmentation when you can do so.
>>>
> I'm understanding from our conversation that you might be communicating 
> with a C12.22 endpoint that won't negotiate downward before happily 
> sending you maximum-length UDP packets whether you wish they would or 
> not...
>
Just to be clear. It is the responsibility of a C12.22 Nodes to communicate 
optimal capabilities to each other so that they do not create a mode of 
failure.
If a C12.22 Relay is involved then it is allowed to re-assemble or 
re-fragment an APDU to best meet local area transport requirements.
So this instruction (limit) simply indicates to makers of IP nodes that they 
should not try to send C12.22 messages gerater than 65527 without 
segmentation when the transport is IP and the protocol is UDP.