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.
/js
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
