Skip to main content

BMP Peer Up Message Namespace
draft-ietf-grow-bmp-peer-up-05

Yes

Warren Kumari

No Objection

Francesca Palombini
Gunter Van de Velde
Jim Guichard
Orie Steele
Paul Wouters
Zaheduzzaman Sarker

Recuse

John Scudder

Note: This ballot was opened for revision 04 and is now closed.

Warren Kumari
Yes
Deb Cooley
No Objection
Comment (2024-09-29 for -04) Sent
Title/Abstract/Introduction:  Please expand BMP at least once near the beginning of the draft (RFC 7854 does that in the title).

Section 5:  While I like the 'rearrangement of the deck chairs' language, it might not be the best when writing for an international audience.
Erik Kline
No Objection
Comment (2024-09-28 for -04) Not sent
# Internet AD comments for draft-ietf-grow-bmp-peer-up-04
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S3

* "is is created" -> "is created"
Francesca Palombini
No Objection
Gunter Van de Velde
No Objection
Jim Guichard
No Objection
Murray Kucherawy
No Objection
Comment (2024-10-02) Sent
The shepherd writeup asks why this should have the status it does, but this wasn't answered.

I am otherwise disappointed that I have no reason to DISCUSS John's document.
Orie Steele
No Objection
Paul Wouters
No Objection
Roman Danyliw
No Objection
Comment (2024-09-30 for -04) Sent
** Abstract and Section 1
   The
   changes in this document are formal only, compliant implementations
   of RFC 7854, RFC 8671 and RFC 9069 also comply with this
   specification.

-- I am unable to parse this sentence.  What does it mean?  For example, do documents make "informal changes"?

-- In what way is RFC8671 and RFC9069 updated?

** Section 5.  Editorial.
   This rearrangement of deck chairs does not change the underlying
   security issues inherent in the existing [RFC7854].

Consider restating this text more clearly without using the Titanic (?) metaphor.

NEW

This document does not alter the security considerations of RFC7854 which continue to apply.
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment (2024-09-24 for -04) Sent
Thanks for the work done in this document. Some editorial suggestions/comments below (they can be ignored):

Should BMP be expanded in the abstract (or even in the title) ?

Unsure whether the leading text of section 3 is useful as the 3.* subsections are rather short and clear.

Section 2, suggest to use "UTF-8 string" as the name; is it useful to define this type, which is used only once ?

Section 3.1, isn't there some contradictions between `The Information field contains *a* string (Section 2)` and `If *multiple* strings are included` ? It is at least unclear to me.

Section 3.3, defining the semantic and syntax of "information" in the description of "Information Type" seems weird and unusual.

Section 5, it is a matter of taste of course, but isn't `This rearrangement of deck chairs` a little too informal ?
John Scudder
Recuse