(Answering as the person who is currently supposed to run the BoF)
On Feb 1, 2024, at 15:03, Paul Vixie wrote:
> Thanks Roy. Would a new working group be open to skeptics?
You have been in the IETF long enough to know that the answer is of course yes.
> I remain concerned about gradually incre
Thanks Roy. Would a new working group be open to skeptics? I remain
concerned about gradually increasing systemic complexity, and I have
some ideas about how some stated goals of the DELEG proposal could have
complexity increase precisely linear to new functionality -- so,
extending beyond but
There is nothing to prevent us saying that responses to priming queries
SHOULD/MUST set TC if all of the addresses of the root servers won’t fit in the
response or that the root server address should be looked up as if they are
glue in the root zone. The rules in RFC 1034 don’t handle priming qu
> On Jan 31, 2024, at 5:57 PM, Paul Hoffman wrote:
>
>> As Mark just clarified. This isn't glue, so perhaps the text just needs
>> updating.
>
> The current text is:
>
> If some root server addresses are omitted from the Additional section,
> there is no expectation that the TC bit in the
>
Edward Lewis writes:
> Is there going to be an assumed "standard set" of keywords?
Yes. Currently it specifies using the Service Parameter Keys
registry:
https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml
> (And a defined manner to know how to deal with
> unknown-to-the-receiver keywords.
On Wed, Jan 31, 2024 at 8:57 PM, Paul Hoffman
wrote:
> On Jan 31, 2024, at 17:39, Paul Wouters wrote:
>
> On Wed, 31 Jan 2024, Paul Hoffman wrote:
>
> On Jan 31, 2024, at 15:15, Paul Wouters wrote:
>
> Can they write a draft with why they are going against the RFC?
>
> Yes, that is possible. Ho
Automation isn't an solution in an of itself. When I recently mentioned,
during a panel discussion, that automation is essential (for scalability), an
operator on the same panel responded that automation is also a great way to
scale problems. Automation is needed but it must be automated corre
On 2/1/24 13:55, Havard Eidnes wrote:
Stupid question time:
The target of a DELEG alias cannot be stored in the child
zone. It would not resolve if you do.
Doesn't this mean that we can never get to an environment where
there only exists DELEG records and no NS records, and still have
a wo
>>Stupid question time:
>>
>>> The target of a DELEG alias cannot be stored in the child
>>> zone. It would not resolve if you do.
>>
>> Doesn't this mean that we can never get to an environment where
>> there only exists DELEG records and no NS records, and still have
>> a working DNS?
>
> DELEG r
On 2/1/24 13:34, Edward Lewis wrote:
The proper response will depend on the reason - more accurately the presumed
(lacking any out-of-band signals) reason - why the record is absent.
Barring any other information, the proper response should IMHO not depend on
the presumed reason, but assume
After thinking about the response below a bit, my question would be - when a
receiver expects a record to be present, but it isn’t, what is the proper
response?
The proper response will depend on the reason - more accurately the presumed
(lacking any out-of-band signals) reason - why the record
Dear DNSOP,
After the DNSOP Interim, I had a short discussion with Warren Kumari about the
vagueness of the request. I have now updated the request to reflect the
sentiment of the interim and to make sure that there is the opportunity to form
a WG if there is the desire to do so.
https://datat
In your letter dated Thu, 01 Feb 2024 10:17:33 +0100 (CET) you wrote:
>Stupid question time:
>
>> The target of a DELEG alias cannot be stored in the child
>> zone. It would not resolve if you do.
>
>Doesn't this mean that we can never get to an environment where
>there only exists DELEG records an
Stupid question time:
> The target of a DELEG alias cannot be stored in the child
> zone. It would not resolve if you do.
Doesn't this mean that we can never get to an environment where
there only exists DELEG records and no NS records, and still have
a working DNS?
Regards,
- Håvard
_
14 matches
Mail list logo