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]
