Re: [Last-Call] [Add] [EXTERNAL] Re: Artart last call review of draft-ietf-add-ddr-07

[Tommy Jensen <Jensen.Thomas=40microsoft.com@xxxxxxxxxxxxxx>]

Hey Vittorio,

 

>each implementation will define on its own what constitutes "some sort of validation" to an acceptable level

 

Agreed, client policy is out of DDR scope. See this text immediately preceding the text previously quoted: “A client MAY additionally use a discovered Designated Resolver without either of these methods, based on implementation-specific policy or user input. Details of such policy are out of scope of this document.”

 

The point being made by the MUST NOT is that if a client chooses to use a designation not validated by a mechanism defined in DDR, it is opting out of the security model provided by DDR and is therefore not a fully compliant DDR client. Resolvers which do not allow validation by DDR mechanisms should expect fully-DDR-compliant clients to fail to use their designations.

 

If a future draft defines an alternative mechanism, then the client can be compliant with that draft (and by extension DDR if the new draft updates/obsoletes DDR).

 

Thanks,

Tommy

 

From: Vittorio Bertola <vittorio.bertola=40open-xchange.com@xxxxxxxxxxxxxx>
Sent: Thursday, June 30, 2022 4:41 AM
To: Tommy Jensen <Jensen.Thomas@xxxxxxxxxxxxx>; Tommy Pauly <tpauly@xxxxxxxxx>; Thomas Fossati <thomas.fossati@xxxxxxx>
Cc: art@xxxxxxxx; add@xxxxxxxx; draft-ietf-add-ddr.all@xxxxxxxx; last-call@xxxxxxxx
Subject: Re: [Add] [EXTERNAL] Re: Artart last call review of draft-ietf-add-ddr-07

 

 

Il 30/06/2022 01:54 Tommy Jensen <jensen.thomas=40microsoft.com@xxxxxxxxxxxxxx> ha scritto:

 

Why the following isn't a MUST NOT?

  Clients SHOULD NOT automatically use a Designated
  Resolver without some sort of validation, such as the two methods
  defined in this document or a future mechanism.

[TommyJ] MUST NOT is probably more appropriate (changed); the SHOULD NOT is an artifact of prior discussions changing the scope of the document.

This is fine as long as it is clear that any validation mechanism other than the two methods in the document is still acceptable, and that each implementation will define on its own what constitutes "some sort of validation" to an acceptable level; "such as" should possibly make that happen. I just hope that we will never get to argue whether some implementation's algorithm actually is "some sort of validation" or not.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@xxxxxxxxxxxxxxxx 
Office @ Via Treviso 12, 10144 Torino, Italy

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call