> 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
country infrastru
> 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
>> declaring a core
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 ass
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 reflect
>> it here)
>>
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.
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
deprecating-obsolete-rr-typ
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 then
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
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 Intern
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 and
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 d
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
> the same time tend
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, Ondřej Surý wrote:
>>
>>
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 tha
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 ar
> 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
> doing PMTUD, or i
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 upd
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 a
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
>
>
> 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:
>>
>> o
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 new document that re
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 bac
Matthew Pounsett wrote:
On 27 March 2018 at 17:33, Paul Vixie mailto:p...@redbarn.org>> 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 diff
>
> 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.
>
24 matches
Mail list logo
