Subject: Re: [Netconf] Anyone want just Configured Subscriptions? (was RE: LC on subscribed-notifications-10)

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 2 Jul 2018 22:50:27 +0000

I am closing this question.  All votes are for Option 2, which is reflected in the current draft.

Eric

From: Andy Bierman, June 25, 2018 1:22 PM

On Mon, Jun 25, 2018 at 5:45 AM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

To be clear, we’re discussing conformance requirements.  Options are:

   1: dynamic: MAY
       configured: MAY

   2: dynamic: MUST
        configured: MAY

I support this option (I think this is in the draft now).
The configured subscriptions are likely less interoperable at this point because
the protocol, transport, and encoding could be proprietary.  There are also
call-home issues (magic proprietary port X means plain call-home,
magic port Y means subscription call-home).

The dynamic subscription is much more constrained by the NETCONF or RESTCONF
protocols, so it is more likely to be consistent across server implementations.

There is no extra burden for supporting an RPC in addition to edit-config.
(As edit-config itself is an RPC.) The RPC does not introduce parameters
that are not already in the configured subscriptions.

Andy

   3: dynamic: MAY
        configured: MUST

   4: dynamic: MUST
        configured: MUST

I don’t really care, as long as there is a good reason for it.

Kent // contributor

On Jun 24, 2018, at 7:42 AM, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:
Hello all,

this poll seems to ask only for "yes" votes, but maybe I am missing something obvious here, but I am also new to the domain of netconf.

In any case, I would like to voice a strong no wrt "only Configured Subscriptions". In complement, I would like to voice a strong yes wrt "Dynamic Subscriptions are not turned into an optional feature".

Drop-shipping or enrollment of YANG datastores should support resilient rendezvous, join or discovery prodedures. I am aware of call home and this seems to be an excellent lightweight basis to build more complex solutions on that will benefit significantly from available dynamic subscription features.

Viele Grüße,

Henk
On June 23, 2018 7:50:33 AM GMT+02:00, "Eric Voit (evoit)" <evoit=40cisco.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__40cisco.com&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=6F3EmGQsbc6Pw0-388AClIWIuFSd8lJgeV1wTTBcqy4&s=fayskuGFUwaicBmdSM3jKsn4WctY15g1FRQuJrZcd7I&e=>@dmarc.ietf.org<http://dmarc.ietf.org>> wrote:
Per below, Kent is interested to know if anyone wants to support a Publisher of just Configured Subscriptions.   This would turn Dynamic Subscriptions into an optional feature.

So does anyone want this?  If a few people say yes, I will tweak the document.

Eric

<Kent8> I understand that supporting dynamic subscriptions is currently a requirement.  I am challenging that requirement.  Why is it a requirement?  Does it have to be a requirement?

What if an IoT device only wants to support configured subscriptions and having code to support dynamic is wasting space?    FWIW, I realize that not supporting dynamic subscriptions also means that it would be impossible to filling in gaps introduced by a reboot, but maybe that's a decision that the vendor can/should make for themselves?

<Eric9> In RFC-5277, all you have is dynamic subscriptions.  So support for that older spec by definition makes dynamic subscriptions mandatory.  Beyond that, newer specifications like RFC-7923 as well as sections of other documents like RFC-7921, section 7.6 identify dynamic subscriptions as mandatory for a subscription service.  So at least some use cases exist where such dynamic support is mandatory.

<Kent9> Does it?   I mean, this draft doesn't obsolete 5277, so it seems that server can optionally support one or the other or both, and when it supports this draft, can't it use a feature statement to limit dynamic subscriptions?

<Eric10> Per below, I am ok to make dynamic subscription support optional (even if I don’t believe this is the right decision).  Part of the fix in the YANG Model description text would be to note that either dynamic or configured must be supported.

With your IoT publisher use case above you are asserting that dynamic subscriptions are not needed for configured subscription only publishers – i.e., there are a class of publishers which have been driven by use cases not considered by the documents referenced above.  So who has documented the need configured subscription only publishers?   I can’t point to such documentation (beyond IoT case above).  Is such a possibility worth slowing down this spec?     In the end making the fix for this specification which you seem to want is itself really quite trivial: we can make both dynamic and configured subscriptions optional.  The reason I have been resisting it is that this solution (a) leads to more complexity for implementers as yet another feature would have to be advertised as optional, (b) this waters down the mandatory capabilities support of the YANG module, and (c) we would need to include some a constraint that at least one of the two optional features needs to be supported.  Also for (c) AFAIK, features don’t support the application of such constraints, so it would have to be done in the feature descriptions themselves.

I guess the text above is a long way of saying that if you assert the optional dynamic subscription is mandatory to progress the document, I will make the change.  But the change will impose complexity costs which to me are hard to justify.

<Kent10> why don't you ask the WG?  "Should we support servers having only configured subscriptions (i.e. no dynamic subscriptions)?"  FWIW, the ietf-*conf-server modules have features around both the "listen" and "call-home" subtrees.  Heck, you might think "listen" would be mandatory (per RFC 6241), but still we support the possibility of a server only supporting call-home…

<Kent9> that's a reasonable answer, but mind you that it was your IoT use-case originally.   I'd like to get other opinions.  Yes, trivial to add now, hard to add later, more flexibility for servers, almost no additional effort for clients.  FWIW, I'm planning to add a feature statement for "periodic connections" in the ietf-[net|rest]conf-client-server drafts for similar reasons, that the server just might not want to support them, and I don't want the minimal bar to be higher than needed.

<Eric10> Lets go with whatever opinions people have.  I will adapt accordingly.   Do you want me to start an independent thread?

<Kent10> yes, please ask the WG

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Tue, 3 Jul 2018 19:17:53 +0000

Since folks are leaning towards:

   dynamic: MUST
   configured: MAY

We might also consider:

   dynamic: MUST
   configured: TBD

Since the transport bindings (only needed for configured subscriptions) seem to depend on the client/server drafts, which aren't ready yet.

Kent // contributor

On 7/2/18, 6:50 PM, "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>> wrote:

Eric

   1: dynamic: MAY
       configured: MAY

   2: dynamic: MUST
        configured: MAY

Andy

   3: dynamic: MAY
        configured: MUST

   4: dynamic: MUST
        configured: MUST

Kent // contributor

Viele Grüße,

Henk
On June 23, 2018 7:50:33 AM GMT+02:00, "Eric Voit (evoit)" <evoit=40cisco.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__40cisco.com&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=6F3EmGQsbc6Pw0-388AClIWIuFSd8lJgeV1wTTBcqy4&s=fayskuGFUwaicBmdSM3jKsn4WctY15g1FRQuJrZcd7I&e=>@dmarc.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__dmarc.ietf.org&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=HWeJMn9vdaXx8aXKRl88y-y1kxIITqL4DeOrv2ykrX8&s=g9Gr4Dqd_DvMfHmlF8pBRvori_D1bd7UloKmwLO1YfE&e=>> wrote:
Per below, Kent is interested to know if anyone wants to support a Publisher of just Configured Subscriptions.   This would turn Dynamic Subscriptions into an optional feature.

Eric

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=HWeJMn9vdaXx8aXKRl88y-y1kxIITqL4DeOrv2ykrX8&s=jWWYWO3k32-6mUco2IlCaCSzMXOuQzyzGamyAcIz1tE&e=>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 3 Jul 2018 19:26:00 +0000

What do you see as the difference between MAY and TBD?      “Configured” is a defined feature.

Eric

From: Kent Watsen, July 3, 2018 3:18 PM

   dynamic: MUST
   configured: MAY

We might also consider:

   dynamic: MUST
   configured: TBD

Kent // contributor

Eric

   1: dynamic: MAY
       configured: MAY

   2: dynamic: MUST
        configured: MAY

Andy

   3: dynamic: MAY
        configured: MUST

   4: dynamic: MUST
        configured: MUST

Kent // contributor

Viele Grüße,

Henk

Eric

---

From: Kent Watsen <[email-masked]>
Date: Tue, 3 Jul 2018 20:01:12 +0000

The difference being that we don't define any support for configured subscriptions now - not even a "feature" statement.  We just do what's needed for dynamic subscriptions now.

Kent

On 7/3/18, 3:26 PM, "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>> wrote:

Eric

   dynamic: MUST
   configured: MAY

We might also consider:

   dynamic: MUST
   configured: TBD

Kent // contributor

Eric

   1: dynamic: MAY
       configured: MAY

   2: dynamic: MUST
        configured: MAY

Andy

   3: dynamic: MAY
        configured: MUST

   4: dynamic: MUST
        configured: MUST

Kent // contributor

Viele Grüße,

Henk

Eric

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 3 Jul 2018 21:16:08 +0000

Really, this should be MAY.  This does not leave it as open-ended as TBD does.
--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Tuesday, July 03, 2018 1:01 PM
To: Eric Voit (evoit) <[email-masked]>; Andy Bierman <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Anyone want just Configured Subscriptions? (was RE: LC on subscribed-notifications-10)

Kent

Eric

   dynamic: MUST
   configured: MAY

We might also consider:

   dynamic: MUST
   configured: TBD

Kent // contributor

Eric

   1: dynamic: MAY
       configured: MAY

   2: dynamic: MUST
        configured: MAY

Andy

   3: dynamic: MAY
        configured: MUST

   4: dynamic: MUST
        configured: MUST

Kent // contributor

Viele Grüße,

Henk

Eric

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 4 Jul 2018 01:09:21 +0000

Hi Kent,

Is the client/server drafts stable or not? If it’s stable, IMHO, the dependency may not be a problem.
If not, what’s the potential risk which may be impacted by the client/server drafts?
Or can we mark an update at the head of the client/server drafts if the impact indeed happened. We always see this, right?

Regards,
Tianran

From: Netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Wednesday, July 04, 2018 3:18 AM
To: Eric Voit (evoit) <[email-masked]>; Andy Bierman <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Anyone want just Configured Subscriptions? (was RE: LC on subscribed-notifications-10)

   dynamic: MUST
   configured: MAY

We might also consider:

   dynamic: MUST
   configured: TBD

Kent // contributor

Eric

   1: dynamic: MAY
       configured: MAY

   2: dynamic: MUST
        configured: MAY

Andy

   3: dynamic: MAY
        configured: MUST

   4: dynamic: MUST
        configured: MUST

Kent // contributor

Viele Grüße,

Henk

Eric

---

From: Andy Bierman <[email-masked]>
Date: Wed, 4 Jul 2018 12:40:19 -0700

On Tue, Jul 3, 2018 at 12:17 PM, Kent Watsen <[email-masked]> wrote:

> Since the transport bindings (only needed for configured subscriptions)
> seem to depend on the client/server drafts, which aren't ready yet.
>
>
>

The "receiver" list is rather proprietary since it has nothing in it about
where or how to send packets,
such as the destination socket, protocol, or message encoding.
I don't see how configured subscriptions are useful as a standard without
these details.

Kent // contributor

Andy

>
>
>
>
> On 7/2/18, 6:50 PM, "Eric Voit (evoit)" <[email-masked]> wrote:
>
>
>
> *From:* Andy Bierman, June 25, 2018 1:22 PM
>
>
>
>
> On Mon, Jun 25, 2018 at 5:45 AM, Kent Watsen <[email-masked]> wrote:
>
>
>
> On Jun 24, 2018, at 7:42 AM, Henk Birkholz <[email-masked].
> de> wrote:
>
> Hello all,
>
> this poll seems to ask only for "yes" votes, but maybe I am missing
> something obvious here, but I am also new to the domain of netconf.
>
> In any case, I would like to voice a strong no wrt "only Configured
> Subscriptions". In complement, I would like to voice a strong yes wrt
> "Dynamic Subscriptions are not turned into an optional feature".
>
> Drop-shipping or enrollment of YANG datastores should support resilient
> rendezvous, join or discovery prodedures. I am aware of call home and this
> seems to be an excellent lightweight basis to build more complex solutions
> on that will benefit significantly from available dynamic subscription
> features.
>
> Viele Grüße,
>
> Henk
>
> On June 23, 2018 7:50:33 AM GMT+02:00, "Eric Voit (evoit)" <evoit=
> 40cisco.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__40cisco.com&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=6F3EmGQsbc6Pw0-388AClIWIuFSd8lJgeV1wTTBcqy4&s=fayskuGFUwaicBmdSM3jKsn4WctY15g1FRQuJrZcd7I&e=>
> @dmarc.ietf.org
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__dmarc.ietf.org&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=HWeJMn9vdaXx8aXKRl88y-y1kxIITqL4DeOrv2ykrX8&s=g9Gr4Dqd_DvMfHmlF8pBRvori_D1bd7UloKmwLO1YfE&e=>>
> wrote:
>
> Per below, Kent is interested to know if anyone wants to support a
> Publisher of just Configured Subscriptions.   This would turn Dynamic
> Subscriptions into an optional feature.
>
>
>
> <Kent8> I understand that supporting dynamic subscriptions is currently a
> requirement.  I am challenging that requirement.  Why is it a requirement?
> Does it have to be a requirement?
>
>
>
> What if an IoT device only wants to support configured subscriptions and
> having code to support dynamic is wasting space?    FWIW, I realize that
> not supporting dynamic subscriptions also means that it would be impossible
> to filling in gaps introduced by a reboot, but maybe that's a decision that
> the vendor can/should make for themselves?
>
>
>
> <Eric9> In RFC-5277, all you have is dynamic subscriptions.  So support
> for that older spec by definition makes dynamic subscriptions mandatory.
> Beyond that, newer specifications like RFC-7923 as well as sections of
> other documents like RFC-7921, section 7.6 identify dynamic subscriptions
> as mandatory for a subscription service.  So at least some use cases exist
> where such dynamic support is mandatory.
>
>
>
> <Kent9> Does it?   I mean, this draft doesn't obsolete 5277, so it seems
> that server can optionally support one or the other or both, and when it
> supports this draft, can't it use a feature statement to limit dynamic
> subscriptions?
>
>
>
> <Eric10> Per below, I am ok to make dynamic subscription support optional
> (even if I don’t believe this is the right decision).  Part of the fix in
> the YANG Model description text would be to note that either dynamic or
> configured must be supported.
>
>
>
> With your IoT publisher use case above you are asserting that dynamic
> subscriptions are not needed for configured subscription only publishers –
> i.e., there are a class of publishers which have been driven by use cases
> not considered by the documents referenced above.  So who has documented
> the need configured subscription only publishers?   I can’t point to such
> documentation (beyond IoT case above).  Is such a possibility worth slowing
> down this spec?     In the end making the fix for this specification which
> you seem to want is itself really quite trivial: we can make both dynamic
> and configured subscriptions optional.  The reason I have been resisting it
> is that this solution (a) leads to more complexity for implementers as yet
> another feature would have to be advertised as optional, (b) this waters
> down the mandatory capabilities support of the YANG module, and (c) we
> would need to include some a constraint that at least one of the two
> optional features needs to be supported.  Also for (c) AFAIK, features
> don’t support the application of such constraints, so it would have to be
> done in the feature descriptions themselves.
>
>
>
> I guess the text above is a long way of saying that if you assert the
> optional dynamic subscription is mandatory to progress the document, I will
> make the change.  But the change will impose complexity costs which to me
> are hard to justify.
>
>
>
> <Kent10> why don't you ask the WG?  "Should we support servers having only
> configured subscriptions (i.e. no dynamic subscriptions)?"  FWIW, the
> ietf-*conf-server modules have features around both the "listen" and
> "call-home" subtrees.  Heck, you might think "listen" would be mandatory
> (per RFC 6241), but still we support the possibility of a server only
> supporting call-home…
>
>
>
>
>
>
>
> <Kent9> that's a reasonable answer, but mind you that it was your IoT
> use-case originally.   I'd like to get other opinions.  Yes, trivial to add
> now, hard to add later, more flexibility for servers, almost no additional
> effort for clients.  FWIW, I'm planning to add a feature statement for
> "periodic connections" in the ietf-[net|rest]conf-client-server drafts
> for similar reasons, that the server just might not want to support them,
> and I don't want the minimal bar to be higher than needed.
>
>
>
> <Eric10> Lets go with whatever opinions people have.  I will adapt
> accordingly.   Do you want me to start an independent thread?
>
> [email-masked]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=HWeJMn9vdaXx8aXKRl88y-y1kxIITqL4DeOrv2ykrX8&s=jWWYWO3k32-6mUco2IlCaCSzMXOuQzyzGamyAcIz1tE&e=>
>
>
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 4 Jul 2018 20:04:40 +0000

From: Andy Bierman, July 4, 2018 3:40 PM

On Tue, Jul 3, 2018 at 12:17 PM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:
Since folks are leaning towards:

   dynamic: MUST
   configured: MAY

We might also consider:

   dynamic: MUST
   configured: TBD

The "receiver" list is rather proprietary since it has nothing in it about where or how to send packets,
such as the destination socket, protocol, or message encoding.
I don't see how configured subscriptions are useful as a standard without these details.

<Eric> Encoding and transport protocol are still set at the subscription level.  Other core elements of the subscription such as: Stream, filter, target datastore, YANG push trigger, etc. also would then be standardized.
I believe there to be value in standardizing those on elements without depending on the outcome of NETCONF call-home.  Especially as many vendors already have mechanisms for call-home in place.

The open question here is whether we mandate the NETCONF call-home work as a dependency.    If the WG wishes, we could close WGLC on Subscribed-notifications and YANG-push, and leave just NETCONF-Notif open until ietf-netconf-server completes.  But the downside would be that it would leave NETCONF transport for dynamic subscriptions undefined.

Eric

Kent // contributor

Andy

Eric

   1: dynamic: MAY
       configured: MAY

   2: dynamic: MUST
        configured: MAY

Andy

   3: dynamic: MAY
        configured: MUST

   4: dynamic: MUST
        configured: MUST

Kent // contributor

Viele Grüße,

Henk

Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Jul 2018 22:15:18 +0200

> The open question here is whether we mandate the NETCONF call-home work as a dependency.    If the WG wishes, we could close WGLC on Subscribed-notifications and YANG-push, and leave just NETCONF-N…

Who is behind the NAT?

(a) notification generator
(b) notification receiver
(c) both

For which scenario is NETCONF call-home needed?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 5 Jul 2018 16:55:42 +0200

We would need dynamic subscriptions with Netconf transport
yesterday, so for me the best solution is whatever delivers this
soon.

How about spiting just the Netconf transport draft into a document
that is good enough for dynamic subscriptions, and later updating
that to include configured subscriptions too. Would that be
possible? Faster?

Configured subscriptions are less important for us.

regards Balazs

On 7/4/2018 9:40 PM, Andy Bierman
wrote:

On Tue, Jul 3, 2018 at 12:17 PM, Kent
Watsen <[email-masked]>
wrote:

Since
folks are leaning towards:

dynamic: MUST

configured: MAY

We
might also consider:

dynamic: MUST

configured: TBD

Since
the transport bindings (only needed for configured
subscriptions) seem to depend on the client/server
drafts, which aren't ready yet.

The "receiver" list is rather proprietary since it has
nothing in it about where or how to send packets,

such as the destination socket, protocol, or message
encoding.

I don't see how configured subscriptions are useful as
a standard without these details.

Kent
// contributor

Andy

On 7/2/18, 6:50 PM, "Eric
Voit (evoit)" <[email-masked]>
wrote:

I
am closing this question.  All votes are for
Option 2, which is reflected in the current draft.

Eric

From:
Andy Bierman, June 25, 2018 1:22 PM

On Mon, Jun 25, 2018 at
5:45 AM, Kent Watsen <[email-masked]>
wrote:

To be clear, we’re
discussing conformance requirements.
Options are:

1: dynamic: MAY

configured:
MAY

2: dynamic:
MUST

configured: MAY

I support this option
(I think this is in the draft now).

The configured
subscriptions are likely less
interoperable at this point because

the protocol,
transport, and encoding could be
proprietary.  There are also

call-home issues (magic
proprietary port X means plain call-home,

magic port Y means
subscription call-home).

The dynamic
subscription is much more constrained by
the NETCONF or RESTCONF

protocols, so it is
more likely to be consistent across server
implementations.

There is no extra
burden for supporting an RPC in addition
to edit-config.

(As edit-config itself
is an RPC.) The RPC does not introduce
parameters

that are not already in
the configured subscriptions..

Andy

3: dynamic:
MAY

configured: MUST

4: dynamic: MUST

configured:
MUST

I don’t really
care, as long as there is a good
reason for it.

Kent // contributor

On Jun 24, 2018, at 7:42 AM, Henk
Birkholz <[email-masked]>
wrote:

Hello
all,

this poll seems to ask only for
"yes" votes, but maybe I am missing
something obvious here, but I am
also new to the domain of netconf.

In any case, I would like to voice a
strong no wrt "only Configured
Subscriptions". In complement, I
would like to voice a strong yes wrt
"Dynamic Subscriptions are not
turned into an optional feature".

Drop-shipping or enrollment of YANG
datastores should support resilient
rendezvous, join or discovery
prodedures. I am aware of call home
and this seems to be an excellent
lightweight basis to build more
complex solutions on that will
benefit significantly from available
dynamic subscription features.

Viele Grüße,

Henk

On June 23,
2018 7:50:33 AM GMT+02:00, "Eric
Voit (evoit)" <evoit=[email-masked]>
wrote:

Per
below, Kent is interested to
know if anyone wants to
support a Publisher of just
Configured Subscriptions.
This would turn Dynamic
Subscriptions into an
optional feature.

So
does anyone want this?  If a
few people say yes, I will
tweak the document.

Eric

<Kent8>
I understand
that supporting
dynamic
subscriptions is
currently a
requirement.  I
am challenging
that
requirement.
Why is it a
requirement?
Does it have to
be a
requirement?

What
if an IoT device
only wants to
support
configured
subscriptions
and having code
to support
dynamic is
wasting space?
FWIW, I
realize that not
supporting
dynamic
subscriptions
also means that
it would be
impossible to
filling in gaps
introduced by a
reboot, but
maybe that's a
decision that
the vendor
can/should make
for
themselves?

<Eric9>
In RFC-5277, all
you have is
dynamic
subscriptions.
So support for
that older spec
by definition
makes dynamic
subscriptions
mandatory.
Beyond that,
newer
specifications
like RFC-7923 as
well as sections
of other
documents like
RFC-7921,
section 7.6
identify dynamic
subscriptions as
mandatory for a
subscription
service.  So at
least some use
cases exist
where such
dynamic support
is mandatory.

<Kent9>
Does it?   I
mean, this draft
doesn't obsolete
5277, so it
seems that
server can
optionally
support one or
the other or
both, and when
it supports this
draft, can't it
use a feature
statement to
limit dynamic
subscriptions?

<Eric10>
Per below, I am
ok to make
dynamic
subscription
support optional
(even if I don’t
believe this is
the right
decision).  Part
of the fix in
the YANG Model
description text
would be to note
that either
dynamic or
configured must
be supported.

With
your IoT
publisher use
case above you
are asserting
that dynamic
subscriptions
are not needed
for configured
subscription
only publishers
– i.e., there
are a class of
publishers which
have been driven
by use cases not
considered by
the documents
referenced
above.  So who
has documented
the need
configured
subscription
only publishers?
I can’t point
to such
documentation
(beyond IoT case
above).  Is such
a possibility
worth slowing
down this spec?
In the end
making the fix
for this
specification
which you seem
to want is
itself really
quite trivial:
we can make both
dynamic and
configured
subscriptions
optional.  The
reason I have
been resisting
it is that this
solution (a)
leads to more
complexity for
implementers as
yet another
feature would
have to be
advertised as
optional, (b)
this waters down
the mandatory
capabilities
support of the
YANG module, and
(c) we would
need to include
some a
constraint that
at least one of
the two optional
features needs
to be
supported.  Also
for (c) AFAIK,
features don’t
support the
application of
such
constraints, so
it would have to
be done in the
feature
descriptions
themselves.

I
guess the text
above is a long
way of saying
that if you
assert the
optional dynamic
subscription is
mandatory to
progress the
document, I will
make the
change.  But the
change will
impose
complexity costs
which to me are
hard to justify.

<Kent10>
why don't you
ask the WG?
"Should we
support servers
having only
configured
subscriptions
(i.e. no dynamic
subscriptions)?"  FWIW, the ietf-*conf-server modules have features
around both the
"listen" and
"call-home"
subtrees.  Heck,
you might think
"listen" would
be mandatory
(per RFC 6241),
but still we
support the
possibility of a
server only
supporting
call-home…

<Kent9>
that's a
reasonable
answer, but mind
you that it was
your IoT
use-case
originally.
I'd like to
get other
opinions.  Yes,
trivial to add
now, hard to add
later, more
flexibility for
servers, almost
no additional
effort for
clients.  FWIW,
I'm planning to
add a feature
statement for
"periodic
connections" in
the
ietf-[net|rest]conf-client-server
drafts for
similar reasons,
that the server
just might not
want to support
them, and I
don't want the
minimal bar to
be higher than
needed.

<Eric10> Lets go with whatever
opinions people
have.  I will
adapt
accordingly.
Do you want me
to start an
independent
thread?

<Kent10>
yes, please ask
the WG

--

Sent
from my Android device with
K-9 Mail. Please excuse my
brevity.

Netconf mailing list

[email-masked]

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 5 Jul 2018 16:17:34 +0000

From: Balazs Lengyel, July 5, 2018 10:56 AM

We would need dynamic subscriptions with Netconf transport yesterday, so for me the best solution is whatever delivers this soon.
How about spiting just the Netconf transport draft into a document that is good enough for dynamic subscriptions, and later updating that to include configured subscriptions too. Would that be possible? Faster?

<Eric> If everyone is ok with doing a –bis for configured subscriptions as soon as ietf-netconf-client-server, I would be ok with making the corresponding updates.  Looking at it now, making the needed deletions to NETCONF-Notif would be very quick to do.

Then there is only one last open issue that I recall for the subscription drafts in WGLC: support for configured replay.  We will be going over that in Montreal.

Eric

regards Balazs

On 7/4/2018 9:40 PM, Andy Bierman wrote:

   dynamic: MUST
   configured: MAY

We might also consider:

   dynamic: MUST
   configured: TBD

Kent // contributor

Andy

Eric

   1: dynamic: MAY
       configured: MAY

   2: dynamic: MUST
        configured: MAY

There is no extra burden for supporting an RPC in addition to edit-config.
(As edit-config itself is an RPC.) The RPC does not introduce parameters
that are not already in the configured subscriptions..

Andy

   3: dynamic: MAY
        configured: MUST

   4: dynamic: MUST
        configured: MUST

Kent // contributor

Viele Grüße,

Henk

Eric

Netconf mailing list

--

Senior Specialist

Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Jul 2018 09:26:07 -0700

On Thu, Jul 5, 2018 at 9:17 AM, Eric Voit (evoit) <[email-masked]> wrote:

> *From:* Balazs Lengyel, July 5, 2018 10:56 AM
>
> We would need dynamic subscriptions with Netconf transport yesterday, so
> for me the best solution is whatever delivers this soon.
> How about spiting just the Netconf transport draft into a document that is
> good enough for dynamic subscriptions, and later updating that to include
> configured subscriptions too. Would that be possible? Faster?
>
>
>
> <Eric> If everyone is ok with doing a –bis for configured subscriptions as
> soon as ietf-netconf-client-server, I would be ok with making the
> corresponding updates.  Looking at it now, making the needed deletions to
> NETCONF-Notif would be very quick to do.
>
>
>
> Then there is only one last open issue that I recall for the subscription
> drafts in WGLC: support for configured replay.  We will be going over that
> in Montreal.
>
>
>

Why does there need to be a dependency on the client-server module?
The only things missing from the "receiver" list are 2 leafs (host, port).

Andy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 5 Jul 2018 16:40:00 +0000

Hi Eric,

> The open question here is whether we mandate the NETCONF call-home work as
> a dependency.    If the WG wishes, we could close WGLC on Subscribed-notifications
> and YANG-push, and leave just NETCONF-Notif open until ietf-netconf-server 
> completes.  But the downside would be that it would leave NETCONF transport
> for dynamic subscriptions undefined. 
 
Just focusing on the "downside" here, how would it be undefined?  Since it is a
*dynamic* subscription, the transport is the same as the one the client used to
connect to the server with.  Perhaps you mean that it wouldn't be possible for
the client to know (other than simply trying the establish-subscription RPC) if
SN is supported for the specific transport used between the client and the server.
For this, I believe it is sufficient for the client to look for the SN module 
in yang-library, since the yang-library response is server-specific (rfc7895bis,
Section 1, paragraph 4).  Do you agree?

Kent

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 5 Jul 2018 17:31:27 +0000

Hi Andy,

From: Andy Bierman, July 5, 2018 12:26 PM

On Thu, Jul 5, 2018 at 9:17 AM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
From: Balazs Lengyel, July 5, 2018 10:56 AM
We would need dynamic subscriptions with Netconf transport yesterday, so for me the best solution is whatever delivers this soon.
How about spiting just the Netconf transport draft into a document that is good enough for dynamic subscriptions, and later updating that to include configured subscriptions too. Would that be possible? Faster?

<Eric>  This is what was there initially.   But several people have asserted that host and port interacts poorly with call-home.

To make progress, I am ok with anything here but stalemate.   And if only supporting dynamic subscriptions results in progress, that is ok with me.

Eric

Eric

Andy

regards Balazs

   dynamic: MUST
   configured: MAY

We might also consider:

   dynamic: MUST
   configured: TBD

Kent // contributor

Andy

Eric

   1: dynamic: MAY
       configured: MAY

   2: dynamic: MUST
        configured: MAY

Andy

   3: dynamic: MAY
        configured: MUST

   4: dynamic: MUST
        configured: MUST

Kent // contributor

Viele Grüße,

Henk

Eric

Netconf mailing list

--

Senior Specialist

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Jul 2018 10:44:03 -0700

On Thu, Jul 5, 2018 at 10:31 AM, Eric Voit (evoit) <[email-masked]> wrote:

> Hi Andy,
>
>
>
> *From:* Andy Bierman, July 5, 2018 12:26 PM
>
>
>
> <Eric>  This is what was there initially.   But several people have
> asserted that host and port interacts poorly with call-home.
>
>
>

Of course it interacts poorly with CallHome, because the receiver list is
used INSTEAD of CallHome,
not with CallHome. CH is for initiating a new NC or RC session, so a
"special" version of it
that doesn't initiate a session would be a misuse.  I guess the concept of
SNMP Trap Receiver is
not that clear to the NETCONF WG.

To make progress, I am ok with anything here but stalemate.   And if only
> supporting dynamic subscriptions results in progress, that is ok with me.
>
>
>
> Eric
>
>
>
>
>

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 5 Jul 2018 18:00:47 +0000

From: Andy Bierman, July 5, 2018 1:44 PM

On Thu, Jul 5, 2018 at 10:31 AM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

Of course it interacts poorly with CallHome, because the receiver list is used INSTEAD of CallHome,
not with CallHome. CH is for initiating a new NC or RC session, so a "special" version of it
that doesn't initiate a session would be a misuse.  I guess the concept of SNMP Trap Receiver is
not that clear to the NETCONF WG.

<Eric> Agree.   Current path allows augmentation of leafrefs to NETCONF CH once client-server completes.  For our implementation, we will be augmenting in address and port now.  This will be a vendor specific augmentation of course.

Eric

Eric

Andy

Eric

Andy

regards Balazs

   dynamic: MUST
   configured: MAY

We might also consider:

   dynamic: MUST
   configured: TBD

Kent // contributor

Andy

Eric

   1: dynamic: MAY
       configured: MAY

   2: dynamic: MUST
        configured: MAY

Andy

   3: dynamic: MAY
        configured: MUST

   4: dynamic: MUST
        configured: MUST

Kent // contributor

Viele Grüße,

Henk

Eric

Netconf mailing list

--

Senior Specialist

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 5 Jul 2018 18:06:05 +0000

> -----Original Message-----
> From: Juergen Schoenwaelder <[email-masked]>
> Sent: Wednesday, July 4, 2018 4:15 PM
> To: Eric Voit (evoit) <[email-masked]>
> Cc: Andy Bierman <[email-masked]>; [email-masked]
> > The open question here is whether we mandate the NETCONF call-home
> work as a dependency.    If the WG wishes, we could close WGLC on
> Subscribed-notifications and YANG-push, and leave just NETCONF-Notif open
> until ietf-netconf-server completes.  But the downside would be that it would
> leave NETCONF transport for dynamic subscriptions undefined.
> >
> 
> Who is behind the NAT?
> 

Hi Juergen,

Short answer is (c).

The long answer is that NETCONF call-home is not needed for dynamic subscriptions.   It is just needed for configured subscriptions.    So on this thread Balazs has just suggested that we reduce draft-ietf-netconf-netconf-event-notifications just to dynamic (so that we can close on the drafts in WGLC).   After that, we would then do a -bis of draft-ietf-netconf-netconf-event-notifications as soon as client-server module completes to cover configured subscriptions.  In this case, draft-ietf-netconf-netconf-event-notifications -bis draft would support any NAT conditions supportable by NETCONF call home, which I believe will be (c).

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 5 Jul 2018 18:18:01 +0000

> From: Kent Watsen, July 5, 2018 12:40 PM
> 
> Hi Eric,
> 
> > Subscribed-notifications and YANG-push, and leave just NETCONF-Notif
> > open until ietf-netconf-server completes.  But the downside would be
> > that it would leave NETCONF transport for dynamic subscriptions undefined.
> 

I don't mean this.

> For this, I believe it is sufficient for the client to look for the SN module in
> yang-library, since the yang-library response is server-specific (rfc7895bis,

My undefined point was that leaving NETCONF-Notif open means that we don't progress sections 3, 4, 5.1, 6, 7 , & 10 of draft-ietf-netconf-netconf-event-notifications towards RFC.  These sections contain the needed requirements for dynamic subscriptions.

Balazs has proposed temporarily getting rid NETCONF configured subscriptions support to make progress.  This would result in the removal of draft-ietf-netconf-netconf-event-notifications section 5.2, 8, A.3, and section A.4.1's "subscription-started" example.  These sections would be returned with a -bis corresponding to client-server draft availability.

Eric

---

From: Kent Watsen <[email-masked]>
Date: Thu, 5 Jul 2018 18:41:36 +0000

>> asserted that host and port interacts poorly with call-home.   

The issue isn't call-home, per se, the issue is that a transport-independent
draft should leave all transport-specific details to the transport drafts.

> used INSTEAD of CallHome, not with CallHome. CH is for initiating a new NC
> or RC session, so a "special" version of it that doesn't initiate a session
> would be a misuse.

I don't follow this comment.  For configured subscriptions, the device is
definitely initiating the underlying transport connection and, in the case
of NC/RC, we've determined that the ietf-*conf-server's call-home mechanism
is appropriate.

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Jul 2018 12:16:51 -0700

> draft should leave all transport-specific details to the transport drafts.

The current "receiver" list is not usable as a standard.
IMO the need for a (host, port) tuple is not enough to require new modules,
but I do not object to removing the configured subscriptions because
they have to wait for other YANG modules.

> of NC/RC, we've determined that the ietf-*conf-server's call-home mechanism

CallHome is for initiating the NETCONF or RESTCONF protocol.
It applies to dynamic subscriptions. E.g., our server initiates a CH session
and the controller starts the session and decides what operations to send
(such as establish-subscription).

CH does not allow the client to use the TCP connection for any other
purpose.

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 5 Jul 2018 20:03:20 +0000

From: Andy Bierman, July 5, 2018 3:17 PM

CH does not allow the client to use the TCP connection for any other purpose.

<Eric> Initiating a Call Home before a dynamic subscription is absolutely fine.  Luckily this step is out of scope for the subscription drafts, as the transport session is already available when the establish-subscription comes in.

Eric

Kent // contributor

Andy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 5 Jul 2018 20:19:23 +0000

> My undefined point was that leaving NETCONF-Notif open means
> that  we don't progress sections 3, 4, 5.1, 6, 7 , & 10 of 
> draft-ietf-netconf-netconf-event-notifications towards RFC.  
> These sections contain the needed requirements for dynamic
> subscriptions.

I see, that's too bad, as I was hoping that we could just not
progress the "notif" documents at all.  Let's review these 
sections to see what's possible:

  Section 3: yes, it seems like this needs to be said.  Though I 
  think a case is missing: establish-subscription RPC cannot be 
  sent on a session on which create-subscription is active, right?

  Section 4: the first paragraph would now no longer be needed.  
  The 2nd paragraph seems like it should be moved to SN Section
  2.1.  Is the 3rd paragraph needed? - YP already requires 
  ietf-datastore to be implemented, and the nmda-netconf draft
  requires that <operational> be supported...

  Section 5.1: the first paragraph seems obvious, but also I think
  the word "deleted" is wrong, since there is nothing to delete,
  should this be rephrased?

  Section 6: the 1st paragraph seems okay.  The 2nd paragraph 
  seems okay for dynamic subscriptions, but this section applies
  to configured subscriptions too, from which there isn't an 
  "establish-subscription" - right?

  Section 7: First, it seems like much of this section (and s3.3
  in restconf-notif) could be moved to the SN draft.  That said,
  I think that the 1st paragraph should remove the reference to YP
  draft, since YP just augments the SN draft.  Regarding the 4th 
  bullet point following the first paragraph, I think that it is
  sufficient to just identify that a suitable base identity must
  be returned (i.e., lose the refs to Sections 2.4.6 and A.1).
  The 2nd paragraph seems to be defining a non-standard way to 
  encode identities (red flag).
  
  Section 10: the 1st paragraph is not a security consideration
  (move to Section 5?).  The 2nd paragraph articulates a valid
  concern, but it seems to apply to all transports (although
  missing in the restconf-notif draft) and so should be moved
  to the SN draft?  The 3rd paragraph could be removed, since it
  isn't for dynamic subscriptions.

Thoughts?

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Jul 2018 13:21:11 -0700

On Thu, Jul 5, 2018 at 1:03 PM, Eric Voit (evoit) <[email-masked]> wrote:

> *From:* Andy Bierman, July 5, 2018 3:17 PM
>
> <Eric> Initiating a Call Home before a dynamic subscription is absolutely
> fine.  Luckily this step is out of scope for the subscription drafts, as
> the transport session is already available when the establish-subscription
> comes in.
>
>
>
It is not fine according to RFC 8071.

   The techniques described in this document are suitable for network
   management scenarios such as the ones described in Section 1.1.
   However, these techniques are only defined for NETCONF Call Home and
   RESTCONF Call Home, as described in this document.

      ...Any use of call home with SSH/TLS for purposes other than NETCONF
or RESTCONF will need a thorough contextual risk assessment. ...

If your server opens a TCP connection to the client and does anything other
than
the procedures in RFC 8071, then it isn't CallHome. It is something new
that should be specified in an RFC and approved by the IETF.

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 5 Jul 2018 23:08:42 +0000

> From: Kent Watsen, July 5, 2018 4:19 PM
> 
> 
> > My undefined point was that leaving NETCONF-Notif open means that  we
> > don't progress sections 3, 4, 5.1, 6, 7 , & 10 of
> I see, that's too bad, as I was hoping that we could just not progress the "notif"
> documents at all.  Let's review these sections to see what's possible:
> 

To make it perfectly clear, I updated bullet #2 to:

It is a prohibited to accept an establish-subscription request, or send either updates or state change notifications for a configured subscription on a NETCONF session where the create-subscription RPC has successfully [RFC5277] created subscription.

>   Section 4: the first paragraph would now no longer be needed.

Yes

>   2.1.  

No, the NETCONF stream is not a MUST for non-NETCONF or non-RESTCONF publishers.  E.g.: draft-birkholz-yang-core-telemetry

>  Is the 3rd paragraph needed? - YP already requires

It could be removed as the requirement is inherited through the YANG models.  As drafts over in core are looking at YANG push for CoMI defined datastores (i.e., draft-birkholz-yang-core-telemetry), I thought it couldn't hurt to make it clear.

>   Section 5.1: the first paragraph seems obvious, 

For HTTP transport, it can be ok to lose the transport session and leave up the subscription.  (This can improve scale)   So better to make it explicit.

>   but also I think

There is a delete-subscription RPC.  Why is it wrong?

>   "establish-subscription" - right?

True.  To clarify the 2nd paragraph, tweaked the words to:

"For dynamic subscriptions, all notification messages MUST use the NETCONF transport session used by the "establish-subscription" RPC."

>   in restconf-notif) could be moved to the SN draft.

This is not the case, as the mapping is NETCONF specific.  Non NETCONF/RESTCONF transports will not necessarily use this mapping.

>   That said,
>   draft, since YP just augments the SN draft. 

There is an additional non-augmented RPC in YANG-Push:  resynch-subscription.

>  Regarding the 4th

That is the way I initially had it.  Martin requested that these be made explicit during his review.

>   encode identities (red flag).

This also was at Martin's request.  It is not non-standard as it simply describes the encoding of an error string.

>   (move to Section 5?).  

Moved into 5.2.

>  The 2nd paragraph articulates a valid
>   to the SN draft? 

As the mechanism for mitigating certain DDoS vectors is transport specific, the transport drafts seemed a better place.  

If you are good with it staying as a transport mechanism, I will add corresponding text to RESTCONF-Notif.

>   The 3rd paragraph could be removed, since it

Yes.

Eric

---

From: Kent Watsen <[email-masked]>
Date: Fri, 6 Jul 2018 22:34:28 +0000

> It is a prohibited to accept an establish-subscription request, or
> send either updates or state change notifications for a configured
> subscription on a NETCONF session where the create-subscription RPC
> has successfully [RFC5277] created subscription.

Looks okay, but without seeing it in context, it's hard to say if ideal.

> No, the NETCONF stream is not a MUST for non-NETCONF or non-RESTCONF
> publishers.  E.g.: draft-birkholz-yang-core-telemetry

I'm unsure about this, and SN draft isn't clear, as it only says:

  Beyond the "NETCONF" stream, implementations MAY define additional
  event streams.

A naïve reading of the above that is that NETCONF stream is required.

That said, I'm "unsure" because I think there is a difference between 
referring to a stream in the RPC and/or config, which are transport-
independent, and how a transport works.  My view is that the NETCONF
stream is always referenceable.  In the same way that it is available
via RESTCONF, so it will be available via CORE.  It's an unfortunate
misnomer, the "NETCONF" stream should've been called the "ALL" stream,
or something like that.

> It could be removed as the requirement is inherited through the 
> YANG models.  As drafts over in core are looking at YANG push 
> for CoMI defined datastores (i.e., draft-birkholz-yang-core-\
> telemetry), I thought it couldn't hurt to make it clear.

Generally, we find that less is more and, if it really needs to be
said, then the text should clearly indicate that it's not defining
anything new, just a product of what already is.

In this case, since I have a general objection to the notif drafts
having any reference to the YP draft, I would rather it be removed,
and a review of the other 9 references reviewed.  [generally, I
expect the text to refer to something in the SN draft that the YP
draft happens to extend (e.g., identities)]

> For HTTP transport, it can be ok to lose the transport session and 
> leave up the subscription.  (This can improve scale)   So better to
> make it explicit.

True, but this is the *netconf* notif draft, it seems obvious in
this context.  What else could an implementation do?

> There is a delete-subscription RPC.  Why is it wrong?

"MUST be deleted" sounds like configuration thing, "terminated" 
is a better word, or perhaps verbosely say it has the same
effect as the delete-subscription RPC.  [but I think it best
to remove the paragraph altogether]

> "For dynamic subscriptions, all notification messages MUST use
> the NETCONF transport session used by the "establish-subscription"
> RPC."

Thanks.

> This is not the case, as the mapping is NETCONF specific.  Non 
> NETCONF/RESTCONF transports will not necessarily use this mapping.

That's what I mean, the SN draft needs to make it a requirement
that the necessary information is provided, then each notif draft
can fill in their transport-specific details.

> There is an additional non-augmented RPC in YANG-Push:  resynch-subscription.

True (but see below)

> be made explicit during his review.

I don't agree.  YP is just one of potentially many (I exaggerate) 
layers on top of SN.  We need to ensure the language allows for
other layers to be defined in the future.  I imagine that there
should be nothing special about YP as far as the notif drafts go.

> This also was at Martin's request.  It is not non-standard as it
> simply describes the encoding of an error string.

I see that error-app-tag is defined in RFC 6241 as a string, so 
maybe there is a basis for this, but note that identities are 
encoded differently for XML and JSON.  It seems like this draft 
could declare that the value must conform to type "identity" 
and then leverage existing encoding-specific rules.  What did 
Martin say?

>>   Section 10: the 1st paragraph is not a security consideration

Thanks.

> As the mechanism for mitigating certain DDoS vectors is 
> transport specific, the transport drafts seemed a better place.  

The problem statement (1st sentence) is generic and should be
moved to the SN draft.  How to handle the issue in a generic
way, if possible, should also be in the SN draft.  Here, the
2nd sentence seems transport-specific and the 3rd transport-
independent.  However, I think that the 2nd or 3rd sentences
could be stated better (and more generically) in the SN draft,
something like this:

  Operators SHOULD monitor for such cases and, if discovered,
  take remedial action to limit the resources used, such as
  suspending or terminating a subset of the subscriptions or,
  if the underlying transport is session based, terminate the
  underlying transport session.

> If you are good with it staying as a transport mechanism, I will
> add corresponding text to RESTCONF-Notif.

I prefer a generic Security Consideration in the SN draft.

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 07 Jul 2018 12:25:39 +0200 (CEST)

"Eric Voit \(evoit\)" <evoit=[email-masked]> wrote:
> On Thu, Jul 5, 2018 at 10:31 AM, Eric Voit (evoit)
> <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Andy,
> 

[...]

> <Eric> Agree.

I am confused.  The intention is to use the "receiver" list AND call
home, right?   IMO, the "receiver" list is a transport indenpendent
construct, and depending on the transport, it is augmented with
necessary parameters; in the case of NETCONF call-home will be used.
In the case of UDP some other parameters will be used.  Etc.

/martin

> Current path allows augmentation of leafrefs to NETCONF
> CH once client-server completes.  For our implementation, we will be
> augmenting in address and port now.  This will be a vendor specific
> augmentation of course.
> 
> Eric
> 
> 
> To make progress, I am ok with anything here but stalemate.  And if
> only supporting dynamic subscriptions results in progress, that is ok
> with me.
> 
> Eric
> 
> 
> 
> 
> Andy
> 
> Eric
> 
> 
> 
> Andy
> 
> 
> On Tue, Jul 3, 2018 at 12:17 PM, Kent Watsen
> <[email-masked]<mailto:[email-masked]>> wrote:
> Since the transport bindings (only needed for configured
> subscriptions) seem to depend on the client/server drafts, which
> aren't ready yet.
> 
> 
> On 7/2/18, 6:50 PM, "Eric Voit (evoit)"
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
> On Mon, Jun 25, 2018 at 5:45 AM, Kent Watsen
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
> On Jun 24, 2018, at 7:42 AM, Henk Birkholz
> <[email-masked]<mailto:[email-masked]>>
> wrote:
> Hello all,
> 
> Drop-shipping or enrollment of YANG datastores should support
> resilient rendezvous, join or discovery prodedures. I am aware of call
> home and this seems to be an excellent lightweight basis to build more
> complex solutions on that will benefit significantly from available
> On June 23, 2018 7:50:33 AM GMT+02:00, "Eric Voit (evoit)"
> <evoit=40cisco.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__40cisco.com&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=6F3EmGQsbc6Pw0-388AClIWIuFSd8lJgeV1wTTBcqy4&s=fayskuGFUwaicBmdSM3jKsn4WctY15g1FRQuJrZcd7I&e=>@dmarc.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__dmarc.ietf.org&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=HWeJMn9vdaXx8aXKRl88y-y1kxIITqL4DeOrv2ykrX8&s=g9Gr4Dqd_DvMfHmlF8pBRvori_D1bd7UloKmwLO1YfE&e=>>
> wrote:
> <Kent8> I understand that supporting dynamic subscriptions is
> currently a requirement.  I am challenging that requirement.  Why is
> it a requirement?  Does it have to be a requirement?
> 
> What if an IoT device only wants to support configured subscriptions
> and having code to support dynamic is wasting space?  FWIW, I realize
> that not supporting dynamic subscriptions also means that it would be
> impossible to filling in gaps introduced by a reboot, but maybe that's
> a decision that the vendor can/should make for themselves?
> 
> <Eric9> In RFC-5277, all you have is dynamic subscriptions.  So
> support for that older spec by definition makes dynamic subscriptions
> mandatory.  Beyond that, newer specifications like RFC-7923 as well as
> sections of other documents like RFC-7921, section 7.6 identify
> dynamic subscriptions as mandatory for a subscription service.  So at
> least some use cases exist where such dynamic support is mandatory.
> 
> <Kent9> Does it?  I mean, this draft doesn't obsolete 5277, so it
> seems that server can optionally support one or the other or both, and
> when it supports this draft, can't it use a feature statement to limit
> dynamic subscriptions?
> 
> <Eric10> Per below, I am ok to make dynamic subscription support
> optional (even if I don’t believe this is the right decision).  Part
> of the fix in the YANG Model description text would be to note that
> either dynamic or configured must be supported.
> 
> subscriptions are not needed for configured subscription only
> publishers – i.e., there are a class of publishers which have been
> driven by use cases not considered by the documents referenced above.
> So who has documented the need configured subscription only
> publishers?  I can’t point to such documentation (beyond IoT case
> above).  Is such a possibility worth slowing down this spec?  In the
> end making the fix for this specification which you seem to want is
> itself really quite trivial: we can make both dynamic and configured
> subscriptions optional.  The reason I have been resisting it is that
> this solution (a) leads to more complexity for implementers as yet
> another feature would have to be advertised as optional, (b) this
> waters down the mandatory capabilities support of the YANG module, and
> (c) we would need to include some a constraint that at least one of
> the two optional features needs to be supported.  Also for (c) AFAIK,
> features don’t support the application of such constraints, so it
> would have to be done in the feature descriptions themselves.
> 
> optional dynamic subscription is mandatory to progress the document, I
> will make the change.  But the change will impose complexity costs
> which to me are hard to justify.
> 
> <Kent10> why don't you ask the WG?  "Should we support servers having
> only configured subscriptions (i.e. no dynamic subscriptions)?"  FWIW,
> the ietf-*conf-server modules have features around both the "listen"
> and "call-home" subtrees.  Heck, you might think "listen" would be
> mandatory (per RFC 6241), but still we support the possibility of a
> server only supporting call-home…
> 
> 
> 
> 
> 
> 
> use-case originally.  I'd like to get other opinions.  Yes, trivial to
> add now, hard to add later, more flexibility for servers, almost no
> additional effort for clients.  FWIW, I'm planning to add a feature
> statement for "periodic connections" in the
> ietf-[net|rest]conf-client-server drafts for similar reasons, that the
> server just might not want to support them, and I don't want the
> minimal bar to be higher than needed.
> 
> Mobile: +36-70-330-7909 email:
> [email-masked]<mailto:[email-masked]>
> 
>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 7 Jul 2018 06:03:17 -0700

> In the case of UDP some other parameters will be used.  Etc.
I am not a fan of standards that are useless unless and until
they are augmented with proprietary objects.

CallHome does not really work here because once it is completed
the NETCONF session is idle. The server is waiting for
the client to send an <rpc-request>.   There is nothing standard that
indicates
the client will just wait and the server will start sending notifications.

As a standard, this is unusable.
It assumes the client developer will know the magic port numbers in advance
in order to use each server (maybe port 40123 mean subscription 23 on
server X and port 40023 means a regular CallHome session. Network management
by ad-hoc port assignments seems fragile at best.

/martin

Andy

> > <[email-masked]<mailto:[email-masked]
> >>
> > wrote:
> > Hello all,
> >
> > <evoit=40cisco.com<https://urldefense.proofpoint.com/v2/
> url?u=http-3A__40cisco.com&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=
> 6F3EmGQsbc6Pw0-388AClIWIuFSd8lJgeV1wTTBcqy4&s=
> fayskuGFUwaicBmdSM3jKsn4WctY15g1FRQuJrZcd7I&e=>@dmarc.ietf.org<
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__dmarc.ietf.org&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=
> HWeJMn9vdaXx8aXKRl88y-y1kxIITqL4DeOrv2ykrX8&s=g9Gr4Dqd_DvMfHmlF8pBRvori_
> D1bd7UloKmwLO1YfE&e=>>
> > wrote:
> > https://www.ietf.org/mailman/listinfo/netconf<https://
> urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_
> mailman_listinfo_netconf&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=
> HWeJMn9vdaXx8aXKRl88y-y1kxIITqL4DeOrv2ykrX8&s=jWWYWO3k32-
> 6mUco2IlCaCSzMXOuQzyzGamyAcIz1tE&e=>
> >
> >
> >
> >

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Sat, 7 Jul 2018 14:17:48 +0000

From: Andy Bierman, July 7, 2018 9:03 AM

On Sat, Jul 7, 2018 at 3:25 AM, Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:
"Eric Voit \(evoit\)" <evoit=[email-masked]<mailto:[email-masked]>> wrote:
> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> Hi Andy,
>

[...]

<eric> I wouldn’t say proprietary objects.   From the perspective of just the subscribed-notifications draft, they would be transport specific objects.

CallHome does not really work here because once it is completed
the NETCONF session is idle. The server is waiting for
the client to send an <rpc-request>.
There is nothing standard that indicates
the client will just wait and the server will start sending notifications.

<eric> My reading of RFC 8071 section 3 is that it doesn’t specify client behavior once the transport session is up. Just that NETCONF can start. And you are correct, after is starts, it is idle.

To make that work with configured subscriptions, what the text says is:

“the first configured subscription to a specific receiver MUST establish a NETCONF transport session via NETCONF call home [RFC8071], section 4.1.  This transport session MUST then be used by additional configured subscriptions targeting that the same receiver.”

As a result, it should be possible to steer the Call Home transport session to a NETCONF port on the receiver capable of awaiting inbound notifications.  (I.e., something which could act in a role similar to SNMP trap receiver.)  To cover this, I have tweaked the to:

“the first configured subscription to a specific receiver MUST establish a NETCONF transport session via NETCONF call home [RFC8071], section 4.1.  The receiver’s NETCONF client MUST be capable of awaiting the publisher’s sending of unsolicited notification messages.  This transport session MUST also then be used by additional configured subscriptions targeting that the same receiver call home connection.”

<eric> I believe it is unnecessary to have a configured subscription per port.   Multiple subscriptions should be able to use the same transport session.    A different call home is only needed if there is an explicit reason to separate the sessions.

Eric

/martin

Andy

> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> wrote:
> Hello all,
>
> <evoit=40cisco.com<http://40cisco.com><https://urldefense.proofpoint.com/v2/url?u=http-3A__40cisco.com&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=6F3EmGQsbc6Pw0-388AClIWIuFSd8lJgeV1wTTBcqy4&s=fayskuGFUwaicBmdSM3jKsn4WctY15g1FRQuJrZcd7I&e=>@dmarc.ietf..org<http://dmarc.ietf.org><https://urldefense.proofpoint.com/v2/url?u=http-3A__dmarc.ietf.org&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=HWeJMn9vdaXx8aXKRl88y-y1kxIITqL4DeOrv2ykrX8&s=g9Gr4Dqd_DvMfHmlF8pBRvori_D1bd7UloKmwLO1YfE&e=>>
> wrote:
> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> https://www.ietf.org/mailman/listinfo/netconf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www..ietf.org_mailman_listinfo_netconf&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=HWeJMn9vdaXx8aXKRl88y-y1kxIITqL4DeOrv2ykrX8&s=jWWYWO3k32-6mUco2IlCaCSzMXOuQzyzGamyAcIz1tE&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=HWeJMn9vdaXx8aXKRl88y-y1kxIITqL4DeOrv2ykrX8&s=jWWYWO3k32-6mUco2IlCaCSzMXOuQzyzGamyAcIz1tE&e=>>
>
>
>
>
> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
>
> Balazs.Lengyel@ericsson..com<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
>
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Sat, 7 Jul 2018 14:27:15 +0000

> From: Kent Watsen, July 6, 2018 6:34 PM
> 
> 

The draft defines the NETCONF stream, and reserves the name, but does not make implementation mandatory.

> That said, I'm "unsure" because I think there is a difference between referring
> to a stream in the RPC and/or config, which are transport- independent, and
> how a transport works.  My view is that the NETCONF stream is always
> referenceable.  In the same way that it is available via RESTCONF, so it will be
> available via CORE.  It's an unfortunate misnomer, the "NETCONF" stream
> should've been called the "ALL" stream, or something like that.

Agree the historical name is unfortunate

> having any reference to the YP draft, I would rather it be removed,

Removed

> and a review of the other 9 references reviewed.  [

Reviewed.  Most are in the non-normative examples, which should be fine.  The others define proper error handling.

> generally, I

There is a new RPC, and this RPC needs error conditions mapped.

> this context.  What else could an implementation do?

While I would never suggest it, I have heard people ask if it would be possible for it to retain the state for a period of time in case the subscriber tries to reconnect.  This is why there are obvious statements sometimes --  to be very clear and preclude attempts at optimizations which might hurt interoperability.

> to remove the paragraph altogether]

Made it "terminated".  It wouldn't be the same as the RPC, as nothing can be returned to the subscriber.

> can fill in their transport-specific details.

The subscribed-notifications document is aimed first at providing requirements for implementers.  Your request provides also requirements to transport document specifiers, which is a useful, but a slightly different audience.

As a result, I updated the text from:

"Because there is no explicit association with an existing transport session, configuration operations require additional parameters beyond those of dynamic subscriptions to indicate receivers, and possibly whether the notification messages need to come from a specific egress interface on the publisher."

To:

"Because there is no explicit association with an existing transport session, configuration operations MUST include additional parameters beyond those of dynamic subscriptions to indicate each receiver, how to contact that receiver, and possibly whether the notification messages need to come from a specific egress interface on the publisher.  Some of these parameters MUST be configured via transport specific augmentations to this specification."

> layers on top of SN.  

What other layer are you expecting?

> We need to ensure the language allows for

This does not precludes additional layers for being placed.  If an implementation doesn't need an RPC, it can safely ignore the identity.  

In the end, when the WG requested that we inherit embedded NETCONF and RESTCONF error processing mechanisms, and this drove to the explicit mappings. 

> and then leverage existing encoding-specific rules.  What did

Per:
https://www.ietf.org/mail-archive/web/netconf/current/msg14345.html

  "I think you should decide on one mechanism, and use it in both
  drafts (specifically, the error-app-tag handling.  BTW, *if* you
  decide to keep it, you need to clarify what "a string that
  corresponds to" means.  Maybe use the JSON encoding of identities in
  this case (<modname>:<identityname>))."

This defined encoding works, and can be placed the same way into different types of error mechanisms.

> moved to the SN draft. 

Section 10, paragraph 2, sentence #1 is context to set up the requirements in sentence 2 & 3.  So I replicated a NETCONF independent statement in SN:

" For dynamic subscriptions, implementations need to protect against malicious or buggy subscribers which may send a large number "establish-subscription" requests, thereby using up system resources.  To cover this possibility operators SHOULD monitor for such cases and, if discovered, take remedial action to limit the resources used, such as suspending or terminating a subset of the subscriptions or, if the underlying transport is session based, terminate the  underlying transport session."

> How to handle the issue in a generic

Hopefully the text above gets us there.

Eric

---

From: Andy Bierman <[email-masked]>
Date: Sat, 7 Jul 2018 07:34:03 -0700

On Sat, Jul 7, 2018 at 7:17 AM, Eric Voit (evoit) <[email-masked]> wrote:

> *From:* Andy Bierman, July 7, 2018 9:03 AM
>
> <eric> I wouldn’t say proprietary objects.   From the perspective of just
> the subscribed-notifications draft, they would be transport specific
> objects.
>
>
>

IMO there needs to be at least 1 complete standard solution that servers
must support.
I would prefer that configured subscriptions be held back until a
fully-baked standard solution
is ready.

> <eric> My reading of RFC 8071 section 3 is that it doesn’t specify client
> behavior once the transport session is up. Just that NETCONF can start. And
> you are correct, after is starts, it is idle.
>
>
>

I don't think this fits the intent of CallHome.
IMO a new protocol is needed that is dedicated to the binary transport
of notification subscription data.

> “the first configured subscription to a specific receiver MUST establish a
> NETCONF transport session via NETCONF call home [RFC8071], section 4.1.
> This transport session MUST then be used by additional configured
> subscriptions targeting that the same receiver.”
>
>
>
> As a result, it should be possible to steer the Call Home transport
> session to a NETCONF port on the receiver capable of awaiting inbound
> notifications.  (I.e., something which could act in a role similar to SNMP
> trap receiver.)  To cover this, I have tweaked the to:
>
>
>
> “the first configured subscription to a specific receiver MUST establish a
> NETCONF transport session via NETCONF call home [RFC8071], section 4.1.
> The receiver’s NETCONF client MUST be capable of awaiting the publisher’s
> sending of unsolicited notification messages.  This transport session MUST
> also then be used by additional configured subscriptions targeting that the
> same receiver call home connection.”
>
>
>
>
>
> <eric> I believe it is unnecessary to have a configured subscription per
> port.   Multiple subscriptions should be able to use the same transport
> session.    A different call home is only needed if there is an explicit
> reason to separate the sessions.
>

OK -- it should be specified in the TBD protocol mentioned above

Andy

> fayskuGFUwaicBmdSM3jKsn4WctY15g1FRQuJrZcd7I&e=>@dmarc.ietf..org
> <http://dmarc.ietf.org><https://urldefense.proofpoint.com/v2/url?u=http-
> urldefense.proofpoint.com/v2/url?u=https-3A__www..ietf.org_
> 6mUco2IlCaCSzMXOuQzyzGamyAcIz1tE&e=
> > Balazs.Lengyel@ericsson..com <[email-masked]><mailto:
> [email-masked]>
> >
> >
>
>
>

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 07 Jul 2018 19:18:00 +0200 (CEST)

> the client will just wait and the server will start sending notifications.

I see.  But is there really anything in 6241 that prohibits this?
Wouldn't it be ok if the new netconf-notif draft specifies this
behavior?

If it can't be solved in this way, we'd have to define a new rpc
<start-all-subscribed-subscriptions>

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 7 Jul 2018 11:07:27 -0700

On Sat, Jul 7, 2018 at 10:18 AM, Martin Bjorklund <[email-masked]> wrote:

> > > > Of course it interacts poorly with CallHome, because the receiver
> list
> > > > is used INSTEAD of CallHome,

You mean <start-all-configured-subscriptions> I think. No need.
I guess this does not violate CallHome.

There is no way to tell (except by implementation) if the callhome client
can accept
<notification> messages even though it did not request them with an RPC.

Andy

> > > > the protocol, transport, and encoding could be proprietary.  There
> are
> > > > also

---

From: Kent Watsen <[email-masked]>
Date: Sat, 7 Jul 2018 23:50:31 +0000

> IMO there needs to be at least 1 complete standard solution that servers must support.
> I would prefer that configured subscriptions be held back until a fully-baked standard
> solution is ready.

This option will be discussed in Montreal.  If the WG agrees, then the below can be
discussed later.

> I don't think this fits the intent of CallHome.

RFC 8071 is very clear (see C8 and S6), the NC or RC protocol *starts*.  Also, from
https://mailarchive.ietf.org/arch/msg/netconf/QS14f-6w-BzCD9280uuO06CZK6c, I
wrote:

 That said, I have to say that I'm not entirely sure if I understand if what is
  planned is legal.  For instance, in a normal NETCONF call-home situation, the
 NETCONF session begins with both sides sending <hello> messages and then
  the server waiting for the client to send RPCs, which might include a 5277
  <create-subscription>, after which the <notifications> begin to flow.  Is this
  the same here, or are you expecting the <notification> messages to start flowing
  immediately?

> of notification subscription data.

Agreed, and I'd like that protocol to be:
  1) mandatory to implement, if the "configured" feature is enabled.
  2) run over UDP, so events can go out line cards directly.
  3) be optionally encrypted, as there are scenarios where it's safe to send unencrypted
      events to a receiver within a security perimeter, which can relay the events over an
      encrypted connection to a remote system, so as to offload the burden from the NE
      equipment to a cheaper general purpose computer.

FWIW, COAP is on top of UDP, and its use of DTLS is optional, so it seems like a good
match, though I don't know if it also needs a client-initiated RPC to start the flow of logs.
Out of curiosity, has anyone ever compared COAP to gRPC?

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Sat, 7 Jul 2018 18:00:53 -0700

On Sat, Jul 7, 2018 at 4:50 PM, Kent Watsen <[email-masked]> wrote:

> fully-baked standard

You convinced me that binary encoding of regular <rpc> message flows
is not a high priority for NETCONF.  If the device or network is that
constrained,
maybe CoMI is a better choice.  Also, use of <get> will probably diminish
as YANG Push
is available instead.

>   the same here, or are you expecting the <notification> messages to start

The problem is that the RFC allows the callhome session to be used for
normal NETCONF operations,
so the client can send <rpc> requests in XML at any time.

I suppose there is a use-case for pre-configuring the subscriptions and then
using call-home to connect to a controller that somehow knows all the
subscriptions that could be configured (so no reads required).
Since the controller needs to know about all the subscriptions anyway,
it can just all <establish-subscription>

>   1) mandatory to implement, if the "configured" feature is enabled.

I would give it its own feature

>   2) run over UDP, so events can go out line cards directly.

or run over TCP I hope

>       equipment to a cheaper general purpose computer.

This was discussed in I2RS WG and a YANG extension can be used to tag
ok-for-unencrypted, so this might get approved by the IESG.

> Out of curiosity, has anyone ever compared COAP to gRPC?

We have implemented RESTCONF over CoAP, but not with DTLS.
This was also XML and JSON, not CBOR.

I would rather let TCP deal with fragmentation instead of using CoAP Block.
IMO the new protocol will be easier to get approved (i.e., much smaller in
scope)
if CoAP is reused instead of using raw UDP.

GPB proto files have to be defined in advance.
Generic protobuffs like gNMI are not as efficient.
CBOR+SID requires no static templates, but does require that
a lot of SID state be kept. IMO the efficiency is very impressive, and
quite worth
the SID caching for YANG Push.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 08 Jul 2018 09:58:07 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> You mean <start-all-configured-subscriptions> I think.

Yes.

> No need.

Ok.

> <notification> messages even though it did not request them with an RPC.

Since it won't happen out of the blue I think it is ok - it happens
when a subscription has been configured for this client.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 08 Jul 2018 10:09:39 +0200 (CEST)

> This option will be discussed in Montreal.  If the WG agrees, then the below can be

How about prioritizing the *conf-{client,server} models so that the
netconf-notif draft can use them, so that we do get a standard
solution now?   Or do we think that these models are still far behind?

>   the same here, or are you expecting the <notification> messages to start flowing

I think it is ok to start sending <notification> messages right away.

If it is a problem, it could be protected by a new capability that the
*client* would have to advertise.  If this new capability is not
advertised, the server wouldn't send these messages.

> > of notification subscription data.

This might be true, but I think it is orthogonal to this dicsussion.
And if we build the negotiation about encoding into the <hello>
exchange, NETCONF with binary encoding can certainly be used for
sending notification subscription data.

>       equipment to a cheaper general purpose computer.

Isn't this what draft-ietf-netmod-udp-pub-channel tries to do?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 08 Jul 2018 10:37:08 +0200 (CEST)

[...]

> > I don't agree.  YP is just one of potentially many (I exaggerate)

If you want to keep this error-app-tag string (I don't think it is
necessary, since the identity is also sent in within the
<error-info>), then I think the document needs to clearly specify
which identity to use for the different errors.

I agree with Kent that the reference to YANG push is not needed here,
and should be removed.  I do think the reference to SN is needed, and
I think the explicit list of rpcs and base identities help.

Kent, do you think that this list is somehow incorrect or misleading?

> What other layer are you expecting?

Who knows?  I agree w/ Kent; it is a matter of getting the design
right, even if we don't see more layers at the moment.

> In the end, when the WG requested that we inherit embedded NETCONF
> and RESTCONF error processing mechanisms, and this drove to the
> explicit mappings.
> 

Note my *if* above.  If we simply don't specify anything for the
error-app-tag, both these issues are solved.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 8 Jul 2018 12:03:10 +0200

> > You mean <start-all-configured-subscriptions> I think.

If you do this, why does the client, after receiving a call home, not
simply create dynamic subscriptions? ;-)

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 08 Jul 2018 18:05:52 +0200 (CEST)

> simply create dynamic subscriptions? ;-)

Well, the configured subscription is needed anyway in order for the
device to call home, so having the client create all configured
subscriptions as dynamic subscriptions as well doesn't seem quite
right.

But if the WG agrees that it is ok to send <notification> directly,
this issue goes away.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 8 Jul 2018 09:25:59 -0700

> subscriptions as dynamic subscriptions as well doesn't seem quite
It is quite possible that multiple RPC operations are needed to get the
session
started, such as reading the YANG library, and that the client
is not ready to receive notifications as soon as the session is started.
So an <activate-configured-sessions> operation may help.

> But if the WG agrees that it is ok to send <notification> directly,
Sitting idle is definitely OK.
Accepting notifications right away is OK as an implementation feature
outside the standard.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 8 Jul 2018 19:53:59 +0200

> subscriptions as dynamic subscriptions as well doesn't seem quite

To call home, all you need is call home configuration, not configured
subscriptions.
 
> But if the WG agrees that it is ok to send <notification> directly,

I wonder what the use case is. I do understand that some people want
transports where subcomponents of a device can send notifications as
fast as possible without having to go through a server process. People
who want this likely won't be using a NETCONF messaging transport. (Of
course, there will be tons of questions related to congestion control
and security for such a lightweight transport.)

So what is the use case for configured subscriptions for a NETCONF
transport? Simply an optimization so that the client does not have to
send a subscribe request?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 08 Jul 2018 20:27:27 +0200 (CEST)

> To call home, all you need is call home configuration, not configured

Yes, but the configured subscription defines parameters (stream and
filter) to trigger the call home action.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Sun, 8 Jul 2018 19:47:28 +0000

> How about prioritizing the *conf-{client,server} models so that 
> the netconf-notif draft can use them, so that we do get a standard

Not behind by much.  If folks give those drafts attention, they
could be done in a few months, which might be okay here.

FWIW, the "update to client/server drafts" and "mandatory local
configuration in keystore groupings" threads are pending responses. 

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Sun, 8 Jul 2018 20:19:20 +0000

> filter) to trigger the call home action.

I think Juergen's idea is to just configure /netconf-server/call-home/
netconf-client instances, and for those instances that are for 
notifications, the client can do a dynamic subscription;  no need to
configure anything under the /subscriptions/subscription/receivers...

Another idea is to have a separate notifications-specific list of
call-home clients, which might be defined as MUST needing to advertise
a new capability indicating that the flow of <notifications> can
occur immediately:

  module ietf-netconf-notifications {
    prefix nn;
    import ietf-netconf-server { prefix ncs; }
    import ietf-subscribed-notifications { prefix sn; }

    // define a *local* netconf-server instance
    container "netconf-server" {
      uses "ncs:netconf-server-grouping" {
        // prune out the "listen" subtree
        refine "listen" {
          when "false()";
        }
      }
    }

    // add leafref to above locally-configured call-home instances
    augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
      leaf netconf-endpoint {
        type leafref {
          path "/nn:netconf-server/nn:call-home/nn:netconf-client/nn:name";
        }
      }
    }
  }

Kent // contributor

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 9 Jul 2018 03:05:08 +0000

Hi Andy,

From: Andy Bierman, July 8, 2018 12:26 PM

On Sun, Jul 8, 2018 at 9:05 AM, Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:
Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:
> > Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:
> > >

It is quite possible that multiple RPC operations are needed to get the session
started, such as reading the YANG library, and that the client
is not ready to receive notifications as soon as the session is started.
So an <activate-configured-sessions> operation may help.

<Eric> If the NETCONF-Notif says that the NETCONF client for a configured subscription must be able to handle accepting notifications right away, do you see any standardization issue with this behavior in this context?

Eric

/martin

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 8 Jul 2018 20:52:01 -0700

On Sun, Jul 8, 2018 at 8:05 PM, Eric Voit (evoit) <[email-masked]> wrote:

> Hi Andy,
>
>
>
> *From:* Andy Bierman, July 8, 2018 12:26 PM
>
> <Eric> If the NETCONF-Notif says that the NETCONF client for a configured
> subscription must be able to handle accepting notifications right away, do
> you see any standardization issue with this behavior in this context?
>
>

NETCONF-Notif can make that requirement, but the Notif-Server MUST support
regular
operations on the session, because CallHome allows a client to do that.

Eric

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 9 Jul 2018 04:17:04 +0000

> From: Martin Bjorklund, July 8, 2018 4:37 AM
> 
> If you want to keep this error-app-tag string (I don't think it is necessary, since
> the identity is also sent in within the <error-info>), 

For NETCONF transport, the <error-info> is populated only when hints are sent.  For more on this, there is history in our December & January thread to morph the previous transport protocol agnostic error structures into something that more closely matched embedded NETCONF implementations.   E.g.,  
https://www.ietf.org/mail-archive/web/netconf/current/msg13954.html
https://www.ietf.org/mail-archive/web/netconf/current/msg13834.html 

It is true that we could changes things and always send the <error-info>.   But what we talked about then works fine.  I don't see what benefit a change buys us.

> then I think the document
> needs to clearly specify which identity to use for the different errors.
> 
> I agree with Kent that the reference to YANG push is not needed here, and
> should be removed.

Without explicitly what RPCs are permitted to have error info carried, any identity could be allowed to populate the error-app-tag or error-info.  I don't think this is what we want.

We all know that subscribed notifications has four RPCs which have error identities which need to be passed back.  But it is also true that yang-push has the resynch-subscription RPC.  This RPC two possible error identities which need to be passed back:
(1) <yang-push>:<no-such-subscription-resynch>
(2) <yang-push>:<synchronization-size>

Without the linkage to yang-push in this section, this connection is not made anywhere in the documents.

>  I do think the reference to SN is needed, and I think the
> explicit list of rpcs and base identities help.
> 
> Who knows?  I agree w/ Kent; it is a matter of getting the design right, even if
> we don't see more layers at the moment.

Other layers can easily be added.  New RPCs can easily bring along their error identities.   How this can be done is demonstrated in yang-push.

> > > We need to ensure the language allows for other layers to be defined
> > > in the future.  I imagine that there should be nothing special about
> > > YP as far as the notif drafts go.
> >
> > This does not precludes additional layers for being placed.  If an
> implementation doesn't need an RPC, it can safely ignore the identity.
> >
> > In the end, when the WG requested that we inherit embedded NETCONF and
> > RESTCONF error processing mechanisms, and this drove to the explicit
> > mappings.
> >
> > > and then leverage existing encoding-specific rules.  What did Martin
> > > say?
> >
> > Per:
> Note my *if* above.  If we simply don't specify anything for the error-app-tag,
> both these issues are solved.

True.  But per earlier threads, what is proposed works.  And I think it a nice convention to only send error-info just when we are providing hints back.

Eric

> > > >>  The 2nd paragraph articulates a valid  concern, but it seems to
> > > >> apply to all transports (although  missing in the restconf-notif
> > > >> draft) and so should be moved  to the SN draft?
> > > >
> > > > As the mechanism for mitigating certain DDoS vectors is transport
> > > > specific, the transport drafts seemed a better place.
> > >
> > > The problem statement (1st sentence) is generic and should be moved
> > > to the SN draft.
> >
> > Section 10, paragraph 2, sentence #1 is context to set up the requirements in
> sentence 2 & 3.  So I replicated a NETCONF independent statement in SN:
> >
> > " For dynamic subscriptions, implementations need to protect against
> malicious or buggy subscribers which may send a large number "establish-
> subscription" requests, thereby using up system resources.  To cover this
> possibility operators SHOULD monitor for such cases and, if discovered, take
> remedial action to limit the resources used, such as suspending or terminating
> a subset of the subscriptions or, if the underlying transport is session based,
> terminate the  underlying transport session."
> >
> > > How to handle the issue in a generic way, if possible, should also
> > > be in the SN draft.  Here, the 2nd sentence seems transport-specific
> > > and the 3rd transport- independent.  However, I think that the 2nd
> > > or 3rd sentences could be stated better (and more generically) in
> > > the SN draft, something like this:
> > >

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 9 Jul 2018 04:17:04 +0000

From: Andy Bierman, July 8, 2018 11:52 PM

On Sun, Jul 8, 2018 at 8:05 PM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

NETCONF-Notif can make that requirement, but the Notif-Server MUST support regular
operations on the session, because CallHome allows a client to do that.

<Eric> Yes.  This is the last sentence of the first paragraph of draft-ietf-netconf-netconf-event-notifications, Section 5.1

“This transport session MAY also be used by dynamic subscriptions and/or non-subscription related NETCONF operations originated by the NETCONF client.”

Eric

Eric

/martin

Andy

Andy

---

From: Qin Wu <[email-masked]>
Date: Mon, 9 Jul 2018 11:19:30 +0000

-----邮件原件-----
发件人: Netconf [mailto:[email-masked]] 代表 Kent Watsen
发送时间: 2018年7月9日 4:19
收件人: Martin Bjorklund; [email-masked]
抄送: [email-masked]
主题: Re: [Netconf] Anyone want just Configured Subscriptions?

> > > > If you do this, why does the client, after receiving a call 
> > > > home, not simply create dynamic subscriptions? ;-)
> > > 
> > > Well, the configured subscription is needed anyway in order for 
> > > the device to call home, so having the client create all 
> > > configured subscriptions as dynamic subscriptions as well doesn't 
> > > seem quite right.
> > 
> > To call home, all you need is call home configuration, not 
> > configured subscriptions.
>

I think Juergen's idea is to just configure /netconf-server/call-home/ netconf-client instances, and for those instances that are for notifications, the client can do a dynamic subscription;  no need to configure anything under the /subscriptions/subscription/receivers...

[Qin]: Forget the history of removing address and port under the /subscriptions/subscription/receivers, what's the real concern for this?
To support call home, what additional parameters are besides address and port?

Another idea is to have a separate notifications-specific list of call-home clients, which might be defined as MUST needing to advertise a new capability indicating that the flow of <notifications> can occur immediately:

[Qin]: Does this new proposal has impact on ietf-netconf-notifications defined in RFC6470?
It looks netcnf-endpoint is not defined as part of base event notification.

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Jul 2018 20:06:52 -0700

> you see any standardization issue with this behavior in this context?

Actually, I think there are issues with configured subscriptions wrt/
CallHome because
of the text in RFC 8071, 1.3:

https://tools.ietf.org/html/rfc8071#section-1.3

The transport and encoding leafs are identityrefs, which means the possible
values
are unknown and unbounded.

Do all possible values (including vendor values, which are valid for the
YANG leaf)
change the protocol enough so separate security analysis are required?
I think a SecDir review may raise concerns wrt/ this issue.

Eric

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 10 Jul 2018 14:53:02 +0200

Hello,
We would need Yang-Push yesterday. We really-really need a basic 
solution (dynamic-subscription with Netconf transport) now. IMHO we do 
have an agreement on this basic part of the function.

This has been dragging along for a long time and we see a chance of 
other people choosing a completely different solution unless we manage 
to agree on the standard soon. I got comments from the ONAP community: 
YangPush could be used, it looks nice, but when will it be ready?

I see the value of configured subscriptions, of multiple transports, 
etc. but if they keep the basic solution from being available I am 
screwed. I appreciate the good work of many people on this topic, but I 
would propose that we consider cutting out any feature from a "first 
release" of  YP unless we manage to get it accepted by the end of August 
in WGLC.
regards Balazs

P.S. Big bang versus agile?

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 10 Jul 2018 15:57:37 +0000

From: Andy Bierman, July 9, 2018 11:07 PM
...

Actually, I think there are issues with configured subscriptions wrt/ CallHome because
of the text in RFC 8071, 1.3:

The transport and encoding leafs are identityrefs, which means the possible values
are unknown and unbounded.

Do all possible values (including vendor values, which are valid for the YANG leaf)
change the protocol enough so separate security analysis are required?
I think a SecDir review may raise concerns wrt/ this issue.

<Eric> For any IETF defined transport, a “Transport-Notif” draft definitely needs to address any issues with Call Home or other such mechanism.  At next IETF, perhaps we will see if this can await concurrent resolution with the NETCONF client/server work.

For configured subscriptions with a vendor specified transport identity, it would be great to see SecDir sees any issues.  I don’t see anything off hand (as it is a vendor transport), but I certainly don’t claim all their perspectives.

Eric

Eric

/martin

Andy

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Jul 2018 09:28:19 -0700

On Tue, Jul 10, 2018 at 8:57 AM, Eric Voit (evoit) <[email-masked]> wrote:

>
>
>
>
> *From:* Andy Bierman, July 9, 2018 11:07 PM
> *...*
>
>
>
> <Eric> For any IETF defined transport, a “Transport-Notif” draft
> definitely needs to address any issues with Call Home or other such
> mechanism.  At next IETF, perhaps we will see if this can await concurrent
> resolution with the NETCONF client/server work.
>
>
>
> For configured subscriptions with a vendor specified transport identity,
> it would be great to see SecDir sees any issues.  I don’t see anything off
> hand (as it is a vendor transport), but I certainly don’t claim all their
> perspectives.
>
>
>

I think all identityref objects need to document the conformance
requirements as detailed
as the WG can agree on. For this draft:

 1) what values of "transport" MUST/SHOULD be implemented by all servers
that
     advertise the "configured" feature?
 2) what values of "transport" MUST/SHOULD be implemented if CallHome is
used?
 3) Are there any "encoding" value restrictions if CallHome is used?
     Text about XML required, JSON optional exists, but is JSON allowed in
NETCONF?
     Is binary allowed in NETCONF? IMO this is OK if both peers opt-in to
the selected encoding
    (and modify the NETCONF contract)

Eric

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jul 2018 21:39:40 +0200

[I can't read this email exchange anymore because the plain text
 format is a mess. So this may be a bit out of context.]

Lets not forget that RFC 8071 is pretty clear that after the call home
procedure the NETCONF / RESTCONF protocol starts (see steps C8 / S6).
And RFC 6241 is pretty clear that the NETCONF protocol starts with a
<hello> exchange. The <hello> exchange is a very useful negotiation
step.

So in short, after RFC 8071 call home, you get NC/RC client and server
starting with a <hello> exchange. Ideally, the client would indicate
its readiness to receive unsolicited notifications before you push
notifications to the client (and the notification sender may even be
interested to know that it is sending notifications to a remote system
that does not just drop them). So either the clients invokes an RPC to
start the notification flow or, if you want to optimize one round
trip, the client includes a special

  :willing-to-receive-unsolicited-notifications

capability in the <hello> exchange.

Note that possible protocol extensions like for example different
encodings will likely be negotiated via the hello exchange as
well. Hence, any attempts to optimize the <hello> exchange away may
cause you some trouble down the road.

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 10 Jul 2018 20:12:01 +0000

> format is a mess. So this may be a bit out of context.]

I've also noticed an increased mangling of responses.  Sometimes they're so bad that my iPhone's email client (Apple's "Mail" app) just shows an empty message and I have to use my laptop's email client just to view the message.

The absolute worst is when I can see that someone has made an effort to convert an email to plain-text with inlined comments, and yet the response converts it back to HTML with the "indent bar" on the left, etc. 

I don't know what all email clients folks are using, but please look at your preferences to see what you can do to improve the settings.  For instance, with Microsoft Outlook for Mac, there is a setting called "When replying or forwarding email, use the format of the original message" that I've found helps a lot.

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Tue, 10 Jul 2018 20:37:30 +0000

> capability in the <hello> exchange.

I agree that a client-advertised capability would be goodness here, but
it only works for NC-clients, there is no corollary for RC-clients.  

Maybe clients should send a "willing-to-receive-unsolicited-notifications"
RPC instead?

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jul 2018 22:59:55 +0200

> Maybe clients should send a "willing-to-receive-unsolicited-notifications"

RFC 8040 (RESTCONF) uses SSE and the client has to fetch an event
stream resource in order to receive events (section 6.3). This is not
a big surprise since HTTP 1/1 is purely client driven. This in fact
implies that the client knows the event stream resource.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 10 Jul 2018 21:13:08 +0000

I send new emails to the IETF in text form.  I reply to emails in the format of the last sender.

If everybody followed such a convention, nothing would diverge from text.

Eric

> From: Kent Watsen <[email-masked]>
> 
> I've also noticed an increased mangling of responses.  Sometimes they're so
> bad that my iPhone's email client (Apple's "Mail" app) just shows an empty
> message and I have to use my laptop's email client just to view the message.
> 
> The absolute worst is when I can see that someone has made an effort to
> convert an email to plain-text with inlined comments, and yet the response
> converts it back to HTML with the "indent bar" on the left, etc.
> 
> I don't know what all email clients folks are using, but please look at your
> preferences to see what you can do to improve the settings.  For instance, with
> Microsoft Outlook for Mac, there is a setting called "When replying or
> forwarding email, use the format of the original message" that I've found helps
> a lot.
> 
> Thanks,
> Kent
> 
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 10 Jul 2018 22:27:23 +0000

> From: Lou Berger, July 10, 2018 4:43 PM
> 
> On 7/10/2018 4:37 PM, Kent Watsen wrote:
> >
> >> So in short, after RFC 8071 call home, you get NC/RC client and
> >> server starting with a <hello> exchange. Ideally, the client would
> >> indicate its readiness to receive unsolicited notifications before
> >> you push notifications to the client (and the notification sender may
> >> even be interested to know that it is sending notifications to a
> >> remote system that does not just drop them). So either the clients
> >> invokes an RPC to start the notification flow or, if you want to
> >> optimize one round trip, the client includes a special
> >>
> > I agree that a client-advertised capability would be goodness here,
> > but it only works for NC-clients, there is no corollary for RC-clients.
> >
> or an an error when an unsolicited notification is received by a client that
> doesn't support it.
> (optimizing for what I think suspect will be the common case in the long
> term...)

Effectively this is what draft-ietf-netconf-restconf-notif, section 4.2 defines now.  A successful POST of a "subscription-started" notification must occur before events are sent.  Failure to receiver an OK for the POST means an error to the publisher.

Some form of RESTCONF Call Home with capability advertisement could also occur before the "subscription-started" POST.  However this advertisement of client capabilities might not be needed for all implementations.

Eric

> Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Jul 2018 00:34:18 +0200

> (optimizing for what I think suspect will be the common case in the long

There is no error message that a client can return in NETCONF for a
notification message the client has received. The client can locally
log an error but that won't impress the sender. So the client closes
the connection and the server calls home again...

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 10 Jul 2018 22:35:34 +0000

> Effectively this is what draft-ietf-netconf-restconf-notif, section 4.2
> defines now.  A successful POST of a "subscription-started" notification
> must occur before events are sent.  Failure to receiver an OK for the POST
> means an error to the publisher.

But if we use RESTCONF Call Home, the receiver is the HTTP-client, can an
HTTP client process a POST?

> Some form of RESTCONF Call Home with capability advertisement could also
> occur before the "subscription-started" POST.  However, this advertisement
> of client capabilities might not be needed for all implementations.

I don't know how.  RESTCONF Call Home just starts the RESTCONF protocol, and
there is no capability-exchange in RESTCONF.

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Jul 2018 00:43:11 +0200

> Some form of RESTCONF Call Home with capability advertisement could also occur before the "subscription-started" POST.  However this advertisement of client capabilities might not be needed for all…

I fail to understand section 4.2. The first sentence already leaves me
puzzled:

   With HTTP2 connectivity established, a POST of each new
   "subscription-started" state change notification messages will be
   addressed to HTTP augmentation code on the receiver capable of
   accepting and acknowledging to subscription state change
   notifications.

What does this say? And why is this HTTP2 specific? The publisher is
the RC server, no? So the RC server does HTTP transactions agains the
client? This does not seem to have anything to do with how the call
home RFC works.

I am not saying that what Figure 3 shows won't work, it just has
nothing to do with call home. You are reversing the RC client and
server roles, call home only reverses the connection establishment
roles. Big difference.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Jul 2018 15:53:35 -0700

> implies that the client knows the event stream resource.
SSE should be an available option for configured notifications.
There could be a pre-determined URL for the client to GET
like GET /restconf/SSE/<subscription-id>

/js

Andy

---

From: Lou Berger <[email-masked]>
Date: Tue, 10 Jul 2018 16:43:06 -0400

> Maybe clients should send a "willing-to-receive-unsolicited-notifications"
or an an error when an unsolicited notification is received by a client 
that doesn't support it.
(optimizing for what I think suspect will be the common case in the long 
term...)

Lou

---

From: Robert Wilton <[email-masked]>
Date: Wed, 11 Jul 2018 17:40:17 +0100

I completely agree.

On 10/07/2018 13:53, Balazs Lengyel wrote:
> screwed. I appreciate the good work of many people on this topic, but 
> I would propose that we consider cutting out any feature from a "first 
> release" of  YP unless we manage to get it accepted by the end of 
> August in WGLC.
> regards Balazs
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Jul 2018 10:10:01 -0700

Hi,

I would support the following actions:
  1) move configured notifications to another draft so dynamic subscriptions
      can move forward.
  2) make this draft NETCONF only and defer RESTCONF notifications
      until there is sufficient demand and consensus on how to do it.
  3) move all subscription monitoring to another draft or remove it.
       (The verbose notifications already define for subscription state
changes
        are sufficient).

I think this would leave the RPC operations and notification events, which
is all YANG Push should need to move forward. IMO a "binary push" transport
is more important than items 1 -3 above.

Andy

On Wed, Jul 11, 2018 at 9:40 AM, Robert Wilton <
rwilton=[email-masked]> wrote:

>> We would need Yang-Push yesterday. We really-really need a basic solution
>> (dynamic-subscription with Netconf transport) now. IMHO we do have an
>> agreement on this basic part of the function.
>>
>> This has been dragging along for a long time and we see a chance of other
>> people choosing a completely different solution unless we manage to agree
>> on the standard soon. I got comments from the ONAP community: YangPush
>> could be used, it looks nice, but when will it be ready?
>>
>> I see the value of configured subscriptions, of multiple transports, etc.
>> but if they keep the basic solution from being available I am screwed. I
>> appreciate the good work of many people on this topic, but I would propose
>> that we consider cutting out any feature from a "first release" of  YP
>> unless we manage to get it accepted by the end of August in WGLC.
>> regards Balazs
>>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 12 Jul 2018 15:30:31 +0200

Hi all,

I would like to strongly +1 retaining the configured subscriptions (not 
necessarily in the Push draft itself for the sake of expediting WGLC or 
modularity) with at least 2 variants:

* using a call home procedure (or similar rendezvous/join/discovery 
procedure with a given scope and purpose) creating a series of 
notification (or a given variant, e.g. bundles) with a kind of 
solicitation, for example, via the attempt to trigger a dynamic subscription

* using a procedure to enable conveyance of notifications (or a given 
variant, e.g bundles) without solicitation (and maybe a way to signal 
refusal to accept incoming telemetry in given scopes)

This request is based on the need for unboxed things (of any sizes) to 
find a suitable home - even in unknown territory or challenged by 
volatile receiver availability.

A third variant that is able to create telemetry (assuming a procedure 
distributing state between potential receivers in order to enable 
conveyance) with solicitation but without a call home procedure would be 
convenient (e.g. wrt to subscription resilience or fail-over of 
subscription state in cases where a home in a group of homes is rendered 
unavailable). Alas, I am new to this domain and am not sure, if this 
third usage scenario is in scope here.

Viele Grüße,

Henk

On 07/11/2018 07:10 PM, Andy Bierman wrote:
> On Wed, Jul 11, 2018 at 9:40 AM, Robert Wilton 
> <rwilton=[email-masked] 
> <mailto:rwilton=[email-masked]>> wrote:
> 
>     I completely agree.
> 
> 
>         solution (dynamic-subscription with Netconf transport) now. IMHO
>         we do have an agreement on this basic part of the function.
> 
>         This has been dragging along for a long time and we see a chance
>         of other people choosing a completely different solution unless
>         we manage to agree on the standard soon. I got comments from the
>         ONAP community: YangPush could be used, it looks nice, but when
>         will it be ready?
> 
>         I see the value of configured subscriptions, of multiple
>         transports, etc. but if they keep the basic solution from being
>         available I am screwed. I appreciate the good work of many
>         people on this topic, but I would propose that we consider
>         cutting out any feature from a "first release" of  YP unless we
>         manage to get it accepted by the end of August in WGLC.
>         regards Balazs
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netconf>
> 
> 
> 
>

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 12 Jul 2018 14:34:16 +0000

I have to return home late Thursday. Can we do this any other day beginning with Monday?

Igor
From:Henk Birkholz
To:Andy Bierman,Robert Wilton,
Cc:Netconf,
Date:2018-07-12 09:37:14
Subject:Re: [Netconf] YangPush now

Hi all,

Viele Grüße,

Henk

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Jul 2018 08:20:01 -0700

Hi,

Maybe this WG needs to figure out how to deliver core functionality and then
add to it over time.

For example, none of the notification drafts are critical or even important
for
getting YANG Push out the door.  We just needed (for core functionality)
to start notification delivery on a session, and RFC 5277 already does that.
All the new features are refinements and add-ons.

YANG Push could have been designed so it does not depend so heavily
on the subscription drafts. Now other non-standard solutions are getting
deployed instead of YANG Push.  There is no real business case to
replace all the proprietary work, especially if YANG Push drags on into
2019.

Andy

On Tue, Jul 10, 2018 at 5:53 AM, Balazs Lengyel <[email-masked]

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 12 Jul 2018 17:29:39 +0200

Hi all,

having just read Andy's reply, I have to agree with this sentiment, I think.

To me, it seems there has been a surprising amount of cycles with this 
set of drafts. Of course, there are always reasons for this, but I have 
to acknowledge that in this case the current process could turn out to 
be a disabler wrt adoption.

Viele Grüße,

Henk

On 07/12/2018 05:20 PM, Andy Bierman wrote:
> Now other non-standard solutions are getting

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Jul 2018 09:08:58 -0700

On Thu, Jul 12, 2018 at 8:29 AM, Henk Birkholz <
[email-masked]> wrote:

> To me, it seems there has been a surprising amount of cycles with this set
> of drafts. Of course, there are always reasons for this, but I have to
> acknowledge that in this case the current process could turn out to be a
> disabler wrt adoption.
>
>
IMO the YANG Push design should have been a stand-alone configuration
subtree
like /yang-push.  All that is really required is some config that says
"send the
specified notifications according to these parameters."  How notifications
get delivered has never been important to the specification of what data to
push.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 12 Jul 2018 18:48:03 +0000

> modularity)

Ah, so here's another hum question: with or without yang push.

hums now are:

 1. dynamic subscriptions ~ configured subscriptions
   a. dynamic first, then configured (published sequentially)
   b. dynamic and configure together (published in parallel)

 2. subscribed-notifications ~ yang-push
   a. SN first, then YP  (published sequentially)
   b. SN and YP together (published in parallel)

Eric/Alex: please include a slide with this somewhere in your preso.

Thanks,
Kent // chair

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Jul 2018 12:38:30 -0700

>    b. dynamic and configure together (published in parallel)

a

>    b. SN and YP together (published in parallel)

b

Since "what to push" is so tightly coupled to "how to push", clearly YP has
to wait for SN

I have not heard any customer-types ask for a different way to do
<create-subscription>,
just requests for YP, so there is no urgency for SN alone

Andy

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 12 Jul 2018 20:28:40 +0000

On 2): not sure I understand that particular hum; I don't see what would be gained by separating them.  YP builds on SN but it is ready.    If the WG decides to refactor SN to move configured subscriptions out, sure, YP needs to be updated to make sure this is reflected, but this should be straightforward.  If separating YP and SN would accelerate them (or at least one of them), sure, but I am not clear why this would be the case.  

To the question on putting YP out without SN: this is a well-intended suggestion even if it seems a bit ironic given SN was originally created by taking it out as a generalizable piece from YP that would be useful for notifications other than push updates per decision of the WG.  Changing YP now to become a self-contained piece would mean reverting on this; I am not convinced it is a good idea to do so this late in the game and would rather have us see this through as we had planned.    

--- Alex

> Sent: Thursday, July 12, 2018 11:48 AM
> To: Henk Birkholz <[email-masked]>; Andy Bierman
> <[email-masked]>; Robert Wilton
> <rwilton=[email-masked]>
> Cc: Netconf <[email-masked]>
> Subject: Re: [Netconf] YangPush now
> 
> 
> > I would like to strongly +1 retaining the configured subscriptions
> > (not necessarily in the Push draft itself for the sake of expediting
> > WGLC or
> > modularity)
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 12 Jul 2018 21:37:31 +0000

Hi Alex,

Addressing your second point first, as you say, we're too far down the road to consider YP w/o SN.  I think Andy was just reflecting how things could've been different if we turned back time.

Regarding your first point, I agree that the delta may not be much, but YP is also a large document (56 pages) and, if only to help better focus the WG, the chairs will probably run the LCs on these two drafts sequentially anyway.  Just speaking for myself, I haven't reviewed YP seriously yet, as I've been waiting for the dust to settle on the SN layer first.  In theory, my review should go easy, since YP builds on top of SN (the harder to define layer) and also because YP has been improved by others already, but that's all part of the unknown behind hum #2.  Makes sense?

Kent

===== original message =====

--- Alex

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 12 Jul 2018 23:26:37 +0000

Hi Kent,

good - so we agree that we are too far down the road to change things and revert back to where we started a few years ago.  I thought that therefore we can just close on these things without opening everything up again.  This is why I was irritated at calling for a hum.  IMHO we should pass the whole package, including YP and SN, and including configured and dynamic (another decision we had made a long time ago).  I agree with Balazs' sentiment that we needed this yesterday.  We should be looking for ways to bring this to swift conclusion (and refactoring documents and rearranging major concepts all take their time) - much more important than trying to perfect it at this point in time IMHO.  

--- Alex

> From: Kent Watsen [mailto:[email-masked]]
> Sent: Thursday, July 12, 2018 2:38 PM
> To: Alexander Clemm <[email-masked]>; Henk Birkholz
> <[email-masked]>; Andy Bierman <[email-masked]>;
> Robert Wilton <rwilton=[email-masked]>
> Addressing your second point first, as you say, we're too far down the road to
> consider YP w/o SN.  I think Andy was just reflecting how things could've been
> different if we turned back time.
> 
> Regarding your first point, I agree that the delta may not be much, but YP is also
> a large document (56 pages) and, if only to help better focus the WG, the chairs
> will probably run the LCs on these two drafts sequentially anyway.  Just speaking
> for myself, I haven't reviewed YP seriously yet, as I've been waiting for the dust
> to settle on the SN layer first.  In theory, my review should go easy, since YP
> builds on top of SN (the harder to define layer) and also because YP has been
> improved by others already, but that's all part of the unknown behind hum #2.
> Makes sense?
> 
> Kent
> 
> 
> On 2): not sure I understand that particular hum; I don't see what would be
> gained by separating them.  YP builds on SN but it is ready.    If the WG decides
> to refactor SN to move configured subscriptions out, sure, YP needs to be
> updated to make sure this is reflected, but this should be straightforward.  If
> separating YP and SN would accelerate them (or at least one of them), sure, but
> I am not clear why this would be the case.
> 
> To the question on putting YP out without SN: this is a well-intended suggestion
> even if it seems a bit ironic given SN was originally created by taking it out as a
> generalizable piece from YP that would be useful for notifications other than
> push updates per decision of the WG.  Changing YP now to become a self-
> contained piece would mean reverting on this; I am not convinced it is a good
> idea to do so this late in the game and would rather have us see this through as
> we had planned.
> 
> --- Alex
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Jul 2018 16:57:26 -0700

On Thu, Jul 12, 2018 at 4:26 PM, Alexander Clemm <[email-masked]

> Hi Kent,
>
> good - so we agree that we are too far down the road to change things and
> revert back to where we started a few years ago.  I thought that therefore
> we can just close on these things without opening everything up again.
> This is why I was irritated at calling for a hum.  IMHO we should pass the
> whole package, including YP and SN, and including configured and dynamic
> (another decision we had made a long time ago).  I agree with Balazs'
> sentiment that we needed this yesterday.  We should be looking for ways to
> bring this to swift conclusion (and refactoring documents and rearranging
> major concepts all take their time) - much more important than trying to
> perfect it at this point in time IMHO.
>
>

What if SN did not wait for client-server?
What would that look like?

Perhaps:

      choice receiver-address {
        case standalone-tcp {
           leaf address {}
           leaf port {}
        }
      }

What if the address/port leafs were part of a choice, so different cases
can be augmented from new modules or proprietary modules?

But SN depends on ietf-network-instance which is not done,
which depends on schema-mount which is not done...

Andy

---

From: Robert Wilton <[email-masked]>
Date: Fri, 13 Jul 2018 09:50:46 +0100

Hi,

It might be useful (at least to me), if the draft authors could 
explicitly indicate what their preference is, and also which of the 
choices below they think would lead to the work completing most quickly.

Thanks,
Rob

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 13 Jul 2018 10:54:28 +0200

Hi all,

I would also like to see the implications and consequences of a specific 
hum option to be highlighted very clearly and explicitly. Every option 
that is available to hum on should highlight an expected amount of delay 
of WGLC created by the decision.

This thread's subject is "YangPush now" and that is exactly the point. 
Remodeling takes time. Wrt to number of changes, I would like to 
encourage the minimal viable solution at this point of time (yes, I a 
can barely believe it myself... but it is actually me, who is writing 
this statement... maybe to some this is an indicator).

Viele Grüße,

Henk

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 13 Jul 2018 20:44:41 +0000

Hi,

I will unfortunately not be able to attend Monday's meeting (still in transit),  so let me briefly summarize what the options are and their implications, and which we therefore prefer as authors.

Regarding progressing Dynamic and Configured Together (hum A):

Option A1: Keep them together, as currently defined in the draft.  This option is done & currently defined in the drafts.  This will be the fastest and is thus preferred.  

Option A2: Keep them together, but leave the Netconf transport option for configured open for now.  This requires updates to the Netconf Notification draft (draft-ietf-netconf-netconf-event-notifications), but the updates should be straightforward and the time delta should still be small.   Once ietf-netconf-server.yang completes, a -bis version of the Netconf Notification draft can be issued to accommodate configured subscriptions with call home using netconf server.  This option is not preferred but acceptable.  

Option A3: Take out configured subscriptions altogether for now, to revisit at a later point.  Keep only dynamic subscriptions.  This option implies having to refactor the drafts.  It will imply further delay and significant effort to make the updates.  The concern is that this will miss the market window, therefore IMHO this a terrible option.  Frankly, given this, I am not sure that the authors will be willing to invest all that effort into something that will de-facto only diminish value.  

Regarding progressing subscribed notification (SN) and YANG-Push (YP) together (hum B):

Option B1: Keep them together as one cluster.  This has been the WG direction since this stuff was adopted; SN was actually created by breaking out the generalizable portions from YP at the time.  They really belong together and the business value we are targeting is provided by them jointly, even if SN can be used on its own.  Hence, author preference is to keep them together.  

Option B2: Separate them out.  The concern is that while in theory it might not result in further delays, in practice it still breeds the risk of doing so.  (And we know that the difference between theory and practice is that while in theory both are the same, in practice often they are not.)  

Summary: Authors clearly prefer A1 and B1, although they will accept A2 and B2 if the WG decides to go there.  A3 is a terrible option and a very clear no go.  
--- Alex

> From: Netconf [mailto:[email-masked]] On Behalf Of Henk Birkholz
> Sent: Friday, July 13, 2018 1:54 AM
> To: Robert Wilton <[email-masked]>; Kent Watsen <[email-masked]>;
> Andy Bierman <[email-masked]>; Netconf <[email-masked]>
> I would also like to see the implications and consequences of a specific hum
> option to be highlighted very clearly and explicitly. Every option that is available
> to hum on should highlight an expected amount of delay of WGLC created by
> the decision.
> 
> Remodeling takes time. Wrt to number of changes, I would like to encourage
> the minimal viable solution at this point of time (yes, I a can barely believe it
> myself... but it is actually me, who is writing this statement... maybe to some
> this is an indicator).
> 
> Viele Grüße,
> 
> Henk
> 
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jul 2018 14:53:01 -0700

Hi,

If the SN draft is only held up for configured subscriptions,
and the people interested in implementing this YANG feature right away
are OK with the receiver list as-is, then A1, B1 seems like an easy choice.

Andy

On Fri, Jul 13, 2018 at 1:44 PM, Alexander Clemm <[email-masked]

> Hi,
>
> I will unfortunately not be able to attend Monday's meeting (still in
> transit),  so let me briefly summarize what the options are and their
> implications, and which we therefore prefer as authors.
>
> Option A1: Keep them together, as currently defined in the draft.  This
> option is done & currently defined in the drafts.  This will be the fastest
> and is thus preferred.
>
> Option A2: Keep them together, but leave the Netconf transport option for
> configured open for now.  This requires updates to the Netconf Notification
> draft (draft-ietf-netconf-netconf-event-notifications), but the updates
> should be straightforward and the time delta should still be small.   Once
> ietf-netconf-server.yang completes, a -bis version of the Netconf
> Notification draft can be issued to accommodate configured subscriptions
> with call home using netconf server.  This option is not preferred but
> acceptable.
>
> Option A3: Take out configured subscriptions altogether for now, to
> revisit at a later point.  Keep only dynamic subscriptions.  This option
> implies having to refactor the drafts.  It will imply further delay and
> significant effort to make the updates.  The concern is that this will miss
> the market window, therefore IMHO this a terrible option.  Frankly, given
> this, I am not sure that the authors will be willing to invest all that
> effort into something that will de-facto only diminish value.
>
> Option B1: Keep them together as one cluster.  This has been the WG
> direction since this stuff was adopted; SN was actually created by breaking
> out the generalizable portions from YP at the time.  They really belong
> together and the business value we are targeting is provided by them
> jointly, even if SN can be used on its own.  Hence, author preference is to
> keep them together.
>
> Option B2: Separate them out.  The concern is that while in theory it
> might not result in further delays, in practice it still breeds the risk of
> doing so.  (And we know that the difference between theory and practice is
> that while in theory both are the same, in practice often they are not.)
>
> Summary: Authors clearly prefer A1 and B1, although they will accept A2
> and B2 if the WG decides to go there.  A3 is a terrible option and a very
> clear no go.
> --- Alex
>
>
> > To: Robert Wilton <[email-masked]>; Kent Watsen <[email-masked]
> >;
> hum
> encourage

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 13 Jul 2018 22:17:21 +0000

+1.   A1 & B1.

Eric

From: Netconf <[email-masked]> On Behalf Of Andy Bierman
Sent: Friday, July 13, 2018 5:53 PM
To: Alexander Clemm <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] YangPush now

Hi,

Andy

On Fri, Jul 13, 2018 at 1:44 PM, Alexander Clemm <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

> From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Henk Birkholz
> To: Robert Wilton <[email-masked]<mailto:[email-masked]>>; Kent Watsen <[email-masked]<mailto:[email-masked]>>;
> Andy Bierman <[email-masked]<mailto:[email-masked]>>; Netconf <[email-masked]<mailto:[email-masked]>>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 13 Jul 2018 22:56:42 +0000

I am not an author of SN or YP but I’m a supporter of A1 and B1. I still don’t see the point/intent of doing anything else.

Regards,
Reshad.

From: Netconf <[email-masked]> on behalf of "Eric Voit (evoit)" <evoit=[email-masked]>
Date: Friday, July 13, 2018 at 6:17 PM
To: 'Andy Bierman' <[email-masked]>, Alexander Clemm <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] YangPush now

+1.   A1 & B1.

Eric

Hi,

Andy

---

From: Kent Watsen <[email-masked]>
Date: Sat, 14 Jul 2018 00:40:03 +0000

Folks,

While it's okay to post your preferences beforehand, note that the goal
of the hum is to get the room's collective response at once.  As such, any
preferences posted before won't be counted.  For the folks that won't
be present, at the appropriate time, please enter your choice in jabber.

Note that, regardless the outcome of the hums, the *same* end-result
will be achieved in time (either all at once or piecemeal).   We're only
looking at if there is an opportunity of getting a subset to RFC status
faster (a number of people asked for this).  It will be a snap-decision,
if there isn't an *obvious* preference from the room, then it will be
author's choice.

BTW, I'm unsure if A2 is a viable option.  It seems that it should not be
possible to configure a receiver without specifying the transport.  In
YANG terms, SN might need a mandatory "choice" that the notif models
augment into.  I think that, to support configured subscriptions, there
should be at least one mandatory to implement "notif" draft.

Kent

On 7/13/18, 6:56 PM, "Netconf on behalf of Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]> on behalf of rrahman=[email-masked]<mailto:rrahman=[email-masked]>> wrote:

Regards,
Reshad.

+1.   A1 & B1.

Eric

Hi,

Andy

> https://www.ietf.org/mailman/listinfo/netconf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=M407zoQiYHA_i5ojIVIn0hQ22DqGzwH1S4ib8mZNtQs&s=S5YFUlo520sYi5HXAj4BXaOXkItF4q1Rf6YpFGzqDTU&e=>

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 14 Jul 2018 06:06:12 +0200

Hello Kent,

while I fully agree with scoping a hum beforehand and with the statement 
that "any preferences posted before won't be counted", I am surprised by 
reading the statement "BTW, I'm unsure if A2 is a viable option." in the 
same message. Maybe I am missing something very obvious here, but is 
that not the exact same thing you were discouraging beforehand?

Again, this is not an attempt to disrupt a constructive and targeted 
process. I am new to this domain and just puzzled by the semantic 
difference of a "preference" and an "option" stated on the list - as it 
seems to me subjectively - they are hard to distinguish for me as a 
non-native speaker.

In consequence, I would like to know what a useful comment before a hum 
looks like and - in contrast - how a comment that does not count looks 
like. The reason for my ("noob") question is that I am unfamiliar with 
the proceedings of this WG & I do not want to infuse disruptive comments 
& I am now unsure how to phrase a productive contribution, I think.

If I voiced a preference that does not count, I am very sorry. I only 
wanted to highlight that not only a set of options, but also their 
implications have to be well understood by the audience before humming. 
That was my only intend :)

Viele Grüße,

Henk

On 07/14/2018 02:40 AM, Kent Watsen wrote:
> On 7/13/18, 6:56 PM, "Netconf on behalf of Reshad Rahman (rrahman)" 
> <[email-masked] <mailto:[email-masked]> on behalf of 
> rrahman=[email-masked] 
> <mailto:rrahman=[email-masked]>> wrote:
> 
> I am not an author of SN or YP but I’m a supporter of A1 and B1. I still 
> don’t see the point/intent of doing anything else.
> 
> Regards,
> 
> Reshad.
> 
> *From: *Netconf <[email-masked]> on behalf of "Eric Voit 
> (evoit)" <evoit=[email-masked]>
> *Date: *Friday, July 13, 2018 at 6:17 PM
> *To: *'Andy Bierman' <[email-masked]>, Alexander Clemm 
> <[email-masked]>
> *Cc: *Netconf <[email-masked]>
> *Subject: *Re: [Netconf] YangPush now
> 
> +1.   A1 & B1.
> 
> Eric
> 
> *From:*Netconf <[email-masked]> *On Behalf Of *Andy Bierman
> *Sent:* Friday, July 13, 2018 5:53 PM
> *To:* Alexander Clemm <[email-masked]>
> *Cc:* Netconf <[email-masked]>
> *Subject:* Re: [Netconf] YangPush now
> 
> Hi,
> 
> On Fri, Jul 13, 2018 at 1:44 PM, Alexander Clemm 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>     I will unfortunately not be able to attend Monday's meeting (still
>     in transit),  so let me briefly summarize what the options are and
>     their implications, and which we therefore prefer as authors.
> 
>     Option A1: Keep them together, as currently defined in the draft. 
>     This option is done & currently defined in the drafts.  This will be
>     the fastest and is thus preferred.
> 
>     Option A2: Keep them together, but leave the Netconf transport
>     option for configured open for now.  This requires updates to the
>     Netconf Notification draft
>     (draft-ietf-netconf-netconf-event-notifications), but the updates
>     should be straightforward and the time delta should still be small. 
>       Once ietf-netconf-server.yang completes, a -bis version of the
>     Netconf Notification draft can be issued to accommodate configured
>     subscriptions with call home using netconf server.  This option is
>     not preferred but acceptable.
> 
>     revisit at a later point.  Keep only dynamic subscriptions.  This
>     option implies having to refactor the drafts.  It will imply further
>     delay and significant effort to make the updates.  The concern is
>     that this will miss the market window, therefore IMHO this a
>     terrible option.  Frankly, given this, I am not sure that the
>     authors will be willing to invest all that effort into something
>     that will de-facto only diminish value.
> 
>     direction since this stuff was adopted; SN was actually created by
>     breaking out the generalizable portions from YP at the time.  They
>     really belong together and the business value we are targeting is
>     provided by them jointly, even if SN can be used on its own.  Hence,
>     author preference is to keep them together.
> 
>     Option B2: Separate them out.  The concern is that while in theory
>     it might not result in further delays, in practice it still breeds
>     the risk of doing so.  (And we know that the difference between
>     theory and practice is that while in theory both are the same, in
>     practice often they are not.)
> 
>     Summary: Authors clearly prefer A1 and B1, although they will accept
>     A2 and B2 if the WG decides to go there.  A3 is a terrible option
>     and a very clear no go.
>     --- Alex
> 
> 
>      > From: Netconf [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Henk Birkholz
>      > To: Robert Wilton <[email-masked] <mailto:[email-masked]>>;
>     Kent Watsen <[email-masked] <mailto:[email-masked]>>;
>      > Andy Bierman <[email-masked] <mailto:[email-masked]>>;
>     Netconf <[email-masked] <mailto:[email-masked]>>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=M407zoQiYHA_i5ojIVIn0hQ22DqGzwH1S4ib8mZNtQs&s=S5YFUlo520sYi5HXAj4BXaOXkItF4q1Rf6YpFGzqDTU&e=>
> 
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 14 Jul 2018 08:01:48 +0200

I am confused to which drafts this analysis applies exactly. The
work seems to be covered by the following drafts:

- draft-ietf-netconf-yang-push [56 pages]
- draft-ietf-netconf-subscribed-notifications [74 pages]
- draft-ietf-netconf-restconf-notif [33 pages]
- draft-ietf-netconf-notification-messages [23 pages]
- draft-ietf-netconf-netconf-event-notifications [26 pages]
- draft-ietf-netconf-udp-pub-channel [19 pages]

I do not think all the 231 pages are 'done', there were technical
issues raised on the list related to configured subscriptions
recently, more specifically draft-ietf-netconf-restconf-notif. Note
that the goal is not to minimize edits but to avoid getting stuck on
issues during WG last call (or the publication queue) on features that
may not seem that relevant. It may also be useful to have a fair
assessment of the dependencies of these drafts (or the relevant drafts
for the questions) wrt configuration data models and their progress.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Sat, 14 Jul 2018 12:53:21 +0000

Hi Juergen,

The options only apply to three drafts which have been under WGLC:
- draft-ietf-netconf-subscribed-notifications
- draft-ietf-netconf-yang-push
- draft-ietf-netconf-netconf-event-notifications

For more context, see the PPT slides for the NETCONF session:
https://github.com/netconf-wg/rfc5277bis/blob/master/Subscriptions-NETCONF-IETF102.pdf 

Agree that draft-ietf-netconf-restconf-notif isn't ready.  And that there are technical issues open there.  This is what was being discussed on the thread earlier this week.

Eric

> From: Netconf <[email-masked]> On Behalf Of Juergen
> Schoenwaelder
> Sent: Saturday, July 14, 2018 2:02 AM
> I am confused to which drafts this analysis applies exactly. The work seems
> to be covered by the following drafts:
> 
> I do not think all the 231 pages are 'done', there were technical issues
> raised on the list related to configured subscriptions recently, more
> specifically draft-ietf-netconf-restconf-notif. Note that the goal is not to
> minimize edits but to avoid getting stuck on issues during WG last call (or
> the publication queue) on features that may not seem that relevant. It may
> also be useful to have a fair assessment of the dependencies of these drafts
> (or the relevant drafts for the questions) wrt configuration data models and
> their progress.
> 
> /js
> 
> option is done & currently defined in the drafts.  This will be the fastest and
> is thus preferred.
> >
> > Option A2: Keep them together, but leave the Netconf transport option
> for configured open for now.  This requires updates to the Netconf
> Notification draft (draft-ietf-netconf-netconf-event-notifications), but the
> updates should be straightforward and the time delta should still be small.
> Once ietf-netconf-server.yang completes, a -bis version of the Netconf
> significant effort to make the updates.  The concern is that this will miss the
> market window, therefore IMHO this a terrible option.  Frankly, given this, I
> am not sure that the authors will be willing to invest all that effort into
> something that will de-facto only diminish value.
> >
> > might not result in further delays, in practice it still breeds the
> > risk of doing so.  (And we know that the difference between theory and
> > practice is that while in theory both are the same, in practice often
> > they are not.)
> >
> > > To: Robert Wilton <[email-masked]>; Kent Watsen
> > > <[email-masked]>; Andy Bierman <[email-masked]>;
> Netconf
> > > <[email-masked]>
> > > I would also like to see the implications and consequences of a
> > > specific hum option to be highlighted very clearly and explicitly.
> > > Every option that is available to hum on should highlight an
> > > expected amount of delay of WGLC created by the decision.
> > >
> > > encourage the minimal viable solution at this point of time (yes, I
> > > a can barely believe it myself... but it is actually me, who is
> > > writing this statement... maybe to some this is an indicator).
> > >
> > > Viele Grüße,
> > >
> > > Henk
> > >
> > >
> > > > explicitly indicate what their preference is, and also which of
> > > > the choices below they think would lead to the work completing most
> quickly.
> > > >
> > > > Thanks,
> > > > Rob
> > > >
> > > >
> > > >>> I would like to strongly +1 retaining the configured
> > > >>> subscriptions (not necessarily in the Push draft itself for the
> > > >>> sake of expediting WGLC or
> > > >>> modularity)

---

From: Balazs Lengyel <[email-masked]>
Date: Sun, 15 Jul 2018 15:29:28 -0400

Hello,

One thing I would like to retain in SN is the ability to put multiple 
subscriptions on a single session. If we are thinking about focused, 
strongly filtered subscriptions, many will be needed. I would just push 
configured subscriptions into phase-2. AFAIK there are no problems with 
the rest.

regards Balazs