Re: [arch-d] [IAB] I-D Action: draft-iab-protocol-maintenance-04.txt

"BRUNGARD, DEBORAH A" <> Mon, 11 November 2019 21:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2540812006D; Mon, 11 Nov 2019 13:28:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZSmECjbUfeyQ; Mon, 11 Nov 2019 13:28:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D460412089C; Mon, 11 Nov 2019 13:28:31 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id xABLKHIb001188; Mon, 11 Nov 2019 16:28:30 -0500
Received: from ( []) by with ESMTP id 2w7eq31e6y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Nov 2019 16:28:30 -0500
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id xABLSSBv011402; Mon, 11 Nov 2019 16:28:29 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id xABLSL7N011260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Nov 2019 16:28:21 -0500
Received: from ( []) by (Service) with ESMTP id 7231F4030710; Mon, 11 Nov 2019 21:28:21 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTPS id 5B9764030701; Mon, 11 Nov 2019 21:28:21 +0000 (GMT)
Received: from ([]) by ([]) with mapi id 14.03.0468.000; Mon, 11 Nov 2019 16:28:20 -0500
To: Ted Hardie <>
CC: Brian E Carpenter <>, "" <>, "" <>
Thread-Topic: [IAB] [arch-d] I-D Action: draft-iab-protocol-maintenance-04.txt
Thread-Index: AQHVktorQzqaBndTdEufGR0WueBBLad8Go4AgAJ+wLCAAHcYAIAHZrLg
Date: Mon, 11 Nov 2019 21:28:20 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8A3AB1B94MISOUT7MSGUSRDE_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-11_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911110186
Archived-At: <>
Subject: Re: [arch-d] [IAB] I-D Action: draft-iab-protocol-maintenance-04.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Nov 2019 21:28:34 -0000

Hi Ted,

With the upcoming meeting, I’ve been swamped with preps, hopefully during the meeting week, can find some time to talk as much easier than email.

I agree with what you have below as likely to be applicable for some protocols but I would be very uncomfortable to say it is universally applicable. In routing, we do many times generate responses for non-recognized requests but the response does not necessarily result in a fatal error. And for many “bits” e.g. flags, depending on the impact, routing may/may not have an error message, :

An example of where we were not “perfect” on first specifying (and assume tolerant receivers):

Maybe I’m a bit more pessimistic than optimistic, I find it hard to parse that generating fatal errors will promote interoperability (if this is what is meant). I think one needs to allow for unexpected behavior and allow graceful failure. One can never be sure all the error cases/delay impacts have been sorted out, especially coming from outside of one’s domain/state machines/microservices. E.g. for a router, one needs first to ensure the integrity of the system is maintained and useful. One can have a beautiful architecture vs. deployment reality.

Carsten – a re-phrasing to clarify would be very helpful.


From: Ted Hardie <>
Sent: Wednesday, November 06, 2019 5:26 PM
Cc: Brian E Carpenter <>om>;;
Subject: Re: [IAB] [arch-d] I-D Action: draft-iab-protocol-maintenance-04.txt

Hi Deborah,

On Wed, Nov 6, 2019 at 1:15 PM BRUNGARD, DEBORAH A <<>> wrote:

For me, the robustness principle has nothing to do with preventing new extensions on a protocol, it has everything to do with protecting existing deployments. The document's proposal "Choosing to generate fatal errors for unspecified conditions" may be appropriate for some protocols, it would cause a melt down of the network for other protocols. One of my working groups currently is doing a "fix" - and only because of the robustness principle, there have been no issues with current deployments.
As Carsten says downthread, some of the applications of the robustness principle are obviously good.  Some, not so much.  I think we all agree, though, that maintaining points of extension is both good and, ultimately, necessary if the Internet is going to continue to change and grow.  One issue is that some of the points of extension get eaten up by poor applications of the robustness principle.  If you reserve a code point but ignore its use in deployments because it has no meaning, it can really never have a meaning until a forklift upgrade arrives, as you can't tell which bits ignore it and which use it.  Given our current rate of ossification, that is a problem.

I don't know the situation you allude to above, and it may not apply there.  If you can send text on how to distinguish the situation you see and the doc describes, we'd be grateful.