Suresh: Thank you for catching these errors. See my comments below.
Summary: Section 2.3 (good catch). Section 4 and 6 - I think the document represents the WG consensus. I will review the emails, WG documents, and contact previous chairs. Susan Hares -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Suresh Krishnan Sent: Thursday, April 5, 2018 1:08 AM To: The IESG Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) Suresh Krishnan has entered the following ballot position for draft-ietf-i2rs-rib-info-model-15: 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-i2rs-rib-info-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 2.3. Regarding the OSPF route for 2001:DB8::1/32 Did you mean 2001:DB8::1/128 for the host route? If not, this example is wrong since 2001:DB8::1/32 expands to 2001:DB8:0000:0000:0000:0000:0000:1/32 -> 2001:DB8::/32 as the route Sue: Yes - this is an error. * Figure 4. Shouldn't the tunnel-encap and tunnel-decap also loop the packet back into nexthop processing just like the derived nexthops do? Suresh - I need to check the email list archives and get back to you on this point. My recollection was that there was a case where things people did not want to automatically loop this back. However, I cannot bring the discussion of 3.5 years ago to mind. I will take this as an action item as a reviewer to try to recreate the discussion. Thank you for mentioning this point. It is important to clarify in either case. * Section 6 I would have expected the match type to have some indication about whether it requires an exact match or LPM (e.g. A MAC route uses an exact match but an IPv6 route uses LPM). Has the WG discussed this? The short answer is yes, extensive in early interims, list discussions and in session. Can you provide more depth to your questions. For the early discussions, I may need to query Alia Atlas and Jeff Haas (previous chairs) to get the institutional memory on this topic. (One of the reason I really want to have this document discussed with Alia Atlas as AD0. _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
