On 14/11/2023 00:56, John R Levine wrote:
Once again, I really wish people would stop blaming the victim.
That's not useful language. DNSBLs fulfill a purpose but are not
victims. People whose privacy is exposed via network traffic are
not correctly described as victims but are nonetheless
Hiya,
Ben's mail prompted me to have a quick read of the draft and
I fully agree when he says:
On 18/04/2023 12:11, Benjamin Schwartz wrote:
I think this registry opens a terrible can of
worms that the IETF can and should avoid.
Cheers,
S.
OpenPGP_0xE4D8E9F997A833DD.asc
Description:
Hiya,
This is good enough, so should proceed.
In terms of substantive comments, I can only think of
arguments that have already been thrashed out so won't
raise any of 'em.
A suggestion/nit which I'm fine to see ignored: the
text in section 4 (Privacy Considerations) isn't that
clear and
Hiya,
On 21/10/2022 22:25, Paul Vixie wrote:
Joe Abley wrote on 2022-10-21 13:51:
On Oct 21, 2022, at 12:52, Paul Vixie
wrote:
it's a registry of carve-outs for use inside DNS, which happens to
facilitate client development by giving agents such as browser
plugins a clear activation
Hiya,
On 23/08/2022 23:52, Martin Thomson wrote:
On Wed, Aug 24, 2022, at 08:30, Stephen Farrell wrote:
Currently chromium and firefox disagree on whether ECH is setup
correctly for one of my test pages
I'm fairly confident that that is a bug on the Firefox end. The
person looking
Hiya,
On 23/08/2022 22:51, Brian Dickson wrote:
The differences in interpretation, and the client behavior under one of
those interpretations, are the problem.
I've seen a different client-behaviour issue related to ports
other than 443 and ECH, but I'm unsure if that's a problem
with this
Hiya,
On 20/08/2022 01:55, Warren Kumari wrote:
On Fri, Aug 19, 2022 at 5:46 PM, Stephen Farrell
wrote:
Hiya,
On 19/08/2022 20:43, Warren Kumari wrote:
So, it is perfectly acceptable (in my view) for it to have:
Reference Name
-
a-cool-document foo.alt
Hiya,
On 19/08/2022 20:43, Warren Kumari wrote:
So, it is perfectly acceptable (in my view) for it to have:
ReferenceName
-
a-cool-document foo.alt
another-documentfoo.alt
yet-another-doc bar.alt
I agree that such duplicate
Hiya,
On 19/08/2022 14:35, Paul Wouters wrote:
Okay, so I understood that you want to run a yellow pages for non-DNS
domains at IANA.
FWIW, that doesn't describe where I've so far
landed on this. It omits the requirement that
there be an RFC for each entry. That IMO does
mean such a
On 18/08/2022 21:11, Eliot Lear wrote:
I could see the value in reserving dns.alt, and the potential mischief
that could ensue by not doing so.
Ugh. Were that done I'd be worried abut the effect
on the web PKI of creating sorta-synonyms like that.
S.
OpenPGP_0x5AB2FAF17B172BEA.asc
Hiya,
On 18/08/2022 20:26, Paul Vixie wrote:
i don't think the .ALT draft is going to move forward without such
change, so the distinction will be between .ALT as proposed and .ALT as
evolved, not between .ALT and some other SUDN.
I think I agree. But to check: are we saying that the .alt
Hiya,
On 16/08/2022 03:01, John Levine wrote:
Right. If it's FCFS, I am sure I am not the only person who will be
waiting at the gate with thousands of preemptive registrations.
Why?
I honestly don't know so that's not a rhetorical question.
Ta,
S.
OpenPGP_0x5AB2FAF17B172BEA.asc
Hiya,
On 16/08/2022 00:22, Paul Wouters wrote:
it’s a whole new gold rush.
I don't get that. The thought experiment(*) is a putative
.alt setup with FCFS registration for 2LD equivalents and
where recursives and all DNS servers are expected to barf
on queries for such names one way or
On 15/08/2022 06:09, Christian Huitema wrote:
.onion is barely visible, with 0.01% of root traffic.
So that should be significant for the disposition
of the GNU stuff, shouldn't it? My impression is
that there'd be maybe an order of magnitude fewer
clients.
S.
Hiya,
On 15/08/2022 02:07, Mark Andrews wrote:
Most users of Kerberos use the DNS namespace as that authority.
I wonder about that. My experience is that most admins (not
quite typical users:-) setup some kerberos realms that are
named after DNS domains, but also have legacy and non-legacy
On 15/08/2022 00:58, David Conrad wrote:
On Aug 14, 2022, at 3:54 PM, Stephen Farrell
wrote:
On 14/08/2022 23:37, David Conrad wrote:
It seems to me that “the correct handling” of how an operating
system or an application distinguishes what protocol to use for
domain name lookup (other than
On 14/08/2022 23:37, David Conrad wrote:
It seems to me that “the correct handling” of how an operating system
or an application distinguishes what protocol to use for domain name
lookup (other than DNS) is outside of the bailiwick of DNSOP or the
IETF.
Disagree in part. I think it is
On 14/08/2022 19:32, David Conrad wrote:
Stephen,
On Aug 13, 2022, at 7:14 PM, Stephen Farrell
wrote:
But, there are also what ought be almost purely technical parts,
Sorry to be dense, but what exactly are those technical parts,
specifically those that are relevant to DNSOP
On 14/08/2022 15:57, Paul Wouters wrote:
On Aug 14, 2022, at 09:16, Stephen Farrell
wrote:
but otherwise stuff works fine even if it can sometimes be
confusing as to how kerberos realms and DNS domains do or don't map
to one another.
But that’s because foo.example in DNS maps
. But by
providing those that do care with options, we get more friends and
less foes.
Rubens
On 13 Aug 2022, at 23:27, Stephen Farrell
wrote:
Signed PGP part
So I think this discussion might benefit from also remembering that
we have a decades-long and widely deployed history of IETF standard
So I think this discussion might benefit from also
remembering that we have a decades-long and widely
deployed history of IETF standard name forms that
use the same name syntax as domain names that may
or may not be related to names used in the DNS.
Kerberos [1] does exactly that.
And the sky
On 14/08/2022 02:55, David Conrad wrote:
As John Levine points out, this isn’t a technology issue: it is
social/politica/economic/bureaucratic
I believe the above statement is incorrect in referring to
"this" issue in the singular. There is more than one thing
in play here and ignoring all
Hiya,
On 13/08/2022 23:32, Paul Vixie wrote:
warren's .ALT proposal can begin to undo that harm. internet standards
should describe roads not walls. i am no fan of blockchain naming, but
i'd like those
systems to reach the market rather than be prevented from doing so.
A strong +1 to the
Hiya,
I've scanned the draft and read the thread.
AFAICS the draft does not ask for a new 6761 (*) special use
name, so ISTM speculation as to what the authors or their
pals would be better off doing is moot. (I.e. there's no
point telling 'em to go away and come back asking to use
gnu.alt or
Hi all,
At IETF 113 a draft of mine [1] was presented (slides [2])
at the dispatch session. Part of the upshot there was to
check with dnsop if people felt asking for adoption here
would be the right plan for this draft.
The draft is concerned with (re-)publishing ECHConfigList
values in
On 10/03/2022 19:04, Paul Wouters wrote:
Sounds good to me.
Something analogous to bcp195 could be a good plan, esp
as signature algorithms, rsa key sizes and maybe ksk/zsk
handling change over time.
Not sure if it'd be better part of such a document but also
be no harm to try document
Hi Stephane,
On 19/01/2022 08:36, Stephane Bortzmeyer wrote:
Does anyone know a service/software to check the consistency between
SVCB/HTTPS DNS records and the Web site? Such as testing the various
alpn, the various IP addresses hints, the aliases, etc. (It seems
ssllabs.com don't do it yet.)
Hiya,
Without commenting on the rest of the discussion (though
I do agree with those who made the point that optimising
for those writing zone files here is better than for
those parsing zone files)...
On 10/05/2021 17:56, Ben Schwartz wrote:
It would also require a dramatic rewrite of a
Hiya,
On 06/04/2021 21:00, Ben Schwartz wrote:
Here's a proposal to add an example as you suggest:
https://github.com/MikeBishop/dns-alt-svc/pull/311/files
LGTM, thanks,
S.
On Sat, Apr 3, 2021 at 2:44 PM Stephen Farrell
wrote:
On 03/04/2021 18:07, Ben Schwartz wrote:
It's supposed
On 03/04/2021 18:07, Ben Schwartz wrote:
It's supposed to be _8410._https.foo.example.com, qtype=65
Thanks. That'd work for me. Probably no harm to add an
example or explicit statement to that effect.
Cheers,
S.
On Sat, Apr 3, 2021 at 12:55 PM Stephen Farrell
wrote:
Hiya,
I had
Hiya,
I had a quick look at the draft I'm not sure if I know
for sure what qname/qtype is supposed to be used for
e.g. https://foo.eample.com:8410/ - can anyone say off
the top of their head?
The options I can imagine are:
qname: foo.example.com, qytpe: type65
qname:
Hiya,
On 04/01/2021 16:05, Paul Wouters wrote:
While asking is fair, you would also have to define what you
do based on the outcome of that ask. You left that out,
I don't think I did omit that. My stated reason to ask was
to help me figure out what I think about the draft named in
the
Hiya,
On 04/01/2021 14:23, Paul Wouters wrote:
On Mon, 4 Jan 2021, Stephen Farrell wrote:
WRT GOST, we're not really talking about an algorithm but
rather a national crypto standards scheme that selects sets
of algorithms. For such things, whether from Russia or the
US or anywhere, I think
Hiya,
On 04/01/2021 11:31, Vittorio Bertola wrote:
We could ask the proponents of new algorithms for information on
current or expected usage.
WRT GOST, we're not really talking about an algorithm but
rather a national crypto standards scheme that selects sets
of algorithms. For such
Hiya,
On 01/01/2021 17:58, Paul Hoffman wrote:
The WG has already adopted the revised GOST document as a WG item;
what you are proposing (if the current use is negligible) would be in
the opposite direction.
I wasn't "proposing" that, just posing it as a possible
option that might or might
Hiya,
I note that you didn't answer my question about actual use
of gost and guess that's because you don't have that data
to hand. I'm still interested in that if someone has info
because grounding this in reality seems likely better.
On 01/01/2021 16:38, Paul Hoffman wrote:
The status quo
Hiya,
On 31/12/2020 21:48, Eric Rescorla wrote:
1. Don't allocate a code point at all
2. Allocate the code point but in some manner that makes clear
we don't endorse it (effectively what TLS does for algorithms
like this)
3. Allocate the code point without comment
FWIW, I kind of
Hiya,
(I wouldn't put that much store on my specific response, but
since you asked...)
On 08/12/2020 01:23, Benjamin Kaduk wrote:
Hi Ondřej,
Thanks for this detailed writeup; it really helps bring clarity to the
current situation.
In light of the follow-ups from others, it seems that there
Hiya,
On 05/12/2020 14:58, Salz, Rich wrote:
There is a fair amount of academic study around SipHash, and while
everyone can make mistakes, its creators have a pretty good
reputation. I don't think we can say SipHash is unknown in the
industry.
The TLSWG made it a practice to ask CFRG to
Hiya,
On 02/12/2020 22:07, Willem Toorop wrote:
Op 02-12-2020 om 22:49 schreef Stephen Farrell:
Hiya,
On 02/12/2020 21:38, Willem Toorop wrote:
Op 02-12-2020 om 21:37 schreef Stephen Farrell:
ad 2) we need a value that’s synchronized well enough and monotonic.
I honestly don’t see
Hiya,
On 02/12/2020 21:38, Willem Toorop wrote:
Op 02-12-2020 om 21:37 schreef Stephen Farrell:
ad 2) we need a value that’s synchronized well enough and monotonic.
I honestly don’t see any value in using 64-bit value here. Using
unixtime has a value in itself, it’s a well-known
, nobody is going
to interpret it after it has been generated, and it’s wide enough to
prevent brute forcing.
So what happens after 2038? That's really not v. far in the
future any more.
Cheers,
S.
Cheers, Ondřej -- Ondřej Surý — ISC (He/Him)
On 2. 12. 2020, at 18:47, Stephen Farrell via
Reviewer: Stephen Farrell
Review result: Has Issues
I see two issues here worth checking:
1. I don't recall SipHash being used as a MAC in
any IETF standard before. We normally use HMAC,
even if truncated. Why make this change and was
that checked with e.g. CFRG? (And the URL given
Hiya,
On 10/03/2020 19:11, Paul Vixie wrote:
> On Tuesday, 10 March 2020 19:05:39 UTC Stephen Farrell wrote:
>> Paul,
>>
>> ...
>>
>> What's the difference between having a port number
>> as part of HTTPSSVC (or whatever we call it;-) in
>> the D
Paul,
On 10/03/2020 18:54, Paul Vixie wrote:
> the httpssvc "port" parameter leading
> a service operator to put something on an "alternative origin" whose port
> number will be broadly unrecognized by far end managed private networks,
> which
> would prevent flow-state creation, thus
Hiya,
Thanks for taking a read of the draft.
On 04/03/2020 04:55, Ben Schwartz wrote:
> I'm still not entirely clear on how this is supposed to work, which is why
> I would appreciate the worked example. It seems like, in addition to RDBD,
> your filter also needs some kind of
I think the better approach, if expressing relationships in DNS,
is likely to be to encode those down to rdbd-tags or similar. At
least, that's the approach we're espousing here.
Cheers,
S.
>
> On Tue, Oct 1, 2019, at 07:17, Stephen Farrell wrote:
>>
>> Hi all,
>>
>> A
Hiya,
On 07/10/2019 15:37, Tim Wicinski wrote:
> All
>
> We want to thank the authors for working on this. The chairs
> feel that part of the discussion around this document would be to
> resolve:
> - ANAME/HTTPSSVC possible overlaps
> - The RR Type Name (no one seems to be in love with
Hi all,
As per discussion at IETF 105, Alex and I did some more
work on the RDBD draft (lots of text edits and a bit of
prototyping) and have posted a new version. [1]
We'd be very interested in folks' opinions.
Thanks,
Stephen & Alex.
[1] https://tools.ietf.org/html/draft-brotman-rdbd-03
Hiya,
On 25/03/2019 09:13, Eliot Lear wrote:
> Putting aside legal language, but Brian’s basic notion is that the
> user can make an informed decision and the network can express its
> policies, with which the user can agree or not agree (and go
> elsewhere). Having the protocol elements to
Hiya,
On 22/03/2019 22:08, Puneet Sood wrote:
> As a core principle, Google Public DNS aims to provide a DNS resolver
> that respects our users’ privacy. Towards that goal, we aim to provide
> high quality implementations of various DNS transport mechanisms that
> our users can use to reach the
On 20/03/2019 05:46, Brian Dickson wrote:
> On Tue, Mar 19, 2019 at 8:36 PM Stephen Farrell
> wrote:
>
>>
>>
>> On 20/03/2019 03:17, Brian Dickson wrote:
>>
>>> - If a network operator has any policy that is enforceable, ONLY the
>>> techn
On 20/03/2019 03:17, Brian Dickson wrote:
> On Tue, Mar 19, 2019 at 6:42 PM Stephen Farrell
> wrote:
>
>>
>> Hiya,
>>
>> One individualistic data point on this sub-topic, and a real point:
>>
>> On 20/03/2019 01:13, Jared Mauch wro
Hiya,
One individualistic data point on this sub-topic, and a real point:
On 20/03/2019 01:13, Jared Mauch wrote:
> My impression is there are people who will not be satisfied until all traffic
> looks
> identical and you have zero way to protect your home,
I would be happier if my home
Hiya,
On 14/03/2019 14:41, Ralf Weber wrote:
> the DoH protocol caused some application providers to experiment with
> switching resolution per default away from OS and the local network provider
I wasn't aware that some application provider was doing this
as their default (assuming that's what
Hi,
On 14/03/2019 00:07, Michael Sinatra wrote:
> On 3/13/19 1:43 PM, Stephen Farrell wrote:
>>
>> (dropping dprive list at WG chair request)
>>
>> Hiya,
>>
>> On 13/03/2019 20:29, Brian Dickson wrote:
>>> The starting place for the conversatio
On 13/03/2019 21:06, Brian Dickson wrote:
> Things like DMCA and its ilk might raise the software to the
> level of "illegal" rather than just a contract violation by a user.
Whacking someone in the head with a fish could well be
illegal... but fish are not illegal:-) [1]
Similarly typing "dig
(dropping dprive list at WG chair request)
Hiya,
On 13/03/2019 20:29, Brian Dickson wrote:
> The starting place for the conversation needs to acknowledge this, and
> accommodate it. It is entirely possible that a DoH client that doesn't do a
> minimum level of getting user acknowledgement
Hiya,
On 13/03/2019 01:04, Paul Wouters wrote:
> RPZ allows filtering answers which would turn into BOGUS for
> DNSSEC validating clients.
Could well be my terminology was imprecise. What I recalled
from some discussion a year or more ago was that RPZ MUST NOT
change a DNSSEC-signed answer that
Hiya,
On 12/03/2019 22:51, Paul Vixie wrote:
> On Tuesday, 12 March 2019 21:38:44 UTC Stephen Farrell wrote:
>> On 12/03/2019 21:11, Paul Vixie wrote:
>>> ...
>>
>> There are reasons to want confidentiality for DNS queries
>> and answers, and access patterns
On 12/03/2019 21:11, Paul Vixie wrote:
> he's trying to achieve a political aim using technology.
Ok, now I think I understand and am pretty sure I disagree
with you there.
There are reasons to want confidentiality for DNS queries
and answers, and access patterns, for which the IETF has
Paul,
On 12/03/2019 20:51, Paul Vixie wrote:
> just as i've cautioned the RFC 8484 authors against imposing their anti-
> censorship views on my parental controls or corporate network policies, let
> me
> here caution you against imposing your (clearly) western liberal-democratic
> views on
thers, do pay attention to what NIST or CERT says.
> Just my 2 cents to try
> to find a long term solution to what has been a contentious and exhausting
> multi-year set of discussions
> for all involved and which seems set to rekindle with DoH.
>
> Nalini
>
> On Tue, Mar 12
(This distribution list is too scattered and diverse. Be
great if some AD or someone just picked one list for this.
In the meantime...)
On 11/03/2019 20:43, nalini elkins wrote:
> impact assessment that certain changes such as
> DoH and TLS1.3 will have on enterprises,
TLS1.3 will, I expect,
Hiya,
On 28/02/2019 02:03, John Levine wrote:
> Well, OK, if that's an issue you spread the names out like we did with
> VBR. If the primary is foo.com and the secondary is bar.org:
>
> bar.org._same.foo.com. SAME . ; yes, we're a primary for whatever name that
> was
>
> _same.bar.org. SAME
sh it out as we go.
On 27/02/2019 18:38, Ted Lemon wrote:
> On Feb 27, 2019, at 10:57 AM, Stephen Farrell
> wrote:
>> Yep. After both domains have DNSSEC, then this could all be
>> simpler. Before they do, there may be value in the sigs though see
>> John's simplificatio
Hiya,
On 27/02/2019 15:54, Paul Wouters wrote:
> How is this data being consumed by the enduser ?
Very good question. Sorry for what's likely a longer
answer than you want:-)
Alex and I chatted about that and I think ended up
figuring: a) there are many potential semantics that
could be
Hi Paul,
On 27/02/2019 15:48, Paul Wouters wrote:
> On Wed, 27 Feb 2019, Paul Wouters wrote:
>
>>> https://datatracker.ietf.org/doc/draft-brotman-rdbd/
>>
>> I've read the draft, and I have my usual complaints.
Thanks for taking a read!
> I scanned this document a bit too fast, with an eye
Hiya,
On 16/02/17 21:43, Wessels, Duane wrote:
>
> Hi Stephen,
>
>
>>
>> --
>>
>>
COMMENT:
>> --
>>
>>
>>
>>
- abstract: referring to section 1.1 from
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-edns-key-tag-04: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-dnssec-roadblock-avoidance-05: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however
Hi Wes,
On 05/08/16 22:18, Wes Hardaker wrote:
> "Stephen Farrell" <stephen.farr...@cs.tcd.ie> writes:
>
>> Why omit sha256 (in particular Alg = 8) from this? That
>> seems like a quite bad plan and *not* a BCP given our
>> current knowledge of ha
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-dnssec-roadblock-avoidance-04: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-edns-client-subnet-07: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however
Hi David,
All of those changes look good to me. Happy to clear the discuss
when you post -07.
Cheers,
S.
On 25/02/16 01:12, Dave Lawrence wrote:
> Stephen Farrell writes:
>> Section 11.3, I like that we're recommending that ECS be
>> disabled by default, but want to check one t
On 18/02/16 14:43, Paul Wouters wrote:
>
> I believe that resolves the "promises" in Section 3.
Thanks, those additions are good,
Cheers,
S.
smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-edns-chain-query-06: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Hi Don,
On 20/01/16 15:20, Donald Eastlake wrote:
> Hi Stephen,
>
> On Wed, Jan 20, 2016 at 7:10 AM, Stephen Farrell
> <stephen.farr...@cs.tcd.ie> wrote:
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-cookies-09: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-edns-client-subnet-06: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-edns-tcp-keepalive-05: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-5966bis-05: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Hiya,
On 06/01/16 21:49, sara wrote:
>
>> On 6 Jan 2016, at 20:57, Stephen Farrell
>> <stephen.farr...@cs.tcd.ie> wrote:
>>
>> Stephen Farrell has entered the following ballot position for
>> draft-ie
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-edns-tcp-keepalive-05: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-qname-minimisation-08: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
+
From: Stephen Farrell <stephen.farr...@cs.tcd.ie>
To: s...@ietf.org
Thanks all, that's sufficient feedback for me to propose to the
IESG that we return a "potentially disrupts, so please do not
publish now" 5742 response so I have proposed that to the IESG.
Additional discu
Forwarded Message
Subject: code points for brainpool curves for DNSSEC
Date: Wed, 9 Dec 2015 18:00:18 +
From: Stephen Farrell <stephen.farr...@cs.tcd.ie>
To: s...@ietf.org
Hiya,
The brainpool folks have written an I-D [1] that they are pushing
through the rfc ed
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-root-loopback-04: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-dns-terminology-04: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-onion-tld-00: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
Hiya,
I'm pretty sure I'll be a yes ballot on this (after I re-read the
draft which I've not read for quite a while). And I don't expect
either of us to change our ballot, but that said, I hope you don't
mind explaining your ballot a little more since I'm not getting part
of your argument and
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-negative-trust-anchors-10: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-dnssec-key-timing-06: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however
On 25/10/14 15:56, Ted Lemon wrote:
And also if anyone from Verisign is participating, they are required to
disclose,
Well, only if they think that the IPR is relevant. Their claims
(I've not read 'em) could after all be unrelated to the draft,
e.g. if they've only claimed some madly
On 04/10/10 15:37, Martin Rex wrote:
One thing that needs to be addressed/solved is the key/cert rollover
for any TLS-Server, so that it is possible to list more than one
server cert as valid for a Server through DNS, at least for the
time of the transition/rollover.
Maybe a side-issue
95 matches
Mail list logo
