Subject: draft-c1222-transport-over-ip-07 -- more concerns

From: Alfred Hönes <[email-masked]>
Date: Tue, 2 Nov 2010 15:46:23 +0100 (MEZ)

Hello,
the recent discussion on draft-c1222-transport-over-ip-07
(regarding the clarification of the role of this specification)
has also caused me to take a closer look at the draft text.
(Unfortunately, I had not found the time to complete my review
earlier and send comments.)

I strongly suggest to address the observations below:

(A)  General, recurring

(A.1)
The most striking editorial flaw I found repeatedly is the
annoying use of partial double-half-expansions of common acronyms,
like "UDP protocol", where the "P" in the abbreviation already
stands for "protocol".

(A.2)
Further, I'm confused a bit about the ISO terms.  I'm almost a
layman in this respect, but as far as I undedstand the ISO OSI
stack, ACSE (Association Control Service Element) is part of the
ISO *session* layer.  Therefore, the equivalence (postulated in
Section 1.1) of ACSE PDU and APDU (== Application Protocol Data Unit)
seems very surprising.  Maybe this can be clarified / resolved.

Do you want to say that Session, Presentation, and Application Layer
are collapsed to a single layer in the C12.22 model?  Then please
make that explicit.  Otherwise, a lot of language in the memo is
confusing, as it mixes Session Control and Application data terms.

(A.3)
Due to the well-known expected addressing requirements for the
deployment of the subject protocol, I'm surprised of the lack of
strong preference towards IPv6.  IMHO, the memo should recommend
that no significant deployments should be performed using IPv4.

See also items (B.10) and (B.11) below for things that are
architecturally insane and represent obstacles and/or unnecessary
overhead in the migration to IPv6.

(B)  Sepcific

Here's a more complete list of specific remarks (in textual order of
first occurrrence); the item headlines contain a classification as
"nit", "concern", or "major concern".

(B.1) Section 1, 2nd para -- minor concern

The draft says:

   ANSI C12.22, which is an application-level messaging protocol, may be
   transported over any underlying transport network.  This RFC defines
   the requirements governing the transmission of ANSI C12.22 Messages
|  via the TCP and UDP transports and the IP networking protocol.

The last line seems to be inbalanced in style, and it contains such
unpleasant partial expansion.  Suggestion for better wording:

   ANSI C12.22, which is an application-level messaging protocol, may be
   transported over any underlying transport network.  This RFC defines
   the requirements governing the transmission of ANSI C12.22 Messages
|  via the TCP and UDP transports in IP networks.

(B.2)  Section 1.2 -- general (multiple instances) -- concern

Please replace phrases like "the UDP protocol" by either
"the User Datagram Protocol (UDP)" or simply "UDP";
(same for "the TCP protocol", "the IP protocol").

(B.3)  Section 1.2 -- APDU and ACSE PDU -- concern

Please clarify as indicated above in (B).

(B.4)  Section 1.2 -- C12.22 [Request/Response] Message definitions -- concern

Given the definition of "C12.22 Message" as being an APDU carrying
either a fully assembled, or a segment of, C12.22 Request Message
of C12.22 Response Message, the term "C12.22 Message APDU" for a
C12.22 Response Message does not make sense.  The preceding
definition of "C12.22 Request Message" uses "C12.22 APDU".

The definitions as presented are circular.  At one stage,
C12.22 Request/Response Messages are said to be an APDU,
but later the draft says that the latter *contain* an ACSE
that includes an EPSEM service request/response.
EPSEM is synonymous for C12.22 here, isn't it?

This confusion is also related to (B).

(B.5)  Section 2.2, 1st para -- minor concern

The draft says:

|  The term Native IP Address is a Native Address, which MAY be used to
|  reach a C12.22 Node on its C12.22 IP Network Segment.  The Native IP
   Address includes the binary IP address, and an OPTIONAL port number
   that MAY be followed by an OPTIONAL protocol identifier.  The Native
   IP Address SHALL be encoded as described in Section 2.3. Encoding of
   Native IP Addresses.

The first sentence is highly confusing.
I suspect that you wanted to indicate:

                              vvvvvvv   vvvvvvvvvvv       vvvvvvvv
|  The term Native IP Address denotes a transport address that can be
   used to reach a C12.22 Node on its C12.22 IP Network Segment.  [...]

(B.6)   Section 2.3, 1st sentence in 1st para -- nit

	      ... for storage in C12.19 Device Table.
should say:
	      ... for storage in the C12.19 Device Table.

(B.7)  Section 2.3, end of 3rd para -- nit

              ... using different ApTitle.
should say:
              ... using different ApTitles.

(B.8)  Section 2.4, last para -- concern

The draft says:

   Any IP firewalls or Access Control Lists (ACLs) shielding a C12.22
   device MUST be configured to forward UDP and TCP traffic destined to
   port 1153 and other ports that are assigned and registered by the
   Network administrator, in order to maintain the continuity of the
   C12.22 IP Network Segment.

This contains a significant, perhaps inappropriate asymmetry.
If ephemeral ports are used, wouldn't firewall rules / ACLs
also have to admit *return* traffic (originated from port 1153) ?
Of course, stateful filtering might be necesssary to discriminate
other port usage, and topological knowledge ('behind' which interface(s)
are listeners to port 1153 to be expected, and where only clients?)
will help to specify proper filtering rules.
Proposed text:

   Any IP firewalls or Access Control Lists (ACLs) shielding a C12.22
|  device MUST be configured to forward UDP and TCP traffic destined to,
|  and originating from, port 1153 and other ports that are assigned and
   registered by the Network administrator, in order to maintain the
   continuity of the C12.22 IP Network Segment.
|  The configuration will likely depend on the presence or absense of
|  devices with asserted "accept" flag(s) (see Section 3.1).

(B.9)  Section 2.6, 4th + 5th para -- nits

The placement of parentheses and a comma there should be adjusted.

4th para:

   Any IPv6 C12.22 IP Node that supports IP multicast SHALL use
|  Multicast Listener Discovery version 2 (MLDv2) (RFC 3810 [14]
|  possibly within ICMPv6 RFC 4443 [15]) to report membership.
---
   Any IPv6 C12.22 IP Node that supports IP multicast SHALL use
|  Multicast Listener Discovery version 2 (MLDv2) (RFC 3810 [14])
                          v                                     ^
|  possibly within ICMPv6 (RFC 4443 [15]) to report membership.

or perhaps shorter:

   Any IPv6 C12.22 IP Node that supports IP multicast SHALL use
|  Multicast Listener Discovery version 2 (MLDv2) (RFC 3810 [14])
  v                                                             ^
|  to report membership.

And in the 5th para:

   Routers that interconnect C12.22 IP Nodes on the C12.22 IP Network
|  Segment, MUST support [...]
---       ^
   Routers that interconnect C12.22 IP Nodes on the C12.22 IP Network
|  Segment MUST support [...]

(B.10)  Section 2.6, 2nd-to-last para -- major concern

The draft says:

   In the implementation of this technique, an administrative domain
   MUST include at least one C12.22 IP Relay, and all C12.22 IP Nodes in
   the administrative domain SHOULD be configured with a TTL
|  sufficiently large to reach that C12.22 IP Relay.  A TTL threshold
|  SHOULD be defined and configured on all border routers linking the
|  administrative domain to the global Internet such that the routers
|  forward on their Internet interfaces only those 224.0.2.4 multicast
|  packets that have a TTL exceeding the threshold value.

This is an architecturally insane recommendation.  Routers decrement the
TTL / Hop Count field on the "fast path" -- frequently with dedicated
hardware support.  This protocol cannot expect to be successful in
requiring a new kind of TTL / Hop Count processing by major (boundary)
routers.  The only property of TTL / Hop Count that routers should
remain interested in is whether it counts down to zero.
The GTSM (RFC 5082) purposely restricts checking of *lower* bounds
for TTL / Hop Count to the communicating end systems (notwithstanding
the case where the relevant end systems are routers themselves).

Therefore, IMHO the advice given here is not a good idea.
An application protocol should not request changes to on-path routers.

(B.11)  Sections 2.7 and 2.8 -- major concern

Section 2.7 (and other parts of the memo) discuss, and seem to
encourage, the use of IPv4 network directed broadcast.
Since since the pervasive use of CIDR the prefix length of subnets
essentially only is known within confined administrative domains,
and knowledge of the addressing structure should not be imposed
on routers other than those at the prefix [de-]aggregation point
in the network topology, this seems to be a ppor advice as well.

Section 2.8 of the draft says (4th paragraph):

   The IPv4 network directed broadcast address can be computed by
   performing a bitwise OR between the bit complement of the subnet mask
   of the target IP subnet and the IP address of any host on that IP
   subnet.

... but it does not say where the knowledge of the subnet mask should
be derived from for non-local (i.e. other that on-link) subnets.

Note that 11 years ago, RFC 2644 (BCP 34) has changed the default
for router support of directed broadcast; it also says:

   Network service providers and corporate network operators are urged
   to ensure their networks are not susceptible to directed broadcast
   packets originating outside their networks.

Thus, it looks like Internet-wide use of directed broadcast cannot
be achieved anyway.  Recommending its use does not make sense for
new applications.

Furthermore, IMO the document should be much more aware of IPv6
and not recommend to explore niches of IPv4 no more present in IPv6;
therefore, I'd strongly suggest to drop broadcast support entirely
from the document.  IP multicast, if properly used, offers scoping
with architectured mechanisms.

(B.12)  Section 2.8, Figure 2 -- major concern

The whole figure seems to be misleading and overly complicated.
Most likely the changes applied to arrive at the current Section 2.3
have been applied thoughtlessly as well:

IP Multicast and Broadcast does not support connection-oriented
transport.  Thus, in this case, the only possible transport protocol
supported by this specification is UDP.
However, according to the 1st para of Section 2.3, an absent "T"
element in the Native Address encoding means  TCP _and_ UDP  !

Thus, for conformance with Section 2.3, the 6 variants (of 9)
in Figure 2 that do not contain the "T" field are inappropriate
and should be deleted entirely.

Getting rid of IPv4 Broadcast (as recommended above) will drop the
first remaining choice as well and leave a single representation
each for IPv4 and IPv6.

(B.13)  Section 3.1, 3rd para (above Table 1) -- concern

The text there seems to be confusing.
I suggest to clarify it by changing:

|  The mapping of the connection-type parameters to the type of TCP and
|  UDP transports that a C12.22 Node MAY support is defined in Table 1.
---
|  The mapping of the connection-type parameters to the type IP-based
   vvvvvvvvvvvvvvvvvv                                        ^^^^^^^^^
|  transport variants that a C12.22 Node MAY support is defined in
   Table 1.

(B.14)  Section 3.1, Table 1 -- concern

The table should perhaps make better use of wildcard ('x') entries
for the "invalid" cases, not only in the first table row.

To this end, I suggest to group together the 4 subsequent such rows
and replace them with properly wildcarded versions:

    0    1       1         0     Invalid
    0    1       1         1     Invalid
---
    0    x       1         x     Invalid

and:

    1    0       0         1     Invalid
    1    0       1         1     Invalid
---
    x    0       x         1     Invalid

Note: Essentially, the groups of the CL and CO related flags are
independent from each other, and an alternate representation of
the table would show the meanings of the CL and the CO related flags
in two distinct, short tables (with 4 rows each), with the additional
remark that, to be useful, at least one of the basic flags must be set
(this rule is currently represented by the first table row).

(B.15)  Section 3.2.1 (ff.) -- major concern

The recommendations given there seem to be in conflict with
RFC-to-be 6056 (BCP 156) on Transport Protocol Port Randomization.
The recommendation given there in focor of the use of fixed port
numbers as far as possible opens an avenue for spoofing attacks.

In the past, the IETF has changed important, also symmetrically
behaving protocols -- most importantly: BCP-4 -- with regard to such
concerns, to get rid of the usage of a fixed port number on the side
of the peer performing the Active Open, and to use the connection,
once established, in a symmetrical manner, irrespective of the
asymmetry of port number usage in the underlying transport layer.

Similarly -- as an example for an UDP-based service -- the DNS
recommendations have been changed in favor of the use of randomized
source port numbers.

I do not see a necessity to weaken the protocol described here by
forcing it to once more use practices that have been recognized as
poor many years ago.

Thus, IMHO, Section 3.2.1 needs a deep reconsideration.

This extends to the rule in the last paragraph of Section 3.2.2
and a couple of other places in the text.

(B.16)  Sections 3.3 and 3.4.1 -- major concern (recurring)

Again, I question the utility and applicability of the considerations
regarding network directed IPv4 broadcast, as explained above.

(B.17)  Section 3.5 -- typo

        ... to send urgent messaged over IP.
---                               ^
        ... to send urgent messages over IP.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Avygdor Moise <[email-masked]>
Date: Tue, 02 Nov 2010 09:19:00 -0600

We shall review the issues identified below and provide editorial 
corrections.

We have two questions:

1) The subject line categorizes  the concerns below as "-- more 
concerns". Are there any other concerns that we are not aware of or that 
were not brought to our attention since the upload of 
draft-c1222-transport-over-ip-07? if so, were are they listed?

2) Should the revised document that addresses the concerns below be 
uploaded as draft-c1222-transport-over-ip-08? or should it be mailed 
directly to the editor?

Thank you
Avygdor Moise

On 11/02/2010 08:46 AM, Alfred � wrote:
> .... but it does not say where the knowledge of the subnet mask should
>    Alfred H�nes.

---

From: "Avygdor Moise" <[email-masked]>
Date: Tue, 2 Nov 2010 16:45:38 -0600

Dear Mr. HÎnes,

I have queued a document that contains the STRICTLY EDITORIAL corrections
documented below for the RFC Editor.
I did not submit the document yet, because I am waiting for instructions
from the RFC Editor regarding these late comments.

List of Changes made to the document for the RFC Editor's consideration:

Removed "Protocol" from all instances of "TCP Protocol" and "UDP Protocol",
corrected commas, brackets and "s", etc.

Also I applied the following specific specific changes:

*** Replaced all instances of "ACSE PDU" with "ACSE APDU" ***

In Introduction:

*** Added missing sentence to the introduction which now informs of the
obvious the that the Presentation, and Application Layers were collapsed in
C12.22.
 ... "(whereby the OSI Session, Presentation, and Application Layers of ANSI
C12.22 are collapsed into a single Application Layer)". ***

*** Edtorial correction applied "via the TCP and UDP transports in IP
networks" ***

In definition of C12.22 Response Message
*** Replaced "C12.22 Message APDU" with "C12.22 APDU" ***

In section Standardized Port Numbers
*** Replace the words ..."... shielding a C12.22 device"... with  ...
"shielding C12.22 Nodes and the IP network"... ***

------------------------------------------------
The following is a detailed account addressing each and every comment (may
not be of interest to the RFC Editor).

> like "UDP protocol", where the "P" in the abbreviation already
See general statement above.

> seems very surprising.  Maybe this can be clarified / resolved.

The Connectionless-mode ACSE defined by "Open Systems Interconnection -
Connectionless-mode protocol specifications, Information technology - Open
Systems Interconnection - Connectionless protocol for the application
service object Association control service, ITU-T  Recommendation  X.237
bis" states the following

    "This Recommendation | International Standard is based on the concepts
developed in ITU-T Rec. X.200 | ISO/IEC 7498-1 and makes use of the
following terms defined in them.

    a)     Application Layer;

    b)     application-process;

    c)     application-entity;

    d)     application-service-element;

    e)     application-protocol-data-unit;

    f)      connectionless-mode presentation-service;

    g)     connectionless-mode session-service; and

    h)     (N)-connectionless-mode transmission."

It is our view that these elements and their use in an ACSE APDU are fully
described by ANSI C12.22 and additional discussion is outside the scope of
this RFC.

*** Replaced all instances of "ACSE PDU" with "ACSE APDU" ***

> confusing, as it mixes Session Control and Application data terms.

*** Added missing sentence to the introduction that informs of the obvious
the that the Presentation, and Application Layers were collams in C12.22.
 ... "(whereby the OSI Session, Presentation, and Application Layers of ANSI
C12.22 are collapsed into a single Application Layer)". ***

> that no significant deployments should be performed using IPv4.
This RFC does not have any preference toward IPv4 or IPv6.
The purpose of this RFC is not to promote IPv6. As such no reccomendation is
made.

> overhead in the migration to IPv6.
See my response to B.10 and B.11

> |  via the TCP and UDP transports in IP networks.

*** Editorial Correction applied "via the TCP and UDP transports in IP
networks" ***

> (same for "the TCP protocol", "the IP protocol").

*** Replaced all instances of "UDP protocol" with "UDP".

> Please clarify as indicated above in (B).

*** Replaced PDU with APDU ***

> definition of "C12.22 Request Message" uses "C12.22 APDU".

*** Replaced "C12.22 Message APDU" with "C12.22 APDU" ***

> EPSEM is synonymous for C12.22 here, isn't it?
I believe that you are confusing "*Contains* an ACSE..." with the actual
text "contains an ACSE use-information element", this is a reference to an
inner member of the ACSE APDU.

>    used to reach a C12.22 Node on its C12.22 IP Network Segment.  [...]

Actually no. The original text is exacly right.
Native Address is a Definition in this RFC and used by C12.22. Native IP
Address is also a Definition in this RFC that scopes its use to an IP
Network.

>       ... for storage in the C12.19 Device Table.

*** Corrected to "for storage in C12.19 Device Tables" ***

>               ... using different ApTitles.
*** Corrected ***

> |  devices with asserted "accept" flag(s) (see Section 3.1).

Lack of symmetry was not intended. However, the suggested correction breaks
the RFC (e.g. Active-OPEN UDP).

A better solution is to
*** Replace the words ..."... shielding a C12.22 device"... with  ...
"shielding C12.22 Nodes and the IP network"... ***

> |  Multicast Listener Discovery version 2 (MLDv2) (RFC 3810 [14])

*** Added missing ) ***

> |  Segment MUST support [...]

*** Corrected ,****

> An application protocol should not request changes to on-path routers.

Although I  agree with you,  this was introduced by another DISCUSS. See RFC
2365 on Administratively Scoped IP Multicast.
The practice in this area is not very clear or clean.

> in the network topology, this seems to be a ppor advice as well.
The RFC does not have a position and does not encourage the use of IPv6 nor
IPv4. It does not care.
The RFC simply documents the encoding when used.

> be derived from for non-local (i.e. other that on-link) subnets.

The source and the means by which the knowledge can be obtained was
intentionally omitted.
This is a system implementation / operating system specific concern.
How it is handled internally by the software/firmware is outside the scope
of the RFC.

> be achieved anyway.  Recommending its use does not make sense for
This RFC does not recommend the use of broadcast. It recommends the use of
multicast.

> from the document.  IP multicast, if properly used, offers scoping.

This RFC documents existing implementations and describes what is being done
and how it is encoded.

It tried very hard to remain in that realm.

> first remaining choice as well and leave a single representation

At first glance I was tempted to say that you are correct about the
interpretation of no "T" field in Figure 2.

However, the absence of the "T" (as documented in Section 2.3 "... or not
set (absent) for both UDP+TCP transports")  should be interpreted as "any of
TCP or UDP as appropriate".
In the case of sending a unicast APDU then if the target supports TCP and
UDP and then the originator may use TCP or UDP to push the message.
In the case of sending a multicast APDU then if the target supports TCP and
UDP and the message should use UDP (of course) to send the multicast
message.
The responses, however, come back as unicast in accordance with the rules
stated in this RFC and the T flag.

Clearly if one wishes to communicate using TCP and via Multicast they should
go back to school.

Also However, getting rid of Broadcast is going too far.

> |  transport variants that a C12.22 Node MAY support is defined in
*** Corrected ****

> (this rule is currently represented by the first table row).

Although I agree with you. At this late stage I do not wish to try to fix
what ain't broken, and risking the introduction of an error.

> and a couple of other places in the text.
Your concern was reviewed and considered and addressed already in the RFC.

In peer-to-peer communication between IP Nodes port randomization is allowed
in this RFC (see section "TCP and UDP Port Use"
item 5. "When the target UDP C12.22 IP Node is reachable using direct
messaging (as defined in [1] the C12.22 IP Node MAY set the
source port number to a UDP port number that is different than its
registered port number".

However C12.22 can and will span across non IP Network Segments. In this
case using source port randomization can and will break the larger C12.22
Network.
i.e. The span of the Smart Grid and C12.22 is greater than just the IP
Network.

> regarding network directed IPv4 broadcast, as explained above.

See my explanations above.

*** Corrected ****

Many Many Thanks for your input.

Avy
----- Original Message ----- 
From: "Alfred HÎnes" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, November 02, 2010 8:46 AM
Subject: draft-c1222-transport-over-ip-07 -- more concerns

Hello,

(A)  General, recurring

(A.1)

(A.2)

(A.3)

(B)  Sepcific

The draft says:

(B.4)  Section 1.2 -- C12.22 [Request/Response] Message definitions --
concern

The draft says:

The draft says:

4th para:

or perhaps shorter:

And in the 5th para:

The draft says:

    0    1       1         0     Invalid
    0    1       1         1     Invalid
---
    0    x       1         x     Invalid

and:

    1    0       0         1     Invalid
    1    0       1         1     Invalid
---
    x    0       x         1     Invalid

Kind regards,
  Alfred HÎnes.

--

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 3 Nov 2010 02:35:41 +0100 (MEZ)

> Dear Mr. Hönes,

Thanks for your efforts and elaborations.

At this instant, I only would like to give a short clarifying response
to a few details where I believe that you have misunderstood me.

> [...]

This cannot be right.
A phrase like   "The term XXX Address _is_ an YYY address ..."
is nonsensical, independent of technical intent; a _term_ (as used
here) never *is* an _address_, it only can *denote* an address.

> Native Address is a Definition in this RFC and used by C12.22.

That's correct from a general view of the C12.22 layer(s), but the
definition in Section 1.2 says "Native Address" is a *network*
address, whereas from the subsequent text it becomes clear that
with "Native IP Address" you want to designate a *transport* address,
that is the triple consisting of an IP address, a selector for the
transport protocol, and the transport protocol port number at that IP
address (with default values for protocol and port that can be omitted).
"Transport address", or colloquially, "socket" is the standing term in
the IETF to designate the communication endpoint where an application
(protocol) interfaces with the standard Internet Protocol suite,
and it should be your goal to map the generic term from C12.22 to the
established Internet terminology that you want to make use of, isn't it?

> Native IP Address is also a Definition in this RFC that scopes its
> use to an IP Network.

But in this paragraph that aims at introducing this term, you can't
also use it on the RHS of the definition, or it will become recursive
and thus not useful.   And yes, in the scope of an IP network you need
a "transport address" for an application endpoint.

Maybe the problem is that the term "network" has a generic, layer-
agnostic meaning and a specific meaning: the IP layer bridging the
underlying subnetworks (physical and virtual link layers).
When used in combination with "address", IETF participants and most
RFC readers will assume the latter meaning; but that's not what I
assume that you want to do here.

>>  [...]
> Although I agree with you, this was introduced by another DISCUSS.
> See RFC 2365 on Administratively Scoped IP Multicast.

IIRC, that is based on counting TTL to 0 or address scope recognition,
not on ensuring a lower bound on the TTL in packets being forwarded.
NB:  Routers typically are not aware of the transport protocol port
usage and therefore, even if they implemented the mechanism suggested
in the document, would not know to which packets this rule needs to be
applied.

> The practice in this area is not very clear or clean.

Agreed.

Relying on such router behavior will, at best, severely impede the
deployment of your proposal.

> The RFC does not have a position and does not encourage the use of
> IPv6 nor IPv4. It does not care.

See BCP 34 for the reasoning why directed broadcast has essentially
become moot since CIDR has been introduced.  It only could make sense
inside a tightly controlled management domain, but it simply will not
work (any more) on the Internet.

> This RFC does not recommend the use of broadcast. It recommends the
> use of multicast.

It has proven a good principle of protocol design to not introduce
brittle mechanisms that are not expected to be useful, ab initio.
So my stance is that adding complications to implementations that
only make (very limited) sense in the IPv4 world does not buy.

> This RFC documents existing implementations and describes what is
> being done and how it is encoded.
>

There's no need to specify *all* features of existing implementations
in such a document if it's clear that these are of very questionable
utility and subsequent implementation would be simplified and furthered
by leaving out these additional unnecessary complications.

> Also However, getting rid of Broadcast is going too far.

Why?  Using the allocated multicast addresses is functionally
equivalent to broadcast in the domain where it is expected to
work in IPv4: on-link; so you wouldn't use any functionality,
and you have no choice of multicast in IPv6.  So why unnecessarily
implement feature use specific to IPv4 at the  *application* layer
that will not work any more in IPv6, which is the only feasible
environment for such project with the huge count of expected
network nodes.

Furthermore, in switched Ethernet fabrics (with IGP/MLD snooping
switches), multicast is more efficient than link layer broadcast.

>> [...]
> In peer-to-peer communication between IP Nodes port randomization is
> allowed in this RFC (see section "TCP and UDP Port Use"

Maybe I'm missing something; but by your definition and usage of the
encoding of "native IP addresses" you already have the base to handle
arbitrary source addresses of peers performing active open.
Simply (re-)use these transport associations once they have been
established.

I'd suggest that you take a look at how this has been solved in BGP-4
when the specification has been updated to RFC 4271 -- the predecessor
had similar preferences to fixed port numbers and was the subject of
serious concerns.  Similarly, RFC 5452 clearly says "don't use port 53
with DNS active open, use random port numbers" (it doesn't use that
former term, but it says the same in other words).

>  [...]
> </snip>

Thanks for your cooperation and responsiveness as well,
even in this unusually late stage!

Kind regards,
  Alfred Hönes.

--

---

From: "Avygdor Moise" <[email-masked]>
Date: Wed, 3 Nov 2010 13:07:00 -0600

Dear Mr. HÎnes,

Thank you for the clarifications. Now we see what you aimed at. In order to 
address your concerns we propose the following changes to the text (for 
complete details is the inline text).

1)
    a) Corrected definition of Native Address (now using the term transport 
address)
    b) Corrected definition of Native IP Address
2) Deleted the last sentence in each of the last two paragraphs of Section 
IP Multicast
3) Corrected the last sentence in Section IP Broadcast.

Avygdor Moise

----- Original Message ----- 
From: "Alfred HÎnes" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, November 02, 2010 7:35 PM
Subject: Re: draft-c1222-transport-over-ip-07 -- more concerns

> assume that you want to do here.

1) Changed the definition of Native Address
from
      "Native Address

      The term Native Address refers to the network address that may be
      used to reach a C12.22 Node on its C12.22 Network Segment [1].  In
      this specification the Native Address refers to the Native IP
      Address."
to
      "Native Address

      The term Native Address refers to the transport address that may be
      used to reach a C12.22 Node on its C12.22 Network Segment [1].  In
      this specification the Native Address refers to the Native IP
      Address."

2) Changed the first sentence in the definition of Native IP Address
from
    "The term Native IP Address is a Native Address, which MAY be used to
   reach a C12.22 Node on its C12.22 IP Network Segment."
to
    "The term Native IP Address denotes a Native Address that MAY be used to
   reach a C12.22 Node on its C12.22 IP Network Segment"

> deployment of your proposal.

Deleted the last sentence in 2nd to last paragraph of Section IP Multicast
    "A TTL threshold
   SHOULD be defined and configured on all border routers linking the
   administrative domain to the global Internet such that the routers
   forward on their Internet interfaces only those 224.0.2.4 multicast
   packets that have a TTL exceeding the threshold value"
.
also deleted the last sentence in last paragraph of Section IP Multicast
    "A
   C12.22 IPv4 Relay SHOULD use a TTL that exceeds the threshold for any
   C12.22 message destined for the global Internet."

> work (any more) on the Internet.
See correction below

> only make (very limited) sense in the IPv4 world does not buy.
Corrected the last sentence in Section IP Broadcast
from:
    " This specification, however, does not preclude the use of
   IP network directed or limited/local scope (address 255.255.255.255)
   broadcast, and specifies a minimum requirement in Section 4.8,
   Encoding of Multicast and Broadcast Addresses."
to
    "This specification, however, does not preclude the use of
   IP network directed or limited/local scope (address 255.255.255.255)
   broadcast within a controlled management domain (as per RFC 2644 [19])"

> by leaving out these additional unnecessary complications.
AMI Implementations have a very long time span and very poor documentation.
The nature of the Utility AMI business is such that it requires 
documentation past, present and future.
I hope that we do let this minor difference of opinion be a stumbling block 
in the publication of this RFC.

> switches), multicast is more efficient than link layer broadcast.

The simple answer to that is the existing implementations and existing 
equipment use it.
There is still a need to support existing (legacy) systems that use 
broadcast. Therefore we included it as part of the possible encodings.

There are scenarios where broadcast works where multicast does not (again 
anything can be made to work at some equipment replacement cost).

> former term, but it says the same in other words).
I believe that you are missing something.
Arbitrary source IP ports will only work in the context of an C12.22 Node 
Associations where both C12.2 Nodes reside on the IP Network and they do not 
utilize a C12.22 Relay.
If a C12.22 Relay gets involved then things will break.
This RFC permits the use of random source ports where applicable and where 
possible. Saying it otherwise will break ANSI C12.22 Standard.