Skip to main content

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

Yes

(Warren Kumari)

No Objection

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

Recuse

(John Scudder)

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

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.
É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 ?
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"
Gunter Van de Velde
No Objection
Jim Guichard
No Objection
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.
Warren Kumari Former IESG member
Yes
Yes (for -04) Unknown

                            
Francesca Palombini Former IESG member
No Objection
No Objection () Not sent

                            
Murray Kucherawy Former IESG member
No Objection
No Objection (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.
Zaheduzzaman Sarker Former IESG member
No Objection
No Objection (for -04) Not sent

                            
John Scudder Former IESG member
Recuse
Recuse (for -04) Not sent