[DNSOP] Francesca Palombini's Discuss on draft-ietf-dnsop-svcb-https-09: (with DISCUSS and COMMENT)

Francesca Palombini via Datatracker <noreply@ietf.org> Mon, 23 May 2022 12:01 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54491C157B43; Mon, 23 May 2022 05:01:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Francesca Palombini via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-svcb-https@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, tjw.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 8.3.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Francesca Palombini <francesca.palombini@ericsson.com>
Message-ID: <165330731633.53326.3094975945466470860@ietfa.amsl.com>
Date: Mon, 23 May 2022 05:01:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4CIk6PDD0igvUM_GPwGrE19XlJs>
Subject: [DNSOP] Francesca Palombini's Discuss on draft-ietf-dnsop-svcb-https-09: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.34
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 May 2022 12:01:56 -0000

Francesca Palombini has entered the following ballot position for
draft-ietf-dnsop-svcb-https-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work on this document.

Many thanks to Cullen Jennings for his ART ART review:
https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/.

Thank you for addressing my previous DISCUSS and COMMENTs. I have reviewed v-09
and I noticed 4 points were not addressed (or I missed them). Do let me know if
you think no further clarifications were necessary - just making sure these
were not missed, as I have not seen any answers to them.

Re: the use of SHOULD - thank you for adding context to most of them. I did not
see any added context to these following two SHOULDs:

> Zone-file implementations SHOULD enforce self-consistency.

and

> If the client enforces DNSSEC validation on A/AAAA responses, it SHOULD apply
the same validation policy to SVCB.

If SHOULD is used, then it must be accompanied by at least one of:
(1) A general description of the character of the exceptions and/or in what
areas exceptions are likely to arise.  Examples are fine but, except in
plausible and rare cases, not enumerated lists. (2) A statement about what
should be done, or what the considerations are, if the "SHOULD" requirement is
not met. (3) A statement about why it is not a MUST.

Francesca


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

4. -----

 The value is then
   validated and converted into wire-format in a manner specific to each
   key.

FP: Section 15.3.1 states

   registration policy ([RFC8126], Section 4.5).  The designated expert
   MUST ensure that the Format Reference is stable and publicly
   available, and that it specifies how to convert the SvcParamValue's
   presentation format to wire format.

This covers the conversion, but does not cover the validation mentioned above.
(This could be really easily addressed by making sure that not only it
specifies how to convert but also how to validate).

10. -----

Table 1

FP: The table reports that

   | 65280-65534 | N/A             | Private Use    | (This document) |

But that is not specified in the text above, that only talks about expert
review registration policy. That should be made consistent.