Hi Joseph, I have addressed your comments on I2NSF Consumer-Facing Interface: https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-27
I attach a revision letter to explain how I have addressed your comments on the revision. Thanks. Best Regards, Paul On Mon, Mar 20, 2023 at 11:27 AM Joseph Touch via Datatracker < nore...@ietf.org> wrote: > Reviewer: Joseph Touch > Review result: Ready with Issues > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the > document's > authors and WG to allow them to address any issues raised and also to the > IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please always CC > tsv-...@ietf.org if you reply to or forward this review. > > Note that this review focuses on transport issues. The document's content > has > not been otherwise reviewed. > > Overall, there is little transport-related content in this document. As a > YANG > model, there are no transport issues. > > The model itself does refer to transport protocols by name. The list is > sufficiently complete. > > The only key issue is the reference to ways of blocking protocols. The > "identity reject" entry below describes a variety of ways of blocking > transport > protocols, buthese examples have issues. It is important that this > document be > updated to give correct advice, even if in such examples. > > ...For example, a TCP packet is rejected with > TCP RST response or a UDP packet may be rejected with an > ICMPv4 response message with Type 3 Code 3 or ICMPv6 response > message Type 1 Code 4 (i.e., Destination Unreachable: > Destination port unreachable)." > > It is not entirely clear from the rest of the context of this document, > but if > this filtering occurs anywhere other than the destination IP address of > these > packets then ICMP messages from routers should be used, not those from > hosts. > I.e., if the issue is packets to/from a NFV service, then host errors are > appropriate, but if the issue is packets relayed through an NFV service, > then > router errors should be used instead. > > Additionally, assuming host errors are intended, the entry mentions ICMPv4 > Type > 3 Code 3 (Destination port unreachable) and ICMPv6 Type 1 Code 4 (also > Destination port unreachable), where it appears that ICMPv4 Type 3 Code 10 > and > ICMPv6 Type 1 Code 1 (both “administratively prohibited”) seems more > appropriate. > > That entry also incorrectly refers to use of TCP RST. TCP RST should be > reserved for actions of the receiver TCP protocol engine based on state > errors, > and emitting that message requires that endpoint’s TCP to enter TIME-WAIT > for > that socket pair (RFC 9293, Note 3 in Sec 3.3). It should never be issued > by a > third party that might not be in a position to maintain those TIME-WAIT > states. > It is also not clear it is appropriate to reject connections using this > technique, i.e., as a substitute for host ICMPs. > > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf >
Revision-Letter-for-Consumer-Facing Interface-27-20230326.pdf
Description: Adobe PDF document
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf