Hi Deb,
Do you still think a change is needed given what was explained so far?
Thanks.
Cheers,
Med
De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mardi 8 juillet 2025 13:48
À : 'Deb Cooley'
Cc : The IESG ; draft-ietf-opsawg-secure-tacacs-y...@ietf.org;
opsawg-cha...@ietf.org; opsawg@ietf.org; jcla
Mohamed Boucadair has entered the following ballot position for
draft-ietf-opsawg-ipfix-on-path-telemetry-20: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however
Hi Michael,
Agree with your proposal (1) below.
I think that we can avoid the "ng" mentions in the Historical doc. I sent you a
PR right now with some few changes:
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-pcap/pull/187#pullrequestreview-3033954886.
Thanks for the continuous effort
Hi Benoît, all
As an input to the chartering discussion but without any intention to interfere
with the ongoing discussion, I'd like to remind that we do have the following
OPS-related items in rfc2418#Section 2.2:
==
To facilitate evaluation of the intended work and to provide on-
Hi Paul,
Thanks for the comment. I fully agree with what you said:
> All security parameters are sensitive - if
> modified to
> weaker or broken algorithms that are still supported, this could be
> used to
> downgrade connections to a lesser security level.
Especially when we have text in the d
253b6f5d20%7C0%7C0%7C638871558726385485%7CUnknown%7CTWFpbGZsb3d8ey
> JF
> >
> bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp
> bC
> >
> IsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7VZ5FHQpq2Ag%2FIzv1J9byoVVyAmd
> bP
> > 2eS9YZeOYxCOs%3D&reserved=0
Hi Deb,
As a general rule, only authorized entities are allowed to read/write. The
second para of the sec cons section covers that part.
Following paragraphs focus on data nodes that are particularly sensitive.
Please note that we avoid repeating considerations already covered in other
RFCs; c
Hi Deb,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Deb Cooley via Datatracker
> Envoyé : lundi 7 juillet 2025 12:54
> À : The IESG
> Cc : draft-ietf-opsawg-secure-tacacs-y...@ietf.org; opsawg-
> cha...@ietf.org; opsawg@ietf.org; jcla...@cisco.com;
> jcla...@cisco.com
IETF Web page: https://datatracker.ietf.org/liaison/2010/
Please reply by 2025-09-08
From: isg_...@list.etsi.org
To: Joe Clarke ,Benoît Claise
,Orie Steele ,Andy Newton
,Mahesh Jethanandani ,Mohamed Boucadair
Cc: Joe Clarke ,Benoît Claise
,Operations and Management Area Working Group
Discussion List
Hi Éric,
Thanks for the review.
Please see inline.
Cheers,
Med (as author)
> -Message d'origine-
> De : Éric Vyncke via Datatracker
> Envoyé : jeudi 3 juillet 2025 11:01
> À : The IESG
> Cc : draft-ietf-opsawg-secure-tacacs-y...@ietf.org; opsawg-
> cha...@ietf.org; opsawg@ietf.org;
Hi Rachid,
(replying without my OPS area director hat, but as an opsawg contributor)
Thank you for sharing this proposal.
As currently written, it is not easy to assess what aspects you are seeking to
standardize and what elements you think requires interoperability. Answering
these questions
Hi Robert,
Thanks for the review.
ACK. Will check and make sure both specs are in sync.
Cheers,
Med (as author)
> -Message d'origine-
> De : Robert Sparks via Datatracker
> Envoyé : lundi 30 juin 2025 19:53
> À : sec...@ietf.org
> Cc : draft-ietf-opsawg-secure-tacacs-yang@ietf.org
Hi Pascal,
(removing IETF LC list + added opsawg).
Thanks for the follow-up with Giuseppe. I think that we need to get this right.
I saw that Janos raised similar comments
(https://mailarchive.ietf.org/arch/msg/detnet/NqTndz1P2DaGTH45JCw5O9XQQqc/),
but failed to find where this was discussed th
Hi Deb,
I hear you, but the situation is more complex.
Upleveling the full protocol to PS is a distinct work item vs what the WG
agreed and committed to deliver. That work would end up BTW with specifying
“something” that is not interoperable with the currently widely deployed
TACACS+. I’m not
Hi Ketan,
Thanks for digging into this and for clearing.
The PS justification for this extension (see more details in the writeup) is
strong enough to not revisit it. It is true that 8907 will be a downref, but
that one should already be in the downref registry as it was already
normatively ci
Hi Ines,
Thank you for the review.
As a general note, some of your comments are related to parts that were already
in RFC 9105, while this revision is scoped to add TLS support.
Please see inline for more context.
Cheers,
Med (as author)
> -Message d'origine-
> De : Ines Robles via
Hi Ketan,
The approach followed here follows what was agreed with the IESG at the time of
publication of 8907 and which is captured in the note sent by Warren to the WG
to act upon (2021):
https://mailarchive.ietf.org/arch/msg/opsawg/IPNhvGyhDAawsavqRUHIliCr4xk/,
especially this part:
" When
Hi all,
Thanks Adrian, Benoît, Carlos, Joe, Ran, Joe, and Thomas for the effort put
into this. I appreciate the hard work and dedication to keep us aligned with
the initial plan.
@all: Please review and share comments and suggestions with the authors. Thank
you.
Cheers,
Med
De : Benoit Clai
Hi all,
(changing the subject to ease tracking the discussion)
At least from where I sit, I think that that the inputs from Andy/ Matthew
kindly helped to clarify the assumptions on the QoS treatment.
Now, focusing on this part of the discussion where Greg suggests:
* In-flow OAM is an act
Hi Andy/Stewart/Matthew,
I hope you are doing well.
I’m soliciting your feedback on this text which is included in
draft-ietf-opsawg-oam-characterization:
An example of "Path-Congruent OAM" is the Virtual Circuit
Connectivity Verification (VCCV), described is Section 6 of
[RFC
Hi Wenxi, all,
Looks good to me. I suggest to mark this as verified.
Thank you.
Cheers,
Med (as author)
> -Message d'origine-
> De : RFC Errata System
> Envoyé : lundi 26 mai 2025 18:24
> À : BOUCADAIR Mohamed INNOV/NET ;
> kond...@gmail.com; al...@freeradius.org; BOUCADAIR Mohamed
> I
Hi Joel, all,
(removing all other @es to cci, but add opsawg as this point is relevant to the
ongoing 5706 refresh)
There is an ongoing discussion about what we should say about IM and so on;
hence changing the subject so that authors are aware of this thread.
The changes made so far on this s
Hi all,
I'm forwarding this announcement to OPSAWG as there might be some implications
on the maintenance of some of the work we have done here. So far, the following
is identified for OPSAWG:
==
Relationship with Existing WGs
OPSAWG
* Offload AC/SAP/LxNM to ONIONS
* Future relevant work on ab
Hi Benoît, all,
Thank you for the team.
FWIW, Alvaro Retana kindly accepted to be the document Shepherd.
Cheers,
Med
De : Benoit Claise
Envoyé : lundi 12 mai 2025 15:24
À : opsawg
Cc : ops-...@ietf.org; draft-opsarea-rfc5706...@ietf.org; ops-ads
Objet : New draft version posted (Fwd: RFC570
Hi Reshad,
Thank you for the review.
For the nacm changes, this was fixed as part the shepherd review as the
Datatracker was complaining about these NACM warnings. Thanks, Joe!
Cheers,
Med
> -Message d'origine-
> De : Reshad Rahman via Datatracker
> Envoyé : mardi 6 mai 2025 23:37
>
Hi Mahesh,
Please see inline.
Cheers,
Med
De : Mahesh Jethanandani
Envoyé : vendredi 2 mai 2025 01:01
À : BOUCADAIR Mohamed INNOV/NET
Cc : draft-ietf-opsawg-secure-tacacs-yang@ietf.org; opsawg
; tina.t...@tiktok.com; Reshad Rahman
Objet : Re: AD Evaluation of draft-ietf-opsawg-secure-tac
Hi Mahesh,
Thanks for the review. A new version that integrates your comments is available
online:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-secure-tacacs-yang-09&url2=draft-ietf-opsawg-secure-tacacs-yang-10&difftype=--html.
As a general note, please note that we are not deal
Hi Victor,
(please keep the ospawg list in the reply as not all WG participants are in
this list)
The document will point to rfc9525#section-7.1 for a discussion of the wildcard
risks.
> Even if wildcards are supported, they should at least be
> discouraged.
The proposed text adheres to the
Mohamed Boucadair has entered the following ballot position for
charter-ietf-opsawg-04-05: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
The document, along
Hi Linda, all,
Thank you for the follow-up and for considering this approach. This exercise is
really important as it is a walk trough a set of models and assess whether they
can address your needs. That exercise is also important because it further
shows how the various modules can be invoked
Hi Tina,
Thank you for clarifying the VRF point.
I don’t think a change is needed as we don’t define the VRF itself but I will
think further about this.
Cheers,
Med
De : Tina Tsou
Envoyé : vendredi 18 avril 2025 19:28
À : BOUCADAIR Mohamed INNOV/NET
Cc : ops-...@ietf.org; draft-ietf-opsawg-s
Hi Thomas, all
FWIW, 8407bis has a subset of classes that reflect the main flavors defined so
far in the IETF (hence the use of "Specifically" below). I'm not sure adding
more sub-categories (e.g., incident management) would be useful.
==
3.5.1. YANG Module Classification
The narrative sec
Hi Tina,
Thank you for the review.
Please see inline.
Cheers,
Med (as doc editor)
> -Message d'origine-
> De : Tina Tsou via Datatracker
> Envoyé : vendredi 18 avril 2025 10:18
> À : ops-...@ietf.org
> Cc : draft-ietf-opsawg-secure-tacacs-yang@ietf.org; last-
> c...@ietf.org; opsaw
Hi Arnaud,
Agree the point you mentioned is a valid pending issue. That was ACKed in
draft-ietf-opsawg-tacacs-tls13-20#section-5.1.
OPSAWG is definitely the main entry point for TACACS+. Whether the work will be
pursued here depends on the availability of a contribution (which we don't have
Mohamed Boucadair has entered the following ballot position for
charter-ietf-opsawg-04-04: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
The document, along
Hi Gunter,
There are many OPS-related protocols out there for which we don't have a home
(IPFIX, DIAMETER, etc.). OPSAWG should not be the place to develop major
changes (e.g. new versions) of these protocols.
For example, we used to have opsawg be tagged as maintenance group for RADIUS
(http
Hi Tom,
As indicated by Benoît, the document is listed under opsarea:
https://datatracker.ietf.org/group/opsarea/documents/
We don't list it in opsawg as we want to uplevel this effort and not
"restricted" to a single WG.
We are using opsawg mailing list for convenience.
Thank you.
Cheers,
Hi Adrian,
I have considered that but abandoned that path because that list is almost
"stale" since years. That’s something we can fix, but another day :-)
What is really key here IMO is to have a discussion venue where we are
confident that we have active participation. OPSAWG (which is the ar
Re-,
I hear you Tom, but there few subtle things that we inherited. For example,
intarea is a **formal WG** that has a charter that can adopt documents. Opsarea
is an AG. I won't dive much more into those things and will focus more on this
part of your message:
> I have looked at the I-D and
Hi Doug, all,
In preparation for the forthcoming IETF LC, I made my AD review based on -19.
Unsurprisingly, the document is stable enough. There are some very minor nits
that I suggest to fix to save us some comments in the last mile. Please clean
up unused refs (there are mentioned in the revi
Hi Benoît, all,
Thanks for starting this. Please find below some comments:
(1) I think that we need to have text to formally endorse the dispatch function
for the ops area.
(2) I would simplify this part as the message seems to be redundant:
"The OPSAWG
will serve as the forum for developing s
Russ,
You should have a “correct review” button under “review” (Assignment) at
https://datatracker.ietf.org/doc/review-ietf-opsawg-tacacs-tls13-18-secdir-lc-housley-2025-03-08/
Cheers
Med
De : Russ Housley
Envoyé : jeudi 3 avril 2025 19:28
À : Joe Clarke (jclarke)
Cc : Douglas Gash (dcmgash)
Hi Sriram, all,
(as a contributor)
Thank you for taking of the changes. Special thanks for the mention about the
checksum, in particular.
I think that this version is ready to move forward. Thanks for the hard work.
Cheers,
Med
De : Sriram Gopalakrishnan (sriragop)
Envoyé : vendredi 4 avril
Hi Joe,
The new version with your comments addressed is now online. Please double check
and let me know if any other change is needed. Thanks.
Cheers,
Med
De : Joe Clarke (jclarke)
Envoyé : mardi 1 avril 2025 14:50
À : opsawg@ietf.org
Objet : [OPSAWG]Re: WG LC: TACACS+ TLS and its YANG module
Hi Benoît, all,
I think that waiting 2 months with many nudges in the mailing list and
privately is sufficient as a clear evidence that "reasonable efforts" have been
made to remind authors.
As a remind, here is what is we supposed to do:
==
12. Have reasonable efforts been made to remind all
Hi Benoît,
Thank you for the interest and also for digging into the practicalities.
Please see inline.
Cheers,
Med
De : Benoit Claise
Envoyé : mardi 1 avril 2025 15:31
À : BOUCADAIR Mohamed INNOV/NET ;
ops-...@ietf.org; opsawg@ietf.org; adr...@olddog.co.uk
Cc : Carlos Pignataro ; me
Objet :
Hi Adrian,
Thank you.
Yes, turning 5706 into an I-D will be the next step. I will be sharing some
more guidance in the coming few days.
Cheers,
Med
De : Adrian Farrel
Envoyé : mardi 1 avril 2025 13:08
À : chen@zte.com.cn; BOUCADAIR Mohamed INNOV/NET
Cc : ops-...@ietf.org; opsawg@ietf.or
Hi Ran,
Glad to hear that you are interested.
Having Adrian on board is more than welcome (he is familiar with at least two
candidate change items), but he has to express interest :-)
Cheers,
Med
De : chen@zte.com.cn
Envoyé : lundi 31 mars 2025 03:21
À : BOUCADAIR Mohamed INNOV/NET
Cc :
Hi Joe,
Good points. Looking forward to see how this will be elaborated in the bis.
Will share by the end of the week the final list of volunteers and a plan to
conduct this project. Thanks.
Cheers,
Med
De : Joe Clarke (jclarke)
Envoyé : dimanche 30 mars 2025 01:00
À : BOUCADAIR Mohamed INNOV
Re-,
Thanks, Carlos. That’s indeed an item to explore.
One comment though, for opsdir, my current take is to have a simplified
template (not frozen in an RFC) with key topics. Let me not tease too much here
:-) Hope we will have some thing to share SOON.
Cheers,
Med
De : Carlos Pignataro
Env
Hi all,
15 years after the publication of this important document, I think that it is
time to consider a refresh.
I'm sending this note to gauge interest and hopefully find volunteers to
explore this path with the aim to produce a bis. Areas that can be easily
revisited are:
* More clari
Hi all,
+1
Changes to the IM in the future do not necessarily imply that both the
control/flow parts will be impacted. Even if both were impacted (e.g., simple
augmentations to the CP/flow), nothing prevent to publish those in a single
document even if we go for option 2 now.
Cheers,
Med (as
Re,
Thanks Joe for the follow-up.
The siloed/lack of engagements for some topics is not related to the dispatch
nature but that sometimes small groups are only interested in their documents.
We may experiment in the future clustering and moving to short-lived WGs. We
should not be frightened b
Hi Reshad,
Thank you for the review. Glad to hear that.
Cheers,
Med
> -Message d'origine-
> De : Reshad Rahman via Datatracker
> Envoyé : mercredi 19 mars 2025 03:03
> À : yang-doct...@ietf.org
> Cc : draft-ietf-opsawg-secure-tacacs-yang@ietf.org;
> opsawg@ietf.org
> Objet : Yangdo
Dear Authors,
As mentioned in the session, I think this is a valid work but it needs to
better define the concept of QUIC flow first (and then better the usage of
various IEs with a flow perspective). Also, I encourage the authors to read RFC
9312.
Thank you.
Cheers,
Med
_
t; > >
> bca17708dd6161cae9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6387
> > >
> 73794832668245%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO
> > >
> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%
> > >
> 7C%7C%7C&sdata
Hi Russ,
The last part of your clarification reflects the intent here. I agree this
should be clearly formulated in the doc.
I trust the authors will follow up with proposed changes SOON.
Cheers,
Med (as doc Shepherd)
> -Message d'origine-
> De : Russ Housley
> Envoyé : dimanche 9 ma
Hi Authors, all,
The authors addressed the comments I raised in the first WGLC:
https://mailarchive.ietf.org/arch/msg/opsawg/CXMtDH_GWRlZfCRhKhggA4zapuA/
There are still some minor nits/edits as shown in the review below:
* pdf:
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master
Hi Russ,
Please see inline.
Cheers,
Med (as doc Shepherd)
> -Message d'origine-
> De : Russ Housley via Datatracker
> Envoyé : dimanche 9 mars 2025 02:17
> À : sec...@ietf.org
> Cc : draft-ietf-opsawg-tacacs-tls13@ietf.org; last-c...@ietf.org;
> opsawg@ietf.org
> Objet : Secdir las
Re-,
Please see inline.
Cheers,
Med
De : Joe Clarke (jclarke)
Envoyé : vendredi 7 mars 2025 17:37
À : draft-ietf-opsawg-secure-tacacs-y...@ietf.org
Cc : opsawg@ietf.org
Objet : Shepherd procedural review
As I work through the shepherd write-up, I have questions:
* Has this module been im
Re-,
Good catch. Please see
https://github.com/boucadair/secure-tacacs-yang/pull/13/files
Thanks.
Cheers,
Med
De : Joe Clarke (jclarke)
Envoyé : vendredi 7 mars 2025 17:19
À : Joe Clarke (jclarke) ; opsawg@ietf.org
Objet : [OPSAWG]Re: WGLC/Shepherd comments for TACACS+ TLS YANG
(draft-ietf-o
Hi Joe,
Thanks you the review.
Good points. These are fixed as you can see in this diff:
https://boucadair.github.io/secure-tacacs-yang/#go.draft-ietf-opsawg-secure-tacacs-yang.diff
Please see inline for more context.
Cheers,
Med
De : Joe Clarke (jclarke)
Envoyé : vendredi 7 mars 2025 16:57
64e2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63876610514
> 1195027%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD
> AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd
> ata=LE0rw3AdSpl6GmrZxu5ow5NWRyJzfstoGNpvmeMnsLU%3D&reserved=0
>
> I provide some answers to y
Hi Joe, all,
No, I'm not aware of any IPR that applies to this draft.
Cheers,
Med
De : Joe Clarke (jclarke)
Envoyé : jeudi 27 février 2025 17:35
À : opsawg@ietf.org; draft-ietf-opsawg-secure-tacacs-y...@ietf.org
Objet : IPR POLL: draft-ietf-opsawg-secure-tacacs-yang : A YANG Data Model for
Ter
Hi Chongfeng, Linda, all,
(ccing CATS/OPSAWG as the current proposed scope seems to overlap with the work
in these WGs)
Thank you for starting this proposal.
I thought that the email discussion we had clarified the relationship with
existing WGs, but I'm afraid that the current work descriptio
Hi Bo, all,
The proposed update to vrf-instance looks good to me (modulo inversing the
order of must/description). Thanks.
Cheers,
Med
De : Wubo (lana)
Envoyé : dimanche 26 janvier 2025 09:56
À : BOUCADAIR Mohamed INNOV/NET ; Reshad Rahman
; yang-doct...@ietf.org
Cc : draft-ietf-opsawg-secure
Hi Mahesh,
The point raised by Reshad is a valid one, for sure.
My point is that whatever decision we will be making here, it has to also
consider the 7134 where all these is rooted. The system yang has the following:
leaf address {
type inet:host;
Hi Reshad,
Thank you for this review.
Please see inline.
Cheers,
Med
De : Reshad Rahman
Envoyé : mercredi 22 janvier 2025 23:32
À : yang-doct...@ietf.org
Cc : draft-ietf-opsawg-secure-tacacs-yang@ietf.org; opsawg@ietf.org
Objet : Re: [yang-doctors] Yangdoctors early review of
draft-ietf-o
Hi Paul,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Paul Wouters via Datatracker
> Envoyé : mardi 21 janvier 2025 21:52
> À : The IESG
> Cc : draft-ietf-opsawg-teas-common...@ietf.org; opsawg-
> cha...@ietf.org; opsawg@ietf.org; rro...@ciena.com;
> rro...@ciena.com
>
Hi Paul,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Paul Wouters via Datatracker
> Envoyé : mardi 21 janvier 2025 22:07
> À : The IESG
> Cc : draft-ietf-opsawg-teas-attachment-circ...@ietf.org; opsawg-
> cha...@ietf.org; opsawg@ietf.org;
> luismiguel.contrerasmuri...@t
Hi all,
This document solves a real problem. I support adoption.
Cheers,
Med
PS: When reviewing the document for this call, I figured out that I might be
aware of an IPR that might cover this contribution. I will double check
internally and, if my assessment is confirmed, a formal disclosure w
Hi Erik,
> ## Comments
>
> ### S5.4
>
> * Should there be any mention of Provider Backbone Bridging (PBB)
> in here,
> or would that go somewhere else as a network operations
> implementation
> detail?
That's more a service that can be bound to ACs. Some PBB matters on PEs are
already cov
Hi Erik,
Thanks for the comments.
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Erik Kline via Datatracker
> Envoyé : lundi 20 janvier 2025 22:19
> À : The IESG
> Cc : draft-ietf-opsawg-teas-attachment-circ...@ietf.org; opsawg-
> cha...@ietf.org; opsawg@ietf.org;
> lui
Re-,
Thanks for the comments.
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Gunter Van de Velde via Datatracker
> Envoyé : lundi 20 janvier 2025 13:49
> À : The IESG
> Cc : draft-ietf-opsawg-teas-attachment-circ...@ietf.org; opsawg-
> cha...@ietf.org; opsawg@ietf.org;
>
Hi Gunter,
Thanks for the review.
I like your edited text. I adopted it with some very few adjustments as you can
see in the diff:
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-ac-lxsm-lxnm-glue.txt&url_2=https://boucadai
Hi Orie,
Thank you for the review.
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Orie Steele via Datatracker
> Envoyé : vendredi 17 janvier 2025 23:57
> À : The IESG
> Cc : draft-ietf-opsawg-teas-common...@ietf.org; opsawg-
> cha...@ietf.org; opsawg@ietf.org; rro...@ci
Hi Gunter,
Thank you for the comments.
I adopted most of your suggested edits as you can see at:
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-common-ac.txt&url_2=https://boucadair.github.io/attachment-circuit-model/g
Hi Éric,
Thank you for the review.
Please see inline.
Cheers,
Med
Orange Restricted
> -Message d'origine-
> De : Éric Vyncke via Datatracker
> Envoyé : mardi 14 janvier 2025 17:16
> À : The IESG
> Cc : draft-ietf-opsawg-teas-attachment-circ...@ietf.org; opsawg-
> cha...@ietf.org;
Re-,
Thanks for clarifying.
Added new text to cover these two points:
https://github.com/boucadair/attachment-circuit-model/commit/f11efbc5400ce5c4106ce4b57056fde4c8765bc1
The full changes can be tracked using the link shared in my first reply:
https://author-tools.ietf.org/api/iddiff?url_1=ht
Hi Éric,
Thank you for the review.
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Éric Vyncke via Datatracker
> Envoyé : lundi 13 janvier 2025 17:43
> À : The IESG
> Cc : draft-ietf-opsawg-teas-common...@ietf.org; opsawg-
> cha...@ietf.org; opsawg@ietf.org; rro...@ciena
Re-,
Your understanding is correct. Let’s then proceed as you recommended.
Thank you for sharing this useful info. Would be worth to factor some if this
in a rfc3113-bis.
Cheers,
Med
De : Lionel Morand
Envoyé : vendredi 10 janvier 2025 10:35
À : Lionel Morand ; BOUCADAIR
Mohamed INNOV/NET ;
Salut Lionel,
I know that you are more familiar than me about 3GPP, but my concern is that
I’m afraid that if we tag it as “for information” this will be simply noted and
we won’t get any useful feedback (including, “we detected no deviation with our
spec”).
The initial motivation that trigger
Hi all,
I think the “purpose” should be changed to “for action” as we are asking for
checks against authoritative 3GPP specs, in particular.
Cheers,
Med
De : Charles Eckel (eckelcu)
Envoyé : vendredi 10 janvier 2025 01:07
À : Joe Clarke (jclarke)
Cc : Peter Schmitt ; Lionel Morand
; Kaippall
Hi Sriram, all,
Thank you for taking care of some of the comments I raised in my review. I
checked the 00/03 diff and I think that the text is improved. I do still think
that we need some discussion on the pending points:
* Should we add a statement about the base 3GPP release used to defi
Hi Adrian,
Thank you for the follow-up.
I merged these changes right now and also reflected some of them in the other
documents of the AC I-Ds set.
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Adrian Farrel
> Envoyé : mercredi 8 janvier 2025 19:04
> À : BOUCADAIR Mo
Hi all,
I reviewed this document in the past:
https://mailarchive.ietf.org/arch/msg/opsawg/TH0ks0KsZTeZbu2MRIUBsCtcSXo/. The
authors addressed some of them, but there are still some that I think are still
pending. Also, it is not clear yet how the use of schema-mount is envisaged
here, but I
Hi Joe,
That was also my concern. I think that it is better to simply remove that para.
Thank you.
Cheers,
Med
De : Joe Clarke (jclarke)
Envoyé : mercredi 8 janvier 2025 14:51
À : BOUCADAIR Mohamed INNOV/NET ; opsawg@ietf.org
Objet : Re: REVIEW: Liaison statement to 3GPP for GTP-U IPFIX work
Reviewer: Mohamed Boucadair
Review result: Has Issues
Thank you for the effort put into this document.
This specification proposes an approach to supply (and store) required context
information to help interpreting telemetry data. It does so by leveraging
existing tools (e.g., yang mount). This
Hi Adrian,
Many thanks for the review.
A diff to track the changes can be found here:
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-attachment-circuit.txt&url_2=https://boucadair.github.io/attachment-circuit-model/opsd
Hi Joe, all,
Thanks for taking care of the LS.
You my find some edits/comments at
https://github.com/boucadair/IETF-Drafts-Reviews/raw/refs/heads/master/2025/The%20IETF%20Operations%20and%20Management%20Area%20Working%20Group-rev%20Med.docx,
fwiw.
Cheers,
Med
De : Joe Clarke (jclarke)
Envoy
he Operations and Management Area Working
> Group (OPSAWG) WG of the IETF.
>
>Title: A YANG Data Model for Terminal Access Controller
> Access-Control System Plus (TACACS+)
>Authors: Mohamed Boucadair
> Bo Wu
> Guangying Zheng
> M
Re-,
Intuitively, the diff would be the difference between the two services that
will be provided by a network to a cloud infra vs. cloud infra to network. If
there are no specifics, this would be a simple interco between two networks.
Identifying these specifics is actually a homework for neot
Hi Benoît,
I was referring to updating the description **IEs defined in this document**.
These IEs belong to a WG-adopted document and as such the WG has control over
the content. Aligning what was pre-registered vs. the consensus of the WG is
simple logistic and will follow usual involvement o
Hi Linda,
(I saw your other message, which I think is not accurate in some parts such as
decentralized nature, etc.)
Please see inline.
Cheers,
Med
De : Linda Dunbar
Envoyé : mercredi 18 décembre 2024 02:04
À : BOUCADAIR Mohamed INNOV/NET ; Chongfeng Xie
Cc : neotec ; opsawg ; sunqiong
Obj
Hi Sriram,
I didn’t check this version against my comments, but I’m reacting to this part
of your message:
==
Since the IEs mentioned in the draft (Sec-5) are already published by the IANA
and is available in https://www.iana.org/assignments/ipfix/ipfix.xhtml, we did
not change the description
Hi Chongfeng,
Thanks for the follow-up.
I expect neotec to produce service models. As you rightfully mentioned,
correlating with the underlying ACs will be required to deliver the (bidir?)
services.
Please note that the ACaaS is not between network devices but between peer
controllers/orchest
r Terminal Access Controller
> Access-Control System Plus (TACACS+)
>Authors: Mohamed Boucadair
> Bo Wu
> Guangying Zheng
> Michael Wang
>Name:draft-ietf-opsawg-secure-tacacs-yang-03.txt
>Pages: 46
>Dates: 2024-12-16
Hi all,
We didn't initially include the 9105 example at
https://datatracker.ietf.org/doc/html/rfc9105#name-example-tacacs-authenticati
in draft-ietf-opsawg-secure-tacacs-yang because we wanted to have an example
with TLS use.
However, when reviewing the 9105 example it appeared that it has sev
orking
> Group (OPSAWG) WG of the IETF.
>
>Title: A YANG Data Model for Terminal Access Controller
> Access-Control System Plus (TACACS+)
>Authors: Mohamed Boucadair
> Bo Wu
> Guangying Zheng
> Michael Wang
>Name
Re-,
This is because there was a bug in -00. For some reason, the module was not
included but only the path:
"{::include-fold ./yang/ietf-system-secure-tacacs.yang}"
Cheers,
Med
De : Joe Clarke (jclarke)
Envoyé : jeudi 12 décembre 2024 18:38
À : BOUCADAIR Mohamed INNOV/NET ; opsawg@ietf.org
O
1 - 100 of 399 matches
Mail list logo
