Re: WG last call for draft-ietf-rtgwg-policy-model

"Acee Lindem (acee)" <acee@cisco.com> Mon, 05 October 2020 17:59 UTC

Return-Path: <acee@cisco.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C623A0F27; Mon, 5 Oct 2020 10:59:03 -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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=PXOLcx6+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hkhkn7SS
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 o2Lr0IR5L2jC; Mon, 5 Oct 2020 10:59:02 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9883A0F26; Mon, 5 Oct 2020 10:59:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10568; q=dns/txt; s=iport; t=1601920741; x=1603130341; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fJaumUr8yTpGk+GIeZcjVrxzezN6WVNHTxREj0UtrJc=; b=PXOLcx6+7c6lH17UpYOMOUJmtqtkXK4ebr4EuGoEWnBPWZDV5+/Cwfrh RmUVQH2ClMB+j4Q2GUbULUUIvntdhOZi6UHxxgtI/Pdbtv2hKEbgF0Y0p 3jBG9DYNEHzEyU0OTrjcHhkmP6ykIjVE86JVLLu8us1P3Pj6vuubq0gWP I=;
IronPort-PHdr: 9a23:5o66wBKB0UiAJ3WBe9mcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeGv68/hkPCWoPd5vlYzeHRtvOoVW8B5MOHt3YPONxJWgQegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX0e1bVpHu/5iJUERL6ZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02jBDOpyhF
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CfBQAjXntf/4kNJK1aBhwBAQEBAQEHAQESAQEEBAEBQIFPgVIjLgdwWS8sCoQzg0YDjXCBAokPjmqCUwNVCwEBAQ0BARgLCgIEAQGESgIXgiECJTgTAgMBAQsBAQUBAQECAQYEbYUvBicMhXIBAQEBAwEBEAsGEQwBASwLAQ8CAQgRBAEBAwImAgICHwYLFQgIAgQBDQUigwQBgksDLgEOnWgCgTmIYXaBMoMBAQEFhSMNC4IQAwaBDiqCcoNpgkSEEhuCAIERJxyCGDU+ghpCAQECgU0Qgxczgi2TPZMCkEBSCoJnj1aFFWuFCwMfgw44iUqFPI5TkxSNWJI+AgQCBAUCDgEBBYFrI4FXcBU7KgGCPlAXAg2BFo0JDBeDToUUhUJ0AjUCBgEJAQEDCXyLCC2BBgGBEAEB
X-IronPort-AV: E=Sophos;i="5.77,340,1596499200"; d="scan'208";a="574553403"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Oct 2020 17:59:00 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 095Hx0RO026856 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2020 17:59:00 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 5 Oct 2020 12:59:00 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 5 Oct 2020 12:58:59 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 5 Oct 2020 13:58:59 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=azp67bbLifk9eTWxGISj7owgNEQAPOO60JnN79vpztg5eVnToDb3P4mCC7qykXdeAgJgDzGp3XTBiJjU2ChW3k0SjcD25Do7NBJWPDPelJpNY380JuSQ3TtgqwK2ABkxAaHzUKLiFeSU/U2VwnC0JCoR1nBbRxVQCkMO7KyWE4JqIOjDeSA/X1PEzazF4acRC849NBuZHR7seQziQ5yqD18jW9kkAt5rmI/oKdk5Actzu98Lnxp7qB2venRiOi+y+WcHs7t2pdHfF2omorhzz396pdCC3+NiQWnUAVireCgdUwO1xFWN23XTOw2erEc5Ibz+T8skkC2Hy4u6OgMeLw==
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=fJaumUr8yTpGk+GIeZcjVrxzezN6WVNHTxREj0UtrJc=; b=Z2SUUlIv9CwHD8VMzcm1KGlQ6SWAraek3190eFBrzmbum4Awymo/WOPizGyMDUgQPbLxytEGgQjRjfkTABI3zEdF2MSf1gOxGOGpQ87GtOglq+Iil5QRNcEXJAamtQnRWVFQLCYQN82akd6OUa0sKCzjE++tFYqXUxBEwrIo4m/9WA9h7KhEOCvHxIIZPBkHNshAsbJTw0u6E/WaabyPHh9IO0DBLIBaImrJCaF5+oeu72PrDiXl6GYZBoxL1BwGB2/MkyZO2fP8lpwlRym4bJhQW9EJB3mHD/KapD46HcjeNhhct4OI7WOJSdrRWCvxgPBxlF95/qP4zy0m3anLjA==
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=fJaumUr8yTpGk+GIeZcjVrxzezN6WVNHTxREj0UtrJc=; b=hkhkn7SSv+TzHl3r1UWFuRt3RyZ6GmpBjJcoyOX3BHBC20HxOIEQyaE7FnM4c96lgo7zWD6bXsZlj+IbvHFtnQ8K9b3xcDsETetZJSDJl+xvwIr4TRD0qF/krldkHKd6rDHLnV7pnJ/tWbMayJ4rsTe/jLnBLLPCumHrp1KvQC8=
Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by SJ0PR11MB5086.namprd11.prod.outlook.com (2603:10b6:a03:2d1::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.34; Mon, 5 Oct 2020 17:58:58 +0000
Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3433.044; Mon, 5 Oct 2020 17:58:57 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: tom petch <ietfa@btconnect.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, Chris Bowers <chrisbowers.ietf@gmail.com>, RTGWG <rtgwg@ietf.org>
CC: rtgwg-chairs <rtgwg-chairs@ietf.org>
Subject: Re: WG last call for draft-ietf-rtgwg-policy-model
Thread-Topic: WG last call for draft-ietf-rtgwg-policy-model
Thread-Index: AQHWdOBUMxhRDuxlwkqot1Yubab0gqlXfeEAgAEhWACAAcGmgIACqGcAgAPWtACAAUi+gIAAKJUAgAfB4QCAASN8AIAAH5AAgABN9AD//9HzgIABXKaAgAHtxACAGmjZgIAALC+A
Date: Mon, 05 Oct 2020 17:58:57 +0000
Message-ID: <F284DA37-2EE6-4C81-8D97-7E9A5AE7E6C8@cisco.com>
References: <CAHzoHbu7g7VifCVf4hEuvNkf46+3AG8_A6JhJdKQ5y2WN1njQA@mail.gmail.com> <CAHzoHbtCvr+9pALnTeV_SQ8fGzebrvHBJ0014Kpxkspd4G+n-A@mail.gmail.com> <DB7PR07MB53400AD2E7D7D741B708C7A1A22D0@DB7PR07MB5340.eurprd07.prod.outlook.com> <D97B9C42-A24C-40E7-93E4-27F344AC9A9A@cisco.com> <DB7PR07MB5340CCD0ABC8382B77C12CECA2280@DB7PR07MB5340.eurprd07.prod.outlook.com> <CAHzoHbtUoyXg7i3epHzOzmUi1A2bUaN6Un9+t5S+6r8aq4JQjw@mail.gmail.com> <DB7PR07MB534069339AB0EFD673CE58C9A2270@DB7PR07MB5340.eurprd07.prod.outlook.com> <F8ED3B80-AB3F-4000-A675-795235F0AFD6@cisco.com> <97D736FD-42BA-483A-9290-15202A678A4D@cisco.com> <DB7PR07MB5340BD58056B435F5ABC606AA2210@DB7PR07MB5340.eurprd07.prod.outlook.com> <6B7CCA52-0A9F-49BD-B390-6637EEA582D4@cisco.com> <DB7PR07MB5340B6FB8725469FBB6925D9A2210@DB7PR07MB5340.eurprd07.prod.outlook.com> <A4D00913-668A-4A0C-8EB4-6C4ED850812F@cisco.com> <DB7PR07MB53409B3A4519B4E9424962E8A23E0@DB7PR07MB5340.eurprd07.prod.outlook.com> <3C987A85-9CBE-4D4F-915E-73A2A6F5F3D7@cisco.com> <DB6PR0701MB256795A042F4024C25413AFFA20C0@DB6PR0701MB2567.eurprd07.prod.outlook.com>
In-Reply-To: <DB6PR0701MB256795A042F4024C25413AFFA20C0@DB6PR0701MB2567.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.41.20091302
authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [136.56.133.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 033aa888-b4ae-4012-2965-08d86958552d
x-ms-traffictypediagnostic: SJ0PR11MB5086:
x-microsoft-antispam-prvs: <SJ0PR11MB50865372696650C1292AF1F7C20C0@SJ0PR11MB5086.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: E2DhN6R1HSSxxXAkcbuTMU4hcx82aiqrAuD2hN3ggJIO86einX8Zi44IRSv1uSpaoFQVOzTCgHfXanc3ZxrQXV7gyt1MKIyEe9lKMjzeTbk0jsd8MvIz6TkoUNJax2npUmsdkAdURTM1+hkac12xZBP0SQQlatSG9SJEdMym8zUPNKEYbU2zRKn4Hxul7ydWyRnPcy5nAAsY2Zrwx8XqQ4O0wIwK9mJLfbmNBuD1iIcVoJPkt7MFOSsKWy02b0m92mtWv0WG+x+GL0z1G9gSBlwSTPhUAm+eMb/RNN56nGqmZn2zeUZXftPxFaFzuxy+kQD/8vYzJIWW9RGLiTztBg5m3fmZ2zyoaFldMaiez81SvGr7LiUXJ+KAF7WJibZlTgCc2cPtsnKEQHCSPLjl/w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(39860400002)(376002)(366004)(346002)(64756008)(66446008)(2906002)(26005)(66556008)(2616005)(53546011)(6506007)(66476007)(83080400001)(33656002)(5660300002)(66946007)(186003)(6486002)(36756003)(71200400001)(76116006)(6512007)(8936002)(966005)(316002)(478600001)(296002)(8676002)(86362001)(83380400001)(110136005)(4326008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: bG1wuoFrSC6f+KvpLV9RcQtGz88t4Z0whKMely94QLfFVGvNDySVong+3BHRKUryoEXEBOhUXnxB2PA2MEC7CMv75YEJYIjPVqix3aIKCrJ1q5bGEVW28gs1nUF9L0+ySJZRUWGupqmupalJAdaSJYRgSywtjxfcc79wBFFI/Jrc98nVxoTm3gELw0UZtFjYhk9MfzLDZS58hquV85LwfYKLsC9hNjGFz5CNZyj0yB/hTtOP6JxZ+uyJncpLlmkoR72rSywu5WmloQx5jd3AxX99d7YamSmLjBNckQkOP/T4lvyv5OtRwg1kRmd7t3IdOyJobgE11T3KQkWCpB3ToWdXLNDY9Jw1MDST3lCj0OOS8qYIzb0oVp17wWpkTKBIuj0Rx7HiOAKPao+NpszbfFoLScIRxERGw/xx1yaBhJkE4JLVX+vdHIXXhSLNTX1lburCJ67rjYekIpbPA8Ul/zPfTLxWfxp3SSXMPDrmSzNJA1ur7/9GbfGORtXLNopAPGeM2EcAh7cXpMaF13TeU+nbdsLiGuIjGulBhdWnKL3lm2ywYJ09VzZnAZdbD4HRXfVNqzMvE3D3RPfdaq/12iwItU2ixNrY4ohxjvehBfz1Y1msMUfnbQOEb0TjadyhdYM/zlggQS+mxLNSoe3aLw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <38E7EB7CD1AE1E42BBC795E1DD9577F1@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 033aa888-b4ae-4012-2965-08d86958552d
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2020 17:58:57.8047 (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: 2zmwQRVHtzWVx1shvC5APJnH7TJIh8b4lbcuDIrpiPJ5DRvjaoMIFXCAM0ZU8dVz
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5086
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/XMzm6NhetMWt3R4hydUiu5Tr3zU>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Oct 2020 17:59:04 -0000

Hi Tom, 

There can only be one "set-metric" action per statement and the statements are order-by-user. Hence, I don't see how there is ambiguity. 

Thanks,
Acee

On 10/5/20, 7:21 AM, "tom petch" <ietfa@btconnect.com> wrote:

    From: Acee Lindem (acee) <acee@cisco.com>
    Sent: 18 September 2020 21:02

    Hi Tom,
    I went ahead and fixed and ran it through a spell-checker.

    <tp>
    Acee

    a technical thought - I'll send some editorial thoughts separately.

    YANG document order is not defined and so you have ordered-by user in suitable places.  I am wondering if there could still be an ambiguity if there are several modifications to the same value e.g. metric.  If one modification takes the value below the minimum of above the maximum, then the result of the next modification will be different than if the order was different.

    I cannot decide whether this is completely ruled out by the ordered-by user or not.  Maybe the document needs to say that document order is undefined and that users must not rely on condition/action being evaluated in the order shown except where ordered by user.

    Tom Petch

    Thanks,
    Acee

    On 9/17/20, 6:35 AM, "tom petch" <ietfa@btconnect.com> wrote:

        From: Acee Lindem (acee) <acee@cisco.com>
        Sent: 16 September 2020 18:47

        Hi Tom, et al,
        I have clarified the usage of policy chain and added the normative language in the YANG description constraints - which I believe is the right approach.

        <tp>

        Looks good.

        Some more trivia:-(
        In container prefixes you fixed the 'is is' but I did not notice
        'outcome outcome'
        or
        'statisfied'
        Sigh.  I suggest holding these (which my spell-checking MUA is complaining about:-) until something else comes along.

        Tom Petch
        Thanks,
        Acee

        On 9/16/20, 12:33 PM, "tom petch" <ietfa@btconnect.com> wrote:

            From: Acee Lindem (acee) <acee@cisco.com>
            Sent: 16 September 2020 16:53
            To: tom petch; Acee Lindem (acee); Chris Bowers; RTGWG
            Cc: rtgwg-chairs
            Subject: Re: WG last call for draft-ietf-rtgwg-policy-model

            Hi Tom,

            On 9/16/20, 6:01 AM, "tom petch" <ietfa@btconnect.com> wrote:

                From: Acee Lindem (acee) <acee@cisco.com>
                Sent: 15 September 2020 21:37

                Hi Tom, Chris, et al,
                I've moved the non-normative sections to appendixes in the -22 version. Also, at the risk of being redundant, I included an explicit reference for the unpopular BGP sub-module prefixes.

                <tp>
                Looks good.

                Every time I read this, I see something:-(  So some trivia for as and when a new version is needed:

                container prefixes has 'is is'
            <acee>
            Fixed in -22.
            </acee>

                container conditions /returns control the/returns control to the/
            <acee>
            Fixed in -22
            </acee>

                and
                should or SHOULD? (an AD is bound to ask if we meant this:-)

            <acee>
            I think it should... Started a thread on this amongst YANG doctors. There is no consistency in published models on "description" statement validation. However, in times we've discussed this on the NETMOD list, these descriptions are normative.
            </acee>

                'chain' is probably worth expanding on.  It appears in 4.4 and is relied on in s.5 without ever a formal definition and it might not be obvious how it is represented in the YANG model. I infer that it is the leaf-list import-policy or export-policy but chain does not appear in the descriptions thereof.  So I think a sentence in 4.4 saying what a chain looks like as YANG would help as would a mention of chain alongside list in the description of export-policy and import-policy.  If my inference is wrong, then please tell me what a chain is!

            <acee>
            Good catch. I think the problem here is that "policy chain" is used for both the list of import or export policies and the list of statement within a called policy. This is clearly wrong and policy chain should only be used for the former.  Let me assure my co-authors agree.

            <tp2>
            Well yes, I think I coped with that one but it is more that I cannot program a chain in YANG the way I can in other languages, forward pointers, backward pointers and so on,  and an ordered by user leaf-list is not an immediately obvious substitute to so I would add in s.4/s.5
            'A policy chain is represented in YANG by a user-ordered leaf-list such as ...'
            and then in the YANG
            'This leaf-list implements a policy  chain as described in ...'

            Tom Petch
            Thanks,
            Acee
            </acee>

            Thanks,
            Acee

                Tom Petch

                Thanks
                Acee

                On 9/10/20, 6:10 PM, "rtgwg on behalf of Acee Lindem (acee)" <rtgwg-bounces@ietf.org on behalf of acee=40cisco.com@dmarc.ietf.org> wrote:

                    Hi Tom,

                    As previously noted, the BGP model augments the routing-policy model and not the other way around. Hence, resolution of BGP model issues is not a prerequisite for publication of this YANG model. AFAIK, none of the open issues with the BGP model are related to its augmentation of the routing-policy model.


                    Now, I'd like to see the BGP model issues addressed and the model progress as much as you but there is absolutely nothing unusual regarding its treatment.

                    Thanks,
                    Acee

                    On 9/10/20, 11:44 AM, "rtgwg on behalf of tom petch" <rtgwg-bounces@ietf.org on behalf of ietfa@btconnect.com> wrote:

                        From: rtgwg <rtgwg-bounces@ietf.org> on behalf of Chris Bowers <chrisbowers.ietf@gmail.com>
                        Sent: 09 September 2020 21:07

                        RTGWG,

                        I think there is rough WG consensus to submit draft-ietf-rtgwg-policy-model to the IESG for publication.  I will include a description of the discussion related to draft-ietf-idr-bgp-model in the shepherd writeup.  It will likely take the IESG several months to publish draft-ietf-rtgwg-policy-model.  If there are changes in draft-ietf-idr-bgp-model that make it desirable to change the text of the example in draft-ietf-rtgwg-policy-model before publication, then any changes in draft-ietf-rtgwg-policy-model will be discussed within RTGWG.

                        <tp>
                        Chris
                        The other thought that I had was that the treatment of bgp-model, which I would regard as unusual, might attract some interesting comment from such as Genart or Opsdir reviews so it might be valuable to get those done earlier rather than later.

                        Tom Petch

                        Thanks,
                        Chris


                        _______________________________________________
                        rtgwg mailing list
                        rtgwg@ietf.org
                        https://www.ietf.org/mailman/listinfo/rtgwg

                    _______________________________________________
                    rtgwg mailing list
                    rtgwg@ietf.org
                    https://www.ietf.org/mailman/listinfo/rtgwg