Additional Units for Sensor Measurement Lists (SenML)
draft-ietf-core-senml-more-units-06

[Ballot comment]
With everything going on I'm not going to have time to dig into this again before the new IESG is seated, so I've changed my ballot position to abstain. I do not think it is sound to publish this as-is with the reliance on a versioning scheme specified in an individual draft that does not have consensus, but I seem to be the only person who thinks that, so I will not stand in the way of publication.

[Ballot comment]
You have a typo in section 4: "obove", where "above" is meant.

+ + + + + + + + + + + + + + + + + + + +

The following are comments from Murray Kucherawy, incoming ART AD.  Murray is getting an early start on doing reviews, and I’m including his comments into my ballots during the overlap period before he’s officially an Area Director.

- - - - - - - - - - - - - - - - - - - -

Section 2: Just out of curiosity, why are some of the newly registered "VA"s all-caps and some all-lowercase?

Section 4: I'm a bit uneasy about saying the rules for this new registry are the same as for that older registry, with exceptions.  That means if the rules for the old registry change, someone needs to remember to consider whether the rules for the new registry should change in parallel, or whether something else should happen.  But if there's precedent for doing that, or the result is unambiguous, then we're probably fine.

Also, "six columns" followed by five bullets... I think I'd rather coax the scale/offset line apart.

Seems to me that Section 2 and all but the last two paragraphs of Section 4 should be in Section 7.  I've never seen an "IANA Considerations" section be a complete indirection like that.  But if we allow that, then OK.

[Ballot comment]
Balloting "No Objection" in the sense of "I trust the sponsoring AD, and have no time this ballot cycle to read the document." I have skimmed the document for typical ART-area gotchas, and found none.

[Ballot discuss]
I have some questions and comments about the text below, which seems like it creates significant scope for interoperability failures:

"Where the benefits of directly using a secondary unit in a SenML pack
  outweigh the above considerations, the use of secondary units in "u"
  fields MAY be enabled by indicating a new SenML version that
  specifically allows this and/or by using a field with a label name
  that ends with the "_" character ("must-understand" field) whose
  definition specifically allows this.  The definition of these
  versions and fields is outside the scope of the present
  specification; one such definition is proposed in
  [I-D.bormann-core-senml-versions]."

Do I understand correctly that this allows secondary units in (1) SenML packs that use some version number besides 10, and (2) SenML fields named with "_" that are in packs where the version number is 10? What is the motivation for providing two different mechanisms to signal that secondary units are in use? I.e., why isn't one or the other of these mechanisms sufficient?

Without defining either a new version that supports secondary units or fields with "_", I don't understand how this update to RFC 8428 is complete enough to be implementable. It says other versions and fields are out of scope, but don't some need to be defined in order for the normative MAY in this text to be actionable?

The label names registry policy is Expert Review, which does not require formal documentation of the registry entry. Where is the "definition [that] specifically allows this" expected to occur?

Presumably some implementations are already using SenML. What is an implementation supposed to do if it encounters a label name containing "_" that it does not understand in a version 10 pack?

It looks like this text went in a week ago but it's a pretty significant change to the extensibility story for SenML, so I'm wondering if the WG had a chance to come to consensus on it?

I'm not super familiar with SenML so apologies if the answers to some of these questions are obvious.

[Ballot comment]
'The unit "degrees" is in wide use in practice for plane angles (as in
  heading, bearing, etc.).  It is marked with an asterisk because the
  preferred coherent SI unit is radian ("rad").'

Is this asterisk notation meant to be common across all units that have this same property? If so, that seems worth specifying more generally, not just for degrees.

[Ballot comment]
I could not read the normative references to IEC-80000-6 and 13 as I do not have access . I trust the sponsoring AD to have gone through them and verified that the item number references are correct.

Also the following text in Section 3 seems very handwavy and not particularly helpful. Is this necessary?

"    It is not presently known to this author how
      the upcoming revision of IEC 80000-6 will update this, but it has
      became clear that there is strong interest in using this unit
      specifically for the imaginary content of complex power, reactive
      power [IEEE-1459]"

[Ballot discuss]
  +-----------+-------------------+-------+-----------+-----+---------+
  | secondary | description      | SenML |    scale | off | refer-  |
  | unit      |                  | unit  |          | set | ence    |
  +-----------+-------------------+-------+-----------+-----+---------+
  [...]
  | km        | kilometer        | km    |      1000 |  0 | RFCthis |

The associated SenML unit would be just 'm', not 'km'.

[Ballot comment]
I appreciate the compromise position that was achieved after the long
last-call discussions questioning the need for this work.  It seems like
a reasonably shaped "escape hatch" to me.

Section 2

I assume this is just a product of my personal background, but I am more
used to "mass density" than "mass concentration" for dimensionalities
such as kg/m3.

Section 3

  o  The Byte.  [IEC-80000-13] defines both the bit (item 13-9.b) and
      the byte (item 13-9.c, also called octet) as alternative names for
      the coherent unit one for the purpose of giving storage capacity
      and related quantities.  While the name octet is associated with

nit: is "one" misplaced, here?

Section 4

  o  scale, offset: two rational numbers, expressed in decimal
      (optionally, with a decimal exponent given) or as a fraction
      divided by a "/" character.

nit: doesn't "a fraction divided by a '/' character" involve two '/'
characters?  That is, "1/2" is a fraction, so "1/2 divided by a '/'
character" would be like "1/2/" or "1/2/2" or something nonsensical like
that.


It's a little surprising to see kibibyte and gigabyte defined but not
gibibyte.

  names.  Guidelines to the difference between units (which can go into
  the registry) and quantities are widely available, see for instance
  [RS] and [BIPM].

I suggest a parenthetical "(which cannot)" after "quantities".

  Where the benefits of directly using a secondary unit in a SenML pack
  outweigh the obove considerations, the use of secondary units in "u"

nit: s/obove/above/

  specifically allows this and/or by using a field with a label name
  that ends with the "_" character ("must-understand" field) that
  specifically allows this.  The definition of these versions and

I suggest "whose definition specifically allows this".

  fields is outside the scope of the present specification; one such
  definition is provided in [I-D.bormann-core-senml-versions].

nit: I suggest "proposed definition" or "possible definition", as
internet-drafts are "works in progress".

Section 5

  potential single point of failure.  Instead of pulling the registry
  in each individual instance of the code, the software update
  mechanism (or a similar, less frequently triggered mechanism) SHOULD
  be used to disseminate updated units registries obtained from IANA
  towards the instances via common repositories.

I like how this blandly assumes that a software update mechanism is
available.  Optimistic for the present-day world, but still probably the
right thing to say.
nit: as written, "less frequently triggered mechanism" means "less
frequently triggered than the software update mechanism", which I
suspect is not the intent.

Section 6

I suggest reiterating the implications of the requirements at the end of
section 4, namely, that use of new units is "fail-safe", in that an
implementation processing a pack using secondary units is guaranteed to
have been developed with an awareness of the risks of having multiple
units available for the same logical type.  (It is not, of course,
guaranteed to know about the specific secondary unit in question when
just the "SenML Version" check is used, in the same way that current
SenML applications are not guaranteed to know about units not in the
initial allocation from RFC 8428.)

  The security considerations of [RFC8428] apply.  The introduction of
  new measurement units poses no additional security considerations
  except from a possible potential for additional confusion about the
  proper unit to use.

Nitpicking, but I think there's a related risk of confusion in terms of
what quantity has been measured and is indicated in a SenML pack, as
alluded to by the previous mention of "trigger[ing] on the presence of a
quantity in a certain unit".

[Ballot comment]
The shepherd write-up says: "The document is intended for Standards Track and updates RFC8428." However, this document doesn't seem to update RFC8422. I assume this is correct and the write-up is a bit outdated? Just wanted to double-check...

[Ballot comment]
Short, simple, and easy to read while being useful.

Just a nit, please use a section on its own for acknowledgments (at least the HTML version does not show it was a section)

Thank you for the time writing this doc

-éric

I reviewed the units in Table 1 and they are OK for registration in the SenML units registry. However, "seconds", "degrees", and "kilograms" in the descriptions should not be in plural but in singular ("second", "degree", "kilogram"). The author acknowledged this was a typo and this will be fixed in the next revision of the draft.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-core-senml-more-units-02. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the SenML Units registry on the Sensor Measurement Lists (SenML) registry page located at:

https://www.iana.org/assignments/senml/

four early registrations in the registry will have their references changed to [ RFC-to-be ]:

Sym Description Type Reference
---+-------------------------------------+-----+-------------
B Byte (information content) float [ RFC-to-be ]
VA volt-ampere (Apparent Power) float [ RFC-to-be ]
var volt-ampere reactive (Reactive Power) float [ RFC-to-be ]
J/m joule per meter (Energy per distance) float [ RFC-to-be ]

Second, also in the SenML Units registry on the Sensor Measurement Lists (SenML) registry page located at:

https://www.iana.org/assignments/senml/

four new registrations will be added to the registry as follows:

Symbol: VAs
Description: volt-ampere seconds (Apparent Energy)
Type: float
Reference: [ RFC-to-be ]

Symbol: vars
Description: volt-ampere reactive seconds (Reactive Energy)
Type: float
Reference: [ RFC-to-be ]

Symbol: kg/m3
Description: kilograms per cubic meter (mass concentration)
Type: float
Reference: [ RFC-to-be ]

Symbol: deg
Description: degrees (angle)*
Type: float
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, a new registry is to be created called the Secondary Units registry. The new registry will be located on the Sensor Measurement Lists (SenML) registry page located at:

https://www.iana.org/assignments/senml/

The new registry will be managed via Expert Review as defined in RFC 8126. There are initial registrations in the new registry as follows:

+-----------+-------------------+-------+-----------+-----+-------------+
| secondary | description | SenML | scale | off | Reference |
| unit | | unit | | set | |
+-----------+-------------------+-------+-----------+-----+-------------+
| ms | millisecond | s | 1/1000 | 0 | [RFC-to-be] |
| min | minute | s | 60 | 0 | [RFC-to-be] |
| h | hour | s | 3600 | 0 | [RFC-to-be] |
| kW | kilowatt | W | 1000 | 0 | [RFC-to-be] |
| kVA | kilovolt-ampere | VA | 1000 | 0 | [RFC-to-be] |
| kvar | kilovar | var | 1000 | 0 | [RFC-to-be] |
| Ah | ampere-hour | C | 3600 | 0 | [RFC-to-be] |
| Wh | watt-hour | J | 3600 | 0 | [RFC-to-be] |
| kWh | kilowatt-hour | J | 3600000 | 0 | [RFC-to-be] |
| varh | var-hour | vars | 3600 | 0 | [RFC-to-be] |
| kvarh | kilovar-hour | vars | 3600000 | 0 | [RFC-to-be] |
| kVAh | kilovolt-ampere- | VAs | 3600000 | 0 | [RFC-to-be] |
| | hour | | | | |
| Wh/km | watts-hour per | J/m | 3.6 | 0 | [RFC-to-be] |
| | kilometer | | | | |
| KiB | kibibyte | B | 1024 | 0 | [RFC-to-be] |
| mV | millivolt | V | 1/1000 | 0 | [RFC-to-be] |
| mA | milliampere | A | 1/1000 | 0 | [RFC-to-be] |
| dBm | decibel | dBW | 1 | -30 | [RFC-to-be] |
| | (milliwatt) | | | | |
| ug/m3 | micrograms per | kg/m3 | 1e-9 | 0 | [RFC-to-be] |
| | cubic meter | | | | |
| mm/h | millimeter per | m/s | 1/3600000 | 0 | [RFC-to-be] |
| | hour | | | | |
| ppm | parts per million | / | 1e-6 | 0 | [RFC-to-be] |
| hPa | hectopascal | Pa | 100 | 0 | [RFC-to-be] |
| mm | millimeter | m | 1/1000 | 0 | [RFC-to-be] |
| km | kilometer | km | 1000 | 0 | [RFC-to-be] |
| km/h | kilometer per | m/s | 1/3.6 | 0 | [RFC-to-be] |
| | hour | | | | |
+-----------+-------------------+-------+-----------+-----+-------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-10-30):

From: The IESG
To: IETF-Announce
CC: core-chairs@ietf.org, draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , jaime@iki.fi, core@ietf.org, alexey.melnikov@isode.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Additional Units for SenML) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'Additional Units for SenML'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-10-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The Sensor Measurement Lists (SenML) media type supports the
  indication of units for a quantity represented.  This short document
  registers a number of additional unit names in the IANA registry for
  Units in SenML.  It also defines a registry for secondary units that
  cannot be in SenML's main registry as they are derived by linear
  transformation from units already in that registry; RFC 8428 is
  updated to also accept these units.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/ballot/


No IPR declarations have been submitted directly on this I-D.

## Shepherd Writeup

The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented.  This short document registers a number of additional unit names in the IANA registry for Units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry as they are derived by linear transformation from units already in that registry.

The SenML RFC (RFC8428) is updated to also accept these units.

### Summary

Document Shepherd: Jaime Jiménez
Area Director: Alexey Melnikov

This very short document essentially creates a sub-registry of derived SenML Units, which will be used by other SDOs like OMA.
The document is intended for Standards Track and updates RFC8428.

### Review and Consensus

Most of the discussions on this document dealt with which units to add and the formatting particularities for them. Part of the discussion was too on the authoritative sources for units, and the role of IANA on that. Ultimately the document has gone through multiple expert reviews and has been discussed on multiple IETF meetings.

### Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

### Other Points

The document creates a sub-registry for SenML and updates the SenML RFC (RFC8428).

### Checklist

[x] Means cleared.
[-] Means done but there are comments that should be checked by IESG.
[ ] Means not done.

- [x] Does the shepherd stand behind the document and think the document is ready for publication?
- [-] Is the correct RFC type indicated in the title page header?
The current draft says "Network Working Group" and should be changed to "CoRE Working Group"

- [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
- [x] Is the intent of the document accurately and adequately explained in the introduction?
- [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
- [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
- [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
- [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
- [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
- [-] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
This draft updates 8428 and is stated so in the Abstract and the header. Idinits warns on the update but it shouldn't be a problem. IMO the document is very clear in other sections about which are the updates to the current SenML registry. Please check if the current text is sufficiently explicit.  https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-core-senml-more-units-02.txt

- [x] If this is a "bis" document, have all of the errata been considered?
`Does not apply`

**IANA** Considerations:

- [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
- [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
- [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
- [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
- [-] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
The primary Designated Expert for the SenML Units is author of the document, but there is no specific mailing list as with core-parameters.

- [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
- [x]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?

## Shepherd Writeup

The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented.  This short document registers a number of additional unit names in the IANA registry for Units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry as they are derived by linear transformation from units already in that registry.

The SenML RFC (RFC8428) is updated to also accept these units.

### Summary

Document Shepherd: Jaime Jiménez
Area Director: Alexey Melnikov

This very short document essentially creates a sub-registry of derived SenML Units, which will be used by other SDOs like OMA.
The document is intended for Standards Track and updates RFC8428.

### Review and Consensus

Most of the discussions on this document dealt with which units to add and the formatting particularities for them. Part of the discussion was too on the authoritative sources for units, and the role of IANA on that. Ultimately the document has gone through multiple expert reviews and has been discussed on multiple IETF meetings.

### Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

### Other Points

The document creates a sub-registry for SenML and updates the SenML RFC (RFC8428).

### Checklist

[x] Means cleared.
[-] Means done but there are comments that should be checked by IESG.
[ ] Means not done.

- [x] Does the shepherd stand behind the document and think the document is ready for publication?
- [-] Is the correct RFC type indicated in the title page header?
The current draft says "Network Working Group" and should be changed to "CoRE Working Group"

- [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
- [x] Is the intent of the document accurately and adequately explained in the introduction?
- [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
- [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
- [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
- [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
- [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
- [-] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
This draft updates 8428 and is stated so in the Abstract and the header. Idinits warns on the update but it shouldn't be a problem. IMO the document is very clear in other sections about which are the updates to the current SenML registry. Please check if the current text is sufficiently explicit.  https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-core-senml-more-units-02.txt

- [x] If this is a "bis" document, have all of the errata been considered?
`Does not apply`

**IANA** Considerations:

- [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
- [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
- [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
- [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
- [-] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
The primary Designated Expert for the SenML Units is author of the document, but there is no specific mailing list as with core-parameters.

- [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
- [x]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?

## Shepherd Writeup

The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented.  This short document registers a number of additional unit names in the IANA registry for Units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry as they are derived by linear transformation from units already in that registry;

The SenML RFC (RFC8428) is updated to also accept these units.

### Summary

Document Shepherd: Jaime Jiménez
Area Director: Alexey Melnikov

This very short document essentially creates a sub-registry of derived SenML Units, which will be used by other SDOs like OMA.
The document is intended for Standards Track and updates RFC8428.

### Review and Consensus

Most of the discussions on this document dealt with which units to add and the formatting particularities for them. Part of the discussion was too on the authoritative sources for units, and the role of IANA on that. Ultimately the document has gone through multiple expert reviews and has been discussed on multiple IETF meetings.

### Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

### Other Points

The document creates a sub-registry for SenML and updates the SenML RFC (RFC8428).

### Checklist

[x] Means cleared.
[-] Means done but there are comments that should be checked by IESG.
[ ] Means not done.

- [x] Does the shepherd stand behind the document and think the document is ready for publication?
- [-] Is the correct RFC type indicated in the title page header?
The current draft says "Network Working Group" and should be changed to "CoRE Working Group"

- [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
- [x] Is the intent of the document accurately and adequately explained in the introduction?
- [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
- [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
- [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
- [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
- [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
- [-] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
This draft updates 8428 and is stated so in the Abstract and the header. Idinits warns on the update but it shouldn't be a problem. IMO the document is very clear in other sections about which are the updates to the current SenML registry. Please check if the current text is sufficiently explicit.  https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-core-senml-more-units-02.txt

- [x] If this is a "bis" document, have all of the errata been considered?
`Does not apply`

**IANA** Considerations:

- [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
- [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
- [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
- [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
- [-] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
A request has been made to "core-parameters", we are awaiting the response.

- [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
- [x]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?