Re: [Gen-art] Gen-ART Last Call review of draft-ietf-tsvwg-rfc5405bis

"Eggert, Lars" <> Fri, 17 June 2016 12:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DDA512D0B9; Fri, 17 Jun 2016 05:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.347
X-Spam-Status: No, score=-8.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 82V3Fsw57fxV; Fri, 17 Jun 2016 05:39:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F298112D147; Fri, 17 Jun 2016 05:39:44 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.26,483,1459839600"; d="asc'?scan'208";a="117684983"
Received: from ([]) by with ESMTP; 17 Jun 2016 05:39:28 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 17 Jun 2016 05:39:24 -0700
Received: from ([::1]) by ([fe80::837:3f3:c8b1:8d6f%21]) with mapi id 15.00.1156.000; Fri, 17 Jun 2016 05:39:24 -0700
From: "Eggert, Lars" <>
To: Paul Kyzivat <>
Thread-Topic: Gen-ART Last Call review of draft-ietf-tsvwg-rfc5405bis
Thread-Index: AQHRuQ3+3hw/tz+TEUyWZ8dG7NFbsp/uLc0A
Date: Fri, 17 Jun 2016 12:39:24 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-mailer: Apple Mail (2.3124)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_658FD740-2536-4C3C-893E-09406FF5A553"; protocol="application/pgp-signature"; micalg="pgp-sha256"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, General Area Review Team <>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-tsvwg-rfc5405bis
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Jun 2016 12:39:46 -0000


thanks for the review! I'll incorporate respective changes into -14.

On 2016-05-28, at 20:23, Paul Kyzivat <> wrote:
> After diffing this document against RFC5405 I see that it really is an incremental change that leaves the scope largely unchanged except for the addition of multicast. So perhaps I am too late to question the scope of the document. But since this *is* a bis, it might be worth considering whether the scope could be focused by splitting some of the material off into a different document(s).

You're right that we inherited this from 5405. And I'm going to use that as the reason to push back on refactoring this ID into multiple ones this late in the process. It'll move us back to square one. It's also not come up in any of the many reviews this ID has gotten so far, or for 5405 itself.

> (2) MINOR? - use of SHOULD
> I was struck by how much SHOULD is used in this document, and how infrequently MUST is used. And while possible justifications for violating SHOULD are sometimes provided, they often are not. In my experience there has been a growing awareness that such vagueness is problematic, because many implementers take it as free license to treat SHOULD as MAY, and just not do it.

This is guidelines BCP. For almost every guideline, there are valid reasons for an application to not follow the SHOULD in this document. But those are application-motivated reasons. This document can't really provide an exhaustive list of reasons on when it is OK and not OK to not follow a SHOULD. It is up to the applications specs that use this BCP to argue why the didn't follow one of our SHOULDs and why.

> (IIUC, in a BCP the normative language is relative to best practice. So if MUST is written and you don't do it then you aren't following best practice. But if SHOULD is written without qualification, and you don't follow it then you can probably claim that you are still following the best practice as documented by the document.)

And that is exactly what is intended. It is OK for applications - after reflection - to not follow one of our SHOULDs, if they can document a valid reason.

> (5) NITs - unlinked references
> I found a number of cases where, in the html format, references are not hyperlinked:
> [RFC5405] section 1
> [RFC4342] section 3
> [RFC6679] section 3.1.7
> [RFC1981] section 3.2
> [RFC6935] section 3.4.1

Those seem to be due to bugs in rfcmarkup.