Re: [netmod] [Technical Errata Reported] RFC8342 (5514)

2018-12-18 Thread Rohit R Ranade 
Hi All,

So the conclusion here is to raise an Errata on RFC 7950 ? Can others please 
provide your thoughts.

With Regards,
Rohit

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
Sent: 08 October 2018 23:25
To: Andy Bierman ; Lou Berger 
Cc: Ignas Bagdonas ; Warren Kumari ; 
NetMod WG ; RFC Errata System 
Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514)


> After reading the RFC details, it seems that the example is intentional based 
> on
> the text about NP-containers.
>
> I think an errata could be used because the sentence about a top-level origin 
> must be defined
> could be interpreted to define "top-level" as the topmost level for which the 
> origin property
> is applicable.  It appears the intent was to exclude NP-containers from this 
> requirement.

Yes, it was intentional to exclude np-containers, I view something like:

OLD:
The origin for any top-level configuration data nodes must be specified.
NEW:
The origin for any top-level configuration data nodes, except
non-presence containers, must be specified.

to be almost editorial in nature.  That said, I also do not think that it’s 
needed, in that I think
one could argue that an np-container isn’t actually “configuration” at all, 
it’s just implicitly
there providing a skeleton to hang stuff off of.

RFC 8342 says:

   o  configuration: Data that is required to get a device from its
  initial default state into a desired operational state.

An np-container doesn’t actually do this.   RFC 7950 says:

   o  non-presence container: A container that has no meaning of its
  own, existing only to contain child nodes.

Bingo.  RFC 7950 also says:

   o  data node: A node in the schema tree that can be instantiated in a
   data tree.  One of container, leaf, leaf-list, list,  anydata, and 
anyxml.

Note that it says “container” without clarification.  Clearly an np-container 
isn’t “data”
so, if there is to be an errata, perhaps it should be against  RFC 7950, for 
instance:

NEW
   o  data node: A node in the schema tree that can be instantiated in a
   data tree.  One of presence container, leaf, leaf-list, list,  anydata, 
and anyxml.


Kent // contributor

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

Re: [netmod] [Technical Errata Reported] RFC8342 (5514)

2018-10-08 Thread Kent Watsen 

> After reading the RFC details, it seems that the example is intentional based 
> on
> the text about NP-containers.
>
> I think an errata could be used because the sentence about a top-level origin 
> must be defined
> could be interpreted to define "top-level" as the topmost level for which the 
> origin property
> is applicable.  It appears the intent was to exclude NP-containers from this 
> requirement.

Yes, it was intentional to exclude np-containers, I view something like:

OLD:
The origin for any top-level configuration data nodes must be specified.
NEW:
The origin for any top-level configuration data nodes, except
non-presence containers, must be specified.

to be almost editorial in nature.  That said, I also do not think that it’s 
needed, in that I think
one could argue that an np-container isn’t actually “configuration” at all, 
it’s just implicitly
there providing a skeleton to hang stuff off of.

RFC 8342 says:

   o  configuration: Data that is required to get a device from its
  initial default state into a desired operational state.

An np-container doesn’t actually do this.   RFC 7950 says:

   o  non-presence container: A container that has no meaning of its
  own, existing only to contain child nodes.

Bingo.  RFC 7950 also says:

   o  data node: A node in the schema tree that can be instantiated in a
   data tree.  One of container, leaf, leaf-list, list,  anydata, and 
anyxml.

Note that it says “container” without clarification.  Clearly an np-container 
isn’t “data”
so, if there is to be an errata, perhaps it should be against  RFC 7950, for 
instance:

NEW
   o  data node: A node in the schema tree that can be instantiated in a
   data tree.  One of presence container, leaf, leaf-list, list,  anydata, 
and anyxml.


Kent // contributor

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

Re: [netmod] [Technical Errata Reported] RFC8342 (5514)

2018-10-08 Thread Andy Bierman 
On Mon, Oct 8, 2018 at 9:03 AM, Lou Berger  wrote:

>
>
> On 10/8/2018 10:13 AM, Juergen Schoenwaelder wrote:
>
>> On Mon, Oct 08, 2018 at 08:57:33AM -0400, Lou Berger wrote:
>>
>>> I think it's clear that the reviewers, notably myself as shepherd, missed
>>> that this is a lowercase "must" and should have asked for clarification
>>> during the review process.
>>>
>>> Having an errata saying this "must" really is a "MUST" is quite
>>> reasonable
>>> from my perspective.
>>>
>> As explained, technically speaking, the "must" is pointless in certain
>> situations. Making it a MUST does not make things any better.
>>
> Okay - then all that needs to be done is clarify the errata and decide if
> you want to author a new draft on the behavior/text you'd like to change.
>
>

After reading the RFC details, it seems that the example is intentional
based on
the text about NP-containers.

I think an errata could be used because the sentence about a top-level
origin must be defined
could be interpreted to define "top-level" as the topmost level for which
the origin property
is applicable.  It appears the intent was to exclude NP-containers from
this requirement.


Thanks,
> Lou
>

Andy


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

Re: [netmod] [Technical Errata Reported] RFC8342 (5514)

2018-10-08 Thread Lou Berger 

Hi Rob,


On 10/8/2018 9:51 AM, Robert Wilton wrote:

Hi Lou,


On 08/10/2018 13:57, Lou Berger wrote:

Hi Rob/All,

Keep in mind that the document says what it says and that to change
text really requires a new version.

On 10/8/2018 6:01 AM, Robert Wilton wrote:

So there seem to be two available solutions here:

(i) The server MUST provide an origin value for the top level datanode,

This is pretty close to what Andy previously quoted:

  md:annotation origin {
    type origin-ref;
    description
  "The 'origin' annotation can be present on any configuration
   data node in the operational state datastore.  It specifies
   from where the node originated.  If not specified for a given
   configuration data node, then the origin is the same as the
   origin of its parent node in the data tree.  The origin for
   any top-level configuration data nodes must be specified.";
  }


I think it's clear that the reviewers, notably myself as shepherd,
missed that this is a lowercase "must" and should have asked for
clarification during the review process.

So I think that the logic for it being must rather than MUST is that it
is in a YANG module, and we didn't want to tie the YANG module to RFC
2119 language.
I'm not sure this is a great argument.  Using conformance language in 
such cases maybe exactly what is needed - but this is a different 
discussion.






Having an errata saying this "must" really is a "MUST" is quite
reasonable from my perspective.

I'm not convinced that this has to change.


but for NP containers it can use whatever origin value it likes - since
the origin value imparts no direct meaning other than the default origin
that descendants acquire if they haven't provided an explicit origin.
In this case we would probably add a line of text to clarify this
behavior of choosing a suitable origin value for top level NP
containers.

I guess I'd need to see that specific language to understand if a new
requirement or recommended behavior is being prescribed.  If it is, we
need a new document to do so.

The additional sentence (added at the paragraph above) could be
something along the lines of:

"For top level nodes that are non-presence containers, where the origin
has no direct meaning other than as a hierarchical default origin, the
server may choose any convenient origin value".

But equally, perhaps the existing test is sufficient without requiring
any changes at all.


I agree, it's not clear that this change is need as it is *already* what 
is allowed.

Then the errata that is required is the one that
Rohit submitted.

so the errata should be corrected

Lou



Thanks,
Rob



(ii) The requirement is weakened as Juergen has described previously.


Solution (i) minimizes the impact of the change to the RFC, but probably
constrains server implementations slightly more than is strictly
required.

Solution (ii) gives a bit more flexibility to server implementations but
in theory could break client implementation that rely on a top level
origin always being provided.  Although, in reality I would expect a
robust client implementation to either not care, or choose a suitable
default origin (e.g. "unknown") if an explicit origin hasn't been
provided.

If solution (ii) is beyond the scope of what is allowed in an errata
then it would seem that we should go with solution (i) instead. But how
do we get to a final decision?

Either we agree that s/must/MUST in an errata or start a new (update
or bis) draft  to update the behavior.  It would also be fine to flag
the issue in the errata without specific resolution, with the
understanding that the issue would need to be resolved, in an update
or bis, at some point in the future.

Lou


Thanks,
Rob


On 07/10/2018 18:09, Juergen Schoenwaelder wrote:

On Sun, Oct 07, 2018 at 09:49:57AM -0700, Andy Bierman wrote:

Can somebody explain the rationale for the highlighted text from
5.3.4?

Note the difference between "applies to" and "carries". A non-presence
container has no relevance for configuration and hence an origin value
does not *apply* to a non-presence container. Still, a non-presence
container can *carry* an origin attribute.


There are many top-level configuration NP-containers defined already.
It is clearly more efficient to have 1 origin attribute in the
top-level
container than in each of the child nodes.

There is no requirement to produce efficient encodings. This is up to
implementations, the cost of calculating a minimal encodings may be
high for systems that like to stream information. That said, even
toplevel origin attributes are not sufficient to guarantee an
efficient encoding. If most child nodes have an origin different than
what is stated in the toplevel container, you gain little.

The requirement really is that an origin must be defined for all
configuration data nodes (except np-containers). The way how this
is done    is up to implementations. If implementations

Re: [netmod] [Technical Errata Reported] RFC8342 (5514)

2018-10-08 Thread Lou Berger 




On 10/8/2018 10:13 AM, Juergen Schoenwaelder wrote:

On Mon, Oct 08, 2018 at 08:57:33AM -0400, Lou Berger wrote:

I think it's clear that the reviewers, notably myself as shepherd, missed
that this is a lowercase "must" and should have asked for clarification
during the review process.

Having an errata saying this "must" really is a "MUST" is quite reasonable
from my perspective.

As explained, technically speaking, the "must" is pointless in certain
situations. Making it a MUST does not make things any better.
Okay - then all that needs to be done is clarify the errata and decide 
if you want to author a new draft on the behavior/text you'd like to change.


Thanks,
Lou



/js



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

Re: [netmod] [Technical Errata Reported] RFC8342 (5514)

2018-10-08 Thread Juergen Schoenwaelder 
On Mon, Oct 08, 2018 at 08:57:33AM -0400, Lou Berger wrote:
> 
> I think it's clear that the reviewers, notably myself as shepherd, missed
> that this is a lowercase "must" and should have asked for clarification
> during the review process.
> 
> Having an errata saying this "must" really is a "MUST" is quite reasonable
> from my perspective.

As explained, technically speaking, the "must" is pointless in certain
situations. Making it a MUST does not make things any better.

/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] RFC8342 (5514)

2018-10-08 Thread Robert Wilton 

Hi Lou,


On 08/10/2018 13:57, Lou Berger wrote:

Hi Rob/All,

Keep in mind that the document says what it says and that to change 
text really requires a new version.


On 10/8/2018 6:01 AM, Robert Wilton wrote:

So there seem to be two available solutions here:

(i) The server MUST provide an origin value for the top level datanode,

This is pretty close to what Andy previously quoted:

 md:annotation origin {
   type origin-ref;
   description
 "The 'origin' annotation can be present on any configuration
  data node in the operational state datastore.  It specifies
  from where the node originated.  If not specified for a given
  configuration data node, then the origin is the same as the
  origin of its parent node in the data tree.  The origin for
  any top-level configuration data nodes must be specified.";
 }


I think it's clear that the reviewers, notably myself as shepherd, 
missed that this is a lowercase "must" and should have asked for 
clarification during the review process.
So I think that the logic for it being must rather than MUST is that it 
is in a YANG module, and we didn't want to tie the YANG module to RFC 
2119 language.





Having an errata saying this "must" really is a "MUST" is quite 
reasonable from my perspective.

I'm not convinced that this has to change.




but for NP containers it can use whatever origin value it likes - since
the origin value imparts no direct meaning other than the default origin
that descendants acquire if they haven't provided an explicit origin.



In this case we would probably add a line of text to clarify this
behavior of choosing a suitable origin value for top level NP 
containers.
I guess I'd need to see that specific language to understand if a new 
requirement or recommended behavior is being prescribed.  If it is, we 
need a new document to do so.
The additional sentence (added at the paragraph above) could be 
something along the lines of:


"For top level nodes that are non-presence containers, where the origin 
has no direct meaning other than as a hierarchical default origin, the 
server may choose any convenient origin value".


But equally, perhaps the existing test is sufficient without requiring 
any changes at all.  Then the errata that is required is the one that 
Rohit submitted.


Thanks,
Rob





(ii) The requirement is weakened as Juergen has described previously.


Solution (i) minimizes the impact of the change to the RFC, but probably
constrains server implementations slightly more than is strictly 
required.


Solution (ii) gives a bit more flexibility to server implementations but
in theory could break client implementation that rely on a top level
origin always being provided.  Although, in reality I would expect a
robust client implementation to either not care, or choose a suitable
default origin (e.g. "unknown") if an explicit origin hasn't been 
provided.


If solution (ii) is beyond the scope of what is allowed in an errata
then it would seem that we should go with solution (i) instead. But how
do we get to a final decision?


Either we agree that s/must/MUST in an errata or start a new (update 
or bis) draft  to update the behavior.  It would also be fine to flag 
the issue in the errata without specific resolution, with the 
understanding that the issue would need to be resolved, in an update 
or bis, at some point in the future.


Lou



Thanks,
Rob


On 07/10/2018 18:09, Juergen Schoenwaelder wrote:

On Sun, Oct 07, 2018 at 09:49:57AM -0700, Andy Bierman wrote:
Can somebody explain the rationale for the highlighted text from 
5.3.4?

Note the difference between "applies to" and "carries". A non-presence
container has no relevance for configuration and hence an origin value
does not *apply* to a non-presence container. Still, a non-presence
container can *carry* an origin attribute.


There are many top-level configuration NP-containers defined already.
It is clearly more efficient to have 1 origin attribute in the 
top-level

container than in each of the child nodes.

There is no requirement to produce efficient encodings. This is up to
implementations, the cost of calculating a minimal encodings may be
high for systems that like to stream information. That said, even
toplevel origin attributes are not sufficient to guarantee an
efficient encoding. If most child nodes have an origin different than
what is stated in the toplevel container, you gain little.

The requirement really is that an origin must be defined for all
configuration data nodes (except np-containers). The way how this
is done    is up to implementations. If implementations want to set
default    origins    at the toplevel, so be it.

/js





.



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

Re: [netmod] [Technical Errata Reported] RFC8342 (5514)

2018-10-08 Thread Lou Berger 

Hi Rob/All,

Keep in mind that the document says what it says and that to change text 
really requires a new version.


On 10/8/2018 6:01 AM, Robert Wilton wrote:

So there seem to be two available solutions here:

(i) The server MUST provide an origin value for the top level datanode,

This is pretty close to what Andy previously quoted:

 md:annotation origin {
   type origin-ref;
   description
 "The 'origin' annotation can be present on any configuration
  data node in the operational state datastore.  It specifies
  from where the node originated.  If not specified for a given
  configuration data node, then the origin is the same as the
  origin of its parent node in the data tree.  The origin for
  any top-level configuration data nodes must be specified.";
 }


I think it's clear that the reviewers, notably myself as shepherd, 
missed that this is a lowercase "must" and should have asked for 
clarification during the review process.


Having an errata saying this "must" really is a "MUST" is quite 
reasonable from my perspective.



but for NP containers it can use whatever origin value it likes - since
the origin value imparts no direct meaning other than the default origin
that descendants acquire if they haven't provided an explicit origin.



In this case we would probably add a line of text to clarify this
behavior of choosing a suitable origin value for top level NP containers.
I guess I'd need to see that specific language to understand if a new 
requirement or recommended behavior is being prescribed.  If it is, we 
need a new document to do so.



(ii) The requirement is weakened as Juergen has described previously.


Solution (i) minimizes the impact of the change to the RFC, but probably
constrains server implementations slightly more than is strictly required.

Solution (ii) gives a bit more flexibility to server implementations but
in theory could break client implementation that rely on a top level
origin always being provided.  Although, in reality I would expect a
robust client implementation to either not care, or choose a suitable
default origin (e.g. "unknown") if an explicit origin hasn't been provided.

If solution (ii) is beyond the scope of what is allowed in an errata
then it would seem that we should go with solution (i) instead.  But how
do we get to a final decision?


Either we agree that s/must/MUST in an errata or start a new (update or 
bis) draft  to update the behavior.  It would also be fine to flag the 
issue in the errata without specific resolution, with the understanding 
that the issue would need to be resolved, in an update or bis, at some 
point in the future.


Lou



Thanks,
Rob


On 07/10/2018 18:09, Juergen Schoenwaelder wrote:

On Sun, Oct 07, 2018 at 09:49:57AM -0700, Andy Bierman wrote:

Can somebody explain the rationale for the highlighted text from 5.3.4?

Note the difference between "applies to" and "carries". A non-presence
container has no relevance for configuration and hence an origin value
does not *apply* to a non-presence container. Still, a non-presence
container can *carry* an origin attribute.


There are many top-level configuration NP-containers defined already.
It is clearly more efficient to have 1 origin attribute in the top-level
container than in each of the child nodes.

There is no requirement to produce efficient encodings. This is up to
implementations, the cost of calculating a minimal encodings may be
high for systems that like to stream information. That said, even
toplevel origin attributes are not sufficient to guarantee an
efficient encoding. If most child nodes have an origin different than
what is stated in the toplevel container, you gain little.

The requirement really is that an origin must be defined for all
configuration data nodes (except np-containers). The way how this
is done is up to implementations. If implementations want to set
default origins at the toplevel, so be it.

/js





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

Re: [netmod] [Technical Errata Reported] RFC8342 (5514)

2018-10-08 Thread Robert Wilton 

So there seem to be two available solutions here:

(i) The server MUST provide an origin value for the top level datanode, 
but for NP containers it can use whatever origin value it likes - since 
the origin value imparts no direct meaning other than the default origin 
that descendants acquire if they haven't provided an explicit origin.  
In this case we would probably add a line of text to clarify this 
behavior of choosing a suitable origin value for top level NP containers.


(ii) The requirement is weakened as Juergen has described previously.


Solution (i) minimizes the impact of the change to the RFC, but probably 
constrains server implementations slightly more than is strictly required.


Solution (ii) gives a bit more flexibility to server implementations but 
in theory could break client implementation that rely on a top level 
origin always being provided.  Although, in reality I would expect a 
robust client implementation to either not care, or choose a suitable 
default origin (e.g. "unknown") if an explicit origin hasn't been provided.


If solution (ii) is beyond the scope of what is allowed in an errata 
then it would seem that we should go with solution (i) instead.  But how 
do we get to a final decision?


Thanks,
Rob


On 07/10/2018 18:09, Juergen Schoenwaelder wrote:

On Sun, Oct 07, 2018 at 09:49:57AM -0700, Andy Bierman wrote:

Can somebody explain the rationale for the highlighted text from 5.3.4?

Note the difference between "applies to" and "carries". A non-presence
container has no relevance for configuration and hence an origin value
does not *apply* to a non-presence container. Still, a non-presence
container can *carry* an origin attribute.


There are many top-level configuration NP-containers defined already.
It is clearly more efficient to have 1 origin attribute in the top-level
container than in each of the child nodes.

There is no requirement to produce efficient encodings. This is up to
implementations, the cost of calculating a minimal encodings may be
high for systems that like to stream information. That said, even
toplevel origin attributes are not sufficient to guarantee an
efficient encoding. If most child nodes have an origin different than
what is stated in the toplevel container, you gain little.

The requirement really is that an origin must be defined for all
configuration data nodes (except np-containers). The way how this
is done is up to implementations. If implementations want to set
default origins at the toplevel, so be it.

/js



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

Re: [netmod] [Technical Errata Reported] RFC8342 (5514)

2018-10-07 Thread Andy Bierman 
On Sat, Oct 6, 2018 at 11:47 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Fri, Oct 05, 2018 at 09:53:32AM -0700, Andy Bierman wrote:
> > On Fri, Oct 5, 2018 at 9:12 AM, Lou Berger  wrote:
> >
> > > My personal opinion (with any hat on) is that it isn't appropriate to
> make
> > > a technical change that impacts implementation in an errata.
> > > Clarifications of original intent, corrections of inconsistencies and
> > > editorial corrections are perfectly appropriate.  I'm happy to learn
> that
> > > this intended use/scope of errata is wrong.
> > >
> > >
> > Strongly agree.
> > Errata cannot be used to change technical decisions.
> > It can only be used to correct text that is incorrect.
> >
>
> So far so good but we all know that at the end its a judgement call.
>
> The intention of the text was to ensure that there is always a defined
> origin value. One way to achieve that is to have an origin defined at
> the root. But there are obviously other possibilities to achieve the
> intended goal, as the example demonstrates. While we can for sure add
> an origin at the root in the example, it serves no purpose. In other
> words, the example demonstrates that we failed to reinforce this by
> saying "every config data node needs to have a defined origin value
> and one way to achieve that is to define origin's are the roots of the
> subtrees" but instead we created the rule "all roots of the subtrees
> must have a defined origin value", which in certain approaches to
> maintain origin metadata and generate origin attributes is more a CLR.
>
> But sure, if people want to close this discussion on formal grounds,
> so be it. We will just have introduced a CLR.
>
>
5.3.4 .  Origin
Metadata Annotation

   As configuration flows into , it is conceptually marked
   with a metadata annotation [RFC7952
] that indicates its origin.*
The
   origin applies to all configuration nodes except non-presence
   containers. *



md:annotation origin {
   type origin-ref;
   description
 "The 'origin' annotation can be present on any configuration
  data node in the operational state datastore.  It specifies
  from where the node originated.  If not specified for a given
  configuration data node, then the origin is the same as the
  origin of its parent node in the data tree. * The origin for
  any top-level configuration data nodes must be specified.*";
 }



Can somebody explain the rationale for the highlighted text from 5.3.4?
There are many top-level configuration NP-containers defined already.
It is clearly more efficient to have 1 origin attribute in the top-level
container
than in each of the child nodes.




/js
>

Andy


>
> --
> 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] RFC8342 (5514)

2018-10-07 Thread Juergen Schoenwaelder 
On Fri, Oct 05, 2018 at 09:53:32AM -0700, Andy Bierman wrote:
> On Fri, Oct 5, 2018 at 9:12 AM, Lou Berger  wrote:
> 
> > My personal opinion (with any hat on) is that it isn't appropriate to make
> > a technical change that impacts implementation in an errata.
> > Clarifications of original intent, corrections of inconsistencies and
> > editorial corrections are perfectly appropriate.  I'm happy to learn that
> > this intended use/scope of errata is wrong.
> >
> >
> Strongly agree.
> Errata cannot be used to change technical decisions.
> It can only be used to correct text that is incorrect.
>

So far so good but we all know that at the end its a judgement call.

The intention of the text was to ensure that there is always a defined
origin value. One way to achieve that is to have an origin defined at
the root. But there are obviously other possibilities to achieve the
intended goal, as the example demonstrates. While we can for sure add
an origin at the root in the example, it serves no purpose. In other
words, the example demonstrates that we failed to reinforce this by
saying "every config data node needs to have a defined origin value
and one way to achieve that is to define origin's are the roots of the
subtrees" but instead we created the rule "all roots of the subtrees
must have a defined origin value", which in certain approaches to
maintain origin metadata and generate origin attributes is more a CLR.

But sure, if people want to close this discussion on formal grounds,
so be it. We will just have introduced a CLR.

/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] RFC8342 (5514)

2018-10-05 Thread Andy Bierman 
On Fri, Oct 5, 2018 at 9:12 AM, Lou Berger  wrote:

> My personal opinion (with any hat on) is that it isn't appropriate to make
> a technical change that impacts implementation in an errata.
> Clarifications of original intent, corrections of inconsistencies and
> editorial corrections are perfectly appropriate.  I'm happy to learn that
> this intended use/scope of errata is wrong.
>
>
Strongly agree.
Errata cannot be used to change technical decisions.
It can only be used to correct text that is incorrect.


> Lou
>

Andy


>
>
> On 10/5/2018 10:28 AM, Juergen Schoenwaelder wrote:
>
>> Well, if you think an errata does not work, we can file a one page
>> document with N pages of boilerplate around it.
>>
>> /js
>>
>> On Fri, Oct 05, 2018 at 08:14:33AM -0400, Lou Berger wrote:
>>
>>> Juergen,
>>>
>>>  The document says what it says, i.e., "The origin for any top-level
>>> configuration data nodes must be specified."  Changes to this would
>>> require
>>> a BIS or an RFC that updates this document.
>>>
>>> Lou
>>>
>>>
>>> On 10/5/2018 6:14 AM, Juergen Schoenwaelder wrote:
>>>
 Hi,

 the authors have been discussing whether the top-level requirement is
 too strict but there has not been a clear conclusion yet I think. In
 the example, all nodes to have a defined origin and hence the origin
 at the root will have zero effect.

 /js

 On Fri, Oct 05, 2018 at 02:48:08AM -0700, RFC Errata System wrote:

> The following errata report has been submitted for RFC8342,
> "Network Management Datastore Architecture (NMDA)".
>
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5514
>
> --
> Type: Technical
> Reported by: Rohit R Ranade 
>
> Section: C.1
>
> Original Text
> -
>    xmlns="urn:example:system"
>  xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
>
>bar.example.com
>
>
>  eth0
>  
>true
>1000
>  
>  100
>  
>2001:db8::10
>64
>  
>  
>2001:db8::1:100
>64
>  
>
>
>
>  lo0
>  
>::1
>128
>  
>
>
>  
>
> Corrected Text
> --
>    xmlns="urn:example:system"
>  xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
>  or:origin="or:intended">
>
>bar.example.com
>
>
>  eth0
>  
>true
>1000
>  
>  100
>  
>2001:db8::10
>64
>  
>  
>2001:db8::1:100
>64
>  
>
>
>
>  lo0
>  
>::1
>128
>  
>
>
>  
>
> Notes
> -
> There was no "origin" attribute to the "system" top-level container,
> though it is a configuration node.
> As per the extension definition "The origin for any top-level
> configuration data nodes must be specified."
>
> To choose an extension for top-level container in such cases, I would
> prefer one of the origin of its children and used "intended". , instead of
> "unknown".
>
> This has already been discussed in the mail chain, but also mentioned
> here to help readers in future.
>
> 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.
>
> --
> RFC8342 (draft-ietf-netmod-revised-datastores-10)
> --
> Title   : Network Management Datastore Architecture (NMDA)
> Publication Date: March 2018
> Author(s)   : M. Bjorklund, J. Schoenwaelder, P. Shafer, K.
> Watsen, R. Wilton
> 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
>>>
>>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

Re: [netmod] [Technical Errata Reported] RFC8342 (5514)

2018-10-05 Thread Lou Berger 
My personal opinion (with any hat on) is that it isn't appropriate to 
make a technical change that impacts implementation in an errata.  
Clarifications of original intent, corrections of inconsistencies and 
editorial corrections are perfectly appropriate.  I'm happy to learn 
that this intended use/scope of errata is wrong.


Lou


On 10/5/2018 10:28 AM, Juergen Schoenwaelder wrote:

Well, if you think an errata does not work, we can file a one page
document with N pages of boilerplate around it.

/js

On Fri, Oct 05, 2018 at 08:14:33AM -0400, Lou Berger wrote:

Juergen,

     The document says what it says, i.e., "The origin for any top-level
configuration data nodes must be specified."  Changes to this would require
a BIS or an RFC that updates this document.

Lou


On 10/5/2018 6:14 AM, Juergen Schoenwaelder wrote:

Hi,

the authors have been discussing whether the top-level requirement is
too strict but there has not been a clear conclusion yet I think. In
the example, all nodes to have a defined origin and hence the origin
at the root will have zero effect.

/js

On Fri, Oct 05, 2018 at 02:48:08AM -0700, RFC Errata System wrote:

The following errata report has been submitted for RFC8342,
"Network Management Datastore Architecture (NMDA)".

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

--
Type: Technical
Reported by: Rohit R Ranade 

Section: C.1

Original Text
-
 

   bar.example.com

   
 eth0
 
   true
   1000
 
 100
 
   2001:db8::10
   64
 
 
   2001:db8::1:100
   64
 
   

   
 lo0
 
   ::1
   128
 
   

 

Corrected Text
--
 

   bar.example.com

   
 eth0
 
   true
   1000
 
 100
 
   2001:db8::10
   64
 
 
   2001:db8::1:100
   64
 
   

   
 lo0
 
   ::1
   128
 
   

 

Notes
-
There was no "origin" attribute to the "system" top-level container, though it 
is a configuration node.
As per the extension definition "The origin for any top-level configuration data 
nodes must be specified."

To choose an extension for top-level container in such cases, I would prefer one of the origin of 
its children and used "intended". , instead of "unknown".

This has already been discussed in the mail chain, but also mentioned here to 
help readers in future.

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.

--
RFC8342 (draft-ietf-netmod-revised-datastores-10)
--
Title   : Network Management Datastore Architecture (NMDA)
Publication Date: March 2018
Author(s)   : M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. 
Wilton
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


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

Re: [netmod] [Technical Errata Reported] RFC8342 (5514)

2018-10-05 Thread Juergen Schoenwaelder 
Well, if you think an errata does not work, we can file a one page
document with N pages of boilerplate around it.

/js

On Fri, Oct 05, 2018 at 08:14:33AM -0400, Lou Berger wrote:
> Juergen,
> 
>     The document says what it says, i.e., "The origin for any top-level
> configuration data nodes must be specified."  Changes to this would require
> a BIS or an RFC that updates this document.
> 
> Lou
> 
> 
> On 10/5/2018 6:14 AM, Juergen Schoenwaelder wrote:
> > Hi,
> > 
> > the authors have been discussing whether the top-level requirement is
> > too strict but there has not been a clear conclusion yet I think. In
> > the example, all nodes to have a defined origin and hence the origin
> > at the root will have zero effect.
> > 
> > /js
> > 
> > On Fri, Oct 05, 2018 at 02:48:08AM -0700, RFC Errata System wrote:
> > > The following errata report has been submitted for RFC8342,
> > > "Network Management Datastore Architecture (NMDA)".
> > > 
> > > --
> > > You may review the report below and at:
> > > http://www.rfc-editor.org/errata/eid5514
> > > 
> > > --
> > > Type: Technical
> > > Reported by: Rohit R Ranade 
> > > 
> > > Section: C.1
> > > 
> > > Original Text
> > > -
> > >  > > xmlns="urn:example:system"
> > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
> > > 
> > >   bar.example.com
> > > 
> > >   
> > > eth0
> > > 
> > >   true
> > >   1000
> > > 
> > > 100
> > > 
> > >   2001:db8::10
> > >   64
> > > 
> > > 
> > >   2001:db8::1:100
> > >   64
> > > 
> > >   
> > > 
> > >   
> > > lo0
> > > 
> > >   ::1
> > >   128
> > > 
> > >   
> > > 
> > > 
> > > 
> > > Corrected Text
> > > --
> > >  > > xmlns="urn:example:system"
> > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
> > > or:origin="or:intended">
> > > 
> > >   bar.example.com
> > > 
> > >   
> > > eth0
> > > 
> > >   true
> > >   1000
> > > 
> > > 100
> > > 
> > >   2001:db8::10
> > >   64
> > > 
> > > 
> > >   2001:db8::1:100
> > >   64
> > > 
> > >   
> > > 
> > >   
> > > lo0
> > > 
> > >   ::1
> > >   128
> > > 
> > >   
> > > 
> > > 
> > > 
> > > Notes
> > > -
> > > There was no "origin" attribute to the "system" top-level container, 
> > > though it is a configuration node.
> > > As per the extension definition "The origin for any top-level 
> > > configuration data nodes must be specified."
> > > 
> > > To choose an extension for top-level container in such cases, I would 
> > > prefer one of the origin of its children and used "intended". , instead 
> > > of "unknown".
> > > 
> > > This has already been discussed in the mail chain, but also mentioned 
> > > here to help readers in future.
> > > 
> > > 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.
> > > 
> > > --
> > > RFC8342 (draft-ietf-netmod-revised-datastores-10)
> > > --
> > > Title   : Network Management Datastore Architecture (NMDA)
> > > Publication Date: March 2018
> > > Author(s)   : M. Bjorklund, J. Schoenwaelder, P. Shafer, K. 
> > > Watsen, R. Wilton
> > > 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] RFC8342 (5514)

2018-10-05 Thread Lou Berger 

Juergen,

    The document says what it says, i.e., "The origin for any top-level 
configuration data nodes must be specified."  Changes to this would 
require a BIS or an RFC that updates this document.


Lou


On 10/5/2018 6:14 AM, Juergen Schoenwaelder wrote:

Hi,

the authors have been discussing whether the top-level requirement is
too strict but there has not been a clear conclusion yet I think. In
the example, all nodes to have a defined origin and hence the origin
at the root will have zero effect.

/js

On Fri, Oct 05, 2018 at 02:48:08AM -0700, RFC Errata System wrote:

The following errata report has been submitted for RFC8342,
"Network Management Datastore Architecture (NMDA)".

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

--
Type: Technical
Reported by: Rohit R Ranade 

Section: C.1

Original Text
-


  bar.example.com

  
eth0

  true
  1000

100

  2001:db8::10
  64


  2001:db8::1:100
  64

  

  
lo0

  ::1
  128

  



Corrected Text
--


  bar.example.com

  
eth0

  true
  1000

100

  2001:db8::10
  64


  2001:db8::1:100
  64

  

  
lo0

  ::1
  128

  



Notes
-
There was no "origin" attribute to the "system" top-level container, though it 
is a configuration node.
As per the extension definition "The origin for any top-level configuration data 
nodes must be specified."

To choose an extension for top-level container in such cases, I would prefer one of the origin of 
its children and used "intended". , instead of "unknown".

This has already been discussed in the mail chain, but also mentioned here to 
help readers in future.

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.

--
RFC8342 (draft-ietf-netmod-revised-datastores-10)
--
Title   : Network Management Datastore Architecture (NMDA)
Publication Date: March 2018
Author(s)   : M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. 
Wilton
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] [Technical Errata Reported] RFC8342 (5514)

2018-10-05 Thread Juergen Schoenwaelder 
Hi,

the authors have been discussing whether the top-level requirement is
too strict but there has not been a clear conclusion yet I think. In
the example, all nodes to have a defined origin and hence the origin
at the root will have zero effect.

/js

On Fri, Oct 05, 2018 at 02:48:08AM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC8342,
> "Network Management Datastore Architecture (NMDA)".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5514
> 
> --
> Type: Technical
> Reported by: Rohit R Ranade 
> 
> Section: C.1
> 
> Original Text
> -
>xmlns="urn:example:system"
>xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
> 
>  bar.example.com
> 
>  
>eth0
>
>  true
>  1000
>
>100
>
>  2001:db8::10
>  64
>
>
>  2001:db8::1:100
>  64
>
>  
> 
>  
>lo0
>
>  ::1
>  128
>
>  
> 
>
> 
> Corrected Text
> --
>xmlns="urn:example:system"
>xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
>or:origin="or:intended">
> 
>  bar.example.com
> 
>  
>eth0
>
>  true
>  1000
>
>100
>
>  2001:db8::10
>  64
>
>
>  2001:db8::1:100
>  64
>
>  
> 
>  
>lo0
>
>  ::1
>  128
>
>  
> 
>
> 
> Notes
> -
> There was no "origin" attribute to the "system" top-level container, though 
> it is a configuration node.
> As per the extension definition "The origin for any top-level configuration 
> data nodes must be specified."
> 
> To choose an extension for top-level container in such cases, I would prefer 
> one of the origin of its children and used "intended". , instead of "unknown".
> 
> This has already been discussed in the mail chain, but also mentioned here to 
> help readers in future.
> 
> 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. 
> 
> --
> RFC8342 (draft-ietf-netmod-revised-datastores-10)
> --
> Title   : Network Management Datastore Architecture (NMDA)
> Publication Date: March 2018
> Author(s)   : M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, 
> R. Wilton
> Category: PROPOSED STANDARD
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG

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