The major problem with Must nots and Should nots, are the underlying assumptions made by vendors. Most vendors will take a should not, and force a Must not so as to be as compliant to RFC specs as possible, and thereafter the feature will slowly become a known Must Not when in fact it is only a Should Not. This has happened before, on a number of different topics, but in the end, we are all subject to misunderstandings. I do agree though, that the practice of origininating prefixes in different AS's, needs to be established as either a should not or must not, and be applied as such. Jay, i do believe that a lack of clarification on such topics in the specs can only cause more ambiguity than anything else, and will lead to uncommon practices beign used. RFC's are documents that are used as reference, and therefor should be as clear as possible on every aspect, so as not to leave ambiguities. Thx, Morgan Dollard -----Original Message----- From: Jay Borkenhagen [mailto:jayb@braeburn.org] Sent: Friday, September 01, 2000 14:40 To: routing-wg@ripe.net Subject: Re: Routing parts of another LIR's PA block
this is not bgp spec. it is rfc 1930, see appended, and is not a MUST NOT.
Bovio> As you can see above Randy wrote that this is *NOT* a MUST NOT, Bovio> and not the opposite as people seem to believe. However, rfc1930 pre-dates rfc2119/bcp0014. Even though some authors may have used the MUST / MUST NOT / etc. notation prior to rfc2119, not all did: for example rfc1918, a prime candidate for a bunch of MUST NOTs if ever there was one, does not use such notation. Admittedly rfc1930 and rfc1918 are not documents in the standards track for which rfc2119 is most targetted, but that further implies that we can't put too much weight on a missing MUST NOT in rfc1930. I'm sure that if I'm off-base here, Randy will gently correct me. :-) Regardless, I feel that clarification on the correctness of the practice of orginating a prefix in multiple ASes is called for. On this I agree with Philip: Philip> Not commenting on the rights and wrong, but if this is really Philip> a "MUST NOT" it needs to be documented as such. Thanks. Jay B. -- Jay Borkenhagen jayb@braeburn.org Disclaimer ---------- This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication represents the originator's personal views and opinions, which do not necessarily reflect those of the NSC Group. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify administrator@nscglobal.com.