Open ietf-svn-bot opened 5 years ago
@julian.reschke@gmx.de changed priority from medium
to trivial
@henrik@levkowetz.com changed status from new
to closed
@henrik@levkowetz.com changed resolution from ` to
invalid`
@henrik@levkowetz.com commented
This is a direct consequence of the preptool phase and its RFC 7998 requirement to set attributes to their default values. Setting consensus to its default value would result in an invalid combination of category and consensus.
I can remove the warning, but I don't see that doing so would make things better.
@julian.reschke@gmx.de commented
Setting consensus to its default value would result in an invalid combination of category and consensus.
Why would it be invalid, in particular for the source of an Internet-Draft? (citation please)
@julian.reschke@gmx.de commented
FWIW, the consensus attribute did not have a default in rfc2629.dtd. Maybe the best fix would be to remove the default in v3 as well.
@jyasskin@chromium.org changed status from closed
to reopened
@jyasskin@chromium.org changed resolution from invalid
to ``
@jyasskin@chromium.org commented
I also can't find a statement that category="std"
(or <seriesInfo status="standard">
) must have consensus="true"
. It's also incorrect for nearly all internet-drafts to claim that they have IETF consensus.
https://tools.ietf.org/html/draft-iab-rfc7991bis-01#section-2.44.2 does state that the default is "false".
@rjsparks@nostrum.com _changed status from reopened
to under_review
_
@rjsparks@nostrum.com commented
I agree with removing the default.
Jeffrey, I think the issue is an assumption about the semantics. What 7991 says is simply
2.45.2. "consensus" Attribute
Affects the generated boilerplate. Note that the values of "no" and
"yes" are deprecated and are replaced by "false" (the default) and
"true".
It is a flag in the grammar to tell the software whether to use the consensus oriented boilerplate when the context to use it makes sense. That is, it really has no meaning at all for Internet-Drafts since they have their own boilerplate that speaks nothing of consensus.
This is similar to the confusion around the consensus flag in the datatracker. All that means is whether to use consensus boilerplate if the document is published as an RFC.
In 7991bis, perhaps we can add words talking about what the semantics of the values are to help avoid this confusion. I don't think we should change the attribute name at this point, but we wouldn't be having this conversation if it was named "use_consensus_boilerplate_once_consensus_is_reached", or if we flipped its meaning and named it "never_use_consensus_boilerplate".
@jyasskin@chromium.org commented
@rjsparks: Yep, documenting that semantics, or a semantics like "this document either has or intends to seek consensus among the relevant body." would resolve my issue. Thanks!
@rjsparks@nostrum.com _changed status from under_review
to assigned
_
@rjsparks@nostrum.com changed owner from henrik@levkowetz.com
to ``
@rjsparks@nostrum.com changed status from assigned
to accepted
@rjsparks@nostrum.com _changed status from accepted
to under_review
_
@mt@lowentropy.net commented
While considering this change, please remove the warning. It is impossible to construct a document that doesn't generate this warning. That makes the warning only contribute to noise.
type_enhancement
| by julian.reschke@gmx.deThis is causing confusion, as the value is irrelevant when producing an internet draft.
Issue migrated from trac:420 at 2022-02-05 12:49:37 +0000