A quick status from the ISE:
draft-makarenko-gost2012-dnssec was formally submitted to me for
consideration as an independent RFC in May of this year. Before I make
a publication decision, there are a number of issues that need to be
addressed:
* What to do about RFC 5933? The original
Chairs,
Can we get some follow-up on this?
Thanks,
Eliot
On 13.01.23 16:56, Suzanne Woolf wrote:
Colleagues,
This WGLC is closed, with many thanks to everyone who commented.
The chairs and editors are reviewing the comments and will summarize
in the next few days.
Suzanne, for the
On 15.12.22 03:51, Paul Wouters wrote:
I don't interpret it as "the person responsible for fixing the
conflict". I think if one opts to use a name under .alt, one has to
engineer in how to deal with conflicts in that namespace. It is a
fundamental feature/bug of it.
That is true with *any*
We're off in the woods again. Let's keep these two principles in mind:
* The DNS resolution mechanisms are not expected to resolve, let alone
secure names ending in .ALT.
* How other resolution mechanisms secure names is their affair.
Therefore, any collisions that occur within .ALT are
I think the point here is that collisions within the alt name space are
beyond the scope of this document. Perhaps that's what should be said.
Eliot
On 14.12.22 11:08, Martin Schanzenbach wrote:
Hi Paul,
the draft lgtm. But, the passage regarding collisions because of
the missing registry
As mentioned in the dnsop meeting the proposed change would be to remove
the following sentences in Section 2:
OLD:
Alternative namespaces should differentiate themselves from other
alternative namespaces by choosing a name and using it in the label
position just before the .alt
Hi Ben and Wes,
On 21.10.22 20:45, Ben Schwartz wrote:
Rather than placing "alt" in the TLD position, I think it might be
better as a scheme modifier: https+alt://... This is a common
pattern for modifications to URI schemes (c.f. git+ssh://), and
informs the software that this URI is
On 23.10.22 05:40, John Levine wrote:
It appears that Eliot Lear said:
As a matter of practicality, a registry surely will be form. It is
simply a matter of whether the IANA will host it. If the IANA does not
host it, then by shifting it elsewhere this group is actually weakening
the IANA
Not to the content, but a note I sent earlier was sent from the wrong
address (as ISE). The content is below, and should have been sent from
my personal address (this one). My apologies for any confusion.
Eliot
I'm with Dave on this. There is nothing wrong with telling endpoints,
“Don't
I'm with Dave on this. There is nothing wrong with telling endpoints,
“Don't transmit queries for .ALT." That is indeed the whole point.
Paul, you're right: we can't stop applications from not doing this, but
we can tell them what Good looks like.
Eliot
On 21.10.22 23:39, David Conrad
On 20.10.22 21:13, Andrew Sullivan wrote:
Hi Eliot,
Still employed and still not speaking for them, I have a question:
On Thu, Oct 20, 2022 at 10:15:22AM +0200, Eliot Lear wrote:
As a matter of practicality, a registry surely will be form.
What evidence do you have for this assertion
Joe,
On 20.10.22 14:44, Joe Abley wrote:
To be clear, Eliot, you're not suggesting that these topics shouldn't be
discussed here, right?
It's a working group mailing list. Of course things can be discussed
here. My issue is that we are suffering from that lack of high bandwidth.
Eliot
Hi Jim,
On 20.10.22 14:14, Jim Reid wrote:
IMO, it doesn’t say that at all Eliot. A fairer PoV here would be when the IETF
gets handed non-IETF problems, it keeps well away (perhaps after a discussion
of the merits and/or scope of that problem).
As I wrote, we should discuss this in London,
Hi Vittorio
On 20.10.22 13:19, Vittorio Bertola wrote:
But IANA is not the registry for everything under the sun, it is the registry
for things that fall under the purview of the IETF and are part of IETF
standards. If we agree that names under .alt do not belong to and at the IETF,
then it
Hi,
First, I would like us to continue to consult on the registry matter at
least through the London IETF, and would ask the chairs for some time in
London for this purpose. I would also be available for side meetings
with any interested party, before or during the IETF. If people would
On 17.10.22 17:16, Paul Wouters wrote:
But does the IETF, when running a FCFS registry, want to take the legal
liability of your adjudicating?
Again, Paul, if you want to ask counsel for advice and have them provide
it here, great. Otherwise we end up Internet-lawyering, which is also
Hi Vittorio,
On 17.10.22 12:37, Vittorio Bertola wrote:
Well, I'm just waiting for the request to register amazon.alt.
(or xxx.alt, or ru[ssia].alt, or .alt, which some people
will do just for fun)
Unless, of course, you mean that the ISE will adjudicate trademarks, define which strings
are
Hi Paul!
Good conversation! I hope we can discuss some of this "in person"
(whatever that means these days) at IETF 115.
On 17.10.22 04:20, Paul Wouters wrote:
On Sun, 16 Oct 2022, Suzanne Woolf wrote:
1. As far as I can tell, this draft does not comply with RFC 6761.
This is a problem
Hiya!
Thanks to Suzanne and the chairs for moving things forward. On this point:
On 16.10.22 17:22, Warren Kumari wrote:
2. Having the IETF maintain a registry of pseudo-SLDs concerns me
on the basis that having the IETF “recognize” (if only by
recording) such pseudo-delegations
On 24.08.22 16:13, Joe Abley wrote:
Hi Peter,
So the question is not whether to allow mixed capitalisation; the question is
why we would intentionally change a fundamental expectation of domain names to
accommodate names and resolution protocols that we largely don't have any
requirements
Hi George,
I could see the value in reserving dns.alt, and the potential mischief
that could ensue by not doing so.
Eliot
OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
Hi Ben,
On 18.08.22 21:11, Ben Schwartz wrote:
What you are describing does not resemble draft-ietf-dnsop-alt-tld,
which would define the "alt" SUDN. That document says:
There is no IANA
registry for names under the ALT TLD - it is an unmanaged namespace,
and developers are
On 17.08.22 16:20, Paul Hoffman wrote:
The discussion with the Independent Submissions Editor appears to be about
whether they are interested in using a TLD that would different TLD or
pseudo-TLD in order to make their naming system more stable.
The authors of draft-schanzen-gns have shown
On 15.08.22 22:22, Paul Wouters wrote:
Schanzenbach, Martin wrote on 2022-08-15 11:49:
...
So, from my authors hat, I would appreciate FCFS; ideally also
existing
RFC/Other Specification + Implementation(s) for a registration in the
registry.
"existing RFC" means all alternative name
On 15.08.22 20:25, Ray Bellis wrote:
Someone also gets to solve the problem of how you get a CA/Browser Forum
Approved TLS cert for any system not accessible via "normal" DNS...
Yes, but not us.
Eliot
___
DNSOP mailing list
DNSOP@ietf.org
Hi,
On 15.08.22 16:11, David Conrad wrote:
My impression is that there'd be maybe an order of magnitude fewer clients.
This is irrelevant.
We have no idea whether GNS will take off in popularity or fade away into
non-existence. Given the way "configuration is forever”, any partitioning of
Paul,
On 14.08.22 16:57, Paul Wouters wrote:
We can have all the clever mappings for DNS to support alternative backend
systems, but in the end the real issue is that “issued names” in the DNS world
won’t map to alternative owners. The only way to guarantee that is to carve out
some strings.
Hi Joe, Dave, Christian, John, George, and others,
Thank you for taking the volume down a notch. It is much appreciated.
The ISE is looking for a way to have the work of the GNS published such
that I am comfortable that if it achieves wild success (RFC 5218), its
use is reasonably safe. I
Dave,
To answer the question, “What is the ISE process?”:
On 04.08.22 21:28, David Conrad wrote:
Martin,
[...]
I see 4 options:
1) Wait for ICANN to fix their processes
2) Wait for the IETF to figure out whether/how to reopen the “Special Use
Domains” registry
3) Try to bypass (1) and/or
On 02.08.22 10:35, Joe Abley wrote:
Had I wanted to do so, I would not have approached dnsop in the first place.
Had you wanted to which? I'm confused.
I came to this group because of concerns that Warren raised, and because
the draft sits before me. I have reviewed what discussion I
Aaaagain
On 02.08.22 09:56, Joe Abley wrote:
If the position of the ISE is to ignore the prior discussion and publish one
set of opinions regardless then perhaps it would be more straightforward just
to say so.
Had I wanted to do so, I would not have approached dnsop in the first
Paul:
It is not the ISE that is ignoring RFC 6761, but this group. 6761
envisioned this precise case. For whatever reason, that document didn't
take the next step and actually reserve a TLD. Sometimes it is
reasonable to do things incrementally. But what is not reasonable to
expect
Hello from your friendly neighborhood independent submissions editor.
It is indeed the case that draft-schanzen-gns is in conflict review. It
is also the case that Warren and I have been discussing that review.
Obviously there are some concerns. On the one hand, we need to find a
way for
+1. I think it looks good.
One very minor comment (more a question): if I read between the lines, it seems
that some thought went into the use of the term “name space” in Section 3.1
regarding there not being a zone cut for ns.arpa (not that it’s anyone’s
business, I suppose). Would it be
On 25 Mar 2019, at 10:25, Stephen Farrell wrote:
> I see a problem with the above argument. DNS means nothing to
> most people, so I can't see how they can ever make the informed
> decision you mention.
I view that as a research question (I don’t accept your assertion, but neither
can I
Hi,
> On 24 Mar 2019, at 23:25, Paul Wouters wrote:
>
>> The blocking of DoT to a given provider should be interpreted as an explicit
>> policy. Users should be informed
>> that they may, and very likely will, be violating someone’s policy, if they
>> choose to use DoH in that
>>
Hi Wes,
On 22 Mar 2019, at 00:21, Wes Hardaker wrote:
>
> If DNS privacy is a goal,
It is a goal. It is not the only goal. There is a tussle here. Let’s
recognize that.
Eliot___
DNSOP mailing list
DNSOP@ietf.org
Hi Christian,
> On 19 Mar 2019, at 18:37, Christian Huitema wrote:
>
>
>
> On 3/19/2019 12:50 AM, Eliot Lear wrote:
>>> On 19 Mar 2019, at 01:50, Matthew Pounsett >> <mailto:m...@conundrum.com>> wrote:
>>>
>>> Somewhere up-thre
> On 19 Mar 2019, at 14:10, Ted Lemon wrote:
>
> On Mar 19, 2019, at 3:50 AM, Eliot Lear <mailto:l...@cisco.com>> wrote:
>> It might also be possible to whitelist ANSWERs into iptables. I wrote the
>> code for that for a dnscap plugin some year
Matthew
> On 19 Mar 2019, at 01:50, Matthew Pounsett wrote:
>
> Somewhere up-thread it was suggested that there are other reasonable steps
> that a network/security operator can take to maintain the controls over
> resolution that we have today, but so far I haven't seen them enumerated
>
Gentlemen,
This conversation has gone to the zoo. What is or is not political doesn’t
matter at this stage in the game, and neither is arguing over rights over bits.
If people want to do that I suggest doing so in the HRPC WG and with a draft
in hand. Flaming back and forth without an
Hi Tiru,
> On 12 Mar 2019, at 16:31, Konda, Tirumaleswar Reddy
> wrote:
>
> MDM may or may not be acceptable even in Enterprise networks. For instance,
> today network security services are using ML techniques to identify malware
> flows without acting as a TLS proxy. MDM is also not an
e willing
partners, I think that would be a great avenue to tread down.
Eliot
>
> Alister
>
> On 12/03/2019, 05:43, "dns-privacy on behalf of Konda, Tirumaleswar Reddy"
> tirumaleswarreddy_ko...@mcafee.com> wrote:
>
>> -Original Message-
>>
Warren,
I would suggest that you wait on creating a new list.
I think Stephane was proposing an *in person* meeting, using the
104sidemeetings Wiki, and I’d like to see that happen first. That also gives
time for the dust from the release of these new drafts to settle a bit, so that
the
Hi Paul,
> On 11 Mar 2019, at 19:12, Paul Vixie wrote:
>
>
>
> nalini elkins wrote on 2019-03-11 10:26:
>> Tiru,
>> Thanks for your comments.
>> > Enterprise networks are already able to block DoH services,
> i wonder if everyone here knows that TLS 1.3 and encrypted headers is going
> to
Hi David,
On 7/20/15 6:06 AM, David Cake wrote:
As someone with moderate experience in both DNS and web server
configuration, FWIW I found the meaning relatively obvious. The notion
that HTTP Host headers might be used to change web server response
independent of name resolution (e.g. that
I have no particular objection to the concept here, but I do have a
question about one sentence in the draft. Section 1 states:
Like Top-Level Domain Names, .onion addresses can have an arbitrary
number of subdomain components. This information is not meaningful
to the Tor protocol,
Hi Richard,
Thanks for the explanation. Please see below.
On 7/17/15 4:38 PM, Richard Barnes wrote:
On Fri, Jul 17, 2015 at 4:20 PM, Eliot Lear l...@cisco.com wrote:
I have no particular objection to the concept here, but I do have a
question about one sentence in the draft. Section 1
Paul,
This seems like a fine and modular approach that doesn't boil the ocean.
Eliot
On 7/5/14, 5:04 AM, Paul Vixie wrote:
i've now seen a number of proposals reaction to the snowden
disclosures, seeking channel encryption for dns transactions. i have
some thoughts on the matter which are
Ted,
What I like about this message is that you have demonstrated the
*potential* severability of these issues. Things are set up as they are
for a matter of scaling. Clearly it ain't perfect, and as one of my
mentors would say, that represents an opportunity. It's also pretty
clear that we
50 matches
Mail list logo
