Subject: [Sidr] action items from IETF68 sidr meeting

From: [email-masked] (Sandy Murphy)
Date: Tue, 27 Mar 2007 18:17:03 -0400 (EDT)

Some action items from the meeting:

Steve Kent: wants to think about the removal of text dealing with CAs
issuing certs for the same resources to two different entities.

Sandy: check "rsync:" as a registered URI type.
All: should we stick with IETF standardized protocols?

Paul: comment to the list about issue of CPS draft being explicit
regarding what text in the template can be changed.

Joe Abley: comment to the list on the difference between RIPE database
combination of allocation data and routing registry data and the
database structure in other RIRs.

Paul: raise question on the list as to whether the architecture
document should be informational or standards track.

Steve: add text to document re: 4 bytes ASNs.

All: begin a discussion of ROA prefix to UPDATE NLRI matching rules,
including what happens with mutliple ROAs.

All: add to the architecture draft a discussion of uses of the certificates
and ROAs.

Did I miss any?

--Sandy

_______________________________________________
Sidr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sidr

---

From: [email-masked] (Sandy Murphy)
Date: Wed, 28 Mar 2007 12:18:21 -0400 (EDT)

>Sandy: check "rsync:" as a registered URI type.

There is no "rsync:" URI scheme listed on the IANA registry:
http://www.iana.org/assignments/uri-schemes.html

For what it's worth, there also is no "rsync:" URN listed on the IANA
URN registry:
http://www.iana.org/assignments/urn-namespaces

--Sandy

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 28 Mar 2007 10:19:26 -0800 (PST)

One other thing to remember is that if URL/URI is registered by
means of RFC, it needs to have protocol that is also documented
by RFC which rsync is not (its would be possible to get it into
informational RFC I suppose) and I have bad feeling that it is
not an IETF documented protocol would be bigger issue and without
it you may not be able to get SIDR drafts passed IESG or general
IETF last-call review (but I'm not sufficiently versed in IETF RFC 
publication requirements to be certain how big of an issue it is).

---

From: Richard Barnes <[email-masked]>
Date: Wed, 28 Mar 2007 14:41:46 -0400

> without

It depends on which draft you're talking about, and whether that draft 
makes normative or informative reference to rsync.  There are two drafts 
that refer to rsync right now:

draft-ietf-sidr-res-certs-01 makes normative references to rsync, e.g. 
"An rsync URI MUST be present in the DistributionPointName set.".

draft-ietf-sidr-arch-00 makes only informative references to rsync, e.g. 
"Current efforts to implement a repository system use RSYNC [9] as the 
single access protocol. RSYNC, as used in this implementation, provides 
all of the above functionality."

It seems to me like the former draft will probably get hung up on the 
issue, while the latter is less likely to.

--Richard

---

From: Geoff Huston <[email-masked]>
Date: Thu, 29 Mar 2007 21:07:10 +1000

At 04:19 AM 29/03/2007, william(at)elan.net wrote:

>by RFC which rsync is not

I was in a URI WG meeting some IETF's ago and I thought that this was 
an historical and not a current constraint. I'm not sure what 
transpired with this work, so perhaps the best way forward is to 
establish what we can from the documentation. So if what you are 
asserting is indeed the case then there should be documentation to 
support this. Could you please point me to the IETF document where 
the need you refer to above relating to a published RFC for a URI 
type is clearly stated?

   regards,

     Geoff

---

From: "tom.petch" <[email-masked]>
Date: Fri, 30 Mar 2007 15:05:06 +0200

----- Original Message -----
From: "Geoff Huston" <[email-masked]>
To: "william(at)elan.net" <[email-masked]>; "Sandy Murphy" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 29, 2007 1:07 PM
Subject: Re: [Sidr] action items from IETF68 sidr meeting

Geoff

The guidelines for URI registration are in RFC4395. s2.3 expects the scheme to
have a well-defined mapping onto a namespace or protocol or there to be a good
explanation of why not.  This is not insuperable.  There is an individual
submission standards-track I-D for SMB (a protocol which could be loaded with
issues of being ill-defined, IPR-laden etc) but does, I think, meet the
requirements.

Tom Petch

---

From: Geoff Huston <[email-masked]>
Date: Sat, 31 Mar 2007 08:04:19 +1000

>issues of being ill-defined, IPR-laden etc) but does, I think, meet the

thanks Tom

I believe that this answers the question - the current process for 
URI registration is via use of a registration template and an IANA 
registry, and not via an RFC.

regards,

    Geoff

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 30 Mar 2007 15:08:46 -0800 (PST)

On Sat, 31 Mar 2007, Geoff Huston wrote:

> I believe that this answers the question - the current process for URI 
> registration is via use of a registration template and an IANA registry, and 
> not via an RFC.

My original post specifically said "if it is defined by an RFC",
this did not mean its the only way to register an URI. However like
I wrote the issue really is that when you're relying on rwhois protocol 
and you want it in STD protocol you'll almost certain have to have it 
described by an RFC too, so like it or not somebody needs to write an
RFC on rwhois (probably send as individual submission) and that is
how it URI can be registered as well.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 30 Mar 2007 17:28:29 -0800 (PST)

Ups I meant RFC on 'rsync'

On Fri, 30 Mar 2007, william(at)elan.net wrote:

>> registration is via use of a registration template and an IANA registry, 
>> and not via an RFC.
>
> I wrote the issue really is that when you're relying on rwhois protocol and 
> you want it in STD protocol you'll almost certain have to have it described 
> by an RFC too, so like it or not somebody needs to write an

---

From: Geoff Huston <[email-masked]>
Date: Sat, 31 Mar 2007 17:08:03 +1000

At 09:08 AM 31/03/2007, william(at)elan.net wrote:

>I wrote the issue really is that when you're relying on rwhois 
>protocol and you want it in STD protocol you'll almost certain have 
>to have it described by an RFC too, so like it or not somebody needs 
>to write an

Perhaps you could refer me to the process document where this is described?

thanks,

   Geoff

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 31 Mar 2007 02:08:42 -0800 (PST)

All "permanent" URI schemes are defined protocol RFCs. Provisional schemes 
are internet drafts. Procedure defined by RFC4395:
  http://www.rfc-editor.org/rfc/rfc4395.txt
IANA lists URI registration as not through "expert" review with Graham 
Klyne designated as expert. A quite from RFC with more details is below:

-------------
5.2.  Registration Procedures

    Someone wishing to register a URI scheme SHOULD:

    1.  Check the IANA URI scheme registry to see whether or not there is
        already an entry for the desired name.  If there is already an
        entry under the name, choose a different URI scheme name.
    2.  Prepare a URI scheme registration template, as specified in
        Section 5.4.  The URI scheme registration template may be
        contained in an Internet Draft, alone or as part of some other
        protocol specification.  The template may also be submitted in
        some other form (as part of another document or as a stand-alone
        document), but the contents will be treated as an "IETF
        Contribution" under the guidelines of RFC 3978 [4].
    3.  Send a copy of the template or a pointer to the containing
        document (with specific reference to the section with the
        template) to the mailing list [email-masked], requesting
        review.  In addition, request review on other mailing lists as
        appropriate.  For example, general discussion of URI syntactical
        issues could be discussed on [email-masked]; schemes for a network
        protocol could be discussed on a mailing list for that protocol.
        Allow a reasonable time for discussion and comments.  Four weeks
        is reasonable for a permanent registration requests.
-------------

http://www.ietf.org/rfc/rfc2026.txt

    Note: Standards track specifications normally must not depend on
    other standards track specifications which are at a lower maturity
    level or on non standards track specifications other than referenced
    specifications from other standards bodies.  (See Section 7.)

...
7.1.2 Incorporation of Other Specifications

    Other proprietary specifications may be incorporated by reference to
    a version of the specification as long as the proprietor meets the
    requirements of section 10.  If the other proprietary specification
    is not widely and readily available, the IESG may request that it be
    published as an Informational RFC.

ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt

     An RFC must include separate lists of normative and informative
     references (see Section 4.7f below.)  The distinction between
     normative and informative references is often important.  The IETF
     standards process and the RFC Editor publication process need to
     know whether a reference to a work in progress is normative.  A
     standards-track RFC cannot be published until all of the documents
     that it lists as normative references have been published.  In
     practice, this often results in the simultaneous publication of a
     group of interrelated RFCs.

  2.8 URLs and DNS names in RFCs

       The use of URLs in RFCs is discouraged, because many URLs are not
       stable references.  Exceptions may be made for normative
       references in those cases where the URL is demonstrably the most
       stable reference available.  References to long-lived files on
       ietf.org and rfc-editor.org are generally acceptable.

-------------

Unless I'm mistaken no document other then one published by another
standards body (i.e. W3) has ever been incorporated as normative
reference STD RFC published within last few years. But since you're
the one who collects all the docs at pataroo.net I'd expect you to
know that better.

-- 
William Leibzon
Elan Networks
[email-masked]