Subject: [lisp] I am not posting the -04 document today

From: Dino Farinacci <[email-masked]>
Date: Fri, 11 Sep 2009 13:45:30 -0700

One of the chairs (Sam) feels we have not reached consensus. I thought  
we had.

I believe there are 2 issues remaining. I'll let Sam specify those.

Regrettably,
Dino

---

From: Sam Hartman <[email-masked]>
Date: Fri, 11 Sep 2009 18:17:41 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:
8
    Dino> One of the chairs (Sam) feels we have not reached
    Dino> consensus. I thought we had.

First, I'm still waiting for feedback on the SMR bit being removed
from the data plane.  I don't think there has been any stated support
for this on the list.  I made a call in the form of an issue and have
seen no responses.

Dino thinks I just missed the discussion.
So, if you spoke up in the past in support of this, please do so again; this is really important to resolve.

The second issue is #19, the mobility bit.  I explained why I don't
believe we can include that.  

--Sam

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 11 Sep 2009 16:00:15 -0700

> for this on the list.  I made a call in the form of an issue and have

I support this.

And I know the core LISP team at cisco has had conversations both on  
and off the list with the UCL-B guys and we all agreed that mapping- 
updates should be out of the data plane. That means the spec should  
not have version numbers in it or a SMR-bit in it.

So just making it clear what I thought we had consensus on. And when  
we brought it to the list, no one objected.

> So, if you spoke up in the past in support of this, please do so  
> again; this is really important to resolve.
>

My understanding was to include the M bit so it can be allocated and  
indicate that it will be described in a future spec. Joel asked me to  
put that text in, and that is what I did.

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Sun, 13 Sep 2009 12:48:56 +0200

>> for this on the list.  I made a call in the form of an issue and have

+1

> updates should be out of the data plane.

Almost....
Our position was that SMR bit in the data-plane could be somehow  
tricky to manage.
But has his value in the control-plane.
We still think  that versioning can be useful in the data-plane and we  
would like to make experiment with it (but this has been discussed in  
another thread).

Luigi

> That means the spec should not have version numbers in it or a SMR- 
> bit in it.
>
> indicate that it will be described in a future spec. Joel asked me  
> to put that text in, and that is what I did.
>
> Dino
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 13 Sep 2009 08:50:32 -0400

>>> for this on the list.  I made a call in the form of an issue and  

Me, too -- +1.
>> My understanding was to include the M bit so it can be allocated  
>> and indicate that it will be described in a future spec. Joel asked  
>> me to put that text in, and that is what I did.

I do not agree with including the M bit, and I didn't perceive that we  
had consensus to do so.  Several of us indicated that we should not  
include any bits in the main spec, unless their mechanism is described  
in (or normatively referenced from) the main spec.  I have no problem  
with the mobility spec allocating an M-bit for its own use, and I  
think we should support that through an appropriate IANA  
considerations section in the LISP specification.

Margaret

---

From: John Zwiebel <[email-masked]>
Date: Sun, 13 Sep 2009 16:18:25 -1000

On Sep 13, 2009, at 2:50 AM, Margaret Wasserman wrote:

>>> and indicate that it will be described in a future spec. Joel  
>>> asked me to put that text in, and that is what I did.
>
> I do not agree with including the M bit, and I didn't perceive that  
> we had consensus to do so.

How many does it take to make a consensus?

I'm for including the M-bit.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 15 Sep 2009 09:12:50 -0400

>>>>> "John" == John Zwiebel <[email-masked]> writes:

    John> On Sep 13, 2009, at 2:50 AM, Margaret Wasserman wrote:

    John> How many does it take to make a consensus?

    John> I'm for including the M-bit.
    John> _______________________________________________ lisp mailing
    John> list [email-masked]
    John> https://www.ietf.org/mailman/listinfo/lisp

This is not so much about lack of consensus (although I don't believe
we have that) as a process problem.

There are fairness issues if we start assigning bits to proposals that
the WG has not accepted and cannot accept unless we first decide on
guidelines we will apply for those assignments and then make the
assignments.  See my write-up of #19.

The AD proposed the same way forward as I did in that issue in private
mail to the editors and chairs.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Sep 2009 16:50:46 +0300

We've talked about mobility now several times. I may be starting to 
sound like a broken record. But mobility is, for now, outside the scope 
of the working group. Lets not insert it half-way into the base 
specifications -- not even for that one bit. Many RFCs define RESERVED 
fields from where subsequent RFCs can allocate bits. That's technically 
the right thing to do in my opinion, because you do not know the full 
list of Lisp extensions and their bit needs anyway. (In addition, you 
can avoid lengthy threads and complex issues about what the bit actually 
means.)

Jari

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 15 Sep 2009 09:24:48 -0700

Sam, I have talked to all the draft-meyer-lisp-mn-00.txt authors. We  
agreed to pull the M-bit allocation and description from the main spec.

Dino

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Sep 2009 09:25:22 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:

    Dino> Sam, I have talked to all the draft-meyer-lisp-mn-00.txt
    Dino> authors. We agreed to pull the M-bit allocation and
    Dino> description from the main spec.
I think we can close this issue as fixed.

I think the discussion supported developing IANA policies and an IANA
section for the spec with Dino as a notable objection.  So, we may be
back to the general IANA issue whenever someone wants to drive it.