On 5/13/19 5:17 AM, Brian Dickson wrote:
> Thoughts?
There's the hiding problem due to aggressive caching, especially when
forwarding to a resolver that does aggressive caching (1.1.1.1 is
well-known but there are more).
https://tools.ietf.org/html/rfc8145#section-5.3.1
If the label was extended t
On May 13, 2019, at 11:06 AM, Ondřej Surý wrote:
> I still would like to continue with this and I still think it’s a no brainer
It is far from a no-brainer. The implementation of this document will leave
RFC-compliant systems in an unknown state.
A far easier approach is for any developer to f
On Mon, May 13, 2019 at 07:47:35AM +, Paul Hoffman wrote:
> A far easier approach is for any developer to feel free to treat these
> RRtypes as unknown RRtypes.
I'm not sure I understand the distinction you're making here?
What you said sounds similar to what the document proposes, so
perhaps
On May 13, 2019, at 3:00 PM, Evan Hunt wrote:
>
> On Mon, May 13, 2019 at 07:47:35AM +, Paul Hoffman wrote:
>> A far easier approach is for any developer to feel free to treat these
>> RRtypes as unknown RRtypes.
>
> I'm not sure I understand the distinction you're making here?
> What you sa
I agree with Paul here. Also sidesteps questions like why HINFO is not in
this list.
On Mon, 13 May 2019, 09:08 Paul Hoffman, wrote:
> On May 13, 2019, at 3:00 PM, Evan Hunt wrote:
> >
> > On Mon, May 13, 2019 at 07:47:35AM +, Paul Hoffman wrote:
> >> A far easier approach is for any develo
On 13 May 2019, at 15:08, Paul Hoffman wrote:
> On May 13, 2019, at 3:00 PM, Evan Hunt wrote:
>
>> On Mon, May 13, 2019 at 07:47:35AM +, Paul Hoffman wrote:
>>> A far easier approach is for any developer to feel free to treat these
>>> RRtypes as unknown RRtypes.
>>
>> I'm not sure I under
> On 13 May 2019, at 09:22, Joe Abley wrote:
>
> I would prefer documented agreement about what is obsolete and what is not.
+1
Though a definition of what is meant by obsolete might be needed too: "no
longer seen in the wild but could still be alive in closed environments",
"deader than E
Paul Hoffman wrote:
> On May 13, 2019, at 11:06 AM, Ondřej Surý wrote:
> > I still would like to continue with this and I still think it’s a
> > no brainer
>
> It is far from a no-brainer. The implementation of this document will
> leave RFC-compliant systems in an unknown state.
>
> A far ea
Paul,
On 13/05/2019 10.08, Paul Hoffman wrote:
On May 13, 2019, at 3:00 PM, Evan Hunt wrote:
On Mon, May 13, 2019 at 07:47:35AM +, Paul Hoffman wrote:
A far easier approach is for any developer to feel free to treat these
RRtypes as unknown RRtypes.
I'm not sure I understand the distin
On Mon, 13 May 2019, Paul Hoffman wrote:
I'm not sure I understand the distinction you're making here?
What you said sounds similar to what the document proposes, so
perhaps the document is unclear, or perhaps I've misunderstood you.
I am proposing that we don't need a document, nor changes to
Last week Daniel and I resurrected
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/
The -08 version was posted, it should have minimal changes for the expired
-07 version, except that this version is done in Markdown/github, etc.
Issues tracked are at:
https:
Last week Daniel and I resurrected
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/
The -08 version was posted, it should have minimal changes for the expired
-07 version, except that this version is done in Markdown/github, etc.
Issues tracked are at:
https:
On Mon, May 13, 2019 at 10:52:59AM +0200, Martin Hoffmann wrote:
> Paul Hoffman wrote:
> > A far easier approach is for any developer to feel free to treat
> > these RRtypes as unknown RRtypes.
>
> That will work for all record types except those defined in RFC 1035
> since name compression in rec
On Monday, 13 May 2019 08:14:34 UTC Miek Gieben wrote:
> I agree with Paul here. Also sidesteps questions like why HINFO is not in
> this list.
i disagree with paul here. see below.
>
> On Mon, 13 May 2019, 09:08 Paul Hoffman, wrote:
> > On May 13, 2019, at 3:00 PM, Evan Hunt wrote:
> > > On M
On Mon, May 13, 2019 at 07:30:44PM +, Paul Vixie wrote:
> maintainers will know which burdens they can avoid. having it be a matter of
> ad-hoc "in-crowd" knowledged passed down from mother to daughter is not the
> internet engineering way.
Well, it might _be_ the Internet engineering way, b
15 matches
Mail list logo
