On Mon, 17 Oct 2022 at 16:28, tom petch wrote:
> inline one minor editorial comment plus a technical one which I do
> not know the answer to.
>
> From: tirumal reddy
> Sent: 14 October 2022 14:01
>
> On Fri, 14 Oct 2022 at 16:46, tom petch ie...@btconnect.com>> wrote:
> From: tirumal reddy
From: Michael Richardson
Sent: Monday, October 17, 2022 14:24
To: tom petch; Mahesh Jethanandani; net...@ietf.org; opsawg@ietf.org
Subject: Re: [OPSAWG] Augmenting ACLs in mud-tls
tom petch wrote:
> draft-ietf-opsawg-mud-tls augments RFC8519 but while the RFC
> structures its matches as
Re-,
Thanks for the feedback.
I submitted a new version which takes into account the comments received so
far:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-add-encrypted-dns-04.
Please let me know if I missed any of the comments. Thanks.
Cheers,
Med
> -Message
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
Ah, ok. Missed that, as old document was likely before setting up the
registry’s was common.
- Bernie (from iPad)
> On Oct 17, 2022, at 9:00 AM, mohamed.boucad...@orange.com wrote:
>
>
> Re-,
>
> Point taken for the registry.
>
> For 4014bis, the issue is that there is no IANA registry
tom petch wrote:
> draft-ietf-opsawg-mud-tls augments RFC8519 but while the RFC
> structures its matches as a series of choices, the augmentation
> does not. Should it?
What in practice does this mean for the YANG?
> The I-D has passed WGLC but has been delayed by me making
Re-,
Point taken for the registry.
For 4014bis, the issue is that there is no IANA registry for this and that 4014
have only a frozen list of options with SHOULD and like. That text should be
fixed, hence
https://datatracker.ietf.org/doc/draft-boucadair-dhcwg-rfc4014-update/.
Cheers,
Med
De
On Oct 17, 2022, at 7:41 AM, Bernie Volz wrote:
> I was thinking more to put this restriction on the dhcp server, when it makes
> use of the Radius attribute to respond to a client. I have no issue with it
> being limited at configuration too, but the dhcp server should also make sure
> only a
I do think it would be best to set up a registry and policy at the server as to
which it uses.
—-
I saw your 4014 bis, though technically you could have just requested IANA to
add your new radius attribute to the existing registry rather than doing the
bis document.
In this bis document, the
Re-,
Please see inline.
Cheers,
Med
De : Add De la part de Bernie Volz
Envoyé : lundi 17 octobre 2022 13:42
À : BOUCADAIR Mohamed INNOV/NET
Cc : dh...@ietf.org; Joe Clarke (jclarke) ; opsawg
; ADD Mailing list ; rad...@ietf.org
Objet : Re: [Add] [OPSAWG] WG LC: RADIUS Extensions for
Dear authors,
And here is my corresponding AD review of
draft-ietf-opsawg-service-assurance-yang-07. Again, I found the document to be
well-written, with mostly minor comments/suggestions, bar one question about
the symptom reference.
Moderate level comments:
(1) p 11, sec 3.3. YANG
Hi authors,
Here is my AD review of draft-ietf-opsawg-service-assurance-architecture-09. I
would like to thank you and the WG for this document. I believe that this
architecture document, and the corresponding YANG document, offer a good
flexible basis to help with the full lifecycle
I was thinking more to put this restriction on the dhcp server, when it makes
use of the Radius attribute to respond to a client. I have no issue with it
being limited at configuration too, but the dhcp server should also make sure
only a limited set of options are sent to client.
Leaving this
From: OPSAWG on behalf of Thomas Fossati
Sent: 17 October 2022 11:10
Hi, all,
I was asked to bring to the list one comment from my shepherd write-up
[1]; specifically, that draft-ietf-opsawg-mud-tls hasn't been reviewed
by the YANG Doctors (yet).
There seems to be an expectation [2] that the
Hi Med,
On 17/10/2022, 12:01, wrote:
> I don’t see why this draft should be an exception.
Thanks for confirming.
> BTW in addition to the yang doctors review, I suggest to also request
> an early secdir review. Thanks.
I agree and suggested the same in the write-up.
cheers, t
--
IMPORTANT
Hi Thomas,
I don't see why this draft should be an exception.
BTW in addition to the yang doctors review, I suggest to also request an early
secdir review. Thanks.
Cheers,
Med
De : OPSAWG De la part de Thomas Fossati
Envoyé : lundi 17 octobre 2022 12:10
À : opsawg
Objet : [OPSAWG]
draft-ietf-opsawg-mud-tls
augments RFC8519 but while the RFC structures its matches as a series of
choices, the augmentation does not. Should it?
The I-D has passed WGLC but has been delayed by me making editorial comments.
AFAICT the I-D has not had a YANG Doctor review.
Tom Petch
inline one minor editorial comment plus a technical one which I do not
know the answer to.
From: tirumal reddy
Sent: 14 October 2022 14:01
On Fri, 14 Oct 2022 at 16:46, tom petch
mailto:ie...@btconnect.com>> wrote:
From: tirumal reddy mailto:kond...@gmail.com>>
Sent: 14 October 2022 09:22
Hi, all,
I was asked to bring to the list one comment from my shepherd write-up
[1]; specifically, that draft-ietf-opsawg-mud-tls hasn't been reviewed
by the YANG Doctors (yet).
There seems to be an expectation [2] that the YANG Doctor review is
completed before or during WGLC.
I am not sure
Hi Bernie,
Thank you for the feedback.
I have considered a registry to declare the options that can be echoed in the
RADIUS attribute, but I then give it up because that list will be restricted
anyway by policy:
RADIUS implementations may support a configuration parameter to
control the
20 matches
Mail list logo
