he comments to
be addressed from Yangdoctors and Opsdir before sending it to IESG.
Thanks.
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
rfc8407bis.txt>.
>
> Let me know if there are other occurrences that I missed where we need to
> follow “modeled after” approach. Thank you.
>
> Cheers,
> Med
>
> De : Kent Watsen
> Envoyé : jeudi 12 septembre 2024 18:02
> À : BOUCADAIR Mohamed INNOV/NET
> Cc : Mah
can add a sentence to that effect. Something like:
"This module imports groupings from ietf-crypto-types YANG module defined in
[I-D.ietf-netconf-crypto-types]. Security considerations described in that
draft apply to this module also.”
Better?
>
>
>
Mahesh Jethanandani
mjeth
atures, if necessary.
This model is designed to be very simple for maximum flexibility.
Some optional features are defined in this document to specify functionality
that is present in specific vendor configurations.
NEW:
The module defines leafs that are common across impleme
d of packets?
I am not a TLS expert, but the certificate+key is used to establish a TLS
session. Once the TLS session is established, both the client and server agree
on symmetric session key for encrypting the payload.
>
> facility-filter seems badly named as it also filters for severit
for severity ? Maybe
> syslof-filter ?
>
> [JMC] I agree with you on this. In the GitHub issue I mentioned we could go
> with syslog-filter or just filter (as syslog should be implied).
>
> [JMC] Mahesh and I will discuss and respond again with new text replies to
> your ot
H) [RFC6242]
> - Using the NETCONF Protocol over Transport Layer Security (TLS) with
> Mutual X.509 Authentication [RFC 7589]
> - Using NETCONF over QUIC connection [NETCONF-QUIC]
>
> For the RESTCONF protocol [RFC8040], the mandatory-to-implement transport is
> HTTPS, as def
gt; 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
diagram.
There is an option to print the tree diagram without expanding the groupings,
but then you will see just the name of the grouping without knowing what is
being included as part of the grouping. We erred on the side of showing what is
included.
Thanks.
>
> Reg
lector’ used
each time for facility of console, remote and file.
>
> Would it be possible to import TLS and authentication from other YANG models ?
It does indeed import groupings from ietf-tls-client module defined in
draft-ietf-netconf-tls-client-server modu
Mahesh Jethanandani has entered the following ballot position for
draft-ietf-netmod-syslog-model-32: Recuse
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
Hi Juergen,
Coming back to this thread. I was hoping for more folks to comment on this
thread. But with the opinions we have, it seems the consensus is around ...
> On Apr 18, 2024, at 6:05 AM, Jürgen Schönwälder
> wrote:
>
> On Tue, Apr 16, 2024 at 10:08:09AM -0700, Mahesh
tf.org/doc/draft-ietf-netmod-acl-extensions/07/> has
> now the sets defined as reusable groupings + augment the ACL models. The
> structure is basically a revert back to what we used to have in -00.
>
> Cheers,
> Med
>
> De : netmod De la part de Mahesh Jethanandani
> Env
>
> The working group last call ends on May 13th.
> Please send your comments to the working group mailing list.
>
> Positive comments, e.g., "I've reviewed this document
> and believe it is ready for publication", are welcome!
> This is us
ing conventions (which this message/thread was
> about). If we are now taking a fresh look at things, I can produce a
> new version, but this really only makes sense if we are willing to
> actually publish this update.
>
> /js
>
> On 06.04.24 06:04, Mahesh Jethanandani wrote:
&g
e for 'ipv4-address'.
>> Fortunately this is 100% out of scope for the 6man draft.
>>>
>>> (3) draft-ietf-netmod-rfc6991-bis-15, p 28, sec 4. Internet Protocol Suite
>>> Types
>>>
>>> The canonical format of IPv6 addresses uses the textual
>>> representation defined in Section 4 of RFC 5952. The
>>> canonical format for the zone index is the numerical
>>> format as described in Section 11.2 of RFC 4007.";
>>>
>>> Would it make sense to also change the canonical format for the zone index
>>> to be interface name (or converted interface name) rather than numeric id
>>> (when used in YANG models)?
>> Please not. In a completely different context (RFC 8990) I've written code
>> handling link local addresses and multiple interfaces, and driving it by
>> interface index rather than by name is definitely the way to go. Humans may
>> like the names, but the numbers are much better for programs.
>> Regard
>> Brian
>>>
>>> This comment also applies for the same change for 'ipv4-address'.
>>>
>>>
>>> Thoughts and comments on these two issues are welcome.
>>>
>>> Regards,
>>> Rob
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
>
>struct timeval {
>time_t tv_sec; /* seconds */
>suseconds_t tv_usec;/* microseconds */
>};
>
> But if there is a use case for milliseconds64, I can easily add it.
> we
Hi Joe,Your name popped up on this thread. See below. Mahesh Jethanandani mjethanand...@gmail.comOn Feb 8, 2024, at 4:01 AM, mohamed.boucad...@orange.com wrote:
Hi Mahesh, all,
FWIW, we submitted an updated version of the draft to address the pending points from your reviews. A diff to
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod
> <https://www.iet
> what we want (I'm split on this one), but I was interested in the opinion of
> the list whether this is allowed today.
>
Please continue to have the discussion here, but suggest you create a new issue
here <https://github.com/netmod-wg/yang-next/issues>, so the
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.
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod
> <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
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.
> ___
> yang-doctors mailing list
> yang-doct...@ietf.org <mailto:yang-doct...@ietf.org>
> https://www.ietf.org/mailman/listinfo/yang-doctors
> <https://www.ietf.org/mailman/listinfo/yang-doctors>
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Reviewer: Mahesh Jethanandani
Review result: Almost Ready
I had started providing my review comments before I was assigned to (formally)
review the document. I will therefore (re)use that thread here. And in order to
understand the level of quotation, I have added either >>, a >, or n
see more context inline.
>
> Cheers,
> Med
>
> De : netmod mailto:netmod-boun...@ietf.org>> De la
> part de Mahesh Jethanandani
> Envoyé : mardi 5 décembre 2023 23:09
> À : Lou Berger mailto:lber...@labn.net>>
> Cc : NETMOD Group mailto:netmod@ietf.org>&
x27;ve reviewed this document
> and believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
>
> Thank you,
> Lou (Co-Chair & doc Shepherd)
>
> ___
>
> _______
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
sorry that we missed them in RFC 8519. Examples of
that include definitions for ipv4-fragment, ipv6-fragment, mpls etc. It is for
those fundamental definitions, my personal opinion (and as author of RFC 8519)
is that it should be -bis.
Cheers.
Mahesh Jethanandani
mjethanand...@gmail.com
t-boucadair-netmod-rfc8407bis/
>
> Please voice your support or technical objections to adoption on the
> list by the end of the day (any time zone) Sept 25.
>
> Thank you,
> Lou (as Co-chair)
>
Mahesh Jethanandani
mjethanand...@gmail.com
> On Aug 29, 2023, at 1:09 PM, Carsten Bormann wrote:
>
> Is there a good place where I can rsync IETF YANG modules from?
rsync -avz --delete rsync.iana.org::assignments/yang-parameters
Mahesh Jethanandani
mjethanand...@gmail.com
_
to it for awhile, though he’s happy to do so upon returning.
>
> Thank you,
> Kent (as Co-chair)
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.
type to the new types that will be defined in
the IANA module? Is there a plan to include ICMP subtype (called code in RFC
8519) both in the new IANA module, but also update RFC 8519 with the definition
in the IANA module?
Regards
Mahesh Jethanandani
mjethanand...@gmail.com
, even if doing so
> again:
> Ebben Aries
> Juergen Schoenwaelder
> Mahesh Jethanandani
> Michael (Wangzitao)
> Jason Sterne
>
> Thank you,
>
> Lou
>
> On 1/16/2023 5:53 PM, Lou Berger wrote:
>> Authors, Contributors, WG,
>>
>&
import ietf-access-control-list {
>prefix acl;
> }
>
> Cheers,
> Med
>
> De : Mahesh Jethanandani
> Envoyé : mercredi 18 janvier 2023 19:32
> À : netmod
> Cc : BOUCADAIR Mohamed INNOV/NET ; Sonal
> Agarwal ; huangyi...@yahoo.com; d...@blairh
ts (ACLs)
> Publication Date: March 2019
> Author(s) : M. Jethanandani, S. Agarwal, L. Huang, D. Blair
> Category: PROPOSED STANDARD
> Source : Network Modeling
> Area: Operations and Management
> Stream : IETF
> Verifying Party : IESG
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
: YANG Data Model for Network Access Control Lists (ACLs)
> Publication Date: March 2019
> Author(s) : M. Jethanandani, S. Agarwal, L. Huang, D. Blair
> Category: PROPOSED STANDARD
> Source : Network Modeling
> Area: Operations and Management
> Stream : IETF
> Verifying Party : IESG
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
tf.org/doc/draft-dbb-netmod-acl/
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
e
> defined, the YANG doctors might consider recommending them in their reviews.
>
> Such things may already be good practice, but perhaps I'm not aware of it.
>
> -- Jeff
>
> * As a matter of fact, it was performing a code review against exactly this
> point that rai
of interface-type.
Thanks
Mahesh Jethanandani
mjethanand...@gmail.com
> On Aug 27, 2022, at 2:42 PM, Kent Watsen wrote:
>
> Ensure that all modules defining identities are *implemented*.
>
> In yanglint, the -i parameter or passing each module on the command line
> c
-type;
description
"This identity is used as a base for all interface types
defined in the 'ifType definitions' registry.";
}
Thanks
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
I have followed the discussions on this draft and believe it is ready for
publication.
>
> On Thursday, February 3, 2022, 09:54:23 PM EST, Kent Watsen
> wrote:
>
>
> Dear NETMOD WG,
>
> This message begins a two-week WGLC for draft-ietf-netmod-rfc6991-bis-11
> ending on Friday, February 1
Hi Qin,
> On Feb 6, 2022, at 6:10 PM, Qin Wu wrote:
>
> Thanks Mahesh for valuable review. Please see reply inline below.
>
> -Qin
>> -----邮件原件-
>> 发件人: Mahesh Jethanandani via Datatracker [mailto:nore...@ietf.org]
>> 发送时间: 2022年2月1日 13:25
>> 收件人:
to generate synthetic prefixes without
> breaking the content, but at least this would solve the problem.
> -
>
> BCP216 (RFC8407 - Guidelines for Authors and Reviewers of Documents
> Containing YANG modules) doesn’t make any mention of how XML namespaces
> should be used, only that example XML/ JSON should be included and that these
> examples need to be validated (pyang and yanglint are mentioned for this).
>
> Does this guidance need to be updated to reflect expert review comments above?
>
> Thanks,
> Ian
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod
> <https://www.ietf.org/mailman/listinfo/netmod>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Reviewer: Mahesh Jethanandani
Review result: On the Right Track
Summary:
This document defines a method to tag data objects associated with operation
and management data in YANG Modules. This YANG data object tagging method can
be used to classify data objects from different YANG modules and
Module "tmp" parsing failed.
>
>
> Regards,
>
> - Olumide
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
lação vigente. Se
> recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente
> por esta mesma via e proceda a sua destruição
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
A related question.
> On Sep 14, 2021, at 12:31 PM, Mahesh Jethanandani
> wrote:
>
> Hi Martin,
>
>> On Sep 14, 2021, at 11:17 AM, Martin Björklund > <mailto:mbj+i...@4668.se>> wrote:
>>
>> Mahesh Jethanandani > <mailto:mjethanand...@gma
Hi Martin,
> On Sep 14, 2021, at 11:17 AM, Martin Björklund wrote:
>
> Mahesh Jethanandani <mailto:mjethanand...@gmail.com>> wrote:
>> Hi Juergen,
>>
>>> On Sep 14, 2021, at 10:17 AM, Jürgen Schönwälder
>>> wrote:
>>>
>>>
nk there are different patterns to choose from
> to handle this situation with their various pros and cons.
>
> /js
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.jacobs-university.de/>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod
> <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
>
> _______
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mah
;. In the
absence of a proper definition, one should follow what RFC 7950 says.
Comments?
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
st
> Ericsson Hungary Ltd.
> Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com
> <mailto:balazs.leng...@ericsson.com>
>
> ___
> netmod mailing list
> netmod@
A contrarian view:
I find the use of sub-modules helpful when I want to use separate files to
maintain part of the module that is logically separate, while
maintaining/restricting the use of them to a single namespace.
The fact that tools have a problem with trying to compile a sub-module can b
+1.
> On Apr 24, 2020, at 12:39 PM, Sterne, Jason (Nokia - CA/Ottawa)
> wrote:
>
> That seems like a reasonable approach to me.
> Jason
>
> From: netmod On Behalf Of Rob Wilton (rwilton)
> Sent: Friday, April 24, 2020 3:34 PM
> To: Kent Watsen ; netmod@ietf.org
> Subject: Re: [netmod] [Techn
__
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
As someone who has reviewed the draft, I want to say I support the work. The
draft is short and easy to read.
Thanks.
> On Mar 26, 2020, at 11:46 AM, Kent Watsen wrote:
>
> Dear All,
>
> This WGLC has received zero responses, which is insufficient to progress the
> document at this time. Th
Reviewer: Mahesh Jethanandani
Review result: Ready with Nits
I am not an expert in geo location. If my understanding of the geo location
model is incorrect, feel free to educate me and everyone else. This review is
looking at the draft from a YANG perspective. With that said, I have marked it
as
config but refers to a non-config leaf "name" defined at
ietf-subscribed-notificati...@2019-09-09.yang:1046
Have other encountered this error? If we agree this is an error, is there a
-bis to fix this?
Thanks.
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
No, I am not aware of any IPR that applies to this draft.
> On Mar 2, 2020, at 2:13 PM, Lou Berger wrote:
>
>
> Authors, Contributors, WG,
>
> As part of preparation for WG Adoption:
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm
Thanks to Benoit for pointing out …
No, I am not aware of any IPR that applies to this draft.
Cheers.
> On Mar 2, 2020, at 2:13 PM, Lou Berger wrote:
>
>
> Authors, Contributors, WG,
>
> As part of preparation for WG Adoption:
>
> Are you aware of any IPR that applies to drafts identified a
Hi Jason,
yanglint does validate XML instance data for must statements:
MAHESH-M-M8D1:/Volumes/External/git/my-YANG-public/src/model/draft *833 >
yanglint -t auto -s -i -p common
.../../../build/mef-legato-servi...@2018-07-17.yang
MEF6.2-bwp-per-uni-mef-interface-configuration.xml
err : Must
mporting "ietf-routing-policy" module into "ietf-bgp" failed.
err : Module "ietf-bgp" parsing failed.
>
> Thanks,
> Chris.
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
The network-instances YANG model [RFC8529] gives an example in Appendix A.1 of how to use schema mount to mount the routing protocol. An example modeled along those lines for the BGP YANG model, and enclosed herewith fails validation using yanglint with the following error. What am I doing wrong?Va
ist
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
nior Specialist
> Ericsson Hungary Ltd.
> Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com
> <mailto:balazs.leng...@ericsson.com>
>
> ___
> netmod mailing list
> netmod@ie
.org/html/draft-ietf-netmod-module-tags-09
>>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-module-tags-09
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-09
>>>
>&g
n look at them and take
> an informed decision whether this is something they can use as well?
> Having some concrete use cases (in the IETF) is likely useful to make
> something a common YANG datatype.
>
> /js
>
> On Mon, Sep 30, 2019 at 02:27:49PM -0700, Mahesh Jethanandani wrote
s needed. Anyway, these are the instances I know of
that could use these definitions. I am sure there are more.
Cheers.
>
> /js
>
> On Fri, Sep 27, 2019 at 06:39:54PM -0700, Mahesh Jethanandani wrote:
>> Hi Juergen,
>>
>> Is there a plan to add more URI syntax co
Hi Juergen,
Is there a plan to add more URI syntax components in rfc6991bis? I know there
is a typedef for uri, but I was looking specifically for the following that are
defined in RFC 3986.
Scheme
Authority field including
User information
Path
Query
Fragment
Thanks.
Mahesh Jethanandani
tyi wrote:
>
> [Dmytro]
> Hello Mahesh Jethanandani,
> Thank you for your comment.
> Please find answers inline.
>
> >I find the representation of a service model in this draft for a uCPE as too
> >simple. In reality, on a uCPE, you could be running a Network Servi
d SW have
> >different device-attributes. SW does not require VNFD attributtes.
> >If we do not distinguish nodes, and only extend the grouping "device
> >attributes" for required attributes the switch will have the properties that
> >are unused leafs which represent the VM-device-attributes.
> >>VNF lifecycle management is separated from topology construction, wrong?
> >[Dmytro]:
> >a) In case of the NFVIs uCPE the same High Level interface allows to
> >configure both topology construction and VM lifecycle management in the same
> >transaction.
> >b) We can not activate Network Service Descriptor without consituent VM node
> >information. At the moment of NSD activation we already have to set the VM
> >node information such as VM capabilities that can be created (previosly)/(at
> >the moment of configuration of NSD) but have to be a part of the network
> >service descriptor at the moment of activation.
> >[Dmytro]
> >The Internet Draft also defines the term uCPE that is not defined at IETF
> >yet.
> >___
> >netmod mailing list
> >netmod@ietf.org <mailto:netmod@ietf.org>
> >https://www.ietf.org/mailman/listinfo/netmod
> ><https://www.ietf.org/mailman/listinfo/netmod>
>
> __
> Dmytro SHYTYI
>
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
the report, if necessary.
>
> --
> RFC8519 (draft-ietf-netmod-acl-model-21)
> --
> Title : YANG Data Model for Network Access Control Lists (ACLs)
> Publication Date: March 2019
> A
> On Apr 2, 2019, at 11:27 AM, Martin Bjorklund wrote:
>
> And for the record (again, perhaps), I think this is a bad idea in
> general, and I am not sure an exception is needed in this case.
+1
Mahesh Jethanandani
mjethanand.
ust that *that* data type forbids
> bits to be set in the mask portion of the address, which is correct for the
> routing table use case, but means it can't be used to describe an interface
> address and mask.
>
> kll
Mahesh Jethanandani
mjethanand...@gmail.com
>
>
the address and
prefix should be separate.
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
ld then encode the
> value as a 4 byte binary value, the XML and JSON encoder would use the
> canonical string representation. If the binary-representation is not
> specified, then the generic CBOR encoding rules apply. I assume that
> additional binary representation definitions will only be needed for a
> coupl
> On Mar 29, 2019, at 11:31 AM, Juergen Schoenwaelder
> wrote:
>
> On Fri, Mar 29, 2019 at 10:50:52AM -0700, Mahesh Jethanandani wrote:
>>
>> The combination of these bullet items, and maybe other bullet items does not
>> make clear if there was any consen
her SDOs decide. Has that sentiment changed?
If it is the case, the split between the requirements of SDO and the vendors is
inevitable.
Thanks.
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
ice your support or objections before April 8.
>
> Kent (and Lou and Joel)
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
___
our undisclosed IPR. For more information, please see the RFCs listed
> above
> and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty
> <http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty>.
>
> Thank you,
> Kent // as co-Chair
>
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Hi Kent,
I think it makes sense to have a virtual meeting before 104.
Mahesh Jethanandani
mjethanand...@gmail.com
> On Jan 15, 2019, at 6:45 AM, Kent Watsen wrote:
>
> I'm interested as well.
>
> PS: I've been too busy to setup a virtual meeting for us to finish
ch) number.
Mahesh Jethanandani
mjethanand...@gmail.com
> On Nov 9, 2018, at 5:52 AM, Andy Bierman wrote:
>
> Hi,
>
> A few comments on the netmod meeting yesterday
>
> 1) what is a bugfix?
> It is not encouraging that the DT cannot agree on the scope of a bugfix.
> B
gt;
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
> On Oct 11, 2018, at 8:04 AM, Martin Bjorklund wrote:
>
> Mahesh Jethanandani wrote:
>>
>>
>>> On Oct 10, 2018, at 11:51 PM, Martin Bjorklund wrote:
>>>
>>> I just which there was a one-click way (or better some repo) to get
>>> a
> On Oct 10, 2018, at 11:51 PM, Martin Bjorklund wrote:
>
> I just which there was a one-click way (or better some repo) to get
> all files.
There is. Benoit had written it, but for the life of me I cannot remember what
it is called. Have send him a note, but he is offline till
[Adding softwire chairs, document shepherd, and AD, and moving netmod to Bcc]
Yes.
> On Oct 3, 2018, at 4:51 PM, Reshad Rahman (rrahman) wrote:
>
> Thanks Mahesh. So the IESG is supposed to ask for YD review at this point for
> draft-ietf-softwire-yang?
>
> From: Mahesh Je
uring the IETF Last Call.
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
t;
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
bout this?
OLD:
The match criteria allows for definition of packet headers and
metadata, all of which must be true for the match to occur.
NEW:
The match criteria allows for definition of packet headers and
metadata, the contents of which must match the definitions.
Thanks.
Mahes
t; §4.3 and 4.4:
>
> These examples use IPv4 addresses exclusively. Please update to use IPv6 or a
> mix of IPv4 and IPv6. See
> https://www.iab.org/2016/11/07/iab-statement-on-ipv6/
> for additional information.
Section 4.3 has two examples, one for IPv4 and one for IPv6.
Tha
header field in ICMP grouping from ‘type uint32’ to ‘type
binary’, as already agreed, to address Mirja’s DISCUSS. The field will be
unbounded.
- Add a reference to RFC 4443 in the grouping.
- At this point the grouping should be able to cater to both icmpv4 and ic
Sep 26, 2018, at 10:06 PM, Suresh Krishnan wrote:
>
> Hi Mahesh,
> Thanks for your quick reply. Please find comments inline.
>
>> On Sep 27, 2018, at 12:57 AM, Mahesh Jethanandani
>> wrote:
>>
>> Hi Suresh,
>>
>>> On Sep 26, 2018, at 9:36 PM
Hi Suresh,
> On Sep 26, 2018, at 9:36 PM, Suresh Krishnan wrote:
>
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-netmod-acl-model-19: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC line
7;t in the well known
> acronyms list. RFC2474 perhaps?
It is in Section 1 and 1.1.
>
> Section 3:
> "These include features such as "Device can support ethernet headers" or
> "Device can support of IPv4 headers". "can support of" makes no sense. Also, I
> *think* Ethernet is uppercase. This is a nit.
Will
s/support/match on/
Thanks.
>
>
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
lly warrant protections against unauthorized log access and a logs
> retention policy.
How about this addition to the section under list of subtrees and data nodes
that are sensitive and vulnerable:
/acls/acl/aces/ace/actions/logging: This node specifies ability to log
packets
;? (Also in subsequent instances.)
Ok.
>
> Section A.1
>
> It's unclear that using a...@newco.com (in particular, the @newco.com part)
> in an example is reasonable; @newco.example would be better.
I do not know if a contact e-mail address, in an example of a YANG model, is
significant.
Thanks.
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
> On Sep 25, 2018, at 12:32 PM, Joe Clarke wrote:
>
> Reviewer: Joe Clarke
> Review result: Has Nits
>
> I have been assigned to review this document on behalf of the ops
> directorate.
> This document defines a YANG model for configuring access control lists (ACLs)
> as well as other modul
Hi Mirja,
See responses inline.
> On Sep 25, 2018, at 2:32 AM, Mirja Kuehlewind (IETF)
> wrote:
>
> Hi Mahesh,
>
> please see below.
>
>> Am 25.09.2018 um 00:56 schrieb Mahesh Jethanandani :
>>
>>
>>
>>> On Sep 21, 2018, at 6:47 AM
1 - 100 of 231 matches
Mail list logo
