Skip to main content

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.

Alvaro Retana No Objection

(Alia Atlas; former steering group member) Yes

Yes (for -08)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (2016-05-04 for -09)
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.

(Ben Campbell; former steering group member) No Objection

No Objection (for -09)

                            

(Benoît Claise; former steering group member) (was Discuss) No Objection

No Objection (2016-05-18 for -10)
Thanks for addressing my DISCUSS points.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -09)

                            

(Jari Arkko; former steering group member) (was Yes) No Objection

No Objection (2016-05-05 for -09)
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 steering group member) No Objection

No Objection (for -09)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2016-05-05 for -09)
I agree with Stephen's discuss and like the text he proposed.

(Mirja Kühlewind; former steering group member) No Objection

No Objection (for -09)

                            

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2016-05-15 for -10)
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 steering group member) No Objection

No Objection (2016-05-03 for -09)
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 steering group member) No Objection

No Objection (for -09)