|
On 9/12/18 5:25 PM, Spencer Dawkins at
IETF wrote:
I have lots of opinions about things, some of which
are useful, but this isn't a topic I'm smart about, so I'm
mostly following the discussion, to help us do the right thing,
whatever that turns out to be.
On Wed, Sep 12, 2018 at 6:19 PM Heather
Flanagan (RFC Series Editor) < rse@xxxxxxxxxxxxxx>
wrote:
On
9/12/18 7:45 AM, Paul Hoffman wrote:
> On 12 Sep 2018, at 7:33, Sean Turner wrote:
>
>>> The specific reasons that a given RFC updates
another should be
>>> described in the abstract and body of the new
RFC. The level of
>>> detail may differ between the abstract and
the body; typically an
>>> abstract should contain enough detail to help
readers decide if they
>>> need to read the rest of the RFC. The body
should contain enough
>>> detail for readers to fully understand the
nature of the update.
>>
>> I like to say that I hate the whole list the
reasons why in the
>> abstract. I understand that we also say what
RFCs are updated in the
>> abstract because there are some tools that don’t
display the
>> meta-data and that we do it so readers will know
whether or not to
>> keep reading. That’s great for an RFC that’s
updating one RFC and it
>> keeps in line with keep the abstract succinct
plus the boiler plate
>> on the 1st page. But, when you’ve got an RFC
that’s going to update
>> say eight (8) RFCs that this is kinda crazy.
>
> Sean's exactly right here. Having to add a lot of new
text to the
> abstract basically makes it a mini-introduction.
Instead, please
> consider:
>
> The specific reasons that a given RFC updates another
should be
> described near the top of the Introduction section of
the new RFC,
> possibly in its own sub-section. This text should
contain enough
> detail to help readers who are familiar with the
specification that is
> being updated to decide if they need to read the rest
of this newer
> RFC. This text must contain enough detail for readers
to fully
> understand the nature of the update.
I think this is a very reasonable approach. The abstract
should
definitely be succinct, and text explaining the
relationship of one RFC
to another (or set of others) should exist, too, but I see
it necessary
that it exists in the abstract itself. Put it in the
introduction or put
it in its own section if the relationships are complicated
enough to
need a roadmap of some type.
I think IESGs I've served on have tended to understand
IESG statements as "one size fits most". I would hope that
continues for future IESGs.
I think what you're saying here, is that we should do
what is helpful for most users in most cases, recognizing
that if a document (say) makes a non-backward-compatible
change that's critical for everyone to implement right now
that will Update 35 RFCs, the best we can do in an
Abstract is say that, followed by "and if you care about
protocol FOO, you REALLY want to read this document".
If I got that, you might very well be right.
Basically correct. I wouldn't list the 35 RFCs in the Abstract, and
I would prefer it if the abstract says "This RFC updates 35 other
RFCs. Further details are in the document itself and in the document
metadata."
I think we should definitely aim for "one size fits most" and
recognize that we can and should be flexible when the unavoidable
edge case shows up.
-Heather
|
