Subject: [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt

From: Geoff Huston <[email-masked]>
Date: Mon, 28 Nov 2016 14:04:13 +1100

Hello,

I have been selected as the Routing Directorate reviewer for this draft.

The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and sometimes
on special request. The purpose of the review is to provide assistance to
the Routing ADs. For more information about the Routing Directorate,
please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-lisp-type-iana-03.txt 
Reviewer: Geoff Huston Review
Date: 28 November 2016 
IETF LC End Date: not called 
Intended Status: Standards Track

Summary:

I have significant concerns about this document and recommend that the
Routing ADs discuss these issues further with the authors and the IANA.

Comments:

Draft quality and readability.

The third paragraph of the Introduction is unclear. Given that LISP itself
is an experimental specification it is hard to understand the distinction
being made between the "experimentation purposes" and some other
undescribed purpose which this reviewer can only conclude is also an
experimentation purpose. I suggest re-thinking the intent of this
paragraph and expressing it in simpler terms.

In section 2, the use of the normative "MUST" seems to be inappropriate,
particularly when a non-normative "must" ius used in section 4 in an
identical context.

Major Issues:

It seems anomalous to me that a request to set up an IANA Registry for an
Experimental Protocol (RFC6830 is Experimental) is itself proposed to be a
Standards Track document.

Furthermore, the document states that additional values be assigned via a
Standards Action. Again, it appears anomalous to me that a specification
of a parameter value of an experimental protocol be described by a
Standards Track action.

If RFC6830 is revised and is re-published as a Standards Track
specification then these points are of course not relevant, but until such
a publication takes place, specifying an IANA parameter registry as a
Standards Track action for an experimental protocol seems to me to be
anomalous and should not proceed unless the IESG specifically agrees with
this approach. Alternatively RFC5226 could be further revised to 
explicitly describe the guidelines as they relate to Experimental
Specifications (as distinct from experimental allocations within Standards
Track specifications), as this area appears to be unclear from my reading
of RFC5226.

However it is not for me to resolve this issue, nor is it up to the draft
authors, or the LISP working group, as far as I can tell.  It is up to the IESG and
IANA to clarify this situation and allow IANA to be given clear directions
as to how to maintain parameter registries for experimental specifications
while they remain experiments.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 27 Nov 2016 23:01:54 -0500

You raise an interesting point Geoff.

The documents are experimental.  As such, it is reasoanble for this 
document to be experimental, and for it merely to require IETF RFC for 
assignment, without restricting it to Standards Track RFCs.

And while we are in the process of moving the LISP documents to 
Standards Track, that will take time.

However, I would like to be able to have the right status in the 
documents when we get the upgrade done.  We can do a revision of this 
document as well, but that seems to be creating work.

Any suggestions for how to thread this needly?

Yours,
Joel

---

From: Geoff Huston <[email-masked]>
Date: Mon, 28 Nov 2016 15:34:57 +1100

I am not fully aware of all the options here, but it strikes me that the IESG could publish this document as EXPERIMENTAL, consistent with RFC6830, and in the future whatever mechanism is used to update RFC6830 to Standards Track, the same document could UPDATE this document and place it on the standards track by virtue of the Update.

There may be other approaches as well, as this is _not_ an area where I would call myself an “expert”!

regards,

  Geoff

> On 28 Nov. 2016, at 3:01 pm, Joel M. Halpern <[email-masked]> wrote:
> 
> The documents are experimental.  As such, it is reasoanble for this document to be experimental, and for it merely to require IETF RFC for assignment, without restricting it to Standards Track RFCs.
> 
> And while we are in the process of moving the LISP documents to Standards Track, that will take time.
> 
> However, I would like to be able to have the right status in the documents when we get the upgrade done.  We can do a revision of this document as well, but that seems to be creating work.
>

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 27 Nov 2016 22:10:59 -0800

I think this is a good and expedient suggestion. 

Dino

> On Nov 27, 2016, at 8:34 PM, Geoff Huston <[email-masked]> wrote:
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 28 Nov 2016 10:12:50 +0100

Hi Geoff,
> On 28 Nov 2016, at 05:34, Geoff Huston <[email-masked]> wrote:
> 

Just for clarity.

You suggest

We publish this document as experimental now. Then we merge the standard track update in the same document that updates 6830 as standard track.

Am I right?

An  alternative option (with less work to do)  is to keep this document  on hold until there will be the standard track update of 6830.
At that point, there will not be any issue in publishing the document as well as standard track.

In this way we do not need to work on merging the document with the 6830 update and we still solve the issue you raised.

Any thought ?

ciao

L.

---

From: Geoff Huston <[email-masked]>
Date: Mon, 28 Nov 2016 20:58:15 +1100

Hi Luigi,

If you think that it would be useful to open up an IANA registry now, then I would not wait i.e. I’d publish the document as EXPERIMENTAL and update it into the standards track when you update RFC6830.

On the other hand, if the IANA registry is not needed at once then it could all wait. 

Personally, I find deferral options difficult to remember and pick up the threads - so I normally do things on the day and then adjust as required down the track - but that's more about my preferred way to work!

kind regards,

   Geoff

> On 28 Nov. 2016, at 8:12 pm, Luigi Iannone <[email-masked]> wrote:
> 
> Hi Geoff,

---

From: "Marc Blanchet" <[email-masked]>
Date: Mon, 28 Nov 2016 08:14:48 -0500

On 28 Nov 2016, at 4:58, Geoff Huston wrote:

> Hi Luigi,
>
> If you think that it would be useful to open up an IANA registry now, 
> then I would not wait i.e. I’d publish the document as EXPERIMENTAL 
> and update it into the standards track when you update RFC6830.

FYI, dtnrg had his specs as experimental. After some good 
experimentation with wg managed registries, we end up creating an RFC to 
register all the parameters. That RFC (6255) was Informational.

Marc.

> Personally, I find deferral options difficult to remember and pick up 
> the threads - so I normally do things on the day and then adjust as 
> required down the track - but that's more about my preferred way to 
> work!
>
> kind regards,
>
>    Geoff
>
>
>
>
>>> I am not fully aware of all the options here, but it strikes me that 
>>> the IESG could publish this document as EXPERIMENTAL, consistent 
>>> with RFC6830, and in the future whatever mechanism is used to update 
>>> RFC6830 to Standards Track, the same document could UPDATE this 
>>> document and place it on the standards track by virtue of the 
>>> Update.
>>
>> Just for clarity.
>>
>> You suggest
>>
>> We publish this document as experimental now. Then we merge the 
>> standard track update in the same document that updates 6830 as 
>> standard track.
>>
>> Am I right?
>>
>> An  alternative option (with less work to do)  is to keep this 
>> document  on hold until there will be the standard track update of 
>> 6830.
>> In this way we do not need to work on merging the document with the 
>> 6830 update and we still solve the issue you raised.
>>
>> Any thought ?
>>
>> ciao
>>
>> L.
>>
>>
>>
>>>
>>>> document to be experimental, and for it merely to require IETF RFC 
>>>> for assignment, without restricting it to Standards Track RFCs.
>>>>
>>>> documents when we get the upgrade done.  We can do a revision of 
>>>> this document as well, but that seems to be creating work.
>>>>

---

From: <[email-masked]>
Date: Mon, 28 Nov 2016 13:43:29 +0000

Hi Goeff, 

> Standards Track document.

FWIW, I'm aware of an IANA registry for an experimental protocol that you can check here: 
http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#mptcp-option-subtypes 

Cheers,
Med

> -----Message d'origine-----
> De : lisp [mailto:[email-masked]] De la part de Geoff Huston
> Envoyé : lundi 28 novembre 2016 04:04
> À : Zhangxian (Xian); [email-masked]
> Cc : [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Jon Hudson
> Objet : [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt
> 
> Hello,
>

---

From: <[email-masked]>
Date: Mon, 28 Nov 2016 13:59:25 +0000

Re-,

Works for me, too. 

Cheers,
Med

> De : Dino Farinacci [mailto:[email-masked]]
> Envoyé : lundi 28 novembre 2016 07:11
> À : Geoff Huston
> Cc : Joel M. Halpern; [email-masked]; Zhangxian (Xian); [email-masked];
> [email-masked]; [email-masked]; draft-ietf-lisp-type-
> [email-masked]; Jon Hudson
> Objet : Re: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-
> 03.txt
> 
> > I am not fully aware of all the options here, but it strikes me that the
> IESG could publish this document as EXPERIMENTAL, consistent with RFC6830,
> and in the future whatever mechanism is used to update RFC6830 to
> Standards Track, the same document could UPDATE this document and place it
> on the standards track by virtue of the Update.
> >

---

From: <[email-masked]>
Date: Mon, 28 Nov 2016 14:04:56 +0000

Hi,

Geoff's proposal is also fine by me.

Cheers,

Christian.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : lundi 28 novembre 2016 14:59
À : Dino Farinacci; Geoff Huston
Cc : Joel M. Halpern; [email-masked]; Zhangxian (Xian); [email-masked]; [email-masked]; [email-masked]; [email-masked]; Jon Hudson
Objet : RE: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt

Re-,

Works for me, too. 

Cheers,
Med

> De : Dino Farinacci [mailto:[email-masked]] Envoyé : lundi 28 
> novembre 2016 07:11 À : Geoff Huston Cc : Joel M. Halpern; 
> [email-masked]; Zhangxian (Xian); [email-masked]; [email-masked]; 
> [email-masked]; draft-ietf-lisp-type- 
> [email-masked]; Jon Hudson Objet : Re: [lisp] [RTG-DIR] RtgDir 
> review: draft-ietf-lisp-type-iana- 03.txt
> 
> > the
> IESG could publish this document as EXPERIMENTAL, consistent with 
> RFC6830, and in the future whatever mechanism is used to update 
> document and place it on the standards track by virtue of the Update.
> >
> > There may be other approaches as well, as this is _not_ an area 
> > where I
> would call myself an “expert”!
> >
> > regards,
> >
> >  Geoff
> >
> >
> >
> >>> The Routing Directorate seeks to review all routing or 
> >>> routing-related drafts as they pass through IETF last call and 
> >>> IESG review, and
> sometimes
> >>> on special request. The purpose of the review is to provide 
> >>> assistance
> to
> >>> the Routing ADs. For more information about the Routing 
> >>> Directorate, please see 
> >>> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> >>>
> >>> Although these comments are primarily for the use of the Routing 
> >>> ADs,
> it
> >>> would be helpful if you could consider them along with any other 
> >>> IETF
> Last
> >>> I have significant concerns about this document and recommend that 
> >>> the Routing ADs discuss these issues further with the authors and 
> >>> the
> IANA.
> >>>
> >>> Comments:
> >>>
> >>> The third paragraph of the Introduction is unclear. Given that 
> >>> LISP
> itself
> >>> undescribed purpose which this reviewer can only conclude is also 
> >>> an experimentation purpose. I suggest re-thinking the intent of 
> >>> this paragraph and expressing it in simpler terms.
> >>>
> >>> particularly when a non-normative "must" ius used in section 4 in 
> >>> an identical context.
> >>>
> >>> Major Issues:
> >>>
> >>> It seems anomalous to me that a request to set up an IANA Registry 
> >>> for
> an
> >>> Experimental Protocol (RFC6830 is Experimental) is itself proposed 
> >>> to
> be a
> >>> Furthermore, the document states that additional values be 
> >>> assigned
> via a
> >>> specification then these points are of course not relevant, but 
> >>> until
> such
> >>> a publication takes place, specifying an IANA parameter registry 
> >>> as a Standards Track action for an experimental protocol seems to 
> >>> me to be anomalous and should not proceed unless the IESG 
> >>> specifically agrees
> with
> >>> However it is not for me to resolve this issue, nor is it up to 
> >>> the
> draft
> >>> authors, or the LISP working group, as far as I can tell.  It is 
> >>> up to
> the IESG and

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Geoff Huston <[email-masked]>
Date: Tue, 29 Nov 2016 05:54:25 +1100

You appear to have misunderstood me - its _not_ that this draft seeks to create an
IANA registry for an experimental specification that I found to be anomalous. What 
I found anomalous was that the document proposing such an action was itself proposed 
to be a Standards Track document. 

Clear now?

thanks,

  Geoff

> On 29 Nov. 2016, at 12:43 am, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Goeff, 
>

---

From: <[email-masked]>
Date: Tue, 29 Nov 2016 06:23:33 +0000

Hi Geoff,

Actually, the proposed status of this document was not triggered by the action to create the IANA register (that can be done via an Informational Document) but with the action to specify a shared LISP extension message format and assign a codepoint (15) for that purpose. 

FWIW, this point was mentioned in the write-up:

==
      This document targets to follow standard track, hence aiming at the
      initial level of "Proposed Standard".
      I personally argued with the authors that usually documents
      aiming at creating IANA registries are "informational".
      Yet, as the authors rightfully pointed out, the document also
      proposes the experimental packet format, for which standard
      track looks more appropriate.
      As a shepherd of the document I am fine keeping this
      intended status. To be noted that the document passed the
      WGLC with the such intended status. No concern was raised by the
      WG members. As for the IETF process, it is up to the
      IESG to assign the most appropriate status to this document.
==

That's said, I'm OK to change the status to EXP if that is more appropriate.

Thank you.

Cheers,
Med

> De : Geoff Huston [mailto:[email-masked]]
> Envoyé : lundi 28 novembre 2016 19:54
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Zhangxian (Xian); [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> Jon Hudson
> Objet : Re: [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt
> 
> >> authors, or the LISP working group, as far as I can tell.  It is up to
> the
> >> IESG and