Re: [DNSOP] dnssec-kskroll-sentinel-06 clarifications

> > I was VERY surprised to see the opposite text sneak its way into > a pull request, and equally surprised that a co-author of the draft > approved the request and pushed the -09 version without raising this > on the mailing list, particularly as it directly contradicts your > message here.

Re: [DNSOP] Current DNS standards, drafts & charter

Matthew Pounsett wrote: On 27 March 2018 at 17:33, Paul Vixie > wrote: i see no purpose in change documents, which would add to the set of things a new implementer would have to know to read, and then to read. I think we're discussing the

[DNSOP] further problems with draft-ietf-dnsop-kskroll-sentinel-09

While I am reviewing this version of the draft, the other problem I see is a block of text that reads: "RFC 8145 relies on resolvers reporting the list of keys that they have to root servers.” The grammatical construction is ambiguous - I suspect that whoever originally submitted this tect

Re: [DNSOP] Current DNS standards, drafts & charter

On 27 March 2018 at 17:33, Paul Vixie wrote: > i see no purpose in change documents, which would add to the set of things > a new implementer would have to know to read, and then to read. I think we're discussing the same idea from different perspectives. I think writing a

Re: [DNSOP] dnssec-kskroll-sentinel-06 clarifications

> > > 3rd proposal > > We have one more thing which needs more manpower to be verified. Right > now, the section 3.1. Preconditions is: > >> 3.1. Preconditions >> >> All of the following conditions must be met to trigger special >> processing inside resolver code: >> >>

Re: [DNSOP] Current DNS standards, drafts & charter

i see no purpose in change documents, which would add to the set of things a new implementer would have to know to read, and then to read. rather, we should focus on a DNSOP document set that specifies a minimum subset of DNS which is considered by the operational community to be mandatory to

Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC

On 03/27/18 10:22, Paul Hoffman wrote: > On 27 Mar 2018, at 10:21, Michael Sinatra wrote: > >> My goal is to basically avoid confusion and just tell people to use the >> strongest algorithm they can reasonably use.  I.e. follow the CNSA >> recommendations and don't spend a lot of time thinking

Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC

On 27 Mar 2018, at 10:21, Michael Sinatra wrote: My goal is to basically avoid confusion and just tell people to use the strongest algorithm they can reasonably use. I.e. follow the CNSA recommendations and don't spend a lot of time thinking about the application. The CNSA will likely be

Re: [DNSOP] avoiding fragmented DNS-over-UDP

> On 21 Mar 2018, at 16:10, Tony Finch wrote: > > Here are some sketchy notes on what this might say... > > * client side > >* implement PMTUD by probing with diferent EDNS buffer sizes > > * does it make sense for a server to try to work out if the client is >

Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC

On 03/27/18 05:43, Paul Hoffman wrote: > On 26 Mar 2018, at 17:30, Michael Sinatra wrote: > >> I am a bit uncomfortable with the document's disrecommendation of SHA384 >> and ECDSAP384SHA384.  The main reason for this is that for crypto >> recommendations here in the USG, > > Note that those

Re: [DNSOP] Current DNS standards, drafts & charter

On 27 Mar 2018, at 9:02, Andrew Sullivan wrote: On Mon, Mar 26, 2018 at 05:46:45PM +0200, bert hubert wrote: So my first suggested action is: could we write a document that has a core introduction of DNS and then provides a recommended (not) reading list. Maybe we could, but we failed at

Re: [DNSOP] Current DNS standards, drafts & charter

Definitely. I didn’t mean to rewrite 1:1, but take existing content and do m:n including splitting and combining existing RFCs into new document(s). Ondřej -- Ondřej Surý — ISC > On 27 Mar 2018, at 18:19, Matthew Pounsett wrote: > > > >> On 27 March 2018 at 03:49,

Re: [DNSOP] Current DNS standards, drafts & charter

On 27 March 2018 at 03:49, Ondřej Surý wrote: > > Again, from experience from dnsext, I would strongly suggest that any work > in this area is split into CHANGE documents and REWRITE documents, with > strict scope. Documents rewriting existing RFCs while adding more stuff at >

Re: [DNSOP] Current DNS standards, drafts & charter

Hi, On Mon, Mar 26, 2018 at 05:46:45PM +0200, bert hubert wrote: > So my first suggested action is: could we write a document that has a core > introduction of DNS and then provides a recommended (not) reading list. Maybe we could, but we failed at that once before. After the DNSSEC work wound

Re: [DNSOP] Current DNS standards, drafts & charter

Paul Wouters wrote: On Mon, 26 Mar 2018, Paul Vixie wrote: what i'd like is something more. KEY, SIG and NXT had multiple interoperable implementations, but were not actually functional in any end-to-end way, and were thus replaced by RRSIG, DNSKEY, DS, and NSEC. later we moved the target

Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

On 3/26/2018 8:18 AM, Martin Hoffmann wrote: Which also reminds me: The DANE RRtypes, ie., TLSA, SMIMEA, and OPENPGPKEY all use underscore labels and are currently missing from the initial table in section 3.1. Added TLSA to the next version of the draft. d/ -- Dave Crocker Brandenburg

Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC

On 26 Mar 2018, at 17:30, Michael Sinatra wrote: I am a bit uncomfortable with the document's disrecommendation of SHA384 and ECDSAP384SHA384. The main reason for this is that for crypto recommendations here in the USG, Note that those are for encryption, where they want to keep some things

Re: [DNSOP] Current DNS standards, drafts & charter

On Mon, 26 Mar 2018, Paul Vixie wrote: what i'd like is something more. KEY, SIG and NXT had multiple interoperable implementations, but were not actually functional in any end-to-end way, and were thus replaced by RRSIG, DNSKEY, DS, and NSEC. later we moved the target and added NSEC3 and

Re: [DNSOP] Current DNS standards, drafts & charter

On Tue, 27 Mar 2018, Ondřej Surý wrote: I strongly believe that any work on cleaning up DNS protocol and/or rewriting RFC1034/RFC1035 and associated document would need a new WG with tightly defined charter. Hence, I will not request or I won’t support adopting my

Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

On 26/03/2018 20:49, John R. Levine wrote: > Assuming we agree that the table also says where to find the registry > for second level names, this removes and need for special cases.  The > top level names _tcp _udp _sctp _dccp all work for SRV and URI and take > service names on the second level.

Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC

Hi Michael, > On 27 Mar 2018, at 02:30, Michael Sinatra wrote: > > > > On 03/22/18 08:08, Ondřej Surý wrote: > >> * Separate operational recommendations for default algorithm to >> ECDSAP256SHA256 >> * Deprecation of ECC-GOST (that actually happened elsewhere, so we

Re: [DNSOP] Current DNS standards, drafts & charter

Hi Suzanne, > If the WG feels that the previous view of how DNSOP should work has been > overtaken by events, we can certainly work with our Area Director (hi > Warren!) on a revised charter. I strongly believe that any work on cleaning up DNS protocol and/or rewriting RFC1034/RFC1035 and

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

> On 27 Mar 2018, at 03:36, Dick Franks wrote: > >> please see down-thread where deprecation turns out to be both undesirable >> for the reasons i've given, and additive to developmental complexity since >> there would be _more_ DNS RFC's to read, and suboptimal compared to

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

> On 26 Mar 2018, at 23:36, Paul Vixie wrote: > > i've had my symbolics 3640 online quite a bit in the last 30 years, This is certainly a fair piece of computer archaelogy, But it is similar to the situation if a museum would insist on providing narrow-wide tracks across the