Subject: [lisp] Ben Campbell's No Objection on draft-ietf-lisp-lcaf-17: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 12 Oct 2016 17:07:03 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-lisp-lcaf-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-lcaf/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 4.3 talks about geo coordinates. I think I understand that these
coordinates may give the location of a device. Is there any expectation
that said device can be associated with a person? The security
considerations mention this briefly. Have the working group considered
whether the guidance in RFC 6280/BCP 160 is applicable here?

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 14 Oct 2016 01:46:39 -0700

> whether the guidance in RFC 6280/BCP 160 is applicable here?

A mapping database entry could identify an individual. We think that confidentiality of the control-plane could be used for protecting data in transit from LISP site to the mapping system. For retrieving information from the mapping system, the transport can provide confidentiality protection but also who can access the information.

How about I put a reference to RFC6280/BCP160 in the Security Considerstaions section?

Dino

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 17 Oct 2016 15:12:27 -0500

On 14 Oct 2016, at 3:46, Dino Farinacci wrote:

> A mapping database entry could identify an individual. We think that 
> confidentiality of the control-plane could be used for protecting data 
> in transit from LISP site to the mapping system. For retrieving 
> information from the mapping system, the transport can provide 
> confidentiality protection but also who can access the information.
>

That's not really what I had in mind. RFC6280 has considerations that 
apply do the design of protocols that can transfer location objects, not 
just their use or implementation. My question was whether the working 
group had considered whether they apply to this document. I'm not saying 
that they do; I am not an expert on lisp, and maybe the this data 
doesn't get sent or used in a way that matters from the perspective of 
RFC 6280. But I would hope that the working group has or will make an 
informed decision about that.

Thanks!

Ben.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 17 Oct 2016 13:21:37 -0700

> That's not really what I had in mind. RFC6280 has considerations that apply do the design of protocols that can transfer location objects, not just their use or implementation. My question was whether the working group had considered whether they apply to this document. I'm not saying that they do; I am not an expert on lisp, and maybe the this data doesn't get sent or used in a way that matters from the perspective of RFC 6280. But I would hope that the working group has or will make an informed decision about that.

We, the LISP WG, had not look at RFC6280 considerations. But the draft-farinacci-lisp-geo-01.txt draft is the use-case document for the LCAF type. Since this draft has not been made into a working group draft we have more time to look into this, if it becomes a working group draft.

Any comments chairs?

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 17 Oct 2016 22:17:10 -0400

Ben, given that this geo LCAF is experimental, would it suffice to put 
in the LCAF document a note that any specification for using this form 
of LCAF needs to discuss RFC 6280 considerations?

Yours,
Joel

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 17 Oct 2016 21:26:39 -0500

Hi Joel,

That seems reasonable for an experimental RFC.  If someday this gets 
promoted to standards track, we would probably want to readdress it.

(The fact that this is experimental is the reason my comment was a 
comment, rather than a discuss. I probably should have mentioned that.)

Thanks!

Ben.

On 17 Oct 2016, at 21:17, Joel M. Halpern wrote:

>>> That's not really what I had in mind. RFC6280 has considerations 
>>> that apply do the design of protocols that can transfer location 
>>> objects, not just their use or implementation. My question was 
>>> whether the working group had considered whether they apply to this 
>>> document. I'm not saying that they do; I am not an expert on lisp, 
>>> and maybe the this data doesn't get sent or used in a way that 
>>> matters from the perspective of RFC 6280. But I would hope that the 
>>> working group has or will make an informed decision about that.
>>
>> We, the LISP WG, had not look at RFC6280 considerations. But the 
>> draft-farinacci-lisp-geo-01.txt draft is the use-case document for 
>> the LCAF type. Since this draft has not been made into a working 
>> group draft we have more time to look into this, if it becomes a 
>> working group draft.
>>
>> Any comments chairs?
>>
>> Dino
>>
>>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 17 Oct 2016 19:50:47 -0700

> That seems reasonable for an experimental RFC.  If someday this gets promoted to standards track, we would probably want to readdress it.

Okay, I’ll move the reference to RFC 6280 out from the Security Considerations section and into the Geo LCAF section with text suggested by Joel.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 17 Oct 2016 20:22:33 -0700

Ben, how is this?

Dino

> On Oct 17, 2016, at 7:26 PM, Ben Campbell <[email-masked]> wrote:
> 
> Hi Joel,
> 
> (The fact that this is experimental is the reason my comment was a comment, rather than a discuss. I probably should have mentioned that.)
> 
> Thanks!
> 
> Ben.
> 
>> Ben, given that this geo LCAF is experimental, would it suffice to put in the LCAF document a note that any specification for using this form of LCAF needs to discuss RFC 6280 considerations?
>> 
>> Yours,
>> Joel
>>

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 17 Oct 2016 23:09:39 -0500

Hi,

I can live with that, with a couple of minor comments: I think it might 
be improved by changing "examine" to "consider the applicability of". I 
say that because I do not know for a fact that RFC6820 really applies to 
lisp use cases; I hope people who understand lisp better than I can 
reach a conclusion on that. But I'm okay with an experimental RFC 
pushing that analysis into the future.

One other point: RFC6280 and BCP160 are the same document. I think these 
days we prefer referencing BCPs by the BCP number, but the RFC editor 
will do the right thing.

Thanks for addressing this!

Ben.

On 17 Oct 2016, at 22:22, Dino Farinacci wrote:

>>> Ben, given that this geo LCAF is experimental, would it suffice to 
>>> put in the LCAF document a note that any specification for using 
>>> this form of LCAF needs to discuss RFC 6280 considerations?
>>>
>>> Yours,
>>> Joel
>>>
>>>>> whether the working group had considered whether they apply to 
>>>>> this document. I'm not saying that they do; I am not an expert on 
>>>>> lisp, and maybe the this data doesn't get sent or used in a way 
>>>>> that matters from the perspective of RFC 6280. But I would hope 
>>>>> that the working group has or will make an informed decision about 
>>>>> that.
>>>>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 18 Oct 2016 10:05:38 -0700

> I can live with that, with a couple of minor comments: I think it might be improved by changing "examine" to "consider the applicability of". I say that because I do not know for a fact that RFC6820 

Changed. See below. Please ack so we can publish.

> really applies to lisp use cases; I hope people who understand lisp better than I can reach a conclusion on that. But I'm okay with an experimental RFC pushing that analysis into the future.

I assure you we will address this in draft-farinacci-lisp-geo.

> One other point: RFC6280 and BCP160 are the same document. I think these days we prefer referencing BCPs by the BCP number, but the RFC editor will do the right thing.

Oh, I didn’t notice that. I’ll change the occurence to RFC6280 to BCP160 and apply the RFC reference. See below.

Dino

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 18 Oct 2016 12:53:59 -0500

Looks good, thanks!

On 18 Oct 2016, at 12:05, Dino Farinacci wrote:

> > I can live with that, with a couple of minor comments: I think it 
> might be improved by changing "examine" to "consider the applicability 
> of". I say that because I do not know for a fact that RFC6820
>
>> really applies to lisp use cases; I hope people who understand lisp 
>> better than I can reach a conclusion on that. But I'm okay with an 
>> experimental RFC pushing that analysis into the future.
>
>> One other point: RFC6280 and BCP160 are the same document. I think 
>> these days we prefer referencing BCPs by the BCP number, but the RFC 
>> editor will do the right thing.
>
> Oh, I didn’t notice that. I’ll change the occurence to RFC6280 to 
> BCP160 and apply the RFC reference. See below.
>
> Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 18 Oct 2016 11:24:46 -0700

Okay, all we have is two Discusses from Stephen and Alexey. I want to wait to post -19 until have a chance to see the updates I’ve made to reflect their issues. See proposed -19 below.

The diff file is for -17 to -19.

Dino

> On Oct 18, 2016, at 10:53 AM, Ben Campbell <[email-masked]> wrote:
> 
> Looks good, thanks!
> 
>