Re: [Sidrops] AD Review of draft-ietf-sidrops-signed-tal - "RPKI Signed Object for Trust Anchor Key"

[Warren Kumari <[e-mail]>]

[ - sidrop, +sidrops ]
Hi Tom, thank you for addressing my feedback; I'm requesting IETF LC.

W


On Tue, Apr 09, 2024 at 11:15 PM, Tom Harrison <[e-mail]> wrote:

> Hi Warren,
>
> On Fri, Apr 05, 2024 at 11:45:33AM -0700, Warren Kumari wrote:
>
> Thank you for this document, I found it clear, useful, and an easy read.
>
> I do have a few comments/nits; addressing these now should help the IETF
> LC and IESG evaluation go more smoothly.
>
> Thanks for these comments, they are much appreciated. The new version has
> been uploaded, and the diff is available at
> https://author-tools.ietf.org/
> iddiff?url1=draft-ietf-sidrops-signed-tal-14&url2=draft-ietf-sidrops-signed-tal-15&difftype=--html
> if you want to review. Except where noted below, your comments were
> incorporated as-is.
>
> 3: "If a TA uses multiple publication servers, then it is by definition
> inevitable that the content of different keys will be out of sync at
> times." I don't really think that it is "by definition" inevitable. Yes,
> they will sometimes be out of sync, but I don't think that this is "by
> definition".
>
> Previous text:
>
> If a TA uses multiple publication servers, then it is by definition
> inevitable that the content of different keys will be out of sync at times.
> In such cases, the TA SHOULD ensure that the duration of these moments are
> limited to the shortest possible time.
>
> Updated text:
>
> If a TA uses multiple publication servers, then the content for different
> keys will be out of sync at times. The TA SHOULD ensure that the duration
> of these moments is limited to the shortest possible time.
>
> 3: "as per normal" is an idiom which not everyone understands. Perhaps "it
> it normally would" or something like that? This isn't a major issue, but…
>
> Updated to be "as it would in the absence of a TAK object".
>
> 4: I personally found:
> "This OID MUST appear both within the eContentType in the encapContentInfo
> object, as well as the content-type signed attribute in the signerInfo
> object (see [RFC6488])." to be clumsy, and think that:
> "This OID MUST appear in both the eContentType in the encapContentInfo
> objectinsert and in the content-type signed attribute in the signerInfo
> object (see [RFC6488])."
> (As with #3, this is just, like, my opinion, man…)
>
> Updated to:
>
> This OID MUST appear in both the eContentType in the encapContentInfo
> object and the content-type signed attribute in the signerInfo object (see
> [RFC6488]).
>
> 5: "This structure defines a TA key, similarly to [RFC8630]." Suggest:
> "This structure defines a TA key, similar to [RFC8630]."
>
> Changed 'similarly to' to 'similar to that from'.
>
> Cheers
> -Tom
>