[OPSAWG] Genart last call review of draft-ietf-opsawg-tlstm-update-11

[Joel Halpern via Datatracker]

Reviewer: Joel Halpern
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-opsawg-tlstm-update-11
Reviewer: Joel Halpern
Review Date: 2023-02-09
IETF LC End Date: 2023-02-20
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as a Proposed Standard RFC

Major issues: N/A

Minor issues:
In the fourth paragraph of section 1.1, the text refers to "a secure
association between two TLS Transport Models (TLSTMs)".  As I understand
the terminology, there is one TLSTM.  There are two instances of /
realizations of the model.  Should the sentence refer to instances or
realizations, rather than two models? (i-d nits gets confused by the
references to rfc 5953 in the revision description.  After looking at it, I
realized there was no problem here, rather it is accurate.  A comment on
this in item 14 of the shepherd writeup would have been helpful.)

Nits/editorial comments: N/A



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Last Call: (RADIUS Extensions for DHCP Configured Services) to Proposed Standard

[The IESG]

The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'RADIUS
Extensions for DHCP Configured Services'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2023-02-23. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document specifies two new Remote Authentication Dial-In User
   Service (RADIUS) attributes that carry DHCP options.  Even if the
   specification was initially motivated by the configuration of
   encrypted DNS resolvers, the specification is generic and can be
   applicable to any service that relies upon DHCP.  Both DHCPv4 and
   DHCPv6 configured services are covered.

   Also, this document updates RFC 4014 by relaxing a constraint on
   permitted RADIUS Attributes in the RADIUS Attributes DHCP suboption.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-encrypted-dns/



No IPR declarations have been submitted directly on this I-D.





___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07

[Rob Wilton (rwilton)]

Hi Med, Alan,

Thanks.  I've requested LC on -09.

Regards,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 09 February 2023 10:32
> To: Rob Wilton (rwilton) ; Alan DeKok
> 
> 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) 
> > Envoyé : jeudi 9 février 2023 11:04
> > À : BOUCADAIR Mohamed INNOV/NET
> ;
> > Alan DeKok 
> > 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
> > > 
> > > Sent: 09 February 2023 09:02
> > > To: Rob Wilton (rwilton) ; Alan DeKok
> > > 
> > > 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)  Envoyé :
> > mercredi 8
> > > > février 2023 20:39 À : Alan DeKok 
> > 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 
> > > > > Sent: 19 December 2022 17:13
> > > > > To: Rob Wilton (rwilton) 
> > > > > 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)
> > > > >  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 desc

Re: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07

[mohamed.boucadair]

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) 
> Envoyé : jeudi 9 février 2023 11:04
> À : BOUCADAIR Mohamed INNOV/NET ;
> Alan DeKok 
> 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
> > 
> > Sent: 09 February 2023 09:02
> > To: Rob Wilton (rwilton) ; Alan DeKok
> > 
> > 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)  Envoyé :
> mercredi 8
> > > février 2023 20:39 À : Alan DeKok 
> 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 
> > > > Sent: 19 December 2022 17:13
> > > > To: Rob Wilton (rwilton) 
> > > > 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)
> > > >  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)]
> 
> 

[OPSAWG] I-D Action: draft-ietf-opsawg-add-encrypted-dns-09.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group 
WG of the IETF.

Title   : RADIUS Extensions for DHCP Configured Services
Authors : Mohamed Boucadair
  Tirumaleswar Reddy
  Alan DeKok
  Filename: draft-ietf-opsawg-add-encrypted-dns-09.txt
  Pages   : 19
  Date: 2023-02-09

Abstract:
   This document specifies two new Remote Authentication Dial-In User
   Service (RADIUS) attributes that carry DHCP options.  Even if the
   specification was initially motivated by the configuration of
   encrypted DNS resolvers, the specification is generic and can be
   applicable to any service that relies upon DHCP.  Both DHCPv4 and
   DHCPv6 configured services are covered.

   Also, this document updates RFC 4014 by relaxing a constraint on
   permitted RADIUS Attributes in the RADIUS Attributes DHCP suboption.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-encrypted-dns/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-add-encrypted-dns-09

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-add-encrypted-dns-09


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07

[Rob Wilton (rwilton)]

Hi Med, Alan,

> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 09 February 2023 09:02
> To: Rob Wilton (rwilton) ; Alan DeKok
> 
> 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) 
> > Envoyé : mercredi 8 février 2023 20:39
> > À : Alan DeKok 
> > 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 
> > > Sent: 19 December 2022 17:13
> > > To: Rob Wilton (rwilton) 
> > > 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)
> > >  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
> > > > si

Re: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07

[mohamed.boucadair]

Hi Rob, all, 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Rob Wilton (rwilton) 
> Envoyé : mercredi 8 février 2023 20:39
> À : Alan DeKok 
> 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 
> > Sent: 19 December 2022 17:13
> > To: Rob Wilton (rwilton) 
> > 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)
> >  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.

> 
> >
> > > (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