[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: Unclear text [was IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]]
From:       otroan () employees ! org
Date:       2017-01-18 13:34:37
Message-ID: B14A0A52-128B-41D1-AA82-088B91238634 () employees ! org
[Download RAW message or body]

Brian,

> ...
> > "Not clear" != "faulty". 
> 
> On the contrary, in a standards document, "Not clear" == "faulty"
> 
> Really. If we publish text that is logically correct but can easily
> be misread (or, of course, text that is ambiguous) then it's faulty text.
> 
> (On a personal note, I have always tried to discipline myself thus:
> if *anybody* misinterprets some text that I wrote, however clear
> I believe it to be, then it's the text that needs fixing, not the
> reader.)

In the parts of a document describing the exact protocol specification and where it \
affects interoperability I do agree with you. In other parts of a document I think \
ambiguity  and leaving leeway up to future readers is perfectly fine. Being very \
strict about this, might lead us into being prescriptive where we have no business \
being prescriptive.

O.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]