Make references normative #4179
Conversation
There was a problem hiding this comment.
I'm not the expert on what should be normative, but these were intentionally marked as informative references since they're all TCP specific RFCs. The pipeACK reference in particular seems like an odd one.
If this is what the chairs want, then I'm ok with it as an editor, but these choices were intentional.
There was a problem hiding this comment.
I see what @gloinul is saying, but I also see some wiggle room in RFC 3967, Section 1.1:
- When a reference to an example is made, such a reference need not
be normative. For example, text such as "an algorithm such as the
one specified in [RFCxxxx] would be acceptable" indicates an
informative reference, since that cited algorithm is just one of
several possible algorithms that could be used.
I am also somewhat concerned that trying to get the downrefs into the registry is more likely to run into trouble (Sec 3)
This procedure should not be used if the proper step is to move the
document to which the reference is being made into the appropriate
category. It is not intended as an easy way out of normal process.
Rather, the procedure is intended for dealing with specific cases
where putting particular documents into the required category is
problematic and unlikely ever to happen.
Anyway, if we decide to proceed the PR is fine modulo my comment below.
| @@ -1133,8 +1133,8 @@ limits and so no advantage is gained by doing so. | |||
|
|
|||
| Endpoints choose the congestion controller that they use. Congestion controllers | |||
| respond to reports of ECN-CE by reducing their rate, but the response may vary. | |||
| Markings can be treated as equivalent to loss ({{?RFC3168}}), but other | |||
| responses can be specified, such as ({{?RFC8511}}) or ({{?RFC8311}}). | |||
| Markings can be treated as equivalent to loss ({{!RFC3168}}), but other | |||
There was a problem hiding this comment.
This section doesn't have normative language, so I don't see a need for these references to be normative.
|
Closing in favor of #4190 |
Closes #4178.