[lamps] Barry Leiba's No Objection on draft-ietf-lamps-rfc6844bis-06: (with COMMENT)

[Barry Leiba via Datatracker <[e-mail]>]

Barry Leiba has entered the following ballot position for
draft-ietf-lamps-rfc6844bis-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6844bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

— Section 4.1 —

   Tag Length: A single octet containing an unsigned integer specifying
   the tag length in octets.  The tag length MUST be at least 1 and
   SHOULD be no more than 15.

What happens if it’s more than 15?  What’s the interoperability issue, and how
would an implementor decide what to do with this requirement?

   Tags MAY contain US-ASCII characters 'a' through 'z', 'A' through
   'Z', and the numbers 0 through 9.  Tags SHOULD NOT contain any other
   characters.  Matching of tags is case insensitive.

Why “SHOULD NOT”, rather than “MUST NOT”?  Why might my implementation need to
use other characters, and what are the interoperability consequences of doing
so?

— Section 4.1.1 —

   Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower
   case.

Make it “non-zero-length”.

-- Section 4.4 —

   The iodef Property Tag takes a URL as its Property Value.  The URL
   scheme type determines the method used for reporting:

I presume that *only* the specified schemes (mailto, http, https) are allowed;
it would help to be explicit about that, lest someone get ideas to use sip or
some such.

— Section 5.6 —

   In practice, such an attack would be of minimal effect since any
   competent competitor that found itself unable to issue certificates
   due to lack of support for a Property marked critical SHOULD
   investigate the cause and report the reason to the customer.  The
   customer will thus discover that they had been deceived.

This doesn’t strike me as a BCP 14 “SHOULD”, but a normal English “should”.