Interface to the Routing System (I2RS) Traceability: Framework and Information Model
RFC 7922
Yes
(Alia Atlas)
No Objection
(Alvaro Retana)
(Ben Campbell)
(Deborah Brungard)
(Joel Jaeggli)
(Mirja Kühlewind)
(Terry Manderson)
Note: This ballot was opened for revision 08 and is now closed.
Alia Atlas Former IESG member
Yes
Yes
(for -08)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2016-05-04 for -09)
Unknown
Given that this is a framework document, rather than repeatedly declaring various operational aspects "out of scope" (7 times in 12 pages by my count), I would suggest just stating the requirements and guidance that are in scope. Readers should not be expecting to find lots of implementation details in this document. This would provide more clarity than saying that details are out of scope, but then specifying some of them anyway (e.g., for log trace rotation in 7.3). I agree with Stephen's DISCUSS and COMMENT.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -09)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(for -09)
Unknown
Benoît Claise Former IESG member
(was Discuss)
No Objection
No Objection
(2016-05-18 for -10)
Unknown
Thanks for addressing my DISCUSS points.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -09)
Unknown
Jari Arkko Former IESG member
(was Yes)
No Objection
No Objection
(2016-05-05 for -09)
Unknown
LATE BUT POSSIBLY IMPORTANT: I apologise for raising a last minute issue, but the points made in Elwyn Davie's Gen-ART review would deserve some discussion. I'm not looking to hold the document but wanted to ensure that the comments get discussed. I agree with Stephen's comments though.
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -09)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2016-05-05 for -09)
Unknown
I agree with Stephen's discuss and like the text he proposed.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -09)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2016-05-15 for -10)
Unknown
Thanks for handling my discuss point. The comments below are old and I didn't check if you'd done anything about them in -10 but that's fine either way unless you want to chat more about 'em. --------- OLD COMMENTS - 5.2: Requested/Applied Operation Data - I would guess this can include sensitive values, e.g. keys/passwords. Shouldn’t you say to at least be careful of those, or perhaps to not log them, or to zero out known sensitive values before logging? - 7.2: how is privacy an implementation detail? - 7.4: What does "being preferred" mean in 2119 terms? Why is one of the three options not mandatory-to-implement?
Suresh Krishnan Former IESG member
No Objection
No Objection
(2016-05-03 for -09)
Unknown
Section 5.2: Starting Timestamp and Ending Timestamp It is not clear what the terms 32-bit second and 32-bit microsecond mean here as the RFC3339 format seems to be a string representation (e.g. the seconds value will never be more than 59). It may be useful to restate these granularity requirements in terms of number of digits required after the decimal point instead Section 5.2: Entry ID Some more clarity as to how Entry IDs work would be useful. e.g. Is this a monotonically increasing integer? What happens when this wraps? What happens when the log file is rotated etc.
Terry Manderson Former IESG member
No Objection
No Objection
(for -09)
Unknown