date:20200327

[netmod] Grammar for new extensions (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

2020-03-27 Thread Reshad Rahman (rrahman)

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/54

o Both YANG modules

All extensions should specify the grammar; i.e., in which statements
they can be present and which substatements they can have.

Ack.

1st part (statements) is clear.

For substatements, isn't this specified in
https://tools.ietf.org/html/rfc7950#section-7.19.1? Can you clarify if that's
not what you're looking for?

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick
off separate therads for each issue.

https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.

o 3.1.1

o In statements that have any data definition statements as
substatements, those data definition substatements MAY be
reordered, as long as they do not change the ordering or any
"rpc"
"input" substatements.

I think this needs to capture that no descendant statements to
"input" can be reordered. Same for "output" (note, "input" and
"output" in both "rpc" and "action").

o 3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

I don't think this is a good idea. Seems like a layer violation.
What if my project use another dialect of semver, that wouldn't be
possible with this rule. I think this needs to be removed.

o 3.3

Submodules MUST NOT use revision label schemes that could be
confused
with the including module's revision label scheme.

Hmm, how do I ensure that this MUST NOT is handled correctly? What
exactly does "could be confused with" mean?

o 3.3

In the filename of a YANG module, where it takes the form: module-
or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

Should this section update 5.2 of RFC 7950? I know that 5.2 just
says "SHOULD". But existing tools implement this SHOULD, and they
need to be updated to handle this new convention.

But I wonder if this a good idea. It means that a tool that looks
for a module with a certain revision date cannot simply check the
filenames, but need to parse all available modules (wijust to find
the

o 3.4

leaf imperial-temperature {
type int64;
units "degrees Fahrenheit";
status deprecated {
rev:status-description
"Imperial measurements are being phased out in favor
of their metric equivalents. Use metric-temperature
instead.";
}
description
"Temperature in degrees Fahrenheit.";
}

I don't think rev:status-description is necessary / worth it. This
can easily be written with the normal description statement instead:

leaf imperial-temperature {
type int64;
units "degrees Fahrenheit";
status deprecated;
description
"Imperial measurements are being phased out in favor
of their metric equivalents. Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
}

o 3.5

The example modules should be legal YANG modules. Use e.g.
"urn:example:module" as namespace.

Also, the modules are missing the last "}", which confuses the
"rfcstrip" tool.

o 4.1.1

Alternatively, the first example could have used the revision label
"1.0.0" instead, which selects the same set of revisions/versions.

import example-module {
rev:revision-or-derived 1.0.0;
}

Shouldn't this be s/1.0.0/2.0.0/g ?

o 5

I think the module name "ietf-yl-revisions" should be changed to
"ietf-yang-library-revisions". "yl" is not a well-known acronym.

o 5.2.2

[netmod] Typos and smaller issues (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

2020-03-27 Thread Reshad Rahman (rrahman)

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/53

We'll make changes/fixes as per the comments below. All good.

o 3.5

The example modules should be legal YANG modules. Use e.g.
"urn:example:module" as namespace.

Also, the modules are missing the last "}", which confuses the
"rfcstrip" tool.

o 4.1.1

Alternatively, the first example could have used the revision label
"1.0.0" instead, which selects the same set of revisions/versions.

import example-module {
rev:revision-or-derived 1.0.0;
}

Shouldn't this be s/1.0.0/2.0.0/g ?

o 5

I think the module name "ietf-yl-revisions" should be changed to
"ietf-yang-library-revisions". "yl" is not a well-known acronym.

o 7.1.1

There is a missing " in:

4. For status "obsolete", it is RECOMMENDED to keep the "status-
description" information, from when the node had status
"deprecated, which is still relevant.
HERE ---^

o 8

s/CODE ENDS>//

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick
off separate therads for each issue.

https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.

o 3.1.1

I think this needs to capture that no descendant statements to
"input" can be reordered. Same for "output" (note, "input" and
"output" in both "rpc" and "action").

o 3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

I don't think this is a good idea. Seems like a layer violation.
What if my project use another dialect of semver, that wouldn't be
possible with this rule. I think this needs to be removed.

o 3.3

Submodules MUST NOT use revision label schemes that could be
confused
with the including module's revision label scheme.

Hmm, how do I ensure that this MUST NOT is handled correctly? What
exactly does "could be confused with" mean?

o 3.3

In the filename of a YANG module, where it takes the form: module-
or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

Should this section update 5.2 of RFC 7950? I know that 5.2 just
says "SHOULD". But existing tools implement this SHOULD, and they
need to be updated to handle this new convention.

o 3.4

I don't think rev:status-description is necessary / worth it. This
can easily be written with the normal description statement instead:

Temperature in degrees Fahrenheit.";
}

[netmod] bool v/s empty for new leafs deprecated-nodes and obsolete-nodes (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

2020-03-27 Thread Reshad Rahman (rrahman)

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/52

o 5.2.2

Wouldn't it be better if the leaf "deprecated-nodes-implemented" and
"obsolete-nodes-absent" were of type "boolean" rather than type
"empty"?

The bool v/s empty philosophical battle. I'm ok with boolean, I don't know if
others have strong opinions on this.
If we go with boolean, if the leaf nodes are absent then the behaviour would be
unspecified.

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick
off separate therads for each issue.

https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.

o 3.1.1

I think this needs to capture that no descendant statements to
"input" can be reordered. Same for "output" (note, "input" and
"output" in both "rpc" and "action").

o 3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

I don't think this is a good idea. Seems like a layer violation.
What if my project use another dialect of semver, that wouldn't be
possible with this rule. I think this needs to be removed.

o 3.3

Submodules MUST NOT use revision label schemes that could be
confused
with the including module's revision label scheme.

Hmm, how do I ensure that this MUST NOT is handled correctly? What
exactly does "could be confused with" mean?

o 3.3

In the filename of a YANG module, where it takes the form: module-
or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

Should this section update 5.2 of RFC 7950? I know that 5.2 just
says "SHOULD". But existing tools implement this SHOULD, and they
need to be updated to handle this new convention.

o 3.4

I don't think rev:status-description is necessary / worth it. This
can easily be written with the normal description statement instead:

Temperature in degrees Fahrenheit.";
}

o 3.5

The example modules should be legal YANG modules. Use e.g.
"urn:example:module" as namespace.

Also, the modules are missing the last "}", which confuses the
"rfcstrip" tool.

o 4.1.1

Alternatively, the first example could have used the revision label
"1.0.0" instead, which selects the same set of revisions/versions.

import example-module {
rev:revision-or-derived 1.0.0;
}

Shouldn't this be s/1.0.0/2.0.0/g ?

o 5

I think the module name "ietf-yl-revisions" should be changed to
"ietf-yang-library-revisions". "yl" is not a well-known acronym.

[netmod] Revision label in filename (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

2020-03-27 Thread Reshad Rahman (rrahman)

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/50

o 3.3

In the filename of a YANG module, where it takes the form: module-
or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

Should this section update 5.2 of RFC 7950? I know that 5.2 just
says "SHOULD". But existing tools implement this SHOULD, and they
need to be updated to handle this new convention.

We agree that there is an impact on searching by date. We put this in to have
the ability to search by revision-label, otherwise we can search just by date
for a module which uses revision-label.
We had also discussed using different limiter for the label and have something
along the lines of: module-or-submodule-name['@'date]['#'revision-label].yang
It'd seem that updating 7950 would be a good idea whichever way we go.

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick
off separate therads for each issue.

https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.

o 3.1.1

I think this needs to capture that no descendant statements to
"input" can be reordered. Same for "output" (note, "input" and
"output" in both "rpc" and "action").

o 3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

I don't think this is a good idea. Seems like a layer violation.
What if my project use another dialect of semver, that wouldn't be
possible with this rule. I think this needs to be removed.

o 3.3

Submodules MUST NOT use revision label schemes that could be
confused
with the including module's revision label scheme.

Hmm, how do I ensure that this MUST NOT is handled correctly? What
exactly does "could be confused with" mean?

o 3.3

In the filename of a YANG module, where it takes the form: module-
or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

Should this section update 5.2 of RFC 7950? I know that 5.2 just
says "SHOULD". But existing tools implement this SHOULD, and they
need to be updated to handle this new convention.

o 3.4

I don't think rev:status-description is necessary / worth it. This
can easily be written with the normal description statement instead:

Temperature in degrees Fahrenheit.";
}

o 3.5

The example modules should be legal YANG modules. Use e.g.
"urn:example:module" as namespace.

[netmod] rev:status-description (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

2020-03-27 Thread Reshad Rahman (rrahman)

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/51

o 3.4

I don't think rev:status-description is necessary / worth it. This
can easily be written with the normal description statement instead:

Temperature in degrees Fahrenheit.";
}

While rev:status-description isn't strictly necessary, without it we'd have to
modify the node's description as you pointed out. That'd make tooling more
difficult: is the description change BC or NBC? Also, a user looking at a diff
would need to go through the description change. Use of rev:status-description
makes this easier to handle.

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick
off separate therads for each issue.

https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.

o 3.1.1

I think this needs to capture that no descendant statements to
"input" can be reordered. Same for "output" (note, "input" and
"output" in both "rpc" and "action").

o 3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

I don't think this is a good idea. Seems like a layer violation.
What if my project use another dialect of semver, that wouldn't be
possible with this rule. I think this needs to be removed.

o 3.3

Submodules MUST NOT use revision label schemes that could be
confused
with the including module's revision label scheme.

Hmm, how do I ensure that this MUST NOT is handled correctly? What
exactly does "could be confused with" mean?

o 3.3

In the filename of a YANG module, where it takes the form: module-
or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

Should this section update 5.2 of RFC 7950? I know that 5.2 just
says "SHOULD". But existing tools implement this SHOULD, and they
need to be updated to handle this new convention.

o 3.4

I don't think rev:status-description is necessary / worth it. This
can easily be written with the normal description statement instead:

leaf imperial-temperature {
type int64;
units "degrees Fahrenheit";
status deprecated;
description
"Imperial measurements are being

[netmod] Interpreting revision labels as YANG semantic version numbers (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

2020-03-27 Thread Reshad Rahman (rrahman)

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/48

o 3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

I don't think this is a good idea. Seems like a layer violation.
What if my project use another dialect of semver, that wouldn't be
possible with this rule. I think this needs to be removed.

Without this, applications cannot know what versioning scheme is being used, or
they have to guess, or the module would need another statement to declare what
versioning scheme is being used. Maybe we should go with the latter.

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick
off separate therads for each issue.

https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.

o 3.1.1

I think this needs to capture that no descendant statements to
"input" can be reordered. Same for "output" (note, "input" and
"output" in both "rpc" and "action").

o 3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

I don't think this is a good idea. Seems like a layer violation.
What if my project use another dialect of semver, that wouldn't be
possible with this rule. I think this needs to be removed.

o 3.3

Submodules MUST NOT use revision label schemes that could be
confused
with the including module's revision label scheme.

Hmm, how do I ensure that this MUST NOT is handled correctly? What
exactly does "could be confused with" mean?

o 3.3

In the filename of a YANG module, where it takes the form: module-
or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

Should this section update 5.2 of RFC 7950? I know that 5.2 just
says "SHOULD". But existing tools implement this SHOULD, and they
need to be updated to handle this new convention.

o 3.4

I don't think rev:status-description is necessary / worth it. This
can easily be written with the normal description statement instead:

Temperature in degrees Fahrenheit.";
}

o 3.5

The example modules should be legal YANG modules. Use e.g.
"urn:example:module" as namespace.

Also, the modules are missing the last "}", which confuses the
"rfcstrip" tool.

o 4.1.1

Alternatively, the first example could have used the revision label
"1.0.0" instead, which selects the same set of revisions/versions.

import example-module {
rev:revision-or-derived 1.0.0;

[netmod] No descendent statements to input/output can be reordered (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

2020-03-27 Thread Reshad Rahman (rrahman)

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/47

o 3.1.1

I think this needs to capture that no descendant statements to
"input" can be reordered. Same for "output" (note, "input" and
"output" in both "rpc" and "action").

Sounds good. JTBC, by descendent you're referring to data nodes (children,
grandchildren etc) and not to statements like type and description?

Also, could you refresh our memory why the decision was made to preserve order
of input/output data nodes?

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick
off separate therads for each issue.

https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.

o 3.1.1

I think this needs to capture that no descendant statements to
"input" can be reordered. Same for "output" (note, "input" and
"output" in both "rpc" and "action").

o 3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

I don't think this is a good idea. Seems like a layer violation.
What if my project use another dialect of semver, that wouldn't be
possible with this rule. I think this needs to be removed.

o 3.3

Submodules MUST NOT use revision label schemes that could be
confused
with the including module's revision label scheme.

Hmm, how do I ensure that this MUST NOT is handled correctly? What
exactly does "could be confused with" mean?

o 3.3

In the filename of a YANG module, where it takes the form: module-
or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

Should this section update 5.2 of RFC 7950? I know that 5.2 just
says "SHOULD". But existing tools implement this SHOULD, and they
need to be updated to handle this new convention.

o 3.4

I don't think rev:status-description is necessary / worth it. This
can easily be written with the normal description statement instead:

Temperature in degrees Fahrenheit.";
}

o 3.5

The example modules should be legal YANG modules. Use e.g.
"urn:example:module" as namespace.

Also, the modules are missing the last "}", which confuses the
"rfcstrip" tool.

o 4.1.1

Alternatively, the first example could have used the revision label
"1.0.0" instead, which selects the same set of revisions/versions.

[netmod] Revision labels for submodules (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

2020-03-27 Thread Reshad Rahman (rrahman)

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/49

o 3.3

Submodules MUST NOT use revision label schemes that could be
confused
with the including module's revision label scheme.

Hmm, how do I ensure that this MUST NOT is handled correctly? What
exactly does "could be confused with" mean?

Good point. What was meant by that the label space for modules and sub-modules
are orthogonal. e.g. the sub-module and module both have the same label, it
shouldn't be inferred that the 2 are related.
We'll change/clarify the text.

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick
off separate therads for each issue.

https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.

o 3.1.1

I think this needs to capture that no descendant statements to
"input" can be reordered. Same for "output" (note, "input" and
"output" in both "rpc" and "action").

o 3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

I don't think this is a good idea. Seems like a layer violation.
What if my project use another dialect of semver, that wouldn't be
possible with this rule. I think this needs to be removed.

o 3.3

Submodules MUST NOT use revision label schemes that could be
confused
with the including module's revision label scheme.

Hmm, how do I ensure that this MUST NOT is handled correctly? What
exactly does "could be confused with" mean?

o 3.3

In the filename of a YANG module, where it takes the form: module-
or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

Should this section update 5.2 of RFC 7950? I know that 5.2 just
says "SHOULD". But existing tools implement this SHOULD, and they
need to be updated to handle this new convention.

o 3.4

I don't think rev:status-description is necessary / worth it. This
can easily be written with the normal description statement instead:

Temperature in degrees Fahrenheit.";
}

o 3.5

The example modules should be legal YANG modules. Use e.g.
"urn:example:module" as namespace.

Also, the modules are missing the last "}", which confuses the
"rfcstrip" tool.

o 4.1.1

Alternatively, the first example could have used the revision label
"1.0.0" instead, which selects the same set of revisions/versions.

import example-module {
rev:revision-or-derived 1.0.0;
}

Shouldn't this be s/1.0.0/2.0.0/g ?

o 5

I think the module

[netmod] All IETF YANG modules MUST include revision-label statements (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

2020-03-27 Thread Reshad Rahman (rrahman)

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/45

o 7.1

The text says:

All IETF YANG modules MUST include revision-label statements for all
newly published YANG modules, and all newly published revisions of
existing YANG modules. The revision-label MUST take the form of a
YANG semantic version number [I-D.verdt-netmod-yang-semver].

I strongly disagree with this new rule. IETF modules use a linear
history, so there are no reasons to use "modified semver".

It is ok to use rev:nbc-changes if needed, though.

We believe some IETF models may not follow linear history, this was brought up
(I think) for IDR. Modified semver allows for non-linear history and also
doesn't preclude linear history. So even if we end up having no IETF modules
using branching, modified semver still works.

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick
off separate therads for each issue.

https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.

o 3.1.1

I think this needs to capture that no descendant statements to
"input" can be reordered. Same for "output" (note, "input" and
"output" in both "rpc" and "action").

o 3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

I don't think this is a good idea. Seems like a layer violation.
What if my project use another dialect of semver, that wouldn't be
possible with this rule. I think this needs to be removed.

o 3.3

Submodules MUST NOT use revision label schemes that could be
confused
with the including module's revision label scheme.

Hmm, how do I ensure that this MUST NOT is handled correctly? What
exactly does "could be confused with" mean?

o 3.3

In the filename of a YANG module, where it takes the form: module-
or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

Should this section update 5.2 of RFC 7950? I know that 5.2 just
says "SHOULD". But existing tools implement this SHOULD, and they
need to be updated to handle this new convention.

o 3.4

I don't think rev:status-description is necessary / worth it. This
can easily be written with the normal description statement instead:

Temperature in degrees Fahrenheit.";
}

o 3.5

The example modules should be legal YANG modules. Use e.g.
"urn:example:module" as namespace.

Also, the modules are missing the last "}", which confuses the
"rfcstrip" tool.

o 4.1.1

Alternatively, the first example could have used

Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04

2020-03-27 Thread Kent Watsen

Chris,

>> Security Considerations does not use template (which other grouping modules 
>> such as Kent's do)
> 
> I've pinged Kent for a pointer.

The template Tom is referring to is from 
https://tools.ietf.org/html/rfc8407#section-3.7.1.

That said, I have always felt that this template is a starting point that needs 
to be customized per YANG module (ideally, a separate template instance for 
each module in the draft).  For instance, if a module defines no "notification” 
or “rpc" statements, it is better for it to just say that instead of strictly 
following the template and producing an empty list.

For instance:


https://tools.ietf.org/html/rfc8572#section-9.15. (only defines an 
rc:yang-data structure)
https://tools.ietf.org/html/rfc8572#section-9.16 (only defines a couple 
“rpc” statements)



https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-04.html#section-6
 (only defines “grouping”)

https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-04.html#section-5
 (only defines “grouping”)


Kent // contributor


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

Re: [netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

2020-03-27 Thread Kent Watsen

Hi Balazs,

> On Mar 27, 2020, at 1:36 PM, Balázs Lengyel 
>  wrote:
> 
> Hello,
> https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12 
>  contains a 
> section with  .

Looking at -12, I see "” (not ), is this just a typo in 
your message?


> However rfcstrip cannot extract this part. Is that a problem?

It seems that the  line is messed up:

OLD:
   

NEW:
file "rfcfold"

Fixes it.


I’ll let the RFC Editor know - thanks!

Kent // contributor 


> Regards Balazs
>  
> -- 
> Balazs LengyelSenior Specialist   
> 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 
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04

2020-03-27 Thread Christian Hopps



> On Mar 27, 2020, at 1:09 PM, tom petch  wrote:
> 
> Kent
> 
> Not Ready
> 
> I thought that so obvious that it was not worth saying:-)
> 
> e.g.
> IANA considerations does not register the namespace so there is no module

Will add.

> Security Considerations does not use template (which other grouping modules 
> such as Kent's do)

I've pinged Kent for a pointer.

> No YANG version

This means it defaults to 1.0 I thought.

> Wrong prefix for ietf-yang-types

Will change the groupings use from "types" to "yang".

> No reference clause for yang types

Do you mean inside the import ietf-yang-types statement?

> A wholesale lack of YANG reference clauses; perhaps half a dozen needed

I can see 2 places I might could put these, in the "astronomical-body" leaf 
that references the IAU and in the "geodetic-system" for the default value. We 
are creating an IANA registry for the values in geodetic-system though so 
perhaps you are asking for an IANA reference instead? I don't see 4 more 
obvious places for external references, could you help point them out?

> No Normative reference for yang-types

We add normative document references for imported modules that are not 
mentioned anywhere else in the actual document? I have no problem doing so, but 
I haven't done that before.

> Insufficient information for IANA - I infer they are being asked to create a 
> registry but details seem lacking compared to the requirements in RFC8126

Thanks for pointing this out, I'll add this instead of waiting for IANA to 
complain. :)

Thanks,
Chris.

> 
> At which point I stop and await a fresh revision before having another go.
> 
> Tom Petch
> 
> 
> From: netmod  on behalf of Kent Watsen 
> 
> Sent: 26 March 2020 18:46
> 
> Dear All,
> 
> This WGLC has received zero responses, which is insufficient to progress the 
> document at this time.  The WGLC is therefore being extended  for another 
> week, now ending April 1st (the day before our Virtual Meeting on April 2nd).
> 
> Again, positive comments, e.g., "I've reviewed this document and believe it 
> is ready for publication", are welcomed.  This is useful and important, even 
> from authors.  Objections, concerns, and suggestions are also welcomed at 
> this time.
> 
> FWIW, the YANG Doctor review was completed on 3/23 (thanks Mahesh) with the 
> “Ready with Nits” status: 
> https://datatracker.ietf.org/doc/review-ietf-netmod-geo-location-04-yangdoctors-lc-jethanandani-2020-03-23.
> 
> Kent // as shepherd and co-chair
> 
> 
> 
> On Mar 9, 2020, at 6:30 PM, Kent Watsen 
> mailto:kent+i...@watsen.net>> wrote:
> 
> This message begins an almost two-week WGLC for 
> draft-ietf-netmod-geo-location-04 ending on March 22nd (the day before the 
> NETMOD sessions).  Here is a direct link to the HTML version of the draft:
> 
> https://tools.ietf.org/html/draft-ietf-netmod-geo-location-04
> 
> 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. Objections, concerns, and suggestions are also welcomed at this time.
> 
> 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

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

[netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

2020-03-27 Thread Balázs Lengyel

Hello,

https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12 contains a
section with  .

However rfcstrip cannot extract this part. Is that a problem?

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

 



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

Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04

2020-03-27 Thread tom petch

Kent

Not Ready

I thought that so obvious that it was not worth saying:-)

e.g.
IANA considerations does not register the namespace so there is no module
Security Considerations does not use template (which other grouping modules 
such as Kent's do)
No YANG version
Wrong prefix for ietf-yang-types
No reference clause for yang types
A wholesale lack of YANG reference clauses; perhaps half a dozen needed
No Normative reference for yang-types
Insufficient information for IANA - I infer they are being asked to create a 
registry but details seem lacking compared to the requirements in RFC8126

At which point I stop and await a fresh revision before having another go.

Tom Petch


From: netmod  on behalf of Kent Watsen 

Sent: 26 March 2020 18:46

Dear All,

This WGLC has received zero responses, which is insufficient to progress the 
document at this time.  The WGLC is therefore being extended  for another week, 
now ending April 1st (the day before our Virtual Meeting on April 2nd).

Again, positive comments, e.g., "I've reviewed this document and believe it is 
ready for publication", are welcomed.  This is useful and important, even from 
authors.  Objections, concerns, and suggestions are also welcomed at this time.

FWIW, the YANG Doctor review was completed on 3/23 (thanks Mahesh) with the 
“Ready with Nits” status: 
https://datatracker.ietf.org/doc/review-ietf-netmod-geo-location-04-yangdoctors-lc-jethanandani-2020-03-23.

Kent // as shepherd and co-chair



On Mar 9, 2020, at 6:30 PM, Kent Watsen 
mailto:kent+i...@watsen.net>> wrote:

This message begins an almost two-week WGLC for 
draft-ietf-netmod-geo-location-04 ending on March 22nd (the day before the 
NETMOD sessions).  Here is a direct link to the HTML version of the draft:

https://tools.ietf.org/html/draft-ietf-netmod-geo-location-04

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. Objections, concerns, and suggestions are also welcomed at this time.

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] [Technical Errata Reported] RFC7950 (6031)

2020-03-27 Thread Juergen Schoenwaelder

On Fri, Mar 27, 2020 at 04:35:44PM +0100, Martin Björklund wrote:
> [re-sent w/ correct address]
> 
> Juergen Schoenwaelder  wrote:
> > Hi,
> > 
> > two comments:
> > 
> > - It is unclear to me whether this really qualifies as an errata.
> > 
> > - If we add this, then there should probably text about which
> >   combinations are allowed. For example, for pattern and ranges, there
> >   is explicit text that says further restrictions of the value space
> >   are possible, bot not expansions. If we follow that logic, then
> > 
> >   typedef a {
> > type leaf-ref {
> >   path "/some/thing";
> >   require-instance true;
> > }
> >   }
> > 
> >   typedef b {
> > type a {
> >   require-instance false;
> > }
> >   }
> > 
> >   might be illegal since b has a larger value space than a.
> 
> The value space of b is the same as for a. "require-instance" doesn't
> change the value space; it changes semantic validation of the given
> values ((see my mail from 17 Mar, "Require-instance problem").
> 
> /martin

OK. If we consider require-instance a constraint and not a
restriction, then the motivation for this errata is at least
confusing:

  Since no one argued against this understanding, this errata changes
  the text to the same form as in other restrictions applicable to
  derived types.

Simply put: Do you think it is OK to overwrite a require-instance true
with a require-instance false in a derived type?

/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

Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

2020-03-27 Thread Martin Björklund

[re-sent w/ correct address]

Juergen Schoenwaelder  wrote:
> Hi,
> 
> two comments:
> 
> - It is unclear to me whether this really qualifies as an errata.
> 
> - If we add this, then there should probably text about which
>   combinations are allowed. For example, for pattern and ranges, there
>   is explicit text that says further restrictions of the value space
>   are possible, bot not expansions. If we follow that logic, then
> 
>   typedef a {
> type leaf-ref {
>   path "/some/thing";
>   require-instance true;
> }
>   }
> 
>   typedef b {
> type a {
>   require-instance false;
> }
>   }
> 
>   might be illegal since b has a larger value space than a.

The value space of b is the same as for a. "require-instance" doesn't
change the value space; it changes semantic validation of the given
values ((see my mail from 17 Mar, "Require-instance problem").


/martin


> 
> /js
> 
> On Fri, Mar 27, 2020 at 03:18:12AM -0700, RFC Errata System wrote:
> > The following errata report has been submitted for RFC7950,
> > "The YANG 1.1 Data Modeling Language".
> > 
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6031
> > 
> > --
> > Type: Technical
> > Reported by: Radek Krejci 
> > 
> > Section: 9.9.3
> > 
> > Original Text
> > -
> > The "require-instance" statement, which is a substatement to the 
> > "type" statement, MAY be present if the type is "instance-identifier"
> > or "leafref".  It takes as an argument the string "true" or "false".
> > If this statement is not present, it defaults to "true".
> > 
> > Corrected Text
> > --
> > The "require-instance" statement, which is a substatement to the
> > "type" statement, MAY be present if the type is "instance-identifier",
> > "leafref" or a type derived from them. It takes as an argument the
> > string "true" or "false". If this statement is not present, it defaults
> > to "true".
> > 
> > Notes
> > -
> > As discussed in 
> > https://mailarchive.ietf.org/arch/browse/netconf/?gbt=1=p_zRKwQ6TBxTuCDPc5wJbdZgWTc,
> >  authors expect that the require-instance statement is available not only 
> > for leafref and instance-identifier types, but also for all the types 
> > derived from them using typedef statement. Since no one argued against this 
> > understanding, this errata changes the text to the same form as in other 
> > restrictions applicable to derived types.
> > 
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party  
> > can log in to change the status and edit the report, if necessary. 
> > 
> > --
> > RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> > --
> > Title   : The YANG 1.1 Data Modeling Language
> > Publication Date: August 2016
> > Author(s)   : M. Bjorklund, Ed.
> > Category: PROPOSED STANDARD
> > Source  : Network Modeling
> > Area: Operations and Management
> > Stream  : IETF
> > Verifying Party : IESG
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> 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

Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

2020-03-27 Thread Juergen Schoenwaelder

Hi,

two comments:

- It is unclear to me whether this really qualifies as an errata.

- If we add this, then there should probably text about which
  combinations are allowed. For example, for pattern and ranges, there
  is explicit text that says further restrictions of the value space
  are possible, bot not expansions. If we follow that logic, then

  typedef a {
type leaf-ref {
  path "/some/thing";
  require-instance true;
}
  }

  typedef b {
type a {
  require-instance false;
}
  }

  might be illegal since b has a larger value space than a.

/js

On Fri, Mar 27, 2020 at 03:18:12AM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6031
> 
> --
> Type: Technical
> Reported by: Radek Krejci 
> 
> Section: 9.9.3
> 
> Original Text
> -
> The "require-instance" statement, which is a substatement to the 
> "type" statement, MAY be present if the type is "instance-identifier"
> or "leafref".  It takes as an argument the string "true" or "false".
> If this statement is not present, it defaults to "true".
> 
> Corrected Text
> --
> The "require-instance" statement, which is a substatement to the
> "type" statement, MAY be present if the type is "instance-identifier",
> "leafref" or a type derived from them. It takes as an argument the
> string "true" or "false". If this statement is not present, it defaults
> to "true".
> 
> Notes
> -
> As discussed in 
> https://mailarchive.ietf.org/arch/browse/netconf/?gbt=1=p_zRKwQ6TBxTuCDPc5wJbdZgWTc,
>  authors expect that the require-instance statement is available not only for 
> leafref and instance-identifier types, but also for all the types derived 
> from them using typedef statement. Since no one argued against this 
> understanding, this errata changes the text to the same form as in other 
> restrictions applicable to derived types.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> --
> Title   : The YANG 1.1 Data Modeling Language
> Publication Date: August 2016
> Author(s)   : M. Bjorklund, Ed.
> Category: PROPOSED STANDARD
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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

Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

2020-03-27 Thread Balázs Lengyel

+1
Balazs

-Original Message-
From: netmod  On Behalf Of RFC Errata System
Sent: 2020. március 27., péntek 11:18
To: m...@tail-f.com; ibagd...@gmail.com; war...@kumari.net; joe...@bogus.com;
kent+i...@watsen.net; lber...@labn.net
Cc: netmod@ietf.org; rfc-edi...@rfc-editor.org
Subject: [netmod] [Technical Errata Reported] RFC7950 (6031)

The following errata report has been submitted for RFC7950, "The YANG 1.1
Data Modeling Language".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6031

--
Type: Technical
Reported by: Radek Krejci 

Section: 9.9.3

Original Text
-
The "require-instance" statement, which is a substatement to the "type"
statement, MAY be present if the type is "instance-identifier"
or "leafref".  It takes as an argument the string "true" or "false".
If this statement is not present, it defaults to "true".

Corrected Text
--
The "require-instance" statement, which is a substatement to the "type"
statement, MAY be present if the type is "instance-identifier", "leafref" or
a type derived from them. It takes as an argument the string "true" or
"false". If this statement is not present, it defaults to "true".

Notes
-
As discussed in
https://mailarchive.ietf.org/arch/browse/netconf/?gbt=1=p_zRKwQ6TBxTuC
DPc5wJbdZgWTc, authors expect that the require-instance statement is
available not only for leafref and instance-identifier types, but also for
all the types derived from them using typedef statement. Since no one argued
against this understanding, this errata changes the text to the same form as
in other restrictions applicable to derived types.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please use
"Reply All" to discuss whether it should be verified or rejected. When a
decision is reached, the verifying party can log in to change the status and
edit the report, if necessary. 

--
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--
Title   : The YANG 1.1 Data Modeling Language
Publication Date: August 2016
Author(s)   : M. Bjorklund, Ed.
Category: PROPOSED STANDARD
Source  : Network Modeling
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

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

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-yang-instance-file-format-06 to -07

2020-03-27 Thread Kent Watsen

All,

The current -10 draft appears to have addressed all issues raised during the 
last call.  Thank you to everyone that participated.

I will start the shepherd review now.  Hopefully it will go smoothly, as a 
number of issues that I raised during the WGLC were related to things that are 
typically discovered during the shepherd review.

Kent // co-chair and shepherd



> On Mar 19, 2020, at 8:08 AM, Balázs Lengyel  
> wrote:
> 
> 
> 
> -Original Message-
> From: Kent Watsen  
> Sent: 2020. március 18., szerda 21:07
> To: Balázs Lengyel 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] WG Last Call: 
> draft-ietf-netmod-yang-instance-file-format-06 to -07
> 
> One more thing, for non-mandatory nodes that don’t have a default value 
> specified, please ensure the “description” statement states what it means for 
> the node to be set or not set (whichever is easier)?   For instance:
> 
> OLD:
> 
>   leaf name {
> type string;
> description
>   "Name of the YANG instance data set.";
>   }
> 
> NEW (assuming this makes sense):
> 
>   leaf name {
> type string;
> description
>   “An arbitrary name for the YANG instance data set.  This
>value is primarily used for descriptive purposes.  However,
>when the instance data set is saved to a file, then the
>filename MUST encode the name’s value, per Section 3 
>of RFC .";
>   }
> BALAZS: OK
> BTW, should the requirement of it needing to be encoded into the filename 
> place constraints on the “string” type?  Should a “pattern”
> statement be added?
> BALAZS: IMHO defining a pattern for a filename string (that may be dependent 
> on the used filesystem) is out of scope for this draft.
> 
> Extended description of content-schema.
> IMHO contact, description, revision, timestamp does not need to explain what 
> does it mean if they are not present. It only means: no information available.
> Kent
> 

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

Re: [netmod] Where can I use ?

2020-03-27 Thread Kent Watsen


Hi Balazs,

> OK, as you are strongly opposed to it, I will remove   ENDS> in the next version.

Is there a need for a “next" version?

Looking at -10 (current), I only see the markers around the YANG module, which 
seems good, right?


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

[netmod] Agenda Items - Re: Network Modeling (netmod) WG Virtual Meeting: 2020-04-02

2020-03-27 Thread Joel Jaeggli

Netmod folks, now that this is scheduled if you have an item you'd like
on the agenda for this meeting which you had not previously gotten in to
us please send it along to netmod chairs netmod-cha...@ietf.org.

Agenda items proposed so far:

Netmod Ver DT presentation

draft-tao-netmod-yang-node-tags

YANG in 3GPP presentation

draft-ietf-netmod-yang-instance-file-format


If I've missed something please let me know.

Thanks

Chairs

On 3/26/20 15:11, IESG Secretary wrote:
> The Network Modeling (netmod) Working Group will hold
> a virtual interim meeting on 2020-04-02 from 11:00 to 13:00 UTC.
>
> Agenda:
> Agenda is forthcoming on https://mailarchive.ietf.org/arch/browse/netmod/ 
>
> Information about remote participation:
> Remote participation information will be obtained at the time of approval
>
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>


pEpkey.asc
Description: application/pgp-keys
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] [Technical Errata Reported] RFC7950 (6031)

2020-03-27 Thread RFC Errata System

The following errata report has been submitted for RFC7950,
"The YANG 1.1 Data Modeling Language".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6031

--
Type: Technical
Reported by: Radek Krejci 

Section: 9.9.3

Original Text
-
The "require-instance" statement, which is a substatement to the 
"type" statement, MAY be present if the type is "instance-identifier"
or "leafref".  It takes as an argument the string "true" or "false".
If this statement is not present, it defaults to "true".

Corrected Text
--
The "require-instance" statement, which is a substatement to the
"type" statement, MAY be present if the type is "instance-identifier",
"leafref" or a type derived from them. It takes as an argument the
string "true" or "false". If this statement is not present, it defaults
to "true".

Notes
-
As discussed in 
https://mailarchive.ietf.org/arch/browse/netconf/?gbt=1=p_zRKwQ6TBxTuCDPc5wJbdZgWTc,
 authors expect that the require-instance statement is available not only for 
leafref and instance-identifier types, but also for all the types derived from 
them using typedef statement. Since no one argued against this understanding, 
this errata changes the text to the same form as in other restrictions 
applicable to derived types.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--
Title   : The YANG 1.1 Data Modeling Language
Publication Date: August 2016
Author(s)   : M. Bjorklund, Ed.
Category: PROPOSED STANDARD
Source  : Network Modeling
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

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

Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04

2020-03-27 Thread Mahesh Jethanandani

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.  The WGLC is therefore being extended  for another 
> week, now ending April 1st (the day before our Virtual Meeting on April 2nd). 
>  
> 
> Again, positive comments, e.g., "I've reviewed this document and believe it 
> is ready for publication", are welcomed.  This is useful and important, even 
> from authors.  Objections, concerns, and suggestions are also welcomed at 
> this time.
> 
> FWIW, the YANG Doctor review was completed on 3/23 (thanks Mahesh) with the 
> “Ready with Nits” status: 
> https://datatracker.ietf.org/doc/review-ietf-netmod-geo-location-04-yangdoctors-lc-jethanandani-2020-03-23
>  
> .
> 
> Kent // as shepherd and co-chair
> 
> 
> 
>> On Mar 9, 2020, at 6:30 PM, Kent Watsen > > wrote:
>> 
>> This message begins an almost two-week WGLC for 
>> draft-ietf-netmod-geo-location-04 ending on March 22nd (the day before the 
>> NETMOD sessions).  Here is a direct link to the HTML version of the draft:
>> 
>>  https://tools.ietf.org/html/draft-ietf-netmod-geo-location-04 
>> 
>> 
>> 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. Objections, concerns, and suggestions are also welcomed at 
>> this time.
>> 
>> 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

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

[netmod] Grammar for new extensions (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[netmod] Typos and smaller issues (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[netmod] bool v/s empty for new leafs deprecated-nodes and obsolete-nodes (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[netmod] Revision label in filename (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[netmod] rev:status-description (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[netmod] Interpreting revision labels as YANG semantic version numbers (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[netmod] No descendent statements to input/output can be reordered (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[netmod] Revision labels for submodules (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[netmod] All IETF YANG modules MUST include revision-label statements (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04

Re: [netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04

[netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04

Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07

Re: [netmod] Where can I use ?

[netmod] Agenda Items - Re: Network Modeling (netmod) WG Virtual Meeting: 2020-04-02

[netmod] [Technical Errata Reported] RFC7950 (6031)

Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04

23 matches

Site Navigation

Mail list logo

Footer information