On Fri, Jul 09, 2021 at 08:57:34AM +, tom petch wrote:
> From: netmod on behalf of Juergen Schoenwaelder
>
> Sent: 08 July 2021 11:13
>
> On Thu, Jul 08, 2021 at 09:30:27AM +, Rob Wilton (rwilton) wrote:
> > It is perhaps worth noting that the NETCO
the import
dependency.
NEW:
If they are excluded then the consumer of the instance data file has
to apply the YANG language rules to resolve the imports.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Ger
augment in a new choice. So I am not
convinced by this argument.
/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/>
__
representation? And does that
> saving justify to start engineering another schema specification format?
>
> I guess my choice would have been to just have
>
>+-- content-schema
> | +-- (content-schema-spec)?
>| +--: (yang-library)
>
a
> module, if required.
>
I think it is not "allowed" but "mandatory to implement". We should
allow implementations to support an ftps:// scheme as long as there
is a common baseline.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49
together. Well, still slightly better
than having implementations fail arbitrarity.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://
he way import-by-revision should have worked from the start.
>
> The draft contains some reasonable updates to YANG and YANG Guidelines
> wrt/ updating a module.. They would be appropriate for a new YANG language
> version.
>
+1
/js
--
Juergen Schoenwaelder Jacobs Un
On Mon, Jun 28, 2021 at 12:39:38PM -0400, Michael Richardson wrote:
>
> Juergen Schoenwaelder wrote:
> >> Juergen Schoenwaelder wrote:
> >> > Note that there is also a middle ground, namely an enumeration type
> >> > factored out into an IANA
On Mon, Jun 28, 2021 at 12:04:46PM -0400, Michael Richardson wrote:
>
> Juergen Schoenwaelder wrote:
> > Note that there is also a middle ground, namely an enumeration type
> > factored out into an IANA maintained module that is process wise easier
> > to ex
ANA maintained module that is process wise
easier to extend - should extensions be needed more regularly.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103
, only the module-name+revision-label can be the unique
> identifier for a revision.
>
> Jason
>
> _______
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder Jacobs University Br
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.i
st
> Ericsson Hungary Ltd.
>
> Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com
>
>
>
> _______
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Ph
discussion of this open issue it was pointed
> out that it would be desirable to specify both the bandwidth and the units
> (Kbps/Mbps/Gbps)
>
> Italo
>
> > -Original Message-
> > From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> > S
units (Kbps/Mbps/Gbps).
>
The description of bandwidth-ieee-float32 says:
The units are octets per second.
Note that draft-ietf-teas-yang-te-types has been published as RFC 8776
in June 2020, it should be safe to use these definitions.
/js
--
Juergen Schoenwaelder Jacobs
mes (i.e., you want zoned addresses you use "-zoned" types e.g.,
> >> "ipv6-address-zoned").
> >>
> >> Thanks,
> >> Chris.
> >>
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://
ormal case as defined in the NMDA-RFC“
> SHOULD conform to any constraints specified”.
>
>
>
> Regards Balazs
>
>
>
> From: Andy Bierman
> Sent: 2021. április 20., kedd 20:21
> To: Juergen Schoenwaelder ; Balázs
> Lengyel ; Sterne, Jason
ter-intuitive and IMHO contradict RFC 7950.
>
> Do you agree?
> If not, could you please describe what does a mandatory=true statement mean
> for a config=false leaf in your interpretation?
>
> -------
> IMHO we never st
On Wed, Apr 14, 2021 at 01:55:04PM +, Balázs Lengyel wrote:
> * On the other hand, changing a state leaf from mandatory false to true
> means always including the leaf in a response.
Where do you get this from?
/js
--
Juergen Schoenwaelder Jacobs University Bremen
> make people do work to analyze it ?
>
> Jason
>
> > -Original Message-
> > From: Juergen Schoenwaelder
> > Sent: Friday, April 9, 2021 9:53 AM
> > To: Sterne, Jason (Nokia - CA/Ottawa)
> > Cc: Rob Wilton (rwilton) ; netmod@ietf.org
> > Sub
lly be how most
> implementations would want to treat state. Would we really want to flag a
> module as non backwards compatible when a state leaf has an enum removed?
> Wouldn't that create a lot of unnecessary noise?
>
> > -Original Message-
> > From: Juergen Schoenw
lues do not change. Note that inserting a new enum
before an existing enum or reordering existing enums will result
in new values for the existing enums, unless they have explicit
values assigned to them.
What do you want this to change to?
/js
--
Juergen Schoenwaelder
xamples
> of data they might get, values outside range)
>
> ACTION: focus on reviewing section 3.1.2
>
> --
> Weekly webex call details:
> Meeting number (access code): 171 069 0374
> Meeting password: semver?
> Occurs every Tuesday effective
> >
> > > > Hi guys,
> > > >
> > > > The text in 7950 doesn't mention anything about semantics in the
> > > > description. That is part of what made me feel it isn't accurate or
> > complete.
> > > >
> > > > It als
ast for the scope of the module versioning doc) ?
Please no. RFC 7950 says data type and for me this includes everything
that defines a type, including the semantics carried in the type's
description statement.
We do not need to fix what is not broken. Why do we need a new
definition at all? If d
On Sat, Mar 20, 2021 at 11:49:09AM +, tom petch wrote:
> From: Juergen Schoenwaelder
> Sent: 19 March 2021 17:54
>
> Subject: Re: [netmod] Use of prefixes in YANG models
>
> On Fri, Mar 19, 2021 at 04:38:11PM +, tom petch wrote:
> >
> >
> > Apolo
On Fri, Mar 19, 2021 at 04:38:11PM +, tom petch wrote:
>
>
> Apologies for the useless quoting that my webmail imposes on me:-(
>
Your webmail does not allow to edit the quoted text?
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49
nizations.
/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/>
___
netmod mailing list
netmod
ethanand...@gmail.com
>
>
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587
/port ranges.
>
> -thanks,
> Aseem
>
> On 3/17/21, 5:29 AM, "netmod on behalf of Juergen Schoenwaelder"
>
> wrote:
>
> Hi,
>
> let me check whether I understand your request correctly: I heard you
> saying that you would like t
beu 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
--
Ju
, Feb 24, 2021 at 09:39:15PM +0100, Juergen Schoenwaelder wrote:
> Here is an attempt to come up with better wording. If people agree on
> a new wording, I volunteer to submit an errata.
>
> OLD
>
>o A "type" statement may be replaced with another "ty
"does the client believe the server has a
bug or not". But even then, I continue to believe that a leaf changing
the semantics of another leaf is bad design.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1
> configuration be provided?
>
> Could any of this option be used to resolve this issue?
>
> Italo
>
> From: Andy Bierman [mailto:a...@yumaworks.com]
> Sent: mercoledì 10 marzo 2021 15:16
> To: Italo Busi
> Cc: Juergen Schoenwaelder ;
> netmod@ietf.org
> Su
rk-around is possible, without breaking any
> client, to allow re-using an existing module which has already defined a
> default value.
>
> Italo
>
> From: Andy Bierman [mailto:a...@yumaworks.com]
> Sent: martedì 9 marzo 2021 21:12
> To: Juergen Schoenwaelder ; Italo Busi
&g
vel blocks and UMLs, and is very difficult to be
> written in YANG and harder to be implemented.
> We will avoid such pitfall.
>
> At the current stage YANG is used for abstraction and representation. YANG is
> both representative and implementable.
>
> -Qin (on behalf of autho
).
>
> In this case, I think that it would be better/cleaner if the origin is marked
> as system.
>
> Maybe a better YANG description for bar could be: "When present, the system
> overrides the default value of foo to 10."
>
> What is your and/or WG opinion?
>
020/yangsters-smansfield-mac-address-format-0420-v01.pdf
--
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/>
considered
worth to clarify. This is relevant for people writing YANG modules and
also for people working on encodings of YANG data where it matters
whether they can rely on underlying built-in types not changing.
Anyway, if this leads to N additional problems that can be considered
to be fixed, th
On Fri, Feb 26, 2021 at 12:21:26PM +, Rob Wilton (rwilton) wrote:
>
>
> > -Original Message-
> > From: netmod On Behalf Of Juergen Schoenwaelder
> > Sent: 24 February 2021 20:39
> > To: netmod@ietf.org
> > Subject: Re: [netmod] type equivalence
&g
d errata, is a pragmatic solution.
>
This document has a long way to go. I am not sure everybody agrees
with changing YANG 1.1 rules by an update (without changing YANG's
version number, i.e., it becomes upclear which rules apply to a given
YANG module).
/js
--
Juergen Schoenwaelder Jacobs Univer
Does the AD see an issue with the proposed text?
/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/>
_
ng the type of a leaf or leaf-list is NBC
This seems to be way more restrictive than the existing YANG 1.1 rules
we have today. Perhaps that is what the versioning people want, but
then we better keep the YANG 1.1 rules and the YANG + versioning rules
separate.
/js
--
Juergen Schoenwaelder
On Mon, Feb 22, 2021 at 03:20:02PM +0100, Carsten Bormann wrote:
> On 2021-02-22, at 15:17, Juergen Schoenwaelder
> wrote:
> >
> > I guess considering the built-in types as incompatible is the most
> > robust approach. If we agree that RFC 7950 tried to say this, we could
>
On Mon, Feb 22, 2021 at 02:55:57PM +0100, Carsten Bormann wrote:
> On 2021-02-22, at 14:53, Juergen Schoenwaelder
> wrote:
> >
> > Yes, "base type" is the wrong term, I think we talk about what RFC
> > 7950 calls "build-in types”.
>
> OK, so rephra
On Mon, Feb 22, 2021 at 11:47:05AM +0100, Carsten Bormann wrote:
>
>
> > On 2021-02-22, at 11:13, Martin Björklund wrote:
> >
> > Juergen Schoenwaelder wrote:
> >> Thanks Martin,
> >>
> >> so you are saying that
> >>
>
of "0..100" to one. And it seems the
answer is "no", at least not in a backwards compatible way if people
picked different base types.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen |
;; }
> type enumeration { enum 4; }
> }
>
>
> But I don't think this is reasonable, and not the intention. I think
> that changing the base built-in type always should be considered
> non-backwards compatible (which the quoted text above seems to imply).
>
>
> /mart
On Fri, Feb 19, 2021 at 10:32:34PM +0100, Carsten Bormann wrote:
>
>
> > On 2021-02-19, at 19:18, Juergen Schoenwaelder
> > wrote:
> >
> > I think the CBOR encoding picks different tags depending on the
> > signedness of the base type and this is why th
no clue what the gnmi people do. The
more diverse encodings we add, the more complex things get.
/js
On Fri, Feb 19, 2021 at 06:24:02PM +0100, Carsten Bormann wrote:
> On 2021-02-19, at 17:55, Juergen Schoenwaelder
> wrote:
> >
> > Hi,
> >
> > can I safel
anges? Note that the value
set is always the same, however the underlying base type changes. Did
we ever define type equivalence?
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 31
because it's NTP-specific. Perhaps iana-crypt-hash
> is fine, and instead ntp-yang-data-model should be republished, augmenting in
> the desired “status” while referencing 8573.
>
> K.
> ___
> netmod mailing list
> netmod@ietf.org
> h
le RFC 7317
Expert Review (Expert: Unassigned)
Perhaps we should focus more on finding a volunteer willing to take
the role of the Designated Expert...
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus R
red
to personally bear the burden of evaluating and deciding all requests,
but acts as a shepherd for the request, enlisting the help of others
as appropriate." (RFC 5226, BCP 26)
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Ca
in such a debate is often that modeling things as
a boolean is simplistic since there are often more than exactly two
states (in this case, enabled, disabled, failed, not-available, ...).
So you settle on blaming the model writer. ;-)
/js
--
Juergen Schoenwaelder Jacobs Universi
by config false leafs.
An example is the zero-based-counter32 typedef in RFC 6991. However,
this style may be debated since it (mis)uses a default statement to
define an initial value. I am not sure whether the pattern of using
default statements for specifying intial values is a good one.
/js
--
origin=default or
origin=system if the default derivation logic becomes more complex.
For me personally, if there is more complex logic involved in deriving
a value for a leaf (i.e., the existence of other leafs or values of
other leafs matter), then I would rather call it a system provided
value and not
it would help to ground the discussions if those who can
> remember previous efforts would share their experiences or at least some
> pointers.
>
> Best,
> Adrian
>
> -Original Message-
> From: netmod On Behalf Of Juergen Schoenwaelder
> Sent: 23 December 2020 1
On Wed, Dec 23, 2020 at 07:08:52PM +0100, Juergen Schoenwaelder wrote:
>
> ECA work has a long 20+ year tradition in the IETF and several
> specifications have been published over the years by various working
> groups. As far as I can tell, none of them got traction in terms of
ECA work has a long 20+ year tradition in the IETF and several
specifications have been published over the years by various working
groups. As far as I can tell, none of them got traction in terms of
signifiant deployment of interoperable implementations.
I would have hoped that the next iterat
ve a good
> weekend!
>
> Rgds,
> Jason
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587
Enclosed are the materials for the Virtual Interim on Monday. Have a good
> weekend!
>
> Rgds,
> Jason
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder
comes from the factory?" is that it is
empty. On first boot, on a system implementing RFC 8808, it would be
loaded with the content of the factory default datastore and on
systems not implementing RFC 8808 it would most likely remain empty.
/js
--
Juergen Schoenwaelder Jacobs Univers
client needs
the complete module list every time a connection is (re-)established.
This is why the recommendation is to use the YANG library wherever
possible, it scales better than the orignal exchange design
and it is more flexible.
/js
--
Juergen Schoenwaelder Jacobs University Bremen
standard version of ietf-yang-types in rfc 6991. So
> the import should be something like "revision 2013-07-15 or derived;".
>
> Rgds,
> Jason
>
>
> From: netmod On Behalf Of Andy Bierman
> Sent: Wednesday, September 2, 2020 10:52 AM
> To: Juergen Schoenwaelde
e "rev:nbc-changes" substatement
> that indicates where NBC changes have occurred in the revision history. As
> long as the allocated YANG Semver revision labels are consistent with the use
> of the rev:nbc-changes" substatement in the revision history then it would
> still b
miss my point: The specification of a leaf needs to be clear what
it is. If it is not clear, then the specification is buggy.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103
ge churn is reasonably under control. During active
development phases, modules may undergo many little (nbc) changes
but dealing with them should be left to version management
systems.
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus
On Wed, Aug 26, 2020 at 05:43:27PM +, Joe Clarke (jclarke) wrote:
>
>
> > On Aug 13, 2020, at 06:23, Juergen Schoenwaelder
> > wrote:
> >
> > On Thu, Aug 13, 2020 at 11:37:18AM +0200, Ladislav Lhotka wrote:
> >>
> >>
> >
If module authors are too lazy
to use existing YANG mechanisms properly, does it make sense to add
more mechanism to the YANG eco system? I doubt it.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
day's YANG versioning rules handle them well.
/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/>
___
ignificant.
Lets raise this to the next level. What about the following?
D1. description "A server.";
D2. description "A server."; // not very descriptive
E1. description "A server."; // not very descriptive
E2. // not very descriptive
description &q
48, Juergen Schoenwaelder wrote:
> >
> >
> > I personally meanwhile believe that sub-modules add complexity with
> > little extra value but this view surely is not shared by others.
> >
> >+1. IMO removing sub-modules from YANG 2.0 should be on the list
grouping instead of
> submodule.
>
> Tom Petch
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 358
raft-ietf-netmod-geo-location-05?
> > Type in my opinion is more reusable building block.
> >
> > -Qin
> > 发件人: Christian Hopps [mailto:cho...@chopps.org <mailto:cho...@chopps.org>]
> > 发送时间: 2020年7月31日 0:38
> > 收件人: Juergen Schoenwaelder >
YANG-Library.
Whether a change is BC or not always depends on which definitions have
changed, how they have changed, and how these definitions are used. So
the answer very likely must be option 1. Option 2 also seems to push
the problem elsewhere (packages, library) without providing the
details.
/
used.
I think this is something where the input from Chris Hopps and the
NETMOD chairs is important to determine the path forward. Since we
have an ietf-geo-location module, I would prefer to have common types
for location information defined there and not in yang-types.
/js
On Thu, Jul 30, 2
ea", deprecation requires some internal communication and
collaboration (but not deprecating also won't hurt much for these
fairly simple types).
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax
-05 only define
> grouping, there is typedef for longitude and latitude, altitude.
>
> -Qin
> -邮件原件-
> 发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> 发送时间: 2020年7月30日 21:32
> 收件人: Qin Wu
> 抄送: netmod@ietf.org
> 主题: Re: [netm
I am not a fan of loopback seeing it as the implementation choice
> of one manufacturer. On the other hand, the IETF has defined documentation
> addresses which many if not most writers of examples for YANG modules seem
> unaware of so if we add anything, I would add those.
>
>
On Wed, Jul 29, 2020 at 01:55:38PM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder writes:
>
> >> If we want to allow non-ASCII names, then it would IMO be safer to use a
> >> type that expects straight Unicode for lexical representation and leave
> >> it
eneficial for future document to import these types from
> rfc6991bis instead of from te topo model.
>
> -Qin
> -邮件原件-
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
> 发送时间: 2020年7月18日 3:16
> 收件人: netmod@ietf.org
> 主题: [netmod] rfc6991b
On Thu, Jul 30, 2020 at 02:58:22PM +0200, Benoit Claise wrote:
> On 20/07/2020 11:19, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder writes:
> >
> > >- Percentages are frequently used in YANG models but usages differ a
> > > lot in precision and range
On Mon, Jul 27, 2020 at 03:18:25PM +0200, Ladislav Lhotka wrote:
>
>
> On 27. 07. 20 12:44, Juergen Schoenwaelder wrote:
> > On Mon, Jul 27, 2020 at 10:51:31AM +0200, Ladislav Lhotka wrote:
> >> Juergen Schoenwaelder writes:
> >>
> >>&
On Mon, Jul 27, 2020 at 12:33:39PM +, Qin Wu wrote:
> -邮件原件-
> 发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> 发送时间: 2020年7月27日 18:42
> 收件人: Qin Wu
> 抄送: netmod@ietf.org
> 主题: Re: [netmod] The NETMOD WG has placed draft-tao-netmod-yang-nod
On Mon, Jul 27, 2020 at 10:51:31AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder writes:
>
> > So would the following do the right thing?
>
> The invert-match pattern also needs to be added in order to avoid reserved
> labels:
Why are they illegal? If we make the
nce tags. If anything, I would
be interested in a generic solution and not something taylored to one
specific use case (telemetry) and this is why I would prefer to have
the specific semantics in the tags and not in the set of leafs
carrying the tags.
/js
--
Juergen Schoenwaelder Jacobs Univ
gt; Benoit Claise:
> https://mailarchive.ietf.org/arch/msg/netmod/3C-K4JaAgLnpAoPqcQAn59DFHYw/
>
> _______
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49
n, Jul 26, 2020 at 03:11:15PM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder writes:
>
> > On Wed, Jul 22, 2020 at 01:46:38PM +0200, Ladislav Lhotka wrote:
> >>
> >>
> >> On 22. 07. 20 13:00, Juergen Schoenwaelder wrote:
> >> >
On Fri, Jul 24, 2020 at 12:14:17PM +0200, Erik Auerswald wrote:
> Hi,
>
> On Fri, Jul 24, 2020 at 10:36:17AM +0200, Juergen Schoenwaelder wrote:
> > On Wed, Jul 22, 2020 at 01:46:38PM +0200, Ladislav Lhotka wrote:
> > > On 22. 07. 20 13:00, Juergen Schoenwaelder wr
On Sat, Jul 18, 2020 at 09:00:42AM -0700, Andy Bierman wrote:
> On Sat, Jul 18, 2020 at 8:42 AM Vladimir Vassilev <
> vladi...@lightside-instruments.com> wrote:
>
> > On 17/07/2020 21.14, Juergen Schoenwaelder wrote:
> >
> > > - How do we deal with
On Fri, Jul 24, 2020 at 10:36:17AM +0200, Juergen Schoenwaelder wrote:
>
> What is the '(.*\.)?' part doing in your pattern?
>
OK, I figured it out, the NR-LDH label and be in anywhere in the
sequence of labels.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
P
On Wed, Jul 22, 2020 at 01:46:38PM +0200, Ladislav Lhotka wrote:
>
>
> On 22. 07. 20 13:00, Juergen Schoenwaelder wrote:
> > Tom,
> >
> > my understanding is that Lada is now proposing something slightly
> > different but I am not sure what exactly, hence I a
Tom,
my understanding is that Lada is now proposing something slightly
different but I am not sure what exactly, hence I asked again.
/js
On Wed, Jul 22, 2020 at 09:54:00AM +, tom petch wrote:
> From: netmod on behalf of Juergen Schoenwaelder
>
> Sent: 21 July 2020 20:44
>
&
On Mon, Jul 20, 2020 at 11:04:55AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder writes:
>
> > - Lada suggested to replace the inet:domain-name usage in
> > the union with a new host-name definition that follows
> > the NR-LDH definition in RFC 5890.
&
not most writers of examples for YANG modules seem
> unaware of so if we add anything, I would add those.
>
> Tom Petch
>
> From: netmod on behalf of Juergen Schoenwaelder
>
> Sent: 17 July 2020 20:25
>
> - There was a request to add types for loopback addr
there is a
common need for types for loopback addresses.
- Proposal: do not add such types at this point in time
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <ht
specific
--
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/>
___
netmod mailing list
netmod@ie
the pattern right.
--
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/>
___
netmod mailing list
' in your private list archive
(I can't find it in the IETF archive)
- I can't tell for sure that Lada's proposal is (i) correct and (ii)
not breaking anything
- Proposal: ?
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring
1 - 100 of 1039 matches
Mail list logo
