Re: [auth48] AUTH48: RFC-to-be 9488 <draft-ietf-pce-local-protection-enforcement-11> for your review

[Rebecca VanRheenen <[e-mail]>]

Hi Andrew,

Thank you for the updated XML file! Responses to your points about questions 12, 17, and 18f are below in addition to a comment about question 18a. Links to the updated files are also listed below. 

Please let us know if you have any further questions or comments.


>> 12) <!-- [rfced] In Table 1, would it be helpful to list bit 6 first and then bit 7
>> (matches IANA registry)? Or do you prefer the current (matches order mentioned in
>> text before table)?
>> -->
> 
> [andrew] Updated to keep consistency with IANA registry and reading the bit object definition from left to right.                  
>                                                                                                                                    
> [andrew] Is it recommended to also update the order of the bit descriptions as well?                                               

The current looks good to us. Let us know if you think any further changes are needed.


>> 17) <!-- [rfced] Would you like the references to be alphabetized or left in their
>> current order?
>> -->
> 
> [andrew] No preference, Okay to proceed with alphabetized if it is commonly recommended and also okay to keep as is.

We alphabetized the references as this is more common in the RFC Series (though it is not required).


>> 18f) We see that "LSP object" is used in both RFCs 8231 and 8281,
>> but "LSP Attribute Object" (or "LSPA") is not used in either. Should the
>> sentence below be updated to reflect usage in the cited documents?
>> 
>> 
>> Original:
>> It is
>> important to note that [RFC8231] and [RFC8281] permit the LSP
>> Attribute Object to be included in PCUpd messages for PCC-initiated
>> and PCE-initiated LSPs.
>> -->
>                                                                                                                                    
> [andrew] LSPA is defined in RFC5440 section 7.11. This is the base PCEP RFC (stateless, only defines PcReq Msg).                   
> LSP and LSPA are seperate objects. LSPA is referenced in RFC8231, see definition in RFC8231 section 6.4.                          
> As per section 6.4, The LSPA object follows immediately after the LSP object in other message exchanges defined in that RFC (ex:   
> PcUpd).                                                                                                                            
> The flag is embedded within the LSP Attribute object, not the LSP Object,                                                          
> thus needs to remain referencing the "attribute" object.                                                                           
>                                                                                                                                    
> Perhaps a citation to RFC5440?:                                                                                                    
>                                                                                                                                    
>    It is                                                                                                                           
>    important to note that [RFC8231] and [RFC8281] permit the LSP                                                                   
>    Attribute Object([RFC5440]) to be included in PCUpd messages for PCC-initiated                                                  
>    and PCE-initiated LSPs.         

Thank you for the clarification. We added the [RFC5440] citation.


>> 18a) Please confirm the name/description for the E flag defined in this
>> document. We see the following forms used in the document:
>> 
>> 
>> Enforcement
>> Protection Enforcement
>> Local Protection Enforcement
>> 
>> 
>> Note: The current name in the "LSPA Object Flag Field" registry is "Protection
>> Enforcement" (see
>> https://www.iana.org/assignments/pcep/pcep.xhtml#lspa-object-flag-field<https://www.iana.org/assignments/pcep/pcep.xhtml#lspa-object-flag-field>); if
>> needed, we will request an update to the registry prior to publication.
> 
> [Andrew] 'Protection Enforcement' should be used.

We updated two instances to use “Protection Enforcement”. See Sections 1 and 5 (Table 1). Please review.                                                                                             
                             
______________

Updated XML file:
   https://www.rfc-editor.org/authors/rfc9488.xml

Updated output files:
   https://www.rfc-editor.org/authors/rfc9488.txt
   https://www.rfc-editor.org/authors/rfc9488.pdf
   https://www.rfc-editor.org/authors/rfc9488.html

Diff file showing all changes made during AUTH48:
   https://www.rfc-editor.org/authors/rfc9488-auth48diff.html

Diff files showing all changes:
   https://www.rfc-editor.org/authors/rfc9488-diff.html
   https://www.rfc-editor.org/authors/rfc9488-rfcdiff.html (side-by-side diff)
   https://www.rfc-editor.org/authors/rfc9488-alt-diff.html (diff showing changes where text is moved or deleted)

Note that it may be necessary for you to refresh your browser to view the most recent version. 

For the AUTH48 status of this document, please see:
   https://www.rfc-editor.org/auth48/rfc9488


Thank you,
RFC Editor/rv



> On Oct 1, 2023, at 8:55 PM, Andrew Stone (Nokia) <[e-mail]> wrote:
> 
> Hi RFC Editor, 
> 
> Thank you very much for undertaking this work and doing a thorough review. Much appreciated.
> 
> I've edited the XML document and attached in the reply. Most recommendations adopted, comments resolved within the XML have been removed. Thank you for the abbreviation expansions. 
> 
> A few outstanding comments/replies embedded in the XML with [andrew].  
> 
> Outstanding points (see reply inline in xml): 
> 
> - (12) reordered table to align with IANA and left-to-right reading, but should bit field description be re-ordered as well? Or okay to keep descriptions in order as is?
> - (17) reference re-ordering. No preference, okay with selection by RFC editor
> - (18.f) text should remain LSPA, but rfceditor to confirm LSPA citation to 5440 required or not
> 
> Thanks
> Andrew
> 
> 
> 
> On 2023-09-28, 5:03 PM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:
> 
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
> 
> Authors,
> 
> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
> 
> 
> 1) <!-- [rfced] Please note that the title of the document has been updated as
> follows. We expanded the abbreviation "PCEP" per Section 3.6 of RFC 7322
> ("RFC Style Guide"). Please review.
> 
> 
> Original:
> Local Protection Enforcement in PCEP
> 
> 
> Current:
> Local Protection Enforcement in the Path Computation Element
> Communication Protocol (PCEP)
> 
> 
> Note that we also updated the abbreviated title (only appears in the running
> header of the pdf output) to match the document title as there was space.
> 
> 
> Original:
> Protection Enforcement
> 
> 
> Current:
> Local Protection Enforcement in PCEP
> -->
> 
> 
> 
> 
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
> title) for use on https://www.rfc-editor.org/search <https://www.rfc-editor.org/search>. -->
> 
> 
> 
> 
> 3) <!-- [rfced] For this sentence in the Abstract, is "protection strictness"
> okay, or would "protection enforcement" (like in the document title) be
> better?
> 
> 
> Original:
> This document also introduces a new flag for
> signalling protection strictness in PCEP.
> -->
> 
> 
> 
> 
> 4) <!-- [rfced] Please review "define enforcement, or strictness of the
> protection requirement" here. Would it be helpful to update to either
> "define the enforcement of the protection requirement" or "define the
> strictness of the protection enforcement requirement"?
> 
> 
> Original:
> It is desirable for an operator to be able to define the enforcement,
> or strictness of the protection requirement.
> 
> 
> Perhaps:
> It is desirable for an operator to be able to define the enforcement
> of the protection requirement.
> 
> 
> Or:
> It is desirable for an operator to be able to define the strictness
> of the protection enforcement requirement.
> -->
> 
> 
> 
> 
> 5) <!-- [rfced] Will readers understand what is meant by "reference notes"? Also,
> we revised "is path setup type and data plane technology agnostic" as
> follows to improve readability.
> 
> 
> Original:
> The document contains reference notes for Segment Routing, however
> the content described is path setup type and data plane technology
> agnostic.
> 
> 
> Current:
> The document contains reference notes for Segment Routing; however,
> the content described is agnostic in regard to path setup type and
> data plane technology.
> -->
> 
> 
> 
> 
> 6) <!-- [rfced] We are having trouble understanding how the last part of this
> sentence (i.e., "and the use case...") connects with the first
> part. Also, would a citation be helpful for "RSVP"?
> 
> 
> Original:
> The name of the flag uses the term "Desired", which by
> definition means "strongly wished for or intended" and the use case
> originated from the RSVP.
> 
> 
> Perhaps:
> The name of the flag uses the term "Desired", which by
> definition means "strongly wished for or intended". The use case
> for this flag originated in RSVP.
> -->
> 
> 
> 
> 
> 7) <!-- [rfced] May we update "Implementations of [RFC5440]" as follows for
> clarity?
> 
> 
> Original:
> Implementations of [RFC5440] have either interpreted the L flag as
> PROTECTION MANDATORY or PROTECTION PREFERRED, leading to operational
> differences.
> 
> 
> Perhaps:
> Implementations that use PCEP [RFC5440] have interpreted the L flag as
> either PROTECTION MANDATORY or PROTECTION PREFERRED, leading to operational
> differences.
> -->
> 
> 
> 
> 
> 8) <!-- [rfced] Should "service agreement definitions" here read "Service Level
> Agreement definitions" or "SLA definitions"? Or is the current correct?
> 
> 
> Original:
> A network may be providing transit to
> multiple service agreement definitions against the same base topology
> network, whose behavior could vary, such as wanting local protection
> to be invoked on some LSPs and not wanting local protection on
> others.
> -->
> 
> 
> 
> 
> 9) <!-- [rfced] Please review "The boolean bit L flag". Would one of the
> following options improve clarity and readability?
> 
> 
> Original:
> The boolean bit L flag is unable to distinguish between the different
> options of PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION
> PREFERRED and UNPROTECTED PREFERRED.
> 
> 
> Perhaps:
> The L flag is a boolean bit and thus unable to distinguish between the different
> options of PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION
> PREFERRED and UNPROTECTED PREFERRED.
> 
> 
> Or:
> Because it is a boolean bit, the L flag is unable to distinguish between the different
> options of PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION
> PREFERRED, and UNPROTECTED PREFERRED.
> -->
> 
> 
> 
> 
> 10) <!-- [rfced] Two consecutive paragraphs in Section 4.2 begin with "For
> example". Is "For example" needed here? Or should the second one be
> updated to something like "As another example"? Please review.
> 
> 
> Also, in the second paragraph below, we updated "is when an operator" to "is
> for use cases in which an operator" for clarity and for consistency with the
> previous paragraph. Please review.
> 
> 
> Original:
> For example, PROTECTION MANDATORY is for use cases where an operator
> may need the LSP to follow a path which has local protection provided
> along the full path, ensuring that if there is a failure anywhere
> along the path that traffic will be fast re-routed at the point.
> 
> 
> For example, UNPROTECTED MANDATORY is when an operator may
> intentionally prefer an LSP to not be locally protected, and thus
> would rather local failures cause the LSP to go down. ...
> 
> 
> Perhaps:
> PROTECTION MANDATORY is for use cases in which an operator
> may need the LSP to follow a path that has local protection provided
> along the full path, ensuring that if there is a failure anywhere
> along the path that traffic will be fast re-routed at the point.
> 
> 
> UNPROTECTED MANDATORY is for use cases in which an operator may
> intentionally prefer an LSP to not be locally protected and thus
> would rather local failures cause the LSP to go down.
> -->
> 
> 
> 
> 
> 11) <!-- [rfced] Please review "protected with path protection" here. Would
> updating to just "protected" retain the intended meaning?
> 
> 
> Original:
> An example
> scenario is one where an LSP is protected with path protection via a
> secondary diverse LSP.
> 
> 
> Perhaps:
> An example
> scenario is one where an LSP is protected via a secondary diverse LSP.
> -->
> 
> 
> 
> 
> 12) <!-- [rfced] In Table 1, would it be helpful to list bit 6 first and then bit 7
> (matches IANA registry)? Or do you prefer the current (matches order mentioned in
> text before table)?
> -->
> 
> 
> 
> 
> 13) <!-- [rfced] We updated this sentence as follows to more accurately describe
> the figure. Please let us know any objections.
> 
> 
> Original:
> The format of the LSPA Object as defined in [RFC5440] is:
> 
> 
> Current:
> The following shows the format of the LSPA object as defined in
> [RFC5440] with the addition of the E flag defined in this document:
> -->
> 
> 
> 
> 
> 14) <!-- [rfced] May we rephrase this sentence to improve clarity?
> 
> 
> Original:
> Considerations in the message passing between the PCC and the PCE for
> the E flag bit which are not supported by the entity are outlined in
> this section, with requirements for the PCE and the PCC implementing
> this document described at the end.
> 
> 
> Perhaps:
> This section outlines considerations for the E flag bit in the message
> passing between the PCC and the PCE that are not supported by the entity.
> The requirements for the PCE and the PCC implementing this document are described
> at the end.
> -->
> 
> 
> 
> 
> 15) <!-- [rfced] Should "PCUpd E flag (and L flag)" be updated to "the E flag (and
> L flag) in a PCUpd message" or something similar? Also, we used a
> semicolon and changed "therefore" to "so" for clarity. Please review.
> 
> 
> Original:
> For PCC-initiated LSPs, PCUpd E flag (and L flag) is an echo from the
> previous PCRpt however the bit value is ignored on the PCE from the
> previous PCRpt, therefore the E flag value set in the PCUpd is zero.
> 
> 
> Perhaps:
> For PCC-initiated LSPs, the E flag (and L flag) in a PCUpd message is an echo from the
> previous PCRpt message; however, the bit value is ignored on the PCE from the
> previous PCRpt message, so the E flag value set in the PCUpd message is 0.
> -->
> 
> 
> 
> 
> 16) <!-- [rfced] Will readers understand what "it" refers to here?
> 
> 
> Original:
> For a PCC which does support this document, it MAY set the E flag to
> 1 depending on local configuration.
> 
> 
> Perhaps:
> A PCC that does support this document MAY set the E flag to
> 1 depending on local configuration.
> 
> 
> Or:
> For a PCC that does support this document, the E flag MAY be set to
> 1 depending on local configuration.
> -->
> 
> 
> 
> 
> 17) <!-- [rfced] Would you like the references to be alphabetized or left in their
> current order?
> -->
> 
> 
> 
> 
> 18) <!-- [rfced] Terminology
> 
> 
> a) Please confirm the name/description for the E flag defined in this
> document. We see the following forms used in the document:
> 
> 
> Enforcement
> Protection Enforcement
> Local Protection Enforcement
> 
> 
> Note: The current name in the "LSPA Object Flag Field" registry is "Protection
> Enforcement" (see
> https://www.iana.org/assignments/pcep/pcep.xhtml#lspa-object-flag-field <https://www.iana.org/assignments/pcep/pcep.xhtml#lspa-object-flag-field>); if
> needed, we will request an update to the registry prior to publication.
> 
> 
> 
> 
> b) Should "a local protection desired" here read "the L flag"?
> 
> 
> Original:
> Therefore, a local protection desired does
> not require the transit router to satisfy protection in order to
> establish the RSVP signalled path.
> 
> 
> Perhaps:
> Therefore, the L flag does
> not require the transit router to satisfy protection in order to
> establish the RSVP-signaled path.
> 
> 
> 
> 
> c) FYI - We have updated instances of "PCRpt", "PCUpd", "PCReq", and
> "PCInitiate" with the word "message" (i.e., "PCRpt message", "PCUpd message",
> "PCReq message", and "PCInitiate message").
> 
> 
> 
> 
> d) We see "Session Attribute" (initial caps and no hyphen) in RFC 3209, but we
> do not see "SESSION-ATTRIBUTE" (all caps with hyphen). Please review and let
> us know if any updates are needed in the following sentence.
> 
> 
> Original:
> One such concept in PCEP is the 'Local Protection
> Desired' (L flag in the LSPA Object in [RFC5440]), which was
> originally defined in the SESSION-ATTRIBUTE Object in RFC3209.
> 
> 
> 
> 
> e) "Segment Routed path" does not appear in RFC 8664, but "Segment
> Routing path" does. Are any changes needed in these sentences?
> 
> 
> Original:
> PCEP Extensions for Segment Routing ([RFC8664]) extends support in
> PCEP for Segment Routed paths.
> ...
> When computing a Segment Routed path, It is RECOMMENDED that a PCE
> assume a Node SID is protected.
> 
> 
> f) We see that "LSP object" is used in both RFCs 8231 and 8281,
> but "LSP Attribute Object" (or "LSPA") is not used in either. Should the
> sentence below be updated to reflect usage in the cited documents?
> 
> 
> Original:
> It is
> important to note that [RFC8231] and [RFC8281] permit the LSP
> Attribute Object to be included in PCUpd messages for PCC-initiated
> and PCE-initiated LSPs.
> -->
> 
> 
> 
> 
> 19) <!-- [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.
> 
> 
> Path Computation Element Communication Protocol (PCEP)
> Label Switched Path (LSP)
> Border Gateway Protocol - Link State (BGP-LS)
> Service Level Agreement (SLA)
> -->
> 
> 
> 
> 
> 20) <!-- [rfced] Please review the "Inclusive Language" portion of the online
> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language&gt;>
> and let us know if any changes are needed.
> 
> 
> Note that our script did not flag any words in particular, but this should
> still be reviewed as a best practice.
> -->
> 
> 
> 
> 
> Thank you.
> 
> 
> RFC Editor/rv/ap
> 
> 
> On Sep 28, 2023, at 2:02 PM, [e-mail] <mailto:[e-mail]> wrote:
> 
> 
> *****IMPORTANT*****
> 
> 
> Updated 2023/09/28
> 
> 
> 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/ <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:
> 
> 
> <!-- [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/ <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> <https://authors.ietf.org/rfcxml-vocabulary&gt;>.
> 
> 
> * 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
> 
> 
> * [e-mail] <mailto:[e-mail]> (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).
> 
> 
> * [e-mail] <mailto:[e-mail]>, 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 <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>
> 
> 
> * The archive itself:
> https://mailarchive.ietf.org/arch/browse/auth48archive/ <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,
> [e-mail] <mailto:[e-mail]> 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/rfc9488.xml <https://www.rfc-editor.org/authors/rfc9488.xml>
> https://www.rfc-editor.org/authors/rfc9488.html <https://www.rfc-editor.org/authors/rfc9488.html>
> https://www.rfc-editor.org/authors/rfc9488.pdf <https://www.rfc-editor.org/authors/rfc9488.pdf>
> https://www.rfc-editor.org/authors/rfc9488.txt <https://www.rfc-editor.org/authors/rfc9488.txt>
> 
> 
> Diff file of the text:
> https://www.rfc-editor.org/authors/rfc9488-diff.html <https://www.rfc-editor.org/authors/rfc9488-diff.html>
> https://www.rfc-editor.org/authors/rfc9488-rfcdiff.html <https://www.rfc-editor.org/authors/rfc9488-rfcdiff.html> (side by side)
> 
> 
> Diff of the XML:
> https://www.rfc-editor.org/authors/rfc9488-xmldiff1.html <https://www.rfc-editor.org/authors/rfc9488-xmldiff1.html>
> 
> 
> The following files are provided to facilitate creation of your own
> diff files of the XML.
> 
> 
> Initial XMLv3 created using XMLv2 as input:
> https://www.rfc-editor.org/authors/rfc9488.original.v2v3.xml <https://www.rfc-editor.org/authors/rfc9488.original.v2v3.xml>
> 
> 
> XMLv3 file that is a best effort to capture v3-related format updates
> only:
> https://www.rfc-editor.org/authors/rfc9488.form.xml <https://www.rfc-editor.org/authors/rfc9488.form.xml>
> 
> 
> 
> 
> Tracking progress
> -----------------
> 
> 
> The details of the AUTH48 status of your document are here:
> https://www.rfc-editor.org/auth48/rfc9488 <https://www.rfc-editor.org/auth48/rfc9488>
> 
> 
> Please let us know if you have any questions.
> 
> 
> Thank you for your cooperation,
> 
> 
> RFC Editor
> 
> 
> --------------------------------------
> RFC9488 (draft-ietf-pce-local-protection-enforcement-11)
> 
> 
> Title : Local Protection Enforcement in PCEP
> Author(s) : A. Stone, M. Aissaoui, S. Sidor, S. Sivabalan
> WG Chair(s) : Julien Meuric, Dhruv Dhody
> 
> 
> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
> 
> 
> 
> 
> 
> 
> 
> <rfc9488-update-1.xml>