Tim, thank you for your review. I have entered a No Objection ballot for this document. Lars > On 2022-9-27, at 6:18, Tim Evens via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Tim Evens > Review result: Ready with Nits > > 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-dots-robust-blocks-?? > Reviewer: Tim Evens > Review Date: 2022-09-26 > IETF LC End Date: 2022-09-16 > IESG Telechat date: 2022-10-06 > > Summary: This document is ready with some minor comments. > > Major issues: > > Minor issues: > > Nits/editorial comments: > > 1) +1 to Paul's Nits > > 2) Upon initial read, the abstract could suggest new parameters being > introduced for configuration, yet that is not the case for this document. In > Section 1 it is more clear by writing "This document augments the > "ietf-dots-signal-channel" DOTS signal YANG module defined in Section 5.3 of > [RFC9132]". It appears to me that this document adds the existing RFC9177 > non-confirming parameters to DOTS. I'm not suggesting that the abstract needs > to be changed, but IMO it is a bit misleading till you read the intro. > > 3) In section 1; "Nevertheless, the parameters listed in Table 1 are not > supported in [RFC9132]". While "not supported" is correct, I believe that it > would be more clear as "not included" considering the parameters do exist. > > 4) In section 3, the parameters are restated from RFC9177 and RFC9132. > > Each parameter looks to be a redefinition of what's documented in RFC9177 but > with missing statements, truncated. I would prefer that if the parameter is > unchanged to RFC9177, it should simply state that it's the same as defined in > RFC9177. > > Restating/documenting the parameters leads the reader to have to compare if > there is a change from the source RFC. > > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
