Re: [Last-Call] [I2nsf] Tsvart last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-26

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

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 <
[e-mail]> 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
> [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>