Re: [Gen-art] [bfcpbis] Genart last call review of draft-ietf-bfcpbis-rfc4583bis-26

[Alissa Cooper <[e-mail]>]

Pete, thanks for your review. Charles, thanks for your responses. I have entered a Yes ballot.

Alissa

> On Oct 21, 2018, at 8:47 PM, Charles Eckel (eckelcu) <[e-mail]> wrote:
> 
> HI Pete,
> 
> Thank you for this careful review. Please see comments inline [cue].
> 
> -----Original Message-----
> From: bfcpbis <[e-mail]> on behalf of Pete Resnick <[e-mail]>
> Date: Thursday, October 18, 2018 at 8:36 PM
> To: "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: [bfcpbis] Genart last call review of draft-ietf-bfcpbis-rfc4583bis-26
> 
>    Reviewer: Pete Resnick
>    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 Chair.  Please treat these comments just
>    like any other last call comments.
> 
>    For more information, please see the FAQ at
> 
>    <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
>    Document: draft-ietf-bfcpbis-rfc4583bis-26
>    Reviewer: Pete Resnick
>    Review Date: 2018-10-18
>    IETF LC End Date: 2018-10-17
>    IESG Telechat date: 2018-10-25
> 
>    Summary: Ready, but one issue with the IANA Considerations section.
> 
>    I reviewed the diff with 4583. The changes were easily understandable and the
>    improvements were obvious. Well done. No major issues at all. I think section
>    13 isn't as clear as it ought to be, but not a showstopper. A couple of nits
>    noted.
> 
>    Major issues: None.
> 
>    Minor issues:
> 
>    13: I found this section confusing. You could just explain this interactively
>    with IANA, as I suspect they will find it confusing too, but I'd suggest:
> 
>    - Where you need to have IANA do something new, identify that to IANA as "IANA
>    is requested to register...", replacing "This document defines" in 13.6.
> 
>    - For the remainder, identify those with "IANA has registered...", replacing
>    "This document defined" in 13.2 through 13.5. You can put a parenthetical note
>    next to each one that says, "No new IANA action requested here"
> 
>    This all gets cleaned up by the RFC Editor anyway, but the whole idea of the
>    IANA Considerations is to make it clear what IANA needs to do, not format the
>    section for what it should look like when published.
> 
> [cue] Good catch, and spot on. The IANA review raised these exact questions, to which we provided the clarifications you suggested.
> 
>    Finally, I don't see a need for the "contact [e-mail]" bit. This is going
>    to be a standards track document, and that is always the case for standards
>    track documents.
> 
> [cue] Will check with RFC editor about removing this.
> 
>    Nits/editorial comments:
> 
>    5.1:
> 
>    - Table 1 contains "c-s", but it has not yet been explained. I would move it
>    below the subsequent paragraph.	
> 
> [cue] Good idea.
> 
>    - In the paragraph that begins, "Endpoints compliant with [RFC4583]", the comma
>    in the second sentence belongs after "present", not "client".
> 
> [cue] Yes, thanks.
> 
>    5.2:
> 
>    - In the section title, s/Attributes/Attribute
> 
> [cue] Yes, thanks.
> 
> Cheers,
> Charles
> 
> 
>    _______________________________________________
>    bfcpbis mailing list
>    [e-mail]
>    https://www.ietf.org/mailman/listinfo/bfcpbis
> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art