from:"mohamed.boucadair"

Re-,

 

Great!

 

FWIW,
https://datatracker.ietf.org/doc/draft-boucla-opsawg-ipfix-fixes/06/
includes now the note proposed below. 

 

Cheers,

Med

 

De : thomas.g...@swisscom.com  
Envoyé : vendredi 5 mai 2023 12:00
À : BOUCADAIR Mohamed INNOV/NET ;
benoit.cla...@huawei.com; opsawg@ietf.org
Cc : juans...@cisco.com; rjo...@cisco.com
Objet : RE: draft-boucla-opsawg-ipfix-fixes-04

 

Dear Med and Benoit,

 

Excellent. Thank you very much for addressing this so quickly. The
proposed changes make perfectly sense and addresses my concerns. 

 

Indeed I was miss leaded by the IANA IPFIX registry indicating
unisgned8 where RFC7270 defined unisgned32 for the IE89
forwardingStatus. Therefore reduced-size encoding makes perfectly
sense now.

 

Best wishes

Thomas

 

From: mohamed.boucad...@orange.com
  mailto:mohamed.boucad...@orange.com> > 
Sent: Friday, May 5, 2023 11:48 AM
To: Benoit Claise mailto:benoit.cla...@huawei.com> >; Graf Thomas, INI-NET-VNC-HCS
mailto:thomas.g...@swisscom.com> >;
opsawg@ietf.org  
Cc: juans...@cisco.com  ; rjo...@cisco.com
 
Subject: RE: draft-boucla-opsawg-ipfix-fixes-04

 

Hi Benoît, 

 

To make it clear and avoid any issues (which I smell coming) with the
IE-doctors at review time, I would make it very clear in the next
version of the draft:
[IANA Note: this unsigned8 to unsigned32 is actually a bug, as
https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12 clearly
mentions that the Abstract Data Type must be unsigned32]

I went with the following: 

 

NEW:

   The current entry in [IANA-IPFIX] deviates from what is provided in


  [RFC7270].  In particular, the registered Abstract Data Type is 

  unsigned8, while it must be unsigned32.  The following update fixes 

  that issue.  The description is also updated to clarify the use of  

  the reduced-size encoding as per Section 6.2 of [RFC7011].

 

Cheers,

Med

 

De : Benoit Claise mailto:benoit.cla...@huawei.com> > 
Envoyé : vendredi 5 mai 2023 11:04
À : thomas.g...@swisscom.com  ;
opsawg@ietf.org  ; BOUCADAIR Mohamed INNOV/NET
mailto:mohamed.boucad...@orange.com> >
Cc : juans...@cisco.com  ; rjo...@cisco.com
 ; me mailto:benoit.cla...@huawei.com> >
Objet : Re: draft-boucla-opsawg-ipfix-fixes-04

 

Dear Thomas,

Thanks for spotting this.
See inline.

On 5/3/2023 4:07 PM, thomas.g...@swisscom.com
  wrote:

Dear OPSAWG, Med and Benoit

 

Regarding section 6.2, forwardingStatus
(https://datatracker.ietf.org/doc/html/draft-boucla-opsawg-ipfix-fixes
-04#section-6.2). Section 4.12 of RFC 7270
(https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12) describes
that reduced-size encoding according to Section 6.2 of RFC 7011
(https://www.rfc-editor.org/rfc/rfc7011#section-6.2) can be applied.
Further Section 4.12 of RFC 7270 describes that "The basic encoding is
8 bits. The future extensions could add one or three bytes". The IANA
IPFIX registry (https://www.iana.org/assignments/ipfix/ipfix.xhtml)
reads unisgned8 for IE89 forwardingStatus.

 

Recently we came across a vendor implementation which implemented IE89
forwardingStatus with unsigned32 instead of unsigned8 already. This
raised the following questions which I like to clarify here:

 

1.  Does "The future extensions could add one or three bytes"
means that data type can be changed from unsigned8 to unsigned32 today
already or is a new RFC document needed to update the IPFIX entity?

Actually, this is clearly a bug in the IFPIX IANA registry. 
https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12 mentions
unsigned32 and it's not the case in the IPFIX IANA registry

2.   
3.  Does " reduced-size encoding" also applies for increasing the
field size? 

No. That's the reason why unsigned32 must be in the IPFIX IANA
registry

4.  If yes, I find the wording rather misleading.
5.  If IE89 forwardingStatus can be implemented in unsigned8,
unsigned16 and unsigned32, shouldn't it be reflected in the IPFIX
registry accordingly?

 

Depending on the answers we might take the opportunity with
draft-boucla-opsawg-ipfix-fixes to update the IE89 forwardingStatus
description.

As I mentions, this is a bug.
We can take the opportunity to include it in
draft-boucla-opsawg-ipfix-fixes-05
Med did it, and this is perfect. Thanks.
To make it clear and avoid any issues (which I smell coming) with the
IE-doctors at review time, I would make it very clear in the next
version of the draft:
[IANA Note: this unsigned8 to unsigned32 is actually a bug, as
https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12 clearly
mentions that the Abstract Data Type must be unsigned32]

Thanks to Thomas for the investigaiton and Med for the speedy
reaction.

Regards, Benoit




 

Best wishes

Thomas

[OPSAWG] IPFIX EH Occurrences (was RE: Minutes from 116)

Hi all,

As a follow-up to this comment:

==
Thomas: IPv6 EH there can be only one occurrence. Consider multiple
types in a package.
==

I prepared a candidate proposal at:
https://boucadair.github.io/ipfix-tcpoptions-and-v6eh/draft-boucadair-opsawg-ipfix-tcpo-v6eh.html#name-ipv6extensionheadercount-in

Comments are welcome.

Cheers,
Med

De : OPSAWG De la part de Joe Clarke (jclarke)
Envoyé : mardi 25 avril 2023 23:44
À : opsawg@ietf.org
Objet : [OPSAWG] Minutes from 116

I have imported our 116 minutes into Data Tracker. A big thanks to Rob and
Henk for recording things (and to anyone else that jumped in).

In terms of actions, we have a WG LC for the 7125 (update bis). I'll close
that out in another thread. We closed the adoption call for DMLMO.

Let us know if there are any changes needed or omissions in these minutes.

Thanks.

https://datatracker.ietf.org/meeting/116/materials/minutes-116-opsawg-202303280030-00

Joe

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

Re: [OPSAWG] draft-boucla-opsawg-ipfix-fixes-04

Hi Benoît,

"To make it clear and avoid any issues (which I smell coming) with the 
IE-doctors at review time, I would make it very clear in the next version of 
the draft:
[IANA Note: this unsigned8 to unsigned32 is actually a bug, as 
https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12 clearly mentions that 
the Abstract Data Type must be unsigned32]"

I went with the following:

NEW:
   The current entry in [IANA-IPFIX] deviates from what is provided in
  [RFC7270].  In particular, the registered Abstract Data Type is
  unsigned8, while it must be unsigned32.  The following update fixes
  that issue.  The description is also updated to clarify the use of
  the reduced-size encoding as per Section 6.2 of [RFC7011].

Cheers,
Med

De : Benoit Claise 
Envoyé : vendredi 5 mai 2023 11:04
À : thomas.g...@swisscom.com; opsawg@ietf.org; BOUCADAIR Mohamed INNOV/NET 

Cc : juans...@cisco.com; rjo...@cisco.com; me 
Objet : Re: draft-boucla-opsawg-ipfix-fixes-04

Dear Thomas,

Thanks for spotting this.
See inline.
On 5/3/2023 4:07 PM, thomas.g...@swisscom.com 
wrote:
Dear OPSAWG, Med and Benoit

Regarding section 6.2, forwardingStatus 
(https://datatracker.ietf.org/doc/html/draft-boucla-opsawg-ipfix-fixes-04#section-6.2).
 Section 4.12 of RFC 7270 
(https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12) describes that 
reduced-size encoding according to Section 6.2 of RFC 7011 
(https://www.rfc-editor.org/rfc/rfc7011#section-6.2) can be applied. Further 
Section 4.12 of RFC 7270 describes that "The basic encoding is 8 bits. The 
future extensions could add one or three bytes". The IANA IPFIX registry 
(https://www.iana.org/assignments/ipfix/ipfix.xhtml) reads unisgned8 for IE89 
forwardingStatus.

Recently we came across a vendor implementation which implemented IE89 
forwardingStatus with unsigned32 instead of unsigned8 already. This raised the 
following questions which I like to clarify here:


  1.  Does "The future extensions could add one or three bytes" means that data 
type can be changed from unsigned8 to unsigned32 today already or is a new RFC 
document needed to update the IPFIX entity?
Actually, this is clearly a bug in the IFPIX IANA registry.
https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12 mentions unsigned32 
and it's not the case in the IPFIX IANA registry


  1.
  2.  Does " reduced-size encoding" also applies for increasing the field size?
No. That's the reason why unsigned32 must be in the IPFIX IANA registry


  1.  If yes, I find the wording rather misleading.
  2.  If IE89 forwardingStatus can be implemented in unsigned8, unsigned16 and 
unsigned32, shouldn't it be reflected in the IPFIX registry accordingly?

Depending on the answers we might take the opportunity with 
draft-boucla-opsawg-ipfix-fixes to update the IE89 forwardingStatus description.
As I mentions, this is a bug.
We can take the opportunity to include it in draft-boucla-opsawg-ipfix-fixes-05
Med did it, and this is perfect. Thanks.
To make it clear and avoid any issues (which I smell coming) with the 
IE-doctors at review time, I would make it very clear in the next version of 
the draft:
[IANA Note: this unsigned8 to unsigned32 is actually a bug, as 
https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12 clearly mentions that 
the Abstract Data Type must be unsigned32]

Thanks to Thomas for the investigaiton and Med for the speedy reaction.

Regards, Benoit



Best wishes
Thomas


_

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

Re: [OPSAWG] draft-boucla-opsawg-ipfix-fixes-04

Hi Thomas, all,

 

An updated version with a first attempt to clarify the description of
forwardingStatus can be seen at:
https://datatracker.ietf.org/doc/draft-boucla-opsawg-ipfix-fixes/05/

 

This version also fixed some wrong pointers (e.g., nat46/nat64).

 

Cheers,

Med

 

De : BOUCADAIR Mohamed INNOV/NET 
Envoyé : jeudi 4 mai 2023 09:51
À : 'thomas.g...@swisscom.com' ;
opsawg@ietf.org; benoit.cla...@huawei.com
Cc : juans...@cisco.com; rjo...@cisco.com
Objet : RE: draft-boucla-opsawg-ipfix-fixes-04

 

Hi Thomas, 

 

Thank you for raising this. 

 

RFC7270 actually uses unsigned32 + 7011#6.2. As only meanings are
assigned with the first 8 bits, RFC7270 assumes 8-bit as the base
encoding.. which is then used as type in the registry. I agree that
that the current description confusing. 

 

This is indeed something that we can clarify in the simple fixes I-D.

 

Cheers,

Med

 

De : thomas.g...@swisscom.com 
mailto:thomas.g...@swisscom.com> > 
Envoyé : mercredi 3 mai 2023 16:08
À : opsawg@ietf.org  ; BOUCADAIR Mohamed
INNOV/NET mailto:mohamed.boucad...@orange.com> >; benoit.cla...@huawei.com
 
Cc : juans...@cisco.com  ; rjo...@cisco.com
 
Objet : draft-boucla-opsawg-ipfix-fixes-04

 

Dear OPSAWG, Med and Benoit

 

Regarding section 6.2, forwardingStatus
(https://datatracker.ietf.org/doc/html/draft-boucla-opsawg-ipfix-fixes
-04#section-6.2). Section 4.12 of RFC 7270
(https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12) describes
that reduced-size encoding according to Section 6.2 of RFC 7011
(https://www.rfc-editor.org/rfc/rfc7011#section-6.2) can be applied.
Further Section 4.12 of RFC 7270 describes that "The basic encoding is
8 bits. The future extensions could add one or three bytes". The IANA
IPFIX registry (https://www.iana.org/assignments/ipfix/ipfix.xhtml)
reads unisgned8 for IE89 forwardingStatus.

 

Recently we came across a vendor implementation which implemented IE89
forwardingStatus with unsigned32 instead of unsigned8 already. This
raised the following questions which I like to clarify here:

 

*   Does "The future extensions could add one or three bytes"
means that data type can be changed from unsigned8 to unsigned32 today
already or is a new RFC document needed to update the IPFIX entity?
*   Does " reduced-size encoding" also applies for increasing the
field size? If yes, I find the wording rather misleading.
*   If IE89 forwardingStatus can be implemented in unsigned8,
unsigned16 and unsigned32, shouldn't it be reflected in the IPFIX
registry accordingly?

 

Depending on the answers we might take the opportunity with
draft-boucla-opsawg-ipfix-fixes to update the IE89 forwardingStatus
description.

 

Best wishes

Thomas



smime.p7s
Description: S/MIME cryptographic signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Minutes from 116

2023-05-04 Thread mohamed.boucadair

Hi Joe, all,

One follow-up on this point:

"Adrian Farrel (from chat): I'd like to see the ORAN draft presented in
TEAS before OPSAWG adopts. There seems to be a lot of overlap with
ongoing work in TEAS"

(1) Not sure which draft Adrian was referring to, but an LS from O-RAN was
received since then by OPSAWG/TEAS for the slice service + AC.

(2) I presented the AC effort in the teas WG with a focus on how this can be
used for slicing: "Bearers, Attachment Circuits, SAPs, & Slicing" [1]. Please
note that the setup example in the slides can't be addressed by the slice
service models.

(3) The authors of the slicing service models discussed in slide 4 of [2]
options about how the AC work complements the model. One of the outcomes of the
discussion is that the authors of the slice service model will use references
to the ac-svc to inherit properties of ACs that were pre-provisioned by the ac
model. However, and although it is much more cleaner to use the refs in the AC
model, we agreed to use strings to avoid adding a normative dependency to ac
drafts at this stage.

I hope this clarifies the comment from Adrian.

Cheers,
Med

[1]
https://datatracker.ietf.org/meeting/116/materials/slides-116-teas-14-bearers-attachment-circuits-saps-00
[2]
https://datatracker.ietf.org/meeting/116/materials/slides-116-teas-sessa-04-a-yang-data-model-for-the-ietf-network-slice-service-01.

De : OPSAWG De la part de Joe Clarke (jclarke)
Envoyé : mardi 25 avril 2023 23:44
À : opsawg@ietf.org
Objet : [OPSAWG] Minutes from 116

I have imported our 116 minutes into Data Tracker. A big thanks to Rob and
Henk for recording things (and to anyone else that jumped in).

In terms of actions, we have a WG LC for the 7125 (update bis). I'll close
that out in another thread. We closed the adoption call for DMLMO.

Let us know if there are any changes needed or omissions in these minutes.

Thanks.

https://datatracker.ietf.org/meeting/116/materials/minutes-116-opsawg-202303280030-00

Joe

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

Re: [OPSAWG] draft-boucla-opsawg-ipfix-fixes-04

2023-05-04 Thread mohamed.boucadair

Hi Thomas, 

 

Thank you for raising this. 

 

RFC7270 actually uses unsigned32 + 7011#6.2. As only meanings are
assigned with the first 8 bits, RFC7270 assumes 8-bit as the base
encoding.. which is then used as type in the registry. I agree that
that the current description confusing. 

 

This is indeed something that we can clarify in the simple fixes I-D.

 

Cheers,

Med

 

De : thomas.g...@swisscom.com  
Envoyé : mercredi 3 mai 2023 16:08
À : opsawg@ietf.org; BOUCADAIR Mohamed INNOV/NET
; benoit.cla...@huawei.com
Cc : juans...@cisco.com; rjo...@cisco.com
Objet : draft-boucla-opsawg-ipfix-fixes-04

 

Dear OPSAWG, Med and Benoit

 

Regarding section 6.2, forwardingStatus
(https://datatracker.ietf.org/doc/html/draft-boucla-opsawg-ipfix-fixes
-04#section-6.2). Section 4.12 of RFC 7270
(https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12) describes
that reduced-size encoding according to Section 6.2 of RFC 7011
(https://www.rfc-editor.org/rfc/rfc7011#section-6.2) can be applied.
Further Section 4.12 of RFC 7270 describes that "The basic encoding is
8 bits. The future extensions could add one or three bytes". The IANA
IPFIX registry (https://www.iana.org/assignments/ipfix/ipfix.xhtml)
reads unisgned8 for IE89 forwardingStatus.

 

Recently we came across a vendor implementation which implemented IE89
forwardingStatus with unsigned32 instead of unsigned8 already. This
raised the following questions which I like to clarify here:

 

*   Does "The future extensions could add one or three bytes"
means that data type can be changed from unsigned8 to unsigned32 today
already or is a new RFC document needed to update the IPFIX entity?
*   Does " reduced-size encoding" also applies for increasing the
field size? If yes, I find the wording rather misleading.
*   If IE89 forwardingStatus can be implemented in unsigned8,
unsigned16 and unsigned32, shouldn't it be reflected in the IPFIX
registry accordingly?

 

Depending on the answers we might take the opportunity with
draft-boucla-opsawg-ipfix-fixes to update the IE89 forwardingStatus
description.

 

Best wishes

Thomas



smime.p7s
Description: S/MIME cryptographic signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] TR: I-D Action: draft-boro-opsawg-teas-attachment-circuit-06.txt

2023-05-03 Thread mohamed.boucadair

Hi all, 

We updated the draft to address the comments received so far, especially a 
review from Kenichi and Luis Angel to control QoS at the AC level (more details 
can be seen at [1]). The full list of closed issues can be tracked at [2].

We also updated the description and examples. 

The AC common model was also updated with new groupings to manage QoS. The 
latest version is available at: 
https://datatracker.ietf.org/doc/draft-boro-opsawg-teas-common-ac/

We think that these versions are more stable and ready for considering a call 
for adoption for these documents.

Cheers,
Med

[1] https://github.com/boucadair/attachment-circuit-model/issues/70
[2] 
https://github.com/boucadair/attachment-circuit-model/issues?q=is%3Aissue+is%3Aclosed

-Message d'origine-
De : I-D-Announce  De la part de 
internet-dra...@ietf.org
Envoyé : mercredi 3 mai 2023 15:35
À : i-d-annou...@ietf.org
Objet : I-D Action: draft-boro-opsawg-teas-attachment-circuit-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.

   Title   : YANG Data Models for 'Attachment Circuits'-as-a-Service 
(ACaaS)
   Authors : Mohamed Boucadair
 Richard Roberts
 Oscar Gonzalez de Dios
 Samier Barguil Giraldo
 Bo Wu
   Filename: draft-boro-opsawg-teas-attachment-circuit-06.txt
   Pages   : 95
   Date: 2023-05-03

Abstract:
   This document specifies a YANG service data model for Attachment
   Circuits (ACs).  This model can be used for the provisioning of ACs
   prior or during service provisioning (e.g., Network Slice Service).
   The document specifies also a module that updates other service and
   network modules with the required information to bind specific
   services to ACs that are created using the AC service model.

   Also, the document specifies a set of reusable groupings.  Whether a
   service model reuses structures defined in the AC models or simply
   include an AC reference is a design choice of these service models.
   Relying upon the AC service model to manage ACs over which a service
   is delivered has the merit to decorrelate the management of a service
   vs. upgrade the AC components to reflect recent AC technologies or
   features.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-boro-opsawg-teas-attachment-circuit/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-boro-opsawg-teas-attachment-circuit-06.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-boro-opsawg-teas-attachment-circuit-06



_

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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-rfc7125-update-03.txt

2023-05-03 Thread mohamed.boucadair

Hi all, 

This version implements the changes shared with directorate reviewers. Also 
made some very minor edits to enhance the readability:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-rfc7125-update-03

Cheers,
Med

> -Message d'origine-
> De : OPSAWG  De la part de internet-
> dra...@ietf.org
> Envoyé : mercredi 3 mai 2023 13:06
> À : i-d-annou...@ietf.org
> Cc : opsawg@ietf.org
> Objet : [OPSAWG] I-D Action: draft-ietf-opsawg-rfc7125-update-
> 03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Operations
> and Management Area Working Group (OPSAWG) WG of the IETF.
> 
>Title   : An Update to the tcpControlBits IP Flow
> Information Export (IPFIX) Information Element
>Author  : Mohamed Boucadair
>Filename: draft-ietf-opsawg-rfc7125-update-03.txt
>Pages   : 7
>Date: 2023-05-03
> 
> Abstract:
>RFC 7125 revised the tcpControlBits IP Flow Information Export
>(IPFIX) Information Element that was originally defined in RFC
> 5102
>to reflect changes to the TCP header control bits since RFC
> 793.
>However, that update is still problematic for interoperability
>because some flag values were deprecated since then.
> 
>This document removes stale information from the IPFIX registry
> and
>avoiding future conflicts with the authoritative TCP Header
> Flags
>registry.
> 
>This document obsoletes RFC 7125.


_

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

Re: [OPSAWG] Rtgdir last call review of draft-ietf-opsawg-rfc7125-update-02

2023-05-02 Thread mohamed.boucadair

Hi Ketan, 

Thank you for the review. Good points. 

I made some changes to take into account your suggestions: 
https://github.com/boucadair/-ipfix-rfc7125-update/commit/dbac6f4ad7617f3e0165068fb2e6e0053095459b.

Some comments from my side:

* I agree that the writeup should include a mention about the track. FWIW, the 
point was raised in 
https://datatracker.ietf.org/meeting/115/materials/slides-115-opsawg-an-update-to-the-tcpcontrolbits-ip-flow-information-export-ipfix-information-element-00
 and also in the mailing list.
* As we are not touching the data type currently defined for IE#6, I don't 
think it is worth the call out the type used here. No change is thus made to 
that part. Thanks.

Cheers,
Med

> -Message d'origine-
> De : Ketan Talaulikar via Datatracker 
> Envoyé : mardi 2 mai 2023 16:32
> À : rtg-...@ietf.org
> Cc : draft-ietf-opsawg-rfc7125-update@ietf.org; last-
> c...@ietf.org; opsawg@ietf.org
> Objet : Rtgdir last call review of draft-ietf-opsawg-rfc7125-
> update-02
> 
> Reviewer: Ketan Talaulikar
> Review result: Has Nits
> 
> 1) This document is Standards Track while the RFC7125 that it
> obsoletes is Informational. Standards Track seems correct to me.
> This may not be an issue - simply calling attention to this change
> in status to be explained perhaps in the Shepherd Write-up down
> the line?
> 
> 2) In Sec 1, please check if the paragraph should be updated as
> below:
> 
> This document fixes that problem by removing stale information
> from the IPFIX registry [IPFIX] and avoiding future conflicts with
> the authoritative TCP registry [TCP-FLAGS].
> 
> 3) Sec 3 does not cover all the fields of the IPFIX IANA Table.
> Notably "Additional Information" field chould have been supplied
> here instead of being described in IANA Section 4. Perhaps if
> everything is stated in Sec 3 then the IANA considerations become
> simpler and clearer?
> 
> 4) Please consider if the additional text from Security And
> Privacy Considerations from RFC7125 is required in addition to the
> reference to the RFC7011. There is discussion related to DDOS in
> section 1 of the document.
> 


_

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

Re: [OPSAWG] Tsvart last call review of draft-ietf-opsawg-rfc7125-update-02

2023-05-02 Thread mohamed.boucadair

Hi Michael, 

Thank you for the review.

The review will be ACKed in the next iteration.

Cheers,
Med

> -Message d'origine-
> De : Michael Scharf via Datatracker 
> Envoyé : mardi 2 mai 2023 12:38
> À : tsv-...@ietf.org
> Cc : draft-ietf-opsawg-rfc7125-update@ietf.org; last-
> c...@ietf.org; opsawg@ietf.org
> Objet : Tsvart last call review of draft-ietf-opsawg-rfc7125-
> update-02
> 
> Reviewer: Michael Scharf
> Review result: Ready
> 
> This document has been reviewed as part of the transport area
> review team's ongoing effort to review key IETF documents. These
> comments were written primarily for the transport area directors,
> but are copied to the document's authors and WG to allow them to
> address any issues raised and also to the IETF discussion list for
> information.
> 
> When done at the time of IETF Last Call, the authors should
> consider this review as part of the last-call comments they
> receive. Please always CC tsv-...@ietf.org if you reply to or
> forward this review.
> 
> I have read version -02 as TSV-ART reviewer. The document is short
> and well-written.
> 
> The described solution for encoding TCP header flags in IPFIX
> seems to make sense given the recent updates of the TCP standard,
> and future changes in future. However, please note that I am not
> an IPFIX expert.
> 


_

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

Re: [OPSAWG] IPR POLL: draft-ietf-opsawg-rfc7125-update

2023-04-04 Thread mohamed.boucadair

Hi Joe, all,

No, I'm not aware of any IPR that applies to this draft.

Cheers,
Med

From: OPSAWG  On Behalf Of Joe Clarke (jclarke)
Sent: mardi 4 avril 2023 22:03
To: opsawg@ietf.org
Subject: [OPSAWG] IPR POLL: draft-ietf-opsawg-rfc7125-update

(FYI, we're going to get more consistent about doing this at adoption time, but 
this one was already adopted.)

Authors and contributors, please respond on-list as to whether or not you are 
aware of any IPR that pertains to this work.

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If you are aware of IPR, indicate whether or not this has been disclosed per 
IETF IPR rules (see RFCs 3669, 5378, and 8179).

Joe

_

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

Re: [OPSAWG] Éric Vyncke's Yes on draft-ietf-opsawg-add-encrypted-dns-12: (with COMMENT)

2023-03-30 Thread mohamed.boucadair

Hi Éric, 

Thanks for double checking. I also think this version is better.

Cheers,
Med

> -Original Message-
> From: Éric Vyncke via Datatracker 
> Sent: vendredi 31 mars 2023 08:48
> To: The IESG 
> Cc: draft-ietf-opsawg-add-encrypted-...@ietf.org; opsawg-
> cha...@ietf.org; opsawg@ietf.org; dh...@ietf.org; bev...@gmail.com;
> bev...@gmail.com
> Subject: Éric Vyncke's Yes on draft-ietf-opsawg-add-encrypted-dns-12:
> (with COMMENT)
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-opsawg-add-encrypted-dns-12: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut
> this introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT
> positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-encrypted-dns/
> 
> 
> 
> -
> -
> COMMENT:
> -
> -
> 
> Thanks for addressing my previous DISCUSS[1], I sincerely think that
> the document is better now.
> 
> Regards
> 
> -éric
> 
> [1]
> https://mailarchive.ietf.org/arch/msg/opsawg/yV4NKUp6tcmFGTkXomh7s1vm
> whY/
> 
> 


_

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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-rfc7125-update-02.txt

2023-03-26 Thread mohamed.boucadair

Hi all, 

This version follows the approach in 
https://mailarchive.ietf.org/arch/msg/opsawg/NB_rRxXHAko9pHW-geKIB1B9rKw/.

This version is ready for the WGLC.

Cheers,
Med

> -Message d'origine-
> De : OPSAWG  De la part de internet-
> dra...@ietf.org
> Envoyé : lundi 27 mars 2023 00:31
> À : i-d-annou...@ietf.org
> Cc : opsawg@ietf.org
> Objet : [OPSAWG] I-D Action: draft-ietf-opsawg-rfc7125-update-02.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Operations and
> Management Area Working Group (OPSAWG) WG of the IETF.
> 
>Title   : An Update to the tcpControlBits IP Flow
> Information Export (IPFIX) Information Element
>Author  : Mohamed Boucadair
>Filename: draft-ietf-opsawg-rfc7125-update-02.txt
>Pages   : 7
>Date: 2023-03-26
> 
> Abstract:
>RFC 7125 revised the tcpControlBits IP Flow Information Export
>(IPFIX) Information Element that was originally defined in RFC
> 5102
>to reflect changes to the TCP Flags header field since RFC 793.
>However, that update is still problematic for interoperability
>because some flag values were deprecated since then.
> 
>This document removes stale information from the IPFIX registry
> and
>avoiding future conflicts with the authoritative TCP Header Flags
>registry.
> 
>This document obsoletes RFC 7125.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc7125-update/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-opsawg-rfc7125-update-
> 02.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-rfc7125-
> update-02
> 
> 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

_

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

Re: [OPSAWG] Éric Vyncke's Discuss on draft-ietf-opsawg-add-encrypted-dns-11: (with DISCUSS and COMMENT)

2023-03-26 Thread mohamed.boucadair

Hi Éric, all,


FWIW, a new version with the changes discussed so far is now available online: 
A diff from the previous version can be seen at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-add-encrypted-dns-12

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : vendredi 17 mars 2023 09:21
À : 'Bernie Volz' 
Cc : Eric Vyncke (evyncke) ; The IESG ; 
draft-ietf-opsawg-add-encrypted-...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; dh...@ietf.org; jin...@wide.ad.jp
Objet : RE: Éric Vyncke's Discuss on draft-ietf-opsawg-add-encrypted-dns-11: 
(with DISCUSS and COMMENT)

Hi Bernie,

Thank you for clarifying.

Please see inline.

Cheers,
Med

De : Bernie Volz mailto:bev...@gmail.com>>
Envoyé : jeudi 16 mars 2023 22:29
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : Eric Vyncke (evyncke) mailto:evyn...@cisco.com>>; The 
IESG mailto:i...@ietf.org>>; 
draft-ietf-opsawg-add-encrypted-...@ietf.org;
 opsawg-cha...@ietf.org; 
opsawg@ietf.org; dh...@ietf.org; 
jin...@wide.ad.jp
Objet : Re: Éric Vyncke's Discuss on draft-ietf-opsawg-add-encrypted-dns-11: 
(with DISCUSS and COMMENT)

I’m really not sure why there is any confusion. I think changing Section 3.1 
and 3.2 (obviously with some edits for 3.2) from:


  Permitted DHCPv6 options in the DHCPv6-Options Attribute are

  maintained by IANA in the registry created in Section 8.4.1.

to:


  Permitted DHCPv6 options in the DHCPv6-Options Attribute are

  maintained by IANA in the registry created in Section 8.4.1. If a

  DHCP server finds an option not permitted, it MUST ignore that

  option.

[Med] MUST conflicts with the config knob. I made this change:

OLD:
   RADIUS implementations may support a configuration parameter to
   control the DHCP options that can be included in a DHCP*-Options
   RADIUS attribute.  Likewise, DHCP server implementations may support
   a configuration parameter to control the permitted DHCP options in a
  DHCP*-Options RADIUS attribute.

NEW:
   RADIUS implementations may support a configuration parameter to
   control the DHCP options that can be included in a DHCP*-Options
   RADIUS attribute.  Likewise, DHCP server implementations may support
   a configuration parameter to control the permitted DHCP options in a
   DHCP*-Options RADIUS attribute.  Absent explicit configuration,
   RADIUS implementations and DHCP server implementations SHOULD ignore
   non-permitted DHCP options received in a DHCP*-Options RADIUS
attribute.

Would be a simple and reasonable fix. This doesn’t fully address the malformed 
data, such as extra data at end of attribute value that is less than 4 octets 
(dhcpv6 options have a 4-octet header) or when an option specifies a length 
that exceeds the remaining data in the attribute, but I’ll allow those issues 
to be handled by the RADIUS documents as an invalid attribute.

[Med] ACK.

Note that I don’t believe RFC7037 documented what should happen if Radius 
Attributes that are not permitted are present in the data. But that doesn’t 
mean as time goes on we shouldn’t become wiser and improve our standards to 
cover more of the potential “bad” considerations.

Until Éric raised it, I hadn’t thought about it either. Éric might still want 
to cover these malformed data issues …

- not limit itself on the validity of the RADIUS attribute but
also clearly state what the DHCP server validation should do

Also, Section 5 is also a bit lacking in how the DHCP server handles this. Yes, 
I know what is expected as having worked with DHCP for a long time … but 
standing back a bit, really is not that clear. You might want to review Section 
6 of RFC 6422. In your case, you likely want the server to prefer this option 
over whatever it may already have.

[Med] This is already covered:

   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.

- Bernie Volz

_

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;

Re: [OPSAWG] draft-ietf-teas-ietf-network-slice-nbi-yang: AC provisioning vs. (slice) service provisioning

2023-03-22 Thread mohamed.boucadair

Hi all,

Please find below an update of the attachment circuit effort:

  *   The content is now split into three I-Ds
 *   Common AC: 
https://datatracker.ietf.org/doc/html/draft-boro-opsawg-teas-common-ac
 *   AC as a Service: 
https://datatracker.ietf.org/doc/draft-boro-opsawg-teas-attachment-circuit/05/
 *   SAP/AC: 
https://datatracker.ietf.org/doc/draft-boro-opsawg-ntw-attachment-circuit/02/
  *   We created a separate model for the bearer service and clarified how it 
interacts with the AC
  *   We integrated comments from Moti, Kenichi, and the rest of the team

The overall dashboard for the attachment circuit effort is available at: 
https://github.com/users/boucadair/projects/1

  *   44 closed issues
  *   11 in progress
  *   6 candidate features
  *   7 features that need more analysis

Our plan is to request adoption of this effort in OPSAWG as we are leveraging 
many pieces that were developed in opsawg and also because AC can be reusing 
beyond slicing. We commit to regularly report and seek for comments from teas.

Comments, questions, and suggestions are appreciated.

Cheers,
Med (on behalf of the AC team)

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mercredi 22 février 2023 16:28
À : 'Richard Roberts' ; TEAS WG ; 
draft-ietf-teas-ietf-network-slice-nbi-y...@ietf.org; opsawg@ietf.org
Cc : Bo Wu ; Oscar Gonzalez de Dios 
; Samier Barguil 
; JACQUENET Christian INNOV/NET 

Objet : RE: draft-ietf-teas-ietf-network-slice-nbi-yang: AC provisioning vs. 
(slice) service provisioning

Hi all,

Thanks Richard for sharing this update from ORAN.

FWIW, a new revision of the Attachment Circuits as a Service Module is 
available online. The main changes are as follows:


  *   Clarify the bearer concept and further elaborate the AC definition
  *   Position AC vs. bearer
  *   Position ACaaS vs. other models
  *   Add more examples, including illustrate how to use the AC module to 
connect to a cloud provider

Other changes can be tracked by looking into the diff provided below:


Title:  YANG Data Models for 'Attachment Circuits'-as-a-Service (ACaaS)

Document date:  2023-02-22

Group:  Individual Submission

Pages:  122

URL:
https://www.ietf.org/archive/id/draft-boro-opsawg-teas-attachment-circuit-02.txt

Status: 
https://datatracker.ietf.org/doc/draft-boro-opsawg-teas-attachment-circuit/

Html:   
https://www.ietf.org/archive/id/draft-boro-opsawg-teas-attachment-circuit-02.html

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-boro-opsawg-teas-attachment-circuit

Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-boro-opsawg-teas-attachment-circuit-02

Comments are welcome.

Cheers,
Med

De : Richard Roberts mailto:rrobe...@juniper.net>>
Envoyé : mercredi 8 février 2023 11:25
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; TEAS WG 
mailto:t...@ietf.org>>; 
draft-ietf-teas-ietf-network-slice-nbi-y...@ietf.org
Cc : opsawg@ietf.org; Bo Wu 
mailto:lana.w...@huawei.com>>; Oscar Gonzalez de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>;
 Samier Barguil 
mailto:samier.barguil_gira...@nokia.com>>; 
JACQUENET Christian INNOV/NET 
mailto:christian.jacque...@orange.com>>
Objet : RE: draft-ietf-teas-ietf-network-slice-nbi-yang: AC provisioning vs. 
(slice) service provisioning

Hi all,

I am sharing with you the link below that deals with TN Slices within ORAN. 
This is joint WG6 (O-CLOUD) and WG9 (TN) presentation.
This presentation shows how the AC Data model can complement the Network Slice 
Service DM to create a new slice (example of a vlan hand-off model - different 
options are possible -).

https://github.com/boucadair/attachment-circuit-model/blob/main/assets/JNPR-WG6-WG9-E2E-TN-31012023.pdf

There are also a few slides related to provide better Transport Network 
automation within the  5G SMO, by extending the 3GPP Network Resource Model 
with the IETF AC YANG DM (EP_TRANSPORT/NextHopInfo). In other words, use IETF 
for network plumbing within the 3GPP ecosystem.

Of course, feel free to reach out to me if you have any questions !

Regards,
R


Juniper Business Use Only
From: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Sent: Friday, January 20, 2023 2:17 PM
To: TEAS WG mailto:t...@ietf.org>>; 
draft-ietf-teas-ietf-network-slice-nbi-y...@ietf.org
Cc: opsawg@ietf.org; Richard Roberts 
mailto:rrobe...@juniper.net>>; Bo Wu 
mailto:lana.w...@huawei.com>>; Oscar Gonzalez de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>;
 Samier Barguil 
mailto:samier.barguil_gira...@nokia.com>>; 
JACQUENET Christian INNOV/NET 
mailto:christian.jacque...@orange.com>>
Subject: RE: draft-ietf-teas-ietf-network-slice-nbi-yang: AC provisioning vs. 
(slice) service provisioning

Re: [OPSAWG] draft-ietf-opsawg-rfc7125-update: bis vs. update

2023-03-21 Thread mohamed.boucadair

Hi all,

I started identifying the changes that are required to replace 7125 instead of
the current OLD/NEW patch. FWIW, please find below some pointers to track the
changes:

* Proposed PR: https://github.com/boucadair/-ipfix-rfc7125-update/pull/3
* Rendered html version:
https://boucadair.github.io/-ipfix-rfc7125-update/obsoletes-7125/draft-ietf-opsawg-rfc7125-update.html
* Diff with the current version of the draft Diff:
draft-ietf-opsawg-rfc7125-update.txt -
draft-ietf-opsawg-rfc7125-update.txt
* Diff with RFC7125:
https://boucadair.github.io/-ipfix-rfc7125-update/obsoletes-7125/draft-ietf-opsawg-rfc7125-update.txt

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : vendredi 24 février 2023 15:23
À : opsawg@ietf.org; OpsAWG-Chairs
Objet : draft-ietf-opsawg-rfc7125-update: bis vs. update

Hi all,

One of the open questions raised in IETF#115 (3rd sub-bullet of bullet#2 in
Slide#5 of [1]) is whether we publish this I-D as a bis, especially that each
of the original RFC and the update draft have almost the same page count.

I personally think it is much more cleaner to go for a bis here but I'm just
the pen holder and would like to hear from the WG/Chairs. Thanks

Cheers,
Med

[1]
https://datatracker.ietf.org/meeting/115/materials/slides-115-opsawg-an-update-to-the-tcpcontrolbits-ip-flow-information-export-ipfix-information-element-00

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

Re: [OPSAWG] New Version Notification for draft-feng-opsawg-incident-management-00.txt

2023-03-21 Thread mohamed.boucadair

Hi Franck, all, 

Thank you for initiating this work. Please find some comments, fwiw: 

(1) The document overstates what it achieves. I would soften many of these 
statements. For example, It would be helpful to discuss whether the approach 
eases the identification of root causes and their mitigation.
(2) Rather than opposing the alarm model with what is specified in this 
document, I would instead better articulate and highlight how they complement 
each other.
(3) The network service aspect is not highlighted as I was expecting from the 
title/abstract. For example, I was expecting to see a discussion how 
service-specific incidents are tagged/characterized and then reported. The 
current discussion is mostly device-centric.
(4) Consider positioning this work in the context of the automation framework 
in RFC8969. Likewise, call out potential interactions with the TMF incident API.
(5) You may also position this work vs. the service assurance work led by 
Benoît. I don’t see conflict between both, but it is better to discuss that in 
the draft.

Hope this helps. 

Cheers,
Med

> -Message d'origine-
> De : OPSAWG  De la part de Fengchong
> (frank)
> Envoyé : lundi 13 mars 2023 14:19
> À : opsawg@ietf.org
> Objet : [OPSAWG] 转发: New Version Notification for draft-feng-
> opsawg-incident-management-00.txt
> 
> Hi all,
>   I submit a new draft about incident management for network
> service. Includes:
> 1. The concept and architecture of Incident management.
> 2. The incident lifecycle management.
> 3. The YANG model for incident management.
> 
>   Please give your comments. Thanks.
> 
>   Best Regards,
>   Frank
> 
> -邮件原件-
> 发件人: internet-dra...@ietf.org 
> 发送时间: 2023年3月13日 21:06
> 收件人: yuchaode ; Fengchong (frank)
> ; Luis Contreras
> ; Luis Miguel
> Contreras Murillo ;
> Qin Wu ; Qin Wu ; Tong Hu
> 
> 主题: New Version Notification for draft-feng-opsawg-incident-
> management-00.txt
> 
> 
> A new version of I-D, draft-feng-opsawg-incident-management-00.txt
> has been successfully submitted by Chong Feng and posted to the
> IETF repository.
> 
> Name: draft-feng-opsawg-incident-management
> Revision: 00
> Title:Incident Management for Network Services
> Document date:2023-03-13
> Group:Individual Submission
> Pages:35
> URL:https://www.ietf.org/archive/id/draft-feng-opsawg-
> incident-management-00.txt
> Status: https://datatracker.ietf.org/doc/draft-feng-
> opsawg-incident-management/
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-feng-
> opsawg-incident-management
> 
> 
> Abstract:
>This document provides an architecture for the incident
> management
>system and related function interface requirements.
> 
>This document also defines a YANG module to support the
> incident
>lifecycle management.  This YANG module is meant to provide a
>standard way to report, diagnose, and resolve incidents for the
> sake
>of enhanced network services.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

_

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

Re: [OPSAWG] WG adoption call for draft-palmero-opsawg-dmlmo-09

2023-03-17 Thread mohamed.boucadair

Hi all,

FWIW, please find below a review of this draft:

* pdf:
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-palmero-opsawg-dmlmo-09-rev%20Med.pdf
* doc:
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-palmero-opsawg-dmlmo-09-rev%20Med.doc

I support the overall effort to provide a common (set of) model(s) to
complement existing the in-house tools (e.g., industrialize collection of
EoL/EoS) with the hope that inventory data is not kept stale and that it is
actively updated.

However, I think that some more effort is needed to better scope this work. I
don't think that the document is ready in its current state. Some "diet" effort
is needed to keep only core components and offload other parts to
future/companion extensions.

I have also many comments on the yang structure itself (lack of structure
types, abuse of string, lack of meaningful descriptions, etc.), but I guess
these can be fixed once the high level concern is handled.

Aaah, rather than "Cisco and Ohers", I suggest you simply rely in the PEN
registry. Here is an example:

leaf vendor-id {
type uint32;
description
"The Vendor ID is a security vendor's Private Enterprise
Number as registered with IANA.";
reference
"IANA: Private Enterprise Numbers
(https://www.iana.org/assignments/enterprise-numbers/)";
}

Thank you.

Cheers,
Med

De : OPSAWG De la part de Tianran Zhou
Envoyé : vendredi 17 mars 2023 03:31
À : opsawg@ietf.org
Cc : opsawg-cha...@ietf.org
Objet : [OPSAWG] WG adoption call for draft-palmero-opsawg-dmlmo-09

Hi WG,

This mail we start a two weeks working group adoption call for:
https://datatracker.ietf.org/doc/draft-palmero-opsawg-dmlmo/

Please show your support or objection in the mailing list.
Any comment and suggestion is welcome.
As this draft is part of the inventory related work, suggestions on how to
cooperate are expected.

The call will end on April 3.

Regards,
Tianran

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

Re: [OPSAWG] Éric Vyncke's Discuss on draft-ietf-opsawg-add-encrypted-dns-11: (with DISCUSS and COMMENT)

2023-03-17 Thread mohamed.boucadair

Hi Bernie,

Thank you for clarifying.

Please see inline.

Cheers,
Med

De : Bernie Volz 
Envoyé : jeudi 16 mars 2023 22:29
À : BOUCADAIR Mohamed INNOV/NET 
Cc : Eric Vyncke (evyncke) ; The IESG ; 
draft-ietf-opsawg-add-encrypted-...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; dh...@ietf.org; jin...@wide.ad.jp
Objet : Re: Éric Vyncke's Discuss on draft-ietf-opsawg-add-encrypted-dns-11: 
(with DISCUSS and COMMENT)

I’m really not sure why there is any confusion. I think changing Section 3.1 
and 3.2 (obviously with some edits for 3.2) from:


  Permitted DHCPv6 options in the DHCPv6-Options Attribute are

  maintained by IANA in the registry created in Section 8.4.1.

to:


  Permitted DHCPv6 options in the DHCPv6-Options Attribute are

  maintained by IANA in the registry created in Section 8.4.1. If a

  DHCP server finds an option not permitted, it MUST ignore that

  option.

[Med] MUST conflicts with the config knob. I made this change:

OLD:
   RADIUS implementations may support a configuration parameter to
   control the DHCP options that can be included in a DHCP*-Options
   RADIUS attribute.  Likewise, DHCP server implementations may support
   a configuration parameter to control the permitted DHCP options in a
  DHCP*-Options RADIUS attribute.

NEW:
   RADIUS implementations may support a configuration parameter to
   control the DHCP options that can be included in a DHCP*-Options
   RADIUS attribute.  Likewise, DHCP server implementations may support
   a configuration parameter to control the permitted DHCP options in a
   DHCP*-Options RADIUS attribute.  Absent explicit configuration,
   RADIUS implementations and DHCP server implementations SHOULD ignore
   non-permitted DHCP options received in a DHCP*-Options RADIUS
attribute.

Would be a simple and reasonable fix. This doesn’t fully address the malformed 
data, such as extra data at end of attribute value that is less than 4 octets 
(dhcpv6 options have a 4-octet header) or when an option specifies a length 
that exceeds the remaining data in the attribute, but I’ll allow those issues 
to be handled by the RADIUS documents as an invalid attribute.

[Med] ACK.

Note that I don’t believe RFC7037 documented what should happen if Radius 
Attributes that are not permitted are present in the data. But that doesn’t 
mean as time goes on we shouldn’t become wiser and improve our standards to 
cover more of the potential “bad” considerations.

Until Éric raised it, I hadn’t thought about it either. Éric might still want 
to cover these malformed data issues …

- not limit itself on the validity of the RADIUS attribute but
also clearly state what the DHCP server validation should do

Also, Section 5 is also a bit lacking in how the DHCP server handles this. Yes, 
I know what is expected as having worked with DHCP for a long time … but 
standing back a bit, really is not that clear. You might want to review Section 
6 of RFC 6422. In your case, you likely want the server to prefer this option 
over whatever it may already have.

[Med] This is already covered:

   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.

- Bernie Volz

_

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

Re: [OPSAWG] Éric Vyncke's Discuss on draft-ietf-opsawg-add-encrypted-dns-11: (with DISCUSS and COMMENT)

2023-03-16 Thread mohamed.boucadair

Hi Éric, 

Thank you for the follow-up.

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Eric Vyncke (evyncke) 
> Envoyé : jeudi 16 mars 2023 14:43
> À : Bernie Volz ; BOUCADAIR Mohamed INNOV/NET
> 
> Cc : The IESG ; draft-ietf-opsawg-add-encrypted-
> d...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org;
> dh...@ietf.org; jin...@wide.ad.jp
> Objet : Re: Éric Vyncke's Discuss on draft-ietf-opsawg-add-
> encrypted-dns-11: (with DISCUSS and COMMENT)
> 
> Thank you all for this open discussion among RADIUS and DCHP
> knowledgeable people.
> 
> From what I read in various email threads and imho (that could be
> wrong of course),  this draft should still be revised to:
> - handle the differences between DHCP attributes and options (per
> Bernie's email below)

[Med] I still don't see what the issue is. I trust Bernie will further explain 
the issue. 

> - handle both IPv4 and IPv6
> - not limit itself on the validity of the RADIUS attribute but
> also clearly state what the DHCP server validation should do

[Med] If DHCP servers behave as RADIUS clients, the usual RFC6929 validation 
are followed. We have a NEW text with a reminder. This applies to both v4/v6 
attributes.
If DHCP relay agents behave as RADIUS clients, then the validation in RFC7037 
(DHCPv6) and RFC4014+Updates in this draft (DHCPv4) are followed by DHCP 
servers. 

What additional validation is missing?

> - the "SHOULD ignore" of section 4.2.2  is dangling... Why not a
> MUST or the reason why the SHOULD is not followed should be
> described
> 

[Med] That SHOULD was already in RFC4014. That’s said, and as you can see in 
https://tinyurl.com/opsawg-add-latest, we have now a NEW text to explain when 
the SHOULD is not followed. 

> Let's all work together to address those concerns, they seem easy
> to fix.
> 
> Regards
> 
> -éric
> 
> On 14/03/2023, 14:06, "iesg on behalf of Bernie Volz"  boun...@ietf.org  on behalf of
> bev...@gmail.com > wrote:
> 
> 
> Section 4.2 is about DHCPv4 and updates to RFC4014. So maybe that
> solves the issue for section 3.2 but not for 3.1? Also, while you
> say section 3 is about Radius attributes, it talks about dhcp
> options. And specifically says “ Permitted DHCPv6 options in the
> DHCPv6-Options Attribute are maintained by IANA in the registry
> created in Section 8.4.1.” So it begs the question about what
> happens if unpermitted options present (this could be an
> interoperability issue as perhaps the registry is extended and the
> radius side is updated but the dhcp server isn’t and hence finds
> options that aren’t allow by its table). Or someone stuffs a dhcp
> option in there that isn’t allowed.
> 
> 
> You also reference:
> 
> 
> > If the relay agent relays RADIUS attributes not included in the
> > IANA-maintained registry (Section 8.3 of [This-Document]), the
> DHCP
> > server SHOULD ignore them.
> 
> 
> But this is about attributes again, not options. Your new DHCPv*-
> Options Attributes can contain many DHCP options. So I think being
> clear about what happens with the potential options inside this
> single attribute is important to clarify.
> 
> 
> - Bernie (from iPad)
> 
> 
> > On Mar 14, 2023, at 7:49 AM, mohamed.boucad...@orange.com
>  wrote:
> >
> > Hi Bernie,
> >
> > Thank you for sharing your thoughts.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : Bernie Volz mailto:bev...@gmail.com>>
> Envoyé
> >> : mardi 14 mars 2023 12:10 À : BOUCADAIR Mohamed INNOV/NET
> >>  >
> >> Cc : Éric Vyncke  >; The
> >> IESG mailto:i...@ietf.org>>;
> >> draft-ietf-opsawg-add-encrypted-...@ietf.org
> >> ; opsawg-
> >> cha...@ietf.org ; opsawg@ietf.org
> >> ; dh...@ietf.org
> ;
> >> jin...@wide.ad.jp  Objet : Re: Éric
> >> Vyncke's Discuss on draft-ietf-opsawg-add-
> >> encrypted-dns-11: (with DISCUSS and COMMENT)
> >> Med:
> >> Eric asked about how non-permitted dhcp options are to be
> handled in
> >> section 3.1/3.2; you responded about RADIUS attributes?
> >
> > [Med] Yes, because these sections are about RADIUS attributes
> (and thus not about the behavior of DHCP servers). But I may be
> missing something.
> >
> >> Wouldn’t just saying that the DHCP server should ignore non-
> >> permitted DHCP options but continue otherwise (process
> remaining)?
> >> (The server may also log about dropped options to alert
> >> administrators to a potential misconfiguration.)
> >
> > [Med] That’s is covered, e.g., in the Update in Section 4.2.2:
> >
> > If the relay agent relays RADIUS attributes not included in the
> > IANA-maintained registry (Section 8.3 of [This-Document]), the
> DHCP
> > server SHOULD ignore them.
> >
> > For DHCPv6, that is

Re: [OPSAWG] Paul Wouters' Yes on draft-ietf-opsawg-add-encrypted-dns-11: (with COMMENT)

Hi Paul, 

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Paul Wouters 
> Envoyé : mercredi 15 mars 2023 18:00
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : The IESG ; draft-ietf-opsawg-add-encrypted-
> d...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org;
> dh...@ietf.org; bev...@gmail.com
> Objet : Re: Paul Wouters' Yes on draft-ietf-opsawg-add-encrypted-
> dns-11: (with COMMENT)
> 
> On Mar 15, 2023, at 02:35, mohamed.boucad...@orange.com wrote:
> >
> > 
> >>
> >>   This document targets deployments where a trusted
> relationship
> >> is in
> >>   place between the RADIUS client and server with
> communication
> >> optionally
> >>   secured by IPsec or Transport Layer Security (TLS)
> [RFC6614].
> >>
> >> I don't understand what this sentence is trying to say.
> >>
> >
> > [Med] As per today, the use of ipsec/TLs are optional in RADIUS
> in trusted networks. As you know there is an effort to make
> ipsec/TLs mandatory even for trusted networks (and deprecate the
> use of plain UDP/TCP transport) and also move 6614 to standard
> track, but all of these are still individual drafts.
> 
> But it is still always trusted for authentication. And sending ADD
> information is still possible and desirable even if radius wasn’t
> using IPsec or TLS. So I still think the sentence should just be
> removed.
> 

[Med] The use of ipsec/tls between radius client/server is superior even in 
trusted environments because, otherwise, many attacks would be possible from 
within the network (gleaning private information, etc.). I prefer to leave the 
mention of ipsec/TLS. 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

Re: [OPSAWG] Warren Kumari's No Objection on draft-ietf-opsawg-add-encrypted-dns-11: (with COMMENT)

Hi Warren, 

Thanks for the comments. 

> Like Eric I wonder what should happen with a RADIUS client
> receiving a
> non-permitted DHCP option - but perhaps this is already well known
> and
> understood?

Yes, that is part of 6929. For the reader's convenience, we added this reminder 
right before Section 3.1: 

NEW:
   Invalid attributes are handled as per Section 2.8 of
   [RFC6929].

Cheers,
Med

> -Message d'origine-
> De : Warren Kumari via Datatracker 
> Envoyé : mercredi 15 mars 2023 15:21
> À : The IESG 
> Cc : draft-ietf-opsawg-add-encrypted-...@ietf.org; opsawg-
> cha...@ietf.org; opsawg@ietf.org; dh...@ietf.org;
> bev...@gmail.com; bev...@gmail.com; d...@fl1ger.de; dns...@ietf.org
> Objet : Warren Kumari's No Objection on draft-ietf-opsawg-add-
> encrypted-dns-11: (with COMMENT)
> 
> Warren Kumari has entered the following ballot position for
> draft-ietf-opsawg-add-encrypted-dns-11: No Objection
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT
> positions.
> 
> 
> The document, along with other ballot positions, can be found
> here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-encrypted-
> dns/
> 
> 
> 
> --
> 
> COMMENT:
> --
> 
> 
> Firstly, thank you to the authors for the document. Also much
> thanks to Ralf
> Weber for reviewing and updating his DNSDIR review
> (https://datatracker.ietf.org/doc/review-ietf-opsawg-add-
> encrypted-dns-10-dnsdir-telechat-weber-2023-03-12/),
> and the authors for addressing the nits.
> 
> Like Eric I wonder what should happen with a RADIUS client
> receiving a
> non-permitted DHCP option - but perhaps this is already well known
> and
> understood?
> 
> 


_

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

Re: [OPSAWG] [dhcwg] Intdir telechat review of draft-ietf-opsawg-add-encrypted-dns-10

Hi Tatuya, 

Thank you for the follow-up. Much appreciated.

> If you're saying that this is just an example and its
> applicability doesn't matter much, then I'd be happier if it were
> clearer that the content of this section is a mere example.  

The introduction says the following: 

   A sample deployment usage of the DHCPv6-Options and DHCPv4-Options
   RADIUS attributes is described in Section 5.

To further insist this is about an example, I made the following change: 

OLD: 
  5.  Applicability to Encrypted DNS Provisioning

NEW:
  5: An Example: Applicability to Encrypted DNS Provisioning

This change together with the current text is much more clear this is an 
example to illustrate the use of

==
   Typical deployment scenarios are similar to those described, for
   ^^
   instance, in Section 2 of [RFC6911].  For illustration purposes,
 ^^ 
   Figure 1 shows an example where a Customer Premises Equipment (CPE)
   is provided with an encrypted DNS resolver.  This example assumes
   
   that the Network Access Server (NAS) embeds both RADIUS client and
   DHCPv6 server capabilities.
==

Hope this is better. 

Cheers,
Med

> -Message d'origine-
> De : JINMEI Tatuya / 神明達哉 
> Envoyé : mercredi 15 mars 2023 00:54
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : int-...@ietf.org; draft-ietf-opsawg-add-encrypted-
> dns@ietf.org; last-c...@ietf.org; opsawg@ietf.org
> Objet : Re: [dhcwg] Intdir telechat review of draft-ietf-opsawg-
> add-encrypted-dns-10
> 
> >> I'm fine with deferring such a discussion to draft-ietf-add-
> dnr; I'm
> >> also fine with just removing any reference to Reconfigure from
> this
> >> draft (and maybe stating that's an out- of-scope topic).
> 
> > [Med] I don't understand this position as what we are discussing
> here
> > is ** an example ** (not a reco or a new feature) to illustrate
> the
> > use of the attributes with CoA. That example wouldn’t be
> complete if
> > the DHCP leg is not exemplified as well. Issues with reconfigure
> are
> > well-known and adequate references for readers who want to learn
> more
> > are now provided in the document.
> 
> One main concern of mine is that it's not so clear whether it's
> just an example or not.  I actually also thought this section is
> intended just as an example.  But it's one of the body of this
> document (not in an appendix), and while the RADIUS part of the
> protocol is generic, it's obvious the primary motivation is to use
> it for ietf-add-dnr. So I also thought the applicability of this
> section may have to be discussed in more detail, either in this
> doc or in ietf-add-dnr.
> 
> If you're saying that this is just an example and its
> applicability doesn't matter much, then I'd be happier if it were
> clearer that the content of this section is a mere example.  One
> clear way for that is to move this section to an appendix.
> Another would be to add a sentence or two clarifying that intent
> at the top of that section.
> 
> If you're not willing to do either, I think we should agree to
> disagree here. In that case please feel free to dismiss my point.
> I'd also suggest removing the reference to RFC6977, since it was
> added to address my comment but it doesn't address it anyway.
> 
> --
> jinmei

_

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

Re: [OPSAWG] Paul Wouters' Yes on draft-ietf-opsawg-add-encrypted-dns-11: (with COMMENT)

Hi Paul,

Thank you for the review.

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Paul Wouters via Datatracker 
> Envoyé : mardi 14 mars 2023 19:21
> À : The IESG 
> Cc : draft-ietf-opsawg-add-encrypted-...@ietf.org; opsawg-
> cha...@ietf.org; opsawg@ietf.org; dh...@ietf.org;
> bev...@gmail.com; bev...@gmail.com
> Objet : Paul Wouters' Yes on draft-ietf-opsawg-add-encrypted-dns-
> 11: (with COMMENT)
> 
> Paul Wouters has entered the following ballot position for
> draft-ietf-opsawg-add-encrypted-dns-11: Yes
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT
> positions.
> 
> 
> The document, along with other ballot positions, can be found
> here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-encrypted-
> dns/
> 
> 
> 
> --
> 
> COMMENT:
> --
> 
> 
>This document targets deployments where a trusted
> relationship is in
>place between the RADIUS client and server with
> communication optionally
>secured by IPsec or Transport Layer Security (TLS)
> [RFC6614].
> 
> I don't understand what this sentence is trying to say.
> 

[Med] As per today, the use of ipsec/TLs are optional in RADIUS in trusted 
networks. As you know there is an effort to make ipsec/TLs mandatory even for 
trusted networks (and deprecate the use of plain UDP/TCP transport) and also 
move 6614 to standard track, but all of these are still individual drafts.

> Does table 7 really clarify the sentences used earlier that say
> exactly the
> same thing but more compact?
> 

[Med] Yes, this is a classic table in every RADISU attribute spec. 

> Why "Expert Review" and not "Specification Required" or "RFC
> Required" ?
> 

[Med] Expert Review is consistent with the policy used in RFC7037 for a similar 
registry (already cited in the draft).  

> Registration requests are to be sent to radius-dhcp-
> rev...@ietf.org
> 
> I thought we didn't put these emails in the documents anymore? But
> I guess IANA
> will get back to you on that.
> 
> NITS:
> 
> As a reminder,
> 
> I would remove this part of the text.
> 

[Med] Will be fixed. Thanks.

> 


_

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

Re: [OPSAWG] Éric Vyncke's Discuss on draft-ietf-opsawg-add-encrypted-dns-11: (with DISCUSS and COMMENT)

Re-,

> solves the issue for section 3.2 but not for 3.1? Also, while you
> say section 3 is about Radius attributes, it talks about dhcp
> options.

That's normal because DHCP options are encapsulated in the RADIUS attributes. 
However, these two sections involve RADIUS client/server not DHCP entities. 

> And specifically says “ Permitted DHCPv6 options in the
> DHCPv6-Options Attribute are maintained by IANA in the registry
> created in Section 8.4.1.” So it begs the question about what
> happens if unpermitted options present (this could be an
> interoperability issue as perhaps the registry is extended and the
> radius side is updated but the dhcp server isn’t and hence finds
> options that aren’t allow by its table). Or someone stuffs a dhcp
> option in there that isn’t allowed.

The permitted option table + the local policy will govern the behavior of the 
servers:

   RADIUS implementations may support a configuration parameter to
   control the DHCP options that can be included in a DHCP*-Options
   RADIUS attribute.  Likewise, DHCP server implementations may support
   a configuration parameter to control the permitted DHCP options in a
   DHCP*-Options RADIUS attribute.

Options that do not match will then be considered as invalid. This is supposed 
to be covered by this NEW text:

   As a reminder, invalid attributes are handled as per
   Section 2.8 of [RFC6929].

Cheers,
Med

> -Message d'origine-
> De : Bernie Volz 
> Envoyé : mardi 14 mars 2023 14:06
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : Éric Vyncke ; The IESG ;
> draft-ietf-opsawg-add-encrypted-...@ietf.org; opsawg-
> cha...@ietf.org; opsawg@ietf.org; dh...@ietf.org;
> jin...@wide.ad.jp
> Objet : Re: Éric Vyncke's Discuss on draft-ietf-opsawg-add-
> encrypted-dns-11: (with DISCUSS and COMMENT)
> 
> Section 4.2 is about DHCPv4 and updates to RFC4014. So maybe that
> solves the issue for section 3.2 but not for 3.1? Also, while you
> say section 3 is about Radius attributes, it talks about dhcp
> options. And specifically says “ Permitted DHCPv6 options in the
> DHCPv6-Options Attribute are maintained by IANA in the registry
> created in Section 8.4.1.” So it begs the question about what
> happens if unpermitted options present (this could be an
> interoperability issue as perhaps the registry is extended and the
> radius side is updated but the dhcp server isn’t and hence finds
> options that aren’t allow by its table). Or someone stuffs a dhcp
> option in there that isn’t allowed.
> 
> You also reference:
> 
> > If the relay agent relays RADIUS attributes not included in the
> > IANA-maintained registry (Section 8.3 of [This-Document]), the
> DHCP
> > server SHOULD ignore them.
> 
> But this is about attributes again, not options. Your new DHCPv*-
> Options Attributes can contain many DHCP options. So I think being
> clear about what happens with the potential options inside this
> single attribute is important to clarify.
> 
> - Bernie (from iPad)
> 
> > On Mar 14, 2023, at 7:49 AM, mohamed.boucad...@orange.com wrote:
> >
> > Hi Bernie,
> >
> > Thank you for sharing your thoughts.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : Bernie Volz 
> >> Envoyé : mardi 14 mars 2023 12:10
> >> À : BOUCADAIR Mohamed INNOV/NET 
> Cc :
> >> Éric Vyncke ; The IESG ;
> >> draft-ietf-opsawg-add-encrypted-...@ietf.org; opsawg-
> >> cha...@ietf.org; opsawg@ietf.org; dh...@ietf.org;
> jin...@wide.ad.jp
> >> Objet : Re: Éric Vyncke's Discuss on draft-ietf-opsawg-add-
> >> encrypted-dns-11: (with DISCUSS and COMMENT)
> >> Med:
> >> Eric asked about how non-permitted dhcp options are to be
> handled in
> >> section 3.1/3.2; you responded about RADIUS attributes?
> >
> > [Med] Yes, because these sections are about RADIUS attributes
> (and thus not about the behavior of DHCP servers). But I may be
> missing something.
> >
> >> Wouldn’t just saying that the DHCP server should ignore non-
> >> permitted DHCP options but continue otherwise (process
> remaining)?
> >> (The server may also log about dropped options to alert
> >> administrators to a potential misconfiguration.)
> >
> > [Med] That’s is covered, e.g., in the Update in Section 4.2.2:
> >
> > If the relay agent relays RADIUS attributes not included in the
> > IANA-maintained registry (Section 8.3 of [This-Document]), the
> DHCP
> > server SHOULD ignore them.
> >
> > For DHCPv6, that is supposed to be handled as per RFC7037. We
> are not touching any part of that spec. No?
> >
> >> Of course if the data is malformed, then following existing
> policies
> >> (rfc6929) is prudent. Though even there it isn’t 100% clear
> what to
> >> do if the attribute is well formatted but the option data is
> bad -
> >> mostly the length of the last DHCP option exceeds the remaining
> data
> >> in the RADIUS attribute. I doubt we expect RADIUS or DHCP
> servers to
> >> assure that each individual option is valid (such as the length
> is a
> >> multiple of 4 or

Re: [OPSAWG] Éric Vyncke's Discuss on draft-ietf-opsawg-add-encrypted-dns-11: (with DISCUSS and COMMENT)

Hi Bernie, 

Thank you for sharing your thoughts. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Bernie Volz 
> Envoyé : mardi 14 mars 2023 12:10
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : Éric Vyncke ; The IESG ;
> draft-ietf-opsawg-add-encrypted-...@ietf.org; opsawg-
> cha...@ietf.org; opsawg@ietf.org; dh...@ietf.org;
> jin...@wide.ad.jp
> Objet : Re: Éric Vyncke's Discuss on draft-ietf-opsawg-add-
> encrypted-dns-11: (with DISCUSS and COMMENT)
> 
> Med:
> 
> Eric asked about how non-permitted dhcp options are to be handled
> in section 3.1/3.2; you responded about RADIUS attributes?

[Med] Yes, because these sections are about RADIUS attributes (and thus not 
about the behavior of DHCP servers). But I may be missing something. 

> Wouldn’t just saying that the DHCP server should ignore non-
> permitted DHCP options but continue otherwise (process remaining)?
> (The server may also log about dropped options to alert
> administrators to a potential misconfiguration.)

[Med] That’s is covered, e.g., in the Update in Section 4.2.2:

  If the relay agent relays RADIUS attributes not included in the
  IANA-maintained registry (Section 8.3 of [This-Document]), the
  DHCP server SHOULD ignore them.

For DHCPv6, that is supposed to be handled as per RFC7037. We are not touching 
any part of that spec. No?

> 
> Of course if the data is malformed, then following existing
> policies (rfc6929) is prudent. Though even there it isn’t 100%
> clear what to do if the attribute is well formatted but the option
> data is bad - mostly the length of the last DHCP option exceeds
> the remaining data in the RADIUS attribute. I doubt we expect
> RADIUS or DHCP servers to assure that each individual option is
> valid (such as the length is a multiple of 4 or 16 if data is list
> of addresses).
> 
> - Bernie (from iPad)
> 
> > On Mar 14, 2023, at 6:38 AM, mohamed.boucad...@orange.com wrote:
> >
> > Hi Éric,
> >
> > Thank you for the review. The changes to address your review can
> be seen at: https://tinyurl.com/opsawg-add-latest.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : Éric Vyncke via Datatracker  Envoyé :
> mardi 14
> >> mars 2023 10:30 À : The IESG  Cc :
> >> draft-ietf-opsawg-add-encrypted-...@ietf.org; opsawg-
> >> cha...@ietf.org; opsawg@ietf.org; dh...@ietf.org;
> bev...@gmail.com;
> >> bev...@gmail.com; jin...@wide.ad.jp Objet : Éric Vyncke's
> Discuss on
> >> draft-ietf-opsawg-add-encrypted-
> >> dns-11: (with DISCUSS and COMMENT)
> >>
> >> Éric Vyncke has entered the following ballot position for
> >> draft-ietf-opsawg-add-encrypted-dns-11: Discuss
> >>
> >> When responding, please keep the subject line intact and reply
> to all
> >> email addresses included in the To and CC lines. (Feel free to
> cut
> >> this introductory paragraph, however.)
> >>
> >>
> >> Please refer to
> >> https://www.ietf.org/about/groups/iesg/statements/handling-
> ballot-
> >> positions/
> >> for more information about how to handle DISCUSS and COMMENT
> >> positions.
> >>
> >>
> >> The document, along with other ballot positions, can be found
> >> here:
> >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-
> encrypted-
> >> dns/
> >>
> >>
> >>
> >> ---
> ---
> >> 
> >> DISCUSS:
> >> ---
> ---
> >> 
> >>
> >>
> >> # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-add-
> >> encrypted-dns-11
> >> CC @evyncke
> >>
> >> Thank you for the work put into this document. Once the trivial
> >> DISCUSS is addressed, I will be happy to ballot a YES.
> >>
> >> Please find below one blocking DISCUSS points (easy to
> address), some
> >> non-blocking COMMENT points (but replies would be appreciated
> even if
> >> only for my own education), and some nits.
> >>
> >> Special thanks to Bernie Volz for the shepherd's detailed
> write-up
> >> including the WG consensus even if the justification of the
> intended
> >> status is rather vague.
> >>
> >> Other thanks to Tatuya Jinmei, the Internet directorate
> reviewer (at
> >> my request), please consider this int-dir review:
> >> https://datatracker.ietf.org/doc/review-ietf-opsawg-add-
> encrypted-
> >> dns-10-intdir-telechat-jinmei-2023-03-09/
> >> (and I have read Med's replies and resolution of the issues)
> >>
> >> I hope that this review helps to improve the document,
> >>
> >> Regards,
> >>
> >> -éric
> >>
> >> ## DISCUSS
> >>
> >> As noted in https://www.ietf.org/blog/handling-iesg-ballot-
> >> positions/, a
> >> DISCUSS ballot is a request to have a discussion on the
> following
> >> topics:
> >>
> >> ### What to do with non-permitted DHCP option ?
> >>
> >> Sections 3.1 and 3.2 contain text like `Permitted DHCPv6
> options in
> >> the DHCPv6-Options Attribute are maintained by IANA in the
> registry
> >> created in Section 8.4.1.` but I was unable to find anywhere in
> the

Re: [OPSAWG] Éric Vyncke's Discuss on draft-ietf-opsawg-add-encrypted-dns-11: (with DISCUSS and COMMENT)

Hi Éric, 

Thank you for the review. The changes to address your review can be seen at: 
https://tinyurl.com/opsawg-add-latest.

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Éric Vyncke via Datatracker 
> Envoyé : mardi 14 mars 2023 10:30
> À : The IESG 
> Cc : draft-ietf-opsawg-add-encrypted-...@ietf.org; opsawg-
> cha...@ietf.org; opsawg@ietf.org; dh...@ietf.org;
> bev...@gmail.com; bev...@gmail.com; jin...@wide.ad.jp
> Objet : Éric Vyncke's Discuss on draft-ietf-opsawg-add-encrypted-
> dns-11: (with DISCUSS and COMMENT)
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-opsawg-add-encrypted-dns-11: Discuss
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT
> positions.
> 
> 
> The document, along with other ballot positions, can be found
> here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-encrypted-
> dns/
> 
> 
> 
> --
> 
> DISCUSS:
> --
> 
> 
> 
> # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-add-
> encrypted-dns-11
> CC @evyncke
> 
> Thank you for the work put into this document. Once the trivial
> DISCUSS is
> addressed, I will be happy to ballot a YES.
> 
> Please find below one blocking DISCUSS points (easy to address),
> some
> non-blocking COMMENT points (but replies would be appreciated even
> if only for
> my own education), and some nits.
> 
> Special thanks to Bernie Volz for the shepherd's detailed write-up
> including
> the WG consensus even if the justification of the intended status
> is rather
> vague.
> 
> Other thanks to Tatuya Jinmei, the Internet directorate reviewer
> (at my
> request), please consider this int-dir review:
> https://datatracker.ietf.org/doc/review-ietf-opsawg-add-encrypted-
> dns-10-intdir-telechat-jinmei-2023-03-09/
> (and I have read Med's replies and resolution of the issues)
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> ## DISCUSS
> 
> As noted in https://www.ietf.org/blog/handling-iesg-ballot-
> positions/, a
> DISCUSS ballot is a request to have a discussion on the following
> topics:
> 
> ### What to do with non-permitted DHCP option ?
> 
> Sections 3.1 and 3.2 contain text like `Permitted DHCPv6 options
> in the
> DHCPv6-Options Attribute are maintained by IANA in the registry
> created in
> Section 8.4.1.` but I was unable to find anywhere in the document
> what is the
> expected behaviour of a RADIUS client receiving a non-permitted
> DHCP option ?
> At the bare minimum, I would expect the I-D to mention "non-
> permitted DHCP
> options MUST silently be ignored by the RADIUS client"
> 

[Med] Absent any local policy, non-permitted attributes should be considered as 
invalid (rfc6929#section-2.8). 

RADIUS attributes specs usually don't repeat validation checks as this is 
redundant with rfc8044, especially: 

   Where the contents of a data type do not match the definition,
   implementations MUST treat the enclosing attribute as being an
   invalid attribute.  This requirement includes, but is not limited to,
   the following situations...

Unless Alan has a string objection, we can add this generic text right before 
Section 3.1:

"As a reminder, invalid attributes are handled as per Section 2.8 of [RFC6929]".


> Or did I fail to find a similar statement in the text ?
> 
> 
> --
> 
> COMMENT:
> --
> 
> 
> 
> ## COMMENTS
> 
> ### Abstract
> 
> Should the sentence `Even if the specification was initially
> motivated by the
> configuration of encrypted DNS resolvers,` be removed from the
> abstract ? It
> adds nothing but confusion.
> 

[Med] OK, deleted that part of the sentence. 

> ### Section 3
> 
> Should the whole paragraph starting with `RADIUS servers have
> conventionally
> tolerated the input of arbitrary data via the "string" data type
> (Section 3.5
> of [RFC8044])... ` rather be in the security (or operational)
> considerations
> section ?
> 

[Med] Good suggestion. Fixed. 

> ### Section 3.1
> 
> Should normative language be used in `However, the server is not
> required to
> honor such a preference.`? I.e., the rest of the paragraph uses
> normative
> language.
> 

[Med] I'm afraid that "s/is no/MAY NOT" is not justified here as the client is 
prepared that its preference to be ignored. There is no impact on interop or 
there will be a "reduced functionality".


> ### Section 4
> 
> Should 'DHCP relay' be mentioned in the section title ? It would
> of course be
>

Re: [OPSAWG] [dhcwg] Intdir telechat review of draft-ietf-opsawg-add-encrypted-dns-10