Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F37A130E62 for ; Thu, 14 Jun 2018 08:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=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 uxAqOyC7OL5M for ; Thu, 14 Jun 2018 08:04:04 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BEE2130E29 for ; Thu, 14 Jun 2018 08:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15852; q=dns/txt; s=iport; t=1528988644; x=1530198244; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Wz4/IHoA2ZafQEgl1HIDOOqr7CYq1130xqGZCs71DZI=; b=kK2htUlpeA3uNNeBtAqvvaXKF7NBxywTdZNcsb2ZFyv6cUxljgQKJgn7 Keybq65Bcv699tIpAfz3qoIbEPK+iB0x8ZiXsCQfHqL+tNfIfE2eHmoGE 9NW11WqPswb9Lb0FMQXbYMxdVoennk1Rluq9/nLI/L/nbk8vS74VZ/9kr E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoAQB0giJb/4wNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJTdWJ/KAqYRIF/j26Ef4F4C4FWgxYCgkUhNRcBAgEBAQE?= =?us-ascii?q?BAQJtKIUoAQEBAwEMGwZMBQsCAQgOAgIDEBoHMhQDDgIEAQ0FCIMcgRtcCKw?= =?us-ascii?q?uM4hGgWiITIFUP4EPgl4uhF+FbAKHUJE+CQKOd41AkRoCERMBgSQeATaBUnA?= =?us-ascii?q?Vgn6CIReOF2+PH4EaAQE?= X-IronPort-AV: E=Sophos;i="5.51,222,1526342400"; d="scan'208,217";a="129036821" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2018 15:04:02 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w5EF42W1009289 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Jun 2018 15:04:02 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 14 Jun 2018 11:04:02 -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.1320.000; Thu, 14 Jun 2018 11:04:01 -0400 From: "Eric Voit (evoit)" To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" , Tianran Zhou , "Zhengguangying (Walker) (zhengguangying@huawei.com)" CC: "netconf@ietf.org" Thread-Topic: [Netconf] a joint discussion on dynamic subscription Thread-Index: AdQCx01ede4gaRHPTgG2WyMdkd0r2gARka+AADD1vgAAAsT/AAACxI2AAAe7UgAABvBhUA== Date: Thu, 14 Jun 2018 15:04:01 +0000 Message-ID: <7d8930974acf4fd28b7e60a24c5d2196@XCH-RTP-013.cisco.com> References: <20180614.091828.21142123428745204.mbj@tail-f.com> <20180614.103746.8291316293283106.mbj@tail-f.com> <20180614095701.74rqetmhark3tzpd@anna.jacobs.jacobs-university.de> <20180614.153824.1029993696264171685.mbj@tail-f.com> In-Reply-To: <20180614.153824.1029993696264171685.mbj@tail-f.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.228] Content-Type: multipart/alternative; boundary="_000_7d8930974acf4fd28b7e60a24c5d2196XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] a joint discussion on dynamic subscription X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 15:04:12 -0000 --_000_7d8930974acf4fd28b7e60a24c5d2196XCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > From: Martin Bjorklund, June 14, 2018 9:38 AM > > Juergen Schoenwaelder > wrote: > > On Thu, Jun 14, 2018 at 10:37:46AM +0200, Martin Bjorklund wrote: > > > > > > Also, I think it would be useful to draw a picture that demonstrates > > > the roles: > > > > > > subscriber/client receiver > > > | ^ > > > | (1) | (3) > > > | | > > > | | > > > v (2) | > > > server ----------> publisher > > > > > > (1) is creation of the subscriptionE; dynamic or configured > > > (2) is implementation specific > > > (3) is the delivery of notifications / event records > > > > > > NOTE: the subscriber and receiver MAY be the same entity > > > NOTE: for some transports, if (1) is dynamic, (3) is sent over the > > > same session as (1) > > > NOTE: for some transports, the sevrer and publisher are the same > > > entity > > > > So why do we need the distinct role of a publisher? I would argue that the server and publisher are the same (see below for why= ). If this is true perhaps we could define the term "distributed publisher= " which matches to the term "Subscribed Domain" in draft-ietf-netconf-udp-p= ub-channel. A distributed publisher would be a type of publisher, inheriti= ng all requirements for that device from subscribed-notifications. If this is acceptable, then (2) is an implementation detail which can be hi= dden. This addresses Juergen's comment that having (2) inserts error condi= tions which might need to be understood by the outside world. My mental m= odel for udp on mult-linecard (when building on the terminology of subscri= bed-notifications) would be something like: subscriber receiver | ^ ^ | (1) | (3) | | | | .---V-------------|-----|-------. | .------. .-------. .-------. | | |master| | agent | | agent | | | '------' '-------' '-------' | | distributed publisher | '-------------------------------' Note that this is very close to figure 1 of the UDP draft. The difference = is that it gets rid of the 's' in Agents and Receivers. And turns subscrib= ed domain into a single publisher. This allows the hiding of error states = between master and agent. Note that this is different than the distribution of terms within draft-zho= u-netconf-multi-stream-originators. And some work would be needed there to= merge the terminology. > > > If we can agree on an architectural picture like this, the different > > > transport docs can refer to this architecture and be defined related > > > to it. For example, the netconf transport doc can state that the > > > publisher is always the same entity etc. > > > > So we introduce the role of a publisher because of some transports > > that do have a server? > > I assume you mean "do not". Yes, that's my understanding. But I might b= e > wrong. Eric and Alex? The term "server" is only used once in draft-ietf-netconf-udp-pub-channel. = And then it refers to "push server". I am assuming the "push server" is = a publisher. Based on this, I do believe we can get away from using the te= rm "server". Eric > > If the publisher is truely distinct entity from the server (and the > > state it has), we may get interesting security considerations to > > write. > > Isn't this what the UDP transport does? It uses a NETCONF/RESTCONF serve= r > to set up the subscription, then UDP to send the notifications. > > > /martin --_000_7d8930974acf4fd28b7e60a24c5d2196XCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> From: Martin Bjorklund, June 14, 2018 9:38 A= M

>

> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:=

> > On Thu, Jun 14, 2018 at 10:37:46AM += ;0200, Martin Bjorklund wrote:

> > >

> > > Also, I think it would be useful t= o draw a picture that demonstrates

> > > the roles:

> > >

> > >       subscriber/client&nbs= p;   receiver

> > >         &nbs= p; |            = ;       ^

> > >         &nbs= p; | (1)           &= nbsp;   | (3)

> > >         &nbs= p; |            = ;       |

> > >          &nb= sp;|            = ;       |

> > >         &nbs= p; v        (2)    &= nbsp;   |

> > >         server&nb= sp; ----------> publisher

> > >

> > > (1) is creation of the subscriptio= nE; dynamic or configured

> > > (2) is implementation specific

> > > (3) is the delivery of notificatio= ns / event records

> > >

> > > NOTE: the subscriber and receiver = MAY be the same entity

> > > NOTE: for some transports, if (1) = is dynamic, (3) is sent over the

> > >      = ; same session as (1)

> > > NOTE: for some transports, the sev= rer and publisher are the same

> > > entity

> >

> > So why do we need the distinct role of = a publisher?

 

I would argue that the server and publisher are t= he same (see below for why).  If this is true perhaps we could define = the term “distributed publisher” which matches to the term R= 20;Subscribed Domain” in draft-ietf-netconf-udp-pub-channel.  A distributed publisher would be a type of publisher, inheriting all requi= rements for that device from subscribed-notifications.

 

If this is acceptable, then (2) is an implementat= ion detail which can be hidden.  This addresses Juergen’s commen= t that having (2) inserts error conditions which might need to be understoo= d by the outside world.   My mental model for udp on mult-linecard  (when building on the terminology of subscribed= -notifications) would be something like:

 

       subscriber    &= nbsp;   receiver

           | = ;            ^  = ;   ^

           | (1)&= nbsp;        | (3) |

            = |             |=     |

        .---V-------------|-----|----= ---.

       | .------.  .-------. .--= -----. |

       | |master|  | agent | | a= gent | |

        | '------'  '-------' '-= ------' |

       |    distribute= d  publisher     |

        '----------------------------= ---'

 

Note that this is very close to figure 1 of the U= DP draft.  The difference is that it gets rid of the ‘s’ i= n Agents and Receivers.  And turns subscribed domain into a single pub= lisher.  This allows the hiding of error states between master and agent.

 

Note that this is different than the distribution= of terms within draft-zhou-netconf-multi-stream-originators.  And som= e work would be needed there to merge the terminology.

 

> > > If we can agree on an architectura= l picture like this, the different

> > > transport docs can refer to this a= rchitecture and be defined related

> > > to it.   For example, th= e netconf transport doc can state that the

> > > publisher is always the same entit= y etc.

> >

> > So we introduce the role of a publisher= because of some transports

> > that do have a server?

>

> I assume you mean "do not".  = Yes, that's my understanding.  But I might be

> wrong.  Eric and Alex?

 

The term “server” is only used once i= n draft-ietf-netconf-udp-pub-channel.   And then it refers to = 220;push server”.  I am assuming the “push server” i= s a publisher.  Based on this, I do believe we can get away from using= the term “server”.

Eric

 

> > If the publisher is truely distinct ent= ity from the server (and the

> > state it has), we may get interesting s= ecurity considerations to

> > write.

>

> Isn't this what the UDP transport does? = ; It uses a NETCONF/RESTCONF server

> to set up the subscription, then UDP to send= the notifications.

>

>

> /martin

--_000_7d8930974acf4fd28b7e60a24c5d2196XCHRTP013ciscocom_--