Hi Tommy, On the IANA registry policy, initial versions of the spec used expert review, but this was changed to a more strict policy per the outcome from the WG even if this was not the authors preference; see the record at https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/issues/15.
Should I understand that you changed your mind since the last time we discussed this: (Minutes IETF116: dnsop<https://datatracker.ietf.org/doc/minutes-116-dnsop/>) == Structured Error Data for Filtered DNS - Document Update, Tirumal Reddy https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/ Ben Schwartz: Would like to see the registries tightly controlled: IETF review Wants to prevent the designated expert from being pressured for odd states Tommy Pauly: Agrees with Ben on reviews Wants the text to not be browser-specific Contact info marked as mandatory There may be future cases which don't need contact info Browser or OS may know better than the DNS about what to do because it has more context Tiru: Agrees, didn't put specific URIs in Should be a list of URIs, but may be too narrow == Cheers, Med De : Tommy Pauly <tpauly=40apple....@dmarc.ietf.org> Envoyé : mardi 5 novembre 2024 15:47 À : DNSOP Working Group <dnsop@ietf.org> Cc : DNSOP Chairs <dnsop-cha...@ietf.org>; Benno Overeinder <be...@nlnetlabs.nl> Objet : [DNSOP] Re: Working Group Last Call draft-ietf-dnsop-structured-dns-error Overall, I think this document, and its definition of the EXTRA-TEXT field as JSON is important. To that end, I am eager to see progress in this area. However, I think we should not quite yet ship this out of the WG. Two specific points: - I’d like to have a working group discussion with regards to the proposal in draft-nottingham-public-resolver-errors-00. While that doesn’t necessarily require being merged into draft-ietf-dnsop-structured-dns-error, it could be, and I would like to ensure with the WG that if they are separate, that there are no changes needed in draft-ietf-dnsop-structured-dns-error in order to support the details Mark’s draft is proposing. I think this incident/operator ID approach is potentially a very compelling tool to drive adoption of these errors across browser clients. - I am concerned about the IANA registry policy for the JSON names being IETF Review. (My concerns are slightly less for the other registries.) Requiring not only an RFC, but an IETF-stream RFC, seems like too high a bar. I would suggest Expert Review. Best, Tommy On Oct 26, 2024, at 9:10 PM, Benno Overeinder <be...@nlnetlabs.nl<mailto:be...@nlnetlabs.nl>> wrote: Dear all, The draft-ietf-dnsop-structured-dns-error has seen several revisions and there has been considerable discussion on the mailing list and in the WG. At IETF 116, Gianpaolo Scalone (Vodafone) and Ralf Weber (Akamai) presented a proof of concept of this specification. The authors and the WG chairs believe the draft is ready for a Working Group Last Call. This initiates the Working Group Last Call (WGLC) for draft-ietf-dnsop-structured-dns-error, "Structured Error Data for Filtered DNS." The draft can be reviewed here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/ Intended Status: Proposed Standard Document Shepherd: Benno Please take the time to review this draft and share any relevant comments. For the WGLC to be effective, we need both positive support and constructive feedback; a simple lack of objection isn’t enough. If you believe this draft is ready for publication as an RFC, please state your support. Conversely, if you feel the document isn’t ready for publication, please provide your concerns and reasoning. This starts a two-week Working Group Last Call process, concluding on November 9, 2024. Thank you, Suzanne Tim Benno _______________________________________________ DNSOP mailing list -- dnsop@ietf.org<mailto:dnsop@ietf.org> To unsubscribe send an email to dnsop-le...@ietf.org<mailto:dnsop-le...@ietf.org> ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
