Re: [CDNi] CDNI Logging - IANA section

["Brandenburg, R. (Ray) van" <[e-mail]>]

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:[e-mail]]
Sent: donderdag 27 juni 2013 14:56
To: Niven-Jenkins Ben; Brandenburg, R. (Ray) van; [e-mail]
Cc: [e-mail]
Subject: Re: [CDNi] CDNI Logging - IANA section

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) <[e-mail]<mailto:[e-mail]>> wrote:


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.



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


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:


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)" <[e-mail]<mailto:[e-mail]>>
wrote:


Hello Ray,

On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" <[e-mail]<mailto:[e-mail]>>
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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Francois Le Faucheur (flefauch)
Sent: dinsdag 25 juni 2013 16:33
To: [e-mail]<mailto:[e-mail]>
Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings

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

-------------------------------------------------------
To join the meeting online(Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=225213802&UID=484318167&PW=NNzQ0ZmZmNjUz&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): [phone]
Call-in toll number (US/Canada): [phone]
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf

Access code:208 330 914

CCP:[phone]x208330914#

======================================
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.
_________________________________________________________________________________________________________________________

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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cdni

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


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