Minutes IETF105: netconf
minutes-105-netconf-00

Introduction

  Chairs (10 minutes)
  Session Intro & WG Status

Balasz Lengyel, Ericsson. I would like to ask what's the situation with some of
the other YANG Push related slides.  For instance, there was the UDP encoding,
there was the binary encoding or unity transport the binary encoding, call home
that was provisionally taken out from YANG Push. Kent Watsen: There was a draft
called UDP pub/sub, is that the one you're referring to?, that was a working
group adopted draft but we unadopted it last time, because the main focus was
actually the multi-stream originators.  What that draft needs to do is be
brought to the workgroups again has a "notif" draft; something like "UDP
Notif".  If someone can submit it in that fashion then it could be accepted by
the working group. Mahesh Jethanandani: makes sense?   Sorry could you speak
that at the mic? Kent: he says that on the website it is still adopted. Balasz:
on the status page UDP Pub Sub is still listed as adopted. Kent: We''l have to
take a look at that.  We did asked the Secretariat to remove it, but we'll
check on it again.

*** ACTION: chairs to remove UDP-draft from "tools" page

Balazs: and the binary encoding and call home?
Kent: the binary encoding...
Mahesh: ...is still in individual draft.  It is not yet a working group item,
if you're referring to the draft that I presented a couple NETCONF meetings
ago.  Yes, so it's still there, it may need a revision, but it is an individual
draft at this point.

Balazs: and the call home parts that we took out of YANG Push, is there any
development on that? Kent: If you look at the draft that Mahesh is presenting,
the last one on the today's agenda, it's actually a "notif" transport for
configured subscriptions which does in fact do call home.  Actually, we
shouldn't say "call home", let's just say "device initiated connection".
Balazs: okay.

Henk Birkholz: Hi, this is Henk.  I will join in Kent's presentation later and,
in that context, I want to highlight that there could also be a CoAP call home
because in the context they were presented here that so there could be multiple
variants off to doing this and I'm not sure if there should be a cross
documents or in a single document.  I don't know. Kent: what Henk is saying is
that that there's another effort for doing a binary transport, a binary "notif"
transport for notifications.

Chartered items:

   Kent Watsen (30 min)
   Status and Issues on Client-Server Drafts
   https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-10
   https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-05
   https://tools.ietf.org/html/draft-ietf-netconf-keystore-12
   https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-02
   https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-14
   https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-14
   https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-14
   https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-14
   https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-03

[ The following regards "Discussion 1"]

Kent: This presentation doesn't discuss the trust anchors draft which Henk and
I were discussing yesterday and Henk wanted to ask a question about it, so
maybe now would be a good time to ask Henk to ask his question about the trust
anchors draft and, especially how relates the TLS draft... Henk: Yeah okay, so
this is Henk again so.  This is my officially it's a CORE-hat, but it's
probably also a YANG of Things hat on.  All of these people who try to do
binary-yang.  There is CoreCONF coming up, formally known as CoMI.  This is
using DTLS, if it's secured, of course, and it should be, and that will be and
in CoAP, and on the DTLS-level, CoAP advises to use different ways to
secureCoAP and that is 1) a raw public key, as a minimal CMS frame, as it was
standardized years ago, and also 2) we have this concept of pairwise symmetric
keys, that are pre-provisioned and both of these are suggested methods to
secure CoAP by the CoAP RFC.  And they can be applied to two levels they can be
applied to DTLS and therefore what extend into TLS which is effectively also
done today I mean a lot of people use PSKs, known as "pre-shared keys", we like
the term "pairwise symmetric key" and the raw public key of course is a little
bit different than the SSH key material, so my proposal here and this mic is to
add these two flavors, the raw public key and the pairwise symmetric key, to
the trust store draft.   Kent and I were already talking about this, so we are
aligned, but the room has to be fine with this, because this extends a little
bit into TLS and into DTLS as it is mandated by CoAP end.  It can be both on
the communication layer but also on the object security layer, so it's a
communication security and it can also be an object security. so it also goes
back to "OSCore" the "object security for constrained environment".   So there
are multiple consumers of this information and my personal point of view is we
should add that to the draft itself. Kent: okay, great, thank you.  Actually to
add to that, the TLS draft primarily considers certificates, but TLS does
support other forms [of credentials] like PGP and and pre-shared keys, and
currently the trust anchor draft does not have any support at all for these
things. it's really an ommision that we ourselves should have caught before and
I would expect IESG would call us on when taking the TLS draft to Last Call. 
What Henk is raising right now in the context of DTLS is something that we
already had an issue with the TLS draft and and thus extending the trust
anchors draft to support pre share keys and raw keys, would be the proper thing
to do.

Tim Carey: Tim Carey, Nokia: I do have a question on this approach though
because, you know, there's gonna be many consumers of these particular drafts,
hopefully ,right, outside the context of you know just client-server type of
stuff, so here we have an example of CoMI and CoAP wanting to augment, and I
use that word I think appropriately here, some of the work that's happening in
the keystore, you know, from a different area, so is it is it the approach or
strategy to continually revising these drafts that is the universal crypto or
keystore types that we wanted to deal with, or do we expect the other working
groups to use those drafts or incorporate them into their into their work and
so I'm just trying to understand the difference because otherwise we'll be
revving this thing for every use possible. Mahesh: there is a SecDir review of
the set of drafts, sometime later today or maybe tomorrow, and we will be
looking for proposals from them to tell us whether the approach that we are
taking allows for extensibility, if need be, without necessarily revising these
set of drafts continuously so, please, if the framework of these drafts looks
good enough, then other working groups can extend the models Henk:This is Henk
again and addressing the concern of perpetual churn, we don't want that, so
it's basically the same scope, but I think it was like more like an oversight
on the on the DTLS part, so we are not not moving outside TLS and SSH here, so
the requirements are coming from the same document.  We actually have the same
scope but we are now completing that scope i think, and beyond that, it should
be different drafts or someone else managing us Tim: okay so what I understand
what you're saying, Henk, is is that the that the base, what we would consider
to be any base draft that would come out of NETCONF, will incorporate both SSH
TLS and DTLS and then we kind of missed the DTLS, and that we are agreeing as a
working group that DTLS is a core secure transport for the work that we do,
right? Kent: i don't know which hat i'm using at the moment, but this working
group is primarily focused on NETCONF and RESTCONF, and they only have SSH and
TLS as official transport bindings not yet, sorry Henk, and that's why I
mentioned before that even TLS itself has already the need to support
pre-shared keys and raw-keys, it's in the TLS draft, so our support of TLS for
our own purposes is already incomplete and that's what I'm saying Tim: so
you're saying that it's not a DTLS thing Ken: Correct, what we have already is
incomplete. Henk raised it, and he absolutely correct, it would have been
caught by IESG had we tried to take the Last Call, but it's better this way
that we can while we're the focuses on trust anchor getting to Last Call Tim:
but we would expect CORE to take if they want to use this for detail us we
would do anything different, right, we would expect CORE to take it Kent: after
trust-anchors has been published, if any other group wanted to extend it and
add another kind of trust anchor, then it would be another draft defining YANG
augmentation and it would proceed that way Heck: basically, this is luckily
coincidence that this is not exceeding your scope Tim: okay good

*** ACTION: authors to extend trust-anchors draft to include support for
pre-shared keys (pairwise symmetric key) and raw keys to trust-anchors draft.

Kent: (regarding the IESG meeting on Sunday) Ignas, did you want to say
something about that? Ignas Bagdona (NETCONF AD): yes, this was discussed
briefly at IESG Sunday meeting and the outcome of that is that there is no
outcome at this time right and what is needed is that probably this working
group needs to think of what are the proposed options?  Either we don't have a
registry but put a hardcoded values into into the documents and we spin that
every time, or have a unified registry which is on the IANA side, or have
something in between?  this is something for probably NETCONF here to think
about that and provide a recommendation what you would see, what would be more
stable in the longer term.

*** ACTION: chairs to ensure working group considers options for crypto-types
solutions

Kent: (regarding the posibility of leveraging COSE's work) Henk, did you want
to speak to that? Henk: This is Henk again.  It is for COSI, for the CBOR
variation, but Jim Shot (sp?) is the expert on this registrybut all the
participants there in the group did an awesome job.  it's key-pair parameters,
its curves, its hashing, its signatures, its crypto and it's always in
combination that are safe, withf key strengths and so on.  It's very elaborate
IANA registry already there, it's pretty much, I don't want to like to say
complete, but it's very very detailed already, so this could be another
well-maintained source for everything crypto. I'm not saying that is complete
for your scope because, it prunes some of the very old stuff and of course of
the deprecated things, but it's the best maintained IANA table I know, so maybe
yeah. Frank: Frank Xia(ling), Huawei, I have interest and general question
about this kind of thing. thank you that you have mentioned that for the COSI,
for this technology, we have a very complete crypto algorithm on the IANA page,
right?, so what is the relation with this new IANA page and the with the
existing IANA pages for TLS, IPSec, and SSH?  and what is your future plan of
how to align with them, and you know this is a very important the problem Henk:
yes, this is Henk again, this is not resolved yet, so we have either the option
to choose in the module where to go to but this can be very confusing and it
would require a lot of implementation and complexity, so that's usually a bad
idea, but if they're gaps and if you see, maybe an assessment of the tables is
an order, but you're TLS-based so that's a way to go, you cannot do something
wrong there, I think.  From the YANG of Things point of view, we could just
document that and have an extension point that there is good to augment, so the
YANG of Things realm could do that just and live with that, and that's okay.  I
just wanted to highlight that there's another table, it's well maintained, and
it goes beyond what TLS does, but it might not be complete because I have not
made a one-to-one comparison of those, actually, this is just the first
discussion about this. Frank: my personal comments is that it's not the
responsibility of the individual or group charter to maintain or reflect the
latest update of crypto algorthms. I hope that those IANA pages can, you know,
can be aligned with each other, and they (IANA) take care of this kind of thing
and we just reference to them. I think that's the best way, for not only for
our draft, but also for future another draft, right, IANA should take care of
that module or this kind of thing. Kent: okay great, you're right, this is
definitely a good resource for us to look at and in terms of potentially
folding some of those ideas into what we're trying to achieve with this
approach.

*** ACTION: authors to consider the COSI registries maintained by IANA

Rob: Rob Wilton, Cisco.  Why would you spit it in many IANA modules something
missing that step as to why it goes from one to many Kent: that is the second
bullet point so, again, as unclear to me how important it may be to me, fomr a
programmatic perspective it doesn't matter, but from a maintenance perspective,
especially for asking IANA to do the maintenance, it could be helpful to them
that then it's been broken up too many modules.  In either case, it'd still be
one draft, this crypto type draft would continue to be the draft, but would
instead create all these modules,if there were many modules, it'd still be one
draft that defined all the modules and assign them to the IANA Rob: so those
modules, are they are they representing what the different security working
groups are producing Kent: exactly, for instance, there would be a module that
be for symmetric key algorithms, another module for asymmetric key algorithms,
another module for hashing algorithms, if it makes sense to break up that way

*** ACTION: authors to consider fallback strategy

[ The following regards "Discussion 2"]

Rob: Rob Wilton, Cisco. Is it safe to have a single operator wide
symmetric-key.  I mean, is that good security practice, in the sense of, if
that key gets compromised, do you then effectively compromise all the devices
and, if so, with these schemes to work if rather having a single operator wide
symmetric key they were managing separate keys for each device so, when you RMA
it, you use what  keys it has Kent: sure you're right it could be the case that
it's a per device symmetric key, not operator wide.  You're right that its just
more maintenance, the operator has to remember what was the symmetric key used
before for each device, but it could be done. Rob: that's their choice Kent:
that's their choice, specifically, the crypto officer's choice.  We push the
problem to them, one solution would be a per device symmetric key, another
solution might be to design some code around a symmetric key stored inside a
TPM of some sort, and then they develop a client that basically does a
handshake transferring this symmetric key to the new device in a way that in
was never revealed to the crypto officer what that symmetric key value was. 
That's also possible Rob: okay.  I think having some Security Considerations of
this and speaking of security people about whether this works would be good.

*** ACTION: authors to add additional information to the Security
Considerations section.

Rob: one other question I have on the bottom on you so you so you modify the
old device to remove the old operator wide key.  why is it better to do that
versus another way? Kent: remember, the first bullet point was saying to go to
the new device and load a new operator wide key, the second thing is if, and
maybe this is out of order, but the second thing I'm thinking if you load that
configuration from the old device and it has a new definition for an operator
white key that would overwrite the value that you just stored, so it you're
kind of like avoiding that overwrite, so maybe just change the order this, load
the old config and then manually overwrite the old operator Rob: or another way
expressing this would be to say when you write that old configuration, you need
to strip out the old device key Kent: or replace it Rob: yes Kent: with a new
one Rob: yeah Kent: there's different ways of saying this, but the intention is
that it's the same symmetric key, it's just encrypted with a different public
key, because it's a different device and your device has a different, it's
actually the same symmetric key value, just encrypted differently, so the
config is slightly different for that reason. Rob: okay

Frank: I just want to know, how these symmetric keys used
Kent: the symmetric key is actually currently only being used for this purpose,
for encrypting other keys. in fact, the data model up until the very most
recent version of the draft did not have this symmetric key section.  There
were no symmetric keys being stored in the keystore, the reason being that it'd
be foolish to have the symmetric key value in the configuration where anybody
could see it, all security properties would be lost, but now that we have the
ability to encrypt the symmetric key then it opens up the possibility that the
symmetric key can be stored safely, so that's one, and then, two, we can then
use it to encrypt all those other keys that are being for instance used by SSH,
TLS, etc.   So that's how it's really being used currently but, to Henk's
previous comment about extending the TLS support and truststore to also support
pre-shared and raw keys, I would like to have those keys also be encrypted with
the symmetric key so that would be another use that I'd be thinking about

Rob: yes, can you go back to open issue one, so now for this one, your point at
bottom, the cons, that it might be better to define an annotation to mark this
configurations read-only, the status read-only, so the factory default
datastore is already read-only, by definition, and running is controlled by the
client, so I didn't get that bit, what you mark as read-only? Kent: I'm sorry,
what is the question? Rob: so the annotation, is you suggesting I have me an
annotation to mark something as read-only Kent: yes Rob: but in factory
default, already everything is read-only, same in operational Kent: right Rob:
so what's your what's the annotation annotating Kent: oh okay what's the
anotation doing? Rob: yes Kent: okay, remember factory default is kind of like
startup, where it really is it's a place where you copy and and you initialize
<running> Rob: right Kent: it's the first <running>, effectively, it becomes
<running> and then, you're doing a <get-config> on <running> and that's when it
would be helpful for some people to know that some nodes are actually read-only
value, kind of like with-defaults you're being told this is actually a default
value Rob: okay, so you say effective you try to write to one of those values
in <running>, the device would reject Kent: that's the intention, yes Rob:
yeah, I'm not sure I like that Kent: okay.  We can hard code it for this draft
and not create the annotation, but I think there's an opportunity to create an
annotation that could be extended to be used in other use cases as well, we
don't have to hre, I'm just opening under so possibility, let's take an online.

*** ACTION: authors to take annotation idea to list.

Mahesh: we have a comment on jabber from Henk saying "yes, providing
confidentiality to key material should include all key material" Kent: okay

Balazs: Balasz, Ericcson. This annotation could be very useful for server
capabilities somes times, where you can't change them because the capability is
read-only, but you want to reference them, for example in 'must' or 'leafref'
statements Kent: okay Rob: Rob Wiilton, but then I question whether they're
running configuration, I think capabilities still needs to be solved, but I'm
not sure that's configuration. They are not coming from the operator. Kent:
well but I think what Balazs the saying is like, when I2RS did the topology
drafts and, the topology was being discovered through the data plane and
populating operational, but then they wanted to have configuration that would
extend it in parts of the topology that was discovered, they needed to promote
the values to configuration.  We told them at the time was okay to copy those
nodes from <operational> and put them into <running> and the intention is that
when it got committed, that the device would know that this is something that
is already in <operational>and hence doesn't need to be created again.  But, to
Balázs's point, it be actually helpful if they could be tagged, a bit like with
'origin' tagged as to know this is actually a value that came from
<operational> or this is actually a value that is read-only Balazs: exactly I
don't care if we called it <running> or not <running>, it's a value that was
discovered from somewhere, in capabilities cases probably from the software
itself, and then I can puta 'must' statement indicating that some configuration
is dependent on the device being capable of supporting some capablity. 
Currently, you can't put a 'must' between "config false" and "config true",
this is the way around that. Rob: Rob Wilton, Cisco. So I wondered in that case
whether you want to be getting that configuration to <intended>, so in
<intended> you I have more freedom to be allowed to inject system-configuration
and templates and things.  There is more freedom there, and that's where you're
doing the validation, so still see that the ideal for <running> is it's just
what the operator provides, so they say, this is the config file for what that
device should be doing, and they have complete control over that and then you
merge it with <intended> which is where I  see these sort of default keys
coming in,  validation all works because it's actually effectively <intended>
that's validated and <running> is implicitly valid by the fact that <intended>
is, but not updating <running> Kent: hmm okay so let's flesh they're on the
list, again, this is an open issue so it needs to be discussed on the list and
it I hope to see you responding there Rob: yeah

[ The following regards "Discussion 3"]

Rob: I think that if the authors think that it should be done then I would do it
Kent: perfect

*** ACTION: authors to decide if to propogate the restructuring from
restconf-server module to the other three modules.

Kent: ok, so that's it, thank you for the input.

Mahesh: so just quickly summarize the next steps that you have planned for the
summary of drafts. I know one of them is the definition of whether we want to
go to the IANA registry, what format should look like anything else Kent: I
always feel guilty answering this question. Every IETF, it comes up and, of
course, the pressure is to say you know we'll get it into Last Call in two
weeks time, and then it slides.   The reality is as I just mentioned
crypto-types traps is we're having SecDir review.  It needs to go to IANA.
There needs to be a discussion if we can do the right thing or if we need to do
a fallback thing, how long will that take to play out, I don't know but it is
the dependency of everything, everything depends on it.  It's also the long
pole in the tent.  Then there's the trust-anchors draft, which I thought was
done, but Henk just mentioned that there's a desire to extend it to support
preshared-keys and raw-keys, and we need it, it was an oversight we should have
done it, we'll add it it's a little bit more work, but I think it'll take less
time than it will take to get the crypto types thing to resolve.   And then,
lastly, keystore, which I just presented, I think we're done there's a couple
points about open issues, one and two, which we need to resolve, but they look
relatively minor, and definitely should resolve sooner than the crypto types
so, ultimately, it comes down to how long will it take to get crypto-types
draft done, and I don't have an answer for that.

Mahesh: does anyone have more questions.
Kent: I don't have any more questions
Mahesh: thank you.

 Balazs Lengyel (10 min)
   YangPush Notification Capabilities
   https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-01

Benoit Claise, Cisco. so actually I like very much on-change flexibility. For
example we could have on-change on the entire datastore or we could have
on-change for  specific feature. For example the question is not how complex
you want to have it, the question is how reliable we want to get this contract
with the box. If I go on a box where the minimum of that period is for entire
datastore, great, but there are some other where the cadence that you want to
get information on is different on a line card for example for a specific
interface. We want to get the contract whenever you connect to a box to
understand the minimum of the period for each of the different things you can
get. In the contract and we connected to it tells me for this part of the three
I could get you every half a second but for the other one interface counters on
their line card on this big box I could do 30 seconds.

I get it that it might be complex but we might be getting the same flexibility
that we've got below or at top as well.

Balasz: I see it as somewhat different because these global minimums are saying
that the best the box can do in any part of the data model any datastore is, I
don't know 170 seconds, and then you try that for interface, oh, interface
sends you back only at 2 seconds. You still have that reliability. It's one
more round trip you can put it in the date. These minimums mean that that's the
best the box can ever give you. Maybe some parts will give you a worse value.

Benoit: Maybe it's not the right question to ask what is the best that box can
do. I want to get like my FIB information every 10 centiseconds or whatever is
the minimum the box advertises. The box then replides , no Mr. Customer, it's
common sense to get it every 5 seconds. It is a question of consequence and
setting the right expectations or to rely on the information.

Reshad, Cisco: Just to add to what Benoit was saying, in terms of
implementation you have collectors and sensors with different  hardware and
have very different collection capabilities. You already have fields per sensor
path and it's not like you're adding an extra list. If you put the update
period per path, and it could be optional by default then there's some
significant benefit.

Balasz: I can live with changing the model.

Robert Wilton, Cisco: I have not read the latest version the draft. I have two
questions though. One is this information available offline? Is it like
instance data?

Balasz: This is a yang model and I very much hope that instance data will be
provided but that's really up to the vendor to decide

Robert: The second question is in terms of these paths if you have a device
that supports many interfaces, can you wild-card those paths to say the
counters under an interface on any of these types of interfaces will have the
same performance, without having to list every single interface?

Balasz: At this point I'm using node selector from an ACM which might be moved
to use the YANG types that say it's the format is the instance identifier but
you can omit the keys,  meaning then it is every key value. If you want to go
into more specific Ethernet interfaces or fast Ethernet interfaces then you
have to do that one by one.

Robert: Okay.

Balasz: I don't think we want to have a full regular expression language
embedded here.

Robert:  No and I agree and I think that's probably right compromise. But it
goes back to what Benoit was saying, is that ultimately this is a contract. I
think contracts of what's the minimum capabilities you're willing support
rather than necessary the maximum. So if you say I can support a damping period
of five seconds or with me then you should effectively be able to honor that
for everything.

Balasz: On-change means I really promise to support it. But these periods
either global, or if we put them per datastore, that node or pair,  you might
still have a CPU overload. I don't think they can ever be taken as a guaranteed
time.

Robert: Would you reject that subscription if it came in and you couldn't honor
it?

Balasz: I think the subscribe notification drafts says  you reject it and say
that try with the double the time or whatever time.

Robert: Okay.

Balasz: But not less.

Benoit: I want to come back to what you said if you can't guarantee the minimum
of the period ...  There are multiple ways that you could do telemetry.  The
point is that we should do the best that we can for a device is healthy. If the
device is not healthy because it's CPU is overloaded etc.  ...  The point is
that I connect to a box and  have a contract.  I understand that you want to do
this for two different use cases, implementation time and run time. I care
about the run time at discovery.

Balasz:  I would change the model by putting all these values under the lists.
It will need to be renamed in that case. still I think that it's not. But the
device still has the right to say that I can support on the double time.

Benoit: Thank you.

Balasz: That means that on-change capable nodes list you have to be renamed to
datastore subscription capability or something like that and all these update
periods max objects and minimum damping period will go under that list.

Mahesh: About last call, looks like you need to make some changes first.

Balasz: Yes, this model needs update,but after that I hope it can go to last
call.

Kent: Just get a sense from the room - How many people have read this version
of the documemt? Raise your hand. A few, and there's no really follow-up
question. We are not going to do a last call at this time.

***ACTION: Author(s) to update the draft/model based on the comments received.

Non-Chartered items:

   Tianran Zhou (10 min)
   Subscription to Multiple Stream Originators
   https://tools.ietf.org/html/draft-zhou-netconf-multi-stream-originators-06

Kent: By channels do you mean line cards?

Tianran: Yes, each card will have a channel.

Tim Carey, Nokia: We did have a question and I think I brought it up the last
time. The question was  again about the IOT use case and my concern was that
outside of a closed ecosystem, a network element itself would have to have some
additional capabilities in place to to be able to discover the capabilities of
the network element. So if you tried to extend this to anything outside of
closed ecosystem I think there's some considerations that need to happen for
the solution to work correctly and all the security that goes around it.  Right
now you're just constrained to a locked box. If you look the extended past that
then you got to worry about discovery and other elements. That would be my
concern with the IOT use case.

Tianran: What's your suggestion so you think we should not include that's in
the chapter or ...?

Tim: If you want to go into those other use cases you're going to have to
address these different issues and so I don't think that that was your original
intent with this draft. You're just trying to say look I've got a I've got a
closed ecosystem that I'm gonna put together a master publisher that's gonna
kind of coordinate that stuff instead of having different streams.  That's
effectively what this was doing right and so I would keep it into the context
that was in if you do choose to make it broader then you're gonna have to
address these other issues.

Tianran: Okay, thanks.

Kent: As a contributor my takeaway from that would be at a minimum the draft
needs to have a section that speaks to this and at least identifies that
intention and then there's question of whether or not the draft actually solves
it. So one potential solution might be for it to define in config policy an
operational state that lists out the channels that the device is having
available that subscriptions can be made on. That would be one way to solve it.
Another might be to look to the equivalent of an entity MIB where you can
somehow discover the line cards that existing on the device and then derive
from that what might be suitable for using as channels destinations. In either
case, I think, this draft needs to talk to it and and choose an approach.
Either say that it's out of scope and and you know it's only going to support
closed ecosystems as Tim suggested,  or it's in scope and point to a solution
that people can use.

Guangying from a Huawei,  I just wanted to menton that we have already
implemented this in one of our  machines.

Kent: As a contributor, I think we discussed this on lists and the with the
channels it was unclear to me that the channels was a lists of channels or ..
We don't have a YANG model that is yet defining this this node or this
container called a channel or actually is a list. Presumably it should be in
this draft. Well actually it should be in the SUBSCRIBED notification draft

Tianran:  It is not included in the in the YANG model in the draft but if we
can agree then I would like to add a channel list under the receiver. That
means that each receiver can have several channel configurations.

Kent: Again as a contributor and also as co-author of the HTTP notif draft that
Mahesh will present after your presentation, that HTTP notif draft is the first
notif draft that we have that this working group has produced for a configured
subscription and the approach it is taking which is in fact was sort of you
know suggested or we're almost mandated by these subscribed notifications draft
or what are now almost RFCs are almost first was to augment the receiver nide
and so that's what that draft does. It augments the receiver node  and then
what you're suggesting is that there'd be a channel that's underneath the
receiver and that it should actually be augmenting the channel node. So how
does is it it know am I supposed to be augmenting the receiver note or am I
supposed to be augmenting the channel. The intention the notif draft is kind of
somewhat independent of the transport and as such out of the context. How would
it know if this is a device that has linecard or not and what is the
appropriate augmentation point. I think that's the issue with this draft.

 I think what I understood and just sort of restate it what you're saying is
 that the HTTP notif draft could actually have two augments,one to receiver and
 the other one to channel and each of those arguments could be with a feature
 statement so that you know it's only one or the other or maybe both I don't
 know. Or I think,

 Tianran: No need to do that because  the channel configuration is also under
 the receiver, so you augment your configurations to the receiver of the
 subscribed notifications draft.

 Kent:  But the subscribed notification draft  doesn't itself have a channels
 list and so devices that only implement that RFC will not be having channels

 Tianran: I realized this. I send a email to you to suggest to your transport
 document include these channel configurations so that it can be compatible if
 you only enable one channel or multiple channels.

Kent: There can be many notif transports that are defined. The HTTP notif is
just one of many possible. I don't think we want each of those notif transports
to themselves happen to be augmenting it and optionally implemented channel.
That's is not the right place to do it. I think that you guys can have a data
model that augments the receiver lists adding in a channel list. ome devices
will implement it others won't . The notif draft  could actually have it that
they have a dependency both to subscribed notifications as well as to your
draft with two arguments and there's a feature effectively that the server
chooses whether or not to be  augmenting one of the sub channel list if it
exists or not. If we move the channel list into the HTML notif draftand it's
only one of many possible notif ... that it's not the right location for it.

Balasz: Ericsson. I'm confused by a statement on this list all potential
channels are pre-configured so others this configuration data config true nodes,

Tianran: Yes it is configuration.

Balasz: How do you prevent the user to add or remove channels that actually
exist or are dummy? We have that problem in many places and have a Ericsson
specific or 3gpp specific solution, but what is your proposal?

Tianran: I actually do not realize your problem.s

Balasz: I see that all channels are pre-configure.  But what prevents the
operator from going on and saying that there's also Balázs channel. Actually
there's no such thing but it looks like from now on as if it was there. So how
can you prevent someone messing up this pre-configured set of channels.

Kent: There's two things. There's the adding of channels to don't exist and
there's the forgetting to configure channels that do exist or removing channels
that were pre-configured.

Mahesh: We have a comment on jabber from Eric . He says I support Ken's
proposal for multi-stream originators. Note, you can augment subscribe
notifications or some objects and multi stream multiple line cuts are needed

Kent: Let's take a step back. Why do we want to have it list the channels at
all?  The reason why is because some protocols require her channel
configuration per instance and actually it's questionable. For instance in TCP
you may want to specify the source IP address on a per line basis. Also for TLS
you may want to specify the cryptographic credentials on per line card basis.
But those are TCP and TLS specifics. Not all notifications transports will
necessarily have either or any such considerations. For instance a flat UDP
let's say syslog or UDP has none of these concerns and so a global
configuration of syslog over UDP be for just going to receiver you, augmenting
receiver and then there  could be a global flag that says I want these line
cards to be able to send syslog over UDPstraight out the data plane and that's
it we're done. It's just a global flag there's no need or a per line card
configuration of any sort.

Mahesh: In the interest of trying to move this draft forward one conversation
that the chairs were having was to figure out maybe we need to put a design
team that might be helpful for the authors and if such a design team would be
formed if people here would be interested in and of contributing to that design
team. Identify the problem, maybe define the scope of the draft and help to
move it forward that would be one way we  would suggest how you move forward.

Tianran: A design team is very welcome

Kent: To be clear the work group very much wants to adopt the draft and we
think it's important work. I shouldn't say the work group. I can't speak for
the group. So would anybody be willing or to work with the author on a design
team.  I see some hands so that's great and you everyone in the room who raised
their hands can send a message to the author so they can sync up.

***ACTIONS: Authors to work with members of the design team to clearly identify
the problem statement and the scope of the draft.


   Mahesh Jethanandani (10 min)
   An HTTPS-based Transport for Configured Subscriptions
   https://tools.ietf.org/html/draft-mahesh-netconf-https-notif-00

Reshad: Cisco. Why is it called HTTPS and not RESTCONF? Is that deliberate or
... ?

Mahesh: t is HTTPs and it doesn't have the heavy load of supporting RESTCONF.

Rob Wilton:  Cisco any thought to using binary coding here.

Mahesh: Good question yes I guess there was that draft presented early on and
COAP is also suggesting a binary based notification. So that's certainly
something we could consider.

Kent: As a contributor this draft actually supports both JSON and XML and the
way it does so is through this subscribed notifications draft.  Inside that
draft'sdata  model there's a leaf called encoding-identity with  types XML
JSON.  In theory it could be extended to support binary.

Ignas Bagdonas: So again serious question is the working group sees this as the
work that is needed if the community would eventually see this being deployed
and used.  Can I see a show of hands. A few.  Who has read this document.  All
right. I think this needs to be raised into the mailing list about adoption
please read the document and please provide your comments and feedback. From
those hands it's a little bit premature to ask this question right now and
here, so let's take this to the mailing list

Reshad: I have read the draft in detail and it's well written, and it matches
well with subscribed notifications draft and  all that so it's all good. But
one thing I was asking the restaurant question before is we don't actually have
an HTTPS draft for dynamic subscriptions. We have NETCONF and RESTCONF,  so is
it just for configured subscription or is there something else for dynamic
subscriptions. That's the part I'm struggling with.

Kent: So first I'll thank you Ignas for running these question. We'll take it
to mailing list. Aand then back to Reshad about question which you raised
before. With a contributor hat on.  Over the course of several IETFs we did
raise and talk about this discussion and certainly dynamic subscriptions have
to be RESTCONF and NETCONF because you're coming in over a RESTCONF or NETCONF
connection to begin with. With configured descriptions is it the best choice
like if the device is going to proactively initiate a connection to a receiver
would that should that connection be of RESTCONF connection which all that into
it entails.Meaning it's a full connection with configuration and operational
datastore  etc type connection. Do we want all that or we were looking for
something smaller, simpler. Remember this is being implemented on linecards so
it has to be simple and people talk about pushing notifications -  syslog, SNMP
is sort of the baseline for what we're doing. The next simplest thing that
we're thinking is HTTPS because it is fairly simple protocol and and it doesn't
come with it any of the extra management overhead of RESTCONF.

Balasz: 3GPP has recently started defining  yang solution set for number of OAM
issues and they actually stated that they prefer a configured way of
subscription. So I see this is important.

***ACTIONS: Bring adoption call to the mailing list.