Thanks! DISCUSS cleared in anticipation of the github version being posted. I appreciate you folks addressing my comments.
Barry On Tue, Jul 16, 2019 at 3:55 PM Tim Evens (tievens) <[email protected]> wrote: > > Hi Barry, > > Thanks for catching that. PR > https://github.com/TimEvens/draft-ietf-grow-bmp-adj-rib-out/pull/14 should > correct this. The rendered txt is > https://github.com/TimEvens/draft-ietf-grow-bmp-adj-rib-out/blob/iana_admin_label/draft-ietf-grow-bmp-adj-rib-out.txt > > Thanks, > Tim > > On 7/16/19, 9:46 AM, "Barry Leiba" <[email protected]> wrote: > > Thanks, Paolo: the updates take care of the DISCUSS and all but one of > the editorial comments. It's a little hard to tell from the github > PR, but it looks like the extra text in Section 9.3 is still there > (after the addition of "byte"): > > << > The Information field contains a free-form UTF-8 string whose byte > length is given by the Information Length field. The value is > administratively given by the Information Length field. The value > is administratively assigned. There is no requirement to terminate > the string with null or any other character. > >> > > The second sentence appears to be a paste error and shouldn't be there... > yes? > > Thanks for addressing my comments! > > Barry > > On Tue, Jul 16, 2019 at 12:19 PM Paolo Lucente <[email protected]> wrote: > > > > > > Hi Barry, > > > > Thanks for your comments. I hope it is felt that the following edits > address them: > > > > > https://github.com/paololucente/draft-ietf-grow-bmp-adj-rib-out/commit/f3a9cb578d6f1a93c207f328f4f912c52cda6bcd > > > > Paolo > > > > On 10 Jul 2019, at 08:21, Barry Leiba via Datatracker > <[email protected]> wrote: > > > > Barry Leiba has entered the following ballot position for > > draft-ietf-grow-bmp-adj-rib-out-06: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Two small points that will be trivial to address: > > > > — Section 4 — > > > > The existing flags are defined in section 4.2 [RFC7854] and the > > remaining bits are reserved for future use. They SHOULD be > > transmitted as 0 and their values MUST be ignored on receipt. > > > > Why “SHOULD”? That’s inconsistent with Section 4.2 of 7854, which says > “MUST”. > > Failing to set the reserved bits to 0 will cause interoperability > problems > > with future extensions. > > > > The following fields in the Per-Peer Header are redefined: > > > > You aren’t redefining them completely, right? Don’t you mean, “When > the O flag > > is set to 1, the following fields in the Per-Peer Header are > redefined:” ? > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Some editorial comments: > > > > Throughout: there are five instances of “use-case”. “Use case” should > not be > > hyphenated (unless it’s used as a modifier, which it isn’t here). > > > > — Section 1 — > > > > An example of pre-policy verses post-policy is > > > > You mean “versus”, with a “u” (and also a second time later in the > section). > > > > This document updates section > > 4.2 [RFC7854] per-peer header by adding a new flag > > > > That’s an odd way to do the citation. Also, “per-peer header” is > misplaced: > > > > NEW > > This document updates the per-peer header in section 4.2 of [RFC7854] > by adding > > a new flag END > > > > The other places in the document that say “section 4.2 [RFC7854]” > should also > > be changed to “section 4.2 of [RFC7854]”. > > > > — Section 6.3.1 — > > > > The Information field contains a free-form > > UTF-8 string whose length is given by the Information Length > > field. > > > > As one UTF-8 character can be more than one byte, it’s best to specify > whether > > the length is in bytes or characters. I would say, “whose byte length > is > > given....” (also in Section 9.3) > > > > — Section 9.3 — > > The sentence, “The value is administratively given by the Information > Length > > field.” appears to be a copy/paste error, and should be deleted. > > > > > > > > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
