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
> >
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 for your time.
/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" (draft-ie
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
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.
> Is the
the 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 behaviour but that is it.)
I believ
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 <pspa...@redhat.com> wrote:
>> [...]
>>>> Few guys in Red Hat proposed
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 <pspa...@redhat.com> wrote:
> [...]
>>> Few guys in Red Hat proposed "hacky but almost-reliable automatic" way how
>>
On 27.8.2015 17:22, Bob Harold wrote:
> On Thu, Aug 27, 2015 at 6:39 AM, Petr Spacek <pspa...@redhat.com> wrote:
>
>> Dear DNSOP Chairs,
>>
>> I'm requesting a call for adoption of draft-spacek-dnsop-update-clarif.
>>
>> We did not have time allocated f
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 answer to the actual question you asked, I sup
.
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 the Dynamic Updates
On 26.6.2015 22:45, Olafur Gudmundsson wrote:
On Feb 11, 2015, at 11:24 AM, Petr Spacek pspa...@redhat.com wrote:
[...]
Few guys in Red Hat proposed hacky but almost-reliable automatic way how to
improve usability without sacrificing security.
Disclaimer
==
Method described below
stuff will agree that sending the root this data is of use to
them, and they may not agree to enable the protocol. I pretty much believe
you need to give them the option to say no.
This whole debate is about MUST vs. SHOULD (opt-in/out), is that right?
--
Petr Spacek @ Red Hat
-tcp-keepalive gets finalized.
--
Petr Spacek
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
, 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 26.6.2015 22:45, Olafur Gudmundsson wrote:
On Feb 11, 2015, at 11:24 AM, Petr Spacek pspa...@redhat.com 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 drawback:
Else
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).
In short, the RFC 2317 tells me to fill
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
enough interest.
--
Petr Spacek @ Red Hat
it seems.
(Proof-of-concept with stand-alone DNS proxy works fine, we have problem with
Unbound module architecture - not with the described method.)
Feel free to incorporate the idea to the draft if you wish.
--
Petr Spacek @ Red Hat
___
DNSOP
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
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
.
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
' 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? Or
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
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-archive/web/dane/current/msg06658.html
--
Petr Spacek @ Red Hat
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 could take the results of the
signer and FTP them to the validator, rsync them, etc. DNSSEC
On 8.4.2014 16:10, Joe Abley wrote:
On 8 Apr 2014, at 9:54, Petr Spacek pspa...@redhat.com 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
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 DNSSEC response
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,
I'm
30 matches
Mail list logo
