On Tue, Sep 13, 2011 at 10:20 AM, Joe Touch to...@isi.edu wrote:
On Sep 12, 2011, at 5:56 PM, Nico Williams n...@cryptonector.com wrote:
On Mon, Sep 12, 2011 at 5:30 PM, Joe Touch to...@isi.edu wrote:
On 9/12/2011 2:43 PM, Nico Williams wrote:
I meant existence as in how it's used. I don't
On Sep 12, 2011, at 1:00 PM, Robert Thurlow wrote:
Joe Touch wrote:
Either this is an nfs service or it isn't.
If it is, then it should be using _nfs._tcp.example.com, etc. If it isn't,
then:
a) a new service name is required
which then *requires*
b) a new port number be
Hi, Nico,
On Sep 12, 2011, at 5:56 PM, Nico Williams n...@cryptonector.com wrote:
On Mon, Sep 12, 2011 at 5:30 PM, Joe Touch to...@isi.edu wrote:
On 9/12/2011 2:43 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 3:57 PM, Joe Touchto...@isi.edu wrote:
My claim is that:
SRVs
On Sep 13, 2011, at 7:38 AM, Cullen Jennings flu...@cisco.com wrote:
Hi Rob,
Few inputs you can take with a huge grain of salt
1) some people on this list have suggest TXT records. Keep in mind this is
totally the wrong group to tell you how to use DNS. Last time I discussed TXT
I disagree w.r.t. your comments regarding the use of SRV RRs for NFSv4
domain root location.
I think it would be a mistake to use TXT RRs to encode what SRV RR
RDATA does just fine just to get around whatever we think the rules
are or ought to be for using SRV RRs.
However, I'll note that the
On Mon, Sep 12, 2011 at 12:39 PM, Joe Touch to...@isi.edu wrote:
On 9/12/2011 8:03 AM, Nico Williams wrote:
You're locating the NFS service. You're using that to setup a domainroot.
The former is a DNS SRV issue. The latter is an endhost configuration issue.
No. We do not normally locate the
Joe Touch wrote:
Either this is an nfs service or it isn't.
If it is, then it should be using _nfs._tcp.example.com, etc. If it
isn't, then:
a) a new service name is required
which then *requires*
b) a new port number be assigned
This doesn't show any real understanding of what
On Mon, Sep 12, 2011 at 2:56 PM, Joe Touch to...@isi.edu wrote:
On 9/12/2011 12:00 PM, Robert Thurlow wrote:
Joe Touch wrote:
We don't want to enumerate all NFS servers in a domain.
That's what SRV records do. If that's not what you want, you should consider
defining a new RR type.
No
On Mon, Sep 12, 2011 at 3:08 PM, Joe Touch to...@isi.edu wrote:
On 9/12/2011 1:00 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 2:56 PM, Joe Touchto...@isi.edu wrote:
On 9/12/2011 12:00 PM, Robert Thurlow wrote:
No We don't want to enumerate *all* NFSv4 servers in a domain. We
want
On Mon, Sep 12, 2011 at 3:15 PM, Keith Moore mo...@network-heretics.com wrote:
On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:
I think RFC 2782 inappropriately specified SRV RRs by defining both the label
syntax and the RDATA syntax at the same time.
I think we can all agree that RFC2782 is
On Mon, Sep 12, 2011 at 3:57 PM, Joe Touch to...@isi.edu wrote:
My claim is that:
SRVs represent services as they are currently assigned by IANA
a new RR could be useful for things that aren't sufficiently
expressible in the IANA service/port registry
Existence proofs
; tsv-
d...@ietf.org; Keith Moore
Subject: Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-
namespace
On 9/12/2011 2:43 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 3:57 PM, Joe Touchto...@isi.edu wrote:
My claim is that:
SRVs represent services
Moore
Subject: Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-
namespace
On 9/12/2011 3:33 PM, Spencer Shepler wrote:
...
The existence proof is that many SRV names have defined TXT fields,
including the following:
ftp
sftp-ssh
ssh
telnet
http
On Mon, Sep 12, 2011 at 5:30 PM, Joe Touch to...@isi.edu wrote:
On 9/12/2011 2:43 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 3:57 PM, Joe Touchto...@isi.edu wrote:
My claim is that:
SRVs represent services as they are currently assigned by IANA
a new RR could be
Hi, Nico,
On 9/12/2011 8:03 AM, Nico Williams wrote:
I disagree w.r.t. your comments regarding the use of SRV RRs for NFSv4
domain root location.
I think it would be a mistake to use TXT RRs to encode what SRV RR
RDATA does just fine just to get around whatever we think the rules
are or ought
Hi, Nico,
On 9/12/2011 10:49 AM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 12:39 PM, Joe Touchto...@isi.edu wrote:
On 9/12/2011 8:03 AM, Nico Williams wrote:
You're locating the NFS service. You're using that to setup a domainroot.
The former is a DNS SRV issue. The latter is an endhost
On Sep 12, 2011, at 2:31 PM, Joe Touch wrote:
The issue is that if this document wants to go outside the spec, *it* needs
to update RFC2782 - and survive the discussion that will incur.
Well, in a pedantic sense I'm sure that's true. But it doesn't need to update
RFC2782 as it pertains to
On 9/12/2011 11:46 AM, Keith Moore wrote:
On Sep 12, 2011, at 2:31 PM, Joe Touch wrote:
The issue is that if this document wants to go outside the spec, *it*
needs to update RFC2782 - and survive the discussion that will incur.
Well, in a pedantic sense I'm sure that's true. But it doesn't
Hi, Robert,
On 9/12/2011 12:00 PM, Robert Thurlow wrote:
Joe Touch wrote:
Either this is an nfs service or it isn't.
If it is, then it should be using _nfs._tcp.example.com, etc. If it
isn't, then:
a) a new service name is required
which then *requires*
b) a new port number be assigned
Hi, Nico,
On 9/12/2011 1:00 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 2:56 PM, Joe Touchto...@isi.edu wrote:
On 9/12/2011 12:00 PM, Robert Thurlow wrote:
Joe Touch wrote:
We don't want to enumerate all NFS servers in a domain.
That's what SRV records do. If that's not what you want,
On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:
On 9/12/2011 11:46 AM, Keith Moore wrote:
On Sep 12, 2011, at 2:31 PM, Joe Touch wrote:
The issue is that if this document wants to go outside the spec, *it*
needs to update RFC2782 - and survive the discussion that will incur.
Well, in a
On 9/12/2011 1:17 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 3:08 PM, Joe Touchto...@isi.edu wrote:
On 9/12/2011 1:00 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 2:56 PM, Joe Touchto...@isi.eduwrote:
On 9/12/2011 12:00 PM, Robert Thurlow wrote:
No We don't want to
On Sep 12, 2011, at 4:23 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 3:15 PM, Keith Moore mo...@network-heretics.com
wrote:
On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:
I think RFC 2782 inappropriately specified SRV RRs by defining both the
label syntax and the RDATA syntax at the
On 9/12/2011 1:20 PM, Keith Moore wrote:
On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:
On 9/12/2011 11:46 AM, Keith Moore wrote:
On Sep 12, 2011, at 2:31 PM, Joe Touch wrote:
The issue is that if this document wants to go outside the
spec, *it* needs to update RFC2782 - and survive the
On 9/12/2011 1:23 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 3:15 PM, Keith Mooremo...@network-heretics.com wrote:
On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:
I think RFC 2782 inappropriately specified SRV RRs by defining both the label
syntax and the RDATA syntax at the same time.
On 9/12/2011 2:43 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 3:57 PM, Joe Touchto...@isi.edu wrote:
My claim is that:
SRVs represent services as they are currently assigned by IANA
a new RR could be useful for things that aren't sufficiently
expressible in the
On 9/12/2011 3:33 PM, Spencer Shepler wrote:
...
The existence proof is that many SRV names have defined TXT fields,
including the following:
ftp
sftp-ssh
ssh
telnet
http
nfs (already defines path to the mount point)
Interesting; do you have a
27 matches
Mail list logo
