"People adopt standards so that they do not need to reinvest into these every 6 months. This is why it is called a "standard" and this is what IETF does as an organization."
I believe that standards are primarily to ensure interoperability at certain level among equipment from multiple vendors. Otherwise you may be quite happy with single-vendor, a.k.a. proprietary, solution. Regards, Greg On Mon, Mar 17, 2014 at 6:10 AM, Anton Ivanov (antivano) <[email protected] > wrote: > On 16/03/14 22:24, Tom Herbert wrote: > > On Sun, Mar 16, 2014 at 2:22 PM, Thomas D Nadeau > > <[email protected]> wrote: > >> that's kind of what you and russ were saying (and I agreeing): > iteration, evolution and refinement have often proven better than > revolution. > >> > > Iteration, evolution, and refinement are key and in fact this is > > precisely a core rationale in GUE and geneve. We need the ability to > > scale and adapt the data center to changing needs and threats, this is > > the requirement. This translates into a requirement for extensible > > protocols that we can modify and evolve as needed and in short > > turnaround time. > > I am sorry to disappoint you, network protocols are not sold in Walmart > in the "disposables" isle. > > Standard network protocol's lifetime is > 10 years. Even if we discard > hardware out of the equation, it is a standard it is still > 5 years. > > This is a result of economic realities - depreciation periods on > equipment, RFI, RFQs, costs of training staff, developing debugging, > benchmarking and analysis tools. > > People adopt standards so that they do not need to reinvest into these > every 6 months. This is why it is called a "standard" and this is what > IETF does as an organization. > > > > > The example that I give in security: what if next week the latest > > Snowden revelations expose some security hole in our data center-- if > > this hole can be addressed by adding a token to my packets, then I > > want to guarantee I retain the capability to do this. It's not > > acceptable that I'd have to go back to standards to change this, and > > neither is swapping out new hardware just because I extended a > > protocol. > > It is a bit difficult to take seriously an example that extends RFC 3514 > from one to 128 evil bit as a security measure. Especially against the > class of adversaries you are referring to. > > > > > I agree that modifying existing protocols would be the best direction > > but that is going to require a real proposal which we can measure > > against (no one has suggested a reasonable alternative). In lieu of > > modifying an existing protocol, developing a a new one based on known > > techniques and mechanisms is prudent. > > That is fine. Provided that you do requirements first. > > I have yet to see requirements. Sorry - "This extra 128 RFC 3514 bits > will defend us against the [insert agency name]" is not a requirement > (unless it is the first of April of course). > > When I see something that has a decent statement of requirements that > does not read like marchitecture we can have a proper engineering > conversation including how many standard engineering input units > (espressos) does it take to implement it. > > A. > > > > > Tom > > > > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
