IETF
mif@jabber.ietf.org
Thursday, November 7, 2013< ^ >
danyork has set the subject to: MIF Working Group at IETF86 in Orlando
Room Configuration
Room Occupants

GMT+0
[02:18:45] Peer Azmat joins the room
[02:51:41] Peer Azmat leaves the room
[19:29:39] Peer Azmat joins the room
[20:02:06] Peer Azmat leaves the room
[20:17:30] Peer Azmat joins the room
[20:45:43] Peer Azmat leaves the room
[20:54:14] Peer Azmat joins the room
[20:55:23] dmitry.anipko joins the room
[20:59:18] dmitry.anipko leaves the room
[20:59:42] dmitry.anipko joins the room
[21:00:28] Ole Troan joins the room
[21:02:00] Ted Lemon joins the room
[21:03:07] <dmitry.anipko> yup, audio stream works
[21:03:12] Dave Thaler joins the room
[21:03:14] <Ole Troan> Audio stream is working, but quite low (as usual)
[21:03:32] ndelregno joins the room
[21:03:42] <Peer Azmat> @ Ole: Yes
[21:04:00] Andrew Yourtchenko joins the room
[21:05:43] sarikaya2012 joins the room
[21:07:02] <dmitry.anipko> hi
[21:07:02] <dmitry.anipko> :)
[21:07:09] Ted Lemon leaves the room
[21:08:33] Brian Carpenter joins the room
[21:14:04] <dmitry.anipko> there is no default hard binding between PVDs and interfaces. PVDs are dynamically discoverable in the interface
[21:14:25] <dmitry.anipko> the entity that provides PVD information, may have chosen to deploy same PVD ID  on multiple interfaces, or different PVD IDs
[21:15:19] Alex Petrescu joins the room
[21:15:30] <Alex Petrescu> Sri Gundavelli is SG
[21:15:35] <Alex Petrescu> SG: not clear...
[21:15:39] <sarikaya2012> This presentation is at http://tools.ietf.org/agenda/88/slides/slides-88-mif-1.pdf
[21:15:47] <Alex Petrescu> Hui Deng is HD
[21:15:55] <Alex Petrescu> HD: per id id
[21:16:13] <Alex Petrescu> Dapeng Liu is DL
[21:16:15] <sarikaya2012> MPVD is multiple provisioning domain
[21:16:25] <Alex Petrescu> DL: http proxy? as local configuration?  combine it into the pvd?
[21:16:28] <sarikaya2012> O:)
[21:16:48] <Alex Petrescu> DL: local configuration into the provisioning domain possible?
[21:16:53] <Alex Petrescu> Tim Chown is TC
[21:17:00] <Alex Petrescu> TC: thats application specific, from browser to host
[21:17:10] <sarikaya2012> AP is Alex Petrescu O:)
[21:17:10] <Alex Petrescu> Dave Thaler is DT
[21:17:24] <Alex Petrescu> DT: would not think of http proxy typed into the browser would not be part of  PVD;
[21:17:30] <Alex Petrescu> DT: or rather a second one?
[21:17:50] <Alex Petrescu> DT: on another hand, browser automatically detects, goes off, queries the network to obtain that http server
[21:18:01] <Alex Petrescu> DT: http proxy is there because..
[21:18:09] <Alex Petrescu> DL: this may need some claricication
[21:18:12] <Alex Petrescu> TC: app
[21:18:16] <Alex Petrescu> Ted Lemon is TD
[21:19:01] <Alex Petrescu> TD: concern about case with more than one?  trust a n http proxy from one PVD, but less trust a PVD from another PVD?  (on starbucks, but trust better the other? (like IETF's or so))
[21:19:06] <Alex Petrescu> DL: ?
[21:19:15] <Alex Petrescu> TD: related to network or not come from network?
[21:19:38] <Alex Petrescu> TD: plug an IP address with a configuraiton of MAC thats just a n IP address, move to a different PVD then it breaks.
[21:19:44] <Alex Petrescu> DL: agree
[21:20:05] <Alex Petrescu> DT: real question: relationship between PVD and local config?  My answer is not part of same PVD, then another.
[21:20:14] <Alex Petrescu> DT: just another case: apply to same network
[21:20:32] <Alex Petrescu> TD: mutliple PVD we talk about, or delivered by different means (DHCP vs RA)
[21:20:49] <Alex Petrescu> TD: PVD foo, look local then look externally
[21:20:57] <Alex Petrescu> DT: but already aware?
[21:21:03] <dmitry.anipko> can please someone relay to the mic, to answer DT: hosts are allowed to augment PVD with local config, based on knowledge host has
[21:21:07] <Alex Petrescu> Mikael Abrahmson is MA
[21:21:19] <Alex Petrescu> MA: next is locked down, proxy, PVD specific
[21:21:51] <Alex Petrescu> TC: applications completely unaware is one thing that draft says, the other thing the draft says, and a middle says that...
[21:22:06] <Alex Petrescu> Alper Yegin is AL
[21:22:06] <Dave Thaler> i can relay if you want
[21:22:11] <dmitry.anipko> thanks :)
[21:22:13] <Alex Petrescu> AL: PVD is like a virtual network concept to me
[21:22:23] <Alex Petrescu> AL: virtual network, and authentication aspect
[21:22:41] Ted Lemon joins the room
[21:22:42] <Alex Petrescu> AL: previous example, local configuraiton, you can set the PVD, but my q iscan we have Global identifiers?
[21:22:49] <dmitry.anipko> to DT: specifically section 5.1
[21:22:51] <dmitry.anipko> A node may use other sources, such as e.g., node local policy, user
   input or other mechanisms, not defined by IETF, to either construct a
   PVD entirely (analogously to static IP configuration of an
   interface), or supplement with particular elements all or some PVDs
   learned from the network, or potentially merge information from
   different PVDs, if such merge is known to the node to be safe, based
   on explicit policies.
[21:22:52] <sarikaya2012> @AP, it should be AY
[21:23:01] <Alex Petrescu> TC: maybe yes, like strbucks, or maybe 'implicit'
[21:23:19] <Alex Petrescu> right Alper Yegin (I wrongly wrote AL)
[21:23:29] <Alex Petrescu> Sri Gundaveli is SG
[21:23:35] <Alex Petrescu> SG: can I malke a relation to...
[21:23:37] <dmitry.anipko> to the current speaker: not necessarily
[21:23:41] <Alex Petrescu> Hui Deng is HD
[21:24:11] <Alex Petrescu> HD: we all assume authentication is there, but multiple reservatin ID, different authentication identifier (maybe same auth source) and then still have PVD...
[21:24:16] <Alex Petrescu> SG: but example please?
[21:24:23] <Alex Petrescu> SG: parameters specific to that network
[21:24:39] <Alex Petrescu> TD: identifiers you provied to network?  If yes, then its opposite to what we think
[21:24:41] <Alex Petrescu> SG: its mutual
[21:24:47] <Alex Petrescu> TD: you said one way, but not
[21:25:24] <Alex Petrescu> TD: a q of one vs multiple domains, may make sense, from one pvd if one provider, or two pvds is different..
[21:25:34] <Alex Petrescu> TD: we may provide 2 different ids to the providers
[21:25:40] <Alex Petrescu> Dmitri Anipko is DA
[21:25:47] <dmitry.anipko> :)
[21:26:03] <Alex Petrescu> DA: local config http, host would allow auth..., quote section 5.1,
[21:26:33] <Alex Petrescu> DA: either construct PVD entirely (static IP config iface) or supplement particular with... or potentially merge, based on explicit policies.
[21:26:41] <Alex Petrescu> DA: any of those 3 could be done.
[21:26:56] <Alex Petrescu> AY: expose PVDs to the apps, bind to target PVDs, impact src address selection
[21:27:07] <Alex Petrescu> TC: mentioned in the document and in the charter I think
[21:28:56] Dan Wing joins the room
[21:29:02] <Alex Petrescu> Brian Carpenter i sBc
[21:29:15] <Alex Petrescu> BC: going on for years about referral problems, how we broke archi
[21:29:44] <Alex Petrescu> BC: conclusion is that we need to identify Scopes.  Your id may be a subset of that.  A form of ID with much more general applicability than what you think.
[21:29:48] <Alex Petrescu> TC: not yet detail
[21:30:03] <Alex Petrescu> BC: remember, Scope wcould be more than just MIF context
[21:30:12] <dmitry.anipko> to BC: can you please send the pointer to the doc to the MIF list?
[21:30:17] <Alex Petrescu> SG: unique ID? multiple PVDs then how about uniqueness?
[21:30:24] <Alex Petrescu> TC: not talked uniqueness
[21:30:29] <Alex Petrescu> Suresh Krishnan is SK
[21:30:42] <Alex Petrescu> SK: we not say how are they unique?  we just say how to bind themm together
[21:30:48] <Alex Petrescu> SG: common rule there should be
[21:30:57] <Alex Petrescu> DT: multiple ways to reahc reqs
[21:31:06] <Alex Petrescu> DT: one possibliitiy is hierarchy, or sufficient randmoness
[21:31:28] <Alex Petrescu> DT: take an existing id, put in this space, or create
[21:31:28] <Alex Petrescu> DT: that is solution space
[21:31:33] <Alex Petrescu> SK: we did that (?)
[21:31:45] <Alex Petrescu> DT: possibly hierarchy, thats one way to meet reqs
[21:32:01] <Alex Petrescu> SK: we put on table in the solution document all the above: a PVD ID type we have
[21:32:03] <Alex Petrescu> TC:...
[21:33:51] <Alex Petrescu> MA: connectivity test?  might be good as reachability information in homenet, default route
[21:34:04] ndelregno leaves the room
[21:34:17] <Alex Petrescu> MA: recommendation needed here, walled garden, avoid, so write something what could be reached.
[21:34:30] <Alex Petrescu> AY: connectivity test: not something that should go through PVDs, right?
[21:34:35] <Alex Petrescu> TC: right, no.
[21:34:56] <Alex Petrescu> AY: even in absence o PVD being used, you'd make same recommendation?
[21:35:14] <Alex Petrescu> AY: we dont degrade something, right?  such that we'd have torecoommend connectivity tests.
[21:35:14] <dmitry.anipko> to the current speaker: connectivity tests are recommended
[21:35:23] <dmitry.anipko> as an input used in decision making about which PVD to use
[21:35:27] <Alex Petrescu> TC: in the absence of, wed need happy eyeballs or so
[21:35:28] <dmitry.anipko> when multiple PVDs are available
[21:35:38] <Alex Petrescu> HD: did you consider 'TLS'?
[21:35:41] <Alex Petrescu> HD: TRS
[21:35:59] <Alex Petrescu> HD: VPN case is one of the cases of MIF WG
[21:36:06] <Alex Petrescu> HD: IKE-based, the other is TLS-based
[21:36:29] <Alex Petrescu> SG: no IP address ocnfiguration in TLS
[21:36:50] <Dave Thaler> if you want something relayed to the mic, prefix comment with "mic:"
[21:37:02] <Dave Thaler> do you want your comment above relayed?
[21:37:20] <dmitry.anipko> yes, thank you, and will do for future comments
[21:37:49] <Alex Petrescu> DA (relayed by DT): connectiviyt tests recommended as input...
[21:38:04] <Alex Petrescu> TC: so I have recommended; so that may be prior to what you...
[21:38:23] <Alex Petrescu> TD: really happy with the progress of the document and...
[21:38:33] <Alex Petrescu> TC: in the text there is complete text about binding
[21:38:46] <Alex Petrescu> DT: looking at the bottom middle of slide, second token, doesnt say IETF
[21:39:00] <Alex Petrescu> DT: should this be adopted as WG document
[21:39:03] <Alex Petrescu> TC: 'catch 22' (whatever that means)
[21:39:11] <Alex Petrescu> MA: nothing on the email list?
[21:39:32] <Alex Petrescu> MA: good to put properties, prefix properties drafts that should be incorporated here as well?
[21:39:39] <Alex Petrescu> MA: many things around coul dbe in scope
[21:39:44] <Alex Petrescu> TC: discussion in homenet?
[21:40:58] <Alex Petrescu> MA: in homenet there is potential of host needing awareness of multi.., prefix properties, different characteristics ( use a conneciton for backup when the other is down, one may be mmobile) theres got to be policies, no answer I have, but right time is this to put this here?  or wait mature more document?
[21:41:07] <Alex Petrescu> TC: good point, Chair please give us a stir on that
[21:41:11] <Alex Petrescu> HD: WG draft
[21:41:22] <Alex Petrescu> TC: coloring prefixes, theres are all related
[21:41:26] <Alex Petrescu> Gang Chen is GC
[21:41:35] <Alex Petrescu> GC: connects about connectivity testing
[21:41:40] <Alex Petrescu> GC: draft tests whether connectivity is available
[21:41:57] <Alex Petrescu> GC: as you know we have ongoing work in the 'IF' WG
[21:42:12] <Alex Petrescu> GC: please have evaluation , fit in current archi, refer to the current archi in the 'IF'(?)
[21:42:34] <Alex Petrescu> AY: prefix properties, not familiar with all, but some with mobility management I am- prefix supports session continuity
[21:42:56] <Alex Petrescu> AY: under single PVD you could have... keep the word separate; if other WGs come up with properties?
[21:43:02] <Alex Petrescu> TC: avoid precluding
[21:43:11] <Alex Petrescu> SG: prefix coloring is an approach to realize PVD
[21:43:21] <Alex Petrescu> SG: an address, PVD is an identifier
[21:43:26] <Alex Petrescu> SG: PVD ID is all this
[21:43:37] <Alex Petrescu> SG: PVD ID is a property to the identifier
[21:43:42] <Alex Petrescu> SK: disagree
[21:44:02] <Alex Petrescu> SG: PVD is ... color is... Prefix Coloring cant color DNS addresses
[21:44:14] <Alex Petrescu> SG: cost of prefix mbyte
[21:44:22] <Alex Petrescu> (that was SG)
[21:44:28] <Alex Petrescu> (sorry
[21:44:42] <Alex Petrescu> SG: V6, V4, al methofds I put that parameter
[21:44:46] <Alex Petrescu> SG: PVD ID
[21:44:57] <Alex Petrescu> SG: at end of day you keep relationhip of PVD
[21:45:04] <Alex Petrescu> SK: more than just prefixes
[21:45:09] <Alex Petrescu> HD: we discuss here...
[21:45:22] <Alex Petrescu> SG: Id like to present, comparative analysis, I want to present
[21:45:42] <Alex Petrescu> MA: if we define purpose of app, needs to be flexbile, be coordinated
[21:46:00] <Alex Petrescu> MA: coordinate with other people doing this.  This API may become very iumportant for app developpers
[21:46:16] <Alex Petrescu> HD: feedback was good; the question was already asked, we had discussion
[21:46:41] <Alex Petrescu> HD: you see not many email list discussion, but we ahave design team; maybe later we move that into the WG.
[21:46:46] <Alex Petrescu> TC: close we are to that point
[21:47:17] <Alex Petrescu> slide: MIF Chqrter updqte proposql
[21:47:28] <Alex Petrescu> Charter update proposal
[21:47:40] <Alex Petrescu> slide: -"- summary
[21:48:25] <sarikaya2012> The slides link http://tools.ietf.org/agenda/88/slides/slides-88-mif-2.pdf
[21:48:56] <Alex Petrescu> slide 3:  ... - pqrt 1
[21:49:00] <Alex Petrescu> part 1
[21:50:18] <Alex Petrescu> slide 4: ... - part 2
[21:52:29] <Alex Petrescu> MA: 1 does not exclude ther ecould be recommendations for apps could connect explicit PVD - is that on purpose ?
[21:52:32] <Alex Petrescu> HD: anyone
[21:52:39] <Alex Petrescu> TC: theres a 3rd point
[21:52:43] <Alex Petrescu> MA: but not API
[21:53:05] <Alex Petrescu> MA: coporate email client I have direct connect to corp LAN, I dont want it to see any connectivity
[21:53:13] <Alex Petrescu> MA: and the print discussion
[21:53:21] <Alex Petrescu> MA: do we want to put this in there?  or later
[21:53:27] <Alex Petrescu> DT: I agree, it is a q on the next lside
[21:53:46] <Alex Petrescu> DT: anything missing?  maybe come back later
[21:53:53] <dmitry.anipko> mic: to MA, there is text ". In addition to the new API, the behavior of existing APIs may be changed to improve
the behavior of unmodified applications.
"
[21:54:11] <dmitry.anipko> which covers the enterprise app case, but not explicitly
[21:54:26] <Alex Petrescu> message of DA relayed
[21:54:34] Mikael Abrahamsson joins the room
[21:54:59] <Alex Petrescu> MA: this doesnt require a change for the API?  IT is a policy to the stack?
[21:55:01] <Alex Petrescu> TD: no
[21:55:12] <dmitry.anipko> mic: both
[21:55:16] <Alex Petrescu> TD: doesn t habe to be implemented that way; it coul dbe the app wit a particular PVD
[21:55:32] <Alex Petrescu> MA: instead of running for 'vi'(?)
[21:55:33] <dmitry.anipko> mic: there is API change for advanced apps, and policy under the covers
[21:55:59] <Alex Petrescu> TC: when you trust PVD if you have
[21:56:07] <Alex Petrescu> message of DA relayed
[21:56:27] <Alex Petrescu> MA: last sentence of number 3 solves my problem?
[21:56:27] <dmitry.anipko> mic:correct
[21:56:37] <Alex Petrescu> DT: you ok with that?  or want it changed?
[21:56:45] <Alex Petrescu> MA: ok
[21:56:57] <Alex Petrescu> TL: ok
[21:57:23] <Alex Petrescu> (in the above I sometimes write wrongly TD, when its actually TL for Ted Lemon; no other intervenant starting with T)
[21:57:36] <Ted Lemon> :)
[21:57:43] <Ted Lemon> I was wondering who TD was.
[21:57:43] <Alex Petrescu> slide 5: ...- part 3
[21:57:46] Ian Farrer joins the room
[21:58:11] <Alex Petrescu> AY: only allow the app choose PVD?  that text seems to allow any compbination DNS, src
[21:58:13] Dan Wing leaves the room
[21:58:36] <Alex Petrescu> TL: LIF API dpocument we wrote earlier would allow that because it exposes info; whether you should that is another q
[21:58:59] <Alex Petrescu> DT: one presentation talks about the use of APIs by a Connection Manager;
[21:59:04] <Alex Petrescu> DT: normal apps wouldnt
[21:59:12] <Alex Petrescu> AY: my understanding o of PVD...
[21:59:31] <Alex Petrescu> AY: mor eparameters from multiple sources, but need to correlate with a single id, such that app...
[21:59:43] <Alex Petrescu> AY: but if you start compose, then you may loose utility of PVD
[21:59:51] <Alex Petrescu> AY: suggest to stick with PVD business
[22:00:01] <Alex Petrescu> HD: recomendation of yours sounds reasonable to me
[22:00:33] <Alex Petrescu> TC: may be there is, maybe at this stage it is very much so, based on app PV, or the app runs over a PV, just to indicate
[22:00:40] <Alex Petrescu> TC: not want to conclude
[22:00:47] <Alex Petrescu> TC: after 'element selection'
[22:00:51] <Alex Petrescu> HD: where is?
[22:00:57] <Alex Petrescu> TC: comma after the end
[22:01:11] <Alex Petrescu> TC: _or_ the app runs over, for example, thanks for the xercise
[22:01:45] <Alex Petrescu> TC: I will send you an email, this is just a detail;
[22:02:06] <Alex Petrescu> TL: I should mention that the way that last calls happen here, proposed charter should be by end of today
[22:02:23] <Alex Petrescu> TC: I could go, if useful, otherwise Id just sit
[22:02:37] <Alex Petrescu> TL: no more detail, its already covered
[22:02:55] <Alex Petrescu> TL: te more detail you have, the more difficult it is to review
[22:03:36] <Alex Petrescu> GC approach
[22:04:37] <Alex Petrescu> GC: q for clarification
[22:04:46] <Alex Petrescu> GC: we do happy eyeballs extension in the MIF WG
[22:04:57] <Alex Petrescu> GC: not sure which item to point to?  4 or so?
[22:05:06] <Alex Petrescu> GC: its already a WG chartered
[22:05:28] <Alex Petrescu> HD: I remember IIRC, connectivity testing desfcriebed in the archi document; not sure whether tha tpart covered the problem of happy eyeball
[22:05:49] <Alex Petrescu> HD: in the charter discussion I saw disagreement about solution; people favored the problem rather than the solution
[22:05:52] <dmitry.anipko> mic: the problem which HE solves would fall into deliverable 1 :...attached to multiple networks, which enable hosts to improve network connectivity for the host's applications and users"
[22:05:57] <Alex Petrescu> HD: do you propose connectivity testing or so?
[22:06:15] <Alex Petrescu> GC: not sure connectivity testing describes really the isssue; id rather sugest item
[22:06:32] <Alex Petrescu> HD: people is ok problme statemt of happy eyeball, more like connectiviy testing
[22:06:40] <Alex Petrescu> HD: ok to propose?
[22:06:42] <Alex Petrescu> GC: hmmm
[22:06:57] <Alex Petrescu> TC: one of the ways to approach that: applications for improved epxrience
[22:07:05] <Alex Petrescu> TC: imrpoved API usage
[22:07:11] <Alex Petrescu> TC: Happy PVDs
[22:07:13] <Alex Petrescu> room: laugh
[22:07:23] <Alex Petrescu> HD;: youd make happy PVD then people still concrned
[22:07:30] <Alex Petrescu> HD: connectivity testing is that rather
[22:07:54] <Alex Petrescu> DT: BC's point th ething missing here propose item: guidelines for gneeration and use PVDs
[22:08:08] <Alex Petrescu> DT: also include that - is it hierarchical, unique, but highlights
[22:08:17] <Alex Petrescu> DT: how to trust this
[22:08:22] <Alex Petrescu> DT: use DNSsec
[22:08:34] <Alex Petrescu> DT: I mean 'guidelines', and these are Brian's
[22:08:53] <Alex Petrescu> TL: we need more than guidelines, we need a spec for...
[22:08:59] <Alex Petrescu> Dima relayed
[22:09:28] <Alex Petrescu> SK: for the authoriwation part we do have some text: how we bind ID to some form of trust
[22:09:34] <Alex Petrescu> DT: this is charter text discussion
[22:09:49] <Alex Petrescu> Jouni
[22:10:10] <Alex Petrescu> J: because, from part 3, somehow brings me we need somewhere else
[22:10:20] <Alex Petrescu> J: we do saucer space?
[22:10:26] <Alex Petrescu> J: solution space ?
[22:10:33] <Dave Thaler> "Guidelines for generation and use of PVD IDs" was my proposed text
[22:10:43] <Alex Petrescu> TL: series of bullets here...
[22:10:48] <Alex Petrescu> Jouni Korhonen is JK
[22:11:08] <Dave Thaler> Ted wanted a word stronger than "Guidelines"
[22:11:08] <Alex Petrescu> TL: slide  says reqs for protocol changes
[22:11:09] <Alex Petrescu> TL: thats the q youre asking
[22:11:18] <Alex Petrescu> TL: DHC is probably going to do the DHCP work, and 6man is probbaly going to do the work for RAs
[22:11:24] <Alex Petrescu> SG: why not doing this in one gorup?
[22:11:52] <Alex Petrescu> TL: thos groups explicitely included that work in that charter, if we do that here then its going to be 'interesting'
[22:11:58] <Alex Petrescu> SG:...
[22:12:15] <Alex Petrescu> TL: do the work anywhere if the people want to do the work; an dthe usual suspects will do
[22:12:23] <Alex Petrescu> Brian Haberman is BH
[22:12:30] <Alex Petrescu> BH: what about mobility management?
[22:12:33] <Alex Petrescu> SG: thank you
[22:12:40] <Alex Petrescu> BH: little piece here, and there
[22:12:47] <Alex Petrescu> TL: you say better do the work here?
[22:13:03] <Alex Petrescu> BH: if we break 2 3 works ok, but 4 5 is what we say here...
[22:13:04] <Alex Petrescu> TL: I
[22:13:11] <Alex Petrescu> TL: I dont have any particular preference here
[22:13:25] <Alex Petrescu> SG: homenet, dmmm, 6net
[22:13:31] <Alex Petrescu> DT: I am with Ted
[22:13:36] <Alex Petrescu> DT: analogy to DHCP options
[22:13:49] <Alex Petrescu> DT: expertise in DHC, but archi slides
[22:14:02] <Alex Petrescu> DT: every one group has one of those needs to think mutlpiple interfaces
[22:14:12] <Alex Petrescu> DT: DHC does reviews but work do elsewhere
[22:14:32] <Alex Petrescu> DT: analogy I do by, explanation
[22:14:41] <Alex Petrescu> DT: same approach good here: work is done there, but we review here
[22:14:49] <Alex Petrescu> BH: need to make sure everone is aware of that
[22:14:54] <Alex Petrescu> SK: concern I have
[22:15:08] <Alex Petrescu> SK: if config protocol, PVD exnteions to them shoul dbe in sync
[22:15:27] <Alex Petrescu> SK: I think because of that I think it makes sense to do as suggested, but concern
[22:15:31] Dan Wing joins the room
[22:15:31] <Alex Petrescu> Bernie Volz is BV
[22:15:40] <Alex Petrescu> BV: 2 seconds
[22:16:01] <Alex Petrescu> TL: DHC added work in the DHC work to do th ePVD extension?  becaus eyou felt obligated to?  or because a good idea?
[22:16:05] <Alex Petrescu> BC: becaus eyou said
[22:16:14] <Alex Petrescu> TL: me?
[22:16:24] <Alex Petrescu> BV: but that is a good idea within IETF; I dont think wed be experts in that area
[22:16:57] <Alex Petrescu> TL: wishy washy AD hat I put I say: I no object to work of this kind done here, but not necessarily all has to be done here
[22:17:05] <Alex Petrescu> TL: all can not be done here
[22:17:21] <Alex Petrescu> TL: this is an IETF consensus case; if IETF says 'can' then tough luck
[22:17:32] <Alex Petrescu> TL: protocol changes says? then wed have to rephrase
[22:17:38] <Alex Petrescu> HD: we just summarize
[22:17:52] <Alex Petrescu> HD: remove this (displays slide 4)
[22:18:18] <Alex Petrescu> TL: how about 'a set of reauirements and/or changes to protocols'
[22:18:30] <Alex Petrescu> DT: yo make changes...
[22:18:38] <Alex Petrescu> TL: that and/or should be ...
[22:18:43] <Alex Petrescu> TL: you have to do reqs
[22:18:51] <Alex Petrescu> BV: reqs and _possibly_ changes to protocols
[22:18:56] <Alex Petrescu> TL: wishy washy
[22:19:05] <Alex Petrescu> TL: in some cases and then another item
[22:19:11] <Alex Petrescu> TL: for example part stays
[22:19:16] <Alex Petrescu> HD: item 3 you want
[22:19:17] <Alex Petrescu> TL yes
[22:19:41] <Alex Petrescu> TL: item 3 is ' in cooperation with other WGs develop in some cases developping the changes of protocols...'
[22:20:03] Ted Lemon leaves the room
[22:20:07] <Alex Petrescu> (HD does the typing live in the document, displayed on screen to room)
[22:20:40] <Alex Petrescu> TL: yep, does this make you Bernie happy?
[22:20:52] <Alex Petrescu> (he asked Dave actually)
[22:21:03] Ted Lemon joins the room
[22:21:11] <Alex Petrescu> This is Ales Vizdal suggesting 'in cooperation with'
[22:21:47] <Alex Petrescu> BH: one of the concerns, if we do the work here the other groups my complain; but we as ADs say that ocnsistency and reviews
[22:21:54] <Alex Petrescu> BH: basis for other protocols
[22:22:06] <Alex Petrescu> BH: two main ways
[22:22:13] Ted Lemon leaves the room
[22:22:19] <Alex Petrescu> DT: why I object to this wording?
[22:22:39] <Alex Petrescu> DT: there are two categories of stuff: one that I object to, the other not.
[22:23:13] <Alex Petrescu> DT: things that change invlvoing change of state machine; no objection
[22:23:18] <Alex Petrescu> DT: I object these that change the guts of the protocol itself
[22:23:50] <Alex Petrescu> DT: things that are only the 'use' category - ok e.g. an option of DHCP that carries the PVD option ok.
[22:23:58] <Alex Petrescu> BH: operational behaviour of protocol?
[22:24:09] <Alex Petrescu> BH: bullet 3
[22:24:16] <Alex Petrescu> BH: in cooperation
[22:24:36] <Alex Petrescu> BH: relevant developping uses, in accordancewith reqs
[22:24:43] <Alex Petrescu> (HD modifies live the doc)
[22:24:59] <Alex Petrescu> TL: time is how?
[22:25:03] <Alex Petrescu> HD: 5 minutes are we
[22:25:07] <Alex Petrescu> TL: how close?
[22:25:20] <Alex Petrescu> HD: 1/2 hour for the other presnetionations, not urgent
[22:25:31] <Alex Petrescu> TL: change usage with uses
[22:25:43] <Alex Petrescu> (live changes to charter)
[22:26:46] <Alex Petrescu> BV: uses _and_ changeS?
[22:27:41] <Alex Petrescu> SK: change that back
[22:28:03] <Mikael Abrahamsson> ....***worthsmithing document***.... I think is enough right now :)
[22:28:25] <Alex Petrescu> wordmithing
[22:28:30] <Alex Petrescu> :-)
[22:28:45] <Alex Petrescu> wordsmithing
[22:31:26] <Alex Petrescu> TC: what are these initial goals?
[22:33:43] <Alex Petrescu> TL: no document we have what PVD looks like?
[22:33:48] <Alex Petrescu> DT: I agree we need
[22:33:53] <Alex Petrescu> DT: 2 places possible
[22:34:02] <Alex Petrescu> DT: in the archi doc, or in the guidelines doc
[22:34:10] <Alex Petrescu> DT: agnosti I want now
[22:34:26] <Alex Petrescu> DT: explains why now rather agnostic
[22:34:29] <Alex Petrescu> DT: I conside rpoint 1
[22:34:38] <Alex Petrescu> TL: to me guidelines are not specs
[22:34:54] <Alex Petrescu> wordsmithing
[22:35:38] <Alex Petrescu> TC: can we just both say ' aspec for pvd IDs and uidelines'
[22:35:44] <Alex Petrescu> TL: agree
[22:36:13] <Alex Petrescu> TL: a specification for the format generation and usage for the...
[22:36:43] <Alex Petrescu> (roome we need Etherpad)
[22:37:42] <Alex Petrescu> TL: question is: is there evverybody understand?
[22:37:51] <Alex Petrescu> room: hum a lot for answer yes
[22:37:58] <Alex Petrescu> TL: is everybody happy with state?
[22:38:19] <dmitry.anipko> can someone paste charter to etherpad?
[22:38:25] <Alex Petrescu> TL: hum if yes?  answer ok (but weaker than before)  hum if no? (silence)
[22:38:30] <Alex Petrescu> where is Etherpad?
[22:38:44] <dmitry.anipko> http://etherpad.tools.ietf.org:9000/p/notes-ietf-88-mif?useMonospaceFont=true
[22:40:19] <Alex Petrescu> (The problem is that HD is editing the document, would not be able to paste it before end of meeting I believe; hes not on jabber)
[22:41:21] <Alex Petrescu> TL: after modification
[22:41:37] <Alex Petrescu> TL: if youre happy with the new Tim Chowns of the Charter, then hum
[22:41:40] <Alex Petrescu> TL: hum
[22:41:45] <Alex Petrescu> room : noise
[22:41:50] <Alex Petrescu> TL: if not then please hum
[22:41:53] <Alex Petrescu> room: silence
[22:41:58] <Alex Petrescu> TL: ok, no answer
[22:42:14] <Alex Petrescu> TL: I would say we have a Charter to go to Last Call
[22:42:20] <Alex Petrescu> HD: will post on the email list after the meeting
[22:42:24] <Alex Petrescu> TC: save it several times
[22:42:40] Ted Lemon joins the room
[22:42:43] <Alex Petrescu> SK approaches presentation spot
[22:42:44] Ted Lemon leaves the room
[22:42:58] <Alex Petrescu> slide 'support for multiple provisioning domains in DHCPv6
[22:43:20] <Alex Petrescu> slide: Bqckground
[22:43:24] <Alex Petrescu> Background
[22:43:35] <dmitry.anipko> can't hear the presenter
[22:44:23] <Dave Thaler> Suresh Krisnan presenting
[22:44:28] <Dave Thaler> Krishnan
[22:44:42] <Alex Petrescu> slide 3: Goals
[22:45:07] <Alex Petrescu> slide 4: Basic concepts
[22:45:16] <Alex Petrescu> slide 5: Container option format
[22:45:39] Dan Wing leaves the room
[22:45:46] <Alex Petrescu> slide 6: Indeitfying PVDs
[22:46:42] <Alex Petrescu> slide 7: PVD ID option format
[22:47:09] <Alex Petrescu> BDapeng Liu is DL
[22:47:17] <Alex Petrescu> DL: mutliple?
[22:47:31] <Alex Petrescu> SK: initial, IANA
[22:47:33] <Alex Petrescu> SK: similar to DUIID
[22:47:38] <Alex Petrescu> Bernie Volz is BV
[22:47:46] <Alex Petrescu> BV: why inside the other option?
[22:48:03] <Alex Petrescu> BV: why not Id type and len inside the main option?
[22:48:11] <Alex Petrescu> BV: such that to avoid an issue
[22:48:18] <Alex Petrescu> SK: two relevant fields are there in that
[22:48:23] <Alex Petrescu> BV: only one here
[22:48:30] <Alex Petrescu> BV: if other option, then
[22:48:35] <Alex Petrescu> BV: (explains)
[22:48:50] <Alex Petrescu> BV: would simplify
[22:48:53] <Alex Petrescu> SK: ok
[22:48:57] <Alex Petrescu> Alper Yegin is AY
[22:49:04] <Alex Petrescu> AY: exptract from this draft
[22:49:11] <Alex Petrescu> SK;: wouldnt agree
[22:49:19] <Alex Petrescu> SK: dont want to have one sid e fits all
[22:49:34] <Alex Petrescu> AY :that discussion wil lhappen independent of the rest of the mechanisml
[22:49:43] <Alex Petrescu> TL: IR6 in the charter, your draft should meet
[22:49:48] <Alex Petrescu> SK: still need an option
[22:50:08] <Alex Petrescu> TL: point is not anything wrong here, just the ID type stuff, payload needs to be described in the guideline document
[22:50:15] <Alex Petrescu> TL: other than that this is rhg
[22:50:15] <Alex Petrescu> t
[22:50:20] <Alex Petrescu> SK:...
[22:50:27] <Alex Petrescu> TL: not in this document, its a DHCP...
[22:50:30] <Alex Petrescu> DT: report
[22:50:35] <Alex Petrescu> TL: from one
[22:50:42] <Alex Petrescu> SK: thinking
[22:51:10] <Alex Petrescu> TL: one ohter way, just do one document that has the initial types we think lake sense: DHCP option, an RA option, and a...
[22:51:15] <Alex Petrescu> TL: no reason cant do that way
[22:51:25] <Alex Petrescu> TL: there has to be one document
[22:51:35] <Alex Petrescu> SG: not stop here, we need to extend IKEv2
[22:51:43] <Alex Petrescu> TL: but IKEv3 reference to this
[22:51:53] <Alex Petrescu> Jouni i sJK
[22:52:19] <Alex Petrescu> JK: common registry? a registry is a set of option, like on eoption fits all; we dont have like a difffferent type of alignment reqs
[22:52:22] <Alex Petrescu> TL: sure
[22:52:32] <Alex Petrescu> SK: point is that not want 2 documents
[22:52:42] <Alex Petrescu> SK: needes to be abstracted out
[22:52:59] <Alex Petrescu> SK: not saying odnt do this, say do it elswhere then import
[22:53:07] <Alex Petrescu> AY: provide some guidelines about uniquneess
[22:53:17] <Alex Petrescu> AY: otherwise people configure mineit networks
[22:53:24] Ted Lemon joins the room
[22:53:42] sarikaya2012 leaves the room
[22:53:48] <Alex Petrescu> DT: another approach Id prefer rather than merging in 1 document - everything after option type is one blob; that blob specified in another document
[22:54:11] <Alex Petrescu> DT: PVD ID is the option number, then you have a 'thing', then you have another document.
[22:54:15] <Alex Petrescu> SK: ...
[22:54:22] <Alex Petrescu> BV:...
[22:54:46] <Alex Petrescu> SK: ok well handle over there
[22:55:07] <Alex Petrescu> slide 8: Authentication/Authorization
[22:56:00] <Alex Petrescu> slide 9: PVD Auth option format
[22:56:03] <Alex Petrescu> Alper is AY
[22:56:08] <Alex Petrescu> AY: any freshness into this?
[22:56:16] <Alex Petrescu> SK: the scen calculation includes a timestamp
[22:56:23] <Alex Petrescu> Mikael is MA
[22:56:30] <Alex Petrescu> MA: all the information in the same packet?
[22:56:38] <Alex Petrescu> SK: no, inside the container
[22:56:42] <Alex Petrescu> SK: auth info, owner
[22:56:51] <Alex Petrescu> MA: if the ORKeys
[22:57:01] <Alex Petrescu> MA: we need to talk to people in Virginia(?)
[22:57:07] <Alex Petrescu> TL: good point
[22:57:16] <Alex Petrescu> AY: value of signing th ePVD ID?
[22:57:26] <Alex Petrescu> SK: no, we sign everything inside... from the option until...
[22:57:35] <Alex Petrescu> AY: also covers the config parameters?
[22:57:39] <Alex Petrescu> SK: yes
[22:57:44] <Alex Petrescu> TL: only 1 PVD per...
[22:57:49] <Alex Petrescu> slide 10: Features
[22:58:28] <Alex Petrescu> TL: DHCP packet, authentication
[22:58:28] Dan Wing joins the room
[22:58:40] <Alex Petrescu> SK: but that is with server, not that the preson who claims ownership
[22:58:49] <Alex Petrescu> TL: operationa implications for getting it from outside...
[22:59:18] <Alex Petrescu> TL: problem is: on a multihoimed multi PVD domains you receive signed, home router receives both signatures on containers...
[22:59:24] <Alex Petrescu> SK: even a 3rd signature
[22:59:36] <Alex Petrescu> TL: everything in this signature may contradict the global scope of the packet
[22:59:43] <Alex Petrescu> TL: would take that out of PVD contianer
[22:59:52] <Alex Petrescu> TL: youd like the client to use...
[23:00:00] <Alex Petrescu> BV: client processing is this?
[23:00:06] <Alex Petrescu> TL: we need to think it
[23:00:19] <Alex Petrescu> SK: Dave had a good talk in the design team meeting
[23:00:27] <Alex Petrescu> SK: trust relationshup domain
[23:00:32] Dan Wing leaves the room
[23:00:36] Ted Lemon leaves the room
[23:00:43] <Alex Petrescu> SK: my idea vs Dave's?
[23:00:46] <Alex Petrescu> HD: time please
[23:01:19] <Alex Petrescu> slide 11: Next steps
[23:01:23] Mikael Abrahamsson leaves the room
[23:01:27] Peer Azmat leaves the room
[23:01:28] <Alex Petrescu> HD: no need to present the RA options
[23:01:34] <Alex Petrescu> HD:: that closes the meeting
[23:01:40] <Alex Petrescu> HD: bluesheet
[23:01:45] Alex Petrescu leaves the room
[23:02:04] Brian Carpenter leaves the room: offline
[23:03:00] Ian Farrer leaves the room
[23:03:26] dmitry.anipko leaves the room
[23:03:55] Andrew Yourtchenko leaves the room
[23:13:00] Dave Thaler leaves the room
[23:14:30] Dave Thaler joins the room
[23:15:27] Ted Lemon joins the room
[23:28:30] Dave Thaler leaves the room
[23:40:25] Andrew Yourtchenko joins the room
[23:40:26] Andrew Yourtchenko leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!