Re: [Taps] Intdir telechat review of draft-ietf-taps-interface-22

["Philipp S. Tiesel" <[e-mail]>]

Dear Tatuya,

thank you very much for your review and especially for pointing out the difference between scope and scope zone.
While the text was originally written with “interface scopes” in mind, it makes particular sense for TAPS to be precise here, as the API can actually distinguish between binding a Preconnection (and the resulting Connection) to a specific Interface and requesting an Endpoint within a specific scope zone. The fix will be included in the next revision of the document.

As suggested, we also corrected the example to using link-local addresses, as there should only be one zone in the global scope. 

AVE!
   Philipp

> On 2. Sep 2023, at 03:02, Tatuya Jinmei via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Tatuya Jinmei
> Review result: Ready with Nits
> 
> I am an assigned INT directorate reviewer for
> <draft-ietf-taps-interface-22.txt>. These comments were written primarily for
> the benefit of the Internet Area Directors. Document editors and shepherd(s)
> should treat these comments just like they would treat comments from any other
> IETF contributors and resolve them along with any other Last Call comments that
> have been received. For more details on the INT Directorate, see
> https://datatracker.ietf.org/group/intdir/about/.
> 
> Based on my review, if I was on the IESG I would ballot this document as NO
> OBJECTION. This draft is generally well-written. Its motivation (providing a
> modern network API framework taking into account advanced transport
> technologies such as MPTCP, QUICK, or TLS) is reasonable. The design looks
> sensible to me.
> 
> The following are minor issues (typos, misspelling, minor text improvements)
> with the document:
> 
> 1. In section 6.1, I suggest changing the following text:
>   Note that an IPv6 address specified with a scope (e.g.
>   2001:db8:4920:e29d:a420:7461:7073:0a%en0) is equivalent to
>   WithIPAddress with an unscoped address and WithInterface together.
> to:
>   Note that a scoped IPv6 address specified with a scope zone ID (e.g.
>   fe80::a420:461%en0) is equivalent to
>   WithIPAddress with the address omitting the zone ID and WithInterface
>   together.
> 
> The rationale of the suggestion is as follows:
> 
>  - While this may be a pedantic comment, the term (address) "scope" is not
>  accurate according to RFC4007. In this context, "(scope) zone" or "(scope)
>  zone ID" is a more accurate term. FYI, RFC4007 explains the difference
>  between scopes and zones:
> 
>   Note that a zone is a particular instance of a topological region
>   (e.g., Alice's site or Bob's site), whereas a scope is the size of a
>   topological region (e.g., a site or a link).
> 
>  - The form "2001:db8:4920:e29d:a420:7461:7073:0a%en0" looks awkward in that
>  it uses the <address>%<zone ID> format for a global address.  RFC 4007
>  actually even states "The format is meaningless and should not be used for
>  global addresses."  And, in fact, some implementations of getaddrinfo don't
>  treat it as the "<address>%<zone ID>" form but as some awkward domain name
>  (which usually results in an error).
> 
> 2. In Section 6.1.2, I suggest changing:
>   *  Specifying an interface on a RemoteEndpoint qualifies the scope of
>      the Remote Endpoint, e.g., for link-local addresses.
> to:
>   *  Specifying an interface on a RemoteEndpoint qualifies the scope zone of
>      the Remote Endpoint, e.g., for link-local addresses.
> For the same reason as the previous suggestion.
> 
> 3. Likewise, in Section 6.2.11, I suggest changing this:
>   Note that this property is not used to specify an interface scope for
>   a particular endpoint.  Section 6.1.2 provides details about how to
>   qualify endpoint candidates on a per-interface basis.
> to:
>   Note that this property is not used to specify a scope zone for...
> 
> 4. Mostly a pure editorial matter, I suggest removing the leading 0 from '0a'
> in 2001:db8:4920:e29d:a420:7461:7073:0a (that appears in Sections 6.1 and
> 6.1.4) as it's redundant.
> 
> 5. Very minor editorial nits follow (those are likely to be caught by the RFC
> editor, but just in case)
> 
> - Section 3: s/a server/a server;/
>   *  through listening on the Preconnection (i.e., passively opening,
>      as in a server Section 7.2),
> - Section 6: s/of they/or they/
>   a multi-homed host, of they might correspond to local interfaces and
> - Section 7.1: s/action Section 9.2.5/action (Section 9.2.5)/
>   Connection establishment and transmission of the first Message can be
>   combined in a single action Section 9.2.5.
> - Section 8.1.4: s/packets Section 6.2/packets (Section 6.2)/
>   A Transport Services API can request a protocol that supports sending
>   keep alive packets Section 6.2.10.  If this property is Numeric, it
> - Section 8.1.11.3: s/It/It is/
>   can receive.  It specified as the number of bytes.
> - Section 9.1.2.2: is this sentence perhaps incomplete?
>   In order to set
>   these properties, the add and get actions on the MessageContext.  To
> - Section 9.1.3.9: s/prefered/preferred/
>   avoid network layer fragmentation when transport segmentation is
>   prefered.
> - Section 9.1.3.10 s/endpount/endpoint/
>   source fragmentation of Messages.  When running over IPv4, setting
>   this property to true will result in a sending endpount setting the
> - Section 13: s/whith/with/
>   objects allows an application to determine whith protocol(s) and
> - Section 13: s/Tranport/Transport/
>   path(s) are in use.  A Tranport Services system SHOULD provide a
> 

--  
Philipp S. Tiesel
https://philipp.tiesel.net/