Hi Authors, This is another friendly weekly reminder that we await answers to the followup questions/comments in this thread for RFC-to-be 9880 (originally sent on 27 October).
Thank you! Madison Church RFC Production Center > On Nov 3, 2025, at 9:09 AM, Madison Church <[email protected]> > wrote: > > Hi Authors, > > This is a friendly reminder that we await answers to the followup > questions/comments below for RFC-to-be 9880. > > Thank you, and happy IETF week! > > Madison Church > RFC Production Center > >> On Oct 27, 2025, at 2:24 PM, Madison Church <[email protected]> >> wrote: >> >> Hi Carsten, >> >> Note that we have added IANA to this thread. >> >> After further discussion with IANA regarding questions 11 and 14, we have >> removed the relative links because they are not permanent. We have reverted >> the text, so the registry titles appear in quotes (i.e., “SenML Units” and >> “Secondary Units”) as shown in the updated files. Please let us know if >> there are any additional textual updates needed. >> >> Updated files: >> https://www.rfc-editor.org/authors/rfc9880.txt >> https://www.rfc-editor.org/authors/rfc9880.pdf >> https://www.rfc-editor.org/authors/rfc9880.html >> https://www.rfc-editor.org/authors/rfc9880.xml >> >> Updated diff files: >> https://www.rfc-editor.org/authors/rfc9880-diff.html >> https://www.rfc-editor.org/authors/rfc9880-rfcdiff.html (side by side) >> https://www.rfc-editor.org/authors/rfc9880-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9880-auth48rfcdiff.html (side by side) >> >> AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9880 >> >> Thank you, >> Madison Church >> RFC Production Center >> >>> On Oct 27, 2025, at 6:42 AM, Madison Church <[email protected]> >>> wrote: >>> >>> Hi Carsten, >>> >>> Thank you for your reply, and apologies for the delayed response! We have >>> updated the document accordingly. Please see below for followup >>> questions/comments. Note that we have left outstanding items in this thread >>> for convenience (and removed questions that have been resolved). >>> >>>> On Oct 10, 2025, at 3:02 PM, Carsten Bormann <[email protected]> wrote: >>>> >>>> RFC-editor, >>>> >>>> thank you for preparing this RFC-to-be. >>>> >>>> We’ll first reply to the more specific ones of your questions below. >>>> We will respond to more general questions (that require us to scan the >>>> document) in the next round (marked here with TO CHECK in questions 6, 20, >>>> 21, 22, 23). >>>> >>>> Please note that we are also preparing a -25, with two typo/C&P fixes and >>>> one more technical omission fixed (PR #187 to #189 in >>>> https://github.com/ietf-wg-asdf/SDF/pulls). >>>> We previously prepared a -24 with PR #186 in it (technical omissions), >>>> which you already picked up. >>>> You probably need AD approval for all these. >>> >>> 1) Thank you for letting us know! We incorporated these edits into the >>> document and also sent a reminder (on October 23) for the AD(s) to review >>> these updates. These updates may be best viewed side-by-side in this diff >>> file: https://www.rfc-editor.org/authors/rfc9880-auth48rfcdiff.html. Please >>> review the files carefully and let us know if they appear as desired. >>> >>>> Grüße, Carsten >>>> >>>> >>>> On 2025-10-07, at 07:03, [email protected] wrote: >>>>> >>>>> Authors, >>>>> >>>>> While reviewing this document during AUTH48, please resolve (as >>>>> necessary) >>>>> the following questions, which are also in the source file. >>>>> 5) <!-- [rfced] Figure 2: The SVG includes additional information that is >>>>> not present in the text. Is this as expected? For example, we see 0+, >>>>> 1, >>>>> and (c) in the SVG but not in the text artwork. In addition, sdfEvent and >>>>> sdfAction appear in a different order. Please review. >>>>> --> >>>> >>>> We originally had completely given up on providing a plaintext form of the >>>> illustration. >>>> The plaintext illustration that now is in there is somewhat rudimentary. >>>> As you notice, it doesn’t have the occurrence labels (0+, 1), and it >>>> doesn’t mark the boxes as compositions which looks almost like a © symbol >>>> in the generated SVG. >>>> >>>> We do warn that this is a limited rendition, so we think we are good. >>> >>> 2) Thank you for the explanation! We also note that pointing to the HTML in >>> the text (and removing the ASCII art) is also an option to avoid >>> mismatching figures; see https://authors.ietf.org/en/diagrams. Let us know >>> if you prefer to keep the text/figure as is, or if you would like to update >>> the document. For example, Figure 1 in RFC 9633 >>> (https://www.rfc-editor.org/rfc/rfc9633.txt) shows how this would appear in >>> the text output. >>> >>>>> 6) <!-- [rfced] Please review whether any of the notes in this document >>>>> should be in the <aside> element. It is defined as "a container for >>>>> content that is semantically less important or tangential to the >>>>> content that surrounds it" >>>>> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). >>>>> --> >>>> >>>> [TO CHECK] >>>> >>>>> 8) <!-- [rfced] May we rephrase the text below as follows to improve >>>>> readability and specify "it" in the second sentence? >>>>> >>>>> Original: >>>>> The keyword (map key) that defines an information block is "info". >>>>> Its value is a JSON map in turn, with a set of entries that represent >>>>> qualities that apply to the included definition. >>>>> >>>>> Perhaps: >>>>> The keyword (map key) that defines an information block as "info". >>>> >>>> This should stay “is” — not a sentence otherwise. >>>> (This is a statement about the keyword, giving its name as “info”.) >>>> >>>>> In turn, the keyword's value is a JSON map with a set of entries that >>>>> represent >>>>> qualities that apply to the included definition. >>>>> --> >>>> >>>> We could also make use of the word “nested”: >>>> >>>>> The keyword's value is nested a JSON map with a set of entries that >>>>> represent >>>>> qualities that apply to the included definition. >>>> >>>> In any case, we need to change >>>> OLD: >>>> included definition >>>> NEW: >>>> included definitions >>>> >>>> … to mirror the first paragraph of 3.1. >>> >>> 3) Thank you for your proposal! We agree with the suggested text and >>> updated the sentence with a minor correction to the placement of "nested >>> a". The sentence now reads as: "The keyword’s value is a nested JSON map…". >>> Please let us know if this is correct. >>> >>>>> 11) <!-- [rfced] FYI - In the XML, we have removed the links from "SenML >>>>> Units" and "Secondary Units" since those links do not point to the correct >>>>> section (and the correct section pointers follow shortly >>>>> thereafter). Please let us know any objections. >>>> >>>> I’m not happy with not having those fragment identifiers as links. >>>> I understand that IANA wants to keep the ability to change their format, >>>> but that has been outstanding for a long time now. >>>> The worst that can happen is that the fragment identifier part of the link >>>> does not work and the link points to the file as a whole. >>>> >>>>> Original XML: >>>>> <t>The unit name <bcp14>SHOULD</bcp14> be as >>>>> >>>>> per the <xref section="SenML Units" relative="#senml-units" >>>>> sectionFormat="bare" >>>>> target="RFC8428"/> registry >>>>> >>>>> or the <xref section="Secondary Units" relative="#secondary-units" >>>>> sectionFormat="bare" >>>>> target="RFC8798"/> registry in <xref target="IANA.senml"/> >>>>> >>>>> as specified by >>>>> >>>>> Sections <xref target="RFC8428" section="4.5.1" sectionFormat="bare"/> >>>>> and <xref >>>>> target="RFC8428" section="12.1" sectionFormat="bare"/> of <xref >>>>> target="RFC8428"/> and >>>>> <xref section="3" sectionFormat="of" target="RFC8798"/>, respectively. >>>>> </t> >>>>> --> >>> >>> 4) Understood. We have restored the links for the fragment identifiers. To >>> clarify, these links refer to RFCs 8428 (for SenML Units) and 8798 (for >>> Secondary Units) rather than the IANA registries themselves >>> (<https://www.iana.org/assignments/senml/senml.xhtml#senml-units> and >>> <https://www.iana.org/assignments/senml/senml.xhtml#secondary-units>). Is >>> this intentional? We ask this because the in-text citations that follow the >>> fragment identifier links reference the specific sections of the RFCs that >>> these registries appear in (so both RFCs are essentially referenced twice >>> in the same sentence). >>> >>>>> 12) <!-- [rfced] The IANA registry includes "(note 1)" as part of the >>>>> description for unix-time, but there is no note included in the registry. >>>>> >>>>> Should the notes be included in the registry >>>> >>>> Yes, please. >>> >>> 5) We will ask IANA to update to include this note. >>> >>>>> or perhaps "(note 1)" should >>>>> be removed from the description? >>>>> >>>>> Original (text): >>>>> | unix-time | A point in | number | POSIX time | Section | >>>>> | | civil time | | | 3.4.2 of | >>>>> | | (note 1) | | | RFC 8949 | >>>>> | | | | | [STD94] | >>>>> >>>>> See the IANA registry: >>>>> https://www.iana.org/assignments/sdf/sdf.xhtml#sdftype-values >>>>> --> >>> >>>>> 14) <!-- [rfced] We have updated this text to remove the use of relative >>>>> references. Please review. >>>>> >>>>> Original: >>>>> Repository: combining the symbol values from the SenML Units >>>>> registry and the Secondary Units registry in [IANA.senml] as >>>>> specified by Sections 4.5.1 and 12.1 of [RFC8428] and Section 3 of >>>>> [RFC8798], respectively (which by the registration policy are >>>>> guaranteed to be non-overlapping). >>>>> >>>>> Current: >>>>> Repository: Combining the symbol values from the "SenML Units" >>>>> registry and the "Secondary Units" registry in the "Sensor >>>>> Measurement Lists (SenML)" registry group [IANA.senml] as >>>>> specified by Sections 4.5.2 and 12.1 of [RFC8428] and Section 3 of >>>>> [RFC8798], respectively (which, by the registration policy, are >>>>> guaranteed to be non-overlapping). >>>>> --> >>>>> >>>> >>>> (I can’t see the change in the plaintext here…) >>>> Please see my comment about relative references into IANA registries above >>>> in question 11. >>> >>> 6) Noted. Relative references have also been restored in this sentence. >>> Please see our response/followup question to question 11. >>> >>>>> 17) <!-- [rfced] References >>>>> >>>>> a) Please review the following reference. The original URL for this >>>>> reference - >>>>> http://www.openmobilealliance.org/wp/omna/lwm2m/lwm2mregistry.html - >>>>> redirects to the following URL: >>>>> https://www.openmobilealliance.org/specifications with the title "OMA >>>>> Specifications". >>>>> >>>>> We could not find a page with the original title for this reference "OMA >>>>> LightweightM2M (LwM2M) Object and Resource Registry". We did find the >>>>> following page: >>>>> https://www.openmobilealliance.org/specifications/registries, which >>>>> contains separate links to the LwM2M Objects and >>>>> Resources registries. >>>>> >>>>> Would you like to update this reference to point to this new URL? >>>>> >>>>> Current: >>>>> [OMA] Open Mobile Alliance, "OMA LightweightM2M (LwM2M) Object >>>>> and Resource Registry", >>>>> <http://www.openmobilealliance.org/wp/omna/lwm2m/ >>>>> lwm2mregistry.html>. >>>> >>>> Right, so the URL and the title would need to be updated. >>>> The actual HTML page title is awkward, though. >>>> >>>> Title: openmobilealliance.org/specifications/registries/objects/ >>>> >>>> Maybe we can use the <h1> title instead of the document.title (which I >>>> don’t find in the page source, by the way): >>>> >>>> NEW: >>>> Title: LwM2M OBJECTS >>>> Link: https://www.openmobilealliance.org/specifications/registries/objects >>>> >>>> This link is slightly more specific than what we referenced before, but >>>> fits the site of the citation (which is about objects, not about >>>> resources) even better. >>>> >>>> (With my browser, the page briefly indicates that it is embarrassed about >>>> itself and then switches back to what we want here; this may need some >>>> additional debugging.) >>>> >>>>> b) The information for this reference appears to be from the 2020 version >>>>> of ECMA Standard ECMA-262. However, the URL provided points to the 2024 >>>>> edition. >>>>> >>>>> We've updated this reference to use the information from the URL - that >>>>> is, >>>>> the 2024 edition. Please let us know if you have any objections. >>>>> >>>>> Current: >>>>> [ECMA-262] Ecma International, "ECMAScript 2024 Language >>>>> Specification", 15th Edition, ECMA Standard ECMA-262, June >>>>> 2024, <https://www.ecma-international.org/wp- >>>>> content/uploads/ECMA-262.pdf>. >>>>> --> >>>> >>>> By now, that would be >>>> title: ECMA-262, 16th edition, June 2025 >>>> link: >>>> https://ecma-international.org/wp-content/uploads/ECMA-262_16th_edition_june_2025.pdf >>>> >>>> Of course, the intention is not to point just to this specific revision. >>>> I don’t think we have a general guideline how to deal with documents that >>>> are on a regular update schedule, so simply going to the 2025 revision >>>> might be the right thing to do. >>>> >>>> (This is based on the belief that the new functionality in 16th edition >>>> relative to 11th edition does not extend the pattern language resulting >>>> from applying the suggested limitations in Appendix C.2 to the referenced >>>> edition. Updating these links does need some care…) >>> >>> 7) Both references have been updated. Please review the updated files and >>> let us know if they appear as desired. >>> >>>>> 19) <!-- [rfced] Does "earlier drafts" refer to earlier drafts of the I-D >>>>> that became this RFC or earlier versions of SDF (defined elsewhere)? >>>>> Perhaps this can be clarified? >>>>> >>>>> Current: >>>>> Appendix E. Some Changes From Earlier Drafts >>>>> --> >>>> >>>> The first (real) paragraph of Appendix E is actually intended to clarify >>>> this. >>>> To answer the question: All the published draft specs have been >>>> Internet-Drafts, see timeline on >>>> https://datatracker.ietf.org/doc/draft-ietf-asdf-sdf/ >>>> >>>> “Earlier drafts” of course is a bit confusing as the RFC-to-be no longer >>>> is a draft. >>>> Maybe “from drafts of this specification”? >>> >>> 8) We have updated the title of Appendix E as follows. Additionally, would >>> the following update clarify "previous revisions of SDF"? >>> >>> Current (Title of Appendix E): Some Changes from Earlier Draft Versions of >>> this Specification >>> >>> Current (Text in Appendix E): >>> Previous revisions of SDF have been in use for several years, and both >>> significant collections of older SDF models and older SDF conversion >>> tools are available today. >>> >>> Perhaps: >>> SDF, as defined in earlier drafts versions of this specification, have been >>> in use >>> for several years; both significant collections of older SDF models and >>> older SDF >>> conversion tools are available today. >>> >>>>> 20) <!-- [rfced] Please review each artwork element and let us know if >>>>> any >>>>> should be marked as sourcecode (or another element) instead. >>>>> >>>>> We updated Figure 5 from artwork to sourcecode. Please confirm that this >>>>> is >>>>> correct. >>>> >>>> When does a snippet (like the one about warning/danger in 2.3.2, which is >>>> marked as artwork) become sourcecode? >>>> Figure 5 is not really parsable per se, it needs to be integrated into >>>> context to *really* be sourcecode. >>>> Despite this, marking it as JSON sourcecode probably is OK (even if >>>> kramdown-rfc would complain that it isn’t really JSON, because it is a >>>> snippet, or actually two of them in one figure). >>>> >>>>> In addition, please consider whether the "type" attribute of any >>>>> sourcecode >>>>> element should be set and/or has been set correctly. >>>> >>>> [TO CHECK] >>>> >>>>> The current list of preferred values for "type" is available at >>>>> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. >>>>> If the current list does not contain an applicable type, feel free to >>>>> suggest additions for consideration. Note that it is also acceptable >>>>> to leave the "type" attribute not set. >>>> >>>> We haven’t really discussed so far whether there should be a sourcecode >>>> type specifically for SDF. >>>> By default, application/sdf+json is one (usually leaving out application/, >>>> so just “sdf+json”). >>>> We do have precedent for using structured syntax suffixes in >>>> yang-instance-data+json, so nothing appears to speak against use that. >>>> (There are 25 instances where this needs to be checked.) >>>> >>>>> --> >>>>> 21) <!-- [rfced] We note that these terms appear both with and without >>>>> <tt> >>>>> tags. Please review each instance of the terms below and ensure that >>>>> they >>>>> appear in the document as desired. If these terms should be formatted >>>>> consistently or follow a specific pattern, please let us know. >>>> >>>> [TO CHECK] >>>> >>>> Generally, when the sourcecode construct is meant, we use the typewriter >>>> font; when the concept is meant (“an array of string values”…), we don’t, >>>> and we then use the English capitalization (“Boolean”). >>>> >>>>> <tt>absolute-URI</tt> >>>>> <tt>array</tt> >>>>> <tt>boolean</tt> >>>>> <tt>curie</tt> >>>>> <tt>date-time</tt> (also appears in quotes) >>>>> <tt>defaultNamespace</tt> >>>>> <tt>description</tt> >>>>> <tt>enum</tt> >>>>> <tt>false</tt> >>>>> <tt>features</tt> (also appears in quotes) >>>>> <tt>format</tt> >>>>> <tt>info</tt> >>>>> <tt>integer</tt> >>>>> <tt>items</tt> >>>>> <tt>json-schema.org</tt> >>>>> <tt>label</tt> >>>>> <tt>length</tt> >>>>> <tt>named-sdq</tt> >>>>> <tt>namespace</tt> >>>>> <tt>null</tt> >>>>> <tt>number</tt> >>>>> <tt>object</tt> (also appears in quotes) >>>>> <tt>pattern</tt> (also appears in quotes) >>>>> <tt>properties</tt> (also appears in quotes) >>>>> <tt>referenceable-name</tt> (also appears in quotes) >>>>> <tt>required</tt> >>>>> <tt>sdfAction</tt> >>>>> <tt>sdfChoice</tt> >>>>> <tt>sdfData</tt> >>>>> <tt>sdfEvent</tt> >>>>> <tt>sdfObject</tt> >>>>> <tt>sdfOutputData</tt> >>>>> <tt>sdfProperty</tt> >>>>> <tt>sdfRef</tt> >>>>> <tt>sdfRequired</tt> (also appears in quotes) >>>>> <tt>sdfThing</tt> >>>>> <tt>sdf</tt> >>>>> <tt>sdfType</tt> >>>>> <tt>string</tt> >>>>> <tt>toggle</tt> (also appears in quotes) >>>>> <tt>true</tt> >>>>> <tt>type</tt> >>>>> <tt>unit(s)</tt> >>>>> <tt>value</tt> >>>>> --> >>>>> >>>>> >>>>> 22) <!-- [rfced] Please review the following terms and let us know if/how >>>>> we should update for consistency. >>>>> >>>>> a) Capitalization >>>> >>>> Continue here later… [TO CHECK] >>>> >>>>> Properties vs. properties >>>>> quality names vs. Quality Names >>>>> SDF model vs. SDF Model >>>>> >>>>> b) Spacing >>>>> data qualities vs. dataqualities >>>>> data quality vs. data quality >>>> >>>> ? >>> >>> 9) Apologies for the confusion. Here is the correct side-by-side comparison: >>> data quality vs. dataquality >>> >>>>> c) Other >>>>> base SDF vs. SDF base >>>>> --> >>>>> >>>>> >>>>> 23) <!-- [rfced] FYI - We have added expansions for abbreviations upon >>>>> first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review >>>>> each expansion in the document carefully to ensure correctness. >>>>> --> >>>> >>>> We’ll get to this in the diff reading phase. >>>> [TO CHECK] >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9880.txt >>> https://www.rfc-editor.org/authors/rfc9880.pdf >>> https://www.rfc-editor.org/authors/rfc9880.html >>> https://www.rfc-editor.org/authors/rfc9880.xml >>> >>> Diff files: >>> https://www.rfc-editor.org/authors/rfc9880-diff.html >>> https://www.rfc-editor.org/authors/rfc9880-rfcdiff.html (side by side) >>> https://www.rfc-editor.org/authors/rfc9880-auth48diff.html >>> https://www.rfc-editor.org/authors/rfc9880-auth48rfcdiff.html (side by side) >>> >>> For the AUTH48 status page, see: https://www.rfc-editor.org/auth48/rfc9880. >>> >>> Thank you! >>> >>> Madison Church >>> RFC Production Center >>> >>>>> Thank you. >>>> >>>> Thank you! >>>> >>>>> Madison Church and Sandy Ginoza >>>>> RFC Production Center >>>>> >>>>> >>>>> >>>>> >>>>> On Oct 6, 2025, at 9:57 PM, [email protected] wrote: >>>>> >>>>> *****IMPORTANT***** >>>>> >>>>> Updated 2025/10/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 >>>>> >>>>> * [email protected] (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). >>>>> >>>>> * [email protected], 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, >>>>> [email protected] 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/rfc9880.xml >>>>> https://www.rfc-editor.org/authors/rfc9880.html >>>>> https://www.rfc-editor.org/authors/rfc9880.pdf >>>>> https://www.rfc-editor.org/authors/rfc9880.txt >>>>> >>>>> Diff file of the text: >>>>> https://www.rfc-editor.org/authors/rfc9880-diff.html >>>>> https://www.rfc-editor.org/authors/rfc9880-rfcdiff.html (side by side) >>>>> >>>>> Diff of the XML: >>>>> https://www.rfc-editor.org/authors/rfc9880-xmldiff1.html >>>>> >>>>> >>>>> Tracking progress >>>>> ----------------- >>>>> >>>>> The details of the AUTH48 status of your document are here: >>>>> https://www.rfc-editor.org/auth48/rfc9880 >>>>> >>>>> Please let us know if you have any questions. >>>>> >>>>> Thank you for your cooperation, >>>>> >>>>> RFC Editor >>>>> >>>>> -------------------------------------- >>>>> RFC 9880 (draft-ietf-asdf-sdf-24) >>>>> >>>>> Title : Semantic Definition Format (SDF) for Data and >>>>> Interactions of Things >>>>> Author(s) : M. Koster, Ed., C. Bormann, Ed., A. Keränen >>>>> WG Chair(s) : Michael Richardson, Lorenzo Corneo >>>>> >>>>> Area Director(s) : Andy Newton, Orie Steele >>>>> >>>>> >>>> >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
