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