I have fixed these warning. Eliot, I am including the updated ACL models. Can you verify?These changes will be uploaded as part of the next update that Sonal is planning to post on Oct. 2.
ietf-access-control-list@2017-09-21.yang
Description: Binary data
ietf-packet-fields@2017-09-21.yang
Descri
ation:
>> Virtual,
>>
>>
>> Agenda:
>> Title: YANG Modelling in IETF WGs – Sharing Lessons Learned
>>
>> Description: Expanding on the IETF116 presentation “Lessons from Working
>> on BGP YANG” from Jeffrey Haas and Mahesh Jethanandani. Input a
And here is some background on the talk on Monday. Begin forwarded message:From: Jeffrey Haas Date: June 2, 2023 at 10:15:49 AM PDTTo: RTGWG Cc: Mahesh Jethanandani Subject: Fwd: Network Modeling (netmod) WG Interim Meeting: 2023-06-05Sorry for the late forward. This coming Monday, Mahesh and I
much later in the document.
Please define in a Terminology Section or somewhere before first use.
> IoT Devices SHOULD prefer doing DNS to with the DHCP provided DNS servers.
Grammar?
> The ADD WG has written [I-D.ietf-add-dnr] and [I-D.ietf-add-ddr] to provided.
Same here.
Mahesh Jet
[Med] Added a new section.
>
>> Is there any way to merge some of these drafts together or do they all
>> have to be separate. It makes it difficult for the reader to follow
>> the solution.
>>
>> Nits:
>> Remove all the bold of lines within the draft. AFAIK it makes it
>> difficult for the user to read.
>>
>
> [Med] Done
>
>> ! Additional drafts reviewed
>> draft-ietf-opsawg-teas-common-ac-05
>>
>> Major Issues:
>> None
>>
>> Minor Issues:
>>
>> Is the goal of this draft to take items that are common between all
>> ACs for the L2NM & L2SM modules. Why not make this part of one of the
>> other drafts like the ac-glue or even the ACAAS draft.
>>
>> I would recommend showing how all 4 drafts work together in each of
>> the 4 drafts as they all work together to provide the overall AC
>> solution.
>>
>> draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
>> draft-ietf-opsawg-ntw-attachment-circuit-05
>> draft-ietf-opsawg-teas-attachment-circuit-06
>> draft-ietf-opsawg-teas-common-ac-05
>>
>
> [Med] Done.
>
>> Is there any way to merge some of these drafts together or do they all
>> have to be separate. It makes it difficult for the reader to follow
>> the solution.
>>
>> Nits:
>> None
>>
>>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
Mahesh Jethanandani
mjethanand...@gmail.com
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
rom the manufacturor. In a way,
>> one could see this as a firmware that has a bit of external firmware hosted
>> elsewhere. And these two can get out of sync. To me that just seems like
>> broken firmware and building a protocol mechanism to resolve thi
eshold event. Values for t
> ^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).
Section 6.23.1, paragraph 4
> | | | table below, and section Section 5.1. | | 2 | PmA | Pe
> ^^^
Possible typo: you repeated a word.
Section 6.24.2, paragraph 1
> SHOULD have this flag set, and vice-versa.) | ++--+-
>^^
The expression "vice versa" is spelled without hyphens.
Section 7.2.1, paragraph 1
> SHOULD have this flag set, and vice-versa.) | ++--+-
>^^
The expression "vice versa" is spelled without hyphens.
Mahesh Jethanandani
mjethanand...@gmail.com
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
identifying root causes of performance degra
> ^^^
The verb "help" is used with an infinitive.
Section 4.2, paragraph 6
> [RFC8883] for a behavior of an intermediate nodes that encounters an unknown
> ^
The plural noun "nodes" cannot be used with the article "an". Did you mean "an
intermediate node" or "intermediate nodes"?
Mahesh Jethanandani
mjethanand...@gmail.com
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
nline for more context.
>
> Cheers,
> Med
>
> De : Mahesh Jethanandani <mailto:mjethanand...@gmail.com>>
> Envoyé : dimanche 14 avril 2024 05:21
> À : draft-ietf-opsawg-ipfix-fi...@ietf.org
> <mailto:draft-ietf-opsawg-ipfix-fi...@ietf.org>
> Cc : op
ft-ietf-opsawg-ipfix-tcpo-v6eh.txt>.
>
> Please see more context inline.
>
> Cheers,
> Med
>
> De : Mahesh Jethanandani <mailto:mjethanand...@gmail.com>>
> Envoyé : dimanche 14 avril 2024 21:42
> À : draft-ietf-opsawg-ipfix-tcpo-v...@ietf.org
> <mailto:dr
but
other times it is used with a small k.
Document references draft-ietf-tsvwg-udp-options-28, but -32 is the latest
available revision.
Document references draft-ietf-opsawg-ipfix-tcpo-v6eh-08, but -10 is the latest
available revision.
Mahesh Jethanandani
mjethanand...@gmail.com
___
itu-t-sg-11-ietf-ls-on-the-new-work-item-itu-t-qmud_iot-framework-for-testing-and-monitoring-iot-devices-networks-using-technica-attachment-1.pdf
>
>LS196
>
> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2024-05-22-itu-t-sg-11-ietf-ls-on-the-new-work-item-itu-t-qm
references draft-ietf-opsawg-teas-attachment-circuit-09, but -13 is
the latest available revision.
Document references draft-ietf-opsawg-ntw-attachment-circuit-07, but -11 is the
latest available revision.
Document references draft-ietf-netmod-rfc8407bis-09, but -11 is the latest
available revisio
Mahesh will decide to skip that or not.
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
Mahesh Jethanandani
mjethanand...@gmail.com
_
what order they should be read in.
Time for me to write my own set of Cliff notes for the drafts that Warren so
good about. 😀
Mahesh Jethanandani
mjethanand...@gmail.com
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
S and DNSSD”, another WG LC, albeit shorter (1
>> week), would be in order.
>
> Works for me.
Mahesh Jethanandani
mjethanand...@gmail.com
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
lleviate them. It would be very beneficial to get
> IETF's participants feedback and suggestions on what is the better next step
> to take for BBF or its members towards IETF to get an IETF solution for the
> scalability issue identified.
> An IETF response liaison to
gt;
>> Errata has been reported to me by a software developer of a major vendor
>> working on implementation.
>>
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". (If it is spam, it
>> will be removed shortly by the RFC Pro
exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si
with all these.
>
> Cheers,
> Med
>
> De : Mahesh Jethanandani <mailto:mjethanand...@gmail.com>>
> Envoyé : jeudi 11 juillet 2024 18:27
> À : BOUCADAIR Mohamed INNOV/NET <mailto:mohamed.boucad...@orange.com>>
> Cc : Paul Wouters mailto:paul.wo
mcr+i...@sandelman.ca>> .
> o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> ___
> OPSAWG mailing list -- opsawg@ietf.org <mailto:opsawg@ietf.org>
> To unsubscribe send an email to opsawg-le...@ietf.org
> <mai
;> registry should be handled in the future.
>>
>> I never saw an update to an obsoleted RFC. IMO, it does not make sense to go
>> that way.
>>
>> We can add a note with a summary to help readers navigate with all these.
>>
>> Cheers,
>> Med
>
_____
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> ___
> OPSAWG mailing list -- opsawg@ietf.org
> To unsubscribe send an email to opsawg-le...@ietf.org
Mahesh Jethanandani
mjethanand...@gmail.com
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
!
Thanks.
Mahesh Jethanandani
mjethanand...@gmail.com
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
Hi Tirumal,
Thanks for your responses. See inline for some follow-up comments.
> On Aug 7, 2024, at 7:17 AM, tirumal reddy wrote:
>
> Hi Mahesh,
>
> Thanks for the review. Please see inline
>
> On Tue, 6 Aug 2024 at 04:38, Mahesh Jethanandani via Datatracker
>
> https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerations-16.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-iot-dns-considerations
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-mud-iot-dns-considerations-16
>
>
>
> I would appreciate someone new to the document to proof the result.
> s/requires/required/ at least.
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
Mahesh Jethanandani
mjet
iff?url2=draft-ietf-opsawg-ipfix-fixes-12>.
> This is to address the second part of the feedback above. A note already
> exists at the top level that 5102 is obsoleted by 7012, though.
>
> Cheers,
> Med
>
> De : Mahesh Jethanandani
> Envoyé : lundi 22 juillet 202
tf.org/wg/opsawg/documents/>
>
> Regards, Benoit
>
> On 8/20/2024 1:59 PM, Joe Clarke (jclarke) wrote:
>> Hey, Mahesh. I was kinda surprised to see this recharter. I know we
>> discussed possibly doing this, but it seemed to jus
datatracker.ietf.org/wg/opsawg/documents/>
>
> Regards, Benoit
>
> On 8/20/2024 1:59 PM, Joe Clarke (jclarke) wrote:
>> Hey, Mahesh. I was kinda surprised to see this recharter. I know we
>> discussed possibly doing this, but it seemed to jus
ns-17.html
>>
>> <https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerations-17.html>
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-mud-iot-dns-considerations-17
>>
>> <https://author-tools.ietf.org
raft-ietf-opsawg-mud-14>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/ <ftp
> ___
> OPSAWG mailing list -- opsawg@ietf.org <mailto:opsawg@ietf.org>
> To unsubscribe send an email to opsawg-le...@ietf.org
> <mailto:opsawg-le...@ietf.org>
Mahesh Jethanandani
mjethanand...@gmail.com
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
Charactering…
<https://mailarchive.ietf.org/arch/msg/opsawg/XQw20HM2tlzhecyo6EJrrGKj-wY/>
[1] https://www.ietf.org/administration/policies-procedures/code-of-conduct/
[2] https://secure.ethicspoint.com/domain/media/en/gui/71269/index.html
[3] https://www.ietf.org/contact/ombudsteam/
Mahesh Jethan
pecific.
s/specific to a given service or be shared/specific for a given service or are
shared/
Document references draft-ietf-teas-ietf-network-slice-nbi-yang-13, but -16 is
the latest available revision.
Document references draft-ietf-netmod-rfc8407bis-14, but -20 is the latest
available revisi
one or multiple ACs (e.g., a
>parent AC and its child ACs).
s/augmentations to/augmentations of/
Section 5.3, paragraph 4
> The exact definition of the specific provisioning profiles profiles
>is local to each service provider. The model only includes an
>identifier
teas-ietf-network-slice-nbi-yang-13, but -16 is
the latest available revision.
Document references draft-ietf-idr-bgp-model-17, but -18 is the latest
available revision.
"OPSAWG", paragraph 0
> 024 YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACa
>
: A later version (-13) exists of
> draft-ietf-opsawg-teas-common-ac-12
>
> == Outdated reference: A later version (-21) exists of
> draft-ietf-netmod-rfc8407bis-20
>
> == Outdated reference: A later version (-11) exists of
> draft-ietf-opsawg-ac-lxsm-lxnm-glue-10
>
Hi Carlos,
Thanks, first of all, for stepping in to perform the OPSDIR review of the
document at the last minute.
I read your review. Was there anything, in particular, you felt had not been
addressed from the YANG Doctors review?
Mahesh Jethanandani
mjethanand...@gmail.com
> On Dec 5, 2024, at 10:51 AM, Russ Housley wrote:
>
>
>
>> On Dec 2, 2024, at 5:34 PM, Mahesh Jethanandani
>> wrote:
>>
>> Hi Russ,
>>
>> Thanks for the review.
>>
>>> On Dec 2, 2024, at 2:08 PM, Russ Housley via Datatrack
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed
ur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
Mahesh Jethanandani
mjethanand...@gmail.com
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
Hi Joe,
I do agree that it makes sense to keep this work in OPSAWG. But since you
mention it, I am sure this liaison statement is being shared with the DMM WG to
get their input on whether they would like any addition to the statement.
Thanks.
Mahesh Jethanandani
mjethanand...@gmail.com
>
ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
>> ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou
>> falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been
>> modified, changed or falsified.
>> Thank you.
>
Mahesh Jethanandani
mjethanand...@gmail.com
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
[Speaking as a contributor]
Hi John,
The advantage that I see with Option 3, and the reason I believe Rob suggested
is that if there is change in the IM model, you would need to update both YANG
and the IPFIX model. From a tracking perspective, it would be easier to do that
if they are all in
eclare OPSAWG to be a catch-all for any work
> from anywhere within the IETF. I feel the existing text leaves open
> that interpretation, though.
Fair enough. Will accept your edit.
Mahesh Jethanandani
mjethanand...@gmail.com
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
ay or MaxDel
> ^^^
A comma may be missing after the conjunctive/linking adverb "However".
Section 7.3, paragraph 1
> packet was transmitted by the node, etc). Based on this information, differ
>
Resending with the correct address for IANA.
> On Apr 28, 2025, at 3:02 PM, Mahesh Jethanandani
> wrote:
>
> Hi Authors,
>
> Thanks for putting this document together. The document has already been
> reviewed by several folks, so most of these comments should
nection Mode was
> enabled, a single TCP connection may contain multiple
> TACACS+ sessions.";
s/completed/established/
s/was not enabled/is not enabled/
s/was enabled/is enabled/
Section 4, paragraph 5
> also cite RFC - fixes a must statement under 'tacacs-plus' by adding a m
> ^
The word "statement" is a noun or an adjective. A verb or adverb is missing or
misspelled here, or maybe a comma is missing.
Section 4, paragraph 28
> n "Explicit configuration of a server credentials."; uses server-authenticati
>
The plural noun "credentials" cannot be used with the article "a".
Thanks
Mahesh Jethanandani
mjethanand...@gmail.com
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
fill out this form to indicate your interest in this or other positions.
https://forms.gle/KWeprcVoqUUW9Zrb9 <https://forms.gle/KWeprcVoqUUW9Zrb9>
Thanks.
Mahesh Jethanandani
mjethanand...@gmail.com
___
OPSAWG mailing list -- opsawg@ietf.
er”. More on it later in this thread.
>
> Cheers,
> Med
>
>> -Message d'origine-
>> De : Mahesh Jethanandani > <mailto:mjethanand...@gmail.com>>
>> Envoyé : mercredi 30 avril 2025 04:17
>> À : draft-ietf-opsawg-secure-tacacs-yang@ie
decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --
> RFC5706 (draft-ietf-opsawg-operations-and-management-09)
> --
, if necessary.
>
> --
> RFC5706 (draft-ietf-opsawg-operations-and-management-09)
> ------
> Title : Guidelines for Considering Operations and Management of
> New Protocols and Protocol Extensions
> Publicat
mation that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, chang
ensure quality and
> sustained progress. "
Thanks for the suggestions. But, I am wary of putting up too many words like
“relevance” in deciding what work needs to be adopted. It is farily subjective
and who decides relevance?
I will put up some variation of the suggested text.
Tha
ng )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> ___
> OPSAWG mailing list -- opsawg@ietf.org
> To unsubscribe send an email to opsawg-le...@ietf.org
Mahesh Jethanandani
mjethanand...@gmail.com
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
needed for decades.
Section 2.2, paragraph 11
> are associated with specific operation system captures, and are operating s
>
The word "operation" doesn't fit in this context.
Thanks
Mahesh Jethanandani
mjethanand...@gmail.co
On Jun 9, 2025, at 8:17 PM, Guy Harris <mailto:ghar...@sonic.net>> wrote:
>
>> On Jun 9, 2025, at 5:29 PM, Mahesh Jethanandani
>> wrote:
>>
>>> Section 2.2, paragraph 8
>>>> * Values from 0 to 32767 are allocated following a First-Come Fir
> On Jun 10, 2025, at 2:01 PM, Guy Harris wrote:
>
> On Jun 10, 2025, at 1:31 PM, Mahesh Jethanandani
> wrote:
>
>>> On Jun 9, 2025, at 8:17 PM, Guy Harris >> <mailto:ghar...@sonic.net>> wrote:
>>
> ...
>
>>>
>>>
quot; is a disappointing excuse.
>>
>>
>> Otherwise, please apply the changes.
> Thanks and regards, Benoit
>
>
>>
>>
>> Thanks,
>> P.
>>
>> From: Benoit Claise
>> <mailto:benoit.cla...@huawei.com>
>> Sent: Wedn
easons, so I came up with the LINKTYPE_
>> values, which normally had the same numerical value as the
>> corresponding DLT_, but, for cases where the corresponding DLT_ had
>> different values on different OSes, I assigned a *new* value for the
>> LINKTYPE_, and mapped between the DLT_ values used in the libpcap APIs
>> and the LINKTYPE_ values used in capture files.)
>
> If only we'd done this IANA registry back in 1995 ;-)
>
>
>
>
>
> --
> Michael Richardson mailto:mcr+i...@sandelman.ca>> .
> o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
Mahesh Jethanandani
mjethanand...@gmail.com
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
Hi Benoit,
Would it make sense to have a statement in the draft that says as much?
Thanks.
Mahesh Jethanandani
mjethanand...@gmail.com
> On Jul 19, 2025, at 10:30 AM, Benoit Claise
> wrote:
>
> Hi Linda,
>
> Thanks for your review.
> You highlighted a valid security
. When it says not to have references in the abstract, what it is
referring to is references using hyperlink. A textual reference to an RFC
(without square braces) is fine.
Cheers.
Mahesh Jethanandani
mjethanand...@gmail.com
___
OPSAWG mail
anyone.
>
> Thanks.
>
> Joe and Benoît
> ___
> OPSAWG mailing list -- opsawg@ietf.org <mailto:opsawg@ietf.org>
> To unsubscribe send an email to opsawg-le...@ietf.org
> <mailto:opsawg-le...@
ity or operational best-
> 455 practice clarifications are needed. It would be helpful to
> 456 reviewers, those who may update or write extensions to the protocol
> 457 in the future, or to those deploying the protocol, to know the
> 458 rationale regarding the decisions on manageability of the protocol at
>
etings/blob/main/123/agenda.md>.
> We had the time to accept everyone that asked for a slot, and have time for
> some good discussion. Please review this to let us know if we are missing
> anyone.
>
>
>
> Thanks.
>
>
>
> Joe and Benoît
>
> _
t; Blue Fern Consulting <https://bluefern.consulting/>
> Email: Carlos@Bluefern.consulting <mailto:Carlos@Bluefern.consulting>
>
> From: Mahesh Jethanandani
> Date: Saturday, July 12, 2025 at 2:57 AM
> To: Alvaro Retana
> Cc: draft-opsarea-rfc5706...@ietf.org ,
> opsawg@ietf.org
Mahesh Jethanandani has entered the following ballot position for
draft-ietf-opsawg-mud-iot-dns-considerations-13: No Objection
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
Mahesh Jethanandani has entered the following ballot position for
draft-ietf-opsawg-mud-tls-15: Discuss
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.)
Please refer to
Mahesh Jethanandani has entered the following ballot position for
draft-ietf-opsawg-mud-iot-dns-considerations-16: 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
Mahesh Jethanandani has entered the following ballot position for
draft-ietf-opsawg-mud-tls-17: No Objection
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.)
Please
Mahesh Jethanandani 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
Mahesh Jethanandani has entered the following ballot position for
charter-ietf-opsawg-04-03: 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
Mahesh Jethanandani has entered the following ballot position for
draft-ietf-opsawg-tacacs-tls13-21: No Objection
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
74 matches
Mail list logo
