Re: Last Call: <draft-bormann-cbor-04.txt> (Concise Binary Object Representation (CBOR)) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Aug 10, 2013, at 8:32 AM, Hadriel Kaplan <hadriel.kaplan@xxxxxxxxxx> wrote:
> I'm not saying that will happen in this case at all, but we shouldn't kid ourselves that it doesn't matter.  If it didn't matter, people wouldn't care about labeling their IDs Informational or Experimental.  People seem to *want* the PS label, and I don't think it's because people want to upgrade to an IS someday. [as an aside: that's what the 2-level RFC experiment should teach us - that there is only 1 level that people care about, in practice]

It almost certainly will happen.   But "we shouldn't do this because someone might later on draw an incorrect conclusion about what we did" is just not a valid argument against advancing the document to proposed standard.   What it is is an argument for understanding the IETF process so that when people make assertions about this sort of thing, you can have a meaningful debate with them and point at RFCs.   Otherwise your working group can get sidetracked by the ownership assertion problem, which as you are already aware can be very damaging.

The reason we call things "proposed standard" is because we expect interoperability.   A thing that can't have or affect interoperability probably isn't a "proposed standard."   In this case, what we have is definitely a proposed standard and not an informational document; the question is whether it's a standard that will get IETF consensus.

I should point out that a lot of arguments have been raised here that don't really affect consensus.   The arguments to raise if you think a proposed standard is a bad idea are technical arguments: "this won't work because of X" or architectural arguments: "we shouldn't do this because there is a better way to do it that fits better with the Internet architecture" or "this is needlessly complicated for the use case we are trying to address."

Importantly, "we shouldn't do this because there's a proposed standard that does something similar" is _not_ a valid argument; if the proposed standard is technically or architecturally better, _that_ is the argument to raise.   The mere existence of the RFC is not an argument in itself.

Seriously, RFC 1958 is a good document to read if you are interested in this issue.   You might also want to read RFC 5218.

(Dave Thaler will know why I know to reference these two documents... :)






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]