Re: [OPSAWG] [Fwd: Your thoughts on draft-richardson-mud-qrcode]
Hi Michael, I am sorry for missing that mail. Now we have IOTOPS for more bandwidth to discussion on MUD. I think it would be a good idea to collect more interest in IOTOPS, and bring to OPSAWG. Tianran -Original Message- From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Michael Richardson Sent: Wednesday, March 17, 2021 4:17 AM To: rfc-...@rfc-editor.org; opsawg-cha...@ietf.org; opsawg@ietf.org Subject: Re: [OPSAWG] [Fwd: Your thoughts on draft-richardson-mud-qrcode] Tianran Zhou wrote: > IMO, whether to apply ISE or WG adoption depends on the authors themselves. > If I recall right, we did not get the adoption request from the > authors. I actually did post back in 2020 https://mailarchive.ietf.org/arch/msg/opsawg/w22FWi_D5586H_LK2UXtzXLhx88/ I got very little interest at all. The document was then simplified, all the DPP integration was removed, and I approached the Return Logistics Association (RLA.org) for a code that would integrate into their system. I think that the OPSAWG has very little available bandwidth for MUD related things, and the mud-qrcode document is not where I would want to spend the limited bandwidth of OPSAWG, since I think that there is very little for the WG. But, if the WG wants it, that's fine with me. RFC ISE (Adrian Farrel) wrote: > In my opinion, work that is in scope for an existing working group must > first be offered to that working group. If the working group has no > interest in pursuing it, that is OK and it can be brought to the > Independent Stream provided it does not conflict with ongoing work in the > working group. > Of course, I can form my own opinion on whether there is interest in the > working group, and I can make my own judgement about conflict, but it is > helpful if the working group chairs can give advice because they should > have a better understanding of what the working group thinks. Unlike my other two MUD related documents, this document does not make any changes at all to RFC8520. The mud-acceptable-urls document an Update (Amends), for RFC8520, and needs WG review. The mud-iot-dns-considerations document is a BCP, and it is getting cross-area review (and a dnsop presentation last week), and I have a number of issues to deal with. -- 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] New Liaison Statement, "LS/o on initiation a new work item ITU-T Y.IMT2020-IBNMO “Intent-based network management and orchestration for network slicing in IMT-2020 and beyond”"
Title: LS/o on initiation a new work item ITU-T Y.IMT2020-IBNMO “Intent-based network management and orchestration for network slicing in IMT-2020 and beyond” Submission Date: 2021-03-16 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1724/ From: Yushuang HU To: Henk Birkholz ,Joe Clarke ,Tianran Zhou Cc: Tianran Zhou ,Robert Wilton ,Joe Clarke ,Scott Mansfield ,Warren Kumari ,Henk Birkholz ,Operations and Management Area Working Group Discussion List Response Contacts: kaz.tanik...@nec.com Technical Contacts: Purpose: For information Body: ITU-T Study Group13 would like to inform ITU-T SG2, SG11, IRTF NMRG and IETF OPSAWG about the initiation of a draft Recommendation Y.IMT2020-IBNMO “Intent-based network management and orchestration for network slicing in IMT-2020 networks and beyond” at 2021 March meeting. An intent-based network enhances the evolution of IMT-2020 networks and beyond. It tries to grasp the intent of users (including end-users and network administrators) for its management, and automatically configure and adjust itself for realizing more highly automated control loop. This new work item is based on Y.3156 “Framework of network slicing with AI-assisted analysis in IMT-2020 networks”. We believe that this work item may have some aspects of interest and relevance with your activities in the field of management and orchestration in IMT-2020 networks (and beyond), and would like to keep co-operation with you. The initial version of the draft is attached herein. Attachment: SG13-TD750/WP1: Draft new Recommendation Y.IMT2020-IBNMO “Intent-based network management and orchestration in IMT-2020 networks and beyond” (March 2021). Attachments: SG13-LS197_att https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2021-03-16-itu-t-sg-13-opsawg-lso-on-initiation-a-new-work-item-itu-t-yimt2020-ibnmo-intent-based-network-management-and-orchestration-for-net-attachment-1.pdf SG13-LS197 https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2021-03-16-itu-t-sg-13-opsawg-lso-on-initiation-a-new-work-item-itu-t-yimt2020-ibnmo-intent-based-network-management-and-orchestration-for-net-attachment-2.docx ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Fwd: Your thoughts on draft-richardson-mud-qrcode]
I think it would benefit from opsawg review, and that a standard is appropriate in this instance. Eliot > On 16 Mar 2021, at 21:16, Michael Richardson wrote: > > Signed PGP part > > Tianran Zhou wrote: >> IMO, whether to apply ISE or WG adoption depends on the authors themselves. >> If I recall right, we did not get the adoption request from the >> authors. > > I actually did post back in 2020 > https://mailarchive.ietf.org/arch/msg/opsawg/w22FWi_D5586H_LK2UXtzXLhx88/ > > I got very little interest at all. > > The document was then simplified, all the DPP integration was removed, and I > approached the Return Logistics Association (RLA.org) for a code that would > integrate into their system. > > I think that the OPSAWG has very little available bandwidth for MUD related > things, and the mud-qrcode document is not where I would want to spend the > limited bandwidth of OPSAWG, since I think that there is very little for the > WG. But, if the WG wants it, that's fine with me. > > RFC ISE (Adrian Farrel) wrote: >> In my opinion, work that is in scope for an existing working group must >> first be offered to that working group. If the working group has no >> interest in pursuing it, that is OK and it can be brought to the >> Independent Stream provided it does not conflict with ongoing work in the >> working group. > >> Of course, I can form my own opinion on whether there is interest in the >> working group, and I can make my own judgement about conflict, but it is >> helpful if the working group chairs can give advice because they should >> have a better understanding of what the working group thinks. > > Unlike my other two MUD related documents, this document does not make any > changes at all to RFC8520. > > The mud-acceptable-urls document an Update (Amends), for RFC8520, and needs > WG review. > The mud-iot-dns-considerations document is a BCP, and it is getting > cross-area review (and a dnsop presentation last week), and I have a number > of issues to deal with. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > signature.asc Description: Message signed with OpenPGP ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Fwd: Your thoughts on draft-richardson-mud-qrcode]
Tianran Zhou wrote: > IMO, whether to apply ISE or WG adoption depends on the authors themselves. > If I recall right, we did not get the adoption request from the > authors. I actually did post back in 2020 https://mailarchive.ietf.org/arch/msg/opsawg/w22FWi_D5586H_LK2UXtzXLhx88/ I got very little interest at all. The document was then simplified, all the DPP integration was removed, and I approached the Return Logistics Association (RLA.org) for a code that would integrate into their system. I think that the OPSAWG has very little available bandwidth for MUD related things, and the mud-qrcode document is not where I would want to spend the limited bandwidth of OPSAWG, since I think that there is very little for the WG. But, if the WG wants it, that's fine with me. RFC ISE (Adrian Farrel) wrote: > In my opinion, work that is in scope for an existing working group must > first be offered to that working group. If the working group has no > interest in pursuing it, that is OK and it can be brought to the > Independent Stream provided it does not conflict with ongoing work in the > working group. > Of course, I can form my own opinion on whether there is interest in the > working group, and I can make my own judgement about conflict, but it is > helpful if the working group chairs can give advice because they should > have a better understanding of what the working group thinks. Unlike my other two MUD related documents, this document does not make any changes at all to RFC8520. The mud-acceptable-urls document an Update (Amends), for RFC8520, and needs WG review. The mud-iot-dns-considerations document is a BCP, and it is getting cross-area review (and a dnsop presentation last week), and I have a number of issues to deal with. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] OPSAWG meeting minutes
And, of course, I pasted the fully-qualified link with revision. The DT link is https://datatracker.ietf.org/doc/minutes-110-opsawg/. Joe On 3/16/21 09:02, Joe Clarke (jclarke) wrote: > On 3/16/21 07:56, tom petch wrote: >> From: OPSAWG on behalf of Tianran Zhou >> >> Sent: 15 March 2021 01:21 >> >> Hi WG, >> >> Thanks very much for your attending the OPSAWG on line meeting. >> The initial meeting minutes is now online: >> https://codimd.ietf.org/notes-ietf-110-opsawg >> >> >> That URL gives me a blank page. The datatracker gives me HTML. > Yes, the official minutes are currently up at > https://datatracker.ietf.org/meeting/110/materials/minutes-110-opsawg-01. > The HTML was all I could previously import as DT was giving me a MIME > error on the markdown. Seems like that has now been addressed, so I > pushed the markdown version to the aforementioned URL. > > Joe > > > ___ > 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] Last Call: (YANG Data Model for TACACS+) to Proposed Standard
On 3/16/21 06:13, tom petch wrote: > Some editorial quirks > > YANG > revision reference > the text value is not quite the same as the title of the I-D; perhaps both > are not quite right Good catch. These two should be normalized. Perhaps the better title is YANG module for TACACS+. > > leaf shared-secret > /shared keys/shared secrets/ Yes, agreed. > > should we recommend improving the entropy with mixed case, digits, > punctuation? I note that the example lacks punctuation. A plus sign might > be appropriate! Given the weakness, this couldn't hurt. This could be called out in both Security Considerations as well as in the leaf description. I like the cheeky notion of a '+' in the example. Joe > > Tom Petch > > > From: OPSAWG on behalf of The IESG > > Sent: 15 March 2021 14:08 > To: IETF-Announce > Cc: opsawg@ietf.org; opsawg-cha...@ietf.org; > draft-ietf-opsawg-tacacs-y...@ietf.org > Subject: [OPSAWG] Last Call: (YANG > Data Model for TACACS+) to Proposed Standard > > > The IESG has received a request from the Operations and Management Area > Working Group WG (opsawg) to consider the following document: - 'YANG Data > Model for TACACS+' >as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-c...@ietf.org mailing lists by 2021-03-29. Exceptionally, comments may > be sent to i...@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > >This document defines a TACACS+ client YANG module, that augments the >System Management data model, defined in RFC 7317, to allow devices >to make use of TACACS+ servers for centralized Authentication, >Authorization and Accounting. > >The YANG module in this document conforms to the Network Management >Datastore Architecture (NMDA) defined in RFC 8342. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/ > > > > No IPR declarations have been submitted directly on this I-D. > > > The document contains these normative downward references. > See RFC 3967 for additional information: > rfc8907: The Terminal Access Controller Access-Control System Plus > (TACACS+) Protocol (Informational - Internent Engineering Task Force (IETF)) > > > > > ___ > 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] OPSAWG meeting minutes
On 3/16/21 07:56, tom petch wrote: > From: OPSAWG on behalf of Tianran Zhou > > Sent: 15 March 2021 01:21 > > Hi WG, > > Thanks very much for your attending the OPSAWG on line meeting. > The initial meeting minutes is now online: > https://codimd.ietf.org/notes-ietf-110-opsawg > > > That URL gives me a blank page. The datatracker gives me HTML. Yes, the official minutes are currently up at https://datatracker.ietf.org/meeting/110/materials/minutes-110-opsawg-01. The HTML was all I could previously import as DT was giving me a MIME error on the markdown. Seems like that has now been addressed, so I pushed the markdown version to the aforementioned URL. Joe ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] OPSAWG meeting minutes
From: OPSAWG on behalf of Tianran Zhou Sent: 15 March 2021 01:21 Hi WG, Thanks very much for your attending the OPSAWG on line meeting. The initial meeting minutes is now online: https://codimd.ietf.org/notes-ietf-110-opsawg That URL gives me a blank page. The datatracker gives me HTML. Tom Petch Please send your comments to the chairs, so that we can achieve the finial one. Cheers, Tianran ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Fwd: Your thoughts on draft-richardson-mud-qrcode]
Thanks Tianran, In my opinion, work that is in scope for an existing working group must first be offered to that working group. If the working group has no interest in pursuing it, that is OK and it can be brought to the Independent Stream provided it does not conflict with ongoing work in the working group. Of course, I can form my own opinion on whether there is interest in the working group, and I can make my own judgement about conflict, but it is helpful if the working group chairs can give advice because they should have a better understanding of what the working group thinks. Best, Adrian Tianran Zhou wrote: > Hi Adrian, > > IMO, whether to apply ISE or WG adoption depends on the authors > themselves. > If I recall right, we did not get the adoption request from the > authors. > We welcome MUD related work, and we will consider from many aspects, > like: > 1. any conflict to existing solution > 2. wg interests > ... > > But anyway, the WG mailing list could always be the place we can > discuss about this technique. > > Best, > Tianran > -Original Message- > From: RFC ISE (Adrian Farrel) [mailto:rfc-...@rfc-editor.org] > Sent: Monday, March 15, 2021 6:20 PM > To: opsawg-cha...@ietf.org > Cc: opsawg@ietf.org; rfc-...@rfc-editor.org > Subject: [Fwd: Your thoughts on draft-richardson-mud-qrcode] > > Hi OPSAWG chairs, > > I wrote to you at the start of Janusary about draft-richardson-mud- > qrcode/ which is derived from draft-richardson-opsawg- > securehomegateway-mud > > My question was whether, in your opinion, this should be in the OPSAWG > or it is OK for it to be published in the Independent Stream. > > I also wondered if you are aware of any history related to the document > that you could share with me. > > I see from the mailing list that Michael has raised the draft on the > list a couple of times, but without any follow-up. > > What I'd like to know (and the WG can contribute to this discussion) is > whether this is something that the WG would like to complete and > publish in the IETF stream. > > Any thoughts? > > Thanks, > Adrian > -- > Adrian Farrel (Independent Stream Editor), rfc-...@rfc-editor.org > > -- Adrian Farrel (ISE), rfc-...@rfc-editor.org ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Last Call: (YANG Data Model for TACACS+) to Proposed Standard
Some editorial quirks YANG revision reference the text value is not quite the same as the title of the I-D; perhaps both are not quite right leaf shared-secret /shared keys/shared secrets/ should we recommend improving the entropy with mixed case, digits, punctuation? I note that the example lacks punctuation. A plus sign might be appropriate! Tom Petch From: OPSAWG on behalf of The IESG Sent: 15 March 2021 14:08 To: IETF-Announce Cc: opsawg@ietf.org; opsawg-cha...@ietf.org; draft-ietf-opsawg-tacacs-y...@ietf.org Subject: [OPSAWG] Last Call: (YANG Data Model for TACACS+) to Proposed Standard The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'YANG Data Model for TACACS+' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-03-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a TACACS+ client YANG module, that augments the System Management data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization and Accounting. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc8907: The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol (Informational - Internent Engineering Task Force (IETF)) ___ 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] [Fwd: Your thoughts on draft-richardson-mud-qrcode]
Hi Adrian, IMO, whether to apply ISE or WG adoption depends on the authors themselves. If I recall right, we did not get the adoption request from the authors. We welcome MUD related work, and we will consider from many aspects, like: 1. any conflict to existing solution 2. wg interests ... But anyway, the WG mailing list could always be the place we can discuss about this technique. Best, Tianran -Original Message- From: RFC ISE (Adrian Farrel) [mailto:rfc-...@rfc-editor.org] Sent: Monday, March 15, 2021 6:20 PM To: opsawg-cha...@ietf.org Cc: opsawg@ietf.org; rfc-...@rfc-editor.org Subject: [Fwd: Your thoughts on draft-richardson-mud-qrcode] Hi OPSAWG chairs, I wrote to you at the start of Janusary about draft-richardson-mud-qrcode/ which is derived from draft-richardson-opsawg-securehomegateway-mud My question was whether, in your opinion, this should be in the OPSAWG or it is OK for it to be published in the Independent Stream. I also wondered if you are aware of any history related to the document that you could share with me. I see from the mailing list that Michael has raised the draft on the list a couple of times, but without any follow-up. What I'd like to know (and the WG can contribute to this discussion) is whether this is something that the WG would like to complete and publish in the IETF stream. Any thoughts? Thanks, Adrian -- Adrian Farrel (Independent Stream Editor), rfc-...@rfc-editor.org ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
