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

[Barry Leiba <[e-mail]>]

Thanks, Jacob!

Barry

On Thu, May 30, 2019 at 11:48 PM Jacob Hoffman-Andrews <[e-mail]> wrote:
>
>
> > — 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?
> Good point. Removed the <15 suggestion.
> >
> >     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?
> Changed to MUST NOT.
> > — Section 4.1.1 —
> >
> >     Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower
> >     case.
> >
> > Make it “non-zero-length”.
> Done.
> >
> > -- 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.
> Done.
> >
> > — 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”.
> Done.