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

Reply via email to