Subject: Re: [sidr] upcoming wg calls

From: Sandra Murphy <[email-masked]>
Date: Thu, 2 Dec 2010 21:29:23 -0500 (Eastern Standard Time)

Andrew suggests that the new naming schemes should be added to the 
repos-struct draft.

Tim's message implies that the naming scheme would be added to the 
roa-format draft (by extension, to whatever draft creates a new repository 
structure element, like the ghostbusters draft).

I'd like wg consideration as to which would be best, both now and going 
forward.

--Sandy

On Mon, 29 Nov 2010, Andrew Chi wrote:

> On 11/18/2010 4:39 AM, Tim Bruijnzeels wrote:
>>> Call for WGLC, I support:
>>>
>>>   draft-ietf-sidr-roa-format
>> 
>> One very minor nit: I think it would be desirable to have a normative
>> naming scheme similar to the one used for manifests as defined in the
>> repos-struct document; using the extension .roa.
>> 
>
> We'll also need to add a ghostbusters extension to repos-struct.  I agree 
> with Tim, and also agree it's minor.
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 03 Dec 2010 10:14:46 +0100

Hi,

On 12/3/10 3:29 AM, Sandra Murphy wrote:
> roa-format draft (by extension, to whatever draft creates a new
> repository structure element, like the ghostbusters draft).
> 

option 1: add to repos-struct

Currently the repos-struct draft reserves the following extensions in
section 2.2:

.cer	certificates
.crl	CRLs
.mft	Manifests

And it goes on to say that signed objects must not use these extensions.

I am afraid that it's not possible to add a complete list of reserved
signed object extensions to the repos-struct draft. Simply because new
object types may be added later. I am afraid we won't be able to update
this document all the time -- once it's standard.

option 2: add to roa-format (and other signed object docs)

That's why I suggested adding it to the ROA format document.

The problem with this is of course that then reservations for extensions
to be used in the repository are made in different locations.

option 3: extract to separate doc

Is it possible/better to maintain a simple separate list that maps
extensions to various object types? And can this be updated more easily
whenever a new signed object makes it to RFC?

Current list could look a little like:

.cer	Certificates as described in RFC sidr-res-certs
.crl	CRL as specified in RFC sidr-res-certs section 5 (refers to 5280)
.mft	Manifest as described in RFC sidr-rpki-manifest
.roa	ROA as described in RFC sidr-roa-format

The repos-struct document could refer to it. This option has my
preference as it keeps all this stuff centralised. If updating the
repos-struct document itself is possible then that option (1) has my
preference.

But.. as I said before. I really do not want to cause more delays. If
none of the 3 options above are feasible (and nothing else is suggested)
I would rather have some trial-and-error code in validators to handle
everything apart from .cer, .crl and .mft than block last call on either
repos-struct or roa-format..

Cheers
Tim

>> We'll also need to add a ghostbusters extension to repos-struct.  I
>> agree with Tim, and also agree it's minor.
>>

---

From: Randy Bush <[email-masked]>
Date: Fri, 03 Dec 2010 18:17:29 +0900

let's be old fashioned

> option 1: add to repos-struct

creates iana registry

> option 2: add to roa-format (and other signed object docs)

each doc adding requests an entry in registry

randy

---

From: Stephen Kent <[email-masked]>
Date: Fri, 3 Dec 2010 15:39:56 -0500

At 9:29 PM -0500 12/2/10, Sandra Murphy wrote:
>I'd like wg consideration as to which would be best, both now and 
>going forward.
>
>--Sandy
>

I support adding .roa; I didn't realize it was not there already.

I think we can wait for GB, because it is a new doc, not yet final 
(it was just adopted by the WG). We will need to have each new RPKI 
signed object specify it's file extension for the future, so why now 
start with the GB doc, when it is approved.

Steve

---

From: Randy Bush <[email-masked]>
Date: Sat, 04 Dec 2010 07:04:05 +0900

> start with the GB doc, when it is approved.

lemme repeat.  keeping track of a changing list of identifiers is (part
of) the iana function and is why we have iana consideration sections in
documents.

probably repo structure should create the registry with certs and
manifests and crls, and roa, ghostbusters, ... should add to it.

randy

---

From: Rob Austein <[email-masked]>
Date: Mon, 06 Dec 2010 22:53:56 -0500

> manifests and crls, and roa, ghostbusters, ... should add to it.

+1

---

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Dec 2010 13:42:39 -0500

At 7:04 AM +0900 12/4/10, Randy Bush wrote:
>  >...

I am persuaded by your argument for an IANA registry.

Steve

---

From: George Michaelson <[email-masked]>
Date: Fri, 17 Dec 2010 10:28:38 +1000

> manifests and crls, and roa, ghostbusters, ... should add to it.

I hesitate to block anything here, but I observe that preserving 8.3 filename semantics is hugely anachronistic and leaves a bad taste in my mouth. We worked very hard to get rid of this insanity in UNIX filesystems/services space, and you can compile any named file you like from C to object to running binary in any legal nameform that the filesystem will accept. 

Its not proscriptive. /etc/magic is the registry, such as it is.

If there is a need for a registry, so be it. But can we acknowledge that this is a retrograde decision? 

	.cgi is not in a registry
	.html is not in a registry

the MIME encodings are in a registry. an OID might be analogous. Cannot the CMS carry an OID, and is an OID not an extensible prefix for creation of identity? 

-G

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 16 Dec 2010 20:35:09 -0500 (Eastern Standard Time)

> I hesitate to block anything here, but I observe that preserving 8.3 filename semantics is hugely anachronistic and leaves a bad taste in my mouth. We worked very hard to get rid of this insanity i…

The repos-struct draft does already mandate three file extensions: .cer, 
.crl, and .mft.  As co-author, are you thinking of retracting that?

--sandy, speaking with wg hood on

---

From: Terry Manderson <[email-masked]>
Date: Fri, 17 Dec 2010 11:42:58 +1000

Speaking strictly for myself on this topic.

On 17/12/2010, at 10:28 AM, George Michaelson wrote:
> 
> I hesitate to block anything here, but I observe that preserving 8.3 filename semantics is hugely anachronistic and leaves a bad taste in my mouth.

I find this contradictory. On the one hand the working group has adopted a repository structure where we describe directories and files, not URIs. Further we speak of manifests with registering file names and so forth.

Section 2.2 in draft-ietf-sidr-repos-struct-06 specifies .cer, mft, and .crl.

thus holding the ".3" part of the name. Do you now wish to make that arbitrary?

> We worked very hard to get rid of this insanity in UNIX filesystems/services space, and you can compile any named file you like from C to object to running binary in any legal nameform that the filesystem will accept. 
> 

I would put forth, regardless of the file name extension length that the extension have special meaning within the SIDR work and hint nicely as to what the file contents might be. I see no reason not to have a stable registry.

Cheers
Terry

---

From: George Michaelson <[email-masked]>
Date: Fri, 17 Dec 2010 11:43:44 +1000

On 17/12/2010, at 11:35 AM, Sandra Murphy wrote:
>  
> The repos-struct draft does already mandate three file extensions: .cer, .crl, and .mft.  As co-author, are you thinking of retracting that?
> 

No. I have no sense this is reversible, and I see a registry of some kind as inevitable.

rsync doesn't have a mechanism other than apparent filename to filter the fetched objects so I suspect the name *has* to be proscriptive to permit

	--include-file=*mft
	--exclude-file=*roa

type selections.

-George

---

From: Geoff Huston <[email-masked]>
Date: Fri, 17 Dec 2010 14:21:24 +1100

> manifests and crls, and roa, ghostbusters, ... should add to it.

this works for me as well.

I'll respin the draft with iana considerations added for registry.