On Mon, Feb 14, 2022 at 1:19 AM Jan Lindblad (jlindbla) <[email protected]>
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.
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 <[email protected]> wrote:
>
> Andy Bierman <[email protected]> writes:
>
> On Sat, Feb 12, 2022 at 6:57 AM Jürgen Schönwälder <
> [email protected]> 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 <https://datatracker.ietf.org/doc/html/rfc7950#section-9.10.3>.
> Lexical Representation
>
> An identityref is lexically represented as the referred identity's
> qualified name as defined in [XML-NAMES
> <https://datatracker.ietf.org/doc/html/rfc7950#ref-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 +0000, tom petch wrote:
>
> Going back to the original issue and so top-posting.
>
> NSF Monitoring Interface YANG Data Model
> is on the IESG Telechat 17feb2022.
>
> It contains the text - not an easy read unless you are an XML expert -
> "In order for the XML
> data to be used correctly, the prefix (i.e., the characters before
> the colon or 'nsfmi' in the example) in the content of the element
> that uses the "identityref" type (e.g., /i2nsf-event/i2nsf-system-
> detection-alarm/alarm-category/) in the YANG module described in this
> document MUST be the same as the namespace prefix (i.e., 'nsfmi' in
> the example) for urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-
> monitoring. Therefore, XML software MUST be chosen that makes the
> namespace prefix information available."
>
> This is the result of discussions between IANA and the XML directorate,
>
> which I have seen copied to the WG list, and seems to me to be in direct
> contradiction of the consensus of the NETMOD WG list as shown in the
> discussions this month on this thread over the DHCP I-D and a separate
> thread on the I2NSF I-D in January and is likely to be a source of
> confusion for the future.
>
>
> NSF-Facing Interface YANG Data Model
> is on the same Telechat but I do not see the same text.
>
> I would like an AD to throw a flag, in the shape of a DISCUSS so I am
>
> copying Robert.
>
>
> My take is that the text should not be included in any I-D based on the
>
> consensus of the NETMOD WG (as I perceive it). One suggestion was that it
> needed an update to RFC7950 to make it justified.
>
>
> (Also, my rant of 2022, these late stage non-WG interventions should not
>
> be over-riding the WG discussions but that is not going to change any time
> soon).
>
>
> Tom Petch
> ________________________________________
> From: netmod <[email protected]> on behalf of tom petch <
>
> [email protected]>
>
> Sent: 11 February 2022 17:03
>
> From: Carsten Bormann <[email protected]>
> Sent: 11 February 2022 08:21
>
> (I’m also still not sure I’ve got an answer to my question about
>
> using inconsistent prefixes between YANG and the XML example. What is
> being demonstrated here?)
>
>
> <tp>
> If you are referring to
> " Is there a reason to violate the SHOULD?"
>
>
> I’m referring to the question I was trying to ask when I said this :-)
>
> I did not see that as related to the thread but thought it was
>
> answered anyway by Juergen. As he said, the SHOULD gets violated when
> prefix clash which, in the absence of a registry, a namespace, for prefix
> is possible.
>
>
> Yes, and thanks to him for answering my question as a general question.
>
> I was answering to a throwaway note that the authors got flak when their
>
> XML did not use the defined prefix. My question was: why do that, then?
> Maybe that was not understood because “ianaift” actually *is* the prefix
> preferred in the YANG module, so my question doesn’t make sense. (I’m not
> sure what the throwaway referred to.)
>
>
> <tp>
>
> Try again.
>
> I have commented a number of times on a YANG import which defines a
>
> prefix other than that in the RFC. Last month, it was
>
> import ietf-hardware {
> prefix ietfhw;
> Usually, when I comment on this, the authors accept my comment and
>
> change the prefix - they did on this occasion - but sometimes I get
> pushback along the lines that YANG Guidelines is only a 'SHOULD' and we
> think that we have a good reason to ignore the 'SHOULD' . To date, I have
> never agreed with the reason and go on commenting:-) If that is flack,
> then yes, I have - and will - generate flack:-)
>
>
> Tom Petch
>
>
> Grüße, Carsten
>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
>
> --
> Jürgen Schönwälder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
