Hi Erik, Thanks very much for your review!
The authors have just posted a -23 version that addresses all of the IESG comments, including your DISCUSS. https://www.ietf.org/archive/id/draft-ietf-taps-interface-23.html For your particular DISCUSS comment on PvD Identifiers, we submitted this PR: https://github.com/ietf-tapswg/api-drafts/pull/1427. That change: - References RFC 8801 - Explains that the FQDN defined there can be used, but that other PvD IDs may be available that are locally defined on a system Best, Tommy (on behalf of the authors) > On Sep 6, 2023, at 10:48 PM, Erik Kline via Datatracker <[email protected]> > wrote: > > Erik Kline has entered the following ballot position for > draft-ietf-taps-interface-22: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > # Internet AD comments for draft-ietf-taps-interface-22 > CC @ekline > > * comment syntax: > - https://github.com/mnot/ietf-comments/blob/main/format.md > > * "Handling Ballot Positions": > - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > > ## Discuss > > ### S6.1.12 > > * "there is currently no portable standard format for a PvD identifier" > > RFC 8801 should be considered here. > > An argument can be made that there is no *single* format, but there > certainly is a string FQDN PvD ID standard. > > I think it's fair to require that the FQDN PvD ID strings be considered > MTI here, or that an implementation have some way to use handles that > refer to these. Maybe that's what's meant here by the integer option > mention and I'm just not getting the clue. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Internet AD comments for draft-ietf-taps-interface-22 > CC @ekline > > * comment syntax: > - https://github.com/mnot/ietf-comments/blob/main/format.md > > * "Handling Ballot Positions": > - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > > # Comments > > ### S3 > > * "The application should not assume that ignoring events..." > s/should not/SHOULD NOT/? > > ### S6.1 > > * "Connection can perform name resolution" > > Does the Connection do name resolution? I would have expected this to > either be done by Preconnection or just "the API implementation". > > ### S6.1.3 > > * If calls like NewPreconnection() take an array of RemoteEndpoints why > is it necessary to add one RemoteEndpoint to another via .AddAlias(), > rather than just tossing into the []RemoteEndpoints array? > > ### S6.2 > > * It's probably too late for a bikeshed, but I find a Preference named > "Ignore" to not mean "No Preference", as I read it. I would have expected > something like a Preference of "None". > > To me, "Ignore" feels kinda somewhat like "Avoid" (or "Eschew" :D ). > > ### S6.2.1 > > * "without corruption"? > > I think I would have expected "without loss"; "without corruption" implies > to me that there's some extra level of integrity checking go on (vis. > S6.2.7). > > ### S6.2.13 > > * Why should the preference be Avoid for Rendezvous use cases? It seems > to me like many Rendezvous uses are not necessarily long-lived and so > might be Preference None (Ignore), or even Prefer. > > ### S9.1.3.7 > > * Same question as S6.2.1 above. > > ## Nits > > ### S5 > > * "Actions, events, and errors in implementations" -> > "Action, event, and error objects in implementations" > > ### S6.1, S6.1.4 > > * "Port (a 16-bit integer)" > > Perhaps "unsigned integer", or "non-negative integer"? > > * ":0a" -> ":a", I think > > ### S6.1.5 > > * "newPreconnection(...)" -> "NewPreconnection(...)"? > > ### S9.1.3.10 > > * s/endpount/endpoint/ > > > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
