[DNSOP] dnsop - Requested sessions have been scheduled for IETF 99
Dear Tim Wicinski, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dnsop Session 1 (2:00:00) Tuesday, Afternoon Session II 1550-1750 Room Name: Congress Hall II size: 350 - dnsop Session 2 (1:00:00) Thursday, Afternoon Session III 1810-1910 Room Name: Grand Hilton Ballroom size: 250 - Request Information: - Working Group Name: Domain Name System Operations Area Name: Operations and Management Area Session Requester: Tim Wicinski Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 160 Conflicts to Avoid: First Priority: dprive dnssd homenet appsawg apparea dhc Second Priority: v6ops intarea trans Third Priority: 6man grow opsarea opsawg pcp saag sidr People who must be present: Suzanne Woolf Joel Jaeggli Warren Kumari Tim Wicinski Resources Requested: Special Requests: If either session is slotted for Friday, please make it the second 1 hour session. thanks - ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)
The errata is correct. Ólafur sent from phone On Jun 23, 2017 11:54, "RFC Errata System" wrote: > The following errata report has been submitted for RFC8078, > "Managing DS Records from the Parent via CDS/CDNSKEY". > > -- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5049 > > -- > Type: Technical > Reported by: Ondřej Caletka > > Section: 4 > > Original Text > - >The contents of the CDS or CDNSKEY RRset MUST contain one RR and only >contain the exact fields as shown below. > > CDS 0 0 0 0 > > CDNSKEY 0 3 0 0 > >The keying material payload is represented by a single 0. This >record is signed in the same way as regular CDS/CDNSKEY RRsets are >signed. > >Strictly speaking, the CDS record could be "CDS X 0 X 0" as only the >DNSKEY algorithm is what signals the DELETE operation, but for >clarity, the "0 0 0 0" notation is mandated -- this is not a >definition of DS digest algorithm 0. The same argument applies to >"CDNSKEY 0 3 0 0"; the value 3 in the second field is mandated by >[RFC4034], Section 2.1.2. > > > Corrected Text > -- >The contents of the CDS or CDNSKEY RRset MUST contain one RR and only >contain the exact fields as shown below. > > CDS 0 0 0 00 > > CDNSKEY 0 3 0 AA== > >The keying material payload is represented by a single octet with >the value 00. This record is signed in the same way as regular >CDS/CDNSKEY RRsets are signed. > >Strictly speaking, the CDS record could be "CDS X 0 X 00" as only the >DNSKEY algorithm is what signals the DELETE operation, but for >clarity, the "0 0 0 00" notation is mandated -- this is not a >definition of DS digest algorithm 0. The same argument applies to >"CDNSKEY 0 3 0 AA=="; the value 3 in the second field is mandated by >[RFC4034], Section 2.1.2. > > Notes > - > RFC 7344 defines both CDS and CDNSKEY record wire and presentation format > to be identical to DS and DNSKEY wire and presentation format defined in > RFC 4034. > > In case of CDNSKEY record, RFC 4034 section 2.2 requires that: > > The Public Key field MUST be represented as a Base64 encoding of the > Public Key. > > As Base64 encoding encodes 6 bits into one character, one character alone > can never be a valid Base64 sequence. The proper encoding of one-byte long > sequence with binary value of 00 is AA==. > > In case of CDS record, RFC 4034 section 5.3 requires that: > > The Digest MUST be represented as a sequence of case-insensitive > hexadecimal digits > > Although the value of a single 0 fulfils this requirement per se, it's not > properly parsable by many implementations since it is expected to be even > number of hex digits to align with octet boundaries in the wire format. So > proper form of CDS record should contain two zeroes in place of the digest. > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC8078 (draft-ietf-dnsop-maintain-ds-06) > -- > Title : Managing DS Records from the Parent via CDS/CDNSKEY > Publication Date: March 2017 > Author(s) : O. Gudmundsson, P. Wouters > Category: PROPOSED STANDARD > Source : Domain Name System Operations > Area: Operations and Management > Stream : IETF > Verifying Party : IESG > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [Technical Errata Reported] RFC8078 (5049)
The following errata report has been submitted for RFC8078, "Managing DS Records from the Parent via CDS/CDNSKEY". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5049 -- Type: Technical Reported by: Ondřej Caletka Section: 4 Original Text - The contents of the CDS or CDNSKEY RRset MUST contain one RR and only contain the exact fields as shown below. CDS 0 0 0 0 CDNSKEY 0 3 0 0 The keying material payload is represented by a single 0. This record is signed in the same way as regular CDS/CDNSKEY RRsets are signed. Strictly speaking, the CDS record could be "CDS X 0 X 0" as only the DNSKEY algorithm is what signals the DELETE operation, but for clarity, the "0 0 0 0" notation is mandated -- this is not a definition of DS digest algorithm 0. The same argument applies to "CDNSKEY 0 3 0 0"; the value 3 in the second field is mandated by [RFC4034], Section 2.1.2. Corrected Text -- The contents of the CDS or CDNSKEY RRset MUST contain one RR and only contain the exact fields as shown below. CDS 0 0 0 00 CDNSKEY 0 3 0 AA== The keying material payload is represented by a single octet with the value 00. This record is signed in the same way as regular CDS/CDNSKEY RRsets are signed. Strictly speaking, the CDS record could be "CDS X 0 X 00" as only the DNSKEY algorithm is what signals the DELETE operation, but for clarity, the "0 0 0 00" notation is mandated -- this is not a definition of DS digest algorithm 0. The same argument applies to "CDNSKEY 0 3 0 AA=="; the value 3 in the second field is mandated by [RFC4034], Section 2.1.2. Notes - RFC 7344 defines both CDS and CDNSKEY record wire and presentation format to be identical to DS and DNSKEY wire and presentation format defined in RFC 4034. In case of CDNSKEY record, RFC 4034 section 2.2 requires that: > The Public Key field MUST be represented as a Base64 encoding of the Public > Key. As Base64 encoding encodes 6 bits into one character, one character alone can never be a valid Base64 sequence. The proper encoding of one-byte long sequence with binary value of 00 is AA==. In case of CDS record, RFC 4034 section 5.3 requires that: > The Digest MUST be represented as a sequence of case-insensitive hexadecimal > digits Although the value of a single 0 fulfils this requirement per se, it's not properly parsable by many implementations since it is expected to be even number of hex digits to align with octet boundaries in the wire format. So proper form of CDS record should contain two zeroes in place of the digest. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC8078 (draft-ietf-dnsop-maintain-ds-06) -- Title : Managing DS Records from the Parent via CDS/CDNSKEY Publication Date: March 2017 Author(s) : O. Gudmundsson, P. Wouters Category: PROPOSED STANDARD Source : Domain Name System Operations Area: Operations and Management Stream : IETF Verifying Party : IESG ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-03.txt
hello, Based on Seoul IETF's discussion, I refine the introduction of this document to explain the motivation and compare with other mechanisms. the key text is here: - 1. Introduction Sometimes, when DNS lookup of X, an application will lookup Y if X fails. For examples, the initiator may fall back to A record if the lookup of MX record fails. Some initiators do it in sequence, X and after a few seconds, then Y. Although it is simple, this leads to unpleasant waiting whenever X times out or answers negatively. Some initiators use concurrent X/Y lookups and a state machine to decide whether to use X or Y. If an answer to Y arrives but none to X, the initiator needs to wait a little or else fall back to Y inappropriately. Concurrent lookup is faster if the X lookup takes time and falling back to Y is appropriate, but rather complex, with four states to test, and the initiator needs to wait for an answer to X or a timeout before it can use Y. This document enables a quicker, more easily tested failover. There is no need to test different answer sequences, there's no need for a state machine, there's no need for timeouts beyond receiving the reply. This document describes a method by which DNS initiators can send a main question accompanying with several related questions in a single DNS query, and enables DNS responders place all related answers into a single DNS response. This mechanism can reduce the number of DNS round-trips per application work-unit, by carrying several related queries in a single query transaction. It has the following advantages compared to other solutions. o Compared to sequential lookups: It's roughly as simple, but much faster in case a fallback to Y is necessary. o Compared to the concurrent mechanism: It is slightly faster (if the initiator needs to wait for an X timeout) and/or prevents inappropriate fallback (if the answer to X arrives too late), and it has a simpler state machine. This mechanism can also be used in the scenarios when the application needs more records of the same domain name or its sub-domain name. For examples, when asking about a QTYPE=A RRset, a QTYPE= RRset may also be of use [RFC 5321]; When asking for some RRset of www.example.com about A and , records of a sub-domain name such as _443._tcp.www.example.com for TLSA may be of interest[RFC 6698]. Jiankang Yao From: internet-drafts Date: 2017-06-23 15:41 To: XiaoDong Lee; Ning Kong; Paul Vixie; Jiankang Yao; Xiaodong Li Subject: New Version Notification for draft-yao-dnsop-accompanying-questions-03.txt A new version of I-D, draft-yao-dnsop-accompanying-questions-03.txt has been successfully submitted by Jiankang Yao and posted to the IETF repository. Name: draft-yao-dnsop-accompanying-questions Revision: 03 Title: A DNS Query including A Main Question with Accompanying Questions Document date: 2017-06-23 Group: dnsop Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-yao-dnsop-accompanying-questions-03.txt Status: https://datatracker.ietf.org/doc/draft-yao-dnsop-accompanying-questions/ Htmlized: https://tools.ietf.org/html/draft-yao-dnsop-accompanying-questions-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-yao-dnsop-accompanying-questions-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-yao-dnsop-accompanying-questions-03 Abstract: This document enables DNS initiators to send a main question accompanying with several related questions in a single DNS query, and enables DNS responders to put the answers into a single DNS response. This extension enables a range of initiators to look up "X, or failing that, Y" in a better way than both current alternatives. This mechanism can reduce the number of DNS round- trips per application work-unit. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-yao-dnsop-accompanying-questions-03.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : A DNS Query including A Main Question with Accompanying Questions Authors : Jiankang Yao Paul Vixie Ning Kong Xiaodong Li Filename: draft-yao-dnsop-accompanying-questions-03.txt Pages : 11 Date: 2017-06-23 Abstract: This document enables DNS initiators to send a main question accompanying with several related questions in a single DNS query, and enables DNS responders to put the answers into a single DNS response. This extension enables a range of initiators to look up "X, or failing that, Y" in a better way than both current alternatives. This mechanism can reduce the number of DNS round- trips per application work-unit. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-yao-dnsop-accompanying-questions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-yao-dnsop-accompanying-questions-03 https://datatracker.ietf.org/doc/html/draft-yao-dnsop-accompanying-questions-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-yao-dnsop-accompanying-questions-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
