[OPSAWG]Re: WG Adoption Call for draft-gfz-opsawg-ipfix-alt-mark-01
Dear OPSAWG members, this email concludes the call for Working Group Adoption for draft-gfz-opsawg-ipfix-alt-mark-01. Despite the general vacation time around several place on the globe, we received some positive feedback and no objections. Taking into account the previous list discussion and the brevity of the I-D as well its scope of application, the chairs discussed the inputs and comments and believe this I-D to be ready for adoption and for the working group to work on. Authors please rename the draft to be draft-ietf-opsawg-ipfix-alt-mark-00, keeping the content as is, and resubmit. For the OPSAWG co-chairs, Henk On 26.06.24 11:58, Henk Birkholz wrote: Dear OPSAWG members, this email starts a call for Working Group Adoption of https://datatracker.ietf.org/doc/html/draft-gfz-opsawg-ipfix-alt-mark-01 ending on Saturday, July 6th. That is a little bit of an odd duration, but the I-D is crisp and concise and if there is rough consensus after that time, this work may become a WG item before the upcoming cut-off. As a reminder, this I-D specifies IPFIX Information Elements for the Alternate-Marking Method as defined in RFC9341 & RFC9342; a technique for measuring packet loss, delay, and jitter of packets in-flight. The chairs acknowledge positive feedback and some review on the list and 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 To unsubscribe send an email to opsawg-le...@ietf.org ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG] WG Adoption Call for draft-gfz-opsawg-ipfix-alt-mark-01
Dear OPSAWG members, this email starts a call for Working Group Adoption of https://datatracker.ietf.org/doc/html/draft-gfz-opsawg-ipfix-alt-mark-01 ending on Saturday, July 6th. That is a little bit of an odd duration, but the I-D is crisp and concise and if there is rough consensus after that time, this work may become a WG item before the upcoming cut-off. As a reminder, this I-D specifies IPFIX Information Elements for the Alternate-Marking Method as defined in RFC9341 & RFC9342; a technique for measuring packet loss, delay, and jitter of packets in-flight. The chairs acknowledge positive feedback and some review on the list and 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 To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG]Re: WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03
Hi Carlos, +1 Sorry for the detour & thanks for bearing with us! Viele Grüße, Henk On 10.05.24 17:38, Carlos Pignataro wrote: Hi, Henk, Closing the loop, we have done it this way. The delta in the wg draft between-00 and-01 <https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-oam-characterization-00=draft-ietf-opsawg-oam-characterization-01=--html> addresses all discussion thus far as part of the adoption call. Thanks, Carlos. On May 10, 2024, at 8:42 AM, Henk Birkholz wrote: 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 <mailto:adr...@olddog.co.uk>> 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 <https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-question-mark-03.html> > > ending on Thursday, May 2nd. > > As a reminder, this I-D summarizes how the term "Operations, > Administration, and Maintenance" (OAM) is used currently & historically > in the IETF and intends to consolidate unambiguous and protocol agnostic > terminology for OAM. The summary includes descriptions of narrower > semantics introduced by added qualifications the term OAM and a list of > common capabilities that can be found in nodes processing OAM packets. > > The chairs acknowledge a positive poll r
[OPSAWG]Re: WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03
FYI, I found the I-D Action notif. My intricate web of shiny sieve filters is to blame (which unfortunately inhibits me from shifting blame from me to mailman anymore. Mailman is fine). On 10.05.24 15:03, Henk Birkholz wrote: Oh I see, DT tells me it is at -05 already. Well, there was no notification on i-d-annou...@ietf.org AFAICS (but there were some mailman transition snafus recently, so I'll just account that under the German expression "tja"). I'd have commented on a -04 submission, if I would have seen an email. Nothing to worry about, though, and no need to hassle already busy Secretariat with that. Just submit -03 as the new -00 and replay the diff between -03 to -05 as a new diff from -00 to 01 and we are good. As Joe just highlighted, any pending submission of draft-ietf-opsawg-oam-characterization-00 can be canceled - and I just did that. So you are good to go. Viele Grüße, Henk On 10.05.24 14:46, Adrian Farrel wrote: 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 mailto:adr...@olddog.co.uk>> 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
[OPSAWG]Re: WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03
Oh I see, DT tells me it is at -05 already.
Well, there was no notification on i-d-annou...@ietf.org AFAICS (but
there were some mailman transition snafus recently, so I'll just account
that under the German expression "tja"). I'd have commented on a -04
submission, if I would have seen an email.
Nothing to worry about, though, and no need to hassle already busy
Secretariat with that. Just submit -03 as the new -00 and replay the
diff between -03 to -05 as a new diff from -00 to 01 and we are good.
As Joe just highlighted, any pending submission of
draft-ietf-opsawg-oam-characterization-00 can be canceled - and I just
did that. So you are good to go.
Viele Grüße,
Henk
On 10.05.24 14:46, Adrian Farrel wrote:
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 mailto:adr...@olddog.co.uk>> 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.
[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 <mailto:adr...@olddog.co.uk>> 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
<https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-question-mark-03.html>
>
> ending on Thursday, May 2nd.
>
> As a reminder, this I-D summarizes how the term "Operations,
> Administration, and Maintenance" (OAM) is used currently &
historically
> in the IETF and intends to consolidate unambiguous and protocol
agnostic
> terminology for OAM. The summary includes descriptions of narrower
> semantics introduced by added qualifications the term OAM and a
list of
> common capabilities that can be found in nodes processing OAM
packets.
>
> The chairs acknowledge a positive poll result at IETF119, but
there has
> not been much discussion on the list yet. We would like to gather
> feedback from the WG if there is interest to further contribute and
> review. As a potential enabler for discussions, this call will last
> three weeks.
>
> Please reply with your support and especially any substantive
comments
> you may have.
>
[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 ending on Thursday, May 2nd. As a reminder, this I-D summarizes how the term "Operations, Administration, and Maintenance" (OAM) is used currently & historically in the IETF and intends to consolidate unambiguous and protocol agnostic terminology for OAM. The summary includes descriptions of narrower semantics introduced by added qualifications the term OAM and a list of common capabilities that can be found in nodes processing OAM packets. The chairs acknowledge a positive poll result at IETF119, but there has not been much discussion on the list yet. We would like to gather feedback from the WG if there is interest to further contribute and review. As a potential enabler for discussions, this call will last three weeks. 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 To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG] IPR Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03
Dear authors and contributors, as a part of the adoption process, the chairs would also like to issue a first IPR call on the content of adoption candidates (there will also be a second IPR call after successful WGLC). Please respond on-list as to whether or not you are aware of any IPR that pertains to draft-pignataro-opsawg-oam-whaaat-question-mark-03. If you are aware of IPR, please also indicate whether or not this has been disclosed per IETF IPR rules (see RFCs 3669, 5378, and 8179). For the OPSAWG co-chairs, Henk p.s. today is a good day to respond to the draft-pignataro-opsawg-oam-whaaat-question-mark-03 WG adoption call, if you have not done so yet ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03
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 ending on Thursday, May 2nd. As a reminder, this I-D summarizes how the term "Operations, Administration, and Maintenance" (OAM) is used currently & historically in the IETF and intends to consolidate unambiguous and protocol agnostic terminology for OAM. The summary includes descriptions of narrower semantics introduced by added qualifications the term OAM and a list of common capabilities that can be found in nodes processing OAM packets. The chairs acknowledge a positive poll result at IETF119, but there has not been much discussion on the list yet. We would like to gather feedback from the WG if there is interest to further contribute and review. As a potential enabler for discussions, this call will last three weeks. 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
Re: [OPSAWG] WG Adoption Call for draft-feng-opsawg-incident-management-04
Dear OPSAWG members, this email concludes the call for Working Group Adoption on https://datatracker.ietf.org/doc/html/draft-feng-opsawg-incident-management-04. We received a significant amount of positive replies, a few elaborate comments, and most importantly the notion that this work should be considered for adoption in the NMOP WG. There were also a few concerns about access to some work by other bodies that must be accounted in this I-D. Strong collaboration with other bodies must happen to ensure terminology consistency (avoiding the definition of subtly different or conflicting semantics). The OPSAWG chairs believe this I-D is ready for adoption. If the NMOP chairs agree they can inherit the result of the WG adoption call or issues a complementary one on the NMOP list, referring to the results of this WG adoption call. For the OPSAWG co-chairs, Henk On 08.02.24 16:44, Henk Birkholz wrote: 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 Adoption Call for draft-feng-opsawg-incident-management-04
We'll conclude the WG Adoption Call in OPSAWG as planned and the result will be one input to the NMOP chairs. Another input, of course, is the notion of that "yet another set of terminology" would require "collaboration and cooperation being clearly spelled out" to ensure consistency. The former is an adoption consideration, the latter is both an adoption consideration and a potential WG item task. On 20.02.24 15:48, Michael Richardson wrote: Qin Wu wrote: > Hi, NMOP Chairs: Since this document has been discussed in OPSAWG for a > long time, and because it was ready for adoption there, and considering > that it is now 'suddenly' in scope for NMOP, could we please consider > moving the existing adoption poll to NMOP (perhaps extending it to make > up for time when NMOP was not aware of the poll). That sounds like a good idea to me. I'll point out that WG chairs adopt documents by fiat: it's up to them. [with being replaced by the AD if they do the wrong thing] This business with consulting people is a courtesy :-) So, Benoit and Mohammed (NMOP chairs) can just do this. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ___ 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 Adoption Call for draft-feng-opsawg-incident-management-04
Hi Adrian, Alex,
hi all,
thanks for bringing that up. Clearly, there is some overlap not only in
name. Before starting to ask chairs and Rob (and I am sure Rob will have
an opinion here), I'd like to add something like a litmus test question
to the authors first - and then we can go from there:
While the English text puts a strong emphasis on "network" (especially
at the beginning), the yang module has a strong emphasis on the more
generic "incident" (especially at the end). Do the authors intend the
document to gravitate more towards the network-focused or
service-focused incidents?
Viele Grüße,
Henk
On 13.02.24 10:20, Adrian Farrel wrote:
I am also as confused as Alex :-)
The OPSAWG charter says:
The Operations and Management Area receives occasional proposals for
the development and publication of RFCs dealing with operational and
management topics that are not in scope of an existing working group
The NMOP charter is very clear that
The current topics of focus for the working group are:
* NETCONF/YANG Push integration with Apache Kafka & time series databases
* Anomaly detection and incident management
It also says:
* Standardize YANG data models to solve operational issues identified in
the scope items above. YANG data models potentially within the scope
of other WGs will only be progressed here with agreement from the
relevant ADs.
So, while I strongly support the IETF working on this draft, I am
confused about why it is being polled for adoption in OPSAWG rather than
NMOP. I appreciate that a lot of initial work has been done in OPSAWG,
but now that NMOP has been chartered we should attempt to keep the lines
clean.
I’d ask that the chairs of both WGs and the ADs talk to each other and
give us direction on this as a matter of some urgency.
Thanks,
Adrian
PS. Unlike Alex, I don’t think the solution is to discuss the document
in two WGs: that usually leads to interesting challenges
*From:*OPSAWG *On Behalf Of *Alex Huang Feng
*Sent:* 13 February 2024 05:25
*To:* Henk Birkholz
*Cc:* OPSAWG
*Subject:* Re: [OPSAWG] WG Adoption Call for
draft-feng-opsawg-incident-management-04
Dear OPSAWG,
I support the progress of this document.
I only have a comment. Since the creation of the new NMOP WG, I wonder
if this draft should be discussed in that WG too. There is “incident
management” in the charter.
Some of the related work such as
https://datatracker.ietf.org/doc/draft-davis-nmop-incident-terminology/
<https://datatracker.ietf.org/doc/draft-davis-nmop-incident-terminology/> is planned to be discussed there.
Just wondering.
Regards,
Alex
On 9 Feb 2024, at 00:44, Henk Birkholz
wrote:
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
[OPSAWG] IPR Call for draft-feng-opsawg-incident-management-04
Dear authors and contributors, as a part of the adoption process, the chairs would also like to issue a first IPR call on the content of adoption candidates (there will also be a second IPR call after successful WGLC). Please respond on-list as to whether or not you are aware of any IPR that pertains to draft-feng-opsawg-incident-management-04. If you are aware of IPR, please also indicate whether or not this has been disclosed per IETF IPR rules (see RFCs 3669, 5378, and 8179). For the OPAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[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
Re: [OPSAWG] WG Adoption Call for draft-opsawg-evans-discardmodel-02
Dear OPSAWG members, this email concludes the call for Working Group Adoption on https://datatracker.ietf.org/doc/html/draft-opsawg-evans-discardmodel-02. We received a significant amount of positive replies, no objections, and willingness to review. The chairs believe this I-D is ready for adoption and for the working group to work on. One common theme in the feedback was the topic of disambiguation of loss and discard (e.g., controlled or uncontrolled availability of transfer units), which is a good direction to further address cause and effect w.r.t. SLOs. Authors, please rename the I-D to draft-ietf-opsawg-discardmodel-00, keeping the content as is, and resubmit. For the OPSAWG co-chairs, Henk On 17.01.24 13:51, Henk Birkholz wrote: Dear OPSAWG members, this email starts a call for Working Group Adoption of https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.html ending on Wednesday, January 31st. As a reminder, this I-D describes an information model in support of automated network mitigation on what and how to report about unintentional packet discards/losses that can have an impact on service level objectives. Implementation of the informational model, which could manifest, e.g., via NETCONF/YANG, SNMP or IPFIX, is out-of-scope. The chairs acknowledge feedback to and interest for the topic during the IETF118 meeting and on the list after afterwards. 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
[OPSAWG] Publication has been requested for draft-ietf-opsawg-mud-acceptable-urls-09
Henk Birkholz has requested publication of draft-ietf-opsawg-mud-acceptable-urls-09 as Proposed Standard on behalf of the OPSAWG working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-acceptable-urls/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] IPR Call for draft-opsawg-evans-discardmodel-02
Dear authors and contributors, as a part of the adoption process, the chairs would also like to issue a first IPR call on the content of adoption candidates (there will also be a second IPR call after successful WGLC). Please respond on-list as to whether or not you are aware of any IPR that pertains to draft-opsawg-evans-discardmodel-02. If you are aware of IPR, please also indicate whether or not this has been disclosed per IETF IPR rules (see RFCs 3669, 5378, and 8179). For the OPAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] WG Adoption Call for draft-opsawg-evans-discardmodel-02
Dear OPSAWG members, this email starts a call for Working Group Adoption of https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.html ending on Wednesday, January 31st. As a reminder, this I-D describes an information model in support of automated network mitigation on what and how to report about unintentional packet discards/losses that can have an impact on service level objectives. Implementation of the informational model, which could manifest, e.g., via NETCONF/YANG, SNMP or IPFIX, is out-of-scope. The chairs acknowledge feedback to and interest for the topic during the IETF118 meeting and on the list after afterwards. 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] Publication has been requested for draft-ietf-opsawg-mud-iot-dns-considerations-08
Henk Birkholz has requested publication of draft-ietf-opsawg-mud-iot-dns-considerations-08 as Best Current Practice on behalf of the OPSAWG working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] IPR Call for draft-ietf-opsawg-mud-acceptable-urls-06
Dear authors and contributors, please respond on-list as to whether or not you are aware of any IPR that pertains to draft-ietf-opsawg-mud-acceptable-urls-06. 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). For the OPAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] IPR Call for draft-ietf-opsawg-mud-iot-dns-considerations-08
Dear authors and contributors, please respond on-list as to whether or not you are aware of any IPR that pertains to draft-ietf-opsawg-mud-iot-dns-considerations-08. 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). For the OPAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Publication has been requested for draft-ietf-opsawg-mud-tls-12
Henk Birkholz has requested publication of draft-ietf-opsawg-mud-tls-12 as Proposed Standard on behalf of the OPSAWG working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG Last Call for draft-ietf-opsawg-mud-iot-dns-considerations-05
Dear OPSAWG members, as all WGLC comments are addressed, the chairs think there is now consensus in the WG regarding this I-D and that it is ready to be submitted to IESG for publication - after Shepard write-up. For the OPSAWG co-chairs, Henk On 09.12.22 17:20, Henk Birkholz wrote: Dear OPSAWG members, this email starts a four week period for a Working Group Last Call of https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerations-05.html ending on Friday, January 6th 2023. Several reviews of this document were submitted. The most recent one from the Security Directorate was addressed. The authors believe the Internet-Draft is ready for a WGLC and the chairs are in support of a WGLC. The draft has been discussed visibly on the list and at previous IETF meetings. Please reply with your active support (+1 required) or objections and your assessment of whether or not it is ready to proceed to publication before January 6th 2023. 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 Last Call for draft-ietf-opsawg-mud-acceptable-urls-05
Dear OPSAWG members, after some consideration, the chairs think there is enough consensus in the WG regarding this I-D and that it is ready to be submitted to IESG for publication - after Shepard write-up. For the OPSAWG co-chairs, Henk On 09.12.22 17:20, Henk Birkholz wrote: Dear OPSAWG members, this email starts a four week period for a Working Group Last Call of https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-acceptable-urls-05.html ending on Friday, January 6th 2023. This internet draft updates RFC8520. The authors believe the Internet-Draft is ready for a WGLC and the chairs agree. The draft has been discussed visibly at previous IETF meetings and there was in-room consensus that the work is uncontroversial. Please reply with your active support (+1 required) or objections and your assessment of whether or not it is ready to proceed to publication before January 6th 2023. 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 Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
Dear OPSAWG members, this email concludes the 2nd call for Working Group Adoption on the bundle of https://www.ietf.org/archive/id/draft-tuexen-opsawg-pcapng-05.html and https://www.ietf.org/archive/id/draft-richardson-opsawg-pcaplinktype-01.html. Looking back on both WGLCs, we received a reasonable number of replies, including an extensive discussion about transfer, maintenance, and quality of content in the pcaplinktype I-D. The chairs discussed the inputs and comments and believe this work to be feasible to be adopted as working group I-Ds. The chairs also acknowledge the concerns raised and expect the authors/editors (with the help of the pcap community and working group members) to create a summary of the issues raised and rephrase them as dedicated action items here on the list so that the working group can track, understand, and address them. Authors, please rename the document draft-tuexen-opsawg-pcapng-05 to draft-ietf-opsawg-pcapng-00 with an Intended Status of Informational, keeping the content as is, and resubmit. Also, please rename the document draft-richardson-opsawg-pcaplinktype-01 to draft-ietf-opsawg-pcaplinktype-00 with an Intended Status of Standards Track, keeping the content as is, and resubmit. For the OPSAWG co-chairs, Henk On 08.12.22 21:34, Henk Birkholz wrote: Dear OPSAWG members, this starts a Working Group Adoption call for a bundle of two documents: https://www.ietf.org/archive/id/draft-tuexen-opsawg-pcapng-05.html https://www.ietf.org/archive/id/draft-richardson-opsawg-pcaplinktype-01.html ending on Monday, December 30th. As a recap: we already went through a first WGLC for draft-tuexen-opsawg-pcapng-03 and this is the second WGLC. The last WGLC did not yield a critical mass of active support. Since the last WGLC, two relevant decisions were made: 1.) The Intended Status of the main document draft-tuexen-opsawg-pcapng is now Informational. 2.) The draft-richardson-opsawg-pcaplinktype document was split from the main documents, focuses solely on the PCAP LINK Type registry content, and retains the Intended Status Standards Track (as informational documents cannot request a registry). As a generic reminder, these internet drafts describe the PCAPng format and its corresponding registry - retaining the established design patterns of PCAP and adding new capabilities as well as a an extensibility feature. Please note that the corresponding document https://www.ietf.org/archive/id/draft-ietf-opsawg-pcap-01.html was adopted in October 2021 and its Intended Status is Historical. Please reply with your active support (+1 required) or objections 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 Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
Hi Tom, Hi Michael, hi all, thanks for your help! As I am continuously challenged by reading my own calendar properly, replies for this Working Group Call for Adoption may drizzle in until Monday (and then some, as I am not sure how many folks will look at this on Jan 1st). In essence, we can relax the deadline a bit as there are probably more important things to plan for this weekend! Also, Michael is correct. This is just about adoption: OLD: Since the last WGLC NEW: Since the last WGAC (Working Group Call for Adoption) A Happy New year to all of you! Henk On 28.12.22 19:46, Michael Tuexen wrote: On 8. Dec 2022, at 21:34, Henk Birkholz wrote: Dear OPSAWG members, this starts a Working Group Adoption call for a bundle of two documents: https://www.ietf.org/archive/id/draft-tuexen-opsawg-pcapng-05.html https://www.ietf.org/archive/id/draft-richardson-opsawg-pcaplinktype-01.html ending on Monday, December 30th. As a recap: we already went through a first WGLC for draft-tuexen-opsawg-pcapng-03 and this is the second WGLC. The last WGLC did not yield a critical mass of active support. Hi Henk, just a clarification question: you are referring to a WGLC in the past. As far as I know, the document has not been accepted as a WG document. That is why it still has draft-tuexen in its name. Are you referring to an adoption call instead of WGLC? Best regards Michael Since the last WGLC, two relevant decisions were made: 1.) The Intended Status of the main document draft-tuexen-opsawg-pcapng is now Informational. 2.) The draft-richardson-opsawg-pcaplinktype document was split from the main documents, focuses solely on the PCAP LINK Type registry content, and retains the Intended Status Standards Track (as informational documents cannot request a registry). As a generic reminder, these internet drafts describe the PCAPng format and its corresponding registry - retaining the established design patterns of PCAP and adding new capabilities as well as a an extensibility feature. Please note that the corresponding document https://www.ietf.org/archive/id/draft-ietf-opsawg-pcap-01.html was adopted in October 2021 and its Intended Status is Historical. Please reply with your active support (+1 required) or objections 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
[OPSAWG] WG Last Call for draft-ietf-opsawg-mud-iot-dns-considerations-05
Dear OPSAWG members, this email starts a four week period for a Working Group Last Call of https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerations-05.html ending on Friday, January 6th 2023. Several reviews of this document were submitted. The most recent one from the Security Directorate was addressed. The authors believe the Internet-Draft is ready for a WGLC and the chairs are in support of a WGLC. The draft has been discussed visibly on the list and at previous IETF meetings. Please reply with your active support (+1 required) or objections and your assessment of whether or not it is ready to proceed to publication before January 6th 2023. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] WG Last Call for draft-ietf-opsawg-mud-acceptable-urls-05
Dear OPSAWG members, this email starts a four week period for a Working Group Last Call of https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-acceptable-urls-05.html ending on Friday, January 6th 2023. This internet draft updates RFC8520. The authors believe the Internet-Draft is ready for a WGLC and the chairs agree. The draft has been discussed visibly at previous IETF meetings and there was in-room consensus that the work is uncontroversial. Please reply with your active support (+1 required) or objections and your assessment of whether or not it is ready to proceed to publication before January 6th 2023. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
Dear OPSAWG members, this starts a Working Group Adoption call for a bundle of two documents: https://www.ietf.org/archive/id/draft-tuexen-opsawg-pcapng-05.html https://www.ietf.org/archive/id/draft-richardson-opsawg-pcaplinktype-01.html ending on Monday, December 30th. As a recap: we already went through a first WGLC for draft-tuexen-opsawg-pcapng-03 and this is the second WGLC. The last WGLC did not yield a critical mass of active support. Since the last WGLC, two relevant decisions were made: 1.) The Intended Status of the main document draft-tuexen-opsawg-pcapng is now Informational. 2.) The draft-richardson-opsawg-pcaplinktype document was split from the main documents, focuses solely on the PCAP LINK Type registry content, and retains the Intended Status Standards Track (as informational documents cannot request a registry). As a generic reminder, these internet drafts describe the PCAPng format and its corresponding registry - retaining the established design patterns of PCAP and adding new capabilities as well as a an extensibility feature. Please note that the corresponding document https://www.ietf.org/archive/id/draft-ietf-opsawg-pcap-01.html was adopted in October 2021 and its Intended Status is Historical. Please reply with your active support (+1 required) or objections 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] Publication has been requested for draft-ietf-opsawg-sbom-access-12
Henk Birkholz has requested publication of draft-ietf-opsawg-sbom-access-12 as Proposed Standard on behalf of the OPSAWG working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WGLC and Shepherd write-up concluded for draft-ietf-opsawg-sbom-access
Dear OPSAWG members, reading no objections, we'll start the submission to IESG. Thanks again to Eliot and Scott for driving the work, to Qin as the document shepherd and to all contributors and reviewers. Viele Grüße, Henk On 10.10.22 09:46, Henk Birkholz wrote: Dear OPSAWG members, the chairs think consensus on this I-D is established and that it is ready to be submitted to IESG for publication. We'll let that assessment simmer here on the list for a few days before pushing the buttons, checking for pending comments from ADs and the list. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG Last Call for draft-ietf-opsawg-mud-tls-07
Hi Tom, would it be possible for you to augment your first comment with change proposals, if possible? @authors: it seems to me that the references issues Tom now provided in specific detail could be resolved in this thread in a timely manner. Is that correct? Viele Grüße, Henk On 12.10.22 13:39, tom petch wrote: From: OPSAWG on behalf of Henk Birkholz Sent: 06 October 2022 13:26 Dear authors and contributors, thank you for your hard work. As it seems that all existing issues have been resolve, we'll move the I-D to write-up in the datatracker. Also, thanks Thomas Fossati for stepping up as shepherd! My main comment on this remains the mix of two different YANG modules with different life cycles; I expect that l will comment again on the Last Call list to give this issue more exposure. Of lesser import, I cannot make sense of the references. I see [RFC5246] which normally means that a reference has been created. Not here, so there would seem to have been some chicanery involved, that this I-D has not been produced by the usual IETF tools. I also see RFC5869, RFC6346, RFC8447 which seem absent from the I-D References. dtls13 is now an RFC. What is the difference between draft-ietf-tls-dtls13: and "RFC : Datagram Transport Layer Security 1.3"; ? How do I find "RFC : Common YANG Data Types for Cryptography"; or "RFC : Common YANG Data Types for Hash algorithms"; ? Does tls-1-2 mean the same as tls-1.2? And is this the same as that which the Netconf WG refers to as tls12? Tom Petch For the OPSAWG co-chairs, Henk On 29.09.22 10:27, Henk Birkholz wrote: Dear OPSAWG members, this email concludes the first WGLC call for https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html. A few comments where raised. Authors/editors, please go ahead and address these as discussed on the list. For the OPSAWG co-chairs, Henk On 14.09.22 16:07, Henk Birkholz wrote: Dear OPSAWG members, this email starts a two week period for a Working Group Last Call of https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html ending on Thursday, September 28th. The authors believe the Internet-Draft is ready for a WGLC and the chairs agree. The draft has been discussed visibly at IETF 114 and review feedback has been incorporated in -07. Please send your comments to the list and your assessment of whether or not it is ready to proceed to publication before September 28th. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] WGLC and Shepherd write-up concluded for draft-ietf-opsawg-sbom-access
Dear OPSAWG members, the chairs think consensus on this I-D is established and that it is ready to be submitted to IESG for publication. We'll let that assessment simmer here on the list for a few days before pushing the buttons, checking for pending comments from ADs and the list. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG Last Call for draft-ietf-opsawg-sbom-access-05
Dear authors and contributors, thank you for your hard work. As it seems that all existing issues have been resolve, we'll move the I-D to write-up in the datatracker. The resulting I-D can be found here: https://www.ietf.org/archive/id/draft-ietf-opsawg-sbom-access-11.html Also, a big thanks to Qin for stepping up as shepherd! For the OPSAWG co-chairs, Henk On 04.05.22 18:22, Henk Birkholz wrote: Dear OPSAWG members, as a reminder, today ends the WGLC for draft-ietf-opsawg-sbom-access-05. This is your last chance to add your comments to the list or an assessment of whether or not the draft is ready to proceed to publication. For the OPSAWG co-chairs, Henk On 01.05.22 19:27, Henk Birkholz wrote: Dear OPSAWG members, as a reminder, the WGLC for draft-ietf-opsawg-sbom-access-05 ends in *three days* at the end of May 4th. If you'd like to add your comments to the list or an assessment of whether or not the draft is ready to proceed to publication, please keep the deadline in mind. For the OPAWG co-chairs, Henk On 15.04.22 02:30, Henk Birkholz wrote: Dear OPSAWG members, please be aware that I introduced an inconsistency in the recent WGLC announcement. It is actually a period of *three weeks* to get your feedback in. I extended the time frame from two weeks due to the Eastern holidays occurring all over the EU. As a result, the deadline to send your comments to the list and your assessment of whether or not it is ready to proceed to publication effectively is *May 4th* and it is not terminating on April 27th already. There so no harm though in providing feedback before April 27th! :-) So don't stop doing that! Thanks Tom for pointing that out. Viele Grüße & a enjoy a inspiring Easter time, Henk On 12.04.22 13:15, Henk Birkholz wrote: Dear OPSAWG members, this email starts a three week period for a Working Group Last Call of > https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/05/ ending on Wednesday, April 27th. The authors believe the Internet-Draft is ready for a WGLC. The draft has been discussed at meetings, as well as on the list, and review feedback has been incorporated in -05. Please send your comments to the list and your assessment of whether or not it is ready to proceed to publication before April 27th. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ 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 Last Call for draft-ietf-opsawg-mud-tls-07
Dear authors and contributors, thank you for your hard work. As it seems that all existing issues have been resolve, we'll move the I-D to write-up in the datatracker. Also, thanks Thomas Fossati for stepping up as shepherd! For the OPSAWG co-chairs, Henk On 29.09.22 10:27, Henk Birkholz wrote: Dear OPSAWG members, this email concludes the first WGLC call for https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html. A few comments where raised. Authors/editors, please go ahead and address these as discussed on the list. For the OPSAWG co-chairs, Henk On 14.09.22 16:07, Henk Birkholz wrote: Dear OPSAWG members, this email starts a two week period for a Working Group Last Call of https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html ending on Thursday, September 28th. The authors believe the Internet-Draft is ready for a WGLC and the chairs agree. The draft has been discussed visibly at IETF 114 and review feedback has been incorporated in -07. Please send your comments to the list and your assessment of whether or not it is ready to proceed to publication before September 28th. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Call for shepherd for draft-ietf-opsawg-mud-tls
Dear OPSAWG members, I'd like to highlight the opportunity to become a shepherd for this I-D. If you'd like to get more involved in the IETF community, becoming a document shepherd is good way to get first hands-on experience. The chairs are happy to help, will support newcomers, and provide guidance, if required. Please contact the chairs (opsawg-cha...@ietf.org), if you are interested. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] IPR Call for draft-ietf-opsawg-mud-tls-07
Dear authors and contributors, as a reminder: please respond on-list as to whether or not you are aware of any IPR that pertains to draft-ietf-opsawg-mud-tls-07. 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, please also indicate whether or not this has been disclosed per IETF IPR rules (see RFCs 3669, 5378, and 8179). For the OPAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG Last Call for draft-ietf-opsawg-mud-tls-07
Dear OPSAWG members, this email concludes the first WGLC call for https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html. A few comments where raised. Authors/editors, please go ahead and address these as discussed on the list. For the OPSAWG co-chairs, Henk On 14.09.22 16:07, Henk Birkholz wrote: Dear OPSAWG members, this email starts a two week period for a Working Group Last Call of https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html ending on Thursday, September 28th. The authors believe the Internet-Draft is ready for a WGLC and the chairs agree. The draft has been discussed visibly at IETF 114 and review feedback has been incorporated in -07. Please send your comments to the list and your assessment of whether or not it is ready to proceed to publication before September 28th. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] WG Last Call for draft-ietf-opsawg-mud-tls-07
Dear OPSAWG members, this email starts a two week period for a Working Group Last Call of https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html ending on Thursday, September 28th. The authors believe the Internet-Draft is ready for a WGLC and the chairs agree. The draft has been discussed visibly at IETF 114 and review feedback has been incorporated in -07. Please send your comments to the list and your assessment of whether or not it is ready to proceed to publication before September 28th. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-09.txt
Hi Eliot, I think Tom was referring to this link: https://standards.iso.org/ittf/PubliclyAvailableStandards/c081870_ISO_IEC_5962_2021(E).zip Please excuse my perpetual latency. Viele Grüße, Henk On 13.09.22 12:26, Eliot Lear wrote: The only change from this version is the pointer to a free version of the SPDX specification. With this, I believe all issues have been addressed. Eliot On 13.09.22 12:24, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : Discovering and Retrieving Software Transparency and Vulnerability Information Authors : Eliot Lear Scott Rose Filename : draft-ietf-opsawg-sbom-access-09.txt Pages : 21 Date : 2022-09-13 Abstract: To improve cybersecurity posture, automation is necessary to locate what software is running on a device, whether that software has known vulnerabilities, and what, if any recommendations suppliers may have. This memo specifies a model to provide access to this information. It may optionally be discovered through manufacturer usage descriptions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sbom-access-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-sbom-access-09 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 ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-06.txt
Thanks Eliot, I've reviewed the changes and can confirm that the highlighted comments are addressed adequately. @OPSAWG: please comment, if you discover any open issues. While the secdir review is still in progress, we can make use of that time. For the OPSAWG co-chairs, Henk On 01.09.22 14:11, Eliot Lear wrote: Hi, The intent of this draft was to address all WGLC comments. I hope that we have. One major change based on Joe's comments: We moved from enums to identities in one case. In doing so we pulled out support for openc2, because it can easily be added back in later. Jean Camp asked for an archive node, so we added that. Please check my work. Eliot On 01.09.22 14:02, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : Discovering and Retrieving Software Transparency and Vulnerability Information Authors : Eliot Lear Scott Rose Filename : draft-ietf-opsawg-sbom-access-06.txt Pages : 21 Date : 2022-09-01 Abstract: To improve cybersecurity posture, automation is necessary to locate what software is running on a device, whether that software has known vulnerabilities, and what, if any recommendations suppliers may have. This memo specifies a model to provide access to this information. It may optionally be discovered through manufacturer usage descriptions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sbom-access-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-sbom-access-06 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 ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG Last Call for draft-ietf-opsawg-sbom-access-05
Dear OPSAWG members, as a reminder, today ends the WGLC for draft-ietf-opsawg-sbom-access-05. This is your last chance to add your comments to the list or an assessment of whether or not the draft is ready to proceed to publication. For the OPSAWG co-chairs, Henk On 01.05.22 19:27, Henk Birkholz wrote: Dear OPSAWG members, as a reminder, the WGLC for draft-ietf-opsawg-sbom-access-05 ends in *three days* at the end of May 4th. If you'd like to add your comments to the list or an assessment of whether or not the draft is ready to proceed to publication, please keep the deadline in mind. For the OPAWG co-chairs, Henk On 15.04.22 02:30, Henk Birkholz wrote: Dear OPSAWG members, please be aware that I introduced an inconsistency in the recent WGLC announcement. It is actually a period of *three weeks* to get your feedback in. I extended the time frame from two weeks due to the Eastern holidays occurring all over the EU. As a result, the deadline to send your comments to the list and your assessment of whether or not it is ready to proceed to publication effectively is *May 4th* and it is not terminating on April 27th already. There so no harm though in providing feedback before April 27th! :-) So don't stop doing that! Thanks Tom for pointing that out. Viele Grüße & a enjoy a inspiring Easter time, Henk On 12.04.22 13:15, Henk Birkholz wrote: Dear OPSAWG members, this email starts a three week period for a Working Group Last Call of > https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/05/ ending on Wednesday, April 27th. The authors believe the Internet-Draft is ready for a WGLC. The draft has been discussed at meetings, as well as on the list, and review feedback has been incorporated in -05. Please send your comments to the list and your assessment of whether or not it is ready to proceed to publication before April 27th. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] IPR Call for draft-ietf-opsawg-sbom-access-05
Dear authors and contributors, please respond on-list as to whether or not you are aware of any IPR that pertains to draft-ietf-opsawg-sbom-access-05. 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). For the OPAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG Last Call for draft-ietf-opsawg-sbom-access-05
Dear OPSAWG members, as a reminder, the WGLC for draft-ietf-opsawg-sbom-access-05 ends in *three days* at the end of May 4th. If you'd like to add your comments to the list or an assessment of whether or not the draft is ready to proceed to publication, please keep the deadline in mind. For the OPAWG co-chairs, Henk On 15.04.22 02:30, Henk Birkholz wrote: Dear OPSAWG members, please be aware that I introduced an inconsistency in the recent WGLC announcement. It is actually a period of *three weeks* to get your feedback in. I extended the time frame from two weeks due to the Eastern holidays occurring all over the EU. As a result, the deadline to send your comments to the list and your assessment of whether or not it is ready to proceed to publication effectively is *May 4th* and it is not terminating on April 27th already. There so no harm though in providing feedback before April 27th! :-) So don't stop doing that! Thanks Tom for pointing that out. Viele Grüße & a enjoy a inspiring Easter time, Henk On 12.04.22 13:15, Henk Birkholz wrote: Dear OPSAWG members, this email starts a three week period for a Working Group Last Call of > https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/05/ ending on Wednesday, April 27th. The authors believe the Internet-Draft is ready for a WGLC. The draft has been discussed at meetings, as well as on the list, and review feedback has been incorporated in -05. Please send your comments to the list and your assessment of whether or not it is ready to proceed to publication before April 27th. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG Last Call for draft-ietf-opsawg-sbom-access-05
Dear OPSAWG members, please be aware that I introduced an inconsistency in the recent WGLC announcement. It is actually a period of *three weeks* to get your feedback in. I extended the time frame from two weeks due to the Eastern holidays occurring all over the EU. As a result, the deadline to send your comments to the list and your assessment of whether or not it is ready to proceed to publication effectively is *May 4th* and it is not terminating on April 27th already. There so no harm though in providing feedback before April 27th! :-) So don't stop doing that! Thanks Tom for pointing that out. Viele Grüße & a enjoy a inspiring Easter time, Henk On 12.04.22 13:15, Henk Birkholz wrote: Dear OPSAWG members, this email starts a three week period for a Working Group Last Call of > https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/05/ ending on Wednesday, April 27th. The authors believe the Internet-Draft is ready for a WGLC. The draft has been discussed at meetings, as well as on the list, and review feedback has been incorporated in -05. Please send your comments to the list and your assessment of whether or not it is ready to proceed to publication before April 27th. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] WG Last Call for draft-ietf-opsawg-sbom-access-05
Dear OPSAWG members, this email starts a three week period for a Working Group Last Call of > https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/05/ ending on Wednesday, April 27th. The authors believe the Internet-Draft is ready for a WGLC. The draft has been discussed at meetings, as well as on the list, and review feedback has been incorporated in -05. Please send your comments to the list and your assessment of whether or not it is ready to proceed to publication before April 27th. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG Adoption Call for draft-lear-opsawg-ol-01
Hi all, as an update to my last reply: ISO 5962:2021 has been made a Publicly Available Standard by ISO's ITTF. https://standards.iso.org/ittf/PubliclyAvailableStandards/c081870_ISO_IEC_5962_2021(E).zip Viele Grüße, Henk On 04.10.21 22:56, Henk Birkholz wrote: Hi all, afaik, SPDX 2.2.1 exactly reflects ISO 5962:2021. The specification can be found here: https://github.com/spdx/spdx-spec Viele Grüße, Henk On 04.10.21 22:51, Michael Richardson wrote: Henk Birkholz wrote: > Dear OPSAWG members, > this starts a call for Working Group Adoption of >> https://datatracker.ietf.org/doc/html/draft-lear-opsawg-ol-01 > ending on Monday, October 18th. > As a reminder, this I-D describes an extension to MUD that allows MUD file > authors to specify ownership and licenses in the MUD files themselves. The > corresponding YANG augment defined can be used outside the scope of MUD as > well. I have read this version of the document and previous versions. I am happy to adopt it. I note that SPDX is now some ISO standard 5962:2021. At present, the ISO still seems to be charging for this document, despite having said they would not. I don't propose to change anything in the document to include "5962" in it. I do not believe that the ISO/IEC adheres to the IETF's open-stand.org principles. While spdx.org redirects to spdx.dev, it appears that: https://spdx.org/licenses/ and https://spdx.dev/licenses/ contain the same information, but with a different CSS. I prefer the one at spdx.org, but I imagine that it will not remain. -- Michael Richardson . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ___ 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] WG Adoption Call for draft-tuexen-opsawg-pcapng-03
Dear OPSAWG members, this email concludes the call for Working Group Adoption on https://datatracker.ietf.org/doc/html/draft-tuexen-opsawg-pcapng-03. We did not reach a critical mass of positive replies, but there were also no objections, and various elaborate comments (in addition to various comments on potential adoption in 2020). The chairs believe that this work is interesting to adopt, but we also have to make sure that there is enough commitment wrt contribution and review. Looking at a list of seven authors, it seems to me that there is enough involvement to advance this work in OPSAWG. My recommendation to the authors is to discuss the issue of review commitment at the IETF 112 meeting's OPSAWG session and we can go from there. For the OPSAWG co-chairs, Henk On 04.10.21 22:00, Henk Birkholz wrote: Dear OPSAWG members, this starts a call for Working Group Adoption of https://datatracker.ietf.org/doc/html/draft-tuexen-opsawg-pcapng-03 ending on Monday, October 18th. As a reminder, this I-D describes the PCAPng format - the successor of the PCAP format - retaining the established design patterns and adding new capabilities as well as a an extensibility feature. 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 Adoption Call for draft-gharris-opsawg-pcap-02
Dear OPSAWG members, this email concludes the call for Working Group Adoption on https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02. We received a minimal amount of positive replies, no objections, and a few elaborate comments. The chairs believe this I-D is ready for adoption and for the working group to work on. As the response was not overwhelming, I want to highlight that this is an extensive document that can only progress with sufficient review. Please bear in mind that some steady progress is required. Authors, please rename the I-D to draft-ietf-opsawg-pcap-00, keeping the content as is, and resubmit. For the OPSAWG co-chairs, Henk On 04.10.21 22:00, Henk Birkholz wrote: Dear OPSAWG members, this starts a call for Working Group Adoption of https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02 ending on Monday, October 18th. As a reminder, this I-D describes the current definition of the PCAP format that has been the industry's de-facto packet capture format since the 1980s. 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 Adoption Call for draft-tuexen-opsawg-pcapng-03
Dear OPSAWG members, this email *extends* the ongoing call for Working Group Adoption on https://datatracker.ietf.org/doc/html/draft-tuexen-opsawg-pcapng-03 until *Sunday, October 24th*. We did not reach a critical mass of positive replies - as a result, I'll grant a grace period until the end of the week. If you are interested in this work, please reply with your support on this list until *Sunday, October 24th*. For the OPSAWG co-chairs, Henk On 04.10.21 22:00, Henk Birkholz wrote: Dear OPSAWG members, this starts a call for Working Group Adoption of https://datatracker.ietf.org/doc/html/draft-tuexen-opsawg-pcapng-03 ending on Monday, October 18th. As a reminder, this I-D describes the PCAPng format - the successor of the PCAP format - retaining the established design patterns and adding new capabilities as well as a an extensibility feature. 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 Adoption Call for draft-gharris-opsawg-pcap-02
Dear OPSAWG members, this email *extends* the ongoing call for Working Group Adoption on https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02 until *Sunday, October 24th*. We did not reach a critical mass of positive replies - as a result, I'll grant a grace period until the end of the week. If you are interested in this work, please reply with your support on this list until *Sunday, October 24th*. For the OPSAWG co-chairs, Henk On 04.10.21 22:00, Henk Birkholz wrote: Dear OPSAWG members, this starts a call for Working Group Adoption of https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02 ending on Monday, October 18th. As a reminder, this I-D describes the current definition of the PCAP format that has been the industry's de-facto packet capture format since the 1980s. 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
Re: [OPSAWG] WG Adoption Call for draft-lear-opsawg-ol-01
Dear OPSAWG members, this email concludes the call for Working Group Adoption on https://datatracker.ietf.org/doc/html/draft-lear-opsawg-ol-01. We received a reasonable number of positive replies, no objections, and a few comments about consideration of instance data. The chairs believe this I-D is ready for adoption and for the working group to work on. Authors please rename the draft to be draft-ietf-opsawg-ol-00, keeping the content as is, and resubmit. Furthermore, please initiate a discussion about instance data scope on the list as the editors of this memo. For the OPSAWG co-chairs, Henk On 04.10.21 22:00, Henk Birkholz wrote: Dear OPSAWG members, this starts a call for Working Group Adoption of https://datatracker.ietf.org/doc/html/draft-lear-opsawg-ol-01 ending on Monday, October 18th. As a reminder, this I-D describes an extension to MUD that allows MUD file authors to specify ownership and licenses in the MUD files themselves. The corresponding YANG augment defined can be used outside the scope of MUD as well. 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 Adoption Call for draft-lear-opsawg-ol-01
Hi all, afaik, SPDX 2.2.1 exactly reflects ISO 5962:2021. The specification can be found here: https://github.com/spdx/spdx-spec Viele Grüße, Henk On 04.10.21 22:51, Michael Richardson wrote: Henk Birkholz wrote: > Dear OPSAWG members, > this starts a call for Working Group Adoption of >> https://datatracker.ietf.org/doc/html/draft-lear-opsawg-ol-01 > ending on Monday, October 18th. > As a reminder, this I-D describes an extension to MUD that allows MUD file > authors to specify ownership and licenses in the MUD files themselves. The > corresponding YANG augment defined can be used outside the scope of MUD as > well. I have read this version of the document and previous versions. I am happy to adopt it. I note that SPDX is now some ISO standard 5962:2021. At present, the ISO still seems to be charging for this document, despite having said they would not. I don't propose to change anything in the document to include "5962" in it. I do not believe that the ISO/IEC adheres to the IETF's open-stand.org principles. While spdx.org redirects to spdx.dev, it appears that: https://spdx.org/licenses/ and https://spdx.dev/licenses/ contain the same information, but with a different CSS. I prefer the one at spdx.org, but I imagine that it will not remain. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ___ 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] WG Adoption Call for draft-tuexen-opsawg-pcapng-03
Dear OPSAWG members, this starts a call for Working Group Adoption of https://datatracker.ietf.org/doc/html/draft-tuexen-opsawg-pcapng-03 ending on Monday, October 18th. As a reminder, this I-D describes the PCAPng format - the successor of the PCAP format - retaining the established design patterns and adding new capabilities as well as a an extensibility feature. 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] WG Adoption Call for draft-gharris-opsawg-pcap-02
Dear OPSAWG members, this starts a call for Working Group Adoption of https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02 ending on Monday, October 18th. As a reminder, this I-D describes the current definition of the PCAP format that has been the industry's de-facto packet capture format since the 1980s. 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] WG Adoption Call for draft-lear-opsawg-ol-01
Dear OPSAWG members, this starts a call for Working Group Adoption of https://datatracker.ietf.org/doc/html/draft-lear-opsawg-ol-01 ending on Monday, October 18th. As a reminder, this I-D describes an extension to MUD that allows MUD file authors to specify ownership and licenses in the MUD files themselves. The corresponding YANG augment defined can be used outside the scope of MUD as well. 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] NomCom 2021-2022 Call for Volunteers
Dear OPSAWG members, please note that the NomCom 2021-2022 Call for Volunteers started today. The IETF NomCom appoints people to fill the open slots on the IETF LLC, IETF Trust, the IAB, and the IESG. Ten voting members for the NomCom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The call's duration is 4 weeks and ends before 23:59 UTC on Wednesday June 23, 2021. Further details can be found in BCP 10 (RFC 8713) and of course the announcement email: https://mailarchive.ietf.org/arch/msg/ietf-announce/T_WVH96pH-5QVTRqd0yTT1TaPaU/ Viele Grüße, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG Adoption Call for draft-claise-opsawg-service-assurance-yang-07
Dear OPSAWG members, this email concludes the call for Working Group Adoption on https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-yang-07. We received a large number of positive replies, no objections, and various significant comments. The chairs believe this I-D is ready for adoption and for the working group to work on. Authors, please rename the I-D to draft-ietf-opsawg-service-assurance-yang-00, keeping the content as is, and resubmit. For the OPSAWG co-chairs, Henk On 27.04.21 20:01, Henk Birkholz wrote: Dear OPSAWG members, this starts a call for Working Group Adoption for https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-yang-07 ending on Tuesday, May 18th. As a reminder, this I-D describes YANG modules intended to facilitate the aggregation of an assurance graph about the health of services and sub-services in a system of interconnected network devices. To achieve that, the I-D defines modules for graph updates about (sub-)services and corresponding health and symptom knowledge acquired via assurance telemetry. 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 Adoption Call for draft-claise-opsawg-service-assurance-architecture-05
Dear OPSAWG members, this email concludes the call for Working Group Adoption on https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-architecture-05. We received a large number of positive replies, no objections, and various significant comments. The chairs believe this I-D is ready for adoption and for the working group to work on. Authors, please rename the I-D to draft-ietf-opsawg-service-assurance-architecture-00, keeping the content as is, and resubmit. Additionally, please continue to discuss the scope of this document and its relationship to IBN as well as other topics in an open discussion on the list. As highlighted by the comments, service assurance and closed loop automation can be in support of various network-related requirements. Scoping decisions to that regard will have an impact on the shape of this document. For the OPSAWG co-chairs, Henk On 27.04.21 20:00, Henk Birkholz wrote: Dear OPSAWG members, this starts a call for Working Group Adoption for https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-architecture-05 ending on Tuesday, May 18th. As a reminder, this I-D describes the health of an interconnected system of network devices and (sub-)services located in that system. A degraded health status is explained via symptom descriptions and the resulting interconnected knowledge is aggregated in an assurance graph. 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] Sbom versioning - draft-ietf-opawg-sbom-access
I was under the assumption that the thing that is immutable is the MUD URL right (e.g. if it resides in an IDevID)? Is a specific MUD URL statically linked to one specific MUD file? If not, you could update the MUD file to always point to the latest version (first, other linked via that MUD file maybe) - or would that defeat some purpose that I am missing or forgot? On 29.04.21 19:42, Eliot Lear wrote: The MUD file can certainly point to a single version, but if the MUD file is obtained through some immutable mechanism (device certificate) then the version info has to come from somewhere else. Eliot On 29 Apr 2021, at 19:39, Henk Birkholz wrote: Hi Eliot, shouldn't be the MUD file (that is maintained by an appropriate authority, hopefully) in charge of that? The default SBOM retrievable via the MUD file could therefore always be the latest version? Older versions should be discoverable via the MUD file or mechanism around that? Viele Grüße, Henk (no hat) On 29.04.21 19:15, Eliot Lear wrote: Soo… I think this is a bit of an interesting question. If an SBOM lives in the cloud somewhere, and it is associated to a version string, how do you know which one is the LATEST version? If there is semantic meaning, then the inventory management system has to be able to determine that. The simple approach would be for the array to be ordered, but I am not a fan of these sorts of implicit mechanisms. Another approach would be to index on a date rather than a version. Eliot On 29 Apr 2021, at 17:16, Dick Brooks wrote: Thanks, Eliot. I was just expressing my preferred method of versioning. As long as the spec doesn't disallow semantic versioning, then I'm ok. Thanks, Dick Brooks Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: d...@reliableenergyanalytics.com Tel: +1 978-696-1788 -Original Message- From: Eliot Lear Sent: Thursday, April 29, 2021 10:25 AM To: Dick Brooks Cc: Eliot Lear ; opsawg Subject: Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access Hi Dick When you say semantic versioning, what do you have in mind? Keep in mind that we want to be neutral to format. Eliot On 29 Apr 2021, at 15:30, Dick Brooks wrote: Eliot, Here is the information I use in SAG-PM to discover and retrieve an SBOM; hope this helps. Version is a must have attribute of the product definition to retrieve the correct SBOM. Semantic versioning is preferred: MAJOR.MINOR.PATCH Reliable Energy Analytics LLC SAG-PM (TM) 1.1.0 https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml.sig;>https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml https://softwareassuranceguardian.com/sag-pm.zip Y N 2021-04-23T15:57:00 Thanks, Dick Brooks Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: d...@reliableenergyanalytics.com Tel: +1 978-696-1788 -Original Message- From: OPSAWG On Behalf Of Eliot Lear Sent: Thursday, April 29, 2021 9:15 AM To: opsawg Subject: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access The current draft allows for multiple SBOM versions. The reason for this is that if a MUD URL is used, and the SBOM is contained on a server somewhere, one would need to use out of band information to determine software versions. However, this doesn’t make sense if you are retrieving the SBOM from the device. Therefore, the model needs to change a bit. We want a “when” clause somewhere for the version info, but this introduces an new challenge: as currently listed the version-info field is an index. That has to go. So… what I think we want to do is invert the list along the following lines: - choice sbom-type: case url: list sboms leaf version-info leaf sbom-url case local-uri: type empty - the whole thing is constructed using .well-known/sbom case contact-info: as before but without versioning Anyway, this is what I am thinking. Thoughts? Eliot ___ 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] Sbom versioning - draft-ietf-opawg-sbom-access
Hi Eliot, shouldn't be the MUD file (that is maintained by an appropriate authority, hopefully) in charge of that? The default SBOM retrievable via the MUD file could therefore always be the latest version? Older versions should be discoverable via the MUD file or mechanism around that? Viele Grüße, Henk (no hat) On 29.04.21 19:15, Eliot Lear wrote: Soo… I think this is a bit of an interesting question. If an SBOM lives in the cloud somewhere, and it is associated to a version string, how do you know which one is the LATEST version? If there is semantic meaning, then the inventory management system has to be able to determine that. The simple approach would be for the array to be ordered, but I am not a fan of these sorts of implicit mechanisms. Another approach would be to index on a date rather than a version. Eliot On 29 Apr 2021, at 17:16, Dick Brooks wrote: Thanks, Eliot. I was just expressing my preferred method of versioning. As long as the spec doesn't disallow semantic versioning, then I'm ok. Thanks, Dick Brooks Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: d...@reliableenergyanalytics.com Tel: +1 978-696-1788 -Original Message- From: Eliot Lear Sent: Thursday, April 29, 2021 10:25 AM To: Dick Brooks Cc: Eliot Lear ; opsawg Subject: Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access Hi Dick When you say semantic versioning, what do you have in mind? Keep in mind that we want to be neutral to format. Eliot On 29 Apr 2021, at 15:30, Dick Brooks wrote: Eliot, Here is the information I use in SAG-PM to discover and retrieve an SBOM; hope this helps. Version is a must have attribute of the product definition to retrieve the correct SBOM. Semantic versioning is preferred: MAJOR.MINOR.PATCH Reliable Energy Analytics LLC SAG-PM (TM) 1.1.0 https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml.sig;>https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml https://softwareassuranceguardian.com/sag-pm.zip Y N 2021-04-23T15:57:00 Thanks, Dick Brooks Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: d...@reliableenergyanalytics.com Tel: +1 978-696-1788 -Original Message- From: OPSAWG On Behalf Of Eliot Lear Sent: Thursday, April 29, 2021 9:15 AM To: opsawg Subject: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access The current draft allows for multiple SBOM versions. The reason for this is that if a MUD URL is used, and the SBOM is contained on a server somewhere, one would need to use out of band information to determine software versions. However, this doesn’t make sense if you are retrieving the SBOM from the device. Therefore, the model needs to change a bit. We want a “when” clause somewhere for the version info, but this introduces an new challenge: as currently listed the version-info field is an index. That has to go. So… what I think we want to do is invert the list along the following lines: - choice sbom-type: case url: list sboms leaf version-info leaf sbom-url case local-uri: type empty - the whole thing is constructed using .well-known/sbom case contact-info: as before but without versioning Anyway, this is what I am thinking. Thoughts? Eliot ___ 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
[OPSAWG] WG Adoption Call for draft-claise-opsawg-service-assurance-yang-07
Dear OPSAWG members, this starts a call for Working Group Adoption for https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-yang-07 ending on Tuesday, May 18th. As a reminder, this I-D describes YANG modules intended to facilitate the aggregation of an assurance graph about the health of services and sub-services in a system of interconnected network devices. To achieve that, the I-D defines modules for graph updates about (sub-)services and corresponding health and symptom knowledge acquired via assurance telemetry. 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] WG Adoption Call for draft-claise-opsawg-service-assurance-architecture-05
Dear OPSAWG members, this starts a call for Working Group Adoption for https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-architecture-05 ending on Tuesday, May 18th. As a reminder, this I-D describes the health of an interconnected system of network devices and (sub-)services located in that system. A degraded health status is explained via symptom descriptions and the resulting interconnected knowledge is aggregated in an assurance graph. 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
Re: [OPSAWG] WG adoption call on draft-richardson-opsawg-mud-acceptable-urls-03
Hi Tom, thanks! On second thought, why not use draft-ietf-opsawg-mud-acceptable-urls-00 instead :o) Viele Grüße, Henk On 26.01.21 17:53, tom petch wrote: From: OPSAWG on behalf of Henk Birkholz Sent: 26 January 2021 15:26 Dear OPSAWG members, this email concludes the call for Working Group Adoption on https://tools.ietf.org/html/draft-richardson-opsawg-mud-iot-dns-considerations-03. We received a reasonable number of positive replies, no objections, and a set of comments. The chairs believe this I-D is ready for adoption and for the working group to work on. Authors please rename the I-D to draft-ietf-opsawg-mud-iot-dns-considerations-00, keeping the content as is, and resubmit. Is that really the name you want it to bee? Tom Petch For the OPSAWG co-chairs, Henk On 04.01.21 19:05, Henk Birkholz wrote: Dear OPSAWG members, this starts a call for Working Group Adoption on https://tools.ietf.org/html/draft-richardson-opsawg-mud-acceptable-urls-03 ending on Monday, January 25. As a reminder, this I-D describes ways to update (if possible) MUD URIs as specified in RFC8520 Manufacturer Usage Description (MUD) in a secure and acceptable manner. 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 ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG adoption call on draft-richardson-opsawg-mud-acceptable-urls-03
Dear OPSAWG members, this email concludes the call for Working Group Adoption on https://tools.ietf.org/html/draft-richardson-opsawg-mud-iot-dns-considerations-03. We received a reasonable number of positive replies, no objections, and a set of comments. The chairs believe this I-D is ready for adoption and for the working group to work on. Authors please rename the I-D to draft-ietf-opsawg-mud-iot-dns-considerations-00, keeping the content as is, and resubmit. For the OPSAWG co-chairs, Henk On 04.01.21 19:05, Henk Birkholz wrote: Dear OPSAWG members, this starts a call for Working Group Adoption on https://tools.ietf.org/html/draft-richardson-opsawg-mud-acceptable-urls-03 ending on Monday, January 25. As a reminder, this I-D describes ways to update (if possible) MUD URIs as specified in RFC8520 Manufacturer Usage Description (MUD) in a secure and acceptable manner. 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 Adoption Call on draft-richardson-opsawg-mud-iot-dns-considerations-03
Dear OPSAWG members, this email concludes the call for Working Group Adoption on https://tools.ietf.org/html/draft-richardson-opsawg-mud-iot-dns-considerations-03. We received a reasonable number of positive replies, no objections, and some significant comments. The chairs believe this I-D is ready for adoption and for the working group to work on. Authors please rename the I-D to draft-ietf-opsawg-mud-iot-dns-considerations-00, keeping the content as is, and resubmit. For the OPSAWG co-chairs, Henk On 04.01.21 19:03, Henk Birkholz wrote: Dear OPSAWG members, this starts a call for Working Group Adoption on https://tools.ietf.org/html/draft-richardson-opsawg-mud-iot-dns-considerations-03 ending on Monday, January 25. As a reminder, this I-D describes potential issues and concerns regarding the use of DNS names and IP addressed with RFC8520 Manufacturer Usage Description (MUD) in support of device access. 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 Adoption Call on draft-lear-opsawg-sbom-access-00
Hi Eliot, if you don't mind, I'd prefer a simple rename for -00 followed by an -01 that addresses the comments from Wei. Looking at Wei's input, I agree that the result should be rather non-controversial (and can be further addressed in the working group proceedings, if the need arises - I'll keep an eye out for that). Viele Grüße, Henk On 26.01.21 15:17, Eliot Lear wrote: Hi Henk, I’ve made a handful of changes in the source to address the comments of Wei Pan. Would you mind if I post that and allow for the possibility that we will back them out if necessary (I think they are non-controversial). Eliot On 26 Jan 2021, at 14:03, Henk Birkholz wrote: Dear OPSAWG members, this email concludes the call for Working Group Adoption on https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00. We received a reasonable number of positive replies, no objections, and various significant comments. The chairs believe this I-D is ready for adoption and for the working group to work on. Authors please rename the draft to be draft-ietf-opsawg-sbom-access-00, keeping the content as is, and resubmit. For the OPSAWG co-chairs, Henk On 04.01.21 17:10, Henk Birkholz wrote: Dear OPSAWG members, this starts a call for Working Group Adoption on https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00 ending on Monday, January 25. As a reminder, this I-D describes different ways to acquire Software Bills of Material (SBOM) about distinguishable managed entities. The work was updated by the authors on October 13th and now elaborates on three ways SBOM can be found, including a MUD URI as one of the options. 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 ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG Adoption Call on draft-lear-opsawg-sbom-access-00
Dear OPSAWG members, this email concludes the call for Working Group Adoption on https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00. We received a reasonable number of positive replies, no objections, and various significant comments. The chairs believe this I-D is ready for adoption and for the working group to work on. Authors please rename the draft to be draft-ietf-opsawg-sbom-access-00, keeping the content as is, and resubmit. For the OPSAWG co-chairs, Henk On 04.01.21 17:10, Henk Birkholz wrote: Dear OPSAWG members, this starts a call for Working Group Adoption on https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00 ending on Monday, January 25. As a reminder, this I-D describes different ways to acquire Software Bills of Material (SBOM) about distinguishable managed entities. The work was updated by the authors on October 13th and now elaborates on three ways SBOM can be found, including a MUD URI as one of the options. 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
[OPSAWG] Final day of three ongoing WG Adoption Calls
Dear OPSAWG members, as a reminder, today is the final day of three ongoing calls for adoption: I-D.lear-opsawg-sbom-access, I-D.richardson-opsawg-mud-iot-dns-considerations, and I-D.richardson-opsawg-mud-acceptable-urls. For the OPAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: WG Adoption Call on draft-lear-opsawg-sbom-access-00
Hi Dick, exactly. Now it seems to me, there might be some dependencies on "sbom type definitions" here. What now springs to my mind are the questions: If there are media-types or corresponding content-formats required to be expressed in headers in order to make this work, (1) where are these specified and (2) where are these expected be registered? Viele Grüße, Henk On 05.01.21 20:04, Dick Brooks wrote: Thanks, Henk, you raise a good question. I guess it depends: If the goal is to ensure interoperability of SBOM data communicated via an OPSWAG solution, that only exchanges SBOM's then I would imagine that we would need to define which SBOM payloads are supported, to ensure interoperability. If the intent of OPSWAG is to send any type of payload labelled as "SBOM content" with mutually agreed to payloads, then I would agree with you. I view this "tell them what is in the package", very similar to how S/MIME works. For example, when I worked in RFC 1767, EDI over the Internet, we assigned different S/MIME content types for the different type of EDI payloads that could be exchanged (and parsed), one of the options is "consent". Maybe OPSWAG should include something similar. I refer you to this section in the I-D: 1.2. SBOM formats There are multiple ways to express an SBOM. When these are retrieved either directly from the device or directly from a web server, "tools will need to observe the content-type header to determine precisely which format is being transmitted". Because IoT devices in particular have limited capabilities, use of a specific Accept: header in HTTP or the Accept Option in CoAP is NOT RECOMMENDED. Instead, backend tooling MUST silently discard SBOM information sent with a media type that is not understood. Thanks, Dick Brooks Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: d...@reliableenergyanalytics.com Tel: +1 978-696-1788 -Original Message- From: Henk Birkholz Sent: Tuesday, January 05, 2021 1:22 PM To: Dick Brooks ; 'Christopher Gates' ; opsawg@ietf.org Cc: Friedman, Allan Subject: Re: [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: WG Adoption Call on draft-lear-opsawg-sbom-access-00 Hi Dick, this is Henk with no hats on. I am not sure how useful it is to make "formats" an exclusive list here. Following the evolution of SBOM work in NTIA (and in extension in CISQ), it seems to me that the focus starts to move into the direction of information models first and that actual format(/serializations/encodings) are starting to be step two. Certainly, SWID semantics are only in the scope of the artifact domain and don't cover the defects domain and only some of the chains of provenance domain. That is why stand-alone SWID are rather minimal SBOM (just a list of (intended) artifacts). In any case, I was under the impression that the I-D is format agnostic and that the references are expositional. Is that maybe an underlying point to discuss here? Viele Grüße, Henk On 05.01.21 16:51, Dick Brooks wrote: I concur with Chris. I’ve heard reports of people trying to use SWID to communicate SBOM information and they are having to make some “brave” assumptions in the process. SPDX and CycloneDX seem to be the only viable SBOM formats, based on my testing experience with both formats. There remain several issues on naming and identification conventions. A lot of the challenges I’ve experienced could be addressed if NIST NVD and NTIA SBOM parties could reach an agreement on how names/identifiers will be represented in their respective domains. It would only require a few elements to be agreed to, like Publisher name, Product name and Version identifier to make an impactful improvement in vulnerability search results, using SBOM data as inputs. Thanks, Dick Brooks */Never trust software, always verify and report! <https://reliableenergyanalytics.com/products>/* ™ http://www.reliableenergyanalytics.com <http://www.reliableenergyanalytics.com/> Email: d...@reliableenergyanalytics.com <mailto:d...@reliableenergyanalytics.com> Tel: +1 978-696-1788 *From:* OPSAWG *On Behalf Of *Christopher Gates *Sent:* Tuesday, January 05, 2021 10:27 AM *To:* opsawg@ietf.org *Subject:* [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: WG Adoption Call on draft-lear-opsawg-sbom-access-00 -- Forwarded Message -- From: "Christopher Gates" mailto:chris.ga...@velentium.com>> To: "Eliot Lear" mailto:l...@cisco.com>>; "ntia-sbom-fram...@cert.org <mailto:ntia-sbom-fram...@cert.org>" mailto:ntia-sbom-fram...@cert.org>> Sent: 1/4/2021 2:48:51 PM Subject: Re: [ntia-sbom-framing] Fwd: [OPSAWG] WG Adoption Call on draft-lear-opsawg-sbom-access-00 Eliot, I joined the IETF WG, and I have some feedback A "SWID tag" isn't
Re: [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: WG Adoption Call on draft-lear-opsawg-sbom-access-00
Adoption Call on draft-lear-opsawg-sbom-access-00 FYI- this is your opportunity to contribute to the IETF. If you think sharing of SBOMs is important, this is a *starting point* for the IETF to begin work on that aspect, not an end point. Please feel free to contribute by joining the opsawg IETF list at https://www.ietf.org/mailman/listinfo/opsawg. Eliot Begin forwarded message: *From: *Henk Birkholz mailto:henk.birkh...@sit.fraunhofer.de>> *Subject: [OPSAWG] ****WG Adoption Call on draft-lear-opsawg-sbom-access-00* *Date: *4 January 2021 at 17:10:19 CET *To: *opsawg mailto:opsawg@ietf.org>> Dear OPSAWG members, this starts a call for Working Group Adoption on https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00 ending on Monday, January 25. As a reminder, this I-D describes different ways to acquire Software Bills of Material (SBOM) about distinguishable managed entities. The work was updated by the authors on October 13th and now elaborates on three ways SBOM can be found, including a MUD URI as one of the options. 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 <mailto:OPSAWG@ietf.org> https://www.ietf.org/mailman/listinfo/opsawg Disclaimer: The information and attachments transmitted by this e-mail are proprietary to Velentium, LLC and the information and attachments may be confidential and legally protected under applicable law and are intended for use only by the individual or entity to whom it was addressed. If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message and attachments is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and delete this message from your system immediately hereafter. ___ 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] WG adoption call on draft-richardson-opsawg-mud-acceptable-urls-03
Dear OPSAWG members, this starts a call for Working Group Adoption on https://tools.ietf.org/html/draft-richardson-opsawg-mud-acceptable-urls-03 ending on Monday, January 25. As a reminder, this I-D describes ways to update (if possible) MUD URIs as specified in RFC8520 Manufacturer Usage Description (MUD) in a secure and acceptable manner. 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] WG Adoption Call on draft-richardson-opsawg-mud-iot-dns-considerations-03
Dear OPSAWG members, this starts a call for Working Group Adoption on https://tools.ietf.org/html/draft-richardson-opsawg-mud-iot-dns-considerations-03 ending on Monday, January 25. As a reminder, this I-D describes potential issues and concerns regarding the use of DNS names and IP addressed with RFC8520 Manufacturer Usage Description (MUD) in support of device access. 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] WG Adoption Call on draft-lear-opsawg-sbom-access-00
Dear OPSAWG members, this starts a call for Working Group Adoption on https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00 ending on Monday, January 25. As a reminder, this I-D describes different ways to acquire Software Bills of Material (SBOM) about distinguishable managed entities. The work was updated by the authors on October 13th and now elaborates on three ways SBOM can be found, including a MUD URI as one of the options. 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
Re: [OPSAWG] Can we please adopt draft-tuexen-opsawg-pcapng?
YANG set a pretty solid IETF precedence here. As an individual, I'd +1 a too late here. On 12.11.20 00:40, Michael Richardson wrote: Brian E Carpenter wrote: > On 12-Nov-20 10:47, Eliot Lear wrote: >> We didn’t use the ISE for JSON. Why should we use it here? > I have no idea what the arguments were for JSON. Carsten already stated > why the Independent Stream is appropriate for PCAPNG: "PCAPNG is a done > deal." So there's nothing non-editorial to discuss. Waste of WG time. Actually, I was going to just go that way, and said so to Eliot on Monday (?!), and then he posted the message that started the thread. > If there's a PCAPNGng proposal, bring it here by all means. Actually, one thing the WG could do is to provide a slightly more sensible name, as "NG" is always in the future. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ___ 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] Henk Birkholz as third OPSAWG chair
Hi Rob et al, thanks for having me! I intend to move from being a burden to being a help in the near future, of course. Thanks also to Joe and Tianran for helping me to move from one side to the other :-) Viele Grüße, Henk On 11.09.20 18:37, Joe Clarke (jclarke) wrote: Welcome, Henk! It’s great to have you onboard. I hope you’ll be able to join us at the virtual 109 meeting for a proper introduction. Joe On Sep 11, 2020, at 12:35, Rob Wilton (rwilton) wrote: Dear all, I am happy to announce that Henk Birkholz has agreed to serve as a third OPSAWG WG chair to help with the current workload and gain some chair experience. Please welcome Henk to OPSAWG. Kind regards, Rob ___ 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] some comments and thoughts on mud-sbom and sbom-type
Just to be really sure: invoke implies executables and not code fragments, yes? If you mean executables that would be the SAM scope of SWID then, I think. Why do you think that this has not been explored? I was under the impression that this is currently being covered in the SBOM WGs out there. On 18.08.20 15:55, Eliot Lear wrote: "code being placed in service" Does that refer to a software creation process or a packaging process, or both? (or... something entirely different that I did not get) Neither. The code may be on the box already, but at all not invoked. Regards, Eliot ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] some comments and thoughts on mud-sbom and sbom-type
Hi Eliot, replying to a single item below. On 18.08.20 15:18, Eliot Lear wrote: Perhaps. I can’t say. We’re going to need some operational experience. There are a number of use cases in the IoT field where you plug in different components that require different software loads. One aspect of SBOM, by the way, that hasn’t been explored is the difference between software being installed and the code being placed in service. Particularly drivers and supporting user-level software. "code being placed in service" Does that refer to a software creation process or a packaging process, or both? (or... something entirely different that I did not get) Viele Grüße, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] IoT-DIR early review of draft-ietf-opsawg-mud-08
Hello Eliot, thank you for your fast feedback! I still have some comments and questions for another round, though. I hope that is okay - please see comments in-line. Viele Grüße, Henk On 08/30/2017 09:56 AM, Eliot Lear wrote: Hi Henk and thanks very much for your review. Please see below. On 8/29/17 11:40 PM, Henk Birkholz wrote: # IoT-DIR Early Review of I-D.ietf-opsawg-mud-08 ## Draft Summary This draft defines a canonical way to compose an URI that points to a specific resource called a MUD file. A MUD file is a text resource that contains imperative guidance in the form of YANG-based ACL policies represented in JSON. The imperative guidance is intended to be applied to things that can be identified by the segments of the MUD URI via a specific controller. The version of MUD is a component (segment) of the MUD URI and there are three examples in what to embed a MUD URI in (DHCP option, X.509 extension, and LLDP extension). ## Comments on General Topics This draft could be a significant step towards to self-descriptiveness of things. Constrained things might require imperative guidance or declarative guidance in order to be managed appropriately - which in includes aspects, such as isolation, clustering, service/capability discovery/exposure, and therefore security automation in general. In a lot of usage scenarios, it might not be feasible to store that guidance on the thing itself and MUD URI could be a solution to support a lot of vendor supplied information, such as reference integrity measurements, intended composition of composite devices, etc. Ok, but a cautionary note: this draft intentionally focuses NOT on giving the Thing guidance but on giving the *network* guidance. That isn't to say that Things couldn't derive guidance from extensions to the model (we'll talk about that below), but at the moment, the pain point is protecting them. This has to be clearly stated in the abstract and the introduction, I think. From my point of view, filter rules that are disabler and enabler of communication are a very specific subset of imperative network guidance, which are a distinct subset of the the usage descriptions a manufacturer would want to provide for a thing. To give a specific example: the passage "These devices therefore have a purpose to their use. By definition, therefore, all other purposes are NOT intended." is basically mirroring the definition of verifying if a thing is a Trusted System (see RFC4949), which can require, for example, reference integrity measurements (RIM) to enable integrity appraisal or Security Profiles to enable enforcement. But as you state, these are out of the scope of the document. I would propose to compose an abstract and introduction that is limited to what MUD is intended to do - to provide ACL for a specific class of devices - up front. because the architecture of your solution would be able to address a lot of complementary requirements that are explicitly not in scope, as it seems. ### Scope of Application On one hand, this drafts limits the potential usage of the MUD architecture to the use of one specific branch of YANG modules regarding ACL policies. There is no way to express other manufacture usage description "information-types" or "content-types" on a fundamental level and section 13 specifically states that "coupled with the fact that we have also chosen to leverage existing mechanisms, we are left with no ability to negotiate extensions and a limited desire for those extensions in any event." Creating augments for the metainfo container as it is also described in Section 13, on the other hand, allows for virtually any kind of information to be expressed and conveyed via a MUD file, but on a semantic level that seems to be a bit perplexing. This comment is not intended to question the feasibility of the technical approach - which is okay - but more taking into account the principle of least surprise. Hence, a strong proposal - in respect to the already included universal extension mechanism - to consider: * aligning ACL content and "other" content on the same semantic level in the YANG module, and * maybe indicating the corresponding semantics of the MUD file in the MUD URI itself. On the first point, that is precisely the intent of the previous reorg, to demote, if you will, access control so that other mechanisms can be employed. I'll speak more to this below. Maybe an example on how to include a trivial non-ACL-focussed extension into the module via an (exemplary/bogus) augment would clarify how to include "other" content in a MUD file. A corresponding example of a JSON instance (MUD file) that then includes content defined by the augment would also be beneficial, I think. Would that be okay? On the second point, one reason for referencing information is so that the underlying information can change as needed without
[OPSAWG] IoT-DIR early review of draft-ietf-opsawg-mud-08
Reviewer: Henk Birkholz Review result: Has Issues Hi, I am the assigned IoT-DIR reviewer for this document's early review. Please find my comments in kramdown below. Viele Grüße, Henk # IoT-DIR Early Review of I-D.ietf-opsawg-mud-08 ## Draft Summary This draft defines a canonical way to compose an URI that points to a specific resource called a MUD file. A MUD file is a text resource that contains imperative guidance in the form of YANG-based ACL policies represented in JSON. The imperative guidance is intended to be applied to things that can be identified by the segments of the MUD URI via a specific controller. The version of MUD is a component (segment) of the MUD URI and there are three examples in what to embed a MUD URI in (DHCP option, X.509 extension, and LLDP extension). ## Comments on General Topics This draft could be a significant step towards to self-descriptiveness of things. Constrained things might require imperative guidance or declarative guidance in order to be managed appropriately - which in includes aspects, such as isolation, clustering, service/capability discovery/exposure, and therefore security automation in general. In a lot of usage scenarios, it might not be feasible to store that guidance on the thing itself and MUD URI could be a solution to support a lot of vendor supplied information, such as reference integrity measurements, intended composition of composite devices, etc. ### Scope of Application On one hand, this drafts limits the potential usage of the MUD architecture to the use of one specific branch of YANG modules regarding ACL policies. There is no way to express other manufacture usage description "information-types" or "content-types" on a fundamental level and section 13 specifically states that "coupled with the fact that we have also chosen to leverage existing mechanisms, we are left with no ability to negotiate extensions and a limited desire for those extensions in any event." Creating augments for the metainfo container as it is also described in Section 13, on the other hand, allows for virtually any kind of information to be expressed and conveyed via a MUD file, but on a semantic level that seems to be a bit perplexing. This comment is not intended to question the feasibility of the technical approach - which is okay - but more taking into account the principle of least surprise. Hence, a strong proposal - in respect to the already included universal extension mechanism - to consider: * aligning ACL content and "other" content on the same semantic level in the YANG module, and * maybe indicating the corresponding semantics of the MUD file in the MUD URI itself. ### Intended & Allowed Representations/Formats The assumption is that neither the MUD controller nor the server serving the MUD files are constrained devices. The things that the imperative guidance is intended to address can be constrained devices. YANG modules are used to create the MUD files and the representation in the MUD files is JSON. In the scope of the extensibility feature highlighted, is it intended that every MUD file must contain content that relates to the structure of a YANG module (or are there other data models for data at rest planned for)? Is JSON intended to be the only allowed representation used for the representation of content in MUD files (a question in respect to the CBOR-based CoMI draft in the CORE WG)? ### Segment "mud-rev" There seems to be conflicting definitions about the semantic of the segment "mud-rev": Section "5. What does a MUD URL look like?" states that a "mud-rev signifies the version of the manufacturer usage description file" and "this memo specifies "v1" of that file". The passages quoted here seem to imply that mud-rev is about the instance of JSON that is the content of the MUD file. Section "13. Extensibility" though states "at a coarse grain, a protocol version is included in a MUD URL. This memo specifies MUD version 1. Any and all changes are entertained when this version is bumped.", which implies that mud-rev is intended to state the version of the MUD protocol and probably the respective YANG module(s). Probably, you want both? Most certainly, this has to be clarified. ### Segment "model" Every device typically is a composite. Similarly, the hardware device-model identifier is a potential composite of device-type, device-model & device-version (and probably even more). The text is very vague on this part, maybe deliberatively so because the authors do not want to prescribe how to compose the string that constitutes the model segment - but a bit more guidance on what this typically means and what could be caveats if you concatenate this potentially very complex identifier into a single string is stro
