Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-mud-tls-07

[tirumal reddy]

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 mailto:kond...@gmail.com>>
> Sent: 14 October 2022 09:22
>
> On Thu, 13 Oct 2022 at 16:55, tom petch  ie...@btconnect.com>>>
> wrote:
> From: tirumal reddy mailto:kond...@gmail.com> kond...@gmail.com>>
> Sent: 13 October 2022 07:57
>
> Thanks Tom for the review. Yes, we will fix the references identified by
> Tom.
>
> 
> -09 looks better.
>
> I still see a mix of TLS-1.2 and TLS-1-2; I am not sure if there is a
> rationale for that.  I prefer the former but that mix of characters may
> confuse others.
>
> Good point, fixed in my copy
> https://github.com/tireddy2/mud-tls/blob/master/draft-ietf-opsawg-mud-tls-10.txt
> .
>
>
> I see a number of editorial issues - I do not know if you want to look at
> those now or leave them to Last Call.
>
> Please feel free to raise the editorial issues, we will fix them.
>
>
> One slightly technical one is that it is very rare to start a YANG prefix
> with ietf as the IANA webpages show - filename, MUST, prefix SHOULD NOT
> IMHO.  Thus acl has a prefix of acl so I would see the augment as acl-tls
> and not ietf-acl-tls; but mud is ietf-mud (unfortunately:-( so the augment
> is perhaps  better as ietf-mud-tls.
>
> We followed the format similar to ietf-access-control-list (YANG data
> model of network ACL) and ietf-mud to be consistent.
>
> 
> Um, that is not what I see.  It is the prefix I have in mind where RFC8519
> specifies a prefix of acl and that is what you use in the import.  An
> extension to that module could then have a prefix of acl-xxx or some such
> where you have specified ietf-acl-tls.  It is that 'ietf' that I see as
> unusual.
>
> Got it, changed the prefix to "acl-tls".
>
>
> Editorially, not all of which you may want to fix at this time
>
> 'The YANG module specified in Section 5...'
> suggest adding the subsection since there is more than one
>
> 'specific terms are used'
> suggest using the terms here e.g. TLS and DTLS are used
>
> s.4
> incapable to decipher
> perhaps 'unable to decipher' or 'incapable of deciphering'
>
> s.5.1
> Add an Infornative Reference to RFC8340 for the meaning of tree diagrams
>
> s.5.2
> /Simplified BSD/Revised BSD/
>
> revision date is out of date
>
> SPKI probably needs expanding both in the body and in the YANG modules
>
> The description of certificate-authorities looks like it is too long for
> an RFC
>
> s.5.3
> BSD license again
>
> revision date again
>
> s.5.4
> ditto
>
> author e-mail address is not the same as elsewhere
>
> YANG import MUST have a reference clause which MUST be a Normative
> reference
>
> Thanks, I fixed all the above editorial issues.
>
> 
> Almost.  I am still seeing a YANG import in s.5.4 which has no reference
> clause.
>

Thanks, fixed in git repo.


>
> Also, there is a technical YANG issue to which I do not know the answer
> and have posted that to the netmod list.  AFAICT there has been no YANG
> Doctor review and it is an issue that at least some YANG Doctors would
> comment on
>

We will publish the revised version after the review from YANG Doctor and
the response to your question in netmod list.

Cheers,
-Tiru


>
> Tom Petch
>
> does profile-supported have a default ?
>
> No.
>
>
> s.8
> There is a template for YANG security as referenced by RFC8407 which I
> note is not used here
>
> Thanks, added note that it is not applicable to draft as it is not meant
> to be accessed via NETCONF/RESTCONF..
>
>
> s.9
> I note that this is TLS and not (D)TLS. Is that intended?  s.4 uses the
> latter
>
> Fixed, it is supposed to be (D)TLS.
>
>
> s.10
> When specifying Expert Review, guidance is often given as to what the
> experts should look for and where.
>
> Yes, I added details for Expert Review..
>
> Cheers,
> -Tiru
>
>
> Tom Petch
>
>
>
>
>
> Cheers,
> -Tiru
>
>
>
> Tom Petch
>
> Cheers,
> -Tiru
>
> On Wed, 12 Oct 2022 at 18:37, Henk Birkholz <
> henk.birkh...@sit.fraunhofer.de >>  henk.birkh...@sit.fraunhofer.de wrote:
> Hi Tom,
>
> would it be possible for you to augment your first comment with change
> proposals, if possible?
>
> @authors: it seems to me that the references issues Tom now provided in
> specific detail could be resolved in this thread in a timely manner. Is
> that correct?
>
> Viele Grüße,
>
> Henk
>
> On 12.10.22 13:39, tom petch wrote:
> > From: OPSAWG mailto:opsawg-boun...@ietf.org
> >> 

Re: [OPSAWG] Augmenting ACLs in mud-tls

[tom petch]

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 a series of choices, the augmentation
> does not.  Should it?

What in practice does this mean for the YANG?


RFC8519 has
container matches {
  choice l2 { container eth
...
  choice l3 {
and so on.

This I-D has
  augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" {
container client-profile {

By contrast, when
  draft-ietf-teas-yang-te-30
is augmented by
  draft-ietf-ccamp-flexigrid-tunnel-yang-01
then the augment is
  augment "/te:te/te:globals/te:named-path-constraints/" +
  "te:named-path-constraint/" +
  "te:explicit-route-objects-always/" +
  "te:route-object-exclude-always/te:type/te:label/" +
  "te:label-hop/te:te-label/te:technology"
 case flexi-grid {
 uses l0-types:flexi-grid-label-hop;

where te:technology from RFC8776 is
  choice technology { default "generic";
 case generic {
ie a case is being augmented to a choice alongside other cases and there are 
many such instances in CCAMP and TEAS of adding case for different technology.

This I-D augments 'container matches' with a YANG container so the choice/case 
as used in other uses of ACLs is not used; legal YANG but I do not know if that 
is the intent of the authors of RFC8519.

Tom Petch



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

Seems that this should have happened.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-



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

Re: [OPSAWG] [dhcwg] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[mohamed.boucadair]

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 d'origine-
> De : Alan DeKok 
> Envoyé : lundi 17 octobre 2022 14:51
> À : Bernie Volz 
> Cc : BOUCADAIR Mohamed INNOV/NET ;
> dh...@ietf.org; Joe Clarke (jclarke) ; opsawg
> ; ADD Mailing list ;
> rad...@ietf.org
> Objet : Re: [dhcwg] [Add] [OPSAWG]  WG LC: RADIUS Extensions for
> Encrypted DNS
> 
> 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 limited set of
> options are sent to client.
> >
> > Leaving this wide open causes issues as it may be miss used to
> inject things that really shouldn’t be.
> 
>   I agree.  There should be a limited set of options which are
> allowed, perhaps via a registry.
> 
> > Looking at it again, it is also unclear how a dhcp server is to
> use information. For example, does the server use options from
> this information before its own configuration or only if it has no
> configuration (I suspect the former, as this is more
> client/request specific).
> 
>   That should be made explicit in the draft.  I don't have
> opinions either way, but your point makes sense.
> 
> > And from RFC7037, there is
> >
> > 169DNS-Server-IPv6-Address [RFC6911]
> >
> > Does this mean someone could now place the DNS server option
> into your new Radius attribute instead of using this attribute to
> have the server map it to the DHCP option?
> 
>   If it's allowed by the registry, presumably, yes.  RFFC 6911
> says that those RADIUS attributes can appear multiple times.  So
> presumably it doesn't matter much if the DNS server information
> appears once in a RADIUS attribute, and separately in a DHCPv6-
> Options attribute.  They can all be added to the packets.
> 
>   i.e. if the administrator of the system configures something
> weird, the systems should just do what's asked.
> 
>   Anything past basic filtering is complex to define, and complex
> to implement.  And arguably doesn't have a lot of extra value.
> 
>   Alan DeKok.


_

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

[OPSAWG] I-D Action: draft-ietf-opsawg-add-encrypted-dns-04.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
  Filename: draft-ietf-opsawg-add-encrypted-dns-04.txt
  Pages   : 15
  Date: 2022-10-17

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.


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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-add-encrypted-dns-04


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] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[Bernie Volz]

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 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 : Add  De la part de Bernie Volz
> Envoyé : lundi 17 octobre 2022 14:49
> À : 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 Encrypted DNS
>  
> 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 new table entry is a bit odd:
>  
> 245.TBA1  | DHCPv4-Options   | This-Document |
>  
> As “this document” doesn’t define that new attribute, and not even TBA1 (that 
> is only reference).
>  
> It may be better to just add an update to the Allowed Radius attributrs table 
> to the document that defines the new Radius attributes, rather than 2 
> documents?
>  
> - Bernie Volz
> 
> 
> On Oct 17, 2022, at 8:08 AM, mohamed.boucad...@orange.com wrote:
> 
> 
> 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 Encrypted DNS
>  
> 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.
> [Med] I think that this is similar to any guards used for consuming 
> conventional radius attributes. What differs in the proposed attribute is 
> just the encoding, not how this feeds the DHCP server logic, but …
>  
> 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.
> [Med] … it is OK to add an explicit statement about a policy to control this 
> at the DHCP server side.
> 
> 
> Leaving this wide open causes issues as it may be miss used to inject things 
> that really shouldn’t be.
> [Med] OK.
>  
>  
> Looking at it again, it is also unclear how a dhcp server is to use 
> information. For example, does the server use options from this information 
> before its own configuration or only if it has no configuration (I suspect 
> the former, as this is more client/request specific).
> [Med] The logic at the server side is the same as how “conventional” RADIUS 
> attributes are consumed by DHCP server.
>  
> And from RFC7037, there is
>  
> 169DNS-Server-IPv6-Address [RFC6911]
>  
> Does this mean someone could now place the DNS server option into your new 
> Radius attribute instead of using this attribute to have the server map it to 
> the DHCP option?
> [Med] The expectation is that this will be used to mimic future DHCPv6 
> options, not those already governed by dedicated RADIUS attributes.
>  
>  
> It seems to me that the reason for doing this is to handle the OPTION_V6_DNR 
> only, so maybe best to restrict just to this for now? Future documents could 
> add more to registry for options allowed.
> [Med] I don’t have an objection to define a registry if you think this is 
> “safer”. Please advise.
>  
>  
> - Bernie (from iPad)
> 
> 
> 
> On Oct 17, 2022, at 2:15 AM, mohamed.boucad...@orange.com wrote:
> 
> 
> 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 DHCP options that can be included in a DHCP*-Options
>RADIUS attribute.
>  
> Cheers,
> Med
>  
> De : Add  De la part de Bernie Volz
> Envoyé : vendredi 14 octobre 2022 17:48
> À : 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 Encrypted DNS
>  
> Hi:
>  
> Your github document is -03 and published is -03, so likely you want to make 
> it -04?
>  
> As no dhcp options are being defined and they are just being encapsulated in 
> Radius attributes, not exactly sure how much the DHC wg can (or needs to) 
> comment?
>  
> This basically changes things so you no longer have unique Radius attributes 
> that are 

Re: [OPSAWG] Augmenting ACLs in mud-tls

[Michael Richardson]

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
> editorial comments.  AFAICT the I-D has not had a YANG Doctor
> review.

Seems that this should have happened.

-- 
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[mohamed.boucadair]

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 : Add  De la part de Bernie Volz
Envoyé : lundi 17 octobre 2022 14:49
À : 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 Encrypted DNS

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 new table entry is a bit odd:


245.TBA1  | DHCPv4-Options   | This-Document |


As “this document” doesn’t define that new attribute, and not even TBA1 (that 
is only reference).

It may be better to just add an update to the Allowed Radius attributrs table 
to the document that defines the new Radius attributes, rather than 2 documents?

- Bernie Volz


On Oct 17, 2022, at 8:08 AM, 
mohamed.boucad...@orange.com wrote:

Re-,

Please see inline.

Cheers,
Med

De : Add mailto:add-boun...@ietf.org>> De la part de 
Bernie Volz
Envoyé : lundi 17 octobre 2022 13:42
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : dh...@ietf.org; Joe Clarke (jclarke) 
mailto:jcla...@cisco.com>>; opsawg 
mailto:opsawg@ietf.org>>; ADD Mailing list 
mailto:a...@ietf.org>>; rad...@ietf.org
Objet : Re: [Add] [OPSAWG]  WG LC: RADIUS Extensions for Encrypted DNS

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.
[Med] I think that this is similar to any guards used for consuming 
conventional radius attributes. What differs in the proposed attribute is just 
the encoding, not how this feeds the DHCP server logic, but …

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.
[Med] … it is OK to add an explicit statement about a policy to control this at 
the DHCP server side.


Leaving this wide open causes issues as it may be miss used to inject things 
that really shouldn’t be.
[Med] OK.


Looking at it again, it is also unclear how a dhcp server is to use 
information. For example, does the server use options from this information 
before its own configuration or only if it has no configuration (I suspect the 
former, as this is more client/request specific).
[Med] The logic at the server side is the same as how “conventional” RADIUS 
attributes are consumed by DHCP server.

And from RFC7037, there is



169DNS-Server-IPv6-Address [RFC6911]

Does this mean someone could now place the DNS server option into your new 
Radius attribute instead of using this attribute to have the server map it to 
the DHCP option?
[Med] The expectation is that this will be used to mimic future DHCPv6 options, 
not those already governed by dedicated RADIUS attributes.


It seems to me that the reason for doing this is to handle the OPTION_V6_DNR 
only, so maybe best to restrict just to this for now? Future documents could 
add more to registry for options allowed.
[Med] I don’t have an objection to define a registry if you think this is 
“safer”. Please advise.



- Bernie (from iPad)



On Oct 17, 2022, at 2:15 AM, 
mohamed.boucad...@orange.com wrote:

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 DHCP options that can be included in a DHCP*-Options
   RADIUS attribute.

Cheers,
Med

De : Add mailto:add-boun...@ietf.org>> De la part de 
Bernie Volz
Envoyé : vendredi 14 octobre 2022 17:48
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : dh...@ietf.org; Joe Clarke (jclarke) 
mailto:jcla...@cisco.com>>; opsawg 
mailto:opsawg@ietf.org>>; ADD Mailing list 
mailto:a...@ietf.org>>; rad...@ietf.org
Objet : Re: [Add] [OPSAWG]  WG LC: RADIUS Extensions for Encrypted DNS

Hi:

Your github document is -03 and published is -03, so likely you want to make it 
-04?

As no dhcp options are being defined and they are just being encapsulated in 
Radius attributes, not exactly sure how much the DHC wg can (or needs to) 
comment?

This basically changes things so you no longer have unique Radius attributes 
that are mapped to DHCP options, but you just use the DHCP 

Re: [OPSAWG] [dhcwg] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[Alan DeKok]

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 limited set of options are sent to client.
> 
> Leaving this wide open causes issues as it may be miss used to inject things 
> that really shouldn’t be.

  I agree.  There should be a limited set of options which are allowed, perhaps 
via a registry.

> Looking at it again, it is also unclear how a dhcp server is to use 
> information. For example, does the server use options from this information 
> before its own configuration or only if it has no configuration (I suspect 
> the former, as this is more client/request specific).

  That should be made explicit in the draft.  I don't have opinions either way, 
but your point makes sense.

> And from RFC7037, there is
> 
> 169DNS-Server-IPv6-Address [RFC6911]
> 
> Does this mean someone could now place the DNS server option into your new 
> Radius attribute instead of using this attribute to have the server map it to 
> the DHCP option?

  If it's allowed by the registry, presumably, yes.  RFFC 6911 says that those 
RADIUS attributes can appear multiple times.  So presumably it doesn't matter 
much if the DNS server information appears once in a RADIUS attribute, and 
separately in a DHCPv6-Options attribute.  They can all be added to the packets.

  i.e. if the administrator of the system configures something weird, the 
systems should just do what's asked.

  Anything past basic filtering is complex to define, and complex to implement. 
 And arguably doesn't have a lot of extra value.

  Alan DeKok.

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

Re: [OPSAWG] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[Bernie Volz]

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 new table entry is a bit odd:

245.TBA1  | DHCPv4-Options   | This-Document |

As “this document” doesn’t define that new attribute, and not even TBA1 (that 
is only reference).

It may be better to just add an update to the Allowed Radius attributrs table 
to the document that defines the new Radius attributes, rather than 2 documents?

- Bernie Volz

> On Oct 17, 2022, at 8:08 AM, mohamed.boucad...@orange.com wrote:
> 
> 
> 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 Encrypted DNS
>  
> 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.
> [Med] I think that this is similar to any guards used for consuming 
> conventional radius attributes. What differs in the proposed attribute is 
> just the encoding, not how this feeds the DHCP server logic, but …
>  
> 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.
> [Med] … it is OK to add an explicit statement about a policy to control this 
> at the DHCP server side.
> 
> 
> Leaving this wide open causes issues as it may be miss used to inject things 
> that really shouldn’t be.
> [Med] OK.
>  
>  
> Looking at it again, it is also unclear how a dhcp server is to use 
> information. For example, does the server use options from this information 
> before its own configuration or only if it has no configuration (I suspect 
> the former, as this is more client/request specific).
> [Med] The logic at the server side is the same as how “conventional” RADIUS 
> attributes are consumed by DHCP server.
>  
> And from RFC7037, there is
>  
> 169DNS-Server-IPv6-Address [RFC6911]
>  
> Does this mean someone could now place the DNS server option into your new 
> Radius attribute instead of using this attribute to have the server map it to 
> the DHCP option?
> [Med] The expectation is that this will be used to mimic future DHCPv6 
> options, not those already governed by dedicated RADIUS attributes.
>  
>  
> It seems to me that the reason for doing this is to handle the OPTION_V6_DNR 
> only, so maybe best to restrict just to this for now? Future documents could 
> add more to registry for options allowed.
> [Med] I don’t have an objection to define a registry if you think this is 
> “safer”. Please advise.
>  
>  
> - Bernie (from iPad)
> 
> 
> On Oct 17, 2022, at 2:15 AM, mohamed.boucad...@orange.com wrote:
> 
> 
> 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 DHCP options that can be included in a DHCP*-Options
>RADIUS attribute.
>  
> Cheers,
> Med
>  
> De : Add  De la part de Bernie Volz
> Envoyé : vendredi 14 octobre 2022 17:48
> À : 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 Encrypted DNS
>  
> Hi:
>  
> Your github document is -03 and published is -03, so likely you want to make 
> it -04?
>  
> As no dhcp options are being defined and they are just being encapsulated in 
> Radius attributes, not exactly sure how much the DHC wg can (or needs to) 
> comment?
>  
> This basically changes things so you no longer have unique Radius attributes 
> that are mapped to DHCP options, but you just use the DHCP options directly. 
> This seems fine. (It does complicate the Radius configuration to handle DHCP 
> option configuration if you don’t want them to be hand encoded as octet data, 
> and many of the encoding/validation rules are not as consistent as we would 
> like, especially for older options.)
>  
> The one concern for DHC wg may be to restrict the options that a DHCP server 
> can send out if these options are intended to be delivered to the client via 
> the dhcp server … for example, one would not want address or prefix 
> delegation options to be allowed. This might be something similar to 
> https://datatracker.ietf.org/doc/rfc6422/ which created a new registry for 
> the allowed DHCPv6 options that can be provided by a relay agent (in this 
> case encoded in the attributes).
> 
> - 

Re: [OPSAWG] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[mohamed.boucadair]

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 Encrypted DNS

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.
[Med] I think that this is similar to any guards used for consuming 
conventional radius attributes. What differs in the proposed attribute is just 
the encoding, not how this feeds the DHCP server logic, but …

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.
[Med] … it is OK to add an explicit statement about a policy to control this at 
the DHCP server side.


Leaving this wide open causes issues as it may be miss used to inject things 
that really shouldn’t be.
[Med] OK.


Looking at it again, it is also unclear how a dhcp server is to use 
information. For example, does the server use options from this information 
before its own configuration or only if it has no configuration (I suspect the 
former, as this is more client/request specific).
[Med] The logic at the server side is the same as how “conventional” RADIUS 
attributes are consumed by DHCP server.

And from RFC7037, there is



169DNS-Server-IPv6-Address [RFC6911]

Does this mean someone could now place the DNS server option into your new 
Radius attribute instead of using this attribute to have the server map it to 
the DHCP option?
[Med] The expectation is that this will be used to mimic future DHCPv6 options, 
not those already governed by dedicated RADIUS attributes.


It seems to me that the reason for doing this is to handle the OPTION_V6_DNR 
only, so maybe best to restrict just to this for now? Future documents could 
add more to registry for options allowed.
[Med] I don’t have an objection to define a registry if you think this is 
“safer”. Please advise.



- Bernie (from iPad)


On Oct 17, 2022, at 2:15 AM, 
mohamed.boucad...@orange.com wrote:

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 DHCP options that can be included in a DHCP*-Options
   RADIUS attribute.

Cheers,
Med

De : Add mailto:add-boun...@ietf.org>> De la part de 
Bernie Volz
Envoyé : vendredi 14 octobre 2022 17:48
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : dh...@ietf.org; Joe Clarke (jclarke) 
mailto:jcla...@cisco.com>>; opsawg 
mailto:opsawg@ietf.org>>; ADD Mailing list 
mailto:a...@ietf.org>>; rad...@ietf.org
Objet : Re: [Add] [OPSAWG]  WG LC: RADIUS Extensions for Encrypted DNS

Hi:

Your github document is -03 and published is -03, so likely you want to make it 
-04?

As no dhcp options are being defined and they are just being encapsulated in 
Radius attributes, not exactly sure how much the DHC wg can (or needs to) 
comment?

This basically changes things so you no longer have unique Radius attributes 
that are mapped to DHCP options, but you just use the DHCP options directly. 
This seems fine. (It does complicate the Radius configuration to handle DHCP 
option configuration if you don’t want them to be hand encoded as octet data, 
and many of the encoding/validation rules are not as consistent as we would 
like, especially for older options.)

The one concern for DHC wg may be to restrict the options that a DHCP server 
can send out if these options are intended to be delivered to the client via 
the dhcp server … for example, one would not want address or prefix delegation 
options to be allowed. This might be something similar to 
https://datatracker.ietf.org/doc/rfc6422/ which created a new registry for the 
allowed DHCPv6 options that can be provided by a relay agent (in this case 
encoded in the attributes).
- Bernie Volz



On Oct 14, 2022, at 10:45 AM, 
mohamed.boucad...@orange.com wrote:
Hi Bernie, dhcwg,

We received a comment during the WGLC of this draft that might lead us to 
revisit the design you have reviewed recently. This alternative design mirrors 
what we have done in 7037 (dhcwg) but with DHCP options included in RADIUS. The 
candidate text is available at:

https://github.com/boucadair/draft-ietf-opsawg-add-encrypted-dns/blob/main/draft-ietf-opsawg-add-encrypted-dns-encap.txt

I'd appreciate if you can review this proposal and share any comments/issues 
you may have.

Thank you.

Cheers,
Med



-Message d'origine-
De : BOUCADAIR Mohamed INNOV/NET
Envoyé : vendredi 14 octobre 2022 

[OPSAWG] AD review of draft-ietf-opsawg-service-assurance-yang-07

[Rob Wilton (rwilton)]

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 Module

  grouping symptom {
description
  "A grouping for the symptoms for a specific subservice.";
leaf symptom-id {
  type leafref {
path "/agents/symptoms-description/symptom-id";
  }
  description
"Identifier of the symptom, to be interpreted according
 to the agent identified by the agent-id.";
}

Should this path be constrained to the specific agent instance identified by 
agent-id?  E.g., similar to how the 'id' path is constrained in 
subservice-reference below.



Minor level comments:

(2) p 2, sec 1.  Introduction

   *  augmentable

Perhaps tie this back to Figure 1 in the SAIN Architecture, which highlights 
the APIs that are documented as YANG modules.


(3) p 4, sec 3.1.  Concepts

   The dependencies are modelled as an adjacency list, in the sense that
   each subservice contains a list of pointers to its dependencies.
   That list can be empty if the subservice instance does not have any
   dependencies.

Perhaps 'references' would be better than 'pointers'.


(4) p 5, sec 3.2.  Tree View

   module: ietf-service-assurance
 +--ro assurance-graph-last-changeyang:date-and-time
 +--rw subservices
 |  +--rw subservice* [type id]
 | +--rw typeidentityref
 | +--rw id  string

I don't really like to mess with the structure of YANG modules during AD (or 
IESG) review, but I wonder whether having type as part of the subservice key 
doesn't end up making it more cumbersome to refer to subservices, and whether a 
flat id space might be better (i.e., removing 'type' from the subservice list 
keys).  But I also don't mind if the author/WG do not want to change the 
structure at this stage.


(5) p 5, sec 3.2.  Tree View

 | +--ro last-change?yang:date-and-time
 | +--ro label?  string
 | +--rw maintenance-contact?string
 | +--rw (parameter)
 | |  +--:(service-instance-parameter)
 | | +--rw service-instance-parameter
 | |+--rw service  string
 | |+--rw instance-namestring
 | +--ro health-score?   union
 | +--ro symptoms-history-start? yang:date-and-time
 | +--ro symptoms
 | |  +--ro symptom* [start-date-time agent-id symptom-id]
 | | +--ro symptom-id
 | | |   -> /agents/symptoms-description/symptom-id
 | | +--ro agent-id   -> /agents/agent-id
 | | +--ro health-score-weight?   uint8
 | | +--ro start-date-timeyang:date-and-time
 | | +--ro stop-date-time?yang:date-and-time
 | +--rw dependencies
 |+--rw dependency* [type id]
 |   +--rw type
 |   |   -> /subservices/subservice/type
 |   +--rw id leafref
 |   +--rw dependency-type?   identityref
 +--ro agents* [agent-id]
 |  +--ro agent-idstring

As a consistency nit, I note that you use "agent-id" here and just "id" under 
subservice.  Possibly using "id" here would be more consistent.  Same comment 
applies to "symptom-id" below.


(6) p 5, sec 3.2.  Tree View

 |  +--ro symptoms-description* [symptom-id]
 | +--ro symptom-id string
 | +--ro descriptionstring

Similar comment as above, did you consider just calling the list "symptoms", 
and the 'symptom-id' just 'id'


(7) p 5, sec 3.2.  Tree View

 +--ro assured-services* [service]
+--ro service  leafref
+--ro instances* [instance-name]
   +--ro instance-nameleafref

Same comment as above, possibly "name" would be sufficient rather than 
"instance-name".


(8) p 5, sec 3.2.  Tree View

   +--ro subservices* [type id]
  +--ro type-> /subservices/subservice/type
  +--ro id  leafref

A couple more consistency questions:
1) I note that subservices has been put into a container, but that agents, 
assured-services are not.
2) The "subservice" list is the singular tense (presumably because it is under 
a container), but agents, assured-services and subservices are not.  I know 
that you have to optimize for XML or JSON readability.


(9) p 6, sec 3.2.  Tree View

   +--ro subservices* [type id]
  +--ro type-> /subservices/subservice/type
  +--ro id  leafref
   The date of last change "assurance-graph-last-change" is read only.
   It must be updated each time the graph structure is changed by
   addition 

[OPSAWG] AD Review of draft-ietf-opsawg-service-assurance-architecture-09

[Rob Wilton (rwilton)]

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 monitoring of deployed services.

Here are my comments which may help improve the document.


Minor level comments:

(1) p 3, sec 1.  Introduction

   The assurance graph of a service is decomposed into components, which
   are then assured independently.  The root of the assurance graph
   represents the service to assure, and its children represent
   components identified as its direct dependencies; each component can
   have dependencies as well.  Components involved in the assurance
   graph of a service are called subservices.  The SAIN orchestrator
   updates automatically the assurance graph when services are modified.

I was wondering if you meant services or subservices in the last sentence?


(2) p 3, sec 1.  Introduction

   When a service is degraded, the SAIN architecture will highlight
   where in the assurance service graph to look, as opposed to going hop
   by hop to troubleshoot the issue.  More precisely, the SAIN
   architecture will associate to each service a list of symptoms
   originating from specific subservices, corresponding to components of
   the network.  These components are good candidates for explaining the
   source of a service degradation.  Not only can this architecture help
   to correlate service degradation with network root cause/symptoms,
   but it can deduce from the assurance graph the number and type of
   services impacted by a component degradation/failure.  This added
   value informs the operational team where to focus its attention for
   maximum return.  Indeed, the operational team should focus his
   priority on the degrading/failing components impacting the highest
   number customers, especially the ones with the SLA contracts
   involving penalties in case of failure.

Rather than "should focus", perhaps "may focus" or "are likely to focus".  
Also, his => their, number customers -> number of customers


(3) p 4, sec 2.  Terminology

   SAIN agent: A functional component that communicates with a device, a
   set of devices, or another agent to build an expression graph from a
   received assurance graph and perform the corresponding computation of
   the health status and symptoms.

Perhaps consider whether stating that the SAIN agent could run directly on the 
device?  Although I noted that this is described later in the document anyway.


(4) p 5, sec 2.  Terminology

   Metric: An information retrieved from the network running the assured
   service.

Suggest An item of information retrieved, or a piece of data retrieved.


(5) p 5, sec 2.  Terminology

   Health score: Integer ranging from 0 to 100 indicating the health of
   a subservice.  A score of 0 means that the subservice is broken, a
   score of 100 means that the subservice in question is operating as
   expected.

I noted that neither the architecture nor the YANG talk about mapping discrete 
properties (e.g., interface up/down). I would intuitively think that these 
would map to a value of 100 and 0 respectively.  Would it be helpful to add any 
text to describe how binary properties are handled?


(6) p 6, sec 3.  A Functional Architecture

   The goal of SAIN is to assure that service instances are operating as
   expected (i.e. the observed service is matching the expected service)
   and if not, to pinpoint what is wrong.  More precisely, SAIN computes
   a score for each service instance and outputs symptoms explaining
   that score.  Symptoms explain the score.  The only valid situation
   where no symptoms are returned is when the score is maximal,
   indicating that no issues where detected for that service.  The score
   augmented with the symptoms is called the health status.

Symptoms explain the score seems to be a duplicate and can be removed.


(7) p 6, sec 3.  A Functional Architecture

   The SAIN architecture is a generic architecture, applicable to
   multiple environments (e.g. wireline, wireless), but also different
   domains (e.g. 5G network function virtualization (NFV) domain with a
   virtual infrastructure manager (VIM)), etc.  And as already noted,
   for physical or virtual devices, as well as virtual functions.
   Thanks to the distributed graph design principle, graphs from
   different environments/orchestrator can be combined together.

perhaps: combined together -> combined together for a given service.


(8) p 7, sec 3.  A Functional Architecture

  +-+
  | Service |
  | Orchestrator|<+
  | | |
  +-+ |
 |^   |
 || Network   |

Re: [OPSAWG] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[Bernie Volz]

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 wide open causes issues as it may be miss used to inject things 
that really shouldn’t be.


Looking at it again, it is also unclear how a dhcp server is to use 
information. For example, does the server use options from this information 
before its own configuration or only if it has no configuration (I suspect the 
former, as this is more client/request specific).

And from RFC7037, there is

169DNS-Server-IPv6-Address [RFC6911]

Does this mean someone could now place the DNS server option into your new 
Radius attribute instead of using this attribute to have the server map it to 
the DHCP option?


It seems to me that the reason for doing this is to handle the OPTION_V6_DNR 
only, so maybe best to restrict just to this for now? Future documents could 
add more to registry for options allowed.

- Bernie (from iPad)

> On Oct 17, 2022, at 2:15 AM, mohamed.boucad...@orange.com wrote:
> 
> 
> 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 DHCP options that can be included in a DHCP*-Options
>RADIUS attribute.
>  
> Cheers,
> Med
>  
> De : Add  De la part de Bernie Volz
> Envoyé : vendredi 14 octobre 2022 17:48
> À : 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 Encrypted DNS
>  
> Hi:
>  
> Your github document is -03 and published is -03, so likely you want to make 
> it -04?
>  
> As no dhcp options are being defined and they are just being encapsulated in 
> Radius attributes, not exactly sure how much the DHC wg can (or needs to) 
> comment?
>  
> This basically changes things so you no longer have unique Radius attributes 
> that are mapped to DHCP options, but you just use the DHCP options directly. 
> This seems fine. (It does complicate the Radius configuration to handle DHCP 
> option configuration if you don’t want them to be hand encoded as octet data, 
> and many of the encoding/validation rules are not as consistent as we would 
> like, especially for older options.)
>  
> The one concern for DHC wg may be to restrict the options that a DHCP server 
> can send out if these options are intended to be delivered to the client via 
> the dhcp server … for example, one would not want address or prefix 
> delegation options to be allowed. This might be something similar to 
> https://datatracker.ietf.org/doc/rfc6422/ which created a new registry for 
> the allowed DHCPv6 options that can be provided by a relay agent (in this 
> case encoded in the attributes).
> 
> - Bernie Volz
> 
> 
> On Oct 14, 2022, at 10:45 AM, mohamed.boucad...@orange.com wrote:
> 
> Hi Bernie, dhcwg, 
> 
> We received a comment during the WGLC of this draft that might lead us to 
> revisit the design you have reviewed recently. This alternative design 
> mirrors what we have done in 7037 (dhcwg) but with DHCP options included in 
> RADIUS. The candidate text is available at: 
> 
> https://github.com/boucadair/draft-ietf-opsawg-add-encrypted-dns/blob/main/draft-ietf-opsawg-add-encrypted-dns-encap.txt
> 
> I'd appreciate if you can review this proposal and share any comments/issues 
> you may have.
> 
> Thank you.
> 
> Cheers,
> Med
> 
> 
> -Message d'origine-
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : vendredi 14 octobre 2022 16:32
> À : 'Alan DeKok' 
> Cc : Ben Schwartz ; Joe Clarke (jclarke)
> ; opsawg ; rad...@ietf.org;
> ADD Mailing list 
> Objet : RE: [Add] [OPSAWG]  WG LC: RADIUS Extensions for
> Encrypted DNS
>  
> Re-,
>  
> Works for me. Thanks.
>  
> I will run this candidate version with dhcwg as well.
>  
> Cheers,
> Med
>  
> -Message d'origine-
> De : Alan DeKok  Envoyé : vendredi 14
> octobre 2022 16:00 À : BOUCADAIR Mohamed INNOV/NET
>  Cc : Ben Schwartz
> ;
> Joe Abley ; Ben Schwartz
> ; Joe Clarke (jclarke)
> ; opsawg ; rad...@ietf.org;
> ADD
> Mailing list  Objet : Re: [Add] [OPSAWG]  WG LC:
> RADIUS Extensions for Encrypted DNS
>  
>  
> On Oct 14, 2022, at 5:47 AM, 
>  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
> 

Re: [OPSAWG] draft-ietf-opsawg-mud-tls YANG Doctor review

[tom petch]

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 YANG Doctor review is
completed before or during WGLC.

I am not sure whether the expectation is still current, or needs to be
relaxed for some reasons.  This is also of interest to me because I am
new to the shepherding process and I'd like to understand what are the
(best) current practices in the YANG area.


Ships in the Night.

I have posted a comment about the lack of a YANG choice in the augmentation to 
RFC8519 in this I-D on the netmod list and to Mahesh as the author of RFC8519.

One of the earlier revisions had a number of changes in it that looked very 
YANG Doctor-ish to me so I thought that someone had had a look at it even if 
the datatracker records no review.

Tom Petch

Cheers, thanks.
t

[1] https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/shepherdwriteup/
[2] https://trac.ietf.org/trac/ops/wiki/yang-doctors-review#Purpose

--

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

Re: [OPSAWG] draft-ietf-opsawg-mud-tls YANG Doctor review

[Thomas Fossati]

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 NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] draft-ietf-opsawg-mud-tls YANG Doctor review

[mohamed.boucadair]

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 YANG Doctor review

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 whether the expectation is still current, or needs to be
relaxed for some reasons.  This is also of interest to me because I am
new to the shepherding process and I'd like to understand what are the
(best) current practices in the YANG area.

Cheers, thanks.
t

[1] https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/shepherdwriteup/
[2] https://trac.ietf.org/trac/ops/wiki/yang-doctors-review#Purpose

--

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

_

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

[OPSAWG] Augmenting ACLs in mud-tls

[tom petch]

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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-mud-tls-07

[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

On Thu, 13 Oct 2022 at 16:55, tom petch 
mailto:ie...@btconnect.com>>>
 wrote:
From: tirumal reddy 
mailto:kond...@gmail.com>>>
Sent: 13 October 2022 07:57

Thanks Tom for the review. Yes, we will fix the references identified by Tom.


-09 looks better.

I still see a mix of TLS-1.2 and TLS-1-2; I am not sure if there is a rationale 
for that.  I prefer the former but that mix of characters may confuse others.

Good point, fixed in my copy 
https://github.com/tireddy2/mud-tls/blob/master/draft-ietf-opsawg-mud-tls-10.txt.


I see a number of editorial issues - I do not know if you want to look at those 
now or leave them to Last Call.

Please feel free to raise the editorial issues, we will fix them.


One slightly technical one is that it is very rare to start a YANG prefix with 
ietf as the IANA webpages show - filename, MUST, prefix SHOULD NOT IMHO.  Thus 
acl has a prefix of acl so I would see the augment as acl-tls and not 
ietf-acl-tls; but mud is ietf-mud (unfortunately:-( so the augment is perhaps  
better as ietf-mud-tls.

We followed the format similar to ietf-access-control-list (YANG data model of 
network ACL) and ietf-mud to be consistent.


Um, that is not what I see.  It is the prefix I have in mind where RFC8519 
specifies a prefix of acl and that is what you use in the import.  An extension 
to that module could then have a prefix of acl-xxx or some such where you have 
specified ietf-acl-tls.  It is that 'ietf' that I see as unusual.

Got it, changed the prefix to "acl-tls".


Editorially, not all of which you may want to fix at this time

'The YANG module specified in Section 5...'
suggest adding the subsection since there is more than one

'specific terms are used'
suggest using the terms here e.g. TLS and DTLS are used

s.4
incapable to decipher
perhaps 'unable to decipher' or 'incapable of deciphering'

s.5.1
Add an Infornative Reference to RFC8340 for the meaning of tree diagrams

s.5.2
/Simplified BSD/Revised BSD/

revision date is out of date

SPKI probably needs expanding both in the body and in the YANG modules

The description of certificate-authorities looks like it is too long for an RFC

s.5.3
BSD license again

revision date again

s.5.4
ditto

author e-mail address is not the same as elsewhere

YANG import MUST have a reference clause which MUST be a Normative reference

Thanks, I fixed all the above editorial issues.


Almost.  I am still seeing a YANG import in s.5.4 which has no reference clause.

Also, there is a technical YANG issue to which I do not know the answer and 
have posted that to the netmod list.  AFAICT there has been no YANG Doctor 
review and it is an issue that at least some YANG Doctors would comment on

Tom Petch

does profile-supported have a default ?

No.


s.8
There is a template for YANG security as referenced by RFC8407 which I note is 
not used here

Thanks, added note that it is not applicable to draft as it is not meant to be 
accessed via NETCONF/RESTCONF..


s.9
I note that this is TLS and not (D)TLS. Is that intended?  s.4 uses the latter

Fixed, it is supposed to be (D)TLS.


s.10
When specifying Expert Review, guidance is often given as to what the experts 
should look for and where.

Yes, I added details for Expert Review..

Cheers,
-Tiru


Tom Petch





Cheers,
-Tiru



Tom Petch

Cheers,
-Tiru

On Wed, 12 Oct 2022 at 18:37, Henk Birkholz 
mailto:henk.birkh...@sit.fraunhofer.de>> From: OPSAWG 
> mailto:opsawg-boun...@ietf.org>>  on behalf of Henk Birkholz 
> mailto:henk.birkh...@sit.fraunhofer.de>> Sent: 06 October 2022 13:26
>
> Dear authors and 

[OPSAWG] draft-ietf-opsawg-mud-tls YANG Doctor review

[Thomas Fossati]

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 whether the expectation is still current, or needs to be
relaxed for some reasons.  This is also of interest to me because I am
new to the shepherding process and I'd like to understand what are the
(best) current practices in the YANG area.

Cheers, thanks.
t

[1] https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/shepherdwriteup/
[2] https://trac.ietf.org/trac/ops/wiki/yang-doctors-review#Purpose

--

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[mohamed.boucadair]

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 DHCP options that can be included in a DHCP*-Options
   RADIUS attribute.

Cheers,
Med

De : Add  De la part de Bernie Volz
Envoyé : vendredi 14 octobre 2022 17:48
À : 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 Encrypted DNS

Hi:

Your github document is -03 and published is -03, so likely you want to make it 
-04?

As no dhcp options are being defined and they are just being encapsulated in 
Radius attributes, not exactly sure how much the DHC wg can (or needs to) 
comment?

This basically changes things so you no longer have unique Radius attributes 
that are mapped to DHCP options, but you just use the DHCP options directly. 
This seems fine. (It does complicate the Radius configuration to handle DHCP 
option configuration if you don’t want them to be hand encoded as octet data, 
and many of the encoding/validation rules are not as consistent as we would 
like, especially for older options.)

The one concern for DHC wg may be to restrict the options that a DHCP server 
can send out if these options are intended to be delivered to the client via 
the dhcp server … for example, one would not want address or prefix delegation 
options to be allowed. This might be something similar to 
https://datatracker.ietf.org/doc/rfc6422/ which created a new registry for the 
allowed DHCPv6 options that can be provided by a relay agent (in this case 
encoded in the attributes).
- Bernie Volz


On Oct 14, 2022, at 10:45 AM, 
mohamed.boucad...@orange.com wrote:
Hi Bernie, dhcwg,

We received a comment during the WGLC of this draft that might lead us to 
revisit the design you have reviewed recently. This alternative design mirrors 
what we have done in 7037 (dhcwg) but with DHCP options included in RADIUS. The 
candidate text is available at:

https://github.com/boucadair/draft-ietf-opsawg-add-encrypted-dns/blob/main/draft-ietf-opsawg-add-encrypted-dns-encap.txt

I'd appreciate if you can review this proposal and share any comments/issues 
you may have.

Thank you.

Cheers,
Med


-Message d'origine-
De : BOUCADAIR Mohamed INNOV/NET
Envoyé : vendredi 14 octobre 2022 16:32
À : 'Alan DeKok' mailto:al...@deployingradius.com>>
Cc : Ben Schwartz mailto:bem...@google.com>>; Joe Clarke 
(jclarke)
mailto:jcla...@cisco.com>>; opsawg 
mailto:opsawg@ietf.org>>; 
rad...@ietf.org;
ADD Mailing list mailto:a...@ietf.org>>
Objet : RE: [Add] [OPSAWG]  WG LC: RADIUS Extensions for
Encrypted DNS

Re-,

Works for me. Thanks.

I will run this candidate version with dhcwg as well.

Cheers,
Med

-Message d'origine-
De : Alan DeKok mailto:al...@deployingradius.com>> 
Envoyé : vendredi 14
octobre 2022 16:00 À : BOUCADAIR Mohamed INNOV/NET
mailto:mohamed.boucad...@orange.com>> Cc : Ben 
Schwartz
mailto:bem...@google.com>>;
Joe Abley mailto:jab...@hopcount.ca>>; Ben Schwartz
mailto:bemasc=40google@dmarc.ietf.org>>;
 Joe Clarke (jclarke)
mailto:jcla...@cisco.com>>; opsawg 
mailto:opsawg@ietf.org>>; 
rad...@ietf.org;
ADD
Mailing list mailto:a...@ietf.org>> Objet : Re: [Add] [OPSAWG]  
WG LC:
RADIUS Extensions for Encrypted DNS


On Oct 14, 2022, at 5:47 AM, 
mailto:mohamed.boucad...@orange.com>>
mailto: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.


_

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