On 01/11/2021 18.29, Michael StJohns wrote:
Section 2 - "their definition should specify..." - this is obviously a
must and is guidance to the IANA for interpreting registrations. E.g.
lack of this data has to result in a rejected registration request.
Section 2.1 - "Key names should contai
On 11/1/2021 11:58 AM, Eric Orth wrote:
The important part for preserving compatibility with potential future
changes is the "recipients MUST ignore any SvcParams that are present"
part.
I don't understand what would be different if the record sender SHOULD
became a MUST. Recipients wouldn
On 11/1/2021 11:58 AM, Eric Orth wrote:
The important part for preserving compatibility with potential future
changes is the "recipients MUST ignore any SvcParams that are present"
part.
I don't understand what would be different if the record sender SHOULD
became a MUST. Recipients wouldn
This text is a "SHOULD NOT" because there has been some discussion of
potential future uses for SvcParams in AliasMode. If implementations
follow the current text, this kind of extension can be backwards-compatible.
I agree that the resulting behavior creates a typo hazard for zone
administrators
> On 1 Nov 2021, at 21:57, libor.peltan wrote:
>
> Hi,
>
> I'm just not sure if this requested SHOULD->MUST change would actually have
> any consequences.
The primary would refuse to load the record and it would have been corrected.
The primary would refuse to accept in as part of an UPDAT
Hi,
I'm just not sure if this requested SHOULD->MUST change would actually
have any consequences.
It still doesn't say anything about what authoritative, and recursive
servers should do.
The draft's sections about authoritative server behavior are somewhat
brief, but that may be OK.
In g
In AliasMode, records SHOULD NOT include any SvcParams, and
recipients MUST ignore any SvcParams that are present.
Today we had the following record like this
example.com IN HTTPS 0 . alpn=h2 ipv4hint=192.0.2.1 ipv6hint=2001:DB8:
interpreting this as described leads to “0 .” which indicates
