Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)
On 25 June 2017 at 20:54, Paul Hoffman wrote: > On 24 Jun 2017, at 6:25, Dick Franks wrote: > > > In each case, > > > > CDS 0 0 0 0 > > > > CDNSKEY 0 3 0 0 > > > > the final "0" is a conventional token representing a zero-length key > field. > > Dick, can you give examples of that conventional token use? > This example is as good as any. conventional: established by custom or agreement token: a mark, sign or distinctive feature. [Chambers 21st Century Dictionary] The token (final zero) is not in this case a self-defining term, but is given meaning, or in this case lack of meaning, by the formal agreement (RFC8078) that a zero algorithm field will completely define a DELETE CDS/CDNSKEY RR. --Dick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)
On 24 Jun 2017, at 6:25, Dick Franks wrote: > In each case, > > CDS 0 0 0 0 > > CDNSKEY 0 3 0 0 > > the final "0" is a conventional token representing a zero-length key field. Dick, can you give examples of that conventional token use? --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)
On 24 June 2017 at 16:45, Ondřej Caletka wrote: >8 The result that made it to the RFC is that there should be indeed one > byte with value of 00 in the Digest/Public key field instead of no data > at all. That does not appear to be the position at all. RFC8078 mandates a specific presentation format notation for the entire RDATA string whenever algorithm is zero, and irrespective of actual values in other fields. The RFC is conspicuously silent about the equivalent wire-format representation. This avoids the need of defining new format and updating all the > deployed software. It's not only about parsers of the wire format but > also about zone file parsers, that would need an update as the single > zero is not conformant with currently defined presentation format of > CDS/CDNSKEY RRs. > It is clear from the text of draft-ietf-dnsop-maintain-ds-04 that the notion of mandated presentation format notation was already present. Moreover, that version also carried the warning: This is a change in format from strict interpretation of [RFC7344] and may cause problems with some deployed software. Your primary argument was therefore a non-starter even before the appearance of the unparseable single zero. I believe changing RRdata format just for this one purpose would add an > unnecessary complexity. > > That train has already left the station. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
