IETF Chair | 30 Mar 22:40 2015
Picon

Thoughts from IETF-92

Thank you all for a wonderful meeting. I wanted to thank all the sponsors and participants, and our host
Google for their support. And the wonderful social event. Well done, you all!

Here are some thoughts from me and Dan York, as the meeting ended: https://www.youtube.com/embed/R2G5eLkX1BM

What are your thoughts? What were the important things coming out of the meeting for you? What can we do
better next time? Are there new things that we should start to work on?

Jari Arkko, IETF Chair

Stephen Farrell | 28 Mar 23:51 2015
Picon
Picon

Fwd: Re: Use of private OIDs in WG (standard-track) documents


-------- Forwarded Message --------
Subject: Re: Use of private OIDs in WG (standard-track) documents
Date: Sat, 28 Mar 2015 22:45:27 +0000
From: Stephen Farrell <stephen.farrell <at> cs.tcd.ie>
To: Massimiliano Pala <director <at> openca.org>

(sorry for the previous mail due to an engimail bug that's
been bugging me for a week now:-)

Hi Max,

On 28/03/15 16:04, Massimiliano Pala wrote:
> Hi Stephen, all,
>
> it seems that lately we do not agree on many positions :-(

Not to worry.

> However, my concern is about a procedure and I do think asking for a
> "standardized" approach to how OIDs should be presented in RFCs is not
> a bad idea. Why this discussion would be counter productive ?

The discussion on the trans list is fine to have. A discussion of a
generic rule disallowing non IETF OIDs in IETF protocols would be
counterproductive I think. The reason is that no such rule is needed
and even if it were we already have a pretty bizarre process full of
bureaucracy and adding to that is not a good plan. (That's my position
anyway, and that of others, though perhaps not everyone's.)

(Continue reading)

Dave Cridland | 28 Mar 09:42 2015
Picon

Re: We should drop the useless urn: prefix


On 27 Mar 2015 21:43, "Phillip Hallam-Baker" <phill <at> hallambaker.com> wrote:
>
> On Fri, Mar 27, 2015 at 8:37 AM, Dave Cridland <dave <at> cridland.net> wrote:
> >
> >
> > On 27 March 2015 at 03:42, Phillip Hallam-Baker <phill <at> hallambaker.com>
>
> > I have no idea what you're on about here.
>
> Then why not take a deep breath and read what was written before
> making another response?
>

Oh, I read it. It just seemed irrelevant. These are not cases where a private identifier has leaked into common use and become embedded, this is a case where the scheme and namespace were registered, and documented on the standards track.

> If you don't understand the issue and you don't care, then why respond?
>

You're taking my statements out of context, probably quite deliberately, but in any case, let's review.

Your original note had the subject line preserved in this one. It clearly proposes to remove the urn: "prefix" (as you insist on calling the scheme). You then gave an example of the IETF's namespace, a pre-existing identifier.

I said that there were good reasons to have such a scheme, but most importantly stripping the scheme as you had clearly proposed was a very poor idea.

> Obviously there are good reasons not to change names already assigned.

And you agree with that latter point, apparently, despite your original statements.

> The urn: prefix is very much like the x-header in this respect.

No, that's about a retro fit namespace for unregistered, ad hoc, often temporary identifiers becoming embedded into de facto standards.

urn, as a scheme, has almost the opposite problem, in that you cannot register a namespace within it without jumping through some extensive hoops, and there is no expectation that organisations which have registered a urn namespace would graduate to a URI scheme.

> Those
> http: URLs have obviously stuck in the XACML spec because there was no
> value in changing an existing registration.
>

It's certainly a reasonable assumption, if your symptoms on the origin is correct. There's lots not to like about it, though, and my point here was that if we used the IETF urn space better, and more visibly, we'd probably avoid it.

>
> But we don't need to keep demanding the same mistake be made over. The
> urn: scheme is clearly causing confusion. Lets clear the confusion by
> registering the scheme the IETF already uses (ISSN) and is about to
> use (DOI) as top level schemes.
>

I'm not clear on the confusion.

I agree that urn registration is a pain, and it lacks any domain based ad hoc usage. Both those are bad; Google, for example, use both an unregistered scheme of google, and a urn namespace urn:google. The former they could in principle register; but the latter they couldn't due to the draconian rules.

Otherwise, I really don't see what it so confusing about four characters.

>
>
> >> We should define URI schemes for DOI, UPC and ISSN and make them all top
> >> level.
> >>
> >
> > That is an entirely different matter, and one that I struggle to care about.
>
> So why respond in such a ridiculous fashion?
>

My apologies, I didn't realise you had the sole right.

>
> > That is, I don't care whether new registrations use a urn: prefix or not;
> > "urn:" might make clear that these are non-resolvable, I certainly dislike
> > the endless urn:ietf:dragons:xml-params:beware:of:the:leopard style of URN
> > the IETF seems to prefer to mint, but really there's more important things
> > in life, like whether I should put that pasty in the microwave about now. (I
> > think I probably should).
>
> Perhaps you could explain how little you care in some more detail?
>

Certainly. If a particular identifier is relatively uncommon or niche, then I think it's helpful to have a clear syntactic indicator if it is not directly resolvable, which the urn scheme provides. I appreciate that whether an identifier is resolvable is to an extent a matter of opinion, though, and hence individual cases are not something I want to get drawn into.

Secondly, the IETF urn tree in particular seems very verbose and over engineered to my eyes. I would be entirely unsurprised if this alone puts people off. For new urn namespaces, this is of course irrelevant, one would hope, but it may be a contributing factor. Again, I wouldn't want to get drawn into whether this affects a specific case.

Does that help clarify?

>
> > On the other hand, bombastically declaring that "urn:" should be stripped
> > everywhere without any further thought is, I think, very short-sighted; more
> > so in the face of obvious examples of problems.
>
> Did I write an Internet Draft suggesting that?

No, it was an email. It's at the beginning of this thread if that helps you locate it.

Dave.

Massimiliano Pala | 28 Mar 05:50 2015

Use of private OIDs in WG (standard-track) documents

Hello IETF,

small question: is it allowed to use private OIDs (i.e., subtree of 1.3.6.1.4.1.XXXX.) in WG documents that are on standard track ? I am asking because in the TRANS wg, that is what is happening and I do not really feel comfortable adopting OIDs that are under the control of a single organization. Would this be a first case ?

Thanks,
Max


l.wood | 28 Mar 02:26 2015
Picon

Re: We should drop the useless urn: prefix

> And I can write a draft pretty quickly now that I have rfctool
> that lets me compose them in Word.

This is the IETF design equivalent of script kiddies.

(CCSDS protocol design documents are done in Word; says much.)

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf <ietf-bounces <at> ietf.org> on behalf of Phillip Hallam-Baker <phill <at> hallambaker.com>
Sent: Saturday, 28 March 2015 8:43 AM
To: Dave Cridland
Cc: Michael Richardson; IETF Discussion Mailing List
Subject: Re: We should drop the useless urn: prefix

On Fri, Mar 27, 2015 at 8:37 AM, Dave Cridland <dave <at> cridland.net> wrote:
>
>
> On 27 March 2015 at 03:42, Phillip Hallam-Baker <phill <at> hallambaker.com>

> I have no idea what you're on about here.

Then why not take a deep breath and read what was written before
making another response?

My concern was very simple. In the plenary it was announced that DOIs
would be added to RFCs. There was then a protest made that 'DOIs are
not URNs' and an assertion that the people proposing them didn't
understand (what was not understood was less clear).

I find this to be a problem for the following reasons:

1) DOIs are very clearly a widely used naming scheme that has
demonstrated considerable utility.

2) It is clear that all sensible requirements for making a DOI: urn
scheme have been met.

3) It seems that the IETF still has not overcome it's principal
obstacle in addressing URI related matters which is the attitude of
many of the self appointed experts.  'Repect mah authoritah' does not
make for a persuasive argument.

Yes, I am one of those people who will on occasion say 'that is
wrong'. But I always say why I think something is wrong. What I find
rather grating and insulting about the topic of naming is that so many
people feel free to say that something is wrong for reasons that they
won't bother to explain. Or the closely related 'this is a very
difficult issue that only a few people understand and I am not one of
them'.

If you don't understand the issue and you don't care, then why respond?

Looking at the DOI people's Web Site I find their reasons for not
applying for a URN scheme is that they don't see the value in
prefixing DOIs with urn:doi: when doi: is clearly sufficient.

My point is simply that that is a perfectly good argument and we
should look for ways that we can bring systems into the URI
infrastructure.

Obviously there are good reasons not to change names already assigned.
The urn: prefix is very much like the x-header in this respect. Those
http: URLs have obviously stuck in the XACML spec because there was no
value in changing an existing registration.

But we don't need to keep demanding the same mistake be made over. The
urn: scheme is clearly causing confusion. Lets clear the confusion by
registering the scheme the IETF already uses (ISSN) and is about to
use (DOI) as top level schemes.

>> We should define URI schemes for DOI, UPC and ISSN and make them all top
>> level.
>>
>
> That is an entirely different matter, and one that I struggle to care about.

So why respond in such a ridiculous fashion?

> That is, I don't care whether new registrations use a urn: prefix or not;
> "urn:" might make clear that these are non-resolvable, I certainly dislike
> the endless urn:ietf:dragons:xml-params:beware:of:the:leopard style of URN
> the IETF seems to prefer to mint, but really there's more important things
> in life, like whether I should put that pasty in the microwave about now. (I
> think I probably should).

Perhaps you could explain how little you care in some more detail?

> On the other hand, bombastically declaring that "urn:" should be stripped
> everywhere without any further thought is, I think, very short-sighted; more
> so in the face of obvious examples of problems.

Did I write an Internet Draft suggesting that? If so I have forgotten
having done so. Quite possible of course. I do write quite a few of
them. And I can write a draft pretty quickly now that I have rfctool
that lets me compose them in Word.

Ah no, I did not. I see what happened now. You read my post and got
worried that as so frequently happens in the IETF, a post submitted to
the ietf discuss list based on conversations in the bar the night
before is likely to become an RFC before the week is out if nobody
gets on the case immediately.

> Yes; these are references to LDAP attributes, and are of the form
> http://www.ietf.org/... rfcXXX.txt#attributeName. I'm in no way trying to
> claim this is sensible.

Take a look at the identifiers for int32 etc.

IETF Secretariat | 27 Mar 21:00 2015
Picon

IETF 93 - Registration is Now Open!

IETF 93
Prague, Czech Republic
July 19 - 24, 2015
Hosts: Brocade and CZ.NIC

IETF 93 Information: http://www.ietf.org/meeting/93/index.html
Meeting venue: The Hilton Prague http://www1.hilton.com/en_US/hi/hotel/PRGHITW-Hilton-Prague-hotel/index.do
Register online at: http://www.ietf.org/meeting/register.html

1.  Registration
2.  Visas & Letters of Invitation
3.  Value Added Tax (VAT)
4.  Accommodations

1. Registration
	A. Early-Bird Registration - USD 700.00, if paid in full prior to 23:59 UTC 10 July 2015.
	B. After Early-Bird cutoff - USD 875.00
	C. Full-time Student Registrations - USD 150.00 (with proper ID)
	D. One Day Pass Registration - USD 375.00
	E. Registration Cancellation   
   	Cut-off for registration cancellation is Monday, 13 July 2015 at UTC 23:59. Cancellations are subject to
a 10% (ten percent) cancellation fee if requested by that date 
	and time.
	F. Online Registration and Payment ends Friday, 17 July 2015, 17:00 local Prague time.
	G. On-site Registration begins on Sunday, 19 July 2015 at 10:00 local Prague time.

2. Visas & Letters of Invitation:
	For information on Visiting the Czech Republic, please visit:http://www.mzv.cz/jnp/en/information_for_aliens/general_visa_information/

	After you complete the registration process, you can request an electronic IETF letter of invitation and
a Local Letter of Invitation. The registration system also allows for 	you to request hard copy letters of
invitation. You may request one at a later time by following the link provided in the confirmation email.

	Please note that the IETF Letter of Invitation may not be sufficient for obtaining a visa to enter the Czech Republic.

3. Value Added Tax (VAT)
	The European Union (EU) and its member states require us to collect a Value Added Tax on all registration
fees. You may be entitled to recoup some or all of the VAT. 	 For this meeting the Czech VAT of 21% has been
added to the Registration Fee. More information is available at http://www.ietf.org/meeting/93/vat.html.

4.  Accommodations
	We are working to open hotel reservations as soon as possible. An announcement will be sent when
reservations are open.

Only 113 days until the Prague IETF!

Thomas Narten | 27 Mar 05:53 2015
Picon

Weekly posting summary for ietf <at> ietf.org

Total of 107 messages in the last 7 days.

script run at: Fri Mar 27 00:53:03 EDT 2015

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
  6.54% |    7 |  7.37% |    70826 | spencerdawkins.ietf <at> gmail.com
  5.61% |    6 |  4.40% |    42307 | dharkins <at> lounge.org
  5.61% |    6 |  4.40% |    42286 | dhc <at> dcrocker.net
  4.67% |    5 |  4.74% |    45511 | nico <at> cryptonector.com
  3.74% |    4 |  5.54% |    53265 | david.black <at> emc.com
  3.74% |    4 |  5.12% |    49160 | akatlas <at> gmail.com
  4.67% |    5 |  3.25% |    31250 | ted.lemon <at> nominum.com
  2.80% |    3 |  4.12% |    39558 | mary.h.barnes <at> gmail.com
  3.74% |    4 |  3.18% |    30541 | jari.arkko <at> piuha.net
  3.74% |    4 |  3.17% |    30498 | brian.e.carpenter <at> gmail.com
  2.80% |    3 |  3.58% |    34412 | kathleen.moriarty.ietf <at> gmail.com
  2.80% |    3 |  3.24% |    31180 | hartmans-ietf <at> mit.edu
  2.80% |    3 |  2.56% |    24598 | mstjohns <at> comcast.net
  2.80% |    3 |  2.38% |    22826 | phill <at> hallambaker.com
  2.80% |    3 |  2.36% |    22674 | scott <at> kitterman.com
  2.80% |    3 |  2.13% |    20490 | mcr+ietf <at> sandelman.ca
  2.80% |    3 |  1.64% |    15727 | randy <at> psg.com
  1.87% |    2 |  2.46% |    23654 | abdussalambaryun <at> gmail.com
  1.87% |    2 |  1.92% |    18441 | john-ietf <at> jck.com
  1.87% |    2 |  1.91% |    18394 | ggm <at> algebras.org
  1.87% |    2 |  1.75% |    16783 | fred <at> cisco.com
  1.87% |    2 |  1.66% |    15946 | melinda.shore <at> gmail.com
  1.87% |    2 |  1.53% |    14677 | masinter <at> adobe.com
  1.87% |    2 |  1.47% |    14151 | adrian <at> olddog.co.uk
  1.87% |    2 |  1.30% |    12469 | ietf-secretariat <at> ietf.org
  0.93% |    1 |  2.21% |    21263 | eric.gray <at> ericsson.com
  0.93% |    1 |  1.74% |    16715 | lee <at> asgard.org
  0.93% |    1 |  1.62% |    15610 | terry.manderson <at> icann.org
  0.93% |    1 |  1.17% |    11276 | dave <at> cridland.net
  0.93% |    1 |  1.16% |    11109 | daedulus <at> btconnect.com
  0.93% |    1 |  1.11% |    10710 | peter <at> andyet.net
  0.93% |    1 |  1.11% |    10637 | james <at> cyberinvasion.net
  0.93% |    1 |  1.08% |    10421 | jordi.palet <at> consulintel.es
  0.93% |    1 |  1.08% |    10399 | allison.mankin <at> gmail.com
  0.93% |    1 |  0.99% |     9512 | jhw <at> nestlabs.com
  0.93% |    1 |  0.93% |     8955 | lear <at> cisco.com
  0.93% |    1 |  0.93% |     8947 | narten <at> us.ibm.com
  0.93% |    1 |  0.92% |     8823 | bob.hinden <at> gmail.com
  0.93% |    1 |  0.87% |     8382 | mcr <at> sandelman.ca
  0.93% |    1 |  0.82% |     7917 | sm+ietf <at> elandsys.com
  0.93% |    1 |  0.81% |     7764 | mlarson <at> amsl.com
  0.93% |    1 |  0.79% |     7572 | joelja <at> bogus.com
  0.93% |    1 |  0.76% |     7345 | marka <at> isc.org
  0.93% |    1 |  0.76% |     7281 | peter <at> akayla.com
  0.93% |    1 |  0.72% |     6901 | tnadeau <at> lucidvision.com
  0.93% |    1 |  0.64% |     6153 | chair <at> ietf.org
  0.93% |    1 |  0.60% |     5772 | ajs <at> anvilwalrusden.com
--------+------+--------+----------+------------------------
100.00% |  107 |100.00% |   961088 | Total

Phillip Hallam-Baker | 26 Mar 17:32 2015

We should drop the useless urn: prefix

Following the discussion at the plenary where I didn't get the chance
to put the record straight, I have been looking at the existing IETF
URN scheme for RFCs and IDs. I plan to add support for this to the
output of my rfctool.

The rfc on IETF URNs is farily old and dates from the 'wasted years'.
https://tools.ietf.org/html/rfc2648
urn:ietf:rfc:2648

So some history on URLs and URL like things. Back in 1993 I discussed
URNs with Tim Berners Lee including the fact that to buy and sell
'stuff' online we would want URLs for cans of baked beans etc. So
there should be a UPC: 'URL'.

That conversation predates the mistake of introducing the false
distinction between URLs and URNs. From a semiotic point of view, ALL
URIs are names except for the 'data' URI and the digest based URIs. A
DNS name is a name. That is why is is called the Domain NAME System.

Whether a URI is a name or a locator depends entirely on how it is
used. Order baked beans from Amazon via the UPC code and it is a
locator. You choose your 'baked beans resolution service' as Amazon,
Peapod, Tesco, etc.

Names and locators are distinct use categories but not distinct
syntactic categories. The distinction comes from whether the name is
sufficiently complete to resolve the identifier to the identified or
not.

Since urns are not a distinct syntactic category, the justification
for the urn: prefix disappears. It is not only useless, it is
unnecessary. There is no circumstance in which a urn subscheme and a
uri scheme should be allowed to have divergent meanings.

Why make people write urn:ietf:rfc:2648 when ietf:rfc:2648 is sufficient?

I think it comes down to ring-kissing: Lets make everyone acknowledge
the fact that they are participating in our information universe which
we control.

The insistence on the urn prefix is leading to divergence where it
comes to DOIs. The DOI folk understand naming at least as well as we
do and they have no interest at all in sticking a 'URN' prefix at the
start.

http://www.doi.org/factsheets/DOIIdentifierSpecs.html

DOI: is a perfectly valid and well defined scheme. We should recognize
it as such and assign a top level URI identifier.

Spencer Dawkins at IETF | 26 Mar 17:24 2015
Picon

Generalist ADs?

Hi, David,

You mentioned intentionally including one or more ADs who were generalists on the IESG, during Admin Plenary open mike time last night.

I think I understood what you mean by that, because I responded to your comment and you didn't say "no, silly rabbit, what I'm saying is ..."

But could you give us a sentence or two about what you're thinking?

(I think I agree, but I'd like to make sure I'm agreeing with what you're thinking!)

Thanks,

Spencer
Spencer Dawkins at IETF | 26 Mar 17:20 2015
Picon

"Per Area" and "Per AD" review ballots?

Hi, David,

You mentioned "per-AD" at the Admin Plenary open mike last night, and I wanted to make sure I understood your point.

I think you were pointing to the ballot display on https://datatracker.ietf.org/iesg/agenda/documents/, where there is a box for each AD to ballot on each document, and suggesting that maybe balloting for each area on each document might would work about as well, giving equivalent coverage while reducing the review load on each AD (except Jari, of course - there being only one GEN AD).

Does that sound familiar?

Thanks,

Spencer
Dave Crocker | 26 Mar 13:41 2015
Picon

Nomcom feedback to appointees not up for renewal

Howdy,

During yesterday's plenary, this year's Nomcom chair, Michael
Richardson, made a comment that I responded to at the mic.  I'd like to
see whether there is interest in pursuing it:

Michael noted that the two-year cycle for appointees means that those
/not/ up for renewal go at least 18 months without feedback.  He put
forward the need for feedback to them sooner than that, but asserted
that having Nomcom do it would not be appropriate.

As a natural consequence of its interviewing process, Nomcoms always get
quite a bit of information about /all/ appointees, not just the ones
currently up for renewal.  No one else acquires this kind of information
regularly and reliably.

Of the 4 nomcoms I've been on, at least two acted on this feedback,
having a directed conversation with at least one such appointee each time.

So I suggest that providing explicit feedback to all appointees not up
for renewal become a regular part of nomcom's deliverables.

d/
--

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


Gmane