All,
We've uploaded a draft agenda for IETF118, but we do feel we could use some
guidance from the working group. We did ask folks if they had conflicts
with either session, and we've had a few specific requests for Tuesday,
including one document marked For Consideration.
We also tentatively sc
Just picking one of these emails.
What’s all the FUD here about?
There is *nothing* new here. CPE boxes have done UPDATE to change their
addresses to *non authoritative* servers using UPDATE for at least a decade
now. DYN DNS did this. The updates used TSIG for authentication. Mac also
doe
> On 25 Oct 2023, at 18:58, Joe Abley wrote:
>
> On 25 Oct 2023, at 18:46, Johan Stenstam
> wrote:
>
>> I agree. But it is bad to design a system where the key CANNOT be rolled.
>
> I agree. I was just expressing doubt that you can find a single automated
> mechanism that is appropriate to
Hi Paul,
> On 25 Oct 2023, at 17:20, Paul Wouters wrote:
>
> On Oct 25, 2023, at 10:11, Paul Vixie
> wrote:
>>
>
> [speaking as individual]
>
>> i am uncomfortable using the UPDATE RCODE for a purpose unrelated to zone
>> modification. perhaps propose a new RCODE having the same message fo
On 25 Oct 2023, at 18:46, Johan Stenstam
wrote:
> I agree. But it is bad to design a system where the key CANNOT be rolled.
I agree. I was just expressing doubt that you can find a single automated
mechanism that is appropriate to use in all possible compromise scenarios.
For a hopefully rar
Hi,
> On 25 Oct 2023, at 17:50, Joe Abley wrote:
>
> On 25 Oct 2023, at 17:31, Johan Stenstam
> wrote:
>
>> On 25 Oct 2023, at 11:32, Joe Abley wrote:
>>
>>> I am not at all familiar with SIG(0), so bear with me. What is the key
>>> distribution mechanism for the DNS UPDATE originator's pu
Hi Paul,
> On 25 Oct 2023, at 16:10, Paul Vixie
> wrote:
>
> see inline.
>
> Johan Stenstam wrote on 2023-10-25 01:09:
>> Greetings Working Group,
>> As many of you are aware Peter Thomassen, John Levine and I have been
>> working on the generalised notifications for a while. The key idea the
On 25 Oct 2023, at 17:31, Johan Stenstam
wrote:
> On 25 Oct 2023, at 11:32, Joe Abley wrote:
>
>> I am not at all familiar with SIG(0), so bear with me. What is the key
>> distribution mechanism for the DNS UPDATE originator's public key? RFC 2931
>> suggests an unsigned KEY RR, I think?
>
Hi Joe,
> On 25 Oct 2023, at 11:32, Joe Abley wrote:
>
> On 25 Oct 2023, at 10:10, Johan Stenstam
> wrote:
>
>> So now there’s a new draft, that further extends the same core idea (locate
>> the target for the information being sent via a DNS lookup in the parent
>> zone). However, the new
On Oct 25, 2023, at 10:11, Paul Vixie wrote:
>
[speaking as individual]
> i am uncomfortable using the UPDATE RCODE for a purpose unrelated to zone
> modification. perhaps propose a new RCODE having the same message form as
> UPDATE?
I agree.
>> 2. No requirement for DNSSEC. Great as DNSSEC
see inline.
Johan Stenstam wrote on 2023-10-25 01:09:
Greetings Working Group,
As many of you are aware Peter Thomassen, John Levine and I have been working
on the generalised notifications for a while. The key idea there is obviously
that a NOTIFY(CDS) or NOTIFY(CSYNC) sent from the child to
On 25 Oct 2023, at 10:10, Johan Stenstam
wrote:
> So now there’s a new draft, that further extends the same core idea (locate
> the target for the information being sent via a DNS lookup in the parent
> zone). However, the new draft
> (draft-johani-dnsop-delegation-mgmt-via-ddns-00) proposes
Greetings Working Group,
As many of you are aware Peter Thomassen, John Levine and I have been working
on the generalised notifications for a while. The key idea there is obviously
that a NOTIFY(CDS) or NOTIFY(CSYNC) sent from the child to the parent scanner
will allow the scanner to fast track
13 matches
Mail list logo
