Subject: [CDNi] CDNI Logging - 2nd Informal Meeting in an hour and 15 minutes

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 5 Jun 2013 13:47:42 +0000

Friendly reminder:

* Wed 5 June 2013, at 08:0 Pacific Time = 17:00 Central European Time, for 90 minutes

============================

Topic: IETF CDNI Logging - Informal Meeting
Date: Wednesday, June 5, 2013
Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00)
Meeting Number: 206 470 738
Password: cdni

-------------------------------------------------------
To join the meeting online(Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=225213782&UID=484318167&PW=NMmQzODVmZjJm&RT=MiMyMw%3D%3D
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: cdni
4. Click "Join".
5. If the meeting includes a teleconference, follow the instructions that appear on your screen.

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code.
Call-in toll-free number (US/Canada): +1-866-432-9903
Call-in toll number (US/Canada): +1-408-525-6800
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf

Access code:206 470 738

CCP:+14085256800x206470738#

======================================
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 25 Jun 2013 14:32:43 +0000

Hello,

Just a friendly reminder about tommorow's informal CDNI Logging meeting.
* Wed 26 June 2013, at 08:0 Pacific Time = 17:00 Central European Time, for 90 minute
Webex details included below.

We just posted a new rev of cdni-logging that reflects some of last informal meeting's discussions. The key changes over -03 are:
* rewrite of all formats/rules aspects
* added creation of three IANA registries to prepare for extensibility of CDNI Logging

A new version (-04) has been submitted for draft-ietf-cdni-logging:
http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-logging-04

Talk to you tomorrow

Francois

========================================

Topic: IETF CDNI Logging - Informal Meeting
Date: Wednesday, June 26, 2013
Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00)
Meeting Number: 208 330 914
Password: cdni

1. Go to https://cisco.webex.com/ciscosales/j.php?ED=225213802&UID=484318167&PW=NNzQ0ZmZmNjUz&RT=MiMyMw%3D%3D

Access code:208 330 914

CCP:+14085256800x208330914#

_________________________________________________________________________________________________________________________

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,
France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 26 Jun 2013 09:27:44 +0000

Hi Francois, all,

I've just read through the latest iteration: my compliments, the document has improved significantly.

(Unfortunately, I have not been able to join the CDNI Logging calls, and will not be able to do so today as well. So the following point may have been discussed during the calls.)

I noticed that the IANA registries specify 'Standards Action' as the method for extending the registries. I was wondering what the reasoning behind this was? To me it seems unnecessarily strict, as well as being somewhat contradictory with the Editor's note included in the same section.  We would basically rule out any informational or experimental RFC, as well as proprietary logging fields or standardization efforts by other bodies. I would expect some CDN vendors to want to do logging of additional fields. I would therefore propose we go for 'Specification Required' or 'Expert Review'.

Best regards,

Ray

From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur (flefauch)
Sent: dinsdag 25 juni 2013 16:33
To: [email-masked]
Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings

Hello,

Talk to you tomorrow

Francois

Access code:208 330 914

Thank you.

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 26 Jun 2013 14:47:32 +0000

On 25 Jun 2013, at 16:32, Francois Le Faucheur (flefauch) <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

Talk to you tomorrow

Francois

Access code:208 330 914

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 26 Jun 2013 14:58:13 +0000

Hello Ray,

On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" <[email-masked]<mailto:[email-masked]>>
 wrote:

Hi Francois, all,

I’ve just read through the latest iteration: my compliments, the document has improved significantly.

Appreciated.

(Unfortunately, I have not been able to join the CDNI Logging calls, and will not be able to do so today as well. So the following point may have been discussed during the calls.)
I noticed that the IANA registries specify ‘Standards Action’ as the method for extending the registries. I was wondering what the reasoning behind this was?

It is just that at teh time of writing, it was clear that some allocation had to go through standards track (eg the WG defines a new type of CDNI Logging record for Request Routing which requires a new Record-Type and say a couple new CDNI Logging fields) and it needed a bit more thinking about how much flexibility we need for the rest (hence teh Editor's note).

To me it seems unnecessarily strict, as well as being somewhat contradictory with the Editor’s note included in the same section.  We would basically rule out any informational or experimental RFC, as well as proprietary logging fields or standardization efforts by other bodies. I would expect some CDN vendors to want to do logging of additional fields. I would therefore propose we go for ‘Specification Required’ or ‘Expert Review’.

I agree flexibility needs to be added.
I am happy to allow something which requires an open spec (possibly somehow vetted by the IETF) (e.g. Specification Required or Expert Review).
I think we should also have a very light-weight process (ie without IETF involvement) to allow vendors to experiment with extensions (eg Private/experimental use).
I'll try collect more input at today's informal meeting.

Thanks

Francois

Best regards,

Ray

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Francois Le Faucheur (flefauch)
Sent: dinsdag 25 juni 2013 16:33
To: [email-masked]<mailto:[email-masked]>
Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings

Hello,

Talk to you tomorrow

Francois

Access code:208 330 914

Thank you.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 26 Jun 2013 17:39:35 +0000

Hi Ray,

We discussed the IANA allocation policy at the informal meeting. There was convergence on adding both a "private use" and a "specification required" namespaces. As an example, below is what I drafted for the first IANA registry. Let us know if you have comments.

Cheers

Francois

6.1.  CDNI Logging Directive Names Registry

   The IANA is requested to create a new registry, CDNI Logging
   Directive Names.

   The initial contents of the CDNI Logging File Directives registry
   comprise the names of the directives specified in Section 3.3 of the
   present document, and are as follows:

    +------------------------------+-----------+
    + Directive name               + Reference |
    +------------------------------+-----------+
    + Version                      + RFC xxxx  |
    + UUID                         + RFC xxxx  |
    + Claimed-Origin               + RFC xxxx  |
    + Verified-Origin              + RFC xxxx  |
    + Record-Type                  + RFC xxxx  |
    + Fields                       + RFC xxxx  |
    + Integrity-Hash               + RFC xxxx  |
    +------------------------------+-----------+

                                 Figure 4

   [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
   the present document]

   Within the registry:

   o  the subset of the namespace starting with "x" "-" is set aside for
      "Private Use" as specified in [RFC5226].  To minimize conflicts in
      the names used, the name MUST be structured as : "x" "-" "vendor-
      ID" "-" "vendor-specific-cdni-logging-directive-name" where the
      "vendor-ID" identifies the vendor and the "vendor-specific- cdni-
      logging-directive-name" identifies the actual vendor-specific
      directive.  For example, a vendor specific directive name could
      look like "x-vendor1-interesting_directive1".

   o  the subset of the namespace starting with "r" "-" is to be
      allocated by IANA according to the "Specification Required" policy
      specified in [RFC5226].

   o  the rest of the namespace is to be allocated by IANA according to
      the "Standards Action" policy specified in [RFC5226].

On 26 Jun 2013, at 16:58, "Francois Le Faucheur (flefauch)" <[email-masked]<mailto:[email-masked]>>
 wrote:

Hello Ray,

Hi Francois, all,

Appreciated.

Thanks

Francois

Best regards,

Ray

Hello,

Talk to you tomorrow

Francois

Access code:208 330 914

Thank you.

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 27 Jun 2013 07:12:43 +0000

Hi Francois,

Seems like a good solution.

One small note: for the Field Name Registry, you currently use various prefixes (e.g. 'c-', 's-', 'u-') as abbreviations. It might be good to refrain from that in the new version, since now you're also using prefixes to indicate namespaces (e.g. 'r' and 'x').

Cheers,

Ray

From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
Sent: woensdag 26 juni 2013 19:40
To: Brandenburg, R. (Ray) van
Cc: [email-masked]
Subject: CDNI Logging - IANA section

Hi Ray,

Cheers

Francois

   Directive Names.

    + Version                      + RFC xxxx  |

    + UUID                         + RFC xxxx  |

    + Fields                       + RFC xxxx  |

                                 Figure 4

   the present document]

   Within the registry:

      specified in [RFC5226].

Hello Ray,

Hi Francois, all,

Appreciated.

(Unfortunately, I have not been able to join the CDNI Logging calls, and will not be able to do so today as well. So the following point may have been discussed during the calls.)
I noticed that the IANA registries specify 'Standards Action' as the method for extending the registries. I was wondering what the reasoning behind this was?

To me it seems unnecessarily strict, as well as being somewhat contradictory with the Editor's note included in the same section.  We would basically rule out any informational or experimental RFC, as well as proprietary logging fields or standardization efforts by other bodies. I would expect some CDN vendors to want to do logging of additional fields. I would therefore propose we go for 'Specification Required' or 'Expert Review'.

Thanks

Francois

Best regards,

Ray

Hello,

Talk to you tomorrow

Francois

Access code:208 330 914

Thank you.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 27 Jun 2013 09:35:15 +0100

Francois,

I haven't considered the proposal in detail but proposing an x- prefix reminded me of this draft

http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful

At one point it was being discussed in appsarea WG but I can't remember whether it ended up going anywhere.

Ben

On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote:

> On 26 Jun 2013, at 16:58, "Francois Le Faucheur (flefauch)" <[email-masked]>
>  wrote:
> 
>> Hello Ray,
>> 
>> On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" <[email-masked]>
>>  wrote:
>> 
>>> Hi Francois, all,
>>>  
>>> [email-masked]
> [email-masked]

---

From: <[email-masked]>
Date: Thu, 27 Jun 2013 10:59:54 +0200

Heya,

We could use x. and r. instead of x- and r-, that would eliminate possible misunderstandings...

-- iuniana

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Brandenburg, R. (Ray) van
Envoyé : jeudi 27 juin 2013 09:13
À : Francois Le Faucheur (flefauch)
Cc : [email-masked]
Objet : Re: [CDNi] CDNI Logging - IANA section

Hi Francois,

Cheers,

Ray

Hi Ray,

Cheers

Francois

   Directive Names.

    + Version                      + RFC xxxx  |

    + UUID                         + RFC xxxx  |

    + Fields                       + RFC xxxx  |

                                 Figure 4

   the present document]

   Within the registry:

      specified in [RFC5226].

Hello Ray,

Hi Francois, all,

Appreciated.

Thanks

Francois

Best regards,

Ray

Hello,

Talk to you tomorrow

Francois

Access code:208 330 914

Thank you.

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: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 27 Jun 2013 09:06:28 +0000

I've reached out to Peter and try get more background around -xdash-considered-harmful. If I got the main idea of the document right, one possible alternative approach could be to get rid of the seggregated namespaces for "Private Use" and "Specification Required" and instead require IANA allocaton with an "Expert Review" policy (so it is kept light-weight, and then provides a stable name if the "experiment" becomes a "standard").
Let's make a decision when we have more information.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 27 Jun 2013 12:56:27 +0000

Folks,

Peter confirmed this document went through and is now RFC 6648.

I believe the rationale explained in RFC 6648 applies to our situation and we should follow its recommendations (quoted at the end of ths message).

Therefore I propose (in all the registries) to:
* remove the seggregated "x-" namespace
* remove the seggregated "r-" namespace
* require IANA registration of all standards-track parameters according to the "Standards Action" policy
* require IANA registration of all non-private and non standards-track parameters according to the "Specification Required" policy

This will leave the following options for people to experiment with un-standardised parameters:
* use an unallocated name for private use without having to document anything. Provided the name is created reasonably smartly this can be done with very low chances of collision, but does not strictly protect against collision, which is OK because this is for private use.
* document the usage sufficiently well and obtain a unique name. This strictly protect against collision, and allows interoperability with other implementation of that same spec. If the parameter specification becomes a standard, the parameter name can remain the same.
* document a usage and parameters and progress it through the whole standards track process.

Let me know if you have comments against that plan.

Cheers

Francois

PS: Ben, thanks for bringing up xdash-considered-harmful.

"

4.  Recommendations for Protocol Designers

   Designers of new application protocols that allow extensions using
   parameters:

   1.  SHOULD establish registries with potentially unlimited value-
       spaces, defining both permanent and provisional registries if
       appropriate.

   2.  SHOULD define simple, clear registration procedures.

   3.  SHOULD mandate registration of all non-private parameters,
       independent of the form of the parameter names.

   4.  SHOULD NOT prohibit parameters with an "X-" prefix or similar
       constructs from being registered.

   5.  MUST NOT stipulate that a parameter with an "X-" prefix or
       similar constructs needs to be understood as unstandardized.

   6.  MUST NOT stipulate that a parameter without an "X-" prefix or
       similar constructs needs to be understood as standardized.

"

On 27 Jun 2013, at 11:06, Francois Le Faucheur (flefauch) <[email-masked]<mailto:[email-masked]>> wrote:

On 27 Jun 2013, at 10:35, Ben Niven-Jenkins <[email-masked]<mailto:[email-masked]>>
wrote:

Francois,

Ben

Hi Ray,

Cheers

Francois

                               Figure 4

 Within the registry:

Hello Ray,

Hi Francois, all,

Appreciated.

Thanks

Francois

Best regards,

Ray

Hello,

Talk to you tomorrow

Francois

Access code:208 330 914

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 27 Jun 2013 13:50:52 +0000

Hi Francois,

In general I agree with the proposal of having only two tracks: standards-track and everything else. However, I'm not sure I understand how your proposal below would work in practice. How would we distinguish between the two if we don't use namespace prefix? And if it is all part of the same namespace, then what's the point of making the distinction and why not just require 'Specification Required' for everything?

Ray

From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
Sent: donderdag 27 juni 2013 14:56
To: Niven-Jenkins Ben; Brandenburg, R. (Ray) van; [email-masked]
Cc: [email-masked]
Subject: Re: [CDNi] CDNI Logging - IANA section

Folks,

Cheers

Francois

"

   parameters:

       appropriate.

"

Francois,

Ben

Hi Ray,

Cheers

Francois

                               Figure 4

 Within the registry:

Hello Ray,

Hi Francois, all,

Appreciated.

Thanks

Francois

Best regards,

Ray

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Francois Le Faucheur (flefauch)
Sent: dinsdag 25 juni 2013 16:33
To: [email-masked]<mailto:[email-masked]>
Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings

Hello,

Talk to you tomorrow

Francois

Access code:208 330 914

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 27 Jun 2013 13:55:43 +0000

On 27 Jun 2013, at 15:50, "Brandenburg, R. (Ray) van" <[email-masked]<mailto:[email-masked]>>
 wrote:

Hi Francois,

In general I agree with the proposal of having only two tracks: standards-track and everything else. However, I’m not sure I understand how your proposal below would work in practice. How would we distinguish between the two if we don’t use namespace prefix?

You don't distinguish between the two. A parameter name is a parameter name. That is exactly the point. This allows transition from "experimentation" to "standards" without having to change the parameter name. Please have alook at RFC 6648.

Let me restate:
We basically say:
* here is a registry
* some names will be allocated through "Standards Action"
* some names can be allocated through "Specification Required"
That's it.

Francois

And if it is all part of the same namespace, then what’s the point of making the distinction and why not just require ‘Specification Required’ for everything?

Ray

From: Francois Le Faucheur (flefauch) [mailto:[email-masked]<http://cisco.com>]
Sent: donderdag 27 juni 2013 14:56
To: Niven-Jenkins Ben; Brandenburg, R. (Ray) van; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] CDNI Logging - IANA section

Folks,

Cheers

Francois

"

   parameters:

       appropriate.

"

Francois,

Ben

Hi Ray,

Cheers

Francois

                               Figure 4

 Within the registry:

Hello Ray,

Hi Francois, all,

Appreciated.

Thanks

Francois

Best regards,

Ray

Hello,

Talk to you tomorrow

Francois

Access code:208 330 914

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 27 Jun 2013 14:16:43 +0000

Hi Francois,

Let me rephrase myself: what I don't understand is how a single registry can have two enforcing policies. If you have a registry with two policies, one of which is stricter than the other, than isn't the de facto policy the less-strict one (in this case specification required)? The way I understand it, a registry with 'Specification Required' doesn't rule out any fields being registered through a standards-track RFC, does it? So what's the point of also slapping a 'Standards Action'-policy on it?

Ray

From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
Sent: donderdag 27 juni 2013 15:56
To: Brandenburg, R. (Ray) van
Cc: Francois Le Faucheur (flefauch); Niven-Jenkins Ben; [email-masked]; [email-masked]
Subject: Re: [CDNi] CDNI Logging - IANA section

Hi Francois,

In general I agree with the proposal of having only two tracks: standards-track and everything else. However, I'm not sure I understand how your proposal below would work in practice. How would we distinguish between the two if we don't use namespace prefix?

Let me restate:
We basically say:
* here is a registry

Francois

And if it is all part of the same namespace, then what's the point of making the distinction and why not just require 'Specification Required' for everything?

Ray

Folks,

Cheers

Francois

"

   parameters:

       appropriate.

"

Francois,

Ben

Hi Ray,

Cheers

Francois

                               Figure 4

 Within the registry:

Hello Ray,

Hi Francois, all,

Appreciated.

Thanks

Francois

Best regards,

Ray

Hello,

Talk to you tomorrow

Francois

Access code:208 330 914

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 27 Jun 2013 16:05:22 +0000

Hi Ray,

On 27 Jun 2013, at 16:16, "Brandenburg, R. (Ray) van" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Francois,

Let me rephrase myself: what I don’t understand is how a single registry can have two enforcing policies. If you have a registry with two policies, one of which is stricter than the other, than isn’t the de facto policy the less-strict one (in this case specification required)?

The thing is that "Specification Required" required is not simply a less-strict "subset" of "Standards Action".
For example, there is a specific process for "Specification Required" which involves sending a request to IANA which will then designate an Expert responsible for performing the review and reporting to IANA. We don't need such a process if a functionality + parameters are progressed in the standards track (ie IANA will be called at publicaton time and the WG + IESG is effectively of doing the expert review).

So my take is we need to say that some names will be allocated according to "Standards Action" and some names will be allocated according to "Specification Required".

Francois

PS: Looping in Peter in case he provide additional guidance.

The way I understand it, a registry with ‘Specification Required’ doesn’t rule out any fields being registered through a standards-track RFC, does it? So what’s the point of also slapping a ‘Standards Action’-policy on it?

Ray

Cc: Francois Le Faucheur (flefauch); Niven-Jenkins Ben; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Francois,

Let me restate:
We basically say:
* here is a registry

Francois

Ray

Folks,

Cheers

Francois

"

   parameters:

       appropriate.

"

Francois,

Ben

Hi Ray,

Cheers

Francois

                               Figure 4

 Within the registry:

Hello Ray,

Hi Francois, all,

Appreciated.

Thanks

Francois

Best regards,

Ray

Hello,

Talk to you tomorrow

Francois

Access code:208 330 914

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 27 Jun 2013 21:24:45 +0000

On 27 jun. 2013, at 18:05, "Francois Le Faucheur (flefauch)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ray,

Hi Francois,

RFC5226 includes the following sentence under 'Specification Required':

"For RFC publication, the normal RFC review process is expected to provide the necessary review for interoperability, though the Designated Expert may be a particularly well-qualified person to perform such a review."

Doesn't this solve the issue you raise?

Ray

Francois

Ray

Hi Francois,

Let me restate:
We basically say:
* here is a registry

Francois

Ray

Folks,

Cheers

Francois

"

   parameters:

       appropriate.

"

Francois,

Ben

Hi Ray,

Cheers

Francois

                               Figure 4

 Within the registry:

Hello Ray,

Hi Francois, all,

Appreciated.

Thanks

Francois

Best regards,

Ray

Hello,

Talk to you tomorrow

Francois

Access code:208 330 914

---

From: "Peter Saint-Andre (psaintan)" <[email-masked]>
Date: Fri, 28 Jun 2013 00:04:00 +0000

I wasn't subscribed to the list, but I am now, so no need to cc me on replies.

On Jun 27, 2013, at 3:24 PM, "Brandenburg, R. (Ray) van" <[email-masked]>
 wrote:

> 
> On 27 jun. 2013, at 18:05, "Francois Le Faucheur (flefauch)" <[email-masked]> wrote:
> 
>> Hi Ray,
>> 
>> On 27 Jun 2013, at 16:16, "Brandenburg, R. (Ray) van" <[email-masked]> wrote:
>> 
>>> Hi Francois,
>>>  

The "specification" in "Specification Required" is not necessarily an RFC -- it could be a document produced by another SDO.

However, "RFC Required" is a heavyweight requirement, because every time someone wants to add a new entry to the registry we need to spin up the whole RFC process: I-D, document shepherd, WG or AD-sponsored, IETF Last Call (with attendant reviews), IESG reviews, RFC Editor time, etc.

Do we really need that in this case?

Further comments below.

>> So my take is we need to say that some names will be allocated according to "Standards Action" and some names will be allocated according to "Specification Required".

Why do we need two separate processes?

Please read RFC 6648. Or read it again. :-) In general there's no need to differentiate between "standard" parameters and "non-standard" parameters. Is CDNI exceptional in this regard?

>>> On 27 Jun 2013, at 15:50, "Brandenburg, R. (Ray) van" <[email-masked]>
>>>  wrote:
>>> 
>>> 
>>> Hi Francois,
>>>  
>>> In general I agree with the proposal of having only two tracks: standards-track and everything else.

Here again I question why two tracks are needed.

>>> However, I’m not sure I understand how your proposal below would work in practice. How would we distinguish between the two if we don’t use namespace prefix?
>>>  

That sounds reasonable to me. It just happens to be the case that some of those specifications will be RFCs.

Peter

<snip/>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 28 Jun 2013 08:44:31 +0100

> Please read RFC 6648. Or read it again. :-) In general there's no need to differentiate between "standard" parameters and "non-standard" parameters. Is CDNI exceptional in this regard?

Not IMO. The objective of registration is to avoid collisions as they are bad for interop. So the bar for registration must be low enough to not prevent people from registering.

For registered values that get enough momentum (de facto or via some kind of RFC/standardisation) to be widely deployed an RFC/standard that describes them is useful to the community.

But I don't think anyone needs to 'vet' the namespace registrations in this instance unless we're really worried about people land grabbing/squatting which seems unlikely given the size of the registry space available (basically unlimited).

Ben

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 28 Jun 2013 08:45:30 +0000

On 27 Jun 2013, at 23:24, "Brandenburg, R. (Ray) van" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ray,

Hi Francois,

It actually does solve the issue. So I agree "Specification Required" should work for both cases.

Thanks

Ray

Francois

Ray

From: Francois Le Faucheur (flefauch) [mailto:[email-masked]<http://cisco.com/>]

Hi Francois,

Let me restate:
We basically say:
* here is a registry

Francois

Ray

From: Francois Le Faucheur (flefauch) [mailto:[email-masked]<http://cisco.com/>]

Folks,

Cheers

Francois

"

   parameters:

       appropriate.

"

Francois,

Ben

Hi Ray,

Cheers

Francois

                               Figure 4

 Within the registry:

Hello Ray,

Hi Francois, all,

Appreciated.

Thanks

Francois

Best regards,

Ray

Hello,

Talk to you tomorrow

Francois

Access code:208 330 914

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 28 Jun 2013 08:57:51 +0000

> Why do we need two separate processes?

We don't. My mistake came from a blurry recollections of the "Specification Required" definition of RFC 5226. I did not think that it also covered the case of regular RFC publication (ie I thought it would force some additional separate process activities such as designating an Expert). Ray clarified that it does cover that case and will not create additional process. So I think what we want is to use "Specification Required" for the wholesamespace of these new registries.

Francois

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 28 Jun 2013 09:03:23 +0000

Ben,

> But I don't think anyone needs to 'vet' the namespace registrations in this instance unless we're really worried about people land grabbing/squatting which seems unlikely given the size of the regi…

Based on RFC 6648, I think we are saying that if you want a name registered in teh registry, it will have to go through the Specification Required process (ie get documented somewhere to a level that allows interoperable implementation etc - but that's much lighter than the full RFC publication process).
If you do not want to document the usage, then you can always use a non-allocated name (and use that in a "private" environment).

Does that work for you?

Francois

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 28 Jun 2013 06:24:59 -0600

> If you do not want to document the usage, then you can always use a non-allocated name (and use that in a "private" environment).

That seems eminently reasonable to me!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 28 Jun 2013 13:53:26 +0100

> If you do not want to document the usage, then you can always use a non-allocated name (and use that in a "private" environment).

Yes. Thanks. Ben