Re: [Gen-art] Genart last call review of draft-ietf-cellar-ffv1-16

2020-09-23 Thread Alissa Cooper 
Joel, thanks for your review. Spencer, thanks for helping to get Joel’s 
comments addressed. I entered a No Objection ballot.

Alissa


> On Jul 16, 2020, at 11:17 AM, Spencer Dawkins at IETF 
>  wrote:
> 
> Hi, Joel, 
> 
> On Mon, Jul 13, 2020 at 11:17 PM Joel Halpern via Datatracker 
> mailto:nore...@ietf.org>> wrote:
> Reviewer: Joel Halpern
> 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 IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
>  >.
> 
> Document: draft-ietf-cellar-ffv1-16
> Reviewer: Joel Halpern
> Review Date: 2020-07-13
> IETF LC End Date: 2020-07-16
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document appears to be ready for publication as an Informational
> RFC.
> 
> *I would have raised question about the intended status, but it appears that
> this is an established IETF convention and I see no reason to argue.)
> 
> Major issues:
> 
> Minor issues:
> Section 3.4 (Context) introduces the notation Q_{#}[ subscript }.  As that
> is the first reference to Q_{#}, it is rather confusing to the reader.  I
> grant that the term is defined in the next section (3.5).  Couldn't they 
> be
> reversed?
> 
> Section 3.8.1.1 refers to C(i), C_{i}, and C_i.  Are these all the same
> thing.
> 
> Section 3.8.1.2 refers to get-rac (which is treated as a function in the
> pseudo-code) as being the process described in section 3.8.1.1.  The text
> in 3.8.1.1 does not call out any of its computed values as an explicit
> result or return.  While I would guess that the intention is to use the
> byte stream (B()), the text does not actually say that.  If that is the
> intention, could the last line of 3.8.1.1 be "get_rac() returns sequential
> bytes from the Byte Stream (B()) as computed by the computation described
> in section 3.8.1.1"?
> 
> Nits/editorial comments:
> 
> Thanks for the review! We'll work through these comments.
> 
> Best,
> 
> Spencer 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-cellar-ffv1-16

2020-07-16 Thread Spencer Dawkins at IETF 
Hi, Joel,

On Mon, Jul 13, 2020 at 11:17 PM Joel Halpern via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Joel Halpern
> 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 IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-cellar-ffv1-16
> Reviewer: Joel Halpern
> Review Date: 2020-07-13
> IETF LC End Date: 2020-07-16
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This document appears to be ready for publication as an
> Informational
> RFC.
>
> *I would have raised question about the intended status, but it appears
> that
> this is an established IETF convention and I see no reason to argue.)
>
> Major issues:
>
> Minor issues:
> Section 3.4 (Context) introduces the notation Q_{#}[ subscript }.  As
> that
> is the first reference to Q_{#}, it is rather confusing to the
> reader.  I
> grant that the term is defined in the next section (3.5).  Couldn't
> they be
> reversed?
>
> Section 3.8.1.1 refers to C(i), C_{i}, and C_i.  Are these all the same
> thing.
>
> Section 3.8.1.2 refers to get-rac (which is treated as a function in
> the
> pseudo-code) as being the process described in section 3.8.1.1.  The
> text
> in 3.8.1.1 does not call out any of its computed values as an explicit
> result or return.  While I would guess that the intention is to use the
> byte stream (B()), the text does not actually say that.  If that is the
> intention, could the last line of 3.8.1.1 be "get_rac() returns
> sequential
> bytes from the Byte Stream (B()) as computed by the computation
> described
> in section 3.8.1.1"?
>
> Nits/editorial comments:
>

Thanks for the review! We'll work through these comments.

Best,

Spencer
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-cellar-ffv1-16

2020-07-13 Thread Joel Halpern via Datatracker 
Reviewer: Joel Halpern
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 IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-cellar-ffv1-16
Reviewer: Joel Halpern
Review Date: 2020-07-13
IETF LC End Date: 2020-07-16
IESG Telechat date: Not scheduled for a telechat

Summary: This document appears to be ready for publication as an Informational
RFC.

*I would have raised question about the intended status, but it appears that
this is an established IETF convention and I see no reason to argue.)

Major issues:

Minor issues:
Section 3.4 (Context) introduces the notation Q_{#}[ subscript }.  As that
is the first reference to Q_{#}, it is rather confusing to the reader.  I
grant that the term is defined in the next section (3.5).  Couldn't they be
reversed?

Section 3.8.1.1 refers to C(i), C_{i}, and C_i.  Are these all the same
thing.

Section 3.8.1.2 refers to get-rac (which is treated as a function in the
pseudo-code) as being the process described in section 3.8.1.1.  The text
in 3.8.1.1 does not call out any of its computed values as an explicit
result or return.  While I would guess that the intention is to use the
byte stream (B()), the text does not actually say that.  If that is the
intention, could the last line of 3.8.1.1 be "get_rac() returns sequential
bytes from the Byte Stream (B()) as computed by the computation described
in section 3.8.1.1"?

Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art