Hi Acee! You're proposed edits would address my DISCUSS point. Thanks for this clarity.
> -----Original Message----- > From: Acee Lindem (acee) [mailto:[email protected]] > Sent: Wednesday, October 02, 2019 9:52 AM > To: Roman Danyliw <[email protected]>; The IESG <[email protected]> > Cc: [email protected]; Yingzhen Qu > <[email protected]>; [email protected]; [email protected]; > [email protected] > Subject: Re: Roman Danyliw's Discuss on draft-ietf-isis-yang-isis-cfg-40: > (with > DISCUSS) > > Hi Roman, > > On 10/1/19, 4:28 PM, "Roman Danyliw via Datatracker" <[email protected]> > wrote: > > Roman Danyliw has entered the following ballot position for > draft-ietf-isis-yang-isis-cfg-40: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 7. A DISCUSS for discussion. Thanks for this enumeration of > writeable > and readable nodes which could be considered sensitive. Per the list of > nodes > that could expose the topology of the network, wouldn’t the following also > have > sensitive topology information: > > -- /isis/local-rib > > Although not as detailed as the Link State Database, a case could also be > made for the local RIB. I'll add it to the sensitive operational data. Thanks. > -- /isis/hostnames > > These is basically a mapping of hostnames to ISO System IDs. The ISO System > ID is really only used by IS-IS (native CLNS is a thing of the past). I > really don't > see this as being all that useful to an attacker. Ok. > Furthermore, shouldn’t the log files also be protected as the errors or > status > posted there could also leak topology information: -- /isis/spf-log -- > /isis/lsp-log > > This doesn't include the contents of the LSP - only the LSP ID that caused the > SPF. I don't see how this would that sensitive - other than that someone > accessing the SPF and LSP logs could determine that the IS-IS Routing domain > is volatile. Ok. > Thanks, > Acee > > > > > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
