Re: [auth48] [C381] AUTH48: RFC-to-be 9304 <draft-ietf-lisp-rfc8113bis-03> for your review

[Luigi Iannone <[e-mail]>]

Hi,

I think that the caption “table” is commonly used.
IMO the final version of the draft should be:

   +===============================+======+===========+
   | Message                       | Code | Reference |
   +===============================+======+===========+
   | LISP Shared Extension Message | 15   |[RFC 9304] |
   +-------------------------------+------+-----------+

            Table 1: LISP Packet Types Registry

Would that work?

Ciao

L.


> On 20 Sep 2022, at 07:20, [e-mail] wrote:
> 
> Dear Alanna, 
> 
> Thank you for the clarification. I wasn't aware that we can deviate from what is actually recorded in the IANA registry. 
> 
> That is said, please delete the new added titles "Table 1" and "Table 2". Thank you. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Alanna Paloma <[e-mail]>
>> Envoyé : mardi 20 septembre 2022 00:28
>> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
>> JACQUENET Christian INNOV/NET <[e-mail]>
>> Cc : [e-mail]; [e-mail]; lisp-
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> Objet : Re: [C381] AUTH48: RFC-to-be 9304 <draft-ietf-lisp-
>> rfc8113bis-03> for your review
>> 
>> Hi Christian and Med,
>> 
>> Thank you for your replies. We have updated the files accordingly
>> and noted Med’s approval on the AUTH48 status page:
>>  https://www.rfc-editor.org/auth48/rfc9304
>> 
>> Med - Please note that we did not change “RFC 9304” to a citation
>> in Table 2 (Section 5.1) as we try to avoid self-references
>> because they can be potentially confusing.
>> 
>> The files have been posted here (please refresh):
>> https://www.rfc-editor.org/authors/rfc9304.xml
>> https://www.rfc-editor.org/authors/rfc9304.txt
>> https://www.rfc-editor.org/authors/rfc9304.html
>> https://www.rfc-editor.org/authors/rfc9304.pdf
>> 
>> The relevant diff files have been posted here:
>> https://www.rfc-editor.org/authors/rfc9304-diff.html
>> (comprehensive diff)  https://www.rfc-editor.org/authors/rfc9304-
>> auth48diff.html (AUTH48 changes)
>> 
>> Please review the document carefully and contact us with any
>> further updates you may have.  Note that we do not make changes
>> once a document is published as an RFC.
>> 
>> We will await Christian’s approval prior to moving this document
>> forward in the publication process.
>> 
>> Thank you,
>> RFC Editor/ap
>> 
>>> On Sep 18, 2022, at 10:47 PM, [e-mail]
>> wrote:
>>> 
>>> Re-,
>>> 
>>> The edits look good to me, except this one:
>>> 
>>> CURRENT:
>>> 
>>>  +===============================+======+===========+
>>>  | Message                       | Code | Reference |
>>>  +===============================+======+===========+
>>>  | LISP Shared Extension Message | 15   | RFC 9304  |
>>>  +-------------------------------+------+-----------+
>>> 
>>> Please use the following to align with how references are listed
>> it https://www.iana.org/assignments/lisp-parameters/lisp-
>> parameters.xhtml#lisp-packet-types:
>>> 
>>> NEW:
>>>  +===============================+======+===========+
>>>  | Message                       | Code | Reference |
>>>  +===============================+======+===========+
>>>  | LISP Shared Extension Message | 15   | [RFC9304] |
>>>  +-------------------------------+------+-----------+
>>> 
>>> Assuming this change is implemented, I approve the publication
>> of this document.
>>> 
>>> Thank you.
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : [e-mail] <[e-mail]>
>> Envoyé :
>>>> vendredi 16 septembre 2022 23:12 À : BOUCADAIR Mohamed
>> INNOV/NET
>>>> <[e-mail]>; JACQUENET Christian INNOV/NET
>>>> <[e-mail]> Cc : rfc-editor@rfc-
>> editor.org;
>>>> [e-mail]; lisp- [e-mail]; [e-mail];
>>>> [e-mail]; [e-mail] Objet : [C381]
>> AUTH48:
>>>> RFC-to-be 9304 <draft-ietf-lisp-rfc8113bis-
>>>> 03> for your review
>>>> 
>>>> *****IMPORTANT*****
>>>> 
>>>> Updated 2022/09/16
>>>> 
>>>> 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:
>>>> 
>>>>  <!-- [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
>>>> 
>>>>  *  [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], 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,
>>>>       [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/rfc9304.xml
>>>>  https://www.rfc-editor.org/authors/rfc9304.html
>>>>  https://www.rfc-editor.org/authors/rfc9304.pdf
>>>>  https://www.rfc-editor.org/authors/rfc9304.txt
>>>> 
>>>> Diff file of the text:
>>>>  https://www.rfc-editor.org/authors/rfc9304-diff.html
>>>>  https://www.rfc-editor.org/authors/rfc9304-rfcdiff.html (side
>> by
>>>> side)
>>>> 
>>>> Diff of the XML:
>>>>  https://www.rfc-editor.org/authors/rfc9304-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/rfc9304.original.v2v3.xml
>>>> 
>>>> XMLv3 file that is a best effort to capture v3-related format
>> updates
>>>> only:
>>>>  https://www.rfc-editor.org/authors/rfc9304.form.xml
>>>> 
>>>> 
>>>> Tracking progress
>>>> -----------------
>>>> 
>>>> The details of the AUTH48 status of your document are here:
>>>>  https://www.rfc-editor.org/auth48/rfc9304
>>>> 
>>>> Please let us know if you have any questions.
>>>> 
>>>> Thank you for your cooperation,
>>>> 
>>>> RFC Editor
>>>> 
>>>> --------------------------------------
>>>> RFC9304 (draft-ietf-lisp-rfc8113bis-03)
>>>> 
>>>> Title            : Locator/ID Separation Protocol (LISP):
>> Shared
>>>> Extension Message and IANA Registry for Packet Type Allocations
>>>> Author(s)        : M. Boucadair, C. Jacquenet
>>>> WG Chair(s)      : Joel M. Halpern, Luigi Iannone
>>>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
>>> 
>>> 
>> __________________________________________________________________
>> ____
>>> ___________________________________________________
>>> 
>>> Ce message et ses pieces jointes peuvent contenir des
>> informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre
>> diffuses,
>>> exploites ou copies sans autorisation. Si vous avez recu ce
>> message
>>> par erreur, veuillez le signaler a l'expediteur et le detruire
>> ainsi que les pieces jointes. Les messages electroniques etant
>> susceptibles d'alteration, Orange decline toute responsabilite si
>> ce message a ete altere, deforme ou falsifie. Merci.
>>> 
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should
>> not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the
>> sender and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that
>> have been modified, changed or falsified.
>>> Thank you.
>>> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>