Hi, Ops Area WG,
Every now and again, there are discussions on how to best characterize or
qualify a particular kind of "OAM", as well as misunderstandings due to
having different definitions and contexts for a given term. A case in point
is "in-band" or "out-of-band" OAM, as recently surfaced at
Many thanks Michael for the review and useful feedback!
Please find some follow-ups inline.
On Sun, Jan 7, 2024 at 2:54 PM Michael Richardson
wrote:
>
> Carlos Pignataro wrote:
> > We would appreciate feedback and input on this position, which aims
> at
> > updati
gt; This is a tricky little subject and I know that Carlos and I expected it
>> to generate more than a little discussion. If we end up with “everything is
>> OK and nothing needs to change” that will be OK with us. If we discover
>> that some work is using terms too genera
he intent. I would
> suggest explicit terms such as: “User Data Embedded OAM” or “OAM-embedded
> User Data”.
>
>
>
> Thank you.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* OPSAWG *De la part de* Carlos Pignataro
> *Envoyé :* vendredi 5 janvier 2024 21:39
>
y WG.
> >> Our intent, therefore, is to select a finer-grained set of terms that
> have
> >> universal applicability and that can be selected within a context
> without
> >> loss of generality.
> > GIM>> I agree with that wholeheartedly.
> >>
ifier] OAM".*
*CMP2: Please note that RFC7799 gives two definitions to Hybrid, and thus
some disambiguation is already needed.*
*CMP2: To me, your suggestion could be useful but seems an Update to
RFC7799 what you are asking.*
>
> Regards,
>
> Greg
>
> On Tue, Jan 16, 2024 at 2:
Many thanks Thomas and Alex, both for the support, as well as for the useful
suggestions.
Alex, “on-path” is much more descriptive than “in-band” for sure!
Thomas, Alex, will send an iteration of the draft incorporating the Node Type
suggestion. (BTW, I think you meant rfc9197 or rfc9359 instea
Many thanks Thomas and Alex, both for the support, as well as for the useful
suggestions.
Alex, “on-path” is much more descriptive than “in-band” for sure!
Thomas, Alex, will send an iteration of the draft incorporating the Node Type
suggestion. (BTW, I think you meant rfc9197 or rfc9359 instea
+Jari
Hello,
*Suresh, Jari,*
I'm confused by this bullet point:
*• next steps? E.g. WG coordination/status, form a WG Design
Team, call for a BOF?*
Could you please clarify?
I understood there's no WG (and hence no WG coordination nor status), in
favor of the IAB Program. There c
nvariably disappears quickly, so I think that we need to frontload the BOF
> preparation effort to achieve consensus at IETF 120 for creating a working
> group.
>
> Anyone else in the side meeting, please feel free to add anything that I have
> missed, or correct me, if I have m
Many thanks Thomas and Alex, both for the support, as well as for the useful
suggestions.
Alex, “on-path” is much more descriptive than “in-band” for sure!
Thomas, Alex, will send an iteration of the draft incorporating the Node Type
suggestion.
Thanks!
Carlos.
> On Mar 18, 2024, at 2:55 AM,
Krishnan (sureshk) <
sure...@cisco.com> wrote:
> Hi Carlos,
>
> Since your message was sent to Rob, I will let him respond, but I wanted
> to chime on some things you said about the e-impact program.
>
Thanks for this -- the salutation did not imply exclusivity.
>
>
&
d some comments (RW) inline …
>
>
>
> *From: *Carlos Pignataro
> *Date: *Monday, 25 March 2024 at 21:09
> *To: *Rob Wilton (rwilton)
> *Cc: *Marisol Palmero Amador (mpalmero) 40cisco@dmarc.ietf.org>, Ops Area WG , E-Impact IETF
> , inventory-y...@ietf.org ,
> Ale
n IETF meetings,
>the time invariably disappears quickly, so I think that we need to
>frontload the BOF preparation effort to achieve consensus at IETF 120 for
>creating a working group.
>
>
> Anyone else in the side meeting, please feel free to add anything that I
> have
Thank you, Jan! I appreciate the clarity and thorough explanation.
How is this problem statement you list below (my paraphrasing for
simplicity, please correct as needed):
(1) "devices can report their energy and/or power usage"
(2) "work belongs / is spread across multiple WGs and it is har
Thank you, Henk.
I support adoption of this document (as a co-author).
As spelled out in the Acknowledgements of this document, its genesis
started in this very mailing list with a need for clarification that seemed
deja vu.
As such, I feel updating RFC 6291 will take clarity to a next level.
T
Thank you Xiao! All good commends and addressed in the next revision.
Carlos.
> On Apr 11, 2024, at 11:43 PM, xiao.m...@zte.com.cn wrote:
>
> I support wg adoption of this draft.
>
> Responding to the call for discussion by the chairs, I would provide some
> comments for the authors considerat
Dear Greg,
Thank you for the input.
It appears that much of what you write below was already discussed at
https://mailarchive.ietf.org/arch/msg/opsawg/IVQzSSU_kvGgopCyCp-8oqK_xmg/
Am I to understand you might be keen on continuing using "in-band OAM" with
different meanings depending on the WG o
n Mon, Apr 15, 2024 at 2:00 PM Carlos Pignataro <cpign...@gmail.com> wrote:Dear Greg,Thank you for the input.It appears that much of what you write below was already discussed at https://mailarchive.ietf.org/arch/msg/opsawg/IVQzSSU_kvGgopCyCp-8oqK_xmg/ Am I to understand you might be keen on
Thank you Loa for reviewing this document again! Much appreciated.
Please find some follow-ups inline below
On Sun, Apr 21, 2024 at 3:46 AM Loa Andersson wrote:
> Working Group, Carlos, and Adrian,
>
> The way I understood draft-pignataro-opsawg-oam-whaaat-question-mark, is
> that
> while it up
Henk,
Thanks! I am not aware of any IPR that pertains to
draft-pignataro-opsawg-oam-whaaat-question-mark-03.
Best,
Carlos.
> On May 2, 2024, at 11:48 AM, Henk Birkholz wrote:
>
> Dear authors and contributors,
>
> as a part of the adoption process, the chairs would also like to issue a
> f
{
"emoji": "👍🏼",
"version": 1
}___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
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 o
ilto:adr...@olddog.co.uk>>
> Date: Friday, May 10, 2024 at 08:47
> To: 'Henk Birkholz' <mailto:henk.birkholz@ietf.contact>>, 'Carlos Pignataro' <mailto:cpign...@gmail.com>>
> Cc: 'OPSAWG' mailto:opsawg@ietf.org>>
> Subject: [OP
k 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
>
stion-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, Carlo
Thanks Alex, Adrian, and Justin!
I do plan on submitting a revision soon, and I also feel these are sensible and
stable based on the feedback we have received.
Thanks,
Carlos.
> On Jul 24, 2024, at 4:39 PM, Justin Iurman wrote:
>
> +1
>
> IMHO, keeping "Encapsulating", "Transit" and "Decaps
Joe,
No, I'm not aware of any IPR that applies to this draft.
Thanks!
Carlos.
On Thu, Oct 10, 2024 at 11:58 AM Joe Clarke (jclarke)
wrote:
> And, of course, I meant ahead of WG LC not adoption.
>
>
>
> Joe
>
>
>
> *From: *Joe Clarke (jclarke)
> *Date: *Thursday, October 10, 2024 at 11:57
> *
Many thanks, Roni, for your review and summary!
Carlos.
On Thu, Oct 31, 2024 at 5:46 PM Roni Even via Datatracker
wrote:
> Reviewer: Roni Even
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being
OpsAWG,
I read through this document, and although not with enough depth to have a
number of super-specific comments, I found this to be a useful document,
well organized, and well written.
Thanks!
Carlos.
Forwarded Message
> Subject: [OPSAWG]WG LAST CALL: Export of Delay Per
Hi, Med,
Thank you very much for your support! The document went through a number of
iterations, each time improving.
Please find some follow-ups inline.
> On Oct 22, 2024, at 3:52 PM, mohamed.boucad...@orange.com wrote:
>
> Hi Joe, Carlos, Adrian, all,
>
> I support this good and well-writt
y wrote:
>
> Dear Carlos,
> please find my notes below tagged GIM>>.
>
> Regards,
> Greg
>
> On Mon, Nov 11, 2024 at 11:07 AM Carlos Pignataro <mailto:cpign...@gmail.com>> wrote:
>> Dear Greg,
>>
>> Thank you for your continued intere
Dear Greg,
Thank you for your continued interest! Let’s work towards improving the
document.
Net-net, there are a couple of places where there are potential editorial
changes to improve clarity — as well as a lot of re-hashing.
Please find some responses inline, as well as two top-level questi
Joe,
Thanks for concluding the WG LC. Adrian and I are working through the comments
with the commenters and on-list.
We will be posting a new revision as we progress on this exercise, and signal
to the chairs and list.
Here's some additional follow-ups and responses.
Tom/Joe -- title typo fi
Hi, Med,
Thank you! Please see one more follow-up inline.
> On Nov 12, 2024, at 4:29 AM, mohamed.boucad...@orange.com wrote:
>
> Hi Carlos,
>
> Thanks for the follow-up.
>
> Please see inline.
>
> Cheers,
> Med
>
> De : Carlos Pignataro mailto:cpign
Hi, Tim,
Many thanks for this thorough review, which I find incredibly helpful!
As a preface, this I-D began with a central concern and idea, gradually
evolving to include adjacent terms based on group discussions and
participants' requests. This organic-growth process seems not uncommon for
term
Anytime!
Not really, I thought good progress was made against the YANG Doctors review —
but I did not want to overstep and judge whether the reviewer felt their
concerns were addressed.
Thanks,
Carlos.
> On Feb 9, 2025, at 4:24 PM, Mahesh Jethanandani
> wrote:
>
> Hi Carlos,
>
> Thanks,
Hi, Med,
Thanks for starting this conversation -- I think this is timely and useful.
One suggestion (that I made implicitly but to explore explicitly), I feel
it would be useful to elevate Appendix A to its own Section, and format it
in a sort-of template that can be used in OpsDir reviews direct
Thanks for this review, Benoit.
Stepping back before answering the specific points, the source of this
document was yet-another on-list confusion with the term “in-band OAM”, for
IP networks where there is no “band”, and with different parties using
different meanings.
A number of the additional
he same
>>>
>>> path as the user data. This term is also used in Section 2 of
>>>
>>> [RFC6669] with the same meaning, and the word "congruent" is
>>>
>>> mentioned as synonymous.
>>>
>>>
>>>
>>
such as PM) but must nonetheless follow
>> the same PW.
>>
>>
>>
>> Best regards
>>
>>
>>
>> Matthew
>>
>>
>>
>>
>>
>> From: mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com>
01:41
> To: Matthew Bocci (Nokia) <mailto:matthew.bo...@nokia.com>>
> Cc: mohamed.boucad...@orange.com
> <mailto:mohamed.boucad...@orange.com> <mailto:mohamed.boucad...@orange.com>>, Andrew G. Malis <mailto:agma...@gmail.com>>, Stewart Bryant <mailto
Greg,
Just a couple quick follow-ups to wrap things up, labeled “CMP_Again”, trimming
the long parts for clarity.
> On Jun 4, 2025, at 1:31 AM, Greg Mirsky wrote:
>
>>> GIM>> I don't think that your interpretation of "in-band" in RFC 5085 is
>>> accurate. The VCCV message not only traverses t
le priority by default
>> (see RFC 7369 for example).
>>
>> Cheers,
>> Tal.
>>
>> On Wed, Jun 4, 2025 at 8:31 AM Greg Mirsky > <mailto:gregimir...@gmail.com>> wrote:
>> >
>> > Hi Carlos,
>> > please find my notes below ta
This is very useful — thank you, Matthew!
> On Jun 4, 2025, at 7:49 AM, Matthew Bocci (Nokia)
> wrote:
>
> I don’t think it means the QoS treatment *must* always be the same between
> VCCV and user data on a given PW. For example, there are cases such as
> VCCV-BFD where you are doing a conti
AM data passing
> through the network which is the subject of OAM.
>
> Section 2.2 then becomes section 4, and the subsequent sections are
> renumbered accordingly.
>
> A small nit in Section 2:
> “that OAM can be” -> “that OAM traffic can be”
>
> Oh, and
t;
>>
>>
>> Do you see any disconnect between this text and RFC5085?
>>
>>
>>
>> FWIW, draft-ietf-opsawg-oam-characterization defines “Path-Congruent OAM” as
>> follows:
>>
>>
>>
>> The OAM information follo
Greg:
While I’ll defer to Tal for a detailed response, I’ve provided three key points
inline.
See “CMP:” below
> On Jun 1, 2025, at 7:49 PM, Greg Mirsky wrote:
>
> Hi Tal,
> thank you for explaining updates. Please find my follow-up notes below tagged
> GIM>>.
>
> Regards,
> Greg
>
> On Th
Hello, Greg,
Perhaps you might have read an old or cached version, of the diff tool didn’t
display the updates properly.
> I don't find that any of my concerns have been addressed.
Because it seems your assertion ^^^ frames the outcome in absolute terms, which
kindly might miss the progress ma
/author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-oam-characterization-04&url2=draft-ietf-opsawg-oam-characterization-06&difftype=--html
> >
> > Please let us know if the current version has addressed your comments.
> >
> > Thanks,
> > Tal.
> >
> > On
> On Jun 11, 2025, at 2:23 AM, Guy Harris wrote:
>
> On Jun 10, 2025, at 4:22 PM, Carlos Pignataro wrote:
>
>
>> 6. Descriptions:
>> Many descriptions are changed (streamlined) from [TCPDUMP].
>> Quite a number of them start like this:
>> Desc
> On Jun 10, 2025, at 9:01 PM, Michael Richardson wrote:
>
>
> Carlos Pignataro wrote:
>> 1. S2.2, Allocation Policy:
>
>> What is the incentive for anyone to submit a Specification Required
>> registration, when there’s FCFS with a much lower bar (just
, 2025, at 8:38 PM, Guy Harris wrote:
>
> On Jun 10, 2025, at 4:22 PM, Carlos Pignataro wrote:
>
>> 3. I recommend adding an Experimental range
>> https://datatracker.ietf.org/doc/html/rfc8126#section-4.2
>
> To quote that section:
>
> Experimental Use is simil
t;>
>> From: Greg Mirsky mailto:gregimir...@gmail.com>>
>> Date: Friday, 6 June 2025 at 01:56
>> To: Matthew Bocci (Nokia) > <mailto:matthew.bo...@nokia.com>>
>> Cc: mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com>
>> mailto:moha
Please find one follow-up inline, for completeness and correctness only.
> On Jun 11, 2025, at 9:48 PM, Michael Richardson wrote:
>
>
> Carlos Pignataro wrote:
>> What is the incentive to request a Spec Required vs. an FCFS? Do you
>> expect someone will ask for t
Hi, PCap LinkType authors,
I was browsing through draft-ietf-opsawg-pcaplinktype-10, and wanted to share a
couple of comments for your consideration.
1. S2.2, Allocation Policy:
What is the incentive for anyone to submit a Specification Required
registration, when there’s FCFS with a much low
Alvaro, Mahesh, Team,
Please find some follow-ups inline, marked with “[CMP]”.
Carlos Pignataro (He/Him)
Founder and Principal
Blue Fern Consulting<https://bluefern.consulting/>
Email: Carlos@Bluefern.consulting<mailto:Carlos@Bluefern.consulting>
From: Mahesh Jethanandani
Da
t
to publish when the holddown lifts.
[CMP] I do not think the name is “Operational Considerations”, but “Operational
and Management Considerations” (modulo figuring out the right grammar)
Thanks,
Carlos Pignataro (He/Him)
Founder and Principal
Blue Fern Consulting<https://bluefern.consult
Hi,
Please find an additional set of comments. Hopefully these are clear and
useful, they include both substantive and editorial comments.
1. Introdoction
1.1. Background
I agree with Ron that this is hard to parse, even more so describing plane
interactions without a diagram. Frankly, the M
comments that you receive, and strive to resolve them through discussion or by
updating the draft.
Document: draft-ietf-opsawg-oam-overview-08.txt
Reviewer: Carlos Pignataro
Review Date: 18 January 2013
IETF LC End Date: 25 January 2013
Intended Status: Informational
Summary:
I have significant
conclusion is
context dependent.
Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows
On Aug 6, 2013, at 8:18 AM, "Fan, Peng" wrote:
> Hi Ramki,
>
> Yes I agree with you on this point. This is also one of the reasons why ICMP
> may not be a proper way to do p
There are two other considerations:
1. ICMP packets might follow a different path than the application in the
presence of ECMP
2. The ICMP responder might rate limit and drop if it's a router regardless of
the drop characteristics of the path -- RFC 6192.
Thanks,
Thumb typed by C
I agree -- I see no conflict with l2tpext work.
-- Carlos.
On Aug 19, 2013, at 12:54 PM, Ignacio Goyret
wrote:
> I don't see any conflict with l2tpext wg work.
> -Ignacio
>
> At 07:43 8/19/2013, Ted Lemon wrote:
>> I've taken on the conflict review for draft-pfaff-ovsdb-proto-02, which is
>>
Hi, Tal,
First of all, there's been tremendous amount of progress and meaningful forward
movement with this document since it went into IETF LC earlier this calendar
year. Very many thanks for that, as it's been very productive.
From my perspective, all major comments have been addressed, and t
On 10/24/13 4:29 PM, "Melinda Shore" wrote:
>On 10/24/13 12:28 PM, Carlos Pignataro (cpignata) wrote:
>> Chairs, Would a WGLC be also in order?
>
>That's the plan, but we'd like to make sure the reviewers'
>concerns have been addressed, first.
Th
Tal,
> On Jul 20, 2016, at 6:30 AM, Tal Mizrahi wrote:
>
> Hi Sashank,
>
>> [SD] The attack is valid only if the attacker can get away bypassing a
>> service function/node.
>> For example, if the attacker bypasses a node and if POT determines it did
>> not bypass is a valid attack on the syst
Thanks,
— Carlos.
> I hope you will elaborate more on the threat model in the next version of the
> draft.
>
> Cheers,
> Tal.
>
>
>> -Original Message-
>> From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com]
>> Sent: Wednesday, July 20, 2016 11:34
M is one we should expand upon.
Thanks!
— Carlos.
> Thanks,
> Tal.
>
>
>> -Original Message-
>> From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com]
>> Sent: Wednesday, July 20, 2016 11:51 AM
>> To: Tal Mizrahi
>> Cc: Sashank Dara (s
ve a committed number of editors and reviewers. It is
Thanks,
—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>
“Sometimes I use big words that I do not fully understand, to make myself sound
more photosynthesis."
On Dec 7, 2016, at 1:36 AM, Zhoutianran
mailto:zhoutia
Hi, Bert,
Please find a couple of follow-ups inline.
—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>
“Sometimes I use big words that I do not fully understand, to make myself sound
more photosynthesis."
On Dec 14, 2016, at 9:48 AM, Bert Wijnen (IETF)
mailto:berti...@
Hi Adrian,
Interesting thoughts, please see inline.
—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>
“Sometimes I use big words that I do not fully understand, to make myself sound
more photosynthesis."
On Dec 15, 2016, at 5:09 PM, Adrian Farrel
mailto:adr...@o
Thanks again, Tianran and Adrian.
Please find a couple additional comments inline.
—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>
“Sometimes I use big words that I do not fully understand, to make myself sound
more photosynthesis."
On Dec 16, 2016, at 1:28 AM,
Hi, Linda,
Moving the discussion to i...@ietf.org<mailto:i...@ietf.org>, other aliases to
Bcc.
Please see inline.
—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>
“Sometimes I use big words that I do not fully understand, to make myself sound
more photosynthesis.
Congratulations Joe, this is excellent news for OPsAWG!
On May 24, 2017, at 7:45 AM, Warren Kumari
mailto:war...@kumari.net>> wrote:
Hi all,
Benoit and I have been discussing this for a while, and we'd like to announce
that we are adding Joe Clarke as an OpsAWG chair.
Joe has both operations
ered.”
> 7625 ... and dogged comments on this draft; though some of us
> have grew a bit weary of the denial game and allowed ourselves to be
> shut up.
Or a DDoS against the ideas on this document?
>
> randy
>
—
Carlos Pignataro, car...@cisc
Reviewer: Carlos Pignataro
Review result: Has Nits
>From an Ops-Dir review for draft-ietf-opsawg-teas-common-ac, there are no
additional operational considerations beyond what the YANG Doctors review
uncovered, and I would recommend addressing the yangdoctors feedback plus have
a re-review af
76 matches
Mail list logo
