[{"author": "David Lawrence", "text": "

Thanks to Tim Wiciniabialishi and Mike Bishop for being our note takers

", "time": "2023-11-08T08:31:01Z"}, {"author": "\u00c9ric Vyncke", "text": "

+1

", "time": "2023-11-08T08:31:24Z"}, {"author": "Tim Wicinski", "text": "

Comment to the authors - They should run the \"Nits\" tool in the datatracker especially in WGLC

", "time": "2023-11-08T08:36:51Z"}, {"author": "David Lawrence", "text": "

Comment for the end, Tim?

", "time": "2023-11-08T08:37:23Z"}, {"author": "Tim Wicinski", "text": "

yes

", "time": "2023-11-08T08:38:07Z"}, {"author": "Mohamed Boucadair", "text": "

Tim, the idnits warning for resolver info is a false positive

", "time": "2023-11-08T08:39:41Z"}, {"author": "Mohamed Boucadair", "text": "

Not sure, which other issues are you referring to.

", "time": "2023-11-08T08:40:02Z"}, {"author": "Tim Wicinski", "text": "

thanks Tommy - I noticed as in the queue the few days between publishing -07 and 9461/2/3

", "time": "2023-11-08T08:43:24Z"}, {"author": "Christian Huitema", "text": "

I am always worried that the cert presents an address, but that the address can be natted to something else.

", "time": "2023-11-08T08:54:11Z"}, {"author": "Anthony Somerset", "text": "

yet another reason why NAT and IPv4 needs to go away :D

", "time": "2023-11-08T08:55:15Z"}, {"author": "Tim Wicinski", "text": "

Security and DNS directorate

", "time": "2023-11-08T09:00:20Z"}, {"author": "Benjamin Schwartz", "text": "

INTDIR for local network config

", "time": "2023-11-08T09:00:38Z"}, {"author": "\u00c9ric Vyncke", "text": "

Good ideas for directorate reviews

", "time": "2023-11-08T09:02:23Z"}, {"author": "Tim Wicinski", "text": "

agree with Ben on the overlapping redirection - I am \"meh\" on it. seems overly complicated

", "time": "2023-11-08T09:15:18Z"}, {"author": "Tim Wicinski", "text": "

(Ben did not say \"meh\" that was me)

", "time": "2023-11-08T09:15:40Z"}, {"author": "Tim Wicinski", "text": "

+1 on adoption

", "time": "2023-11-08T09:16:38Z"}, {"author": "Anthony Somerset", "text": "

agreed - adopt and work out the final niggles

", "time": "2023-11-08T09:16:54Z"}, {"author": "Anthony Somerset", "text": "

i am inclined to agree that overlapping should be its own draft

", "time": "2023-11-08T09:21:03Z"}, {"author": "Andrew Campling", "text": "

Isn\u2019t the plural of CPE CPE? (Equipment not Equipments)

", "time": "2023-11-08T09:22:44Z"}, {"author": "Anthony Somerset", "text": "

CPEs is fine as a more obvious demarcation between referring to a single CPE vs multiple CPE IMHO

", "time": "2023-11-08T09:24:15Z"}, {"author": "Manu Bretelle", "text": "

For the overlapping case.... I wonder if you can also get in a scenario were client A, whom is willing to send queries to provider B would transparently be sent to provider C while it may not be willing to have its data sent/seeing by C.

\n

Otherwise, I like the idea of EDSR and think it should be adopted. Moving overlapping case in a separate document will probably help getting the main use-case dusted and leave bikeshedding for another document.

", "time": "2023-11-08T09:26:28Z"}, {"author": "Benjamin Schwartz", "text": "

Re EDSR, it seems pretty odd to me to adopt a draft with major components that we don't expect can reach consensus.

", "time": "2023-11-08T09:26:29Z"}, {"author": "Manu Bretelle", "text": "

Benjamin Schwartz said:

\n
\n

Re EDSR, it seems pretty odd to me to adopt a draft with major components that we don't expect can reach consensus.

\n
\n

splitting the document would work right?

", "time": "2023-11-08T09:27:39Z"}, {"author": "Benjamin Schwartz", "text": "

@Erik Nygren But what if you have a mix of mandatory and ignorable flags...

", "time": "2023-11-08T09:28:12Z"}, {"author": "Andrew Campling", "text": "

Similar to Manu\u2019s point, I think that there maybe privacy issues in transferring to a third party provider without consent from the client.

", "time": "2023-11-08T09:28:59Z"}, {"author": "\u00c9ric Vyncke", "text": "

$ dig +short doh.bt.com aaaa
\n$

", "time": "2023-11-08T09:31:50Z"}, {"author": "\u00c9ric Vyncke", "text": "

:-o

", "time": "2023-11-08T09:31:53Z"}, {"author": "Erik Nygren", "text": "

And to be specific on my proposal on the mic, it might be better to have a SvcParam that has a list of required/mandatory client capabilities for using a service. For example:

\n
    cap=tls-deleg-cred mandatory=cap\n
\n

Which would then be extensible for other cases where a server is only usable by clients that implement ALL of a set of capabilities. (I'm sure there are other variations to have a mix of mandatory and ignoreable flags but we might want to think through how to handle that.)

", "time": "2023-11-08T09:34:07Z"}, {"author": "Mohamed Boucadair", "text": "

Thanks, Erik. The point is recorded at https://github.com/tireddy2/subcert/issues/7

", "time": "2023-11-08T09:37:41Z"}, {"author": "Benjamin Schwartz", "text": "

Erik Nygren said:

\n
\n

    cap=tls-deleg-cred mandatory=cap\n

\n

\n
\n

I think this costs 10+N bytes instead of 4+6*N? I'm not sure we are minting so many flags that this matters.

", "time": "2023-11-08T09:39:17Z"}, {"author": "Erik Nygren", "text": "

I also still think that something like @Martin Thomson 's \"HTTPS for Local Domains\" would be vastly better than Delegated Credentials for this use-case: https://docs.google.com/document/d/170rFC91jqvpFrKIqG4K8Vox8AL4LeQXzfikBQXYPmzU/edit
\n(Although a much bigger lift and would be outside the scope of this WG.)

", "time": "2023-11-08T09:39:19Z"}, {"author": "Erik Nygren", "text": "

Benjamin Schwartz said:

\n
\n

Erik Nygren said:

\n
\n

    cap=tls-deleg-cred mandatory=cap\n

\n

\n
\n

I think this costs 10+N bytes instead of 4+6*N? I'm not sure we are minting so many flags that this matters.

\n
\n

I'm thinking more that it could reduce implementation complexity on both clients and servers if it becomes a common pattern?

", "time": "2023-11-08T09:40:22Z"}, {"author": "Benjamin Schwartz", "text": "

Wait, remote participation counts as attending?

", "time": "2023-11-08T09:40:23Z"}, {"author": "Benjamin Schwartz", "text": "

@Erik Nygren It doesn't sound like less code to me.

", "time": "2023-11-08T09:41:40Z"}, {"author": "David Lawrence", "text": "

@Meetecho we're all done here. Thank you very much!

", "time": "2023-11-08T09:41:59Z"}, {"author": "Lorenzo Miniero", "text": "

Thanks for the heads up!

", "time": "2023-11-08T09:42:34Z"}]