Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
From: Sarah Tarrant <starrant@staff.rfc-editor.org>
In-Reply-To: <476f1032f39b4ed2bfe0b60b1fe461e2@huawei.com>
Date: Tue, 26 May 2026 10:36:17 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E66C4D6-97D9-4112-BB9E-A706B2FEE1A0@staff.rfc-editor.org>
References: <177948224397.17.10942712238693796264@rfc-editor.org>
 <476f1032f39b4ed2bfe0b60b1fe461e2@huawei.com>
To: "Wubo (lana)" <lana.wubo=40huawei.com@dmarc.ietf.org>
Message-ID-Hash: 4M4KKGVDWV3QWQAAMDJPZHAJ54WFAI4Z
CC: "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>,
 "dd@dhruvdhody.com" <dd@dhruvdhody.com>,
 "rrokui@ciena.com" <rrokui@ciena.com>,
 "tsaad.net@gmail.com" <tsaad.net@gmail.com>,
 "jmullool@cisco.com" <jmullool@cisco.com>,
 "ketant.ietf@gmail.com" <ketant.ietf@gmail.com>,
 "vishnupavan.ietf@gmail.com" <vishnupavan.ietf@gmail.com>,
 "james.n.guichard@futurewei.com" <james.n.guichard@futurewei.com>,
 "gunter.van_de_velde@nokia.com" <gunter.van_de_velde@nokia.com>,
 "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Precedence: list
Subject: =?utf-8?q?=5Bauth48=5D_Re=3A_Document_intake_questions_about_draft-ietf-teas?=
 =?utf-8?q?-ietf-network-slice-nbi-yang?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/auth48archive/UaCLizLaurFVFXFg_gS-RinIDi0>

Hi Bo,

Thank you for your reply.

Please go ahead and update the references and nits as you would like and =
upload the files to the datatracker as usual. However, there is no need =
to update the placeholder values at this time -- we will resolve those =
on our end.

Sincerely,
Sarah Tarrant
RFC Production Center

> On May 26, 2026, at 3:16=E2=80=AFAM, Wubo (lana) =
<lana.wubo=3D40huawei.com@dmarc.ietf.org> wrote:
>=20
> Dear RPC team,
>=20
> Thank you for adding our draft to the RFC Editor queue.=20
> On behalf of the authors, please find our response inline to the =
questions.
> We have reviewed the current version (=E2=80=9325) and confirm some =
references need updates to RFC publication and some minor nits (e.g. =
stale copyright ) need to be fixed. Should we update now or later in the =
further stage?
>=20
> Thanks,
> Bo (On behalf of the authors)
>=20
> -----Original Message-----
> From: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>=20
> Sent: Saturday, May 23, 2026 4:37 AM
> To: Wubo (lana) <lana.wubo@huawei.com>; dd@dhruvdhody.com; =
rrokui@ciena.com; tsaad.net@gmail.com; jmullool@cisco.com
> Cc: ketant.ietf@gmail.com; vishnupavan.ietf@gmail.com; =
james.n.guichard@futurewei.com; gunter.van_de_velde@nokia.com; =
rfc-editor@rfc-editor.org; auth48archive@rfc-editor.org
> Subject: Document intake questions about =
draft-ietf-teas-ietf-network-slice-nbi-yang
>=20
> Author(s),=20
>=20
> Congratulations, your document has been successfully added to the RFC =
Editor queue! =20
> The team at the RFC Production Center (RPC) is looking forward to =
working with you as your document moves forward toward publication. To =
help reduce processing time and improve editing accuracy, please respond =
to the questions below. Please confer with your coauthors (or authors of =
other documents if your document is in a
> cluster) as necessary prior to taking action in order to streamline =
communication.=20
> If your document has multiple authors, only one author needs to reply =
to this message.
>=20
> As you read through the rest of this email:
>=20
> * If you need/want to make updates to your document, we encourage you =
to make those changes and resubmit to the Datatracker. This allows for =
the easy creation of diffs, which facilitates review by interested =
parties (e.g., authors, ADs, doc shepherds).
> * If you feel no updates to the document are necessary, please reply =
with any applicable rationale/comments.
>=20
>=20
> Please note that the RPC team will not work on your document until we =
hear from you (that is, your document will remain in AUTH state until we =
receive a reply). Even if you don't have guidance or don't feel that you =
need to make any updates to the document, you need to let us know. After =
we hear from you, your document will start moving through the queue. You =
will be able to review and approve our updates during AUTH48.
>=20
> Please feel free to contact us with any questions you may have at =
rfc-editor@rfc-editor.org.
>=20
> Thank you!
> The RPC Team
>=20
> --
>=20
> 1) As there may have been multiple updates made to the document during =
Last Call, please review the current version of the document:=20
>=20
> * Is the text in the Abstract still accurate?
> * Are the Authors' Addresses, Contributors, and Acknowledgments =
sections current?
> [Bo Wu] The Abstract remains correct and consistent with the document =
body. The draft defines the ietf-network-slice-service YANG module, =
which is a customer-service model for the RFC 9543 Network Slice Service =
interface, as intended.
> And I confirmed Authors' Addresses, Contributors, and Acknowledgments =
sections current and complete.
>=20
>=20
> 2) Please share any style information that could help us with editing =
your=20
> document. For example:
>=20
> * Is your document's format or its terminology based on another =
document,=20
> WG style guide, etc.? If so, please provide a pointer to that =
information=20
> (e.g., "This document's terminology should match DNS terminology in=20
> RFC 9499." or "This document uses the style info at=20
> <https://httpwg.org/admin/editors/style-guide>.").
> * Is there a general pattern of capitalization or formatting of terms =
that=20
> editors can follow (e.g., "Field names should have initial =
capitalization."=20
> or  "Parameter names should be in double quotes." or "<tt/> should be =
used=20
> for token names." etc.)?
> [Bo Wu] This document's terminology should match Network Slice =
terminology in=20
> RFC 9543. Specifically, terms such as Network Slice Service, Service =
Demarcation Point (SDP), Connectivity Construct (CC), Service Level =
Objective (SLO), and Service Level Expectation (SLE) are defined in =
Section 3.2 and Section 5.1 of RFC 9543. This document uses "Network =
Slice Service" (without the "IETF" prefix) for brevity, as noted in =
Section 1.
>=20
> 3) Please carefully review the entries and their URLs in the
> References section with the following in mind. Note that we will=20
> update as follows unless we hear otherwise at this time:
>=20
> * References to obsoleted RFCs will be updated to point to the current=20=

> RFC on the topic in accordance with Section 4.8.6 of RFC 7322=20
> (RFC Style Guide).
>=20
> * References to I-Ds that have been replaced by another I-D will be=20
> updated to point to the replacement I-D.
> [Bo Wu] RFC 6991 is obsolete and has been replaced by: RFCRFC9911. We =
will update.
> * References to documents from other organizations that have been=20
> superseded will be updated to their superseding version.
>=20
> Note: To check for outdated RFC and I-D references, you can use=20
> idnits <https://author-tools.ietf.org/idnits>. You can also help the
> IETF Tools Team by testing idnits3 =
<https://author-tools.ietf.org/idnits3/>
> with your document and reporting any issues to them.
> [Bo Wu] We have carefully reviewed the References section and confirm =
the following:
> The draft reference draft-ietf-opsawg-teas-attachment-circuit (version =
20) is stale. It was replaced by rfc9834 (version rfc9834).
> The draft reference draft-ietf-opsawg-teas-common-ac (version 15) is =
stale. It was replaced by rfc9833 (version rfc9833).
> The draft reference draft-ietf-netmod-rfc8407bis (version 24) is =
stale. It was replaced by draft-ietf-netmod-rfc8407bis (version 28) and =
rfc9907 (version rfc9907).
> The copyright year in the IETF Trust and authors Copyright Line does =
not match the current year
> The YANG module contains a stale license declaration.
> Domain "foo.com" is not an allowed reserved domain. Use =
".example.(com|org|net)" instead.
> BCP14->BCP 14
>=20
> 4) Is there any text that requires special handling? For example:
> * Are there any sections that were contentious when the document was =
drafted?
> [Bo Wu] There are no contentious sections remaining. The document has =
completed WG Last Call, multiple directorate reviews (rtgdir, opsdir, =
secdir, tsvdir, genart), and IESG review without outstanding objections. =
All previous issues were resolved during the review process.
> * Are any sections that need to be removed before publication marked =
as such=20
> (e.g., Implementation Status sections (per RFC 7942)).
> [Bo Wu] Section 1 (Introduction) contains an "Editorial Note: (To be =
removed by RFC Editor)" that explicitly lists the placeholder =
substitutions (AAAA =E2=86=92 RFC number, BBBB =E2=86=92 RFC number, =
etc.) and the YANG module revision date update. This section must be =
removed before publication.
> There is no Implementation Status section in this document. Per RFC =
7942, this is not required.
>=20
> * Are there any instances of repeated text/sections that should be =
edited=20
> the same way?
> [Bo Wu] Except the Security Consideration, YANG module header, =
Placeholder patterns, we confirm that no other special handling is =
required.
>=20
> 5) This document contains sourcecode:=20
>=20
> * Does the sourcecode validate?
> [Bo Wu] Yes, the YANG module validates successfully.
> The document contains one primary YANG module: =
ietf-network-slice-service@2025-05-09.yang.=20
> This module has been validated using standard YANG validation tools =
(e.g., pyang, yanglint) during WG Last Call and directorate reviews and =
no validation errors are present in the final version.
>=20
> * Some sourcecode types (e.g., YANG) require certain references and/or =
text=20
> in the Security Considerations section. Is this information correct?
> [Bo Wu] The module uses placeholder values (AAAA, BBBB, CCCC, DDDD) =
for RFC numbers of documents that are part of the same cluster or =
completed publication.=20
> These are addressed in the Editorial Note. Can we resolve this now or =
later during AUTH48?=20
> AAAA --> the assigned RFC value for this draft both in this draft
>      and in the YANG models under the revision statement
> BBBB --> the assigned RFC value for
>      [I-D.ietf-opsawg-teas-common-ac] -> Published as RFC 9833
> CCCC --> the assigned RFC value for
>      [I-D.ietf-opsawg-teas-attachment-circuit] -> Published as RFC =
9834
> DDDD --> the assigned RFC value for [I-D.ietf-teas-rfc8776-update]
>=20
> For YANG-specific Security Considerations references, we confirmed =
correct and complete.
> But we need to update draft-ietf-netmod-rfc8407bis to published RFC =
9907.
>=20
> * Is the sourcecode type indicated in the XML? (See information about=20=

> types: =
https://www.rfc-editor.org/rpc/wiki/doku.php?id=3Dsourcecode-types.)
> [Bo Wu] Yes. The YANG module is properly enclosed in <CODE BEGINS> and =
<CODE ENDS>.
>=20
>=20
> 6) This document is part of Cluster 517:
> https://queue.rfc-editor.org/clusters/517/=20
>=20
> * To help the reader understand the content of the cluster, is there a=20=

> document in the cluster that should be read first? Next? If so, please =
provide=20
> the order and we will provide RFC numbers for the documents =
accordingly.=20
> If order is not important, please let us know.=20
>=20
> [Bo Wu] We recommend the following sequence for readers to understand =
the cluster:
> First: draft-ietf-opsawg-teas-common-ac (A Common YANG Data Model for =
Attachment Circuits) - RFC 9833
> This provides the foundational common AC types and groupings used by =
all other documents in the cluster.
> Second: draft-ietf-opsawg-teas-attachment-circuit (YANG Data Models =
for Bearers and 'Attachment Circuits'-as-a-Service) - RFC 9834
> This defines the AC service model, which is referenced by the Network =
Slice Service model for SDP attachment circuit bindings.
> Third: draft-ietf-teas-rfc8776-update (Common YANG Data Types for =
Traffic Engineering)
> This provides updated TE common types used by this document (e.g., =
te-types:te-path-disjointness for path diversity constraints).
> Fourth: draft-ietf-teas-ietf-network-slice-nbi-yang (this document)
> This document builds upon the models above and defines the Network =
Slice Service YANG model.
>=20
>=20
> * Is there any text that has been repeated within the cluster document =
that=20
> should be edited in the same way (for instance, parallel introductory =
text or=20
> Security Considerations)?
> [Bo Wu] Yes, there are parallel structures that should be edited =
consistently:
> Security Considerations boilerplate: RFC 9907 (Guidelines for Authors =
and Reviewers of Documents Containing YANG Data Models)
> YANG module header/footer: All modules in the cluster contain similar =
copyright notices, revision statements, and RFC Editor notes as guided =
also by RFC 9907.
> Editorial Notes: These should be removed consistently at publication =
time.
>=20
> * For more information about clusters, see:=20
> https://authors.ietf.org/en/rfc-publication-process#clusters
> * For a list of all current clusters, see:=20
> https://queue.rfc-editor.org/clusters/
>=20
>=20
> 7) Is there anything else that the RPC should be aware of while =
editing this=20
> document?
> [Bo Wu]=20
> a)This document uses four placeholder patterns that must be replaced =
consistently:
> AAAA =E2=86=92 RFC number assigned to this document
> BBBB =E2=86=92 RFC number for draft-ietf-opsawg-teas-common-ac -> =
published as RFC 9833
> CCCC =E2=86=92 RFC number for =
draft-ietf-opsawg-teas-attachment-circuit -> published as RFC 9834
> DDDD =E2=86=92 RFC number for draft-ietf-teas-rfc8776-update
> The YANG module's revision statement date (2025-05-09) and the =
reference text in the module description must also be updated to the =
final publication date
> b)And also I-D.ietf-netmod-rfc8407bis we referenced is published as =
RFC9907.
> YANG module filename:
> c)The <CODE BEGINS> tag includes the revision date in the filename =
(ietf-network-slice-service@2025-05-09.yang). If the publication date =
differs significantly, the filename in the code tag should be updated to =
match the final revision date in the module.
> d) JSON examples:Appendix B contains multiple JSON examples that use =
RFC 8792 line wrapping (indicated by \ line continuation). These are =
properly formatted and should render correctly in the final RFC