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