On Sat, Dec 28, 2019 at 1:02 PM S Moonesamy <sm+ietf@xxxxxxxxxxxx> wrote:
>
> Section 1.1 of the draft states that it is about helping
> organizations to communicate information about their security
> disclosure policies. Is the field defined in Section 3.5.6 optional?
>
All fields are optional except for the "Contact" directive so at a
minimum, there is a way to contact the organization even without a
published policy.
> Section 3 sets a requirement for the file (security.txt) to be
> accessible via HTTP and references RFC 1945. Does it mean that the
> file must be accessible using HTTP/1/0?
>
Are you saying we should only allow HTTP 1.1 or 2.0? If so, I would
argue that HTTP 1.0 must be allowed.
> Section 3.1 specifies that the file would only apply to the domain in
> the URI. The examples given in that section states that the file
> also applies to to IPv4 and IPv6 addresses.
>
Being that it is referencing the URI format, the intent is the host as
per section 3.2.2 of RFC 3986. That would include both domain names
and IP addresses. We would need to clarify the language to match.
> There is a requirement in Section 3.3 for the line separator to be
> either CRLF or LF. Have the authors considered using only one
> convention for specifying the end of line?
>
> Have the authors considered line limits given that the specification
> defines a machine-parsable format?
>
There is an ongoing issue with some systems supporting CRLF and some
only LF, which is why we defined in a more fluid way. This is somewhat
similar to section 3.5 in RFC 7230 (HTTP 1.1):
Although the line terminator for the start-line and header fields is
the sequence CRLF, a recipient MAY recognize a single LF as a line
terminator and ignore any preceding CR.
> Why does the robustness principle require capital letters? (Section 4)?
>
I am not sure about this question - can you clarify?
> How will the designated expert determine whether a proposed
> registration (Section 7.2) provides value? What is the "wider
> Internet community"?
>
Well, from the various feedback received so far, there are certainly
strong opinions expressed whether the proposal itself and many of its
parts provide value at all :)
All jokes aside, we didn't want the registry to be a free for all via
"First Come First Served" on the one extreme, and be completely
restricted ("IESG Approval") on the other extreme. We felt an expert
review would provide the right amount of oversight so something crazy
doesn't get shoved into the registry. A good example of this would be
a proposal of a directive indicating that the researcher doesn't have
permission to test any of the assets - something we couldn't reach
consensus on earlier. This would be something that would benefit from
a review by someone versed in security and standards.
The wider community would be the researchers and organizations using
this format.
> How should "MAY assume that English is the default language to be
> used" be interpreted (Section 3.5.7)? RFC 2777 states that
> "i-default" is not a specific language.
>
The reference is to the following language in RFC 2277:
When human-readable text must be presented in a context where the
sender has no knowledge of the recipient's language preferences (such
as login failures or E-mailed warnings, or prior to language
negotiation), text SHOULD be presented in Default Language.
And:
Messages in Default Language MUST be understandable by an English-
speaking person, since English is the language which, worldwide, the
greatest number of people will be able to get adequate help in
interpreting when working with computers.
Note that negotiating English is NOT the same as Default Language;
Default Language is an emergency measure in otherwise unmanageable
situations.
Basically, we wanted to come up with a safe default and that was the
best reference that seemed to indicate that English may be used in
this case.
> As an overall comment, there are a lot of requirements and
> recommendations (please see RFC 2119) in the draft. There is, for
> example, a restatement of a requirement: "The value MUST follow the
> URI syntax described in [RFC3986]. This means that "mailto" and
> "tel" URI schemes MUST be used when specifying email addresses and
> telephone numbers, as defined in [RFC6068] and [RFC3966]". Does that
> comply with the ABNF defined in Section 5?
>
The earlier versions of the draft allowed contact information without
the full URI which is why the current draft calls this out. In the
ABNF grammar (section 5), URI references RFC 3986. The assumption is
that this reference also includes the IANA and all relevant RFCs that
define URIs, since it would be impractical to list all of them out in
our draft. Perhaps, the use of RFC 2119 keywords in this specific
section may not be needed, since the MUST for URI syntax would be
sufficient.
Thanks
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
