Re: [netmod] draft-ietf-netmod-nmda-diff - IPR verfication request

[Jeff Tantsura]

Joel,

Corrected statement - No, I'm not aware of any IPR that applies to this draft 
that has not been previously disclosed.

Cheers,
Jeff
On Feb 26, 2020, 1:42 AM -0500, Jeff Tantsura , wrote:
> Joel,
>
> No, I'm not aware of any IPR that applies to this draft.
>
> Cheers,
> Jeff
>
> > On Feb 17, 2020, at 11:44, Joel Jaeggli  wrote:
> >
> > No, I'm not aware of any IPR that applies to this draft
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-nmda-diff - IPR verfication request

[Jeff Tantsura]

Joel,

No, I'm not aware of any IPR that applies to this draft.

Cheers,
Jeff

> On Feb 17, 2020, at 11:44, Joel Jaeggli  wrote:
> 
> No, I'm not aware of any IPR that applies to this draft


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call: draft-ietf-netmod-sub-intf-vlan-model-05

[Jeff Tantsura]

Yes/support 

Cheers,
Jeff

> On Jul 9, 2019, at 17:15, Kent Watsen  wrote:
> 
> All,
> 
> This starts a twelve-day working group last call for 
> draft-ietf-netmod-sub-intf-vlan-model-05.
> 
> The working group last call ends on July 21 (the day before the NETMOD 105 
> sessions).  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 useful and important, even from 
> authors.
> 
> Thank you,
> NETMOD Chairs
> ___
> 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

Re: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02

[Jeff Tantsura]

Lou,

I support the progress of the draft and it is ready for the publication.

Regards,
Jeff

> On May 12, 2019, at 14:19, Lou Berger  wrote:
> 
> 
> All,
> 
> This starts a two-week working group last call for
> draft-ietf-netmod-artwork-folding-02
> 
> The working group last call ends on May 27.
> 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 useful and important, even from authors.
> 
> Thank you,
> NetMod Chairs
> 
> 
> 
> ___
> 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

Re: [netmod] 6021 ipv4-prefix

[Jeff Tantsura]

+1

Cheers,
Jeff

> On Apr 18, 2019, at 6:12 AM, Lou Berger  wrote:
> 
> Having worked with UIs that have the behavior of accepting an 
> address/prefix-len and mapping it to a prefix, (i.e., network/prefix-len and 
> zeroing out the non-significant bits)  - some users really like it as they 
> don't have to do the transformation from address to network, notably for odd 
> length prefixes, while other users hate it as the system shows/does something 
> different than what they entered.
> 
> In the end the current definition is what it is.  If we want something 
> different we can define it. I personally think an address/prefix-len would be 
> useful, and would leave ip-prefix as is.  (again just an individual's 
> opinion.)
> 
> Lou
> 
>> On 4/18/2019 6:53 AM, Mikael Abrahamsson wrote:
>>> On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:
>>> 
 On Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote:
 
 2001:db8::/64 and 2001:db8::1/64 are NOT the same if you use them.
>>> Why are they not the same if you define a prefix?
>> Because they're not. One of them is a valid prefix, the other one isn't.
>> 
>>> +17.4 is not an integer, so this is an error (not because of the + but
>>> because of the . followed by additional digits). +17 is I think a valid
>>> integer value but the + will be dropped in the canonical representation.
>> Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of
>> the prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
>> rounded if an integer input is expected?
>> 
> 
> ___
> 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

Re: [netmod] 6991bis: address-with-prefix-length

[Jeff Tantsura]

What Kristian has proposed makes sense, in favor.

Cheers,
Jeff
On Apr 1, 2019, 1:09 PM -0700, Kristian Larsson , 
wrote:
> Hello Mahesh,
>
> On 2019-04-01 21:40, Mahesh Jethanandani wrote:
> >
> > > On Apr 1, 2019, at 10:29 AM, Martin Bjorklund  wrote:
> > >
> > > I know that this type is convenient, esp. if you use it for manual
> > > input, but I wonder if it really is good practice to squeeze two
> > > values into one.
> >
> > Agree. The combination makes sense for CLI, but for modeling the address 
> > and prefix should be separate.
>
> Okay, then why do we have an ip-prefix data type at all? With the same
> line of argument you apply, it should be split up.
>
> So you're the third person bringing up CLI. I don't get this at all. I
> don't see how CLI are different from everything else. This is about data
> modeling and data modeling is about expressing the world in a data
> modeling language. It's like painting a picture but instead of a brush
> you have a schema language like YANG. What do you see? Express it. It
> doesn't matter if the purpose is a CLI, a web page or just exposing it
> via NETCONF for another system to consume.
>
> I think address-and-prefix-length is natural. JUNOS uses this format. XR
> uses this format (for IPv6 at least). Nokia SROS uses this format.
>
> We have written a bunch of models where the lack of this IMHO makes them
> less elegant. I'd like for there to be an IETF standard data type to
> make those models more elegant.
>
> Kind regards,
> Kristian.
>
> ___
> 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

Re: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01

[Jeff Tantsura]

yes/support

Cheers,
Jeff
On Mar 26, 2019, 7:41 AM +0100, Rob Wilton (rwilton) , wrote:
> Support.
>
> From: netmod  On Behalf Of Kent Watsen
> Sent: 25 March 2019 21:32
> To: netmod@ietf.org
> Subject: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01
>
> This email begins a 2-week adoption poll for:
>
>
>     https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01
>
>
> Please voice your support or objections before April 8.
>
>
> Kent // as co-chair
>
>
>
> ___
> 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

Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call

[Jeff Tantsura]

+1 Christian 

Regards,
Jeff

> On Nov 16, 2018, at 10:23, Andy Bierman  wrote:
> 
> 
> 
>> On Thu, Nov 15, 2018 at 6:57 PM Christian Hopps  wrote:
>> So I would now have a new tags server to store tags associated with the 
>> modules for each of my actual servers in my network?
>> 
>> This seems a bit convoluted to me, and I haven’t heard anyone say what the 
>> problem is with the servers storing the tags associated with their modules, 
>> there are obvious problems (that you highlight) with the servers *not* 
>> storing the tags.
>> 
>> I think this is a rather simple thing we’ve proposed, and the server is the 
>> seemingly natural/simple place to do it.
>> 
>> I think it would be good to get some justification for *not* having the 
>> server store tags for it’s own modules.
>> 
> 
> +1 to all.
> Hopefully, the standard and vendor tags automatically installed by the server 
> are good enough,
> but if not, then the user can configure tags as well.
> 
> It would be good to get away from complex data silos in the client, or a 
> mega-tags-server
> that does the same thing. The tag mappings could get complex and keeping them 
> in the config
> on each server seems the easiest to manage,
> 
> 
>> Thanks,
>> Chris.
>> 
> 
> 
> Andy 
> 
>> 
>> 
>> > On Nov 15, 2018, at 19:54, Kent Watsen  wrote:
>> > 
>> > 
>> >> The servers implement the modules which can have predefined tags from
>> >> the module designer as well as the implementer (vendor) which literally
>> >> cannot come from anywhere *but* the server that implements the module.
>> > 
>> > Predefined tags from the implementer only needs to come from the 
>> > implementor.  Whether it is provided by the server itself or via
>> > some out-of-band mechanism (e.g., module catalog) seems to be the
>> > question.
>> > 
>> > Of course, one might say that user-tags must be provided by the 
>> > server itself, in order to provide an inter-client communication 
>> > mechanism of some sort, as otherwise a single client, even if 
>> > distributed, could keep the user-tags in its local database.
>> > 
>> > Though this begs the question, would it be better for the clients
>> > to use a centralized service of some sort (perhaps within the
>> > deployment's infrastructure, assuming the user-tags are private)
>> > to have user-tags once per module, rather than (redundantly?) on
>> > each server, thus ensuring consistency as well as avoiding 
>> > potential race conditions?  Or are these user-tags truly 
>> > server-specific (not just module-specific)?
>> > 
>> > Is it accurate to assume that two servers running identical 
>> > software would have identical user-tags?  Of course, the servers
>> > might be running different software (either different releases
>> > for the same hardware, or different hardware, potentially from
>> > different vendors).  Accommodating such would complicate the
>> > construction of a centralized module-tagging service, though
>> > it could still be done.
>> > 
>> > I suppose that the value of this document is not in any one of
>> > the use-cases, as they each seem minor and having alternate 
>> > (potentially better) workarounds, but in the multitude of them
>> > all, and how a single mechanism can help.
>> > 
>> > 
>> >> This is not what I thought would hold this work up.
>> > 
>> > My experience is that Last Calls tend to drive people to question
>> > basics again.  By example, it's rather common for a draft's title
>> > to change during a Last Call.  That said, this suitability question
>> > has been lingering since the day Joel kicked off the Adoption Call,
>> > that it is still with us seems to be the problem.
>> > 
>> > 
>> > Kent // contributor
>> > 
>> > 
>> > 
>> 
>> ___
>> 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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

[Jeff Tantsura]

Yes/support

Cheers,
Jeff
On Oct 18, 2018, 6:12 AM -0700, Lou Berger , wrote:
> All,
>
> This is start of a two week poll on making
> draft-kwatsen-netmod-artwork-folding-08 a working group
> document. Please send email to the list indicating "yes/support" or
> "no/do not support". If indicating no, please state your reservations
> with the document. If yes, please also feel free to provide comments
> you'd like to see addressed once the document is a WG document.
>
> The poll ends Oct 1.
>
> Thanks,
>
> Lou (and co-chairs)
>
> ___
> 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

Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

[Jeff Tantsura]

Support as co-author

Cheers,
Jeff
On Oct 1, 2018, 11:48 AM -0700, Kent Watsen , wrote:
> The IETF 102 in-room poll should really good support to adopt
> this draft, and no objections.
>
> This email starts an adoption poll for:
>
> https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00
>
> Please indicate your support or objection to the adoption poll.
> If objecting, please state your reasons on this thread.
>
> Kent (and Lou and Joel)
>
> ___
> 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

Re: [netmod] IPR poll on draft-clemm-netmod-nmda-diff-00

[Jeff Tantsura]

Kent,

I’m not aware of any IPR that has not been disclosed.
Thanks!

Cheers,
Jeff
On Oct 1, 2018, 11:48 AM -0700, Kent Watsen , wrote:
> This mail starts the IPR poll for draft-clemm-netmod-nmda-diff-00.
>
> Are you aware of any IPR that applies to this draft? If so, has this IPR been 
> disclosed in compliance with IETF IPR rules? Note, you do not have to be an 
> author or a contributor to make everyone aware of an IPR. See RFC 3669, 3979, 
> 4879 and 5378 for details.
>
> If you are listed as an author on the document, or as a contributor, please 
> respond to this e-mail, indicating whether or not you are aware of any 
> relevant IPRs. The response needs to be send to the NETMOD mailing list. The 
> document will not advance to the next stage until a response has been 
> received from all the authors and any contributors.
>
> Kent (and Lou and Joel)
>
>
> ___
> 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

Re: [netmod] "iana" in yang modules' name/namespace/prefix

[Jeff Tantsura]

Same here, let’s focus on immediate problems, there are plenty of those...

Regards,
Jeff

> On Jul 22, 2018, at 07:20, Acee Lindem (acee) 
>  wrote:
> 
> Hi Benoit, et al, 
> I couldn't agree more. The IETF has much more exigent issues with respect to 
> YANG models and the attendant protocol infrastructure than whether IANA might 
> go away in the future. 
> Thanks,
> Acee 
> 
> On 7/22/18, 9:54 AM, "netmod on behalf of Benoit Claise" 
>  
> wrote:
> 
>Martin,
> 
>I'm wonder whether this is really an important optimization, worth 
>changing now, in the hypothetical case that IANA is not called IANA any 
>longer in the future?
>Right now, "iana" n the YANG module name correctly states what this is 
> about
>https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml
> => "maintained by IANA"
>I agree with Jürgen that documenting this in 6087bis is the right way 
>forward.
> 
>Regards, Benoit.
>> Hello
>> 
>> As part of a recent IESG review (of draft-bfd-yang) a point came up on 
>> the use of "iana" in yang modules' name/namespace/prefix.
>> This is typically used in the case where the module refers to an IANA 
>> maintained registry. However, the point raised was that the name of 
>> the registry operator might not always be IANA, and that using that 
>> name might not put modules on the most stable deployment footing under 
>> all possible circumstances.
>> 
>> On top of that, as far as I can tell, the use of "iana" is an 
>> undocumented convention.
>> 
>> So, I wanted to collect views:
>> on whether a convention should be documented,
>> and, with regards to the point raised in IESG, on whether that keyword 
>> should be changed going forward. In that context, what about "reg" 
>> (for registry) or "regop" (for registry operator)? Other proposals are 
>> welcome.
>> 
>> Thanks
>> -m
>> 
>> ___
>> 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
> 
> 
> ___
> 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

Re: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

[Jeff Tantsura]

Yes/support

 

On 2/6/18 3:47 PM, joel jaeggli wrote:

Hi, 

This is the start of a *two* week poll on making 
draft-rtgyangdt-netmod-module-tags-02 a working group document.  

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

This document was most recently discussed at IETF 100.

Please send email to the list indicating "yes/support" or "no/do not support".  
If indicating no, please state your reservations with the document.  If yes, 
please also feel free to provide comments you'd like to see addressed once the 
document is a WG document. 

This poll ends on February 8. 

Thank you! 

Joel Jaeggli and IETF NETMOD Co-Chairs




___
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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Live meeting? and my opinion. [Re: moving forward with schema mount]

[Jeff Tantsura]

+1 Dean.
I’m having this discussion on daily bases...
I do care about sustainability and long term growth though 

Regards,
Jeff

> On Jan 26, 2018, at 07:30, Dean Bogdanovic  wrote:
> 
> I will ask a different question
> 
> How many people have implemented the draft? And are they talking from 
> experience implementing the model? I have implemented LNE and NI and to be 
> honest, when customers ask about IETF compatibility, i reference a draft and 
> tell them it will take long time until IETF finalizes the RFC. When it does, 
> we will update the implementation if needed. Within WG are hearing very 
> little about implementation and operational experience and feedback during 
> the process. 
> If any company had to wait two or more years to release software, they would 
> find themselves out of customers.
> 
> Dean
> 
>> On Jan 26, 2018, at 10:22 AM, Juergen Schoenwaelder 
>>  wrote:
>> 
>> OK, I accept that you do not care. Please also accept that others do
>> care. And these people believe YANG library bis is needed.
>> 
>> Since you do not want to read emails and involve yourself in
>> discussions of technical details, I assume this is where our
>> conversation stops.
>> 
>> I tought you wanted to start a constructive conversation towards a
>> resolution of the problem but it seems I misunderstood.
>> 
>> /js
>> 
>>> On Fri, Jan 26, 2018 at 10:06:06AM -0500, Christian Hopps wrote:
>>> 
>>> In the context of holding up this work, I don't care one iota about YANG
>>> library bis, and it works just fine with NMDA AFAICT.
>>> 
>>> We need models to get work done.
>>> 
>>> Thanks,
>>> Chris.
>>> 
>>> Juergen Schoenwaelder  writes:
>>> 
> On Fri, Jan 26, 2018 at 09:18:55AM -0500, Christian Hopps wrote:
> 
> Now it seems we are supposed to wait a bunch longer on yet other works
> in progress for as near as I can tell (could be wrong here as I just
> don't have time to read the very long email threads that netmod
> generates) capturing meta-data in a cleaner way than another. This does
> *not* seem like a reason to stall this work any further.
> 
 
 What is your interpretation of 'a bunch longer'? Or said differently,
 how much time do you think it will take to get the current schema
 mount approved (which has pending WG last call issues) and how much
 time would you find acceptable for a solution that also complies with
 NMDA and YANG library bis? I believe people are willing to give the
 later high priority.
 
 /js
>> 
>> -- 
>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103 
>> 
>> ___
>> 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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] schema mount and YANG library

[Jeff Tantsura]

+1, with Acee

Cheers,
Jeff

On 1/22/18, 08:18, "netmod on behalf of Acee Lindem (acee)" 
 wrote:

Hi Lada, 

My primary concern is that the YANG Schema Mount delay will not only hold 
the NI/LNE but all the models that are dependent on them (e.g., L2VPN and 
L3VPN). This is for a document that has already finished WG Last Call. 
Additionally, your estimate for the size of the change and time to reach 
standardization is based on there being immediate consensus on the changes. 
This is probably overly optimistic given there was discussion on the proposed 
YANG Library BIS changes. I’d vote to publish the existing draft. 

In any case, being able to see the proposed changes ASAP is critical. 

Thanks,
Acee

On 1/22/18, 8:45 AM, "netmod on behalf of Ladislav Lhotka" 
 wrote:

Juergen Schoenwaelder  writes:

> On Fri, Jan 19, 2018 at 06:05:15PM +, Robert Wilton wrote:
>> 
>> Hence, for me, I see the choice as:
>> 1) do we publish the existing model now (perhaps also mark the draft 
as
>> experimental) followed by an updated draft with the NMDA compatible 
module?
>> 2) do we publish both models in a single draft (e.g. with the 
existing model
>> in an appendix)?
>> 3) do we only publish a single version of the draft with an NMDA 
compliant
>> solution.
>>
>
> I think the situation is as follows (likely obvious but it may help to
> make sure we are all on the same page):
>
> - the NI and LNE models have a normative reference to
>   I-D.ietf-netmod-schema-mount (and this makes sense since there are
>   MUST sentences in the I-D)
>
> - I-D.ietf-netmod-schema-mount (last updated in October) has normative
>   references to RFC 7895 (old YANG library)
>
> - RFC 7895 does not work with NMDA, NMDA work on a YANG library update
>   replacing RFC 7895
>
> So the YANG library update is gating the schema mount update which is
> gating the publication of the NI and LNE models.
>
> A proper solution would be to prioritize work on the YANG library
> update and the schema mount update. I assume that the next revision of
> the YANG library update (say end of January) is ready for WG last call
> and perhaps the schema mount authors can take an effort to get that
> document there as well, say beginning of February.

I completely agree.

Lada

>
> /js
>
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
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



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Jeff Tantsura]

+1 to 2

Cheers,
Jeff

On 1/16/18, 07:41, "netmod on behalf of Martin Bjorklund" 
 wrote:

Vladimir Vassilev  wrote:
> On 01/16/2018 11:56 AM, Martin Bjorklund wrote:
> 
> > Vladimir Vassilev  wrote:

[...]

> >> There is also undocumented alignment space count function before
> >>  that pyang uses to align the  fields of child data leafs
> >> with common ancestor. If this is specified in the draft the tree
> >> output can be deterministic and for me this is an advantage. This is
> >> currently one of the few underspecified pieces of the tree format so I
> >> had to check pyang implementation in oder to generate same alignment
> >> space counts and binary identical tree output results.
> > I think that we at least should write that there may be more than one
> > space between  and :
> >
> >There may be any number of additional space characters between
> > and .
> For the sake of the argument (at least having this on the mailing list
> as reference):
> 
>should be aligned at a common offset for all sibling nodes
>   from the start of  by adding trailing spaces. The recommended
>   offset is 3 plus the length of the longest node name among all
> sibling nodes
>   including those siblings defined under choice and case nodes.
> 
> This is what pyang does now. It is not a perfect solution but it
> allows identical output down to the bit.

Does anyone else have an opinion on this?  I can see three
alternatives:

  1) allow any number of addtional spaces
  2) allow any number of addtional spaces + define a suggested
 alignment algorithm
  3) mandate the alignment algorithm


/martin

___
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

Re: [netmod] Augmentation to Groupings

[Jeff Tantsura]

+1
Very much needed capability 

Regards,
Jeff

> On Dec 19, 2017, at 08:45, Xufeng Liu  wrote:
> 
> During the discussions of TE tunnel and topology models, we have found that 
> it is desirable to have the capability of augmenting a grouping.
> 
> In our case, there are multiple technology specific models augmenting a base 
> generic model. In the base model, some groupings are used multiple times, and 
> each augmentation model needs to add more schema nodes to the grouping 
> structure. For now, we have to specify an “augment” statement for each 
> location where the grouping is used. Such an “augment” statement is repeated 
> many times. It would be convenient and cleaner if we could augment the 
> grouping.
> 
> We’d like to hear opinions on the feasibility of such a capability.
> 
> Thanks,
> 
> - Xufeng
> 
> 
> 
> ___
> 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

Re: [netmod] Joel Jaeggli as a third NETMOD co-chair

[Jeff Tantsura]

Welcome Joel!

 

Cheers,

Jeff

 

From: netmod  on behalf of Kent Watsen 

Date: Friday, December 15, 2017 at 13:03
To: Lou Berger 
Cc: "EXT - joe...@bogus.com" , NETMOD Working Group 

Subject: Re: [netmod] Joel Jaeggli as a third NETMOD co-chair

 

 

Indeed, congrats! 

 

K. 

Sent from my iPhone


On Dec 15, 2017, at 12:19 PM, Lou Berger  wrote:

Joel,

Welcome aboard!

Lou

On 12/15/2017 12:21 PM, Benoit Claise wrote:


Dear all,

 

A lot is happening these days in the world of data modeling-driven 

management at the IETF:

NMDA architecture, NETCONF, RESTCONF

NMDA-compliant YANG modules: some RFC bis modules but also new ones

Guidelines: RFC6087bis and the tree diagram

The interaction with NETCONF: The schema mount, IETF-YANG-LIBRARY, 

telemetry

The interaction with routing, where many YANG modules come from.

etc.

There are a lot of dependencies between all these tasks, which must take 

place in parallel, and, obviously, be completed ASAP.

 

Kent and Lou have a lot on their shoulders these days.

To help with the situation and proactively progress documents, I'm happy 

to announce that Joel Jaeggli accepted to serve as a third NETMOD 

co-chair. Thank you Joel.

 

Please welcome Joel.

 

Regards, Benoit

 

___

netmod mailing list

netmod@ietf.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=aQtrcY_GHgRkFfWKs98sSl_yYy7MAromRtRm63miwFQ&s=mxu0y9ch7J7FeNSpDgZkgFaNo_22Ucov9NXusI356DE&e=


___
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=aQtrcY_GHgRkFfWKs98sSl_yYy7MAromRtRm63miwFQ&s=mxu0y9ch7J7FeNSpDgZkgFaNo_22Ucov9NXusI356DE&e=

___ 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

Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07

[Jeff Tantsura]

Yes/support!
Very important work with many other drafts depending on.

Regards,
Jeff

> On Oct 20, 2017, at 14:37, Kent Watsen  wrote:
> 
> All,
> 
> This starts a two-week working group last call on
> draft-ietf-netmod-schema-mount-07.
> 
> The working group last call ends on November 3.
> Please send your comments to the netmod mailing list.
> 
> Positive comments, e.g., "I've reviewed this document 
> and believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Could the authors, explicitly CC-ed on this email, 
> please also confirm one more time that they are 
> unaware of any IPR related to this draft.
> 
> Thank you,
> Netmod Chairs
> 
> 
> ___
> 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

Re: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03

[Jeff Tantsura]

Yes/support 

Jeff
>> On 13/10/2017 15:37, Kent Watsen wrote:
>> All,
>> 
>> Now that we have resolved the module naming issue on the list (i.e.
>> that keeps the original rfc module names and updates the unwanted
>> legacy nodes to have status 'obsolete'), rather than wait for the
>> changes to be made in the individual document, we'd like to move
>> ahead with the adoption now, with the understanding that these
>> changes will be made in the -01 version of the adopted draft.
>> 
>> This is start of a two-week poll on making draft-acee-netmod-rfc8022bis-03
>> a working group document.  Please send email to the list indicating
>> "yes/support" or "no/do not support".  If indicating no, please state
>> your reservations with the document.  If yes, please also feel free to
>> provide comments you'd like to see addressed once the document is a WG
>> document.
>> 
>> The poll ends Oct 27.
>> 
>> Thanks,
>> Kent (and Lou)
>> 
>> ___
>> 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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams

[Jeff Tantsura]

yes/support (TM for Acee()

 
Cheers,
Jeff
 
On 4/7/17, 7:22 PM, "netmod on behalf of Kent Watsen"
 wrote:

>All,
>
>This is start of a two-week poll on making the following draft a
>NETMOD working group document:
>
>  draft-bjorklund-netmod-yang-tree-diagrams
>
>Please send email to the list indicating "yes/support" or "no/do not
>support".  If indicating no, please state your reservations with the
>document.  If yes, please also feel free to provide comments you'd like
>to see addressed once the document is a WG document.
>
>
>Thank you,
>NETMOD WG Chairs
>
>
>___
>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



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Jeff Tantsura]

Yes/support

 

 

Cheers,

Jeff

 

 

 

 

This is a notice to start a two-week NETMOD WG last call for the document:

 

   Network Access Control List (ACL) YANG Data Model

   https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09

 

Please indicate your support or concerns by Thursday, October 27, 2016.

 

We are particularly interested in statements of the form:

  * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.

  * I have reviewed draft-ietf-netmod-acl-model-09 and found the following 
issues: ...

 

As well as:

 * I have implemented the data model in draft-ietf-netmod-acl-model-09.

  * I am implementing the data model in draft-ietf-netmod-acl-model-09.

  * I am considering to implement the data model in 
draft-ietf-netmod-acl-model-09.

  * I am not considering to implement the data model in 
draft-ietf-netmod-acl-model-09.

 

Thank you,

NETMOD WG Chairs

 

 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question about acl-type in draft-ietf-netmod-acl-model-08

[Jeff Tantsura]

+1

It should represent business logic rather than a  subset of existing features.

Regards,
Jeff

> On Aug 23, 2016, at 2:41 PM, Sam Aldrin  wrote:
> 
> Model design shouldn't be limited by the device capabilities, rather it 
> should be agnostic.
> The existing IETF model is more of a YANG version of CLI, which is rather 
> limiting from operational perspective.
> 
> How do we (operators) like to see ACL model should be? take a look at the 
> model we published (work in progress) at 
> 
> 
> -sam
> 
>> On Mon, Aug 22, 2016 at 7:04 AM, Adrian Pan  wrote:
>> Hi Dean,
>> 
>>  
>> 
>> 3)   With the model definition, even the acl-type is configured as Ethernet, 
>> the operator still can configure the matches of ace under the acl as ipv4 or 
>> ipv6, right?
>> 
>>  
>> 
>> No, if ACL type is ethernet, then all ACEs are expected to be ethernet. 
>> 
>> [Adrian] I understand your point, but this is not reflected in the model, if 
>> according to the model, the operator still can configure the acl-type as 
>> Ethernet, while configure the ace of the acl as ipv4, and this should be 
>> valid configuration.
>> 
>> 
>> is this the model design intention?
>> 
>>  
>> 
>> If acl-type is of one family, then only ace with match condition from that 
>> family are expected to be in the acl. If you want to combine them, please 
>> use mixed type.
>> 
>> [Adrian] if it’s only expected to be the same as the acl-type, but without 
>> the restriction in the model, you can’t avoid the operator configuration to 
>> mix the acl-type and the ace matches. So my thinking is that, can we add the 
>> restriction in the model for this as below to better reflect the model 
>> design intention?
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> container matches {
>> 
>>   description
>> 
>> "Definitions for match criteria for this Access List
>> 
>> Entry.";
>> 
>>  
>> 
>>   container ace-ipv4 {
>> 
>> when "../../acl-type='ipv4-acl'";
>> 
>> description "IPv4 Access List Entry.";
>> 
>> uses packet-fields:acl-ip-header-fields;
>> 
>> uses packet-fields:acl-ipv4-header-fields;
>> 
>>   }
>> 
>>   container ace-ipv6 {
>> 
>> when "../../acl-type='ipv6-acl'";
>> 
>> description "IPv6 Access List Entry.";
>> 
>> uses packet-fields:acl-ip-header-fields;
>> 
>> uses packet-fields:acl-ipv6-header-fields;
>> 
>>   }
>> 
>>   container ace-eth {
>> 
>> when "../../acl-type='eth-acl'";
>> 
>> description
>> 
>>   "Ethernet Access List entry.";
>> 
>> uses packet-fields:acl-eth-header-fields;
>> 
>>   }
>> 
>> }
>> 
>>  
>> 
>>  
>> 
>> Thanks
>> 
>> Adrian
>> 
>>  
>> 
>> From: Dean Bogdanovic [mailto:ivand...@gmail.com] 
>> Sent: Monday, August 22, 2016 5:39 PM
>> To: Adrian Pan 
>> Cc: kkous...@cisco.com; lyihuan...@gmail.com; dbl...@cisco.com; netmod WG 
>> 
>> Subject: Re: Question about acl-type in draft-ietf-netmod-acl-model-08
>> 
>>  
>> 
>> (+netmod mailing list)
>> 
>> Adrian,
>> 
>>  
>> 
>> Please see inline
>> 
>> On Aug 22, 2016, at 2:27 AM, Adrian Pan  wrote:
>> 
>>  
>> 
>> Dear authors,
>> 
>>  
>> 
>> I have some questions about ietf acl model as below, your reply is 
>> appreciated.
>> 
>>  
>> 
>> 1)   In the model definition acl-type is one key of the acl, also in the 
>> description it says that the acl-type could be ethernet, IPv4, IPv6, mixed, 
>> in case the acl-type is mixed, what’s the identifier should be?
>> 
>> Should it be augmented by different vendor? Since I don’t  see the 
>> definition about it.
>> 
>>  
>> 
>> As mixed ACLs are not supported by all vendors, those are not part of the 
>> standard model. Iit is up to the vendor to augment the ace-type and select 
>> an identifier to their liking. 
>> 
>> 
>> 
>> 
>> 2)   In the “mix” case, the “matches” the ace list can be the combination of 
>> Ethernet,ipv4,ipv6 for different ace, right?
>> 
>>  
>> 
>> Or another combination, again depends on what that particular vendor 
>> supports.
>> 
>> 
>> 3)   With the model definition, even the acl-type is configured as Ethernet, 
>> the operator still can configure the matches of ace under the acl as ipv4 or 
>> ipv6, right?
>> 
>>  
>> 
>> No, if ACL type is ethernet, then all ACEs are expected to be ethernet. 
>> 
>> 
>> is this the model design intention?
>> 
>>  
>> 
>> If acl-type is of one family, then only ace with match condition from that 
>> family are expected to be in the acl. If you want to combine them, please 
>> use mixed type.
>> 
>>  
>> 
>> Dean
>> 
>> 
>> 
>> 
>> module: ietf-access-control-list
>>+--rw access-lists
>>   +--rw acl* [acl-type acl-name]
>>  +--rw acl-name   string
>>  +--rw acl-type   acl-type
>>  +--ro acl-oper-data
>>  +--rw access-list-entries
>> +--rw ace* [rule-name]
>>+--rw rule-namestring
>>+--rw matches
>>|  +--rw (ace-type)?
>>  
>> 
>>