* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Netconf Status Pages

Network Configuration (Active WG)
Ops Area: Ignas Bagdonas, Warren Kumari | 2003-Apr-30 —  
Chairs
 
 


IETF-105 netconf minutes

Session 2019-07-22 1000-1200: Viger - Audio stream - netconf chatroom

Minutes

minutes-105-netconf-00 minute



          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
          Rob: right
          Kent: it's the first , effectively, it becomes  and then, you're doing
          a  on  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 , 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  and put them into
          and the intention is that when it got committed, that the device would
          know that this is something that is already in 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  or this is actually a value that
          is read-only
          Balazs: exactly I don't care if we called it  or not , 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 , so in  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  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  which is where I  see these sort of default keys coming in, 
          validation all works because it's actually effectively  that's validated
          and  is implicitly valid by the fact that  is, but not updating
          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.
          
          



Generated from PyHt script /wg/netconf/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -