Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
Hi Dave, I agree with you about the counter-marketing text that will only turn off potential implementers. However I think this would be more appropriate as Experimental. Yes, we give PS to specs that may not ever be implemented. But at least working groups are (usually) good at avoiding publishing multiple specs to solve the same problem. Here we do not have that gating function. If we foresee multiple solutions being published for this problem space, which is what I'm hearing, then Experimental is the better choice. Thanks, Yaron Date: Fri, 09 Aug 2013 19:33:49 -0700 From: Dave Crockerd...@dcrocker.net To: Stephen Farrellstephen.farr...@cs.tcd.ie Cc: Carsten Bormannc...@tzi.org,IETF Discussion Mailing List ietf@ietf.org Subject: Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard Message-ID:5205a68d.2020...@dcrocker.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 8/9/2013 6:09 PM, Stephen Farrell wrote: So some kind of statement that CBOR is one point in a design space (as opposed to an optimal solution for some set of design objectives) would be worthwhile. huh? a statement beyond the opening sentence of the introduction and its third paragraph? worthwhile to whom and for what? it's a spec (or perhaps a meta-spec.) it provides a capability. it needs to specify the what and how well enough to be usable. while ietf culture permits specifications to have quite a variety of commentary, historical or contextual discussion is not an essential part of the document, and certainly not discussion cast in a manner to denigrate the current spec. Counter-marketing that has the current spec self-deprecatingly casting itself as only one of many seems mostly worthwhile to get people to avoid using it. exp makes sense if there is doubt that it is technically workable, not because its success in the market is questionable. we give ps all the time to specs that have little clear market and go on gain small market use. from what i've seen, this is a carefully researched and crafted mechanism and i haven't noted anyone challenging it on basic technical grounds. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Aug 10, 2013, at 08:46, Yaron Sheffer yaronf.i...@gmail.com wrote: If we foresee multiple solutions being published for this problem space, which is what I'm hearing, then Experimental is the better choice. By that argument, TCP and UDP should be Experimental, too -- they are both in the transport protocol problem space. There is nothing Experimental about CBOR. Grüße, Carsten
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On 08/10/2013 03:33 AM, Dave Crocker wrote: On 8/9/2013 6:09 PM, Stephen Farrell wrote: So some kind of statement that CBOR is one point in a design space (as opposed to an optimal solution for some set of design objectives) would be worthwhile. huh? That's fair. My suggestion above wasn't a model of clarity;-) a statement beyond the opening sentence of the introduction and its third paragraph? And now that I read that again, yes, it does what I was trying try to ask for well enough. S. worthwhile to whom and for what? it's a spec (or perhaps a meta-spec.) it provides a capability. it needs to specify the what and how well enough to be usable. while ietf culture permits specifications to have quite a variety of commentary, historical or contextual discussion is not an essential part of the document, and certainly not discussion cast in a manner to denigrate the current spec. Counter-marketing that has the current spec self-deprecatingly casting itself as only one of many seems mostly worthwhile to get people to avoid using it. exp makes sense if there is doubt that it is technically workable, not because its success in the market is questionable. we give ps all the time to specs that have little clear market and go on gain small market use. from what i've seen, this is a carefully researched and crafted mechanism and i haven't noted anyone challenging it on basic technical grounds. d/
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
Howdy, You asked for community input, so I'll pipe up from the peanut gallery. I happen to be looking for a JSON-ish on-the-wire encoding with binary support, and I actually like what I see in CBOR. (I'll probably end up using MessagePack anyway though... popularity has a quality all its own) Comments inline... On Aug 9, 2013, at 2:52 PM, Barry Leiba barryle...@computer.org wrote: To the rest of the community: Does anyone else think it is not appropriate to publish CBOR as a Proposed Standard, and see who uses it? If the intention is to just document an encoding format/mechanism and see who uses it, I think 'Informational' achieves that goal and is more appropriate. If the intention is to base other standards-track work on this one in the near-term, and you've got some such use-case in mind for it, then 'Proposed Standard' seems reasonable to me if there're no strong objections. Afaict it's always been easier to move Info to PS later, but it's been a lot harder to deprecate PS. In the latter you have to prove something's broken/dangerous, while in the former you just have to prove people use it. Also, while I take Ted's point that people shouldn't feel constrained to use it in other WGs, in practice I find that both WG participants and WG Chairs do in fact give a huge bias to re-using something that's published as a PS. The burden of proof required to not re-use an existing PS RFC is very high. They say: It's a STANDARD! and the implication is its something written on a stone tablet given to a guy named Moses. 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] To the rest of the community: What is your view of Phill's technical arguments with CBOR? Do you agree that CBOR is flawed? No, it doesn't appear to contain technical errors nor fail to meet its self-stated design objectives. I think Phillip probably has different design objectives. But I'm not an expert in the field of object encoding theory. :) To the rest of the community: Do you agree with that concern? Do you think such an analysis and selection of common goals, leading to one (or perhaps two) new binary encodings being proposed is what we should be doing? Or is it acceptable to have work such as CBOR proposed without that analysis? I think it's fair to publish CBOR as Informational right now. I think publishing it as Proposed Standard would be ok if there wasn't strong disagreement, but it appears there is strong disagreement, including on how it came to be. I have no idea what the history of CBOR's development has been, but if it's truly the case that it's just a couple people's personal work, then that's cool but PS seems wrong to me if a third person says it's a bad design. [again, I have no idea if that's true/false] We rarely get 100% agreement even in WGs, but at least in WGs you get focused concentration from many participants. Usually I've only seen PS going the A-D route when there are no objections from anyone whatsoever. (but that could be a wrong impression) -hadriel
Re: Faraday cages...
On 08/09/2013 09:39 AM, Ted Lemon wrote: On Aug 8, 2013, at 9:05 PM, Keith Moore mo...@network-heretics.com wrote: Would being able to reliably know exactly who said everything that was said in a WG meeting visibly improve the quality of our standards? If the answer is not a clear yes (and I don't think it is) then I suggest that this topic is a distraction. If you mean will it improve what is written on the page, probably not. Will it decrease the likelihood of someone participating without identifying themself, and then violating the IPR rules? Possibly. AFAIK that's why we do it. Not so much because it is an iron-clad preventative, but because it to some degree removes the illusion of anonymity that might tempt someone to do something like that, or just be careless about it. If it's that important to catch people violating the IPR rules, perhaps we need to hire a court reporter for every WG meeting, and not rely on volunteer Jabber scribes to accurately capture what is said and who said it. Keith
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Aug 10, 2013, at 8:32 AM, Hadriel Kaplan hadriel.kap...@oracle.com 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... :)
Re: Faraday cages...
On Friday, August 09, 2013 09:39:12 Ted Lemon wrote: On Aug 8, 2013, at 9:05 PM, Keith Moore mo...@network-heretics.com wrote: Would being able to reliably know exactly who said everything that was said in a WG meeting visibly improve the quality of our standards? If the answer is not a clear yes (and I don't think it is) then I suggest that this topic is a distraction. If you mean will it improve what is written on the page, probably not. Will it decrease the likelihood of someone participating without identifying themself, and then violating the IPR rules? Possibly. AFAIK that's why we do it. Not so much because it is an iron-clad preventative, but because it to some degree removes the illusion of anonymity that might tempt someone to do something like that, or just be careless about it. Unless you're checking identification provided by sources all agree are trustworthy, you've done nothing of the sort. You may be able to attach an unverified identifier to a group of statements, but there's still no firm connection to identity (I'm not arguing in favor of one, but it seems a bit silly to expend resources to protect against something you aren't actually protecting against). Scott K
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On 8/10/2013 12:07 AM, Carsten Bormann wrote: On Aug 10, 2013, at 08:46, Yaron Sheffer yaronf.i...@gmail.com wrote: If we foresee multiple solutions being published for this problem space, which is what I'm hearing, then Experimental is the better choice. By that argument, TCP and UDP should be Experimental, too -- they are both in the transport protocol problem space. There is nothing Experimental about CBOR. One of the reasons we find groups choosing to avoid the IETF's standards process is its unpredictability. Folks here -- both on open discussion lists and often in the IESG -- think it's acceptable to invoke spontaneous, personal criteria, rather than pay attention to the rules we've put into place. We have criteria for the standards labels. They've gone through IETF consensus and they are supposed to have something akin to the force of (IETF) law. If someone feels that this specification does not qualify for Proposed Standard, they ought to feel obligated to begin with a citation of the portion of RFC 2026, Section 4.1.1 -- specifying the criteria for Proposed Standard -- that this specification fails to satisfy. In particular, they should draw carefully from the second paragraph of that section., By my own reading, this specification looks to be a pretty classic example of what we say we want for Proposed Standard. Most of this thread has ignored the IETF's own rules and criteria. As such, it's wasteful, at best, though I think it's actually destructive, since it provides fuel to the view that the IETF is a questionable venue for standards work. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Faraday cages...
On Aug 10, 2013, at 10:52 AM, Scott Kitterman sc...@kitterman.com wrote: Unless you're checking identification provided by sources all agree are trustworthy, you've done nothing of the sort. You may be able to attach an unverified identifier to a group of statements, but there's still no firm connection to identity (I'm not arguing in favor of one, but it seems a bit silly to expend resources to protect against something you aren't actually protecting against). I think you misunderstand the threat model.
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Aug 10, 2013, at 11:00 AM, Dave Crocker d...@dcrocker.net wrote: Most of this thread has ignored the IETF's own rules and criteria. As such, it's wasteful, at best, though I think it's actually destructive, since it provides fuel to the view that the IETF is a questionable venue for standards work. +1
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Aug 10, 2013, at 10:21 AM, Ted Lemon ted.le...@nominum.com wrote: 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'm not sure if you intended to, but you're implying non-standards-track docs are only for things we don't expect interoperability for, or cannot have or affect interoperability. I've read RFC 2026, and afaict non-standards-track docs can still be things that have or affect interoperability. That's not to say it ought not to be PS, obviously, but more that a statement of what we have is definitely a proposed standard seems like jumping the gun to me. 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. That's fair, and I should have been clearer. I think 'Informatonal' is more appropriate for now, because I don't think we know what the it is in your above statements - i.e., I don't know what Internet use-cases and/or IETF protocols CBOR was intended to be used for. For example, is the purpose of it to be JSONv2 for Javascript uses, vs. a new encoding for DNS AXFR/IXFR, vs. an encoding for a NoSQL inter-DB synch protocol, vs. a new encoding for MIME bodies in SMTP. I don't see how we can know whether an encoding mechanism is sound or broken without knowing what its intended/motivating use-case is. But, if the IESG feels an encoding mechanism doesn't need any targeted use-case to be published as a PS, then please ignore my email for purposes of consensus. I'm not strongly for/against - just answering Barry's original question, from the peanut gallery as I said in my original email. And as I said in my original email: [the draft] doesn't appear to contain technical errors nor fail to meet its self-stated design objectives. 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. I read RFC 1958 yesterday when I saw your previous email, and I read it again this morning when I saw your comment above. But I still don't grok which part of it let's me tell a WG Chair: No, just because there's a PS RFC doing something similar, doesn't mean we can't do something better and more appropriate for this particular application. I mean I can tell them that now, but it doesn't carry much weight. What part of RFC 1958 would help me making such a statement? -hadriel
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
--On Saturday, August 10, 2013 11:14 -0400 Ted Lemon ted.le...@nominum.com wrote: On Aug 10, 2013, at 11:00 AM, Dave Crocker d...@dcrocker.net wrote: Most of this thread has ignored the IETF's own rules and criteria. As such, it's wasteful, at best, though I think it's actually destructive, since it provides fuel to the view that the IETF is a questionable venue for standards work. +1 +1 more. Not doing this sort of thing to ourselves is probably far more important, in the long run, than trying to slightly re-tune the language of 2026 in that hope that will impress someone. The latter might still be worthwhile, but it is, IMO, far more important to stop shooting ourselves in the foot. john
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Aug 10, 2013, at 11:30 AM, Hadriel Kaplan hadriel.kap...@oracle.com wrote: I'm not sure if you intended to, but you're implying non-standards-track docs are only for things we don't expect interoperability for, or cannot have or affect interoperability. I've read RFC 2026, and afaict non-standards-track docs can still be things that have or affect interoperability. That's not to say it ought not to be PS, obviously, but more that a statement of what we have is definitely a proposed standard seems like jumping the gun to me. Fair point. RFC2026 does not in fact make the distinction I made. Here is what RFC 2026 says about proposed standards: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Here is what it says about Informational documents: An Informational specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see section 4.2.3). In practice, the qualifications for Informational generally don't give us any reasonable expectation of interoperability, nor do they require it. There is one exception: Specifications that have been prepared outside of the Internet community and are not incorporated into the Internet Standards Process by any of the provisions of section 10 may be published as Informational RFCs, with the permission of the owner and the concurrence of the RFC Editor. As a practice, we also do sometimes publish informational documents that were produced by working groups and that were intended to be standards, but that were not selected by the working group to be standards, but that nevertheless are considered to be useful to the community for informational purposes. But the most common examples of informational documents are operational practices documents that do not qualify as BCP, reports, architecture documents, requirements documents, gap analyses and other analyses. It is on this basis that I made the claim that informational documents generally aren't intended to interoperate. That's fair, and I should have been clearer. I think 'Informatonal' is more appropriate for now, because I don't think we know what the it is in your above statements - i.e., I don't know what Internet use-cases and/or IETF protocols CBOR was intended to be used for. For example, is the purpose of it to be JSONv2 for Javascript uses, vs. a new encoding for DNS AXFR/IXFR, vs. an encoding for a NoSQL inter-DB synch protocol, vs. a new encoding for MIME bodies in SMTP. I don't see how we can know whether an encoding mechanism is sound or broken without knowing what its intended/motivating use-case is. Section 1.1 goes on at some length about the intended use for the document is. If you believe it is unclear or incomplete, some pointed questions about it would be entirely appropriate. But, if the IESG feels an encoding mechanism doesn't need any targeted use-case to be published as a PS, then please ignore my email for purposes of consensus. I'm not strongly for/against - just answering Barry's original question, from the peanut gallery as I said in my original email. And as I said in my original email: [the draft] doesn't appear to contain technical errors nor fail to meet its self-stated design objectives. I can't speak for the IESG. You already know what my opinion as an individual AD is—I am not strongly in favor of publishing this document, because it's out of my area, but I haven't seen any argument raised against publishing it that I find convincing; in particular I do think it's appropriate to publish it as a standards-track document if it's found to have consensus. I read RFC 1958 yesterday when I saw your previous email, and I read it again this morning when I saw your comment above. But I still don't grok which part of it let's me tell a WG Chair: No, just because there's a PS RFC doing something similar, doesn't mean we can't do something better and more appropriate for this particular application. I mean I can tell them that now, but it doesn't carry much weight. What part of RFC 1958 would help me making such a statement? Section 3. If you only read section 3.2, and don't read the last clause of the last sentence in that section, then you might come to the
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Aug 10, 2013, at 12:25 PM, Ted Lemon ted.le...@nominum.com wrote: Section 1.1 goes on at some length about the intended use for the document is. If you believe it is unclear or incomplete, some pointed questions about it would be entirely appropriate. To expand on this slightly, the point is that if you say it's not clear to me what the use case for this document is, that's a valid objection, and the authors ought to address it, either by explaining to the satisfaction of the consensus-caller and, more generally, the reviewers, why it's not relevant, or by fixing the document to be clearer about what the current intended use cases are. But if you want that to happen, you should really raise your objection in a way that makes it clearly actionable, so that the authors know you are asking them to do something.
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Aug 10, 2013, at 6:30 PM, Hadriel Kaplan hadriel.kap...@oracle.com wrote: But, if the IESG feels an encoding mechanism doesn't need any targeted use-case to be published as a PS, then please ignore my email for purposes of consensus. I'm not strongly for/against - just answering Barry's original question, from the peanut gallery as I said in my original email. And as I said in my original email: [the draft] doesn't appear to contain technical errors nor fail to meet its self-stated design objectives. I don't know about the IESG, but I don't think an encoding mechanism or for that matter any format needs to have a targeted use case. WebSec is currently debating ([1] whether to put the key pinning data in an HTTP header or in a resource. If we choose the latter, there will be the question of encoding, and we will probably consider things like XML, JSON, ASN.1, and CBOR, or roll our own new one-time format. If someone in the group wants to do the one-off format, we will ask why not use XML, JSON, or CBOR (nobody's going to ask about ASN.1, because those that care enough to suggest it also know to call it BER), and of course you'll need a good reason not to use a documented format, whether it's standard or not. Those will be the obvious choices regardless of whether CBOR is Informational, Experimental, PS, or still a draft-bormann. Nobody's proposing technical changes, so we might as well stick an RFC number on it. IMO the only time you stick the INFORMATIONAL label on a protocol or an encoding, is when you are just documenting a protocol or an encoding that exists outside the IETF, and the IETF is not given change control. See draft-ietf-websec-x-frame-options for an example. Experimental is for things where we don't know if they work in general or if they scale. IOW, we're not sure they're appropriate for their stated goal. That is not the case with CBOR. Yes, we can reference CBOR as normative from draft-ietf-websec-key-pinning (intended to be PS) with a downref. But just because downrefs exist does not mean we should aim for them. PS is the right choice IMO. Yoav
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On 8/10/13 5:00 PM, Dave Crocker wrote: One of the reasons we find groups choosing to avoid the IETF's standards process is its unpredictability. Our processes must be stable, but people have different reasons for articulating concern. 2026 is not meant to be the singular criteria. In fact we have for a long time accepted the additional questions that form a working group, as well. And unpredictability is part and parcel of standards activity: you can't buy a standard at the IETF, which is what predictability implies, if taken to extremes. And people not familiar with the IETF often take it to extremes. A perfect example was Tim Berners-Lee who wanted to standardize HTML, but didn't want to give up control of the specification. It just doesn't work that way. Now that we're done with generalities, I'll just chime in and say that the spec in question seems perfectly fine to advance as a Proposed Standard. I do wonder whether CBOR is better than compressed JSON, but I understand that in this context CPU may be a limiting factor. There is an architectural question hiding here: when we use CBOR in various protocols, we may be optimizing for the wrong set of devices overall. Conversely, we may be optimizing for just the right devices since the so-called Internet of Things that are low end devices will outnumber other devices. Which is it? Either way, it seems to me we can't answer without CBOR or something like it, so... let's have it, then. Eliot
Re: TCPMUX (RFC 1078) status
On 8/10/2013 1:43 AM, Martin Sustrik wrote: Hi all, Does anyone have any idea how widely is TCPMUX (RFC 1078) protocol used? Is it the case that there are inetd daemons in TCPMUX mode running everywhere, or can it be rather considered a dead protocol? Specifically, if I implement a new TCPMUX daemon how likely I am to clash with an existing TCPMUX daemon listening on port 1? It's in the FreeBSD inetd, among others, but to to my knowledge, nobody actually turns it on. There are probably security issues. -- Wes Eddy MTI Systems
Re: TCPMUX (RFC 1078) status
On 10/08/13 21:29, Wesley Eddy wrote: On 8/10/2013 1:43 AM, Martin Sustrik wrote: Hi all, Does anyone have any idea how widely is TCPMUX (RFC 1078) protocol used? Is it the case that there are inetd daemons in TCPMUX mode running everywhere, or can it be rather considered a dead protocol? Specifically, if I implement a new TCPMUX daemon how likely I am to clash with an existing TCPMUX daemon listening on port 1? It's in the FreeBSD inetd, among others, but to to my knowledge, nobody actually turns it on. There are probably security issues. I am aware of inetd and alternatives. I was more interested whether there's some significant deployment base of systems with TCPMUX turned on. So far, the only relevant info I've found is that TCPMUX was turned on by default on SGI Irix systems, but given that these had end of life in 2006, I guess there's not much of them left out there. Martin
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Sat, Aug 10, 2013 at 3:21 PM, Ted Lemon ted.le...@nominum.com wrote: On Aug 10, 2013, at 8:32 AM, Hadriel Kaplan hadriel.kap...@oracle.com 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 You seem to think that the IETF process is a model of clarity and purpose. For over a decade the vast majority of IETF standards were not STANDARDs. It seems rather odd to be referring to 2026 as holly writ here when we have since changed the process so that there are two steps instead of three. This being largely to recognize the fact that the contemporary criteria for PS were far in excess of what the criteria had been twenty years ago. Standards are what people interpret them as, no more, not less. If the IETF calls something a cat then people are going to expect it to be a feline even if RFC 3141.56 says that a 'cat' is actually an umbrella. The obvious reading of 2026 is that Proposed Standard is a document that describes something that the IETF is proposing should be a standard and that the part that David cites states the minimum criteria for documents that are to be endorsed by the IETF as standards proposals. Like it or not, the endorsement of the IETF is what the various people who hire consultants to work on IETF specifications are seeking. 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. It really is neither, it is an experiment, the experiment being to see whether anyone will use it. -- Website: http://hallambaker.com/
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Sat, Aug 10, 2013 at 7:12 PM, Yoav Nir y...@checkpoint.com wrote: On Aug 10, 2013, at 6:30 PM, Hadriel Kaplan hadriel.kap...@oracle.com wrote: But, if the IESG feels an encoding mechanism doesn't need any targeted use-case to be published as a PS, then please ignore my email for purposes of consensus. I'm not strongly for/against - just answering Barry's original question, from the peanut gallery as I said in my original email. And as I said in my original email: [the draft] doesn't appear to contain technical errors nor fail to meet its self-stated design objectives. I don't know about the IESG, but I don't think an encoding mechanism or for that matter any format needs to have a targeted use case. WebSec is currently debating ([1] whether to put the key pinning data in an HTTP header or in a resource. If we choose the latter, there will be the question of encoding, and we will probably consider things like XML, JSON, ASN.1, and CBOR, or roll our own new one-time format. If someone in the group wants to do the one-off format, we will ask why not use XML, JSON, or CBOR (nobody's going to ask about ASN.1, because those that care enough to suggest it also know to call it BER), and of course you'll need a good reason not to use a documented format, whether it's standard or not. Those will be the obvious choices regardless of whether CBOR is Informational, Experimental, PS, or still a draft-bormann. Nobody's proposing technical changes, so we might as well stick an RFC number on it. IMO the only time you stick the INFORMATIONAL label on a protocol or an encoding, is when you are just documenting a protocol or an encoding that exists outside the IETF, and the IETF is not given change control. See draft-ietf-websec-x-frame-options for an example. Experimental is for things where we don't know if they work in general or if they scale. IOW, we're not sure they're appropriate for their stated goal. That is not the case with CBOR. Yes, we can reference CBOR as normative from draft-ietf-websec-key-pinning (intended to be PS) with a downref. But just because downrefs exist does not mean we should aim for them. PS is the right choice IMO. If key pinning was to use CBOR rather than JSON or ASN.1, I think you are going to be laughed at. Since pins are to ASN.1 encoded certificates, I think you are obliged to choose ASN.1 if you want the browser people to implement. But lets consider the case that you did decide on CBOR. The Working Group would then be obliged to look at the specification and persuade key stakeholders to implement the code. And that might result in changes of the 'remove this half of the specification before we will accept it' variety or the 'we won't implement unless the encoding is ASN.1'. At the very least it means that the 'design goals' would get a work out. But why would CBOR be on the table and not BJSON or JSON-B or any of the other potential choices? -- Website: http://hallambaker.com/
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Aug 10, 2013, at 10:55 PM, Phillip Hallam-Baker hal...@gmail.commailto:hal...@gmail.com wrote: On Sat, Aug 10, 2013 at 7:12 PM, Yoav Nir y...@checkpoint.commailto:y...@checkpoint.com wrote: On Aug 10, 2013, at 6:30 PM, Hadriel Kaplan hadriel.kap...@oracle.commailto:hadriel.kap...@oracle.com wrote: But, if the IESG feels an encoding mechanism doesn't need any targeted use-case to be published as a PS, then please ignore my email for purposes of consensus. I'm not strongly for/against - just answering Barry's original question, from the peanut gallery as I said in my original email. And as I said in my original email: [the draft] doesn't appear to contain technical errors nor fail to meet its self-stated design objectives. I don't know about the IESG, but I don't think an encoding mechanism or for that matter any format needs to have a targeted use case. WebSec is currently debating ([1] whether to put the key pinning data in an HTTP header or in a resource. If we choose the latter, there will be the question of encoding, and we will probably consider things like XML, JSON, ASN.1, and CBOR, or roll our own new one-time format. If someone in the group wants to do the one-off format, we will ask why not use XML, JSON, or CBOR (nobody's going to ask about ASN.1, because those that care enough to suggest it also know to call it BER), and of course you'll need a good reason not to use a documented format, whether it's standard or not. Those will be the obvious choices regardless of whether CBOR is Informational, Experimental, PS, or still a draft-bormann. Nobody's proposing technical changes, so we might as well stick an RFC number on it. IMO the only time you stick the INFORMATIONAL label on a protocol or an encoding, is when you are just documenting a protocol or an encoding that exists outside the IETF, and the IETF is not given change control. See draft-ietf-websec-x-frame-options for an example. Experimental is for things where we don't know if they work in general or if they scale. IOW, we're not sure they're appropriate for their stated goal. That is not the case with CBOR. Yes, we can reference CBOR as normative from draft-ietf-websec-key-pinning (intended to be PS) with a downref. But just because downrefs exist does not mean we should aim for them. PS is the right choice IMO. If key pinning was to use CBOR rather than JSON or ASN.1, I think you are going to be laughed at. Since pins are to ASN.1 encoded certificates, I think you are obliged to choose ASN.1 if you want the browser people to implement. I think the browser people also have a JSON parser lying around somewhere. But I agree that CBOR would increase the cost of implementation, and that's a good argument against choosing CBOR. It's also a good argument against choosing any new encoding anybody might propose. But lets consider the case that you did decide on CBOR. The Working Group would then be obliged to look at the specification and persuade key stakeholders to implement the code. And that might result in changes of the 'remove this half of the specification before we will accept it' variety or the 'we won't implement unless the encoding is ASN.1'. At the very least it means that the 'design goals' would get a work out. But why would CBOR be on the table and not BJSON or JSON-B or any of the other potential choices? I don't see why any of them would be off the table. Yoav
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Aug 10, 2013, at 12:25 PM, Ted Lemon ted.le...@nominum.com wrote: On Aug 10, 2013, at 11:30 AM, Hadriel Kaplan hadriel.kap...@oracle.com wrote: That's fair, and I should have been clearer. I think 'Informatonal' is more appropriate for now, because I don't think we know what the it is in your above statements - i.e., I don't know what Internet use-cases and/or IETF protocols CBOR was intended to be used for. For example, is the purpose of it to be JSONv2 for Javascript uses, vs. a new encoding for DNS AXFR/IXFR, vs. an encoding for a NoSQL inter-DB synch protocol, vs. a new encoding for MIME bodies in SMTP. I don't see how we can know whether an encoding mechanism is sound or broken without knowing what its intended/motivating use-case is. Section 1.1 goes on at some length about the intended use for the document is. If you believe it is unclear or incomplete, some pointed questions about it would be entirely appropriate. OK... I read that section previously, and I just re-read it now, and I think that section is quite clear on the *design* goals. And I think it meets those goals. That's why I said, if that's all that's needed for PS, then I'm cool. I literally don't know whether or not a PS for an encoding mechanism needs any more than that - I deal mostly with protocol docs, not encoding docs. And I don't know whether the same considerations make sense or not for an encoding doc. I'm quite sensitive to not blocking people from progress, as I've been in similar situations myself. So I'm just giving my 2 cents, because I happen to have looked at it for using it as a binary JSON alternative for a non-IETF application. What I'm curious about is the intended IETF protocol use-case(s). I don't think a use-case even needs to be stated in the doc, because this doc is really about a generic object encoding mechanism; it has properties X, and if you want properties X then you should use it. I'm more just asking what the authors were targeting, if anything. For example, if it's intended for a new encoding mechanism for IPFIX I'd have strong opinions one way; whereas if it's a new encoding mechanism for DNS zone transfers I'd probably have a different opinion. But if the use-case is just anything that needs our properties X, that's fine too. From reading the doc, it feels like it's intended to be the successor for MessagePack. Afaik, MessagePack is used by a broad community as a drop-in replacement for JSON. (I could be wrong on that, it's just my impression and how I plan to use it) If that's the goal of CBOR, then I think it will have a tough time of it but I've got no objection to letting it try. I read RFC 1958 yesterday when I saw your previous email, and I read it again this morning when I saw your comment above. But I still don't grok which part of it let's me tell a WG Chair: No, just because there's a PS RFC doing something similar, doesn't mean we can't do something better and more appropriate for this particular application. I mean I can tell them that now, but it doesn't carry much weight. What part of RFC 1958 would help me making such a statement? Section 3. If you only read section 3.2, and don't read the last clause of the last sentence in that section, then you might come to the conclusion that once an RFC is published that solves a specific problem, no other RFC can ever be published that addresses a similar problem. Section 3.2 definitely does argue that if you have a good solution to a problem, you shouldn't invent a new solution to the problem. If you were to apply section 3.2 strictly without all the caveats, you could argue that this document shouldn't be published because ASN.1 solves the same problem. But that's not a correct reading of the document, because of all the other caveats that are listed in subsequent sections. Ahh, I see. I did read that sentence but it felt more like an afterthought escape clause. :) That's good to know though. -hadriel
RE: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
BCP 70 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols attempted to outline some of the design considerations for data representation using XML. In 2003, it represented the consensus and also the disagreements about what was best current practice at the time. Section 3 of BCP 70, Alternatives, lists some of the alternatives and provides a comparison. I think what might be missing is an update to BCP 70 or a companion which more explicitly compares XML, JSON, CBOR and other alternatives in use in IETF protocols. If you're interested in this work, perhaps you might review BCP 70 and suggest updates. Larry -- http://larry.masinter.net
Gen-ART Telechat review of draft-jabley-dnsext-eui48-eui64-rrtypes-05
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-jabley-dnsext-eui48-eui64-rrtypes-05 Reviewer: Peter Yee Review Date: July-07-2013 IETF LC End Date: July-17-2013 IESG Telechat date: August-15-2013 Summary: This draft is basically ready for publication as an Informational RFC, but has nits that should be fixed before publication. [Ready with nits] This review is the same as the IETF LC review of this draft, which remain unchanged for the telechat. This draft defines DNS Resources Record Types for encoding IEEE 802 EUI-48 and EUI-64 addresses. Potential privacy issues with this scheme have been soundly beaten to death with extreme prejudice. Major issues: Minor issues: Nits: Page 1, Abstract, 1st paragraph: After e.g., append a comma and delete an extraneous space before Ethernet. Page 3, Introduction, 1st paragraph, 2nd sentence: change This to These and change specification defines to specifications define. Page 3, Introduction, 2nd paragraph: append a comma after e.g.. -Peter Yee
meeting summary article
I wrote a brief summary of the meeting and what was important from my perspective. Here's the article: http://www.ietf.org/blog/2013/08/meeting-summary/ Thank you all for a very productive meeting! For your information, we also had some media interested in the meeting, e.g., radio programs and articles on the web. Here are some of those that I know about, although I am not entirely sure what is being said :-) http://podcast-mp3.dradio.de/podcast/2013/07/30/dlf_20130730_1645_992ecd8d.mp3 http://www.dradio.de/dlf/sendungen/computer/2202387/ http://www.dradio.de/dlf/sendungen/computer/2202291/ http://www.dradio.de/dlf/sendungen/computer/2202419/ http://www.heise.de/newsticker/meldung/87-IETF-Treffen-im-Schatten-des-Ueberwachungsskandals-1925495.html http://www.heise.de/newsticker/meldung/IETF-87-Wann-ist-ein-Standard-ein-Standard-1926705.html http://www.heise.de/newsticker/meldung/IETF-87-Opus-Audiocodec-kommt-in-den-Container-1926465.html http://www.webhostlist.de/2013/07/ietf-meeting-in-berlin-offene-internetstandards-durch-technische-exzellenz/ http://www.domain-recht.de/domain-events/sonstige-events/isoc-auftaktveranstaltung-zum-ietf-treffen-in-berlin-63191.html http://policyreview.info/articles/news/ietf-–-berlin-meeting-did-not-overlook-mass-surveillance/186 Jari Arkko
meeting summary report
I wrote a brief summary of the meeting and what was important from my perspective. Here's the article: http://www.ietf.org/blog/2013/08/meeting-summary/ Thank you all for a very productive meeting! For your information, we also had some media interested in the meeting, e.g., radio programs and articles on the web. Here are some of those that I know about, although I am not entirely sure what is being said :-) http://podcast-mp3.dradio.de/podcast/2013/07/30/dlf_20130730_1645_992ecd8d.mp3 http://www.dradio.de/dlf/sendungen/computer/2202387/ http://www.dradio.de/dlf/sendungen/computer/2202291/ http://www.dradio.de/dlf/sendungen/computer/2202419/ http://www.heise.de/newsticker/meldung/87-IETF-Treffen-im-Schatten-des-Ueberwachungsskandals-1925495.html http://www.heise.de/newsticker/meldung/IETF-87-Wann-ist-ein-Standard-ein-Standard-1926705.html http://www.heise.de/newsticker/meldung/IETF-87-Opus-Audiocodec-kommt-in-den-Container-1926465.html http://www.webhostlist.de/2013/07/ietf-meeting-in-berlin-offene-internetstandards-durch-technische-exzellenz/ http://www.domain-recht.de/domain-events/sonstige-events/isoc-auftaktveranstaltung-zum-ietf-treffen-in-berlin-63191.html http://policyreview.info/articles/news/ietf-–-berlin-meeting-did-not-overlook-mass-surveillance/186 Jari Arkko
