Hi Tom, Thanks for flagging this.
I agree that this text is not helpful in understanding the examples (nor is this text present in other YANG module examples), and I will indeed raise this in my ballot. Regards, Rob -----Original Message----- From: tom petch <[email protected]> Sent: 12 February 2022 12:54 To: Rob Wilton (rwilton) <[email protected]> Cc: [email protected] Subject: Re: [netmod] Use XML namespaces in YANG document examples 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
