On Tuesday, June 19, 2018 01:21 CEST, Shumon Huque wrote:
> On Mon, Jun 18, 2018 at 7:05 PM Darcy Kevin (FCA)
> wrote:
>
> > RFC 6724 specifically says: "Rules 9 and 10 MAY be superseded if the
> > implementation has other
> > means of sorting destination addresses. For example, if the
> > im
haps as an informational RFC), but it seems like the only
> deployable option for individuals and small organizations
...
Could someone validate these assumptions?
I do not like TXT but I'm not in position to judge validity of these arguments.
Thank you f
clarifications and corrections in addition
> to the valuable
> contribution from RedHat.
Thank you!
I just read the diff and it looks good to me.
Petr^2 Spacek
>
> Olafur
>
>
>> On Dec 1, 2015, at 4:42 AM, Petr Spacek wrote:
>>
>> Hello dnsop,
>>
dnsop/current/msg13303.html
?
Thank you!
Petr Spacek
On 30.11.2015 20:50, IETF Secretariat wrote:
> Dear Wesley Hardaker, Ólafur Guðmundsson, Suresh Krishnaswamy:
>
>
> An IPR disclosure that pertains to your Internet-Draft entitled "DNSSEC
> Roadblock Avoidance" (dra
ble from
http://www.ietf.org/mail-archive/web/dnsop/current/msg15848.html
I do not know how long it will take to incorporate it, but I believe that it
is an important addition for roaming clients and similar situations.
--
Petr Spacek @ Red Hat
___
DNS
.ARPA sub-trees it is up to implementation
to decide if it is necessary to update alias itself or if it is
necessary to update endpoint records and thus the method described
in the section 9.2 needs to be applied.
Is there something wrong with it? It should be just informational
e text above makes sense :-) I will read the
procedure in section 9.2 carefully again this week, but it seems okay at a
first glance. (For generalization proposed above we would have to drop "PTR"
from the very last bullet in 9.2. Suggested behaviou
On 7.10.2015 17:47, Petr Spacek wrote:
> On 25.8.2015 17:34, Petr Spacek wrote:
>> On 26.6.2015 22:45, Olafur Gudmundsson wrote:
>>>> On Feb 11, 2015, at 11:24 AM, Petr Spacek wrote:
>> [...]
>>>> Few guys in Red Hat proposed "hacky but almost-relia
On 25.8.2015 17:34, Petr Spacek wrote:
> On 26.6.2015 22:45, Olafur Gudmundsson wrote:
>>> On Feb 11, 2015, at 11:24 AM, Petr Spacek wrote:
> [...]
>>> Few guys in Red Hat proposed "hacky but almost-reliable automatic" way how
>>> to
>>
On 27.8.2015 17:22, Bob Harold wrote:
> On Thu, Aug 27, 2015 at 6:39 AM, Petr Spacek wrote:
>
>> Dear DNSOP Chairs,
>>
>> I'm requesting a call for adoption of draft-spacek-dnsop-update-clarif.
>>
>> We did not have time allocated for discussing this in P
e records
in IN-ADDR.ARPA and other zones without changing existing CNAME/DNAME
redirections. This clarification is not applicable to cases where the
purpose of the DNS update is to change CNAME/DNAME redirection.
Any suggestions are more than welcome! Thank you for your time.
Petr Spacek
> In
his till Yokohama is necessary.
Thank you.
Petr Spacek
A new version of I-D, draft-spacek-dnsop-update-clarif-01.txt
has been successfully submitted by Petr Spacek and posted to the
IETF repository.
Name: draft-spacek-dnsop-update-clarif
Revision: 01
Title: Clarifications to th
On 26.6.2015 22:45, Olafur Gudmundsson wrote:
>> On Feb 11, 2015, at 11:24 AM, Petr Spacek wrote:
[...]
>> Few guys in Red Hat proposed "hacky but almost-reliable automatic" way how to
>> improve usability without sacrificing security.
>>
>>
>> Disc
; questions and I'm pretty
> sure that's not an unusual approach for other IETF attendees.
>
> You cannot assume that every single new installation of modified client code
> to do Warren's stuff will agree that sending the root this data is of use to
> them, and they
to read
and follow, especially if edns-tcp-keepalive gets finalized.
--
Petr Spacek
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
is kind of hard to read, but that is just matter of taste.
--
Petr Spacek
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 26.6.2015 22:45, Olafur Gudmundsson wrote:
>> On Feb 11, 2015, at 11:24 AM, Petr Spacek wrote:
>> draft-ietf-dnsop-dnssec-roadblock-avoidance is a nice idea in general but
>> current version of "Roadblock Avoidance", section 5, version 01 has a
>> significant
feedback about Section 4 and definition of
canonicalization, I'm not sure if it is clear enough.
And of course, any other feedback is also welcome!
--
Petr Spacek @ Red Hat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 3.6.2015 10:44, Mark Andrews wrote:
> In message <556ea478.80...@redhat.com>, Petr Spacek writes:
>> I would like early feedback about following idea about interaction between DN
>> S
>> updates (RFC 2136) and classless IN-ADDR.ARPA delegation (RFC 2317).
>>
&
is sometimes quite hard to
debug so this extension could be a tremendous help!
(Yes, all this may require some configurable policy to specify clients who can
use ESD option.)
I will be in Prague so I'm more than happy to discuss it there if there is
On 3.6.2015 17:00, Evan Hunt wrote:
> On Wed, Jun 03, 2015 at 08:40:16AM +0200, Petr Spacek wrote:
>> Could this be added to agenda for IETF 93? Does it make sense to discuss
>> it there?
>
> Unfortunately I won't be in Prague, but I do expect to be in Yokohama.
>
7;Security Considerations'
(considering signed updates).
I would welcome early feedback about the idea even before the -00 is published.
Thank you very much!
--
Petr Spacek @ Red Hat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
I had other business to attend to.
Could this be added to agenda for IETF 93? Does it make sense to discuss it
there?
--
Petr Spacek @ Red Hat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e from doing crazy things
just by obscuring format of diagnostics data. I'm sure somebody will try to
parse free-form string 'signature expired 1 week ago' and do some decisions
from that :-)
--
Petr Spacek @ Red Hat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ds. (Naturally it works only
for cases where fallback to iteration is possible.)
We wanted to write Unbound module for this but it is harder than it seems.
(Proof-of-concept with stand-alone DNS proxy works fine, we have problem with
Unbound module architecture
e refer
me back to archives so I can understand the reasoning.
Thank you for your time!
--
Petr Spacek @ Red Hat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
given bit.
What about private RR types? Are we intentionally saying 'private types cannot
be used'?
--
Petr Spacek @ Red Hat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
;HTTPS required' signalization?
(This is weird, I admit that. There will be troubles with DNS client libraries
not exposing CNAMEs etc... I just can't resist.)
--
Petr Spacek @ Red Hat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 2.5.2014 01:26, Wes Hardaker wrote:
>- I'm bit nervous about "should be processed" in section:
>2.2.2. CSYNC Record Types
>
>This document defines how the following record types may be processed
>if the CSYNC Type Bit Map field indicates they should be processed.
>
>Did you mean SHOULD
On 15.4.2014 10:46, Matthijs Mekking wrote:
2.1.1.1. The SOA Serial Field
First, this document talks about serial being greater than... It might
be good to reference RFC 1982 serial number arithmetic that defines
serial comparison.
Second, I don't like having a special value of 0 to indicate som
ny library.
I hope this clarifies my intent.
--
Petr Spacek @ Red Hat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 8.4.2014 16:10, Joe Abley wrote:
On 8 Apr 2014, at 9:54, Petr Spacek wrote:
On 8.4.2014 15:20, Edward Lewis wrote:
From the linked message:
Let me quote very first part of the message to put it into context:
People start to disagree when it comes to questions like "Is it feasib
ot;How can an application detect that the IPSEC tunnel is
in place?"
I hope this clarifies purpose of the proposal.
Have a nice day!
Petr Spacek @ Red Hat
> What goes in one comes out the other unmolested. The fact that “below” the
DNSSEC plane is plain old DNS is irrelevant. I coul
ike a good idea.
There were long threads about DNSSEC handling in stub-resolvers on dane-list
[0] but dnsop seems like a better place to discuss this matter.
Note that this discussion is not over so we can move it to dnsop if dnsop
agrees.
[0] http://www.ietf.org/mail
Greetings,
Paul Wouters and me have accidentally open threads about the same topic on
this list and also on dane-list. I guess that this discussion fits better to
dane-list so please discuss there.
I'm sorry for the noise.
Petr Spacek
On 26.2.2014 16:44, Petr Spacek wrote:
Greetings,
Greetings,
I'm Petr Spacek from Red Hat's Identity Management group. We plan to extend
support for DNSSEC (including DANE and others) in open-source software and we
would like to discuss the right implementation approach with you.
We can see two very basic approaches:
A) Do DNSSE
36 matches
Mail list logo
