Internet-Draft needs additional sections.

[mickenordin]

All RFC:s must have these sections, that we don't have:

• Introduction
• Security considerations
• IANA Considerations
• References

[mickenordin]

Additionally, we have these warnings from https://author-tools.ietf.org/:

    (10) Expected a valid submissionType (stream) setting, one of IETF, IAB, IRTF, independent, editorial, but found None. Will use 'IETF'
    (645) Artwork too wide, reducing indentation from 3 to 0
    (638) Li too wide, reducing indentation from 0 to 0
    (567) Ul too wide, reducing indentation from 3 to 0
    (565) Section too wide, reducing indentation from 0 to 0
    (545) Section too wide, reducing indentation from 0 to 0
    (898) Artwork too wide, reducing indentation from 3 to 0
    (947) Artwork too wide, reducing indentation from 3 to 0
    (943) Section too wide, reducing indentation from 0 to 0
    (997) Artwork too wide, reducing indentation from 3 to 0
    (967) Section too wide, reducing indentation from 0 to 0
    (892) Section too wide, reducing indentation from 0 to 0
    (54) Middle too wide, reducing indentation from 0 to 0
    (645) Too long line found (L959), 14 characters longer than 72 characters:
    (645) Too long line found (L960), 12 characters longer than 72 characters:
    (645) Too long line found (L962), 12 characters longer than 72 characters:
    (645) Too long line found (L967), 25 characters longer than 72 characters:
    (645) Too long line found (L968), 4 characters longer than 72 characters:
    (645) Too long line found (L969), 2 characters longer than 72 characters:
    (645) Too long line found (L971), 20 characters longer than 72 characters:
    (898) Too long line found (L1313), 104 characters longer than 72 characters:
    (947) Too long line found (L1365), 31 characters longer than 72 characters:
    (947) Too long line found (L1366), 7 characters longer than 72 characters:
    (947) Too long line found (L1370), 4 characters longer than 72 characters:
    (947) Too long line found (L1372), 31 characters longer than 72 characters:
    (997) Too long line found (L1417), 17 characters longer than 72 characters:
    (997) Too long line found (L1418), 48 characters longer than 72 characters:
    (997) Too long line found (L1423), 24 characters longer than 72 characters: 

id-nits:

idnits 2.17.1 

draft-lopresti-open-cloud-mesh-04.txt:
-(1212): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(1228): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(1229): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == There are 7 instances of lines with non-ascii characters in the document.


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack a Security Considerations section.

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)

  ** There are 15 instances of too long lines in the document, the longest
     one being 104 characters in excess of 72.

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords -- however, there's a paragraph with a matching beginning.
     Boilerplate error?

     RFC 2119 keyword, line 175: '...erver is identified.  This MUST be the...'
     RFC 2119 keyword, line 248: '...Receiving Server MAY notify the Receiv...'
     RFC 2119 keyword, line 274: '...e Sending Server MAY offer the Sending...'
     RFC 2119 keyword, line 283: '...   MAY allow any internet user to type...'
     RFC 2119 keyword, line 290: '...e Sending Server MAY allow any interne...'
     (115 more instances...)


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     If a Receiving Server exposes the capability enforce-mfa, it
     indicates that it will try and comply with a MFA requirement set on a
     Share.  If the Sending Server trusts the Receiving Server, the Sending
     Server MAY set the requirement mfa-enforced on a Share, which the
     Receiving Server MUST honor.  A compliant Receiving Server that signals
     that it is MFA-capable MUST not allow access to a resource protected with
     the mfa-enforced requirement, if the Receiving Party has not provided a
     second factor to establish their identity with greater confidence.

  -- Found something which looks like a code comment -- if you have code
     sections in the document, please surround them with '' and
     '' lines.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Missing reference section? '0' on line 980 looks like a reference


     Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

Informational:

    (1045) Found non-ascii characters in an element that should be inspected to ensure they are intentional, in <t>: b'Our deepest thanks and appreciation go to the people who started the work on what would become this specification in 2015. In particular we want to thank (in alphabetical order) Guido Aben, Russell Albert, Holger Angenent, David Anto?, Hrachya Astsatryan, Kurt Bauer, Charles du Jeu, Andreas Eckey, David Gillard, Andranik Hayrapetyan Wahi, Christoph Herzog, David Jericho, Frank Karlitschek, Christian Kracher, Ralph Krimmel, Massimo Lamanna, Simon Leinen, Jari Miettinen, Jakub Moscicki, Frederik Orellana, Vlad Roman, Christian Schmitz, Woojin Seok, Rogier Spoor, Christian Sprajc, Peter Szegedi, Ron Trompert, Benedikt Wegmann and Johnatan Xu.'
    (1046) Found non-ascii characters in an element that should be inspected to ensure they are intentional, in <t>: b'We would also like to thank Ishank Arora, Gianmaria Del Monte, J?rn Friedrich Dreyer, Hugo Gonz?lez Labrador, Maxence Lange, Lovisa Lugneg?rd, Sandro Mesterheide, Antoon Prins and Bj?rn Schissle for their direct contributions to the specification.'
    (1047) Found non-ascii characters in an element that should be inspected to ensure they are intentional, in <t>: b"Over the years many more people have been involved in the development of OCM. We would like to thank all of them for their contributions, including Jean-Thomas Acquaviva, Samuel Alfageme Sainz, Karsten Asshauer, Miroslav Bauer, Felix B?hm, Maciej Brze?niak, Diogo Castro, Gavin Charles Kennedy, Jaros?aw Czub, Milan Danecek, Michael D'Silva, Lukasz Dutka, Pedro Ferreira, Renato Furter, Klaas Freitag, Raman Ganguly, Eva Gergely, Hilary Goodson, Daniel Halbe, Dave Heyns, Jan Holesovsky, Jan Hornicek, Carina Kemp, Fergus Kerins, Andreas Klotz, Matthias Knoll, Christian Kracher, Mario Lassnig, Claudius Laumanns, Anthony Leroy, Patrick Maier, Vladislav Makarenko, Anna Manou, Rita Meneses, Zheng Meyer-Zhao, Crystal Michelle Chua, Yoann Moulin, Daniel M?ller, Frederik M?ller, Rasmus Munk, Micha? Orzechowski, Jacek Pawel Kitowski, Iosif Peterfi, Alessandro Petraro, Rene Ranger, Angelo Romasanta, David Rousse, Carla Sauvanaud, Klaus Scheibenberger, Christian Schmitz, Marcin Sieprawski, Tilo Steiger, C.D. Tiwari, Alejandro Unger and Tom Wezepoel."

and

*** Latin-1 Supplement (Latin)
á: U+00E1    1 LATIN SMALL LETTER A WITH ACUTE
å: U+00E5    1 LATIN SMALL LETTER A WITH RING ABOVE
ö: U+00F6    3 LATIN SMALL LETTER O WITH DIAERESIS
ü: U+00FC    2 LATIN SMALL LETTER U WITH DIAERESIS
*** Latin Extended-A (Latin)
ł: U+0142    2 LATIN SMALL LETTER L WITH STROKE
š: U+0161    1 LATIN SMALL LETTER S WITH CARON
ź: U+017A    1 LATIN SMALL LETTER Z WITH ACUTE

[mickenordin]

https://authors.ietf.org/en/required-content
https://authors.ietf.org/iana-considerations
https://www.iana.org/help/protocol-registration#verbiage

[mickenordin]

PR for security considerations: #221

[glpatcern]

What remains now is the References section, where the IESG published a "reference": https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/