From nobody Wed May 1 15:39:25 2019 Return-Path: <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@amazonses.watsen.net> X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9109120025; Wed, 1 May 2019 15:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 trsbGbmu6G_o; Wed, 1 May 2019 15:39:13 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ACAD120019; Wed, 1 May 2019 15:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556750352; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=V5KtbbfevQ1KLEhpE4cJ8IG5qHOTzaOnf3eukJTczVA=; b=PmK8qQjAA0n+3GR3HDIYnHennmx2Ky79Li9t0D49zvCFTf2vesOW1eJScyTJNIgs WGmxiPZkwtc4qMp4BX4FgNpJ/39+/aUUovOQ5m5ZAssCUEuMncIZodLzezORPBQORr0 WYWnD8OACBkanmzTPYf0p6PH14X11fh+4d/Dqq30= From: Kent Watsen Message-ID: <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_70111C22-DA5F-4E78-A41B-CD6A03381CB3" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 1 May 2019 22:39:11 +0000 In-Reply-To: <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> Cc: Dhruv Dhody , "rtg-dir@ietf.org" , "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" , Dhruv Dhody , "" To: "Eric Voit (evoit)" References: <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.05.01-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 22:39:17 -0000 --Apple-Mail=_70111C22-DA5F-4E78-A41B-CD6A03381CB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 30, 2019, at 1:44 PM, Eric Voit (evoit) = wrote: >=20 > Hi Dhruv, > Hi Kent, >=20 > Thanks very much for the comments Dhruv. Thoughts in-line, with one = question to Kent... >=20 >> From: Dhruv Dhody, April 30, 2019 12:53 AM >>=20 >> Hello, >>=20 >> I have been selected as the Routing Directorate reviewer for this = draft. The >> Routing Directorate seeks to review all routing or routing-related = drafts as they >> pass through IETF last call and IESG review, and sometimes on special = request. >> The purpose of the review is to provide assistance to the Routing = ADs. For more >> information about the Routing Directorate, please see >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>=20 >> Although these comments are primarily for the use of the Routing ADs, = it would >> be helpful if you could consider them along with any other IETF Last = Call >> comments that you receive, and strive to resolve them through = discussion or by >> updating the draft. >>=20 >> Document: draft-ietf-netconf-netconf-event-notifications-17 >> Reviewer: Dhruv Dhody >> Review Date: 2019-04-29 >> IETF LC End Date: 2019-04-12 >> Intended Status: Standards Track >>=20 >> Summary: >> -------- >> I have some minor concerns about this document that I think should be = resolved >> before publication. >>=20 >> Comments: >> --------- >> This document provides a binding for events streamed over the NETCONF = for >> dynamic subscriptions. This is a companion document to = draft-ietf-netconf- >> subscribed-notifications and this capability for RESTCONF is defined = in draft-ietf- >> netconf-restconf-notif. >>=20 >> The document is overall well written, it makes an assumption that the = reader is >> well versed in this area and thus sparse in providing details in the = Introduction >> section. The appendix provides good examples. >>=20 >> I don't see any Routing Yang model specific issue. >>=20 >> Major Issues: >> ------------- >> Note - An IETF process issue, but worth handling right away. >>=20 >> Section 11 says - >>=20 >> 11. Notes to the RFC Editor >>=20 >> This section can be removed by the RFC editor after the requests = have >> been performed. >>=20 >> It further says - >>=20 >> RFC 6241 needs to be updated based on the needs of this draft. >> RFC-6241 section 1.2 bullet "(2)" targets RFC-5277 (actually it >> identifies RFC 5717, but that was an error fixed after RFC >> publication). Anyway the current phrasing in RFC-5277 says that a >> notification message can only be sent after a successful "create- >> subscription". Therefore the reference text must be modified to = also >> allow notification messages be sent after a successful "establish- >> subscription". Proposed text for bullet (2) of RFC-6241 would be: >>=20 >> (2) The Messages layer provides a simple, transport-independent >> framing mechanism for encoding RPCs and notifications. >> Section 4 documents the RPC messages, [RFC5277] documents >> Notifications sent as a result of a = RPC, >> and [RFC xxxx] documents Notifications sent as a result of >> an RPC. >>=20 >> (where xxxx is replaced with this RFC number) >>=20 >> I am not sure if this is correct. I don't think RFC editor can do the = action you are >> asking them to do on their own. They would need an errata (which is = not correct >> here) or another document that updates RFC 6241. In my view this = document >> should just update RFC 6241 (and mark that in this document's >> header) and do necessary text changes to reflect that. >=20 > I am happy to follow whatever process is cleanest. =20 >=20 > Kent, are you comfortable with this document directly revising = wording of RFC-6241 section 1.2 bullet "(2)" above? If yes, it would = be great to have your thoughts on what needs to go into this document. = Especially as RFC-6241 section 1.2 bullet "(2)" already had a fix = applied against it.=20 Dhruv is correct, the RFC Editor cannot make the requested change, and = an Errata is also not correct, as there is nothing wrong with the way = that RFC 6241 was written at the time it was written. To answer the question, if this draft is to "update" RFC 6241, the steps = are 1) declare the update in the draft's header (see Section 2.33.10 of = RFC 7749), 2) so so in the Abstract, and 3) have a new section (either = before of after the current Section 3 called "Update to RFC 6241" that = describes the desired modification. However, it is unclear if an "update" is appropriate either, given that = the "update" is informative in nature and, while it is true that this = document cannot be used without RFC 6241, that is also true for so many = documents that don't update RFC 6241. =46rom now obsolete RFC 2223 (I couldn't find a current reference): Updates To be used as a reference from a new item that cannot be used alone (i.e., one that supplements a previous document), to refer to the previous document. The newer publication is a part that will supplement or be added on to the existing document; e.g., an addendum, or separate, extra information that is to be added to the original document. and from expired draft-rfc-editor-rfc2223bis-08: Updates Specifies an earlier document whose contents are modified or augmented by the new document. The new document cannot be used alone, it can only be used in conjunction with the earlier document. Is an "update" overreaching? Another option is to not update RFC 6241 and instead just mention it, = similar to what was done here: = https://tools.ietf.org/html/rfc8071#section-1.4 = . Note that RFC 8071 = originally "updated" RFC 4253, but Benoit (AD at the time) recommended = downgrading it to what it is now. A couple more thoughts: 1) if an update is needed, would it be better coming from = draft-ietf-netconf-subscribed-notifications, which defines the = "establish-subscription" RPC? 2) whatever the outcome of this discussion, it seems that a similar = outcome should be applied to draft-ietf-netconf-restconf-notif and its = relation to RFC 8040. [also see my comment below] >> Minor Issues: >> ------------- >> (1) Abstract & Introduction, It is not clear what does the 'binding' = mean and who >> are the parties to this binding? If this is the document that = mentions 'binding' >> first, so please add some more clarifying text. >>=20 >> (2) Section 3, since you use MUST in the error handling, isn't it = better to use >> normative in below sentence as well - >> OLD: >> However a = single >> NETCONF transport session cannot support both this specification = and >> a subscription established by [RFC5277]'s "create-subscription" = RPC. >> NEW: >> However a = single >> NETCONF transport session MUST NOT support both this specification = and >> a subscription established by [RFC5277]'s "create-subscription" = RPC. >=20 > Makes sense. I have made the change, and will post the update when = the "Major issue" from above is resolved. >=20 >> (3) Section 6, You have - >>=20 >> And per [RFC5277]'s "eventTime" object definition, the >> "eventTime" MUST be populated with the event occurrence time. >>=20 >> Is this a new requirement, or just re-stating RFC5277? RFC5277 says - >>=20 >> eventTime >>=20 >> The time the event was generated by the event source. This >> parameter is of type dateTime and compliant to [RFC3339]. >> Implementations must support time zones. >>=20 >> Also contains notification-specific tagged content, if any. = With >> the exception of , the content of the notification is >> beyond the scope of this document. >>=20 >> Maybe remove MUST? If you are trying to refine the text from RFC5277, = then >> please re-word. >=20 > You are correct. The MUST is redundant with RFC-5277's XSD = definition. Therefore I have removed "MUST be". >=20 >> Nits: >> ----- >> (1) Abstract >>=20 >> RFC Editor note: please replace the four references to pre-RFC >> normative drafts with the actual assigned RFC numbers. >>=20 >> I see two drafts in the reference section. Why four? >=20 > You are correct. I removed the word "four". =20 >=20 >> Also, since those two are normative references, these would be = published as a >> cluster as a part of normal RFC editor processing right? >=20 > Yes. >=20 >> (2) Regarding NETCONF, the RFC editor says [1] - >>=20 >> NETCONF - Network Configuration Protocol (NETCONF) >> [Not typically expanded in titles, but expand in = abstract] >>=20 >> Please expand. >=20 > Done. >=20 >> (3) s/[I-D.draft-ietf-netconf-subscribed-notifications] >> /[I-D.ietf-netconf-subscribed-notifications] >=20 > Actually I changed the [I-D.ietf-netconf-yang-push] to = [I-D.draft-ietf-netconf-yang-push] >=20 > This makes it consistent across all four drafts. The issue isn't consistency so much as meeting expectations, per = `xml2rfc`, the document should have something like the following in the = References section, which then auto-expands to the correct reference = text, as well as defining the anchor = "I-D.ietf-netconf-subscribed-notifications": Kent // shepherd >=20 > Thanks again! > Eric >=20 >> Just so that you have the same style of draft reference in the = document. I get >> that it would be replaced with a RFC number anyways :) >>=20 >> [1] https://www.rfc-editor.org/materials/abbrev.expansion.txt = >>=20 >> Thanks! >> Dhruv --Apple-Mail=_70111C22-DA5F-4E78-A41B-CD6A03381CB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 30, 2019, at 1:44 PM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

Hi = Dhruv,
Hi = Kent,

Thanks very = much for the comments Dhruv.  Thoughts in-line, with one question = to Kent...

From: = Dhruv Dhody, April 30, 2019 12:53 AM

Hello,

I have been selected as = the Routing Directorate reviewer for this draft. The
Routing= Directorate seeks to review all routing or routing-related drafts as = they
pass through IETF last call and IESG review, and = sometimes on special request.
The purpose of the review is = to provide assistance to the Routing ADs. For more
information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the = use of the Routing ADs, it would
be helpful if you could = consider them along with any other IETF Last Call
comments = that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: = draft-ietf-netconf-netconf-event-notifications-17
Reviewer: = Dhruv Dhody
Review Date: 2019-04-29
IETF LC = End Date: 2019-04-12
Intended Status: Standards Track

Summary:
--------
I = have some minor concerns about this document that I think should be = resolved
before publication.

Comments:
---------
This document = provides a binding for events streamed over the NETCONF for
dynamic subscriptions. This is a companion document to = draft-ietf-netconf-
subscribed-notifications and this = capability for RESTCONF is defined in draft-ietf-
netconf-restconf-notif.

The = document is overall well written, it makes an assumption that the reader = is
well versed in this area and thus sparse in providing = details in the Introduction
section. The appendix provides = good examples.

I don't see any Routing Yang = model specific issue.

Major Issues:
-------------
Note - An IETF process issue, but = worth handling right away.

Section 11 says = -

11.  Notes to the RFC Editor

  This section can be removed by the = RFC editor after the requests have
  been = performed.

It further says -

  RFC 6241 needs to be updated based = on the needs of this draft.
  RFC-6241 section = 1.2 bullet "(2)" targets RFC-5277 (actually it
  identifies RFC 5717, but that was an error fixed = after RFC
  publication).  Anyway the = current phrasing in RFC-5277 says that a
  notification message can only be sent after a = successful "create-
  subscription". =  Therefore the reference text must be modified to also
  allow notification messages be sent after a = successful "establish-
  subscription". =  Proposed text for bullet (2) of RFC-6241 would be:
    (2)  The Messages layer = provides a simple, transport-independent
         framing = mechanism for encoding RPCs and notifications.
         Section = 4 documents the RPC messages, [RFC5277] documents
         Notificat= ions sent as a result of a <create-subscription> RPC,
         and = [RFC xxxx] documents Notifications sent as a result of
         an = <establish-subscription> RPC.

     (where xxxx is replaced with = this RFC number)

I am not sure if this is = correct. I don't think RFC editor can do the action you are
asking them to do on their own. They would need an errata = (which is not correct
here) or another document that = updates RFC 6241. In my view this document
should just = update RFC 6241 (and mark that in this document's
header) = and do necessary text changes to reflect that.

I am happy to follow whatever process is cleanest. =   

Kent, are you = comfortable with this document directly revising  wording of = RFC-6241 section 1.2 bullet "(2)" above?    If yes, it = would be great to have your thoughts on what needs to go into this = document.   Especially as RFC-6241 section 1.2 bullet "(2)" = already had a fix applied against it. 


Dhruv is correct, the RFC Editor cannot make the = requested change, and an Errata is also not correct, as there is nothing = wrong with the way that RFC 6241 was written at the time it was = written.

To answer the = question, if this draft is to "update" RFC 6241, the steps are 1) = declare the update in the draft's header (see Section 2.33.10 of RFC = 7749), 2) so so in the Abstract, and 3) have a new section (either = before of after the current Section 3 called "Update to RFC 6241" that = describes the desired modification.

However, it is unclear if an "update" is = appropriate either, given that the "update" is informative in nature = and, while it is true that this document cannot be used without RFC = 6241, that is also true for so many documents that don't update RFC = 6241.

=46rom now obsolete RFC 2223 = (I couldn't find a current reference):

   Updates

      To = be used as a reference from a new item that cannot be used
      alone (i.e., one that supplements a = previous document), to refer
      = to the previous document.  The newer publication is a part = that
      will supplement or be = added on to the existing document; e.g., an
  =     addendum, or separate, extra information that is to be = added to
      the original = document.

and = from expired draft-rfc-editor-rfc2223bis-08:
      =    Updates

            Specifies an = earlier document whose contents are modified or
            augmented by the = new document.  The new document cannot be
 =           used alone, it can only be used in = conjunction with the
        =     earlier document.

Is an "update" overreaching?

Another option is to not update RFC 6241 and = instead just mention it, similar to what was done here: https://tools.ietf.org/html/rfc8071#section-1.4.   = Note that RFC 8071 originally "updated" RFC 4253, but Benoit (AD at the = time) recommended downgrading it to what it is now.


A = couple more thoughts:

1) if an = update is needed, would it be better coming from = draft-ietf-netconf-subscribed-notifications, which defines the = "establish-subscription" RPC?

2) = whatever the outcome of this discussion, it seems that a similar outcome = should be applied to draft-ietf-netconf-restconf-notif and its relation = to RFC 8040.


[also see my comment below]



Minor Issues:
-------------
(1) Abstract & Introduction, = It is not clear what does the 'binding' mean and who
are = the parties to this binding? If this is the document that mentions = 'binding'
first, so please add some more clarifying = text.

(2) Section 3, since you use MUST in = the error handling, isn't it better to use
normative in = below sentence as well -
OLD:
          &nb= sp;            = ;            &= nbsp;           &nb= sp;      However a single
  NETCONF transport session cannot support both = this specification and
  a subscription = established by [RFC5277]'s "create-subscription" RPC.
NEW:
          &nb= sp;            = ;            &= nbsp;           &nb= sp;      However a single
  NETCONF transport session MUST NOT support both = this specification and
  a subscription = established by [RFC5277]'s "create-subscription" RPC.

Makes sense.  I have made the change, and will post the = update when the "Major issue" from above is resolved.

(3) = Section 6, You have -

  And per = [RFC5277]'s "eventTime" object definition, the
  "eventTime" MUST be populated with the event = occurrence time.

Is this a new requirement, = or just re-stating RFC5277? RFC5277 says -

     eventTime

        The time the = event was generated by the event source.  This
        parameter is = of type dateTime and compliant to [RFC3339].
        Implementations= must support time zones.

     Also contains = notification-specific tagged content, if any.  With
     the exception of = <eventTime>, the content of the notification is
     beyond the scope of this = document.

Maybe remove MUST? If you are = trying to refine the text from RFC5277, then
please = re-word.

You are correct.  The MUST is redundant with RFC-5277's = XSD definition.   Therefore I have removed "MUST = be".

Nits:
-----
(1) Abstract

  RFC Editor note: please replace = the four references to pre-RFC
  normative = drafts with the actual assigned RFC numbers.

I see two drafts in the reference section. Why four?

You are correct.  I removed the word "four". =  

Also, = since those two are normative references, these would be published as = a
cluster as a part of normal RFC editor processing = right?

Yes.

(2) Regarding NETCONF, the RFC editor = says [1] -

NETCONF    - = Network Configuration Protocol (NETCONF)
          &nb= sp;   [Not typically expanded in titles, but expand in = abstract]

Please expand.

Done.

(3) = s/[I-D.draft-ietf-netconf-subscribed-notifications]
    /[I-D.ietf-netconf-subscribed-notificat= ions]

Actually I changed the [I-D.ietf-netconf-yang-push]  to =  [I-D.draft-ietf-netconf-yang-push]

This makes it consistent across all four drafts.


The issue isn't consistency so much as meeting = expectations, per `xml2rfc`, the document should have something like the = following in the References section, which then auto-expands to the = correct reference text, as well as defining the anchor = "I-D.ietf-netconf-subscribed-notifications":

        <?rfc = include=3D"reference.I-D.ietf-netconf-subscribed-notifications"?>



Kent // = shepherd



Thanks again!
Eric

Just so that you have the same style = of draft reference in the document. I get
that it would be = replaced with a RFC number anyways :)

[1] https://www.rfc-editor.org/materials/abbrev.expansion.txt
Thanks!
Dhruv

= --Apple-Mail=_70111C22-DA5F-4E78-A41B-CD6A03381CB3-- From nobody Tue May 7 09:11:37 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C6C120178; Tue, 7 May 2019 09:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 kKHwRaD96SyN; Tue, 7 May 2019 09:11:32 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8369120169; Tue, 7 May 2019 09:11:32 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x47G71MV027619; Tue, 7 May 2019 12:11:31 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 2sbd3ygg0t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 May 2019 12:11:30 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x47GBSQE023075; Tue, 7 May 2019 12:11:29 -0400 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [135.66.87.31]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x47GBOBs022913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 May 2019 12:11:24 -0400 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [127.0.0.1]) by zlp27127.vci.att.com (Service) with ESMTP id 702744009E71; Tue, 7 May 2019 16:11:24 +0000 (GMT) Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (unknown [130.9.129.147]) by zlp27127.vci.att.com (Service) with ESMTPS id 5B92D4009E70; Tue, 7 May 2019 16:11:24 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.184]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0439.000; Tue, 7 May 2019 12:11:23 -0400 From: "BRUNGARD, DEBORAH A" To: "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Thread-Topic: Harmful consequences of Postel's principle Thread-Index: AdUE7raFYXVucAjPRR+XrROKu4os/w== Date: Tue, 7 May 2019 16:11:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.217] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-07_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905070104 Archived-At: Subject: [RTG-DIR] Harmful consequences of Postel's principle X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 16:11:35 -0000 SGksDQoNCk5vdCBzdXJlIGlmIHRoaXMgZG9jdW1lbnQgY2F1Z2h0IHlvdXIgYXR0ZW50aW9uIGFz IEkgdGhpbmsgaXQgaXMgYSBiaXQgb2YgYSBtaXNub21lciBmb3IgdGhlIHRpdGxlLiBUaGUgSUFC IGFyZSBsb29raW5nIHRvIHB1Ymxpc2ggaXQgYXMgYW4gSUFCIGRvY3VtZW50Lg0KDQpJJ20gZ29p bmcgdG8gY29tbWVudCBvbiBpdCBhcyBJIHRoaW5rIHRvIG1ha2UgYSBnZW5lcmljIHN0YXRlbWVu dCB0aGF0IFBvc3RlbCdzIHByaW5jaXBsZSBpcyBoYXJtZnVsIGlzIGhhcm1mdWwuDQoNCkludGVy ZXN0ZWQgaW4geW91ciB0aG91Z2h0cy0NCkRlYm9yYWgNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogSUFCIDxpYWItYm91bmNlc0BpYWIub3JnPiBPbiBCZWhhbGYgT2YgaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnDQpTZW50OiBNb25kYXksIE1heSAwNiwgMjAxOSAxMDo0MCBQ TQ0KVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KQ2M6IGlhYkBpYWIub3JnDQpTdWJqZWN0OiBb SUFCXSBJLUQgQWN0aW9uOiBkcmFmdC1pYWItcHJvdG9jb2wtbWFpbnRlbmFuY2UtMDMudHh0DQoN Cg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgSW50ZXJuZXQgQXJjaGl0ZWN0dXJlIEJvYXJkIElFVEYgb2YgdGhlIElFVEYuDQoNCiAgICAg ICAgVGl0bGUgICAgICAgICAgIDogVGhlIEhhcm1mdWwgQ29uc2VxdWVuY2VzIG9mIHRoZSBSb2J1 c3RuZXNzIFByaW5jaXBsZQ0KICAgICAgICBBdXRob3IgICAgICAgICAgOiBNYXJ0aW4gVGhvbXNv bg0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlhYi1wcm90b2NvbC1tYWludGVuYW5jZS0wMy50 eHQNCglQYWdlcyAgICAgICAgICAgOiAxMQ0KCURhdGUgICAgICAgICAgICA6IDIwMTktMDUtMDYN Cg0KQWJzdHJhY3Q6DQogICBKb24gUG9zdGVsJ3MgZmFtb3VzIHN0YXRlbWVudCBvZiAiQmUgbGli ZXJhbCBpbiB3aGF0IHlvdSBhY2NlcHQsIGFuZA0KICAgY29uc2VydmF0aXZlIGluIHdoYXQgeW91 IHNlbmQiIGlzIGEgcHJpbmNpcGxlIHRoYXQgaGFzIGxvbmcgZ3VpZGVkDQogICB0aGUgZGVzaWdu IGFuZCBpbXBsZW1lbnRhdGlvbiBvZiBJbnRlcm5ldCBwcm90b2NvbHMuICBUaGUgcG9zdHVyZQ0K ICAgdGhpcyBzdGF0ZW1lbnQgYWR2b2NhdGVzIHByb21vdGVzIGludGVyb3BlcmFiaWxpdHkgaW4g dGhlIHNob3J0IHRlcm0sDQogICBidXQgY2FuIG5lZ2F0aXZlbHkgYWZmZWN0IHRoZSBwcm90b2Nv bCBlY29zeXN0ZW0gb3ZlciB0aW1lLiAgRm9yIGENCiAgIHByb3RvY29sIHRoYXQgaXMgYWN0aXZl bHkgbWFpbnRhaW5lZCwgdGhlIHJvYnVzdG5lc3MgcHJpbmNpcGxlIGNhbiwNCiAgIGFuZCBzaG91 bGQsIGJlIGF2b2lkZWQuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRGlhYi0yRHByb3Rv Y29sLTJEbWFpbnRlbmFuY2VfJmQ9RHdJQ2FRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPTZV aEdwVzlsd2k5ZE03allseFhEOHcmbT1WWlV4WGJvV1k0NHJ0WmNtY3N3aUxRdVE4VG1XNmc3RjdB emdsLWowYW13JnM9RnhwOXdSb0NWUkpfOEJaQnpZMU1vRXhqUmxWQ2VnTGJGdHE4dHhjcjZGOCZl PQ0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQpodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmll dGYub3JnX2h0bWxfZHJhZnQtMkRpYWItMkRwcm90b2NvbC0yRG1haW50ZW5hbmNlLTJEMDMmZD1E d0lDYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9NlVoR3BXOWx3aTlkTTdqWWx4WEQ4dyZt PVZaVXhYYm9XWTQ0cnRaY21jc3dpTFF1UThUbVc2ZzdGN0F6Z2wtajBhbXcmcz1hQ2JXZloyV0ZI bFRuaDdXZWlJOGhKX04wNEVveVc5MHktV3VtbDhnTHVBJmU9DQpodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2Rv Y19odG1sX2RyYWZ0LTJEaWFiLTJEcHJvdG9jb2wtMkRtYWludGVuYW5jZS0yRDAzJmQ9RHdJQ2FR JmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPTZVaEdwVzlsd2k5ZE03allseFhEOHcmbT1WWlV4 WGJvV1k0NHJ0WmNtY3N3aUxRdVE4VG1XNmc3RjdBemdsLWowYW13JnM9bEJWd1M5eXp4OWxCbUJF TUEwY0lpZG1oX2hnUnFHRmNsR010NmlOVFBmdyZlPQ0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlv dXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19yZmNkaWZmLTNGdXJsMi0zRGRy YWZ0LTJEaWFiLTJEcHJvdG9jb2wtMkRtYWludGVuYW5jZS0yRDAzJmQ9RHdJQ2FRJmM9TEZZWi1v OV9IVU1lTVRTUWljdmpJZyZyPTZVaEdwVzlsd2k5ZE03allseFhEOHcmbT1WWlV4WGJvV1k0NHJ0 WmNtY3N3aUxRdVE4VG1XNmc3RjdBemdsLWowYW13JnM9SmRWM0N1eDU0Q0xyM0dMcmhjNFNhcFZN dTBtQmNoZy02NXhLcndxWVBDbyZlPQ0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ IGF0Og0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWZ0cC0zQV9f ZnRwLmlldGYub3JnX2ludGVybmV0LTJEZHJhZnRzXyZkPUR3SUNhUSZjPUxGWVotbzlfSFVNZU1U U1FpY3ZqSWcmcj02VWhHcFc5bHdpOWRNN2pZbHhYRDh3Jm09VlpVeFhib1dZNDRydFpjbWNzd2lM UXVROFRtVzZnN0Y3QXpnbC1qMGFtdyZzPUZBMy0yOFJHQlBYNm9lUW5JUjQyTkJwZmVrU1ZoLUJV N3d5SENrdWVzZEEmZT0NCg0K From nobody Tue May 7 09:42:39 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FD512018B; Tue, 7 May 2019 09:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 geEn1w2PxtBe; Tue, 7 May 2019 09:42:35 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2919912018A; Tue, 7 May 2019 09:42:34 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x47GgU3I025919; Tue, 7 May 2019 17:42:30 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D14892203B; Tue, 7 May 2019 17:42:29 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id C592E2203D; Tue, 7 May 2019 17:42:29 +0100 (BST) Received: from LAPTOPK7AS653V ([87.112.228.68]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x47GgSvI011337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 May 2019 17:42:29 +0100 Reply-To: From: "Adrian Farrel" To: "'BRUNGARD, DEBORAH A'" , , References: In-Reply-To: Date: Tue, 7 May 2019 17:42:29 +0100 Organization: Old Dog Consulting Message-ID: <0a5a01d504f3$dc7421a0$955c64e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQK+iyhptHxOCSaq3th8upRvOvmhu6SM0IUA Content-Language: en-gb X-Originating-IP: 87.112.228.68 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24598.000 X-TM-AS-Result: No--4.360-10.0-31-10 X-imss-scan-details: No--4.360-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24598.000 X-TMASE-Result: 10--4.359600-10.000000 X-TMASE-MatchedRID: byfwvk+IcRnxIbpQ8BhdbDPDkSOzeDWWfkuZtv/FS5rBQmthaZij0yUc tKY3q+Ds49bJrkN9wqz5fokVQYpSF7NFdXOVxOU0lVHM/F6YkvSq+eA48cLTbrrfxlRjqBJ3YdZ pj+WManpCnLVdVwWGHqsnHA/NdMElc3eYMKyaPySiVU7u7I4INQGZ/+APXW9k7icOyA4624b6dy zF+dpAW4jtXTM4ySGxAH+13/h3Btf3gr9T3KhP3gizXxlOHX34GSqdEmeD/nUBOMBsCslSyND1S FVeE0DsdtSe/JWsGJIxDeoOGIeZ79CzEk+/JINjYx1jPJKy+Dy7bm4onsHlrmjliw+xvItdYUUc TJLR9ZNR4kuXOqRTp3/inirn0Q3sMHsCEB6xhyOpRKRclM3X830tCKdnhB581B0Hk1Q1KyJcRgd 0HR6VpXQdJ7XfU86eOwBXM346/+xHa2vINb/8qpTlAF7hn4iUeAROcfTLc4JkXqP0GQis0lxTs2 4ELAGW X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [RTG-DIR] Harmful consequences of Postel's principle X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 16:42:39 -0000 I read it some time ago.=20 I am in no way convinced that publishing this in the IAB stream is in = any way going to have a positive impact on the way protocols are = designed or on the image of the IETF. It left me remembering that the Internet routes around errors. So I am = also not so worried about that IAB publishing it.=20 It is also possible that the authors do not completely understand the = robustness principle. Best, Adrian -----Original Message----- From: BRUNGARD, DEBORAH A =20 Sent: 07 May 2019 17:11 To: rtg-chairs@ietf.org; rtg-dir@ietf.org Subject: Harmful consequences of Postel's principle Hi, Not sure if this document caught your attention as I think it is a bit = of a misnomer for the title. The IAB are looking to publish it as an IAB = document. I'm going to comment on it as I think to make a generic statement that = Postel's principle is harmful is harmful. Interested in your thoughts- Deborah -----Original Message----- From: IAB On Behalf Of internet-drafts@ietf.org Sent: Monday, May 06, 2019 10:40 PM To: i-d-announce@ietf.org Cc: iab@iab.org Subject: [IAB] I-D Action: draft-iab-protocol-maintenance-03.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Internet Architecture Board IETF of the = IETF. Title : The Harmful Consequences of the Robustness = Principle Author : Martin Thomson Filename : draft-iab-protocol-maintenance-03.txt Pages : 11 Date : 2019-05-06 Abstract: Jon Postel's famous statement of "Be liberal in what you accept, and conservative in what you send" is a principle that has long guided the design and implementation of Internet protocols. The posture this statement advocates promotes interoperability in the short term, but can negatively affect the protocol ecosystem over time. For a protocol that is actively maintained, the robustness principle can, and should, be avoided. The IETF datatracker status page for this draft is: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_draft-2Diab-2Dprotocol-2Dmaintenance_&d=3DDwICaQ&c=3DLFYZ-o9_HUMeM= TSQicvjIg&r=3D6UhGpW9lwi9dM7jYlxXD8w&m=3DVZUxXboWY44rtZcmcswiLQuQ8TmW6g7F= 7Azgl-j0amw&s=3DFxp9wRoCVRJ_8BZBzY1MoExjRlVCegLbFtq8txcr6F8&e=3D There are also htmlized versions available at: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_draft-2Diab-2Dprotocol-2Dmaintenance-2D03&d=3DDwICaQ&c=3DLFYZ-o9_HUMeMT= SQicvjIg&r=3D6UhGpW9lwi9dM7jYlxXD8w&m=3DVZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7= Azgl-j0amw&s=3DaCbWfZ2WFHlTnh7WeiI8hJ_N04EoyW90y-Wuml8gLuA&e=3D https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_html_draft-2Diab-2Dprotocol-2Dmaintenance-2D03&d=3DDwICaQ&c=3DLFYZ= -o9_HUMeMTSQicvjIg&r=3D6UhGpW9lwi9dM7jYlxXD8w&m=3DVZUxXboWY44rtZcmcswiLQu= Q8TmW6g7F7Azgl-j0amw&s=3DlBVwS9yzx9lBmBEMA0cIidmh_hgRqGFclGMt6iNTPfw&e=3D= A diff from the previous version is available at: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdi= ff-3Furl2-3Ddraft-2Diab-2Dprotocol-2Dmaintenance-2D03&d=3DDwICaQ&c=3DLFYZ= -o9_HUMeMTSQicvjIg&r=3D6UhGpW9lwi9dM7jYlxXD8w&m=3DVZUxXboWY44rtZcmcswiLQu= Q8TmW6g7F7Azgl-j0amw&s=3DJdV3Cux54CLr3GLrhc4SapVMu0mBchg-65xKrwqYPCo&e=3D= 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: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_interne= t-2Ddrafts_&d=3DDwICaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D6UhGpW9lwi9dM7jYlxX= D8w&m=3DVZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7Azgl-j0amw&s=3DFA3-28RGBPX6oeQnI= R42NBpfekSVh-BU7wyHCkuesdA&e=3D From nobody Tue May 7 14:30:11 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB501202BA; Tue, 7 May 2019 14:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 yCPH7M2z3hM2; Tue, 7 May 2019 14:30:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20562120247; Tue, 7 May 2019 14:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35461; q=dns/txt; s=iport; t=1557264605; x=1558474205; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3DOTfV1Da5mVWcXq2j7s+n5g92BeDEiNfLUdMftooK8=; b=LGgz/15190LKNZTLbUSNY02s5vkVZnA9Yp5FlYDICo0maoLWBnVN8W6o lkXmxDsAR+xtRLFGE0UJBKQd8pkRvRiiCO3adL9b2zF/D8PkGbdkleGTL Barh8cri8PCoQpYRkEfK/8TK3KkKGMySRtkZC7K/fxQmpFbRntOc5J/93 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAABu+NFc/5xdJa1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUgUBAQELAYEOWCppgQQoCpkqmFIUgWcOAQEjhEoCghYjNQgOAQM?= =?us-ascii?q?BAQQBAQIBAm0cDIVKAQEBBC1FBQIQAgEIFAEQEwEGBzIUEQIEAQ0FCIJPSwG?= =?us-ascii?q?BHW0Prx6KL4EyAYRkhmkXgUA/gRGCFH4+glYLAQECAYFGHwcSFgKFKgSLCQY?= =?us-ascii?q?MCYIGhHmCEoV3jRYJAoIJhUpTjCojgUJOYoViBYx+gxuJCYEhhSyIIT2FSwI?= =?us-ascii?q?RFYEwDRQBNYFWcBWDJwmLCYU/QTEBAZA2gSEBAQ?= X-IronPort-AV: E=Sophos;i="5.60,443,1549929600"; d="scan'208,217";a="554361263" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 May 2019 21:29:39 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x47LTdjZ007713 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 May 2019 21:29:39 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 May 2019 17:29:38 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Tue, 7 May 2019 17:29:38 -0400 From: "Eric Voit (evoit)" To: Kent Watsen , Dhruv Dhody CC: "rtg-dir@ietf.org" , "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" , Dhruv Dhody , "" Thread-Topic: RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 Thread-Index: AQHU/xC8WbWTXSPvekeZmlnK7/xOtqZU7OSwgAI1bICACP37sA== Date: Tue, 7 May 2019 21:29:38 +0000 Message-ID: <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> References: <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> In-Reply-To: <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.233] Content-Type: multipart/alternative; boundary="_000_1cf686e76a314553842305bc97baeb3dXCHRTP013ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 21:30:11 -0000 --_000_1cf686e76a314553842305bc97baeb3dXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dhruv, Hi Kent, From: Kent Watsen, May 1, 2019 6:39 PM On Apr 30, 2019, at 1:44 PM, Eric Voit (evoit) > wrote: Hi Dhruv, Hi Kent, Thanks very much for the comments Dhruv. Thoughts in-line, with one questi= on to Kent... From: Dhruv Dhody, April 30, 2019 12:53 AM Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts a= s they pass through IETF last call and IESG review, and sometimes on special reque= st. The purpose of the review is to provide assistance to the Routing ADs. For = more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or= by updating the draft. Document: draft-ietf-netconf-netconf-event-notifications-17 Reviewer: Dhruv Dhody Review Date: 2019-04-29 IETF LC End Date: 2019-04-12 Intended Status: Standards Track Summary: -------- I have some minor concerns about this document that I think should be resol= ved before publication. Comments: --------- This document provides a binding for events streamed over the NETCONF for dynamic subscriptions. This is a companion document to draft-ietf-netconf- subscribed-notifications and this capability for RESTCONF is defined in dra= ft-ietf- netconf-restconf-notif. The document is overall well written, it makes an assumption that the reade= r is well versed in this area and thus sparse in providing details in the Introd= uction section. The appendix provides good examples. I don't see any Routing Yang model specific issue. Major Issues: ------------- Note - An IETF process issue, but worth handling right away. Section 11 says - 11. Notes to the RFC Editor This section can be removed by the RFC editor after the requests have been performed. It further says - RFC 6241 needs to be updated based on the needs of this draft. RFC-6241 section 1.2 bullet "(2)" targets RFC-5277 (actually it identifies RFC 5717, but that was an error fixed after RFC publication). Anyway the current phrasing in RFC-5277 says that a notification message can only be sent after a successful "create- subscription". Therefore the reference text must be modified to also allow notification messages be sent after a successful "establish- subscription". Proposed text for bullet (2) of RFC-6241 would be: (2) The Messages layer provides a simple, transport-independent framing mechanism for encoding RPCs and notifications. Section 4 documents the RPC messages, [RFC5277] documents Notifications sent as a result of a RPC, and [RFC xxxx] documents Notifications sent as a result of an RPC. (where xxxx is replaced with this RFC number) I am not sure if this is correct. I don't think RFC editor can do the actio= n you are asking them to do on their own. They would need an errata (which is not cor= rect here) or another document that updates RFC 6241. In my view this document should just update RFC 6241 (and mark that in this document's header) and do necessary text changes to reflect that. I am happy to follow whatever process is cleanest. Kent, are you comfortable with this document directly revising wording of = RFC-6241 section 1.2 bullet "(2)" above? If yes, it would be great to ha= ve your thoughts on what needs to go into this document. Especially as RF= C-6241 section 1.2 bullet "(2)" already had a fix applied against it. Dhruv is correct, the RFC Editor cannot make the requested change, and an E= rrata is also not correct, as there is nothing wrong with the way that RFC = 6241 was written at the time it was written. To answer the question, if this draft is to "update" RFC 6241, the steps ar= e 1) declare the update in the draft's header (see Section 2.33.10 of RFC 7= 749), 2) so so in the Abstract, and 3) have a new section (either before of= after the current Section 3 called "Update to RFC 6241" that describes the= desired modification. However, it is unclear if an "update" is appropriate either, given that the= "update" is informative in nature and, while it is true that this document= cannot be used without RFC 6241, that is also true for so many documents t= hat don't update RFC 6241. >From now obsolete RFC 2223 (I couldn't find a current reference): Updates To be used as a reference from a new item that cannot be used alone (i.e., one that supplements a previous document), to refer to the previous document. The newer publication is a part that will supplement or be added on to the existing document; e.g., an addendum, or separate, extra information that is to be added to the original document. and from expired draft-rfc-editor-rfc2223bis-08: Updates Specifies an earlier document whose contents are modified or augmented by the new document. The new document cannot be used alone, it can only be used in conjunction with the earlier document. Is an "update" overreaching? Another option is to not update RFC 6241 and instead just mention it, simil= ar to what was done here: https://tools.ietf.org/html/rfc8071#section-1.4. = Note that RFC 8071 originally "updated" RFC 4253, but Benoit (AD at the t= ime) recommended downgrading it to what it is now. A couple more thoughts: 1) if an update is needed, would it be better coming from draft-ietf-netcon= f-subscribed-notifications, which defines the "establish-subscription" RPC? 2) whatever the outcome of this discussion, it seems that a similar outcome= should be applied to draft-ietf-netconf-restconf-notif and its relation to= RFC 8040. Based on my reading of your process suggestions Kent, I like best th= e "mention" approach which you used for RFC-8071, Section 1.4. What I think could be done to cover this is: (A) Remove Section 11: Notes to the RFC Editor (B) Per Kent's desire to also cover draft-ietf-netconf-restconf-notif, pla= ce the following statement into draft-ietf-netconf-subscribed-notifications= directly after Figure 10 [RFC-5277] Section 2.2.1 states that a notification message is to be sent t= o a subscriber which initiated a "create-subscription". With this specifi= cation, this RFC-5277 statement should be more broadly interpreted to mean = that notification messages can also be sent to a subscriber which initiated= an "establish-subscription", or a configured receiver which has been sent = a "subscription-started". Does this work for both of you? [also see my comment below] Minor Issues: ------------- (1) Abstract & Introduction, It is not clear what does the 'binding' mean a= nd who are the parties to this binding? If this is the document that mentions 'bin= ding' first, so please add some more clarifying text. (2) Section 3, since you use MUST in the error handling, isn't it better to= use normative in below sentence as well - OLD: However a single NETCONF transport session cannot support both this specification and a subscription established by [RFC5277]'s "create-subscription" RPC. NEW: However a single NETCONF transport session MUST NOT support both this specification and a subscription established by [RFC5277]'s "create-subscription" RPC. Makes sense. I have made the change, and will post the update when the "Ma= jor issue" from above is resolved. (3) Section 6, You have - And per [RFC5277]'s "eventTime" object definition, the "eventTime" MUST be populated with the event occurrence time. Is this a new requirement, or just re-stating RFC5277? RFC5277 says - eventTime The time the event was generated by the event source. This parameter is of type dateTime and compliant to [RFC3339]. Implementations must support time zones. Also contains notification-specific tagged content, if any. With the exception of , the content of the notification is beyond the scope of this document. Maybe remove MUST? If you are trying to refine the text from RFC5277, then please re-word. You are correct. The MUST is redundant with RFC-5277's XSD definition. T= herefore I have removed "MUST be". Nits: ----- (1) Abstract RFC Editor note: please replace the four references to pre-RFC normative drafts with the actual assigned RFC numbers. I see two drafts in the reference section. Why four? You are correct. I removed the word "four". Also, since those two are normative references, these would be published as= a cluster as a part of normal RFC editor processing right? Yes. (2) Regarding NETCONF, the RFC editor says [1] - NETCONF - Network Configuration Protocol (NETCONF) [Not typically expanded in titles, but expand in abstract] Please expand. Done. (3) s/[I-D.draft-ietf-netconf-subscribed-notifications] /[I-D.ietf-netconf-subscribed-notifications] Actually I changed the [I-D.ietf-netconf-yang-push] to [I-D.draft-ietf-ne= tconf-yang-push] This makes it consistent across all four drafts. The issue isn't consistency so much as meeting expectations, per `xml2rfc`,= the document should have something like the following in the References se= ction, which then auto-expands to the correct reference text, as well as de= fining the anchor "I-D.ietf-netconf-subscribed-notifications": That definitely makes things easier than what I have been doing. I = am hitting an xml2rfc error trying this right now, but I will get there. Eric Kent // shepherd Thanks again! Eric Just so that you have the same style of draft reference in the document. I = get that it would be replaced with a RFC number anyways :) [1] https://www.rfc-editor.org/materials/abbrev.expansion.txt Thanks! Dhruv --_000_1cf686e76a314553842305bc97baeb3dXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dhruv,

Hi Kent,

 

From: Kent Wat= sen, May 1, 2019 6:39 PM

On Apr 30, 2019, at 1:44 PM, Eric Voit (evoit) <<= a href=3D"mailto:evoit@cisco.com">evoit@cisco.com> wrote:=

 

Hi Dhruv,
Hi Kent,

Thanks very much for the comments Dhruv.  Thoughts in-line, with one q= uestion to Kent...

From: Dhruv Dhody, April 30, 2019 12:53 AM

Hello,

I have been selected as the Routing Directorate reviewer for this draft. Th= e
Routing Directorate seeks to review all routing or routing-related drafts a= s they
pass through IETF last call and IESG review, and sometimes on special reque= st.
The purpose of the review is to provide assistance to the Routing ADs. For = more
information about the Routing Directorate, please see
http://tra= c.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it wo= uld
be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or= by
updating the draft.

Document: draft-ietf-netconf-netconf-event-notifications-17
Reviewer: Dhruv Dhody
Review Date: 2019-04-29
IETF LC End Date: 2019-04-12
Intended Status: Standards Track

Summary:
--------
I have some minor concerns about this document that I think should be resol= ved
before publication.

Comments:
---------
This document provides a binding for events streamed over the NETCONF for dynamic subscriptions. This is a companion document to draft-ietf-netconf-<= br> subscribed-notifications and this capability for RESTCONF is defined in dra= ft-ietf-
netconf-restconf-notif.

The document is overall well written, it makes an assumption that the reade= r is
well versed in this area and thus sparse in providing details in the Introd= uction
section. The appendix provides good examples.

I don't see any Routing Yang model specific issue.

Major Issues:
-------------
Note - An IETF process issue, but worth handling right away.

Section 11 says -

11.  Notes to the RFC Editor

  This section can be removed by the RFC editor after the request= s have
  been performed.

It further says -

  RFC 6241 needs to be updated based on the needs of this draft.<= br>   RFC-6241 section 1.2 bullet "(2)" targets RFC-5277 (a= ctually it
  identifies RFC 5717, but that was an error fixed after RFC
  publication).  Anyway the current phrasing in RFC-5277 say= s that a
  notification message can only be sent after a successful "= create-
  subscription".  Therefore the reference text must be = modified to also
  allow notification messages be sent after a successful "es= tablish-
  subscription".  Proposed text for bullet (2) of RFC-6= 241 would be:

    (2)  The Messages layer provides a simple, tra= nsport-independent
         framing mechanism for= encoding RPCs and notifications.
         Section 4 documents t= he RPC messages, [RFC5277] documents
         Notifications sent as= a result of a <create-subscription> RPC,
         and [RFC xxxx] docume= nts Notifications sent as a result of
         an <establish-subs= cription> RPC.

     (where xxxx is replaced with this RFC number)=

I am not sure if this is correct. I don't think RFC editor can do the actio= n you are
asking them to do on their own. They would need an errata (which is not cor= rect
here) or another document that updates RFC 6241. In my view this document should just update RFC 6241 (and mark that in this document's
header) and do necessary text changes to reflect that.


I am happy to follow whatever process is cleanest.   

Kent, are you comfortable with this document directly revising  wordin= g of RFC-6241 section 1.2 bullet "(2)" above?    I= f yes, it would be great to have your thoughts on what needs to go into thi= s document.   Especially as RFC-6241 section 1.2 bullet "(2)= " already had a fix applied against it. 

 

 

Dhruv is correct, the RFC Editor cannot make the req= uested change, and an Errata is also not correct, as there is nothing wrong= with the way that RFC 6241 was written at the time it was written.

 

To answer the question, if this draft is to "up= date" RFC 6241, the steps are 1) declare the update in the draft's hea= der (see Section 2.33.10 of RFC 7749), 2) so so in the Abstract, and 3) hav= e a new section (either before of after the current Section 3 called "Update to RFC 6241" that describes the= desired modification.

 

However, it is unclear if an "update" is a= ppropriate either, given that the "update" is informative in natu= re and, while it is true that this document cannot be used without RFC 6241= , that is also true for so many documents that don't update RFC 6241.

 

From now obsolete RFC 2223 (I couldn't find a curren= t reference):

 

   Updates

 

      To be used as a reference from = a new item that cannot be used

      alone (i.e., one that supplemen= ts a previous document), to refer

      to the previous document.  = ;The newer publication is a part that

      will supplement or be added on = to the existing document; e.g., an

      addendum, or separate, extra in= formation that is to be added to

      the original document.

 

and from expired draft-rfc-editor-rfc2223bis-08= :

 

         Updates=

 

            Specifies = an earlier document whose contents are modified or

            augmented = by the new document.  The new document cannot be

            used alone= , it can only be used in conjunction with the

            earlier do= cument.

 

Is an "update" overreaching?

 

Another option is to not update RFC 6241 and instead= just mention it, similar to what was done here: https://tools.ietf.org/html/rfc8071#= section-1.4.   Note that RFC 8071 originally "updated" RFC 4253, but Benoit (AD at the time) recommended down= grading it to what it is now.

 

 

A couple more thoughts:

 

1) if an update is needed, would it be better coming= from draft-ietf-netconf-subscribed-notifications, which defines the "= establish-subscription" RPC?

 

 

2) whatever the outcome of this discussion, it seems= that a similar outcome should be applied to draft-ietf-netconf-restconf-no= tif and its relation to RFC 8040.

 

 

<eric> Based on = my reading of your process suggestions Kent, I like best the “mention= ” approach which you used for RFC-8071, Section 1.4.

 

What I think could be = done to cover this is:

 

(A)  Remove Secti= on 11: Notes to the RFC Editor

 

(B)  Per KentR= 17;s desire to also cover draft-ietf-netconf-restconf-notif, place the foll= owing statement into draft-ietf-netconf-subscribed-notifications directly a= fter Figure 10

 

[RFC-5277] Section 2.2.1 states that a notification message i= s to be sent to a subscriber which initiated a "create-subscription&qu= ot;.   With this specification, this RFC-5277 statement should be more broadly interpreted to mean that notification messages can = also be sent to a subscriber which initiated an "establish-subscriptio= n", or a configured receiver which has been sent a “subscription= -started”.

 

Does this work for bot= h of you? 

 

 

[also see my comment below]

 

 

 

Minor Issues:
-------------
(1) Abstract & Introduction, It is not clear what does the 'binding' me= an and who
are the parties to this binding? If this is the document that mentions 'bin= ding'
first, so please add some more clarifying text.

(2) Section 3, since you use MUST in the error handling, isn't it better to= use
normative in below sentence as well -
OLD:
            &nb= sp;            =             &nb= sp;            =     However a single
  NETCONF transport session cannot support both this specificatio= n and
  a subscription established by [RFC5277]'s "create-subscrip= tion" RPC.
NEW:
            &nb= sp;            =             &nb= sp;            =     However a single
  NETCONF transport session MUST NOT support both this specificat= ion and
  a subscription established by [RFC5277]'s "create-subscrip= tion" RPC.


Makes sense.  I have made the change, and will post the update when th= e "Major issue" from above is resolved.

(3) Section 6, You have -

  And per [RFC5277]'s "eventTime" object definition, th= e
  "eventTime" MUST be populated with the event occurren= ce time.

Is this a new requirement, or just re-stating RFC5277? RFC5277 says -

     eventTime

        The time the event was gene= rated by the event source.  This
        parameter is of type dateTi= me and compliant to [RFC3339].
        Implementations must suppor= t time zones.

     Also contains notification-specific tagged co= ntent, if any.  With
     the exception of <eventTime>, the conte= nt of the notification is
     beyond the scope of this document.

Maybe remove MUST? If you are trying to refine the text from RFC5277, then<= br> please re-word.


You are correct.  The MUST is redundant with RFC-5277's XSD definition= .   Therefore I have removed "MUST be".

Nits:
-----
(1) Abstract

  RFC Editor note: please replace the four references to pre-RFC<= br>   normative drafts with the actual assigned RFC numbers.

I see two drafts in the reference section. Why four?


You are correct.  I removed the word "four".  

Also, since those two are normative references, th= ese would be published as a
cluster as a part of normal RFC editor processing right?<= /p>


Yes.

(2) Regarding NETCONF, the RFC editor says [1] -
NETCONF    - Network Configuration Protocol (NETCONF)
            &nb= sp; [Not typically expanded in titles, but expand in abstract]

Please expand.


Done.

(3) s/[I-D.draft-ietf-netconf-subscribed-notificat= ions]
    /[I-D.ietf-netconf-subscribed-notifications]


Actually I changed the [I-D.ietf-netconf-yang-push]  to  [I-D.dra= ft-ietf-netconf-yang-push]

This makes it consistent across all four drafts.

 

 

The issue isn't consistency so much as meeting expec= tations, per `xml2rfc`, the document should have something like the followi= ng in the References section, which then auto-expands to the correct refere= nce text, as well as defining the anchor "I-D.ietf-netconf-subscribed-notifications":

 

        <?rfc include=3D= "reference.I-D.ietf-netconf-subscribed-notifications"?>

 

<Eric> That defi= nitely makes things easier than what I have been doing.  I am hitting = an xml2rfc error trying this right now, but I will get there.

 

Eric=

 

 

 

Kent // shepherd

 

 


Thanks again!
Eric

Just so that you have the same style of draft refe= rence in the document. I get
that it would be replaced with a RFC number anyways :)

[1] https://www.rfc-editor.org= /materials/abbrev.expansion.txt

Thanks!
Dhruv

 

--_000_1cf686e76a314553842305bc97baeb3dXCHRTP013ciscocom_-- From nobody Tue May 7 14:49:47 2019 Return-Path: <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@amazonses.watsen.net> X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520381200EB; Tue, 7 May 2019 14:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 1NZLesFMdBSr; Tue, 7 May 2019 14:49:43 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381A6120086; Tue, 7 May 2019 14:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1557265781; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=BJj6538wbLJwCYzQThiiB19tcjwdgm/QGhFZOz9Lofk=; b=ENskTtUohbvx6HpYxqLfyvpv1Vzjel8g+L86qvg4HKGb6Z+PNsAJVK4FCcD8TKzS 0bZLu9YEq/uprXQ2EXxGgEnjET7josPqLpg8OGwGAuLCEc7+OFy/0agxvu2q2fcLeYZ L9Glw6uzdwD1Yhox26scI5wRq/JvKhMciCwDScmM= From: Kent Watsen Message-ID: <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0FE25B22-758E-4E55-B537-77E289AF4899" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 7 May 2019 21:49:41 +0000 In-Reply-To: <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> Cc: Dhruv Dhody , "rtg-dir@ietf.org" , "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" , Dhruv Dhody , "" To: "Eric Voit (evoit)" References: <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.05.07-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 21:49:46 -0000 --Apple-Mail=_0FE25B22-758E-4E55-B537-77E289AF4899 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Based on my reading of your process suggestions Kent, I like = best the =E2=80=9Cmention=E2=80=9D approach which you used for RFC-8071, = Section 1.4. > =20 > What I think could be done to cover this is: > =20 > (A) Remove Section 11: Notes to the RFC Editor > =20 > (B) Per Kent=E2=80=99s desire to also cover = draft-ietf-netconf-restconf-notif, place the following statement into = draft-ietf-netconf-subscribed-notifications directly after Figure 10 > =20 > [RFC-5277] Section 2.2.1 states that a notification message is to be = sent to a subscriber which initiated a "create-subscription". With = this specification, this RFC-5277 statement should be more broadly = interpreted to mean that notification messages can also be sent to a = subscriber which initiated an "establish-subscription", or a configured = receiver which has been sent a =E2=80=9Csubscription-started=E2=80=9D. > =20 > Does this work for both of you?=20 Works for me. > The issue isn't consistency so much as meeting expectations, per = `xml2rfc`, the document should have something like the following in the = References section, which then auto-expands to the correct reference = text, as well as defining the anchor = "I-D.ietf-netconf-subscribed-notifications": > =20 > > =20 > That definitely makes things easier than what I have been = doing. I am hitting an xml2rfc error trying this right now, but I will = get there. Yes, it was an eye-opener when I figured it out. Be aware that, though = some external sources (e.g., ITU standards) are supported, many are not, = and so hand-coding the is still sometimes required... Kent // shepherd --Apple-Mail=_0FE25B22-758E-4E55-B537-77E289AF4899 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

<eric> Based on my reading of your process = suggestions Kent, I like best the =E2=80=9Cmention=E2=80=9D approach = which you used for RFC-8071, Section 1.4.
 
What I = think could be done to cover this is:
 
(A) =  Remove Section 11: Notes to the RFC Editor
 
(B) =  Per Kent=E2=80=99s desire to also cover = draft-ietf-netconf-restconf-notif, place the following statement into = draft-ietf-netconf-subscribed-notifications directly after Figure 10
 
[RFC-5277] = Section 2.2.1 states that a notification message is to be sent to a = subscriber which initiated a "create-subscription".   With = this specification, this RFC-5277 statement should be more broadly = interpreted to mean that notification messages can also be sent to a = subscriber which initiated an "establish-subscription", or a configured = receiver which has been sent a =E2=80=9Csubscription-started=E2=80=9D.
 
Does = this work for both of = you? 

Works for me.



The issue isn't consistency so = much as meeting expectations, per `xml2rfc`, the document should have = something like the following in the References section, which then = auto-expands to the correct reference text, as well as defining the = anchor = "I-D.ietf-netconf-subscribed-notifications":
 
      =   <?rfc = include=3D"reference.I-D.ietf-netconf-subscribed-notifications"?>
 
<Eric> That definitely makes things easier than = what I have been doing.  I am hitting an xml2rfc error trying this = right now, but I will get = there.

Yes, it was an eye-opener when I figured it out. =   Be aware that, though some external sources (e.g., ITU standards) = are supported, many are not, and so hand-coding the <reference> is = still sometimes required...


Kent // shepherd



= --Apple-Mail=_0FE25B22-758E-4E55-B537-77E289AF4899-- From nobody Tue May 7 23:21:30 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A06112014A; Tue, 7 May 2019 23:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 zKKjeAJQMW8j; Tue, 7 May 2019 23:21:23 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 0A2C6120134; Tue, 7 May 2019 23:21:23 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id g71so2152237ita.5; Tue, 07 May 2019 23:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4j58fOYHrClmYK94QGDLpjLQ7AmsI03YqKwjVGMeaZo=; b=end91jnoC15BoLGesk297OPobhrOGxVMW8XSQ/jaSAPG8gNwCcDVfXQrUFA0664Ec8 geuZSSgkOassi3i9GuLLbPrENL/2SCxaiRbWN+eGjtvTW9gqCD9aYDAyAMcr9Kt9s8pv /s47rfoltgk74n6cKjGFrMqZtYYNwJW+v4QhahR1s5+TyVuYycNdb11f/iXT9P07xYu6 gd934nUauT0tbEmfI+f3bGpsdqaqYRABiezWOMQPJqC8GvaAzTtViEpq3WkazmOMzIGQ Goi5V4nwNRBIL16rT4WJULRqLYwuGnT4FSt8g/o393jU77ALc11M5eUinvslwqy2QcS0 fzNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4j58fOYHrClmYK94QGDLpjLQ7AmsI03YqKwjVGMeaZo=; b=YN7twdQ0ArejB21Xkwo/SkRjX5HMAquP/ZymUH/Ukm2kFspv2ZtSj0g9Dg212ThIxn Pi5jTlrKWDcZZaXpQXUz4mBIix6pxZlDW8PMmhEBcSSyoDHs2wEnxKceYHmN9YXqjKM1 SY/VP3XTOBRdDyOFgIZwuNOHxXGfFbpeRo9ZPzfnVX77LYmQNaknY5iuNsHh896TG6Ir w8srxvrVlN+tLWMwrrFahhGCarEBSPHllL0s5hYtvbmAf8tz0RHY+lCEz7bgQRsGglmK R2W79GBe5z1+/5T8/ojV1p2+QzTCiTMYNzUdYegBDIQXQ2Nu1UA/GzYUBgNIyOYRNqjd lH1A== X-Gm-Message-State: APjAAAUV2k6tKkAwHac4iCXyqYE/kpCiZdQVg7Nxfo7myLNpojFxOtLY EUvlwO4BJMLqAW6N/Ss4vNZdBS3mq0pgyGeHl2s= X-Google-Smtp-Source: APXvYqyZ9mlpYlrerT2VPxlbORQe7EwJrU3z4S4eYSo60R7UjFSQbCAq8dsV2yYmdqoBDaZix7/5ZC4Bjwm/CL6mAXE= X-Received: by 2002:a24:cd82:: with SMTP id l124mr2157139itg.164.1557296482202; Tue, 07 May 2019 23:21:22 -0700 (PDT) MIME-Version: 1.0 References: <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com> In-Reply-To: <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com> From: Dhruv Dhody Date: Wed, 8 May 2019 11:50:45 +0530 Message-ID: To: Kent Watsen Cc: "Eric Voit (evoit)" , "rtg-dir@ietf.org" , "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" , Dhruv Dhody , "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 06:21:25 -0000 Hi Kent, Eric, Fine with me! Thanks! Dhruv On Wed, May 8, 2019 at 3:19 AM Kent Watsen wrote: > > > > Based on my reading of your process suggestions Kent, I like best = the =E2=80=9Cmention=E2=80=9D approach which you used for RFC-8071, Section= 1.4. > > What I think could be done to cover this is: > > (A) Remove Section 11: Notes to the RFC Editor > > (B) Per Kent=E2=80=99s desire to also cover draft-ietf-netconf-restconf-= notif, place the following statement into draft-ietf-netconf-subscribed-not= ifications directly after Figure 10 > > [RFC-5277] Section 2.2.1 states that a notification message is to be sent= to a subscriber which initiated a "create-subscription". With this speci= fication, this RFC-5277 statement should be more broadly interpreted to mea= n that notification messages can also be sent to a subscriber which initiat= ed an "establish-subscription", or a configured receiver which has been sen= t a =E2=80=9Csubscription-started=E2=80=9D. > > Does this work for both of you? > > > Works for me. > > > > The issue isn't consistency so much as meeting expectations, per `xml2rfc= `, the document should have something like the following in the References = section, which then auto-expands to the correct reference text, as well as = defining the anchor "I-D.ietf-netconf-subscribed-notifications": > > > > That definitely makes things easier than what I have been doing. = I am hitting an xml2rfc error trying this right now, but I will get there. > > > Yes, it was an eye-opener when I figured it out. Be aware that, though = some external sources (e.g., ITU standards) are supported, many are not, an= d so hand-coding the is still sometimes required... > > > Kent // shepherd > > > From nobody Wed May 8 08:44:41 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A6512013C; Wed, 8 May 2019 08:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 aluGz2cHVDc8; Wed, 8 May 2019 08:44:30 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CEA5120136; Wed, 8 May 2019 08:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2928; q=dns/txt; s=iport; t=1557330269; x=1558539869; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r477+/v9Fjr/1wZqh4zPAZFRSKPiAJSC6FGSKVQC9BY=; b=Uxa2vdMYB74KiF1dl7Eq76EvRAkMqAMZbsCYPOO3itx+7QPgiUowetEf DaVfPv0GlxL4/Gh6FsfNS1Ug6XUKpXbVGCRE/towKeX+DOh6IQhZ48X3o uhZqnCcqo7Fqq5aSsmZ/fOK9GYx8MfEbcELAZZ7fLZ1YKIXvrjcwXBKwu g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAABA+NJc/5ldJa1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgWYqgT0wKAqEBogcjQKYUoF7CQcBAS+EPwIXgXEjNAkOAQM?= =?us-ascii?q?BAQQBAQIBBG0ohUoBAQEDASMRQwIFCwIBCBUDAgIJHQICAjAVEAIEAQ0FCIJ?= =?us-ascii?q?PS4F8D60jgS+KKoELJwGLTReBQD+EIz6ESzOCUIJYBI0qLJlsCQKCCZJHI4I?= =?us-ascii?q?Qk0eDG4kJgSGTVQIRFYEwHziBVnAVgyeQUUExj26BIQEB?= X-IronPort-AV: E=Sophos;i="5.60,446,1549929600"; d="scan'208";a="268935471" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 May 2019 15:44:28 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x48FiR7f000383 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 May 2019 15:44:27 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 May 2019 11:44:26 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Wed, 8 May 2019 11:44:26 -0400 From: "Eric Voit (evoit)" To: Dhruv Dhody , Kent Watsen CC: "rtg-dir@ietf.org" , "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" , Dhruv Dhody , "" Thread-Topic: RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 Thread-Index: AQHU/xC8WbWTXSPvekeZmlnK7/xOtqZU7OSwgAI1bICACP37sIAAYi6AgACOyoCAAFnN8A== Date: Wed, 8 May 2019 15:44:26 +0000 Message-ID: References: <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.233] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 15:44:32 -0000 VXBkYXRlIHBvc3RlZCBhcyAtdjIwLiAgIFdpdGggdGhlIGNvcnJlc3BvbmRpbmcgY2hhbmdlIHRv IGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMgcG9zdGVkIGFzIC12 MjUuDQoNCkVyaWMNCg0KPiBGcm9tOiBEaHJ1diBEaG9keSwgTWF5IDgsIDIwMTkgMjoyMSBBTQ0K PiANCj4gSGkgS2VudCwgRXJpYywNCj4gDQo+IEZpbmUgd2l0aCBtZSENCj4gDQo+IFRoYW5rcyEN Cj4gRGhydXYNCj4gDQo+IE9uIFdlZCwgTWF5IDgsIDIwMTkgYXQgMzoxOSBBTSBLZW50IFdhdHNl biA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPg0KPiA+IDxlcmlj PiBCYXNlZCBvbiBteSByZWFkaW5nIG9mIHlvdXIgcHJvY2VzcyBzdWdnZXN0aW9ucyBLZW50LCBJ IGxpa2UgYmVzdCB0aGUNCj4g4oCcbWVudGlvbuKAnSBhcHByb2FjaCB3aGljaCB5b3UgdXNlZCBm b3IgUkZDLTgwNzEsIFNlY3Rpb24gMS40Lg0KPiA+DQo+ID4gV2hhdCBJIHRoaW5rIGNvdWxkIGJl IGRvbmUgdG8gY292ZXIgdGhpcyBpczoNCj4gPg0KPiA+IChBKSAgUmVtb3ZlIFNlY3Rpb24gMTE6 IE5vdGVzIHRvIHRoZSBSRkMgRWRpdG9yDQo+ID4NCj4gPiAoQikgIFBlciBLZW504oCZcyBkZXNp cmUgdG8gYWxzbyBjb3ZlciBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYsIHBsYWNl IHRoZQ0KPiBmb2xsb3dpbmcgc3RhdGVtZW50IGludG8gZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNj cmliZWQtbm90aWZpY2F0aW9ucyBkaXJlY3RseQ0KPiBhZnRlciBGaWd1cmUgMTANCj4gPg0KPiA+ IFtSRkMtNTI3N10gU2VjdGlvbiAyLjIuMSBzdGF0ZXMgdGhhdCBhIG5vdGlmaWNhdGlvbiBtZXNz YWdlIGlzIHRvIGJlIHNlbnQgdG8gYQ0KPiBzdWJzY3JpYmVyIHdoaWNoIGluaXRpYXRlZCBhICJj cmVhdGUtc3Vic2NyaXB0aW9uIi4gICBXaXRoIHRoaXMgc3BlY2lmaWNhdGlvbiwgdGhpcw0KPiBS RkMtNTI3NyBzdGF0ZW1lbnQgc2hvdWxkIGJlIG1vcmUgYnJvYWRseSBpbnRlcnByZXRlZCB0byBt ZWFuIHRoYXQNCj4gbm90aWZpY2F0aW9uIG1lc3NhZ2VzIGNhbiBhbHNvIGJlIHNlbnQgdG8gYSBz dWJzY3JpYmVyIHdoaWNoIGluaXRpYXRlZCBhbg0KPiAiZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiIs IG9yIGEgY29uZmlndXJlZCByZWNlaXZlciB3aGljaCBoYXMgYmVlbiBzZW50IGENCj4g4oCcc3Vi c2NyaXB0aW9uLXN0YXJ0ZWTigJ0uDQo+ID4NCj4gPiBEb2VzIHRoaXMgd29yayBmb3IgYm90aCBv ZiB5b3U/DQo+ID4NCj4gPg0KPiA+IFdvcmtzIGZvciBtZS4NCj4gPg0KPiA+DQo+ID4NCj4gPiBU aGUgaXNzdWUgaXNuJ3QgY29uc2lzdGVuY3kgc28gbXVjaCBhcyBtZWV0aW5nIGV4cGVjdGF0aW9u cywgcGVyIGB4bWwycmZjYCwgdGhlDQo+IGRvY3VtZW50IHNob3VsZCBoYXZlIHNvbWV0aGluZyBs aWtlIHRoZSBmb2xsb3dpbmcgaW4gdGhlIFJlZmVyZW5jZXMgc2VjdGlvbiwNCj4gd2hpY2ggdGhl biBhdXRvLWV4cGFuZHMgdG8gdGhlIGNvcnJlY3QgcmVmZXJlbmNlIHRleHQsIGFzIHdlbGwgYXMg ZGVmaW5pbmcgdGhlDQo+IGFuY2hvciAiSS1ELmlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlm aWNhdGlvbnMiOg0KPiA+DQo+ID4gICAgICAgICA8P3JmYyBpbmNsdWRlPSJyZWZlcmVuY2UuSS1E LmlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMiPz4NCj4gPg0KPiA+IDxFcmlj PiBUaGF0IGRlZmluaXRlbHkgbWFrZXMgdGhpbmdzIGVhc2llciB0aGFuIHdoYXQgSSBoYXZlIGJl ZW4gZG9pbmcuICBJIGFtDQo+IGhpdHRpbmcgYW4geG1sMnJmYyBlcnJvciB0cnlpbmcgdGhpcyBy aWdodCBub3csIGJ1dCBJIHdpbGwgZ2V0IHRoZXJlLg0KPiA+DQo+ID4NCj4gPiBZZXMsIGl0IHdh cyBhbiBleWUtb3BlbmVyIHdoZW4gSSBmaWd1cmVkIGl0IG91dC4gICBCZSBhd2FyZSB0aGF0LCB0 aG91Z2ggc29tZQ0KPiBleHRlcm5hbCBzb3VyY2VzIChlLmcuLCBJVFUgc3RhbmRhcmRzKSBhcmUg c3VwcG9ydGVkLCBtYW55IGFyZSBub3QsIGFuZCBzbyBoYW5kLQ0KPiBjb2RpbmcgdGhlIDxyZWZl cmVuY2U+IGlzIHN0aWxsIHNvbWV0aW1lcyByZXF1aXJlZC4uLg0KPiA+DQo+ID4NCj4gPiBLZW50 IC8vIHNoZXBoZXJkDQo+ID4NCj4gPg0KPiA+DQo= From nobody Wed May 8 21:03:18 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42AF12025B; Wed, 8 May 2019 21:03:15 -0700 (PDT) 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 fNuDIR3eFOO2; Wed, 8 May 2019 21:03:13 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 53DA0120264; Wed, 8 May 2019 21:03:13 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id z4so566335iol.0; Wed, 08 May 2019 21:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5QQMZ929+wacsGBuhjCLfY+y7FGKryJPsvoIVE7BVKc=; b=DIvqaj/27Hc6foVZLdLEAxPRnW4R3LDEbUA+V1so5P9p1Ypuhgg4CxqI3vHmNntL2w Kknnv9nn3vukuq2Lrp7GComb1BnzQgYUQrqLBWr5T9CTAPTaWgVWvJbsmtjWTLZOgnee cZP8QwWCU3qdC/3mp+zlX+rwZxMFIbZMyDBZdhm5HqTrnQ0LF6JLffoEGX72JJOr1RZX jABuPbI7I2eFcq7061vy+MX909ILjmRYlzqbf4geR2i+mgF8MNddfNCkgEHfOy0MkVQV LUK9M8w8VYsS/3WqfSJw2OU9HwlHUm+2As2gItGfRPeIlcotlmU70Pesi12M0kHt6Fmr xglg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5QQMZ929+wacsGBuhjCLfY+y7FGKryJPsvoIVE7BVKc=; b=npMCgAt3hKcgjprmJ1eKUPVBNkNUrBpj+EgzEVDprmmeg/9rhRX3igpPfqUGMDfMzs OUgEGLzzcd1kVpCREFDkyPUYR8Km9RCMSNEF6DUYiz7yaU4R7c+skQtiMixGX+d3yGyY bj3C+f19N642u1KxANIL4fT6l4qA50W5OD54ftvZcHhE6a6D+39OER2Fqv0On5Ise04X QsO7GHZF4dv3leFIyZGFYBTwJUbWuJWhqDlnD/FLty0Zv8Z7I3VpRgBrVrLKEng4CDzQ I00YRRUsne7Y3mORKpDHPaS4EebgLeqdC2c5RI+yhb+bhSWPGtTA7b8MpbE9wGDfuAt+ dRjg== X-Gm-Message-State: APjAAAVISKX9t4lYgVO/Hkw0UAjmfn/5M51aeQvVxSSBIiMAci91bYyo Yg2iU7VnuNN3Eb4BZFGj6uZm1MriEHGyAuXsJiY= X-Google-Smtp-Source: APXvYqzNvnT75htL2kMUWtBDvKorKkLcw1qkb07ca6t7U+tkNUAJhXiIHPD1HjqZJSL1yNpTrK7urWk67KHJloNrIdc= X-Received: by 2002:a5e:9b05:: with SMTP id j5mr1113170iok.158.1557374592410; Wed, 08 May 2019 21:03:12 -0700 (PDT) MIME-Version: 1.0 References: <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com> In-Reply-To: From: Dhruv Dhody Date: Thu, 9 May 2019 09:32:35 +0530 Message-ID: To: "Eric Voit (evoit)" Cc: Kent Watsen , "rtg-dir@ietf.org" , "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" , Dhruv Dhody , "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 04:03:16 -0000 Hi Eric, Thanks for the update. I see one minor comment that is not handled. Maybe you missed it? Or you disagree, that some more text is required? > Minor Issues: > ------------- > (1) Abstract & Introduction, It is not clear what does the 'binding' mean= and who > are the parties to this binding? If this is the document that mentions 'b= inding' > first, so please add some more clarifying text. Thanks! Dhruv On Wed, May 8, 2019 at 9:14 PM Eric Voit (evoit) wrote: > > Update posted as -v20. With the corresponding change to draft-ietf-netc= onf-subscribed-notifications posted as -v25. > > Eric > > > From: Dhruv Dhody, May 8, 2019 2:21 AM > > > > Hi Kent, Eric, > > > > Fine with me! > > > > Thanks! > > Dhruv > > > > On Wed, May 8, 2019 at 3:19 AM Kent Watsen wrote= : > > > > > > > > > > > > Based on my reading of your process suggestions Kent, I like b= est the > > =E2=80=9Cmention=E2=80=9D approach which you used for RFC-8071, Section= 1.4. > > > > > > What I think could be done to cover this is: > > > > > > (A) Remove Section 11: Notes to the RFC Editor > > > > > > (B) Per Kent=E2=80=99s desire to also cover draft-ietf-netconf-restc= onf-notif, place the > > following statement into draft-ietf-netconf-subscribed-notifications di= rectly > > after Figure 10 > > > > > > [RFC-5277] Section 2.2.1 states that a notification message is to be = sent to a > > subscriber which initiated a "create-subscription". With this specifi= cation, this > > RFC-5277 statement should be more broadly interpreted to mean that > > notification messages can also be sent to a subscriber which initiated = an > > "establish-subscription", or a configured receiver which has been sent = a > > =E2=80=9Csubscription-started=E2=80=9D. > > > > > > Does this work for both of you? > > > > > > > > > Works for me. > > > > > > > > > > > > The issue isn't consistency so much as meeting expectations, per `xml= 2rfc`, the > > document should have something like the following in the References sec= tion, > > which then auto-expands to the correct reference text, as well as defin= ing the > > anchor "I-D.ietf-netconf-subscribed-notifications": > > > > > > > > > > > > That definitely makes things easier than what I have been doin= g. I am > > hitting an xml2rfc error trying this right now, but I will get there. > > > > > > > > > Yes, it was an eye-opener when I figured it out. Be aware that, tho= ugh some > > external sources (e.g., ITU standards) are supported, many are not, and= so hand- > > coding the is still sometimes required... > > > > > > > > > Kent // shepherd > > > > > > > > > From nobody Thu May 9 13:47:51 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7743E1200DE; Thu, 9 May 2019 13:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 fEPEZsopt7QG; Thu, 9 May 2019 13:47:40 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDCE612009C; Thu, 9 May 2019 13:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5014; q=dns/txt; s=iport; t=1557434859; x=1558644459; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fe08GN/4ONqB/3ECqbgrx3gPLg19ykkOYX6Zmmxzo1I=; b=VlySrsFguTO/kQNZNqL4x8wKU/lXtBuWJVx7u1KexTyNS1ywtr+TTQOB GBLcSDENfjpFTDT2dmn5VGgZ2PN0EXv4yC5f0rBsAN1ZY9YE9mCx+bgRX 0L0Q3EUO23MQU2tgoRaPKP9XpnQYaAjdQWNEOetob+z9AJje5Jqwai6Bd s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DAAADokNRc/5JdJa1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBVAQBAQsBgWYqgT0wKAqEB5Uemk4JAQEBDAEBLwEBhEACF4FxIzcGDgE?= =?us-ascii?q?DAQEEAQECAQRtKIVKAQEBAwEjEUMCBQsCAQgVAwICCR0CAgIwFRACBA4FCIJ?= =?us-ascii?q?PS4F8D603gS+KMoELJwGLTheBQD+EIz6ESzOCUIJYBIsZA4IPLJluCQKCCZJ?= =?us-ascii?q?MI4IQhkYFjH6DG4ork1YCERWBMDUigVdwFYMnkFFBMY5egSEBAQ?= X-IronPort-AV: E=Sophos;i="5.60,450,1549929600"; d="scan'208";a="557414181" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 May 2019 20:47:38 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x49Klcsp005052 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 May 2019 20:47:38 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 May 2019 16:47:37 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Thu, 9 May 2019 16:47:37 -0400 From: "Eric Voit (evoit)" To: Dhruv Dhody CC: Kent Watsen , "rtg-dir@ietf.org" , "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" , Dhruv Dhody , "" Thread-Topic: RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 Thread-Index: AQHU/xC8WbWTXSPvekeZmlnK7/xOtqZU7OSwgAI1bICACP37sIAAYi6AgACOyoCAAFnN8IABEe2AgADU50A= Date: Thu, 9 May 2019 20:47:37 +0000 Message-ID: References: <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 20:47:42 -0000 SGkgRGhydXYsDQoNCj4gRnJvbTogRGhydXYgRGhvZHksIE1heSA5LCAyMDE5IDEyOjAzIEFNDQo+ IA0KPiBIaSBFcmljLA0KPiANCj4gVGhhbmtzIGZvciB0aGUgdXBkYXRlLiBJIHNlZSBvbmUgbWlu b3IgY29tbWVudCB0aGF0IGlzIG5vdCBoYW5kbGVkLg0KPiBNYXliZSB5b3UgbWlzc2VkIGl0PyBP ciB5b3UgZGlzYWdyZWUsIHRoYXQgc29tZSBtb3JlIHRleHQgaXMgcmVxdWlyZWQ/DQo+IA0KPiA+ IE1pbm9yIElzc3VlczoNCj4gPiAtLS0tLS0tLS0tLS0tDQo+ID4gKDEpIEFic3RyYWN0ICYgSW50 cm9kdWN0aW9uLCBJdCBpcyBub3QgY2xlYXIgd2hhdCBkb2VzIHRoZSAnYmluZGluZycNCj4gPiBt ZWFuIGFuZCB3aG8gYXJlIHRoZSBwYXJ0aWVzIHRvIHRoaXMgYmluZGluZz8gSWYgdGhpcyBpcyB0 aGUgZG9jdW1lbnQgdGhhdA0KPiBtZW50aW9ucyAnYmluZGluZycNCj4gPiBmaXJzdCwgc28gcGxl YXNlIGFkZCBzb21lIG1vcmUgY2xhcmlmeWluZyB0ZXh0Lg0KDQpUaGlzIGlzIG5vdCB0aGUgZmly c3QgZG9jdW1lbnQgd2hpY2ggbWVudGlvbnMgJ2JpbmRpbmcnICBmaXJzdC4gIFRoZSBkb2N1bWVu dCB3aGljaCBkb2VzIHRoaXMgZmlyc3QgaXMgZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQt bm90aWZpY2F0aW9ucy4gICBJbiB0aGUgYWJzdHJhY3Qgb2YgdGhpcyBkb2N1bWVudCwgdGhhdCBk cmFmdCBpcyBub3QgZXhwbGljaXRseSBsaXN0ZWQgYnkgcmVmZXJlbmNlIChhcyBJIHVuZGVyc3Rv b2Qgd2UgYXJlIG5vdCBzdXBwb3NlZCB0byB1c2UgcmVmZXJlbmNlcyBpbiBhYnN0cmFjdHMpLiAg QnV0IGl0IGlzIGxpc3RlZCBpbiB0aGUgSW50cm9kdWN0aW9uLg0KDQpUbyBtYWtlIHRoaXMgY2xl YXJlciBmb3IgeW91IGluIHRoaXMgZG9jdW1lbnQsIHBlcmhhcHMgInRyYW5zcG9ydCBiaW5kaW5n IiBpbnN0ZWFkIG9mICJiaW5kaW5nIj8gICBJIHJlYWxseSBkb24ndCBoYXZlIG1hbnkgYWx0ZXJu YXRpdmVzIEkgY2FuIHRoaW5rIG9mIHdoaWNoIGFsc28ga2VlcHMgdGhlIHRleHQgYnJpZWYuICAg VGhpcyBwYXJ0aWN1bGFyIHRleHQgaGFzIGJlZW4gZnJlcXVlbnRseSB0d2Vha2VkIGluIHRoZSBw YXN0Lg0KDQpUaGFua3MuDQpFcmljDQoNCiANCj4gVGhhbmtzIQ0KPiBEaHJ1dj4gDQo+IE9uIFdl ZCwgTWF5IDgsIDIwMTkgYXQgOToxNCBQTSBFcmljIFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28u Y29tPiB3cm90ZToNCj4gPg0KPiA+IFVwZGF0ZSBwb3N0ZWQgYXMgLXYyMC4gICBXaXRoIHRoZSBj b3JyZXNwb25kaW5nIGNoYW5nZSB0byBkcmFmdC1pZXRmLW5ldGNvbmYtDQo+IHN1YnNjcmliZWQt bm90aWZpY2F0aW9ucyBwb3N0ZWQgYXMgLXYyNS4NCj4gPg0KPiA+IEVyaWMNCj4gPg0KPiA+ID4g RnJvbTogRGhydXYgRGhvZHksIE1heSA4LCAyMDE5IDI6MjEgQU0NCj4gPiA+DQo+ID4gPiBIaSBL ZW50LCBFcmljLA0KPiA+ID4NCj4gPiA+IEZpbmUgd2l0aCBtZSENCj4gPiA+DQo+ID4gPiBUaGFu a3MhDQo+ID4gPiBEaHJ1dg0KPiA+ID4NCj4gPiA+IE9uIFdlZCwgTWF5IDgsIDIwMTkgYXQgMzox OSBBTSBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+DQo+IHdyb3RlOg0KPiA+ID4g Pg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiA8ZXJpYz4gQmFzZWQgb24gbXkgcmVhZGluZyBv ZiB5b3VyIHByb2Nlc3Mgc3VnZ2VzdGlvbnMgS2VudCwgSQ0KPiA+ID4gPiBsaWtlIGJlc3QgdGhl DQo+ID4gPiDigJxtZW50aW9u4oCdIGFwcHJvYWNoIHdoaWNoIHlvdSB1c2VkIGZvciBSRkMtODA3 MSwgU2VjdGlvbiAxLjQuDQo+ID4gPiA+DQo+ID4gPiA+IFdoYXQgSSB0aGluayBjb3VsZCBiZSBk b25lIHRvIGNvdmVyIHRoaXMgaXM6DQo+ID4gPiA+DQo+ID4gPiA+IChBKSAgUmVtb3ZlIFNlY3Rp b24gMTE6IE5vdGVzIHRvIHRoZSBSRkMgRWRpdG9yDQo+ID4gPiA+DQo+ID4gPiA+IChCKSAgUGVy IEtlbnTigJlzIGRlc2lyZSB0byBhbHNvIGNvdmVyDQo+ID4gPiA+IGRyYWZ0LWlldGYtbmV0Y29u Zi1yZXN0Y29uZi1ub3RpZiwgcGxhY2UgdGhlDQo+ID4gPiBmb2xsb3dpbmcgc3RhdGVtZW50IGlu dG8gZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucw0KPiA+ID4gZGly ZWN0bHkgYWZ0ZXIgRmlndXJlIDEwDQo+ID4gPiA+DQo+ID4gPiA+IFtSRkMtNTI3N10gU2VjdGlv biAyLjIuMSBzdGF0ZXMgdGhhdCBhIG5vdGlmaWNhdGlvbiBtZXNzYWdlIGlzIHRvDQo+ID4gPiA+ IGJlIHNlbnQgdG8gYQ0KPiA+ID4gc3Vic2NyaWJlciB3aGljaCBpbml0aWF0ZWQgYSAiY3JlYXRl LXN1YnNjcmlwdGlvbiIuICAgV2l0aCB0aGlzIHNwZWNpZmljYXRpb24sDQo+IHRoaXMNCj4gPiA+ IFJGQy01Mjc3IHN0YXRlbWVudCBzaG91bGQgYmUgbW9yZSBicm9hZGx5IGludGVycHJldGVkIHRv IG1lYW4gdGhhdA0KPiA+ID4gbm90aWZpY2F0aW9uIG1lc3NhZ2VzIGNhbiBhbHNvIGJlIHNlbnQg dG8gYSBzdWJzY3JpYmVyIHdoaWNoDQo+ID4gPiBpbml0aWF0ZWQgYW4gImVzdGFibGlzaC1zdWJz Y3JpcHRpb24iLCBvciBhIGNvbmZpZ3VyZWQgcmVjZWl2ZXINCj4gPiA+IHdoaWNoIGhhcyBiZWVu IHNlbnQgYSDigJxzdWJzY3JpcHRpb24tc3RhcnRlZOKAnS4NCj4gPiA+ID4NCj4gPiA+ID4gRG9l cyB0aGlzIHdvcmsgZm9yIGJvdGggb2YgeW91Pw0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBX b3JrcyBmb3IgbWUuDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBpc3N1 ZSBpc24ndCBjb25zaXN0ZW5jeSBzbyBtdWNoIGFzIG1lZXRpbmcgZXhwZWN0YXRpb25zLCBwZXIN Cj4gPiA+ID4gYHhtbDJyZmNgLCB0aGUNCj4gPiA+IGRvY3VtZW50IHNob3VsZCBoYXZlIHNvbWV0 aGluZyBsaWtlIHRoZSBmb2xsb3dpbmcgaW4gdGhlIFJlZmVyZW5jZXMNCj4gPiA+IHNlY3Rpb24s IHdoaWNoIHRoZW4gYXV0by1leHBhbmRzIHRvIHRoZSBjb3JyZWN0IHJlZmVyZW5jZSB0ZXh0LCBh cw0KPiA+ID4gd2VsbCBhcyBkZWZpbmluZyB0aGUgYW5jaG9yICJJLUQuaWV0Zi1uZXRjb25mLXN1 YnNjcmliZWQtbm90aWZpY2F0aW9ucyI6DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgPD9yZmMN Cj4gPiA+ID4gaW5jbHVkZT0icmVmZXJlbmNlLkktRC5pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1u b3RpZmljYXRpb25zIj8+DQo+ID4gPiA+DQo+ID4gPiA+IDxFcmljPiBUaGF0IGRlZmluaXRlbHkg bWFrZXMgdGhpbmdzIGVhc2llciB0aGFuIHdoYXQgSSBoYXZlIGJlZW4NCj4gPiA+ID4gZG9pbmcu ICBJIGFtDQo+ID4gPiBoaXR0aW5nIGFuIHhtbDJyZmMgZXJyb3IgdHJ5aW5nIHRoaXMgcmlnaHQg bm93LCBidXQgSSB3aWxsIGdldCB0aGVyZS4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gWWVz LCBpdCB3YXMgYW4gZXllLW9wZW5lciB3aGVuIEkgZmlndXJlZCBpdCBvdXQuICAgQmUgYXdhcmUg dGhhdCwgdGhvdWdoDQo+IHNvbWUNCj4gPiA+IGV4dGVybmFsIHNvdXJjZXMgKGUuZy4sIElUVSBz dGFuZGFyZHMpIGFyZSBzdXBwb3J0ZWQsIG1hbnkgYXJlIG5vdCwNCj4gPiA+IGFuZCBzbyBoYW5k LSBjb2RpbmcgdGhlIDxyZWZlcmVuY2U+IGlzIHN0aWxsIHNvbWV0aW1lcyByZXF1aXJlZC4uLg0K PiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBLZW50IC8vIHNoZXBoZXJkDQo+ID4gPiA+DQo+ID4g PiA+DQo+ID4gPiA+DQo= From nobody Thu May 9 20:28:34 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC525120098; Thu, 9 May 2019 20:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 ndpfxbhldtKR; Thu, 9 May 2019 20:28:24 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8AEF12006E; Thu, 9 May 2019 20:28:23 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B184870B0F97F5C4BB1D; Fri, 10 May 2019 04:28:21 +0100 (IST) Received: from BLREML703-CAH.china.huawei.com (10.20.4.172) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 10 May 2019 04:28:20 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.86]) by blreml703-cah.china.huawei.com ([::1]) with mapi id 14.03.0439.000; Fri, 10 May 2019 08:58:07 +0530 From: Dhruv Dhody To: "Eric Voit (evoit)" , Dhruv Dhody CC: Kent Watsen , "rtg-dir@ietf.org" , "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" , "" Thread-Topic: RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 Thread-Index: AQHU/xDB/M0APTVwV06CgM5HTxBRkKZUnleAgAHkuICACVqOAIAABZqAgACOyoCAAJ1+AIAAzj2AgAEYzYCAAMiuUA== Date: Fri, 10 May 2019 03:28:06 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8DA56A70@BLREML503-MBX.china.huawei.com> References: <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.149.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 03:28:26 -0000 SGkgRXJpYywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBFcmljIFZv aXQgKGV2b2l0KSBbbWFpbHRvOmV2b2l0QGNpc2NvLmNvbV0NCj4gU2VudDogMTAgTWF5IDIwMTkg MDI6MTgNCj4gVG86IERocnV2IERob2R5IDxkaHJ1di5pZXRmQGdtYWlsLmNvbT4NCj4gQ2M6IEtl bnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD47IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRyYWZ0 LWlldGYtDQo+IG5ldGNvbmYtbmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb25zLmFsbEBpZXRmLm9y ZzsgbmV0Y29uZkBpZXRmLm9yZzsgRGhydXYNCj4gRGhvZHkgPGRocnV2LmRob2R5QGh1YXdlaS5j b20+OyA8cnRnLWFkc0BpZXRmLm9yZz4gPHJ0Zy1hZHNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJF OiBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLW5ldGNvbmYtbmV0Y29uZi1ldmVudC0NCj4gbm90 aWZpY2F0aW9ucy0xNw0KPiANCj4gSGkgRGhydXYsDQo+IA0KPiA+IEZyb206IERocnV2IERob2R5 LCBNYXkgOSwgMjAxOSAxMjowMyBBTQ0KPiA+DQo+ID4gSGkgRXJpYywNCj4gPg0KPiA+IFRoYW5r cyBmb3IgdGhlIHVwZGF0ZS4gSSBzZWUgb25lIG1pbm9yIGNvbW1lbnQgdGhhdCBpcyBub3QgaGFu ZGxlZC4NCj4gPiBNYXliZSB5b3UgbWlzc2VkIGl0PyBPciB5b3UgZGlzYWdyZWUsIHRoYXQgc29t ZSBtb3JlIHRleHQgaXMgcmVxdWlyZWQ/DQo+ID4NCj4gPiA+IE1pbm9yIElzc3VlczoNCj4gPiA+ IC0tLS0tLS0tLS0tLS0NCj4gPiA+ICgxKSBBYnN0cmFjdCAmIEludHJvZHVjdGlvbiwgSXQgaXMg bm90IGNsZWFyIHdoYXQgZG9lcyB0aGUgJ2JpbmRpbmcnDQo+ID4gPiBtZWFuIGFuZCB3aG8gYXJl IHRoZSBwYXJ0aWVzIHRvIHRoaXMgYmluZGluZz8gSWYgdGhpcyBpcyB0aGUNCj4gPiA+IGRvY3Vt ZW50IHRoYXQNCj4gPiBtZW50aW9ucyAnYmluZGluZycNCj4gPiA+IGZpcnN0LCBzbyBwbGVhc2Ug YWRkIHNvbWUgbW9yZSBjbGFyaWZ5aW5nIHRleHQuDQo+IA0KPiBUaGlzIGlzIG5vdCB0aGUgZmly c3QgZG9jdW1lbnQgd2hpY2ggbWVudGlvbnMgJ2JpbmRpbmcnICBmaXJzdC4gIFRoZQ0KPiBkb2N1 bWVudCB3aGljaCBkb2VzIHRoaXMgZmlyc3QgaXMgZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmli ZWQtDQo+IG5vdGlmaWNhdGlvbnMuICAgDQpbW0RocnV2IERob2R5XV0gZHJhZnQtaWV0Zi1uZXRj b25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyBzYXlzIHRoaXMgaW4gdGhlIEludHJvZHVjdGlv biAtIA0KDQogICBXaGlsZSB0aGUgZnVuY3Rpb25hbGl0eSBkZWZpbmVkIGluIHRoaXMgZG9jdW1l bnQgaXMgdHJhbnNwb3J0LQ0KICAgYWdub3N0aWMsIHRyYW5zcG9ydHMgbGlrZSBORVRDT05GIFtS RkM2MjQxXSBvciBSRVNUQ09ORiBbUkZDODA0MF0gY2FuDQogICBiZSB1c2VkIHRvIGNvbmZpZ3Vy ZSBvciBkeW5hbWljYWxseSBzaWduYWwgc3Vic2NyaXB0aW9ucywgYW5kIHRoZXJlDQogICBhcmUg YmluZGluZ3MgZGVmaW5lZCBmb3Igc3Vic2NyaWJlZCBldmVudCByZWNvcmQgZGVsaXZlcnkgZm9y IE5FVENPTkYNCiAgIHdpdGhpbiBbSS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50 LW5vdGlmaWNhdGlvbnNdLCBhbmQgZm9yDQogICBSRVNUQ09ORiB3aXRoaW4gW0ktRC5kcmFmdC1p ZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWZdLg0KDQpJIHRoaW5rIHRoaXMgaXMgb25seSB0aW1l IGJpbmRpbmcgaXMgdXNlZCBpbiB0aGlzIGNvbnRleHQuIA0KQW5kIG5vdyB0aGlzIEktRCBzYXlz IC0gDQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBiaW5kaW5nIGZvciBldmVudHMgc3Ry ZWFtZWQgb3ZlciB0aGUgTkVUQ09ORg0KICAgcHJvdG9jb2wgW1JGQzYyNDFdIGZvciBkeW5hbWlj IHN1YnNjcmlwdGlvbnMgYXMgZGVmaW5lZCBpbg0KICAgW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYt c3Vic2NyaWJlZC1ub3RpZmljYXRpb25zXS4NCg0KQW5kIHlvdSBkb27igJl0IHVzZSB0aGlzIHRl cm0gZXZlciBhZ2Fpbi4gDQoNClRvIG1lIHRoaXMgaXMgYml0IGNpcmN1bGFyIGFuZCB0aGUgdGVy bSBiaW5kaW5nIGlzIHVzZWQgbG9vc2VseS4gQW5kIHRodXMgSSBmbGFnZ2VkIGl0LiBJIHdpbGwg bGV0IHlvdSBhbmQgS2VudCBkZWNpZGUgdGhlIHJpZ2h0IGFwcHJvYWNoLiANCg0KVGhhbmtzISAN CkRocnV2DQoNCg0KPiBJbiB0aGUgYWJzdHJhY3Qgb2YgdGhpcyBkb2N1bWVudCwgdGhhdCBkcmFm dCBpcyBub3QNCj4gZXhwbGljaXRseSBsaXN0ZWQgYnkgcmVmZXJlbmNlIChhcyBJIHVuZGVyc3Rv b2Qgd2UgYXJlIG5vdCBzdXBwb3NlZCB0byB1c2UNCj4gcmVmZXJlbmNlcyBpbiBhYnN0cmFjdHMp LiAgQnV0IGl0IGlzIGxpc3RlZCBpbiB0aGUgSW50cm9kdWN0aW9uLg0KPiANCj4gVG8gbWFrZSB0 aGlzIGNsZWFyZXIgZm9yIHlvdSBpbiB0aGlzIGRvY3VtZW50LCBwZXJoYXBzICJ0cmFuc3BvcnQg YmluZGluZyINCj4gaW5zdGVhZCBvZiAiYmluZGluZyI/ICAgSSByZWFsbHkgZG9uJ3QgaGF2ZSBt YW55IGFsdGVybmF0aXZlcyBJIGNhbiB0aGluaw0KPiBvZiB3aGljaCBhbHNvIGtlZXBzIHRoZSB0 ZXh0IGJyaWVmLiAgIFRoaXMgcGFydGljdWxhciB0ZXh0IGhhcyBiZWVuDQo+IGZyZXF1ZW50bHkg dHdlYWtlZCBpbiB0aGUgcGFzdC4NCj4gDQo+IFRoYW5rcy4NCj4gRXJpYw0KPiANCj4gDQo+ID4g VGhhbmtzIQ0KPiA+IERocnV2Pg0KPiA+IE9uIFdlZCwgTWF5IDgsIDIwMTkgYXQgOToxNCBQTSBF cmljIFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPiB3cm90ZToNCj4gPiA+DQo+ID4gPiBV cGRhdGUgcG9zdGVkIGFzIC12MjAuICAgV2l0aCB0aGUgY29ycmVzcG9uZGluZyBjaGFuZ2UgdG8g ZHJhZnQtaWV0Zi0NCj4gbmV0Y29uZi0NCj4gPiBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMgcG9z dGVkIGFzIC12MjUuDQo+ID4gPg0KPiA+ID4gRXJpYw0KPiA+ID4NCj4gPiA+ID4gRnJvbTogRGhy dXYgRGhvZHksIE1heSA4LCAyMDE5IDI6MjEgQU0NCj4gPiA+ID4NCj4gPiA+ID4gSGkgS2VudCwg RXJpYywNCj4gPiA+ID4NCj4gPiA+ID4gRmluZSB3aXRoIG1lIQ0KPiA+ID4gPg0KPiA+ID4gPiBU aGFua3MhDQo+ID4gPiA+IERocnV2DQo+ID4gPiA+DQo+ID4gPiA+IE9uIFdlZCwgTWF5IDgsIDIw MTkgYXQgMzoxOSBBTSBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+DQo+ID4gd3Jv dGU6DQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPGVyaWM+IEJh c2VkIG9uIG15IHJlYWRpbmcgb2YgeW91ciBwcm9jZXNzIHN1Z2dlc3Rpb25zIEtlbnQsIEkNCj4g PiA+ID4gPiBsaWtlIGJlc3QgdGhlDQo+ID4gPiA+IOKAnG1lbnRpb27igJ0gYXBwcm9hY2ggd2hp Y2ggeW91IHVzZWQgZm9yIFJGQy04MDcxLCBTZWN0aW9uIDEuNC4NCj4gPiA+ID4gPg0KPiA+ID4g PiA+IFdoYXQgSSB0aGluayBjb3VsZCBiZSBkb25lIHRvIGNvdmVyIHRoaXMgaXM6DQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiAoQSkgIFJlbW92ZSBTZWN0aW9uIDExOiBOb3RlcyB0byB0aGUgUkZDIEVk aXRvcg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gKEIpICBQZXIgS2VudOKAmXMgZGVzaXJlIHRvIGFs c28gY292ZXINCj4gPiA+ID4gPiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYsIHBs YWNlIHRoZQ0KPiA+ID4gPiBmb2xsb3dpbmcgc3RhdGVtZW50IGludG8NCj4gPiA+ID4gZHJhZnQt aWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucw0KPiA+ID4gPiBkaXJlY3RseSBh ZnRlciBGaWd1cmUgMTANCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFtSRkMtNTI3N10gU2VjdGlvbiAy LjIuMSBzdGF0ZXMgdGhhdCBhIG5vdGlmaWNhdGlvbiBtZXNzYWdlIGlzDQo+ID4gPiA+ID4gdG8g YmUgc2VudCB0byBhDQo+ID4gPiA+IHN1YnNjcmliZXIgd2hpY2ggaW5pdGlhdGVkIGEgImNyZWF0 ZS1zdWJzY3JpcHRpb24iLiAgIFdpdGggdGhpcw0KPiBzcGVjaWZpY2F0aW9uLA0KPiA+IHRoaXMN Cj4gPiA+ID4gUkZDLTUyNzcgc3RhdGVtZW50IHNob3VsZCBiZSBtb3JlIGJyb2FkbHkgaW50ZXJw cmV0ZWQgdG8gbWVhbiB0aGF0DQo+ID4gPiA+IG5vdGlmaWNhdGlvbiBtZXNzYWdlcyBjYW4gYWxz byBiZSBzZW50IHRvIGEgc3Vic2NyaWJlciB3aGljaA0KPiA+ID4gPiBpbml0aWF0ZWQgYW4gImVz dGFibGlzaC1zdWJzY3JpcHRpb24iLCBvciBhIGNvbmZpZ3VyZWQgcmVjZWl2ZXINCj4gPiA+ID4g d2hpY2ggaGFzIGJlZW4gc2VudCBhIOKAnHN1YnNjcmlwdGlvbi1zdGFydGVk4oCdLg0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gRG9lcyB0aGlzIHdvcmsgZm9yIGJvdGggb2YgeW91Pw0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBXb3JrcyBmb3IgbWUuDQo+ID4gPiA+ID4NCj4gPiA+ID4g Pg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhlIGlzc3VlIGlzbid0IGNvbnNpc3RlbmN5IHNvIG11 Y2ggYXMgbWVldGluZyBleHBlY3RhdGlvbnMsIHBlcg0KPiA+ID4gPiA+IGB4bWwycmZjYCwgdGhl DQo+ID4gPiA+IGRvY3VtZW50IHNob3VsZCBoYXZlIHNvbWV0aGluZyBsaWtlIHRoZSBmb2xsb3dp bmcgaW4gdGhlDQo+ID4gPiA+IFJlZmVyZW5jZXMgc2VjdGlvbiwgd2hpY2ggdGhlbiBhdXRvLWV4 cGFuZHMgdG8gdGhlIGNvcnJlY3QNCj4gPiA+ID4gcmVmZXJlbmNlIHRleHQsIGFzIHdlbGwgYXMg ZGVmaW5pbmcgdGhlIGFuY2hvciAiSS1ELmlldGYtbmV0Y29uZi0NCj4gc3Vic2NyaWJlZC1ub3Rp ZmljYXRpb25zIjoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgICAgICAgPD9yZmMNCj4gPiA+ID4g PiBpbmNsdWRlPSJyZWZlcmVuY2UuSS1ELmlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNh dGlvbnMiPz4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IDxFcmljPiBUaGF0IGRlZmluaXRlbHkgbWFr ZXMgdGhpbmdzIGVhc2llciB0aGFuIHdoYXQgSSBoYXZlIGJlZW4NCj4gPiA+ID4gPiBkb2luZy4g IEkgYW0NCj4gPiA+ID4gaGl0dGluZyBhbiB4bWwycmZjIGVycm9yIHRyeWluZyB0aGlzIHJpZ2h0 IG5vdywgYnV0IEkgd2lsbCBnZXQgdGhlcmUuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4g PiA+IFllcywgaXQgd2FzIGFuIGV5ZS1vcGVuZXIgd2hlbiBJIGZpZ3VyZWQgaXQgb3V0LiAgIEJl IGF3YXJlIHRoYXQsDQo+IHRob3VnaA0KPiA+IHNvbWUNCj4gPiA+ID4gZXh0ZXJuYWwgc291cmNl cyAoZS5nLiwgSVRVIHN0YW5kYXJkcykgYXJlIHN1cHBvcnRlZCwgbWFueSBhcmUNCj4gPiA+ID4g bm90LCBhbmQgc28gaGFuZC0gY29kaW5nIHRoZSA8cmVmZXJlbmNlPiBpcyBzdGlsbCBzb21ldGlt ZXMNCj4gcmVxdWlyZWQuLi4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gS2VudCAv LyBzaGVwaGVyZA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0K From nobody Fri May 10 02:20:45 2019 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 720181200F9; Fri, 10 May 2019 02:20:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adrian Farrel via Datatracker To: Cc: grow@ietf.org, ietf@ietf.org, draft-ietf-grow-wkc-behavior.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adrian Farrel Message-ID: <155748003641.2996.7455035161017233072@ietfa.amsl.com> Date: Fri, 10 May 2019 02:20:36 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-grow-wkc-behavior-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 09:20:37 -0000 Reviewer: Adrian Farrel Review result: Has Issues Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-grow-wkc-behavior-03.txt Reviewer: Adrian Farrel Review Date: 2019-05-09 IETF LC End Date: 2019-05-13 Intended Status: Proposed Standard Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Thanks for this document which is short and simple to read. I thought that the main (most substantive and actionble) message is actually hidden as the last paragraph of Section 6: Network operators are encouraged to limit their use of the "set" directive (within reason), to improve the readability of their configurations and hopefully to achieve behavioral consistency across platforms. That message could be placed more prominently and so increase the value of the document. ==Minor Issues== In section 4 you have some inconsistent language in describing how different implementations behave. Sometime you talk about removing "all received communities" and sometimes about "all communities". This appears to imply a difference. Similarly, sometimes you have "all received communities, Well-Known or otherwise" and sometimes all received communities". I suggest it may help clarify behaviors if you carefully use identical language for identical behavior. --- I am confused by the wording in Section 4.1. The IANA registry is purely a list of Well-Known Communities. It makes no statement about how those Communities are supposed to be handled. I think that the issue you raise is not hat IOS XR has a list of well-known communities that differs from that in the registry. I think the issue you raise is that IOS XR's "set community" command does not act uniformly on all well-known communities. It looks to me that you have already made this point in Table 1, and if you wanted to you could strengthen the point in text there. But I think that bringing IANA into it and making it appear that IOS XR has a divergence from the registry is misleading. --- Section 5 makes a good and firm point, but... :-( "Care should be taken" is a doubly ambiguous statement: - Care should be taken by whom? Do you mean care by protocol specifiers, (so this is a directive to other working groups), or do you mean care by implementers? - What care are you advising, specifically? For specifications it might be to state how the new community attribute is to be handled. For implementations it might be to ensure that the new community attribute is handled in a specific way. Specifically to conform with the statement in section 6 that.. Vendors SHOULD clearly document the behavior of "set" directive in their implementations. ==Nits== You should move the 2119 boilerplate down to its own section (1.1 would work) to be consistent with the current RFC Editor style guide. Also, you really should use the more recent boilerplate that looks like: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. --- You have some inconsistency between "Well-Known" and "well-known". ==Pedant-alert== Abstract has Well-Known BGP Communities are manipulated inconsistently by current implementations. I presume you mean that there is inconsistency between how different implementations manipulate BGP communities, not that individual implementations are inconsistent in how they manipulate BGP communities. ==Questions== Does (or might) error handling of Community Attributes differ between implementations? I raise this specifically because RFC 7606 section 7.8 calls out two processing steps. From nobody Fri May 10 11:39:21 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E0712003E; Fri, 10 May 2019 11:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 GgjODe7fn2rh; Fri, 10 May 2019 11:39:08 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C698712000E; Fri, 10 May 2019 11:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10194; q=dns/txt; s=iport; t=1557513548; x=1558723148; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9SF5HdEyYvyBYH1mpU7EAjP/JYYW3nzLusiedPUdqh0=; b=RL0Z7zhClOYIJlTPLjTv1ECTeJpkc0vQ4FMbhvC9gnnxOf2Mt3sHMOEU IPjwOTcAIBhuvRtXOsqAwaV+EAKQ8aPAY5jqt2qhPNutCYT6Inru1mKuI sj6RViRjuNspR10kH0peCQovKBG443iObmGsbLl+9DViKcXIKJgFMTsi/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAADUxNVc/4sNJK1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYFmKoE9MCgKhAeIHI0DiT+PFIF7CQEBAQwBAS8BAYR?= =?us-ascii?q?AAheBdCM0CQ4BAwEBBAEBAgEEbSiFSgEBAQMBIxFDAgUHBAIBCBEEAQEBAgI?= =?us-ascii?q?JGgMCAgIfERQBCAgCBAENBQiCT0uBawMOD6xlgS+IAA2CI4ELJwGLTheBQD+?= =?us-ascii?q?EIz6CGoIxM4JQglgEixsDgg8smT45CQKCCYomhF6DTSOCE4ZLBY0GgyCJEYE?= =?us-ascii?q?ihwCMYQIRFYEwHziBV3AVgyeQUUExj1iBIQEB?= X-IronPort-AV: E=Sophos;i="5.60,454,1549929600"; d="scan'208";a="271621247" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 May 2019 18:39:06 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x4AId6AE028349 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 May 2019 18:39:06 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 10 May 2019 14:39:05 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Fri, 10 May 2019 14:39:05 -0400 From: "Eric Voit (evoit)" To: Dhruv Dhody , Dhruv Dhody , Kent Watsen CC: "rtg-dir@ietf.org" , "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" , "" Thread-Topic: RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 Thread-Index: AQHU/xC8WbWTXSPvekeZmlnK7/xOtqZU7OSwgAI1bICACP37sIAAYi6AgACOyoCAAFnN8IABEe2AgADU50CAALPMAIAAqWnw Date: Fri, 10 May 2019 18:39:05 +0000 Message-ID: <5e89a05b0eb6492abee9cedfe3134031@XCH-RTP-013.cisco.com> References: <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com> <23CE718903A838468A8B325B80962F9B8DA56A70@BLREML503-MBX.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B8DA56A70@BLREML503-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.232] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 18:39:11 -0000 SGkgRGhydXYsDQpIaSBLZW50LA0KDQo+IEZyb206IERocnV2IERob2R5LCBNYXkgOSwgMjAxOSAx MToyOCBQTQ0KPiANCj4gSGkgRXJpYywNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPiBGcm9tOiBFcmljIFZvaXQgKGV2b2l0KSBbbWFpbHRvOmV2b2l0QGNpc2NvLmNvbV0N Cj4gPiBTZW50OiAxMCBNYXkgMjAxOSAwMjoxOA0KPiA+IFRvOiBEaHJ1diBEaG9keSA8ZGhydXYu aWV0ZkBnbWFpbC5jb20+DQo+ID4gQ2M6IEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5l dD47IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtDQo+ID4gbmV0Y29uZi1uZXRjb25mLWV2 ZW50LW5vdGlmaWNhdGlvbnMuYWxsQGlldGYub3JnOyBuZXRjb25mQGlldGYub3JnOw0KPiA+IERo cnV2IERob2R5IDxkaHJ1di5kaG9keUBodWF3ZWkuY29tPjsgPHJ0Zy1hZHNAaWV0Zi5vcmc+DQo+ ID4gPHJ0Zy1hZHNAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUkU6IFJ0Z0RpciByZXZpZXc6IGRy YWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50LQ0KPiA+IG5vdGlmaWNhdGlvbnMtMTcNCj4g Pg0KPiA+IEhpIERocnV2LA0KPiA+DQo+ID4gPiBGcm9tOiBEaHJ1diBEaG9keSwgTWF5IDksIDIw MTkgMTI6MDMgQU0NCj4gPiA+DQo+ID4gPiBIaSBFcmljLA0KPiA+ID4NCj4gPiA+IFRoYW5rcyBm b3IgdGhlIHVwZGF0ZS4gSSBzZWUgb25lIG1pbm9yIGNvbW1lbnQgdGhhdCBpcyBub3QgaGFuZGxl ZC4NCj4gPiA+IE1heWJlIHlvdSBtaXNzZWQgaXQ/IE9yIHlvdSBkaXNhZ3JlZSwgdGhhdCBzb21l IG1vcmUgdGV4dCBpcyByZXF1aXJlZD8NCj4gPiA+DQo+ID4gPiA+IE1pbm9yIElzc3VlczoNCj4g PiA+ID4gLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiAoMSkgQWJzdHJhY3QgJiBJbnRyb2R1Y3Rpb24s IEl0IGlzIG5vdCBjbGVhciB3aGF0IGRvZXMgdGhlICdiaW5kaW5nJw0KPiA+ID4gPiBtZWFuIGFu ZCB3aG8gYXJlIHRoZSBwYXJ0aWVzIHRvIHRoaXMgYmluZGluZz8gSWYgdGhpcyBpcyB0aGUNCj4g PiA+ID4gZG9jdW1lbnQgdGhhdA0KPiA+ID4gbWVudGlvbnMgJ2JpbmRpbmcnDQo+ID4gPiA+IGZp cnN0LCBzbyBwbGVhc2UgYWRkIHNvbWUgbW9yZSBjbGFyaWZ5aW5nIHRleHQuDQo+ID4NCj4gPiBU aGlzIGlzIG5vdCB0aGUgZmlyc3QgZG9jdW1lbnQgd2hpY2ggbWVudGlvbnMgJ2JpbmRpbmcnICBm aXJzdC4gIFRoZQ0KPiA+IGRvY3VtZW50IHdoaWNoIGRvZXMgdGhpcyBmaXJzdCBpcyBkcmFmdC1p ZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC0NCj4gPiBub3RpZmljYXRpb25zLg0KPiBbW0RocnV2IERo b2R5XV0gZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyBzYXlzIHRo aXMgaW4gdGhlDQo+IEludHJvZHVjdGlvbiAtDQo+IA0KPiAgICBXaGlsZSB0aGUgZnVuY3Rpb25h bGl0eSBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgdHJhbnNwb3J0LQ0KPiAgICBhZ25vc3Rp YywgdHJhbnNwb3J0cyBsaWtlIE5FVENPTkYgW1JGQzYyNDFdIG9yIFJFU1RDT05GIFtSRkM4MDQw XSBjYW4NCj4gICAgYmUgdXNlZCB0byBjb25maWd1cmUgb3IgZHluYW1pY2FsbHkgc2lnbmFsIHN1 YnNjcmlwdGlvbnMsIGFuZCB0aGVyZQ0KPiAgICBhcmUgYmluZGluZ3MgZGVmaW5lZCBmb3Igc3Vi c2NyaWJlZCBldmVudCByZWNvcmQgZGVsaXZlcnkgZm9yIE5FVENPTkYNCj4gICAgd2l0aGluIFtJ LUQuZHJhZnQtaWV0Zi1uZXRjb25mLW5ldGNvbmYtZXZlbnQtbm90aWZpY2F0aW9uc10sIGFuZCBm b3INCj4gICAgUkVTVENPTkYgd2l0aGluIFtJLUQuZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25m LW5vdGlmXS4NCj4gDQo+IEkgdGhpbmsgdGhpcyBpcyBvbmx5IHRpbWUgYmluZGluZyBpcyB1c2Vk IGluIHRoaXMgY29udGV4dC4NCj4gQW5kIG5vdyB0aGlzIEktRCBzYXlzIC0NCj4gDQo+ICAgIFRo aXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBiaW5kaW5nIGZvciBldmVudHMgc3RyZWFtZWQgb3ZlciB0 aGUgTkVUQ09ORg0KPiAgICBwcm90b2NvbCBbUkZDNjI0MV0gZm9yIGR5bmFtaWMgc3Vic2NyaXB0 aW9ucyBhcyBkZWZpbmVkIGluDQo+ICAgIFtJLUQuZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmli ZWQtbm90aWZpY2F0aW9uc10uDQo+IA0KPiBBbmQgeW91IGRvbuKAmXQgdXNlIHRoaXMgdGVybSBl dmVyIGFnYWluLg0KPiANCj4gVG8gbWUgdGhpcyBpcyBiaXQgY2lyY3VsYXIgYW5kIHRoZSB0ZXJt IGJpbmRpbmcgaXMgdXNlZCBsb29zZWx5LiBBbmQgdGh1cyBJIGZsYWdnZWQNCj4gaXQuIEkgd2ls bCBsZXQgeW91IGFuZCBLZW50IGRlY2lkZSB0aGUgcmlnaHQgYXBwcm9hY2guDQoNCkkgcmVhbGx5 IGFtIG9rIHdpdGggbWFueSBvcHRpb25zIGhlcmU6DQogKGEpICBrZWVwIHRoZSBjdXJyZW50IHRl eHQuICANCiAoYikgIHVzZSBwcmV2aW91cyB2ZXJzaW9ucyBvZiB0aGUgYWJzdHJhY3QuICANCiAo YykgIHJlcGxhY2UgdGhlIHdvcmQgYmluZGluZyB3aXRoIHNvbWUgb3RoZXIgdGV4dC4gICANCg0K R2V0dGluZyB0aGUgcmlnaHQgd29yZHMgaGVyZSBuYWlsZWQgZG93biBoYXNuJ3QgYmVlbiBmcm9t IGxhY2sgb2YgZWZmb3J0LiAgVG8gZ2l2ZSB5b3UgYW4gaWRlYSwgYmVsb3cgYXJlIGZvdXIgcHJl dmlvdXMgYXR0ZW1wdHMgYXQgdGhlIGFic3RyYWN0Lg0KDQpGcm9tIC12NQ0KDQogICBUaGlzIGRv Y3VtZW50IGRlZmluZXMgaG93IHRvIHRyYW5zcG9ydCBuZXR3b3JrIHN1YnNjcmlwdGlvbnMgYW5k DQogICBldmVudCBtZXNzYWdlcyBvbiB0b3Agb2YgdGhlIE5ldHdvcmsgQ29uZmlndXJhdGlvbiBw cm90b2NvbA0KICAgKE5FVENPTkYpLiAgVGhpcyBpbmNsdWRlcyB0aGUgZnVsbCBzZXQgb2YgUlBD cywgc3Vic2NyaXB0aW9uIHN0YXRlDQogICBjaGFuZ2VzLCBhbmQgc3Vic2NyaWJlZCBjb250ZW50 IG5lZWRpbmcgYXN5bmNocm9ub3VzIGRlbGl2ZXJ5Lg0KDQoNCkZyb20gLXY2IA0KIA0KICAgVGhp cyBkb2N1bWVudCBwcm92aWRlcyBhIE5FVENPTkYgYmluZGluZyBmb3INCiAgIFtJLUQuZHJhZnQt aWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uc10uICBJbmNsdWRlZCBhcmU6DQoN CiAgIG8gIFRyYW5zcG9ydCBtYXBwaW5ncyBmb3Igc3Vic2NyaXB0aW9uIFJQQ3MsIHN0YXRlIGNo YW5nZQ0KICAgICAgbm90aWZpY2F0aW9ucywgYW5kIG5vdGlmaWNhdGlvbiBtZXNzYWdlcw0KDQog ICBvICBGdW5jdGlvbmFsaXR5IHdoaWNoIG11c3QgYmUgc3VwcG9ydGVkIHdpdGggTkVUQ09ORg0K DQogICBvICBFeGFtcGxlcyBpbiBhcHBlbmRpY2VzDQoNCg0KRnJvbSAtdjcNCg0KICAgVGhpcyBk b2N1bWVudCBwcm92aWRlcyBhIE5FVENPTkYgYmluZGluZyBmb3INCiAgIFtJLUQuZHJhZnQtaWV0 Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uc10gYW5kDQogICBbSS1ELmlldGYtbmV0 Y29uZi15YW5nLXB1c2hdLiAgSW5jbHVkZWQgYXJlOg0KDQogICBvICB0cmFuc3BvcnQgbWFwcGlu Z3MgZm9yIHN1YnNjcmlwdGlvbiBSUENzLCBzdGF0ZSBjaGFuZ2UNCiAgICAgIG5vdGlmaWNhdGlv bnMsIGFuZCBub3RpZmljYXRpb24gbWVzc2FnZXMsDQogICBvICBmdW5jdGlvbmFsIHJlcXVpcmVt ZW50cywgYW5kDQogICBvICBleGFtcGxlcw0KDQoNCkZyb20gLXY4DQoNCiAgIFRoaXMgZG9jdW1l bnQgcHJvdmlkZXMgYSBORVRDT05GIGJpbmRpbmcgdG8gc3Vic2NyaWJlZCBub3RpZmljYXRpb25z DQogICBhbmQgdG8gWUFORyBwdXNoLg0KDQoNCkhvbmVzdGx5IEkgbGlrZSB0aGUgdjUgdmVyc2lv bi4gICBCdXQgcHJldmlvdXMgcmV2aWV3ZXJzIGhhdmUgaW5jcmVtZW50YWxseSBkcml2ZW4gdGhp bmdzIHRvIHRoZSBjdXJyZW50IHRleHQuICAgIElmIEtlbnQgeW91IHByZWZlciBzb21ldGhpbmcg b3RoZXIgdGhhbiB0aGUgY3VycmVudCB0ZXh0LCBsZXQgbWUga25vdyB3aGF0IGl0IGlzLiAgSSBh bSBzdXJlIEkgd2lsbCBsaWtlIGl0IHRvby4NCg0KRXJpYyANCg0KDQo+IFRoYW5rcyENCj4gRGhy dXYNCj4gDQo+IA0KPiA+IEluIHRoZSBhYnN0cmFjdCBvZiB0aGlzIGRvY3VtZW50LCB0aGF0IGRy YWZ0IGlzIG5vdCBleHBsaWNpdGx5IGxpc3RlZA0KPiA+IGJ5IHJlZmVyZW5jZSAoYXMgSSB1bmRl cnN0b29kIHdlIGFyZSBub3Qgc3VwcG9zZWQgdG8gdXNlIHJlZmVyZW5jZXMgaW4NCj4gPiBhYnN0 cmFjdHMpLiAgQnV0IGl0IGlzIGxpc3RlZCBpbiB0aGUgSW50cm9kdWN0aW9uLg0KPiA+DQo+ID4g VG8gbWFrZSB0aGlzIGNsZWFyZXIgZm9yIHlvdSBpbiB0aGlzIGRvY3VtZW50LCBwZXJoYXBzICJ0 cmFuc3BvcnQgYmluZGluZyINCj4gPiBpbnN0ZWFkIG9mICJiaW5kaW5nIj8gICBJIHJlYWxseSBk b24ndCBoYXZlIG1hbnkgYWx0ZXJuYXRpdmVzIEkgY2FuIHRoaW5rDQo+ID4gb2Ygd2hpY2ggYWxz byBrZWVwcyB0aGUgdGV4dCBicmllZi4gICBUaGlzIHBhcnRpY3VsYXIgdGV4dCBoYXMgYmVlbg0K PiA+IGZyZXF1ZW50bHkgdHdlYWtlZCBpbiB0aGUgcGFzdC4NCj4gPg0KPiA+IFRoYW5rcy4NCj4g PiBFcmljDQo+ID4NCj4gPg0KPiA+ID4gVGhhbmtzIQ0KPiA+ID4gRGhydXY+DQo+ID4gPiBPbiBX ZWQsIE1heSA4LCAyMDE5IGF0IDk6MTQgUE0gRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2Nv LmNvbT4gd3JvdGU6DQo+ID4gPiA+DQo+ID4gPiA+IFVwZGF0ZSBwb3N0ZWQgYXMgLXYyMC4gICBX aXRoIHRoZSBjb3JyZXNwb25kaW5nIGNoYW5nZSB0byBkcmFmdC1pZXRmLQ0KPiA+IG5ldGNvbmYt DQo+ID4gPiBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMgcG9zdGVkIGFzIC12MjUuDQo+ID4gPiA+ DQo+ID4gPiA+IEVyaWMNCj4gPiA+ID4NCj4gPiA+ID4gPiBGcm9tOiBEaHJ1diBEaG9keSwgTWF5 IDgsIDIwMTkgMjoyMSBBTQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSGkgS2VudCwgRXJpYywNCj4g PiA+ID4gPg0KPiA+ID4gPiA+IEZpbmUgd2l0aCBtZSENCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRo YW5rcyENCj4gPiA+ID4gPiBEaHJ1dg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gT24gV2VkLCBNYXkg OCwgMjAxOSBhdCAzOjE5IEFNIEtlbnQgV2F0c2VuDQo+ID4gPiA+ID4gPGtlbnQraWV0ZkB3YXRz ZW4ubmV0Pg0KPiA+ID4gd3JvdGU6DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiA8ZXJpYz4gQmFzZWQgb24gbXkgcmVhZGluZyBvZiB5b3VyIHByb2Nl c3Mgc3VnZ2VzdGlvbnMgS2VudCwgSQ0KPiA+ID4gPiA+ID4gbGlrZSBiZXN0IHRoZQ0KPiA+ID4g PiA+IOKAnG1lbnRpb27igJ0gYXBwcm9hY2ggd2hpY2ggeW91IHVzZWQgZm9yIFJGQy04MDcxLCBT ZWN0aW9uIDEuNC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBXaGF0IEkgdGhpbmsgY291bGQg YmUgZG9uZSB0byBjb3ZlciB0aGlzIGlzOg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IChBKSAg UmVtb3ZlIFNlY3Rpb24gMTE6IE5vdGVzIHRvIHRoZSBSRkMgRWRpdG9yDQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gKEIpICBQZXIgS2VudOKAmXMgZGVzaXJlIHRvIGFsc28gY292ZXINCj4gPiA+ ID4gPiA+IGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZiwgcGxhY2UgdGhlDQo+ID4g PiA+ID4gZm9sbG93aW5nIHN0YXRlbWVudCBpbnRvDQo+ID4gPiA+ID4gZHJhZnQtaWV0Zi1uZXRj b25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucw0KPiA+ID4gPiA+IGRpcmVjdGx5IGFmdGVyIEZp Z3VyZSAxMA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFtSRkMtNTI3N10gU2VjdGlvbiAyLjIu MSBzdGF0ZXMgdGhhdCBhIG5vdGlmaWNhdGlvbiBtZXNzYWdlIGlzDQo+ID4gPiA+ID4gPiB0byBi ZSBzZW50IHRvIGENCj4gPiA+ID4gPiBzdWJzY3JpYmVyIHdoaWNoIGluaXRpYXRlZCBhICJjcmVh dGUtc3Vic2NyaXB0aW9uIi4gICBXaXRoIHRoaXMNCj4gPiBzcGVjaWZpY2F0aW9uLA0KPiA+ID4g dGhpcw0KPiA+ID4gPiA+IFJGQy01Mjc3IHN0YXRlbWVudCBzaG91bGQgYmUgbW9yZSBicm9hZGx5 IGludGVycHJldGVkIHRvIG1lYW4NCj4gPiA+ID4gPiB0aGF0IG5vdGlmaWNhdGlvbiBtZXNzYWdl cyBjYW4gYWxzbyBiZSBzZW50IHRvIGEgc3Vic2NyaWJlcg0KPiA+ID4gPiA+IHdoaWNoIGluaXRp YXRlZCBhbiAiZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiIsIG9yIGEgY29uZmlndXJlZA0KPiA+ID4g PiA+IHJlY2VpdmVyIHdoaWNoIGhhcyBiZWVuIHNlbnQgYSDigJxzdWJzY3JpcHRpb24tc3RhcnRl ZOKAnS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBEb2VzIHRoaXMgd29yayBmb3IgYm90aCBv ZiB5b3U/DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFdvcmtzIGZvciBt ZS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFRo ZSBpc3N1ZSBpc24ndCBjb25zaXN0ZW5jeSBzbyBtdWNoIGFzIG1lZXRpbmcgZXhwZWN0YXRpb25z LA0KPiA+ID4gPiA+ID4gcGVyIGB4bWwycmZjYCwgdGhlDQo+ID4gPiA+ID4gZG9jdW1lbnQgc2hv dWxkIGhhdmUgc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZyBpbiB0aGUNCj4gPiA+ID4gPiBS ZWZlcmVuY2VzIHNlY3Rpb24sIHdoaWNoIHRoZW4gYXV0by1leHBhbmRzIHRvIHRoZSBjb3JyZWN0 DQo+ID4gPiA+ID4gcmVmZXJlbmNlIHRleHQsIGFzIHdlbGwgYXMgZGVmaW5pbmcgdGhlIGFuY2hv cg0KPiA+ID4gPiA+ICJJLUQuaWV0Zi1uZXRjb25mLQ0KPiA+IHN1YnNjcmliZWQtbm90aWZpY2F0 aW9ucyI6DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gICAgICAgICA8P3JmYw0KPiA+ID4gPiA+ ID4gaW5jbHVkZT0icmVmZXJlbmNlLkktRC5pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmlj YXRpb25zIj8NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA8RXJpYz4g VGhhdCBkZWZpbml0ZWx5IG1ha2VzIHRoaW5ncyBlYXNpZXIgdGhhbiB3aGF0IEkgaGF2ZQ0KPiA+ ID4gPiA+ID4gYmVlbiBkb2luZy4gIEkgYW0NCj4gPiA+ID4gPiBoaXR0aW5nIGFuIHhtbDJyZmMg ZXJyb3IgdHJ5aW5nIHRoaXMgcmlnaHQgbm93LCBidXQgSSB3aWxsIGdldCB0aGVyZS4NCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gWWVzLCBpdCB3YXMgYW4gZXllLW9wZW5l ciB3aGVuIEkgZmlndXJlZCBpdCBvdXQuICAgQmUgYXdhcmUgdGhhdCwNCj4gPiB0aG91Z2gNCj4g PiA+IHNvbWUNCj4gPiA+ID4gPiBleHRlcm5hbCBzb3VyY2VzIChlLmcuLCBJVFUgc3RhbmRhcmRz KSBhcmUgc3VwcG9ydGVkLCBtYW55IGFyZQ0KPiA+ID4gPiA+IG5vdCwgYW5kIHNvIGhhbmQtIGNv ZGluZyB0aGUgPHJlZmVyZW5jZT4gaXMgc3RpbGwgc29tZXRpbWVzDQo+ID4gcmVxdWlyZWQuLi4N Cj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gS2VudCAvLyBzaGVwaGVyZA0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0K From nobody Mon May 13 12:25:19 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7361200C5 for ; Mon, 13 May 2019 12:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielking-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qAyFkiUfShf for ; Mon, 13 May 2019 12:25:07 -0700 (PDT) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 9F89F120228 for ; Mon, 13 May 2019 12:25:06 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id r4so16535429wro.10 for ; Mon, 13 May 2019 12:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20150623.gappssmtp.com; s=20150623; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Z1rZOxaR8m4wE3Ne1BsELybquWnG7337Cuboy1A2ZpY=; b=u/KY4kX6B6FryTMtI/pNzX4Rg9rq/J/YLVLGnfpLsOjiywM+zfhOrlb/uk0adcwEWa oTtg/4pJyDCq3iFoNhYKOeC7PpvArzxpBtppulBG3a0RPPCFyzMjRrPhr9Fq2EHGt2tR VUcmBbTfc35ytqDq0a8I4iQJusO8t/Mt0wUk4KVceAKqHkJRpPKw03HUW8UkuphgdeYo pS9Yx/Ij/F6eUcyiwn8HCFy1QcU7Smu8XH0iwcYv3JzL6v4GXskgEE1fOEo9uTVu9aQ1 wdo89PJoSGcL1icy5mPk5PKD8rI1gNL+xqCwOB+4jpeqV7DhM18Q/d4ykIKShaqNfVVw I6hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Z1rZOxaR8m4wE3Ne1BsELybquWnG7337Cuboy1A2ZpY=; b=KDy5b3WO2e4c7xvsJwIZKCmB5/QluyfGBdLT6GBcc9QmnIr2POHQvlBbt8vbt2IBtp kcvq5LUEBqWCIUK5whvBF8PFza7RR8V4UTnhJ5SJf4dy9jtwHot47BaMTEz6ljoZlZro hfolKt+1UDMwG8OsZeuapCo/6nUFHeJ8wvyjeYQi9VslcJbRdYeCs/LOEHOZY56A1DUg 7z+z1dnV0JxLY6ZjjUyWgQkczFGyCe/RNepO1JHurrkwngyEiyDQYJE6nnrdUTUTqYOK JQRakQyWSRSjYPu7PAexApJECakbSuXVS1h+lTFx5mzHeRx01ukAZR5S1zz8YWCG6NSF 7Yzw== X-Gm-Message-State: APjAAAXI0JI0Z3sdl6d5G8jmHP78wkJlnoCxemEHWd5mhmU3nXZeN4lX eNyyIGwnjLb2X+W/aI6TF+gvH03i2q9sZA== X-Google-Smtp-Source: APXvYqylmLxI84MEgsxjCEU6/mThkHm+GeNNkmv6DRhkNh9F0ggsuUzQjVPclwhbOLd6uxYofKc0Yg== X-Received: by 2002:adf:d081:: with SMTP id y1mr18517719wrh.283.1557775504793; Mon, 13 May 2019 12:25:04 -0700 (PDT) Received: from CIPHER ([88.202.231.139]) by smtp.gmail.com with ESMTPSA id f81sm374609wmf.10.2019.05.13.12.25.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 May 2019 12:25:03 -0700 (PDT) Sender: Daniel King X-Google-Original-Sender: "Daniel King" From: To: "'Mike McBride'" , Cc: , , References: <155113646185.10637.8298004858075315120@ietfa.amsl.com> In-Reply-To: <155113646185.10637.8298004858075315120@ietfa.amsl.com> Date: Mon, 13 May 2019 20:25:02 +0100 Message-ID: <007801d509c1$90966090$b1c321b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG+ES6JhOVysTjiKqeoh3yJTvsHhaaXYCyg Content-Language: en-gb Archived-At: Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-pce-hierarchy-extensions-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2019 19:25:10 -0000 Thanks again Mike for all your thorough review, and valuable = comments/suggestions, and especially text changes!=20 All of these NITS have been squashed in our latest version (v11) which = will post once the IESG telechat is complete.=20 BR, Dan and the other authors.=20 -----Original Message----- From: Mike McBride =20 Sent: 25 February 2019 23:14 To: rtg-dir@ietf.org Cc: draft-ietf-pce-hierarchy-extensions.all@ietf.org; pce@ietf.org Subject: Rtgdir last call review of = draft-ietf-pce-hierarchy-extensions-09 Reviewer: Mike McBride Review result: Has Nits I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and sometimes on = special request. The purpose of the review is to provide assistance to the = Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF Last = Call comments that you receive, and strive to resolve them through discussion = or by updating the draft. Document: draft-ietf-pce-hierarchy-extensions-09 Reviewer: Mike McBride Review Date: 25 February 2019 IETF LC End Date: N/A (in preparation for IETF LC) Intended Status: Standards Track Summary: This document is near ready for publication. It has nits that should be considered prior to publication. Comments: Great job on the draft and congrats on near publication. It was a tad = difficult to follow certain areas of the document and I therefore offer = suggestions to improve the readability. Major issues: No major issues found. Minor Issues: No minor issues found. Nits for your consideration: 1. Page 4: Replace: A child PCE may be responsible for a single domain or multiple domains, = it is used to compute the intra-domain path based on its own domain topology information. With: A child PCE may be responsible for single or multiple domains and is = used to compute..." 2. Page 4: Replace: In addition, the parent PCE may be requested to provide only the = sequence of domains to a child PCE so that alternative inter-domain path computation procedures, including Per Domain (PD) [RFC5152] and Backwards Recursive = Path Computation (BRPC) [RFC5441] may be used. With: The parent PCE may be requested to provide only the sequence of domains = to a child PCE so that alternative inter-domain path computation procedures, including Per Domain (PD) [RFC5152] and Backwards Recursive Path = Computation (BRPC) [RFC5441], may be used. 3. Page 5: Replace: This could be done via With: Move formatting to the right to remain consistent in this section. Under "Learning". 4. Page 5: Replace: The hierarchical relationship model is described in [RFC6805]. It is = applicable to environments with small groups of domains where visibility from the = ingress LSRs is limited. As highlighted in [RFC7399] applying the hierarchical = PCE model to large groups of domains such as the Internet is not considered feasible or desirable. With: Move formatting to the right to remain consistent in this section. Under "Stateful". 5. Page 10: Replace: The Domain-ID TLV when used in the OPEN object, identify the domains = served by the PCE. With: Add a comma after TLV s/identify/identifies 6. Page 12: Replace: The usage of Domain-ID TLV carried in an OPEN object is used to indicate = a (list of) managed domains and is described in Section 3.3.1. This TLV = when carried in an RP object, indicates the destination domain ID. With: Use of commas. Comma after 'Domain-ID TLV' and 'object'. And after 'This = TLV'. 7. Page 12: Replace: If a Domain-id TLV is used in the RP object, and the destination is not actually in the indicated domain, then the parent PCE should respond = with a NO-PATH object and NO-PATH VECTOR TLV should be used, and a new bit = number is assigned to indicate "Destination not found in the indicated domain" = (see Section 3.7). With: End the sentence after the second 'used' and then start the new sentence = with 'And a new bit...' 8. Page 14: Replace: The domain count metric type of the METRIC object encodes the number of = domain crossed in the path. With: change the second 'domain' to 'domains' or maybe 'domain's'. 9. Page 14: Replace: A PCC or child PCE MAY use these metric in PCReq message for an = inter-domain path computation meeting the number of domain or border nodes crossing requirement. With: Change 'these' to 'the' 10. Page 15: Replace: The Parent PCE MAY use these metric in a PCRep message along with a = NO-PATH object in the case where the PCE cannot compute a path meeting this = constraint. With: change 'these' to 'the' or change to 'PCRep messages'. 11. Page 16: Replace: The child PCE MAY also report its list of domain IDs to the parent PCE = by specifying them in the Domain-ID TLVs in the OPEN object carried in the = Open message during the PCEP session initialization procedure. With: This is a tough sentence to follow. With the following punctuation = changes is the intention still correct?: "The child PCE MAY also report its list of = domain IDs, to the parent PCE, by specifying them in the Domain-ID TLVs in the = OPEN object. This object is carried in the OPEN message during the PCEP = session initialization procedure." 12. Page 16: Replace: When a specific child PCE sends a PCReq to a peer PCE that requires = parental activity and H-PCE capability flags TLV was not included in the session establishment procedure as described above, the peer PCE should send a = PCErr message to the child PCE and specify the error-type=3DTBD8 (H-PCE error) = and error-value=3D1 (H-PCE capability was not advertised) in the PCEP-ERROR = object. With: Again, a hard, and long, sentence to follow. I'm not certain if its the = child or peer PCE that is doing the requiring, I'll go with the peer. See if = this is still correct after adding some commas: "When a child PCE sends a PCReq = to a peer PCE, which requires parental activity and H-PCE capability flags = TLV but which were not included in the session establishment procedure described = above, the peer PCE should send a PCErr message to the child PCE and should = specify the error-type..." 13. Page 17: Replace: When a specific child PCE sends a PCReq to a peer PCE that requires = parental activity and the peer PCE does not want to act as the parent for it, the = peer PCE should send a PCErr message to the child PCE and specify the error-type=3DTBD8 (H-PCE error) and error-value=3D2 (Parent PCE = capability cannot be provided) in the PCEP-ERROR object. With: strategically placed commas for clarity: "When a specific child PCE sends a PCReq to a peer PCE, that requires = parental activity and the peer PCE does not want to act as the parent for it, the = peer PCE..." 14. Page 17: Replace: ERO With: first time ERO is being used in the document. Please call out Explicit = Route Object somewhere. 15. Page 17: Replace: o The parent PCE do not hear from a child PCE for a specified time; With: 'does not' instead of 'do not' that's it! ;-) I'm suggestion many changes but it'll go quick and make = it much more readable. thanks, mike From nobody Tue May 14 04:47:55 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0212B12023E; Tue, 14 May 2019 04:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 YqRHTGlxOHfu; Tue, 14 May 2019 04:47:43 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40136.outbound.protection.outlook.com [40.107.4.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6C512011D; Tue, 14 May 2019 04:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kwz28VGWEARLQp01ztODptTCgO8hcRfpGm7UyIv44kA=; b=jRn2JYF7qMrYFUPvltAoqCXq0H83TRtatQOGiKfshKB5CFpYZsJQY3vWa5thSt9es2WeqlYi1+jKYKF9PDlQDCwM+n+RcIycqTf1nKFC84x2lfT299XTLrR49owF5JqZ1uyffYPtIY/ar+1I69D2/5S3Hb9dIw2DMXEXNBz/fwU= Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB4573.eurprd07.prod.outlook.com (20.177.56.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.5; Tue, 14 May 2019 11:47:40 +0000 Received: from VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b]) by VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b%3]) with mapi id 15.20.1900.010; Tue, 14 May 2019 11:47:40 +0000 From: tom petch To: "Eric Voit (evoit)" , Dhruv Dhody , Kent Watsen CC: "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "rtg-dir@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 Thread-Index: AQHVCkrVRLH1NGoaRE+6tKjUhBK41g== Date: Tue, 14 May 2019 11:47:39 +0000 Message-ID: <058801d50a4a$4f3308e0$4001a8c0@gateway.2wire.net> References: <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com> <23CE718903A838468A8B325B80962F9B8DA56A70@BLREML503-MBX.china.huawei.com> <5e89a05b0eb6492abee9cedfe3134031@XCH-RTP-013.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0339.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:d::15) To VI1PR07MB3118.eurprd07.prod.outlook.com (2603:10a6:802:20::28) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.215.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dddd2f64-f8b4-4ee9-a425-08d6d861f76e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB4573; x-ms-traffictypediagnostic: VI1PR07MB4573: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0037FD6480 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(396003)(376002)(366004)(39860400002)(51444003)(51914003)(199004)(189003)(13464003)(53546011)(50226002)(3846002)(476003)(6512007)(110136005)(446003)(54906003)(102836004)(486006)(86362001)(14454004)(9686003)(8936002)(2906002)(81156014)(81166006)(66066001)(71200400001)(229853002)(52116002)(68736007)(6436002)(84392002)(76176011)(386003)(44736005)(81686011)(81816011)(6506007)(6486002)(316002)(61296003)(53936002)(25786009)(305945005)(1556002)(7736002)(4326008)(5660300002)(6116002)(14496001)(86152003)(186003)(99286004)(44716002)(26005)(62236002)(478600001)(14444005)(256004)(66446008)(8676002)(73956011)(66556008)(15650500001)(64756008)(66946007)(66476007)(4720700003)(6246003)(71190400001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4573; H:VI1PR07MB3118.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AheCw2HFrYWbrgbNSbvFmeUZ6hwivuyZF0f8Fr109tE138doL4JEypNM1CPQKL/EV7D0+Bf1EdZ9A+kywxixCAAhpLlVD/RLJvIG1tqaXzOj4ILJG15btcNJ/qm0EzMYLrtvbE3rxQDWP6HQVT3iVsuq1jcsabEPntZEobeLJ50+mtpW0pBRlFQrwzEm7menZ3xNbrjSYrFAGUvJLayokIK3cFroMtFUeMGrN+qewxplqXDkzQPw8Nn7OPu0fdSuLhWoslN1mV7riHrVpxzWmH93bI9XxvyfGr60zwm70sZzCvWxSJudbvIi9j2mR50Hmb6eadOGlC329cGAooaH1jOIlNu5m+M6QH7zsGnaCyuzDwaSo8jnJBisIGYFEL455xA9/6jR52wHVuyiSpf2YSWLDB7oKgtPRRQHyLeInPA= Content-Type: text/plain; charset="utf-8" Content-ID: <3883871607C4DE4BA71C674F975A5E31@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: dddd2f64-f8b4-4ee9-a425-08d6d861f76e X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2019 11:47:39.8492 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4573 Archived-At: Subject: Re: [RTG-DIR] [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 11:47:46 -0000 RXJpYw0KDQpBIHF1aWNrIGJyb3dzZSB0ZWxscyBtZSB0aGF0IGluIHRoZSBSRkMgSSByZWd1bGFy bHkgcmVmZXIgdG8sICdiaW5kaW5nJw0KaXMgdXNlZCBpbiBvdmVyIDMwMCBvZiB0aGVtIGJ1dCB0 aGF0IGluIGFsbCB0aG9zZSB0aGF0IEkgbG9va2VkIGF0LCBpdA0KaXMgYWx3YXlzIGJpbmRpbmcg YW4gZWxlbWVudCBvZiBhIHNldCB0byBhbiBlbGVtZW50IG9mIHRoZSBzYW1lIG9yIGENCmRpZmZl cmVudCBzZXQsIHdoZXJlIHRoZSBzZXRzIGFyZSBzaW1pbGFyIGluIG5hdHVyZS4gIFRodXMgQVJQ IGJpbmRzIGFuDQpJUCBhZGRyZXNzIHRvIGEgTUFDIGFkZHJlc3Mgb3IgYSBiaWRpcmVjdGlvbmFs IE1QTFMgTFNQIGJpbmRzIG9uZQ0KdW5pZGlyZWN0aW9uYWwgTFNQIHRvIGFub3RoZXIgYW5kIHNv IG9uZS4NCg0KV2hhdCBJIGRvIG5vdCBsZWFybiBoZXJlIGlzIHdoYXQgaXMgYmVpbmcgYm91bmQg dG8gd2hhdC4NCg0KUGVyaGFwcw0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIGJpbmRp bmcgb2YgYSBzdHJlYW0gb2YgZXZlbnRzIHdoaWNoIGZvcm0NCnBhcnQgb2YgYSBkeW5hbWljIHN1 YnNjcmlwdGlvbiB0byB0aGUgTkVUQ09ORg0KICAgcHJvdG9jb2wgW1JGQzYyNDFdLiAgRHluYW1p YyBzdWJzY3JpcHRpb25zIGFyZSBkZWZpbmVkIGluDQogICBbSS1ELmRyYWZ0LWlldGYtbmV0Y29u Zi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnNdLg0KDQpUaGUgY3J1eCBpcyAiYmluZGluZyAuLi4g dG8gLi4uIiB3aGljaCBpcyBjdXJyZW50bHkgbGFja2luZy4NCg0KTW9yZSBnZW5lcmFsbHk6LSgN CkkgZG8gZmluZCB0aGlzIEktRCBoYXJkIHRvIHVuZGVyc3RhbmQuICBJIHRoaW5rIHRoYXQgdGhl IGtleSBpcyB0aGF0DQp0aGlzIEktRCwgbW9yZSB0aGFuIGFueSBvdGhlciBJIGNhbiB0aGluayBv ZiwgaXMgc28gZGVwZW5kZW50IG9uIG9uZSBvZg0KaXRzIE5vcm1hdGl2ZSBSZWZlcmVuY2VzLCB0 byB3aGl0LCBzdWJzY3JpYmVkIG5vdGlmaWNhdGlvbnM7IEkgdGhpbmsNCnRoYXQgdGhhdCBuZWVk cyBjYWxsaW5nIG91dCBzbyBJIHdvdWxkIGFkZA0KIlRoaXMgbWVtbyBhc3N1bWVzIHRoYXQgdGhl IHJlYWRlciBpcyBmYW1pbGlhciB3aXRoIHRoZSB0ZXJtaW5vbG9neSBhbmQNCmNvbmNlcHRzIGRl ZmluZWQgaW4gW3N1YnNjcmliZWQtbm90aWZpY2F0aW9uc10iDQoNClllcywgdGhhdCBpcyB3aGF0 IGEgTm9ybWF0aXZlIFJlZmVyZW5jZSBtZWFucyBidXQgSSBmaW5kIHRoaXMgZXhhbXBsZSBzbw0K ZXh0cmVtZSB0aGF0IEkgdGhpbmsgaXQgbmVlZHMgY2FsbGluZyBvdXQuICBFYWNoIHRpbWUgaW4g dGhlIHBhc3Qgc2l4DQptb250aHMgSSBoYXZlIHR1cm5lZCB0byB0aGlzIEktRCAoaXQgaXMgdGhl IHNtYWxsZXN0IG9mIHRoZSB2ZXJ5IGxhcmdlDQpzZXQgb2YgbmV0Y29uZiBJLURzOi0pLCBJIGhh dmUgZ2l2ZW4gdXAsIGV2ZW50dWFsbHkgd29ya2luZyBvdXQgdGhhdA0KZmlyc3QgSSBtdXN0IG1h c3RlciB0aGUgODAgcGFnZXMgb2Ygc3Vic2NyaWJlZCBub3RpZmljYXRpb25zLiAgVGhpcyBtYXkN Cm5vdCBiZSBzbyBvYnZpb3VzIHRvIHRob3NlIGludm9sdmVkIGF0IExhc3QgQ2FsbCB0aW1lLg0K DQpUb20gUGV0Y2gNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiRXJp YyBWb2l0IChldm9pdCkiIDxldm9pdEBjaXNjby5jb20+DQpTZW50OiBGcmlkYXksIE1heSAxMCwg MjAxOSA3OjM5IFBNDQoNCg0KPiBIaSBEaHJ1diwNCj4gSGkgS2VudCwNCj4NCj4gPiBGcm9tOiBE aHJ1diBEaG9keSwgTWF5IDksIDIwMTkgMTE6MjggUE0NCj4gPg0KPiA+IEhpIEVyaWMsDQo+ID4N Cj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBFcmljIFZvaXQg KGV2b2l0KSBbbWFpbHRvOmV2b2l0QGNpc2NvLmNvbV0NCj4gPiA+IFNlbnQ6IDEwIE1heSAyMDE5 IDAyOjE4DQo+ID4gPiBIaSBEaHJ1diwNCj4gPiA+DQo+ID4gPiA+IEZyb206IERocnV2IERob2R5 LCBNYXkgOSwgMjAxOSAxMjowMyBBTQ0KPiA+ID4gPg0KPiA+ID4gPiBIaSBFcmljLA0KPiA+ID4g Pg0KPiA+ID4gPiBUaGFua3MgZm9yIHRoZSB1cGRhdGUuIEkgc2VlIG9uZSBtaW5vciBjb21tZW50 IHRoYXQgaXMgbm90DQpoYW5kbGVkLg0KPiA+ID4gPiBNYXliZSB5b3UgbWlzc2VkIGl0PyBPciB5 b3UgZGlzYWdyZWUsIHRoYXQgc29tZSBtb3JlIHRleHQgaXMNCnJlcXVpcmVkPw0KPiA+ID4gPg0K PiA+ID4gPiA+IE1pbm9yIElzc3VlczoNCj4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tDQo+ID4gPiA+ ID4gKDEpIEFic3RyYWN0ICYgSW50cm9kdWN0aW9uLCBJdCBpcyBub3QgY2xlYXIgd2hhdCBkb2Vz IHRoZQ0KJ2JpbmRpbmcnDQo+ID4gPiA+ID4gbWVhbiBhbmQgd2hvIGFyZSB0aGUgcGFydGllcyB0 byB0aGlzIGJpbmRpbmc/IElmIHRoaXMgaXMgdGhlDQo+ID4gPiA+ID4gZG9jdW1lbnQgdGhhdA0K PiA+ID4gPiBtZW50aW9ucyAnYmluZGluZycNCj4gPiA+ID4gPiBmaXJzdCwgc28gcGxlYXNlIGFk ZCBzb21lIG1vcmUgY2xhcmlmeWluZyB0ZXh0Lg0KPiA+ID4NCj4gPiA+IFRoaXMgaXMgbm90IHRo ZSBmaXJzdCBkb2N1bWVudCB3aGljaCBtZW50aW9ucyAnYmluZGluZycgIGZpcnN0Lg0KVGhlDQo+ ID4gPiBkb2N1bWVudCB3aGljaCBkb2VzIHRoaXMgZmlyc3QgaXMgZHJhZnQtaWV0Zi1uZXRjb25m LXN1YnNjcmliZWQtDQo+ID4gPiBub3RpZmljYXRpb25zLg0KPiA+IFtbRGhydXYgRGhvZHldXSBk cmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIHNheXMNCnRoaXMgaW4g dGhlDQo+ID4gSW50cm9kdWN0aW9uIC0NCj4gPg0KPiA+ICAgIFdoaWxlIHRoZSBmdW5jdGlvbmFs aXR5IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBpcyB0cmFuc3BvcnQtDQo+ID4gICAgYWdub3N0 aWMsIHRyYW5zcG9ydHMgbGlrZSBORVRDT05GIFtSRkM2MjQxXSBvciBSRVNUQ09ORiBbUkZDODA0 MF0NCmNhbg0KPiA+ICAgIGJlIHVzZWQgdG8gY29uZmlndXJlIG9yIGR5bmFtaWNhbGx5IHNpZ25h bCBzdWJzY3JpcHRpb25zLCBhbmQNCnRoZXJlDQo+ID4gICAgYXJlIGJpbmRpbmdzIGRlZmluZWQg Zm9yIHN1YnNjcmliZWQgZXZlbnQgcmVjb3JkIGRlbGl2ZXJ5IGZvcg0KTkVUQ09ORg0KPiA+ICAg IHdpdGhpbiBbSS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50LW5vdGlmaWNhdGlv bnNdLCBhbmQNCmZvcg0KPiA+ICAgIFJFU1RDT05GIHdpdGhpbiBbSS1ELmRyYWZ0LWlldGYtbmV0 Y29uZi1yZXN0Y29uZi1ub3RpZl0uDQo+ID4NCj4gPiBJIHRoaW5rIHRoaXMgaXMgb25seSB0aW1l IGJpbmRpbmcgaXMgdXNlZCBpbiB0aGlzIGNvbnRleHQuDQo+ID4gQW5kIG5vdyB0aGlzIEktRCBz YXlzIC0NCj4gPg0KPiA+ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBiaW5kaW5nIGZvciBl dmVudHMgc3RyZWFtZWQgb3ZlciB0aGUNCk5FVENPTkYNCj4gPiAgICBwcm90b2NvbCBbUkZDNjI0 MV0gZm9yIGR5bmFtaWMgc3Vic2NyaXB0aW9ucyBhcyBkZWZpbmVkIGluDQo+ID4gICAgW0ktRC5k cmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zXS4NCj4gPg0KPiA+IEFu ZCB5b3UgZG9u4oCZdCB1c2UgdGhpcyB0ZXJtIGV2ZXIgYWdhaW4uDQo+ID4NCj4gPiBUbyBtZSB0 aGlzIGlzIGJpdCBjaXJjdWxhciBhbmQgdGhlIHRlcm0gYmluZGluZyBpcyB1c2VkIGxvb3NlbHku IEFuZA0KdGh1cyBJIGZsYWdnZWQNCj4gPiBpdC4gSSB3aWxsIGxldCB5b3UgYW5kIEtlbnQgZGVj aWRlIHRoZSByaWdodCBhcHByb2FjaC4NCj4NCj4gSSByZWFsbHkgYW0gb2sgd2l0aCBtYW55IG9w dGlvbnMgaGVyZToNCj4gIChhKSAga2VlcCB0aGUgY3VycmVudCB0ZXh0Lg0KPiAgKGIpICB1c2Ug cHJldmlvdXMgdmVyc2lvbnMgb2YgdGhlIGFic3RyYWN0Lg0KPiAgKGMpICByZXBsYWNlIHRoZSB3 b3JkIGJpbmRpbmcgd2l0aCBzb21lIG90aGVyIHRleHQuDQo+DQo+IEdldHRpbmcgdGhlIHJpZ2h0 IHdvcmRzIGhlcmUgbmFpbGVkIGRvd24gaGFzbid0IGJlZW4gZnJvbSBsYWNrIG9mDQplZmZvcnQu ICBUbyBnaXZlIHlvdSBhbiBpZGVhLCBiZWxvdyBhcmUgZm91ciBwcmV2aW91cyBhdHRlbXB0cyBh dCB0aGUNCmFic3RyYWN0Lg0KPg0KPiBGcm9tIC12NQ0KPg0KPiAgICBUaGlzIGRvY3VtZW50IGRl ZmluZXMgaG93IHRvIHRyYW5zcG9ydCBuZXR3b3JrIHN1YnNjcmlwdGlvbnMgYW5kDQo+ICAgIGV2 ZW50IG1lc3NhZ2VzIG9uIHRvcCBvZiB0aGUgTmV0d29yayBDb25maWd1cmF0aW9uIHByb3RvY29s DQo+ICAgIChORVRDT05GKS4gIFRoaXMgaW5jbHVkZXMgdGhlIGZ1bGwgc2V0IG9mIFJQQ3MsIHN1 YnNjcmlwdGlvbiBzdGF0ZQ0KPiAgICBjaGFuZ2VzLCBhbmQgc3Vic2NyaWJlZCBjb250ZW50IG5l ZWRpbmcgYXN5bmNocm9ub3VzIGRlbGl2ZXJ5Lg0KPg0KPg0KPiBGcm9tIC12Ng0KPg0KPiAgICBU aGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgTkVUQ09ORiBiaW5kaW5nIGZvcg0KPiAgICBbSS1ELmRy YWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnNdLiAgSW5jbHVkZWQgYXJl Og0KPg0KPiAgICBvICBUcmFuc3BvcnQgbWFwcGluZ3MgZm9yIHN1YnNjcmlwdGlvbiBSUENzLCBz dGF0ZSBjaGFuZ2UNCj4gICAgICAgbm90aWZpY2F0aW9ucywgYW5kIG5vdGlmaWNhdGlvbiBtZXNz YWdlcw0KPg0KPiAgICBvICBGdW5jdGlvbmFsaXR5IHdoaWNoIG11c3QgYmUgc3VwcG9ydGVkIHdp dGggTkVUQ09ORg0KPg0KPiAgICBvICBFeGFtcGxlcyBpbiBhcHBlbmRpY2VzDQo+DQo+DQo+IEZy b20gLXY3DQo+DQo+ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBORVRDT05GIGJpbmRpbmcg Zm9yDQo+ICAgIFtJLUQuZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9u c10gYW5kDQo+ICAgIFtJLUQuaWV0Zi1uZXRjb25mLXlhbmctcHVzaF0uICBJbmNsdWRlZCBhcmU6 DQo+DQo+ICAgIG8gIHRyYW5zcG9ydCBtYXBwaW5ncyBmb3Igc3Vic2NyaXB0aW9uIFJQQ3MsIHN0 YXRlIGNoYW5nZQ0KPiAgICAgICBub3RpZmljYXRpb25zLCBhbmQgbm90aWZpY2F0aW9uIG1lc3Nh Z2VzLA0KPiAgICBvICBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cywgYW5kDQo+ICAgIG8gIGV4YW1w bGVzDQo+DQo+DQo+IEZyb20gLXY4DQo+DQo+ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBO RVRDT05GIGJpbmRpbmcgdG8gc3Vic2NyaWJlZA0Kbm90aWZpY2F0aW9ucw0KPiAgICBhbmQgdG8g WUFORyBwdXNoLg0KPg0KPg0KPiBIb25lc3RseSBJIGxpa2UgdGhlIHY1IHZlcnNpb24uICAgQnV0 IHByZXZpb3VzIHJldmlld2VycyBoYXZlDQppbmNyZW1lbnRhbGx5IGRyaXZlbiB0aGluZ3MgdG8g dGhlIGN1cnJlbnQgdGV4dC4gICAgSWYgS2VudCB5b3UgcHJlZmVyDQpzb21ldGhpbmcgb3RoZXIg dGhhbiB0aGUgY3VycmVudCB0ZXh0LCBsZXQgbWUga25vdyB3aGF0IGl0IGlzLiAgSSBhbQ0Kc3Vy ZSBJIHdpbGwgbGlrZSBpdCB0b28uDQo+DQo+IEVyaWMNCj4NCj4NCj4gPiBUaGFua3MhDQo+ID4g RGhydXYNCj4gPg0KPiA+DQo+ID4gPiBJbiB0aGUgYWJzdHJhY3Qgb2YgdGhpcyBkb2N1bWVudCwg dGhhdCBkcmFmdCBpcyBub3QgZXhwbGljaXRseQ0KbGlzdGVkDQo+ID4gPiBieSByZWZlcmVuY2Ug KGFzIEkgdW5kZXJzdG9vZCB3ZSBhcmUgbm90IHN1cHBvc2VkIHRvIHVzZQ0KcmVmZXJlbmNlcyBp bg0KPiA+ID4gYWJzdHJhY3RzKS4gIEJ1dCBpdCBpcyBsaXN0ZWQgaW4gdGhlIEludHJvZHVjdGlv bi4NCj4gPiA+DQo+ID4gPiBUbyBtYWtlIHRoaXMgY2xlYXJlciBmb3IgeW91IGluIHRoaXMgZG9j dW1lbnQsIHBlcmhhcHMgInRyYW5zcG9ydA0KYmluZGluZyINCj4gPiA+IGluc3RlYWQgb2YgImJp bmRpbmciPyAgIEkgcmVhbGx5IGRvbid0IGhhdmUgbWFueSBhbHRlcm5hdGl2ZXMgSQ0KY2FuIHRo aW5rDQo+ID4gPiBvZiB3aGljaCBhbHNvIGtlZXBzIHRoZSB0ZXh0IGJyaWVmLiAgIFRoaXMgcGFy dGljdWxhciB0ZXh0IGhhcw0KYmVlbg0KPiA+ID4gZnJlcXVlbnRseSB0d2Vha2VkIGluIHRoZSBw YXN0Lg0KPiA+ID4NCj4gPiA+IFRoYW5rcy4NCj4gPiA+IEVyaWMNCj4gPiA+DQo+ID4gPg0KPiA+ ID4gPiBUaGFua3MhDQo+ID4gPiA+IERocnV2Pg0KPiA+ID4gPiBPbiBXZWQsIE1heSA4LCAyMDE5 IGF0IDk6MTQgUE0gRXJpYyBWb2l0IChldm9pdCkNCjxldm9pdEBjaXNjby5jb20+IHdyb3RlOg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gVXBkYXRlIHBvc3RlZCBhcyAtdjIwLiAgIFdpdGggdGhlIGNv cnJlc3BvbmRpbmcgY2hhbmdlIHRvDQpkcmFmdC1pZXRmLQ0KPiA+ID4gbmV0Y29uZi0NCj4gPiA+ ID4gc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIHBvc3RlZCBhcyAtdjI1Lg0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gRXJpYw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBGcm9tOiBEaHJ1diBEaG9keSwg TWF5IDgsIDIwMTkgMjoyMSBBTQ0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEhpIEtlbnQsIEVy aWMsDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gRmluZSB3aXRoIG1lIQ0KPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+IFRoYW5rcyENCj4gPiA+ID4gPiA+IERocnV2DQo+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gT24gV2VkLCBNYXkgOCwgMjAxOSBhdCAzOjE5IEFNIEtlbnQgV2F0c2VuDQo+ID4g PiA+ID4gPiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+DQo+ID4gPiA+IHdyb3RlOg0KPiA+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA8ZXJpYz4g QmFzZWQgb24gbXkgcmVhZGluZyBvZiB5b3VyIHByb2Nlc3Mgc3VnZ2VzdGlvbnMNCktlbnQsIEkN Cj4gPiA+ID4gPiA+ID4gbGlrZSBiZXN0IHRoZQ0KPiA+ID4gPiA+ID4g4oCcbWVudGlvbuKAnSBh cHByb2FjaCB3aGljaCB5b3UgdXNlZCBmb3IgUkZDLTgwNzEsIFNlY3Rpb24gMS40Lg0KPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBXaGF0IEkgdGhpbmsgY291bGQgYmUgZG9uZSB0byBjb3Zl ciB0aGlzIGlzOg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAoQSkgIFJlbW92ZSBTZWN0 aW9uIDExOiBOb3RlcyB0byB0aGUgUkZDIEVkaXRvcg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gPiAoQikgIFBlciBLZW504oCZcyBkZXNpcmUgdG8gYWxzbyBjb3Zlcg0KPiA+ID4gPiA+ID4g PiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYsIHBsYWNlIHRoZQ0KPiA+ID4gPiA+ ID4gZm9sbG93aW5nIHN0YXRlbWVudCBpbnRvDQo+ID4gPiA+ID4gPiBkcmFmdC1pZXRmLW5ldGNv bmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zDQo+ID4gPiA+ID4gPiBkaXJlY3RseSBhZnRlciBG aWd1cmUgMTANCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gW1JGQy01Mjc3XSBTZWN0aW9u IDIuMi4xIHN0YXRlcyB0aGF0IGEgbm90aWZpY2F0aW9uDQptZXNzYWdlIGlzDQo+ID4gPiA+ID4g PiA+IHRvIGJlIHNlbnQgdG8gYQ0KPiA+ID4gPiA+ID4gc3Vic2NyaWJlciB3aGljaCBpbml0aWF0 ZWQgYSAiY3JlYXRlLXN1YnNjcmlwdGlvbiIuICAgV2l0aA0KdGhpcw0KPiA+ID4gc3BlY2lmaWNh dGlvbiwNCj4gPiA+ID4gdGhpcw0KPiA+ID4gPiA+ID4gUkZDLTUyNzcgc3RhdGVtZW50IHNob3Vs ZCBiZSBtb3JlIGJyb2FkbHkgaW50ZXJwcmV0ZWQgdG8NCm1lYW4NCj4gPiA+ID4gPiA+IHRoYXQg bm90aWZpY2F0aW9uIG1lc3NhZ2VzIGNhbiBhbHNvIGJlIHNlbnQgdG8gYSBzdWJzY3JpYmVyDQo+ ID4gPiA+ID4gPiB3aGljaCBpbml0aWF0ZWQgYW4gImVzdGFibGlzaC1zdWJzY3JpcHRpb24iLCBv ciBhIGNvbmZpZ3VyZWQNCj4gPiA+ID4gPiA+IHJlY2VpdmVyIHdoaWNoIGhhcyBiZWVuIHNlbnQg YSDigJxzdWJzY3JpcHRpb24tc3RhcnRlZOKAnS4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ ID4gRG9lcyB0aGlzIHdvcmsgZm9yIGJvdGggb2YgeW91Pw0KPiA+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBXb3JrcyBmb3IgbWUuDQo+ID4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IFRoZSBpc3N1ZSBpc24ndCBj b25zaXN0ZW5jeSBzbyBtdWNoIGFzIG1lZXRpbmcNCmV4cGVjdGF0aW9ucywNCj4gPiA+ID4gPiA+ ID4gcGVyIGB4bWwycmZjYCwgdGhlDQo+ID4gPiA+ID4gPiBkb2N1bWVudCBzaG91bGQgaGF2ZSBz b21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nIGluIHRoZQ0KPiA+ID4gPiA+ID4gUmVmZXJlbmNl cyBzZWN0aW9uLCB3aGljaCB0aGVuIGF1dG8tZXhwYW5kcyB0byB0aGUgY29ycmVjdA0KPiA+ID4g PiA+ID4gcmVmZXJlbmNlIHRleHQsIGFzIHdlbGwgYXMgZGVmaW5pbmcgdGhlIGFuY2hvcg0KPiA+ ID4gPiA+ID4gIkktRC5pZXRmLW5ldGNvbmYtDQo+ID4gPiBzdWJzY3JpYmVkLW5vdGlmaWNhdGlv bnMiOg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAgICAgICAgIDw/cmZjDQo+ID4gPiA+ ID4gPiA+DQppbmNsdWRlPSJyZWZlcmVuY2UuSS1ELmlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5v dGlmaWNhdGlvbnMiPw0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g PiA+IDxFcmljPiBUaGF0IGRlZmluaXRlbHkgbWFrZXMgdGhpbmdzIGVhc2llciB0aGFuIHdoYXQg SQ0KaGF2ZQ0KPiA+ID4gPiA+ID4gPiBiZWVuIGRvaW5nLiAgSSBhbQ0KPiA+ID4gPiA+ID4gaGl0 dGluZyBhbiB4bWwycmZjIGVycm9yIHRyeWluZyB0aGlzIHJpZ2h0IG5vdywgYnV0IEkgd2lsbA0K Z2V0IHRoZXJlLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBZ ZXMsIGl0IHdhcyBhbiBleWUtb3BlbmVyIHdoZW4gSSBmaWd1cmVkIGl0IG91dC4gICBCZQ0KYXdh cmUgdGhhdCwNCj4gPiA+IHRob3VnaA0KPiA+ID4gPiBzb21lDQo+ID4gPiA+ID4gPiBleHRlcm5h bCBzb3VyY2VzIChlLmcuLCBJVFUgc3RhbmRhcmRzKSBhcmUgc3VwcG9ydGVkLCBtYW55DQphcmUN Cj4gPiA+ID4gPiA+IG5vdCwgYW5kIHNvIGhhbmQtIGNvZGluZyB0aGUgPHJlZmVyZW5jZT4gaXMg c3RpbGwgc29tZXRpbWVzDQo+ID4gPiByZXF1aXJlZC4uLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBLZW50IC8vIHNoZXBoZXJkDQo+ID4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+DQo+DQoNCg== From nobody Tue May 14 08:00:20 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E562D120139; Tue, 14 May 2019 08:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 vh1U3TASQvtS; Tue, 14 May 2019 08:00:09 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E61612013A; Tue, 14 May 2019 07:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14106; q=dns/txt; s=iport; t=1557845985; x=1559055585; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xBhrQ00WbNdEEd4CkbWCM0qyYYsDnjaf+x8oK4VBzAA=; b=OERUWC9C+MbutOy5DQBf0AgE1gIMfDt2F5Xuw6g8mPgGN5e5Wzc3J8XV /5lxfheKtjMkIdYu6B+EPYg/fLTZawRCz38H8Ktzzqg/UObPN9DusDRLA RJ6Rx9OkuFB+QqGyEGoub2RxR4czzW7rkbjOsVFO2NWaDEX4H9xGl7IF8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AgC+1tpc/4kNJK1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBZYFnKoE9MCgKhAeVH5pOCQEBAQwBAS8BAYRAAheCBiM4EwEDAQEEAQE?= =?us-ascii?q?CAQRtKIVKAQEBAwEjEUMCBQcEAgEIFQECAgIJGgMCAgIwFAEQAgQBDQUIgk9?= =?us-ascii?q?LgXwPrlCBL4oxgQsoi08XgUA/hCM+hEszglCCWASLHgOCO5l9CQKCCZJWI4I?= =?us-ascii?q?UhkwFjQmDIIkUgSKTaAIRFYEwNiGBV3AVgyeQUUExj06BIQEB?= X-IronPort-AV: E=Sophos;i="5.60,469,1549929600"; d="scan'208";a="270275950" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 May 2019 14:59:44 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x4EExidI021780 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 May 2019 14:59:44 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 14 May 2019 10:59:43 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Tue, 14 May 2019 10:59:43 -0400 From: "Eric Voit (evoit)" To: tom petch , Dhruv Dhody , Kent Watsen CC: "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "rtg-dir@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 Thread-Index: AQHU/xC8WbWTXSPvekeZmlnK7/xOtqZqyZ/Q Date: Tue, 14 May 2019 14:59:43 +0000 Message-ID: <23a9e41d7bcb41d7a6b7a9eeb50aaa18@XCH-RTP-013.cisco.com> References: <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com> <23CE718903A838468A8B325B80962F9B8DA56A70@BLREML503-MBX.china.huawei.com> <5e89a05b0eb6492abee9cedfe3134031@XCH-RTP-013.cisco.com> <058801d50a4a$4f3308e0$4001a8c0@gateway.2wire.net> In-Reply-To: <058801d50a4a$4f3308e0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [RTG-DIR] [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 15:00:12 -0000 SGkgVG9tLA0KDQo+IEZyb206IHRvbSBwZXRjaCwgTWF5IDE0LCAyMDE5IDc6NDggQU0NCj4gDQo+ IEVyaWMNCj4gDQo+IEEgcXVpY2sgYnJvd3NlIHRlbGxzIG1lIHRoYXQgaW4gdGhlIFJGQyBJIHJl Z3VsYXJseSByZWZlciB0bywgJ2JpbmRpbmcnDQo+IGlzIHVzZWQgaW4gb3ZlciAzMDAgb2YgdGhl bSBidXQgdGhhdCBpbiBhbGwgdGhvc2UgdGhhdCBJIGxvb2tlZCBhdCwgaXQgaXMgYWx3YXlzDQo+ IGJpbmRpbmcgYW4gZWxlbWVudCBvZiBhIHNldCB0byBhbiBlbGVtZW50IG9mIHRoZSBzYW1lIG9y IGEgZGlmZmVyZW50IHNldCwgd2hlcmUNCj4gdGhlIHNldHMgYXJlIHNpbWlsYXIgaW4gbmF0dXJl LiAgVGh1cyBBUlAgYmluZHMgYW4gSVAgYWRkcmVzcyB0byBhIE1BQyBhZGRyZXNzIG9yDQo+IGEg YmlkaXJlY3Rpb25hbCBNUExTIExTUCBiaW5kcyBvbmUgdW5pZGlyZWN0aW9uYWwgTFNQIHRvIGFu b3RoZXIgYW5kIHNvIG9uZS4NCj4gDQo+IFdoYXQgSSBkbyBub3QgbGVhcm4gaGVyZSBpcyB3aGF0 IGlzIGJlaW5nIGJvdW5kIHRvIHdoYXQuDQo+IA0KPiBQZXJoYXBzDQo+ICAgIFRoaXMgZG9jdW1l bnQgc3BlY2lmaWVzIHRoZSBiaW5kaW5nIG9mIGEgc3RyZWFtIG9mIGV2ZW50cyB3aGljaCBmb3Jt IHBhcnQgb2YgYQ0KPiBkeW5hbWljIHN1YnNjcmlwdGlvbiB0byB0aGUgTkVUQ09ORg0KPiAgICBw cm90b2NvbCBbUkZDNjI0MV0uICBEeW5hbWljIHN1YnNjcmlwdGlvbnMgYXJlIGRlZmluZWQgaW4N Cj4gICAgW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zXS4N Cg0KSSBhbSBhc3N1bWluZyB0aGF0IHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoZSBmaXJzdCBzZW50 ZW5jZSBvZiB0aGUgSW50cm8gaGVyZSwgYXMgZG9jdW1lbnQgcmVmZXJlbmNlcyBhcmUgbm90IGlu IGFic3RyYWN0cy4NCg0KVGhpcyB0ZXh0IHdvcmtzIGZvciBtZS4gICBBbnkgb2JqZWN0aW9ucyBh bnlvbmU/DQogDQo+IFRoZSBjcnV4IGlzICJiaW5kaW5nIC4uLiB0byAuLi4iIHdoaWNoIGlzIGN1 cnJlbnRseSBsYWNraW5nLg0KPiANCj4gTW9yZSBnZW5lcmFsbHk6LSgNCj4gSSBkbyBmaW5kIHRo aXMgSS1EIGhhcmQgdG8gdW5kZXJzdGFuZC4gIEkgdGhpbmsgdGhhdCB0aGUga2V5IGlzIHRoYXQg dGhpcyBJLUQsIG1vcmUNCj4gdGhhbiBhbnkgb3RoZXIgSSBjYW4gdGhpbmsgb2YsIGlzIHNvIGRl cGVuZGVudCBvbiBvbmUgb2YgaXRzIE5vcm1hdGl2ZQ0KPiBSZWZlcmVuY2VzLCB0byB3aGl0LCBz dWJzY3JpYmVkIG5vdGlmaWNhdGlvbnM7IEkgdGhpbmsgdGhhdCB0aGF0IG5lZWRzIGNhbGxpbmcg b3V0DQo+IHNvIEkgd291bGQgYWRkICJUaGlzIG1lbW8gYXNzdW1lcyB0aGF0IHRoZSByZWFkZXIg aXMgZmFtaWxpYXIgd2l0aCB0aGUNCj4gdGVybWlub2xvZ3kgYW5kIGNvbmNlcHRzIGRlZmluZWQg aW4gW3N1YnNjcmliZWQtbm90aWZpY2F0aW9uc10iDQoNCkFzIHRoZSBsYXN0IHNlbnRlbmNlIGlu IHRoZSBJbnRybyBzZWN0aW9uLCBJIGhhdmUgYWRkZWQ6IA0KIlRoaXMgZG9jdW1lbnQgYXNzdW1l cyB0aGF0IHRoZSByZWFkZXIgaXMgZmFtaWxpYXIgd2l0aCB0aGUgdGVybWlub2xvZ3kgYW5kIGNv bmNlcHRzIGRlZmluZWQgaW4gW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3Rp ZmljYXRpb25zXS4iDQogDQo+IFllcywgdGhhdCBpcyB3aGF0IGEgTm9ybWF0aXZlIFJlZmVyZW5j ZSBtZWFucyBidXQgSSBmaW5kIHRoaXMgZXhhbXBsZSBzbw0KPiBleHRyZW1lIHRoYXQgSSB0aGlu ayBpdCBuZWVkcyBjYWxsaW5nIG91dC4gIEVhY2ggdGltZSBpbiB0aGUgcGFzdCBzaXggbW9udGhz IEkgaGF2ZQ0KPiB0dXJuZWQgdG8gdGhpcyBJLUQgKGl0IGlzIHRoZSBzbWFsbGVzdCBvZiB0aGUg dmVyeSBsYXJnZSBzZXQgb2YgbmV0Y29uZiBJLURzOi0pLCBJIGhhdmUNCj4gZ2l2ZW4gdXAsIGV2 ZW50dWFsbHkgd29ya2luZyBvdXQgdGhhdCBmaXJzdCBJIG11c3QgbWFzdGVyIHRoZSA4MCBwYWdl cyBvZg0KPiBzdWJzY3JpYmVkIG5vdGlmaWNhdGlvbnMuICBUaGlzIG1heSBub3QgYmUgc28gb2J2 aW91cyB0byB0aG9zZSBpbnZvbHZlZCBhdCBMYXN0DQo+IENhbGwgdGltZS4NCg0KVW5kZXJzdG9v ZC4gIEFuZCBpdCBpcyB0cnVlIHRoYXQgdW5kZXJzdGFuZGluZyBzdWJzY3JpYmVkLW5vdGlmaWNh dGlvbnMgaXMgYSBwcmVyZXF1aXNpdGUuDQoNCkVyaWMNCg0KPiBUb20gUGV0Y2gNCj4gDQo+IA0K PiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJFcmljIFZvaXQgKGV2b2l0 KSIgPGV2b2l0QGNpc2NvLmNvbT4NCj4gU2VudDogRnJpZGF5LCBNYXkgMTAsIDIwMTkgNzozOSBQ TQ0KPiANCj4gDQo+ID4gSGkgRGhydXYsDQo+ID4gSGkgS2VudCwNCj4gPg0KPiA+ID4gRnJvbTog RGhydXYgRGhvZHksIE1heSA5LCAyMDE5IDExOjI4IFBNDQo+ID4gPg0KPiA+ID4gSGkgRXJpYywN Cj4gPiA+DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206 IEVyaWMgVm9pdCAoZXZvaXQpIFttYWlsdG86ZXZvaXRAY2lzY28uY29tXQ0KPiA+ID4gPiBTZW50 OiAxMCBNYXkgMjAxOSAwMjoxOA0KPiA+ID4gPiBIaSBEaHJ1diwNCj4gPiA+ID4NCj4gPiA+ID4g PiBGcm9tOiBEaHJ1diBEaG9keSwgTWF5IDksIDIwMTkgMTI6MDMgQU0NCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IEhpIEVyaWMsDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGFua3MgZm9yIHRoZSB1cGRh dGUuIEkgc2VlIG9uZSBtaW5vciBjb21tZW50IHRoYXQgaXMgbm90DQo+IGhhbmRsZWQuDQo+ID4g PiA+ID4gTWF5YmUgeW91IG1pc3NlZCBpdD8gT3IgeW91IGRpc2FncmVlLCB0aGF0IHNvbWUgbW9y ZSB0ZXh0IGlzDQo+IHJlcXVpcmVkPw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBNaW5vciBJc3N1 ZXM6DQo+ID4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4gPiAoMSkgQWJzdHJhY3Qg JiBJbnRyb2R1Y3Rpb24sIEl0IGlzIG5vdCBjbGVhciB3aGF0IGRvZXMgdGhlDQo+ICdiaW5kaW5n Jw0KPiA+ID4gPiA+ID4gbWVhbiBhbmQgd2hvIGFyZSB0aGUgcGFydGllcyB0byB0aGlzIGJpbmRp bmc/IElmIHRoaXMgaXMgdGhlDQo+ID4gPiA+ID4gPiBkb2N1bWVudCB0aGF0DQo+ID4gPiA+ID4g bWVudGlvbnMgJ2JpbmRpbmcnDQo+ID4gPiA+ID4gPiBmaXJzdCwgc28gcGxlYXNlIGFkZCBzb21l IG1vcmUgY2xhcmlmeWluZyB0ZXh0Lg0KPiA+ID4gPg0KPiA+ID4gPiBUaGlzIGlzIG5vdCB0aGUg Zmlyc3QgZG9jdW1lbnQgd2hpY2ggbWVudGlvbnMgJ2JpbmRpbmcnICBmaXJzdC4NCj4gVGhlDQo+ ID4gPiA+IGRvY3VtZW50IHdoaWNoIGRvZXMgdGhpcyBmaXJzdCBpcyBkcmFmdC1pZXRmLW5ldGNv bmYtc3Vic2NyaWJlZC0NCj4gPiA+ID4gbm90aWZpY2F0aW9ucy4NCj4gPiA+IFtbRGhydXYgRGhv ZHldXSBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIHNheXMNCj4g dGhpcyBpbiB0aGUNCj4gPiA+IEludHJvZHVjdGlvbiAtDQo+ID4gPg0KPiA+ID4gICAgV2hpbGUg dGhlIGZ1bmN0aW9uYWxpdHkgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGlzIHRyYW5zcG9ydC0N Cj4gPiA+ICAgIGFnbm9zdGljLCB0cmFuc3BvcnRzIGxpa2UgTkVUQ09ORiBbUkZDNjI0MV0gb3Ig UkVTVENPTkYgW1JGQzgwNDBdDQo+IGNhbg0KPiA+ID4gICAgYmUgdXNlZCB0byBjb25maWd1cmUg b3IgZHluYW1pY2FsbHkgc2lnbmFsIHN1YnNjcmlwdGlvbnMsIGFuZA0KPiB0aGVyZQ0KPiA+ID4g ICAgYXJlIGJpbmRpbmdzIGRlZmluZWQgZm9yIHN1YnNjcmliZWQgZXZlbnQgcmVjb3JkIGRlbGl2 ZXJ5IGZvcg0KPiBORVRDT05GDQo+ID4gPiAgICB3aXRoaW4gW0ktRC5kcmFmdC1pZXRmLW5ldGNv bmYtbmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb25zXSwgYW5kDQo+IGZvcg0KPiA+ID4gICAgUkVT VENPTkYgd2l0aGluIFtJLUQuZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlmXS4NCj4g PiA+DQo+ID4gPiBJIHRoaW5rIHRoaXMgaXMgb25seSB0aW1lIGJpbmRpbmcgaXMgdXNlZCBpbiB0 aGlzIGNvbnRleHQuDQo+ID4gPiBBbmQgbm93IHRoaXMgSS1EIHNheXMgLQ0KPiA+ID4NCj4gPiA+ ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBiaW5kaW5nIGZvciBldmVudHMgc3RyZWFtZWQg b3ZlciB0aGUNCj4gTkVUQ09ORg0KPiA+ID4gICAgcHJvdG9jb2wgW1JGQzYyNDFdIGZvciBkeW5h bWljIHN1YnNjcmlwdGlvbnMgYXMgZGVmaW5lZCBpbg0KPiA+ID4gICAgW0ktRC5kcmFmdC1pZXRm LW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zXS4NCj4gPiA+DQo+ID4gPiBBbmQgeW91 IGRvbuKAmXQgdXNlIHRoaXMgdGVybSBldmVyIGFnYWluLg0KPiA+ID4NCj4gPiA+IFRvIG1lIHRo aXMgaXMgYml0IGNpcmN1bGFyIGFuZCB0aGUgdGVybSBiaW5kaW5nIGlzIHVzZWQgbG9vc2VseS4g QW5kDQo+IHRodXMgSSBmbGFnZ2VkDQo+ID4gPiBpdC4gSSB3aWxsIGxldCB5b3UgYW5kIEtlbnQg ZGVjaWRlIHRoZSByaWdodCBhcHByb2FjaC4NCj4gPg0KPiA+IEkgcmVhbGx5IGFtIG9rIHdpdGgg bWFueSBvcHRpb25zIGhlcmU6DQo+ID4gIChhKSAga2VlcCB0aGUgY3VycmVudCB0ZXh0Lg0KPiA+ ICAoYikgIHVzZSBwcmV2aW91cyB2ZXJzaW9ucyBvZiB0aGUgYWJzdHJhY3QuDQo+ID4gIChjKSAg cmVwbGFjZSB0aGUgd29yZCBiaW5kaW5nIHdpdGggc29tZSBvdGhlciB0ZXh0Lg0KPiA+DQo+ID4g R2V0dGluZyB0aGUgcmlnaHQgd29yZHMgaGVyZSBuYWlsZWQgZG93biBoYXNuJ3QgYmVlbiBmcm9t IGxhY2sgb2YNCj4gZWZmb3J0LiAgVG8gZ2l2ZSB5b3UgYW4gaWRlYSwgYmVsb3cgYXJlIGZvdXIg cHJldmlvdXMgYXR0ZW1wdHMgYXQgdGhlIGFic3RyYWN0Lg0KPiA+DQo+ID4gRnJvbSAtdjUNCj4g Pg0KPiA+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBob3cgdG8gdHJhbnNwb3J0IG5ldHdvcmsg c3Vic2NyaXB0aW9ucyBhbmQNCj4gPiAgICBldmVudCBtZXNzYWdlcyBvbiB0b3Agb2YgdGhlIE5l dHdvcmsgQ29uZmlndXJhdGlvbiBwcm90b2NvbA0KPiA+ICAgIChORVRDT05GKS4gIFRoaXMgaW5j bHVkZXMgdGhlIGZ1bGwgc2V0IG9mIFJQQ3MsIHN1YnNjcmlwdGlvbiBzdGF0ZQ0KPiA+ICAgIGNo YW5nZXMsIGFuZCBzdWJzY3JpYmVkIGNvbnRlbnQgbmVlZGluZyBhc3luY2hyb25vdXMgZGVsaXZl cnkuDQo+ID4NCj4gPg0KPiA+IEZyb20gLXY2DQo+ID4NCj4gPiAgICBUaGlzIGRvY3VtZW50IHBy b3ZpZGVzIGEgTkVUQ09ORiBiaW5kaW5nIGZvcg0KPiA+ICAgIFtJLUQuZHJhZnQtaWV0Zi1uZXRj b25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uc10uICBJbmNsdWRlZCBhcmU6DQo+ID4NCj4gPiAg ICBvICBUcmFuc3BvcnQgbWFwcGluZ3MgZm9yIHN1YnNjcmlwdGlvbiBSUENzLCBzdGF0ZSBjaGFu Z2UNCj4gPiAgICAgICBub3RpZmljYXRpb25zLCBhbmQgbm90aWZpY2F0aW9uIG1lc3NhZ2VzDQo+ ID4NCj4gPiAgICBvICBGdW5jdGlvbmFsaXR5IHdoaWNoIG11c3QgYmUgc3VwcG9ydGVkIHdpdGgg TkVUQ09ORg0KPiA+DQo+ID4gICAgbyAgRXhhbXBsZXMgaW4gYXBwZW5kaWNlcw0KPiA+DQo+ID4N Cj4gPiBGcm9tIC12Nw0KPiA+DQo+ID4gICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIE5FVENP TkYgYmluZGluZyBmb3INCj4gPiAgICBbSS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVk LW5vdGlmaWNhdGlvbnNdIGFuZA0KPiA+ICAgIFtJLUQuaWV0Zi1uZXRjb25mLXlhbmctcHVzaF0u ICBJbmNsdWRlZCBhcmU6DQo+ID4NCj4gPiAgICBvICB0cmFuc3BvcnQgbWFwcGluZ3MgZm9yIHN1 YnNjcmlwdGlvbiBSUENzLCBzdGF0ZSBjaGFuZ2UNCj4gPiAgICAgICBub3RpZmljYXRpb25zLCBh bmQgbm90aWZpY2F0aW9uIG1lc3NhZ2VzLA0KPiA+ICAgIG8gIGZ1bmN0aW9uYWwgcmVxdWlyZW1l bnRzLCBhbmQNCj4gPiAgICBvICBleGFtcGxlcw0KPiA+DQo+ID4NCj4gPiBGcm9tIC12OA0KPiA+ DQo+ID4gICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIE5FVENPTkYgYmluZGluZyB0byBzdWJz Y3JpYmVkDQo+IG5vdGlmaWNhdGlvbnMNCj4gPiAgICBhbmQgdG8gWUFORyBwdXNoLg0KPiA+DQo+ ID4NCj4gPiBIb25lc3RseSBJIGxpa2UgdGhlIHY1IHZlcnNpb24uICAgQnV0IHByZXZpb3VzIHJl dmlld2VycyBoYXZlDQo+IGluY3JlbWVudGFsbHkgZHJpdmVuIHRoaW5ncyB0byB0aGUgY3VycmVu dCB0ZXh0LiAgICBJZiBLZW50IHlvdSBwcmVmZXINCj4gc29tZXRoaW5nIG90aGVyIHRoYW4gdGhl IGN1cnJlbnQgdGV4dCwgbGV0IG1lIGtub3cgd2hhdCBpdCBpcy4gIEkgYW0gc3VyZSBJIHdpbGwN Cj4gbGlrZSBpdCB0b28uDQo+ID4NCj4gPiBFcmljDQo+ID4NCj4gPg0KPiA+ID4gVGhhbmtzIQ0K PiA+ID4gRGhydXYNCj4gPiA+DQo+ID4gPg0KPiA+ID4gPiBJbiB0aGUgYWJzdHJhY3Qgb2YgdGhp cyBkb2N1bWVudCwgdGhhdCBkcmFmdCBpcyBub3QgZXhwbGljaXRseQ0KPiBsaXN0ZWQNCj4gPiA+ ID4gYnkgcmVmZXJlbmNlIChhcyBJIHVuZGVyc3Rvb2Qgd2UgYXJlIG5vdCBzdXBwb3NlZCB0byB1 c2UNCj4gcmVmZXJlbmNlcyBpbg0KPiA+ID4gPiBhYnN0cmFjdHMpLiAgQnV0IGl0IGlzIGxpc3Rl ZCBpbiB0aGUgSW50cm9kdWN0aW9uLg0KPiA+ID4gPg0KPiA+ID4gPiBUbyBtYWtlIHRoaXMgY2xl YXJlciBmb3IgeW91IGluIHRoaXMgZG9jdW1lbnQsIHBlcmhhcHMgInRyYW5zcG9ydA0KPiBiaW5k aW5nIg0KPiA+ID4gPiBpbnN0ZWFkIG9mICJiaW5kaW5nIj8gICBJIHJlYWxseSBkb24ndCBoYXZl IG1hbnkgYWx0ZXJuYXRpdmVzIEkNCj4gY2FuIHRoaW5rDQo+ID4gPiA+IG9mIHdoaWNoIGFsc28g a2VlcHMgdGhlIHRleHQgYnJpZWYuICAgVGhpcyBwYXJ0aWN1bGFyIHRleHQgaGFzDQo+IGJlZW4N Cj4gPiA+ID4gZnJlcXVlbnRseSB0d2Vha2VkIGluIHRoZSBwYXN0Lg0KPiA+ID4gPg0KPiA+ID4g PiBUaGFua3MuDQo+ID4gPiA+IEVyaWMNCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gPiBUaGFu a3MhDQo+ID4gPiA+ID4gRGhydXY+DQo+ID4gPiA+ID4gT24gV2VkLCBNYXkgOCwgMjAxOSBhdCA5 OjE0IFBNIEVyaWMgVm9pdCAoZXZvaXQpDQo+IDxldm9pdEBjaXNjby5jb20+IHdyb3RlOg0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFVwZGF0ZSBwb3N0ZWQgYXMgLXYyMC4gICBXaXRoIHRoZSBj b3JyZXNwb25kaW5nIGNoYW5nZSB0bw0KPiBkcmFmdC1pZXRmLQ0KPiA+ID4gPiBuZXRjb25mLQ0K PiA+ID4gPiA+IHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyBwb3N0ZWQgYXMgLXYyNS4NCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiBFcmljDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBGcm9t OiBEaHJ1diBEaG9keSwgTWF5IDgsIDIwMTkgMjoyMSBBTQ0KPiA+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gPiBIaSBLZW50LCBFcmljLA0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBGaW5l IHdpdGggbWUhDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IFRoYW5rcyENCj4gPiA+ID4g PiA+ID4gRGhydXYNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gT24gV2VkLCBNYXkgOCwg MjAxOSBhdCAzOjE5IEFNIEtlbnQgV2F0c2VuDQo+ID4gPiA+ID4gPiA+IDxrZW50K2lldGZAd2F0 c2VuLm5ldD4NCj4gPiA+ID4gPiB3cm90ZToNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA8ZXJpYz4gQmFzZWQgb24gbXkg cmVhZGluZyBvZiB5b3VyIHByb2Nlc3Mgc3VnZ2VzdGlvbnMNCj4gS2VudCwgSQ0KPiA+ID4gPiA+ ID4gPiA+IGxpa2UgYmVzdCB0aGUNCj4gPiA+ID4gPiA+ID4g4oCcbWVudGlvbuKAnSBhcHByb2Fj aCB3aGljaCB5b3UgdXNlZCBmb3IgUkZDLTgwNzEsIFNlY3Rpb24gMS40Lg0KPiA+ID4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiA+ID4gV2hhdCBJIHRoaW5rIGNvdWxkIGJlIGRvbmUgdG8gY292ZXIg dGhpcyBpczoNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IChBKSAgUmVtb3ZlIFNl Y3Rpb24gMTE6IE5vdGVzIHRvIHRoZSBSRkMgRWRpdG9yDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+ID4gPiAoQikgIFBlciBLZW504oCZcyBkZXNpcmUgdG8gYWxzbyBjb3Zlcg0KPiA+ID4g PiA+ID4gPiA+IGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZiwgcGxhY2UgdGhlDQo+ ID4gPiA+ID4gPiA+IGZvbGxvd2luZyBzdGF0ZW1lbnQgaW50bw0KPiA+ID4gPiA+ID4gPiBkcmFm dC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zDQo+ID4gPiA+ID4gPiA+IGRp cmVjdGx5IGFmdGVyIEZpZ3VyZSAxMA0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4g W1JGQy01Mjc3XSBTZWN0aW9uIDIuMi4xIHN0YXRlcyB0aGF0IGEgbm90aWZpY2F0aW9uDQo+IG1l c3NhZ2UgaXMNCj4gPiA+ID4gPiA+ID4gPiB0byBiZSBzZW50IHRvIGENCj4gPiA+ID4gPiA+ID4g c3Vic2NyaWJlciB3aGljaCBpbml0aWF0ZWQgYSAiY3JlYXRlLXN1YnNjcmlwdGlvbiIuICAgV2l0 aA0KPiB0aGlzDQo+ID4gPiA+IHNwZWNpZmljYXRpb24sDQo+ID4gPiA+ID4gdGhpcw0KPiA+ID4g PiA+ID4gPiBSRkMtNTI3NyBzdGF0ZW1lbnQgc2hvdWxkIGJlIG1vcmUgYnJvYWRseSBpbnRlcnBy ZXRlZCB0bw0KPiBtZWFuDQo+ID4gPiA+ID4gPiA+IHRoYXQgbm90aWZpY2F0aW9uIG1lc3NhZ2Vz IGNhbiBhbHNvIGJlIHNlbnQgdG8gYSBzdWJzY3JpYmVyDQo+ID4gPiA+ID4gPiA+IHdoaWNoIGlu aXRpYXRlZCBhbiAiZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiIsIG9yIGEgY29uZmlndXJlZA0KPiA+ ID4gPiA+ID4gPiByZWNlaXZlciB3aGljaCBoYXMgYmVlbiBzZW50IGEg4oCcc3Vic2NyaXB0aW9u LXN0YXJ0ZWTigJ0uDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBEb2VzIHRoaXMg d29yayBmb3IgYm90aCBvZiB5b3U/DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gPiA+IFdvcmtzIGZvciBtZS4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBUaGUgaXNzdWUgaXNuJ3Qg Y29uc2lzdGVuY3kgc28gbXVjaCBhcyBtZWV0aW5nDQo+IGV4cGVjdGF0aW9ucywNCj4gPiA+ID4g PiA+ID4gPiBwZXIgYHhtbDJyZmNgLCB0aGUNCj4gPiA+ID4gPiA+ID4gZG9jdW1lbnQgc2hvdWxk IGhhdmUgc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZyBpbiB0aGUNCj4gPiA+ID4gPiA+ID4g UmVmZXJlbmNlcyBzZWN0aW9uLCB3aGljaCB0aGVuIGF1dG8tZXhwYW5kcyB0byB0aGUgY29ycmVj dA0KPiA+ID4gPiA+ID4gPiByZWZlcmVuY2UgdGV4dCwgYXMgd2VsbCBhcyBkZWZpbmluZyB0aGUg YW5jaG9yDQo+ID4gPiA+ID4gPiA+ICJJLUQuaWV0Zi1uZXRjb25mLQ0KPiA+ID4gPiBzdWJzY3Jp YmVkLW5vdGlmaWNhdGlvbnMiOg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gICAg ICAgICA8P3JmYw0KPiA+ID4gPiA+ID4gPiA+DQo+IGluY2x1ZGU9InJlZmVyZW5jZS5JLUQuaWV0 Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyI/DQo+ID4gPiA+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPEVyaWM+IFRoYXQgZGVmaW5pdGVseSBt YWtlcyB0aGluZ3MgZWFzaWVyIHRoYW4gd2hhdCBJDQo+IGhhdmUNCj4gPiA+ID4gPiA+ID4gPiBi ZWVuIGRvaW5nLiAgSSBhbQ0KPiA+ID4gPiA+ID4gPiBoaXR0aW5nIGFuIHhtbDJyZmMgZXJyb3Ig dHJ5aW5nIHRoaXMgcmlnaHQgbm93LCBidXQgSSB3aWxsDQo+IGdldCB0aGVyZS4NCj4gPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gWWVzLCBpdCB3YXMgYW4g ZXllLW9wZW5lciB3aGVuIEkgZmlndXJlZCBpdCBvdXQuICAgQmUNCj4gYXdhcmUgdGhhdCwNCj4g PiA+ID4gdGhvdWdoDQo+ID4gPiA+ID4gc29tZQ0KPiA+ID4gPiA+ID4gPiBleHRlcm5hbCBzb3Vy Y2VzIChlLmcuLCBJVFUgc3RhbmRhcmRzKSBhcmUgc3VwcG9ydGVkLCBtYW55DQo+IGFyZQ0KPiA+ ID4gPiA+ID4gPiBub3QsIGFuZCBzbyBoYW5kLSBjb2RpbmcgdGhlIDxyZWZlcmVuY2U+IGlzIHN0 aWxsIHNvbWV0aW1lcw0KPiA+ID4gPiByZXF1aXJlZC4uLg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBLZW50IC8vIHNoZXBoZXJkDQo+ID4gPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4NCg0K From nobody Tue May 14 19:54:28 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1189120127; Tue, 14 May 2019 19:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 4MuLi6bg37uJ; Tue, 14 May 2019 19:54:03 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 F28CB1201D0; Tue, 14 May 2019 19:54:02 -0700 (PDT) Received: from LAPTOPR7T053C2 ([71.178.248.224]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1M6DvY-1hK7Hq1pUG-006dFd; Wed, 15 May 2019 04:53:58 +0200 From: "Alexander Clemm" To: "'Daniele Ceccarelli'" , Cc: , , References: In-Reply-To: Date: Tue, 14 May 2019 19:53:52 -0700 Message-ID: <043d01d50ac9$710eb070$532c1150$@clemm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_043E_01D50A8E.C4B27080" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIX4Hao3662Ojb5sUX1GhdIgG7VPqXlc/bA Content-Language: en-us X-Provags-ID: V03:K1:RHK5NVZ8+kA2vDXXzHhtRAoUUfKtHGu1xX+Sxbc0I68VMqkLBpD 0u9VFOD7deGgccsnwBH2BWyqlDRVnO6SiKxyOqy0PO6BdvKr6bNqzVfrChOicFjgEi0nwxg MUTAfcZ2negrOEHzEGATpdq58DIjCi9KwyBOIvAw7xevTwUFWjYq7wwsVoS72F8lx4OUeip SyHUsyOQYVOBtK5PW/3LA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Dz8gmBzMHj8=:fYALs2uD1Otzh/Gkkdppf8 0zApgCOi7M1qJm6GtgIhULanfSisk2am+4b5aP5NHzP2G5JTdV4A5pIxgdGsvUz3c0loIm4pC EBjKbK8Zg7gluID7retTuPUjEC2tWF1G4ctpIJTRStQ/XuzX1VFQqOXrp27P7Hw6lpk0FhQM6 1NJI1a6tnzRLRAkeGHWGPsUAh2BdEa6z/3Oy5UbnqFURNdVUX4PJC4YMEWcexTBtdmddhFNDh 2wyqF8aikkG6VKl7lOX0zfbHySVGNGhTSpm5eU61rCASSEjqc6JMsUDyaja9AjmJra09jWVYF gOpDzlwJs1qZGXcns/Z/d4/yuN446HHQvn7FWXu91JflFxh5h9+zY+VRpxZovtz8+YjLlI9ub zsf7sUv3yz/H0UDLzbzPx8hEwcPdI/RcJW4Y1E3yzVkzU4qddl5N/guVGW/vNSvm6J08dM+pO ks6p7ZF6RqvSasTsE756i8kv7XiZlwAUKDbBU4aJSxPgSvZFEycJJods9tJSQwQGeQhjX7+zN P1PUV8eEkOgiZ1RNwCfRelUHaCbhfFL9YFH0uO5pqY5hWihKPgcim1eYYgUz+B48iWTRQ6xPR ULIbZMLMukMTlWEWjXlQLR1CmHQ5Tp6I+va8bMBBbDMo+nlShj9c30ACfh8PvgPXoTPdSAMCG 7lMPTwrZP6GQaBmGPTFUvVy+OYiCjQt76EGksCW9l7ebhE7dH/V2xB5X4Fvn3XAY3oEAuTVVb RxMWc3yVyfwRYJXG9E+Vm0WVQI1Z/oNqG3ui2zBbPcymogPCL2mPvgXJcro= Archived-At: Subject: Re: [RTG-DIR] [netconf] RtgDir review: draft-ietf-netconf-yang-push-22 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 02:54:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_043E_01D50A8E.C4B27080 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Daniele, =20 Thank you for your review! Responses inline, . Updates will be = reflected in -24, to be published shortly. =20 =20 Kind regards --- Alex =20 From: netconf On Behalf Of Daniele Ceccarelli Sent: Tuesday, April 30, 2019 12:24 PM To: (rtg-ads@ietf.org) Cc: rtg-dir@ietf.org; draft-ietf-netconf-yang-push.all@ietf.org; = netconf@ietf.org Subject: [netconf] RtgDir review: draft-ietf-netconf-yang-push-22 =20 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-netconf-yang-push-22 Reviewer: Daniele ceccarelli=20 Review Date: 2019-04-30 IETF LC End Date:=20 Intended Status: Standards Track Summary:=20 * This document is basically ready for publication, but has nits that = should be considered prior to publication. Comments: * The draft is well structured and covers a lot of different aspects of = the proposed method. I only have some concerns on readability and = quality of English. A review from a mother tongue would improve it = significantly. (maybe the RFC editor should be enough). Major Issues: * No major issues found Minor Issues: * Number of authors on the front page: shouldn=E2=80=99t it be 5 max? Several of the authors have graciously agreed to step down and be = listed as contributors. * Section 3: =E2=80=9CThis solution supports dynamic as well as = configured subscriptions to updates of datastore node=E2=80=9D. What = does dynamic and configured mean? It=E2=80=99s probably defined in other = documents?=20 Yes, these are defined in the Subscribed Notifications draft = which YANG-Push builds on, as explained in the Introduction. * Section 3.2. =E2=80=9CHowever, there are no guarantees that subsequent = requests which consider these hints will be accepted.=E2=80=9D What = happens then? Undefined number of retries? It is up to the client application. When making a subsequent = request, it should presumably =E2=80=9Clower=E2=80=9D its demands. The = idea of the hint is to provide an idea which request would result in a = load that is still acceptable, a =E2=80=9Cpoor man=E2=80=99s = negotiation=E2=80=9D if you will that will reduce the number of retries = that might otherwise result. * 3.5.1. Periodic Subscriptions:=E2=80=9DIn a periodic subscription, = the data included as part of an update record corresponds to data that = could have been read using a retrieval operation.=E2=80=9D. Is it not = possible to have periodic subscriptions with just the delta between the = previous update and the last one? Everything needs to be sent at any = time?=20 In that case, you would request an on-change subscription. In = case of a high rate of changes, the dampening period will in effect = result in periodic updates of changes only. =20 Nits: * Abstract: suggest to change =E2=80=9Ccontinuous, customized=E2=80=9D = with =E2=80=9Ccontinuous and customized=E2=80=9D. see next bullet item * Maybe it=E2=80=99s better to change the first sentence entirely. How = about: =E2=80=9C This document describes a mechanism that allows = subscriber applications requesting a continuous and customized stream of = updates from a YANG datastore.=E2=80=9D This sounds fine to me. Perhaps we have edited the sentence too = much in the past. I am making the change, but replacing = =E2=80=9Crequesting=E2=80=9D with =E2=80=9Cto request=E2=80=9D, to read = =E2=80=9CThis document describes a mechanism that allows subscriber = applications to request a continuous and customized stream of updates = from a YANG datastore.=E2=80=9D * =E2=80=9CTraditional approaches to providing=E2=80=9D, = shouldn=E2=80=99t this be =E2=80=9Cto provide=E2=80=9D or =E2=80=9Cof = providing=E2=80=9D? OK, change made * Polling incurs significant latency. This latency prohibits many = application types. =E2=80=93 Also this sentence doesn=E2=80=99t look = very correct. Actually the entire section can be improved from a = language perspective. (e.g. =E2=80=9Cyet for which applications need to = be quickly notified whenever a change does occur with minimal = delay.=E2=80=9D) Prefer to keep as-is at this point. Would leave copy edits to = RFC-editor. * [I-D.draft-ietf-netconf-subscribed-notifications] usually a more = friendly reference is used, e.g. [SUB-NOT] Keeping this as-is, as this will be replaced by the corresponding = RFC reference anyhow. BR Daniele =20 =20 ------=_NextPart_000_043E_01D50A8E.C4B27080 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello Daniele,

 

Thank you = for your review!  Responses inline, <ALEX>.  Updates = will be reflected in -24, to be published shortly.  =

 

Kind regards

--- = Alex

 

From: netconf = <netconf-bounces@ietf.org> On Behalf Of Daniele = Ceccarelli
Sent: Tuesday, April 30, 2019 12:24 = PM
To: <rtg-ads@ietf.org> (rtg-ads@ietf.org) = <rtg-ads@ietf.org>
Cc: rtg-dir@ietf.org; = draft-ietf-netconf-yang-push.all@ietf.org; = netconf@ietf.org
Subject: [netconf] RtgDir review: = draft-ietf-netconf-yang-push-22

 

H= ello,

I= have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see <= a href=3D"http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir">=E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/Rtg= Dir<= o:p>

A= lthough these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft.

D= ocument: draft-ietf-netconf-yang-push-22
Reviewer: Daniele = ceccarelli 
Review Date: 2019-04-30
IETF LC End Date: =
Intended Status: Standards Track

Summary: 

  • This document is basically ready for publication, but has = nits that should be considered prior to = publication.

Comments:

  • The draft is well structured and covers a lot of different = aspects of the proposed method. I only have some concerns on readability = and quality of English. A review from a mother tongue would improve it = significantly. (maybe the RFC editor should be = enough).

Major Issues:

  • No major issues found

Minor Issues:

  • Number of authors on the front page: shouldn=E2=80=99t it be = 5 max?

<ALEX> Several of the = authors have graciously agreed to step down and be listed as = contributors. </ALEX>

  • Section 3: =E2=80=9CThis solution supports dynamic as well as = configured subscriptions to updates of datastore node=E2=80=9D. What = does dynamic and configured mean? It=E2=80=99s probably defined in other = documents?

<ALEX> Yes, these are = defined in the Subscribed Notifications draft which YANG-Push builds on, = as explained in the Introduction.  = </ALEX>

  • Section 3.2. =E2=80=9CHowever, there are no guarantees that = subsequent requests which consider these hints will be = accepted.=E2=80=9D What happens then? Undefined number of = retries?

<ALEX> It is up to = the client application.  When making a subsequent request, it = should presumably =E2=80=9Clower=E2=80=9D its demands.  The idea of = the hint is to provide an idea which request would result in a load that = is still acceptable, a =E2=80=9Cpoor man=E2=80=99s negotiation=E2=80=9D = if you will that will reduce the number of retries that might otherwise = result.  </ALEX>

  • 3.5.1.  Periodic Subscriptions:=E2=80=9DIn a periodic = subscription, the data included as part of an update record corresponds = to data that could have been read using a retrieval operation.=E2=80=9D. = Is it not possible to have periodic subscriptions with just the delta = between the previous update and the last one? Everything needs to be = sent at any time?

<ALEX> In that case, = you would request an on-change subscription.  In case of a high = rate of changes, the dampening period will in effect result in periodic = updates of changes only. </ALEX> 

Nits:

  • Abstract: suggest to change =E2=80=9Ccontinuous, = customized=E2=80=9D with =E2=80=9Ccontinuous and = customized=E2=80=9D.

<ALEX> see next = bullet item </ALEX>

  • Maybe it=E2=80=99s better to change the first sentence = entirely. How about: =E2=80=9C  This document describes a mechanism = that allows subscriber applications requesting a continuous and = customized stream of updates from a YANG = datastore.=E2=80=9D

<ALEX> This sounds = fine to me. Perhaps we have edited the sentence too much in the = past.  I am making the change, but replacing = =E2=80=9Crequesting=E2=80=9D with =E2=80=9Cto request=E2=80=9D, to read = =E2=80=9CThis document describes a mechanism that allows = subscriber applications to request a continuous and customized stream of = updates from a YANG datastore.=E2=80=9D = </ALEX>

  • =E2=80=9CTraditional approaches to providing=E2=80=9D, = shouldn=E2=80=99t this be =E2=80=9Cto provide=E2=80=9D or =E2=80=9Cof = providing=E2=80=9D?

<ALEX> OK, change = made </ALEX>

  • Polling incurs significant latency. This latency prohibits = many application types. =E2=80=93 Also this sentence doesn=E2=80=99t = look very correct. Actually the entire section can be improved from a = language perspective. (e.g. =E2=80=9Cyet for which applications need to = be quickly notified whenever a change does occur with minimal = delay.=E2=80=9D)

<ALEX> Prefer to keep = as-is at this point.  Would leave copy edits to RFC-editor.  = </ALEX>

  • [I-D.draft-ietf-netconf-subscribed-notifications] usually a = more friendly reference is used, e.g. = [SUB-NOT]

<ALEX> Keeping this = as-is, as this will be replaced by the corresponding RFC reference = anyhow.  </ALEX>

BR

Daniele 

 

------=_NextPart_000_043E_01D50A8E.C4B27080-- From nobody Fri May 17 15:05:23 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2E0120169; Fri, 17 May 2019 15:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 5a41JWp3-uQ4; Fri, 17 May 2019 15:05:19 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 43DFC12001B; Fri, 17 May 2019 15:05:19 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id k24so9794488qtq.7; Fri, 17 May 2019 15:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TERKtv6qRwCot4VZv42OEqkZkNrlkuWEKkFkcjV1cU0=; b=AqR8nM6Ec5rBRRzN099whvEVmSAcvMz3lOE40msfMiHXQF1hnIyUOIAYgkmirrooOy Y+mb+B5VM4D0bMLRCtBWZDj0MxMTpWwXT6Cg+VxxPe2oxi1wo/pBP8vrKIKe6GaIhsdX HtlAfd6JiDlLt6ss0EWS4xg6UB/qb9lpFFEUUnQw9m+dKEr/GqTRV8lFAh1CTEIYRJfP 8mlg8H/ljiWqcV6q5lSCpbLNJvWnU8kn4n9duZoZGzyXlmc00tvF5RjEwZnlu1LN4YmL /B7D3KYiqkmEiibyfHRVtUNJfGrRrTmF8s5lR5knn7lDT+aqSEAixc79h3qVpsdB826J Vbcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TERKtv6qRwCot4VZv42OEqkZkNrlkuWEKkFkcjV1cU0=; b=ioGlMCLJQXCaTmxjyYWTqPAyAwwx2/WuaIBgWf9hR81FX990xKDOtF+Ixqk+zMw5Rp bD5E0pM4DfprAMWWdiExUXAkkoZC1aWkFK+L2o6WzuufC1lP32a+2z9dVwN8ZmQnoixs V/w2WTuyDsI8AOYxNSRku0YHloQP3Yh4du0XQxeXem8oojlORsa9p0Iqq2ndwKhG6ziP 77Rfh36DveuZTc1jT4dvOGOvpfwiRqSNDQH9lOkx7uPeUdhCbSkIZI+2Ztzw6lKlTGFo Zq7z4n19+7aaUE4hzX+9tn2t/rdy2qJhRjea1fx/2gVnGnl1GbqG/Zu3+Pare0IZAKOk +vwQ== X-Gm-Message-State: APjAAAUSoakBqN0qZZoaFB/FHhCG5g1w3XAaUSqU8uN3usN7N7K7gGfV HchR2fLi+53C97lBvLAxER66PRZr2EFvcKe/1Bs= X-Google-Smtp-Source: APXvYqxsSwmsB4wo0kDuI1+mMVnyUNSMUrNvLKXUhYvWL1bYU6DQWWXPltR3ONcudiHuxW/3UttwJVvfafSbCZkNGZI= X-Received: by 2002:a0c:aed4:: with SMTP id n20mr48616655qvd.195.1558130718401; Fri, 17 May 2019 15:05:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Chris Bowers Date: Fri, 17 May 2019 17:02:13 -0500 Message-ID: To: N.Leymann@telekom.de Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-rtgwg-enterprise-pa-multihoming@ietf.org, RTGWG Content-Type: multipart/alternative; boundary="000000000000fbe83505891c9392" Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-rtgwg-enterprise-pa-multihoming-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 22:05:22 -0000 --000000000000fbe83505891c9392 Content-Type: text/plain; charset="UTF-8" Nic, Thanks for the review. We have uploaded a new revision (-08) addressing your comments as well as comments from Martin Vigoureux. Below is a summary of the changes. ==== We addressed your comment about the title by adding "IPv6" to the title. ==== We addressed your comment about convergence after failures by adding the following text. Multihoming with PA addresses and NAT has created the expectation of a fairly quick and simple recovery from network failures. Alternatives should to be evaluated in terms of the speed and complexity of the recovery mechanism. ==== In response to feedback from Martin, we modified the last paragraph of the introduction to bring it up to date with the current text, and to make it clearer that although section 3 uses the concepts of source-prefix-scoped routing advertisements and forwarding tables without stopping to provide a precise description of how source-prefix-scoped routing advertisements are used to generate source-prefix-scoped forwarding tables, the reader can find the more detailed description in section 4. ==== In the process of cleaning up the ID-Nits, we discovered that RFC3315, RFC4242, and RFC3736 have all been obsoleted by RFC8415, so we adjusted those references appropriately, ==== After a discussion with David Lamparter in Prague, I removed text that equivocates about the functional equivalence of the forwarding behavior described in this draft compared to that described in draft-ietf-rtgwg-dst-src-routing. ==== We fixed a large number of spelling and grammatical errors pointed out by Martin. ==== Thanks, Chris On Fri, Feb 22, 2019 at 10:37 AM wrote: > Hi, > > > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks > > to review all routing or routing-related drafts as they pass through IETF > last call and IESG review, > > and sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. > > For more information about the Routing Directorate, please see > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could > > consider them along with any other IETF Last Call comments that you > receive, and strive to resolve them > > through discussion or by updating the draft. > > > > Document: draft-ietf-rtgwg-enterprise-pa-multihoming-07 > > Reviewer: Nicolai Leymann > > Review Date: 19/02/19 > > IETF LC End Date: date-if-known > > Intended Status: Informational > > Summary: > > This document is basically ready for publication, but has nits that should > be considered prior to > > publication. > > Comments: > > The draft is in good shape and describes a real world problem. The problem > description is clear > > as well as the solution to. > > > > As a general remark the interesting questions remains if typical > enterprise networks will > > move to one of the solutions described in the draft of if they will stay > with a more "classical" > > approach like IPv6 prefix translation (because it's more in line with > their IPv4 scenario). I agree > > that any type of address translation causes problems but many enterprises > are concerned about > > internal IP addresses exposed to the external world. > > > > Section 3: > > There might be also some expectations regarding convergence times if one > of the SER fails. > > Some mechanisms (e.g. pure prefix translations) will have no > relevance/impact on other > > routers and hosts in the enterprise networks whereas with more complex > mechanisms it might > > take longer (e.g. to renumber or make sure that all systems are using > the new source address). > > > > Major Issues: > > "No major issues found." > > > > Minor Issues: > > "No minor issues found." > > > > Nits: > > - I am always confused if BCPs are referenced but never explicitly listed > with a related tag > > in the list of references. But I guess that's a general problem :) > > - Document title and the introduction are IP version agnostic (reading the > introduction it can be > > assumed that the solution is valid for IPv4 and IPv6, but the document > only addresses IPv6). > > - The need for connection re-establishment depends also on the protocol > (TCP vs. QUIC). > > > > Regards > > Nic > > > > > > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --000000000000fbe83505891c9392 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nic,

Thanks for the review.= =C2=A0 We have uploaded a new revision (-08) addressing your comments as we= ll as comments from Martin Vigoureux.

= B= elow is a summary of the changes.

=3D= =3D=3D=3D
We addressed your comment about the title by = adding "IPv6" to the title.
=3D=3D=3D=3D
We addressed your comment about convergence after failures by addin= g the following text.
   Multihoming with PA
   addresses and NAT has created the expectation of a fairly quick and
   simple recovery from network failures.  Alternatives should to be
   evaluated in terms of the speed and complexity of the recovery
   mechanism.
<= /span>
=3D=3D=3D=3D
In response to feedback from M= artin, we modified the last paragraph of the introduction
=
to bring it up to date with the current text, and to make it clearer th= at although section 3 u= ses
=
the concepts of source-pr= efix-scoped routing advertisements and forwarding tables without stopping
to provide a precise description of how source-prefix-scoped routing advertisem= ents are used to
generate sourc= e-prefix-scoped forwarding tables, the reader can find the more detailed de= scription in
section 4.
<= /span>
=3D=3D=3D=3D
In the process of cleaning up = the ID-Nits, we discovered that=20 RFC3315, RFC4242, and RFC3736 have
all been obsoleted by RFC8415, so we adjusted those references = appropriately,
=3D=3D=3D=3D
= After a discussion with David Lamparter in Prague, I removed text that equivocates
about the functional equ= ivalence of the forwarding behavior described
in this draf= t compared to that described in draft-ietf-rtgwg-dst-src-routing.=C2=A0
=3D=3D=3D=3D
We fixed a large number o= f spelling and grammatical errors pointed out by Martin.
<= span style=3D"font-size:11pt;font-family:"Calibri",sans-serif">= =3D=3D=3D=3D
Thanks,
Chris
=


= On Fri, Feb 22, 2019 at 10:37 AM <N.Leymann@telekom.de> wrote:

Hi,

=C2=A0

I have been selected as the Rou= ting Directorate reviewer for this draft. The Routing Directorate seeks

to review all routing or routin= g-related drafts as they pass through IETF last call and IESG review,

and sometimes on special reques= t. The purpose of the review is to provide assistance to the Routing ADs.

For more information about the = Routing Directorate, please see

http://trac.tools.ietf.= org/area/rtg/trac/wiki/RtgDir

=C2=A0

Although these comments are pri= marily for the use of the Routing ADs, it would be helpful if you could

consider them along with any ot= her IETF Last Call comments that you receive, and strive to resolve them

through discussion or by updati= ng the draft.

=C2=A0

Document: draft-ietf-rtgwg-ente= rprise-pa-multihoming-07

Reviewer: Nicolai Leymann

Review Date: 19/02/19=

IETF LC End Date: date-if-known=

Intended Status: Informational<= u>

Summary: <= /p>

This document is basically read= y for publication, but has nits that should be considered prior to

publication.

Comments: =

The draft is in good shape and = describes a real world problem. The problem description is clear

as well as the solution to. =

=C2=A0

As a general remark the interes= ting questions remains if typical enterprise networks will

move to one of the solutions de= scribed in the draft of if they will stay with a more "classical"=

approach like IPv6 prefix trans= lation (because it's more in line with their IPv4 scenario). I agree=

that any type of address transl= ation causes problems but many enterprises are concerned about

internal IP addresses exposed t= o the external world.

=C2=A0

Section 3:=

=C2=A0 There might be also some= expectations regarding convergence times if one of the SER fails.

=C2=A0 Some mechanisms (e.g. pu= re prefix translations) will have no relevance/impact on other

=C2=A0=C2=A0routers and hosts i= n the enterprise networks whereas with more complex mechanisms it might<= /u>

=C2=A0 take longer (e.g. to ren= umber or make sure that all systems are using the new source address).

=C2=A0

Major Issues:

"No major issues found.&qu= ot;

=C2=A0

Minor Issues:

"No minor issues found.&qu= ot;

=C2=A0

Nits:

- I am always confused if BCPs = are referenced but never explicitly listed with a related tag=

=C2=A0 in the list of reference= s. But I guess that's a general problem :)

- Document title and the introd= uction are IP version agnostic (reading the introduction it can be

=C2=A0=C2=A0assumed that the so= lution is valid for IPv4 and IPv6, but the document only addresses IPv6).

- The need for connection re-es= tablishment depends also on the protocol (TCP vs. QUIC).

=C2=A0

Regards

Nic

=C2=A0

=C2=A0

=C2=A0

=C2=A0

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
--000000000000fbe83505891c9392-- From nobody Thu May 23 15:06:45 2019 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A002C12014E; Thu, 23 May 2019 15:06:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Joel Halpern via Datatracker To: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-vxlan.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Joel Halpern Message-ID: <155864919758.8626.11137277913302380197@ietfa.amsl.com> Date: Thu, 23 May 2019 15:06:37 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-bfd-vxlan-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 22:06:38 -0000 Reviewer: Joel Halpern Review result: Has Issues Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: ddraft-ietf-bfd-vxlan-07 Reviewer: your-name Review Date: date IETF LC End Date: date-if-known Intended Status: copy-from-I-D Summary: This document does not appear to be ready for publication as a Proposed Standard RFC. Major issues: The scoping of the BFD usage is unclear. In places, this looks like it is intended to be used by the underlay service provider, who will monitor the connectivity between VTEPs. In other places it seems to be aimed at monitoring individual VNIs. This is made worse when the packet format is laid out. The inner packet is an Ethernet Packet with an IP packet (with UDP, with BFD). This means that it is a tenant packet. The IP address is a tenant IP. But the diagram shows this as being the IP address of the VTEP. Which is not a tenant entity. There is further confusion as to whether the processing is driven by the VNI the packet arrived with, or the VNI is ignored. Minor Issues: N/A Nits: N/A