Domain Connect (dconn) @ IETF 126

Note takers: Caspar Schutijser

Opening, Note Well

No comments

Pawel Kowalik: Domain Connect Protocol - DNS provisioning between Services and DNS Providers

About open issue Locale-Aware /settings End-Point (slide 11):

• Peter Thomassen (Chair): no hats, is this about the locale that is
  displayed to the DNS provider customer? this is about before login?
  Because provider knows customer.
• Pawel: yes.

About open issue Protocol version / backward compatibility (slide 15):

• Hans-Jörg Happel: Support supporting considering future versions of
  protocol as well. TXT records don't have structure. Do you see
  issues with that in the future?
• Pawel: Right now it's just FQDN and path element. Future revisions
  can have key-value structure, like DMARC, DKIM. Can be version 2 and
  then clients can distinguish.
• John Levine: we have lots of experience that adding version numbers
  does not work. You can add it it you want. I'ts not terrible but I
  don't think it'll do what you think it will.
• Peter: didn't mean to say it needs a version number, but it is a
  point that should be considered. Protocol can also be extensible by
  ignoring new stuff.
• John Levine: I agree with the "you have to understand this" tag.
  When you extend it then you know that you break it.

About open issue Offer also POST, not only GET on /apply for sync flow
(slide 16):

• John Levine: HTTP just introduced a new method called QUERY and this
  sounds like an application for it.

Additional comment regarding open issue Use-case - different person
making service setup vs. DNS changes (slide 13):

• Peter Thomassen: you write "DNS providers may offer better UX". I
  don't get how the DNS provider actually provides a better
  experience. Is it about the service provider, not the DNS provider?
• Pawel: can be solved on both sides. But it's all UX solutions, not
  sure how much time we should invest in UX.

Not about an open issue but just generally about
draft-ietf-dconn-domainconnect-03:

• Murray Kucherawy: is there a reason the IANA considerations section
  is so complicated? Worried about: 1. look at the media type
  rgistration. 2. a lot of SHOULDs. Think about what you are going to
  bind with the rules that you are creating. IANA is not going to do
  anything about this.
• Pawel: IANA text is quite new. Mostly copy-paste from other IANA
  considerations.
• Murray: happy to work on it with you.
• Pawel: I'm happy to work on this.

Pawel Kowalik: Domain Connect Protocol - Asynchronous Flow Extension

About open issue Ambiguous asynchronous apply. Unclear precedence for
parameters via query string vs. JSON body. (slide 19):

• Peter: I understand it's useful to have some stuff in query string.
  Would it make sense to have an error when the JSON says something
  else than the query parameters?
• Pawel: two approaches, 1: one is always right, or 2: if they are
  appearing twice, they always have to agree.
• Peter: possibility for misunderstanding. perhaps allow it either in
  query string or JSON or both but only when it's consistent.
• Pawel: agreed.

About open issue Automated deployment pipeline Use-Case (Secdir
review) (slide 20):

• Peter: why do you say it requires a template-less DNS update?
• Pawel: It could still use templates. ...
• Peter: to me it sounds like they're asking for automated deployments
  with other authentication methods, like PKIX certs. Different from
  the template constraint.
• Pawel: I'd need to have a look again.

AOB

• Hans-Jörg Happel (Chair): regarding milestones. Do we need to change
  anything?
• Pawel: no, all good.