[OPSAWG]Re: Sheperd write-up for for YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (draft-ietf-opsawg-teas-attachment-circuit)

[Joe Clarke (jclarke)]

Thanks, Med.  Luis, can you re-review and adjust your shepherd write-up 
accordingly?

Joe

From: mohamed.boucad...@orange.com 
Date: Wednesday, May 29, 2024 at 09:21
To: Joe Clarke (jclarke) , LUIS MIGUEL CONTRERAS MURILLO 
, opsawg@ietf.org 
Cc: draft-ietf-opsawg-teas-attachment-circ...@ietf.org 

Subject: RE: Sheperd write-up for for YANG Data Models for Bearers and 
'Attachment Circuits'-as-a-Service (ACaaS) 
(draft-ietf-opsawg-teas-attachment-circuit)
Hi Joe, Luis, all,

I agree with Joe’s assessment for these refs. Submitted right now a new version 
to address the review from Luis.

As a bonus, also added another example to show how the model is powerful in 
covering another deployment case.

Cheers,
Med

De : Joe Clarke (jclarke) 
Envoyé : mercredi 29 mai 2024 12:49
À : BOUCADAIR Mohamed INNOV/NET ; LUIS MIGUEL 
CONTRERAS MURILLO ; opsawg@ietf.org
Cc : draft-ietf-opsawg-teas-attachment-circ...@ietf.org
Objet : Re: Sheperd write-up for for YANG Data Models for Bearers and 
'Attachment Circuits'-as-a-Service (ACaaS) 
(draft-ietf-opsawg-teas-attachment-circuit)

Thank you, Luis for the review and for agreeing to act as shepherd.  I read 
through your write-up and this diff.  I see you called out the IEEE802.1AX and 
IEEE802.1AB references, but I do not see that addressed in this diff or 
discussed here.

I don’t like sending up drafts that have identified or potentially identified 
issues if it can be avoided.  In my reading of this draft, I feel these IEEE 
standards are informative in that I don’t need to understand them to be able to 
implement this YANG module.  It sounds like you feel differently, Luis?

Joe

From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
mailto:mohamed.boucad...@orange.com>>
Date: Tuesday, May 28, 2024 at 04:48
To: LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>,
 opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Cc: 
draft-ietf-opsawg-teas-attachment-circ...@ietf.org<mailto:draft-ietf-opsawg-teas-attachment-circ...@ietf.org>
 
mailto:draft-ietf-opsawg-teas-attachment-circ...@ietf.org>>
Subject: [OPSAWG]Re: Sheperd write-up for for YANG Data Models for Bearers and 
'Attachment Circuits'-as-a-Service (ACaaS) 
(draft-ietf-opsawg-teas-attachment-circuit)
Hi Luis,

Thank you for the review.

Please see a diff to track the changes at: Diff: 
draft-ietf-opsawg-teas-attachment-circuit.txt - 
draft-ietf-opsawg-teas-attachment-circuit.txt<https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-attachment-circuit.txt_2=https://boucadair.github.io/attachment-circuit-model/boucadair-patch-5/draft-ietf-opsawg-teas-attachment-circuit.txt>.

Please let us know if any further change is needed.

See inline for more context.

Cheers,
Med

De : LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
Envoyé : lundi 27 mai 2024 16:55
À : opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc : 
draft-ietf-opsawg-teas-attachment-circ...@ietf.org<mailto:draft-ietf-opsawg-teas-attachment-circ...@ietf.org>
Objet : Sheperd write-up for for YANG Data Models for Bearers and 'Attachment 
Circuits'-as-a-Service (ACaaS) (draft-ietf-opsawg-teas-attachment-circuit)


Dear authors,

With some delay (apologies for that), I have provided the shepherd’s review of 
draft-ietf-opsawg-teas-attachment-circuit.

The review is available here: 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/shepherdwriteup/
[Med] Thanks. I guess the writeup can indicate that this spec was presented to 
TEAS and that it was WGLCed there as well. Thanks.


Apart from the review provided I have some comments / suggestions / 
clarification questions:


The title quotes ‘Attachment Circuits’, while in the text is not quoted at all. 
Probably better to follow the same approach always.
[Med] It is quoted to make as-a-service refers to the AC, not circuit. Changed 
one occurrence in the main text for consistency.


Scope section refers to ancillary nodes, but the document does not include any 
definition of what an ancillary node refers to
[Med] Ancillary is used in reference to a connectivity service. An example is 
https://datatracker.ietf.org/doc/html/rfc9543#name-ancillary-ces.


Section 1.1: s/… while the underlying link is referred to as “bearers” /… while 
the underlying link is referred to as “bearer”
[Med] ACK.


Regarding the terminology to Network Slice service, not clear if should be 
prefixed as IETF Network Slice service (or not). Necessary to be aligned with 
the criteria that could be defined in TEAS WG.
[Med] ACK, although the AC can be used for other slice types.


The document includes references to the other attachment circuit documents. I 
guess all these references should be updated to the corresponding RFC during 
the publication process. It could be interesting to add 

[OPSAWG]Re: Sheperd write-up for for YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (draft-ietf-opsawg-teas-attachment-circuit)

[Joe Clarke (jclarke)]

Thank you, Luis for the review and for agreeing to act as shepherd.  I read 
through your write-up and this diff.  I see you called out the IEEE802.1AX and 
IEEE802.1AB references, but I do not see that addressed in this diff or 
discussed here.

I don’t like sending up drafts that have identified or potentially identified 
issues if it can be avoided.  In my reading of this draft, I feel these IEEE 
standards are informative in that I don’t need to understand them to be able to 
implement this YANG module.  It sounds like you feel differently, Luis?

Joe

From: mohamed.boucad...@orange.com 
Date: Tuesday, May 28, 2024 at 04:48
To: LUIS MIGUEL CONTRERAS MURILLO , 
opsawg@ietf.org 
Cc: draft-ietf-opsawg-teas-attachment-circ...@ietf.org 

Subject: [OPSAWG]Re: Sheperd write-up for for YANG Data Models for Bearers and 
'Attachment Circuits'-as-a-Service (ACaaS) 
(draft-ietf-opsawg-teas-attachment-circuit)
Hi Luis,

Thank you for the review.

Please see a diff to track the changes at: Diff: 
draft-ietf-opsawg-teas-attachment-circuit.txt - 
draft-ietf-opsawg-teas-attachment-circuit.txt.

Please let us know if any further change is needed.

See inline for more context.

Cheers,
Med

De : LUIS MIGUEL CONTRERAS MURILLO 
Envoyé : lundi 27 mai 2024 16:55
À : opsawg@ietf.org
Cc : draft-ietf-opsawg-teas-attachment-circ...@ietf.org
Objet : Sheperd write-up for for YANG Data Models for Bearers and 'Attachment 
Circuits'-as-a-Service (ACaaS) (draft-ietf-opsawg-teas-attachment-circuit)


Dear authors,

With some delay (apologies for that), I have provided the shepherd’s review of 
draft-ietf-opsawg-teas-attachment-circuit.

The review is available here: 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/shepherdwriteup/
[Med] Thanks. I guess the writeup can indicate that this spec was presented to 
TEAS and that it was WGLCed there as well. Thanks.


Apart from the review provided I have some comments / suggestions / 
clarification questions:


· The title quotes ‘Attachment Circuits’, while in the text is not 
quoted at all. Probably better to follow the same approach always.
[Med] It is quoted to make as-a-service refers to the AC, not circuit. Changed 
one occurrence in the main text for consistency.


· Scope section refers to ancillary nodes, but the document does not 
include any definition of what an ancillary node refers to
[Med] Ancillary is used in reference to a connectivity service. An example is 
https://datatracker.ietf.org/doc/html/rfc9543#name-ancillary-ces.


· Section 1.1: s/… while the underlying link is referred to as 
“bearers” /… while the underlying link is referred to as “bearer”
[Med] ACK.


· Regarding the terminology to Network Slice service, not clear if 
should be prefixed as IETF Network Slice service (or not). Necessary to be 
aligned with the criteria that could be defined in TEAS WG.
[Med] ACK, although the AC can be used for other slice types.


· The document includes references to the other attachment circuit 
documents. I guess all these references should be updated to the corresponding 
RFC during the publication process. It could be interesting to add a note for 
the RFC editors to note this fact.
[Med] I don’t think a note is needed here because the set of I-Ds will progress 
as a cluster. The RFC Editor will take care of that. Thanks.


· Section 2. Definition of Bearer. It is stated that one or multiple 
technologies can be used to build a bearer. It is not clear what are the 
implications of this. Does it imply concatenation? The YANG model describe 
applies to bearer from multiple technologies concatenated? An example of this 
would be beneficial.
[Med] Added the example of LAG.


· Section 4.1, last paragraph about protection. It is mentioned that 
the customer may request protection schemes when endpoints are terminated by 
the same PE, but the customer in principle does not have any view of the 
provider network. Is that right? If so, how the customer knows that endpoints 
are on the same PE?
[Med] The customer indicates that type, without calling it out a specific PE. 
Updated the text to make it clear that the provider will select the PE.


· Section 4.2. s/ This includes the flow put in place for the 
provisioning of network services … / This includes the workflow put in place 
for the provisioning of network services …
[Med] Sure. Done.


· Sentence above Figure 3. s/Figure 3 shows the positioning of the AC 
service model is the overall … /Figure 3 shows the positioning of the AC 
service model in the overall …
[Med] ACK.


· The ietf-bearer-svc model has associated a customer-name. Does it 
mean that the 

[OPSAWG]Re: WG LC: Attachment circuits work

[Joe Clarke (jclarke)]

We would like to thank the WG (and TEAS) for the reviews and comments during WG 
LC.  LC has concluded, and comments have been addressed (today) for issues 
raised.

We are still pending a couple of shepherd write-ups, but once we get them we 
can move these drafts forward to the IESG.

Joe

From: Joe Clarke (jclarke) 
Date: Friday, April 19, 2024 at 10:40
To: opsawg@ietf.org 
Cc: Traffic Engineering Architecture and Signaling Discussion List 

Subject: WG LC: Attachment circuits work
Thanks to efforts by the WG and cross-collaboration with TEAS, these four 
drafts are at the point to run a WG LC.  All currently reported issues have 
been resolved by the authors, and we are grateful to have four volunteers for 
shepherds.

The Attachment Circuits work is divided into four documents:

https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-common-ac/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntw-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ac-lxsm-lxnm-glue/

Given the size of the work, we will run for a three-week LC period (closing on 
May 10), and we are copying teas@ for additional reviews.  Please reply on-list 
with comments.

Joe
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re:  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Joe Clarke (jclarke)]

Doesn’t look like Henk approved the submission yet (and I did not).  So we can 
cancel this submission, and you can repost.

Joe

From: Adrian Farrel 
Date: Friday, May 10, 2024 at 08:47
To: 'Henk Birkholz' , 'Carlos Pignataro' 

Cc: 'OPSAWG' 
Subject: [OPSAWG]Re:  WG Adoption Call for 
draft-pignataro-opsawg-oam-whaaat-question-mark-03
Hmmm, did Carlos jump the gun? Don't you hate enthusiastic people?

If so, do you want us to undo the changes? Options would be:
- Ask the Secretariat to unpost the latest revision
- Post a change-back version of the draft

Alternative is that "we" suck it up.
- You post email to say, all changes made addressed only the adoption poll 
comments
- You accept the adoption and we follow up per Carlos' plan

Let us know.

Cheers,

A


-Original Message-
From: Henk Birkholz 
Sent: 10 May 2024 13:43
To: Carlos Pignataro ; adr...@olddog.co.uk
Cc: OPSAWG 
Subject: Re: [OPSAWG]Re:  WG Adoption Call for 
draft-pignataro-opsawg-oam-whaaat-question-mark-03

Hi Carlos,
hi Adrian,

please do it the other way around ☺️

The chairs ask the authors to first rename
draft-pignataro-opsawg-oam-whaaat-question-mark-03 to
draft-ietf-opsawg-oam-characterization-00, keeping the content as is,
and resubmit. And then post a -01 that addresses all discussion so far,
as these represent WG feedback already.


For the OPSAWG co-chairs,

Henk

On 09.05.24 03:08, Carlos Pignataro wrote:
> Thank you, Henk, for the descriptive and thorough wrap of this adoption
> call.
>
> Like Adrian, I'm also inclined to align with your conclusions, including:
>
>   * "draft-ietf-opsawg-oam-characterization" WFM -- even when it is much
> _less_ expressive than the original, IMO ;-)
>   * As the other one of the editors, ofc more than happy to commit to,
> seek, and follow the WG on the 'pro-active alignment'.
> (understanding we are at a starting point in which the relevant
> lexicon is 'reactively misaligned', or otherwise we would not need
> this draft.)
>
> Net-net: All sounds good with thanks!
>
> I can post a rev++ addressing all discussion thus far, and then an
> unchanged draft-ietf-opsawg-...-00
>
> Thanks!
>
> Carlos.
>
> On Wed, May 8, 2024 at 4:14 AM Adrian Farrel  > wrote:
>
> Thanks Henk,
>
> Apologies for the fatuous original name of this draft (but it worked
> to get everyone's attention ;-)
>
> - Yes, your suggested new name works for me.
>
> - Since you ask, as one of the editors, I commit to a "pro-active
> alignment", making changes as requested by the WG, and paying
> attention to any sources of similar terminology pointed out to us.
>
> Ciao,
> Adrian
>
> -Original Message-
> From: Henk Birkholz 
> Sent: 08 May 2024 08:50
> To: OPSAWG mailto:opsawg@ietf.org>>
> Subject: [OPSAWG]Re:  WG Adoption Call for
> draft-pignataro-opsawg-oam-whaaat-question-mark-03
>
> Dear OPSAWG members,
>
> this email concludes the 1st call for Working Group Adoption for
> draft-pignataro-opsawg-oam-whaaat-question-mark-03.
>
> We received a healthy number of replies, including a good discussion
> about "yet another set of terminology" and its intrinsic
> usefulness/feasibility in the IETF. A good example reflecting the
> overall discussion is the existing terminology established in the
> DetNet
> WG and published in RFC 9551.
>
> The chairs discussed the inputs and comments and believe this work
> to be
> feasible to be adopted as a working group I-D. This believe includes
> the
> expectation that no inconsistencies are introduced by this work and the
> authors, editors, and contributors commit to a pro-active alignment
> (scope and relationship of terms and their use in the respective
> ecosystems) with other existing bodies of work that is brought to
> attention in OPSAWG or otherwise.
>
> Typically, we would now ask to rename and resubmit as is. Alas,
> there is
> the inconsistency between draft name and draft title. Some concern
> about
> that naming was raised during the WGLC. While the draft name was fine
> for the individual submission, the chairs tend to agree that a more
> expressive draft name would benefit the work. Could the authors please
> work with the WG to come up with a better draft name? We can kick this
> off with a proposal from chairs: how about
> draft-ietf-opsawg-oam-characterization? Please bash, so we can move
> forward. The chairs assume that this naming exercise can be resolved
> quickly.
>
>
> For the OPSAWG co-chairs,
>
> Henk
>
> On 10.04.24 13:05, Henk Birkholz wrote:
>  > Dear OPSAWG members,
>  >
>  > this email starts a call for Working Group Adoption of
>  >
>  >>
> 
> https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-question-mark-03.html
>  
> 

Re: [OPSAWG] IPR POLL: Attachment circuits work

[Joe Clarke (jclarke)]

Thank you to all authors and named contributors.  We have received 
acknowledgement that there is no currently known IPR associated with these 
drafts.

As a reminder, IPR disclosure is not just a do-it-when-polled thing.  If you 
learn of IPR at any point in the process, you must disclose as part of the 
guidelines in BCP79 and the relevant RFCs below.

The WG LC on this work is still open until May 10.

Joe

From: OPSAWG  on behalf of Joe Clarke (jclarke) 

Date: Friday, April 19, 2024 at 10:33
To: opsawg@ietf.org 
Subject: [OPSAWG] IPR POLL: Attachment circuits work
We’re up to WG LC on these four drafts.  And while we did an IPR poll before, 
we want to be thorough since this work has evolved.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntw-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-common-ac/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ac-lxsm-lxnm-glue/

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to these drafts”
or
"Yes, I'm aware of IPR that applies to these drafts"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules”
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

As of this time, no IPR has been disclosed on any of the four drafts.

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

[OPSAWG] IETF 120 Meeting

[Joe Clarke (jclarke)]

Hello, WG.  The request to schedule 120 meetings has just gone out to the 
chairs.  We’ll be planning to meet in Vancouver (this time for our usual 2 
hours).

This is not a call for presentations yet.  But we want to plant the seed early 
with people who think they might want to present.  Get your drafts in EARLY.  
Start the conversation on the list EARLY.  We will be prioritizing WG items 
then non-WG items that have had discussion.

Also, please be sure to register early, especially if you plan to attend in 
person.  I hear hotels might be a bit steep, and apparently the IETF has a 
decent price on the room block.

We’re looking forward to seeing/talking to you in Vancouver!

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

Re: [OPSAWG] Confirm submission of I-D draft-ietf-opsawg-tacacs-tls13

[Joe Clarke (jclarke)]

Thanks for the quick responses and push on this draft.  And thank you, Med for 
stepping up to shepherd.  FYI, we have asked for a review from TSVART at Med’s 
request to see what the appetite is for a dedicated port allocation.

Joe

From: OPSAWG  on behalf of Douglas Gash (dcmgash) 

Date: Tuesday, April 23, 2024 at 09:55
To: opsawg@ietf.org , mohamed.boucad...@orange.com 

Cc: John Heasley , Andrej Ota 
Subject: Re: [OPSAWG] Confirm submission of I-D draft-ietf-opsawg-tacacs-tls13
Dear OPSAWG, Mohamed,

This attest revision intends to address the majority of the issues raised in 
the last round of review (Thanks to Med)


There is one known outstanding issue at this time, to update the TLS 
Identification with reference to RFC 9525. We plan to include that, and 
revisions related to this draft version, shortly.

Many thanks.

The Authors.

From: IETF I-D Submission Tool 
Date: Tuesday, 23 April 2024 at 14:46
To: Douglas Gash (dcmgash) , Andrej Ota , 
John Heasley , Thorsten Dahm 
Subject: Confirm submission of I-D draft-ietf-opsawg-tacacs-tls13

Hi,

The IETF datatracker Internet-Draft submission service has received your 
Internet-Draft
draft-ietf-opsawg-tacacs-tls13-07, and requires a
confirmation step in order to be able to complete the posting of
the Internet-Draft.
Please follow this link to the page where you can confirm the posting:

https://datatracker.ietf.org/submit/status/142126/confirm/9c5e13a4722a901ff95632148619611b/


Best regards,

The IETF Secretariat
through the Internet-Draft submission service

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

[OPSAWG] WG LC: Attachment circuits work

[Joe Clarke (jclarke)]

Thanks to efforts by the WG and cross-collaboration with TEAS, these four 
drafts are at the point to run a WG LC.  All currently reported issues have 
been resolved by the authors, and we are grateful to have four volunteers for 
shepherds.

The Attachment Circuits work is divided into four documents:

https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-common-ac/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntw-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ac-lxsm-lxnm-glue/

Given the size of the work, we will run for a three-week LC period (closing on 
May 10), and we are copying teas@ for additional reviews.  Please reply on-list 
with comments.

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

[OPSAWG] IPR POLL: Attachment circuits work

[Joe Clarke (jclarke)]

We’re up to WG LC on these four drafts.  And while we did an IPR poll before, 
we want to be thorough since this work has evolved.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntw-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-common-ac/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ac-lxsm-lxnm-glue/

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to these drafts”
or
"Yes, I'm aware of IPR that applies to these drafts"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules”
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

As of this time, no IPR has been disclosed on any of the four drafts.

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

Re: [OPSAWG] Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents

[Joe Clarke (jclarke)]

Thank you, Thomas and authors/contributors.  We will move this forward to the 
IESG.

Joe

From: OPSAWG  on behalf of thomas.g...@swisscom.com 

Date: Saturday, April 6, 2024 at 03:29
To: jclarke=40cisco@dmarc.ietf.org , 
mohamed.boucad...@orange.com , pait...@ciena.com 
, opsawg@ietf.org 
Cc: ip...@ietf.org 
Subject: Re: [OPSAWG] Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX 
documents
Dear Joe and Med,


I updated both shepherd writeup's accordingly and adjusted to: that consensus 
for introducing a new data type unsigned256 has been achieved.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/shepherdwriteup/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/shepherdwriteup/

I confirm that there is no more blocking points for moving forward to IESG.

Best wishes
Thomas

From: OPSAWG  On Behalf Of Joe Clarke (jclarke)
Sent: Tuesday, April 2, 2024 5:41 PM
To: mohamed.boucad...@orange.com; Aitken, Paul ; 
opsawg@ietf.org
Cc: ip...@ietf.org
Subject: Re: [OPSAWG] Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX 
documents

Be aware: This is an external email.

As a co-chair, I’m willing to call consensus on this as there hasn’t been any 
other replies on this thread after Med asserted the reasoning for sticking with 
unsigned256.

I would ask Thomas as shepherd to note this in the write-up, and we can proceed 
to IESG as I believe all other comments from reviews have now been addressed.

Joe

From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
mailto:mohamed.boucad...@orange.com>>
Date: Tuesday, April 2, 2024 at 11:04
To: Aitken, Paul mailto:pait...@ciena.com>>, Joe Clarke 
(jclarke) mailto:jcla...@cisco.com>>, 
opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Cc: ip...@ietf.org<mailto:ip...@ietf.org> 
mailto:ip...@ietf.org>>
Subject: RE: Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents
Hi all,

As indicated in IETF#119, we suggest to tag this issue as closed and proceed 
with the publication of the current versions of the various I-Ds.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : vendredi 23 février 2024 15:55
À : 'Aitken, Paul' mailto:pait...@ciena.com>>; 'Joe Clarke 
(jclarke)' 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 'opsawg@ietf.org' mailto:opsawg@ietf.org>>
Cc : 'ip...@ietf.org' mailto:ip...@ietf.org>>
Objet : RE: Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents

Hi Paul,

Unless I’m mistaken, I didn’t see any follow-up to this issue.

May I consider this point as closed? Thanks.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mardi 23 janvier 2024 14:23
À : 'Aitken, Paul' mailto:pait...@ciena.com>>; Aitken, Paul 
mailto:paitken=40ciena@dmarc.ietf.org>>;
 Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc : t...@ietf.org<mailto:t...@ietf.org>; 
ts...@ietf.org<mailto:ts...@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>; 
ip...@ietf.org<mailto:ip...@ietf.org>
Objet : Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents

Hi Paul,

> It is consistent but wrong, as the numeric value of these fields is 
> meaningless. Bitfields with flags semantics don't have a meaningful 
> "unsigned" value.

You raised this comment for both TCP/UDP specs.

As I mentioned in the previous message, all existing IEs of type flags are 
using an unsigned type. Also, please note that rfc7012#section-3.2.5 says the 
followings:

   "flags" is an integral value that represents a set of bit fields.
   Logical operations are appropriate on such values, but other
   mathematical operations are not.  Flags MUST always be of an unsigned
   data type.

And rfc7012#section-3:

   Abstract data types unsigned8, unsigned16, unsigned32, unsigned64,
   signed8, signed16, signed32, and signed64 are integral data types.
   As described in Section 3.2, their data type semantics can be further

   specified, for example, by 'totalCounter', 'deltaCounter',
   'identifier', or 'flags'.
 ^^

I quite don’t understand why we need to define Bitfields rather than leveraging 
on the approach followed so far in IPFIX.

Cheers,
Med

De : Aitken, Paul mailto:pait...@ciena.com>>
Envoyé : lundi 22 janvier 2024 11:49
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; Aitken, 
Paul 
mailto:paitken=40ciena@dmarc.ietf.org>>;
 Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc : t...@ietf.org<mailto:t...@ietf.org>; 
ts...@ietf.org<mailto:ts...@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>; 
ip...@ietf.org<mailto:ip...@ietf.org>
Objet : Re: Re: [IPFIX] WG LC: IPFIX documents

Med,

[OPSAWG] IETF 119 Minutes Posted

[Joe Clarke (jclarke)]

Hello, WG.  The initial minutes from our 119 meeting are now posted:

https://datatracker.ietf.org/doc/minutes-119-opsawg-202403180530/

Thank you to Rob, Adrian, and Jean for your contributions to the proceedings!  
Let us know if there are large errors or omissions.

Henk and I are working through the AIs.  We’re closing on consensus on the 
IPFIX drafts to get them to the IESG, and we will be calling for adoption on 
the OAM terminology work soon based on the in-meeting poll.

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

Re: [OPSAWG] Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents

[Joe Clarke (jclarke)]

As a co-chair, I’m willing to call consensus on this as there hasn’t been any 
other replies on this thread after Med asserted the reasoning for sticking with 
unsigned256.

I would ask Thomas as shepherd to note this in the write-up, and we can proceed 
to IESG as I believe all other comments from reviews have now been addressed.

Joe

From: mohamed.boucad...@orange.com 
Date: Tuesday, April 2, 2024 at 11:04
To: Aitken, Paul , Joe Clarke (jclarke) , 
opsawg@ietf.org 
Cc: ip...@ietf.org 
Subject: RE: Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents
Hi all,

As indicated in IETF#119, we suggest to tag this issue as closed and proceed 
with the publication of the current versions of the various I-Ds.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : vendredi 23 février 2024 15:55
À : 'Aitken, Paul' ; 'Joe Clarke (jclarke)' 
; 'opsawg@ietf.org' 
Cc : 'ip...@ietf.org' 
Objet : RE: Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents

Hi Paul,

Unless I’m mistaken, I didn’t see any follow-up to this issue.

May I consider this point as closed? Thanks.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mardi 23 janvier 2024 14:23
À : 'Aitken, Paul' mailto:pait...@ciena.com>>; Aitken, Paul 
mailto:paitken=40ciena@dmarc.ietf.org>>;
 Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc : t...@ietf.org<mailto:t...@ietf.org>; 
ts...@ietf.org<mailto:ts...@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>; 
ip...@ietf.org<mailto:ip...@ietf.org>
Objet : Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents

Hi Paul,

> It is consistent but wrong, as the numeric value of these fields is 
> meaningless. Bitfields with flags semantics don't have a meaningful 
> "unsigned" value.

You raised this comment for both TCP/UDP specs.

As I mentioned in the previous message, all existing IEs of type flags are 
using an unsigned type. Also, please note that rfc7012#section-3.2.5 says the 
followings:

   "flags" is an integral value that represents a set of bit fields.
   Logical operations are appropriate on such values, but other
   mathematical operations are not.  Flags MUST always be of an unsigned
   data type.

And rfc7012#section-3:

   Abstract data types unsigned8, unsigned16, unsigned32, unsigned64,
   signed8, signed16, signed32, and signed64 are integral data types.
   As described in Section 3.2, their data type semantics can be further

   specified, for example, by 'totalCounter', 'deltaCounter',
   'identifier', or 'flags'.
 ^^

I quite don’t understand why we need to define Bitfields rather than leveraging 
on the approach followed so far in IPFIX.

Cheers,
Med

De : Aitken, Paul mailto:pait...@ciena.com>>
Envoyé : lundi 22 janvier 2024 11:49
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; Aitken, 
Paul 
mailto:paitken=40ciena@dmarc.ietf.org>>;
 Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc : t...@ietf.org<mailto:t...@ietf.org>; 
ts...@ietf.org<mailto:ts...@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>; 
ip...@ietf.org<mailto:ip...@ietf.org>
Objet : Re: Re: [IPFIX] WG LC: IPFIX documents

Med,
   The IE specified in Section 4.1 uses the new abstract data type
   defined in [I-D.ietf-opsawg-ipfix-tcpo-v6eh].

The unsigned256 type? It makes more sense to introduce a bitfield type.
[Med] I think the use of unsigned256 is consistent with the current use in IP 
Flow Information Export (IPFIX) Entities (iana.org) 
[iana.org]<https://urldefense.com/v3/__https:/www.iana.org/assignments/ipfix/ipfix.xhtml__;!!OSsGDw!PbyTGwK6ng1xsDx7EDsqY-zP5SN-siBTe9ltLeN6whqtHew5I4J3MgqA7QOaYGnkTWnF4w1wMldDkBYIpjb9XwrB$>
 (where unsigned8, unsigned16, unsigned32, and unsigned64 are used for IEs 
having data semantic of flags.

It is consistent but wrong, as the numeric value of these fields is 
meaningless. Bitfields with flags semantics don't have a meaningful "unsigned" 
value.



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 with

Re: [OPSAWG] [netmod] Adoption call for draft-ma-opsawg-schedule-yang-04

[Joe Clarke (jclarke)]

I support adoption of this work.  It forms the foundation of work in other WGs, 
and I’m happy to have this worked by netmod if there is sufficient interest.

As an opsawg co-chair, I’m copying opsawg to get their opinions.  This work has 
been presented there and is a dependency of an ACL draft currently adopted by 
opsawg.

Joe

From: netmod  on behalf of Kent Watsen 

Date: Tuesday, March 26, 2024 at 11:50
To: net...@ietf.org 
Subject: [netmod] Adoption call for draft-ma-opsawg-schedule-yang-04
NETMOD WG,

This email begins a 2-week adoption poll for:

A Common YANG Data Model for Scheduling
https://datatracker.ietf.org/doc/draft-ma-opsawg-schedule-yang

PS: This draft moved from OPSAWG to NETMOD

There is no known IPR on this draft:


https://mailarchive.ietf.org/arch/msg/netmod/mg1KP3m6bCSXh-3N-YKLvEb_udk/

Please voice your support or technical objections to adoption on the list by 
the end of the day Apr 10 (any time zone).

Thank you,
Kent (as co-chair)

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

Re: [OPSAWG] [ippm] draft-spiegel-ippm-ioam-rawexport

[Joe Clarke (jclarke)]

It need not wait.  We would adopt on this list if we adopt in opsawg.  And this 
work has already seen some discussion on-list today alone.  As you say, we have 
many of the interest IPFIX crowd here already.  It also seems like there is 
some IPPM cross-members to give this a proper holistic review.


Speaking as a contributor, I read the draft when Thomas copied it here, and I 
think it would fit with recent work being progressed through opsawg.

Joe

From: OPSAWG  on behalf of Benoit Claise 

Date: Monday, March 18, 2024 at 23:23
To: thomas.g...@swisscom.com , i...@ietf.org 
, opsawg@ietf.org , justin.iur...@uliege.be 

Subject: Re: [OPSAWG] [ippm] draft-spiegel-ippm-ioam-rawexport
Dear all,
On 3/19/2024 10:40 AM, 
thomas.g...@swisscom.com wrote:
Dear Justin, Dear OPSAWG and IPPM working groups

Thanks a lot for the presentation at IPPM. I believe that this work needs 
further refinement by defining also IPFIX entities for IOAM which allow a 
decomposition of each IOAM dimension fields, thus enabling IPFIX Flow 
Aggregation as described in RFC 7015 which is a requirement to scale out for 
IOAM DEX and Trace Option Type. I believe this should be performed after the 
working group adoption and me should move forward quickly since IOAM is now 
getting implemented by vendors and applied by operators.

While shepherding IPFIX at OPSAWG, I noticed that most discussions where around 
choosing the right data type and aligning with the IPFIX registry. Not so much 
about exposing the right dimensions from the data plane.

draft-ietf-opsawg-ipfix-on-path-telemetry is already adopted and well 
progressed at OPSAWG. I suggest that draft-spiegel-ippm-ioam-rawexport is being 
adopted together with draft-gfz-opsawg-ipfix-alt-mark. With that we are 
covering both Hybrid Type options developed at IPPM.

In order to pool the IPFIX entity definitions, I believe OPSAWG would be the 
best place to move with draft-spiegel-ippm-ioam-rawexport forward.
Regardless of the WG (*), I believe those two drafts should be adopted soon.

(*) OPSAWG or IPPM, it doesn't matter too much as we have the right expert 
inputs anyway. I am a little concerned that OPSAWG meeting was yesterday, so if 
we ask for WG adoption, it would be typically at the next physical meeting in 4 
months. IMO, waiting that long is not required

Regards, Benoit


I would appreciate feedback from IPPM and OPSAWG wherever they share my opinion 
or not.

Best wishes
Thomas




___

ippm mailing list

i...@ietf.org

https://www.ietf.org/mailman/listinfo/ippm

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

[OPSAWG] Preparing for our IETF 119 session

[Joe Clarke (jclarke)]

Hello, WG.  I hope everyone is doing well and those that traveled here to 
Brisbane are recovering from jet lag.

Our WG session is tomorrow, Monday March 18 at 15:30 local time, 0530 UTC.  
Please review 
https://www.ietf.org/how/meetings/technology/meetecho-guide-participant/ if you 
will be attending remotely.  And for in-person attendees, you should also join 
the Meetecho queue to ask questions at the mic.

You may have noticed our slot got reduced from 2 hours to 1.5 hours.  As such, 
we had to compress people’s speaking slots, and we will greatly appreciate all 
speakers keeping on their allotted times.  We will have to cut people off if 
presentations are going long.

In this session, we will be saying goodbye to our esteemed AD, Rob and 
welcoming Mahesh as our new, incoming AD.  You may remember Rob from such great 
minute-taking meetings as 118, 117, 116, … (he will be missed for other 
reasons, too).

The chairs would be grateful if someone could respond saying you can help with 
minutes at https://notes.ietf.org/notes-ietf-119-opsawg?both.  This will 
expedite our process to getting to presentations.

Thanks!

Joe (on behalf of the opsawg chairs)
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Proposed Liaison Response to SG11

[Joe Clarke (jclarke)]

I think your response reads well.  Thank you for drafting this and inviting 
ITU-T to the part in mpls should they want to collaborate further.  As an 
opsawg co-chair, I would be willing to co-sign.

Joe

From: Adrian Farrel 
Date: Saturday, March 9, 2024 at 11:45
To: 'OPSAWG' 
Cc: 'mpls-chairs' , opsawg-cha...@ietf.org 
, ops-...@ietf.org , rtg-...@ietf.org 

Subject: Proposed Liaison Response to SG11
Hi OPSAWG,

The MPLS working group is discussing sending a liaison to ITU-T SG11 in
response to their liaison (https://datatracker.ietf.org/liaison/1869/)
originally targeted at OPSAWG.

If you feel:
- OPSAWG should co-sign
- MPLS should butt out
- edits are needed

Please respond to the MPLS chairs copying either mailing list. We do intend
moving fairly quickly on this, but will wait until after MPLS has met (IETF
Tuesday) before sending anything.

Cheers,
Adrian (for the MPLS WG chairs)

-Original Message-
From: mpls  On Behalf Of Adrian Farrel
Sent: 08 March 2024 15:37
To: 'mpls' 
Cc: mpls-...@ietf.org
Subject: [mpls] For Review: Proposed Liaison Response to SG11

Hi WG,

You may have seen some back and forth on the list with respect to a liaison
statement sent "For Information" to the OPSAWG by ITU-T Study Group 11.

Watching the mailing list, your chairs thought it would be a good idea to
send a response even though one is not requested or required, and even
though we were not the original recipients of the incoming liaison.

Our draft is below. We would welcome any thoughts or edits.

The intention is to send this "soon" so it would help if you could respond
in a timely way.

Thanks,
Adrian for the MPLS Chairs

===

To: ITU-T-SG-11
Cc: Denis Andreev ;
Tatiana Kurakova ;
Scott Mansfield ;
m...@ietf.org; mpls-cha...@ietf.org; itu-t-liai...@iab.org
Purpose: For Information
In response to: https://datatracker.ietf.org/liaison/1869/
Subject: Response to your Liaison Statement - LS on the consent of draft
Recommendation ITU-T Q.3962 (ex. Q.joint_tr) "Requirements and Reference
Model for optimized traceroute of joint Internet Protocol/Multi-Protocol
Label Switching"

Body:

Thank you for your Liaison Statement - LS on the consent of draft
Recommendation ITU-T Q.3962 (ex. Q.joint_tr) "Requirements and Reference
Model for optimized traceroute of joint Internet Protocol/Multi-Protocol
Label Switching" dated 2023-10-24. This has been passed on to the MPLS
working group for consideration.

The MPLS working group would like to thank you for sharing your requirements
as expressed in Q.3962.

Our current understanding of your requirements suggests that all or most of
your requirements can be addressed using existing IP/MPLS OAM tools.

We would welcome all experts to bring these requirements to the IETF's MPLS
working group with a view to working collaboratively on an Informational RFC
that describes how to deliver the function you want to see. Obviously,
should any lacunae be discovered during this process, the working group
would also be pleased to engage in additional protocol work to resolve any
issues.

Kind regards,
Adrian Farrel MPLS Working Group Co-Chair
On behalf of the MPLS Working Group and Co-Chairs


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

Re: [OPSAWG] Call for presentations at IETF119

[Joe Clarke (jclarke)]

Implementations are fantastic, and I personally appreciate it when operators 
bring problems (and solutions).

The challenge is we only have a finite amount of time for presentations; and, 
as you say, this work may be difficult to generate discussion.  I conferred 
with the other co-chairs, and it seems we’re already at our time allocation.  
We will add this as a “best-effort-if-time-allows” agenda item at the very end 
(meaning you may not, and in all likelihood won’t, have time to speak).  That 
said, the mailing list is where we need to see the discussion to promote 
adoption and overall WG engagement.  I would hope talk of implementations might 
help generate such discussion.

Joe

From: Voyer, Daniel 
Date: Tuesday, February 27, 2024 at 09:23
To: Voyer, Daniel , Joe Clarke (jclarke) 
, Sriram Gopalakrishnan (sriragop) , 
Tianran Zhou , OPSAWG 
Cc: opsawg-chairs , Ralu Johny (rjohny) 
, vyas...@juniper.net 
Subject: RE: [OPSAWG] Call for presentations at IETF119
Joe,

And forgot to mention; we are currently updating the draft with a new 
"implementation status" section, as there is an existing running code (with 
enterprise-specific IPFIX Information Elements 
(https://datatracker.ietf.org/doc/html/rfc7011.html#section-3.2)

Regards,
Dan


From: OPSAWG  on behalf of "Voyer, Daniel" 

Date: Tuesday, February 27, 2024 at 8:42 AM
To: "Joe Clarke (jclarke)" , "Sriram Gopalakrishnan 
(sriragop)" , Tianran Zhou 
, OPSAWG 
Cc: opsawg-chairs , "Ralu Johny (rjohny)" 
, "vyas...@juniper.net" 
Subject: [EXT]Re: [OPSAWG] Call for presentations at IETF119

Hi Joe,

I understand your perspective regarding the presentation slot and the need for 
prior mailing list discussions. However, given that this draft straddle the 
intersection of two standards development organizations (SDOs)—where GTP-U 
adheres to the 3GPP protocol and IPFIX falls under the IETF—it may be 
challenging to generate substantial interest on the mailing list, despite our 
intentions.

We welcome feedback on the draft content from both the GTP-U and IPFIX 
viewpoints.

And most importantly , please note that during the IETF week, we will be 
requesting IPFIX IANA allocation. This is required to get us going with 
“standardized implementation”. Therefore, the purpose of the presentation slot 
request is to facilitate discussion around the draft.

Best Regards,
Dan (involved in both 3GPP and IETF)

From: "Joe Clarke (jclarke)" 
Date: Friday, February 23, 2024 at 12:20 PM
To: "Sriram Gopalakrishnan (sriragop)" , Tianran Zhou 
, OPSAWG 
Cc: opsawg-chairs , Benoit Claise 
, Dan Voyer , "Ralu Johny 
(rjohny)" , Thomas Graf , 
"vyas...@juniper.net" 
Subject: [EXT]Re: Call for presentations at IETF119

Hey, Sriram.  We only have the one slot for 119, and one of the things the 
chairs discussed to keep the agenda manageable was focusing on work that had 
mailing list discussion already.  I did a quick search through the IETF mail 
archives, and this draft has never once been raised on opsawg@ or any other 
mailing list that I can see.

Before we consider a presentation slot, we’d like to see this socialized and 
discussed on-list.

Joe

From: Sriram Gopalakrishnan (sriragop) 
Date: Friday, February 23, 2024 at 11:37
To: Tianran Zhou , OPSAWG 

Cc: opsawg-chairs , Benoit Claise 
, Dan Voyer , Ralu Johny 
(rjohny) , Thomas Graf , 
vyas...@juniper.net 
Subject: Re: Call for presentations at IETF119
Hi Tianran

We would like to request for a 15 minutes slot for our presentation of below 
draft.

Name: draft-voyersriram-opsawg-ipfix-gtpu
Revision: 03
Title:Export of GTP-U Information in IP Flow Information Export (IPFIX)
URL:  
https://www.ietf.org/archive/id/draft-voyersriram-opsawg-ipfix-gtpu-03.txt

Thanks
--Sriram

From: OPSAWG  on behalf of Tianran Zhou 

Date: Sunday, 18 February 2024 at 12:12 PM
To: OPSAWG 
Cc: opsawg-chairs 
Subject: [OPSAWG] Call for presentations at IETF119
Hi OPSAWG,

The IETF119 preliminary agenda is posted.

https://datatracker.ietf.org/meeting/119/agenda/

The joint OPSAWG and OPS Area meeting is scheduled at 15:30 - 17:00 Monday 
Session III.
We are now available to accept presentations. Please send your request to the 
chairs.
Look forward to seeing you in Brisbane.

Best,
Tianran


External Email: Please use caution when opening links and attachments / 
Courriel externe: Soyez prudent avec les liens et documents joints
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Call for presentations at IETF119

[Joe Clarke (jclarke)]

Hey, Sriram.  We only have the one slot for 119, and one of the things the 
chairs discussed to keep the agenda manageable was focusing on work that had 
mailing list discussion already.  I did a quick search through the IETF mail 
archives, and this draft has never once been raised on opsawg@ or any other 
mailing list that I can see.

Before we consider a presentation slot, we’d like to see this socialized and 
discussed on-list.

Joe

From: Sriram Gopalakrishnan (sriragop) 
Date: Friday, February 23, 2024 at 11:37
To: Tianran Zhou , OPSAWG 

Cc: opsawg-chairs , Benoit Claise 
, Dan Voyer , Ralu Johny 
(rjohny) , Thomas Graf , 
vyas...@juniper.net 
Subject: Re: Call for presentations at IETF119
Hi Tianran

We would like to request for a 15 minutes slot for our presentation of below 
draft.

Name: draft-voyersriram-opsawg-ipfix-gtpu
Revision: 03
Title:Export of GTP-U Information in IP Flow Information Export (IPFIX)
URL:  
https://www.ietf.org/archive/id/draft-voyersriram-opsawg-ipfix-gtpu-03.txt

Thanks
--Sriram

From: OPSAWG  on behalf of Tianran Zhou 

Date: Sunday, 18 February 2024 at 12:12 PM
To: OPSAWG 
Cc: opsawg-chairs 
Subject: [OPSAWG] Call for presentations at IETF119
Hi OPSAWG,

The IETF119 preliminary agenda is posted.

https://datatracker.ietf.org/meeting/119/agenda/

The joint OPSAWG and OPS Area meeting is scheduled at 15:30 - 17:00 Monday 
Session III.
We are now available to accept presentations. Please send your request to the 
chairs.
Look forward to seeing you in Brisbane.

Best,
Tianran

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

Re: [OPSAWG] Submission of new version of TACACS+ TLS Spec (V4)

[Joe Clarke (jclarke)]

Hello, Douglas (and other authors).  Seeing as since we’re gearing up for IETF 
119, I wanted to check to see when you might have a response and another 
version of the document planned in order to update the WG on progress.  
Ultimately, this is the reason we did the original T+ informational draft, and 
I know there are interested parties in seeing this work progress.

Thanks.

Joe

From: OPSAWG  on behalf of Douglas Gash (dcmgash) 

Date: Thursday, January 25, 2024 at 10:22
To: mohamed.boucad...@orange.com , 
opsawg@ietf.org 
Cc: John Heasly , Andrej Ota 
Subject: Re: [OPSAWG] Submission of new version of TACACS+ TLS Spec (V4)
Hi,

Thanks for your further review.

We will check through your comments against the latest version and identify the 
missing items, then continue this thread on what their acceptable resolution 
could be.

Thanks,

The Authors.

From: mohamed.boucad...@orange.com 
Date: Thursday, 25 January 2024 at 14:34
To: Douglas Gash (dcmgash) , opsawg@ietf.org 

Cc: John Heasly , Andrej Ota 
Subject: RE: Submission of new version of TACACS+ TLS Spec (V4)
Hi Authors, all,

Many thanks for your effort on this document.

I managed finally to read the new version. I’m afraid that some of the comments 
in 
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-tacacs-tls13-03-rev%20Med.pdf
 were not addressed or at least I fail to see how they are.

For example, I still don’t think that we can separate the discussion of the 
port number from how the IP address of the server is configured. I still also 
think that cipher suite discuss can be offloaded to RFC9325 (which btw should 
be cited as normative; also, please note that RFC7525 is now obsoleted by 
RFC9325).

Cheers,
Med

De : OPSAWG  De la part de Douglas Gash (dcmgash)
Envoyé : vendredi 22 décembre 2023 17:54
À : opsawg@ietf.org
Cc : John Heasly ; Andrej Ota 
Objet : [OPSAWG] Submission of new version of TACACS+ TLS Spec (V4)

Dear OPSAWG,

Many thank for all the comments on the Secure TACACS+ (TLS) draft v3.

We have submitted a revised doc which intention to address the concerns and 
comments. It is rather later than originally planned, our apologies for the 
delay. We will look forward to addressing the corresponding issues form this 
revision in a timelier manner.

Some brief notes regarding the broader topics raised in v3, all items of 
course, are open for re-aligning as the group sees fit.

Regarding the allocation of a specific port, a key motivation concerns the 
pervasive use of default ports in current configurations. Ensuring the client 
implementations work correctly with default ports now TLS is introduced, to 
minimise burden for operators whilst avoiding wrinkles with downgrade attacks 
does require said new default port to be allocated, and we will explicitly 
mention this in a new section in the new doc. We hope this should help account 
for our request for an allocated port.
RFC9325 does look a timely reference, and we have tried to delegate what we can 
from the new TACACS+ doc to it.
Tracking the discussion on the deprecation of obfuscation option inside TLS, 
our current reading is that:
All TLS traffic must NOT use obfuscation.
Setting the non-obfuscation option (TACACS has a flag for unencrypted)  is 
mandatory for all TLS TACACS+ traffic.
The aim is to avoid any ambiguity and to remove MD5 operations from this level 
of the protocol.
We hope we have addressed the raised issues nits and ambiguities.

Best regards, the Authors.




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-feng-opsawg-incident-management-04

[Joe Clarke (jclarke)]

=== Again, as contributor ===

Thanks, Nigel. Italo, and Qin for further comments.

Nigel, you hit on my overall heartburn with this document.  I ultimately feel 
that without strong collaboration with other bodies (de facto or otherwise) the 
IETF will end up with yet another set of terminology and approach to 
incident/problem management.  If this document is adopted – regardless of WG – 
that collaboration and cooperation needs to be clearly spelled out IMHO.

Qin and Italo, comments below.


I struggle to see why the IETF should be working on this.  Clearly there are 
other SDOs that work in the area of incident management.  This draft refers to 
a [IMHO tenuous] reference to a TM Forum API spec (which I cannot read as I am 
not a member), but ITIL has similar definitions of incidents and problems.  
There does not seem to be any liaison or indication of a close relationship 
with these other SDOs to help drive consistent use of terminology and help 
their members achieve desired goals.

[Qin Wu]
Thanks Joe for valuable input and comments, see my clarification in the 
presentation in IETF 116 
(https://datatracker.ietf.org/meeting/116/materials/slides-116-opsawg-incident-management-for-network-service-00.pdf
 
[datatracker.ietf.org]),
 which I clarify the relationship
with TMF API spec, as you can see what draft-feng proposes to do is to define 
YANG model for incident lifecycle management, complementary to TMF API profile 
which focus on requirements, function, component capability. Talking with TMF 
API profile authors in TMF, they are happy to have this work land on IETF since 
IETF has more YANG model work expertise.

Secondly, the definition of network incidents and problems in TMF API spec is 
sourced from ITIL. ITIL is an internationally recognized and widespread 
de-facto standard for IT services management, not **developed by any other 
SDOs**, the idea of the definition of network incident and problem in TMF API 
spec is to introduce incident concept originally applied to IT field to 
**operator's network field**, which require support not only from domain 
controllers but also OSS. The typical scenario not only applied to optical 
scenario but also applied to IP network scenario.
Therefore in my opinion, alignment with TMF specification by quoting TMF 
network incident definition is sufficient, note that TMF specification has 
already been published by TMF. if you think necessary, I can consult with TMF 
specification authors for clarification.

[Italo Busi] IMHO, after this document is adopted as WG item, we can send a LS 
to TMF to get their feedbacks to make it sure the work is fully complementary 
to their work

[JMC] I’d go as far as to spell out that tight cooperation is needed to make 
sure we don’t end up with our own flavor of incident management.

Even in this first pass, I see what I feel is a mix of terminology.  You have 
an enumeration on leaf type where “fault” reads as the type of incident being a 
fault.  To me, this is the type of problem (i.e., the cause of the incident).  
The incident type might be an SLA violation.

[Qin Wu] I believe this is naming confusion issue, according to network 
incident definition, the incident type can be unexpected interruption of the 
network service, or degradation of the network service, in the current design, 
we use fault and potential risk, if this is not clear, we can use better term 
as you suggested. Thanks.
Also as you can see, Nigel and Adrian have started a new draft on incident 
management terminology based on action point taken in IETF 118 side meeting on 
incident management, which can also help produce better terminology for this 
work.

[Italo Busi] This looks like an issue which can be addressed through normal WG 
process after adoption.

[JMC] Yes and no.  If there is de facto or standardized language to which this 
document refers, then that should be incorporated.  To Nigel’s point, maybe 
there is some additional language that can be local, but this should track with 
what those other bodies are doing.  This would include liaison reviews to 
ensure consistency.

I do not feel this work should be adopted by the IETF in its current form.

[Qin Wu] I am thinking change the title into "A YANG Data Model for Network 
Incident management", which will focus on network level model, in the same 
level as L3NM, L2NM and Attachment Circuit.
[Italo Busi] Sounds reasonable to me

[JMC] Agreed this title would be clearer.

Joe

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

Re: [OPSAWG]  WG Adoption Call for draft-feng-opsawg-incident-management-04

[Joe Clarke (jclarke)]

=== As a contributor ===

I struggle to see why the IETF should be working on this.  Clearly there are 
other SDOs that work in the area of incident management.  This draft refers to 
a [IMHO tenuous] reference to a TM Forum API spec (which I cannot read as I am 
not a member), but ITIL has similar definitions of incidents and problems.  
There does not seem to be any liaison or indication of a close relationship 
with these other SDOs to help drive consistent use of terminology and help 
their members achieve desired goals.

Even in this first pass, I see what I feel is a mix of terminology.  You have 
an enumeration on leaf type where “fault” reads as the type of incident being a 
fault.  To me, this is the type of problem (i.e., the cause of the incident).  
The incident type might be an SLA violation.

I do not feel this work should be adopted by the IETF in its current form.

Joe

From: OPSAWG  on behalf of Henk Birkholz 

Date: Thursday, February 8, 2024 at 10:44
To: OPSAWG 
Subject: [OPSAWG]  WG Adoption Call for 
draft-feng-opsawg-incident-management-04
Dear OPSAWG members,

this email starts a call for Working Group Adoption of

> https://www.ietf.org/archive/id/draft-feng-opsawg-incident-management-04.html

ending on Thursday, February 22nd.

As a reminder, this I-D specifies a YANG Module for Incident Management.
Incidents in this context are scoped to unexpected yet quantifiable
adverse effects detected in a network service. The majority of the
document provides background and motivation for the structure of the
YANG Module that is in support of reporting, diagnosing, and mitigating
the detected adverse effects.

The chairs acknowledge some positive feedback on the list and a positive
poll result at IETF118. We would like to gather feedback from the WG if
there is interest to further contribute and review.

Please reply with your support and especially any substantive comments
you may have.


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

Re: [OPSAWG] WG LC: IPFIX documents

[Joe Clarke (jclarke)]

The last call period has ended for these documents, and we did receive a few 
reviews from various directorates.  Despite no major issues, the comments do 
request revisions to the three drafts.  We ask the authors to address the 
comments prior to pushing on to the IESG.

We are also grateful that Thomas Graf as stepped forward to act as shepherd for 
these three documents.  Thomas, let the chairs know if you need any help on the 
shepherd write-ups.

Thanks.

Joe

From: Joe Clarke (jclarke) 
Date: Monday, December 18, 2023 at 14:22
To: opsawg@ietf.org 
Cc: t...@ietf.org , ts...@ietf.org , 
6...@ietf.org <6...@ietf.org>, ip...@ietf.org 
Subject: WG LC: IPFIX documents
We’d like to kick off a [rather extended] WG LC on the three IPFIX-related 
“fixes” documents we have in the hopper.  We’ve already requested some 
directorate reviews for these, and the authors feel they have stabilized well.

Please review:


· https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/

· https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/

· https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/

And comment as to whether or not you feel they are in the right shape to 
progress to the IESG.  We will run this LC until Jan 8 given that the holidays 
means some people will not be around.  Also note that an IPR poll was conducted 
prior to adoption and no known IPR has been disclosed.

Thanks.

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

[OPSAWG] WG LC: IPFIX documents

[Joe Clarke (jclarke)]

We’d like to kick off a [rather extended] WG LC on the three IPFIX-related 
“fixes” documents we have in the hopper.  We’ve already requested some 
directorate reviews for these, and the authors feel they have stabilized well.

Please review:


  *   https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/
  *   https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/
  *   https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/

And comment as to whether or not you feel they are in the right shape to 
progress to the IESG.  We will run this LC until Jan 8 given that the holidays 
means some people will not be around.  Also note that an IPR poll was conducted 
prior to adoption and no known IPR has been disclosed.

Thanks.

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

Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update

[Joe Clarke (jclarke)]

Rob, can you comment on this with respect to 9092 and the intent for this bis?

Thanks.

Joe

On 11/30/23, 09:24, "Michael Richardson"  wrote:

mohamed.boucad...@orange.com wrote:
> I guess Rob has to call this out in the last call; please see RFC8067:

>   For Standards Track or BCP documents requiring normative
> reference to documents of lower maturity, the normal IETF Last Call
> procedure will be issued, with the need for the downward reference
> explicitly documented in the Last Call itself.  Any community comments
> on the appropriateness of downward references will be considered by the
> IESG as part of its deliberations.

Yes, but it seems that this didn't happen when RFC9092 went through Last Call, 
and some of
those references are occuring again.

--
Michael Richardson mailto:mcr+i...@sandelman.ca>>, 
Sandelman Software Works
-= IPv6 IoT consulting =-  *I*LIKE*TRAINS*




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

Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update

[Joe Clarke (jclarke)]

The WG LC has concluded.  Two of the directorate reviews came in, and there 
were some other reviews from the WG (thank you!), which yielded a -07.  Michael 
has completed the shepherd write-up.  With that, I will move this doc to the 
IESG.

Thanks to the authors, contributors, WG, and our shepherd, mcr.

Joe

From: OPSAWG  on behalf of Joe Clarke (jclarke) 

Date: Tuesday, November 14, 2023 at 13:56
To: opsawg@ietf.org 
Subject: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update
This kicks off a two week WG LC on the update to “Finding and Using Geofeed 
Data”.  This draft has received some initial comments and a rather extensive 
certificate review from Job.  We’d appreciate some more eyes to look iover the 
changes to the original RFC9092 and focus comments there.  Thanks again to mcr 
for agreeing to shepherd this document.

In addition to substantive comments, we’d appreciate reviewers that think it is 
ready to go to say so on-list.  The WG LC will end on November 28, 2023.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-9092-update/

Thanks.

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

Re: [OPSAWG] Opsdir last call review of draft-ietf-opsawg-9092-update-06

[Joe Clarke (jclarke)]

Thank you for your review, Bo.  OPSAWG appreciates it.

Joe

From: Bo Wu via Datatracker 
Date: Wednesday, November 22, 2023 at 04:00
To: ops-...@ietf.org 
Cc: draft-ietf-opsawg-9092-update@ietf.org 
, last-c...@ietf.org 
, opsawg@ietf.org 
Subject: Opsdir last call review of draft-ietf-opsawg-9092-update-06
Reviewer: Bo Wu
Review result: Has Nits

Hi all,

I have reviewed this document as Ops area reviewer.

This document updates RFC 9092, adding new sections of Fetching Geofeed data
and the implementation of Geofeed, and supplements and optimizes the original
sections based on practices. The document is well written and almost ready with
small nits as below.

1. Abbreviations
Severl abbreviations in the newly added text is better to be expanded on the
first use, including Certification Authority (CA), EE (end-entity), Certificate
Revocation List (CRL) and Autonomous System (AS).

2. Content seems repetitive
Section 3:
Any particular inetnum: object SHOULD have, at most, one geofeed
   reference, whether a remarks: or a proper geofeed: attribute when it
   is implemented.  If there is more than one, the geofeed: attribute
   SHOULD be used.

Section 4:
If an inetnum: object has both remarks: with geofeed data and also has a
geofeed: attribute, the geofeed: attribute SHOULD be used and the remarks:
ignored


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

[OPSAWG] IETF 118 opsawg minute

[Joe Clarke (jclarke)]

Thanks to Rob Wills and Rob Wilton (and any others that contributed to the 
minutes).

The minutes from both opsawg sessions at IETF 118 (Monday and Wednesday) have 
been imported from HedgeDoc and are available at 
https://datatracker.ietf.org/meeting/118/materials/minutes-118-opsawg-202311061200-00.

There have already been some on-list post-meeting discussions for some of the 
presented work, which is great.  There was one chair action item noted, which 
was to poll the WG to see if there was an appetite to take on a bis to I2RS’s 
RFC8345 based on lessons learned on the digital map and specific routing 
protocol management fronts.

That said, Rob Wilton is working on a new operator-centric OPS WG (tentatively 
called “netmo”) where this bis work was mentioned as perhaps happening there.  
Therefore, we’d like to get AD input as to whether we first discuss this with 
opsawg or wait until this new WG forms.

Of course, all other comments/corrections on the minutes are welcome.

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

Re: [OPSAWG] Intdir last call review of draft-ietf-opsawg-9092-update-06

[Joe Clarke (jclarke)]

Thank you for the review, Sheng Jiang.  OPSAWG appreciates it.

Joe

From: Sheng Jiang via Datatracker 
Date: Monday, November 20, 2023 at 06:36
To: int-...@ietf.org 
Cc: draft-ietf-opsawg-9092-update@ietf.org 
, last-c...@ietf.org 
, opsawg@ietf.org 
Subject: Intdir last call review of draft-ietf-opsawg-9092-update-06
Reviewer: Sheng Jiang
Review result: Ready with Nits

I have reviewed this document as part of the IntArea directorate's ongoing
effort to review all IETF documents being processed by the IESG. Comments that
are not addressed in last call may be included in AD reviews during the IESG
review. Document editors and WG chairs should treat these comments just like
any other last call comments.

Document: draft-ietf-opsawg-9092-update-06
Reviewer: Sheng Jiang
Review Date: 2023-11-20
Result: Ready with Nits

This Standards Track document specifies how to augment the
Routing Policy Specification Language inetnum: class to
refer specifically to geofeed data files and describes an
optional scheme that uses the Resource Public Key
Infrastructure to authenticate the geofeed datafiles. It intends
to obsolete RFC 9092. It is well written and almost ready with
several Nits regarding to references, see beloww.

Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110)
Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286)
Downref: Normative reference to an Informational RFC: RFC 8805

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

Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update

[Joe Clarke (jclarke)]

>   *   The changes vs 9092 lists "Geofeed file only UTF-8 CSV", but the
>   NEW abstract removes the CSV mentions that were called out in
>   the abstract of RFC9092. I would revert to the OLD wording in
>   9092.

my, admittedly poor, memory is that this happened because some other
reviewer pushed in the other direction.

but i think this would be a good change and is in my emacs buffer for
-07.  unless i hear otherwise, good change

[JMC] I recall commenting that I thought normative language should be used to 
enforce UTF-8 CSV, but reading the abstract from 9092, I agree mentioning CSV 
there seems reasonable.

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

[OPSAWG] WG LC: draft-ietf-opsawg-9092-update

[Joe Clarke (jclarke)]

This kicks off a two week WG LC on the update to “Finding and Using Geofeed 
Data”.  This draft has received some initial comments and a rather extensive 
certificate review from Job.  We’d appreciate some more eyes to look iover the 
changes to the original RFC9092 and focus comments there.  Thanks again to mcr 
for agreeing to shepherd this document.

In addition to substantive comments, we’d appreciate reviewers that think it is 
ready to go to say so on-list.  The WG LC will end on November 28, 2023.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-9092-update/

Thanks.

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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-9092-update-05.txt

[Joe Clarke (jclarke)]

Unfortunately, we’ve had crickets from the directorates.  Since we have a 
shepherd, I think we’ll kickoff a WG LC and hopefully that will encourage more 
eyes.

Joe

From: Joe Clarke (jclarke) 
Date: Monday, October 23, 2023 at 12:54
To: Randy Bush , Ops Area WG 
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-9092-update-05.txt
Let me kick off some reviews in DT.  From my chair perspective, I do think it’s 
close to WGLC.  That should get a few more reviews.

Joe

From: OPSAWG  on behalf of Randy Bush 
Date: Thursday, October 19, 2023 at 18:13
To: Ops Area WG 
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-9092-update-05.txt
> authors pushed latest revision of $ubject.  would very much like some
> wg members, or anyone actually. to have a look and comment before we
> decide if it is time to ask for wglc.

well, that elicited only one poke (thanks ggm) :(

chairs, think a wglc will elicit more?

randy

___
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] IETF 118 opsawg/Ops Area session today!

[Joe Clarke (jclarke)]

Good morning to those of you in Prague.  As a reminder, our first session is 
today at 13:00 in the Ballroom (on the Mezzanine).  All slides for today’s 
session are now in Data Tracker.

We still need a minutes scribe!  Please let the chairs know if you are willing 
to help out.

Thanks.

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

Re: [OPSAWG] FW: New Version Notification for draft-opsawg-poweff-00.txt

[Joe Clarke (jclarke)]

Yes!  I knew I was forgetting to mention something.  That would help.  I found 
myself doing a lot of back and forth scrolling to grok things.

Joe

From: OPSAWG  on behalf of Tianran Zhou 

Date: Tuesday, October 31, 2023 at 09:01
To: Marisol Palmero Amador (mpalmero) , 
opsawg 
Cc: Gonzalo Salgueiro (gsalguei) , Jan Lindblad (jlindbla) 
, Snezana Mitrovic (snmitrov) , 
emile.stephan , Per Andersson (perander) 
, Esther Roure Vila (erourevi) , 
emile.stephan 
Subject: Re: [OPSAWG] FW: New Version Notification for 
draft-opsawg-poweff-00.txt
Hi Marisol,

Could you please add the YANG tree in the draft? So that people can understand 
your idea easier.

Best,
Tianran





Sent from WeLink
发件人： Marisol Palmero Amador 
(mpalmero)mailto:mpalmero=40cisco@dmarc.ietf.org>>
收件人： opsawgmailto:opsawg@ietf.org>>
抄送： Gonzalo Salgueiro 
(gsalguei)mailto:gsalg...@cisco.com>>;Jan Lindblad 
(jlindbla)mailto:jlind...@cisco.com>>;Snezana Mitrovic 
(snmitrov)mailto:snmit...@cisco.com>>;emile.stephanmailto:emile.step...@orange.com>>;Per
 Andersson (perander)mailto:peran...@cisco.com>>;Esther 
Roure Vila 
(erourevi)mailto:erour...@cisco.com>>;emile.stephanmailto:emile.step...@orange.com>>
主题： [OPSAWG] FW: New Version Notification for draft-opsawg-poweff-00.txt
时间： 2023-10-28 01:09:07

Dear OPSA WG,

Earlier this week, we posted a new draft that introduces a data model for power 
and energy related metrics :
https://datatracker.ietf.org/doc/draft-opsawg-poweff/
The focus is mainly on runtime information provided by power sensors, but also 
an extension to other related metrics and given attributes that will complement 
the representation of the energy consumed by the network device, implemented in 
hardware or software, as well as by specific network components.
This is a first-version approach where we see still challenges based on 
implementation.
Note: Some of those challenges are covered on Jan`s draft: 
draft-lindblad-tlm-philatelist

Along with POWEFF draft, we’ve also updated the version of the Sustainability 
Insights draft:
https://datatracker.ietf.org/doc/draft-almprs-sustainability-insights/
where we introduced an updated architecture reference diagram, that provides a 
more structured view of the functional blocks that might be part of where those 
attributes and metrics might be produced, processed, visualized, etc. We also 
have reviewed and added Use Cases that such framework could drive.

We greatly appreciate your thoughts and comments.

Many thanks,
Marisol Palmero


From: internet-dra...@ietf.org 
Date: Friday, 20 October 2023 at 17:45
To: Gonzalo Salgueiro (gsalguei) , Jan Lindblad (jlindbla) 
, Marisol Palmero Amador (mpalmero) , 
Snezana Mitrovic (snmitrov) 
Subject: New Version Notification for draft-opsawg-poweff-00.txt
A new version of Internet-Draft draft-opsawg-poweff-00.txt has been
successfully submitted by Marisol Palmero and posted to the
IETF repository.

Name: draft-opsawg-poweff
Revision: 00
Title:Power and Energy Efficiency
Date: 2023-10-20
Group:Individual Submission
Pages:37
URL:  https://www.ietf.org/archive/id/draft-opsawg-poweff-00.txt
Status:   https://datatracker.ietf.org/doc/draft-opsawg-poweff/
HTMLized: https://datatracker.ietf.org/doc/html/draft-opsawg-poweff


Abstract:

   This document motivates and specifies a data model to report power
   and energy efficiency of an asset.  As highlighted during the IAB
   workshop on environmental impacts
   (https://datatracker.ietf.org/doc/html/draft-iab-ws-environmental-
   impacts-report-00), visibility is a very important first step
   (paraphrasing Peter Drucker's mantra of "You cannot improve what you
   don't measure").  During the workshop the need for standardized
   metrics was established, to avoid proprietary, double counting and
   even contradictory metrics across vendors.

   This Power and Energy Efficiency Telemetry Specification (POWEFF) is
   required to promote consistency across vendors and consumers, based
   on: 1.  The definition of datasets and attributes defining a common
   data model utilized by the standard calculation to yield power and
   energy efficiency value for any asset or network element.  2.  The
   standard calculations utilizing the specified datasets and attributes
   which will yield energy consumption and energy efficiency value for
   any asset or network element.

   The model provides information and data requirements for calculating
   the Power and Energy Efficiency for specific assets.  Assets can
   include hardware (physical or virtual), software, applications, or
   services.



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

Re: [OPSAWG] New Version Notification for draft-opsawg-poweff-00.txt

[Joe Clarke (jclarke)]

You mention calculation in the draft, but I didn’t see this reflected in the 
data model.  Note that I’m not sure the data model needs to address 
calculations per se.  I think you could spell those out outside of YANG, with 
respect to the data objects.  I just expected to see some specifics or examples 
of using the modeled data to reflect a composite energy efficiency metric.


[Marisol]
Calculations will be part of what we consider part of the POWEFF-derived module
We need more discussions, and feedback from the group on it
Our next steps are considering linking into the draft-lindblad-tlm-philatelist 
proposal. This module should contribute to the data produced by the 
aggregation/processor, where we might need to consume from pointers and 
metadata, like ietf-interfaces model.


[JMC] Ah, okay.  Some of those things didn’t seem like calculations so much as 
specs or real-time measurements.  That said, energy-traffic-ratio fits the 
calculation definition and seems useful.



On the data model, I’m a bit confused why the network interface module is 
needed.  In your text about this you say that it might line up exactly to 
standardized modules, but it’s needed for those things that are not network 
devices.  What devices are not network devices that have network interfaces and 
don’t fit into the general, say, ietf-interfaces model?

[Marisol]
Our thought it is more in the direction on how to add into “useful work” and 
which attributes/“sensors” might be part of it. As part of the asset 
definition, we are not only looking into network devices, but we also consider 
servers, as part of compute, they also have defined interfaces, and it might be 
where YANG ietf-interface model doesn’t fit well. But we agree that pointers 
should address different types of assets.

[JMC] Such as?  What compute interfaces wouldn’t fit with what you’re currently 
modeling in the interfaces?

As chair, I’d love to see how this factors into the green networking metrics 
work that has been presented at opsawg before.  Some of the text touches on 
similar topics.  Perhaps POWEFF can be seen to take a practical approach to 
some of the concepts and thoughts in draft-cx-opsawg-green-metrics?

[Marisol]
We have scheduled a Side Meeting on Monday morning, and it will be great to 
review with the green-metrics authors, how we should move forward
Side meeting: Monday Nov 6, 8:45 - 9:30Karlin 4 Sustainability 
Insights. Description: Gaps on Power Metrics Normalization

[JMC] Excellent.

Joe


Many thanks,
Marisol



Joe

From: OPSAWG  on behalf of Marisol Palmero Amador 
(mpalmero) 
Date: Friday, October 27, 2023 at 13:07
To: opsawg@ietf.org 
Cc: Gonzalo Salgueiro (gsalguei) , Jan Lindblad (jlindbla) 
, Snezana Mitrovic (snmitrov) , 
emile.step...@orange.com , Per Andersson (perander) 
, Esther Roure Vila (erourevi) , 
emile.step...@orange.com 
Subject: [OPSAWG] FW: New Version Notification for draft-opsawg-poweff-00.txt
Dear OPSA WG,

Earlier this week, we posted a new draft that introduces a data model for power 
and energy related metrics :
https://datatracker.ietf.org/doc/draft-opsawg-poweff/




The focus is mainly on runtime information provided by power sensors, but also 
an extension to other related metrics and given attributes that will complement 
the representation of the energy consumed by the network device, implemented in 
hardware or software, as well as by specific network components.
This is a first-version approach where we see still challenges based on 
implementation.
Note: Some of those challenges are covered on Jan`s draft: 
draft-lindblad-tlm-philatelist

Along with POWEFF draft, we’ve also updated the version of the Sustainability 
Insights draft:
https://datatracker.ietf.org/doc/draft-almprs-sustainability-insights/
where we introduced an updated architecture reference diagram, that provides a 
more structured view of the functional blocks that might be part of where those 
attributes and metrics might be produced, processed, visualized, etc. We also 
have reviewed and added Use Cases that such framework could drive.

We greatly appreciate your thoughts and comments.

Many thanks,
Marisol Palmero


From: internet-dra...@ietf.org 
Date: Friday, 20 October 2023 at 17:45
To: Gonzalo Salgueiro (gsalguei) , Jan Lindblad (jlindbla) 
, Marisol Palmero Amador (mpalmero) , 
Snezana Mitrovic (snmitrov) 
Subject: New Version Notification for draft-opsawg-poweff-00.txt
A new version of Internet-Draft draft-opsawg-poweff-00.txt has been
successfully submitted by Marisol Palmero and posted to the
IETF repository.

Name: draft-opsawg-poweff
Revision: 00
Title:Power and Energy Efficiency
Date: 2023-10-20
Group:Individual Submission
Pages:37
URL:  https://www.ietf.org/archive/id/draft-opsawg-poweff-00.txt
Status:   https://datatracker.ietf.org/doc/draft-opsawg-poweff/
HTMLized: 

[OPSAWG] HEADS UP: Remote IETF 118 attendees Meetecho changes

[Joe Clarke (jclarke)]

The Meetecho interface has changed for 118.   I affectionately think it looks 
like an Xfce desktop.  But whatever your opinion, please familiarize yourself 
with the requirements for remote attendance at 
https://www.ietf.org/how/meetings/technology/meetecho-guide-participant/ (the 
video is worth watching).

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

[OPSAWG] IETF 118 Final opsawg agenda

[Joe Clarke (jclarke)]

Our agenda is now final.  We have a somewhat packed schedule across both 
meeting slots (though we do have some buffer).  Presenters, please start to 
work on your slides.  We’d appreciate you submit them no later than this Friday 
(Nov 3).  When building slides, focus on your designated time allotments.

https://datatracker.ietf.org/doc/agenda-118-opsawg/

Talk to you all in Prague.

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

Re: [OPSAWG] New Version Notification for draft-opsawg-poweff-00.txt

[Joe Clarke (jclarke)]

I had a brief read of POWEFF, and I have some questions/possible discussion 
points for your presentation (as a contributor).

You mention calculation in the draft, but I didn’t see this reflected in the 
data model.  Note that I’m not sure the data model needs to address 
calculations per se.  I think you could spell those out outside of YANG, with 
respect to the data objects.  I just expected to see some specifics or examples 
of using the modeled data to reflect a composite energy efficiency metric.

On the data model, I’m a bit confused why the network interface module is 
needed.  In your text about this you say that it might line up exactly to 
standardized modules, but it’s needed for those things that are not network 
devices.  What devices are not network devices that have network interfaces and 
don’t fit into the general, say, ietf-interfaces model?

Finally, why are all of these objects config true?  The way I read this, a 
vendor or device manufacturer would stream these objects based on how the 
system is built or how it’s operating.  I can’t see any reason why one would 
need to configure any of this.

As chair, I’d love to see how this factors into the green networking metrics 
work that has been presented at opsawg before.  Some of the text touches on 
similar topics.  Perhaps POWEFF can be seen to take a practical approach to 
some of the concepts and thoughts in draft-cx-opsawg-green-metrics?

Joe

From: OPSAWG  on behalf of Marisol Palmero Amador 
(mpalmero) 
Date: Friday, October 27, 2023 at 13:07
To: opsawg@ietf.org 
Cc: Gonzalo Salgueiro (gsalguei) , Jan Lindblad (jlindbla) 
, Snezana Mitrovic (snmitrov) , 
emile.step...@orange.com , Per Andersson (perander) 
, Esther Roure Vila (erourevi) , 
emile.step...@orange.com 
Subject: [OPSAWG] FW: New Version Notification for draft-opsawg-poweff-00.txt
Dear OPSA WG,

Earlier this week, we posted a new draft that introduces a data model for power 
and energy related metrics :
https://datatracker.ietf.org/doc/draft-opsawg-poweff/


The focus is mainly on runtime information provided by power sensors, but also 
an extension to other related metrics and given attributes that will complement 
the representation of the energy consumed by the network device, implemented in 
hardware or software, as well as by specific network components.
This is a first-version approach where we see still challenges based on 
implementation.
Note: Some of those challenges are covered on Jan`s draft: 
draft-lindblad-tlm-philatelist

Along with POWEFF draft, we’ve also updated the version of the Sustainability 
Insights draft:
https://datatracker.ietf.org/doc/draft-almprs-sustainability-insights/
where we introduced an updated architecture reference diagram, that provides a 
more structured view of the functional blocks that might be part of where those 
attributes and metrics might be produced, processed, visualized, etc. We also 
have reviewed and added Use Cases that such framework could drive.

We greatly appreciate your thoughts and comments.

Many thanks,
Marisol Palmero


From: internet-dra...@ietf.org 
Date: Friday, 20 October 2023 at 17:45
To: Gonzalo Salgueiro (gsalguei) , Jan Lindblad (jlindbla) 
, Marisol Palmero Amador (mpalmero) , 
Snezana Mitrovic (snmitrov) 
Subject: New Version Notification for draft-opsawg-poweff-00.txt
A new version of Internet-Draft draft-opsawg-poweff-00.txt has been
successfully submitted by Marisol Palmero and posted to the
IETF repository.

Name: draft-opsawg-poweff
Revision: 00
Title:Power and Energy Efficiency
Date: 2023-10-20
Group:Individual Submission
Pages:37
URL:  https://www.ietf.org/archive/id/draft-opsawg-poweff-00.txt
Status:   https://datatracker.ietf.org/doc/draft-opsawg-poweff/
HTMLized: https://datatracker.ietf.org/doc/html/draft-opsawg-poweff


Abstract:

   This document motivates and specifies a data model to report power
   and energy efficiency of an asset.  As highlighted during the IAB
   workshop on environmental impacts
   (https://datatracker.ietf.org/doc/html/draft-iab-ws-environmental-
   impacts-report-00), visibility is a very important first step
   (paraphrasing Peter Drucker's mantra of "You cannot improve what you
   don't measure").  During the workshop the need for standardized
   metrics was established, to avoid proprietary, double counting and
   even contradictory metrics across vendors.

   This Power and Energy Efficiency Telemetry Specification (POWEFF) is
   required to promote consistency across vendors and consumers, based
   on: 1.  The definition of datasets and attributes defining a common
   data model utilized by the standard calculation to yield power and
   energy efficiency value for any asset or network element.  2.  The
   standard calculations utilizing the specified datasets and attributes
   which will yield energy consumption and energy efficiency value for
   any asset or 

Re: [OPSAWG] IETF 118 opsawg / OpsA tentative agenda

[Joe Clarke (jclarke)]

You’re right.  I had it on my mind, and it fell out when I moved to Day 2.  
It’s there now.

https://datatracker.ietf.org/doc/agenda-118-opsawg/

Joe

From: Benoit Claise 
Date: Wednesday, October 25, 2023 at 11:50
To: Joe Clarke (jclarke) , opsawg@ietf.org 

Cc: opsawg-cha...@ietf.org , ops-...@ietf.org 
, 'Oscar González de Dios' 

Subject: Re: [OPSAWG] IETF 118 opsawg / OpsA tentative agenda
Hi Joe,

You forgot the draft-havel-opsawg-digital-map-01 slot.

Regards, Benoit
On 10/25/2023 4:51 PM, Joe Clarke (jclarke) wrote:
Hello, WG and ADs.  The tentative agenda for our two opsawg sessions for IETF 
118 is up.  We are close to capacity, but we still have some buffer time.  
Please review and let me know if I have missed any requests.

https://datatracker.ietf.org/meeting/118/materials/agenda-118-opsawg-00.txt

We also need minutes takers for both sessions.  This is a great opportunity to 
connect more with IETF process.  Please respond if you’re interested.  We won’t 
have Rob forever!

Thanks.

Joe



___

OPSAWG mailing list

OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>

https://www.ietf.org/mailman/listinfo/opsawg

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

[OPSAWG] IETF 118 opsawg / OpsA tentative agenda

[Joe Clarke (jclarke)]

Hello, WG and ADs.  The tentative agenda for our two opsawg sessions for IETF 
118 is up.  We are close to capacity, but we still have some buffer time.  
Please review and let me know if I have missed any requests.

https://datatracker.ietf.org/meeting/118/materials/agenda-118-opsawg-00.txt

We also need minutes takers for both sessions.  This is a great opportunity to 
connect more with IETF process.  Please respond if you’re interested.  We won’t 
have Rob forever!

Thanks.

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

Re: [OPSAWG] CALL FOR ADOPTION: Attachment circuits work

[Joe Clarke (jclarke)]

The call for adoption has concluded.  Unfortunately, the hold down on draft 
submissions is now in effect.  All part of my evil plan, I guess .

Thanks to all that responded with comments.  Despite the fact the work consists 
of four documents, there does appear to be considerable support for tackling 
this effort with upsides in both complementing IETF work (e.g., with LxNM) as 
well as O-RAN.

Authors, when able, please resubmit the drafts as draft-ietf-opsawg-…-00 
(replacing each of the original drafts respectively).  The chairs would also 
appreciate (from authors as well as the broader WG) suggestions for a shepherd 
as this work progresses.  A reminder to the WG that the authors and 
contributors replied that there is no known IPR covering this work.

Thanks.

Joe

From: Joe Clarke (jclarke) 
Date: Monday, October 2, 2023 at 09:21
To: opsawg@ietf.org 
Subject: CALL FOR ADOPTION: Attachment circuits work
At IETF 117, we asked the room if there was support to adopt the four 
attachment circuits drafts.  The room had support (of the 75 present, 18 raised 
hands for adoption interest, 1 was opposed), but the list is where it counts.

While the drafts aren’t too terribly long, there are four of them, so we will 
do a three week call for adoption.  Please review and comment on-list on the 
following indicating whether you support their adoption or not:

· draft-boro-opsawg-teas-common-ac
· draft-boro-opsawg-teas-attachment-circuit
· draft-boro-opsawg-ntw-attachment-circuit
· draft-boro-opsawg-ac-lxsm-lxnm-glue

The authors and contributors have all signaled there is no known IPR covering 
this work.

The CfA will end on October 23.

Thanks.

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

Re: [OPSAWG] Status of T+ TLS work

[Joe Clarke (jclarke)]

Thanks for the update, Douglas.  We look forward to rev -04.

Joe

From: Douglas Gash (dcmgash) 
Date: Monday, October 23, 2023 at 16:14
To: Joe Clarke (jclarke) , 
draft-ietf-opsawg-tacacs-tl...@ietf.org 

Cc: opsawg@ietf.org 
Subject: Re: Status of T+ TLS work
Hi Joe,

An update is underway, current phase is to examine RFC 9325, which seems very 
relevant, to see what can be delegated to it.

From: Joe Clarke (jclarke) 
Date: Monday, 23 October 2023 at 18:04
To: draft-ietf-opsawg-tacacs-tl...@ietf.org 

Cc: opsawg@ietf.org 
Subject: Status of T+ TLS work
Hello, authors.  As we prepare for IETF 118, I wanted to get an update from you 
on the TACACS+ TLS work.  The last revision was in June, and since then there 
have been comments from Alan, Med, Marc Huber, and Peter Marrinon.  It seems 
like a revision is required.  What plans do you have for updating?

Thanks.

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

Re: [OPSAWG] Session slot request in OPSAWG for draft-havel-opsawg-digital-map-01

[Joe Clarke (jclarke)]

We’re not specifically asking for which slot people want.  But it does seem 
like we will need to use Wednesday.  Who is presenting and will they be local 
or remote?

Joe

From: OPSAWG  on behalf of Olga Havel 

Date: Tuesday, October 24, 2023 at 10:12
To: opsawg-cha...@ietf.org 
Cc: ahmed.elhass...@swisscom.com , 
digitalmap-y...@ietf.org , opsawg@ietf.org 

Subject: [OPSAWG] Session slot request in OPSAWG for 
draft-havel-opsawg-digital-map-01
Dear Chairs,
We would like to ask you for a session slot (10-15 mins) during the Wednesday 
session.

We would like to present

-  the new version 01 of the draft:  Modelling the Digital map based on 
RFC8345: Sharing Experience and Perspectives 
(https://datatracker.ietf.org/doc/draft-havel-opsawg-digital-map/)

-  comparison between the 2 options for modelling IS-IS topology

o   option 1: based on the existing RFC8345 and the current version of 
https://datatracker.ietf.org/doc/draft-ogondio-opsawg-isis-topology

o   option 2: requires RFC8345 extensions, 
https://datatracker.ietf.org/doc/draft-ogondio-opsawg-isis-topology/ would 
evolve based on these extensions

Best Regards,
Olga
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] CALL FOR PRESENTATIONS: Submit requests for IETF 118

[Joe Clarke (jclarke)]

Who is presenting and will they be local or remote?

Joe

From: Jean Quilbeuf 
Date: Tuesday, October 24, 2023 at 10:33
To: Joe Clarke (jclarke) , opsawg@ietf.org 
Cc: ops-...@ietf.org 
Subject: RE: CALL FOR PRESENTATIONS: Submit requests for IETF 118
Dear OPSAWG chairs,
We would like to present updates in draft-ietf-opsawg-collected-data-manifest-02

10 minutes would be great.

Thanks
Jean


From: OPSAWG  On Behalf Of Joe Clarke (jclarke)
Sent: Friday, October 13, 2023 10:30 PM
To: opsawg@ietf.org
Cc: ops-...@ietf.org
Subject: Re: [OPSAWG] CALL FOR PRESENTATIONS: Submit requests for IETF 118

FYI, the agenda is now final.  The days and times below are still correct for 
the two opsawg sessions.

Joe

From: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>
Date: Friday, October 6, 2023 at 19:01
To: opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Cc: ops-...@ietf.org<mailto:ops-...@ietf.org> 
mailto:ops-...@ietf.org>>
Subject: CALL FOR PRESENTATIONS: Submit requests for IETF 118
Hello, opsawg (and Ops Area).  The preliminary agenda is up at 
https://datatracker.ietf.org/meeting/118/agenda.  This time around we’re trying 
something new.  We have two session slots.  We have a typical two-hour slot 
currently on Monday from 13:00 to 15:00.  This will be the combined opsawg/Ops 
Area session.

Then on Wednesday from 13:00 to 14:00, we have a second slot for those opsawg 
presentations that didn’t get time in the first.  This doesn’t mean we want to 
jam pack both slots.  What we are trying to fix is what we had last time where 
people had to be cut.

If you would like a presentation slot, please send email to opsawg-chairs@ with 
the draft, presenter, desired time, and whether or not the presenter will be 
local.  Adopted work will be prioritized.  Call for presentations will close on 
October 27.

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

Re: [OPSAWG] Session slot request in OPSAWG for network/compute exposure

[Joe Clarke (jclarke)]

Who is presenting and will they be local or remote?

Joe

From: OPSAWG  on behalf of Jordi Ros Giralt 

Date: Tuesday, October 24, 2023 at 11:04
To: opsawg@ietf.org 
Cc: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 

Subject: [OPSAWG] Session slot request in OPSAWG for network/compute exposure
Dear Chairs,

We would like to request a session slot to present a new draft on joint 
exposure of network and compute information: 
https://datatracker.ietf.org/doc/draft-rcr-opsawg-operational-compute-metrics/

10’ minutes would be ideal, but if time is limited, we would be happy with 5’.

Thanks,
Jordi, Sabine, and Luis
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Status of T+ TLS work

[Joe Clarke (jclarke)]

Hello, authors.  As we prepare for IETF 118, I wanted to get an update from you 
on the TACACS+ TLS work.  The last revision was in June, and since then there 
have been comments from Alan, Med, Marc Huber, and Peter Marrinon.  It seems 
like a revision is required.  What plans do you have for updating?

Thanks.

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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-9092-update-05.txt

[Joe Clarke (jclarke)]

Let me kick off some reviews in DT.  From my chair perspective, I do think it’s 
close to WGLC.  That should get a few more reviews.

Joe

From: OPSAWG  on behalf of Randy Bush 
Date: Thursday, October 19, 2023 at 18:13
To: Ops Area WG 
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-9092-update-05.txt
> authors pushed latest revision of $ubject.  would very much like some
> wg members, or anyone actually. to have a look and comment before we
> decide if it is time to ask for wglc.

well, that elicited only one poke (thanks ggm) :(

chairs, think a wglc will elicit more?

randy

___
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] Session slot request in OPSAWG

[Joe Clarke (jclarke)]

So noted.

Joe

From: OPSAWG  on behalf of Marisol Palmero Amador 
(mpalmero) 
Date: Friday, October 20, 2023 at 06:10
To: opsawg@ietf.org 
Cc: Jan Lindblad (jlindbla) , Per Andersson (perander) 
, Snezana Mitrovic (snmitrov) , Esther 
Roure Vila (erourevi) , Gonzalo Salgueiro (gsalguei) 
, emile.step...@orange.com 
Subject: [OPSAWG] Session slot request in OPSAWG
Dear chairs,
We would like to ask you for a session slot, when possible, on Monday session.

We would like to introduce to the working group two drafts:

· Sustainability Insights - 
https://datatracker.ietf.org/doc/draft-almprs-sustainability-insights/

· POWEFF (to be submitted before Monday 23rd Oct)

10 min will be good for us to cover both.

Many thanks,
Marisol



Message: 2
Date: Fri, 13 Oct 2023 13:06:28 -0700
From: "\"IETF Secretariat\"" mailto:age...@ietf.org>>
To: mailto:jcla...@cisco.com>>, 
mailto:opsawg-cha...@ietf.org>>
Cc: opsawg@ietf.org, 
rwil...@cisco.com
Subject: [OPSAWG] opsawg - Requested sessions have been scheduled for
IETF 118
Message-ID: 
<169722758803.19136.16369844994976782...@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"

Dear Joe Clarke,

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)
Monday, 6 November 2023, Session II 1300-1500 Europe/Prague
Room Name: Ballroom size: 250
-
opsawg Session 2 (1:00 requested)
Wednesday, 8 November 2023, Session II 1300-1400 Europe/Prague
Room Name: Congress Hall 1 size: 250
-

Special Note: Combined OpsAWG / OpsAREA

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

Request Information:


-
Working Group Name: Operations and Management Area Working Group
Area Name: Operations and Management Area
Session Requester: Joe Clarke
First session joint with: opsarea

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




Participants who must be present:
  Warren Ace Kumari

Resources Requested:

Special Requests:
  PLEASE NOTE: Combined OpsAWG / OpsAREA
-





Marisol Palmero
CCIE #5122 | Technical Leader EMEA  | Cisco CPX TEAO | P: +34.91.201.2643 | M: 
+34.629.634.595

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

Re: [OPSAWG] CALL FOR ADOPTION: Attachment circuits work

[Joe Clarke (jclarke)]

I recall that Med has either presented some of this work or discussed it with 
TEAS in the past, but would be good to get as many comments on this work as 
possible.  Opsawg is currently in an adoption process for the four drafts below 
until next Monday.  Thus far, sentiment has been positive on the list.  Further 
comments are welcome.

Joe

From: Joe Clarke (jclarke) 
Date: Monday, October 2, 2023 at 09:21
To: opsawg@ietf.org 
Subject: CALL FOR ADOPTION: Attachment circuits work
At IETF 117, we asked the room if there was support to adopt the four 
attachment circuits drafts.  The room had support (of the 75 present, 18 raised 
hands for adoption interest, 1 was opposed), but the list is where it counts.

While the drafts aren’t too terribly long, there are four of them, so we will 
do a three week call for adoption.  Please review and comment on-list on the 
following indicating whether you support their adoption or not:

· draft-boro-opsawg-teas-common-ac
· draft-boro-opsawg-teas-attachment-circuit
· draft-boro-opsawg-ntw-attachment-circuit
· draft-boro-opsawg-ac-lxsm-lxnm-glue

The authors and contributors have all signaled there is no known IPR covering 
this work.

The CfA will end on October 23.

Thanks.

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

Re: [OPSAWG] CALL FOR ADOPTION: Attachment circuits work

[Joe Clarke (jclarke)]

Thanks, Oscar.  I saw the “teas” field in the name and recall (maybe in error) 
that Med had said he had presented to or informed that WG of this effort.  If I 
am mis-remembering, I will forward this adoption call there for the last ~week.

Joe

From: Oscar González de Dios 
Date: Tuesday, October 17, 2023 at 04:43
To: Joe Clarke (jclarke) , opsawg@ietf.org 
Subject: RE: CALL FOR ADOPTION: Attachment circuits work
Hi Joe, all,

   These drafts complement the work that was started with the LxNM models 
and the Service attachment points. It provides a much necessary glue to the 
ongoing efforts on slicing. Hence (also as co-author of the document) I support 
the adoption of the drafts.

  I also suggest informing TEAS about the adoption, as some of the 
drafts are applicable and usable in TEAS document.

  Best Regards,

  Oscar

De: OPSAWG  En nombre de Joe Clarke (jclarke)
Enviado el: lunes, 2 de octubre de 2023 15:22
Para: opsawg@ietf.org
Asunto: [OPSAWG] CALL FOR ADOPTION: Attachment circuits work

At IETF 117, we asked the room if there was support to adopt the four 
attachment circuits drafts.  The room had support (of the 75 present, 18 raised 
hands for adoption interest, 1 was opposed), but the list is where it counts.

While the drafts aren’t too terribly long, there are four of them, so we will 
do a three week call for adoption.  Please review and comment on-list on the 
following indicating whether you support their adoption or not:

· draft-boro-opsawg-teas-common-ac
· draft-boro-opsawg-teas-attachment-circuit
· draft-boro-opsawg-ntw-attachment-circuit
· draft-boro-opsawg-ac-lxsm-lxnm-glue

The authors and contributors have all signaled there is no known IPR covering 
this work.

The CfA will end on October 23.

Thanks.

Joe



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição


Le informamos de que el responsable del tratamiento de sus datos es la entidad 
del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el 
contacto profesional y gestionar la relación establecida con el destinatario o 
con la entidad a la que está vinculado. Puede contactar con el responsable del 
tratamiento y ejercitar sus derechos escribiendo a 
privacidad@telefonica.com<mailto:privacidad@telefonica.com>. Puede 
consultar información adicional sobre el tratamiento de sus datos en nuestra 
Política de 
Privacidad<https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>.

We inform you that the data controller is the Telefónica Group entity linked to 
the sender, for the purpose of maintaining professional contact and managing 
the relationship established with the recipient or with the entity to which it 
is linked. You may contact the data controller and exercise your rights by 
writing to privacidad@telefonica.com<mailto:privacidad@telefonica.com>. 
You may consult additional information on the processing of your data in our 
Privacy 
Policy<https://www.telefonica.com/en/wp-content/uploads/sites/5/2022/12/Telefonica-Third-data-subjects-Privacy-Policy.pdf>.

Informamos que o responsável pelo tratamento dos seus dados é a entidade do 
Grupo Telefónica vinculada ao remetente, a fim de manter o contato professional 
e administrar a relação estabelecida com o destinatário ou com a entidade à 
qual esteja vinculado. Você pode entrar em cont

Re: [OPSAWG] CALL FOR PRESENTATIONS: Submit requests for IETF 118

[Joe Clarke (jclarke)]

FYI, the agenda is now final.  The days and times below are still correct for 
the two opsawg sessions.

Joe

From: Joe Clarke (jclarke) 
Date: Friday, October 6, 2023 at 19:01
To: opsawg@ietf.org 
Cc: ops-...@ietf.org 
Subject: CALL FOR PRESENTATIONS: Submit requests for IETF 118
Hello, opsawg (and Ops Area).  The preliminary agenda is up at 
https://datatracker.ietf.org/meeting/118/agenda.  This time around we’re trying 
something new.  We have two session slots.  We have a typical two-hour slot 
currently on Monday from 13:00 to 15:00.  This will be the combined opsawg/Ops 
Area session.

Then on Wednesday from 13:00 to 14:00, we have a second slot for those opsawg 
presentations that didn’t get time in the first.  This doesn’t mean we want to 
jam pack both slots.  What we are trying to fix is what we had last time where 
people had to be cut.

If you would like a presentation slot, please send email to opsawg-chairs@ with 
the draft, presenter, desired time, and whether or not the presenter will be 
local.  Adopted work will be prioritized.  Call for presentations will close on 
October 27.

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

Re: [OPSAWG] Working group adoption call for draft-ma-opsawg-ucl-acl-03

[Joe Clarke (jclarke)]

Thanks, Qiufang.  Olga asked the question, as I recall.  Your answer here makes 
sense, and I would emphasize this in the document to be clear what hardware 
ramifications might exist and what operational tradeoffs one would consider.

Joe

From: maqiufang (A) 
Date: Thursday, October 12, 2023 at 04:18
To: Joe Clarke (jclarke) 
Cc: Tianran Zhou , opsawg@ietf.org , 
opsawg-cha...@ietf.org 
Subject: RE: Working group adoption call for draft-ma-opsawg-ucl-acl-03
Hi, Joe

Apologize for being late with this response.

Please first allow me to give more context about this specific question, I 
recall presenting the next step of this work in IETF 117, to add 
application-group as the third endpoint group (beside user-group and 
device-group), the authors believe this could be useful if multiple 
applications that need to apply different access control policies run on a 
single device. That way would require the controller or the PEP performing the 
application-group based ACL to understand the mapping between the 
application-group and the packet fields(e.g., IP and port). I am thinking it to 
be optional to implement.

I cannot really remember having mentioned that some advanced method like DPI 
must be there to effectively implement this application-group based ACL;-) In 
fact, I am now thinking the easiest way like statically configuring the mapping 
between the application-group and packet fields would work. And I would share 
the idea with you that this work should be able to be used even without any 
additional capabilities. Hopefully this clarifies things to you.

Best Regards,
Qiufang

From: OPSAWG  On Behalf Of Joe Clarke (jclarke)
Sent: Thursday, September 7, 2023 7:01 PM
To: Tianran Zhou ; opsawg@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: Re: [OPSAWG] Working group adoption call for draft-ma-opsawg-ucl-acl-03

As a contributor, I support adoption of this work.  I have previously read and 
commented on this document.  The main reason for my comment this time is to 
address something that was brought up at the mic in 117.  There was a question 
asked about needing deep packet inspection to effectively implement this.  
Quifang said yes, but I don't think it would be necessary.  If the controller 
maintained the state and knew who the user was through other means (e.g., 
AAA/dot1x), it could program the network elements with standard ACL tuple data 
(i.e., traditional ACLs) dynamically, thus not putting more logic onto the 
devices or into the hardware.  This was similar to a past comment of mine, and 
I think the document text addresses this.

It's not to say an implementor couldn't do something fancier within the 
network, but I don't think additional capabilities are required to make this 
work.

Joe

From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Sent: Monday, September 4, 2023 9:12 PM
To: opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Cc: opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org> 
mailto:opsawg-cha...@ietf.org>>
Subject: Working group adoption call for draft-ma-opsawg-ucl-acl-03


Hi WG,



This mail starts a two weeks working group adoption call for 
draft-ma-opsawg-ucl-acl-03

https://datatracker.ietf.org/doc/draft-ma-opsawg-ucl-acl/



Please send over your objections or supports to the mailing list.

If you object the adoption, please also give the reason, so that the authors 
can improve.

We will conclude this adoption call on Sep 20, 2023.

All your comments are welcome.



Best,

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

Re: [OPSAWG] Should the schedule YANG model be seperated from draft-ietf-opsawg-ucl-acl?

[Joe Clarke (jclarke)]

I agree with Tianran.  The scope of this document would be broader than just 
use within UCL-ACL if I understand the intent of the split.

Joe

From: OPSAWG  on behalf of Tianran Zhou 

Date: Monday, October 9, 2023 at 23:38
To: adr...@olddog.co.uk , maqiufang (A) 
, opsawg@ietf.org 
Cc: draft-ietf-opsawg-ucl-...@ietf.org 
Subject: Re: [OPSAWG] Should the schedule YANG model be seperated from 
draft-ietf-opsawg-ucl-acl?
QUESTION FOR THE CHAIRS
If this is split out, does it o into an individual draft for a further adoption 
poll, or can it be split into a second WG ID at once?

ZTR> In my opinion, it should go into an individual draft. We adopted 
draft-ietf-opsawg-ucl-acl because of the whole solution. Scheduling in this 
solution is only a component and very specific. If we want to generalize the 
scheduling for services, resources, etc, the common model is new work.

Best,
Tianran

发件人: OPSAWG  代表 Adrian Farrel
发送时间: 2023年10月10日 10:06
收件人: maqiufang (A) ; opsawg@ietf.org
抄送: draft-ietf-opsawg-ucl-...@ietf.org
主题: Re: [OPSAWG] Should the schedule YANG model be seperated from 
draft-ietf-opsawg-ucl-acl?

As I said in my original comment, I’d like to see this separation. Various 
recent conversations suggest that scheduling (services, resources, ACLs, etc.) 
is becoming a Big Thing. Having a common model to facilitate this would be 
really helpful.

QUESTION FOR THE CHAIRS
If this is split out, does it o into an individual draft for a further adoption 
poll, or can it be split into a second WG ID at once?

A

From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
Behalf Of maqiufang (A)
Sent: 07 October 2023 11:48
To: opsawg@ietf.org
Cc: 
draft-ietf-opsawg-ucl-...@ietf.org
Subject: [OPSAWG] Should the schedule YANG model be seperated from 
draft-ietf-opsawg-ucl-acl?

Hi, all

Based on the comments we’ve received during the adoption call of 
draft-ma-opsawg-ucl-acl [1], the authors would like to start a separate thread 
to highlight a question raised by Adrian:
should the schedule model be moved out into a separate document? And we would 
like to collect more feedback from the WG.

It is indeed that the ietf-schedule YANG model in the draft is now designed to 
be applicable in other common scheduling contexts and not specific to ACL 
policies.
The authors already see some usage of it in other date and time based 
context[2], and it might seem awkward for it (and other potential ones in the 
future) to reference draft-ietf-opsawg-ucl-acl for reusing the scheduling 
groupings.

It would be good to know if the WG think it useful for this model to be defined 
in a separate document, so that the authors will take the time to work on it if 
there is consensus.
Would appreciate any of your input, thanks a lot!


[1] https://datatracker.ietf.org/doc/draft-ietf-opsawg-ucl-acl/
[2] 
https://datatracker.ietf.org/doc/draft-contreras-opsawg-scheduling-oam-tests/


Best Regards,
Qiufang
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] CALL FOR PRESENTATIONS: Submit requests for IETF 118

[Joe Clarke (jclarke)]

Hello, opsawg (and Ops Area).  The preliminary agenda is up at 
https://datatracker.ietf.org/meeting/118/agenda.  This time around we’re trying 
something new.  We have two session slots.  We have a typical two-hour slot 
currently on Monday from 13:00 to 15:00.  This will be the combined opsawg/Ops 
Area session.

Then on Wednesday from 13:00 to 14:00, we have a second slot for those opsawg 
presentations that didn’t get time in the first.  This doesn’t mean we want to 
jam pack both slots.  What we are trying to fix is what we had last time where 
people had to be cut.

If you would like a presentation slot, please send email to opsawg-chairs@ with 
the draft, presenter, desired time, and whether or not the presenter will be 
local.  Adopted work will be prioritized.  Call for presentations will close on 
October 27.

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

[OPSAWG] CALL FOR ADOPTION: Attachment circuits work

[Joe Clarke (jclarke)]

At IETF 117, we asked the room if there was support to adopt the four 
attachment circuits drafts.  The room had support (of the 75 present, 18 raised 
hands for adoption interest, 1 was opposed), but the list is where it counts.

While the drafts aren’t too terribly long, there are four of them, so we will 
do a three week call for adoption.  Please review and comment on-list on the 
following indicating whether you support their adoption or not:


  *   draft-boro-opsawg-teas-common-ac
  *   draft-boro-opsawg-teas-attachment-circuit
  *   draft-boro-opsawg-ntw-attachment-circuit
  *   draft-boro-opsawg-ac-lxsm-lxnm-glue

The authors and contributors have all signaled there is no known IPR covering 
this work.

The CfA will end on October 23.

Thanks.

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

Re: [OPSAWG] IPR POLL: Attachment circuits work

[Joe Clarke (jclarke)]

Thanks, Richard.  To be thorough, I assume you mean all four drafts?

Joe

From: Richard Roberts 
Date: Tuesday, September 26, 2023 at 05:17
To: Joe Clarke (jclarke) , opsawg@ietf.org 
, mohamed.boucadair , Oscar 
González de Dios , samir.barg...@gmail.com 
, Wubo (lana) , 
victor.lo...@nokia.com , ivan.by...@rbbn.com 
, Qin Wu , ke-oog...@kddi.com 
, luis-angel.mu...@vodafone.com 

Subject: Re: IPR POLL: Attachment circuits work

Hi Joe,

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



Juniper Business Use Only


From: Joe Clarke (jclarke) 
Sent: Monday, September 25, 2023 5:28 PM
To: opsawg@ietf.org ; mohamed.boucadair 
; Richard Roberts ; Oscar 
González de Dios ; samir.barg...@gmail.com 
; Wubo (lana) ; 
victor.lo...@nokia.com ; ivan.by...@rbbn.com 
; Qin Wu ; ke-oog...@kddi.com 
; luis-angel.mu...@vodafone.com 

Subject: IPR POLL: Attachment circuits work

[External Email. Be cautious of content]


This is a consolidated poll for the following drafts:
· draft-boro-opsawg-teas-common-ac
· draft-boro-opsawg-teas-attachment-circuit
· draft-boro-opsawg-ntw-attachment-circuit
· draft-boro-opsawg-ac-lxsm-lxnm-glue



Authors and contributors on the To: line, 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


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

Re: [OPSAWG] [EXTERNAL] IPR POLL: Attachment circuits work

[Joe Clarke (jclarke)]

Thanks, Ivan.  To be thorough, I assume you mean all four drafts?

Joe

From: Ivan Bykov 
Date: Tuesday, September 26, 2023 at 04:01
To: opsawg@ietf.org 
Cc: Joe Clarke (jclarke) , mohamed.boucadair 
, Richard Roberts , Oscar 
González de Dios , samir.barg...@gmail.com 
, victor.lo...@nokia.com , Qin 
Wu , ke-oog...@kddi.com , 
luis-angel.mu...@vodafone.com , Wubo (lana) 

Subject: Re: [EXTERNAL] IPR POLL: Attachment circuits work
Hi all,

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

Ivan Bykov

On 26 Sep 2023, at 04:19, Wubo (lana)  wrote:

Hi Joe, all,

No, I'm not aware of any IPR that applies to these four drafts.

Thanks,
Bo Wu
From: Joe Clarke (jclarke) 
Sent: Monday, September 25, 2023 11:29 PM
To: opsawg@ietf.org; mohamed.boucadair ; Richard 
Roberts ; Oscar González de Dios 
; samir.barg...@gmail.com; Wubo (lana) 
; victor.lo...@nokia.com; ivan.by...@rbbn.com; Qin Wu 
; ke-oog...@kddi.com; luis-angel.mu...@vodafone.com
Subject: IPR POLL: Attachment circuits work


This is a consolidated poll for the following drafts:
* draft-boro-opsawg-teas-common-ac
* draft-boro-opsawg-teas-attachment-circuit
* draft-boro-opsawg-ntw-attachment-circuit
* draft-boro-opsawg-ac-lxsm-lxnm-glue

Authors and contributors on the To: line, 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



Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] IPR POLL: Attachment circuits work

[Joe Clarke (jclarke)]

I should have adjusted my boilerplate to say “these drafts”.  I assume your 
“this draft” is applicable to all four?

Joe

From: samier Barguil 
Date: Monday, September 25, 2023 at 11:54
To: Joe Clarke (jclarke) 
Cc: opsawg@ietf.org , mohamed.boucadair 
, Richard Roberts , Oscar 
González de Dios , Wubo (lana) 
, victor.lo...@nokia.com , 
ivan.by...@rbbn.com , Qin Wu , 
ke-oog...@kddi.com , luis-angel.mu...@vodafone.com 

Subject: Re: IPR POLL: Attachment circuits work
Hello all,

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

Regards,

Samier

On Mon, Sep 25, 2023 at 5:28 PM Joe Clarke (jclarke) 
mailto:jcla...@cisco.com>> wrote:

This is a consolidated poll for the following drafts:
· draft-boro-opsawg-teas-common-ac
· draft-boro-opsawg-teas-attachment-circuit
· draft-boro-opsawg-ntw-attachment-circuit
· draft-boro-opsawg-ac-lxsm-lxnm-glue

Authors and contributors on the To: line, 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

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

[OPSAWG] IPR POLL: Attachment circuits work

[Joe Clarke (jclarke)]

This is a consolidated poll for the following drafts:

  *   draft-boro-opsawg-teas-common-ac
  *   draft-boro-opsawg-teas-attachment-circuit
  *   draft-boro-opsawg-ntw-attachment-circuit
  *   draft-boro-opsawg-ac-lxsm-lxnm-glue

Authors and contributors on the To: line, 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

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

Re: [OPSAWG] [Technical Errata Reported] RFC5343 (7645)

[Joe Clarke (jclarke)]

The erratum was supposed to be for RFC 5340, which came from the OSPF WG.  This 
is why I suggested it might be easier to simply reject the erratum as reported 
and have the submitter open a new one on the correct RFC so everything is 
directed to the right places and people.

Joe

From: Sandy Ginoza 
Date: Tuesday, September 19, 2023 at 10:03
To: Jürgen Schönwälder 
Cc: Chris Smiley , j.schoenwael...@jacobs-university.de 
, Warren Kumari , Rob 
Wilton (rwilton) , Henk Birkholz 
, Joe Clarke (jclarke) , 
zhoutian...@huawei.com , o...@delong.com 
, opsawg@ietf.org , RFC Editor 

Subject: Re: [Technical Errata Reported] RFC5343 (7645)
Hi Jürgen,

>From the datatracker:

Was draft-ietf-opsawg-snmp-engineid-discovery (opsawg WG)

This document is the product of the Operations and Management Area Working
Group.


Is OPSAWG incorrect, or are you suggesting that the right place to discuss this 
RFC now is OSPF?

Thanks,
RFC Editor/sg



On Sep 18, 2023, at 11:30 PM, Jürgen Schönwälder 
mailto:jschoenwaelder@constructor.university>>
 wrote:

You have to make sure that the right people and WG receive the
erratum, RFC 5340 belongs to the OSPF WG.

/js

On Mon, Sep 18, 2023 at 04:32:02PM -0700, Chris Smiley wrote:


Greetings,

This errata reports a problem with Section A.3.3/RFC 5343.  It has been 
corrected to Section A.3.3/RFC 5340

Please let us know any concerns.

Thank you.

RFC Editor/cs



On Sep 17, 2023, at 10:49 PM, RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>> wrote:

The following errata report has been submitted for RFC5343,
"Simple Network Management Protocol (SNMP) Context EngineID Discovery".

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

--
Type: Technical
Reported by: Owen DeLong 

Section: A.3.3

Original Text
-
Section A.3.3 (in part) reads:

Interface MTU
The size in bytes of the largest IPv6 datagram that can be sent
out the associated interface without fragmentation.  The MTUs of
common Internet link types can be found in Table 7-1 of [MTUDISC].
Interface MTU should be set to 0 in Database Description packets
sent over virtual links.


Corrected Text
--
Interface MTU
The size in bytes of the largest IPv6 datagram that can be sent
out the associated interface without fragmentation.  The MTUs of
common Internet link types can be found in Table 7-1 of [MTUDISC].
Interface MTU should be set to 0 in Database Description packets
sent over OSPF virtual links. This rule should not be applied to tunnel
or other software interfaces.


Notes
-
OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed and 
this provision makes sense. For interfaces that have an actual MTU, even though 
they may be "virtual" interfaces, they are not "virtual links" in the intended 
meaning of this paragraph. As such, this change will provide clarification and 
remove ambiguity from the current standard. At least one popular router vendor 
implements this RFC as MTU = 0 sent on all GRE interfaces which results in 
incompatibilities with most other router platforms which expect an actual 
value. The router vendor points to this provision in the RFCs as justification 
for their implementation. It is (arguably) a legitimate, if nonsensical 
interpretation of the existing text.

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.

--
RFC5343 (draft-ietf-opsawg-snmp-engineid-discovery-03)
--
Title   : Simple Network Management Protocol (SNMP) Context 
EngineID Discovery
Publication Date: September 2008
Author(s)   : J. Schoenwaelder
Category: PROPOSED STANDARD
Source  : Operations and Management Area Working Group
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG


--
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://constructor.university/>

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

Re: [OPSAWG] [Technical Errata Reported] RFC5343 (7645)

[Joe Clarke (jclarke)]

Typos with 5333 and 5343 

I would let the ADs reject this and you submit a new erratum.

Joe

From: Owen DeLong 
Date: Monday, September 18, 2023 at 11:48
To: Jürgen Schönwälder 
Cc: RFC Errata System , 
j.schoenwael...@jacobs-university.de , 
war...@kumari.net , Rob Wilton (rwilton) 
, henk.birkh...@sit.fraunhofer.de 
, Joe Clarke (jclarke) , 
zhoutian...@huawei.com , opsawg@ietf.org 

Subject: Re: [Technical Errata Reported] RFC5343 (7645)
Juergen is right. 5340 is the correct rfc and 5333 is a typo. Apologies.

Can the errata be reassigned or should I resubmit? What is the best process 
here?

Owen


> On Sep 18, 2023, at 00:42, Jürgen Schönwälder 
>  wrote:
>
> This erratum should be rejected since the text does not appear in RFC
> 5343. It seems the text is found in 5340, 'OSPF for IPv6', and this is
> a typo when the erratum was entered.
>
> /js
>
>> On Sun, Sep 17, 2023 at 10:49:29PM -0700, RFC Errata System wrote:
>> The following errata report has been submitted for RFC5343,
>> "Simple Network Management Protocol (SNMP) Context EngineID Discovery".
>>
>> --
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid7645
>>
>> --
>> Type: Technical
>> Reported by: Owen DeLong 
>>
>> Section: A.3.3
>>
>> Original Text
>> -
>> Section A.3.3 (in part) reads:
>>
>> Interface MTU
>>  The size in bytes of the largest IPv6 datagram that can be sent
>>  out the associated interface without fragmentation.  The MTUs of
>>  common Internet link types can be found in Table 7-1 of [MTUDISC].
>>  Interface MTU should be set to 0 in Database Description packets
>>  sent over virtual links.
>>
>>
>> Corrected Text
>> --
>> Interface MTU
>>  The size in bytes of the largest IPv6 datagram that can be sent
>>  out the associated interface without fragmentation.  The MTUs of
>>  common Internet link types can be found in Table 7-1 of [MTUDISC].
>>  Interface MTU should be set to 0 in Database Description packets
>>  sent over OSPF virtual links. This rule should not be applied to tunnel
>>  or other software interfaces.
>>
>>
>> Notes
>> -
>> OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed 
>> and this provision makes sense. For interfaces that have an actual MTU, even 
>> though they may be "virtual" interfaces, they are not "virtual links" in the 
>> intended meaning of this paragraph. As such, this change will provide 
>> clarification and remove ambiguity from the current standard. At least one 
>> popular router vendor implements this RFC as MTU = 0 sent on all GRE 
>> interfaces which results in incompatibilities with most other router 
>> platforms which expect an actual value. The router vendor points to this 
>> provision in the RFCs as justification for their implementation. It is 
>> (arguably) a legitimate, if nonsensical interpretation of the existing text.
>>
>> 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.
>>
>> --
>> RFC5343 (draft-ietf-opsawg-snmp-engineid-discovery-03)
>> --
>> Title   : Simple Network Management Protocol (SNMP) Context 
>> EngineID Discovery
>> Publication Date: September 2008
>> Author(s)   : J. Schoenwaelder
>> Category: PROPOSED STANDARD
>> Source  : Operations and Management Area Working Group
>> Area: Operations and Management
>> Stream  : IETF
>> Verifying Party : IESG
>
> --
> Jürgen Schönwälder  Constructor University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://constructor.university/>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Working group adoption call for draft-ma-opsawg-ucl-acl-03

[Joe Clarke (jclarke)]

As a contributor, I support adoption of this work.  I have previously read and 
commented on this document.  The main reason for my comment this time is to 
address something that was brought up at the mic in 117.  There was a question 
asked about needing deep packet inspection to effectively implement this.  
Quifang said yes, but I don't think it would be necessary.  If the controller 
maintained the state and knew who the user was through other means (e.g., 
AAA/dot1x), it could program the network elements with standard ACL tuple data 
(i.e., traditional ACLs) dynamically, thus not putting more logic onto the 
devices or into the hardware.  This was similar to a past comment of mine, and 
I think the document text addresses this.

It's not to say an implementor couldn't do something fancier within the 
network, but I don't think additional capabilities are required to make this 
work.

Joe

From: Tianran Zhou 
Sent: Monday, September 4, 2023 9:12 PM
To: opsawg@ietf.org 
Cc: opsawg-cha...@ietf.org 
Subject: Working group adoption call for draft-ma-opsawg-ucl-acl-03


Hi WG,



This mail starts a two weeks working group adoption call for 
draft-ma-opsawg-ucl-acl-03

https://datatracker.ietf.org/doc/draft-ma-opsawg-ucl-acl/



Please send over your objections or supports to the mailing list.

If you object the adoption, please also give the reason, so that the authors 
can improve.

We will conclude this adoption call on Sep 20, 2023.

All your comments are welcome.



Best,

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

Re: [OPSAWG] Looking for a shepherd for draft-ietf-opsawg-9092-update

[Joe Clarke (jclarke)]

Thanks, Warren.  As people have have seen if they stalk Data Tracker, mcr has 
graciously agreed to shepherd this document.  Thanks!

Joe

From: Warren Kumari 
Date: Monday, August 28, 2023 at 17:18
To: Joe Clarke (jclarke) 
Cc: opsawg@ietf.org 
Subject: Re: [OPSAWG] Looking for a shepherd for draft-ietf-opsawg-9092-update


On Fri, Aug 25, 2023 at 9:13 AM, Joe Clarke 
mailto:jclarke=40cisco@dmarc.ietf.org>> 
wrote:
With this work being adopted, the chairs would like to request someone to step 
forward to serve as shepherd when the document moves to LC.  There has been a 
recent discussion between all WG chairs that ideal shepherds are those that are 
not authors and have a vested interest in the work and can both defend it and 
help to keep it moving through the process.

Just as a quick followup to this:
Yes, it would be great if we can have volunteers from the WG serve as 
shepherds. It provides a whole bunch of benefits, including:
1: An additional set of (focused) eyes on the document.

2: It provides people with significant "behind the curtains" exposure - you get 
to see how the sausage is actually made

3: It provides a further backstop to confirm that the process was correctly 
followed (there does indeed seem to be consensus, the check and balances were 
all checked and balanced, etc).

4: It provides you with a taste of chairing, but with less work.

If you are even considering ever chairing a WG, you can get a good head start 
by shepherding a few documents — ADs are likely to be more supportive if you've 
already demonstrated skill and judgment by doing so.

W



Additionally, chairs are not ideal shepherds.

If you would like to raise your hand for this work, let us know.  Authors, if 
you know of someone that would be good give us the name or have them reach out.

Thanks.

Joe
___
OPSAWG mailing list
OPSAWG@ietf.org<mailto: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] [inventory-yang] poll for network inventory base model

[Joe Clarke (jclarke)]

Since you copied opsawg, I’ll make it clear my reply is as a contributor.  As I 
said at the first IVY meeting, I like the CCAMP work a bit more as a base 
inventory draft.  It feels more data-centric and less use-case centric if that 
makes sense.

That said, it’s adopted work in CCAMP.  What would happen to it?  Would it move 
to IVY?  Would IVY work just reference it as it progresses through CCAMP?

While I like option 1, I think perhaps option 3 might be more viable, but using 
the model of the CCAMP work where it leverages previous ENTITY-MIB concepts 
while staying true to common inventory.

Joe

From: Inventory-yang  on behalf of maqiufang 
(A) 
Date: Monday, August 28, 2023 at 02:22
To: inventory-y...@ietf.org 
Cc: ivy-cha...@ietf.org , opsawg , 
cc...@ietf.org 
Subject: [Inventory-yang] [inventory-yang] poll for network inventory base model
Hi Working Group,

It’s now time to start considering how to move forward with the inventory base 
model. We have two different documents that could be used as a starting point 
for our work or, in case the working group believes none of them is “good 
enough”, we can start a brand new ID.
In case the latter option is chosen, Daniele and I will write a -00 version 
including just the table of content and what we’d like to be covered in each 
section. The document will then be handed over to a pool of authors which will 
bring it till the WG adoption.

Hence, we will have a 3 weeks polling starting today. We decided to make it a 
bit longer than usual because this time the working group is requested to 
review two drafts instead of one.

This mail starts a 3 weeks polling, terminating on September 15th,  where we 
would like the working group to express your preference among:

1.   Adopt  draft-ietf-ccamp-network-inventory-yang-02 in IVY and evolve it 
to become the network inventory base model
2.   Adopt draft-wzwb-opsawg-network-inventory-management-03 in IVY and 
evolve it to become the network inventory base model
3.   Start a brand new document from scratch as described above

In the week after the closure of the polling (between September 18 and 25) we 
will have an IVY interim meeting to discuss the issues/concerns raised during 
the polling ( A separate mail will be sent).

Thank you,

Qiufang and Daniele

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

[OPSAWG] Looking for a shepherd for draft-ietf-opsawg-9092-update

[Joe Clarke (jclarke)]

With this work being adopted, the chairs would like to request someone to step 
forward to serve as shepherd when the document moves to LC.  There has been a 
recent discussion between all WG chairs that ideal shepherds are those that are 
not authors and have a vested interest in the work and can both defend it and 
help to keep it moving through the process.  Additionally, chairs are not ideal 
shepherds.

If you would like to raise your hand for this work, let us know.  Authors, if 
you know of someone that would be good give us the name or have them reach out.

Thanks.

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

Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update

[Joe Clarke (jclarke)]

The CfA on this document has concluded.  The comments received were supportive 
of the work, and the chairs feel the implementation thus far shows value in 
continuing its evolution.  We hope this can proceed quickly.

Authors, please resubmit this draft as draft-ietf-opsawg-9092-update-00 
replacing draft-ymbk-opsawg-9092-update.  Do not make any other changes to the 
document text.

Thanks.

Joe

From: Joe Clarke (jclarke) 
Date: Monday, August 7, 2023 at 15:46
To: opsawg@ietf.org 
Subject: CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
Coming out of 117, there was an action to put the 9092bis document up for WG 
adoption.  The authors have all responded that there is no known IPR pertaining 
to this document.  This document is an update to the guidelines for finding and 
using geofeed data.

Therefore, we would like to start a two week CfA for 
https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/.  Please reply 
on-list with your comments and whether or not you support working on this 
document.  The CfA will run until EOD on August 21, 2023.

Thanks.

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

Re: [OPSAWG] RFC 9445 on RADIUS Extensions for DHCP-Configured Services

[Joe Clarke (jclarke)]

Well done, authors and WG contributors!  Thank you to Bernie for shepherding 
this.

Joe

From: OPSAWG  on behalf of rfc-edi...@rfc-editor.org 

Date: Wednesday, August 16, 2023 at 17:40
To: ietf-annou...@ietf.org , rfc-d...@rfc-editor.org 

Cc: rfc-edi...@rfc-editor.org , 
drafts-update-...@iana.org , opsawg@ietf.org 

Subject: [OPSAWG] RFC 9445 on RADIUS Extensions for DHCP-Configured Services
A new Request for Comments is now available in online RFC libraries.


RFC 9445

Title:  RADIUS Extensions for DHCP-Configured Services
Author: M. Boucadair,
T. Reddy.K,
A. DeKok
Status: Standards Track
Stream: IETF
Date:   August 2023
Mailbox:mohamed.boucad...@orange.com,
kond...@gmail.com,
al...@freeradius.org
Pages:  18
Updates:RFC 4014

I-D Tag:draft-ietf-opsawg-add-encrypted-dns-12.txt

URL:https://www.rfc-editor.org/info/rfc9445

DOI:10.17487/RFC9445

This document specifies two new Remote Authentication Dial-In User
Service (RADIUS) attributes that carry DHCP options. The
specification is generic and can be applicable to any service that
relies upon DHCP. Both DHCPv4- and DHCPv6-configured services are
covered.

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

This document is a product of the Operations and Management Area Working Group 
Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
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] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update

[Joe Clarke (jclarke)]

Speaking as a contributor and one who reviewed both the current draft as well 
as the previous, I support the adoption of this, and I appreciate the 
modifications to the implementation status section, as well as the clarity 
around when to use the geofeed: and remarks: attributes.  I do wonder if the 
new text pertaining to geofeed files only being CSV (Section 2) could be 
simplified with normative language:

Per [RFC8805], geofeed files MUST only consist of CSVs in UTF-8 text format.

Joe

From: OPSAWG  on behalf of Joe Clarke (jclarke) 

Date: Monday, August 7, 2023 at 15:47
To: opsawg@ietf.org 
Subject: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
Coming out of 117, there was an action to put the 9092bis document up for WG 
adoption.  The authors have all responded that there is no known IPR pertaining 
to this document.  This document is an update to the guidelines for finding and 
using geofeed data.

Therefore, we would like to start a two week CfA for 
https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/.  Please reply 
on-list with your comments and whether or not you support working on this 
document.  The CfA will run until EOD on August 21, 2023.

Thanks.

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

[OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update

[Joe Clarke (jclarke)]

Coming out of 117, there was an action to put the 9092bis document up for WG 
adoption.  The authors have all responded that there is no known IPR pertaining 
to this document.  This document is an update to the guidelines for finding and 
using geofeed data.

Therefore, we would like to start a two week CfA for 
https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/.  Please reply 
on-list with your comments and whether or not you support working on this 
document.  The CfA will run until EOD on August 21, 2023.

Thanks.

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

[OPSAWG] POLL FOR IPR: draft-ymbk-opsawg-9092-update

[Joe Clarke (jclarke)]

Ahead of a call for WG adoption of draft-ymbk-opsawg-9092-update, we’d like to 
poll for known IPR.

Authors and contributors on the To: line, 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

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

[OPSAWG] IETF 117 Minutes

[Joe Clarke (jclarke)]

Thanks again to our excellent minutes taker, Rob Wilton.  I have imported the 
minutes from HedgeDoc into Datatracker.  Coming out of 117, I want to once 
again apologize to the two sessions for which there wasn’t time (we will 
prioritize for 118) as well as Alex, who was cut short at the end.

A reminder to the WG that Rob is stepping down as Area Director this spring.  
Anyone interested in running for Ops Area director (on the management side) 
should reach out to him.

Once again, we have a few action items from the meeting.  One of which was to 
acknowledge the Liaison Statement from ORAN (which has now been done).  The 
others are:


  *   Call for adoption for policy-based ACL, attachment circuits, and the 
geofeed bis
  *   Alex is going to try and generate some more “green” discussion on opsawg@
  *   We’d like more reviews of draft-ietf-opsawg-tacacs-tls13 to close on the 
questions of dedicated port and obfuscation in the tunnel

Let me know if I missed anything or if any clarification is needed in minutes.

https://datatracker.ietf.org/doc/minutes-117-opsawg-202307262000/

Joe


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

Re: [OPSAWG] New Liaison Statement, "LS on O-RAN Transport Network Slicing Enhancement"

[Joe Clarke (jclarke)]

On behalf of OPSAWG, thank  you for your interest in the attachment circuits 
work and for reaching out with this liaison statement.  We just concluded the 
OPSAWG session at IETF 117 where the AC work was presented.

We conducted a poll at the meeting for interest in adoption.  Given that there 
was interest from those in attendance, we will be conducting an adoption poll 
on our mailing list.

Joe

From: Liaison Statement Management Tool 
Date: Friday, April 21, 2023 at 10:33
To: Henk Birkholz , Joe Clarke (jclarke) 
, Lou Berger , Tianran Zhou 
, Vishnu Beeram 
Cc: Andrew Alston , Henk Birkholz 
, Jim Guichard 
, Joe Clarke (jclarke) , 
John Scudder , Lou Berger , Operations and 
Management Area Working Group Discussion List , Oscar de Dios 
, Richard Roberts , 
Rob Wilton (rwilton) , Tianran Zhou 
, Traffic Engineering Architecture and Signaling 
Discussion List , Vishnu Beeram , Warren 
Kumari , liaison-coordinat...@iab.org 
, liais...@o-ran.org 
Subject: New Liaison Statement, "LS on O-RAN Transport Network Slicing 
Enhancement"
Title: LS on O-RAN Transport Network Slicing Enhancement
Submission Date: 2023-04-21
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1829/

From: Richard Roberts 
To: Vishnu Beeram ,Lou Berger ,Henk 
Birkholz ,Joe Clarke 
,Tianran Zhou 
Cc: Warren Kumari ,Henk Birkholz 
,Tianran Zhou ,Andrew 
Alston ,Jim Guichard 
,Operations and Management Area Working Group 
Discussion List ,Richard Roberts ,Oscar 
de Dios ,Robert Wilton 
,Lou Berger ,Joe Clarke 
,Traffic Engineering Architecture and Signaling Discussion 
List ,Vishnu Beeram ,John Scudder 

Response Contacts: liais...@o-ran.org
Technical Contacts:
Purpose: For information

Body:
Attachments:

O-RAN-WG9-LS-2023-003-IETF on Transport Network Slicing Enhancement

https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2023-04-21-o-ran-wg9-opsawg-teas-ls-on-o-ran-transport-network-slicing-enhancement-attachment-1.docx

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

Re: [OPSAWG] draft-ymbk-opsawg-9092-update-01

[Joe Clarke (jclarke)]

Absent implementation of the geofeed: attribute in a particular IRR
database

if so, it was intentional.  perhaps s/IRR/Whois/?

JMC: Yep.  I see what you’re saying now.  I was reading as RIR.  I think IRR is 
fine, but perhaps it should be expanded like you do RIR earlier.


> My biggest gripe in the diff is that your “Implementation Status”
> section has normative language, which seemed odd to me.

that MAY is from 9092.  but i take your point and downcased it.

JMC: Thanks.  There are two MUSTs there, too around how to interpret ARIN data. 
 This may just be me, but I wasn’t expecting any other instruction of how to 
interpret the data in a status section.  But the more I read this bit on ARIN, 
I’m torn.  I definitely follow what you’re getting at here.  Maybe I’ll reserve 
more thoughts until your next rev.

Joe

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

Re: [OPSAWG] draft-ymbk-opsawg-9092-update-01

[Joe Clarke (jclarke)]

I’ve read the original draft and the diff mentioned below.  Thanks for fixing 
the “until such time” thing as that read strangely to me.

I think you’ve misspelled RIR as IRR in the diff.

I appreciate this work progressing and the revisiting of the recommendations 
based on actual implementation.

My biggest gripe in the diff is that your “Implementation Status” section has 
normative language, which seemed odd to me.  I would think as a “status” it 
would merely describe what has been done.  I would think the normative language 
would be in Operational Considerations, personally.

Joe

From: OPSAWG  on behalf of Randy Bush 
Date: Tuesday, July 4, 2023 at 14:37
To: mohamed.boucad...@orange.com 
Cc: Ops Area WG , draft-ymbk-opsawg-9092-upd...@ietf.org 

Subject: Re: [OPSAWG] draft-ymbk-opsawg-9092-update-01
hi med,

>>> (4) Note sure we can mandate by spec how the data can be
>>> "consumed". I'm afraid the NEW sentence in the Sec Cons>> isn't
>>> useful. I would at least avoid the use of normative language
>>> there.
>>
>> you mean
>>
>> The consumer of geofeed data SHOULD fetch and process the data
>> themselves.  Importing datasets produced and/or processed by a
>> third-party places ill-advised trust in the third-party.
>>
>> are you saying this is not a security consideration, with which i
>> am inclined to disagree?  it's an attack vector; i could
>> indirectly cause you not to get your MTV.  or you just don't like
>> the SHOULD?
>
> [Med] The point here is that the NEW SHOULD is too specific about how
> a consumer access the content, while it does not guarantee that the
> data is not altered (absent integrity/verification checks). Also, it
> is OK to access the data via trusted parties that extract and present
> the data with all due checks/verification in place.
>
> BTW, please note that you already have:
>
>All the security
>considerations of [RFC8805] apply here as well.
>
> And RFC8805 says the following:
>
>For consumers, feed retrieval processes may receive input from
>potentially hostile sources (e.g., in the event of hijacked traffic).
>As such, proper input validation and defense measures MUST be taken
>(see the discussion in Section 3.1).

i am still waiting to hear from co-authors.  but ...

i think this is trying to address an actual current problem.  folk are
alleging to provide aggregated data with no formal statement of the
methods to ensure provenance, integrity, or authenticity of those data.

so i am gonna stall on this one.

>>> (3) Section 3
>>>
>>> CURRENT:
>>>   "Currently, this has been..."
>>>
>>> It is good to report what is implemented, but I don't think we need
>>> to have them frozen in the spec. Please see RFC7942.
>>
>> easy for me to hack, but i would like to hear from co-authors
>> before doing so.  some motivation for this update is the socio-
>> politics of the RIRs and getting them to move forward.
>>
>> or are you perhaps suggesting an Implementation Status Section per
>> 7942?
>
> [Med] Yes.

ok.  done.  it is not always easy to pick what to move.  so further
discussion solicited.

> [Med] https://author-tools.ietf.org/iddiff

thanks!  i am a poor ietf tools archaeologist.  unfortunately, i am old
enough to not like massive bits in an email.  so i have stashed a
proposed diff at https://archive.psg.com/draft-ymbk-9092update.diff.html

thanks again for spending time on this.  much appreciated.

randy

___
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] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt

[Joe Clarke (jclarke)]

Fair point.  I was agreeing to the dedicated port for tacacss.  That said, I do 
believe tacacss meets the secure requirement set forth in 7605 with respect to 
creating a new, secure service that replicates and insecure service in a 
non-backwards compatible way.

That part of Section 7.1 should be cited as a justification for the assignment.

Joe

From: mohamed.boucad...@orange.com 
Date: Wednesday, July 5, 2023 at 11:04
To: Joe Clarke (jclarke) , opsawg@ietf.org 
Subject: RE: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt
Hi Joe, all,

On the port number point, I’m afraid that the arguments in Section 8 are more 
for justifying why distinct port numbers might be useful, not why a well-known 
port number has to be assigned. I would suggest to strengthen that part before 
making the request (see more in rfc6335#section-7.2 and also rfc7605#section-7).
Cheers,
Med

De : OPSAWG  De la part de Joe Clarke (jclarke)
Envoyé : mercredi 5 juillet 2023 16:42
À : opsawg@ietf.org
Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt

Thanks for the update on this document.  I’ve reviewed this new version in its 
entirety.  To summarize:


· TACACS+ TLS will use a dedicated “tacacss” TCP port number

· Obfuscation is prohibited by TACACS+ TLS compliant clients/servers 
(within the tunnel)

These were two issues I believe were discussion points in the WG.  As a 
contributor, I am convinced that both make sense for the reasons put forth in 
the draft.  Hopefully during the migration process, implementors won’t forget 
the obfuscation on non-TLS sessions.

I like the migration section, but I am curious why, after migration, one would 
need any legacy servers at all (regardless of server lists).  I can see having 
my “DEVICE_ADMIN” T+ list having both TLS servers first followed by legacy 
servers while I sus out the stability of the new implementation.  But when I’m 
satisfied, I likely would remove the legacy servers altogether.  Moreover, at 
least with Cisco config, I assume I’d have each server defined with various TLS 
attributes and it wouldn’t matter what list they are in.

I guess what I’m suggesting is dropping the second paragraph in Section 6.2 and 
saying something to the effect of, when migration from legacy, obfuscated T+ to 
T+ TLS, insecure and secure servers MAY be mixed in redundant service lists.  
However, secure servers SHOULD be tried first before falling back to insecure 
servers.

As a nit, Indication is misspelled in Section 3.3.

As co-chair:


· WG, please review this draft!

· Authors, any thoughts to what port number to use for tacacss or 
whatever IANA can assign?  I’d like to see a few more reviews before pinging 
the ADs on early allocation.

· Are there any implementations of this thus far?  If so having an 
Appendix for them would help.

Joe

From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Date: Thursday, June 29, 2023 at 10:55
To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> 
mailto:i-d-annou...@ietf.org>>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-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   : TACACS+ TLS 1.3
   Authors : Thorsten Dahm
 Douglas Gash
 Andrej Ota
 John Heasley
   Filename: draft-ietf-opsawg-tacacs-tls13-03.txt
   Pages   : 12
   Date: 2023-06-29

Abstract:
   The TACACS+ Protocol [RFC8907] provides device administration for
   routers, network access servers and other networked computing devices
   via one or more centralized servers.  This document, a companion to
   the TACACS+ protocol [RFC8907], adds Transport Layer Security
   (currently defined by TLS 1.3 [RFC8446]) support and obsoletes former
   inferior security mechanisms.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-03.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tacacs-tls13-03

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


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



Ce message et ses pieces jointes peuvent contenir des inf

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt

[Joe Clarke (jclarke)]

Thanks for the update on this document.  I’ve reviewed this new version in its 
entirety.  To summarize:


  *   TACACS+ TLS will use a dedicated “tacacss” TCP port number
  *   Obfuscation is prohibited by TACACS+ TLS compliant clients/servers 
(within the tunnel)

These were two issues I believe were discussion points in the WG.  As a 
contributor, I am convinced that both make sense for the reasons put forth in 
the draft.  Hopefully during the migration process, implementors won’t forget 
the obfuscation on non-TLS sessions.

I like the migration section, but I am curious why, after migration, one would 
need any legacy servers at all (regardless of server lists).  I can see having 
my “DEVICE_ADMIN” T+ list having both TLS servers first followed by legacy 
servers while I sus out the stability of the new implementation.  But when I’m 
satisfied, I likely would remove the legacy servers altogether.  Moreover, at 
least with Cisco config, I assume I’d have each server defined with various TLS 
attributes and it wouldn’t matter what list they are in.

I guess what I’m suggesting is dropping the second paragraph in Section 6.2 and 
saying something to the effect of, when migration from legacy, obfuscated T+ to 
T+ TLS, insecure and secure servers MAY be mixed in redundant service lists.  
However, secure servers SHOULD be tried first before falling back to insecure 
servers.

As a nit, Indication is misspelled in Section 3.3.

As co-chair:


  *   WG, please review this draft!
  *   Authors, any thoughts to what port number to use for tacacss or whatever 
IANA can assign?  I’d like to see a few more reviews before pinging the ADs on 
early allocation.
  *   Are there any implementations of this thus far?  If so having an Appendix 
for them would help.

Joe

From: OPSAWG  on behalf of internet-dra...@ietf.org 

Date: Thursday, June 29, 2023 at 10:55
To: i-d-annou...@ietf.org 
Cc: opsawg@ietf.org 
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-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   : TACACS+ TLS 1.3
   Authors : Thorsten Dahm
 Douglas Gash
 Andrej Ota
 John Heasley
   Filename: draft-ietf-opsawg-tacacs-tls13-03.txt
   Pages   : 12
   Date: 2023-06-29

Abstract:
   The TACACS+ Protocol [RFC8907] provides device administration for
   routers, network access servers and other networked computing devices
   via one or more centralized servers.  This document, a companion to
   the TACACS+ protocol [RFC8907], adds Transport Layer Security
   (currently defined by TLS 1.3 [RFC8446]) support and obsoletes former
   inferior security mechanisms.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-03.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tacacs-tls13-03

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

Re: [OPSAWG] RFC 9408 on A YANG Network Data Model for Service Attachment Points (SAPs)

[Joe Clarke (jclarke)]

Indeed!  Lots of back and forth on the administrivia side at the end, and the 
authors were prompt to respond and work with ADs and RFC-EDITOR.  Nice work, 
all.

Joe

From: OPSAWG  on behalf of Tianran Zhou 

Date: Wednesday, June 21, 2023 at 02:19
To: opsawg@ietf.org 
Subject: Re: [OPSAWG] RFC 9408 on A YANG Network Data Model for Service 
Attachment Points (SAPs)

Congratulations to the authors and contributors!

Cheers,
Tianran

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of 
rfc-edi...@rfc-editor.org
Sent: Wednesday, June 21, 2023 1:28 PM
To: ietf-annou...@ietf.org; rfc-d...@rfc-editor.org
Cc: rfc-edi...@rfc-editor.org; drafts-update-...@iana.org; opsawg@ietf.org
Subject: [OPSAWG] RFC 9408 on A YANG Network Data Model for Service Attachment 
Points (SAPs)

A new Request for Comments is now available in online RFC libraries.


RFC 9408

Title:  A YANG Network Data Model
for Service Attachment Points (SAPs)
Author: M. Boucadair, Ed.,
O. Gonzalez de Dios,
S. Barguil,
Q. Wu,
V. Lopez
Status: Standards Track
Stream: IETF
Date:   June 2023
Mailbox:mohamed.boucad...@orange.com,
oscar.gonzalezded...@telefonica.com,
samier.barguil_gira...@nokia.com,
bill...@huawei.com,
victor.lo...@nokia.com
Pages:  37
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-opsawg-sap-15.txt

URL:https://www.rfc-editor.org/info/rfc9408

DOI:10.17487/RFC9408

This document defines a YANG data model for representing an abstract view of 
the provider network topology that contains the points from which its services 
can be attached (e.g., basic connectivity, VPN, network slices). Also, the 
model can be used to retrieve the points where the services are actually being 
delivered to customers (including peer networks).

This document augments the 'ietf-network' data model defined in RFC
8345 by adding the concept of Service Attachment Points (SAPs). The SAPs are 
the network reference points to which network services, such as Layer 3 Virtual 
Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be 
attached. One or multiple services can be bound to the same SAP. Both 
User-to-Network Interface (UNI) and Network-to-Network Interface (NNI) are 
supported in the SAP data model.

This document is a product of the Operations and Management Area Working Group 
Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track protocol 
for the Internet community, and requests discussion and suggestions for 
improvements.  Please refer to the current edition of the Official Internet 
Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this memo 
is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search For 
downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the author of 
the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless specifically 
noted otherwise on the RFC itself, all RFCs are for unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
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] ADOPTION POLL: A Data Manifest for Contextualized Telemetry Data

[Joe Clarke (jclarke)]

I’m closing this CfA out.  Support on-list has been positive for this work, and 
we will adopt it.  Authors have replied that there is no known IPR.

Authors, please resubmit this draft as 
draft-ietf-opsawg-collected-data-manifest-00 replacing 
draft-claise-opsawg-collected-data-manifest.  DO NOT make any other changes.

Joe

From: Joe Clarke (jclarke) 
Date: Monday, May 1, 2023 at 18:17
To: opsawg@ietf.org 
Subject: ADOPTION POLL: A Data Manifest for Contextualized Telemetry Data
This work has been presented a few times now, and has had some on-list as well 
as at-mic discussion.  Coming out of 116, we said we’d bring the question of 
adoption to the list (minutes have been updated to reflect the conversation at 
the mic).

As such, we are holding a three-ish-week call for adoption for 
https://datatracker.ietf.org/doc/draft-claise-opsawg-collected-data-manifest/.  
Please reply with support, dissent, comments, etc. to the list.  The CfA will 
end on May 25, 2023.  I’m doing this as I will be out of the office, and I can 
conclude it on May 25th.  It also gives people a bit more time to digest the 
work and provide substantive comments.

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

[OPSAWG] IPR Poll: draft-ietf-opsawg-rfc7125-update

[Joe Clarke (jclarke)]

Hello, Brian and Paul.  As authors of RFC7125 and named contributors on 
draft-ietf-opsawg-rfc7125-update (the bis document), I wanted to specifically 
poll to see if you know of any IPR associated with this new 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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG LC: draft-ietf-opsawg-rfc7125-update

[Joe Clarke (jclarke)]

Yeah, the normative language in 7125 confused me.  It seemed like it should 
have been Standard, but given it was ratified as Info, I wanted to raise the 
point for consistency.

Thanks for the additional context.

Joe

From: mohamed.boucad...@orange.com 
Date: Tuesday, May 9, 2023 at 10:16
To: Joe Clarke (jclarke) , opsawg@ietf.org 
Subject: RE: WG LC: draft-ietf-opsawg-rfc7125-update
Re-,

FWIW, std vs. info was raised at least twice:


· Please look at “Which stream” in Slide 5 of 
https://datatracker.ietf.org/meeting/115/materials/slides-115-opsawg-an-update-to-the-tcpcontrolbits-ip-flow-information-export-ipfix-information-element-00

· 
https://mailarchive.ietf.org/arch/msg/opsawg/xiNdPUoDVFhNfOCKSDFWEJbwzdA/

Please note that the initial RFC that defined IE#6 was published in the 
Standard Track (https://www.rfc-editor.org/rfc/rfc5102.html).

Unless I’m mistaken, the reasoning that was given at the time for publishing 
7125 as informational is that it modifies a registry with a expert review 
policy. I’m afraid that justification is weak, especially given that the 
document includes normative behavior.

I suggest we leave the track as currently in the document. Thanks.

Cheers,
Med

De : Joe Clarke (jclarke) 
Envoyé : mardi 9 mai 2023 15:47
À : BOUCADAIR Mohamed INNOV/NET ; opsawg@ietf.org
Objet : Re: WG LC: draft-ietf-opsawg-rfc7125-update

I agree that if the intent is to use that registry as the canonical reference, 
then a normative reference makes sense.  RFC7125 leaned on TCP only, but then 
changes to the registry were not assumed.

Another point, I don’t recall seeing any discussion on why this document is a 
proposed standard whereas 7125 is informational.  As I go through the shepherd 
task list, I noticed this and as I consider both texts, I do think 
Informational might be more accurate for this bis, too.

Joe

From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
mailto:mohamed.boucad...@orange.com>>
Date: Tuesday, May 9, 2023 at 02:42
To: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>, 
opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Subject: RE: WG LC: draft-ietf-opsawg-rfc7125-update
Hi Joe,

TCP-FLAGS is listed as normative as this is the authoritative reference for 
interpreting the flags by the collector, not RFC9293. I agree that RFC9293 
would be sufficient for the exporter though.

Cheers,
Med

De : OPSAWG mailto:opsawg-boun...@ietf.org>> De la 
part de Joe Clarke (jclarke)
Envoyé : lundi 8 mai 2023 19:08
À : Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 opsawg@ietf.org<mailto:opsawg@ietf.org>
Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg-rfc7125-update

I am working on the shepherd write-up for this document and saw that Paul and 
Brian were not included in the IPR poll (and they are named contributors).  
I’ve sent them an email, but it seems Brian’s email has changed since 7125.  
Does anyone have his current email?

I have reviewed the document (-03) and the IDNITS.  The document text looks 
okay.  Most of the IDNITS are false positives (Benoît, when is your name going 
to comply to ASCII  ?).  Does the TCP-FLAGS registry need to be normative for 
this document?  Should this be informative since 9293 is already normative?

Joe

From: Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>
Date: Tuesday, May 2, 2023 at 18:49
To: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>, 
opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Subject: Re: WG LC: draft-ietf-opsawg-rfc7125-update
I have concluded the WG LC for this document.  We got two directorate reviews 
in, and it sounds like the authors will make one more revision.

While I was hoping we’d get a shepherd volunteer, I didn’t hear from anyone.  I 
will shepherd this document and try to have the write-up done by middle of next 
week.

Joe

From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>
Date: Tuesday, April 25, 2023 at 18:13
To: opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Subject: Re: [OPSAWG] WG LC: draft-ietf-opsawg-rfc7125-update
Again, sorry for the delay.  I’m just back to the office, and I’m catching up 
on things.  I’ve pushed for some other directorate reviews, but given that we 
want to progress this document, I’m happy to work in parallel with those.

I didn’t get any offers to shepherd, though.  I’ll ask once more to see if 
anyone in the WG is interested?  This is a good, short draft to cut one’s teeth 
on…

Joe

From: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>
Date: Tuesday, April 4, 2023 at 16:01
To: opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Subject: WG LC: draft-ietf-opsawg-rfc7125-update
Hello, WG.  I hope everyone that traveled for 116 is back home and healthy.

O

Re: [OPSAWG] WG LC: draft-ietf-opsawg-rfc7125-update

[Joe Clarke (jclarke)]

I agree that if the intent is to use that registry as the canonical reference, 
then a normative reference makes sense.  RFC7125 leaned on TCP only, but then 
changes to the registry were not assumed.

Another point, I don’t recall seeing any discussion on why this document is a 
proposed standard whereas 7125 is informational.  As I go through the shepherd 
task list, I noticed this and as I consider both texts, I do think 
Informational might be more accurate for this bis, too.

Joe

From: mohamed.boucad...@orange.com 
Date: Tuesday, May 9, 2023 at 02:42
To: Joe Clarke (jclarke) , opsawg@ietf.org 
Subject: RE: WG LC: draft-ietf-opsawg-rfc7125-update
Hi Joe,

TCP-FLAGS is listed as normative as this is the authoritative reference for 
interpreting the flags by the collector, not RFC9293. I agree that RFC9293 
would be sufficient for the exporter though.

Cheers,
Med

De : OPSAWG  De la part de Joe Clarke (jclarke)
Envoyé : lundi 8 mai 2023 19:08
À : Joe Clarke (jclarke) ; opsawg@ietf.org
Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg-rfc7125-update

I am working on the shepherd write-up for this document and saw that Paul and 
Brian were not included in the IPR poll (and they are named contributors).  
I’ve sent them an email, but it seems Brian’s email has changed since 7125.  
Does anyone have his current email?

I have reviewed the document (-03) and the IDNITS.  The document text looks 
okay.  Most of the IDNITS are false positives (Benoît, when is your name going 
to comply to ASCII  ?).  Does the TCP-FLAGS registry need to be normative for 
this document?  Should this be informative since 9293 is already normative?

Joe

From: Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>
Date: Tuesday, May 2, 2023 at 18:49
To: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>, 
opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Subject: Re: WG LC: draft-ietf-opsawg-rfc7125-update
I have concluded the WG LC for this document.  We got two directorate reviews 
in, and it sounds like the authors will make one more revision.

While I was hoping we’d get a shepherd volunteer, I didn’t hear from anyone.  I 
will shepherd this document and try to have the write-up done by middle of next 
week.

Joe

From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>
Date: Tuesday, April 25, 2023 at 18:13
To: opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Subject: Re: [OPSAWG] WG LC: draft-ietf-opsawg-rfc7125-update
Again, sorry for the delay.  I’m just back to the office, and I’m catching up 
on things.  I’ve pushed for some other directorate reviews, but given that we 
want to progress this document, I’m happy to work in parallel with those.

I didn’t get any offers to shepherd, though.  I’ll ask once more to see if 
anyone in the WG is interested?  This is a good, short draft to cut one’s teeth 
on…

Joe

From: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>
Date: Tuesday, April 4, 2023 at 16:01
To: opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Subject: WG LC: draft-ietf-opsawg-rfc7125-update
Hello, WG.  I hope everyone that traveled for 116 is back home and healthy.

One of the items that came out of the 116 meeting was that this document is in 
decent shape for a WGLC.  We wanted to move these IPFIX maintenance documents 
through the process rather quickly.

One of the open questions Med asked of the WG (and chairs) is should this be a 
bis.  As a chair, I think a bis is cleaner here, but I would like to hear from 
the WG during this LC if that makes sense.

We will run a two week WG LC ending on April 18, 2023.  Please provide your 
comments on list.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc7125-update/

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] WG LC: draft-ietf-opsawg-rfc7125-update

[Joe Clarke (jclarke)]

I am working on the shepherd write-up for this document and saw that Paul and 
Brian were not included in the IPR poll (and they are named contributors).  
I’ve sent them an email, but it seems Brian’s email has changed since 7125.  
Does anyone have his current email?

I have reviewed the document (-03) and the IDNITS.  The document text looks 
okay.  Most of the IDNITS are false positives (Benoît, when is your name going 
to comply to ASCII  ?).  Does the TCP-FLAGS registry need to be normative for 
this document?  Should this be informative since 9293 is already normative?

Joe

From: Joe Clarke (jclarke) 
Date: Tuesday, May 2, 2023 at 18:49
To: Joe Clarke (jclarke) , opsawg@ietf.org 
Subject: Re: WG LC: draft-ietf-opsawg-rfc7125-update
I have concluded the WG LC for this document.  We got two directorate reviews 
in, and it sounds like the authors will make one more revision.

While I was hoping we’d get a shepherd volunteer, I didn’t hear from anyone.  I 
will shepherd this document and try to have the write-up done by middle of next 
week.

Joe

From: OPSAWG  on behalf of Joe Clarke (jclarke) 

Date: Tuesday, April 25, 2023 at 18:13
To: opsawg@ietf.org 
Subject: Re: [OPSAWG] WG LC: draft-ietf-opsawg-rfc7125-update
Again, sorry for the delay.  I’m just back to the office, and I’m catching up 
on things.  I’ve pushed for some other directorate reviews, but given that we 
want to progress this document, I’m happy to work in parallel with those.

I didn’t get any offers to shepherd, though.  I’ll ask once more to see if 
anyone in the WG is interested?  This is a good, short draft to cut one’s teeth 
on…

Joe

From: Joe Clarke (jclarke) 
Date: Tuesday, April 4, 2023 at 16:01
To: opsawg@ietf.org 
Subject: WG LC: draft-ietf-opsawg-rfc7125-update
Hello, WG.  I hope everyone that traveled for 116 is back home and healthy.

One of the items that came out of the 116 meeting was that this document is in 
decent shape for a WGLC.  We wanted to move these IPFIX maintenance documents 
through the process rather quickly.

One of the open questions Med asked of the WG (and chairs) is should this be a 
bis.  As a chair, I think a bis is cleaner here, but I would like to hear from 
the WG during this LC if that makes sense.

We will run a two week WG LC ending on April 18, 2023.  Please provide your 
comments on list.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc7125-update/

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

[OPSAWG] IPR Poll: draft-ietf-opsawg-rfc7125-update

[Joe Clarke (jclarke)]

Hello, Brian and Paul.  As authors of RFC7125 and named contributors on 
draft-ietf-opsawg-rfc7125-update (the bis document), I wanted to specifically 
poll to see if you know of any IPR associated with this new 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

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

Re: [OPSAWG] WG LC: draft-ietf-opsawg-rfc7125-update

[Joe Clarke (jclarke)]

I have concluded the WG LC for this document.  We got two directorate reviews 
in, and it sounds like the authors will make one more revision.

While I was hoping we’d get a shepherd volunteer, I didn’t hear from anyone.  I 
will shepherd this document and try to have the write-up done by middle of next 
week.

Joe

From: OPSAWG  on behalf of Joe Clarke (jclarke) 

Date: Tuesday, April 25, 2023 at 18:13
To: opsawg@ietf.org 
Subject: Re: [OPSAWG] WG LC: draft-ietf-opsawg-rfc7125-update
Again, sorry for the delay.  I’m just back to the office, and I’m catching up 
on things.  I’ve pushed for some other directorate reviews, but given that we 
want to progress this document, I’m happy to work in parallel with those.

I didn’t get any offers to shepherd, though.  I’ll ask once more to see if 
anyone in the WG is interested?  This is a good, short draft to cut one’s teeth 
on…

Joe

From: Joe Clarke (jclarke) 
Date: Tuesday, April 4, 2023 at 16:01
To: opsawg@ietf.org 
Subject: WG LC: draft-ietf-opsawg-rfc7125-update
Hello, WG.  I hope everyone that traveled for 116 is back home and healthy.

One of the items that came out of the 116 meeting was that this document is in 
decent shape for a WGLC.  We wanted to move these IPFIX maintenance documents 
through the process rather quickly.

One of the open questions Med asked of the WG (and chairs) is should this be a 
bis.  As a chair, I think a bis is cleaner here, but I would like to hear from 
the WG during this LC if that makes sense.

We will run a two week WG LC ending on April 18, 2023.  Please provide your 
comments on list.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc7125-update/

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

Re: [OPSAWG] ADOPTION POLL: A Data Manifest for Contextualized Telemetry Data

[Joe Clarke (jclarke)]

FYI, all authors/contributors have replied that they know of no IPR relevant to 
this document.

Joe

From: Joe Clarke (jclarke) 
Date: Monday, May 1, 2023 at 18:17
To: opsawg@ietf.org 
Subject: ADOPTION POLL: A Data Manifest for Contextualized Telemetry Data
This work has been presented a few times now, and has had some on-list as well 
as at-mic discussion.  Coming out of 116, we said we’d bring the question of 
adoption to the list (minutes have been updated to reflect the conversation at 
the mic).

As such, we are holding a three-ish-week call for adoption for 
https://datatracker.ietf.org/doc/draft-claise-opsawg-collected-data-manifest/.  
Please reply with support, dissent, comments, etc. to the list.  The CfA will 
end on May 25, 2023.  I’m doing this as I will be out of the office, and I can 
conclude it on May 25th.  It also gives people a bit more time to digest the 
work and provide substantive comments.

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

[OPSAWG] POLL FOR IPR: A Data Manifest for Contextualized Telemetry Data

[Joe Clarke (jclarke)]

Authors and contributors on the To: line, 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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] ADOPTION POLL: A Data Manifest for Contextualized Telemetry Data

[Joe Clarke (jclarke)]

This work has been presented a few times now, and has had some on-list as well 
as at-mic discussion.  Coming out of 116, we said we’d bring the question of 
adoption to the list (minutes have been updated to reflect the conversation at 
the mic).

As such, we are holding a three-ish-week call for adoption for 
https://datatracker.ietf.org/doc/draft-claise-opsawg-collected-data-manifest/.  
Please reply with support, dissent, comments, etc. to the list.  The CfA will 
end on May 25, 2023.  I’m doing this as I will be out of the office, and I can 
conclude it on May 25th.  It also gives people a bit more time to digest the 
work and provide substantive comments.

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

Re: [OPSAWG] WG LC: draft-ietf-opsawg-rfc7125-update

[Joe Clarke (jclarke)]

Again, sorry for the delay.  I’m just back to the office, and I’m catching up 
on things.  I’ve pushed for some other directorate reviews, but given that we 
want to progress this document, I’m happy to work in parallel with those.

I didn’t get any offers to shepherd, though.  I’ll ask once more to see if 
anyone in the WG is interested?  This is a good, short draft to cut one’s teeth 
on…

Joe

From: Joe Clarke (jclarke) 
Date: Tuesday, April 4, 2023 at 16:01
To: opsawg@ietf.org 
Subject: WG LC: draft-ietf-opsawg-rfc7125-update
Hello, WG.  I hope everyone that traveled for 116 is back home and healthy.

One of the items that came out of the 116 meeting was that this document is in 
decent shape for a WGLC.  We wanted to move these IPFIX maintenance documents 
through the process rather quickly.

One of the open questions Med asked of the WG (and chairs) is should this be a 
bis.  As a chair, I think a bis is cleaner here, but I would like to hear from 
the WG during this LC if that makes sense.

We will run a two week WG LC ending on April 18, 2023.  Please provide your 
comments on list.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc7125-update/

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

[OPSAWG] Minutes from 116

[Joe Clarke (jclarke)]

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] I-D Action: draft-ietf-opsawg-tlstm-update-14.txt

[Joe Clarke (jclarke)]

Thanks, Rob!

Joe

From: Rob Wilton (rwilton) 
Date: Monday, April 17, 2023 at 13:05
To: Kenneth Vaughn , opsawg@ietf.org , 
Joe Clarke (jclarke) 
Cc: i-d-annou...@ietf.org , Amanda Baber via RT 

Subject: RE: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-14.txt
Hi Ken, Joe, OPSAWG,

Thank you all for your work and reviews of this document.

This document has now been approved and moves on to the RFC editor queue.

Regards,
Rob


From: Kenneth Vaughn 
Sent: 31 March 2023 00:33
To: opsawg@ietf.org; Joe Clarke (jclarke) ; Rob Wilton 
(rwilton) 
Cc: i-d-annou...@ietf.org; Amanda Baber via RT 
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-14.txt

I believe this version of the document addresses all concerns. The approach 
taken to reference the registry was accepted as is, so the only changes in this 
version was to convert textual references to RFC 8446 and RFC9150 to xref links 
and to add RFC 9150 to the list of informative references at the end of the 
document.

The document should be ready to submit back to IANA for their approval; I've 
included Amanda on the email, but I assume the formal release needs to come 
from Joe (or perhaps Rob since the web site shows him as the action owner).

Regards,
Ken Vaughn

Trevilon LLC
1060 S Hwy 107
Del Rio, TN 37727
+1-571-331-5670 cell
kvau...@trevilon.com<mailto:kvau...@trevilon.com>
www.trevilon.com<http://www.trevilon.com>



On Mar 30, 2023, at 7:18 PM, 
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> wrote:


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   : Updates to the TLS Transport Model for SNMP
  Author  : Kenneth Vaughn
  Filename: draft-ietf-opsawg-tlstm-update-14.txt
  Pages   : 34
  Date: 2023-03-30

Abstract:
  This document updates RFC 6353 "Transport Layer Security (TLS)
  Transport Model for the Simple Network Management Protocol (SNMP)",
  to reflect changes necessary to support Transport Layer Security
  Version 1.3 (TLS 1.3) and Datagram Transport Layer Security Version
  1.3 (DTLS 1.3), which are jointly known as "(D)TLS 1.3".  This
  document is compatible with (D)TLS 1.2 and is intended to be
  compatible with future versions of SNMP and (D)TLS.

  This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tlstm-update/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-14.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tlstm-update-14

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


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

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

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

[Joe Clarke (jclarke)]

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

Re: [OPSAWG] WG LC: draft-ietf-opsawg-rfc7125-update

[Joe Clarke (jclarke)]

One other item, is anyone willing to be a shepherd for this document?  Ideally, 
assuming all the IPFIX maintenance documents are adopted, that person can help 
shepherd all of them, but let’s start with this one for now.

Joe

From: OPSAWG  on behalf of Joe Clarke (jclarke) 

Date: Tuesday, April 4, 2023 at 16:01
To: opsawg@ietf.org 
Subject: [OPSAWG] WG LC: draft-ietf-opsawg-rfc7125-update
Hello, WG.  I hope everyone that traveled for 116 is back home and healthy.

One of the items that came out of the 116 meeting was that this document is in 
decent shape for a WGLC.  We wanted to move these IPFIX maintenance documents 
through the process rather quickly.

One of the open questions Med asked of the WG (and chairs) is should this be a 
bis.  As a chair, I think a bis is cleaner here, but I would like to hear from 
the WG during this LC if that makes sense.

We will run a two week WG LC ending on April 18, 2023.  Please provide your 
comments on list.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc7125-update/

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

[OPSAWG] WG LC: draft-ietf-opsawg-rfc7125-update

[Joe Clarke (jclarke)]

Hello, WG.  I hope everyone that traveled for 116 is back home and healthy.

One of the items that came out of the 116 meeting was that this document is in 
decent shape for a WGLC.  We wanted to move these IPFIX maintenance documents 
through the process rather quickly.

One of the open questions Med asked of the WG (and chairs) is should this be a 
bis.  As a chair, I think a bis is cleaner here, but I would like to hear from 
the WG during this LC if that makes sense.

We will run a two week WG LC ending on April 18, 2023.  Please provide your 
comments on list.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc7125-update/

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

[OPSAWG] Upcoming IETF 116 opsawg meeting

[Joe Clarke (jclarke)]

Hello, WG.  IETF 116 has kicked off with the Hackathon running in the Pacifico 
Yokohama.  Our meeting is right around the corner on Tuesday, March 28 at 9:30 
am JST.  We look forward to seeing you in person or on Meetecho.

Be sure to familiarize yourself with the attendee prep guide at 
https://www.ietf.org/how/meetings/preparation/ and make sure you check out our 
agenda at https://datatracker.ietf.org/doc/agenda-116-opsawg/.  We’ll have a 
tight schedule (coming in at 115 minutes of content), so speakers, please 
respect your allocated times.

Thanks!

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

Re: [OPSAWG] OPSAWG meeting agenda

[Joe Clarke (jclarke)]

I want to put a fine point on the timing.  Those last three topics (below the 
time exceeded line) will almost certainly not be presented.  We’re currently at 
115 minutes (as OPS Area wants 15).

So, please all speakers keep to your time.  And all speakers, please get your 
slides in by Friday of this week (by March 24, 2023).

Thanks.

Joe

From: Tianran Zhou 
Date: Thursday, March 16, 2023 at 07:16
To: opsawg@ietf.org 
Cc: opsawg-cha...@ietf.org 
Subject: OPSAWG meeting agenda
Hi WG,

We just posted the preliminary agenda for IETF116.
https://datatracker.ietf.org/doc/agenda-116-opsawg/

It’s really great that we got so many requests.
We prepare the schedule by first come first serve. So there are 3 topics can 
only be presented when time allows.
Please check if there is anything missing.

The speaker please send over your slides before the meeting date.

Look forward to see you in Yokohama.

Cheers,
Tianran, Joe, Hank


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

Re: [OPSAWG] New Version Notification for draft-palmero-opsawg-dmlmo-09.txt

[Joe Clarke (jclarke)]

From: Marisol Palmero Amador (mpalmero) 
Date: Monday, March 13, 2023 at 12:29
To: Joe Clarke (jclarke) , opsawg@ietf.org 
, Rob Wilton (rwilton) 
Cc: Sudhendu Kumar , Shwetha Bhandari 
, Jan Lindblad (jlindbla) 
, inventory-y...@ietf.org 
Subject: Re: New Version Notification for draft-palmero-opsawg-dmlmo-09.txt
Many thanks Joe for your comments,

When referring to license or entitlement, we refer to the availability of being 
able to use a feature or asset, the scope of it is not to refer to source code, 
but just the “right to use” that specific feature or asset. It will be great to 
have an agreement from the group for the best word to use.

JMC: Entitlement might be the right word.  My comment was about the fact that 
you bring Open Source into that.  While an OSS licenses does give you some 
rights to use, the model for that seems quite different than the entitlement 
model you have here.  Maybe they do map and perhaps this works but is overkill 
for an OSS license.  That’s why I’d like to see some examples.

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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-13.txt

[Joe Clarke (jclarke)]

Given Randy’s explanation I’m fine to move forward.

Joe

From: Kenneth Vaughn 
Date: Tuesday, March 14, 2023 at 14:13
To: Joe Clarke (jclarke) 
Cc: Randy Presuhn , Joe Clarke (jclarke) 
, opsawg@ietf.org 
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-13.txt
Joe,
The thread seems to have gone cold. Are you now okay with the proposal to use a 
new OBJECT-IDENTITY as the identifier for the registry. If so, I have one more 
nit update to save (adding an informative reference to 9150) and then I think 
we are done - but if we think there are other changes, I am happy to hold off 
until this issue is resolved.

Regards,
Ken Vaughn

Trevilon LLC
1060 S Hwy 107
Del Rio, TN 37727
+1-571-331-5670 cell
kvau...@trevilon.com<mailto:kvau...@trevilon.com>
www.trevilon.com<http://www.trevilon.com>


On Mar 3, 2023, at 8:08 AM, Joe Clarke (jclarke) 
mailto:jcla...@cisco.com>> wrote:

Thanks for the review, Randy.  I was concerned that the anchored object wasn’t 
of the type (thinking of other examples like ifType).

Joe

From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of Randy Presuhn 
mailto:randy_pres...@alumni.stanford.edu>>
Date: Thursday, March 2, 2023 at 13:23
To: Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>,
 Kenneth Vaughn mailto:kvau...@trevilon.com>>, 
opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-13.txt
Hi -

On 2023-03-02 7:08 AM, Joe Clarke (jclarke) wrote:
> - Sect 4: Added the snmpTlstmHashAlgorithms node to represent the new
> registry --- This is related to the issue that is still under review
>
> On this point, I would like some guidance from other MIB experts.  You
> have created a “dummy” node with no type to represent this.  This
> doesn’t give enough of a pointer to what this registry represents IMHO.
> I suggested pointing to the MIB module itself, but I can see that is
> sub-optimal, too.  In this case, the registry is used within a
> TEXTUAL-CONVENTION, which has no OID itself.  There are three current
> objects in the MIB that use this TC.  Should one of those be the anchor
> for the registry description?  For example:  snmpTlstmCertToTSNEntry
>   (1.3.6.1.2.1.198.2.2.1.3.1.2)?

Definitely not.  The description of snmpTlstmHashAlgorithms
spells out its purpose as the anchor for the object identifiers in the
SNMP-TLSTM registry, and the IANA considerations section, as well as
section 2.1, specify what belongs in that registry.  One *might*
consider making an explicit reference to section 2.1 in the
description, but that would probably be lily-gilding.

Randy

___
OPSAWG mailing list
OPSAWG@ietf.org<mailto: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] New Version Notification for draft-palmero-opsawg-dmlmo-09.txt

[Joe Clarke (jclarke)]

Hello, authors.  I’ve read through the new -09 and I have a few comments and 
questions.  First, thanks for the effort here to abstract inventory and to show 
how this work can map to other inventory models.

I’m not sure your change from license to entitlement tracks 100%.  Your model 
for “entitlement” strongly resembles a vendor entitlement and not something 
that would be issued by the Open Source community as you say in section 2.  I 
would be very curious how you see modeling, say, the BSD License in this 
entitlement framework.

On that point, I think this draft would benefit from some examples of different 
hardware, software, and entitlements and how they would look in this overall 
model.

In Section 2, your last term is “User Experience” which you describe as being 
influenced by “ease of use” as it pertains to a user’s experience.  Where and 
how is that rationalized in your four classes described in Section 3?  And 
wouldn’t those four classes describe LMO vs. the user experience?  
Specifically, the description of an asset (class 1) doesn’t seem to me to be 
directly related to user experience.  I also wonder how some of the feature use 
elements might also fit into Open Telemetry and instrumentation of an 
application to understand use.  I’m not saying OTel replaces this, but there 
might be some cross-over there in the application space.  That might even get 
closer to understanding the ease of use you mention.

With respect to the YANG modules, there are a lot of “string” types here.  In 
particular, the incident management model feels both under-described and 
perhaps too restrictive in its fields to provide general use across multiple 
vendors and OSS.

Ultimately, I feel this draft, even with it being more agnostic to inventory, 
is trying to cover a lot of ground.  Perhaps an initial focus on entitlements 
and/or features would be helpful in focusing the work.

Joe


From: OPSAWG  on behalf of Marisol Palmero Amador 
(mpalmero) 
Date: Tuesday, January 17, 2023 at 12:58
To: opsawg@ietf.org , Rob Wilton (rwilton) 
Cc: Sudhendu Kumar , Shwetha Bhandari 
, Jan Lindblad (jlindbla) 
, inventory-y...@ietf.org 
Subject: [OPSAWG] FW: New Version Notification for 
draft-palmero-opsawg-dmlmo-09.txt
Dear OPSA WG/AD,

We've just posted a new version, v09, for DMLMO, data model for lifecycle 
management and operations:
https://www.ietf.org/archive/id/draft-palmero-opsawg-dmlmo-09.txt

Where we have been addressing the comments given during OPSA WG meeting and 
inventory side meeting, part of IETF #115.

DMLMO version 09 is independent from inventory, where the DMLMO YANG modules, 
as specific ietf-lmo-assets YANG module, can consume from any other specific 
inventory YANG module(s). An example is given in Appendix A.



   version 09

   *  Rename "license" to "entitlement".

   *  renamed ietf-lmo-assets-inventory to ietf-lmo-assets.

   *  ietf-lmo-assets provides capability of integration and extention for a 
different approach on how to address inventory use cases. Process is explained 
in the Appendix A.

   *  ietf-lmo-example-mapping-XXX YANG modules accommodates the 
ietf-lmo-assets YANG module to any other inventory which will be required in 
the future to be referenced.

We greatly appreciate your thoughts, comments and evaluation.

Many thanks,
Marisol Palmero

From: internet-dra...@ietf.org 
Date: Tuesday, 17 January 2023 at 18:28
To: Camilo Cardona , Diego Lopez 
, Frank Brockners (fbrockne) 
, Marisol Palmero Amador (mpalmero) , 
Shwetha Bhandari , Sudhendu Kumar 

Subject: New Version Notification for draft-palmero-opsawg-dmlmo-09.txt

A new version of I-D, draft-palmero-opsawg-dmlmo-09.txt
has been successfully submitted by Marisol Palmero and posted to the
IETF repository.

Name:   draft-palmero-opsawg-dmlmo
Revision:   09
Title:  Data Model for Lifecycle Management and Operations
Document date:  2023-01-17
Group:  Individual Submission
Pages:  80
URL:
https://www.ietf.org/archive/id/draft-palmero-opsawg-dmlmo-09.txt
Status: https://datatracker.ietf.org/doc/draft-palmero-opsawg-dmlmo/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-palmero-opsawg-dmlmo
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-palmero-opsawg-dmlmo-09

Abstract:
   This document motivates and specifies a data model for lifecycle
   management and operations.  It describes the motivation and
   requirements to collect asset-centric metrics including but not
   limited to asset adoption and usability, licensing, supported
   features and capabilities, enabled features and capabilities, etc.;
   with the primary objective to measure and improve the overall user
   experience along the lifecycle journey, from technical requirements
   and technology selection through advocacy and renewal, including the
   end of life of an asset.




The IETF Secretariat


___
OPSAWG mailing list

Re: [OPSAWG] Update on T+/TLS

[Joe Clarke (jclarke)]

Thanks, heas.  Will you be getting this next rev in before the cut-off on 
Monday?

Joe

From: heasley 
Date: Friday, March 10, 2023 at 13:42
To: Joe Clarke (jclarke) 
Cc: opsawg@ietf.org , draft-ietf-opsawg-tacacs-tl...@ietf.org 

Subject: Re: Update on T+/TLS
Wed, Mar 08, 2023 at 07:34:21PM +, Joe Clarke (jclarke):
> Hello, authors.  I’m not sure if you’re planning to request a speaking slot 
> for IETF 116, but we would like to get an update of the current state of this 
> work (and author’s thoughts on next steps).  After publishing -01, there was 
> a discussion on whether or not the obfuscation should be allowed within the 
> TLS encap.  I don’t think that was concluded, though it seems like there is 
> more support for NO.
>
> Speaking as chair, I’d like to see this move forward, and perhaps it’s in or 
> close to a state where we can do a WG LC?
>
> Thanks.
>
> Joe

Hey Joe,
We'd hoped to have an updated draft two weeks ago, but the delay is because
of me.  Just a lack of time.

We will have an update for both drafts next week.  I do not think that
the TLS draft is quite ready for a LC.  I expect that there will be at
least one more round of discussion.  I do hope that the other draft will
subsequently be ready for an adoption call.

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

[OPSAWG] Update on T+/TLS

[Joe Clarke (jclarke)]

Hello, authors.  I’m not sure if you’re planning to request a speaking slot for 
IETF 116, but we would like to get an update of the current state of this work 
(and author’s thoughts on next steps).  After publishing -01, there was a 
discussion on whether or not the obfuscation should be allowed within the TLS 
encap.  I don’t think that was concluded, though it seems like there is more 
support for NO.

Speaking as chair, I’d like to see this move forward, and perhaps it’s in or 
close to a state where we can do a WG LC?

Thanks.

Joe

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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-13.txt

[Joe Clarke (jclarke)]

Thanks for the review, Randy.  I was concerned that the anchored object wasn’t 
of the type (thinking of other examples like ifType).

Joe

From: OPSAWG  on behalf of Randy Presuhn 

Date: Thursday, March 2, 2023 at 13:23
To: Joe Clarke (jclarke) , Kenneth Vaughn 
, opsawg@ietf.org 
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-13.txt
Hi -

On 2023-03-02 7:08 AM, Joe Clarke (jclarke) wrote:
> - Sect 4: Added the snmpTlstmHashAlgorithms node to represent the new
> registry --- This is related to the issue that is still under review
>
> On this point, I would like some guidance from other MIB experts.  You
> have created a “dummy” node with no type to represent this.  This
> doesn’t give enough of a pointer to what this registry represents IMHO.
> I suggested pointing to the MIB module itself, but I can see that is
> sub-optimal, too.  In this case, the registry is used within a
> TEXTUAL-CONVENTION, which has no OID itself.  There are three current
> objects in the MIB that use this TC.  Should one of those be the anchor
> for the registry description?  For example:  snmpTlstmCertToTSNEntry
>   (1.3.6.1.2.1.198.2.2.1.3.1.2)?

Definitely not.  The description of snmpTlstmHashAlgorithms
spells out its purpose as the anchor for the object identifiers in the
SNMP-TLSTM registry, and the IANA considerations section, as well as
section 2.1, specify what belongs in that registry.  One *might*
consider making an explicit reference to section 2.1 in the
description, but that would probably be lily-gilding.

Randy

___
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