Greetings. The WG chairs have added me as a co-author for
draft-ietf-dnsop-resolver-priming to help drive the work to completion.
As you just saw, there is a new version of the draft. Looking over the
earlier discussions over the years, we have greatly simplified the
document:
- Advice on how
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group
of the IETF.
Title : Initializing a DNS Resolver with Priming Queries
Authors : Peter Koch
Is Dave's registry proposal documented in written form anywhere? Some
planned alignment with that (assuming it has consensus) seems like a good
idea.
It's draft-crocker-dns-attrleaf-07.
I've been pinging Dave about working on it but haven't heard back.
Regards,
John Levine, jo...@taugh.com, Ta
I think we're in violent agreement -- that's why I want to put _client
into the service registry so it doesn't further mess up the list of L3
protocols.
Right, except that I want that service registry to only include the
most-significant-label.
Um, right, a client label is _._client._
Yes, the
On 1/13/16 3:22 PM, Shumon Huque wrote:
On Wed, Jan 13, 2016 at 3:05 PM, Ray Bellis mailto:r...@bellis.me.uk>> wrote:
On 13/01/2016 20:01, John Levine wrote:
I suppose, but doing it as _._client._ puts it
in > the existing service namespace. It's not a huge
diff
On Wed, Jan 13, 2016 at 3:05 PM, Ray Bellis wrote:
>
>
> On 13/01/2016 20:01, John Levine wrote:
>
>> I suppose, but doing it as _._client._ puts it in > the
>> existing service namespace. It's not a huge difference, and it's
>>
> > been clear for a while that if we do Dave's registry, part of w
On 13/01/2016 20:09, John Levine wrote:
When Dave and I last discussed that draft in any detail (back in
Orlando!) my proposal was that it should for SRV-based services the only
entries should be _tcp and _udp (or other L3 protocols), and that
anything that exists in the IANA port registry (wit
>When Dave and I last discussed that draft in any detail (back in
>Orlando!) my proposal was that it should for SRV-based services the only
>entries should be _tcp and _udp (or other L3 protocols), and that
>anything that exists in the IANA port registry (with the prepended
>underscore) would b
On 13/01/2016 20:01, John Levine wrote:
I suppose, but doing it as _._client._ puts it in > the existing service namespace. It's not a huge difference, and it's
> been clear for a while that if we do Dave's registry, part of what >
it includes will be a list of the underscore names that are p
>> Here's a concrete example. My laptop is named mypc.example.com. Because
>> I am a forward thinking guy, I send a DANE-verified client cert whenever
>> I connect for submission, POP, IMAP, or jabber, and because I'm still
>> lazy, I use the same certificate for all of them. The DNS records to
>
On 1/13/16 12:23 PM, 神明達哉 wrote:
With this understanding I have two followup questions:
- If a document is marked as "Updates ", does it
automatically mean its status should be Standards Track, too?
It would go in as "Proposed Standard"
tim
__
On 13/01/2016 17:12, John R Levine wrote:
> Here's a concrete example. My laptop is named mypc.example.com. Because
> I am a forward thinking guy, I send a DANE-verified client cert whenever
> I connect for submission, POP, IMAP, or jabber, and because I'm still
> lazy, I use the same certifica
At Wed, 13 Jan 2016 10:13:42 +,
Tony Finch wrote:
> > - I wonder why its intended status is standards track. It generally
> > just talks about operational techniques rather than describe some
> > new protocol, so a BCP seems to be more appropriate (in fact RFC2317
> > is a BCP). Perha
Yet the IANA registry seems to have a provision for registering
client service names (i.e. application specific identifiers used by
clients).
It might seem that way if we didn't look too closely. All of the service
names that contain words like "client" have reserved port numbers so they
are
On 1/13/16, 8:30 AM, "Mankin, Allison" wrote:
>I see that your Discuss is still in place. Could you remove it now
Cleared.
Alvaro.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Wed, Jan 13, 2016 at 5:24 AM, Tony Finch wrote:
> John Levine wrote:
> >
> > What's peculiar is the names. The previous proposal was to look up a
> > TLSA at _smtp.outbound.example.com, then somone noted that _smtp is
> > for servers, so they want to look up the newly invented name
> > _smtp
Alvaro,
I see that your Discuss is still in place. Could you remove it now since I
think we have no further action on this? (Based on the discussion from last
week).
Thank you and Joel and Brian.
Allison
Sent from my iPhone
> On Jan 7, 2016, at 15:25, joel jaeggli wrote:
>
> -BEGIN PGP
On 1/7/16 2:19 PM, Alvaro Retana (aretana) wrote:
On 1/6/16, 11:55 AM, "Mankin, Allison" wrote:
Allison:
Hi!
I think you've found an XML editing bug on our part.
No, actually the problem is not in the document, but in how the "Intended
RFC Status" was set on the datatracker page:
https:/
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group
of the IETF.
Title : Classless IN-ADDR.ARPA delegation and dynamic reverse
DNS UPDATE
Author : Tony Fi
John Levine wrote:
>
> What's peculiar is the names. The previous proposal was to look up a
> TLSA at _smtp.outbound.example.com, then somone noted that _smtp is
> for servers, so they want to look up the newly invented name
> _smtp-client.outbound.example.com. If you have a client for some
> ot
神明達哉 wrote:
>
> - I wonder why its intended status is standards track. It generally
> just talks about operational techniques rather than describe some
> new protocol, so a BCP seems to be more appropriate (in fact RFC2317
> is a BCP). Perhaps it's because this document will "update" RFC21
George,
I think you are correct in highlighting the role vs. protocol
difference.
Looking at it like that, John's idea makes sense, although probably it
should be inverted, so:
_client._smtp._tcp.outbound.example.com
This way case, it will happily support protocols that are not
client/server (
22 matches
Mail list logo
