Re: Gen-ART Last Call review of draft-klensin-unicode-escapes-06.txt

[John C Klensin]

--On Tuesday, 06 November, 2007 21:18 -0600 Spencer Dawkins
<[EMAIL PROTECTED]> wrote:

> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please resolve these comments along with any other Last Call
> comments
> you may receive.
> 
> Document: draft-klensin-unicode-escapes-06.txt
> Reviewer: Spencer Dawkins
> Review Date: 2007-11-08
> IETF LC End Date: 2007-11-15
> IESG Telechat date:
> 
> Summary: This document is ready for publication as a BCP, with
> one question and one comment for the sponsoring AD. I should
> also mention that the document is very clear and well-written.
> 
> Comments: This document uses a fair amount of SHOULD/SHOULD
> NOT language without a lot of explanation about why the
> SHOULDs are not MUSTs. I'm not sure what's appropriate for an
> APPS-area BCP, but I usually ask about SHOULD/SHOULD NOT
> without guidance.
> 
> This is a BCP that recommends two different encoding escapes.
> If the SHOULDs are something like "MUST unless you're using
> the other method", is 2119 language even needed?

That is a good question.  Some small part of that language is
the result of the evolution of this document from one strong
recommendation, to no recommendation at all, to a pair of
alternative recommendations, neither of which was the original
one.  (So much for the theory that individual submissions don't
change during IETF discussion.)I'd be happy to change it to
"you MUST use one or the other" if that is what the community
prefers, but there actually are reasons for the weaker language:
there are probably protocols that are closely tied to a
particular programming language or existing protocol that would
be better off following their practices than these
recommendations.  

One example that came up in the discussions involved IRIs.  URIs
use escaped (hexified) UTF-8, which, as you probably inferred
from the document, is one of my least favorite choices.  IRIs
stayed with that convention to keep things from becoming even
worse as the two types of escapes got confused.   I personally
think that may have been the wrong choice, but my belief is part
of a more general impression that IRIs didn't go nearly far
enough in the direction of internationalization to be really
useful.   And, since we seem to be trapped in  that direction, I
suspect there can be a strong case made that some future
protocol that builds in IRIs and URIs should follow the same
path... hence SHOULD.

I didn't discuss those exception cases in the draft for two
reasons.  First, no one before this has asked for that
discussion.  Second, I find most of the cases I've been able to
think of, including the one above, to be distasteful and didn't
want to explain them in a way that would give those who like
them better than I do an excuse and rationale.

best,
   john



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Gen-ART Last Call review of draft-klensin-unicode-escapes-06.txt

[Spencer Dawkins]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-klensin-unicode-escapes-06.txt
Reviewer: Spencer Dawkins
Review Date: 2007-11-08
IETF LC End Date: 2007-11-15
IESG Telechat date:

Summary: This document is ready for publication as a BCP, with one question 
and one comment for the sponsoring AD. I should also mention that the 
document is very clear and well-written.


Comments: This document uses a fair amount of SHOULD/SHOULD NOT language 
without a lot of explanation about why the SHOULDs are not MUSTs. I'm not 
sure what's appropriate for an APPS-area BCP, but I usually ask about 
SHOULD/SHOULD NOT without guidance.


This is a BCP that recommends two different encoding escapes. If the SHOULDs 
are something like "MUST unless you're using the other method", is 2119 
language even needed?


Thanks,

Spencer 




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [Ietf-message-headers] Re: I-DAction:draft-saintandre-header-pres-00.txt

[SM]

At 12:03 06-11-2007, Peter Saint-Andre wrote:

> 1 - why two drafts instead of one ?

Because some people consider IM and presence to be fully separable
features, which is why we have both the pres: and im: URI schemes (as
defined in RFCs 3859 and 3860 respectively). See also RFC 2779.


I read draft-saintandre-header-im-00.  I must have missed 
draft-saintandre-header-pres-00.


I hope there's not going to be a new header each time there's a new 
feature. :-)




> 9 - Likewise RFC 3860.  I hope you're not trying to
> move vCards piecemeal into mail header fields.

By no means. I am trying to address feedback received during the Last
Call on draft-saintandre-jabberid. Part of that feedback raised the
issue of working on a more generic solution that is not tied to a
specific instant messaging and presence technology (in this case, XMPP).
These I-Ds are my good-faith attempt at fulfilling my promise to work on
a more generic solution.


Could we have only one I-D which is extensible to encompass all these 
schemes?  I assume that will be draft-saintandre-header-pres-01.


BTW, the Author's address in your draft seems incomplete.

Regards,
-sm 



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP

[Jari Arkko]

Stephane,

>> IANA has never charged an applicant for their request for protocol
>> parameters including port numbers.
>> 
>
> McBride never said so. He said you have to pay experts for the
> reviews.
>   

Right, but that's not needed either. At least not if we are
talking about a registry that has policy Expert Review.
If an expert exists, he will be polled by IANA for an opinion.
If an expert is not assigned for the particular registry, IANA
will ask IESG to assign one.

Jari


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [Ietf-message-headers] Re: Re:I-DAction:draft-saintandre-header-pres-00.txt

[Peter Saint-Andre]

Frank Ellermann wrote:
> Peter Saint-Andre wrote:
> 
>>> 1 - why two drafts instead of one ?
>> Because some people consider IM and presence to be fully separable
>> features, which is why we have both the pres: and im: URI schemes
> 
> Two schemes with a semantics somewhere between about: and file: ...
> if I am interested in pres:[EMAIL PROTECTED], can say Psi help me ?

Not unless Psi implements resolution of the pres: URI scheme (i.e.,
doing the required SRV lookup). As far as I know, Psi does not yet
implement that.

>>> 2 - who wants to publish pres URIs in email headers ?
>> Presumably people who want to show presence icons next to the names
>> of message authors.
> 
> Okay, but Gmail can manage that without a fancy Pres-ID: mail header
> field.  I also don't quite believe in this separation "feature".

Gmail is an integrated service. What if you're using mutt or Thunderbird
or some random MUA and you want to show presence information about a
message author?

>>> 3 - what about Netnews ?
>> Yes, I added that in version -01 this morning (not yet submitted)
> 
> Thanks.
> 
>>> 4 - what's going on with the nice jabberid draft ?
>> That is still to be determined.
> 
> You've now demonstrated your good will wrt im: and pres:, after
> that exercise please let's continue with the jabberid.  It was
> almost perfect, "experimental" status is also okay.

Version -06 had an intended status of Informational. I have been
convinced that that's most appropriate.

>>> 5 - jabberid had an interesting IRI example, the new
>>> drafts claim that [EMAIL PROTECTED] is an URI.
>> For good or for ill, the pres: and im: URI schemes reuse the 
>> "mailbox" construct from RFC 2822. Or something like that
> 
> For ill, they imitate mailto:.  But what I meant in (5) was a
> syntactical nit, [EMAIL PROTECTED] is no URI, you forgot the
> scheme, as in im:[EMAIL PROTECTED]
> 
>> In any case non-US-ASCII characters would need to be handled
>> as is traditional in email systems, as far as I can see.
> 
> "mailto-ter" (my name for a successor of mailto-bis supporting
> EAI) is a _very_ hard case.  And mailto-bis is also a _very_
> hard case.  Don't hold your breath.
> 
> IFF mailto-bis survives a Last Call, and IFF im/pres follow
> suite, and IFF 2822bis reduces its NO-WS-CTL horrors, and IFF
> EAI reaches "experimental", then might be a good time to look
> at im/pres again.  
> 
>>> 6 - I've never seen a pres: URI outside of RFC 3859,
>>> why should I wish to see this in a mail header ?
>> Because it is a more generic solution.
> 
> Okay, I've to check if Psi has a "be more generic" option :-)

Probably not yet. You can always request the feature. :)

>> http://www.iana.org/assignments/im-srv-labels
> 
> Some SRV magic, does it work wrt xmpp ?  Apparently there
> is no _xmpp.stpeter.im.  "SRV" is still a mystery for me.

I don't run an xmpp server at my personal domain, since I use the
jabber.org domain for that. But per RFC 3859 you can type 'dig SRV
_pres._xmpp.jabber.org' and get some results (since we mainly use these
SRV records for server-to-server functionality, the SRV record lists a
port of 5269, which is the server-to-server port for xmpp).

>>> if I recall discussions with Paul and Martin on the
>>> URI list about RFC 2368 (mailto) correctly. 
>> I do not recall that discussion.
> 
>   Sorry,
> it was Bruce and Paul, Matin was in other mailto-threads.

Thanks.

Peter

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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP

[Stephane Bortzmeyer]

On Tue, Nov 06, 2007 at 09:28:36AM -0800,
 Ted Hardie <[EMAIL PROTECTED]> wrote 
 a message of 48 lines which said:

> ... to combat whatever other bad info is floating around there. Not
> that I really expect blogs to fact check, but it would get anyone
> who actually looked the right information.

I am not sure it is easy for a newcomer, who programs but is not
acquainted with IETF rules and habits, to know about these
processes. Those who are deeply involved in the IETF for many years
often forget how scary and surprising it can be for people coming from
the outside. RFC 3774, 2.6.6, 2.6.7, etc

In the hope of spreading the information, I've added pointers to the
IETF public archives to the Web page at kerneltrap.

Sorry for horribly mispelling your name, but I typed too fast and did
not find a way to fix my mistakes afterwards.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP

[Stephane Bortzmeyer]

On Tue, Nov 06, 2007 at 11:04:46AM -0800,
 Michelle Cotton <[EMAIL PROTECTED]> wrote 
 a message of 86 lines which said:

> IANA has never charged an applicant for their request for protocol
> parameters including port numbers.

McBride never said so. He said you have to pay experts for the
reviews.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Daily Dose version 2 launched

[Jari Arkko]

Stephane,

> Shame on you, you should use Atom, the IETF format (RFC 4287) :-)
>   

Point taken. I switched to the Atom feed.

>>   For that, the left hand side frame that lists WGs seems a bit
>>   unnecessary, and consumes screen space. Is there a way to make the
>>   frame not be included in the RSS feed?
>> 
>
> I do not understand, there are no frames in the RSS feed (nor in the
> Atom one) and RSS has no support for frames anyway.
>
> Actually, the problem I have with both feeds is that they have no
> , just the titles (which does not change, except for the
> issue number), the date and the link. Not very useful.
>   
Apparently my reader (Thunderbird 1.5) does something funny
with the feed; it shows the actual content. I like that, but I have
not looked at the details of what is actually provided in the feed
and what is fetched from the link.

Jari


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [Ietf-message-headers] Re: I-DAction:draft-saintandre-header-pres-00.txt

[Peter Saint-Andre]

Frank Ellermann wrote:
> Peter Saint-Andre wrote on the message-headers list:
> 
>> FYI
> 
> Thanks.  Frankly, I hate these drafts.

Great! Honest feedback is appreciated and agreement is overrated. :)

> 1 - why two drafts instead of one ?

Because some people consider IM and presence to be fully separable
features, which is why we have both the pres: and im: URI schemes (as
defined in RFCs 3859 and 3860 respectively). See also RFC 2779.

> 2 - who wants to publish pres URIs in email headers ?

Presumably people who want to show presence icons next to the names of
message authors.

> 3 - what about Netnews ?

Yes, I added that in version -01 this morning (not yet submitted):

http://svn.xmpp.org:18080/browse/XMPP/trunk/internet-drafts/draft-saintandre-header-pres-01.xml?r1=1337&r2=1339

> 4 - what's going on with the nice jabberid draft ?

That is still to be determined.

> 5 - jabberid had an interesting IRI example, the new
> drafts claim that [EMAIL PROTECTED] is an URI.

For good or for ill, the pres: and im: URI schemes reuse the "mailbox"
construct from RFC 2822. Or something like that -- I asked about it once
on the SIMPLE WG list but never received a reply, so the exact meaning
is unclear to me:

http://www1.ietf.org/mail-archive/web/simple/current/msg07163.html

In any case non-US-ASCII characters would need to be handled as is
traditional in email systems, as far as I can see.

> 6 - I've never seen a pres: URI outside of RFC 3859,
> why should I wish to see this in a mail header ?

Because it is a more generic solution.

> 7 - the jabberid was obviously about xmpp:, what are 
> im: and pres: about ?

Any instant messaging and presence technology, as registered with the IANA:

http://www.iana.org/assignments/im-srv-labels

http://www.iana.org/assignments/pres-srv-labels

Oddly, the only registered technology is XMPP. But other technologies
could be registered (and I presume that the lack of a SIP registration
is merely an oversight).

> 8 - RFC 3859 still uses RFC 2396 syntax on top of a
> RFC 2822 .  That's known to be wrong if
> I recall discussions with Paul and Martin on the
> URI list about RFC 2368 (mailto) correctly. 

I do not recall that discussion. But, as mentioned, I do admit to being
confused about the exact syntax of the pres: and im: URI schemes.

> 9 - Likewise RFC 3860.  I hope you're not trying to
> move vCards piecemeal into mail header fields.

By no means. I am trying to address feedback received during the Last
Call on draft-saintandre-jabberid. Part of that feedback raised the
issue of working on a more generic solution that is not tied to a
specific instant messaging and presence technology (in this case, XMPP).
These I-Ds are my good-faith attempt at fulfilling my promise to work on
a more generic solution.

>  Frank
> 
> Cc: general list, after all jabberid was Last Called.

Fair enough, I retain the cc.

Peter

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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-goodwin-iso-urn (A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO)) to Informational RFC

[Frank Ellermann]

The IESG wrote:

> as an Informational RFC

The draft says "Intended status: Standards Track", what's 
correct ?  RFC 3406 states:  "The RFC need not be standards-
track".  

Is the fourth paragraph in the introduction from "Every" up
to "withdrawn" supposed to reflect an IETF consensus ?  It
talks about "democratic framework", "consensus", and similar
magic words.

The ABNF doesn't pass validation,  can't be folded,
just add ";" in front of folded lines.  And there can't be
no  at all in a rule, proposed fix:

-| techelement   = ; unspecified
-|
-| isodefined= ; unspecified

+| techelement   = 
+|
+| isodefined= 

It would be interesting to see the URNs for the "normative
references" [ISODIR-1], [ISODIR-2], [ISODIR-S], and
[ISOGUIDE69] in action, together with a corresponding URI.

BTW, ISO Guide 69:1999, 8 pages available as PDF for 56 CHF.
I don't find the normative "directives" immediately.

 Frank


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP

[Bill Fenner]

>For example, see:
>http://kerneltrap.org/node/2873

That message appears to be based completely on conjecture - for
example, their assertion based on looking at the list of assigned
numbers ignores the fact that all of the numbers they based their
supposition on were assigned before the rules were put in place.

  Bill

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP

[Michelle Cotton]

Keep in mind that the interview with Mr. McBride was back in April 2004.
The response times back then may not have been great, but IANA has never
charged an applicant for their request for protocol parameters including
port numbers.

IANA response times have greatly improved over the last few years.  See:
http://www.iana.org/reporting-and-stats/index.html (Performance Charts)

In cases where experts are used, IANA has a reminder system in place as
well as an escalation process to notify the IESG if an expert is not
responding to IANA.

With regards to the protocol numbers described in
arkko-rfc2780-proto-upate, there are only approximately 115 that are
unassigned in the registry.  This is a scarce resource and care should
taken in making assignments.  This document does not change much in
actual procedures with the IANA as a protocol number has not been
assigned under NDA for at least 6 years if not longer.

Hope this information is helpful.

Michelle Cotton
Manager, IETF Relations
IANA

--

From: Bernard Aboba <[EMAIL PROTECTED]>
To: ietf@ietf.org
Date: Tue, 6 Nov 2007 07:02:08 -0800 (PST)
Subject: Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation
Guidelines for the Protocol Field) to BCP


I also think this is an appropriate, even if significant,
change of policy. I really don't see why we would give away
a precious resource such as a protocol number for secret
usage.


I also agree that the change is appropriate.  However, I am also aware of
significant frustration being voiced with respect to the speed by which
the expert review process moved -- and this change could slow it
further.  It's worth keeping in mind that the IETF has no power to prevent
people from using unallocated protocol numbers.

For example, see:
http://kerneltrap.org/node/2873

Quoting from Ryan McBride:

"The IANA has a heavily bureaucratic process for getting official number
assignments. There are essentially two options for getting a protocol
number assigned: The first is to run your protocol through the IETF on a
standards track. This avenue is closed to us - the IETF has become
monopolized by large corporate interests, and they have no problem with
using patented protocols. They're perfectly happy using VRRP, and they
won't support another standard. The second path is their proprietary
path; you pay for "experts" to review your protocol and if they agree
that it requires the numbers you're asking for, you get it. If you look
at the list of assigned protocol numbers, this method appears to be the
favored one. Getting a number allocation has more to do with having
money. Obviously, since we're not a large multinational corporation, we
can't afford to take this path. Since they were unable to help us by
providing a real alternative, our only option is to simply pick an unused
number and go with that."


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--- End of Forwarded Message

___
Ietf-iana mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf-iana




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP

[Jari Arkko]

Bernard,

> I also agree that the change is appropriate.  

Good.

> However, I am also aware of 
> significant frustration being voiced with respect to the speed by which 
> the expert review process moved -- and this change could slow it 
> further.  It's worth keeping in mind that the IETF has no power to prevent
> people from using unallocated protocol numbers.
>
> For example, see:
> http://kerneltrap.org/node/2873
>   

I would like to separate three things: 1) this change which is for IPv4
and IPv6 protocol numbers, 2) expert review process speed, and 3)
the specific case that you pointed to in the above.

For 1), I do not think we can have a blanket IANA rule for everything.
What the numbers are for impacts what the policy should be. I believe
what we are suggesting for the proto numbers is the right thing,
given that we are dealing with this specific space. Since the new
policy is IESG Approval or Standards Approval, the IESG can grant
requests based on a judgment call. For what it is worth, if, e.g., some
open source developers approached me for an allocation I would
work to get it approved in a timely manner, assuming the request
was reasonably sane.

For 2), this is indeed a problem. The IESG and IANA have been
in discussions on how to track these cases, what deadlines
we should set for raising the issue to the IESG if the expert
does not respond, etc. I think there's definitely room for
improvement here.

In addition, as has been discussed before on this list, we need
to think about what policies make sense. A restrictive
Standards Action/Expert Review/IESG Approval does not
always make sense unless there are field size or
interoperability issues. The rest should be as open as
possible. In general, the IANA policies need monitoring
and updates; WGs should look at their current policies
and determine if they are correct in today's environment

This is part of the reason why I said that the port case
is being handled separately. I think people should be
able to request ports much more easily than protocol
numbers.

For 3), I respectfully disagree with Ryan's statements on
the web page. He said "... you pay for "experts" to review
your protocol and if they agree that it requires the numbers
you're asking for, you get it. If you look at the list of assigned
protocol numbers, this method appears to be the favored one.
Getting a number allocation has more to do with having money."
This is obviously completely incorrect. All you have to do to
get an expert looking at an allocation is ask. And experts
who are unresponsive -- they appear to be capable of stalling
requests even from the big business guys :-(

Jari


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP

[Ted Hardie]

At 7:02 AM -0800 11/6/07, Bernard Aboba wrote:
>\
>Quoting from Ryan McBride:
>
>"The IANA has a heavily bureaucratic process for getting official number
>assignments. There are essentially two options for getting a protocol
>number assigned: The first is to run your protocol through the IETF on a
>standards track. This avenue is closed to us - the IETF has become
>monopolized by large corporate interests, and they have no problem with
>using patented protocols. They're perfectly happy using VRRP, and they
>won't support another standard. The second path is their proprietary
>path; you pay for "experts" to review your protocol and if they agree
>that it requires the numbers you're asking for, you get it.

Paying for expert review is certainly news to me.  I've cc'ed David Conrad, who 
is
GM of IANA, so he can comment. Looking at
 http://www.iana.org/cgi-bin/usr-port-number.pl and
http://www.iana.org/cgi-bin/sys-port-number.pl, though, I certainly don't
see a charge for expert review.

>If you look
>at the list of assigned protocol numbers, this method appears to be the
>favored one. Getting a number allocation has more to do with having
>money. Obviously, since we're not a large multinational corporation, we
>can't afford to take this path. Since they were unable to help us by
>providing a real alternative, our only option is to simply pick an unused
>number and go with that."

The article goes on to say:

>JA: Are you concerned that at a future date the IANA might officially assign 
>the port you've chosen to another protocol?
>Ryan McBride: Not extremely worried, no. Our hope is that they will accept it 
>as an official assignment before that has to happen.


In other words, they are squatting.  They're certainly not the first, but it 
might
be useful if IANA put something in large letters about the fees or lack of fees
on the application page, to combat whatever other bad info is floating around
there. Not that I really expect blogs to fact check, but it would get anyone who
actually looked the right information.

regards,
Ted


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP

[Russ Housley]

Bernard:

The worst case latency comes from the expert review with 
non-disclosure agreements.


We really do believe that this will make the latency much more consistent.

Russ


At 10:02 AM 11/6/2007, Bernard Aboba wrote:

>I also think this is an appropriate, even if significant,
>change of policy. I really don't see why we would give away
>a precious resource such as a protocol number for secret
>usage.

I also agree that the change is appropriate.  However, I am also aware of
significant frustration being voiced with respect to the speed by which
the expert review process moved -- and this change could slow it
further.  It's worth keeping in mind that the IETF has no power to prevent
people from using unallocated protocol numbers.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP

[Bernard Aboba]

>I also think this is an appropriate, even if significant,
>change of policy. I really don't see why we would give away
>a precious resource such as a protocol number for secret
>usage.

I also agree that the change is appropriate.  However, I am also aware of 
significant frustration being voiced with respect to the speed by which 
the expert review process moved -- and this change could slow it 
further.  It's worth keeping in mind that the IETF has no power to prevent
people from using unallocated protocol numbers.

For example, see:
http://kerneltrap.org/node/2873

Quoting from Ryan McBride:

"The IANA has a heavily bureaucratic process for getting official number 
assignments. There are essentially two options for getting a protocol 
number assigned: The first is to run your protocol through the IETF on a 
standards track. This avenue is closed to us - the IETF has become 
monopolized by large corporate interests, and they have no problem with 
using patented protocols. They're perfectly happy using VRRP, and they 
won't support another standard. The second path is their proprietary 
path; you pay for "experts" to review your protocol and if they agree 
that it requires the numbers you're asking for, you get it. If you look 
at the list of assigned protocol numbers, this method appears to be the 
favored one. Getting a number allocation has more to do with having 
money. Obviously, since we're not a large multinational corporation, we 
can't afford to take this path. Since they were unable to help us by 
providing a real alternative, our only option is to simply pick an unused 
number and go with that."


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Daily Dose version 2 launched

[Lars Eggert]

Hi,

I'm hoping that everyone who's criticizing the volunteers that create  
and maintain our tools is considering to offer their obviously vast  
expertise in Vancouver: http://www3.tools.ietf.org/tools/ietfdb/wiki/ 
VancouverSprint


Lars

smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Daily Dose version 2 launched

[Hannes Tschofenig]

I am sure both of you can help to improve the existing tools.

I like Pasi's webpage a lot and I don't plan to retrieve any IETF page 
over GPRS.


Ciao
Hannes

Stephane Bortzmeyer wrote:

On Tue, Nov 06, 2007 at 02:23:19PM -,
 [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote 
 a message of 33 lines which said:


  

Generally, RSS and ATOM feeds are produced by software.  Software
can do things like parse web pages and separate the content from the
markup and also shorten long content items to the first 300
characters or so.



That's Python 101. Python 102 is to create the Web pages *and* the
syndication feeds from the same database of content (wether the
database is in XML, JSON, a RDBMS, etc) :-)

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
  



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Daily Dose version 2 launched

[Stephane Bortzmeyer]

On Tue, Nov 06, 2007 at 02:23:19PM -,
 [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote 
 a message of 33 lines which said:

> Generally, RSS and ATOM feeds are produced by software.  Software
> can do things like parse web pages and separate the content from the
> markup and also shorten long content items to the first 300
> characters or so.

That's Python 101. Python 102 is to create the Web pages *and* the
syndication feeds from the same database of content (wether the
database is in XML, JSON, a RDBMS, etc) :-)

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Daily Dose version 2 launched

[michael.dillon]

> The second, and more important, reason is that AFAIK most 
> feed readers and aggregators wouldn't be able to render the 
> expanding yellowish boxes (which contain ID abstracts and 
> other details) anyway, because they rely on CSS and JavaScript.

Since when has anyone considered CSS and JavaScript to be
CONTENT!?!?!?

Generally, RSS and ATOM feeds are produced by software.
Software can do things like parse web pages and separate
the content from the markup and also shorten long content
items to the first 300 characters or so. 

In the real world, this kind of thing is Python 101 in that
beginners who have never before used a scripting language
somehow manage to set up their own RSS and ATOM feeds.

In the real world, web site developers also do something
called "usability testing" which catches all these issues
before the site ever goes live. For example, read this:
http://www.useit.com/alertbox/2319.html

If you would run three or four cycles of these cheap
5-user usability tests, fixing all issues before doing
the next test, then you would not have so much traffic
on the IETF complaining.

--Michael Dillon

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Daily Dose version 2 launched

[Stephane Bortzmeyer]

On Tue, Nov 06, 2007 at 03:30:04PM +0200,
 [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote 
 a message of 17 lines which said:

> > Actually, the problem I have with both feeds is that they have no
> > ,[...]
> 
> There were two reasons for this: the first is size (one issue can 
> easily be 100 KB, so a feed containing the 20 most recent issues
> would be quite large).

A typical syndication feed does not serve the entire content, but an
abstract.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Daily Dose version 2 launched

[Pasi.Eronen]

Stephane Bortzmeyer wrote:

> Actually, the problem I have with both feeds is that they have no
> , just the titles (which does not change, except for the
> issue number), the date and the link. Not very useful.

There were two reasons for this: the first is size (one issue can 
easily be 100 KB, so a feed containing the 20 most recent issues
would be quite large).

The second, and more important, reason is that AFAIK most feed 
readers and aggregators wouldn't be able to render the expanding 
yellowish boxes (which contain ID abstracts and other details) 
anyway, because they rely on CSS and JavaScript.

Best regards,
Pasi

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Daily Dose version 2 launched

[Stephane Bortzmeyer]

On Tue, Nov 06, 2007 at 03:04:14PM +0200,
 Jari Arkko <[EMAIL PROTECTED]> wrote 
 a message of 31 lines which said:

> - I'm using RSS (not browser) for accessing the news.

Shame on you, you should use Atom, the IETF format (RFC 4287) :-)

>   For that, the left hand side frame that lists WGs seems a bit
>   unnecessary, and consumes screen space. Is there a way to make the
>   frame not be included in the RSS feed?

I do not understand, there are no frames in the RSS feed (nor in the
Atom one) and RSS has no support for frames anyway.

Actually, the problem I have with both feeds is that they have no
, just the titles (which does not change, except for the
issue number), the date and the link. Not very useful.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Daily Dose version 2 launched

[Jari Arkko]

The new page does look VERY nice, thanks Pasi and Henrik!

A couple of observations:

- I'm using RSS (not browser) for accessing the news. For that,
  the left hand side frame that lists WGs seems a bit unnecessary,
  and consumes screen space. Is there a way to make the
  frame not be included in the RSS feed?

- I have trained my eyes to look for draft-wg-foo patterns, and the
  new "title: (draft): new status" format is a bit harder to read for
  that. I don't know how to fix this, though. Perhaps you'd want to
  test with "draft: title: new status" or something like that, just to
  make the draft name more visible and more easily found from the
  same horizontal position on the page.

- I don't really care much about what the main page at tools.ietf.org
  contains, as long as I can get to the necessary information from
  there. 99.9% of my accesses to the tools.ietf.org web site are to
  the WG or draft status pages. The tools that I use are either
  installed on my computer (e.g., xml2rfc) or conveniently
  available from the WG status pages (e.g., idnits). But other
  people may have different usage patterns, YMMV.

Jari


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Reminder: Offer of time on the IPR WG agenda for rechartering

[Norbert Bollow]

Lawrence Rosen <[EMAIL PROTECTED]> wrote:
> In any event, these email lists have elicited more comments than any
> meeting in Vancouver could properly address. How do we intend to
> move toward consensus?

I think it is clear from the discussions that while there is no
consensus that the current way of doing things is adequate, there
is also little to no hope for reaching a consensus anytime soon
for a comprehensive set of changes that would fully resolve the
existing concerns with regard to standards-track and other RFCs
describing protocols and data formats which for patent reasons
cannot fully be implemented in open source and free software.

The only way forward therefore seems to be to seek to identify
relatively small changes for which rough consensus can be reached
and which are helpful already for reducing the problem or resoving
some aspects of it.

Greetings,
Norbert.


-- 
Norbert Bollow <[EMAIL PROTECTED]>  http://Norbert.ch
President of the Swiss Internet User Group SIUGhttp://SIUG.ch
Working on establishing a non-corrupt and
truly /open/ international standards organization  http://OpenISO.org

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP

[Jari Arkko]

Brian, Frank,

Thanks for your comments. A few additional notes below:

> Red herring as far as this draft is concerned: I'd be interested
> to know why we are still willing to allow non-disclosure for
> port numbers (see RFC 2780 sections 8 and 9.1). Port numbers
> are going fast.

As was mentioned already, this is something that Lars and a
few other folks are currently looking at. I'm presuming that
there will be a draft about this later.

But the port case might be different; that's why they are pursued
separately, even if both share some practical problems associated
with NDAs for volunteer experts etc. I view the protocol number
rule change as a bug fix.

>>> From -00 to Last Call in less than three hours, is that
>> a "speedy publish" procedure I haven't heard of before ?
>
> I-D submission tool plus the sponsoring AD's special buttons in
> the I-D tracker. Seems like eating our own dogfood to me.

Its part of the IESG's effort to improve the speed of our process
by moving to units of hours instead of months ;-) But seriously,
this was merely the combination of a very short draft, a change
that appears to be the right thing, sponsoring AD (Russ) being
aware of the issue from past discussions with IANA, and the
AD review getting done in fifteen minutes after I requested
it. But the main effort and bulk of time for this draft is in
the public discussion of what rules makes sense -- and we
just started that in the last call.

More generally, short drafts and bug fixes tend to go through
relatively quickly. Individual submissions via sponsoring AD
may sometimes go quicker than WG submissions, because there
are less forums and their managers to go through. However,
individual submissions may get less priority from the ADs
if they have many WG submissions on their queue as well.
And complex proposals need some forum for the discussion
to happen in any case. Finally, drafts that do not need
modification at LC or IESG review stage tend to go through
about four times as fast as drafts that do need modification.

Jari


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP

[Lars Eggert]

On 2007-11-6, at 2:08, ext Brian E Carpenter wrote:

Red herring as far as this draft is concerned: I'd be interested
to know why we are still willing to allow non-disclosure for
port numbers (see RFC 2780 sections 8 and 9.1). Port numbers
are going fast.


We've recently been discussing port number allocation procedures with  
IANA, and changes may be coming.


Lars

smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf