Hi Vladimir, Noted! We'll move this to the formatting stage.
Thank you, Sarah Tarrant RFC Production Center > On Jul 12, 2026, at 3:04 PM, Vladimir Vassilev > <[email protected]> wrote: > > On 7/10/26 10:15 PM, Sarah Tarrant wrote: > >> Hi Vladimir, >> >> No need for a new version -- we're happy to update the files on our end, >> with your permission. >> >> A more recent sourcecode type="xml" example can be found in Section >> 2.1.1.3.2 of RFC 9684 (see the xml source). >> >> As for the elements in Section 2.4, 2.5, 3, and 4, may we update those to >> sourcecode type="yang"? > > > OK. Seems RFC9684 XML uses <sourcecode type="yangtree"> which is relevant > for the 2.4 and 2.5 sections. > > /V > > >> >> Thank you, >> Sarah Tarrant >> RFC Production Center >> >>> On Jul 10, 2026, at 5:05 AM, Vladimir Vassilev >>> <[email protected]> wrote: >>> >>> 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]
