Hi Theresa,
On Fri, Mar 04, 2022 at 06:42:07PM -0800, Theresa Enghardt wrote:
> Dear Cigdem,
>
> Thank you for preparing the revised version, it looks pretty good to me.
>
> Some replies inline:
>
> On 3/4/22 14:23, Cigdem Sengul wrote:
> >
> >
> > Section 1.3:
> >
> > "Will
> >
Hi Med, Robert,
I echo the thanks to Robert for the review.
A few notes inline (trimming as needed)...
On Mon, Jan 24, 2022 at 12:08:32PM +, mohamed.boucad...@orange.com wrote:
> Hi Robert,
>
> Many thanks for the careful review.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -Mess
Hi dkg,
On Tue, Dec 07, 2021 at 03:11:56PM +0200, Daniel Kahn Gillmor wrote:
> I appreciate your catching these unexpanded acronyms. I am happy to add
> expansions for them, or maybe just outbound references if that seems
> appropriate.
>
> "OCSP" and "CRL" appear in the draft in reference to ce
On Fri, Oct 15, 2021 at 11:25:01PM -0400, Dale R. Worley wrote:
> "Sam Whited" writes:
> >> The appearance of this paragraph in this section suggests (but does
> >> not assert) that in TLS 1.3, the cipher negotiation always results in
> >> unique master secrets. Indeed, it would be extremely conv
Thank you, Roni!
-Ben
On Mon, Jul 05, 2021 at 02:47:39AM -0700, Roni Even via Datatracker wrote:
> Reviewer: Roni Even
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG f
Hi Dale,
A bit thanks for your careful (as always) review.
Med, thanks for responding and updating the document.
I think there's just one point left that I want to comment on:
On Tue, Mar 23, 2021 at 12:38:20PM +, mohamed.boucad...@orange.com wrote:
> Hi Dale,
>
> Thank you for the careful
Hi Dan,
On Tue, Feb 16, 2021 at 12:41:53AM -0800, Dan Romascanu via Datatracker wrote:
> Reviewer: Dan Romascanu
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the
Hi Scott,
> Dan, thanks for the review. Would you please give me a little more on
> what you think is needed to explain the relationship between the two
> documents? I can't think of much more to say beyond "7482 describes
> protocol queries" and "7483 describes protocol responses to the queries
>
Hi Göran, Paul, Olaf,
Sorry for the slow reply.
I agree with Göran's original assessment that the language referring to
7049bis does provide enough information to have a deterministic encoding
for the HKDF inputs.
As such, I don't think pull #28 is needed, and would prefer that it was
reverted (
gt;
> /Ludwig
>
> -Original Message-
> From: Stefanie Gerdes
> Sent: den 3 augusti 2020 16:18
> To: Seitz Ludwig ; Benjamin Kaduk ;
> Paul Kyzivat
> Cc: draft-ietf-ace-dtls-authorize@ietf.org; General Area Review Team
> ; hannes.tschofe...@arm.com
> Subject: Re
Hi Paul,
Also inline.
On Tue, Jul 28, 2020 at 11:36:48AM -0400, Paul Kyzivat wrote:
> Hi Ben,
>
> Please find my comments inline.
>
> On 7/27/20 3:10 PM, Benjamin Kaduk wrote:
> > Hi Paul,
> >
> > Just a couple notes in addition to what Jim already mentioned.
Hi Paul,
Just a couple notes in addition to what Jim already mentioned.
On Sun, Jul 19, 2020 at 04:23:46PM -0400, Paul Kyzivat wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF
On Tue, Jul 21, 2020 at 03:56:07PM -0700, Elwyn Davies via Datatracker wrote:
> Reviewer: Elwyn Davies
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF
> As I understood, Dan's comment was not specific to the sequential increment
> > allocation policy but to provide some guidance to an implementor.
> >
> > Regards,
> > Greg
> >
> > On Fri, Jul 17, 2020 at 3:39 PM Benjamin Kaduk wrote:
> >
> >>
Hi again Greg :)
Reading Dan's review reminded me of one other point (inline)...
On Thu, Jul 02, 2020 at 12:22:04PM -0700, Greg Mirsky wrote:
> Hi Dan,
> thank you for your review, detailed questions, and helpful suggestions.
> Please find my answers and notes below tagged GIM>>.
>
> Regards,
>
On Sat, Jun 06, 2020 at 08:19:52AM +0100, Gorry Fairhurst wrote:
> Please see below.
>
> On 05/06/2020 17:43, Mark Allman wrote:
> >> =
> >>
> >> (3) Each time the RTO is used to detect a loss, the value of the RTO
> >> MUST be exponentially backed off such that the next
On Tue, Mar 10, 2020 at 12:25:12AM -0400, Y. Richard Yang wrote:
> Dear Elwyn,
>
> Thanks a lot for the review! Please see inline below.
>
> On Mon, Mar 9, 2020 at 8:45 PM Elwyn Davies via Datatracker <
> nore...@ietf.org> wrote:
>
> > Reviewer: Elwyn Davies
> > Review result: Almost Ready
> >
>
On Wed, Mar 04, 2020 at 12:23:43PM -0500, Sean Turner wrote:
>
>
> > On Mar 3, 2020, at 16:09, Alissa Cooper wrote:
> >
> > Dale, thanks for your reviews. Sean, thanks for your responses. I entered a
> > No Objection ballot. If Dale’s questions can be clarified for non-expert
> > readers, I t
On Sun, Dec 29, 2019 at 05:50:57AM -0800, Mohit Sethi via Datatracker wrote:
> Reviewer: Mohit Sethi
> Review result: On the Right Track
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the
On Mon, Dec 09, 2019 at 09:22:53PM +, MORTON, ALFRED C (AL) wrote:
> Thanks Roni!
>
> I'm glad you took this on, the long sets of comments/DISCUSS
> from Benjamin kept me very busy while I was flying
> again - literally all day on Sunday to reach Kona, HI.
> You'll see those replies after I s
Hi Brian,
I agree that this updated text provides more clarity about why the
change is being made, but I am not sure that it fully addresses all of
the concerns you raised, and would appreciate your thoughts.
Specifically, you had raised the possibility of existing, fielded,
implementations that
Thanks for the update, Mike.
I will go ahead and get this in front of the whole IESG, but one comment
below...
On Fri, Oct 18, 2019 at 10:57:06PM +, Mike Jones wrote:
> Hi Christer,
>
> https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-09 has
> been published, which address
On Thu, Oct 17, 2019 at 02:48:00PM +0100, Cyril Margaria wrote:
> Thanks for the review,
>
> a new version has been posted addressing your comments.
> Please also see inline
>
> On Wed, 10 Apr 2019 at 13:47, Elwyn Davies via Datatracker
> wrote:
>
>
>
> > s9.2, RFC7025: Given the references t
Thanks for the review, Meral!
Authors, I'm going to go ahead and send this over to the IESG, but it will
end up (most likely) on the September 19th telechat, so you have over a
week to get a revision up with fixes.
-Ben
On Tue, Sep 03, 2019 at 05:56:20AM +, Meral Shirazipour wrote:
> I am th
e in the case this point is a problem.
> >
>
> Ack. +Benjamin Kaduk , do you have preferences on this? I
> don't think the requirements on "random" are particularly strong, so I
> don't know if we should prescribe cryptographic randomness. At the same
> time, it
Going up to a more general topic (and ignoring the particulars here):
On Wed, Mar 06, 2019 at 05:50:00PM -0500, Christian Hopps wrote:
> Thanks for the review! Comments inline.
>
> > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies
> > wrote:
> >
> >
> > Minor issues:
> > Abs
On Tue, Feb 05, 2019 at 07:56:39PM -0800, Dino Farinacci wrote:
> > Nits/editorial comments: Section 2: Get rid of everything except the last
> > paragraph.
>
> Are you sure? I just followed what RFC 8174 suggested. Give me reason to not
> follow it?
Yes, he's sure.
You pasted the text that 81
On Wed, Jan 09, 2019 at 03:34:55PM +0100, Francis Dupont wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please treat these comments just
> like any other last call com
Hi Dale,
On Sun, Jun 10, 2018 at 08:23:54PM -0700, Dale Worley wrote:
> Reviewer: Dale Worley
> Review result: Ready with Nits
Thanks for doing the review. I couldn't tell if the body of it was
supposed to be a copy of the document with the nits fixed, or if
there was inline commentary that I fa
On Tue, Feb 27, 2018 at 11:59:50AM +0200, Dan Romascanu wrote:
> Hi,
>
> See also my other notes.
>
> I believe that what the document tries to say is:
>
> Register R is divided into four different ranges R1, R2, R3, R4 (defining
> the value limits may be useful)
>
> Values in range R1 are allo
On 02/27/2018 08:11 AM, Sean Turner wrote:
> There are two states for the Recommended column: YES and NO. I can go either
> way on whether
> marked as not recommended = NO
> not marked as recommended = NO
>
> WG - thoughts?
I thought we had always been clear that it was "not marked as
recommende
On Mon, Feb 26, 2018 at 11:03:07AM -0800, Dan Romascanu wrote:
>
> 1. CWT is derived from JWT (RFC 7519) using CBOR rather than JSON for
> encoding.
> The rationale as explained in the document is related to efficiency for some
> IoT systems. The initial claims registry defined in Section 9.1 is
On Mon, Feb 26, 2018 at 11:19:04PM +0200, Dan Romascanu wrote:
> Hi Jim,
>
> Thank you for your answer and for addressing my comments.
>
> On item #2:
>
>
>
> On Mon, Feb 26, 2018 at 10:12 PM, Jim Schaad wrote:
>
> >
> >
> > > -Original Message-
> > > From: Dan Romascanu [mailto:drom
Can be null if no such token is available. It
> - MUST not be an empty array. When provided, the
> + MUST NOT be an empty array. When provided, the
> array will be cloned to protect against
>
On Wed, Feb 07, 2018 at 05:43:58PM -0500, Greg Hudson wrote:
> On 02/07/2018 04:32 PM, Benjamin Kaduk wrote:> Line 2519, I think should
[line 2519]
> --> SHOULD, since elsewhere we use SHOULD
> > for sending the error token to the peer.
>
> No opinion. You could make a
e able to sanity-check the above (and one below)
comment?
Thanks,
Ben
On Wed, Feb 07, 2018 at 11:35:34AM -0600, Benjamin Kaduk wrote:
> I am doing a review now. (Line 413, "SHOULD not" --> "SHOULD NOT"
> is all I have so far.)
>
> And I will second Greg&
I am doing a review now. (Line 413, "SHOULD not" --> "SHOULD NOT"
is all I have so far.)
And I will second Greg's comment about this format being an awesome
way to view these changes -- thank you again for putting them
together!
-Ben
On Tue, Feb 06, 2018 at 10:17:35PM +0800, Weijun Wang wrote:
t; reasonable to keep using RFC 2119 and leave all "must" and "required" in
> > lowercase?
> >
> > Thanks
> > Weijun
> >
> >
> >> On Jan 3, 2018, at 9:49 AM, Joel M. Halpern wrote:
> >>
> >> Thanks Ben. Th
Hi Joel,
On Tue, Jan 02, 2018 at 03:30:31PM -0800, Joel Halpern wrote:
> Reviewer: Joel Halpern
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF
Hi Robert,
Thanks for the review (I'm the shepherd, not the editor).
On Thu, Dec 22, 2016 at 11:41:12AM -0800, Robert Sparks wrote:
> Reviewer: Robert Sparks
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews a
On Mon, Nov 28, 2016 at 09:53:35PM +, Paul Miller (NT) wrote:
> Minimum length is a problematic topic due to the fact that we intentionally
> did not specify the format of the freshness token. Since the structure of
> the freshness token is left up to the KDC, there is no good way to determi
On Mon, 24 Oct 2016, Shawn M Emery wrote:
>
> Agreed, however I noticed another area that could use better 2119 language in
> regards to this. Here are the proposed updates:
>
> OLD:
> Care MUST be taken by the KDC not to reveal the client's identity in the
> authorization data of the returned ti
On Fri, 21 Oct 2016, Robert Sparks wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please treat these comments just
> like any other last call comments.
>
> For more i
Hi Meral,
Thank you for the review.
On Wed, 2 Dec 2015, Meral Shirazipour wrote:
> Nits/editorial comments:
>
> [Page 3] 2nd and 3rd paragraph: The word "service" is used to designate
> both the proxy-service and the second backend "application-service" as
> per [MS-SFU]. This may confuse the re
On Wed, 28 Jan 2015, Joel M. Halpern wrote:
> Summary: This document is ready for publication as an Informational RFC
>
> Major issues: N/A
>
> Minor issues: N/A
>
> Nits/editorial comments:
> Section 3.4 paragraph 2: "It is likely appropriate
>for the acceptor to report this error conditi
Hi Meral,
An update is pending which should address your comments, along with some
comments from the OPS-DIR reviewer and a couple of IESG members.
The responsible AD has given a go-ahead to submit an update of the
document.
Thanks,
Ben (document shepherd)
On Mon, 5 Jan 2015, Meral Shirazipour
46 matches
Mail list logo
