Subject: [core] Stephen Farrell's No Objection on draft-ietf-core-block-19: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 19 Apr 2016 05:10:34 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-core-block-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-block/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The intro and early section 2 has quite a bit of argument
as to why this design is good or better than some other.
For this reader, that's not really needed (I assume the WG
had those discussions). I think this is an example of a
recurring problem with the text here - with too many words,
clarity suffers. For example the Implementation note on p7
is, just by itself, the best and would be a sufficient
explanation of, the encoding, the description of which is
otherwise pretty opaque. There's also a good bit of
repetition that makes this a harder read in general. That's
all just IMO of course, and there may be history in the WG
that provides good cause for so many words to be needed.
All that said, I assume that it's too late to reduce the
size of this document, so no action is required unless the
authors/WG/chairs would themselves like to try remove
words.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Apr 2016 08:39:50 +0200

> had those discussions). 

Indeed, this could have been cleaned out, but then having some rationale
*why* things were done in some way is often helpful to the implementer.

> I think this is an example of a
> otherwise pretty opaque. 

There are some specifications out there that essentially give a canned
implementation in prose.  That runs into a problem when that prose is
ambiguous (or wrong).  So having some descriptive text as well is
usually preferable.  Some amount of redundancy may be useful (examples
should always be redundant...).

> There's also a good bit of

The history is that this specification was written long ago and updated
as new information became available.  No conscious decision to be overly
verbose.

> authors/WG/chairs would themselves like to try remove

As an author, I think it would have been good to have a major rewrite
around 2013 when the concepts had become solid.  Doing that now is a bit
more dangerous than I like...  (And we have already had enough delay in
processing this.)

Grüße, Carsten