Stéphane, Thank you for your reply. I appreciate it.
-éric On 01/10/2019, 21:31, "[email protected]" <[email protected]> wrote: Hi Eric, Thanks for your feedback. Please find some comments inline. Stephane -----Original Message----- From: Éric Vyncke via Datatracker <[email protected]> Sent: lundi 30 septembre 2019 22:50 To: The IESG <[email protected]> Cc: [email protected]; Yingzhen Qu <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Éric Vyncke's No Objection on draft-ietf-isis-yang-isis-cfg-40: (with COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-isis-yang-isis-cfg-40: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Disclaimer: I am neither an IS-IS export nor a YANG doctor ;-) I have 2 COMMENTs below. Regards, -éric == COMMENTS == -- Section 2.3 -- C.1) Is there a reason to have one example with a generic value of 250 that will never be used as you are either level-1 or level-2 ? (I am not an IS-IS expert of course) [SLI] I agree that a better example may have been to not have a value for level-2. We can fix this. -- Section 6 / YANG module -- C.2) About lsp-entry/remaining-lifetime, is there also a state about the received hold time ? It could be interesting to know whether the remaining lifetime is 3% of the original lifetime or 30% ;-) But again, I am not an IS-IS expert [SLI] I don't see the use case here. The fact is that there is no real original life time. The lifetime received from the neighbor is already a reduced value from the maximum-lifetime and depending on the neighbor the LSP has been learned from during the flooding this received lifetime may be slightly different. If we want to really track "lifetime issues", we may need to track the neighbor we learned from as well, but we don't keep track of all incarnation of an LSP from all neighbors, we just keep one (the more recent one). If needed such information may probably find a better home within an lsp-log kind of structure rather than in the LSDB. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
