Ondřej Surý wrote:
...
But it’s funny that we should not remove a record while this was
already written in 1989:
An application SHOULD NOT rely on the ability to locate a WKS
record containing an accurate listing of all services at a
particular host address, since the
On 26 March 2018 at 14:39, Tony Finch wrote:
> Evan Hunt wrote:
> >
> > These RR types have text representations and wire format representations,
> > which from a complexity standpoint seem quite harmless to implement.
> There
> > are the old annoying rules about
> On 26 Mar 2018, at 15:39, Tony Finch wrote:
>
> Evan Hunt wrote:
>>
>> These RR types have text representations and wire format representations,
>> which from a complexity standpoint seem quite harmless to implement. There
>> are the old annoying rules about
Evan Hunt wrote:
>
> These RR types have text representations and wire format representations,
> which from a complexity standpoint seem quite harmless to implement. There
> are the old annoying rules about name compression and sorting, which do add
> some complexity, but are
All,
Matthijs Mekking:
>
>
> On 24-03-18 14:48, Joe Abley wrote:
>> On Mar 24, 2018, at 13:49, Jared Mauch wrote:
>>
>>> isc/bind can and perhaps should implement logging for these
>>> rrtypes that say they may be going away so folks can see the impact.
>>
>> I'm
Matthijs Mekking wrote:
On 24-03-18 14:48, Joe Abley wrote:
On Mar 24, 2018, at 13:49, Jared Mauch wrote:
isc/bind can and perhaps should implement logging for these
rrtypes that say they may be going away so folks can see the impact.
I'm actually surprised to
On 24-03-18 14:48, Joe Abley wrote:
On Mar 24, 2018, at 13:49, Jared Mauch wrote:
isc/bind can and perhaps should implement logging for these
rrtypes that say they may be going away so folks can see the impact.
I'm actually surprised to see that support for
On Sun, 25 Mar 2018, Evan Hunt wrote:
I think it would help if there were more clarity on what exactly is being
proposed, other than adding the words "obsolete" or "deprecated" to a list
of RRtypes on a website somewhere. The draft didn't seem to have
particularly clear guidance to
On Sat, Mar 24, 2018 at 06:48:35AM -0700, Joe Abley wrote:
> I'm actually surprised to see that support for rarely-used RRTypes is
> really upsetting the camel.
It's an interesting object lesson in the complexity of unloading camels,
though. (Perhaps it's time to add something about "the eye of
On 24 March 2018 at 09:48, Joe Abley wrote:
> But I think brushing the grains RRType parsing dust off the
> camel is not going to do much for its posture.
>
> +1
Speaking from experience, having spent a few dozen hours so far on some
client code, the code necessary to
On Sat, Mar 24, 2018 at 02:58:55PM +, Jim Reid wrote:
> IMO there's no need to do this in the protocol unless there is convincing
> proof that nobody anywhere is using a now-obsolete RRtype. An RFC saying
> a server could return FORMERR (or whatever) when it gets a query for one
> of these
Joe,
it’s actually not the complexity in BIND (although I view everything as extra
complexity), it’s the interop for new players that need to implement every
piece of rusty junk that's in the protocol to be interoperable.
While it seems to be attractive to keep the existing open-source
On Mar 24, 2018, at 13:49, Jared Mauch wrote:
>isc/bind can and perhaps should implement logging for these
> rrtypes that say they may be going away so folks can see the impact.
I'm actually surprised to see that support for rarely-used RRTypes is
really upsetting the
On Fri, Mar 23, 2018 at 06:32:07PM +, Ondřej Surý wrote:
> What’s so wrong of using TYPExxx for these if you absolutely need them to run
> the ancient technology while at the same time running the latest version of
> BIND (or your favorite DNS server)?
>
> Your argument feels like strawman
On 23 March 2018 at 12:11, Ondřej Surý wrote:
>
> this is a first attempt to start reducing the load on DNS Implementors and
> actually remove the stuff from DNS that’s not used and not needed anymore.
>
I have no quarrel with the overall effect of this proposal, but the
Did you hear the part about doing it the way we did when deprecation iquery?
There's a discovery and decision process that involves the broader community.
Technical merit was provided. Sad that I can't think of a way to do it more
clearly.
On March 23, 2018 7:18:25 PM UTC, "Ondřej Surý"
The configurations change all the time, I am sorry, but your argument doesn’t
have a technical merit.
We really do need to start removing obsolete stuff from DNS, and I believe this
is a good start.
Ondřej
--
Ondřej Surý — ISC
> On 23 Mar 2018, at 18:39, Paul Vixie wrote:
Ondřej Surý wrote:
What’s so wrong of using TYPExxx for these if you absolutely need
them to run the ancient technology while at the same time running the
latest version of BIND (or your favorite DNS server)?
because i am loathe to break existing working configurations. when isc
changed the
What’s so wrong of using TYPExxx for these if you absolutely need them to run
the ancient technology while at the same time running the latest version of
BIND (or your favorite DNS server)?
Your argument feels like strawman to me. And I am not the one sitting on a pile
of passive DNS data, so
Ondřej Surý wrote:
I strongly disagree. The DNS protocol deserve cleanup. Deprecating
RRTYPEs doesn’t mean the will stop working on the day the RFC is
published, neither are people going to backport the removal of
RRTYPEs to existing DNS software releases.
It just means - whatever ancient
I strongly disagree. The DNS protocol deserve cleanup. Deprecating RRTYPEs
doesn’t mean the will stop working on the day the RFC is published, neither are
people going to backport the removal of RRTYPEs to existing DNS software
releases.
It just means - whatever ancient stuff you are using -
On Fri, Mar 23, 2018 at 1:03 PM, Ondřej Surý wrote:
> Thanks, now I understand what you are asking for;), so what about:
>
> “No existing Internet Standard uses these Resource Records and there no
> know practical usage in the public Internet.”
>
> Ondřej
> --
> Ondřej Surý — ISC
Thanks, now I understand what you are asking for;), so what about:
“No existing Internet Standard uses these Resource Records and there no know
practical usage in the public Internet.”
Ondřej
--
Ondřej Surý — ISC
> On 23 Mar 2018, at 16:51, Bob Harold wrote:
>
>
>> On
On Fri, Mar 23, 2018 at 12:05 PM, Ondřej Surý wrote:
> No, I don’t mean that. While in theory you can call an aquarium with dead
> fish and algae “in use” and tell your neighbors that you have fish and have
> a green thumb, it wouldn’t be necessarily an accurate assessment of the
No, I don’t mean that. While in theory you can call an aquarium with dead fish
and algae “in use” and tell your neighbors that you have fish and have a green
thumb, it wouldn’t be necessarily an accurate assessment of the situation.
Similarly, an occasional user that tries things doesn’t make
On Fri, Mar 23, 2018 at 8:11 AM, Ondřej Surý wrote:
> Heya,
>
> this is a first attempt to start reducing the load on DNS Implementors and
> actually remove the stuff from DNS that’s not used and not needed anymore.
>
> There’s github for the draft:
On Fri, Mar 23, 2018 at 01:48:03PM +0100, Matthijs Mekking wrote:
> Other candidates: MD, NXT, MAILA - They are obsolete too according to the
> IANA DNS parameters.
>
> Also, if you want to deprecate MB, MG, you might want to consider
> deprecating MAILB too.
There are a few more that are/were
Other candidates: MD, NXT, MAILA - They are obsolete too according to
the IANA DNS parameters.
Also, if you want to deprecate MB, MG, you might want to consider
deprecating MAILB too.
- Matthijs
On 23-03-18 13:11, Ondřej Surý wrote:
Heya,
this is a first attempt to start reducing the
Heya,
this is a first attempt to start reducing the load on DNS Implementors and
actually remove the stuff from DNS that’s not used and not needed anymore.
There’s github for the draft:
https://github.com/oerdnj/draft-sury-dnsop-deprecate-obsolete-resource-records
29 matches
Mail list logo