From nobody Fri Dec 2 06:35:58 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F971294A6; Fri, 2 Dec 2016 06:35:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148068935639.29745.3476376407202004751.idtracker@ietfa.amsl.com> Date: Fri, 02 Dec 2016 06:35:56 -0800 Archived-At: Cc: lionel.morand@orange.com, jclarke@cisco.com, draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs-chairs@ietf.org, i2rs@ietf.org Subject: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-ephemeral-state-23: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:35:56 -0000 Benoit Claise has entered the following ballot position for draft-ietf-i2rs-ephemeral-state-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My previous DISCUSS, which was ... I read REQ3 and 4 multiple times. Isn't REQ 3 a subset of REQ4? Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints that refer to operational state, this includes potentially fast changing or short lived operational state nodes, Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- ephemeral state as a constraint. Non-ephemeral state can be configuration state or operational state. I should be missing something. Examples would help me. ... as been solved with Sue's email: “This change difference was suggested by Juergen and Andy as two separate cases rather than the original one. Juergen and Andy have been concerned about the speed of testing constraints that are in the operational state if the operational state yang variables are fast changing and short-lived. They believe this requirement might not be doable in implementations. They wanted this split out from Ephemeral-REQ-04 that simply states that ephemeral state MUST be able to refer to non-ephemeral state (configuration or operational state). Since we do not know if the I2RS can handle the fast changing and short-lived ephemeral state, I think this split is a good one.” - Just one comment from Lionel's OPS DIR feedback left, that might need some clarifications. Ephemeral-REQ-11: The following requirements must be supported by the I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order to support I2RS client identity and priority: o the data nodes MAY store I2RS client identity and not the effective priority at the time the data node is stored. [LM] This requirement seems to be in contradiction with the one given in section 2 i.e. "I2RS agent MUST record the client identity when a node is created or modified.". If I'm correct, the "MAY" applies only to the "effective priority" and not to the I2RS Id storage. [Sue]: I do not understand your point. The "MAY" Deals with the fact the implementation may attach a priority to the I2RS client and choose to only store the link to the I2RS client. What is the concern here? From nobody Mon Dec 5 13:55:24 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42AE129E2A; Mon, 5 Dec 2016 13:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VBF3N60PTPpB; Mon, 5 Dec 2016 13:55:21 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 4292B129D5F; Mon, 5 Dec 2016 13:55:18 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id n6so328966183qtd.1; Mon, 05 Dec 2016 13:55:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=6vzI3sfFOSRNo/x0aDE1rvr2wVArTGLojrHlgVkKQs0=; b=jgGSHSZFCnKsYQaWGdBfHWBfdEo8ZCmsX3WmNMhx/XW1G+1C516fjzVXomfDalSGkm 3FyY6kfhH0w2pMJRfjJcz8Wnx+qWzvwKYKKV5Acsdjusc3Qu1MjDpOAswh4jw3rzY9DL CFoossOdi/0ERllB6M6/q3MzSvRZi0IWdndKONdBWGRmTWUV9c7DvR5gt/3CSHkhqslW 79G779hiwqa2NfeOsR5QYUOE1fbubVJXG1UNwJ9siOE28hWZ5u/BSOo3IlFBQ6QB4ocg 1LPzbAPYrLq1kYr8grZu8hcCMmmC6oO3iBr0I3pE4e10GUMMjzT9VHb5omK3967qTG2S YnpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6vzI3sfFOSRNo/x0aDE1rvr2wVArTGLojrHlgVkKQs0=; b=aJYxsu0A7VHL6WHAhtapLzxJV5VfBQqBj+Dag2d6FdTDQckBlWFKRyLR5WxPQWioiq IgQPTrswnSG5jiuskCoymwSVRzs6yn0rvpoCnds/87rKQjMZfgD00S0Tjupw1/9HlD9W 4RCdKcGc92Z+GNjBYQldwZLZe87lvkwPZWbMRddbg97GtIATbxH9okqjaTJPobXjgAZj o2Bhl1MTyJBoAyOZ5r/jtt7ziuoH8wZtUWRZwGnh4X1/g5/beJvioR3/5RBA3P2S7Wjx PQE0FCkTlXAAqSPLAkpWS+FbxSiarckyAnZKLW/J2AcchCTWNblWoSgOgAd02xJhhNN/ vdaA== X-Gm-Message-State: AKaTC01d4QM9R1vvhMwezRQL4izYkpm26cyLjeN9wIlv+zihRgfZGV4E5wGpzPe3YFZCAICZ0W26jGfCGKaJ8w== X-Received: by 10.200.44.196 with SMTP id 4mr50831788qtx.262.1480974917254; Mon, 05 Dec 2016 13:55:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.45.14 with HTTP; Mon, 5 Dec 2016 13:55:16 -0800 (PST) From: Alia Atlas Date: Mon, 5 Dec 2016 16:55:16 -0500 Message-ID: To: "i2rs@ietf.org" , draft-ietf-i2rs-yang-network-topo@ietf.org Content-Type: multipart/alternative; boundary=001a11357024dd458d0542f057fe Archived-At: Subject: [i2rs] AD review of draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 21:55:23 -0000 --001a11357024dd458d0542f057fe Content-Type: text/plain; charset=UTF-8 As is customary, I have done my AD review of draft-ietf-i2rs-yang-network-topo-09. First I would like to thank the authors, Alex, Jan, Hari, Nitin, Robert, & Xufeng, for their work on a very nicely written document. I do see that there are 6 authors. I am open to hearing why and how each author has and will continue to be an active participant - including through AUTH48, but this is higher than the normal limit. I am requesting that IETF Last Call start and have scheduled this for the IESG telechat on Jan 5, 2017. I do have a few minor comments below: 1) Section 5 mentions I-D.draft-acee-rtgwg-yang-rib-extend. Since this is an individual draft, it's probably better not to include it as a reference. 2) On p. 25-26, in list link description: "Layering dependencies on links in underlay topologies are not represented, as the layering information of nodes and of termination points is sufficient." This seems to contradict earlier text and the exice of the list supporting link that is immediately after. Could you please clean up or clarify? Regards, Alia --001a11357024dd458d0542f057fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As is customary, I have done my AD review of=C2=A0dra= ft-ietf-i2rs-yang-network-topo-09.=C2=A0 First I would like to thank the au= thors, Alex, Jan, Hari, Nitin, Robert, & Xufeng, for their work on a ve= ry nicely written document.

I do see that there ar= e 6 authors.=C2=A0 I am open to hearing why and how each author has and wil= l continue to be an active participant - including through AUTH48, but this= is higher than the normal limit.

I am requesting = that IETF Last Call start and have scheduled this for the IESG telechat on = Jan 5, 2017.

I do have a few minor comments below:=

1) Section 5 mentions I-D.draft-acee-rtgwg-yang-rib-extend.=C2=A0= Since this is an individual draft, it's probably better not to include= it as a reference.

2) On p. 25-26, in list link description: =C2=A0= "Layering dependencies on links in underlay topologies are
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 not represented, as the layering information of= nodes and of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 termination points is s= ufficient." =C2=A0This seems to contradict earlier text and the exice = of the list supporting link that is immediately after.=C2=A0 Could you plea= se clean up or clarify?

Regards,
Alia
--001a11357024dd458d0542f057fe-- From nobody Mon Dec 5 14:59:58 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B6512960D; Mon, 5 Dec 2016 14:59:53 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148097879297.9626.12112191933890998555.idtracker@ietfa.amsl.com> Date: Mon, 05 Dec 2016 14:59:52 -0800 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com, akatlas@gmail.com Subject: [i2rs] Last Call: (A Data Model for Network Topologies) to Proposed Standard X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 22:59:53 -0000 The IESG has received a request from the Interface to the Routing System WG (i2rs) to consider the following document: - 'A Data Model for Network Topologies' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-12-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines an abstract (generic) YANG data model for network/service topologies and inventories. The model serves as a base model which is augmented with technology-specific details in other, more specific topology and inventory models. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ballot/ No IPR declarations have been submitted directly on this I-D. From alex@sympotech.com Mon Dec 5 16:35:57 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BFC12962D; Mon, 5 Dec 2016 16:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001] autolearn=no autolearn_force=no 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 knt7LNP6d7Pi; Mon, 5 Dec 2016 16:35:56 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6646312962B; Mon, 5 Dec 2016 16:35:56 -0800 (PST) Received: from LAPTOPR7T053C2 ([47.143.86.36]) by mrelay.perfora.net (mreueus001 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MCaCy-1cMLBw34oE-009PdU; Tue, 06 Dec 2016 01:35:55 +0100 From: To: "'Alia Atlas'" , , References: In-Reply-To: Date: Mon, 5 Dec 2016 16:35:51 -0800 Message-ID: <032d01d24f58$b32ca6d0$1985f470$@sympotech.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_032E_01D24F15.A50A2A20" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQICyNJ1IcRthhlU529hdoCLOtUUbqCZHSqw Content-Language: en-us X-Provags-ID: V03:K0:F3hwkuQcxNQbhDqZRC2J2cQ/sSdMnRUHegGajG8wgwYfFUAnTqW W2g3NlkxVV++TD+dyYdPT5OC0epySc3bbo+1g6yJPWXGeoyw7BJ/6xbNBySsAmVrMvOtLxo 31IDSWcirPZsVv3YUS26EYTVbPhz22ra5XRm7OBNKJEpdBhq0Wnj1PLAks3a7LS6D/HqXf/ gQRBgfVs7PIeocAWIwfAA== X-UI-Out-Filterresults: notjunk:1;V01:K0:xY2Tq3DN/yE=:lmBlLAIRmxh9xp0g5mlT3K 3lwRE0cqQhORKDUT2bjoYTn/vQasNjfZyCUgMxrIkQ+2qujhqc8mEXqGLawGzzH0KUKb/l1rV HvqSAxZ01nwhmzE0D0o8/sajZjpEwmrt+urKubVRZkkEgeXGYl+soPKhoPIu6DLPhFcExMUxx eOdY8Oo9ve/m/a13YKl0ya+73tF/UFdT9qJoEHjC3SsALUi8zNJ+R+r05WSb/W2Vo0mY+KgQz ewPqqO1MwNhgqFWkorW848kXQPSJnBiEBOLN/MynxNgSOl1C40uzXKDdQfYp6YNOBfLb1KWyO wD9ztJnQW6ak0IyzRN8McS4Juzpk8KGF9EL+oLMWUxZm87FoIXZcAIdb50iLW75JcX4Rmur4p xtqXVUVDFzmB6y8CcUzp3ABgf0RBq7KkJ6USCTKKxC+1xEd15C+gbVjyg6WFo1XstxgvYL2kC b1usTbh8TmC4KrWgcqF3JrI5Lzqd1EuQWcNPUh3hVcT2nN09FvcvooT5gYi+nLcOqXOFFIjX6 7mPs8pFF5Q2s4d+8UlWeg30TQXGhDDFOVR1991NZvxTahhNYVh6SzOyv0threPQpVOO0VDdWd 4IpZYLMBRmNsmuYBEUqrpXowmDpxDTkUP2+FvDFDsfi5dHI/O5xKINtG6WrIGohDJVsPktDmg mMIuRExmbhZYRGeSCVnX8RyVIFzjtZ1UD6cJhpyoy0totcWKf2GZ35sj9GeMVTNHSs8yJGNIj k+tJv9Kh4h3mdRSk Archived-At: Subject: Re: [i2rs] AD review of draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 00:38:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_032E_01D24F15.A50A2A20 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Alia, =20 Thank you for your comments. =20 =20 Re: 1, we are happy to take the reference out. We felt that it would be = useful to have it for explanatory reasons to delineate it from other = efforts, but do not feel strongly about it.=20 =20 Re: 2, I am re-reading it and yes, the description is indeed = contradictory. We will take out the corresponding sentence.=20 =20 Thanks --- Alex =20 =20 From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Monday, December 5, 2016 1:55 PM To: i2rs@ietf.org; draft-ietf-i2rs-yang-network-topo@ietf.org Subject: AD review of draft-ietf-i2rs-yang-network-topo =20 As is customary, I have done my AD review of = draft-ietf-i2rs-yang-network-topo-09. First I would like to thank the = authors, Alex, Jan, Hari, Nitin, Robert, & Xufeng, for their work on a = very nicely written document. =20 I do see that there are 6 authors. I am open to hearing why and how = each author has and will continue to be an active participant - = including through AUTH48, but this is higher than the normal limit. =20 I am requesting that IETF Last Call start and have scheduled this for = the IESG telechat on Jan 5, 2017. =20 I do have a few minor comments below: 1) Section 5 mentions I-D.draft-acee-rtgwg-yang-rib-extend. Since this = is an individual draft, it's probably better not to include it as a = reference. 2) On p. 25-26, in list link description: "Layering dependencies on = links in underlay topologies are not represented, as the layering information of nodes and of termination points is sufficient." This seems to contradict = earlier text and the exice of the list supporting link that is = immediately after. Could you please clean up or clarify? =20 Regards, Alia ------=_NextPart_000_032E_01D24F15.A50A2A20 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello = Alia,

 

Thank you = for your comments.=C2=A0

 

Re: 1, we = are happy to take the reference out.=C2=A0 We felt that it would be = useful to have it for explanatory reasons to delineate it from other = efforts, but do not feel strongly about it.

 

Re: 2, I am = re-reading it and yes, the description is indeed contradictory. =C2=A0We = will take out the corresponding sentence.

 

Thanks

--- Alex = =C2=A0

 

From:<= /b> = Alia Atlas [mailto:akatlas@gmail.com]
Sent: Monday, December = 5, 2016 1:55 PM
To: i2rs@ietf.org; = draft-ietf-i2rs-yang-network-topo@ietf.org
Subject: AD review = of draft-ietf-i2rs-yang-network-topo

 

As = is customary, I have done my AD review = of draft-ietf-i2rs-yang-network-topo-09.  First I would like = to thank the authors, Alex, Jan, Hari, Nitin, Robert, & Xufeng, for = their work on a very nicely written = document.

 

I = do see that there are 6 authors.  I am open to hearing why and how = each author has and will continue to be an active participant - = including through AUTH48, but this is higher than the normal = limit.

 

I = am requesting that IETF Last Call start and have scheduled this for the = IESG telechat on Jan 5, 2017.

 

I = do have a few minor comments below:


1) Section 5 mentions = I-D.draft-acee-rtgwg-yang-rib-extend.  Since this is an individual = draft, it's probably better not to include it as a reference.

2) = On p. 25-26, in list link description:  "Layering dependencies = on links in underlay topologies are
        =   not represented, as the layering information of nodes and = of
          termination points is = sufficient."  This seems to contradict earlier text and the = exice of the list supporting link that is immediately after.  Could = you please clean up or clarify?

 

Regards,

Alia

------=_NextPart_000_032E_01D24F15.A50A2A20-- From nobody Tue Dec 6 06:37:56 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124F31294F8; Tue, 6 Dec 2016 06:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no 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 UAVHQiXj-cDL; Tue, 6 Dec 2016 06:37:53 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 BD37C1294F2; Tue, 6 Dec 2016 06:37:50 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.18.103; From: "Susan Hares" To: , "'Alia Atlas'" , , References: <032d01d24f58$b32ca6d0$1985f470$@sympotech.com> In-Reply-To: <032d01d24f58$b32ca6d0$1985f470$@sympotech.com> Date: Tue, 6 Dec 2016 09:33:24 -0500 Message-ID: <022c01d24fcd$b3e56150$1bb023f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_022D_01D24FA3.CB1091D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQICyNJ1IcRthhlU529hdoCLOtUUbgGwwYbDoIyAkZA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] AD review of draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 14:37:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_022D_01D24FA3.CB1091D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Alex: =20 The remaining question Alia needs to hear is why and how each author has = supported this work.=20 =20 Here=E2=80=99s my understanding from our earlier discussions: =20 1) Alex =E2=80=93 why (main author), how (editing text and = coordinating input),=20 2) Jan - why (early developer of yang modules (server-side in = ODL), how (created initial yang modules)=20 3) Hari =E2=80=93 why (early developer of yang modules (client = side)), how (created initial yang modules)=20 =20 Perhaps you could fill out the same input for the rest of the team: = Nitin, Robert, and Xufeng. =20 I will update the shepherd=E2=80=99s report if you send it to the list.=20 =20 Sue =20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of = alex@sympotech.com Sent: Monday, December 5, 2016 7:36 PM To: 'Alia Atlas'; i2rs@ietf.org; = draft-ietf-i2rs-yang-network-topo@ietf.org Subject: Re: [i2rs] AD review of draft-ietf-i2rs-yang-network-topo =20 Hello Alia, =20 Thank you for your comments. =20 =20 Re: 1, we are happy to take the reference out. We felt that it would be = useful to have it for explanatory reasons to delineate it from other = efforts, but do not feel strongly about it.=20 =20 Re: 2, I am re-reading it and yes, the description is indeed = contradictory. We will take out the corresponding sentence.=20 =20 Thanks --- Alex =20 =20 From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Monday, December 5, 2016 1:55 PM To: i2rs@ietf.org; draft-ietf-i2rs-yang-network-topo@ietf.org Subject: AD review of draft-ietf-i2rs-yang-network-topo =20 As is customary, I have done my AD review of = draft-ietf-i2rs-yang-network-topo-09. First I would like to thank the = authors, Alex, Jan, Hari, Nitin, Robert, & Xufeng, for their work on a = very nicely written document. =20 I do see that there are 6 authors. I am open to hearing why and how = each author has and will continue to be an active participant - = including through AUTH48, but this is higher than the normal limit. =20 I am requesting that IETF Last Call start and have scheduled this for = the IESG telechat on Jan 5, 2017. =20 I do have a few minor comments below: 1) Section 5 mentions I-D.draft-acee-rtgwg-yang-rib-extend. Since this = is an individual draft, it's probably better not to include it as a = reference. 2) On p. 25-26, in list link description: "Layering dependencies on = links in underlay topologies are not represented, as the layering information of nodes and of termination points is sufficient." This seems to contradict = earlier text and the exice of the list supporting link that is = immediately after. Could you please clean up or clarify? =20 Regards, Alia ------=_NextPart_000_022D_01D24FA3.CB1091D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Alex:

 

The remaining question Alia needs to hear is why and how each author = has supported this work.

 

Here=E2=80=99s my understanding from our earlier = discussions:

 

1)      = Alex =E2=80=93 why (main author),=C2=A0 how (editing text and = coordinating input),

2)      = Jan -=C2=A0 why (early developer of yang modules (server-side in = ODL), how (created initial yang modules)

3)      = Hari =E2=80=93 why (early developer of yang modules (client side)), = how (created initial yang modules)

 

Perhaps you could fill out the same input for the rest of the team: = Nitin, Robert, and Xufeng.

 

I will update the shepherd=E2=80=99s report if you send it to the = list.

 

Sue =C2=A0

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of = alex@sympotech.com
Sent: Monday, December 5, 2016 7:36 = PM
To: 'Alia Atlas'; i2rs@ietf.org; = draft-ietf-i2rs-yang-network-topo@ietf.org
Subject: Re: [i2rs] = AD review of = draft-ietf-i2rs-yang-network-topo

 

Hello = Alia,

 =

Thank you = for your comments. 

 =

Re: 1, we = are happy to take the reference out.  We felt that it would be = useful to have it for explanatory reasons to delineate it from other = efforts, but do not feel strongly about it.

 =

Re: 2, I = am re-reading it and yes, the description is indeed contradictory. =  We will take out the corresponding sentence. =

 =

Thanks=

--- Alex =  

 =

From: Alia = Atlas [mailto:akatlas@gmail.com] =
Sent: Monday, December 5, 2016 1:55 PM
To: i2rs@ietf.org; draft-ietf-i2r= s-yang-network-topo@ietf.org
Subject: AD review of = draft-ietf-i2rs-yang-network-topo

 

As = is customary, I have done my AD review = of draft-ietf-i2rs-yang-network-topo-09.  First I would like = to thank the authors, Alex, Jan, Hari, Nitin, Robert, & Xufeng, for = their work on a very nicely written = document.

 

I = do see that there are 6 authors.  I am open to hearing why and how = each author has and will continue to be an active participant - = including through AUTH48, but this is higher than the normal = limit.

 

I = am requesting that IETF Last Call start and have scheduled this for the = IESG telechat on Jan 5, 2017.

 

I = do have a few minor comments below:


1) Section 5 mentions = I-D.draft-acee-rtgwg-yang-rib-extend.  Since this is an individual = draft, it's probably better not to include it as a reference.

2) = On p. 25-26, in list link description:  "Layering dependencies = on links in underlay topologies are
        =   not represented, as the layering information of nodes and = of
          termination points is = sufficient."  This seems to contradict earlier text and the = exice of the list supporting link that is immediately after.  Could = you please clean up or clarify?

 

Regards,

Alia

------=_NextPart_000_022D_01D24FA3.CB1091D0-- From nobody Tue Dec 6 07:29:13 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7844812947C for ; Tue, 6 Dec 2016 07:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RbQLTDvp5NiN for ; Tue, 6 Dec 2016 07:29:07 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 8AE8D1295BC for ; Tue, 6 Dec 2016 07:29:06 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id n6so349717146qtd.1 for ; Tue, 06 Dec 2016 07:29:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=iE09LvvKpq52gvZtAFtesqfbtk4HetIjoX1XwzzjyEE=; b=uPmeqnBsF29q1Elb+xBYy1mMD2BTTMbdLJlx/gv5ngs6e4Ult7dPytXzF1ooonvOnO VE6jKqBUouw4m6NVyET2ykGHuOiC+27fX/5FesVuB8M28mtzlaMyifjEwdpAGxGFnF+r IIFkvHiGuTjN06bL+EfUb0GgGRRP1VU5lmZwLp+JNtxkJ3A3cbTnrcB0H+WUueIXiv69 GlLhmw7SRKhg6W/m34tA78NWt0XPynwUhmAFgYsiHuzF/Vv8uUfhGymixO/Me1gDOIi6 Gxfbri5d8WBLzliuOGTCy/F38AoCHr+vvpMIv3mT6gw7NETufacE6QMwvxk9bmYN6pwT W+6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=iE09LvvKpq52gvZtAFtesqfbtk4HetIjoX1XwzzjyEE=; b=eNZz8XarL8a65Ic8HMM0vn5gA7MbG4iDzu48ycj7j2vaqpKpo1aGqkRnmpgzy5jc3y Q2LzDwQRxlRPCidqH5BezCD4xdHDcdoFK6+J5JUxXHeCB1baQCQlJEXPnlVEqtUOgspw KzSPkl5/8SjOQ76qjFtnNpcWJkTgoavb1dowUJWhbM/t4Ig3RxaYjfLofiZsP5j9rrV9 jSPEu3qvGJd/KZumQ4sed+naOzOs3Xt7yRl5yPkCHPtvgTVSm5+1txezQMT/ary4whui q7tXodSfEpvUWpWJdO9VWEzfKZ8w0Dd98mPI4P8OMz2zTR9WEF1fnec9I5YpUkdLVele H67A== X-Gm-Message-State: AKaTC02zNr2a7yYGMAESWC3Z01P6T44neeVvaMWtaQLtdAqyo8+6XMzCxFbyM8FKcKa/VNbGhiPqYVDZ/jfu+g== X-Received: by 10.200.42.4 with SMTP id k4mr63469038qtk.86.1481038140000; Tue, 06 Dec 2016 07:29:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.45.14 with HTTP; Tue, 6 Dec 2016 07:28:59 -0800 (PST) From: Alia Atlas Date: Tue, 6 Dec 2016 10:28:59 -0500 Message-ID: To: "i2rs@ietf.org" , draft-i2rs-yang-l3-topology@ietf.org Content-Type: multipart/alternative; boundary=001a1138fa2a3bcff10542ff1010 Archived-At: Subject: [i2rs] AD review of draft-i2rs-yang-l3-topology-06 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 15:29:12 -0000 --001a1138fa2a3bcff10542ff1010 Content-Type: text/plain; charset=UTF-8 As is customary, I have done my AD review of draft-i2rs-yang-l3-topology-06 before progressing it to IETF Last Call. First, I would like to thank the authors and contributors of this document for their work. Regrettably, I will not progress this document with 9!!!! authors (one of whose email already bounces). Please select a few editors and update it. I have scheduled this for the January 5, 2017 telechat - which means that it must be ready for IETF Last Call no later than Dec 13 & preferrably sooner, given the end-of-year vacations typical. Please find my detailed review below. Major: a) Please clarify whether there are existing WG models that depend on this module. b) "augment /nd:networks/nd:network/nd:node/lnk:termination-point: +--rw l3-termination-point-attributes +--rw (termination-point-type)? +--:(ip) | +--rw ip-address* inet:ip-address +--:(unnumbered) +--rw unnumbered-id? uint32 " Is the unnumbered-id an ifIndex? Can you declare it with that type? Similarly in the model on p. 12: "case unnumbered { leaf unnumbered-id { type uint32; description "Unnumbered interface identifier"; }" why isn't this an ifIndex?!? Minor: 1) Intro: Please clean up paragraphs 2&3. When this is an RFC, it wont matter what the logic was for pulling the L3 topology model out. That can go. Similarly, there are existing WG drafts for IS-IS and OSPF models. Rather than "expecting", how about a reference? Are there such models? 2) Intro: Do we really need the paragraph on why to choose YANG? 3)Intro: How about an informative reference to the TED topology model? 4) Sec 2: Datastore definition - please add a pointer to the NetMod RFC that defines it or at least indicate that this isn't a new definition & where it comes from. 5) On p. 9: " typedef link-flag-type { type identityref { base "flag-identity"; } description "Prefix flag attributes"; " Shouldn't the description be "Link flag attributes"? 6) Section 6 with the non-normative examples should be an Appendix. 7) Contributors should be listed with at most address information (which usually includes affiliation) - but such affiliation should be correct!(e.g. Ken Gray) or just by name. We are all participating as individuals - not company representatives. Regards, Alia --001a1138fa2a3bcff10542ff1010 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As is customary, I have done my AD review of=C2=A0dra= ft-i2rs-yang-l3-topology-06 before progressing it to IETF Last Call.
<= div>
First, I would like to thank the authors and contributor= s of this document for their work.

Regrettably, I = will not progress this document with 9!!!! authors (one of whose email alre= ady bounces).=C2=A0 Please select a few editors and update it.=C2=A0 I have= scheduled this for the January 5, 2017 telechat - which means that it must= be ready for IETF Last Call no later than Dec 13 & preferrably sooner,= given the end-of-year vacations typical.

Please f= ind my detailed review below.

Major:
a) Please clarify whether there are existing WG models that dep= end on this module.

b) "augment /nd:netw= orks/nd:network/nd:node/lnk:termination-point:

=C2=A0 =C2=A0 =C2=A0 = +--rw l3-termination-point-attributes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw (termination-point-type)?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--:(ip)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw ip-= address* =C2=A0 =C2=A0 =C2=A0inet:ip-address
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 +--:(unnumbered)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+--rw unnumbered-id? =C2=A0 uint32 "
Is the= unnumbered-id an ifIndex?=C2=A0 Can you declare it with that type?
Similarly in the model on p. 12: =C2=A0
"case unnumbered = {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf unnumbered-id= {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Unnumbered= interface identifier";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0}"
why isn't this an ifIndex?!?

Minor:

1) Intro: Please clean up paragraphs 2&am= p;3. =C2=A0 When this is an RFC, it wont matter what the logic was for pull= ing the L3 topology model out. That can go.=C2=A0 Similarly, there are exis= ting WG drafts for IS-IS and OSPF models.=C2=A0 Rather than "expecting= ", how about a reference?=C2=A0 Are there such models?

<= /div>
2) Intro: =C2=A0Do we really need the paragraph on why to choose = YANG?

3)Intro: =C2=A0How about an informative refe= rence to the TED topology model?

4) Sec 2: Datasto= re definition - =C2=A0please add a pointer to the NetMod RFC that defines i= t or at least indicate that this isn't a new definition & where it = comes from.

5) On p. 9: =C2=A0" typedef link-= flag-type {

=C2=A0 =C2=A0 =C2=A0 =C2=A0type identityref {
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0base "flag-identity";
=C2=A0 =C2=A0= =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0description "Prefix flag= attributes"; =C2=A0"
Shouldn't the description= be "Link flag attributes"?

6) =C2=A0Sec= tion 6 with the non-normative examples should be an Appendix.
7) =C2=A0Contributors should be listed with at most address inf= ormation (which usually includes affiliation) - but such affiliation should= be correct!(e.g. Ken Gray) or just by name.=C2=A0 We are all participating= as individuals - not company representatives. =C2=A0

<= div>Regards,
Alia
--001a1138fa2a3bcff10542ff1010-- From nobody Tue Dec 6 07:30:26 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63A812947C; Tue, 6 Dec 2016 07:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dtU0Ghc_-sw7; Tue, 6 Dec 2016 07:30:22 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 5E7571294E8; Tue, 6 Dec 2016 07:30:22 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id x190so383117354qkb.0; Tue, 06 Dec 2016 07:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=50zCuc0ae06oBi0bH1oid/3Az2iqd3bK1W5cmYVz9jY=; b=OQ63quH0nNjqgJWiXtvyjbIRmlbqIvoTsy7hCxh+cXP4HeN3zuTSxsKE+qqsytu/Fu K+eX2zreqBuVpCmAVMBkEnKIzNQJMicn4CZLEk1FXW9uC6iGVWHPeHFrdhe8z9GLxAek 3UxO1CKC9/87orCpLPtFb1nagUhdbjUXHemY5Ei8DF1aSwWqA59fva29JKTsd/gZbjmF 8V3XrT3wTHxOLcbYEd+ROmX3u7a9Ks7rPVRdyZEBvfFb4YpuzZWen00aIGjfngbq5Vea 7l8sJHz2JrW8iI6w2fEJI+AdCNbclswXOzrxxT87Rw3LBNtiNk4HM4RUfSZykMORYJGE zomQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=50zCuc0ae06oBi0bH1oid/3Az2iqd3bK1W5cmYVz9jY=; b=UQ2DGnn5PYEb/e8Uw2fRjybk+Q2Wc1C3V2k6Co9xzre4sTLMGUOyzJ1c+1wY9wF06A MXHBV75zQgLZTfkPq3nA5B7vn7vvl5J6acsCAZssN3p+4GWzIwFMF7XeAyhmN2YbEYK9 y0KFrlvtCWPg+UC8AabuQ71ozfO1jkbzNniBN+uGPttAmpAlUa/xblZC1K82KQ+Vf1ll lBkxhUrdJu+rkmJdjwq0TNTEhBWFWe3IbDn7o92qdy/He23/2N965k3h3me1e48M8skw N7RngE9QNXk5EklGCQg1fsB+7kw2dPRNOMFB1z9wt+S+f2/wvnUHK1ykuThUUJlaJ7XU 0JVA== X-Gm-Message-State: AKaTC006du/tO//kmGxOdad+w7iGpm3P98FrmbSslg0KMmnRLRXu6GbfLC3UskEEqYcbpeOIMF+Ks2WUFTFosA== X-Received: by 10.55.128.3 with SMTP id b3mr54043947qkd.130.1481038221137; Tue, 06 Dec 2016 07:30:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.45.14 with HTTP; Tue, 6 Dec 2016 07:30:20 -0800 (PST) In-Reply-To: References: From: Alia Atlas Date: Tue, 6 Dec 2016 10:30:20 -0500 Message-ID: To: "i2rs@ietf.org" , draft-ietf-i2rs-yang-l3-topology@ietf.org Content-Type: multipart/alternative; boundary=94eb2c05e42611dc0e0542ff15d4 Archived-At: Subject: Re: [i2rs] AD review of draft-i2rs-yang-l3-topology-06 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 15:30:25 -0000 --94eb2c05e42611dc0e0542ff15d4 Content-Type: text/plain; charset=UTF-8 (correcting typo to send to draft authors) On Tue, Dec 6, 2016 at 10:28 AM, Alia Atlas wrote: > As is customary, I have done my AD review of draft-i2rs-yang-l3-topology-06 > before progressing it to IETF Last Call. > > First, I would like to thank the authors and contributors of this document > for their work. > > Regrettably, I will not progress this document with 9!!!! authors (one of > whose email already bounces). Please select a few editors and update it. > I have scheduled this for the January 5, 2017 telechat - which means that > it must be ready for IETF Last Call no later than Dec 13 & preferrably > sooner, given the end-of-year vacations typical. > > Please find my detailed review below. > > Major: > > a) Please clarify whether there are existing WG models that depend on this > module. > > b) "augment /nd:networks/nd:network/nd:node/lnk:termination-point: > > +--rw l3-termination-point-attributes > +--rw (termination-point-type)? > +--:(ip) > | +--rw ip-address* inet:ip-address > +--:(unnumbered) > +--rw unnumbered-id? uint32 " > Is the unnumbered-id an ifIndex? Can you declare it with that type? > Similarly in the model on p. 12: > "case unnumbered { > > leaf unnumbered-id { > type uint32; > description > "Unnumbered interface identifier"; > }" > why isn't this an ifIndex?!? > > Minor: > > 1) Intro: Please clean up paragraphs 2&3. When this is an RFC, it wont > matter what the logic was for pulling the L3 topology model out. That can > go. Similarly, there are existing WG drafts for IS-IS and OSPF models. > Rather than "expecting", how about a reference? Are there such models? > > 2) Intro: Do we really need the paragraph on why to choose YANG? > > 3)Intro: How about an informative reference to the TED topology model? > > 4) Sec 2: Datastore definition - please add a pointer to the NetMod RFC > that defines it or at least indicate that this isn't a new definition & > where it comes from. > > 5) On p. 9: " typedef link-flag-type { > > type identityref { > base "flag-identity"; > } > description "Prefix flag attributes"; " > Shouldn't the description be "Link flag attributes"? > > 6) Section 6 with the non-normative examples should be an Appendix. > > 7) Contributors should be listed with at most address information (which > usually includes affiliation) - but such affiliation should be > correct!(e.g. Ken Gray) or just by name. We are all participating as > individuals - not company representatives. > > Regards, > Alia > --94eb2c05e42611dc0e0542ff15d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(correcting typo =C2=A0to send to draft authors)

On Tue, Dec 6, 2016 a= t 10:28 AM, Alia Atlas <akatlas@gmail.com> wrote:
As is customary, I have done = my AD review of=C2=A0draft-i2rs-yang-l3-topology-06 before progressing= it to IETF Last Call.

First, I would like to than= k the authors and contributors of this document for their work.
<= br>
Regrettably, I will not progress this document with 9!!!! aut= hors (one of whose email already bounces).=C2=A0 Please select a few editor= s and update it.=C2=A0 I have scheduled this for the January 5, 2017 telech= at - which means that it must be ready for IETF Last Call no later than Dec= 13 & preferrably sooner, given the end-of-year vacations typical.

Please find my detailed review below.

Major:

a) Please clarify whether there ar= e existing WG models that depend on this module.

<= div>b) "augment /nd:networks/nd:network/nd:node/lnk:termination-p= oint:

=C2=A0 =C2=A0 =C2=A0 +--rw l3-termination-point-attribute= s
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw (termination-point-type)?
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--:(ip)
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw ip-address* =C2=A0 =C2=A0 =C2=A0inet:ip-= address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--:(unnumbered)
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw unnumbered-id?= =C2=A0 uint32 "
Is the unnumbered-id an ifIndex?=C2=A0 Can = you declare it with that type?
Similarly in the model on p. 12: = =C2=A0
"case unnumbered {

=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0leaf unnumbered-id {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0"Unnumbered interface identifier";
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}"
why isn&#= 39;t this an ifIndex?!?

Minor:

1) Intro: Please clean up paragraphs 2&3. =C2=A0 When this is an RFC, = it wont matter what the logic was for pulling the L3 topology model out. Th= at can go.=C2=A0 Similarly, there are existing WG drafts for IS-IS and OSPF= models.=C2=A0 Rather than "expecting", how about a reference?=C2= =A0 Are there such models?

2) Intro: =C2=A0Do we r= eally need the paragraph on why to choose YANG?

3)= Intro: =C2=A0How about an informative reference to the TED topology model?<= /div>

4) Sec 2: Datastore definition - =C2=A0please add = a pointer to the NetMod RFC that defines it or at least indicate that this = isn't a new definition & where it comes from.

<= div>5) On p. 9: =C2=A0" typedef link-flag-type {

=C2=A0 =C2=A0 = =C2=A0 =C2=A0type identityref {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0base &= quot;flag-identity";
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 = =C2=A0 =C2=A0description "Prefix flag attributes"; =C2=A0"
Shouldn't the description be "Link flag attributes&qu= ot;?

6) =C2=A0Section 6 with the non-normative exa= mples should be an Appendix.

7) =C2=A0Contributors= should be listed with at most address information (which usually includes = affiliation) - but such affiliation should be correct!(e.g. Ken Gray) or ju= st by name.=C2=A0 We are all participating as individuals - not company rep= resentatives. =C2=A0

Regards,
Alia
=

--94eb2c05e42611dc0e0542ff15d4-- From nobody Wed Dec 7 03:23:59 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DB6129D82; Wed, 7 Dec 2016 03:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.515 X-Spam-Level: X-Spam-Status: No, score=-5.515 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 smcx9c3zdvT6; Wed, 7 Dec 2016 03:23:56 -0800 (PST) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B94B129D9C; Wed, 7 Dec 2016 03:23:52 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id A5F1B201E6; Wed, 7 Dec 2016 12:23:50 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 62D7A1A006D; Wed, 7 Dec 2016 12:23:50 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0319.002; Wed, 7 Dec 2016 12:23:50 +0100 From: To: Benoit Claise , The IESG Thread-Topic: Benoit Claise's No Objection on draft-ietf-i2rs-ephemeral-state-23: (with COMMENT) Thread-Index: AQHSTKlmgXexP1jH70O8ym3d6vQ0TqD8Wofg Date: Wed, 7 Dec 2016 11:23:48 +0000 Message-ID: <21257_1481109830_5847F146_21257_877_1_6B7134B31289DC4FAF731D844122B36E0BFA2EFA@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <148068935639.29745.3476376407202004751.idtracker@ietfa.amsl.com> In-Reply-To: <148068935639.29745.3476376407202004751.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "jclarke@cisco.com" , "draft-ietf-i2rs-ephemeral-state@ietf.org" , "i2rs-chairs@ietf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-ephemeral-state-23: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 11:23:58 -0000 aGksDQoNCk9uIHRoZSBmb2xsb3dpbmcgcG9pbnQ6DQoNCj4gLSBKdXN0IG9uZSBjb21tZW50IGZy b20gTGlvbmVsJ3MgT1BTIERJUiBmZWVkYmFjayBsZWZ0LCB0aGF0IG1pZ2h0IG5lZWQgc29tZQ0K PiBjbGFyaWZpY2F0aW9ucy4NCj4gDQo+ICAgIEVwaGVtZXJhbC1SRVEtMTE6IFRoZSBmb2xsb3dp bmcgcmVxdWlyZW1lbnRzIG11c3QgYmUgc3VwcG9ydGVkIGJ5IHRoZQ0KPiAgICBJMlJTIHByb3Rv Y29sIEkyUlMgUHJvdG9jb2wgKGUuZy4gIE5FVENPTkYvUkVTVENPTkYgKyB5YW5nKSBpbiBvcmRl cg0KPiAgICB0byBzdXBwb3J0IEkyUlMgY2xpZW50IGlkZW50aXR5IGFuZCBwcmlvcml0eToNCj4g DQo+ICAgIG8gIHRoZSBkYXRhIG5vZGVzIE1BWSBzdG9yZSBJMlJTIGNsaWVudCBpZGVudGl0eSBh bmQgbm90IHRoZQ0KPiAgICAgICBlZmZlY3RpdmUgcHJpb3JpdHkgYXQgdGhlIHRpbWUgdGhlIGRh dGEgbm9kZSBpcyBzdG9yZWQuDQo+IA0KPiBbTE1dIFRoaXMgcmVxdWlyZW1lbnQgc2VlbXMgdG8g YmUgaW4gY29udHJhZGljdGlvbiB3aXRoIHRoZSBvbmUgZ2l2ZW4gaW4gc2VjdGlvbg0KPiAyIGku ZS4gIkkyUlMgYWdlbnQgTVVTVCByZWNvcmQgdGhlIGNsaWVudCBpZGVudGl0eSB3aGVuIGEgbm9k ZSBpcyBjcmVhdGVkIG9yDQo+IG1vZGlmaWVkLiIuIElmIEknbSBjb3JyZWN0LCB0aGUgIk1BWSIg YXBwbGllcyBvbmx5IHRvIHRoZSAiZWZmZWN0aXZlIHByaW9yaXR5IiBhbmQNCj4gbm90IHRvIHRo ZSBJMlJTIElkIHN0b3JhZ2UuDQo+IA0KPiBbU3VlXTogSSBkbyBub3QgdW5kZXJzdGFuZCB5b3Vy IHBvaW50LiAgIFRoZSAiTUFZIiBEZWFscyB3aXRoIHRoZSBmYWN0DQo+IHRoZQ0KPiBpbXBsZW1l bnRhdGlvbiBtYXkgYXR0YWNoIGEgcHJpb3JpdHkgdG8gdGhlIEkyUlMgY2xpZW50IGFuZCBjaG9v c2UgdG8gb25seQ0KPiBzdG9yZSB0aGUgbGluayB0byB0aGUgSTJSUyBjbGllbnQuICAgV2hhdCBp cyB0aGUgY29uY2VybiBoZXJlPw0KDQpNeSBjb21tZW50IHdhcyBvbiB0aGUgTUFZIGFwcGx5aW5n IHRvIGJvdGggInN0b3JlIEkyUlMgY2xpZW50IGlkZW50aXR5IiBhbmQgIm5vdCB0aGUgZWZmZWN0 aXZlIHByaW9yaXR5Ii4NClNpbmNlIHRoZW4sIHRoaXMgaGFzIGJlZW4gY2xhcmlmaWVkIGluIGFu IHVwZGF0ZWQgdmVyc2lvbiBhcyAidGhlIGRhdGEgbm9kZXMgTVVTVCBzdG9yZSBJMlJTIGNsaWVu dCBpZGVudGl0eSBhbmQgTUFZIHN0b3JlIHRoZSAgZWZmZWN0aXZlIHByaW9yaXR5IGF0IHRoZSB0 aW1lIHRoZSBkYXRhIG5vZGUgaXMgc3RvcmVkLiINCg0KTGlvbmVsDQoNCg0KPiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogQmVub2l0IENsYWlzZSBbbWFpbHRvOmJjbGFpc2VA Y2lzY28uY29tXQ0KPiBFbnZvecOpwqA6IHZlbmRyZWRpIDIgZMOpY2VtYnJlIDIwMTYgMTU6MzYN Cj4gw4DCoDogVGhlIElFU0cNCj4gQ2PCoDogZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0 ZUBpZXRmLm9yZzsgSm9lIENsYXJrZTsgaTJycy1jaGFpcnNAaWV0Zi5vcmc7DQo+IGpjbGFya2VA Y2lzY28uY29tOyBpMnJzQGlldGYub3JnOyBNT1JBTkQgTGlvbmVsIElNVC9PTE4NCj4gT2JqZXTC oDogQmVub2l0IENsYWlzZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWkycnMtZXBoZW1l cmFsLXN0YXRlLTIzOiAod2l0aA0KPiBDT01NRU5UKQ0KPiANCj4gQmVub2l0IENsYWlzZSBoYXMg ZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1p MnJzLWVwaGVtZXJhbC1zdGF0ZS0yMzogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRp bmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwg ZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVs IGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVt ZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJ RVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVu dCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToN Cj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLWVwaGVt ZXJhbC1zdGF0ZS8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IA0KPiANCj4gTXkgcHJldmlvdXMgRElTQ1VTUywgd2hpY2ggd2FzIC4u Lg0KPiAgIEkgcmVhZCBSRVEzIGFuZCA0IG11bHRpcGxlIHRpbWVzLiBJc24ndCBSRVEgMyBhIHN1 YnNldCBvZiBSRVE0Pw0KPiANCj4gICAgIEVwaGVtZXJhbC1SRVEtMDM6IEVwaGVtZXJhbCBzdGF0 ZSBNVVNUIGJlIGFibGUgdG8gaGF2ZSBjb25zdHJhaW50cw0KPiAgICAgICAgdGhhdCByZWZlciB0 byBvcGVyYXRpb25hbCBzdGF0ZSwgdGhpcyBpbmNsdWRlcyBwb3RlbnRpYWxseSBmYXN0DQo+ICAg ICAgICBjaGFuZ2luZyBvciBzaG9ydCBsaXZlZCBvcGVyYXRpb25hbCBzdGF0ZSBub2RlcywNCj4g DQo+IA0KPiAgICBFcGhlbWVyYWwtUkVRLTA0OiBFcGhlbWVyYWwgc3RhdGUgTVVTVCBiZSBhYmxl IHRvIHJlZmVyIHRvIG5vbi0NCj4gICAgZXBoZW1lcmFsIHN0YXRlIGFzIGEgY29uc3RyYWludC4g IE5vbi1lcGhlbWVyYWwgc3RhdGUgY2FuIGJlDQo+ICAgIGNvbmZpZ3VyYXRpb24gc3RhdGUgb3Ig b3BlcmF0aW9uYWwgc3RhdGUuDQo+IA0KPiAgSSBzaG91bGQgYmUgbWlzc2luZyBzb21ldGhpbmcu IEV4YW1wbGVzIHdvdWxkIGhlbHAgbWUuDQo+IC4uLiBhcyBiZWVuIHNvbHZlZCB3aXRoIFN1ZSdz IGVtYWlsOg0KPiANCj4g4oCcVGhpcyBjaGFuZ2UgZGlmZmVyZW5jZSB3YXMgc3VnZ2VzdGVkIGJ5 IEp1ZXJnZW4gYW5kIEFuZHkgYXMgdHdvIHNlcGFyYXRlDQo+IGNhc2VzIHJhdGhlciB0aGFuIHRo ZSBvcmlnaW5hbCBvbmUuDQo+ICAgSnVlcmdlbiBhbmQgQW5keSBoYXZlIGJlZW4gY29uY2VybmVk IGFib3V0IHRoZSBzcGVlZCBvZiB0ZXN0aW5nIGNvbnN0cmFpbnRzDQo+IHRoYXQgYXJlIGluIHRo ZSBvcGVyYXRpb25hbCBzdGF0ZSBpZiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUNCj4geWFuZyB2YXJp YWJsZXMgYXJlIGZhc3QgY2hhbmdpbmcgYW5kIHNob3J0LWxpdmVkLiAgICBUaGV5IGJlbGlldmUg dGhpcw0KPiByZXF1aXJlbWVudCBtaWdodCBub3QgYmUgZG9hYmxlIGluIGltcGxlbWVudGF0aW9u cy4gIFRoZXkgd2FudGVkIHRoaXMgc3BsaXQgb3V0DQo+IGZyb20gRXBoZW1lcmFsLVJFUS0wNCB0 aGF0IHNpbXBseSBzdGF0ZXMgdGhhdCBlcGhlbWVyYWwgc3RhdGUgTVVTVCBiZSBhYmxlDQo+IHRv IHJlZmVyIHRvIG5vbi1lcGhlbWVyYWwgc3RhdGUgKGNvbmZpZ3VyYXRpb24gb3Igb3BlcmF0aW9u YWwgc3RhdGUpLiAgU2luY2Ugd2UNCj4gZG8gbm90IGtub3cgaWYgdGhlIEkyUlMgY2FuIGhhbmRs ZSB0aGUgZmFzdCBjaGFuZ2luZyBhbmQgc2hvcnQtbGl2ZWQgZXBoZW1lcmFsDQo+IHN0YXRlLCBJ IHRoaW5rIHRoaXMgc3BsaXQgaXMgYSBnb29kIG9uZS7igJ0NCj4gDQo+IA0KPiAtIEp1c3Qgb25l IGNvbW1lbnQgZnJvbSBMaW9uZWwncyBPUFMgRElSIGZlZWRiYWNrIGxlZnQsIHRoYXQgbWlnaHQg bmVlZCBzb21lDQo+IGNsYXJpZmljYXRpb25zLg0KPiANCj4gICAgRXBoZW1lcmFsLVJFUS0xMTog VGhlIGZvbGxvd2luZyByZXF1aXJlbWVudHMgbXVzdCBiZSBzdXBwb3J0ZWQgYnkgdGhlDQo+ICAg IEkyUlMgcHJvdG9jb2wgSTJSUyBQcm90b2NvbCAoZS5nLiAgTkVUQ09ORi9SRVNUQ09ORiArIHlh bmcpIGluIG9yZGVyDQo+ICAgIHRvIHN1cHBvcnQgSTJSUyBjbGllbnQgaWRlbnRpdHkgYW5kIHBy aW9yaXR5Og0KPiANCj4gICAgbyAgdGhlIGRhdGEgbm9kZXMgTUFZIHN0b3JlIEkyUlMgY2xpZW50 IGlkZW50aXR5IGFuZCBub3QgdGhlDQo+ICAgICAgIGVmZmVjdGl2ZSBwcmlvcml0eSBhdCB0aGUg dGltZSB0aGUgZGF0YSBub2RlIGlzIHN0b3JlZC4NCj4gDQo+IFtMTV0gVGhpcyByZXF1aXJlbWVu dCBzZWVtcyB0byBiZSBpbiBjb250cmFkaWN0aW9uIHdpdGggdGhlIG9uZSBnaXZlbiBpbiBzZWN0 aW9uDQo+IDIgaS5lLiAiSTJSUyBhZ2VudCBNVVNUIHJlY29yZCB0aGUgY2xpZW50IGlkZW50aXR5 IHdoZW4gYSBub2RlIGlzIGNyZWF0ZWQgb3INCj4gbW9kaWZpZWQuIi4gSWYgSSdtIGNvcnJlY3Qs IHRoZSAiTUFZIiBhcHBsaWVzIG9ubHkgdG8gdGhlICJlZmZlY3RpdmUgcHJpb3JpdHkiIGFuZA0K PiBub3QgdG8gdGhlIEkyUlMgSWQgc3RvcmFnZS4NCj4gDQo+IFtTdWVdOiBJIGRvIG5vdCB1bmRl cnN0YW5kIHlvdXIgcG9pbnQuICAgVGhlICJNQVkiIERlYWxzIHdpdGggdGhlIGZhY3QNCj4gdGhl DQo+IGltcGxlbWVudGF0aW9uIG1heSBhdHRhY2ggYSBwcmlvcml0eSB0byB0aGUgSTJSUyBjbGll bnQgYW5kIGNob29zZSB0byBvbmx5DQo+IHN0b3JlIHRoZSBsaW5rIHRvIHRoZSBJMlJTIGNsaWVu dC4gICBXaGF0IGlzIHRoZSBjb25jZXJuIGhlcmU/DQo+IA0KDQoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBl dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2 b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy CmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50 ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy YXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5v dCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3Uu Cgo= From nobody Wed Dec 7 08:14:54 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D40B5129FAA; Wed, 7 Dec 2016 08:14:47 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148112728786.13602.17050144171915235097.idtracker@ietfa.amsl.com> Date: Wed, 07 Dec 2016 08:14:47 -0800 Archived-At: Cc: i2rs@ietf.org, jclarke@cisco.com, i2rs-chairs@ietf.org, akatlas@gmail.com, draft-ietf-i2rs-ephemeral-state@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [i2rs] Document Action: 'I2RS Ephemeral State Requirements' to Informational RFC (draft-ietf-i2rs-ephemeral-state-23.txt) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 16:14:48 -0000 The IESG has approved the following document: - 'I2RS Ephemeral State Requirements' (draft-ietf-i2rs-ephemeral-state-23.txt) as Informational RFC This document is the product of the Interface to the Routing System Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ Technical Summary This document describes requirements for those implementing the I2RS higher-layer protocol (i.e., netconf and netmod IETF working groups) for functionality to support ephemeral state. Working Group Summary This draft has been debated over the past three years, and at IETF 96 - netconf and i2rs WG straw-polls had no comments. This was included in netmod's longer discussion on operational state. The Working group process ran from August 2 to August 15, please see https://www.ietf.org/mail-archive/web/i2rs/current/msg03858.html Conclusion of the WG LC is at: https://www.ietf.org/mail-archive/web/i2rs/current/msg03984.html Follow-up to WG LC is at: https://www.ietf.org/mail-archive/web/i2rs/current/msg03989.html Document Quality OpenDaylight, Juniper, and the IETF hackathon have created existing pre-standard work. This draft documents the requirements around the ephemeral state concept that is core to the functionality of I2RS. These requirements have been discussed at netmod, netconf, and i2rs working group meetings. Personnel Document Shepherd: Joe Clarke AD: Alia Atlas Working Group Chairs: Sue Hares and Russ White From nobody Wed Dec 7 08:32:10 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594D6129FAB for ; Wed, 7 Dec 2016 08:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no 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 rCZGggTIqtPx for ; Wed, 7 Dec 2016 08:32:03 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 999F4129F7B for ; Wed, 7 Dec 2016 08:32:03 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.18.103; From: "Susan Hares" To: References: <148112728786.13602.17050144171915235097.idtracker@ietfa.amsl.com> In-Reply-To: <148112728786.13602.17050144171915235097.idtracker@ietfa.amsl.com> Date: Wed, 7 Dec 2016 11:29:04 -0500 Message-ID: <011601d250a7$0708bf60$151a3e20$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJkm41noKICzpnKed7bHYnq9NKRX5/YE4xw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [i2rs] FW: Document Action: 'I2RS Ephemeral State Requirements' to Informational RFC (draft-ietf-i2rs-ephemeral-state-23.txt) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 16:32:09 -0000 Congratulation to the I2RS WG! All of the I2RS protocol requirements are through the IESG. Sue Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of The IESG Sent: Wednesday, December 7, 2016 11:15 AM To: IETF-Announce Cc: i2rs@ietf.org; jclarke@cisco.com; i2rs-chairs@ietf.org; akatlas@gmail.com; draft-ietf-i2rs-ephemeral-state@ietf.org; The IESG; rfc-editor@rfc-editor.org Subject: [i2rs] Document Action: 'I2RS Ephemeral State Requirements' to Informational RFC (draft-ietf-i2rs-ephemeral-state-23.txt) The IESG has approved the following document: - 'I2RS Ephemeral State Requirements' (draft-ietf-i2rs-ephemeral-state-23.txt) as Informational RFC This document is the product of the Interface to the Routing System Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ Technical Summary This document describes requirements for those implementing the I2RS higher-layer protocol (i.e., netconf and netmod IETF working groups) for functionality to support ephemeral state. Working Group Summary This draft has been debated over the past three years, and at IETF 96 - netconf and i2rs WG straw-polls had no comments. This was included in netmod's longer discussion on operational state. The Working group process ran from August 2 to August 15, please see https://www.ietf.org/mail-archive/web/i2rs/current/msg03858.html Conclusion of the WG LC is at: https://www.ietf.org/mail-archive/web/i2rs/current/msg03984.html Follow-up to WG LC is at: https://www.ietf.org/mail-archive/web/i2rs/current/msg03989.html Document Quality OpenDaylight, Juniper, and the IETF hackathon have created existing pre-standard work. This draft documents the requirements around the ephemeral state concept that is core to the functionality of I2RS. These requirements have been discussed at netmod, netconf, and i2rs working group meetings. Personnel Document Shepherd: Joe Clarke AD: Alia Atlas Working Group Chairs: Sue Hares and Russ White _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Dec 9 03:18:42 2016 Return-Path: <7riw77@gmail.com> X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB93312A3F4 for ; Fri, 9 Dec 2016 03:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1SuYMco5OaIb for ; Fri, 9 Dec 2016 03:18:39 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 8EFC912A42B for ; Fri, 9 Dec 2016 03:12:01 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id i145so11642335ywg.2 for ; Fri, 09 Dec 2016 03:12:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:content-language:thread-index; bh=lCsFFVNMwq4Led42Ln8vue+Epriq727nZNTZo0TVReY=; b=ZZVZtmeRTwbVv/NF0totI/M/mFmxAWre86OKJkBmcBHS/yh+krPbbIGVFlWVs3sjrH 78Cdd/uaPF8kwjL6jMtgFfU1qOvtySXDR4xk2JrpL8X9RtU/2HUdWIhw361vgx0CzlNR kthpMVq7pl2E87wFEXn0wCGCQkCi2cBsaZUvV+FvYqv/i0cKqATA+ZLRkP7yQ+5xgdeP 0qMGK3jlyQN+EiGXVKCDulMVpgnH+26aFHNP0nKaS42m5dcg2iDjVCewT6ztg9PArj5J zb9hNdCjkO7/N0LBv0sxn98Rzf61YQw2OTjkuZPk3rDUuswF1kHni2xGhiAZbXBG8gya wDgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=lCsFFVNMwq4Led42Ln8vue+Epriq727nZNTZo0TVReY=; b=HLA/70eHNKn4ZJl6ST2HKH2RJyz00f9Hsyp6dr/Km3c56YNoEMIl31+q06fWap3vvj J/jOwit7VTnVVIXYE1D1iBpAjVDR5Rp1F73RtI66dc0AgbWIKr6R9SVgTTH4g3fanCbj XtPT0YtWhdppLY7Lx6zQ+8/evzGY40ivrsup80rkcJgzZrBDyNfMZzD+r0eVCoESWoL/ 9thowHOdHRxy7mkSJvFJossjjOUF9xAcO9Go4mwdOR3ziVmsSsVCCbV4ZiGWL0gM4P7R 4efVY90LA/gygt5pQ+2BfJmTr12AhJ2Qiuf586+8hPBSf06ha+jEFL34r4vNG22oUwZx Mn4A== X-Gm-Message-State: AKaTC01CN4G6r30uEcJzpYM9vd7OLQBR0TWOUdLHl5/8/gmpdsVW6ob3xFKFOrXwyvjOOg== X-Received: by 10.129.79.70 with SMTP id d67mr70615178ywb.303.1481281920852; Fri, 09 Dec 2016 03:12:00 -0800 (PST) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id k14sm13294613ywi.11.2016.12.09.03.12.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Dec 2016 03:12:00 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: References: <148112728786.13602.17050144171915235097.idtracker@ietfa.amsl.com> <011601d250a7$0708bf60$151a3e20$@ndzh.com> In-Reply-To: <011601d250a7$0708bf60$151a3e20$@ndzh.com> Date: Fri, 9 Dec 2016 06:12:00 -0500 Message-ID: <00bb01d2520d$1077b9e0$31672da0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJkm41noKICzpnKed7bHYnq9NKRXwFgQ8cgn8/gv9A= Archived-At: Subject: Re: [i2rs] FW: Document Action: 'I2RS Ephemeral State Requirements' to Informational RFC (draft-ietf-i2rs-ephemeral-state-23.txt) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 11:18:41 -0000 > Congratulation to the I2RS WG! All of the I2RS protocol requirements are > through the IESG. This is a great piece of work -- thanks to everyone who helped out in making this happen. :-) Russ From nobody Mon Dec 12 06:30:38 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 503B1129BFF for ; Mon, 12 Dec 2016 06:30:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148155303732.22388.17816303757715190318.idtracker@ietfa.amsl.com> Date: Mon, 12 Dec 2016 06:30:37 -0800 From: IETF Secretariat Archived-At: Subject: [i2rs] Milestones changed for i2rs WG X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 14:30:37 -0000 Changed milestone "Request Publication of Filter-Based RIB Data Model ", set state to active from review, accepting new milestone. Changed milestone "Working Group adoption of Filter-Based RIB Yang Data Model ", set state to active from review, accepting new milestone. Changed milestone "Request Publication of Protocol Independent RIB Data Model ", set state to active from review, accepting new milestone. Changed milestone "Request Publication of Protocol Independent Topology Data Models ", set state to active from review, accepting new milestone, set due date to December 2016 from September 2016. URL: https://datatracker.ietf.org/wg/i2rs/charter/ From nobody Tue Dec 13 23:15:20 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C66129731; Tue, 13 Dec 2016 23:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001] autolearn=no autolearn_force=no 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 Tl5HqVK8lUXm; Tue, 13 Dec 2016 23:15:17 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 517AA129865; Tue, 13 Dec 2016 23:15:17 -0800 (PST) Received: from LAPTOPR7T053C2 ([47.143.86.36]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0M88bH-1cUJGe1jk1-00vgLW; Wed, 14 Dec 2016 08:15:01 +0100 From: To: "'Susan Hares'" , , "'Alia Atlas'" , , References: <032d01d24f58$b32ca6d0$1985f470$@sympotech.com> <022c01d24fcd$b3e56150$1bb023f0$@ndzh.com> In-Reply-To: <022c01d24fcd$b3e56150$1bb023f0$@ndzh.com> Date: Tue, 13 Dec 2016 23:15:00 -0800 Message-ID: <00db01d255d9$ca0ab810$5e202830$@clemm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DC_01D25596.BBE94CD0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQICyNJ1IcRthhlU529hdoCLOtUUbgGwwYbDAaqwFcKgiz9NoA== Content-Language: en-us X-Provags-ID: V03:K0:9fOikaB3vuEP2vu0CUXjB+3DH/lpUBhxp31uStUx1AP0a/nHSq/ Q67P7eMrgUR0IH19PlWgdgKanQzKVLAOl7OncRbD6Vplt5frlzqaAQAT52j0OYfF/0lns8W WwfB2xuN0A9bXPyrsO+188QE1gHkudvEjLuF4IeHO+ckKpgK8ltcNeGPSC0aegy0/cxCRws 7Cel1IzvjqMcVqoxowvlQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:7328PEBXjH0=:5MVmuwRUCd4H+AoRAxEmno ms4RGU2IXG0TiIU9mvHC22xxsc0zHRaIwp+gZzT3eMBwIA5T2xrbGwOk/8n6BgDPz9x28xPnD WweOXhD1TiYdmOzu88gunOLvRzbilTjjpXA37Vb/CkPkPKsZb0Vws1HUJbj6wIo61B+X849sm ic5+HmJQWzlpix/Uiv6WmT2xnwRZZ5l9qhlG60LBpOkRyUx5QYjJEwTmsyhvuqyjudvqRt7qH qQg7tZnbCFrLD7gIKzlx2atKmoRFiDSRwRXlUQOFhKN2BOHZHV/CMYEBZgxn5N7Cd6c+hkuoo 0CSItGlRWWK14A7FfU2r0qxekh8PNy5MEBXw72SMTVIaTFo7HK2Tqtb0qu5WJCXeICkQTZF2t Y5bBgaU2vrZd8CQqhh8Bh+Q+vXS21B3iHKRXY5Pt/P0cnICKgAzDu2rjoZsYHrePjQqoKoKfA /7kUIv371wsOaue9FnhaGDmn0wTUISXCCExD0WL8tvFBjYKX/O/kyBBnjsy4yyG+NnmpA4IB8 F4ukCaSaUuz5eEaBwdf0cIr9yASahywZBYVwqi1QxqLrxNDFH0ANRYtXQBz9q6NueCifqTU8f Tpid1w1U4Cp0bqUwaEObBXmT6IvO97jtenkvtctjki/0RQ9Vjdj3MCaoQw9m+0mUkcDROkuer AhO4rgTJfFdQ4ey709HdxhWVzDw3zXQ7o5hi7sv/p+vGm8XU3nBpQXcQJiKfGpDAYAchRghag LS0SR+f4RderBKqR Archived-At: Subject: Re: [i2rs] AD review of draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 07:15:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DC_01D25596.BBE94CD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Susan, Alia,=20 =20 Apologies for the delay.=20 =20 Here is the table regarding the coauthors of the topology model draft: =20 1) Alex - main editor of draft, coauthor of initial yang modules=20 2) Jan - early developer of yang module (server-side in ODL), = coauthor of initial yang modules=20 3) Robert =E2=80=93 early developer of yang modules and lead in = implementation in ODL, coauthor of initial yang modules 4) Nitin =E2=80=93 early developer of yang modules, coauthor of = initial yang modules, in part some earlier efforts coming from different = origins got merged=20 5) Hari =E2=80=93 early developer of yang module implementations = (client side), coauthor of initial yang modules=20 6) Xufeng =E2=80=93 scrutinization and refinement of important yang = module details, derivation of and integration with other topolog yang = modules including TE topology, Layer 1 topology, L3 TE topology, and SR = topology providing important adjustments in the model for greater = robustness=20 =20 I sincerely believe that having all six of us listed as authors is = justified. The draft is the result of the collaboration of multiple = persons from several independent teams (originally, Jan/Robert/myself = were working on this problem in one collaboration, whereas Nitin and = Hari had a separate collaboration and Xufeng coming from a different = direction still, but we all came together to combine our designs) and = coming from very different directions (with controller and ODL = perspective in mind, with routing perspective in mind, with TE = perspective in mind, with optical perspective in mind) over a long = period of time. In addition, all six of us represent different = organizations/companies. =20 =20 Thanks --- Alex=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, December 6, 2016 6:33 AM To: alex@sympotech.com; 'Alia Atlas' ; i2rs@ietf.org; = draft-ietf-i2rs-yang-network-topo@ietf.org Subject: Re: [i2rs] AD review of draft-ietf-i2rs-yang-network-topo =20 Alex: =20 The remaining question Alia needs to hear is why and how each author has = supported this work.=20 =20 Here=E2=80=99s my understanding from our earlier discussions: =20 1) Alex =E2=80=93 why (main author), how (editing text and = coordinating input),=20 2) Jan - why (early developer of yang modules (server-side in = ODL), how (created initial yang modules)=20 3) Hari =E2=80=93 why (early developer of yang modules (client = side)), how (created initial yang modules)=20 =20 Perhaps you could fill out the same input for the rest of the team: = Nitin, Robert, and Xufeng. =20 I will update the shepherd=E2=80=99s report if you send it to the list.=20 =20 Sue =20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of = alex@sympotech.com =20 Sent: Monday, December 5, 2016 7:36 PM To: 'Alia Atlas'; i2rs@ietf.org ; = draft-ietf-i2rs-yang-network-topo@ietf.org = =20 Subject: Re: [i2rs] AD review of draft-ietf-i2rs-yang-network-topo =20 Hello Alia, =20 Thank you for your comments. =20 =20 Re: 1, we are happy to take the reference out. We felt that it would be = useful to have it for explanatory reasons to delineate it from other = efforts, but do not feel strongly about it.=20 =20 Re: 2, I am re-reading it and yes, the description is indeed = contradictory. We will take out the corresponding sentence.=20 =20 Thanks --- Alex =20 =20 From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Monday, December 5, 2016 1:55 PM To: i2rs@ietf.org ; = draft-ietf-i2rs-yang-network-topo@ietf.org = =20 Subject: AD review of draft-ietf-i2rs-yang-network-topo =20 As is customary, I have done my AD review of = draft-ietf-i2rs-yang-network-topo-09. First I would like to thank the = authors, Alex, Jan, Hari, Nitin, Robert, & Xufeng, for their work on a = very nicely written document. =20 I do see that there are 6 authors. I am open to hearing why and how = each author has and will continue to be an active participant - = including through AUTH48, but this is higher than the normal limit. =20 I am requesting that IETF Last Call start and have scheduled this for = the IESG telechat on Jan 5, 2017. =20 I do have a few minor comments below: 1) Section 5 mentions I-D.draft-acee-rtgwg-yang-rib-extend. Since this = is an individual draft, it's probably better not to include it as a = reference. 2) On p. 25-26, in list link description: "Layering dependencies on = links in underlay topologies are not represented, as the layering information of nodes and of termination points is sufficient." This seems to contradict = earlier text and the exice of the list supporting link that is = immediately after. Could you please clean up or clarify? =20 Regards, Alia ------=_NextPart_000_00DC_01D25596.BBE94CD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Susan, = Alia,

 

Apologies = for the delay.

 

Here is the = table regarding the coauthors of the topology model = draft:

 

1)      = Alex - main = editor of draft, coauthor of initial yang modules =

2)      = Jan -  = early developer of yang module (server-side in ODL), coauthor of initial = yang modules

3)      = Robert = =E2=80=93 early developer of yang modules and lead in implementation in = ODL, coauthor of initial yang modules

4)      = Nitin = =E2=80=93 early developer of yang modules, coauthor of initial yang = modules, in part some earlier efforts coming from different origins got = merged

5)      = Hari = =E2=80=93 early developer of yang module implementations (client side), = coauthor of initial yang modules

6)      = Xufeng = =E2=80=93 scrutinization and refinement of important yang module = details, derivation of and integration with other topolog yang modules = including TE topology, Layer 1 topology, L3 TE topology, and SR topology = providing important adjustments in the model for greater robustness =

 

I sincerely = believe that having all six of us listed as authors is justified.=C2=A0 = The draft is the result of the collaboration of multiple persons from = several independent teams (originally, Jan/Robert/myself were working on = this problem in one collaboration, whereas Nitin and Hari had a separate = collaboration and Xufeng coming from a different direction still, but we = all came together to combine our designs) and coming from very different = directions (with controller and ODL perspective in mind, with routing = perspective in mind, with TE perspective in mind, with optical = perspective in mind) over a long period of time. =C2=A0=C2=A0In = addition, all six of us represent different = organizations/companies.=C2=A0

 

Thanks

--- Alex =

 

From:<= /b> = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Tuesday, December 6, 2016 6:33 AM
To: = alex@sympotech.com; 'Alia Atlas' <akatlas@gmail.com>; = i2rs@ietf.org; = draft-ietf-i2rs-yang-network-topo@ietf.org
Subject: Re: [i2rs] = AD review of = draft-ietf-i2rs-yang-network-topo

 

Alex:

 

The remaining question Alia needs to hear is why and how each author = has supported this work.

 

Here=E2=80=99s my understanding from our earlier = discussions:

 

1)      = Alex =E2=80=93 why (main author),  how (editing text and = coordinating input),

2)      = Jan -  why (early developer of yang modules (server-side in ODL), = how (created initial yang modules)

3)      = Hari =E2=80=93 why (early developer of yang modules (client side)), how = (created initial yang modules)

 

Perhaps you could fill out the same input for the rest of the team: = Nitin, Robert, and Xufeng.

 

I will update the shepherd=E2=80=99s report if you send it to the list. =

 

Sue  

 

From: i2rs = [mailto:i2rs-bounces@ietf.org] = On Behalf Of alex@sympotech.com
Sent:= Monday, December 5, 2016 7:36 PM
To: 'Alia Atlas'; i2rs@ietf.org; draft-ietf-i2r= s-yang-network-topo@ietf.org
Subject: Re: [i2rs] AD review = of draft-ietf-i2rs-yang-network-topo

 

Hello = Alia,

 

Thank you = for your comments. 

 

Re: 1, we = are happy to take the reference out.  We felt that it would be = useful to have it for explanatory reasons to delineate it from other = efforts, but do not feel strongly about it.

 

Re: 2, I am = re-reading it and yes, the description is indeed contradictory.  We = will take out the corresponding sentence.

 

Thanks

--- Alex =  

 

From:<= /b> = Alia Atlas [mailto:akatlas@gmail.com] =
Sent: Monday, December 5, 2016 1:55 PM
To: i2rs@ietf.org; draft-ietf-i2r= s-yang-network-topo@ietf.org
Subject: AD review of = draft-ietf-i2rs-yang-network-topo

 

As = is customary, I have done my AD review = of draft-ietf-i2rs-yang-network-topo-09.  First I would like = to thank the authors, Alex, Jan, Hari, Nitin, Robert, & Xufeng, for = their work on a very nicely written = document.

 

I = do see that there are 6 authors.  I am open to hearing why and how = each author has and will continue to be an active participant - = including through AUTH48, but this is higher than the normal = limit.

 

I = am requesting that IETF Last Call start and have scheduled this for the = IESG telechat on Jan 5, 2017.

 

I = do have a few minor comments below:


1) Section 5 mentions = I-D.draft-acee-rtgwg-yang-rib-extend.  Since this is an individual = draft, it's probably better not to include it as a reference.

2) = On p. 25-26, in list link description:  "Layering dependencies = on links in underlay topologies are
        =   not represented, as the layering information of nodes and = of
          termination points is = sufficient."  This seems to contradict earlier text and the = exice of the list supporting link that is immediately after.  Could = you please clean up or clarify?

 

Regards,

Alia

------=_NextPart_000_00DC_01D25596.BBE94CD0-- From nobody Wed Dec 14 02:41:23 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8566712997C; Wed, 14 Dec 2016 02:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 x8D2M46ynH_v; Wed, 14 Dec 2016 02:41:15 -0800 (PST) Received: from mail-wj0-x22c.google.com (mail-wj0-x22c.google.com [IPv6:2a00:1450:400c:c01::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 47616129594; Wed, 14 Dec 2016 02:41:12 -0800 (PST) Received: by mail-wj0-x22c.google.com with SMTP id tk12so26393277wjb.3; Wed, 14 Dec 2016 02:41:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=rUbUdSN07eDHodOzFAWWtjlZ5bpr692cG3oJz9bAG1c=; b=wKLTVaK0dUbp6HA9TfCQ+2+zH2tB+yrP9uRVLMCvPpHQOL8BJQTnNsW6DZDX8ApL0t NrVivPoXnEeFR/CPCXWAwjMsJ/KfCSmo0wbGcWs35opOjC3ikipkvS88/tLQaoOfd/L5 tsAeQgFkf3KoysY9PBKixYC1CkorWYoUOZZoDRrGFrq6ewTlNuN0wm3r0zdXwbaJE9Py x0q/6jDedeET/KuhGN+BGxtiqaijEUS63pDf7UCFuglwhMppc7/DqHZQgv4JQzuWwAMv hcrkvaDiUXRqRrcr/MD6iqervLEXs50FRF+Iwx7cAmitbClNJsuX5IUYJTVnBKvEolWV vXzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=rUbUdSN07eDHodOzFAWWtjlZ5bpr692cG3oJz9bAG1c=; b=LeDbQc+Pa8JLFMc/Z67JpDS4vRuk/wRSavUZZENBf7CofckvxfhA0ziuMGtWVfmcK7 cBNWKPWaHJr/fa3ol+gYnlwuny8QpEA0/lLduhy+Z7R1yfoOcJJ89hpW86qgp8pkLOHq 061ZA3y4cQFXZ+ve4nXVM7El17AJo7aAulDbgzHrUQe/VoH+CZauaLRD9AKqSDTY5WfO zDKhOlUyqRIonE9Nsxp+Jeptr0I6ZTSBeVKkcobJxLAd1J9ARpmdwBVlQvPnp+KHb++L JJqeEzTgqZiyh8BtpyKADf3ZppMRX8A7rYPQErrSfANC9V+2mwAu7PJFW6+nuPB7Tkjr XY1Q== X-Gm-Message-State: AKaTC00kIgMdk98Lb2NVGVT7PsDKDxEprG/qvaIsiotUHpDh4fr3Wvza24F92hxPdfctgA== X-Received: by 10.28.166.20 with SMTP id p20mr6627825wme.87.1481712070092; Wed, 14 Dec 2016 02:41:10 -0800 (PST) Received: from [192.168.2.131] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id e5sm6956043wma.12.2016.12.14.02.41.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Dec 2016 02:41:09 -0800 (PST) From: Stewart Bryant To: General Area Review Team , draft-ietf-i2rs-yang-network-topo.all@ietf.org, i2rs@ietf.org, IETF Discussion Message-ID: <0cadda16-bafb-6f98-f01b-2f1261747f20@gmail.com> Date: Wed, 14 Dec 2016 10:41:07 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [i2rs] Genart LC review: draft-ietf-i2rs-yang-network-topo-09 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 10:41:17 -0000 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-i2rs-yang-network-topo-09 Reviewer: Stewart Bryant Review Date: 12 Dec 2016 IETF LC End Date: 19 Dec 2016 IESG Telechat date: 5 Jan 2017 Summary: Ready with issues This is a well written document and is basically ready for publication and the issues are minor. There are a number of minor issues that the responsible AD needs to look into, and a systematic English problem (missing pronouns) that the authors ought fix to avoid the RFC Editor having to ask. There are six authors which I assume is acceptable. I am not a YANG expert and have therefore not checked the YANG syntax or logic. Detail: ========= 1. Introduction This document introduces an abstract (base) YANG [RFC7950] [RFC6991] data model to represent networks and topologies. The data model is divided into two parts. The first part of the model defines a network model that allows to define network hierarchies (i.e. network SB> minor English problem : "allows to define" perhaps "allows the SB> definition of" or "allows an operator to define". stacks) and to maintain an inventory of nodes contained in a network. SB> same problem as above. SB> Also I am a little worried that the term "network stack" is going to SB> to confuse a lot of people. Many will confuse network stack with SB> protocol stack. There probably needs to be some text explaining SB> the difference. ======== While it would be possible to combine both parts into a single model, the separation facilitates integration of network topology and network inventory models, by allowing to augment network inventory information separately and without concern for topology into the network model. SB> same English problem - "by allowing to augment" The model can be augmented to describe specifics of particular types SB> describe THE specifics of networks and topologies. For example, an augmenting model can SB> Not sure is that should be augmenting or augmented (same further SB> down the para). ============= The basic data models introduced in this document are generic in nature and can be applied to many network and service topologies and inventories. The models allow applications to operate on an inventory or topology of any network at a generic level, where specifics of particular inventory/topology types are not required. At the same time, where data specific to a network type does comes into play and the model is augmented, the instantiated data still adheres to the same structure and is represented in consistent SB> nit: in a consistent fashion. This also facilitates the representation of network hierarchies and dependencies between different network components and network types. The abstract (base) network YANG module introduced in this document, entitled "network.yang", contains a list of abstract network nodes and defines the concept of network hierarchy (network stack). The abstract network node can be augmented in inventory and topology SB> nit possibly "augmented in both the inventory" SB> either way I think at least a "the" is missing models with inventory and topology specific attributes. Network ========================== A network can contain multiple topologies, for example topologies at different layers and overlay topologies. The model therefore allows to capture SB> English: "allows to capture" - who does it allow to make a capture? relationships between topologies, as well as dependencies between nodes and termination points across topologies. An example of a topology stack is shown in the following figure. =========================== 3. Definitions and Acronyms HTTP: Hyper-Text Transfer Protocol SB> HTTP is stared in the "well known" list and so does not need expanding SB> also it is only used once in the text =========================== When a network is of a certain type, it will contain a corresponding data node. Network types SHOULD always be represented using presence containers, not leafs of empty type. This allows to represent SB> missing word "This allows who or what to represent" =========================== This (physical) network, respectively the (entities) nodes in that network, can then be referred to as underlay network and nodes from the other (logical) networks and nodes, respectively. Note that the model allows to SB> allows who to define? define more than one underlay network (and node), allowing for simultaneous representation of layered network- and service SB> Spurious "-" topologies and physical instantiation. Similar to a network, a node can be supported by other nodes, and map onto one or more other nodes in an underlay network. This is captured in the list "supporting-node". The resulting hierarchy of nodes allows also to represent device stacks, where a node at one SB> Allows who to also? level is supported by a set of nodes at an underlying level. For example, a "router" node might be supported by a node representing a route processor and separate nodes for various line cards and service modules, a virtual router might be supported or hosted on a physical device represented by a separate node, and so on. Finally, there is an object "server-provided". This object is state that indicates how the network came into being. Network data can come into being in one of two ways. In one way, network data is configured by client applications, for example in case of overlay networks that are configured by an SDN Controller application. In annother way, it is populated by the server, in case of networks that SB> s/annother/another/ can be discovered. SB> I don't understand the end of the previous para. I think you are SB> covering the case of SDN and classic self-learning networks where SB> information is discovered from neighbours. If that is the case SB> it is not clear from the text above. If server-provided is set to false, the network was configured by a client application, for example in the case of an overlay network that is configured by a controller application. If server-provided is set to true, the network was populated by the server itself, respectively an application on the server that is able to discover the network. Client applications SHOULD NOT modify configurations of networks for which "server-provided" is true. When they do, they need to be aware that any modifications they make are subject to be SB> s/be/being/ reverted by the server. For servers that support NACM (Netconf Access Control Model), data node rules should ideally prevent write access by other clients to network instances for which server- provided is set to true. ========================== A node has a list of termination points that are used to terminate links. An example of a termination point might be a physical or logical port or, more generally, an interface. SB> When I read this I immediately wondered about multi-point links SB> You clear up later that your model does not support them. It SB> would be kind to the reader to pre-empt the question here. =========================== 4.4.4. Use of groupings The model makes use of groupings, instead of simply defining data nodes "in-line". This allows to more easily include the SB> this allows who? ============================= 4.4.7. Mapping redundancy In a hierarchy of networks, there are nodes mapping to nodes, links mapping to links, and termination points mapping to termination points. Some of this information is redundant. Specifically, if the link-to-links mapping known, and the termination points of each link SB> link-to-links mapping IS known ============================ In the case of a physical network, nodes represent physical devices and termination points physical ports. It should be noted that it is also conceivable to augment the model for a physical network-type, SB> do you mean conceivable or possible? ==================== That said, it is conceivable that certain types of topology need to also be SB> again I think you mean "it is possible" configurable by an application. The model needs to support both cases. ===================== Another alternative would make use of a YANG extension to tag specific network instances as "server-provided" instead of defining a leaf object, or rely on the concept of YANG metadata [RFC7952] for SB> perhaps "or relying on" the same effect. The tag would be automatically applied to any topology data that comes into being (respectively is configured) by an embedded application on the network, as opposed to e.g. a controller application. ======================== 4.4.11. Identifiers of string or URI type The current model defines identifiers of nodes, networks, links, and termination points as URIs. An alternative would define them as string. SB> given "them" (plural) I think that should be "strings" The case for strings is that they will be easier to implement. The reason for choosing URIs is that the topology/node/tp exists in a larger context, hence it is useful to be able to correlate identifiers across systems. While strings, being the universal data type, are easier for human beings (a string is a string is a string), SB> Well maybe, it could be an ASCII string or an EBCDIC string etc From nobody Mon Dec 19 08:32:19 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A00129BC2 for ; Mon, 19 Dec 2016 08:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no 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 rt0l4V6wzNNY for ; Mon, 19 Dec 2016 08:32:16 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 C55A0129BBB for ; Mon, 19 Dec 2016 08:32:15 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.7.237; From: "Susan Hares" To: References: <2530302c-cab3-09b1-6c2d-39c2bd84ecf6@rfc-editor.org> In-Reply-To: Date: Mon, 19 Dec 2016 11:29:04 -0500 Message-ID: <00b601d25a15$03fc5fd0$0bf51f70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGZ8lJ/Kv1DDQqYKnOAoyVHWmFc/QIuFRAioW7RvJA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Russ White' Subject: [i2rs] FW: [mpls] Fwd: The RFC Format docs are now RFCs X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 16:32:17 -0000 Fyi - The new format for RFCs will be XML. All I2RS documents will need to be in the RFC format. Sue -------- Forwarded Message -------- Subject: The RFC Format docs are now RFCs Date: Fri, 16 Dec 2016 09:14:27 -0800 From: Heather Flanagan (RFC Series Editor) To: rfc-interest@rfc-editor.org, ietf@ietf.org Hello all, The RFC Format requirements documents were published this morning. This represents an enormous amount of work on the part of the RFC Format Design Team, and an enormous amount of patience and feedback from the community. Of course, the work isn't quite done - all of these RFCs will undergo a -bis cycle so we can document the "as built" instead of just the "as proposed." But regardless of the amount of work still to come, this is a big milestone for the project! So, thank you all, and stay tuned for the next steps of code development, testing, and collecting feedback! -Heather Flanagan, RSE The RFC Format Design Team: * Nevil Brownlee (ISE) * Heather Flanagan (RSE) * Tony Hansen * Joe Hildebrand * Paul Hoffman * Ted Lemon * Julian Reschke * Adam Roach * Alice Russo * Robert Sparks (Tools Team liaison) * Dave Thaler The RFCs, in suggested reading order: * "RFC Format Framework " - https://www.rfc-editor.org/info/rfc7990 * "The "xml2rfc" Version 3 Vocabulary" - https://www.rfc-editor.org/info/rfc7991 * "HTML Format for RFCs" - https://www.rfc-editor.org/info/rfc7992 * "Cascading Style Sheets (CSS) Requirements for RFCs" - https://www.rfc-editor.org/info/rfc7993 * "Requirements for Plain-Text RFCs" - https://www.rfc-editor.org/info/rfc7994 * "PDF Format for RFCs" - https://www.rfc-editor.org/info/rfc7995 * "SVG Drawings for RFCs: SVG 1.2 RFC" - https://www.rfc-editor.org/info/rfc7996 * "The Use of Non-ASCII Characters in RFCs" - https://www.rfc-editor.org/info/rfc7997 * ""xml2rfc" Version 3 Preparation Tool Description" - https://www.rfc-editor.org/info/rfc7997 - From nobody Thu Dec 22 00:00:52 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA5012947E; Thu, 22 Dec 2016 00:00:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148239364677.22504.6987109846507251502.idtracker@ietfa.amsl.com> Date: Thu, 22 Dec 2016 00:00:46 -0800 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-info-model-10.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 08:00:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : Routing Information Base Info Model Authors : Nitin Bahadur Sriganesh Kini Jan Medved Filename : draft-ietf-i2rs-rib-info-model-10.txt Pages : 25 Date : 2016-12-21 Abstract: Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a routing information base (RIB). Protocols and configuration push data into the RIB and the RIB manager installs state into the hardware; for packet forwarding. This draft specifies a information model for the RIB to enable defining a standardized data model. Such a data model can be used to define an interface to the RIB from an entity that may even be external to the network device. This interface can be used to support new use-cases being defined by the IETF I2RS WG. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-rib-info-model-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-rib-info-model-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 22 00:02:43 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F6C1294C3 for ; Thu, 22 Dec 2016 00:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.12 X-Spam-Level: X-Spam-Status: No, score=-5.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 fIvkjUHiYTcH for ; Thu, 22 Dec 2016 00:02:40 -0800 (PST) Received: from nm23-vm0.bullet.mail.ne1.yahoo.com (nm23-vm0.bullet.mail.ne1.yahoo.com [98.138.91.57]) (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 8A4F812947E for ; Thu, 22 Dec 2016 00:02:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1482393759; bh=IDJHDdOn37p8P1Pa2z0WMweGGAxYhlsRy9lE7SBaY90=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject; b=BPLcpatZoKT7NnlQDOsUl/VzdhhtUFV+DsCnRvomfKFkTmu68FH977Gy8RS6Qf3YDXX8JdOYUtQD4LpMatohFyVElAZP155UzjxFJbgDIxts3vr821NTeTHE5Mrht0MchUmTykRQ34PsURbaq+OxEB12b6Y+AGOa5gcoUcgQiRjE2cBW6kNQbnlNJ2vcqndgP9yQkLVjkqLYFcrhqDvS+TDjHsEuNvO1gNqz5c91yz4zXac9NDKzz/LmXlu3SAH4OjwnFlSb1UNaQzc0LYAtVYX6UuvdNp+uoBb/120MAVUy/5N0EPWVAckyr/dMr+95H+UG4dk5ebiUK2wLuzip4g== Received: from [98.138.100.102] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 22 Dec 2016 08:02:39 -0000 Received: from [98.138.84.37] by tm101.bullet.mail.ne1.yahoo.com with NNFMP; 22 Dec 2016 08:02:39 -0000 Received: from [127.0.0.1] by smtp105.mail.ne1.yahoo.com with NNFMP; 22 Dec 2016 08:02:39 -0000 X-Yahoo-Newman-Id: 969089.4805.bm@smtp105.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 0L0M9U8VM1kqE8he7aX5NnYacNjFEi0hVVQvVBPWdV.nxkQ MUUUh7V_a7jnkSrn2EEfep2gkkGUszuZiP3twWGKMyDxIBjUd9q0JiAl1w_r wogv7itygVB7duWWYf1RXeicFQ0wu2DBRTXyDJ.7qaVXdw2N9DeX8rZMIgVh t02MvLsW0mz8ablnInGkGZXIk.fm2gzNoeCyafCFxDme3f85lkxQgv6TG3cD 35EAFvJ21jr4k1C9.dftBVSh4EAScBqs9EEpJb1Yw12yFl0CvStADSTVm1yj P1IOYsleYIMXSAxPin6.SHbHqs8HhdYNRVW4pBrA4J21WbX7yqgNur.Vdwi1 ayAwc4Q9vFsd_vFOXggEzGecKSPG_TzJJ_aedMEkdKj3dTGibXrMobii.HWU J0MLb64CT5L46peIxNNCNL.j6HleJPzJEVsKMhUsdYQIZYzi0YGR9J8Xmeh4 0GvjQZ4iCoxo2UPTfSdOXAbwu2Y5RLSbvzNgI7ImTL.01pynuSmOId_GGg_H OkSMG.8jaz58M8PuD7ztOoy5bHdilw3E68sxcmCfC5sdPGpuExXw3A.BksLr FAiDKBPHAHS2gFGu5dt3aX0Vb X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- User-Agent: Microsoft-MacOutlook/14.7.0.161029 Date: Thu, 22 Dec 2016 13:32:29 +0530 From: Nitin Bahadur To: Message-ID: Thread-Topic: [i2rs] I-D Action: draft-ietf-i2rs-rib-info-model-10.txt References: <148239364677.22504.6987109846507251502.idtracker@ietfa.amsl.com> In-Reply-To: <148239364677.22504.6987109846507251502.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-info-model-10.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 08:02:42 -0000 Just a refresh of the draft to prevent it from expiring=8A On 12/22/16, 1:30 PM, "i2rs-bounces@ietf.org on behalf of internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Interface to the Routing System of the >IETF. > > Title : Routing Information Base Info Model > Authors : Nitin Bahadur > Sriganesh Kini > Jan Medved > Filename : draft-ietf-i2rs-rib-info-model-10.txt > Pages : 25 > Date : 2016-12-21 > >Abstract: > Routing and routing functions in enterprise and carrier networks are > typically performed by network devices (routers and switches) using a > routing information base (RIB). Protocols and configuration push > data into the RIB and the RIB manager installs state into the > hardware; for packet forwarding. This draft specifies a information > model for the RIB to enable defining a standardized data model. Such > a data model can be used to define an interface to the RIB from an > entity that may even be external to the network device. This > interface can be used to support new use-cases being defined by the > IETF I2RS WG. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-i2rs-rib-info-model-10 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-info-model-10 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >i2rs mailing list >i2rs@ietf.org >https://www.ietf.org/mailman/listinfo/i2rs