Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

"Rob Wilton (rwilton)" <rwilton@cisco.com> Mon, 12 October 2020 15:56 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4ADF3A158A; Mon, 12 Oct 2020 08:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Cx/muQh6; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=uvMBSCno
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHnXKMErfgSp; Mon, 12 Oct 2020 08:56:18 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1D83A158D; Mon, 12 Oct 2020 08:56:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8335; q=dns/txt; s=iport; t=1602518178; x=1603727778; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7eM5vr9ONLpjSYvzxfZECNLfXW88Tr+MUlivY9NCkbU=; b=Cx/muQh6EDNqHO8A0r1yujN43lPLOnbdZeaQJnFVQyowIFsefqOhvh07 qYvtlHdkrG9B64rVNSogL5KyMmpmTedQHWmWHPr2046TEufvWLA/d3FBi Y+XmrLi4KQtKh74VVd1uphLm/MBt3gd438LwpNcqm1AaqmLM1y23PeH+D M=;
IronPort-PHdr: 9a23:2rOSYh1A5wOE9zGTsmDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxWFuadhiVbTVsPa5u5Kze3MvPOoVW8B5MOHt3YPONxJWgQegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZXyYlTIqTuz4CIcXBLlOlk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV3CpX4bdg==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADBgBKe4Rf/5ldJa1gHAEBAQEBAQcBARIBAQQEAQFAgU+BUlEHgUkvLAqHeQONUYoRjmqBQoERA1ULAQEBDQEBLQIEAQGESgKCFgIlOBMCAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEBAgESKAYBATcBCwQCAQgRBAEBAR4QIREdCAIEDgUIGoVQAw4gAQOcVAKBOYhhdIE0gwEBAQWFCQ0LghAJgTiCcoYyhBIbgUE/gRFDgk0+ghqBew4CGoNIgi2QBCQygjMBkw01kAo4UgqCaJVeBIUpgxWKCIVCgw2LTqB/kkgCBAIEBQIOAQEFgWsjgVdwFYMkUBcCDY4fCQIYFIM6ilZ0NwIGCgEBAwl8iweBNAExXwEB
X-IronPort-AV: E=Sophos;i="5.77,367,1596499200"; d="scan'208";a="574108619"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Oct 2020 15:56:16 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 09CFuGSH028186 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Oct 2020 15:56:16 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 12 Oct 2020 10:56:16 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 12 Oct 2020 10:56:15 -0500
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 12 Oct 2020 10:56:15 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WnmlGVlrys5dw9PwLiErnoJhf+W5tnJN6nlOJnk+aIdJY4xGF+ZWWoJEEGGE0j2njU/LqkPMr9whGaH2lSd6qrvcbxF0U8GPqmjHy4X1/zTpu/gN2lY9Or38QeX1XA39mcwVls5O4IFQ6rFoQhcTAgBCBllzmf3OJX3Awo2Mhcy56C1KZDpiVNCJOxRpEJ6pfW5YsLR6Xpa/YCD1ziEBXBRNc3Jah7EsI/ZgTj6c6KFbDAf+I3tFISjf8BFBLH47BA1zDYj8EVBBq2nyKjmb6+O3pS0gExbveA02eqrQyjzKkbo+rNpwbtkiS8Tl7DDn/gcHWsvZLB6S/4l/1v6G3g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VEHx8F8JKeCOBVM25Nm222j8KXA8Y17BMo++e1pcDGY=; b=hpjRe4PxMPoDkWWFyfUm4zuZPaX5wnXveRaeCz7tmG+vI8BvRCdaxkwQxjKkIeYjSx6MBRK+4hyaVSwf3cKdIcxkh6zq44CIWIfeislpNQ7KoDWuRlMblifA7E8NLkkSBmsQ3Ky9EMDaIptGb6x1+3iGrMqj6nOmLMAdyHB18jjd2fVMo4I0IKVXxkfJkikwKPvlYZ9tEN2JPt7QF5zqanYkh6+zOik3gZj4i5dPFdEW2z9NzEZHbhN0+bkQUrp1cbawOZxdgPHTeo/ZydbSjg0O8/ayYWT33qDmuisTPPEXEN4uHSRMyueFKRZ2m8MilRD/oQ+ToJVBBZctZXFZ5Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VEHx8F8JKeCOBVM25Nm222j8KXA8Y17BMo++e1pcDGY=; b=uvMBSCnoqh3CSBFl+dJ7Gug5lhg9604++Q5lJhRDDDNQi6b+VPdl0WO/3uTN2wRFaUoA1vcZEw4xYG0om4xSYJ400NqwxsNviB529M8ixrRmCl5CLjPWh3EXOKHCN1dytS2IKZVYfwN+ffMHdkMasFtjudaQKezsIThckAB2zY0=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3490.namprd11.prod.outlook.com (2603:10b6:208:7e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.21; Mon, 12 Oct 2020 15:56:14 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3455.030; Mon, 12 Oct 2020 15:56:14 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>
CC: "draft-ietf-dnsop-dns-zone-digest@ietf.org" <draft-ietf-dnsop-dns-zone-digest@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>, "dnsop@ietf.org" <dnsop@ietf.org>, "dnsop-chairs@ietf.org" <dnsop-chairs@ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
Thread-Index: AQHWnWTLXBOmQTmNGkG7AmGk8bLrYqmPm2kAgASDkdA=
Date: Mon, 12 Oct 2020 15:56:14 +0000
Message-ID: <MN2PR11MB43665A8B2DE4ECFF99CEAB7EB5070@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <160215590178.19643.8185294724542473578@ietfa.amsl.com> <514C5EA8-2814-42AA-9787-455445BA828D@verisign.com>
In-Reply-To: <514C5EA8-2814-42AA-9787-455445BA828D@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [82.12.233.180]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2ab288cb-0a50-4767-cb02-08d86ec75951
x-ms-traffictypediagnostic: BL0PR11MB3490:
x-microsoft-antispam-prvs: <BL0PR11MB3490BCE725DA6A4221ACD2DEB5070@BL0PR11MB3490.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: CmVopRoexNLtJ2G/JqvzbsnSuD9Hk2Qupgwn2K9PyV3B7gbJ4pK4TTfyuuGq65eSt56FwTQhVJAxVXYDOBmYqgfMf6Vkj7q6djqo6iYAoJ3zvGhnDewSKSv5LSziADMIfpH9YKHmeAlgBlobv8DXSW0FHL5GqPCIUE8szzKLt/t4OKf61KyN8/wJ1zwNpvEhHa5ZnjQVdUbAy/V3qDwhJyjzfxWosFNpBD1l9CjFKovU3Qvuzp2lD1t78WuLmedvfF3JwBkAUMC202apDpZSkFqDELoLqQiku5yukh9JJG5ZISbPIhnFPuZVKDuWexXFPFCgzoJ58lnrA07sxT2+1g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(39860400002)(346002)(136003)(396003)(26005)(55016002)(316002)(186003)(8936002)(9686003)(71200400001)(53546011)(6506007)(7696005)(8676002)(54906003)(86362001)(83380400001)(4326008)(52536014)(66446008)(66556008)(66476007)(5660300002)(66946007)(76116006)(33656002)(64756008)(478600001)(2906002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 0lAt3A9yRIhxlyXOy7c/g62oTM2TNoVKCxSkr+zolG08vZ/ff0np5UK6muR+9owInnkIWHVEIM8RT07eJJQsV4Vb7kEgp26rLELM6ztuz7ibW4PJKQi1Z+6nHEJrh+v3A674rOTHoiK918gXAZ1FHFQXRV0Y+mnOqXDw0+9n8SlDvv2TKFB2jcioDuPycGybslI0x0R+WXmuTYxodLjqwZB/edkfzWc7w/lPDxR6Z59GmszXFUFJPlC95V9zlKqbprRGwNkQ3nLEynQNJ4P+tVVofXm6JDzLFU00SPEmjOmxVe0Xm4DgQDif4llW9YmuyZjuVsneJwNY4zHfn+ttaknVJKurIYFLUZIZtw30FWfMt9kwT8UXKvApdz1NbmPTc38/CV5qr4WdkrODyagO4oZIOqLRFWhnm621cDYAamWVXa9jRo+783r/Z9YSZF/AbeRCwtAjFjDY8RKFekPXwDWN41Omfz2v5klzPkpXSB28Tpyg5o29l4QiYSNfCBxOBYK8wqa9SEKRgJSwbIOaKImyfm0Ma+5PC06O4OfUsT1twwM+CCM06GEf+EjB0kqazWv8rR40J1p+RFav+afN+RMdY26TZhjFcHeXMsQ5yt5bcrD+WRQa8gCU6yIAttTSVRRSlrQsQ5t2C72YOayAQw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2ab288cb-0a50-4767-cb02-08d86ec75951
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2020 15:56:14.7336 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: e2yETbReRptXDxwv41j0Ze3maMRTYirr+kwQ5nCF8ID4Ydbsq991JONa1pNRqNIZR++uSedL7XdJYF9NfN2hMQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3490
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LcGquh4Yf2beWGAnBKbvmjHRDTc>
Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Oct 2020 15:56:20 -0000

Hi Duane,

Please see inline.

> -----Original Message-----
> From: iesg <iesg-bounces@ietf.org> On Behalf Of Wessels, Duane
> Sent: 09 October 2020 19:36
> To: Rob Wilton (rwilton) <rwilton@cisco.com>
> Cc: draft-ietf-dnsop-dns-zone-digest@ietf.org; Tim Wicinski
> <tjw.ietf@gmail.com>; dnsop@ietf.org; dnsop-chairs@ietf.org; The IESG
> <iesg@ietf.org>
> Subject: Re: Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-
> digest-12: (with COMMENT)
> 
> 
> 
> > On Oct 8, 2020, at 4:18 AM, Robert Wilton via Datatracker
> <noreply@ietf.org> wrote:
> >
> > Robert Wilton has entered the following ballot position for
> > draft-ietf-dnsop-dns-zone-digest-12: No Objection
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Thank for you this document.  I found it interesting and it looks
> useful.
> >
> > I have a few comments that may improve this document for you to please
> consider:
> >
> >   Herein, SHA384 [RFC6234], with value 1, is the only standardized Hash
> >   Algorithm defined for ZONEMD records that MUST be implemented.  When
> >   SHA384 is used, the size of the Digest field is 48 octets.  The
> >   result of the SHA384 digest algorithm MUST NOT be truncated, and the
> >   entire 48 octet digest is published in the ZONEMD record.
> >
> >   SHA512 [RFC6234], with Hash Algorithm value 2, is also defined for
> >   ZONEMD records, and SHOULD be implemented.  When SHA512 is used, the
> >   size of the Digest field is 64 octets.  The result of the SHA512
> >   digest algorithm MUST NOT be truncated, and the entire 64 octet
> >   digest is published in the ZONEMD record.
> >
> > For consistency, perhaps change "with value 1" to "with Hash Algorithm
> value 1"?
> 
> Done.
> 
> 
> >
> >    2.2.4.  The Digest Field
> >
> >       The Digest field MUST NOT be shorter than 12 octets.  Digests for
> the
> >       SHA384 and SHA512 hash algorithms specified herein are never
> >       truncated.  Digests for future hash algorithms MAY be truncated,
> but
> >       MUST NOT be truncated to a length that results in less than 96-
> bits
> >       (12 octets) of equivalent strength.
> >
> > When I read this, I wonder why the limit of 12 bytes was chosen.
> Possibly a
> > sentence that justifies why this value was chosen might be useful,
> noting that
> > the two suggested algorithms have significantly longer digests.
> 
> 
> I know there has been some followup on this with Donald.  In our earlier
> conversations with him he wrote "96 bits seems to be a common minimum
> length for disgests in the IETF although perhaps I have that impression
> due to the common case of SHA-1 truncated to 96 bits."
> 
[RW] 

As per my comment to Ben, I think that you can regard this one as closed.


> 
> >
> >    2.  The ZONEMD Resource Record
> >
> >       It is
> >       RECOMMENDED that a zone include only one ZONEMD RR, unless the
> zone
> >       publisher is in the process of transitioning to a new Scheme or
> Hash
> >       Algorithm.
> >
> > I'm not quite sure how well this fits with sections 2.2.3 restriction
> that
> > SHA384 MUST be implemented, and SHA512 SHOULD be implemented.   As a
> recipient
> > of the zone info I understand that I would need to implement both, but
> as a
> > sender am I allowed to only send SHA512, or both, or must I always send
> SHA384?
> 
> As sender (publisher) you are allowed to publish whatever you want.
[RW] 

Okay, taken in conjunction with 2.2.3 that didn't seem clear to me.  My reading is that the sender SHOULD only send one, and [everyone] MUST support SHA384, effectively implying that is SHA384 that MUST be sent ...  Perhaps the RFC 2119 language in section 2.2.3 needs to be restricted to receivers processing ZONEMD records?  ... or some other way to convey the difference in requirements on algorithm implementation between senders and receivers.


> 
> The purpose of the recommendation above is to hopefully avoid the
> situation
> where multiple records are published (with both types) on an ongoing
> basis.
> That is something we observe with DS records quite often.  For example,
> 750 TLDs today publish both SHA1 and SHA256 digest types as DS records in
> the root zone.  This new paragraph has been added to the security
> considerations:
> 
> 6.2.  Use of Multiple ZONEMD Hash Algorithms
> 
>    When a zone publishes multiple ZONEMD RRs, the overall security is
>    only as good as the weakest hash algorithm in use.  For this reason,
>    Section 2 recommends only publishing multiple ZONEMD RRs when
>    transitioning to a new scheme or hash algorithm.  Once the transition
>    is complete, the old scheme or hash algorithm should be removed from
>    the ZONEMD RRSet.
> 
> 
> >
> >    3.1.  Add ZONEMD Placeholder
> >
> >       In preparation for calculating the zone digest, any existing
> ZONEMD
> >       records (and covering RRSIGs) at the zone apex are first deleted.
> >
> > I think that this places a requirement that all zone digests must be
> > constructed at the same time.  I suggest at least changing "zone digest"
> to
> > "zone digest(s)", but it might also be worth adding a sentence to
> highlight
> > that.
> 
> I've changed it to "zone digest(s)" as you suggest.
> 
> Strictly speaking, there is not a requirement that all digests must be
> created
> at the same time (in parallel).
> 
> The reason for the placeholder is explained in the next paragraph, which
> is to
> ensure correct NSEC/NSEC3 records when the zone is signed with DNSSEC.
> 
> 
> >
> > I was also left wondering whether it is strictly required that the zone
> digests
> > must be deleted, or just that placeholder zone digests must be used in
> their
> > place during the calculation.  E.g. what happens if a request is
> received to
> > fetch the ZONEMD record at the same time that it is being reconstructed?
> 
> It is not strictly required to delete any existing digest first.  The
> ZONEMD records
> are not included in the digest calculation.
> 
> To address your questions around this, I suggest adding this text to
> section 3,
> before section 3.1:
> 
> 3.  Calculating the Digest
> 
>    The algorithm described in this section is designed for the common
>    case of offline DNSSEC signing.  Slight deviations may be permitted
>    or necessary in other situations, such as with unsigned zones or
>    online DNSSEC signing.  Implementations that deviate from the
>    described algorithm are advised to ensure that identical ZONEMD RRs,
>    signatures, and dential-of-existence records are produced.
> 
[RW] 

Yes, I think that would help clarify.


> 
> 
> > 4.  Verifying Zone Digest
> >
> >   5.  Loop over all apex ZONEMD RRs and perform the following steps:
> >
> >   ...
> >
> > My, perhaps mistaken, interpretation of these error reporting
> instructions in
> > this loop is that they really assume only a single ZONEMD RR.  I.e., I
> wouldn't
> > expect the recipient to generate/return these errors if there were two
> ZONEMD
> > RR's and only one scheme/algorithm was was supported.  Yes, there is
> some text
> > at the beginning of the entire algorithm that suggests what to do here,
> but
> > further guidance here may also be helpful.  E.g. what does the server
> return if
> > there are two ZONEMD records and neither of them are acceptable for
> different
> > reasons?  I'm presuming, perhaps incorrectly, that only a single error
> > can/should be returned.
> 
> Ben raised a similar point about this section, namely that it could result
> in a lot of diagnostic output.
> 
> Do you think it would be better remove those "SHOULD report" from each
> individual
> step and instead have a paragraph at the end that says the verifier SHOULD
> report
> the result of its verification and leave it at that?
> 
[RW] 

Yes, I think that would be better.

Regards,
Rob


> 
> >
> > Regards,
> > Rob
> >
> 
> Thanks for the review and comments!
> 
> DW
>