Subject: Re: [lisp] #19: not including the M bit

From: [email-masked] (Noel Chiappa)
Date: Thu, 17 Sep 2009 11:22:32 -0400 (EDT)

> From: Sam Hartman <[email-masked]>

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

As long as there's a WG open for LISP, I think it should be in control of
allocating bits headers in the header, not the IANA. Header bits are a very
limited resource, and an allocation authority is by its very nature just not
in as good a position to judge what is a good way to 'spend' them as the
technical group developing the protocol is.

	Noel

---

From: Eliot Lear <[email-masked]>
Date: Thu, 17 Sep 2009 17:31:18 +0200

Noel,

When you specify a registry for IANA you also specify an update policy. 
I agree with your concerns about the limited availability of bits.  That
should be taken into account when specifying the policy.  You can
require designated expert review, working group review, or perhaps other
mechanisms.  Because these are still early days for LISP you don't want
to make it impossible to get a bit, but you also want people to be
serious when they ask.  Thus, my suggestion would be to start with a
designated expert review and then as time goes on you up the requirement
to a heavier review process.

Eliot

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Sep 2009 11:40:54 -0400

>>>>> "Noel" == Noel Chiappa <[email-masked]> writes:

    >> From: Sam Hartman <[email-masked]> I think the
    >> discussion supported developing IANA policies and an IANA
    >> section for the spec ...  So, we may be back to the general
    >> IANA issue whenever someone wants to drive it.

    Noel> As long as there's a WG open for LISP, I think it should be
    Noel> in control of allocating bits headers in the header, not the
    Noel> IANA. Header bits are a very limited resource, and an
    Noel> allocation authority is by its very nature just not in as
    Noel> good a position to judge what is a good way to 'spend' them
    Noel> as the technical group developing the protocol is.

*sigh* I think you completely misunderstand what IANA does and how it
works, especially for a document not yet published.  IANA basically
never makes decisions about protocol assignments except for
first-come-first-serve registries.  They used to make a few more
decisions, for example for specification required registries, but I
believe even those have experts assigned.  Take a look at RFC 5226 for
details.

Here's how using IANA would work for us.

1) Step one: the step we most care about.  We'd decide what policy
we're going to use for allocating scarce resources. "Whenever we
decide to do so for WG documents," would be fine.  Especially when
making allocations for non-WG documents I'd want us to have more
guidelines than simply "we come to consensus."  Especially since some
of the proposed uses are for things that are out of scope, we need
guidelines that are easier to evaluate for fairness.  We can
definitely use judgment, but we should at least write down the factors
we're going to consider.

2) We write up some text that describes the namespaces that our
document creates and the assignment guidelines we're using.

3) We effectively already have the initial assignments in the form of
the flags we're using today.

4) As the spec progresses within the WG, we can modify the
allocations/initial assignments consistent with our guidelines.  We
can even modify our assignment guidelines although doing so has certain fairness considerations that are important.

5) When our document gets published as an RFC, IANA creates registries
for the namespaces we create.  In the future, they will update them
according to the guidelines we established.  If we want to retain
control, one of the common guidelines is "IETF review," meaning that
the IETF must publish an RFC to make the change.  There's complexity
surrounding things like early assignments, etc, but once we figure out
what the WG wants as a high level we can figure out the right process
text to affect that.

I don't think it is particularly negotiable that by the time it is
published as an RFC, the LISP spec will create a bunch of IANA
namespaces.  Whether we create one for the flags probably is
negotiable, and teh assignment guidelines certainly are.

The main thrust of my point in #19 is that we're not going to make
assignments for non-WG documents without coming up with guidelines for
how we make those assignments.  The framework the IETF uses to discuss
such issues is IANA assignments.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 17 Sep 2009 11:47:42 -0400

> negotiable, and teh assignment guidelines certainly are.

If we don't create a loser assignment policy for the flags, the de- 
facto policy will be "RFC required" or thereabouts, because the IETF  
has been pretty ferocious about not having documents from other  
standards bodies allocate code points for parts of our standards that  
don't have IANA-controlled registries.  So, if we want a loser policy  
than requiring an RFC (that updates our RFC) to allocate new options,  
we should specify an IANA policy for them.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 17 Sep 2009 11:52:26 -0400

On Sep 17, 2009, at 11:47 AM, Margaret Wasserman wrote:

> If we don't create a loser assignment policy for the flags...

I meant a _looser_ assignment policy, not a _loser_ one.  Sorry.

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 17 Sep 2009 16:00:45 -0700

I think your proposal needs to be greatly simplified. I think any  
contention points for allocations can be easily resolve by talking to  
each other.

Can we wait for the drafts to be published as experimental RFCs before  
we go through this process? That would seem simpler and we can focus  
on design and not IETF procedure.

Tell me what adding all this formalism earlier is going to buy us?

Dino

On Sep 17, 2009, at 8:40 AM, Sam Hartman wrote:

> can even modify our assignment guidelines although doing so has  
> certain fairness considerations that are important.
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 17 Sep 2009 20:42:19 -0400

On Sep 17, 2009, at 7:00 PM, Dino Farinacci wrote:
>
> Can we wait for the drafts to be published as experimental RFCs  
> before we go through this process? That would seem simpler and we  
> can focus on design and not IETF procedure.

An "IANA Considerations" section is required in all I-Ds that are  
submitted for RFC publication (per http://www.ietf.org/id-info/checklist.html) 
, so we definitely have to add one before the Experimental RFCs can be  
published.  It is up to the WG to decide what IANA registries are  
needed, and what the allocation policy should be for those  
registries.  The allocation policy choices are described in RFC 2434:  
"Guidelines for Writing an IANA Considerations Section".

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 17 Sep 2009 17:53:13 -0700

> , so we definitely have to add one before the Experimental RFCs can  
> be published.  It is up to the WG to decide what IANA registries are  
> registries.  The allocation policy choices are described in RFC  
> 2434: "Guidelines for Writing an IANA Considerations Section".

The former is fine to put in the specs now. It's the later we could  
wait on.

Dino

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Sep 2009 13:09:18 +1200

BTW, RFC2434 is obsolete. You need to check the latest choices
in RFC5226.

   Brian

On 2009-09-18 12:53, Dino Farinacci wrote:
>>> before we go through this process? That would seem simpler and we can
>>> focus on design and not IETF procedure.
>>
>> submitted for RFC publication (per
>> http://www.ietf.org/id-info/checklist.html), so we definitely have to
>> add one before the Experimental RFCs can be published.  It is up to
>> the WG to decide what IANA registries are needed, and what the
>> allocation policy should be for those registries.  The allocation
>> policy choices are described in RFC 2434: "Guidelines for Writing an
>> IANA Considerations Section".
> 
> The former is fine to put in the specs now. It's the later we could wait
> on.
> 
> Dino
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Sep 2009 19:32:45 +0300

Expert review is a fine rule for an Experimental RFC bits from my 
perspective.

Jari