cbor-05 (was: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard)
This was a rather productive IETF Last Call! Thank you all for the many comments. Paul and I have taken your comments and believe that we have incorporated the ones that we said we would. The -05 has just been published: http://tools.ietf.org/html/draft-bormann-cbor-05 ... and there are lots of diffs; see http://tools.ietf.org/rfcdiff?url2=draft-bormann-cbor-05 We would particularly like review of the changes we made in section 3, where we tightened up a lot of the "might" language for parsers. We also clarified that what we were too-loosely calling a "parser" was actually a "decoder" that has two sub-parts: a parser (grammar only) and semantic processor (checking for validity). We hope that this major edit alleviates most concerns, but further comments are certainly appreciated. Grüße, Carsten
Re: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard
Hi Randy, I prefer to leave this question to people who know something about Netconf, i.e. not me. But let me just say that, based on my thoroughly extensive 5-min. research, YANG seems to be incompatible with CBOR. Thanks, Yaron On 2013-08-14 04:53, Randy Presuhn wrote: Hi - From: Yaron Sheffer Sent: Aug 13, 2013 2:11 PM To: IETF Discussion Mailing List Subject: re: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard ... - The "diagnostic notation" can be used very effectively for things like configuration files, e.g. if an application already uses CBOR on the wire. Therefore I would suggest to formalize it a bit more, so that we also have interoperability at this level. Do you envision it as an encoding for Netconf? Randy
Re: Community Input Sought on SOWs for RFC Production Center and RFCPublisher
- Original Message - From: "Ted Lemon" To: "John Levine" Cc: "IETF Discussion Mailing List" Sent: Tuesday, August 13, 2013 4:03 PM > On Aug 13, 2013, at 9:51 AM, John Levine wrote: > > There's no great way > > to send around a redlined document and I'd say that Word formats are > > currently the least bad. > > rfcdiff does really nicely, actually. And HTML can also be used to produce a genuine red-lined document (but I expect that you know that:-) Sharon Chisholm used to do it for Netconf as with draft-ietf-netconf-notification-09.txt.prerelease2 January is the operative tag. Tom Petch
Re: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard
> YANG seems to be incompatible with CBOR. so what does that say about yang, yang's suitability for netconf, cbor, and cbor's suitability? randy
Re: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Aug 14, 2013, at 13:40, Randy Bush wrote: >> YANG seems to be incompatible with CBOR. > > so what does that say about yang, yang's suitability for netconf, cbor, > and cbor's suitability? Good question. I'm not sure the jury is even out on that yet. Yaron reminded me that netconf is using XPath for various purposes, so a CBOR rendition of netconf would need to do the same that you would need for doing netconf with JSON: either replace XPath with something else (indeed causing some incompatibility), or explain how to use XPath with the CBOR/JSON translation of the YANG model (which might be interesting). CBOR certainly has no trouble carrying around the data described by a YANG model. (Indeed, CBOR's decimal fractions were inspired by YANG's.) But then, I don't have an opinion whether adding a binary object representation to the netconf ecosystem is on the agenda. Grüße, Carsten
Re: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Wed, Aug 14, 2013 at 12:31 AM, Yaron Sheffer wrote: > Hi Randy, > > I prefer to leave this question to people who know something about Netconf, > i.e. not me. > > But let me just say that, based on my thoroughly extensive 5-min. research, > YANG seems to be incompatible with CBOR. > Can you be more specific? What is incompatible about YANG? > Thanks, > Yaron > Andy > On 2013-08-14 04:53, Randy Presuhn wrote: >> >> Hi - >> >>> From: Yaron Sheffer >>> Sent: Aug 13, 2013 2:11 PM >>> To: IETF Discussion Mailing List >>> Subject: re: Last Call: (Concise Binary >>> Object Representation (CBOR)) to Proposed Standard >> >> ... >>> >>> - The "diagnostic notation" can be used very effectively for things like >>> configuration files, e.g. if an application already uses CBOR on the >>> wire. Therefore I would suggest to formalize it a bit more, so that we >>> also have interoperability at this level. >> >> >> Do you envision it as an encoding for Netconf? >> >> Randy >> >
Re: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard
On 8/13/2013 3:20 PM, Joe Hildebrand wrote: One of the reasons why I like the CBOR tag applied to a byte stream is that it can be used to skip parsing on entire sections (no matter their underlying types) in processors that don't need to understand that section. This is an example of the core reason that having a "one true standard" is not appropriate for many topics: design choices optimize along particular axes, giving particular optimizations, typically at the expense of others. Different operating context benefit from different optimizations. It makes sense for a specification to document its tradeoffs; it often does not make sense to choose only one such specification for use in all scenarios. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard
Hi Andy, Please see Carsten's mail on this subject. Thanks, Yaron On 2013-08-14 18:18, Andy Bierman wrote: On Wed, Aug 14, 2013 at 12:31 AM, Yaron Sheffer wrote: Hi Randy, I prefer to leave this question to people who know something about Netconf, i.e. not me. But let me just say that, based on my thoroughly extensive 5-min. research, YANG seems to be incompatible with CBOR. Can you be more specific? What is incompatible about YANG? Thanks, Yaron Andy On 2013-08-14 04:53, Randy Presuhn wrote: Hi - From: Yaron Sheffer Sent: Aug 13, 2013 2:11 PM To: IETF Discussion Mailing List Subject: re: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard ... - The "diagnostic notation" can be used very effectively for things like configuration files, e.g. if an application already uses CBOR on the wire. Therefore I would suggest to formalize it a bit more, so that we also have interoperability at this level. Do you envision it as an encoding for Netconf? Randy
Re: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Wed, Aug 14, 2013 at 6:07 AM, Carsten Bormann wrote: > On Aug 14, 2013, at 13:40, Randy Bush wrote: > >>> YANG seems to be incompatible with CBOR. >> >> so what does that say about yang, yang's suitability for netconf, cbor, >> and cbor's suitability? > > Good question. I'm not sure the jury is even out on that yet. > > Yaron reminded me that netconf is using XPath for various purposes, so a CBOR > rendition of netconf would need to do the same that you would need for doing > netconf with JSON: either replace XPath with something else (indeed causing > some incompatibility), or explain how to use XPath with the CBOR/JSON > translation of the YANG model (which might be interesting). > > CBOR certainly has no trouble carrying around the data described by a YANG > model. > (Indeed, CBOR's decimal fractions were inspired by YANG's.) > But then, I don't have an opinion whether adding a binary object > representation to the netconf ecosystem is on the agenda. > I am not sure this is an actual problem. NETCONF uses full XPath only if the :xpath capability is supported. The "select" expression represents the data to be returned from the conceptual datastore and possibly the state/statistics within the device. The select expression is not related to the message on the wire. There is also an "error-path" field that is returned in errors that contains the absolute path of the message or data node that caused the error. Neither of these message fields should cause an encoding problem. They are just strings at the message layer. > Grüße, Carsten > Andy
Call for Review of draft-rfced-rfcxx00-retired, "List of Internet Official Protocol Standards: Replaced by an Online Database"
This is a call for review of "List of Internet Official Protocol Standards: Replaced by an Online Database" prior to potential approval as an IAB stream RFC. The document is available for inspection here: https://datatracker.ietf.org/doc/draft-rfced-rfcxx00-retired/ The Call for Review will last until 11 September 2013. Please send comments to i...@iab.org. On behalf of the IAB, Russ Housley IAB Chair
Re: Last Call: (URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard
On 08/13/2013 12:14 AM, Graham Klyne wrote: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-08-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document is the specification of the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-nandakumar-rtcweb-stun-uri/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-nandakumar-rtcweb-stun-uri/ballot/ No IPR declarations have been submitted directly on this I-D. As IANA designated expert for reviewing URI scheme registrations, I've been asked to approve this scheme for registration. If there is IETF consensus to publish this document, it is clear to me that the scheme should be registered. But, in a personal capacity, not as designated reviewer, I have to ask *why* this needs to be a URI. As far as I can tell, it is intended for use only in very constrained environments, where there seems to be little value in having an identifier that can appear in all the contexts where a URI may be recognized. The criteria for new URI schemes in http://tools.ietf.org/html/rfc4395 include: "New URI schemes SHOULD have clear utility to the broad Internet community, beyond that available with already registered URI schemes." -- http://tools.ietf.org/html/rfc4395#section-2.1 This "utility to the broader community" is not clear to me, but I don't fully understand the intended scope of this protocol, so I could be missing something. So, in declaring consensus for this specification, I would request that this aspect at least be considered. I can only give my personal opinion 1) This is a format for a piece of data. This data cannot be expressed using any existing URI scheme - indeed, I don't think there exists another well-defined textual representation of this piece of data. 1) This is defining an identifier that will be used in W3C-defined APIs. W3C tends to use URIs every time they want a self-defining piece of data with a clearly defined structure. In the particular API where this is wanted, one wants to have STUN URIs, TURNS URIs and TURN URIs passed over the same interface. Thus, keeping with the W3C tradition of URIs seems reasonable. I think this answers the question about "utility to the broader community" to my satisfaction - your mileage may differ, of course. ... Further, according to http://tools.ietf.org/html/rfc5389 it appears that there are security considerations with regard to the STUN protocol that it should not be used in isolation: [[ Classic STUN also had a security vulnerability -- attackers could provide the client with incorrect mapped addresses under certain topologies and constraints, and this was fundamentally not solvable through any cryptographic means. Though this problem remains with this specification, those attacks are now mitigated through the use of more complete solutions that make use of STUN. For these reasons, this specification obsoletes RFC 3489, and instead describes STUN as a tool that is utilized as part of a complete NAT traversal solution. ]] -- http://tools.ietf.org/html/rfc5389#section-2 It seems to me that creating a URI for STUN could encourage its use in environments outside the "more complete solutions that make use of STUN". This seems to be further reason that STUN[S] should not be a URI scheme. I have also suggested that, if registered, the URI scheme registration should carries a "health warning" to this effect, and that it is not suitable for general use that is not part of a "complete NAT traversal solution". But I also recognize that I do not fully grasp the security implications, and that if those that do know better can agree that there is no potential for creating security risks here, this suggestion may be unnecessary. This URI scheme does not represent STUN. It represents configuration data that is used to initialize a protocol machine that utilizes STUN. This configuration data has to be passed no matter what the format of the data is - whether it be URI or not. Thus, I do not think the argument raised is really relevant to the context. The data will be passed, and registering an URI scheme will cause no more and n
Re: Last Call: (URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard
On 08/13/2013 09:03 PM, S Moonesamy wrote: At 15:14 12-08-2013, Graham Klyne wrote: But, in a personal capacity, not as designated reviewer, I have to ask *why* this needs to be a URI. As far as I can tell, it is intended for use only in very constrained environments, where there seems to be little value in having an identifier that can appear in all the contexts where a URI may be recognized. This is an individual comment. I reviewed draft-petithuguenin-behave-turn-uris-05. I wondered why a URI was needed given the limited use. The same argument is applicable for draft-nandakumar-rtcweb-stun-uri-05. There is running code for both drafts. Both draft qualify for "DNP". I would describe the proposals as trying to fit the solution within a URI instead of designing a URI scheme. Both proposals sound like UNSAF. FWIW, UNSAF = Unilateral Self Address Fixing, or "figuring out what my address is on the Internet", and is exactly what STUN is useful for. In a world of NATs, UNSAF is, unfortunately, a necessary thing to do. These URI schemes allow us to pass configuration data for performing these operations in a standardized form.
Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08
David, as we mentioned in the IESG thread, we seem to have dropped the response to your comments about IANA actions. WG: >From the genart review: [9] I suggest Expert Review for the new IANA registries, not just First Come First Served, so that someone with a security "clue" can check that the proposed registrations are reasonable. Stephen has filed a related DISCUSS position. He's confused why we need a registry for KDFs or algorithms. He argues that the protocols should already have such a registry. He argues that it would be non-sensical to register a value in this registry but not the protocol registry. In a somewhat related discussion, multiple people have asked what the scope of this document is. Are we defining something for routing protocols? Any security protocol in the world? Something in-between? IU'm going to make two responses: 1) I think FCFS is not harmful for these registries. David's main concern is that bad security will get registered. I'll point out that these registries are not about what security you can use with a routing protocol, but about what security you can configure from a management standpoint. Registering rot13 or similarly questionable security here wouldn't mean I could use it with a routing protocol, only that I could ask a system to do so. If ROT13 was not actually in the security-specific registries for the protocols in question there'd be no way to send a rot13-transformed message. I think people wanting to use bad security in routing protocols will focus on specifying how to use the security for the protocols, and that's the appropriate place to do any gateway review. Yeah, I guess with FCFS it's possible someone could register here and then later realize they cannot get their md4 security approved in the actual protocol registry document. That might be confusing but doesn't seem very harmful. Also, some routing protocols are protected by cleartext passwords sent over the network. We want to be able to manage that, so we will be registering plaintext password in these registries. I don't think anyone will come up with anything worse than that. Finally, I think a lot of us have begun to question the value in security review for codepoint assignment. Some security WGs care a lot; some don't seem to care much at all. 2) Why I prefer FCFS or at least would object strongly to expert review. If we're going to say we want expert review I want us to give expert instructions at least good enough that I believe I could answer the question of what registrations to approve if I were appointed the expert. I don't think we could come to consensus on those instructions very easily. In particular, I think it would be challenging for us to describe what security protocols the protocol registry applies to and which ones it does not. I'm totally fine publishing this document knowing it will be used for routing protocols but not knowing what beyond routing protocols it will be used for. If we do that FCFS makes a lot of sense. So, my recommendation is that we keep our current registration policy.
Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08
> "Black," == Black, David writes: Black,> [A] Overall - I would like to see a paragraph added on how Black,> this database conceptually relates to the IPsec Peer Black,> Authorization Database (PAD) - see RFC 4301, section 4.4.3. It doesn't. not even a little bit. It's not IPsec; it's not about what key management peers to interact with. It's conceptually similar to the Security Association Database (SAD). In a discussion with Jari I agreed to propose text for a paragraph describing how this interacts with IPsec. If this conceptual database is used to manage to keys for a security protocol that uses IPsec [RFC4301] security services, then the interactions between this conceptual database and the IPsec databases needs to be described by the protocol specification. Typically such a protocol would insert entries into the Security Association Database (SAD) when rows are inserted into the key table and remove SAD entries when key table rows are removed. The protocol specification needs to describe how the SAD entries are constructed along with any other IPsec database entries that are needed, including a description of how these entries are ordered along with other IPsec database entries. The question of whether it is desirable to use this conceptual database to manage protocols that use IPsec security services is open and has not been evaluated. Black,> [C] (Section 3) Where does key selection occur? I would Black,> suggest that the database return all possible keys and let Black,> the protocol figure out what to use. This is particularly Black,> important for inbound traffic for obvious reasons. I think we've discussed key selection in the WG and come to a different conclusion. The key table selects the key. We expect peer, key ID, protocol and interface to identify a unique key for an inbound packet. So, I think the concern you raise is not a problem. While there was not a specific thread discussing key selection or this issue, there were multiple reviewers who provided comments on key selection over the development of the document, and making a major change at this point without a technical problem seems undesirable. If I'm missing something and the inbound packet issue is a problem then we need to discuss it.
Re: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Wed, Aug 14, 2013 at 4:23 PM, Dave Crocker wrote: > On 8/13/2013 3:20 PM, Joe Hildebrand wrote: > >> One of the reasons why I like the CBOR tag applied to a byte stream is >> that >> it can be used to skip parsing on entire sections (no matter their >> underlying types) in processors that don't need to understand that >> section. >> > > > This is an example of the core reason that having a "one true standard" is > not appropriate for many topics: design choices optimize along particular > axes, giving particular optimizations, typically at the expense of others. > Different operating context benefit from different optimizations. > > It makes sense for a specification to document its tradeoffs; it often > does not make sense to choose only one such specification for use in all > scenarios. Maybe, but should the standards process at least uncover what the potential design axes might be? I think that we could actually dispense with design options for application protocols entirely Remember that standards are all about making design choices that don't matter. It does not matter how the bits are encoded on the wire, all that actually matters is the complexity of decoding them. And CBOR is not a good encoding by that measure. It has a lot of options and is designed to offer even more. CBOR is retrograde to MessagePack, a step backwards. 90% of Application protocols are simple API function calls. The other 10% are API function callbacks. Thats it. We have a complete set of intrinsic types that are recognized by modern programming languages. There are some programming languages that don't recognize all the intrinsic types of C/C#/Java but at this point the intrinsic types that are not supported those languages are pretty few and tending to decrease rather than increase over time. The approach I took in JSON-BCD was to start with the assumption that the JSON data model was sufficiently complete to be considered definitive (after adding binary arrays) and then propose three extensions to the JSON encoding model to provide what I believe to be 100% coverage of all reasonable use cases. It is possible that I did not succeed but there are two ways that I might have slipped up. Dave does not distinguish between these. 1) An application might need a richer data model than JSON affords. 2) An application might need a more efficient bit packing than JSON-BCD provides or a canonical encoding. I can't address the first since the starting point for my design is to not change the JSON data model. If someone did find JSON insufficient then they should probably be looking at XML or ASN.1 anyway. The second is easy enough to address, just add another encoding like I did. -- Website: http://hallambaker.com/
Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-04
On Aug 13, 2013, at 13:14, Tony Finch wrote: > MessagePack is simpler so will need even less code FWIW, earlier today I had a nice afternoon with the msgpack-ruby C code, converting it to encoding and decoding CBOR instead. Saved ~ 250 lines of C code. Of course, I'm filling in that gap now by implementing some of the optional tags of CBOR. In the end, the implementation of a generic CBOR encoder/decoder with a sizable collection of optional tags will probably indeed be slightly larger. But if you just need the features of MessagePack, I now have one data point where CBOR measurably wins on the implementation complexity metric. Grüße, Carsten
