On Oct 14, 2022, at 5:47 AM, <mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com> wrote: > Let's try to exercise this approach and see if there are not hidden > complications vs. current design with known limitation. A drafty text (not > yet in the main draft) can be seen at: > https://github.com/boucadair/draft-ietf-opsawg-add-encrypted-dns/blob/main/draft-ietf-opsawg-add-encrypted-dns-encap.txt
Nits: Section 3: just drop the ASCII art. RFC 8044 makes it no longer necessary. Section 3.1, 3.2, and 7.1: the data type should be "string" for "opaque data" Other than that, it looks good on first read-through. > The attributes should not be seen as opaque data by the RADIUS server but it > should understand the encoding of the enclosed options. The intended behavior > should be called out, IMO. I would suggest saying something like "for ease of administrator configuration, the RADIUS server SHOULD expose the DHCP options and allow administrators to configure them, instead of requiring them to be entered as opaque data". That gets the best of both worlds. Alan DeKok. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
