[auth48] Re: [IANA #1456011] [IANA] Re: Final Review: RFC-to-be 10016 (draft-ietf-netmod-system-config) in XML
Alanna Paloma <apaloma@staff.rfc-editor.org> Wed, 22 July 2026 20:36 UTC
Return-Path: <apaloma@staff.rfc-editor.org>
X-Original-To: auth48archive@mail2.ietf.org
Delivered-To: auth48archive@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id A917011CBC779 for <auth48archive@mail2.ietf.org>; Wed, 22 Jul 2026 13:36:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784752593; bh=GwGKSWWwrWCkhKx42JWw8nKaK+GnyggyJP00ZyVvL38=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=I57j+M8+5Z+ubdKdR0fp756Ba8r9cVqV2FQJCxzOfMOk+zo9JBWu2HhrQj6wp6fVZ L4Qu1WV9uO/Nr9xvkaD3ZuzqGzIJLDFCJZNE8ocXKDEQFEnlwxj/NczbK/A4g4PfNN 4s51VNC3ad5zyI/TphBphSbPjKBNh4+90Vx4qyP0=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=staff-rfc-editor-org.20251104.gappssmtp.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpVY4AizJ-nQ for <auth48archive@mail2.ietf.org>; Wed, 22 Jul 2026 13:36:33 -0700 (PDT)
Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id DB07211CBC724 for <auth48archive@rfc-editor.org>; Wed, 22 Jul 2026 13:36:24 -0700 (PDT)
Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-81eaf3709b4so109477007b3.0 for <auth48archive@rfc-editor.org>; Wed, 22 Jul 2026 13:36:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=staff-rfc-editor-org.20251104.gappssmtp.com; s=20251104; t=1784752578; x=1785357378; darn=rfc-editor.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:content-type:from:to:cc :subject:date:message-id:reply-to:content-type; bh=s9A1gx9J6f7feprNHXJKQ3L0SjACURT/xegDWcititM=; b=ABxVnC5NpY6wgjt1K3CrL4Lg+uZ0d64bbsHScNhi/MDWc6mZiV5sXG5WAaIYKDU02B cvaPzUwwsK6bMsnieR6t7OOhjVFGrX7ewMpsLjUubpwSAQKXlU8ZYqWdlc3cIO1Baksm by8xuGZHLkmAY7wdPuz2zXRYLLP9qR7+X0tqFyA+fPtBNQWz07pCLIL+LAEze1JMGHj0 IUZzHPhLqtIh4qM9y5xNzjOUqCo2rWrV6gx/nQZjlv9tQuQHSe+K8c7TJ7K1b/ZoFxHV vrEuJfkvY7K7CWrscegWkyCcZGclATRIaPOplN727T2YxZvB0SRBQP5SPLZQrxDDVJsB 3Uog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784752578; x=1785357378; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:content-type:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=s9A1gx9J6f7feprNHXJKQ3L0SjACURT/xegDWcititM=; b=fpQuS+qBZyAhlPmXQSnZth/g6YSFf7hvFBIRgz/1NIN30VfR2o/pTPHyb+eH3t4Vt5 yGrFhrgZnYxeKx89e9DOp3tMLoB3FHe9d0m0C3OTMuUMd1odwi2aSDNTx7APF/cjljpi 46VD13B/HeH3KJ7SAgRwiZumMtXWrZtFKPDjAO8ejgU5wIlkMjFwSYzF8sHCX6+pQy6/ 7aTpEwmrrRf0t9Ej88p2xInfkrXiTu9pLsRf+BbzG1bqTDS3F2H3vWw/dv49/KqMtaXZ 3PDDBp8gWKgWZXxsm+8CgCmbtm9xOqa8JwYH7GxkzoKqpQKtvzNsc8ZIrf9FCzAHQD0L dUfQ==
X-Forwarded-Encrypted: i=1; AHgh+Ro3bd5429WZwCwOR0gS7CHw6i/yIjuXzSz0VZcQPiRUwyxB9+kpmrvb22imVE/ES73aItfXoxdGx9XVV+ru@rfc-editor.org
X-Gm-Message-State: AOJu0YxJtrVRqdpTpYGA+IY8J0nJZo/hIpt/dghSrLt280rUQHv2JPk/ xm8UeXtsx69yK8bhDwFwFi080I8aMsrIHdMJHH5UvGhfNLtI19lev4YM7qsb6dgyFfXh1A==
X-Gm-Gg: AR+sD12Ihh13HbkfnnVifxFb7E7ij6/4ZGIuA/vMYm7usliEPX/3zqYVgfhAdnTGY6t zaBHqmLox8lsD0bZuDAOWHRLdsQFUiR3ZceIoC6xtFf3BXzWjNiC1wFsihWYAQjQikssYMKcB3p z8TlWV/B0h04MMamfzWXTHOcmAVXX/2k6RGTJTVeHYOaa3iiEHjRJqj4Mwkdj3CA044yFoCRilO +7isViWWZMRujJCjy7d+j69UzM3b7hApyvn8fETJKSdiUEGhbiC3w5xFzmOhoCQZ0RiTDR7x0XD i9Oh9MTKhNxaB4uV9Do7eTjnjO+i418wH0wpFlKiKAjH7tSmTYRQz2HbNxEesTzwn5masBMPHdP hR3XBSuOdEwT4VNNSFvr4BsLUt+oS0nThbHEvh0vsGToQM3rktOjTlB3UwWB+QXFYHGWngEh+Ck Ac0U5Jt02EINHggLHca80DHzAeBIGyv1PdOGDIL7qa
X-Received: by 2002:a05:690c:c509:b0:81e:5f38:b20e with SMTP id 00721157ae682-81f4c13dc70mr627287b3.6.1784752577983; Wed, 22 Jul 2026 13:36:17 -0700 (PDT)
Received: from smtpclient.apple ([2600:1700:fad0:24f0:19b0:f5b4:e08c:5175]) by smtp.gmail.com with ESMTPSA id 00721157ae682-81f33c6432csm19262277b3.20.2026.07.22.13.36.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jul 2026 13:36:17 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
From: Alanna Paloma <apaloma@staff.rfc-editor.org>
In-Reply-To: <rt-5.0.3-583668-1784751154-677.1456011-37-0@icann.org>
Date: Wed, 22 Jul 2026 13:35:54 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <E0F8B169-08B0-4065-A33B-D2E6C4A195E7@staff.rfc-editor.org>
References: <RT-Ticket-1456011@icann.org> <178338089143.13.8535512300281727431@rfc-editor.org> <F22BAB29-BFD7-48A4-BF03-31D19C1C35E9@gmail.com> <4EDA71D9-49B5-46D0-8677-DFFA4EDB2B5C@staff.rfc-editor.org> <C68B0429-ADC9-47E8-A5D2-7310BED5FE12@staff.rfc-editor.org> <rt-5.0.3-583668-1784751154-677.1456011-37-0@icann.org>
To: iana-matrix@iana.org
X-Mailer: Apple Mail (2.3774.400.31)
Message-ID-Hash: GGHXGVKF2ZBH5ZI5HUQZYIBSOL3AAQFK
X-Message-ID-Hash: GGHXGVKF2ZBH5ZI5HUQZYIBSOL3AAQFK
X-MailFrom: apaloma@staff.rfc-editor.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Mahesh Jethanandani <mjethanandani@gmail.com>, Qin Wu <bill.wu@huawei.com>, fengchonglly@gmail.com, RFC Editor <rfc-editor@rfc-editor.org>, "maqiufang (A)" <maqiufang1@huawei.com>, auth48archive <auth48archive@rfc-editor.org>, ops-ads@ietf.org, Kent Watsen <kent+ietf@watsen.net>, netmod-chairs@ietf.org, "mohamed.boucadair" <mohamed.boucadair@orange.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [auth48] Re: [IANA #1456011] [IANA] Re: Final Review: RFC-to-be 10016 (draft-ietf-netmod-system-config) in XML
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/ORYxMyNcpcJzNmsMohmucCfv5P8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Owner: <mailto:auth48archive-owner@rfc-editor.org>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Subscribe: <mailto:auth48archive-join@rfc-editor.org>
List-Unsubscribe: <mailto:auth48archive-leave@rfc-editor.org>
Hi David. No worries! The update looks good. Thank you! Alanna Paloma RFC Production Center > On Jul 22, 2026, at 1:12 PM, David Dong via RT <iana-matrix@iana.org> wrote: > > Hi Alanna, > > Apologies for the delay on this. We've made the update: > > URI: urn:ietf:params:xml:ns:yang:ietf-system-datastore > Registrant Contact: The IESG > XML: N/A; the requested URIs are XML namespaces. > > https://www.iana.org/assignments/xml-registry/ns/yang/ietf-system-datastore.txt > > Thanks! > > Best regards, > > David Dong > IANA Services Sr. Specialist > > On Wed Jul 15 21:04:41 2026, apaloma@staff.rfc-editor.org wrote: >> IANA, >> >> Please make this minor punctuation update in the Registrant Contact >> field for this XML namespace URI in the “ns” registry at >> <https://www.iana.org/assignments/xml-registry/ns/yang/ietf-system- >> datastore.txt>. >> >> Old: >> URI: urn:ietf:params:xml:ns:yang:ietf-system-datastore >> Registrant Contact: The IESG. >> >> New: >> URI: urn:ietf:params:xml:ns:yang:ietf-system-datastore >> Registrant Contact: The IESG >> >> Best regards, >> Alanna Paloma >> RFC Production Center >> >>> On Jul 15, 2026, at 12:51 PM, Alanna Paloma <apaloma@staff.rfc- >>> editor.org> wrote: >>> >>> Hi Chong, Qin, and Mahesh*, >>> >>> Thank you for your approvals. They’ve been noted here: >>> https://queue.rfc-editor.org/final-review/rfc10016/ >>> >>> *Mahesh - We have updated the text per your suggestion. As you noted >>> that more changes to the template are actively being discussed, we >>> will hold publication of this document until we hear further from >>> you. >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc10016.xml >>> https://www.rfc-editor.org/authors/rfc10016.txt >>> https://www.rfc-editor.org/authors/rfc10016.html >>> https://www.rfc-editor.org/authors/rfc10016.pdf >>> >>> The relevant diff files have been posted here: >>> https://www.rfc-editor.org/authors/rfc10016-diff.html (comprehensive >>> diff) >>> https://www.rfc-editor.org/authors/rfc10016-auth48diff.html (Final >>> Review changes) >>> https://www.rfc-editor.org/authors/rfc10016-auth48rfcdiff.html >>> (Final Review changes side by side) >>> https://www.rfc-editor.org/authors/rfc10016-lastdiff.html (last >>> version to this one) >>> https://www.rfc-editor.org/authors/rfc10016-lastrfcdiff.html (rfcdiff >>> between last version and this) >>> >>> Best regards, >>> Alanna Paloma >>> RFC Production Center >>> >>>> On Jul 15, 2026, at 10:42 AM, Mahesh Jethanandani >>>> <mjethanandani@gmail.com> wrote: >>>> >>>> Hi Alanna, >>>> >>>> I have looked at the changes you have made for question #5. Most of >>>> the changes look good to me. However, there is more change that we >>>> have to make (and something that I need to update the wiki also >>>> with) is the following: >>>> >>>> In the second paragraph, the template text is getting updated to say >>>> the following. Note, this is still being debated, and we can expect >>>> some more changes to the text. >>>> >>>> >>>> OLD: >>>> (1) have to use a secure transport layer (e.g., Secure Shell (SSH) >>>> [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use >>>> mutual authentication. >>>> >>>> NEW: >>>> >>>> (1) have to use a secure transport layer and (2) have to use >>>> mutual authentication (e.g., Secure Shell (SSH) [RFC4252], >>>> TLS [RFC8446], and QUIC [RFC9000]). >>>> >>>>> On Jul 6, 2026, at 4:34 PM, rfc-editor@rfc-editor.org wrote: >>>>> >>>>> Authors and *AD, >>>>> >>>>> While reviewing this document during Final Review, please resolve >>>>> (as necessary) the following questions, which are also in the >>>>> source file. >>>>> >>>>> *AD, please review question #5 below. >>>>> >>>>> >>>>> 1) <!--[rfced] We note that most of the recently published RFCs >>>>> containing YANG modules format their titles as "A YANG Data Model >>>>> for...", for example: >>>>> >>>>> RFC 9094 - A YANG Data Model for Wavelength Switched Optical >>>>> Networks (WSONs) >>>>> RFC 9093 - A YANG Data Model for Layer 0 Types >>>>> RFC 9067 - A YANG Data Model for Routing Policy >>>>> >>>>> Please consider whether the title of this document should be >>>>> updated. >>>>> >>>>> Current: >>>>> System-Defined Configuration >>>>> >>>>> Perhaps: >>>>> A YANG Data Model for System-Defined Configuration >>>>> --> >>>>> >>>>> >>>>> 2) <!--[rfced] Per guidance from Section 2 of RFC 8340, we moved >>>>> the >>>>> lines in the YANG tree diagram (in Section 7.1) over two spaces >>>>> to the left. Please review and let us know of any objections. >>>>> --> >>>>> >>>>> >>>>> 3) <!--[rfced] Because XML examples are present in this document, >>>>> we >>>>> added a citation to W3C in Section 7.3 and a corresponding entry >>>>> under the Informative References section. Please let us know if >>>>> this is agreeable or if you prefer otherwise. >>>>> >>>>> Original: >>>>> The following example shows how the configuration in <system> >>>>> could >>>>> be retrieved in a NETCONF <get-data> RPC operation. The example >>>>> uses >>>>> the "example-application" fictional data model defined in >>>>> Appendix A.1. >>>>> >>>>> Current: >>>>> The following example shows how the configuration in <system> could >>>>> be retrieved in a NETCONF <get-data> RPC operation. The example >>>>> uses XML [W3C.XML1.0] and the "example-application" fictional data >>>>> model defined in Appendix A.1. >>>>> --> >>>>> >>>>> >>>>> 4) <!--[rfced] FYI - In Section 7.3, note that we moved the example >>>>> over >>>>> three spaces to the left because >>>>> "xmlns:sysds="urn:ietf:params:xml:ns:yang:ietf-system-datastore">" >>>>> was 3 characters over the limit. >>>>> --> >>>>> >>>>> >>>>> 5) <!--[rfced] *[AD] We have altered some text in the Security >>>>> Considerations section to match the boilerplate text at >>>>> <https://wiki.ietf.org/group/ops/yang-security-guidelines>. Also >>>>> note that paragraph 4 varies from the template (we attempted to >>>>> make it match more closely). Please review and let us know if any >>>>> further updates are needed or if the text is agreeable as is. >>>>> --> >>>>> >>>>> >>>>> 6) <!--[rfced] Note that the YANG module examples have been updated >>>>> per >>>>> the formatting option of pyang. Please let us know any concerns. >>>>> >>>>> a) example-application has been updated as follows: >>>>> >>>>> prefix "ex-app" -> prefix ex-app >>>>> prefix "inet" -> prefix inet >>>>> >>>>> b) example-acl has been updated as follows: >>>>> >>>>> prefix "ex-acl" -> prefix ex-acl >>>>> prefix "ex-app" -> prefix ex-app >>>>> prefix "inet" -> prefix inet >>>>> >>>>> c) example-interface has been updated as follows: >>>>> >>>>> prefix "ex-if" -> prefix ex-if >>>>> prefix "inet" -> prefix inet >>>>> key name -> key "name" >>>>> >>>>> d) example-interface-management has been updated as follows: >>>>> >>>>> prefix "ex-ifm" -> prefix ex-ifm >>>>> prefix "inet" -> prefix inet >>>>> --> >>>>> >>>>> >>>>> 7) <!--[rfced] We note that the following system configuration >>>>> terms are >>>>> hyphenated. Are these specific terms that should always appear >>>>> hyphenated? We are confirming because adverbs ending in "ly" are >>>>> not typically hyphenated in the RFC Series, and we could not find >>>>> the hyphenated forms of these terms in past RFCs. >>>>> >>>>> If the hyphens are not essential, we would remove them from >>>>> "immediately-present" and "conditionally-present", and we would >>>>> hyphenate "always present" only when in attributive position >>>>> (i.e., when followed by a noun). Please let us know your >>>>> preference. >>>>> >>>>> always-present >>>>> conditionally-present >>>>> immediately-present >>>>> --> >>>>> >>>>> >>>>> 8) <!-- [rfced] FYI - We have added expansions for the following >>>>> abbreviations per Section 3.6 of RFC 7322 ("RFC Style >>>>> Guide"). Please review each expansion in the document carefully >>>>> to ensure correctness. >>>>> >>>>> Access Control List (ACL) >>>>> Network Configuration Protocol (NETCONF) >>>>> --> >>>>> >>>>> >>>>> 9) <!-- [rfced] Please review the "Inclusive Language" portion of >>>>> the online >>>>> Style Guide <https://www.rfc- >>>>> editor.org/styleguide/part2/#inclusive_language> >>>>> and let us know if any changes are needed. Updates of this nature >>>>> typically >>>>> result in more precise language, which is helpful for readers. >>>>> >>>>> Note that our script did not flag any words in particular, but this >>>>> should >>>>> still be reviewed as a best practice. >>>>> --> >>>>> >>>>> >>>>> Thank you. >>>>> >>>>> Alanna Paloma and Karen Moore >>>>> RFC Production Center >>>>> >>>>> >>>>> On Jul 6, 2026, at 4:24 PM, rfc-editor@rfc-editor.org wrote: >>>>> >>>>> *****IMPORTANT***** >>>>> >>>>> RFC Author(s): >>>>> -------------- >>>>> >>>>> Final Review for RFC-to-be 10016 <draft-ietf-netmod-system-config> >>>>> >>>>> Your document is now available for Final Review (previously >>>>> AUTH48). Once it has been >>>>> reviewed and approved by you and all coauthors, it will be >>>>> published as an RFC. >>>>> If an author is no longer available, there are several remedies; >>>>> see the Unavailable Authors section >>>>> (https://authors.ietf.org/rfc-publication-process#unavailable- >>>>> authors). >>>>> >>>>> You and you coauthors are responsible for engaging other parties >>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>> your approval. >>>>> >>>>> Planning your review >>>>> --------------------- >>>>> >>>>> Please review the following aspects of your document: >>>>> >>>>> * RFC Editor questions >>>>> >>>>> Please review and resolve any questions raised by the RFC Editor >>>>> that have been included in the XML file as comments marked as >>>>> follows: >>>>> >>>>> <!-- [rfced] ... --> >>>>> >>>>> These questions will also be sent in a subsequent email. >>>>> >>>>> * Changes submitted by coauthors >>>>> >>>>> Please ensure that you review any changes submitted by your >>>>> coauthors. We assume that if you do not speak up that you >>>>> agree to changes submitted by your coauthors. >>>>> >>>>> * Content >>>>> >>>>> Please review the full content of the document, as this cannot >>>>> change once the RFC is published. Please pay particular attention >>>>> to: >>>>> - IANA considerations updates (if applicable) >>>>> - contact information >>>>> - references >>>>> >>>>> * Copyright notices and legends >>>>> >>>>> Please review the copyright notice and legends as defined in >>>>> RFC 5378 and the Trust Legal Provisions >>>>> (TLP – https://trustee.ietf.org/license-info) >>>>> >>>>> * Semantic markup >>>>> >>>>> Please review the markup in the XML file to ensure that elements of >>>>> content are correctly tagged. For example, ensure that >>>>> <sourcecode> >>>>> and <artwork> are set correctly. See details at >>>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>>> >>>>> * Formatted output >>>>> >>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>> formatted output, as generated from the markup in the XML file, is >>>>> reasonable. Please note that the TXT will have formatting >>>>> limitations compared to the PDF and HTML. >>>>> >>>>> >>>>> Submitting changes >>>>> ------------------ >>>>> >>>>> To submit changes, please reply to this email using 'REPLY ALL' as >>>>> all >>>>> the parties CCed on this message need to see your changes. The >>>>> parties >>>>> include: >>>>> >>>>> * your coauthors >>>>> >>>>> * rfc-editor@rfc-editor.org (the RPC team) >>>>> >>>>> * other document participants, depending on the stream (e.g., >>>>> IETF Stream participants are your working group chairs, the >>>>> responsible ADs, and the document shepherd). >>>>> >>>>> * auth48archive@rfc-editor.org, which is an archival mailing list >>>>> to preserve discussion about the document while in the RPC >>>>> editorial >>>>> queue; it is not an active discussion list: >>>>> >>>>> * More info: >>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh- >>>>> 4Q9l2USxIAe6P8O4Zc >>>>> >>>>> * The archive itself: >>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>> >>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>> of the archiving of messages (e.g., to discuss a sensitive >>>>> matter). >>>>> If needed, please add a note at the top of the message that you >>>>> have dropped the address. When the discussion is concluded, >>>>> auth48archive@rfc-editor.org will be re-added to the CC list and >>>>> its addition will be noted at the top of the message. >>>>> >>>>> You may submit your changes in one of two ways: >>>>> >>>>> An update to the provided XML file >>>>> — OR — >>>>> An explicit list of changes in this format >>>>> >>>>> Section # (or indicate Global) >>>>> >>>>> OLD: >>>>> old text >>>>> >>>>> NEW: >>>>> new text >>>>> >>>>> You do not need to reply with both an updated XML file and an >>>>> explicit >>>>> list of changes, as either form is sufficient. >>>>> >>>>> We will ask a stream manager to review and approve any changes that >>>>> seem >>>>> beyond editorial in nature, e.g., addition of new text, deletion of >>>>> text, >>>>> and technical changes. Information about stream managers can be >>>>> found in >>>>> the FAQ. Editorial changes do not require approval from a stream >>>>> manager. >>>>> >>>>> >>>>> Approving for publication >>>>> -------------------------- >>>>> >>>>> To approve your RFC for publication, please reply to this email >>>>> stating >>>>> that you approve this RFC for publication. Please use 'REPLY ALL', >>>>> as all the parties CCed on this message need to see your approval. >>>>> >>>>> >>>>> Files >>>>> ----- >>>>> >>>>> The files are available here: >>>>> https://www.rfc-editor.org/authors/rfc10016.xml >>>>> https://www.rfc-editor.org/authors/rfc10016.html >>>>> https://www.rfc-editor.org/authors/rfc10016.pdf >>>>> https://www.rfc-editor.org/authors/rfc10016.txt >>>>> >>>>> Diff file of the text: >>>>> https://www.rfc-editor.org/authors/rfc10016-diff.html >>>>> https://www.rfc-editor.org/authors/rfc10016-rfcdiff.html (side by >>>>> side) >>>>> >>>>> Diff of the XML: >>>>> https://www.rfc-editor.org/authors/rfc10016-xmldiff1.html >>>>> >>>>> >>>>> Tracking progress >>>>> ----------------- >>>>> >>>>> Details on the status of your Final Review are here: >>>>> https://queue.rfc-editor.org/final-review/rfc10016/ >>>>> >>>>> Please let us know if you have any questions. >>>>> >>>>> Thank you for your cooperation, >>>>> >>>>> RFC Editor >>>>> >>>>> -------------------------------------- >>>>> RFC 10016 (draft-ietf-netmod-system-config) >>>>> >>>>> Title : System-defined Configuration >>>>> Author(s) : Q. Ma, Ed., >>>>> Q. Wu, >>>>> C. Feng >>>>> WG Chair(s) : Kent Watsen, Lou Berger >>>>> Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani >>>> >>>> >>>> Mahesh Jethanandani >>>> mjethanandani@gmail.com >>>> >>>> >>>> >>>> >>>> >>>> >>> >
- [auth48] Final Review: RFC-to-be 10016 (draft-iet… rfc-editor
- [auth48] [AD] Re: Final Review: RFC-to-be 10016 (… rfc-editor
- [auth48] Re: [AD] Re: Final Review: RFC-to-be 100… maqiufang (A)
- [auth48] Re: [AD] Final Review: RFC-to-be 10016 (… Alanna Paloma
- [auth48] Re: [AD] Final Review: RFC-to-be 10016 (… maqiufang (A)
- [auth48] Re: [AD] Final Review: RFC-to-be 10016 (… Alanna Paloma
- [auth48] Re: [AD] Final Review: RFC-to-be 10016 (… maqiufang (A)
- [auth48] Re: [AD] Final Review: RFC-to-be 10016 (… Alanna Paloma
- [auth48] Re: [AD] Final Review: RFC-to-be 10016 (… maqiufang (A)
- [auth48] Re: [AD] Final Review: RFC-to-be 10016 (… Alanna Paloma
- [auth48] Re: [AD] Final Review: RFC-to-be 10016 (… chong feng
- [auth48] Re: [AD] Final Review: RFC-to-be 10016 (… Mahesh Jethanandani
- [auth48] Re: [AD] Final Review: RFC-to-be 10016 (… Alanna Paloma
- [auth48] [IANA] Re: Final Review: RFC-to-be 10016… Alanna Paloma
- [auth48] [IANA #1456011] [IANA] Re: Final Review:… David Dong via RT
- [auth48] Re: [IANA #1456011] [IANA] Re: Final Rev… Alanna Paloma
- [auth48] Re: [AD] Final Review: RFC-to-be 10016 (… Qin Wu