Re: [Gen-art] [tram] Genart telechat review of draft-ietf-tram-stunbis-16

[Marc Petit-Huguenin]

On 05/14/2018 07:18 PM, Dale R. Worley wrote:
> Marc Petit-Huguenin  writes:
>>>To do that, it follows the
>>>identification procedures defined in [RFC6125], with a certificate
>>>containing an identifier of type DNS-ID or CN-ID, eventually with
>>>wildcards, but not of type SRV-ID or URI-ID.
>>>
>>> The meaning of "eventually" here is not clear.
>>
>> Rephrased as:
>>
>>[...]
>>containing an identifier of type DNS-ID or CN-ID, eventually with a
>>wildcard character as leftmost label, but not of type SRV-ID or URI-
>>[...]
> 
> I have some doubt about the use of "eventually" here.  As I use it,
> "eventually" means that the thing will happen at some unspecified time
> in the future.  Wiktionary gives this meaning also.  But I looked
> "eventually" up in my paper dictionary, and it also has the meaning
> "dependent on circumstance; contingent".
> 
> In this context, I do not see how the meaning about unspecified future
> time works.  But perhaps you mean that having a wildcard character as
> leftmost label is contingent?  That meaning works.  But in that case, I
> would find "optionally" to be clearer.  (And Google Translate says that
> "éventuellement" can be translated into English as either "eventually"
> or "optionally", although it provides "facultativement" as the first
> translation into French of "optionally".)
> 
> You may wish to consult the RFC Editor about this.
> 

No, you are right, I was using "eventually" incorrectly all this time.  I 
changed "eventually" to "optionally" in my copy.

Thanks.

-- 
Marc Petit-Huguenin
Email: m...@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug



signature.asc
Description: OpenPGP digital signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [tram] Genart telechat review of draft-ietf-tram-stunbis-16

[Dale R. Worley]

Marc Petit-Huguenin  writes:
>>To do that, it follows the
>>identification procedures defined in [RFC6125], with a certificate
>>containing an identifier of type DNS-ID or CN-ID, eventually with
>>wildcards, but not of type SRV-ID or URI-ID.
>> 
>> The meaning of "eventually" here is not clear.
>
> Rephrased as:
>
>[...]
>containing an identifier of type DNS-ID or CN-ID, eventually with a
>wildcard character as leftmost label, but not of type SRV-ID or URI-
>[...]

I have some doubt about the use of "eventually" here.  As I use it,
"eventually" means that the thing will happen at some unspecified time
in the future.  Wiktionary gives this meaning also.  But I looked
"eventually" up in my paper dictionary, and it also has the meaning
"dependent on circumstance; contingent".

In this context, I do not see how the meaning about unspecified future
time works.  But perhaps you mean that having a wildcard character as
leftmost label is contingent?  That meaning works.  But in that case, I
would find "optionally" to be clearer.  (And Google Translate says that
"éventuellement" can be translated into English as either "eventually"
or "optionally", although it provides "facultativement" as the first
translation into French of "optionally".)

You may wish to consult the RFC Editor about this.

Dale

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [tram] Genart telechat review of draft-ietf-tram-stunbis-16

[Marc Petit-Huguenin]

Thank you.  See inline.

On 05/03/2018 06:32 PM, Dale R. Worley wrote:
> Marc Petit-Huguenin  writes:
>> Because we believe that this is a problem that will become more and
>> more frequent, we decided to fix it, at least for new implementations.
>>
>> Please have a look at -17 and let us know what you think of it.
> 
> It looks like you've handled the problem of a NAT that changes the
> address family of the request as well as can be done.
> 
> You've clarified the question of how the security feature bits are
> assigned, although I note that -16 and -17 assign the bits differently
> than versions -7 through -15 do.
> 
> That completes all of the significant issues from my review of -16.
> 
> And there are some nits:
> 
> 6.2.1.  Sending over UDP or DTLS-over-UDP
> 
>SHOULD be greater or equal than 500 ms.
> 
> s/equal than/equal to/.

Applied.

> 
> 6.2.3.  Sending over TLS-over-TCP or DTLS-over-UDP
> 
>To do that, it follows the
>identification procedures defined in [RFC6125], with a certificate
>containing an identifier of type DNS-ID or CN-ID, eventually with
>wildcards, but not of type SRV-ID or URI-ID.
> 
> The meaning of "eventually" here is not clear.

Rephrased as:

   [...]
   containing an identifier of type DNS-ID or CN-ID, eventually with a
   wildcard character as leftmost label, but not of type SRV-ID or URI-
   [...]

> 
> 14.  STUN Attributes
> 
>The
>padding bits MUST be set to zero on sending and must be ignored by
>the receiver.
> 
> I assume the latter "must" is supposed to be "MUST".

Fixed.

> 
> 14.13.  UNKNOWN-ATTRIBUTES
> 
>Note:  In [RFC3489], this field was padded to 32 by duplicating the
>   last attribute.  In this version of the specification, thPetriNet
>   m --> PetriNet m --> e normal padding rules for attributes are
>   used instead.
> 
> I assume that "thPetriNet m --> PetriNet m --> e" is intended to be
> "the".

Fixed.

> 
> Appendix C.  Release notes
> 
> Section C.8 has the same contents as section C.9, but section C.9 has
> the same title as section C.10.  (Although section C will be removed
> before publication, so it's not important.)

Fixed.

-- 
Marc Petit-Huguenin
Email: m...@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug



signature.asc
Description: OpenPGP digital signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [tram] Genart telechat review of draft-ietf-tram-stunbis-16

[Dale R. Worley]

Marc Petit-Huguenin  writes:
> Because we believe that this is a problem that will become more and
> more frequent, we decided to fix it, at least for new implementations.
>
> Please have a look at -17 and let us know what you think of it.

It looks like you've handled the problem of a NAT that changes the
address family of the request as well as can be done.

You've clarified the question of how the security feature bits are
assigned, although I note that -16 and -17 assign the bits differently
than versions -7 through -15 do.

That completes all of the significant issues from my review of -16.

And there are some nits:

6.2.1.  Sending over UDP or DTLS-over-UDP

   SHOULD be greater or equal than 500 ms.

s/equal than/equal to/.

6.2.3.  Sending over TLS-over-TCP or DTLS-over-UDP

   To do that, it follows the
   identification procedures defined in [RFC6125], with a certificate
   containing an identifier of type DNS-ID or CN-ID, eventually with
   wildcards, but not of type SRV-ID or URI-ID.

The meaning of "eventually" here is not clear.

14.  STUN Attributes

   The
   padding bits MUST be set to zero on sending and must be ignored by
   the receiver.

I assume the latter "must" is supposed to be "MUST".

14.13.  UNKNOWN-ATTRIBUTES

   Note:  In [RFC3489], this field was padded to 32 by duplicating the
  last attribute.  In this version of the specification, thPetriNet
  m --> PetriNet m --> e normal padding rules for attributes are
  used instead.

I assume that "thPetriNet m --> PetriNet m --> e" is intended to be
"the".

Appendix C.  Release notes

Section C.8 has the same contents as section C.9, but section C.9 has
the same title as section C.10.  (Although section C will be removed
before publication, so it's not important.)

Dale

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [tram] Genart telechat review of draft-ietf-tram-stunbis-16

[Marc Petit-Huguenin]

On 04/16/2018 02:49 PM, Marc Petit-Huguenin wrote:
> Thanks again for the review.  Comments inline.
> 
> On 03/30/2018 04:45 AM, Dale Worley wrote:
>> Reviewer: Dale Worley
>> Review result: Ready with Nits
>>
>> I am the assigned Gen-ART reviewer for this draft.  The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed by
>> the IESG for the IETF Chair.  Please wait for direction from your
>> document shepherd or AD before posting a new version of the draft.
>>
>> For more information, please see the FAQ at
>> .
>>
>> Document:  draft-ietf-tram-stunbis-16
>> Reviewer:  Dale R. Worley
>> Review Date:  2018-03-29
>> IETF LC End Date:  2018-02-20
>> IESG Telechat date:  2018-04-19
>>
>> Summary:
>>
>>This draft is basically ready for publication, but has nits
>>that should be fixed before publication.
>>
>> The only interesting item concerns section 17.1, where the assignment
>> of meanings to bits in the "security feature set" value is different
>> from the assignment in -16.  This is either non-upward-compatible with
>> -16, or there is an error in either -16 or -17.
>>
>> --
>>
>> There is an issue that shows up in several places:  The NAT may
>> forward the request using an IP family that is different from the IP
>> family that it received the request using.  This means that the
>> "source IP family of the request" may depend on whether one is
>> speaking of the client or the server.  The draft is cognizant of this,
>> and mentions its consequences in sections 6.3.3 and 12.  But this also
>> has consequences for ALTERNATE-SERVER:  Section 14.15 says "The IP
>> address family MUST be identical to that of the source IP address of
>> the request." even though that family might not be usable by the
>> client.  The draft doesn't seem to explicitly say that this comes from
>> address-switching by the NAT.  It would help if there was a
>> higher-level discussion of this matter, pointing to the various
>> consequences.
> 
> I still do not have text about that but, as this is blocking this response 
> since 2 weeks now, I am releasing it as is and will come back to that after I 
> process the other reviews that accumulated during my time traveling around 
> Europe.
> 

Because we believe that this is a problem that will become more and more 
frequent, we decided to fix it, at least for new implementations.

Please have a look at -17 and let us know what you think of it.

Thanks.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [tram] Genart telechat review of draft-ietf-tram-stunbis-16

[Dale R. Worley]

Marc Petit-Huguenin  writes:
> I did some research and you were right, starting from the left side is
> more common.  My main counter-example is in fact in STUN itself as
> figure 3:
>
>0 1
>2  3  4 5 6 7 8 9 0 1 2 3 4 5
>   +--+--+-+-+-+-+-+-+-+-+-+-+-+-+
>   |M |M |M|M|M|C|M|M|M|C|M|M|M|M|
>   |11|10|9|8|7|1|6|5|4|0|3|2|1|0|
>   +--+--+-+-+-+-+-+-+-+-+-+-+-+-+
[...]

That's an interesting complication.  As you've noted, it's nearly
universal for IETF documents to use big-endian numbering.

But the above example is paradoxical, as the bits are numbered in a
big-endian way across the top of the diagram, from 2 to 15, while being
numbered in a littl-endian way is the boxes, from 11 to 0.  I had
noticed that the top numbers didn't start at 0 (so I didn't count this
figure in my "8 out of 10"), but I overlooked the numbers in the boxes.

Dale

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [tram] Genart telechat review of draft-ietf-tram-stunbis-16

[Marc Petit-Huguenin]

On 04/22/2018 07:12 PM, Dale R. Worley wrote:
> My apologies for not responding to this sooner:
> 
> Marc Petit-Huguenin  writes:
>>> 17.1.  STUN Security Features Registry
>>>
>>>A STUN Security Feature set defines 24 bit as flags.
>>>
>>>IANA is requested to create a new registry containing the STUN
>>>Security Features that are protected by the bid down attack
>>>prevention mechanism described in section Section 9.2.1.
>>>
>>>The initial STUN Security Features are:
>>>
>>>Bit 0: Password algorithms
>>>Bit 1: Username anonymity
>>>Bit 2-23: Unassigned
>>>
>>> Beware that the assignment of features to bits in the security feature
>>> value has changed!  Bit numbers are assigned from the left/high-order
>>> end -- see figure 2 in the draft.  So the *values* for these bits are:
>>>
>>> 0x40   Bit 0: Password algorithms
>>> 0x20   Bit 1: Username anonymity
>>>
>>> But the values assigned in -15 were:
>>>
>>>0x01: Password algorithms
>>>0x02: Username anonymity
>>
>> Hmm, that was not the intent, and not how I read the text. Even in
>> Figure 2 less significant bits are on the right.  So the intent is
>> real tat bit0=0x001, bit1 = 0x002, and so on.  All we do is about
>> interoperability, so I added some text that makes that less ambiguous.
> 
> (The latest posted version is still -16, so I haven't seen the changes
> you refer to.)

Sorry, I should have pasted the text.  But the point is moot, see below.

> 
> In reference to the statements:
> 
>>>The initial STUN Security Features are:
>>>
>>>Bit 0: Password algorithms
>>>Bit 1: Username anonymity
>>>Bit 2-23: Unassigned
> 
> I've skimmed the text again, and it appears that this passage is the
> only one that allocates the functions "password algorithms" and
> "username anonymity" to specific bits of the security feature value.
> Thus, it's critical what "bit 0" means in this context.
> 
> Searching for "0" in the document, I can find no outright definition of
> the meaning of "bit 0".  However, there are 10 figures in the document,
> and 8 of them show the numbering of the bits of various fields, with bit
> "0" being the *high-order*, *most-significant*, "left"-most bit of the
> field, bit "1" the next-highest-order bit, etc.  This numbering seems to
> be conventional in RFCs.

I did some research and you were right, starting from the left side is more 
common.  My main counter-example is in fact in STUN itself as figure 3:

   0 1
   2  3  4 5 6 7 8 9 0 1 2 3 4 5
  +--+--+-+-+-+-+-+-+-+-+-+-+-+-+
  |M |M |M|M|M|C|M|M|M|C|M|M|M|M|
  |11|10|9|8|7|1|6|5|4|0|3|2|1|0|
  +--+--+-+-+-+-+-+-+-+-+-+-+-+-+

And as the base64 encoding is done on an array of bytes and not an integer, it 
is in fact simpler to define it that way. The new text in section now reads:

   Bits are assigned starting from the most significant side of the bit
   set, so Bit 0 is the leftmost bit and Bit 23 the rightmost bit.

I also updated the example in Appendix B.1.

-- 
Marc Petit-Huguenin
Email: m...@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug




signature.asc
Description: OpenPGP digital signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [tram] Genart telechat review of draft-ietf-tram-stunbis-16

[Dale R. Worley]

My apologies for not responding to this sooner:

Marc Petit-Huguenin  writes:
>> 17.1.  STUN Security Features Registry
>> 
>>A STUN Security Feature set defines 24 bit as flags.
>> 
>>IANA is requested to create a new registry containing the STUN
>>Security Features that are protected by the bid down attack
>>prevention mechanism described in section Section 9.2.1.
>> 
>>The initial STUN Security Features are:
>> 
>>Bit 0: Password algorithms
>>Bit 1: Username anonymity
>>Bit 2-23: Unassigned
>> 
>> Beware that the assignment of features to bits in the security feature
>> value has changed!  Bit numbers are assigned from the left/high-order
>> end -- see figure 2 in the draft.  So the *values* for these bits are:
>> 
>> 0x40   Bit 0: Password algorithms
>> 0x20   Bit 1: Username anonymity
>> 
>> But the values assigned in -15 were:
>> 
>>0x01: Password algorithms
>>0x02: Username anonymity
>
> Hmm, that was not the intent, and not how I read the text. Even in
> Figure 2 less significant bits are on the right.  So the intent is
> real tat bit0=0x001, bit1 = 0x002, and so on.  All we do is about
> interoperability, so I added some text that makes that less ambiguous.

(The latest posted version is still -16, so I haven't seen the changes
you refer to.)

In reference to the statements:

>>The initial STUN Security Features are:
>> 
>>Bit 0: Password algorithms
>>Bit 1: Username anonymity
>>Bit 2-23: Unassigned

I've skimmed the text again, and it appears that this passage is the
only one that allocates the functions "password algorithms" and
"username anonymity" to specific bits of the security feature value.
Thus, it's critical what "bit 0" means in this context.

Searching for "0" in the document, I can find no outright definition of
the meaning of "bit 0".  However, there are 10 figures in the document,
and 8 of them show the numbering of the bits of various fields, with bit
"0" being the *high-order*, *most-significant*, "left"-most bit of the
field, bit "1" the next-highest-order bit, etc.  This numbering seems to
be conventional in RFCs.

Thus, I recommend that if you really want to persist in calling the
low-order bit of the security features field "bit 0", you should explain
that very clearly in section 17.1.

Dale

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [tram] Genart telechat review of draft-ietf-tram-stunbis-16

[Alissa Cooper]

Dale, thanks for your reviews. Marc, thanks for your response. I have entered a 
No Objection ballot.

Alissa

> On Apr 16, 2018, at 5:49 PM, Marc Petit-Huguenin  
> wrote:
> 
> Thanks again for the review.  Comments inline.
> 
> On 03/30/2018 04:45 AM, Dale Worley wrote:
>> Reviewer: Dale Worley
>> Review result: Ready with Nits
>> 
>> I am the assigned Gen-ART reviewer for this draft.  The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed by
>> the IESG for the IETF Chair.  Please wait for direction from your
>> document shepherd or AD before posting a new version of the draft.
>> 
>> For more information, please see the FAQ at
>> .
>> 
>> Document:  draft-ietf-tram-stunbis-16
>> Reviewer:  Dale R. Worley
>> Review Date:  2018-03-29
>> IETF LC End Date:  2018-02-20
>> IESG Telechat date:  2018-04-19
>> 
>> Summary:
>> 
>>   This draft is basically ready for publication, but has nits
>>   that should be fixed before publication.
>> 
>> The only interesting item concerns section 17.1, where the assignment
>> of meanings to bits in the "security feature set" value is different
>> from the assignment in -16.  This is either non-upward-compatible with
>> -16, or there is an error in either -16 or -17.
>> 
>> --
>> 
>> There is an issue that shows up in several places:  The NAT may
>> forward the request using an IP family that is different from the IP
>> family that it received the request using.  This means that the
>> "source IP family of the request" may depend on whether one is
>> speaking of the client or the server.  The draft is cognizant of this,
>> and mentions its consequences in sections 6.3.3 and 12.  But this also
>> has consequences for ALTERNATE-SERVER:  Section 14.15 says "The IP
>> address family MUST be identical to that of the source IP address of
>> the request." even though that family might not be usable by the
>> client.  The draft doesn't seem to explicitly say that this comes from
>> address-switching by the NAT.  It would help if there was a
>> higher-level discussion of this matter, pointing to the various
>> consequences.
> 
> I still do not have text about that but, as this is blocking this response 
> since 2 weeks now, I am releasing it as is and will come back to that after I 
> process the other reviews that accumulated during my time traveling around 
> Europe.
> 
>> 
>> 3.  Terminology
>> 
>> This section needs to be updated to reference RFC 8174, including
>> updating the paragraph (especially the final two lines) to read as
>> specified in RFC 8174:
>> 
>>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>>  NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
>>  "MAY", and "OPTIONAL" in this document are to be interpreted as
>>  described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
>>  appear in all capitals, as shown here.
> 
> Updated.
> 
>> 
>> 6.2.2.  Sending over TCP or TLS-over-TCP
>> 
>>   o  if multiplexing other application protocols over that port, has
>>  finished using that other protocol, and
>> 
>> The two clauses don't match in grammatical number.  This should be
>> either
>> 
>>   o  if multiplexing other application protocols over that port, has
>>  finished using those other protocols, and
>> 
>> or
>> 
>>   o  if multiplexing another application protocol over that port, has
>>  finished using that other protocol, and
> 
> Updated using the former.
> 
>> 
>> 9.2.4.  Receiving a Request
>> 
>>  *  If the request contains neither PASSWORD-ALGORITHMS nor
>> PASSWORD- ALGORITHM, then the request is processed as though
>> PASSWORD- ALGORITHM were MD5 (Note that if the original
>> PASSWORD-ALGORITHMS attribute did not contain MD5, this will
>> result in a 400 Bad Request in a later step below).
>> 
>> There are two places where s/PASSWORD- ALGORITHM/PASSWORD-ALGORITHM/.
> 
> Already fixed following a previous review.
> 
>> 
>> 14.3.  USERNAME
>> 
>>   The value of USERNAME is a variable-length value containing the
>>   authentication username.  It MUST contain a UTF-8 [RFC3629] encoded
>>   sequence of less than 509 bytes, and MUST have been processed using
>>   the OpaqueString profile [RFC8265].  A compliant implementation MUST
>>   be able to parse UTF-8 encoded sequence of less than 763.
>> 
>> The final "763" is grammatically incorrect.  I think you intend
>> s/763/763 bytes/, to parallel other items.
> 
> Fixed.
> 
>> 
>> 14.4.  USERHASH
>> 
>>   userhash = SHA-256(Opaque(username) ":" Opaque(realm))
>> 
>> I believe that this should be
>> 
>>   userhash = SHA-256(OpaqueString(username) ":" OpaqueString(realm))
> 
> Fixed.
> 
>> 
>> 14.5.  MESSAGE-INTEGRITY
>> 
>>   Petit-Huguenin, et al.  Expires September 6, 2018 [Page 40]
>> 
>>   Internet-Draft Session Traversal Utilities for NAT (STUN) Ma

Re: [Gen-art] [tram] Genart telechat review of draft-ietf-tram-stunbis-16

[Marc Petit-Huguenin]

Thanks again for the review.  Comments inline.

On 03/30/2018 04:45 AM, Dale Worley wrote:
> Reviewer: Dale Worley
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft.  The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed by
> the IESG for the IETF Chair.  Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> .
> 
> Document:  draft-ietf-tram-stunbis-16
> Reviewer:  Dale R. Worley
> Review Date:  2018-03-29
> IETF LC End Date:  2018-02-20
> IESG Telechat date:  2018-04-19
> 
> Summary:
> 
>This draft is basically ready for publication, but has nits
>that should be fixed before publication.
> 
> The only interesting item concerns section 17.1, where the assignment
> of meanings to bits in the "security feature set" value is different
> from the assignment in -16.  This is either non-upward-compatible with
> -16, or there is an error in either -16 or -17.
> 
> --
> 
> There is an issue that shows up in several places:  The NAT may
> forward the request using an IP family that is different from the IP
> family that it received the request using.  This means that the
> "source IP family of the request" may depend on whether one is
> speaking of the client or the server.  The draft is cognizant of this,
> and mentions its consequences in sections 6.3.3 and 12.  But this also
> has consequences for ALTERNATE-SERVER:  Section 14.15 says "The IP
> address family MUST be identical to that of the source IP address of
> the request." even though that family might not be usable by the
> client.  The draft doesn't seem to explicitly say that this comes from
> address-switching by the NAT.  It would help if there was a
> higher-level discussion of this matter, pointing to the various
> consequences.

I still do not have text about that but, as this is blocking this response 
since 2 weeks now, I am releasing it as is and will come back to that after I 
process the other reviews that accumulated during my time traveling around 
Europe.

> 
> 3.  Terminology
> 
> This section needs to be updated to reference RFC 8174, including
> updating the paragraph (especially the final two lines) to read as
> specified in RFC 8174:
> 
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
>   "MAY", and "OPTIONAL" in this document are to be interpreted as
>   described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
>   appear in all capitals, as shown here.

Updated.

> 
> 6.2.2.  Sending over TCP or TLS-over-TCP
> 
>o  if multiplexing other application protocols over that port, has
>   finished using that other protocol, and
> 
> The two clauses don't match in grammatical number.  This should be
> either
> 
>o  if multiplexing other application protocols over that port, has
>   finished using those other protocols, and
> 
> or
> 
>o  if multiplexing another application protocol over that port, has
>   finished using that other protocol, and

Updated using the former.

> 
> 9.2.4.  Receiving a Request
> 
>   *  If the request contains neither PASSWORD-ALGORITHMS nor
>  PASSWORD- ALGORITHM, then the request is processed as though
>  PASSWORD- ALGORITHM were MD5 (Note that if the original
>  PASSWORD-ALGORITHMS attribute did not contain MD5, this will
>  result in a 400 Bad Request in a later step below).
> 
> There are two places where s/PASSWORD- ALGORITHM/PASSWORD-ALGORITHM/.

Already fixed following a previous review.

> 
> 14.3.  USERNAME
> 
>The value of USERNAME is a variable-length value containing the
>authentication username.  It MUST contain a UTF-8 [RFC3629] encoded
>sequence of less than 509 bytes, and MUST have been processed using
>the OpaqueString profile [RFC8265].  A compliant implementation MUST
>be able to parse UTF-8 encoded sequence of less than 763.
> 
> The final "763" is grammatically incorrect.  I think you intend
> s/763/763 bytes/, to parallel other items.

Fixed.

> 
> 14.4.  USERHASH
> 
>userhash = SHA-256(Opaque(username) ":" Opaque(realm))
> 
> I believe that this should be
> 
>userhash = SHA-256(OpaqueString(username) ":" OpaqueString(realm))

Fixed.

> 
> 14.5.  MESSAGE-INTEGRITY
> 
>Petit-Huguenin, et al.  Expires September 6, 2018 [Page 40]
> 
>Internet-Draft Session Traversal Utilities for NAT (STUN) March 2018
> 
> This bit of text appears as body text in the middle of page 40.

Already fixed following a previous review.

> 
> 14.6.  MESSAGE-INTEGRITY-SHA256
> 
>The MESSAGE-INTEGRITY-SHA256 attribute contains an HMAC-SHA256
>[RFC2104] of the STUN message.  The MESSAGE-INTEGRITY-SHA256
>