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).
(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".
See general statement above.
(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.
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" ***
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.
*** 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)". ***
(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.
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.
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.
See my response to B.10 and B.11
(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.
*** Editorial Correction applied "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").
*** Replaced all instances of "UDP protocol" with "UDP".
(B.3) Section 1.2 -- APDU and ACSE PDU -- concern
Please clarify as indicated above in (B).
*** Replaced PDU with APDU ***
(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".
*** Replaced "C12.22 Message APDU" with "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?
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.
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. [...]
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.
(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.
*** Corrected to "for storage in C12.19 Device Tables" ***
(B.7) Section 2.3, end of 3rd para -- nit
... using different ApTitle.
should say:
... using different ApTitles.
*** Corrected ***
(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).
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"... ***
(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.
*** Added missing ) ***
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 [...]
*** Corrected ,****
(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.
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.
(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.
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.
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.
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.
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.
This RFC does not recommend the use of broadcast. It recommends the use of
multicast.
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.
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.
(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.
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.
(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.
*** Corrected ****
(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).
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.
(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.
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.
(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.
See my explanations above.
(B.17) Section 3.5 -- typo
... to send urgent messaged over IP.
--- ^
... to send urgent messages over IP.
*** Corrected ****
Many Many Thanks for your input.
Avy
----- Original Message -----
From: "Alfred HÎnes" <ah(_at_)TR-Sys(_dot_)de>
To: <draft-c1222-transport-over-ip(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org>
Cc: <ietf(_at_)ietf(_dot_)org>
Sent: Tuesday, November 02, 2010 8:46 AM
Subject: draft-c1222-transport-over-ip-07 -- more concerns
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: ah(_at_)TR-Sys(_dot_)de
|
+------------------------+--------------------------------------------+
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf