Hi Sarah,
On 7/9/26 4:54 PM, Sarah Tarrant wrote:
Hi Vladimir,
What appears in A.4 would typically be marked as <sourcecode type=“xml”>. Also, what
appears in Sections 2.4, 2.5, 3, and 4 would typically be marked as <sourcecode
type=“yang”>. Marking them as such allows users/readers to easily extract the
sourcecode from the RFC(s). Please note that Section 3.12 of RFC 9907 seems to recommend
marking examples as code.
Please review and let us know if you have strong objections.
Do you want me to make -18 version with these changes? I can use
<sourcecode type="pseudocode"> for the examples.
As for the YANG modules and the XML serialization I have no objections
if this is the latest recommendation. As noted RFC7223 was used as
template and the current version is consistent with
https://www.ietf.org/archive/id/draft-ietf-netmod-rfc7223bis-03.xml
where only <artwork><![CDATA[ was used for YANG modules and XML
serialization. By the way rfcstrip correctly detects the YANG modules
and extracts them from -17
Is there a more recent RFC that is consistent with your recommendation
just so we can use it instead?
/V
Thank you,
Sarah Tarrant
RFC Production Center
On Jul 9, 2026, at 1:12 AM, Vladimir Vassilev
<[email protected]> wrote:
Hi Sarah,
A.1, A.2, A.3 are the pseudocode examples.
A.4 is XML. But you should not change that to <sourcecode> since it is not source. Seems the other
drafts/RFCs we used for template/reference specifying YANG data model defined NETCONF PDUs also use
"<artwork><![CDATA[" for that.
/V
On 7/8/26 7:21 PM, Sarah Tarrant wrote:
Hi Vladimir,
Thank you for your reply!
Regarding the pseudocode, the XML files shows all code elements inside
<sourcecode> tags, so it is difficult to determine which ones (besides the
obvious artwork elements) are yang, xml, or pseudocode. Could you further clarify
which type should be set for each of the following sourcecode elements? (I've
included the section number and the first line to help.)
Section 2.4: module: ietf-traffic-generator
Section 2.5: module: ietf-traffic-analyzer
Section 3: module ietf-traffic-generator
Section 4: module ietf-traffic-analyzer
Section A.1: # Connect to network
Section A.2: net.node("tester1").edit(
Section A.3: net.node("tester1").edit(
Section A.4: <rpc-reply
Sincerely,
Sarah Tarrant
RFC Production Center
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
