Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00

[Juergen Schoenwaelder]

On Fri, Jul 20, 2018 at 02:41:33PM -0700, Andy Bierman wrote:
> Hi,
> 
> I strongly object to requirement 3.1:
> 
> 
> 3.1  The solution MUST provide a mechanism to allow servers to
> support existing clients in a backward compatible way.
> 
> 
> 
> This is not what servers do today at all.
> They provide only one version of an implemented module, as specified in RFC
> 7950.

But today a backwards incompatible change leads to a new module and
you can very well implement two modules if that is reasonable to do in
order to allow clients a transition period.

/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] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00

[Juergen Schoenwaelder]

My understanding is that the MUST puts a requirement on the solution
and the rest is an "allow servers", i.e., something that servers may
want to do. (I was against using RFC 2119 keywords in the first place
for this document.)

/js

On Fri, Jul 20, 2018 at 02:41:33PM -0700, Andy Bierman wrote:
> Hi,
> 
> I strongly object to requirement 3.1:
> 
> 
> 3.1  The solution MUST provide a mechanism to allow servers to
> support existing clients in a backward compatible way.
> 
> 
> 
> This is not what servers do today at all.
> They provide only one version of an implemented module, as specified in RFC
> 7950.
> 
> It is a vendor and operator decision when to upgrade a server such that
> non-backward compatible changes are made. They must decide if/when it is ok
> based on the client applications in use.
> 
> This requirement says you cannot make backward-incompatible changes
> which completely contradicts requirements 1.1 and 1.2.
> 
> IMO requirement 3.1 should be removed, or change MUST to MAY
> 
> 
> Andy

> ___
> 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] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00

[Andy Bierman]

Hi,

I strongly object to requirement 3.1:


3.1  The solution MUST provide a mechanism to allow servers to
support existing clients in a backward compatible way.



This is not what servers do today at all.
They provide only one version of an implemented module, as specified in RFC
7950.

It is a vendor and operator decision when to upgrade a server such that
non-backward compatible changes are made. They must decide if/when it is ok
based on the client applications in use.

This requirement says you cannot make backward-incompatible changes
which completely contradicts requirements 1.1 and 1.2.

IMO requirement 3.1 should be removed, or change MUST to MAY


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

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

[Mahesh Jethanandani]

Sent from my iPhone

> On Jul 20, 2018, at 10:40 AM, Juergen Schoenwaelder 
>  wrote:
> 
>> On Fri, Jul 20, 2018 at 03:45:47PM +0200, Martin Vigoureux wrote:
>> 
>> 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.
> 
> iana- has the advantage that everybody knows which registry is meant.
> Using registry- is perhaps more flexible in case IANA registry gets
> renamed but it leaves is much more open where the module is
> maintained. The first part of a module name is supposed to identify an
> organization. draft-ietf-netmod-rfc6087bis-20.txt (RFC editor queue)
> says:
> 
>   It is suggested that a stable prefix be selected representing the
>   entire organization.  All normative YANG modules published by the
>   IETF MUST begin with the prefix "ietf-".  Another standards
>   organization, such as the IEEE, might use the prefix "ieee-" for all
>   YANG modules.
> 
> Concerning documentation, perhaps we could change the above to this:
> 
>   It is suggested that a stable prefix be selected representing the
>   entire organization.  All normative YANG modules published by the
>   IETF MUST begin with the prefix "ietf-".  Another standards
>   organization, such as the IEEE, might use the prefix "ieee-" for all
>   YANG modules. YANG modules maintained by IANA for the IETF SHOULD
>   begin with the prefix "iana-".

+1

I agree that the prefix suggests the organization responsible for maintaining 
the model, something reg- or registry- does not. Two more examples that already 
exist are mef- and etsi-. I understand there is the possibility that that 
prefix changes, but we then pick a new prefix, if we know what it might be. 

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

Re: [netmod] Thoughts on draft-clemm-netmod-nmda-diff

[Qin Wu]

Add two additional thoughts,
(1) I hope NMDA datastore can be used to compare one datastore at two different 
timepoints, so I am not sure source and target defined in the model are enough 
to support this case.
(2) NMDA Base events defined in 
(https://tools.ietf.org/html/draft-wu-netconf-base-notification-nmda-01 can 
leverage NMDA diff to perform NMDA data validation, right now it is up to the 
server to detect validation event, but now we might rely on NMDA diff to decide 
which object is missing, what failed objects are. NMDA diff becomes a good tool.
On the other hand, user might want to know when applied configuration start, 
when applied configuration complete, based on this to see when to perform NMDA 
diff. To address this, we might consider two or three new notifications
In the draft-wu-netconf-base-notification-nmda-01 to help to decide when to use 
NDMA diff

-Qin
-邮件原件-)
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Joe Clarke
发送时间: 2018年7月20日 21:52
收件人: netmod@ietf.org
主题: [netmod] Thoughts on draft-clemm-netmod-nmda-diff

I just had a chance to finish reading this.  The in-person meeting group seems 
to strongly support this work, and I agree.

Coming from a serviceability standpoint, I find this might serve as a precursor 
to a VCS-like "blame log".  Would it be reasonable to include identifiers as to 
who (or what) made the change and when?  Sorry if this was raised at the mic 
today.  I came to the room a bit late.

Joe

___
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

[Juergen Schoenwaelder]

On Fri, Jul 20, 2018 at 03:45:47PM +0200, Martin Vigoureux wrote:
 
> 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.

iana- has the advantage that everybody knows which registry is meant.
Using registry- is perhaps more flexible in case IANA registry gets
renamed but it leaves is much more open where the module is
maintained. The first part of a module name is supposed to identify an
organization. draft-ietf-netmod-rfc6087bis-20.txt (RFC editor queue)
says:

   It is suggested that a stable prefix be selected representing the
   entire organization.  All normative YANG modules published by the
   IETF MUST begin with the prefix "ietf-".  Another standards
   organization, such as the IEEE, might use the prefix "ieee-" for all
   YANG modules.

Concerning documentation, perhaps we could change the above to this:

   It is suggested that a stable prefix be selected representing the
   entire organization.  All normative YANG modules published by the
   IETF MUST begin with the prefix "ietf-".  Another standards
   organization, such as the IEEE, might use the prefix "ieee-" for all
   YANG modules. YANG modules maintained by IANA for the IETF SHOULD
   begin with the prefix "iana-".

/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] "iana" in yang modules' name/namespace/prefix

[Acee Lindem (acee)]

Hi Martin, 
I would prefer not using "reg" since it will always be an abbreviation for a 
machine language register to me. I'd favor using "registry" in the module name 
and the more cryptic "reg" in the module prefix. 
Thanks,
Acee 

On 7/20/18, 9:46 AM, "netmod on behalf of Martin Vigoureux" 
 wrote:

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] clarifications for draft-clemm-netmod-nmda-diff

[Sterne, Jason (Nokia - CA/Ottawa)]

Hi all,

One thing that we should probably clarify in the diff draft is that a 
comparison to the operational datastore is not expected to be an atomic 
snapshot..   As the diff function walks through the nodes, some of the 
operational nodes may change value while the diff is underway.

I believe the primary use case for the draft is related to comparison of 
config=true data.  Most of the draft seems focused on that case.  Are there use 
cases that compare config=false data ?  Maybe we should give some example or 
explanation of that case.

Regards,
Jason


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

[netmod] Thoughts on draft-clemm-netmod-nmda-diff

[Joe Clarke]

I just had a chance to finish reading this.  The in-person meeting group
seems to strongly support this work, and I agree.

Coming from a serviceability standpoint, I find this might serve as a
precursor to a VCS-like "blame log".  Would it be reasonable to include
identifiers as to who (or what) made the change and when?  Sorry if this
was raised at the mic today.  I came to the room a bit late.

Joe

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

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

[Martin Vigoureux]

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

Re: [netmod] YANG schema mount - any early implementations?

[Juergen Schoenwaelder]

On Wed, Jul 11, 2018 at 09:43:32AM +1200, hayden wrote:
>   
> I understand that the schema mount proposal is still effectively in a 
> state of flux, but are there any publicly visible implementations or 
> deployments of a NETCONF or RESTCONF server that those interested could 
> experiment with (e.g. to aid in client development)?
>

State of flux? It is past WG last call and IETF last call.

https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/history/

/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