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

[tirumal reddy]

On Thu, 13 Oct 2022 at 16:55, tom petch  wrote:

> From: tirumal reddy 
> Sent: 13 October 2022 07:57
>
> Thanks Tom for the review. Yes, we will fix the references identified by
> Tom.
>
> 
> -09 looks better.
>
> I still see a mix of TLS-1.2 and TLS-1-2; I am not sure if there is a
> rationale for that.  I prefer the former but that mix of characters may
> confuse others.
>

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


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

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


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


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

Cheers,
-Tiru


>
>
> Tom Petch
>
> Cheers,
> -Tiru
>
> On Wed, 12 Oct 2022 at 18:37, Henk Birkholz <
> henk.birkh...@sit.fraunhofer.de>
> wrote:
> Hi Tom,
>
> would it be possible for you to augment your first comment with change
> proposals, if possible?
>
> @authors: it seems to me that the references issues Tom now provided in
> specific detail could be resolved in this thread in a timely manner. Is
> that correct?
>
> Viele Grüße,
>
> Henk
>
> On 12.10.22 13:39, tom petch wrote:
> > From: OPSAWG mailto:opsawg-boun...@ietf.org>>
> on behalf of Henk Birkholz  henk.birkh...@sit.fraunhofer.de>>
> > Sent: 06 October 2022 13:26
> >
> > Dear authors and contributors,
> >
> > thank you for your hard work. As it seems that all existing issues have
> > been resolve, we'll move the I-D to write-up in the datatracker.
> >
> > Also, thanks Thomas Fossati for stepping up as shepherd!
> >
> > 
> > My main comment on this remains the mix of two different YANG modules
> with different life cycles; I expect that l will comment again on the Last
> Call list to give this issue more exposure.
> >
> > Of lesser import, I cannot make sense of the references.
> > I see [RFC5246] which normally means that a reference has been created.
> Not here, so there would seem to have been some chicanery involved, that
> this I-D has not been produced by the usual IETF tools.
> >
> > I also see RFC5869, RFC6346, RFC8447 which seem absent from the I-D
> References.
> >
> > dtls13 is now an RFC.
> >
> > What is the difference between
> > draft-ietf-tls-dtls13:
> > and
> >  "RFC : Datagram Transport Layer Security 1.3";
> >   ?
> > How do I find
> >  "RFC : Common YANG Data Types for Cryptography";
> >   or
> > "RFC : Common YANG Data Types for Hash algorithms"; ?
> >
> > Does tls-1-2 mean the same as tls-1.2?  And is this the same as that
> which the Netconf WG refers to as tls12?
> >
> > Tom Petch
> >
> >
> > For the OPSAWG co-chairs,
> >
> > Henk
> >
> >
> > On 29.09.22 10:27, Henk Birkholz wrote:
> >> Dear OPSAWG members,
> >>
> >> this email concludes the first WGLC call for
> >> https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html.
> >>
> >> A few comments where raised. Authors/editors, please go ahead and
> >> address these as discussed on the list.
> >>
> >>
> >> For the OPSAWG co-chairs,
> >>
> >> Henk
> >>
> >> On 14.09.22 16:07, Henk Birkholz wrote:
> >>> Dear OPSAWG members,
> >>>
> >>> this email starts a two week period for a Working Group Last Call of
> >>>
>  https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html
> >>>
> >>> ending on Thursday, September 28th.
> >>>
> >>> The authors believe the Internet-Draft is ready for a WGLC and the
> >>> chairs agree. The draft has been discussed visibly at IETF 114 and
> >>> review feedback has been incorporated in -07.
> >>>
> >>> Please send your comments to the list and your assessment of whether
> >>> or not it is ready to proceed to publication before September 28th.
> >>>
> >>>
> >>> For the OPSAWG co-chairs,
> >>>
> >>> Henk
> >>
> >> ___
> >> OPSAWG mailing list
> >> OPSAWG@ietf.org
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >
> > ___
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[mohamed.boucadair]

Re-,

Thanks for the feedback.

Let's try to exercise this approach and see if there are not hidden 
complications vs. current design with known limitation. A drafty text (not yet 
in the main draft) can be seen at: 
https://github.com/boucadair/draft-ietf-opsawg-add-encrypted-dns/blob/main/draft-ietf-opsawg-add-encrypted-dns-encap.txt

A diff is also available at: 
https://www.ietf.org/rfcdiff?url1=draft-ietf-opsawg-add-encrypted-dns&url2=https://raw.githubusercontent.com/boucadair/draft-ietf-opsawg-add-encrypted-dns/master/draft-ietf-opsawg-add-encrypted-dns-encap.txt

The attributes should not be seen as opaque data by the RADIUS server but it 
should understand the encoding of the enclosed options. The intended behavior 
should be called out, IMO.

For the case of RA-triggered authorization process, some adaptation is needed 
as the encoding is a little but distinct vs. DHCPv6. The mapping should also be 
explicated. 

Cheers,
Med

> -Message d'origine-
> De : Alan DeKok 
> Envoyé : jeudi 13 octobre 2022 17:16
> À : Ben Schwartz 
> Cc : Joe Abley ; BOUCADAIR Mohamed INNOV/NET
> ; Ben Schwartz
> ; Joe Clarke (jclarke)
> ; opsawg ; rad...@ietf.org;
> ADD Mailing list 
> Objet : Re: [Add] [OPSAWG] 🔔 WG LC: RADIUS Extensions for
> Encrypted DNS
> 
> On Oct 13, 2022, at 10:50 AM, Ben Schwartz 
> wrote:
> > Even if longer SvcParams aren't useful in DNR, creating an
> encoding that can't carry them introduces a serious compatibility
> problem for systems that copy between SVCB, DNR, and RADIUS.  What
> is such a tool supposed to do when a valid SVCB record or DNR
> option is unrepresentable in RADIUS?  What is a naive operator to
> do, faced with this error message?
> 
>   The traditional RADIUS solution for encoding data which can't
> fit into an attribute is one of (a) truncation, or (b) dropping
> the attribute entirely.  The standards are silent on this issue,
> so the behavior is entirely implementation-defined.
> 
>   As for this issue, it may be best to avoid it entirely with
> careful design, so that it's not possible for implementations to
> run into the problem.
> 
> 
>   The only solution which entirely avoids the 253 octet limit is
> to just define a DHCPv6-Options attribute in RADIUS.  It can carry
> a blob of DHCPv6 options, encoded as DHCPv6 options.  This is
> behavior is permitted by https://www.rfc-
> editor.org/rfc/rfc6158#section-3.2.4:
> 
>  Another exception to the recommendation against complex types
> is for
>  types that can be treated as opaque data by the RADIUS
> server.
> 
>   So just define a DHCPv6-Options attribute from the 245.X space.
> Allow it to contain any DHCPv6 option.  Suggest that the switch /
> RADIUS client send the options in a DHCPv6 packet.  And then it
> can carry the options needed here.
> 
>   Since the encoding is now DHCPv6 options, all limitations other
> than the 4K RADIUS "maximum packet size" limitation disappear.
> And many RADIUS implementations support packets larger than 4K, so
> that limit is not concrete either.  The specification defining
> DHCPv6-Options could suggest that implementations SHOULD support
> 64K RADIUS packets.
> 
>   Alan DeKok.


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [OPSAWG] 🔔 WGLC and Shepherd write-up concluded for draft-ietf-opsawg-sbom-access

[Henk Birkholz]

Dear OPSAWG members,

reading no objections, we'll start the submission to IESG.

Thanks again to Eliot and Scott for driving the work, to Qin as the 
document shepherd and to all contributors and reviewers.


Viele Grüße,

Henk

On 10.10.22 09:46, Henk Birkholz wrote:

Dear OPSAWG members,

the chairs think consensus on this I-D is established and that it is 
ready to be submitted to IESG for publication.


We'll let that assessment simmer here on the list for a few days before 
pushing the buttons, checking for pending comments from ADs and the list.



For the OPSAWG co-chairs,

Henk

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


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

[OPSAWG] Publication has been requested for draft-ietf-opsawg-sbom-access-12

[Henk Birkholz via Datatracker]

Henk Birkholz has requested publication of draft-ietf-opsawg-sbom-access-12 as 
Proposed Standard on behalf of the OPSAWG working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/


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

[OPSAWG] [Errata Verified] RFC9291 (7162)

[RFC Errata System]

The following errata report has been verified for RFC9291,
"A YANG Network Data Model for Layer 2 VPNs". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7162

--
Status: Verified
Type: Editorial

Reported by: Nikolai Malykh 
Date Reported: 2022-10-13
Verified by: Rob Wilton (IESG)

Section: 9

Original Text
-
   'ethernet-segments' and 'vpn-services':  An attacker who is able to
  access network nodes can undertake various attacks, such as
  deleting a running L2VPN service, interrupting all the traffic of
  a client.  In addition, an attacker may modify the attributes of a
  running service (e.g., QoS, bandwidth) or an ES, leading to
  malfunctioning of the service and therefore to SLA violations.  In
  addition, an attacker could attempt to create an L2VPN service,
  add a new network access, or intercept/redirect the traffic to a
  non-authorized node.  In addition to using NACM to prevent
  authorized access, such activity can be detected by adequately
  monitoring and tracking network configuration changes.


Corrected Text
--
   'ethernet-segments' and 'vpn-services':  An attacker who is able to
  access network nodes can undertake various attacks, such as
  deleting a running L2VPN service, interrupting all the traffic of
  a client.  In addition, an attacker may modify the attributes of a
  running service (e.g., QoS, bandwidth) or an ES, leading to
  malfunctioning of the service and therefore to SLA violations.  In
  addition, an attacker could attempt to create an L2VPN service,
  add a new network access, or intercept/redirect the traffic to a
  non-authorized node.  In addition to using NACM to prevent
  unauthorized access, such activity can be detected by adequately
  monitoring and tracking network configuration changes.


Notes
-
Typo in last sentence, should be "unauthorized".

--
RFC9291 (draft-ietf-opsawg-l2nm-19)
--
Title   : A YANG Network Data Model for Layer 2 VPNs
Publication Date: September 2022
Author(s)   : M. Boucadair, Ed., O. Gonzalez de Dios, Ed., S. Barguil, 
L. Munoz
Category: PROPOSED STANDARD
Source  : Operations and Management Area Working Group
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

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

Re: [OPSAWG] [Editorial Errata Reported] RFC9291 (7162)

[Rob Wilton (rwilton)]

Yes.  I've just verified it.  Nikolai, thanks for raising it.

Regards,
Rob



From: Joe Clarke (jclarke) 
Sent: 13 October 2022 13:48
To: mohamed.boucad...@orange.com; RFC Errata System 
; nmal...@ieee.org
Cc: luis-angel.mu...@vodafone.com; opsawg@ietf.org; Rob Wilton (rwilton) 

Subject: Re: [Editorial Errata Reported] RFC9291 (7162)

Agreed.  Rob?

Joe

From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Date: Thursday, October 13, 2022 at 7:29 AM
To: RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>>, 
nmal...@ieee.org 
mailto:nmal...@ieee.org>>
Cc: luis-angel.mu...@vodafone.com 
mailto:luis-angel.mu...@vodafone.com>>, 
opsawg@ietf.org 
mailto:opsawg@ietf.org>>
Subject: Re: [OPSAWG] [Editorial Errata Reported] RFC9291 (7162)
Hi Nikolai, all,

Thank you for reporting this.

This editorial erratum should be accepted. Thanks.

Cheers,
Med

> -Message d'origine-
> De : RFC Errata System 
> mailto:rfc-edi...@rfc-editor.org>>
> Envoyé : jeudi 13 octobre 2022 13:23
> À : rfc-edi...@rfc-editor.org
> Cc : nmal...@ieee.org; BOUCADAIR Mohamed INNOV/NET
> mailto:mohamed.boucad...@orange.com>>;
> oscar.gonzalezded...@telefonica.com;
> samier.barguilgiraldo@telefonica.com;
>  luis-
> angel.mu...@vodafone.com; 
> opsawg@ietf.org
> Objet : [Editorial Errata Reported] RFC9291 (7162)
>
> The following errata report has been submitted for RFC9291, "A
> YANG Network Data Model for Layer 2 VPNs".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7162
>
> --
> Type: Editorial
> Reported by: Nikolai Malykh mailto:nmal...@ieee.org>>
>
> Section: 9
>
> Original Text
> -
>'ethernet-segments' and 'vpn-services':  An attacker who is
> able to
>   access network nodes can undertake various attacks, such as
>   deleting a running L2VPN service, interrupting all the
> traffic of
>   a client.  In addition, an attacker may modify the
> attributes of a
>   running service (e.g., QoS, bandwidth) or an ES, leading to
>   malfunctioning of the service and therefore to SLA
> violations.  In
>   addition, an attacker could attempt to create an L2VPN
> service,
>   add a new network access, or intercept/redirect the traffic
> to a
>   non-authorized node.  In addition to using NACM to prevent
>   authorized access, such activity can be detected by
> adequately
>   monitoring and tracking network configuration changes.
>
>
> Corrected Text
> --
>'ethernet-segments' and 'vpn-services':  An attacker who is
> able to
>   access network nodes can undertake various attacks, such as
>   deleting a running L2VPN service, interrupting all the
> traffic of
>   a client.  In addition, an attacker may modify the
> attributes of a
>   running service (e.g., QoS, bandwidth) or an ES, leading to
>   malfunctioning of the service and therefore to SLA
> violations.  In
>   addition, an attacker could attempt to create an L2VPN
> service,
>   add a new network access, or intercept/redirect the traffic
> to a
>   non-authorized node.  In addition to using NACM to prevent
>   unauthorized access, such activity can be detected by
> adequately
>   monitoring and tracking network configuration changes.
>
>
> Notes
> -
> Typo in last sentence, should be "unauthorized".
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary,
> please use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party can log
> in to change the status and edit the report, if necessary.
>
> --
> RFC9291 (draft-ietf-opsawg-l2nm-19)
> --
> Title   : A YANG Network Data Model for Layer 2 VPNs
> Publication Date: September 2022
> Author(s)   : M. Boucadair, Ed., O. Gonzalez de Dios, Ed.,
> S. Barguil, L. Munoz
> Category: PROPOSED STANDARD
> Source  : Operations and Management Area Working Group
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG

_

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, ve

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

[tom petch]

From: tirumal reddy 
Sent: 14 October 2022 09:22

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

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


-09 looks better.

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

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


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

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


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

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


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

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

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

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

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

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

s.5.2
/Simplified BSD/Revised BSD/

revision date is out of date

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

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

s.5.3
BSD license again

revision date again

s.5.4
ditto

author e-mail address is not the same as elsewhere

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

does profile-supported have a default?

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

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

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

Tom Petch





Cheers,
-Tiru



Tom Petch

Cheers,
-Tiru

On Wed, 12 Oct 2022 at 18:37, Henk Birkholz 
mailto:henk.birkh...@sit.fraunhofer.de>>>
 wrote:
Hi Tom,

would it be possible for you to augment your first comment with change
proposals, if possible?

@authors: it seems to me that the references issues Tom now provided in
specific detail could be resolved in this thread in a timely manner. Is
that correct?

Viele Grüße,

Henk

On 12.10.22 13:39, tom petch wrote:
> From: OPSAWG 
> mailto:opsawg-boun...@ietf.org>>>
>  on behalf of Henk Birkholz 
> mailto:henk.birkh...@sit.fraunhofer.de>>>
> Sent: 06 October 2022 13:26
>
> Dear authors and contributors,
>
> thank you for your hard work. As it seems that all existing issues have
> been resolve, we'll move the I-D to write-up in the datatracker.
>
> Also, thanks Thomas Fossati for stepping up as shepherd!
>
> 
> My main comment on this remains the mix of two different YANG modules with 
> different life cycles; I expect that l will comment again on the Last Call 
> list to give this issue more exposure.
>
> Of lesser import, I cannot make sense of the references.
> I see [RFC5246] which normally means that a reference has been created.  Not 
> here, so there would seem to have been some chicanery involved, that this I-D 
> has not been produced by the usual IETF tools.
>
> I also see RFC5869, RFC6346, RFC8447 which seem absent from the I-D 
> References.
>
> dtls13 is now an RFC.
>
> What is the difference between
> draft-ietf-tls-dtls13:
> and
>  "RFC : Datagram Transport Layer Security 1.3";
>   ?
> How do I find
>  "RFC : Common YANG Data Types for Cryptography";
>   or
> "RFC : Common YANG Data Types for Hash algorithms"; ?
>
> Does tls-1-2 mean the same as tls-1.2?  And is this the same as that which 
> the Netconf WG refers to as tls12?
>
> Tom Petch
>
>
> For the OPSAWG co-chairs,
>
> Henk
>
>
> On 29.09.22 10:27, Henk Birkholz wrote:
>> Dear OPSAWG members,
>>
>> this email concludes the first WGLC call for
>> https://www.ietf.org/archive/id/draft-ietf-opsawg

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

[tirumal reddy]

On Fri, 14 Oct 2022 at 16:46, tom petch  wrote:

> From: tirumal reddy 
> Sent: 14 October 2022 09:22
>
> On Thu, 13 Oct 2022 at 16:55, tom petch  ie...@btconnect.com>> wrote:
> From: tirumal reddy mailto:kond...@gmail.com>>
> Sent: 13 October 2022 07:57
>
> Thanks Tom for the review. Yes, we will fix the references identified by
> Tom.
>
> 
> -09 looks better.
>
> I still see a mix of TLS-1.2 and TLS-1-2; I am not sure if there is a
> rationale for that.  I prefer the former but that mix of characters may
> confuse others.
>
> Good point, fixed in my copy
> https://github.com/tireddy2/mud-tls/blob/master/draft-ietf-opsawg-mud-tls-10.txt
> .
>
>
> I see a number of editorial issues - I do not know if you want to look at
> those now or leave them to Last Call.
>
> Please feel free to raise the editorial issues, we will fix them.
>
>
> One slightly technical one is that it is very rare to start a YANG prefix
> with ietf as the IANA webpages show - filename, MUST, prefix SHOULD NOT
> IMHO.  Thus acl has a prefix of acl so I would see the augment as acl-tls
> and not ietf-acl-tls; but mud is ietf-mud (unfortunately:-( so the augment
> is perhaps  better as ietf-mud-tls.
>
> We followed the format similar to ietf-access-control-list (YANG data
> model of network ACL) and ietf-mud to be consistent.
>
> 
> Um, that is not what I see.  It is the prefix I have in mind where RFC8519
> specifies a prefix of acl and that is what you use in the import.  An
> extension to that module could then have a prefix of acl-xxx or some such
> where you have specified ietf-acl-tls.  It is that 'ietf' that I see as
> unusual.
>

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


>
> Editorially, not all of which you may want to fix at this time
>
> 'The YANG module specified in Section 5...'
> suggest adding the subsection since there is more than one
>
> 'specific terms are used'
> suggest using the terms here e.g. TLS and DTLS are used
>
> s.4
> incapable to decipher
> perhaps 'unable to decipher' or 'incapable of deciphering'
>
> s.5.1
> Add an Infornative Reference to RFC8340 for the meaning of tree diagrams
>
> s.5.2
> /Simplified BSD/Revised BSD/
>
> revision date is out of date
>
> SPKI probably needs expanding both in the body and in the YANG modules
>
> The description of certificate-authorities looks like it is too long for
> an RFC
>
> s.5.3
> BSD license again
>
> revision date again
>
> s.5.4
> ditto
>
> author e-mail address is not the same as elsewhere
>
> YANG import MUST have a reference clause which MUST be a Normative
> reference
>

Thanks, I fixed all the above editorial issues.


>
> does profile-supported have a default ?
>

No.


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

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


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

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


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

Yes, I added details for Expert Review..

Cheers,
-Tiru


>
> Tom Petch
>
>
>
>
>
> Cheers,
> -Tiru
>
>
>
> Tom Petch
>
> Cheers,
> -Tiru
>
> On Wed, 12 Oct 2022 at 18:37, Henk Birkholz <
> henk.birkh...@sit.fraunhofer.de >>> wrote:
> Hi Tom,
>
> would it be possible for you to augment your first comment with change
> proposals, if possible?
>
> @authors: it seems to me that the references issues Tom now provided in
> specific detail could be resolved in this thread in a timely manner. Is
> that correct?
>
> Viele Grüße,
>
> Henk
>
> On 12.10.22 13:39, tom petch wrote:
> > From: OPSAWG mailto:opsawg-boun...@ietf.org
> >>> on
> behalf of Henk Birkholz  henk.birkh...@sit.fraunhofer.de> >>
> > Sent: 06 October 2022 13:26
> >
> > Dear authors and contributors,
> >
> > thank you for your hard work. As it seems that all existing issues have
> > been resolve, we'll move the I-D to write-up in the datatracker.
> >
> > Also, thanks Thomas Fossati for stepping up as shepherd!
> >
> > 
> > My main comment on this remains the mix of two different YANG modules
> with different life cycles; I expect that l will comment again on the Last
> Call list to give this issue more exposure.
> >
> > Of lesser import, I cannot make sense of the references.
> > I see [RFC5246] which normally means that a reference has been created.
> Not here, so there would seem to have been some chicanery involved, that
> this I-D has not been produced by the usual IETF tools.
> >
> > I also see RFC5869, RFC6346, RFC8447 which seem absent from the I-D
> References.
> >
> > dtls13 is now an RFC.
> >
> > What is the

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

[Alan DeKok]

On Oct 14, 2022, at 5:47 AM,  
 wrote:
> Let's try to exercise this approach and see if there are not hidden 
> complications vs. current design with known limitation. A drafty text (not 
> yet in the main draft) can be seen at: 
> https://github.com/boucadair/draft-ietf-opsawg-add-encrypted-dns/blob/main/draft-ietf-opsawg-add-encrypted-dns-encap.txt

  Nits:

Section 3: just drop the ASCII art.  RFC 8044 makes it no longer necessary.

Section 3.1, 3.2, and 7.1: the data type should be "string" for "opaque data"

  Other than that, it looks good on first read-through.
 
> The attributes should not be seen as opaque data by the RADIUS server but it 
> should understand the encoding of the enclosed options. The intended behavior 
> should be called out, IMO.

  I would suggest saying something like "for ease of administrator 
configuration, the RADIUS server SHOULD expose the DHCP options and allow 
administrators to configure them, instead of requiring them to be entered as 
opaque data".

  That gets the best of both worlds.

  Alan DeKok.

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

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

[mohamed.boucadair]

Re-,

Works for me. Thanks.

I will run this candidate version with dhcwg as well. 

Cheers,
Med 

> -Message d'origine-
> De : Alan DeKok 
> Envoyé : vendredi 14 octobre 2022 16:00
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : Ben Schwartz ; Joe Abley
> ; Ben Schwartz
> ; Joe Clarke (jclarke)
> ; opsawg ; rad...@ietf.org;
> ADD Mailing list 
> Objet : Re: [Add] [OPSAWG] 🔔 WG LC: RADIUS Extensions for
> Encrypted DNS
> 
> 
> On Oct 14, 2022, at 5:47 AM, 
>  wrote:
> > Let's try to exercise this approach and see if there are not
> hidden complications vs. current design with known limitation. A
> drafty text (not yet in the main draft) can be seen at:
> https://github.com/boucadair/draft-ietf-opsawg-add-encrypted-
> dns/blob/main/draft-ietf-opsawg-add-encrypted-dns-encap.txt
> 
>   Nits:
> 
> Section 3: just drop the ASCII art.  RFC 8044 makes it no longer
> necessary.
> 
> Section 3.1, 3.2, and 7.1: the data type should be "string" for
> "opaque data"
> 
>   Other than that, it looks good on first read-through.
> 
> > The attributes should not be seen as opaque data by the RADIUS
> server but it should understand the encoding of the enclosed
> options. The intended behavior should be called out, IMO.
> 
>   I would suggest saying something like "for ease of administrator
> configuration, the RADIUS server SHOULD expose the DHCP options
> and allow administrators to configure them, instead of requiring
> them to be entered as opaque data".
> 
>   That gets the best of both worlds.
> 
>   Alan DeKok.


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 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] [Add] 🔔 WG LC: RADIUS Extensions for Encrypted DNS

[mohamed.boucadair]

Hi Bernie, dhcwg, 

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

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

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

Thank you.

Cheers,
Med

> -Message d'origine-
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : vendredi 14 octobre 2022 16:32
> À : 'Alan DeKok' 
> Cc : Ben Schwartz ; Joe Clarke (jclarke)
> ; opsawg ; rad...@ietf.org;
> ADD Mailing list 
> Objet : RE: [Add] [OPSAWG] 🔔 WG LC: RADIUS Extensions for
> Encrypted DNS
> 
> Re-,
> 
> Works for me. Thanks.
> 
> I will run this candidate version with dhcwg as well.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Alan DeKok  Envoyé : vendredi 14
> > octobre 2022 16:00 À : BOUCADAIR Mohamed INNOV/NET
> >  Cc : Ben Schwartz
> ;
> > Joe Abley ; Ben Schwartz
> > ; Joe Clarke (jclarke)
> > ; opsawg ; rad...@ietf.org;
> ADD
> > Mailing list  Objet : Re: [Add] [OPSAWG] 🔔 WG LC:
> > RADIUS Extensions for Encrypted DNS
> >
> >
> > On Oct 14, 2022, at 5:47 AM, 
> >  wrote:
> > > Let's try to exercise this approach and see if there are not
> > hidden complications vs. current design with known limitation. A
> > drafty text (not yet in the main draft) can be seen at:
> > https://github.com/boucadair/draft-ietf-opsawg-add-encrypted-
> > dns/blob/main/draft-ietf-opsawg-add-encrypted-dns-encap.txt
> >
> >   Nits:
> >
> > Section 3: just drop the ASCII art.  RFC 8044 makes it no longer
> > necessary.
> >
> > Section 3.1, 3.2, and 7.1: the data type should be "string" for
> > "opaque data"
> >
> >   Other than that, it looks good on first read-through.
> >
> > > The attributes should not be seen as opaque data by the RADIUS
> > server but it should understand the encoding of the enclosed
> options.
> > The intended behavior should be called out, IMO.
> >
> >   I would suggest saying something like "for ease of
> administrator
> > configuration, the RADIUS server SHOULD expose the DHCP options
> and
> > allow administrators to configure them, instead of requiring
> them to
> > be entered as opaque data".
> >
> >   That gets the best of both worlds.
> >
> >   Alan DeKok.


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 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] [Add] 🔔 WG LC: RADIUS Extensions for Encrypted DNS

[Bernie Volz]

Hi:

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

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

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

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

- Bernie Volz

> On Oct 14, 2022, at 10:45 AM, mohamed.boucad...@orange.com wrote:
> 
> Hi Bernie, dhcwg, 
> 
> We received a comment during the WGLC of this draft that might lead us to 
> revisit the design you have reviewed recently. This alternative design 
> mirrors what we have done in 7037 (dhcwg) but with DHCP options included in 
> RADIUS. The candidate text is available at: 
> 
> https://github.com/boucadair/draft-ietf-opsawg-add-encrypted-dns/blob/main/draft-ietf-opsawg-add-encrypted-dns-encap.txt
> 
> I'd appreciate if you can review this proposal and share any comments/issues 
> you may have.
> 
> Thank you.
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : BOUCADAIR Mohamed INNOV/NET
>> Envoyé : vendredi 14 octobre 2022 16:32
>> À : 'Alan DeKok' 
>> Cc : Ben Schwartz ; Joe Clarke (jclarke)
>> ; opsawg ; rad...@ietf.org;
>> ADD Mailing list 
>> Objet : RE: [Add] [OPSAWG] 🔔 WG LC: RADIUS Extensions for
>> Encrypted DNS
>> 
>> Re-,
>> 
>> Works for me. Thanks.
>> 
>> I will run this candidate version with dhcwg as well.
>> 
>> Cheers,
>> Med
>> 
>>> -Message d'origine-
>>> De : Alan DeKok  Envoyé : vendredi 14
>>> octobre 2022 16:00 À : BOUCADAIR Mohamed INNOV/NET
>>>  Cc : Ben Schwartz
>> ;
>>> Joe Abley ; Ben Schwartz
>>> ; Joe Clarke (jclarke)
>>> ; opsawg ; rad...@ietf.org;
>> ADD
>>> Mailing list  Objet : Re: [Add] [OPSAWG] 🔔 WG LC:
>>> RADIUS Extensions for Encrypted DNS
>>> 
>>> 
>>> On Oct 14, 2022, at 5:47 AM, 
>>>  wrote:
 Let's try to exercise this approach and see if there are not
>>> hidden complications vs. current design with known limitation. A
>>> drafty text (not yet in the main draft) can be seen at:
>>> https://github.com/boucadair/draft-ietf-opsawg-add-encrypted-
>>> dns/blob/main/draft-ietf-opsawg-add-encrypted-dns-encap.txt
>>> 
>>>  Nits:
>>> 
>>> Section 3: just drop the ASCII art.  RFC 8044 makes it no longer
>>> necessary.
>>> 
>>> Section 3.1, 3.2, and 7.1: the data type should be "string" for
>>> "opaque data"
>>> 
>>>  Other than that, it looks good on first read-through.
>>> 
 The attributes should not be seen as opaque data by the RADIUS
>>> server but it should understand the encoding of the enclosed
>> options.
>>> The intended behavior should be called out, IMO.
>>> 
>>>  I would suggest saying something like "for ease of
>> administrator
>>> configuration, the RADIUS server SHOULD expose the DHCP options
>> and
>>> allow administrators to configure them, instead of requiring
>> them to
>>> be entered as opaque data".
>>> 
>>>  That gets the best of both worlds.
>>> 
>>>  Alan DeKok.
> 
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 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] [Ie-doctors] [IANA #1240167] IANA question regarding draft-ietf-opsawg-ipfix-srv6-srh-01

[Andrew Feren]

Hi All,

First the easy part I didn’t have any problems with the IEs.

Now for the registries.

To Benoit’s 3 use cases.

1. A new IPFIX IE is added in the registry
A collector now knows the name, type, and semantics of a new a new IE.  
This allows the value to be named and stored, but actually doing something 
interesting with a novel IE would require additional intervention.

2. A new value is added for one of the IPFIX sub-registries
3. A new value is added for in the external (non-IPFIX) registry
I know these aren’t quite the same, but for me they are close enough that 
I’m going to lump them together.   This is maybe a little better than a finding 
a new IE, but it still isn’t clear to me what I can really do with this 
information other than give something a nice name.  For example looking at 
“SRv6 Endpoint Behaviors” my hypothetical cron job could learn 158 is now 
defined as “Andrew FUBAR”.  I know it is an endpoint behavior and I can name 
it, but what else can I do with it?

I’d love to see a database or something that I could reliably pull information 
from.  Parsing the registry is already pretty finicky.  Getting a notification 
when registries and subregistries are updated so I can act on them would be 
much more useful to me.  For IPFIX and IPFIX subregistries this list tends to 
work for me, but that probably doesn’t help the broader community of implentors.

Adding an embedded link in the “Additional Information” column may be the best 
we can do today.  I think it should be tagged in a way that differentiates it 
from any other links in that column to facilitate parsing.  I’m skeptical of 
how useful this is in the short term, but I don’t see a reason to oppose it.  
Also if we don’t try new things then nothing changes.

-Andrew

From: ie-doctors  on behalf of Benoit Claise 

Date: Thursday, October 6, 2022 at 11:30 AM
To: iana-iss...@iana.org 
Cc: opsawg@ietf.org , mohamed.boucad...@orange.com 
, ie-doct...@ietf.org , 
Paolo Lucente 
Subject: Re: [Ie-doctors] [IANA #1240167] IANA question regarding 
draft-ietf-opsawg-ipfix-srv6-srh-01
[EXTERNAL] CAUTION: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender and know 
the content is safe.

Hi Amanda, IPFIX IE doctors,

See inline.
On 9/30/2022 4:58 AM, Amanda Baber via RT wrote:

Hi Benoit, all,



Dear IPFIX doctors, (IANA),



We would like to get your feedback regarding the IANA section in

draft-ietf-opsawg-ipfix-srv6-srh-01.

Especially, the two following information elements:

srhFlagsIPv6:

https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-

srh-01#section-5.1

srhSegmentEndpointBehavior:

https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-

srh-01#section-5.11



We can keep separate registries in sync (although we don't currently have 
automation to ensure this), but is the intention for the IPFIX IPv6 SRH Flags 
and IPFIX SRV6 Endpoint Behavior registries to be contained within each IPFIX 
IE registration's Description field?



In 2020, with IE Doctor approval, all IPFIX IE Description field tables that 
constituted sub-registries were replaced with links to separate sub-registries 
located outside of the IPFIX Information Elements registry. You can see the 
list of sub-registries under the heading "Registries included below":



https://www.iana.org/assignments/ipfix





I went to the IANA table in Philly and we discussed those. Hence I

copied IANA here.

In the currentdraft-ietf-opsawg-ipfix-srv6-srh-01



srh-01>

version, we created two IPFIX subregistries, which mimic existing

Segment Routing registries.

The main reason is that we are in favor of having a self contained

IPFIX

IANA registry, which we can download as a cron job in the collector.

We

discussed such a project with Michelle Cotton in the past (I know that

Michelle moved on).



I'm afraid we don't have any of Michelle's notes on this topic. What will you 
need IANA to do? We may need to put you in touch with IANA's technical 
director. In the future, the registries will be moved from an XML-based to a 
database-based registry system.
Regarding the argument of "having a self having a self contained IPFIX IANA 
registry, which we can download as a cron job in the collector", what we need 
is the ability to retrieve either the entire registry in one go, or have 
pointers to other (registries) the IPFIX collector has to take into account ... 
in an automatic manner
The former, with subregistries duplication (and synchronization) might be 
beyond repair at this point in time (at least, I don't have the courage to 
engage), on top of pushing much administration to IANA for the 
synchronization/maintenance

Looking closer at the IF

[OPSAWG] opsawg - Requested session has been scheduled for IETF 115

["IETF Secretariat"]

Dear Tianran Zhou,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


opsawg Session 1 (2:00 requested)
Wednesday, 9 November 2022, Session I 0930-1130
Room Name: Mezzanine 10-11 size: 80
-

Special Note: Combined OpsAWG/OpsAREA

iCalendar: https://datatracker.ietf.org/meeting/115/sessions/opsawg.ics

Request Information:


-
Working Group Name: Operations and Management Area Working Group
Area Name: Operations and Management Area
Session Requester: Tianran Zhou


Number of Sessions: 1
Length of Session(s): 
Number of Attendees: 70
Conflicts to Avoid: 

   


People who must be present:
  Henk Birkholz
  Joe Clarke
  Robert Wilton
  Tianran Zhou
  Warren "Ace" Kumari

Resources Requested:

Special Requests:
  PLEASE NOTE: Combined OpsAWG / OpsAREA
-


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

Re: [OPSAWG] [Ie-doctors] [IANA #1240167] IANA question regarding draft-ietf-opsawg-ipfix-srv6-srh-01

[Benoit Claise]

Hi Andrew,

Thank you for your IPFIX doctor review.

On 10/15/2022 6:05 AM, Andrew Feren wrote:


Hi All,

First the easy part I didn’t have any problems with the IEs.


We will be posting the draft version shortly.


Now for the registries.

To Benoit’s 3 use cases.

1. A new IPFIX IE is added in the registry

    A collector now knows the name, type, and semantics of a new a new 
IE.  This allows the value to be named and stored, but actually doing 
something interesting with a novel IE would require additional 
intervention.


2. A new value is added for one of the IPFIX sub-registries

3. A new value is added for in the external (non-IPFIX) registry

    I know these aren’t quite the same, but for me they are close 
enough that I’m going to lump them together.   This is maybe a little 
better than a finding a new IE, but it still isn’t clear to me what I 
can really do with this information other than give something a nice 
name.  For example looking at “SRv6 Endpoint Behaviors” my 
hypothetical cron job could learn 158 is now defined as “Andrew 
FUBAR”.  I know it is an endpoint behavior and I can name it, but what 
else can I do with it?


I’d love to see a database or something that I could reliably pull 
information from.  Parsing the registry is already pretty finicky.  
Getting a notification when registries and subregistries are updated 
so I can act on them would be much more useful to me.


I would agree with this notification. That might be even more practical 
than trying to get a cron job retrieval of the IANA registries...  which 
would still need to be parsed.

That's something IANA should be thinking about, as a future project.


For IPFIX and IPFIX subregistries this list tends to work for me, but 
that probably doesn’t help the broader community of implentors.


Adding an embedded link in the “Additional Information” column may be 
the best we can do today.  I think it should be tagged in a way that 
differentiates it from any other links in that column to facilitate 
parsing.  I’m skeptical of how useful this is in the short term, but I 
don’t see a reason to oppose it.  Also if we don’t try new things then 
nothing changes.



Thanks and regards, Benoit


-Andrew

*From: *ie-doctors  on behalf of Benoit 
Claise 

*Date: *Thursday, October 6, 2022 at 11:30 AM
*To: *iana-iss...@iana.org 
*Cc: *opsawg@ietf.org , mohamed.boucad...@orange.com 
, ie-doct...@ietf.org 
, Paolo Lucente 
*Subject: *Re: [Ie-doctors] [IANA #1240167] IANA question regarding 
draft-ietf-opsawg-ipfix-srv6-srh-01


[EXTERNAL] CAUTION: This email originated from outside of the 
organization. Do not click links or open attachments unless you 
recognize the sender and know the content is safe.


Hi Amanda, IPFIX IE doctors,

See inline.

On 9/30/2022 4:58 AM, Amanda Baber via RT wrote:

Hi Benoit, all,

Dear IPFIX doctors, (IANA),

We would like to get your feedback regarding the IANA section in

draft-ietf-opsawg-ipfix-srv6-srh-01.

Especially, the two following information elements:

srhFlagsIPv6:

https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-

srh-01#section-5.1

srhSegmentEndpointBehavior:

https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-

srh-01#section-5.11

We can keep separate registries in sync (although we don't currently have 
automation to ensure this), but is the intention for the IPFIX IPv6 SRH Flags 
and IPFIX SRV6 Endpoint Behavior registries to be contained within each IPFIX 
IE registration's Description field?

In 2020, with IE Doctor approval, all IPFIX IE Description field tables that 
constituted sub-registries were replaced with links to separate sub-registries located 
outside of the IPFIX Information Elements registry. You can see the list of 
sub-registries under the heading "Registries included below":

https://www.iana.org/assignments/ipfix

  


I went to the IANA table in Philly and we discussed those. Hence I

copied IANA here.

In the currentdraft-ietf-opsawg-ipfix-srv6-srh-01



srh-01>



version, we created two IPFIX subregistries, which mimic existing

Segment Routing registries.

The main reason is that we are in favor of having a self contained

IPFIX

IANA registry, which we can download as a cron job in the collector.

We

discussed such a project with Michelle Cotton in the past (I know that

Michelle moved on).

I'm afraid we don't have any of Michelle's notes on this topic. What will 
you need IANA to do? We may need to put you in touch with IANA's technical 
director. In the future, the registries will be