Re: [netmod] 回复：confusion about canonicalization of date-and-time type value in?? netconf reply

[Jürgen Schönwälder]

On Tue, Aug 29, 2023 at 11:04:37AM +0800, lyzliyu...@163.com wrote:
>But I think rfc7950 section 9.1 is only about yang built-in type because
>section 9's title is built-in type.
> 
>If someone define a leaf with date-and-time type but modify it's pattern
>to only Z-suffix time form( this is valid in rfc7950), and then if the
>server still reply the value with +08:00 form, then the server actually
>reply an invalid value which violates the pattern.
>So I think it is not a good practice for a server to do such value change
>in reply for the non built-in type.
>

Canonicalization comes into play when there are multiple possible
_representations_ of the same value.

The idea is that a server may accept different representations as
input but always responds with a predictable representation as output.

/js

-- 
Jürgen Schönwälder  Constructor 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] YANG module updates based on Errata

[Reshad Rahman]

 Hi Balazs,
AFAIK an errata does not lead to an updated "official" module somewhere. I seem 
to recall that this was brought up by Benoit and/or Rob some time ago, but I 
might be misremembering. I agree that having individual consumers apply the 
errata isn't great.
Regards,Reshad.
On Wednesday, August 23, 2023, 09:28:21 AM EDT, Balázs Lengyel 
 wrote:  
 
  
Hello,
 
If a YANG module in an RFC is updated by errata (e.g. 
https://www.rfc-editor.org/errata/rfc6470) is an official updated IETF  YANG 
module published somewhere?
 
At the moment I don’t find an official update for 
ietf-netconf-notification.yang, thus the only thing my company can do is to 
create and use an unofficial update to the IETF module. That is nasty as a 
vendor should not change IETF modules. But is there any better solution?
 
  
 
  
 
LONG TERM: my preference would be that the errata should include the updated 
module which should be published  on the IETF github. (A full bis updated would 
be preferred, but unlikely to happen.)
 
  
 
Regards Balazs
 
P.S. Sorry if this was discussed, but I don’t remember.
 ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Kent Watsen]

Thank you everyone that participated in the poll.
Based on the results, there isn’t sufficient support to adopt the draft at this 
time.

Kent and Lou


> On Aug 3, 2023, at 2:02 PM, Kent Watsen  wrote:
> 
> NETMOD WG,
> 
> This email begins a 2-week adoption poll for: 
> https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits/02
> 
> There is no known IPR on this draft (IPR call 
> ).
> 
> Please voice your support or technical objections to adoption on the list by 
> the end of the day (any time zone) Aug 17.
> 
> PS: I was hoping that Jeff would update the draft to reflect comments 
> received on-list (e.g., here 
> ) 
> before starting this poll, but he is going on PTO shortly and wouldn’t be 
> able to get to it for awhile, though he’s happy to do so upon returning.
> 
> Thank you,
> Kent (as Co-chair)
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] confusion about canonicalization of date-and-time type value in netconf reply

[Jürgen Schönwälder]

Your question seems to be whether the server should return the
canonical format or the format used in the request. My take is that
the server should always return the canonical format. See RFC 7950
Section 9.1.

/js

On Tue, Aug 29, 2023 at 01:01:42AM +0800, 老空楼 wrote:
> If a list key is date-and-time type, is it a little bit strange for a netconf 
> server to reply data with key value different from that in get/get-config 
> request ?
> 
> Demo module:
> 
> module test {
> 
> namespace "urn:test";
> 
> prefix test;
> 
> import ietf-yang-types {
> 
> prefix yang;
> 
> }
> 
> container con {
> 
> list time-range {
> 
> key "start-time";
> 
> leaf start-time {
> 
> type yang:date-and-time;
> 
> }
> 
> leaf else {
> 
> type string;
> 
> }
> 
> }
> 
> }
> 
> }
> 
> Suppose a client send a get rpc to query the /test:con 
> 
> 
> 
> 
> 
> 
> and the server reply 
> 
>   
>   
>   2022-02-01T08:00:00+08:00
>   something
>   
>   
> 
> which mean there only on list entry with key "2022-02-01T08:00:00+08:00".
> And then if the client send another get rpc with list key value 
> "2022-02-01T00:00:00Z" in subtree
> 
>   
>   
>   2022-02-01T00:00:00Z
>   
>   
> 
> shoud the server reply the list entry with key "2022-02-01T08:00:00+08:00" as 
> in the previous get rpc?
> 
>   
>   
>   2022-02-01T08:00:00+08:00
>   something
>   
>   
> 
> Although I know that according to RF6991 the date-and-time value should be 
> canolicalize, but I think it still seems a little strange for a server to 
> reply value different from the request ? 
> How the working group consider this situation? 
> Thanks.
> 
> 
> 

-- 
Jürgen Schönwälder  Constructor 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