> -----Original Message----- > From: Randy Bush [mailto:ra...@psg.com] > > aven i, an old fuddy duddy, kinda assume that an AS number is two or > four bytes, an ip address is ipv4 or ipv6, etc. i can understand > clarifying once in a document where it is critical to do so, but would > not be inclined to make it explicit everywhere AS is used or ip address > is used. > > randy [WEG] And I agree with the notion that unless specified as one or the other, it means the combination. However, especially in documents dealing with the mechanics of wrangling the bits on the router, that is not an implementation detail I want to leave purely to assumption/interpretation. Doesn't have to be stated and restated ad infinitum, I simply mention the other docs because I wasn't 100% certain where it made the most sense to cover it.
Based on the comments thus far, sounds like the questions are: Q1) is RFC4893 support a prerequisite for those routers supporting SIDR Origin and Path validation A: Yes. I believe that this needs to be explicitly documented, where is the most appropriate location? Q2) Do we need to incorporate something like: "MUST validate the AS Path _after_ reconstruction using AS4_PATH in the case where routing information comes from a peer which doesn't recognize 4-byte ASNs" as John suggested? Q3) do we need some sort of language recommending a method to handle AS23456 as an origin (or in a path in the case of BGPSec), especially if it does not coincide with valid AS4_PATH info? Technically if we're saying 4893 is a prereq, this shouldn't happen, but I could see it as a possible attack vector if we don't explicitly cover it. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
