Re: [DNSOP] DNS names for local networks - not only home residental networks ...

2017-09-05 Thread Stephane Bortzmeyer 
On Tue, Sep 05, 2017 at 06:09:06AM +0200,
 Walter H.  wrote 
 a message of 20 lines which said:

> I see it exact this, and it would be fair to prevent future bugs with
> defining one or two FAKE TLDs (e.g. .corp, .lan) for exact this use
> case;

Why does it need to be a TLD (see all the discussions here about
Special Use Domain Names, .alt, .alt.arpa, etc)? Why not
lan.mycompany.com?

> - there isn't really a uniqness as requirement

As I said before, and explained, you're wrong here, since you don't
take merging and acquisition into account.

> - a public WHOIS grabbing for these domains needn't also be given;

With a subdomain of your Second Level Domain, no need for WHOIS (or
RDAP).

But I agree that ICANN rules for the .corp TLDs are stupid. If
McDonald's register .MCDONALDS, why do they need delegation and public
social info for the SLD?

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

Re: [DNSOP] DNS names for local networks - not only home residental networks ...

2017-09-05 Thread Walter H. 
On Tue, September 5, 2017 09:04, Stephane Bortzmeyer wrote:
> On Tue, Sep 05, 2017 at 06:09:06AM +0200,
>  Walter H.  wrote
>  a message of 20 lines which said:
>
>> I see it exact this, and it would be fair to prevent future bugs with
>> defining one or two FAKE TLDs (e.g. .corp, .lan) for exact this use
>> case;
>
> Why does it need to be a TLD (see all the discussions here about
> Special Use Domain Names, .alt, .alt.arpa, etc)?

.alt is a TLD ...

> Why not lan.mycompany.com?

because mycompany.com is in WHOIS ..., see below

>> - there isn't really a uniqness as requirement
>
> As I said before, and explained, you're wrong here,

no, because nobody said, that uniqness is forbidden ..., and uniqness
implicitly requires the other point which I'd say, that MUST NOT

>> - a public WHOIS grabbing for these domains needn't also be given;
>
> With a subdomain of your Second Level Domain, no need for WHOIS (or
> RDAP).

you are wrong ...
the subdomain is part of the Second Level Domain and so there is a need
for WHOIS (or RDAP) for the Second Level Domain ...


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

Re: [DNSOP] DNS names for local networks - not only home residental networks ...

2017-09-05 Thread Matthew Pounsett 
On 5 September 2017 at 00:01, Walter H.  wrote:

>
> > The keyword above was examples which they clearly were.  Most of
> > 1.0.0.0/8 is in use today despite those examples.  The use of local
> > test were also clearly examples.  The Microsoft page above advocated
> > the use literal use of .local which is very different.
>
> and now in the IPv6 ages the same bug is done again ...
>
> 2001:db8: ...
>
> 2001:db8::/32 is reserved for documentation in RFC 3849.  As 192.0.2.0/24,
198.51.100.0/24, and 203.0.113.0/24 were in RFC 5737.

It's not a bug, it's a feature.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] IPR Disclosure Google Inc.'s Statement about IPR related to draft-tale-dnsop-serve-stale

2017-09-05 Thread IETF Secretariat 
Dear David C Lawrence, Warren Kumari:


An IPR disclosure that pertains to your Internet-Draft entitled "Serving
Stale Data to Improve DNS Resiliency" (draft-tale-dnsop-serve-stale) was
submitted to the IETF Secretariat on  and has been posted on the "IETF Page
of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/3059/). The title of the IPR disclosure is
"Google Inc.'s Statement about IPR related to
draft-tale-dnsop-serve-stale"


Thank you

IETF Secretariat

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

[DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

2017-09-05 Thread tjw ietf 
August is over and my self-imposed holiday is over, so it's time to get
busy again. We have this document marked as a candidate for adoption.

This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale

The draft is available here:
https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

*If You have already stated your position for or against adoption, we are
counting those so you do not need to repeat yourself. *

This call for adoption ends: 19 September 2017

Thanks,
tim wicinski
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] 答复: DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

2017-09-05 Thread 宋林健 
Just quickly go through the draft. 

 

One question: Is it worthwhile to let sub-resolver to know that the answer is 
stale. It is true that “stale bread is better than no bread” on the recursive 
server’s point of view. But it may be not true for sub-resolver or measurement 
probes .

 

The user may want to be more informative. They may have alterative recursive 
servers or other resolution path ( some apps have their own resolution path) . 
I have this thought analogous to buying a sushi in 7&11 shop. I pay attention 
to the   
expiration time. I think I need to know it. 

 

Davey

 

发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 tjw ietf
发送时间: 2017年9月6日 3:26
收件人: dnsop
主题: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

 

August is over and my self-imposed holiday is over, so it's time to get busy 
again. We have this document marked as a candidate for adoption.  

 

This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale

 

The draft is available here:

https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/

 

Please review this draft to see if you think it is suitable for adoption by 
DNSOP, and comments to the list, clearly stating your view.

 

Please also indicate if you are willing to contribute text, review, etc.

 

*If You have already stated your position for or against adoption, we are 
counting those so you do not need to repeat yourself. *

 

This call for adoption ends: 19 September 2017

 

Thanks,

tim wicinski

DNSOP co-chair

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