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

[Paul Vixie]

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 WKS RR type is not often used
   by Internet sites.  To confirm that a service is present, simply
   attempt to use it.




While the special processing was added to RFC 2136 (9 years later)
isreally beyond my understanding :(.


host requirements was not a DNS document. it removed nothing from the 
DNS. rather, it removed the burden on service responders to list their 
service in WKS, by telling service initiators not to look for it.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

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 name compression and sorting, which do
> add
> > some complexity, but are already implemented in all the existing
> codebases.
>
> There's the particularly special case of WKS which has weird collision
> logic - RFC 2136 section 3.4.2.2. It's extra weird that this was specified
> in 1997 when WKS was deprecated in 1989 - RFC 1101 and RFC 1123.
>

Getting rid of extraneous weird logic is the primary objective.


> I fear that this will make it hard to delete WKS code because that may
> introduce interop bugs if a new server bindly allows colliding WKS records
> that an old server objects to.
>

There are no compressible domain names in WKS.  RFC3597 unknown type
representation
does not change the meaning or otherwise damage the rdata.

Intermediate nameservers unaware of WKS, pass it along as as an unknown
type.

The end-points, if there still are any, are free to continue using WKS by
mutual agreement.



>
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h
> punycode
> Irish Sea: South 4, increasing 5 to 7, then veering west later. Slight or
> moderate. Rain at times. Good, occasionally poor.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

> 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 name compression and sorting, which do add
>> some complexity, but are already implemented in all the existing codebases.
> 
> There's the particularly special case of WKS which has weird collision
> logic - RFC 2136 section 3.4.2.2. It's extra weird that this was specified
> in 1997 when WKS was deprecated in 1989 - RFC 1101 and RFC 1123.
> 
> I fear that this will make it hard to delete WKS code because that may
> introduce interop bugs if a new server bindly allows colliding WKS records
> that an old server objects to.

Good catch. WKS would then probably need a separate document that would also 
remove it from RFC 2136.

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 WKS RR type is not often used
  by Internet sites.  To confirm that a service is present, simply
  attempt to use it.

While the special processing was added to RFC 2136 (9 years later) is really 
beyond my understanding :(.

Ondrej
--
Ondřej Surý
ond...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

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 already implemented in all the existing codebases.

There's the particularly special case of WKS which has weird collision
logic - RFC 2136 section 3.4.2.2. It's extra weird that this was specified
in 1997 when WKS was deprecated in 1989 - RFC 1101 and RFC 1123.

I fear that this will make it hard to delete WKS code because that may
introduce interop bugs if a new server bindly allows colliding WKS records
that an old server objects to.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: South 4, increasing 5 to 7, then veering west later. Slight or
moderate. Rain at times. Good, occasionally poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shane Kerr]

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 actually surprised to see that support for rarely-used RRTypes is
>> really upsetting the camel.

I'm not that surprised. It's pretty close to a bike shed topic; everyone
can understand it, it is not *that* important, and so everyone can have
an opinion that is basically as valid as any other. ;-)

> To me this deprecating obsolete records is more an exercise of picking
> the low hanging fruit. Start with an easy task, gain experience for more
> difficult "unloading the camel".

I agree with Matthijs here.

I think Paul's advice of looking at prior work in deprecating unused (or
harmful) bits of the DNS protocol makes sense. Since the way software is
deployed and used is not exactly the same now as it was in 2002, so we
actually have to repeat the exercise and see how stuff breaks now (or
not... I mean... MB?).

Cheers,

--
Shane

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 see that support for rarely-used RRTypes is
really upsetting the camel.


To me this deprecating obsolete records is more an exercise of picking
the low hanging fruit. Start with an easy task, gain experience for more
difficult "unloading the camel".


that was done, with deprecate-iquery. we now know how to do this.

but, we have got to stop saying things like "i don't see this protocol 
feature used in the queries hitting my feature, therefore it's not 
important any more." the internet, and the private intranets beyond the 
edge of the internet, is a big place.


the fat part of this camel may not be the oldest dna, either.

--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[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 actually surprised to see that support for rarely-used RRTypes is
really upsetting the camel.


To me this deprecating obsolete records is more an exercise of picking 
the low hanging fruit. Start with an easy task, gain experience for more 
difficult "unloading the camel".


Best regards,
  Matthijs



A combinatorial explosion of annoying workarounds for the inability of
middleboxes or upstream authority servers to implement EDNS(0)
properly seems like a much more plausible camel irritant to me. I'm
sure there are many more like that.

I can see why you could strip out lines of code by eliminating the
need to parse the canonical formatting of WKS and friends, but I'm
surprised that it's a notable source of complexity. It is, after all,
complexity that I heard is causing the camel strain, not just lines of
code.

If future-BIND stops parsing an archaic RRType that I happen to use,
I'm going to have to change whatever code or processes that depend on
it. Maybe someone (ISC, even) is going to publish a filter that will
turn all the old RRs in canonical syntax into TYPE representation,
and back again. New RRTypes might then need to get implemented in both
BIND (because presumably they are camel-friendly) and also in the
filter or filters, because perhaps we are targeting multiple
nameserver implementations with our zone file.

This all sounds like we're just sharing the complexity around. It
doesn't sound any simpler. Maybe it's a silly example? I don't know.
Could be. But I think brushing the grains RRType parsing dust off the
camel is not going to do much for its posture.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

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 implementers.


I agree.

And I don't see much point in obsoleting simple defines and logging
unknown RRtypes.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

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 a needle" to
our camel metaphor.)

> A combinatorial explosion of annoying workarounds for the inability of
> middleboxes or upstream authority servers to implement EDNS(0)
> properly seems like a much more plausible camel irritant to me. I'm
> sure there are many more like that.

Wholeheartedly agree, and efforts to address this are under way.

> I can see why you could strip out lines of code by eliminating the
> need to parse the canonical formatting of WKS and friends, but I'm
> surprised that it's a notable source of complexity. It is, after all,
> complexity that I heard is causing the camel strain, not just lines of
> code.
> 
> If future-BIND stops parsing an archaic RRType that I happen to use,
> I'm going to have to change whatever code or processes that depend on
> it. Maybe someone (ISC, even) is going to publish a filter that will
> turn all the old RRs in canonical syntax into TYPE representation,
> and back again. New RRTypes might then need to get implemented in both
> BIND (because presumably they are camel-friendly) and also in the
> filter or filters, because perhaps we are targeting multiple
> nameserver implementations with our zone file.
> 
> This all sounds like we're just sharing the complexity around. It
> doesn't sound any simpler. Maybe it's a silly example? I don't know.
> Could be. But I think brushing the grains RRType parsing dust off the
> camel is not going to do much for its posture.

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 implementers.

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 already implemented in all the existing codebases.
I don't see how the IETF can mandate that they be removed, nor am I sure
it's particuilarly worth doing.  We can make them optional to implement in
the future, though.  Perhaps that's all Ondrej has in mind?

(With respect to BIND, if these types are declared obsolete by the working
group, then my inclination would be to a log a message saying so if you
tried to load them in a zone, same as with SPF.  In a future relase I might
start treating them as opague types when rendering to wire format, but
would probably retain the ability to parse them and display them as text.)

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthew Pounsett]

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 implement an additional RRType is
trivial by comparison to literally anything else in the protocol, including
such (supposedly) trivial operations as reading and writing zone files.
I've got nothing against deprecating RRTypes that we know aren't in use,
but it doesn't seem like a particularly high priority.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Viktor Dukhovni]

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 dead/zombie QTYPEs might be OK I suppose.

Absolutely no!  *THAT* would add substantial run-time complexity
for no reason, achieving the opposite of any simplification that
might result from dropping support for the RRtype. If there's no
such data in your zone, return NODATA or NXDOMAIN as appropriate.
If there is such data, return that data.

This would be grossly misguided.  Perhaps time to reread:

https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08

As for removing parsing code from tools, I sympathise with the view
that this does not remove much complexity that matters.  The
complexity we really should care about is wire (protocol) complexity,
not tool complexity.  One might say that *new* tools may skip
implementing obsolete RRtypes, and that users should avoid new
uses of obsolete RRtypes, but there's not IMHO much impetus
for removing support from existing tools.

That said, legacy code has some costs, and one should attempt to
eventually shed bits nobody uses. So while I agre that the priorities
are elsewhere, this too is something one might eventually pay
attention to.  So I am not opposed to dropping parser support for
essentially unused types.  It just needs to be down with care,
first issue deprecation warnings for a few releases, then if there
are few enough complaints, remove support.

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

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 tetrapoly 
(insert your favorite Greek numerical prefix), the fact is that new 
implementations do pop up from time to time, and if we can reduce the protocol 
a little bit, so they can actually implement what’s important, that would be 
the noble goal here.

Let me repeat again - we are speaking about stuff that was declared either 
OBSOLETE or EXPERIMENTAL already in RFC1035.

I’ll elaborate more about why I think we locked ourselves into this when I am 
not typing on small phone screen in reply to Jared’s message later today.

Cheers,
Ondrej

--
Ondřej Surý — ISC

> On 24 Mar 2018, at 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 rarely-used RRTypes is
> really upsetting the camel.
> 
> A combinatorial explosion of annoying workarounds for the inability of
> middleboxes or upstream authority servers to implement EDNS(0)
> properly seems like a much more plausible camel irritant to me. I'm
> sure there are many more like that.
> 
> I can see why you could strip out lines of code by eliminating the
> need to parse the canonical formatting of WKS and friends, but I'm
> surprised that it's a notable source of complexity. It is, after all,
> complexity that I heard is causing the camel strain, not just lines of
> code.
> 
> If future-BIND stops parsing an archaic RRType that I happen to use,
> I'm going to have to change whatever code or processes that depend on
> it. Maybe someone (ISC, even) is going to publish a filter that will
> turn all the old RRs in canonical syntax into TYPE representation,
> and back again. New RRTypes might then need to get implemented in both
> BIND (because presumably they are camel-friendly) and also in the
> filter or filters, because perhaps we are targeting multiple
> nameserver implementations with our zone file.
> 
> This all sounds like we're just sharing the complexity around. It
> doesn't sound any simpler. Maybe it's a silly example? I don't know.
> Could be. But I think brushing the grains RRType parsing dust off the
> camel is not going to do much for its posture.
> 
> 
> Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

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 camel.

A combinatorial explosion of annoying workarounds for the inability of
middleboxes or upstream authority servers to implement EDNS(0)
properly seems like a much more plausible camel irritant to me. I'm
sure there are many more like that.

I can see why you could strip out lines of code by eliminating the
need to parse the canonical formatting of WKS and friends, but I'm
surprised that it's a notable source of complexity. It is, after all,
complexity that I heard is causing the camel strain, not just lines of
code.

If future-BIND stops parsing an archaic RRType that I happen to use,
I'm going to have to change whatever code or processes that depend on
it. Maybe someone (ISC, even) is going to publish a filter that will
turn all the old RRs in canonical syntax into TYPE representation,
and back again. New RRTypes might then need to get implemented in both
BIND (because presumably they are camel-friendly) and also in the
filter or filters, because perhaps we are targeting multiple
nameserver implementations with our zone file.

This all sounds like we're just sharing the complexity around. It
doesn't sound any simpler. Maybe it's a silly example? I don't know.
Could be. But I think brushing the grains RRType parsing dust off the
camel is not going to do much for its posture.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jared Mauch]

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 to me. And I am not the one sitting on a 
> pile of passive DNS data, so I can’t pull the numbers...
> 
> We are not taking the ability to put random TYPEnnn records into the zone, we 
> are just saying the tools just won’t understand them anymore. Again nothing 
> is going to break on the day one.

Ondrej,

I think the issue here is just because it's not commonly seen on the
public internet, doesn't mean it's not used.  We don't use DHCP to configure
p2p links on routers, this doesn't mean that DHCP can go away, it's used
elsewhere.

I think what Paul is trying to point out is the same thing, some
enterprises may still be using it internally.  Just because we
don't use the RR type in isc.org, nether.net, akamai.com doesn't mean
nobody is using it for their internal networks.  We should attempt to
determine who may be using it.  This can be done by logging or a survey
of folks doing slave zones, etc.

isc/bind can and perhaps should implement logging for these
rrtypes that say they may be going away so folks can see the impact.

ISC/bind also have a history of doing this with the warn & fail
directives in the named.conf file, which would be a great way to expose
these types of items.  check-old-rrtype (warn|fail|ignore) or something
similar would be useful to an actual operator.

here's some data on rrtypes seen in my nameserver.

- Jared

server0.queries=109159256
server1.queries=100199925
num.queries=209359181
num.type.TYPE0=27
num.type.A=98905962
num.type.NS=3428038
num.type.MD=0
num.type.MF=0
num.type.CNAME=949771
num.type.SOA=807788
num.type.MB=0
num.type.MG=0
num.type.MR=0
num.type.NULL=28
num.type.WKS=0
num.type.PTR=8847792
num.type.HINFO=1178
num.type.MINFO=0
num.type.MX=4110956
num.type.TXT=1164968
num.type.RP=0
num.type.AFSDB=2018
num.type.X25=0
num.type.ISDN=0
num.type.RT=0
num.type.NSAP=0
num.type.SIG=0
num.type.KEY=0
num.type.PX=0
num.type.=64526576
num.type.LOC=2288
num.type.NXT=780
num.type.TYPE31=108
num.type.SRV=2194823
num.type.NAPTR=18707
num.type.KX=0
num.type.CERT=6
num.type.TYPE38=238830
num.type.DNAME=9
num.type.OPT=0
num.type.APL=0
num.type.DS=177999
num.type.SSHFP=4846
num.type.IPSECKEY=0
num.type.RRSIG=20178
num.type.NSEC=281
num.type.DNSKEY=2261055
num.type.DHCID=0
num.type.NSEC3=0
num.type.NSEC3PARAM=2596
num.type.TLSA=22176
num.type.TYPE53=8
num.type.CDS=2267
num.type.CDNSKEY=2027
num.type.OPENPGPKEY=0
num.type.CSYNC=0
num.type.TYPE65=2
num.type.TYPE92=9
num.type.SPF=109981
num.type.NID=0
num.type.L32=0
num.type.L64=0
num.type.LP=0
num.type.EUI48=0
num.type.EUI64=0
num.type.TYPE127=5
num.type.TYPE143=1
num.type.TYPE165=1
num.type.TYPE191=335
num.type.TYPE222=3
num.type.TYPE223=27
num.type.TYPE239=29
num.type.TYPE240=2
num.type.TYPE243=2
num.type.TYPE246=1
num.type.TYPE247=41
num.type.TYPE251=26458
num.type.TYPE252=3312
num.type.TYPE253=42
num.type.TYPE254=29
num.type.TYPE255=21357118
num.opcode.QUERY=209248548
num.opcode.NOTIFY=80330
num.class.IN=209324746
num.class.CH=4132
num.rcode.NOERROR=138257521
num.rcode.FORMERR=417
num.rcode.SERVFAIL=132820
num.rcode.NXDOMAIN=25011450
num.rcode.NOTIMP=56046
num.rcode.REFUSED=36625841
num.rcode.YXDOMAIN=0
num.rcode.NOTAUTH=4
num.edns=189357953
num.ednserr=307
num.udp=171926848
num.udp6=28159814
num.tcp=9107734
num.tcp6=164785
num.answer_wo_aa=703271
num.rxerr=0
num.txerr=6
num.raxfr=54
num.truncated=12595885
num.dropped=2592
zone.master=70
zone.slave=9350


-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

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
justifications are necessarily different for each category identified in
RFC1035.

  3.3.4. MD RDATA format (Obsolete)
  3.3.5. MF RDATA format (Obsolete)

These were already obsolete when RFC1035 was published and arguably should
never have appeared at all.
If these have not already been deprecated somewhere else, there is no
plausible argument against doing so now.


  3.3.3. MB RDATA format (EXPERIMENTAL)
  3.3.6. MG RDATA format (EXPERIMENTAL)
  3.3.7. MINFO RDATA format (EXPERIMENTAL)
  3.3.8. MR RDATA format (EXPERIMENTAL)

After 30 years, it seem clear that the "experiment" produced little or
nothing of lasting value.  Plenty of word have been wasted in the past
about open-ended experiments and unpublished results.  Deprecating these
RRTYPES would put a formal end to the "experiment".  Any counter-argument
needs to be justified by evidence of continuing use in the global internet,
and made by the parties directly affected.  The "someone might be using it
somewhere ..." argument is far from convincing.


  3.4.2. WKS RDATA format

WKS is IPv4-specific, so the choice is ether to wait until IPv4 itself
becomes deprecated, or to dispose of it now in the same manner as MB, MG
etc.


  3.2.3. QTYPE values

The intended meaning of MAILA is uncertain, but it is already declared by
RFC1035 to be obsolete.

MAILB is a specific request for MB, MG, and MR records.

Both should also be deprecated by this document.



--DIck

___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[P Vix]

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ý"  wrote:
>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 value of allow-query to be LAN only, it took years to
>do as safely as we knew how, and even so there was some breakage.
>> 
>>> Your argument feels like strawman to me. And I am not the one
>sitting
>>> on a pile of passive DNS data, so I can’t pull the numbers...
>> 
>> we don't see a lot of intranet data, so that would not be
>dispositive. however, i urge you to reconsider your strawman-ish
>feelings. we are forever rebuilding the airplane in flight. the long
>tail matters.
>> 
>>> We are not taking the ability to put random TYPEnnn records into the
>>> zone, we are just saying the tools just won’t understand them
>>> anymore. Again nothing is going to break on the day one.
>> 
>> as long as people know what they're doing and are willing to convert
>their zones using tools unspecified, that's true. but you are chewing
>on the narrowest part of bert's camel here, at some risk, little gain.
>> 
>> -- 
>> P Vixie
>> 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[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 value of allow-query to be LAN only, it took years to do as 
> safely as we knew how, and even so there was some breakage.
> 
>> Your argument feels like strawman to me. And I am not the one sitting
>> on a pile of passive DNS data, so I can’t pull the numbers...
> 
> we don't see a lot of intranet data, so that would not be dispositive. 
> however, i urge you to reconsider your strawman-ish feelings. we are forever 
> rebuilding the airplane in flight. the long tail matters.
> 
>> We are not taking the ability to put random TYPEnnn records into the
>> zone, we are just saying the tools just won’t understand them
>> anymore. Again nothing is going to break on the day one.
> 
> as long as people know what they're doing and are willing to convert their 
> zones using tools unspecified, that's true. but you are chewing on the 
> narrowest part of bert's camel here, at some risk, little gain.
> 
> -- 
> P Vixie
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 value of allow-query to be LAN only, it took years to do as 
safely as we knew how, and even so there was some breakage.



Your argument feels like strawman to me. And I am not the one sitting
on a pile of passive DNS data, so I can’t pull the numbers...


we don't see a lot of intranet data, so that would not be dispositive. 
however, i urge you to reconsider your strawman-ish feelings. we are 
forever rebuilding the airplane in flight. the long tail matters.



We are not taking the ability to put random TYPEnnn records into the
zone, we are just saying the tools just won’t understand them
anymore. Again nothing is going to break on the day one.


as long as people know what they're doing and are willing to convert 
their zones using tools unspecified, that's true. but you are chewing on 
the narrowest part of bert's camel here, at some risk, little gain.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

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 I can’t pull the numbers...

We are not taking the ability to put random TYPEnnn records into the zone, we 
are just saying the tools just won’t understand them anymore. Again nothing is 
going to break on the day one.

Ondrej
--
Ondřej Surý — ISC

> On 23 Mar 2018, at 18:26, Paul Vixie  wrote:
> 
> 
> 
> 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 stuff you are using - you are on
>> your own now. It’s same as with the stuff that never got the RFC.
> 
> so anyone supporting an older internal network using modern tools has to stop 
> upgrading their tooling. that's not constructive for anybody. all of us will 
> be less safe if these tools become non-upgradeable.
> 
>> Paul, sorry, but the argument “but I know of people running” ancient
>> systems can’t be used at every attempt to cleanup the kitchensink
>> protocol that DNS is right now.
> 
> ondrej, if you're looking for stuff to kill that nobody is using and that 
> needlessly fattens the camel, there's a lot of lower hanging fruit.
> 
> to say it's complicated, let's simplify it, and oh by the way we need to add 
> a CNAME to support the never-workable RFC 5011 plan we adopted in ignorance 
> many years back, in the same breath, confuses me.
> 
> -- 
> P Vixie
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 stuff you are using - you are on
your own now. It’s same as with the stuff that never got the RFC.


so anyone supporting an older internal network using modern tools has to 
stop upgrading their tooling. that's not constructive for anybody. all 
of us will be less safe if these tools become non-upgradeable.



Paul, sorry, but the argument “but I know of people running” ancient
systems can’t be used at every attempt to cleanup the kitchensink
protocol that DNS is right now.


ondrej, if you're looking for stuff to kill that nobody is using and 
that needlessly fattens the camel, there's a lot of lower hanging fruit.


to say it's complicated, let's simplify it, and oh by the way we need to 
add a CNAME to support the never-workable RFC 5011 plan we adopted in 
ignorance many years back, in the same breath, confuses me.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

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 - you are on your own now. 
It’s same as with the stuff that never got the RFC. You can you whatever you 
want, it will be your responsibility (and costs), not the implementors. So, the 
people can keep their old system running, they just can’t expect the current 
DNS to interoperate with them.

Paul, sorry, but the argument “but I know of people running” ancient systems 
can’t be used at every attempt to cleanup the kitchensink protocol that DNS is 
right now.

Ondrej 
--
Ondřej Surý — ISC

> On 23 Mar 2018, at 17:55, Paul Vixie  wrote:
> 
> 
> 
> 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.”
> 
> i think this is overbroad. if we aren't also sure that it's not being used in 
> some private network somewhere, we should not tell implementers to remove 
> support. a lot of private networks use internet protocols and implementations 
> to support their local apps and users.
> 
> mf, mg, mb, and mail1 are i think still in use on some as/400 intranets.
> 
> when i removed UID and GID from BIND it was because there was no RFC, not 
> because i wasn't fully aware of some older athena implementations still in 
> use at that time which used these instead of TXT.
> 
> ideally we'd put out an extended call for comments about anything we'd like 
> to remove if it ever worked to anyone's knowledge. if it never worked, like 
> extended label types in EDNS, they can just be removed.
> 
> this is how we handled IQUERY deprecation and i think it went well.
> 
> -- 
> P Vixie
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bob Harold]

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
>
>
Works for me, thanks!

-- 
Bob Harold



> On 23 Mar 2018, at 16:51, Bob Harold  wrote:
>
>
> 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
>> situation. Similarly, an occasional user that tries things doesn’t make
>> those experimental RRTYPEs to be “in use”.
>>
>> What I mean is to make DNS simpler by kicking out stuff that has no use
>> in existing protocols.
>>
>> Ondřej
>> --
>> Ondřej Surý — ISC
>>
>>
> Ok, sorry to sound mean.  But I think 'not in use' needs to be defined in
> the rfc so we all understand it the same.  How do we decide when something
> in no longer in use?  Perhaps there is no quantitative measurement and we
> just have to make a judgement call.
>
> "no known practical usage" ?
> "no known use that will break anything if removed" ?
> "use is so low that the the advantage of removing exceeds the advantage of
> continuing to support it" ?
> "there is very little use and we don't think removing it will cause a
> problem" ?
>
> --
> Bob Harold
>
>
>
>> On 23 Mar 2018, at 14:18, Bob Harold  wrote:
>>
>>
>> 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: https://github.com/oerd
>>> nj/draft-sury-dnsop-deprecate-obsolete-resource-records
>>>
>>> Ondrej
>>> --
>>> Ondřej Surý
>>> ond...@isc.org
>>>
>>> Begin forwarded message:
>>>
>>> *From: *internet-dra...@ietf.org
>>> *Subject: **New Version Notification for
>>> draft-sury-deprecate-obsolete-resource-records-00.txt*
>>> *Date: *23 March 2018 at 12:09:19 GMT
>>> *To: *"Ondrej Sury" 
>>>
>>>
>>> A new version of I-D, draft-sury-deprecate-obsolete-
>>> resource-records-00.txt
>>> has been successfully submitted by Ondrej Sury and posted to the
>>> IETF repository.
>>>
>>> Name: draft-sury-deprecate-obsolete-resource-records
>>> Revision: 00
>>> Title: Deprecating obsolete DNS Resource Records
>>> Document date: 2018-03-22
>>> Group: Individual Submission
>>> Pages: 4
>>> URL:https://www.ietf.org/internet-drafts/draft-sury-d
>>> eprecate-obsolete-resource-records-00.txt
>>> Status: https://datatracker.ietf.org/doc/draft-sury-deprecat
>>> e-obsolete-resource-records/
>>> Htmlized:   https://tools.ietf.org/html/draft-sury-deprecate-obsol
>>> ete-resource-records-00
>>> Htmlized:   https://datatracker.ietf.org/doc/html/draft-sury-depre
>>> cate-obsolete-resource-records
>>>
>>>
>>> Abstract:
>>>   This document deprecates Resource Records that are neither being used
>>>   for anything meanigful nor already made obsolete by other RFCs.  This
>>>   document updates [RFC1035].
>>>
>>>
>> I don't mind deprecating unused types.  But I don't understand how an
>> unused type can affect compression.  I can only imagine it having an effect
>> if the type actually exists in a packet, which means that it is 'in use'..
>>
>> Do you mean 'types that have DNS records, and hosts query for those
>> records, but we think they are not really used'  ?
>>
>> --
>> Bob Harold
>>
>>
>>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

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 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 
>> situation. Similarly, an occasional user that tries things doesn’t make 
>> those experimental RRTYPEs to be “in use”.
>> 
>> What I mean is to make DNS simpler by kicking out stuff that has no use in 
>> existing protocols.
>> 
>> Ondřej 
>> --
>> Ondřej Surý — ISC
> 
> Ok, sorry to sound mean.  But I think 'not in use' needs to be defined in the 
> rfc so we all understand it the same.  How do we decide when something in no 
> longer in use?  Perhaps there is no quantitative measurement and we just have 
> to make a judgement call.
> 
> "no known practical usage" ?
> "no known use that will break anything if removed" ?
> "use is so low that the the advantage of removing exceeds the advantage of 
> continuing to support it" ?
> "there is very little use and we don't think removing it will cause a 
> problem" ?
> 
> -- 
> Bob Harold
> 
>  
>>> On 23 Mar 2018, at 14:18, Bob Harold  wrote:
>>> 
>>> 
 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: 
 https://github.com/oerdnj/draft-sury-dnsop-deprecate-obsolete-resource-records
 
 Ondrej
 --
 Ondřej Surý
 ond...@isc.org
 
> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for 
> draft-sury-deprecate-obsolete-resource-records-00.txt
> Date: 23 March 2018 at 12:09:19 GMT
> To: "Ondrej Sury" 
> 
> 
> A new version of I-D, 
> draft-sury-deprecate-obsolete-resource-records-00.txt
> has been successfully submitted by Ondrej Sury and posted to the
> IETF repository.
> 
> Name: draft-sury-deprecate-obsolete-resource-records
> Revision: 00
> Title:Deprecating obsolete DNS Resource Records
> Document date:2018-03-22
> Group:Individual Submission
> Pages:4
> URL:
> https://www.ietf.org/internet-drafts/draft-sury-deprecate-obsolete-resource-records-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-sury-deprecate-obsolete-resource-records/
> Htmlized:   
> https://tools.ietf.org/html/draft-sury-deprecate-obsolete-resource-records-00
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-sury-deprecate-obsolete-resource-records
> 
> 
> Abstract:
>   This document deprecates Resource Records that are neither being used
>   for anything meanigful nor already made obsolete by other RFCs.  This
>   document updates [RFC1035].
>>> 
>>> I don't mind deprecating unused types.  But I don't understand how an 
>>> unused type can affect compression.  I can only imagine it having an effect 
>>> if the type actually exists in a packet, which means that it is 'in use'.
>>> 
>>> Do you mean 'types that have DNS records, and hosts query for those 
>>> records, but we think they are not really used'  ?
>>> 
>>> -- 
>>> Bob Harold
> 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bob Harold]

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
> situation. Similarly, an occasional user that tries things doesn’t make
> those experimental RRTYPEs to be “in use”.
>
> What I mean is to make DNS simpler by kicking out stuff that has no use in
> existing protocols.
>
> Ondřej
> --
> Ondřej Surý — ISC
>
>
Ok, sorry to sound mean.  But I think 'not in use' needs to be defined in
the rfc so we all understand it the same.  How do we decide when something
in no longer in use?  Perhaps there is no quantitative measurement and we
just have to make a judgement call.

"no known practical usage" ?
"no known use that will break anything if removed" ?
"use is so low that the the advantage of removing exceeds the advantage of
continuing to support it" ?
"there is very little use and we don't think removing it will cause a
problem" ?

-- 
Bob Harold



> On 23 Mar 2018, at 14:18, Bob Harold  wrote:
>
>
> 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: https://github.com/oerd
>> nj/draft-sury-dnsop-deprecate-obsolete-resource-records
>>
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@isc.org
>>
>> Begin forwarded message:
>>
>> *From: *internet-dra...@ietf.org
>> *Subject: **New Version Notification for
>> draft-sury-deprecate-obsolete-resource-records-00.txt*
>> *Date: *23 March 2018 at 12:09:19 GMT
>> *To: *"Ondrej Sury" 
>>
>>
>> A new version of I-D, draft-sury-deprecate-obsolete-
>> resource-records-00.txt
>> has been successfully submitted by Ondrej Sury and posted to the
>> IETF repository.
>>
>> Name: draft-sury-deprecate-obsolete-resource-records
>> Revision: 00
>> Title: Deprecating obsolete DNS Resource Records
>> Document date: 2018-03-22
>> Group: Individual Submission
>> Pages: 4
>> URL:https://www.ietf.org/internet-drafts/draft-sury-
>> deprecate-obsolete-resource-records-00.txt
>> Status: https://datatracker.ietf.org/doc/draft-sury-deprecat
>> e-obsolete-resource-records/
>> Htmlized:   https://tools.ietf.org/html/draft-sury-deprecate-obsol
>> ete-resource-records-00
>> Htmlized:   https://datatracker.ietf.org/doc/html/draft-sury-depre
>> cate-obsolete-resource-records
>>
>>
>> Abstract:
>>   This document deprecates Resource Records that are neither being used
>>   for anything meanigful nor already made obsolete by other RFCs.  This
>>   document updates [RFC1035].
>>
>>
> I don't mind deprecating unused types.  But I don't understand how an
> unused type can affect compression.  I can only imagine it having an effect
> if the type actually exists in a packet, which means that it is 'in use'.
>
> Do you mean 'types that have DNS records, and hosts query for those
> records, but we think they are not really used'  ?
>
> --
> Bob Harold
>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

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 those experimental 
RRTYPEs to be “in use”.

What I mean is to make DNS simpler by kicking out stuff that has no use in 
existing protocols.

Ondřej 
--
Ondřej Surý — ISC

> On 23 Mar 2018, at 14:18, Bob Harold  wrote:
> 
> 
>> 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: 
>> https://github.com/oerdnj/draft-sury-dnsop-deprecate-obsolete-resource-records
>> 
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@isc.org
>> 
>>> Begin forwarded message:
>>> 
>>> From: internet-dra...@ietf.org
>>> Subject: New Version Notification for 
>>> draft-sury-deprecate-obsolete-resource-records-00.txt
>>> Date: 23 March 2018 at 12:09:19 GMT
>>> To: "Ondrej Sury" 
>>> 
>>> 
>>> A new version of I-D, draft-sury-deprecate-obsolete-resource-records-00.txt
>>> has been successfully submitted by Ondrej Sury and posted to the
>>> IETF repository.
>>> 
>>> Name:   draft-sury-deprecate-obsolete-resource-records
>>> Revision:   00
>>> Title:  Deprecating obsolete DNS Resource Records
>>> Document date:  2018-03-22
>>> Group:  Individual Submission
>>> Pages:  4
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-sury-deprecate-obsolete-resource-records-00.txt
>>> Status: 
>>> https://datatracker.ietf.org/doc/draft-sury-deprecate-obsolete-resource-records/
>>> Htmlized:   
>>> https://tools.ietf.org/html/draft-sury-deprecate-obsolete-resource-records-00
>>> Htmlized:   
>>> https://datatracker.ietf.org/doc/html/draft-sury-deprecate-obsolete-resource-records
>>> 
>>> 
>>> Abstract:
>>>   This document deprecates Resource Records that are neither being used
>>>   for anything meanigful nor already made obsolete by other RFCs.  This
>>>   document updates [RFC1035].
> 
> I don't mind deprecating unused types.  But I don't understand how an unused 
> type can affect compression.  I can only imagine it having an effect if the 
> type actually exists in a packet, which means that it is 'in use'.
> 
> Do you mean 'types that have DNS records, and hosts query for those records, 
> but we think they are not really used'  ?
> 
> -- 
> Bob Harold
>  
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bob Harold]

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: https://github.com/oerdnj/draft-sury-dnsop-
> deprecate-obsolete-resource-records
>
> Ondrej
> --
> Ondřej Surý
> ond...@isc.org
>
> Begin forwarded message:
>
> *From: *internet-dra...@ietf.org
> *Subject: **New Version Notification for
> draft-sury-deprecate-obsolete-resource-records-00.txt*
> *Date: *23 March 2018 at 12:09:19 GMT
> *To: *"Ondrej Sury" 
>
>
> A new version of I-D, draft-sury-deprecate-obsolete-
> resource-records-00.txt
> has been successfully submitted by Ondrej Sury and posted to the
> IETF repository.
>
> Name: draft-sury-deprecate-obsolete-resource-records
> Revision: 00
> Title: Deprecating obsolete DNS Resource Records
> Document date: 2018-03-22
> Group: Individual Submission
> Pages: 4
> URL:https://www.ietf.org/internet-drafts/draft-
> sury-deprecate-obsolete-resource-records-00.txt
> Status: https://datatracker.ietf.org/doc/draft-sury-
> deprecate-obsolete-resource-records/
> Htmlized:   https://tools.ietf.org/html/draft-sury-deprecate-
> obsolete-resource-records-00
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-sury-
> deprecate-obsolete-resource-records
>
>
> Abstract:
>   This document deprecates Resource Records that are neither being used
>   for anything meanigful nor already made obsolete by other RFCs.  This
>   document updates [RFC1035].
>
>
I don't mind deprecating unused types.  But I don't understand how an
unused type can affect compression.  I can only imagine it having an effect
if the type actually exists in a packet, which means that it is 'in use'.

Do you mean 'types that have DNS records, and hosts query for those
records, but we think they are not really used'  ?

-- 
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mukund Sivaraman]

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 in use which are not even listed.
E.g, "A" was used outside IN class.

Mukund

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthijs Mekking]

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 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


Ondrej
--
Ondřej Surý
ond...@isc.org 


Begin forwarded message:

*From: *internet-dra...@ietf.org 
*Subject: **New Version Notification for 
draft-sury-deprecate-obsolete-resource-records-00.txt*

*Date: *23 March 2018 at 12:09:19 GMT
*To: *"Ondrej Sury" >


A new version of I-D, 
draft-sury-deprecate-obsolete-resource-records-00.txt

has been successfully submitted by Ondrej Sury and posted to the
IETF repository.

Name:draft-sury-deprecate-obsolete-resource-records
Revision:00
Title:Deprecating obsolete DNS Resource Records
Document date:2018-03-22
Group:Individual Submission
Pages:4
URL: 
https://www.ietf.org/internet-drafts/draft-sury-deprecate-obsolete-resource-records-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-sury-deprecate-obsolete-resource-records/
Htmlized: 
https://tools.ietf.org/html/draft-sury-deprecate-obsolete-resource-records-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-sury-deprecate-obsolete-resource-records



Abstract:
  This document deprecates Resource Records that are neither being used
  for anything meanigful nor already made obsolete by other RFCs.  This
  document updates [RFC1035].




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 mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop