Re: [Taps] Erik Kline's Discuss on draft-ietf-taps-interface-22: (with DISCUSS and COMMENT)

[Tommy Pauly <[e-mail]>]

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 <tpauly=[e-mail]> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/taps
> 
> _______________________________________________
> Taps mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/taps