Editors,
Thank you for your work so far. Responses to the individual questions are
here numbered:
1) You are correct that there is no intention that an operating BPA
software is not expected to actually use the IANA registry in-place. The
registry is for documentation of the code points. So I think your suggested
edit is good.
2) Your interpretation is correct; your suggested edit is more accurate but
I will prepend some text to make the citation not treated as part of the
sentence.
Section 1
OLD:
The earlier Bundle Protocol (BP) Version 6 (BPv6) defined an IANA
registry for Administrative Record type code points under [IANA-BP].
NEW:
An earlier specification [RFC7116] defined an IANA registry for
Administrative Record type code points [IANA-BP] for use with the
Bundle Protocol (BP) Version 6 (BPv6) [RFC5050].
3) Your interpretation is correct; your suggested edit is more clear and
looks good.
4) Your suggestion B seems more understandable and looks like a good edit.
5) Yes, this single use of the abbreviation can be expanded.
6) I'm trying to find some example of similar overloaded code point tables
outside of the Bundle Protocol registry group, but failing to do so. There
is no implication that assignments in that range need to apply to both
version 6 and 7. Other tables in the Bundle Protocol registry group leave
the version column empty for the unassigned values, so it's probably best
to do so here also.
Table 1
OLD:
| 6,7 | 3 | Unassigned | |
| 6,7 | 5 to 15 | Unassigned | |
NEW:
| | 3 | Unassigned | |
| | 5 to 15 | Unassigned | |
Related to this table, I see that there have been some edits to replace "X
to Y" numbering with "X-Y". Is this the consistent way to indicate this in
registries? I was trying to avoid using the hyphen to not confuse it with a
negative sign, but whatever is consistent is the right way.
7) Yes, keeping lower case for consistency is a good edit.
8) This section should be removed entirely.
9) I have reviewed the Inclusive Language style guide and I do not believe
that any other edits are needed.
On Tue, Jan 7, 2025 at 2:47 AM <rfc-edi...@rfc-editor.org> wrote:
> Authors,
>
> While reviewing this document during AUTH48, please resolve (as necessary)
> the following questions, which are also in the XML file.
>
> 1) <!-- [rfced] Initially, we found this text unclear because we
> questioned
> whether the BPv7 agent was using the IANA registry to document
> Administrative Record types or whether the agent was using the IANA
> registry itself. We believe both may be true. Please review whether the
> following possible update is accurate.
>
> Original:
> This document updates RFC 9171 to clarify that a Bundle Protocol
> Version 7 agent is intended to use an IANA registry for
> Administrative Record types. It also makes a code point reservations
> for private and experimental use.
>
> Perhaps:
> This document updates RFC 9171 to clarify that Bundle Protocol Version
> 7
> agents are expected to use the IANA "Bundle Administrative Record Types"
> registry to identify and document Administrative Record types. This
> document also designates code points for Private and Experimental Use.
> -->
>
>
> 2) <!-- [rfced] As we believe the "earlier Bundle Protocol (BP) Version 6
> (BPv6)" refers to the version specified in RFC 5050, and because the
> relevant registry seems to have been created per RFC 7116, we suggest the
> following update. Please review and let us know if this update is
> acceptable.
>
> Original:
> The earlier Bundle Protocol (BP) Version 6 (BPv6) defined an IANA
> registry for Administrative Record type code points under [IANA-BP].
>
> Perhaps:
> [RFC7116] defined an IANA registry for Administrative Record type code
> points [IANA-BP] for use with the Bundle Protocol (BP)
> Version 6 (BPv6) [RFC5050].
> -->
>
>
> 3) <!-- [rfced] Does "overlapping code points" mean code points that are
> used for both BPv6 and BPv7? For clarity, please consider whether the
> following correctly conveys the intended meaning.
>
> Original:
> This document does not specify how BPv6 and BPv7 can interoperate for
> overlapping code points or how a specific code point is to be
> interpreted either similarly or differently between Bundle Protocol
> versions. It is up to each individual Administrative Record type
> specification to define how it relates to each BP version.
>
> Perhaps:
> This document does not specify how BPv6 and BPv7 can interoperate
> when both use the same code points or how a specific code point is to be
> interpreted either similarly or differently by Bundle Protocol
> versions. The specification for each Administrative Record type is to
> define how the Administrative Record type relates to each BP version.
> -->
>
>
> 4) <!-- [rfced] We are having trouble parsing this text. Please clarify.
>
> Original:
> Instead of using the list of types in Section 6.1 of [RFC9171], a
> BPv7 administrative element SHALL interpret administrative record
> type code values in accordance with the IANA "Bundle Administrative
>
> Record Types" registry under [IANA-BP] for entries having a "Bundle
>
> Protocol Version" of 7.
>
> Perhaps A:
> Instead of using the list of types in Section 6.1 of [RFC9171], a
> BPv7 administrative element SHALL use administrative record
> type code values as registered in the IANA "Bundle Administrative
>
> Record Types" registry [IANA-BP]. BPv7 administrative elements
> may use the code points marked with "7" in the Bundle Protocol
> Version column.
>
> Or perhaps B:
> Instead of using the list of types in Section 6.1 of [RFC9171], a
> BPv7 administrative element SHALL determine which administrative
> record type code values can be used by the "7" noted in the Bundle
> Protocol Version column of the IANA "Bundle Administrative Record Types"
> registry [IANA-BP].
> -->
>
>
> 5) <!-- [rfced] This is the only occurrence of BPA. May we change this to
> "bundle protocol agent"?
>
> Original:
> The processing of a received administrative record ADU
> does not affect the fact that the bundle itself was delivered to the
> administrative element or any related BPA processing of (e.g. status
> reports on) the enveloping bundle.
> -->
>
>
> 6) <!-- [rfced] Because values 3 and 5-15 are unassigned, is it correct
> for
> the Bundle Protocol Versions to be noted as 6,7? Does this imply that 6
> and 7 must apply to future assignments of those values (i.e., 6,7 apply to
> unassigned values defined by BPv6, and 7 (only) applies to all other
> future
> assignments as values 16+ are defined for BPv7)?
>
> From Table 1:
> | 6,7 | 3 | Unassigned | |
> | 6,7 | 5 to 15 | Unassigned | |
> -->
>
>
> 7) <!-- [rfced] Throughout the text, the following terminology appears to
> be used inconsistently. May we lowercase these for consistency with RFC
> 9171, which seems to use lower case except when referring to the name of
> the IANA registry.
>
> Administrative Record types
> administrative record type code values
> Administrative Record type code points
> administrative record type code
> administrative record ADU
> -->
>
>
> 8) <!-- [rfced] It appears that there is no text in the Acknowledgments
> section. Would you like to add text or remove the section entirely?
> -->
>
>
> 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.
>
> RFC Editor
>
>
> On Jan 6, 2025, at 11:43 PM, rfc-edi...@rfc-editor.org wrote:
>
> *****IMPORTANT*****
>
> Updated 2025/01/06
>
> 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
>
> * 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/rfc9713.xml
> https://www.rfc-editor.org/authors/rfc9713.html
> https://www.rfc-editor.org/authors/rfc9713.pdf
> https://www.rfc-editor.org/authors/rfc9713.txt
>
> Diff file of the text:
> https://www.rfc-editor.org/authors/rfc9713-diff.html
> https://www.rfc-editor.org/authors/rfc9713-rfcdiff.html (side by side)
>
> Diff of the XML:
> https://www.rfc-editor.org/authors/rfc9713-xmldiff1.html
>
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
> https://www.rfc-editor.org/auth48/rfc9713
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC9713 (draft-ietf-dtn-bpv7-admin-iana-04)
>
> Title : Bundle Protocol Version 7 Administrative Record Types
> Registry
> Author(s) : B. Sipos
> WG Chair(s) : Edward J. Birrane, Rick Taylor
> Area Director(s) : Erik Kline, Éric Vyncke
>
>
>
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
