Great thank you for update and approved for all below
Grzegorz Piotr Orchel executive director GGO Trust On Mon, 13 Jul 2026 at 15:04, Sarah Tarrant via auth48archive < [email protected]> wrote: > 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] >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
