Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

[Charles Eckel (eckelcu)]

I have reviewed this document. I believe it is in good shape and ready to 
proceed toward publication. 

Cheers,
Charles

> On Feb 3, 2022, at 6:54 PM, Kent Watsen  wrote:
> 
> Dear NETMOD WG,
> 
> This message begins a two-week WGLC for draft-ietf-netmod-rfc6991-bis-11 
> ending on Friday, February 18th.  Here is a direct link to the HTML version 
> of the draft:
> 
>   
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-11.html
> 
> 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,
> 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] WGLC on draft-ietf-netmod-rfc6991-bis-11

[Benoit Claise]

+1

B.

On 2/14/2022 11:49 PM, Mahesh Jethanandani wrote:
I have followed the discussions on this draft and believe it is ready 
for publication.




On Thursday, February 3, 2022, 09:54:23 PM EST, Kent Watsen 
 wrote:



Dear NETMOD WG,

This message begins a two-week WGLC for 
draft-ietf-netmod-rfc6991-bis-11 ending on Friday, February 18th.  
Here is a direct link to the HTML version of the draft:


https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-11.html

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


___
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 on draft-ietf-netmod-rfc6991-bis-11

[maqiufang (A)]

Hi, all
I have read the document and support the publication of this work.
I have only one comment: It seems that Table 2 doesn’t list all the types 
defined in “ietf-inet-types” YANG module, e.g., protocol-number, 
ip-address-link-local, ip-address-and-prefix… Should this be fixed?

Best Regards,
Qiufang

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
Sent: Tuesday, February 15, 2022 6:43 AM
To: Reshad Rahman 
Cc: netmod@ietf.org
Subject: Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

Thank you Reshad for your reply.

All, the WGLC is set to close in three days, but first there needs to be more 
responses…can others provide comments too?   Especially authors of other drafts 
in progress ;)

Thanks,
Kent  (and Lou)



On Feb 14, 2022, at 9:05 AM, Reshad Rahman 
mailto:res...@yahoo.com>> wrote:

I have reviewed this document, no concerns. I believe it is ready for 
publication.

Regards,
Reshad.

On Thursday, February 3, 2022, 09:54:23 PM EST, Kent Watsen 
mailto:kent+i...@watsen.net>> wrote:


Dear NETMOD WG,

This message begins a two-week WGLC for draft-ietf-netmod-rfc6991-bis-11 ending 
on Friday, February 18th.  Here is a direct link to the HTML version of the 
draft:

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-11.html

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,
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] Use XML namespaces in YANG document examples

[Ladislav Lhotka]

Andy Bierman  writes:

> On Mon, Feb 14, 2022 at 1:19 AM Jan Lindblad (jlindbla) 
> wrote:
>
>> Just to add to the complexity here, it's not only about identityrefs.
>>
>> People (including IETF) have also defined types that use qname:s inside
>> YANG strings, which the servers and clients would have to recognize and
>> treat properly in order to interoperate well.
>>
>> module ietf-yang-types {
>> ...
>>   typedef xpath1.0 {
>> type string;
>> description
>>  "This type represents an XPATH 1.0 expression.
>>
>>   When a schema node is defined that uses this type, the
>>   description of the schema node MUST specify the XPath
>>   context in which the XPath expression is evaluated.";
>> reference
>>  "XPATH: XML Path Language (XPath) Version 1.0";
>>   }
>>
>>
>
> Good point.  Not just a server implementation detail I guess.
> We had a YANG extension for this before this xpath type came out.
> https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-xpath
>
> The server implementation definitely needs to know (early in the
> processing) which strings are plain strings
> and which are XPath expressions.  Usually it is too late to get the
> namespace bindings
> after the XML parser is finished.
>
> Maybe a solution for YANG 2.0...
> Create a standard algorithm to convert QName and xpath:1.0 strings to a
> canonical format,
> using the module-name approach defined in RFC 7951.

This is not so easy, as long as a canonical value must also stay lexically 
valid in a given representation. The only reasonable (but backwards 
incompatible) solution seems to be to change the XML encoding of identityref 
values to be the same as in RFC 7951.

Lada

>
> For now, there is no real problem to solve. Supporting YANG 1.1 requires the
> implementation to be aware of XML prefixes in string node content.
> Leaf value comparisons involving strings with XML prefixes are not reliable.
> (Maybe a whole new can of worms there...)
>
>
>
>> /jan
>>
>>
> Andy
>
>
>> On 14 Feb 2022, at 10:05, Ladislav Lhotka  wrote:
>>
>> Andy Bierman  writes:
>>
>> On Sat, Feb 12, 2022 at 6:57 AM Jürgen Schönwälder <
>> j.schoenwael...@jacobs-university.de> wrote:
>>
>> I agree that this should not go forward as is.
>>
>> The XML representation of YANG instance data does indeed use QNames in
>> element values and hence applications must be able to resolve XML
>> namespace prefixes. If this is not clear enough in RFC 7950, then we
>> need to address the lack of clarity where it belongs to be addressed.
>>
>> If we were to add a warning to all (past and) future YANG modules to
>> help implementors who did not read RFC 7950, then the warning should
>> be concise ("Applications using the XML representation of YANG
>> instance data must be able to resolve XML namespace prefixes."). My
>> preference, though, is to assume that implementors read RFC 7950 when
>> they are not sure how to implement the prefixes correctly.
>>
>>
>> It seems clear that this is not an issue specific to a particular YANG
>> module,
>> so the fix needs to be an errata against RFC 7950.
>> The text in question is probably limited to the first paragraph (first
>> sentence).
>>
>> 9.10.3 .
>> Lexical Representation
>>
>>   An identityref is lexically represented as the referred identity's
>>   qualified name as defined in [XML-NAMES
>> ].  If
>> the prefix is not
>>   present, the namespace of the identityref is the default namespace
>>   in effect on the element that contains the identityref value.
>>
>>
>>
>> The problem is that XML-NAMES only applies to elements and attributes (not
>> string node content).
>>
>>
>> I looked into XSLT 2.0, sec. 5.1 [1], hoping that we could use it as a
>> model, but it became clear to me that we have a bigger problem: equality of
>> identityref values isn't properly defined in YANG. We resolved this in YANG
>> 1.1 for identityrefs appearing in XPath expressions by adding the functions
>> "derived-from" and "derived-from-or-self", but the problem still persists
>> e.g. when comparing identityref values serving as list keys (sec. 9.1 in
>> RFC 7950 doesn't help here).
>>
>> Lada
>>
>> [1] https://www.w3.org/TR/xslt20/#qname
>>
>>
>> I do not know the proper replacement text for the first sentence, but it
>> seems maybe
>> a specific definition of the expanded name for identityref:
>>
>>   The expanded name for an identityref value consists of a namespace name
>> equal
>>   to a module namespace (defined in 5.3) and a local name equal to an
>> identity identifier.
>>   The reffered identity is defined within the module bound to the module
>> namespace
>>   value.
>>
>>
>>
>> /js
>>
>>
>>
>>
>> Andy
>>
>>
>>
>> On Sat, Feb 12, 2022 at 12:54:18PM +, tom petch wrote:
>>
>> Going back to the original issue and so top-posting.
>>
>> NSF Monitoring Interface YANG Data Model
>> is