Hi! I mostly just have nits, but there are a couple of questions interspersed
below.
s1, para 1: s/While one may directly obscure the data through the use of/While
directly obscuring the data with
s1, para 1: s/it’s/its
s1, para 3: s/IP-TFS/IP-TFS (IP Traffic Flow Security)
s1, last para: s/IP-TFS provides for dealing with network congestion/IP-TFS
addresses network congestion
s1: You mention full TFC. Is it partial TFC if you use a non-constant
send-rate? if so that might be good to qualify in the 3rd paragraph with
something like:
OLD:
A non-
constant send-rate is allowed, but the confidentiality properties of
its use are outside the scope of this document.
NEW:
A non-
constant send-rate is allowed to support partial TFC, but the
confidentiality properties of its use are outside the scope of
this document.
s1.1, para 1: Use updated terminology para from 8174 ("BCP 14” is missing):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
appear in all capitals, as shown here.
s2, para 1:
is the "(SA)" needed? ... tunnel (SA) ...
s/it’s/its
s2, 2nd para: I tripped over this para a couple of times. Does this get the
same point across?
OLD:
The primary input to the tunnel algorithm is the requested bandwidth
used by the tunnel. Two values are then required to provide for this
bandwidth, the fixed size of the encapsulating packets, and rate at
which to send them.
NEW:
The primary input to the tunnel algorithm is the requested
bandwidth for the tunnel. Two values needed to determine
the bandwidth are the fixed size of the encapsulating
packets and the rate at which to send them.
s2, 3rd para: s/or could be/or be
s2, 4th para: s/requested tunnel used bandwidth/
requested tunnel bandwidth
s1, last para to make it match the rest of the sentence: s/The egress of the
IP-TFS/The egress (receiving) side of the IP-TFS
s2.1, 1st para: s/In order to maximize bandwidth IP-TFS/
In order to maximize bandwidth, IP-TFS
s2.1, 3rd para: Does this say the same thing:
OLD:
This is accomplished using a new Encapsulating Security Payload (ESP,
[RFC4303]) type which is identified by the number AGGFRAG_PAYLOAD
(Section 6.1).
NEW:
IP-TFS uses a new Encapsulating Security Payload (ESP, [RFC4303])
type identified by the number assigned to AGGFRAG_PAYLOAD
(Section 6.1).
s2.2: I had a really hard time parsing this sentence:
The AGGFRAG_PAYLOAD payload content defined in this document is
comprised of a 4 or 24 octet header followed by either a partial, a
full or multiple partial or full data blocks.
There are three options: partial, full or multiple partial, or full data? Maybe
it’s just missing a comma: s/multiple partial or/multiple partial or,
s2.2.1: Should we be specific about the IPv4 and IPv6 length’s field name:
OLD:
Likewise, the length of the data block is extracted from the
encapsulated IPv4 or IPv6 packet's length field.
NEW:
Likewise, the length of the data block is extracted from the
encapsulated IPv4’s Total Length or IPv6’s Payload Length fields.
s2.2: s/It’s/It is
s2.2.3: s/to be able to reassemble/to reassemble
s2.2.3: s/This possible interleaving/This interleaving
s2.2.3: s/sender to always be able to send a/sender to always send a
s2.2.3, 4th para: s/Finally, we note/Finally, note
s2.2.3, 5th para: s/As the amount of reordering that may be present is hard to
predict the window/As the amount of reordering that may be present is hard to
predict, the window
2.2.3, 5th para: I am all about not littering I-Ds with 2119-language, but here
it looks like you are burying the MUST in the parenthetical. BTW - I think the
sentence stands on its own without the "i.e.” and it could safely be deleted.
Would this rewording work:
Gaps in the sequence numbers will not work for this document,
therefore ESP sequence number stream MUST increase monotonically
by 1 for each subsequent packet.
s2.2.3, penultimate para: s/b/c/because
s2.2.3, last para: Should the I-D state what happens if the implementation does
send initial fragments of an inner packet using one SA and subsequent fragments
in a different SA. I.e., motivate the SHOULD NOT.
s2.2.3, last para: implementation here refers to sender right so maybe: senders
SHOULD NOT
s2.2.3.1: Implementations here refers to senders so maybe:
s/An implementation/Senders
s/Implementation implementing/Senders implementing ;)
s2.2.4: s/In order to support/To support
s2.2.5, 1st para:
s/(by design!)/(by design) ;)
s/although an implementation/although a sender
s/An implementation SHOULD/A sender SHOULD
s2.2.5, 2nd para:
s/an implementation/a sender
s/([RFC3168])/[RFC3168]
s2.2.6, 1st para: s/([RFC0791])/[RFC0791]
s2.2.6, 2nd para: 2119 the should?: s/should be/SHOULD be. Is there a reason
you would want to handle the errors differently? If not then would the
following also be true (i.e., replace "should be" with "are":
Any errors (e.g., ICMP errors arriving back at the tunnel ingress due
to tunnel traffic) are handled the same as with non IP-TFS
IPsec tunnels.
s2.2.7, 1st para: s/am implementation/a sender
s2.2.7, 2nd para: s/([RFC4301])/[RFC4301]
s2.3: Does this work?
OLD:
It is not the intention of this specification to allow
for mixed use of an AGGFRAG_PAYLOAD enabled SA.
NEW:
This document does not specify mixed use of an
AGGFRAG_PAYLOAD enabled SA.
s2.4.1, 1st para: s/In the non-congestion controlled mode IP_TFS /In the
non-congestion controlled mode, IP-TFS
s2.4.1, 2nd para:
Should the should be SHOULD?
s/In this case packet/In this case, packet
There is a reference to a user. Is it really a user?
s2.4.2, 2nd para:
s/the ingress sends/the ingress side sends
Maybe just swap this around?
OLD:
An example of an implementation of the [RFC5348] algorithm which
matches the requirements of IP-TFS (i.e., designed for fixed-size
packet and send rate varied based on congestion) is documented in
[RFC4342].
NEW:
[RFC4342] provides an example of the [RFC5348] algorithm which
matches the requirements of IP-TFS (i.e., designed for fixed-size
packet and send rate varied based on congestion.
s2.4.2, 3rd para: s/In particular these/In particular, these
s2.4.2, 4th para:
Should the must be MUST?
s/The lack of receiving this information/Not receiving this information
s2.4.2, 4th and 5th paras: s/it’s/its
s2.4.2, 6th para: Does this work?
OLD:
When an implementation is choosing a congestion control algorithm (or
a selection of algorithms) one should remember that IP-TFS is not
providing for reliable delivery of IP traffic, and so per packet ACKs
are not required and are not provided.
NEW:
When choosing a congestion control algorithm (or
a selection of algorithms) note that IP-TFS is not
providing for reliable delivery of IP traffic, and so per packet ACKs
are not required and are not provided.
s2.4.2, last para: s/It’s/It is
s3, 1st para:
s/and also be able to approximate/and also to approximate
s/([RFC5348])/[RFC5348]
s/In order to obtain these values the/
In order to obtain these values, the
s/Thus in order, to support/Thus, to
s/is used to convey/conveys
s3, 1st and 3rd para: s/it’s/its
s3, 3rd para: Nits complained about this so I am assuming it’s MUST NOT here -
s/MUST not/MUST NOT
s3.1, 1st para: s/egress endpoint/egress (receiving) side
s3.1, last para: s/For this reason ECN/For this reason, ECN/
s4: s/should be able to be specified/should be specified
s4.1: s/For non-congestion controlled mode the/For non-congestion controlled
mode, the
s4.1: Does this work:
OLD:
For congestion controlled mode one can configure the
bandwidth or have no configuration and let congestion
control discover the maximum bandwidth available.
NEW:
For congestion controlled mode, the bandwidth can be
configured or the congestion controller discovers
the maximum bandwidth available.
s5.1, 2nd para: s/is used to enable use of/enables the
s5.1, 3rd para:
s/To request using the/To request use of the
s/then response/then the response
s5.1, penultimate para: Should the should not be SHOULD NOT?
s6.1: s/8 bit/8-bit
s6.1: s/specification/document
s6.1.1: s/"DataBlocks” data/“DataBlocks" ?
s6.1.1: s/16 bit/16-bit
s6.1.2: s/7 bit/7-bit
s6.1.2: s/1 bit/1-bit
s6.1.2 x3: s/32 bit/32-bit
s6.1.2: s/22 bit/22-bit
s6.1.2 x2: s/21 bit/21-bit
s6.1.3: s/4 bit/4-bit
s6.1.3.1/s6.1.3.2/s6.1.3.3: s/4 bit/4-bit
s6.1.3.1/s6.1.3.2: s/16 bit/16-bit
s6.1.3.3: s/extends/Extends
s6.1.4: s/As discussed in Section 5.1 a/As discussed in Section 5.1, a
s6.1.4, D bullet (make it match C): s/Don't Fragment bit, if/Don't Fragment
bit. If
s7: I may have missed this in earlier discussions but why is the registration
policy Standards Action? I thought that most of the registries were trending
more towards Expert Review.
s8, 1st para: s/Traffic Flow Confidentiality/TFC
s8:
You warned in s1 about using a non-constant send-rate, but shouldn’t that be
echoed here?
Likewise maybe repeat the ECN covert channel statement.
s9.2: r/[draft-iab-wire-image]/[RFC8546]
Appendix B: YMMV here but since this is an Appendix and you’re repeating the
current practice s/SHOULD/should
Cheers,
spt
> On Jan 24, 2021, at 20:55, Tero Kivinen <kivi...@iki.fi> wrote:
>
> This is the start of 3 week WGLC on the document, ending 2021-02-15.
> Please submit your comments to the list, also send a note if you have
> reviewed the document, so we can see how many people are interested in
> getting this out.
> --
> kivi...@iki.fi
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
