[tcpm] 793bis: references to 2119 keywords

Wesley Eddy <wes@mti-systems.com> Fri, 27 July 2018 15:22 UTC

Return-Path: <wes@mti-systems.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7BC130F33 for <tcpm@ietfa.amsl.com>; Fri, 27 Jul 2018 08:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com
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 Qcyo-nEynLgH for <tcpm@ietfa.amsl.com>; Fri, 27 Jul 2018 08:22:30 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5013130EBD for <tcpm@ietf.org>; Fri, 27 Jul 2018 08:22:30 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id g141-v6so7850660ita.4 for <tcpm@ietf.org>; Fri, 27 Jul 2018 08:22:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=NWVcECPYXkG1rmprsueHVtrA2r+bOBC96UGrzpIiVBY=; b=jzFJUWVMVESNPTOiq5+MqZPvgePhyZPGgSOGi/5clhK3JJW1FAoUXugq16SgQUq0V4 ixTIq3TS2u98+vgqDsGU6o7GknDnwBzYATC+IFvSNqVvakUiCcUFs/bDEdqoKmSRHkHE bOrhUoBrRsB4g1RxzhgudQySZql/W/faxOdE/pzDOVJli/ACbkm9DBT5cxCaCcfcSrcO sbmuDarxCaVeDorAugPLnFVzf5X/SHcV02uJs0JN3THITvKrJeQaGyrtS/D35fTKiLCK 1MPIVmkbzv9i8gByIPe+kLKlvZhk7h1IYZImJNE07rIx1B3nx4vnhaJUKhESmbXakU56 wM0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=NWVcECPYXkG1rmprsueHVtrA2r+bOBC96UGrzpIiVBY=; b=oj9zT8sALnusEUe67N8tWgbpZxWnU1h+lrdZvrtdvXYESbmjZyd21bbQinX0HyDPfb 7sqrAqCUjQ6WRHye4oyxL6Vl/hkt4XrBYVrrC5JfiXJebI+bCg3Cx7147HnTAx/J3Y0X TlGDVxLhW19U68XjTzS6cqf55S7AuTptY3Zi5tPHPVPhXuu2o8sWzbYkSEaVDOg9aZY8 WqL7y28azZvxBh6JHTJ1ZCmw1XBGTHdzFqL7XhZFRGZmWeq39hmeRi1R2i2RtmamkcdY caVfDroUNaEL7NdCr76i8LVD8SgUjuNjAaP16RJsnOLCEyx2nbTQN5xAUbLJSdV3+VFh 1oqQ==
X-Gm-Message-State: AOUpUlGEmpnjWav0XH5xosDRag+9tvqcejZS/lHxQYC9X0X9T8frzzay p06kWpguPd7Btak0PZRImerecToFjtk=
X-Google-Smtp-Source: AAOMgpchi0DnruMxFYh3GaOwuCtYDTa1k9/1edlwclCErfetQ6LUahqw+3Bcaqac6SYt6Hu7OH6auQ==
X-Received: by 2002:a24:d80a:: with SMTP id b10-v6mr6082119itg.27.1532704949732; Fri, 27 Jul 2018 08:22:29 -0700 (PDT)
Received: from [192.168.1.105] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id c12-v6sm1262156ioh.2.2018.07.27.08.22.28 for <tcpm@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jul 2018 08:22:29 -0700 (PDT)
To: tcpm@ietf.org
From: Wesley Eddy <wes@mti-systems.com>
Message-ID: <fe6e2c39-fec1-30a8-7b25-1520e1cbd774@mti-systems.com>
Date: Fri, 27 Jul 2018 11:22:23 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------C0244D80D3EB4B9F0FFAA8DB"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/Xq6LuysKfpdo2UdAeb0rbUuQ6Ys>
Subject: [tcpm] 793bis: references to 2119 keywords
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jul 2018 15:22:33 -0000

In the 793bis draft, some time ago we had included the appendix from 
1122 that has a table of all the places where 2119 keywords are used 
(MUST/SHOULD/MAY/etc).

I'm now updating that so that it:
(1) points to the right section numbers or places within the current 
document rather than 1122
(2) contains references for requirements that came from other documents 
than 1122

There are a few challenges, and I have a proposal.

Instead of carrying forth exactly the prior format where the table 
looked like:

                                                   |        | | | |S| |
                                                   |        | | | |H| |F
                                                   |        | | | |O|M|o
                                                   |        | |S| |U|U|o
                                                   |        | |H| |L|S|t
                                                   |        |M|O| |D|T|n
                                                   |        |U|U|M| | |o
                                                   |        |S|L|A|N|N|t
                                                   |RFC1122 |T|D|Y|O|O|t
  FEATURE                                          |SECTION | | | |T|T|e
  -------------------------------------------------|--------|-|-|-|-|-|--
  Closing Connections                              |        | | | | | |
    Half-duplex close connections                  |4.2.2.13| | |x| | |

I'm suggesting to replace the "RFC1122 SECTION" column with one called 
something like "ID", and then adding an ID tag into the sentence where 
the requirement occurs, which winds up looking like:

                                                   |        | | | |S| |
                                                   |        | | | |H| |F
                                                   |        | | | |O|M|o
                                                   |        | |S| |U|U|o
                                                   |        | |H| |L|S|t
                                                   |        |M|O| |D|T|n
                                                   |        |U|U|M| | |o
                                                   |        |S|L|A|N|N|t
                                                   |        |T|D|Y|O|O|t
  FEATURE                                          |   ID   | | | |T|T|e
  -------------------------------------------------|--------|-|-|-|-|-|--
  Closing Connections                              |        | | | | | |
    Half-duplex close connections                  | MAY-1  | | |x| | |


And then searching the document for "MAY-1", you would find the sentence 
in section 3.5.1:

    A host MAY implement a "half-duplex" TCP close sequence, so that an
    application that has called CLOSE cannot continue to read data from
    the connection (MAY-1).

Subsequent statements would be labelled "MAY-2", "MAY-3", etc.

Before I do this for a large number of these, I thought it would be good 
to solicit feedback from the group. Does this seem like a good idea? Is 
it valuable? Given that XML2RFC "artwork" can't contain "xref" tags, it 
seems easier and less error prone than maintaining section number 
references in that table.