Hello Florian, thank you for taking the time to review the document.
> I am marking the document as ready. Overall the draft is well written > and gives a concise introduction to BGP security without going off > into the weeds. > > I'll note some oddities that I spotted while reading the document > with fresh eyes. Feel free to address these or ignore as you see fit. Thank you, this is good to hear. I outline below how we addressed your comments and uploaded -10 with these comments addressed. Please find the diff here: https://author-tools.ietf.org/iddiff?url1=draft-ietf-grow-bgpopsecupd-09&url2=draft-ietf-grow-bgpopsecupd-10&difftype=--html > Title > ----- > "Updated BGP Operations and Security" that's probably not going to > age > well, if someone wishes to update this document 10 years from now, > will its title be "Updated Updated BGP Operations and Security"? > Maybe change it to "BGP Operations and Security", I don't think RFC > titles need to be unique. This is an artifact from the initial working title. The recommendation has been implemented. > Abstract > -------- > I was surprised to read commentary on how this document changes the > document it obsoletes in the abstract. Maybe the 2nd paragraph > ("Previously, security considerations for BGP have been described > in...") can be moved to an appendix. I'm also used to checking the > header of RFC to see if they update or obsolete other RFC, so I don't > have a need for this information in the abstract. > > If this is done, the 3rd paragraph does not fit any more. It could be > moved to the end of the introduction, slightly changed: > > Remove "To this end, the document describes the security requirements > and..." from the abstract and add > > > The document explicitly does not focus on specific technical > > implementations and requirements. Operators are advised to consult > > documentation and contemporary informational documents concerning > > methods to ensure that these properties are sufficiently ensured in > > their network. > > at the end of the introduction. I partially integrated this, reducing the text to the initial summarizing part, while including the point you mentioned at the end of the introduction as well. This creates a slight text duplication; However, given the abstract's purpose, I would argue that the doubling of text there is a reasonable trade-off. > 3. Protection of the BGP Speaker and Session > --------------------------------------------- > > "The BGP speaker, i.e., the host running BGP..." maybe I'm tainted by > IPv6 terminology, but I find the term "host" strange. A host is a > node > that does not forward traffic. A BGP speaker might very well forward > traffic, so maybe "node" is a better term. Otoh I've only ever used > the term BGP speaker myself... This is an interesting point; After some thought about it, I tend to agree. I hence exchange the two occurrences of 'host' with 'node'. With best regards, Tobias -- My working day may not be your working day. Please do not feel obliged to reply to my email outside of your normal working hours. ----------------------------------------------------------------- Tobias Fiebig, Forschungsgruppe Internet Architecture (INET) Max-Planck-Institut für Informatik, Campus E14, 66123 Saarbrücken E1 4 - Raum 517 mobil: +31 616 80 98 99
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
