[08:06:30] --- toni.paila has joined
[08:06:40] <toni.paila> Hello
[08:06:54] --- toni.paila has left
[08:07:43] --- toni.paila has joined
[08:08:45] --- toni.paila has left
[08:10:19] --- Magnus W has joined
[08:10:41] --- toni.paila has joined
[08:10:47] <Magnus W> Starting with document status
[08:13:24] --- guido.franceschini has joined
[08:16:05] <toni.paila> Someone mentioned broadcast - which document are we talking?
[08:16:27] <Magnus W> Magnus clarified that draft-mehta-rmt-flute-sdp does not expire and is approved waiting for publication.
[08:16:58] <toni.paila> OK. Magnus point on reusing this in broadcast area was correct.
[08:17:02] <Magnus W> Currently stuck in RFC-editor queue because of normative reference to revised building blocks
[08:17:56] <Magnus W> Discussion on how to generalize this work for use in fecframe. However it was commented that the current draft is used in a number of standards like 3GPP, OMA
[08:18:52] <Magnus W> Greg and Lorenzo discussed a bit on how to move forward with something more generic. Seems to not be a problem.
[08:19:28] <Magnus W> Lorenzo, who is the main editor for flute?
[08:20:06] <Magnus W> Vincent, no changes latetly.
[08:20:50] <Magnus W> Vincent starts presenting FEC RS building block
[08:22:36] <Magnus W> On comment 2 mark commented that vincents document should register the instance ID itself.
[08:24:06] --- raj_uoa has joined
[08:24:25] <Magnus W> Lorenzo, the IANA section can do the register. We are being a bit unorthodox by registering a fully specified code in the underspecified (129) space.
[08:24:53] <Magnus W> Mark. Why is G lager than 1 considered.
[08:25:48] <Magnus W> Brian, one reason could be to have cases where less than the whole packet is received and parts could be used if they include the whole symbol.
[08:25:52] <Magnus W> Lorenzo, take to list
[08:26:42] <Magnus W> Vincent, a new version adressing issues will be produced next week.
[08:27:13] <Magnus W> Lorenzo, a new version will not require another WGLC.
[08:27:23] <Magnus W> Tesla ID update
[08:27:53] <Magnus W> Vincent, two open issues
[08:28:15] <Magnus W> First, how to send direct time synch in Norm?
[08:29:01] <Magnus W> A number of sub-questions, see slides page 5. Working on the problem.
[08:29:34] <Magnus W> Issue 2, how does an end-point know how to interpret EXT_AUTH
[08:30:15] <Magnus W> Proposal 1 is to include auth scheme ID that allows multiple schemes to be used simultanously.
[08:31:40] <Magnus W> Solution 2, signal out of band what is used, e.g. in SDP.
[08:32:02] <Magnus W> Slide page 7
[08:33:00] <Magnus W> In ALC the codepoint can be used to map algorithms. But in NORM that field doesn't exist.
[08:33:21] <Magnus W> How will this be used in Norm
[08:34:33] --- ldondeti has joined
[08:34:57] <Magnus W> Lorenzo, If the WG are going down the path of self describing creates a lot of extra work
[08:35:55] <Magnus W> In norm we can't change authentication schemes on the fly during a session. Nor can two be used.
[08:36:37] <Magnus W> It should be possible to use one in sender direction and another in the feedback direction based on the packet context.
[08:36:57] <raj_uoa> can we use the codepoint in FLUTE to do this as well?
[08:37:02] <Magnus W> Seem easier to use solution 2.
[08:37:18] <Magnus W> FLUTE uses ALC so that shouldn't be a problem
[08:37:49] <Magnus W> raj_uoa: are you in the room or do you want the question rasied on the mic?
[08:38:16] <Magnus W> New Topic: Reviesed milestonse.
[08:39:28] <raj_uoa> in the new FLUTE draft it says the the codepoint is to be used for FEC Encoding ID
[08:40:12] <Magnus W> Last meeting the RMT security issues document was presented. Will be updated as WG doc.
[08:40:34] <raj_uoa> draft-ietf-rmt-flute-revised-03 , page 19
[08:41:00] <Magnus W> Yes, but do you want this issue raised on the MIC?
[08:41:13] <raj_uoa> yes please, thanks
[08:41:35] <Magnus W> New topic: FCAST
[08:42:08] <Magnus W> Lorenzo presenting background to FCAST. Being a altarnative to the IPR encumbered FLUTE.
[08:44:31] <Magnus W> Vincent refering to Nokia IPR and the purpose is to try find an alternative that doesn't encumber this patent.
[08:44:56] <ldondeti> I like the historical aspect Vincent is pointing to, I didn't know
[08:45:02] <ldondeti> FCAST has been around before
[08:45:07] <Magnus W> Resurrecting proposal from 2000.
[08:45:14] <ldondeti> right
[08:45:31] <ldondeti> I wish Vincent stuck to that line of presentation and not try to point to IPR or what not
[08:45:34] <ldondeti> but oh well!
[08:46:04] <Magnus W> raj_uoa, will do that later after FCAST presentation.
[08:46:23] <raj_uoa> thanks, sorry for the late response
[08:47:01] <toni.paila> I would prefer to see Vincent focusing on technical aspects of the FCAST proposal.
[08:47:09] <Magnus W> Lorenzo, the WG should focus on the looking at the new proposal.
[08:47:43] <Magnus W> Vincent, the original has major limiation: Need to download and decode to get to meta data.
[08:48:42] <Magnus W> Two complementary ways of carry meta data. Append or in Extension.
[08:49:21] <Magnus W> Only subset of meta data are of interest to put in header extension. Rest can be appended.
[08:50:34] <Magnus W> FCAST session description object can describe all the objects that are part of the carousel instance. Simple way for client to learn if it has download all the files.
[08:51:39] <Magnus W> Way forward for the WG. Option 1, look into the patent. 2. we don't care about the patent. 3. we continue in the direction of fcast.
[08:52:00] <Magnus W> Although FCAST only is for ALC it can be extended for NORM.
[08:52:36] <Magnus W> Brian, there are an alternative way of carrying the inforamtion within Norm
[08:53:11] <Magnus W> Brian, this alternative solution has been implemented on low bandwidth links.
[08:54:50] <Magnus W> Lorenzo, we will bring this discussion to the WG list.
[08:55:35] <Magnus W> Lorenzo, one goal of flute was to constrain the ALC so that they would interoperate more easily. We probably like to do that also for FCAST.
[08:56:24] <toni.paila> Scribe: Vincent mentioned that the intent is not to replace FLUTE. Also he identified that external organizations have already selected FLUTE and there are products based on that. This note by Vincent should be captured in the meeting notes.
[08:56:34] <Magnus W> Rami lettinen: Do we really like to put this also on standards track.
[08:59:12] <Magnus W> Wenger: Are the distginguish factor between the propsals only the IPR. There might already be patents on this going into a design phase.
[08:59:36] <Magnus W> Laksminath: Lets develop a new alternative and see where it goes.
[09:00:05] <toni.paila> The IPR discussion goes to way that is not in scope or expertise of RMT. I suggest that we stick to technical discussion.
[09:00:34] <Magnus W> Gorry Fairhurst: We talked about congestion control early in the this WG. How is this covered?
[09:00:43] <Magnus W> Vincent, that is handled by ALC.
[09:02:03] <Magnus W> Mark Watson: There might be patent out there that cover anything of the solution. Had we known about the Nokia patent at the time we did the design, then things may have looked different. However, I will not comment now on what to do. Lets take that on the list.
[09:02:07] <toni.paila> OMA, 3GPP and DVB make FLUTE mandatory.
[09:02:36] <toni.paila> The light-weight option Laksminath is mentioning is only used as optional alternative.
[09:03:23] <Magnus W> What do we do with Flute
[09:04:04] <Magnus W> Laksminath: There are standards bodies that adopted FLUTE. We shouldn't kick it out. However for the ones that hasn't selected yet we can develop alternatives.
[09:04:37] <Magnus W> Lorenzo, will send mail to the list about this quesiton. Will also ask the list about accepting FCAST as WG item.
[09:06:54] <Magnus W> Moving onto security for Norm PI
[09:07:16] <Magnus W> Presented by Brian
[09:08:08] <Magnus W> Get a base line that uses available security tools for the most common Norm usages.
[09:08:32] <Magnus W> Norm SSM seems that lowest hanging fruit.
[09:09:11] <Magnus W> Going through the NORM SSM paradigm for SSM
[09:09:52] <Magnus W> Potential for bi-directional traffic from NORM receiver and senders.
[09:11:03] <Magnus W> Looked at a number of options for securing the whole thing.
[09:12:08] <Magnus W> Laksminath: We are used to see web server and client model.
[09:12:34] <Magnus W> For both side authentication we need certificates.
[09:13:33] <Magnus W> There some alternatives that could be using EAP to provide base for client side authentication.
[09:15:57] <Magnus W> Brian, DTLS doesn't work because the norm sender can't demultiplex the different NORM feedback traffic arriving on the same port.
[09:17:27] <Magnus W> Brian, IPSec transport mode, multicast support replay attack, wasn't expected.
[09:18:11] <Magnus W> After some testing arrived at a solution with two security association per receiver.
[09:19:06] <Magnus W> Can include replay protection for sender -> receiver flow.
[09:19:49] <Magnus W> Receiver -> sender flow can be replay protected at NORM level and avoid having it in IPsec.
[09:22:22] <Magnus W> Norm is reasonably well protected against feedback.
[09:23:15] <Magnus W> Laksminath, so the 16-bit nack sequence number is very slow to wrap.
[09:23:24] <Magnus W> Brian, yes
[09:23:42] <Magnus W> Laksminath, can consider to use a roll over counter that isn't included in packets.
[09:24:36] <Magnus W> Brian, that may can create some problem with dynamic groups where receivers come and leave.
[09:25:14] <Magnus W> Brain, field .... could be a better usage as it ....
[09:26:40] <Magnus W> Lorenzo, GDOI groupkey-push: could go .... but is seems that it is likely that it need to go into the payload.
[09:27:21] <Magnus W> Laksminath: Are you fine with the time it takes to establish the keys using GDOI?
[09:27:59] <Magnus W> Brian: That is type of an out-of-band thing thing. Happens so no problem expected. Could use pre-placed keys.
[09:28:14] <Magnus W> Laksminath: Worried by using a common key.
[09:28:50] <Magnus W> Dan Harkins: Can affect security properties.
[09:30:54] <Magnus W> Brian, included IPsec usage in draft. OSPF is a good example as they recently have done this work. They also have a sec requirement doc.
[09:31:26] <Magnus W> Brian, a future solution could be to do SRTP similar solution in the EXT_AUTH header.
[09:31:55] <Magnus W> However that is not likely yet. We are focusing on what are available.
[09:32:40] <Magnus W> Lorenzo, thanks, this seems good and allow ALC to reuse a lot of this work.
[09:36:30] <Magnus W> Lorenzo, what does the AD think about this?
[09:40:15] <Magnus W> Magnus, I think this is reasonable. Should send for sec review quite soon to determine if it seems okay.
[09:40:29] <Magnus W> Now discussing Liasion Statement from OMA.
[09:40:36] <Magnus W> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=298
[09:41:27] <Magnus W> First question. LCT Specifications are stable and this should be rather soon.
[09:41:51] <Magnus W> This was the answer on the second question.
[09:42:06] <Magnus W> Stephan Wenger volunteered to draft a response and send to the list.
[09:46:08] <Magnus W> Lorenzo, what to do with the experimental congestion control blocks? We may need to consider moving the forward later.
[09:46:40] <Magnus W> Magnus, althoug there are exception mechanism it would be good to move them on to the same maturity as the other building blocks.
[09:47:26] --- toni.paila has left
[09:47:46] <Magnus W> Lorenzo, so far we have put a requirement and an example of solutions to be used.
[09:48:06] --- guido.franceschini has left
[09:48:47] --- ldondeti has left
[09:49:10] <Magnus W> Meeting closed.
[10:42:12] --- LOGGING STARTED