Dear reviewer, Thanks for reviewing the draft. As a co-author of draft, I think the most important value of this document is "formalizing the problem of intra-domain source address validation", which is worth of publication as an RFC. Understanding and consenting the problem of intra-domain source address validation is not a straightforward or intuitive issue. In the SAVNET WG, there are a lot of debates for this draft in different stages. For instance, whether we need to tackle the validation on internal routers of an AS, or just focusing on the AS boundary. I agree with you that the "discussion" is important because it can help people better understand the problem and benefit the whole community. In the current version of this document, we try to make it concise so we do not put the discussion details. Although we think this version is enough for understanding the problem, we can add more details if people think necessary. As a whole, the value of this draft is not just guiding the WG, but more importantly, defining the problem of intra-domain source address validation, which may also help future works beyond this WG. We want to make the thorough discussions on this problem have footprint in the RFC series. That's the reason why we authors, WG chairs and other people think we should publish as an RFC. Best, Dan -----邮件原件----- 发件人: forwardingalgorithm@xxxxxxxx <forwardingalgorithm@xxxxxxxx> 代表 Sarah Banks via Datatracker 发送时间: 2025年1月25日 3:30 收件人: ops-dir@xxxxxxxx 抄送: draft-ietf-savnet-intra-domain-problem-statement.all@xxxxxxxx; last-call@xxxxxxxx; savnet@xxxxxxxx 主题: [savnet] Opsdir last call review of draft-ietf-savnet-intra-domain-problem-statement-10 Reviewer: Sarah Banks Review result: Not Ready Hi authors! I appreciate that you took the time to think through and write a well written gap analysis draft. I believe I understand the intent, and I applaud it. That said, my opinion is that generally, these types of documents are not ones I'd expect to see as an RFC; they'd either guide the WG into some work stream doc(s), or roll into one of those docs directly. I can see the case for exceptions. For example, sometimes issues with requirements and implementation are thorny enough where having a "discussion" doc could make sense. However, this draft covers requirements that are somewhat broad, with no consideration for any of the issues or obstacles to overcome, or tradeoffs in one approach versus another, where the requirements are potentially OK by themselves, but without anything else with them, I find it a good discussion point, but not an informational RFC. -- savnet mailing list -- savnet@xxxxxxxx To unsubscribe send an email to savnet-leave@xxxxxxxx -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
