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) <[email protected]> > wrote: > > HI Pete, > > Thank you for this careful review. Please see comments inline [cue]. > > -----Original Message----- > From: bfcpbis <[email protected]> on behalf of Pete Resnick > <[email protected]> > Date: Thursday, October 18, 2018 at 8:36 PM > To: "[email protected]" <[email protected]> > Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, > "[email protected]" > <[email protected]> > 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 [email protected]" 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 > [email protected] > https://www.ietf.org/mailman/listinfo/bfcpbis > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
