Hi Warren, On Fri, 2020-03-20 at 12:33 -0400, Warren Kumari wrote: > On Fri, Mar 20, 2020 at 12:11 PM Randy Bush <randy@xxxxxxx> wrote: > > > > > > > BGP implementations have to take removal of private AS(s), > > > > > confederation, AS migration, etc into consideration. > > > > > > > > and the winds of summer. we do not need to enumerate all > > > > knobs, as > > > > if we could. > > > > > > > > > > But enumerating *some* helps the reader understand the context in > > > which > > > this is important/useful. > > > > which is why > > > > When applied to egress policy, the effective origin AS MUST be > > used > > to determine the Origin Validation state. The effective origin > > AS is > > that which will actually be the origin AS in the > > announcement. It > > might be affected by removal of private AS(s), confederation, AS > > migration, etc. > > > > One of the things that I personally like most about this document is > that it concise - it clarifies something for *implementors* to keep > in > mind / points out something where they might trip over something and > hurt themselves. > I only partially agree. For three reasons: - My experience over the last 12 months of running invalid==deny in production is that some implementors have managed to take every ambiguity in the various rov-related RFCs and translate it into bugs or fragile/hostile behavior. I think our lesson should be that even obvious-seeming spec gaps ought to be filled in this area. - Operators using implementations of this draft will observe behavioural differences between similar-seeming policy applied at different attachment points. This document should help them understand those differences. - We may very well see some implementations wind up with separate policy knobs for "enable rpki-rov" and "enable rpki-rov-egress". Again, operators will need a spec against which to validate that feature behaviour if it is claiming RFC compliance. > While I generally like examples and detail in RFCs, in this case it > would be "teaching your grandmother to suck eggs"[0] - the readers in > this case are folk who write BGP, the document basically says > "Warning: sharp object, careful with fingers" - having too much > detail > decreases the utility in this case. > > Again, I generally agree that documents should enumerate all of the > corner cases, have examples, etc - but in this case I think it would > do more harm than good... > I'm not suggesting turning this into a use-case doc. But enough color to make the mental link between real-world policy and protocol concepts is necessary, imho. Cheers, Ben > W > [0]: https://en.wikipedia.org/wiki/Teaching_grandmother_to_suck_eggs > > randy > > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
