[{"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.
\nOtherwise, 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\nRe EDSR, it seems pretty odd to me to adopt a draft with major components that we don't expect can reach consensus.
\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$
:-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
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\ncap=tls-deleg-cred mandatory=cap\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.)
Benjamin Schwartz said:
\n\n\nErik Nygren said:
\n\n\ncap=tls-deleg-cred mandatory=cap\n
\n\nI 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
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"}]