Hi Med, Alan, Thanks. I've requested LC on -09.
Regards, Rob > -----Original Message----- > From: mohamed.boucad...@orange.com > <mohamed.boucad...@orange.com> > Sent: 09 February 2023 10:32 > To: Rob Wilton (rwilton) <rwil...@cisco.com>; Alan DeKok > <al...@deployingradius.com> > Cc: draft-ietf-opsawg-add-encrypted-dns....@ietf.org; opsawg@ietf.org > Subject: RE: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07 > > Re-, > > Thanks Rob for the follow-up. > > A new version with the proposed changes is now online: https://author- > tools.ietf.org/iddiff?url2=draft-ietf-opsawg-add-encrypted-dns-09. > > Cheers, > Med > > > -----Message d'origine----- > > De : Rob Wilton (rwilton) <rwil...@cisco.com> > > Envoyé : jeudi 9 février 2023 11:04 > > À : BOUCADAIR Mohamed INNOV/NET > <mohamed.boucad...@orange.com>; > > Alan DeKok <al...@deployingradius.com> > > Cc : draft-ietf-opsawg-add-encrypted-dns....@ietf.org; > > opsawg@ietf.org > > Objet : RE: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted- > > dns-07 > > > > Hi Med, Alan, > > > > > -----Original Message----- > > > From: mohamed.boucad...@orange.com > > > <mohamed.boucad...@orange.com> > > > Sent: 09 February 2023 09:02 > > > To: Rob Wilton (rwilton) <rwil...@cisco.com>; Alan DeKok > > > <al...@deployingradius.com> > > > Cc: draft-ietf-opsawg-add-encrypted-dns....@ietf.org; > > opsawg@ietf.org > > > Subject: RE: [OPSAWG] AD review of > > > draft-ietf-opsawg-add-encrypted-dns-07 > > > > > > Hi Rob, all, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : Rob Wilton (rwilton) <rwil...@cisco.com> Envoyé : > > mercredi 8 > > > > février 2023 20:39 À : Alan DeKok <al...@deployingradius.com> > > Cc : > > > > draft-ietf-opsawg-add-encrypted-dns....@ietf.org; > > > > opsawg@ietf.org > > > > Objet : RE: [OPSAWG] AD review of draft-ietf-opsawg-add- > > encrypted- > > > > dns-07 > > > > > > > > Hi Alan, > > > > > > > > Sorry for the delay. Please see inline ... > > > > > > > > > -----Original Message----- > > > > > From: Alan DeKok <al...@deployingradius.com> > > > > > Sent: 19 December 2022 17:13 > > > > > To: Rob Wilton (rwilton) <rwil...@cisco.com> > > > > > Cc: draft-ietf-opsawg-add-encrypted-dns....@ietf.org; > > > > opsawg@ietf.org > > > > > Subject: Re: [OPSAWG] AD review of > > > > > draft-ietf-opsawg-add-encrypted-dns-07 > > > > > > > > > > On Dec 19, 2022, at 11:53 AM, Rob Wilton (rwilton) > > > > > <rwilton=40cisco....@dmarc.ietf.org> wrote: > > > > > > It isn't really clear to me why some of the registries are > > > > needed, > > > > > > specifically > > > > > the ones in 8.4.1 and 8.4.2. Why not allow any v4 or v6 > > DHCP > > > > > attribute to be carried within the DHCPv6-Options or DHCPv4- > > > > Options field? > > > > > > > > > > The original intent of the document was to define a > > limited > > > > set of > > > > > DHCP options which could be carried in RADIUS. i.e. option > > X > > > > would > > > > > map to RADIUS attribute Y. After some discussion, this was > > > > deemed to > > > > > be unworkable, and changed to the current method. > > > > > > > > > > The previous limitations were still kept, however. > > > > > > > > > > While it is useful, I could see issues with allowing any > > DHCP > > > > option > > > > > to be transported in RADIUS. I'll have to dig deeper to get > > > > into details. > > > > [Rob Wilton (rwilton)] > > > > > > > > Okay. > > > > > > > > > > > > > > > > > > > > > (2) p 4, sec 3. DHCP Options RADIUS Attributes > > > > > > > > > > > > Absent any explicit configuration on the DHCP server, > > RADIUS > > > > supplied > > > > > > data by means of DHCP*-Options Attributes take > > precedence > > > > over any > > > > > > local configuration. > > > > > > > > > > > > This point may be worth discussing. Naturally, I would > > > > explicit > > > > > > configuration > > > > > to a network device to generally take precedent over > > implicitly > > > > > learned configuration from the network. > > > > > > > > > > I'm not sure which options are "implicitly learned" from > > the > > > > network. > > > > > One set is configured in the device, and another is > > configured > > > > on a > > > > > per-user / per- session basis. This allows for sane > > defaults, > > > > with > > > > > specific over-rides where those are needed. > > > > > > > > > > If the options configured on the device always take > > precedence > > > > over > > > > > the per- session options (via RADIUS), then there isn't much > > > > point in > > > > > sending per-session options. > > > > [Rob Wilton (rwilton)] > > > > To give a regular configuration example, if you were to enable > > the > > > > Ethernet auto-negotiation protocol but also explicitly > > configure an > > > > 10/100/1000 Ethernet interface to run at 100 Mb/s then I would > > > > expect the explicit client provided configuration to take > > precedence > > > > over negotiating the speed value. > > > > > > > > It sounds like, in what you describe, the configuration is > > > > effectively hierarchical. I.e., it is really because the > > RADIUS > > > > supplied configuration is more-specific that it takes > > precedence > > > > over the local configuration. If so, that is expected, but I > > think > > > > that it would be helpful to clarify the description to make > > that > > > > clear. > > > > > > > > > > [Med] OK. We can make this change: > > > > > > OLD: > > > Absent any explicit configuration on the DHCP server, RADIUS > > > supplied data by means of DHCP*-Options Attributes take > > precedence > > > over any local configuration. > > > > > > NEW: > > > RADIUS supplied data is specific configuration data that is > > > returned as a function of authentication and authorization > > checks. > > > As such, absent any explicit configuration on the DHCP > > server, RADIUS > > > supplied data by means of DHCP*-Options Attributes take > > precedence > > > over any local configuration. > > [Rob Wilton (rwilton)] > > > > This is okay, but would probably prefer a slight tweak to the last > > sentence to: > > > > RADIUS supplied data is specific configuration data that is > > returned as a function of authentication and authorization > > checks. > > As such, absent any explicit configuration on the DHCP server, > > RADIUS > > supplied data by means of DHCP*-Options Attributes take > > precedence > > over any less specific or default local configuration. > > > > But I'll leave this to the authors to decide. > > > > > > > > > > > > > > > > > > > > > > (3) p 6, sec 3.2. DHCPv4-Options Attribute > > > > > > > > > > > > Permitted DHCPv4 options in the DHCPv4-Options > > Attribute > > > > are > > > > > > maintained by IANA in the registry created in Section > > > > 8.4.2. > > > > > > > > > > > > Comparing this text to the description for v6, this > > > > description is > > > > > > silent on > > > > > whether multiple instances of the same DHCPv4 option MAY be > > > > included. > > > > > Should that be specified here? > > > > > > > > > > Likely, yes. The RADIUS attributes are simply carrying > > DHCP > > > > > options, as if they were in a DHCP packet. So all of the > > DHCP > > > > rules > > > > > about option handling should apply here. > > > > [Rob Wilton (rwilton)] > > > > Okay. > > > > > > > > > > > > > > > > > > > > > (4) p 10, sec 7. Table of Attributes > > > > > > > > > > > > The following table provides a guide as what type of > > RADIUS > > > > packets > > > > > > that may contain these attributes, and in what quantity. > > > > > > > > > > > > Am I right that this is just a duplication of what is > > > > described in > > > > > > section 3? If > > > > > so, perhaps change "guide" to "informative guide" and > > include > > > > text to > > > > > refer back to the canonical definition in section 3. > > > > > > > > > > Sure. This table is traditional in RADIUS RFCs, so the > > text > > > > here > > > > > mirrors previous RADIUS RFCs. > > > > [Rob Wilton (rwilton)] > > > > Okay. > > > > > > > > > > > > > > > > > > > (8) p 3, sec 3. DHCP Options RADIUS Attributes > > > > > > > > > > > > These attributes use the "Long Extended Type" format in > > > > order to > > > > > > permit the transport of attributes encapsulating more > > than > > > > 253 octets > > > > > > of data. DHCP options that can be included in the > > DHCP*- > > > > Options > > > > > > RADIUS attributes are limited by the maximum packet size > > of > > > > 4096 > > > > > > bytes. In order to accommodate deployments with large > > > > options, > > > > > > implementations are RECOMMENDED to support a packet size > > up > > > > to 65535 > > > > > > bytes. > > > > > > > > > > > > I didn't find this text clear. E.g., limit is 4k but > > should > > > > support up to 64K. > > > > > Which implementations should support larger packet sizes? > > Is > > > > this RADIUS > > > > > implementations? > > > > > > > > > > It's a limitation of RADIUS. Everything RADIUS has to > > support > > > > 4K packets. > > > > > Later RFCs allow for 64K packets. > > > > [Rob Wilton (rwilton)] > > > > > > > > Okay. If this will be obvious to everyone > > implementing/deploying > > > > RADIUS then fine, otherwise it might be worth including an > > > > informative reference to the RFC that increases the limit to > > 64K. > > > > > > > > > > > > > > [Med] We do already have the following: > > > > > > Note: The 4096 bytes size limit was relaxed by other RFCs, > > e.g., > > > [RFC7499] and [RFC7930]. > > > > > > Do we need to say more? Thanks. > > [Rob Wilton (rwilton)] > > > > Nope. I missed that you already state that. > > > > > > > > > > > > > > > > > > > > > > > > > > (9) p 5, sec 3.1. DHCPv6-Options Attribute > > > > > > > > > > > > This field contains a list of DHCPv6 options. > > Multiple > > > > instances > > > > > > of the same DHCPv6 option MAY be included. > > Consistent > > > > with > > > > > > Section 17 of [RFC7227], this document does not > > impose > > > > any option > > > > > > order when multiple options are present. > > > > > > > > > > > > Is there any requirement to merge multiple instances of > > > > options together, > > > > > presumably they are logically just concatenated today. > > > > > > > > > > The rules for DHCP options processing should apply. > > > > [Rob Wilton (rwilton)] > > > > > > > > Okay. Should that be stated here, or at least made consistent > > with > > > > the v4 description that has been updated to: > > > > > > > > | This field contains a list of DHCPv4 options. Multiple > > > > instances > > > > | of the same DHCPv4 option MAY be included, especially > > for > > > > | concatenation-requiring options that exceed the maximum > > > > DHCPv4 > > > > | option size of 255 octets. The mechanism specified in > > > > [RFC3396] > > > > | MUST be used for splitting and concatenating the > > instances > > > > of a > > > > | concatenation-requiring option. > > > > > > > > > > [Med] We can echo the relevant part from 8415 here: > > > > > > OLD: > > > This field contains a list of DHCPv6 options. Multiple > > instances > > > of the same DHCPv6 option MAY be included. Consistent > > with > > > Section 17 of [RFC7227], this document does not impose any > > option > > > order when multiple options are present. > > > > > > NEW: > > > This field contains a list of DHCPv6 options (Section 21 > > of > > > [RFC8415]). Multiple instances of the same DHCPv6 option > > MAY be > > > included. If an option appears multiple times, each > > instance is > > > considered separate and the data areas of the options MUST > > NOT be > > > concatenated or otherwise combined. Consistent with > > Section 17 of > > > [RFC7227], this document does not impose any option order > > when > > > multiple options are present. > > [Rob Wilton (rwilton)] > > > > Looks good. > > > > Let me know when you have posted an updated draft. > > > > Thanks, > > Rob > > > ________________________________________________________________ > _________________________________________________________ > > 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. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
