Dear Karen,





Thank you for the updates. Current form looks good to me and I agree we can 
proceed with the publication process.





Best Regards,


Liyan









----邮件原文----发件人:Karen Moore  <kmo...@staff.rfc-editor.org>收件人:"chen.ran" 
<chen....@zte.com.cn>,"zhao.detao" <zhao.de...@zte.com.cn>,ppsenak 
<ppse...@cisco.com>,gongliyan <gongli...@chinamobile.com>,"ketant.ietf" 
<ketant.i...@gmail.com>抄 送: RFC Errata System  
<rfc-edi...@rfc-editor.org>,lsr-ads <lsr-...@ietf.org>,lsr-chairs 
<lsr-cha...@ietf.org>,Acee Lindem  <acee.i...@gmail.com>,"Gunter van de Velde 
(Nokia)" <gunter.van_de_ve...@nokia.com>,RFC Editor via auth48archive  
<auth48archive@rfc-editor.org>发送时间:2025-05-24 03:54:46主题:Re: [auth48] AUTH48: 
RFC-to-be 9792<draft-ietf-lsr-ospf-prefix-extended-flags-07> for your 
reviewDear Ran,Thank you for your quick reply! We have updated our files 
accordingly. Please review the changes and let us know if any further updates 
are needed or if you approve the document in its current form. Note that we 
will await approvals from each author prior to moving forward with the 
publication process.—FILES— The updated XML file is here: 
https://www.rfc-editor.org/authors/rfc9792.xmlThe updated output files are 
here: https://www.rfc-editor.org/authors/rfc9792.txt 
https://www.rfc-editor.org/authors/rfc9792.pdf 
https://www.rfc-editor.org/authors/rfc9792.htmlThese diff files show all 
changes made during AUTH48: 
https://www.rfc-editor.org/authors/rfc9792-auth48diff.html 
https://www.rfc-editor.org/authors/rfc9792-auth48rfcdiff.html (side by 
side)These diff files show all changes made to date: 
https://www.rfc-editor.org/authors/rfc9792-diff.html 
https://www.rfc-editor.org/authors/rfc9792-rfcdiff.html (side by side)Note that 
it may be necessary for you to refresh your browser to view the most recent 
version. Please review the document carefully to ensure satisfaction as we do 
not make changes once it has been published as an RFC.For the AUTH48 status of 
this document, please see: https://www.rfc-editor.org/auth48/rfc9792Best 
regards,RFC Editor/kc> On May 23, 2025, at 2:30 AM, ranchen via auth48archive  
wrote:> > Hi RFC Editor, > > > > Sorry, a typo correction,please see point 5) 
(b)> > > > Many thanks!> > Ran> > > > Original> From: 陈然00080434> To: 
rfc-edi...@rfc-editor.org > Cc: 赵德涛10132546ppse...@cisco.com 
ketant.i...@gmail.com gongli...@chinamobile.com rfc-edi...@rfc-editor.org 
lsr-...@ietf.org lsr-cha...@ietf.org acee.i...@gmail.com 
gunter.van_de_ve...@nokia.com auth48archive@rfc-editor.org > Date: 2025年05月23日 
17:13> Subject: Re: AUTH48: RFC-to-be 9792  for your review> Hi RFC Editor, > > 
Thanks for this mail. Please find my replies inline. > > > > > > From: 
rfc-edi...@rfc-editor.org > To: 陈然00080434赵德涛10132546ppse...@cisco.com 
ketant.i...@gmail.com gongli...@chinamobile.com > Cc: rfc-edi...@rfc-editor.org 
lsr-...@ietf.org lsr-cha...@ietf.org acee.i...@gmail.com 
gunter.van_de_ve...@nokia.com auth48archive@rfc-editor.org > Date: 2025年05月23日 
07:00> Subject: Re: AUTH48: RFC-to-be 9792  for your review> Authors,> > While 
reviewing this document during AUTH48, please resolve (as necessary) the 
following questions, which are also in the XML file.> > 1)  > I suggest:Prefix 
attributes;IGP> > > > 2) Yes, that change looks good.  > > > 3) You are 
correct. The intended references were mistakenly reversed. > > > 4) Yes, it 
still need to be added. Please add: The entry in the "L2BM" field is "X" at the 
> > bottom of section 5.2.1. Please see blow:> > > 5.2.1.  OSPFv3 Prefix 
Attribute Flags Sub-TLV Registry     This document requests IANA to make 
permanent the early allocation of    the following codepoint for the "OSPFv3 
Prefix Attribute Flags" in    the "OSPFv3 Extended-LSA sub-TLVs" registry:      
   Value            Description                      Reference       --------   
----------------------------------   --------------         37         OSPFv3 
Prefix Attribute Flags         RFC to be> The entry in the "L2BM" field is 
"X".> > > > b) Should the titles of the new registries created by this 
document> be updated to use "Flags" rather than "Flag Field"? We ask because 
that> seems to be the pattern with other registry titles within both of the> 
registry groups (see links below).> > Also, the name of the field in Figure 1 
of this document is "Prefix Attribute> Flags". Should the titles of the 
registries be updated further to use  > "Prefix Attribute" rather than "Prefix 
Extended"? Or is this okay?> > If the titles are updated, we will ask IANA to 
update the registries  > accordingly.> > 
https://www.iana.org/assignments/ospfv2-parameters/> 
https://www.iana.org/assignments/ospfv3-parameters/> > Current:>   OSPFv2 
Prefix Extended Flag Field>   OSPFv3 Prefix Extended Flag Field> > Perhaps A:>  
 OSPFv2 Prefix Extended Flags>   OSPFv3 Prefix Extended Flags> > or> > Perhaps 
B:>   OSPFv2 Prefix Attribute Flags>   OSPFv3 Prefix Attribute Flags> --> We 
agree with the suggestion and prefer to rename the registries as follows for > 
> clarity and consistency with the field name used in the document:> >  • 
OSPFv2 Prefix Attribute Flags> >  • OSPFv3 Prefix Attribute Flags> > Please 
proceed to ask IANA to update the registry titles accordingly. Many thanks!> > 
> 5)  Yes, that change looks good. > > > > b) Please review the capitalization 
of "prefix attribute flags" and "Prefix> Attribute Flags" in the text below. We 
believe this should be capitalized in> the name of the TLV and the name of the 
field but lowercased in general> text. However, we are not sure if the 
capitalized form in the following> sentences is referring to the field. Are any 
updates needed?> > Original:>    Length (2 octets): Variable, dependent on the 
included Prefix>    Attribute Flags.  This indicates the length of the prefix 
attributes>    flags in octets.>    ...>    For example, the most>    
significant bit in the fifth octet of an 8-octet Prefix Attribute>    Flags is 
referred to as bit 32.> > Perhaps (leave capitalized form and add "field" for 
clarity):>    Length (2 octets): Variable, dependent on the included Prefix>    
   Attribute Flags field.  This indicates the length of the prefix  >       
attributes flags in octets.>    ...>    For example, the most>    significant 
bit in the fifth octet of an 8-octet Prefix Attribute>    Flags field is 
referred to as bit 32.> --> Yes,  I agree. > > There is one more place that 
needs to be updated.> > Original:>    Length (2 octets): Variable, dependent on 
the included Prefix>    Attribute Flags.  This indicates the length of the 
prefix attributes>    flags in octets.> > New:> >    Length (2 octets): 
Variable, dependent on the included Prefix>       Attribute Flags field.  This 
indicates the length of the Prefix >       Attributes Flags field in octets.> > 
Change to:> > Length (2 octets): Variable, dependent on the included Prefix>    
   Attribute Flags field.  This indicates the length of the Prefix >       
Attribute Flags field in octets.> > > 6)  > After checking I believe the 
current text is OK in this aspect.> > Many thanks,> > Ran> > > > Thank you.> > 
RFC Editor/rv/kc> > > On May 22, 2025, at 3:57 PM, rfc-edi...@rfc-editor.org 
wrote:> > *****IMPORTANT*****> > Updated 2025/05/22> > RFC Author(s):> 
--------------> > Instructions for Completing AUTH48> > Your document has now 
entered 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  > available as listed in the FAQ 
(https://www.rfc-editor.org/faq/).> > 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:> >    > >   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   >   
and  are set correctly.  See details at  >   .> > *  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-edi...@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 a new 
archival mailing list  >      to preserve AUTH48 conversations 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/rfc9792.xml>   
https://www.rfc-editor.org/authors/rfc9792.html>   
https://www.rfc-editor.org/authors/rfc9792.pdf>   
https://www.rfc-editor.org/authors/rfc9792.txt> > Diff file of the text:>   
https://www.rfc-editor.org/authors/rfc9792-diff.html>   
https://www.rfc-editor.org/authors/rfc9792-rfcdiff.html (side by side)> > Diff 
of the XML:  >   https://www.rfc-editor.org/authors/rfc9792-xmldiff1.html> > > 
Tracking progress> -----------------> > The details of the AUTH48 status of 
your document are here:>   https://www.rfc-editor.org/auth48/rfc9792> > Please 
let us know if you have any questions.   > > Thank you for your cooperation,> > 
RFC Editor> > --------------------------------------> RFC9792 
(draft-ietf-lsr-ospf-prefix-extended-flags-07)> > Title            : Prefix 
Flag Extension for OSPFv2 and OSPFv3> Author(s)        : R. Chen, D. Zhao, P. 
Psenak, K. Talaulikar, L. Gong> WG Chair(s)      : Acee Lindem, Christian 
Hopps, Yingzhen Qu> > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter 
Van de Velde> > > > > -- > auth48archive mailing list -- 
auth48archive@rfc-editor.org> To unsubscribe send an email to 
auth48archive-le...@rfc-editor.org

-- 
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org

Reply via email to