Hi Erik, Thanks again for your review — just a quick reminder to please take a look at the updates, and let us know if there’s anything else that needs to be addressed to clear your DISCUSS.
Best, Tommy > On Nov 14, 2023, at 8:54 AM, Tommy Pauly <[email protected]> > wrote: > > 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
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
