Test version of the Parking Area
What's the Parking Area? It's the list of all drafts that have been approved by the IESG but are not yet published as RFCs. You can find the test version at http://rtg.ietf.org:8080/Test/parking There's also a link to it off the IETF Chair's page at http://www.ietf.org/u/ietfchair/ Thanks to Bill Fenner for putting this together. Comments on the principle or the test implementation are welcome. Brian Carpenter ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-klensin-iana-reg-policy-00.txt
John C Klensin wrote: --On Wednesday, July 13, 2005 16:57 +0200 Brian E Carpenter <[EMAIL PROTECTED]> wrote: General AD hat on: I'm concerned that since rfc2434bis is in progress, any changes to RFC 2434 should be made in that draft, not by an additional document. Otherwise we will end up with a patchwork quilt of documents. So I'd encourage the authors of iana-reg-policy to figure out where their ideas would impact draft-narten-iana-considerations-rfc2434bis, and as the saying goes "send text." Brian, Let me/us respond to the substantive part of your message separately. However, I think the above is, if not equivalent to, at least vaguely similar to: "forget everything that has been said about consensus documents, if the right people (maybe defined here as 'authors of original') post an I-D, it immediately supercedes the published document". I think that makes me very anxious. And I don't understand your interpretation. 2434 is a consensus document and 2434bis is in progress and, assuming it makes it through the process, will emerge as a consensus document. All I meant to say was: let's make sure that the pieces of iana-reg-policy that would modify 2434 are discussed as part of forming consensus about the contents of 2434bis. Otherwise, we'd risk ending up with inconsistent output documents. We have other rules that makes this problem even worse: when our I-D was written, one possibility was that it would gain some traction, it would be revised once or maybe twice, and we (or someone else) would request an IETF Last Call. If that, in turn, went smoothly and quickly, Why would it go more quickly than 2434bis, especially if the two drafts remain inconsistent, as they certainly are right now? we'd have a document that was intended to change the way registration procedures were conducted making a probably-normative reference to a working draft and the entire "update and fix to reflect community consensus" blocked both procedurally and on the flow of the RFC Editor queue.Again, that doesn't seem like a good idea to me. It wouldn't be a good idea. I would want to last call 2434bis and iana-reg-policy simultaneously, with a specific intent that they be mutually consistent. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-klensin-iana-reg-policy-00.txt
(reminder - my AD hat is off for this part of the discussion) John Leslie wrote: ... Hans Kruse <[EMAIL PROTECTED]> wrote: ... 1. If the option appears in a packet, will there be any possible negative impact on a network element that has no code to process the option. This is a genuine issue in the proposal by Dr. Roberts... But, IMHO, it's far better to _review_ that issue, and document the negative impacts I agree. Did I write something that indicated otherwise? (which we have failed to do for the issue at hand). Correct, so far. And despite the IESG's recommendation, I expect that we (the IETF) will get the chance to do so in the case in point. ... I fundamentally disagree with "There's every reason that the same standard should apply to specifications developed outside the IETF exactly as to IETF documents" for the simple reason that it is non-enforceable. I also fundamentally disagree, but primarily because it asks for omniscience, and our supply of potential IESG members is limited enough without adding "demonstrated omniscience" to the requirements. It is enforcable and doesn't call for omniscience. When an outside body or person asks for one of these assignments, they are asked to provide a justification or specification. That's what the IETF will review. ... Beyond stewardship of limited code point space, I see no justification for the IETF having veto power over standards being developed to use public standards like IP. The fact that such independent developments are possible is at the heart of the success of the Internet. I agree with Hans here: a _large_ portion of the success of the Internet has come from being able to develop new ideas without waiting for the IETF _at_all_. Yes. What we're arguing about is whether there some specific domains in which the stability of the Internet is at risk, and whether parameter assignments in those domains can be treated neutrally. ... It seems that you want a review of "is this protocol safe to deploy on the Internet"? I can see the reasoning behind that, but I think the code point assignment review is the wrong place. I partly agree with Hans here; but we're likely to get stuck needing to review it at that point. In fact, if a spec is developed elsewhere, as in this case, the fact is that the assignment review is the *only* place available for IETF review. That, I think, is why RFC 2780 was written ... What if, in the case above, the code gets assigned along with publication of an RFC that in fact says that the code in question "belongs" to another organization and represents a non-IETF protocol that operators should filter unless they understand the implications of carrying these packets... I recommend seriously considering such a possibility. I agree that this would be very reasonable. It's very analogous to the Experimental/Local Use diffserv code points. See draft-fenner-iana-exp-2780-00.txt. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Test version of the Parking Area
Brian E Carpenter wrote: > You can find the test version at > http://rtg.ietf.org:8080/Test/parking Test results: all I get are various site errors. Please delete the dummy user "ietf" (didn't help) Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Test version of the Parking Area
How embarassing. The link worked yesterday but is broken today. Well,it *is* a test. I'm sure Bill will fix it shortly. Brian Brian E Carpenter wrote: What's the Parking Area? It's the list of all drafts that have been approved by the IESG but are not yet published as RFCs. You can find the test version at http://rtg.ietf.org:8080/Test/parking There's also a link to it off the IETF Chair's page at http://www.ietf.org/u/ietfchair/ Thanks to Bill Fenner for putting this together. Comments on the principle or the test implementation are welcome. Brian Carpenter ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
A proposed experiment in narrative minutes of IESG meetings
The IESG is interested in carrrying out an experiment to publish narrative minutes for IESG meetings as well as the regular minutes of decisions taken. Currently the IESG minutes are a formal record of decisions taken and (like the agenda) are generated semi-automatically by the secretariat. This is a well-oiled process that we don't want to disturb. However, the community clearly would like more information about the way the IESG reaches its decisions, beyond the record of comments on each document that is stored in the I-D tracker. We propose that, for an initial period of 6 months, a member of the community will be added to regular IESG meetings as a "recording secretary" who will write narrative minutes of the discussions, which will be posted publicly after IESG review for accuracy. (As always, personnel discussions will need to remain private or be minuted with great care.) The IESG welcomes comments on this proposal, to iesg@ietf.org or ietf@ietf.org as appropriate. If the community seems to be in favour of this experiment, we will soon call for volunteers and pick one person to act for the initial six months. After six months, we will ask the community whether the results justify continuing the effort. The main question will be whether the community is getting useful extra information. (Thanks to Spencer Dawkins for triggering this idea.) Brian for the IESG ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Test version of the Parking Area
It should be working now. (The danger of running on live data - when it changes in unanticipated ways, the page breaks!) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Test version of the Parking Area
Dear Brian and Bill, Thanks for providing this! Is this (239-element) table sorted? I might suggest "sorted by ID name within WG", but any sort would be a good thing to provide. Thanks for making it available, Spencer What's the Parking Area? It's the list of all drafts that have been approved by the IESG but are not yet published as RFCs. You can find the test version at http://rtg.ietf.org:8080/Test/parking There's also a link to it off the IETF Chair's page at http://www.ietf.org/u/ietfchair/ Thanks to Bill Fenner for putting this together. Comments on the principle or the test implementation are welcome. Brian Carpenter ___ 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
Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)
Brian E Carpenter wrote: 3. Thus I come to the key question - how high should the bar be for assignments in clearly constrained namespaces? This month's poster child is IPv6 option numbers, but at an even more basic level, we should probably be more worried about port numbers, where we seem pretty close to running out of well-known numbers, and moving along nicely through the registered port numbers. I was surprised that TCP-over-IPv6 and UDP-over-IPv6 didn't increase the port number space. I know it's off-topic here, but anyone know why they didn't? It surely must have been considered. -- David Hopwood <[EMAIL PROTECTED]> ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A proposed experiment in narrative minutes of IESG meetings
We propose that, for an initial period of 6 months, a member of the community will be added to regular IESG meetings as a "recording secretary" who will write narrative minutes of the discussions, ... The IESG welcomes comments on this proposal Bold, interesting and encouraging. -- d/ Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)
In message <[EMAIL PROTECTED]>, David Hopwood writes: >Brian E Carpenter wrote: >> 3. Thus I come to the key question - how high should the bar be for >> assignments in clearly constrained namespaces? This month's poster >> child is IPv6 option numbers, but at an even more basic level, we >> should probably be more worried about port numbers, where we seem >> pretty close to running out of well-known numbers, and moving along >> nicely through the registered port numbers. > >I was surprised that TCP-over-IPv6 and UDP-over-IPv6 didn't increase >the port number space. I know it's off-topic here, but anyone know why >they didn't? It surely must have been considered. > That was considered to be part of TCPng, and as best I recall was explicitly out of scope. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
On Wed, 13 Jul 2005, Brian E Carpenter wrote: > These are personal comments. I am also the shepherding AD for > this draft. I have a request for the authors and the shepherding AD: please review Section 3.5 of , which provides guidelines on how to write and IANA Considerations section in a MIB document, and bring to my attention any inconsistencies with draft-narten-iana-considerations-rfc2434bis. Note that has been approved as a BCP and is in the RFC Editor's queue; it would not be good to have an inconsistency. I didn't see any myself, but I would like for more eyeballs to have a look. > >5.1. When There Are No IANA Actions > > > > Before an Internet-Draft can be published as an RFC, IANA needs to > > know what actions (if any) it needs to perform. Experience has shown > > that it is not always immediately obvious whether a document has no > > IANA actions, without reviewing a document in some detail. In order > > to make it clear to IANA that it has no actions to perform (and that > > the author has consciously made such a determination!), such > > documents should include an IANA Considerations section that states: > > > > This document has no IANA Actions. > > Suggest adding: > > This statement, or an equivalent form of words, must only be inserted > after the WG or individual submitter has carefully verified it to be true. > > In some cases, the absence of IANA-assigned values may be considered > valuable information for future readers; in other cases it may be > considered of no value once the document has been approved, and may be > removed before archival publication. This choice should be made clear > in the draft, for example by including a sentence such as > > [RFC Editor: please remove this section prior to publication.] > or > > [RFC Editor: please do not remove this section.] I support this change. First, it makes clear (by the phrase "or an equivalent form of words") that we are not going to require that authors copy the words verbatim. That's good. Second, given the lack of consensus we have on whether or not null IANA Considerations sections should remain in a published RFC, leaving the decision in the hands of the of the people responsible for the document seems to me to be the right way to go. Mike Heard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A proposed experiment in narrative minutes of IESG meetings
Brian E Carpenter <[EMAIL PROTECTED]> writes: > We propose that, for an initial period of 6 months, a member of > the community will be added to regular IESG meetings as a "recording > secretary" who will write narrative minutes of the discussions, > which will be posted publicly after IESG review for accuracy. Sounds useful to me. How about actually recording the discussion too? And publishing them as OGG or MP3. Editing out personnel discussion would still be possible. All for the sake of transparency and accountability. Regards, Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)
> I was surprised that TCP-over-IPv6 and UDP-over-IPv6 didn't increase > >the port number space. I know it's off-topic here, but anyone know why > >they didn't? It surely must have been considered. > > > > That was considered to be part of TCPng, and as best I recall was > explicitly out of scope. correct Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-klensin-iana-reg-policy-00.txt
On 13-jul-2005, at 16:57, Brian E Carpenter wrote: I can't disagree that namespaces should be as large as reasonably possible on engineering grounds. But actually extending a deployed namespace is a massive undertaking. A good example is the BGP4 AS number space - we've known for years that it is filling up, but the deployment effort involved in expanding it has prevented any action. Well, how is deployment going to happen if the specification never progresses beyond being a draft in half a decade? Also, draft-ietf-idr-as4bytes-10.txt has excellent backward compatibility so deployment shouldn't be much of a problem if we take enough time. However, for some inexplicable reason a sizable number of operators are violently set against increasing the AS number space. This month's poster child is IPv6 option numbers, but at an even more basic level, we should probably be more worried about port numbers, where we seem pretty close to running out of well-known numbers, and moving along nicely through the registered port numbers. It would be a very bad idea to increase the port number space. The reason a port number must be in every packet is in order to demultiplex different sessions between a pair of hosts. For this, 2 x 16 bits is more than enough. Port numbers are also used to identify the application protocol in question, but this only needs to happen when a session or association is established. So when the port numbers run out, let them eat SRV records. (And architecturally, port numbers in different places in different transport protocols are an abomination. They should be part of the address.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)
On Thu, 2005-07-14 at 15:54 +0100, David Hopwood wrote: > Brian E Carpenter wrote: > > 3. Thus I come to the key question - how high should the bar be for > > assignments in clearly constrained namespaces? This month's poster > > child is IPv6 option numbers, but at an even more basic level, we > > should probably be more worried about port numbers, where we seem > > pretty close to running out of well-known numbers, and moving along > > nicely through the registered port numbers. > > I was surprised that TCP-over-IPv6 and UDP-over-IPv6 didn't increase > the port number space. I know it's off-topic here, but anyone know why > they didn't? It surely must have been considered. It would not make much sense, between 2 hosts you can already have 65536*65536 possible connections*, which should be more than enough(tm) ;) I wonder if there are any hosts actually using more than 65536 connections at the same time. Greets, Jeroen * = Listening sockets of course limit this quite a bit, but even with 2 listening sockets, 40k*60k is still a lot. signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
imo this update is much needed - there has been considerable confusion about some of the processes in RFC 2434 and it would be good to clear up the confusion one specific area of confusion was what used to be called "IETF Consensus" - renaming it to "IETF Review" may help but I'm not sure I think there should be a IANA evaluation process that includes a required IETF-wide Last-Call and evaluatiopn of the results of that Last-Call by the IESG - the current text for "IETF Review" does not make a Last-Call manditory (this is seperate from IETF Standards action because it should not require a standards-track RFC - an info or exp RFC should be fine) it would be my suggestion to use a very specific term such as "IETF Last-Call & Consensus" for a process that includes the following requires a public document (not limited to IDs & RFCs) requires an IETF-wide Last-Call includes IESG evaluation of results of Last-Call IESG permitted to do own evaluation but if results differ from results of Last-Call then IESG has to specifically justify difference in public message to IETF list also concerning the "IESG Approval" process I'm fine with having such a process but considering the mess we have been going through I would like to add a step to the "IESG Approval" process if the IESG decides to turn down a request it must document the reason(s) for the reject in a message to the IETF list and run a Last-Call like request for opinions on the proposed IESG rejection - if the responses to the comment requested process clearly do not support the proposed IESG rejection the IESG must withdraw its proposed rejection. The IESG can publish a RFC listing its issues with the proposed use but can not block the assignment if the responses to the comment requested process do not clearly object to the proposed IESG rejection then the IESG recommendation for rejection can be forwarded to the IANA Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-klensin-iana-reg-policy-00.txt
At 17:23 14/07/2005, Brian E Carpenter wrote: Since we don't have a WG for this, the IETF list is the only place right now. Brian I would recommand a WG. This would permit to have a merge of the current propositions, to engage into more complex issues such as: - compatibility with externally defined elements (ex. ISO 3166 discussed in RFC 1591) - political disclaimer when a registry may be construed as a support for a political, commercial or technical vision. - experimentation - registry system architecture and generic registry solution - multilingual support in spite of the current state of the art technology limitations - harmonisation with ISO 11179, inter-registry relations - transition from namespace towards ASCII non dependent codespaces - distributed registries, relations with private or experimental/temporary registries, registries specialised restrictions - reporting on registries updates and corrections - registry managers committees selections - updates via Working Group RFCs etc. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A proposed experiment in narrative minutes of IESG meetings
On Thu, 14 Jul 2005 18:08:45 +0200 Simon Josefsson <[EMAIL PROTECTED]> wrote: > Brian E Carpenter <[EMAIL PROTECTED]> writes: > > > We propose that, for an initial period of 6 months, a member of > > the community will be added to regular IESG meetings as a "recording > > secretary" who will write narrative minutes of the discussions, > > which will be posted publicly after IESG review for accuracy. > > Sounds useful to me. How about actually recording the discussion too? > And publishing them as OGG or MP3. Editing out personnel discussion > would still be possible. All for the sake of transparency and > accountability. > My experience is that recordings tend to shut some people up. Plus, if they exist, they are subject to subpoena. > Regards, > Simon > Regards Marshall > ___ > 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: Test version of the Parking Area
>Is this (239-element) table sorted? I might suggest "sorted by ID name >within WG", but any sort would be a good thing to provide. It's sorted by document approval date. I'll point that out in the header and look into making other optional sorts available. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A proposed experiment in narrative minutes of IESG meetings
Brian, We propose that, for an initial period of 6 months, a member of the community will be added to regular IESG meetings as a "recording secretary" who will write narrative minutes of the discussions, which will be posted publicly after IESG review for accuracy. (As always, personnel discussions will need to remain private or be minuted with great care.) The IESG welcomes comments on this proposal, to iesg@ietf.org or ietf@ietf.org as appropriate. If the community seems to be in favour of this experiment, we will soon call for volunteers and pick one person to act for the initial six months. After six months, we will ask the community whether the results justify continuing the effort. The main question will be whether the community is getting useful extra information. I think this is an excellent idea! Please proceed with it. Thanks, Bob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A proposed experiment in narrative minutes of IESG meetings
"Marshall Eubanks" <[EMAIL PROTECTED]> writes: > On Thu, 14 Jul 2005 18:08:45 +0200 > Simon Josefsson <[EMAIL PROTECTED]> wrote: >> Brian E Carpenter <[EMAIL PROTECTED]> writes: >> >> > We propose that, for an initial period of 6 months, a member of >> > the community will be added to regular IESG meetings as a "recording >> > secretary" who will write narrative minutes of the discussions, >> > which will be posted publicly after IESG review for accuracy. >> >> Sounds useful to me. How about actually recording the discussion too? >> And publishing them as OGG or MP3. Editing out personnel discussion >> would still be possible. All for the sake of transparency and >> accountability. > > My experience is that recordings tend to shut some people up. My experience is that recordings tend to make people focus on facts, rather than trying to win a discussion or furthering their own agenda. If the IESG meetings are intended as service to the community, from experts, that seem to be a good thing. > Plus, if they exist, they are subject to subpoena. Is that a problem? Not purely a rhetorical question. Thanks, Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Seeking reviewers for language tag registry docs in WG last call
Hi - We are looking for reviewers for two ltru working group documents. Language tags are used in many applications and protocols, so we'd like to get as broad a review as practical of these: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-09.txt http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.txt The working group charter is at http://www.ietf.org/html.charters/ltru-charter.html The issue tracker we've been using is at https://rt.psg.com/ (user and password "ietf", all our queues start with the string "ltru-".) Comments should be posted to [EMAIL PROTECTED] If you're not a subscriber to that mailing list, there will be some delay while your posting is manually approved. The working group last call will conclude July 28. If you take the time to read either or both of these documents, but have no comments, we'd still like to hear from you, so we will have an idea of how many people have looked at the documents. Randy Presuhn, ltru co-chair ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A proposed experiment in narrative minutes of IESG meetings
I think that this is a great idea, Brian. Further insight into the decision making process of the IESG, I believe, will benefit everyone involved. On 7/14/05, Brian E Carpenter <[EMAIL PROTECTED]> wrote: > The IESG is interested in carrrying out an experiment to publish > narrative minutes for IESG meetings as well as the regular minutes > of decisions taken. > > Currently the IESG minutes are a formal record of decisions taken > and (like the agenda) are generated semi-automatically by the > secretariat. This is a well-oiled process that we don't want to > disturb. However, the community clearly would like more information > about the way the IESG reaches its decisions, beyond the record > of comments on each document that is stored in the I-D tracker. > > We propose that, for an initial period of 6 months, a member of > the community will be added to regular IESG meetings as a "recording > secretary" who will write narrative minutes of the discussions, > which will be posted publicly after IESG review for accuracy. > (As always, personnel discussions will need to remain private > or be minuted with great care.) > > The IESG welcomes comments on this proposal, to iesg@ietf.org > or ietf@ietf.org as appropriate. If the community seems to be > in favour of this experiment, we will soon call for volunteers > and pick one person to act for the initial six months. After > six months, we will ask the community whether the results > justify continuing the effort. The main question will be whether > the community is getting useful extra information. > > (Thanks to Spencer Dawkins for triggering this idea.) > > Brian for the IESG > > > > > > > ___ > 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
Recording discussion
> "Simon" == Simon Josefsson <[EMAIL PROTECTED]> writes: Simon> Brian E Carpenter <[EMAIL PROTECTED]> writes: >> We propose that, for an initial period of 6 months, a member of >> the community will be added to regular IESG meetings as a >> "recording secretary" who will write narrative minutes of the >> discussions, which will be posted publicly after IESG review >> for accuracy. Simon> Sounds useful to me. How about actually recording the Simon> discussion too? And publishing them as OGG or MP3. Simon> Editing out personnel discussion would still be possible. Simon> All for the sake of transparency and accountability. Simon> Regards, Simon I think doing this on a regular basis would be too time consuming to edit. However I think it would actually be useful to the community, to those considering serving on the IESG etc to record one telechat a year or so and edit out the confidential bits. I certainly know I had no idea what to expect when I called into my first telechat. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
would it be reasonable to just say that we are going to always last call IETF review documents? Personally I'd approve of this option unless people think it is too restrictive. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Recording discussion
Perhaps requiring less effort and being just as useful would be having volunteers dictate the written narrative minutes and make them available as OGG or MP3? On 7/14/05, Sam Hartman <[EMAIL PROTECTED]> wrote: > > "Simon" == Simon Josefsson <[EMAIL PROTECTED]> writes: > > Simon> Brian E Carpenter <[EMAIL PROTECTED]> writes: > >> We propose that, for an initial period of 6 months, a member of > >> the community will be added to regular IESG meetings as a > >> "recording secretary" who will write narrative minutes of the > >> discussions, which will be posted publicly after IESG review > >> for accuracy. > > Simon> Sounds useful to me. How about actually recording the > Simon> discussion too? And publishing them as OGG or MP3. > Simon> Editing out personnel discussion would still be possible. > Simon> All for the sake of transparency and accountability. > > Simon> Regards, Simon > I think doing this on a regular basis would be too time consuming to > edit. However I think it would actually be useful to the community, > to those considering serving on the IESG etc to record one telechat a > year or so and edit out the confidential bits. I certainly know I had > no idea what to expect when I called into my first telechat. > > --Sam > > > ___ > 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: Recording discussion
On 15-jul-2005, at 0:22, Steve Miller wrote: Perhaps requiring less effort and being just as useful would be having volunteers dictate the written narrative minutes and make them available as OGG or MP3? On 7/14/05, Sam Hartman <[EMAIL PROTECTED]> wrote: "Simon" == Simon Josefsson <[EMAIL PROTECTED]> writes: Simon> Brian E Carpenter <[EMAIL PROTECTED]> writes: We propose that, for an initial period of 6 months, a member of the community will be added to regular IESG meetings as a "recording secretary" who will write narrative minutes of the discussions, which will be posted publicly after IESG review for accuracy. Simon> Sounds useful to me. How about actually recording the Simon> discussion too? And publishing them as OGG or MP3. Simon> Editing out personnel discussion would still be possible. Simon> All for the sake of transparency and accountability. Simon> Regards, Simon I think doing this on a regular basis would be too time consuming to edit. However I think it would actually be useful to the community, to those considering serving on the IESG etc to record one telechat a year or so and edit out the confidential bits. I certainly know I had no idea what to expect when I called into my first telechat. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf You can't do a text search on MP3s, listening is slower than reading and language issues tend to be tougher with spoken language than they are with written language. An advantage would be that spoken language conveys sarcasm better. :-) And that people don't end their point by repeating everything the previous speaker said. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Recording discussion
Iljitsch van Beijnum <[EMAIL PROTECTED]> writes: > You can't do a text search on MP3s, listening is slower than reading > and language issues tend to be tougher with spoken language than they > are with written language. Making audio recording available doesn't prevent also having a written version of the same discussion. Perhaps I didn't say it, but I believe narrative minutes of IESG meetings was a splendid idea. Thanks, Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Recording discussion
> "Steve" == Steve Miller <[EMAIL PROTECTED]> writes: Steve> Perhaps requiring less effort and being just as useful Steve> would be having volunteers dictate the written narrative Steve> minutes and make them available as OGG or MP3? I don't think this would be just as useful. I think there's a lot you can get out of an actual recording of a call you cannot get from IETF-style minutes. I'm particularly thinking of issues of style and flow--issues necessary to understand a culture and organization but not to understand specific decisions. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Seeking reviewers for language tag registry docs in WG last call
I am glad Randy Preshun now joins my call for additional expertise. This Draft is particular: due to its political, cultural and commercial implications, and their possible impact on the IETF, what is to be considered is probably more what is not in the Draft than the technical constraints introduced by the Draft, where I consider that we should simplify. A first list of questions is under http://rfc3066.org/review.htm. Readers should also address these questions. They are important enough to be considered carefully, with an open mind. IMHO they call for a dedicated document providing a clear, stable, politically protected IETF framework. jfc At 22:57 14/07/2005, Randy Presuhn wrote: Hi - We are looking for reviewers for two ltru working group documents. Language tags are used in many applications and protocols, so we'd like to get as broad a review as practical of these: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-09.txt http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.txt The working group charter is at http://www.ietf.org/html.charters/ltru-charter.html The issue tracker we've been using is at https://rt.psg.com/ (user and password "ietf", all our queues start with the string "ltru-".) Comments should be posted to [EMAIL PROTECTED] If you're not a subscriber to that mailing list, there will be some delay while your posting is manually approved. The working group last call will conclude July 28. If you take the time to read either or both of these documents, but have no comments, we'd still like to hear from you, so we will have an idea of how many people have looked at the documents. Randy Presuhn, ltru co-chair ___ 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: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
works for me (assuming that you include non-IETF documents when you say "IETF review documents") Scott >From [EMAIL PROTECTED] Thu Jul 14 18:12:46 2005 X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] (Scott Bradner) Cc: ietf@ietf.org Subject: Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt References: <[EMAIL PROTECTED]> From: Sam Hartman <[EMAIL PROTECTED]> Date: Thu, 14 Jul 2005 18:12:40 -0400 In-Reply-To: <[EMAIL PROTECTED]> (Scott Bradner's message of "Thu, 14 Jul 2005 12:52:38 -0400 (EDT)") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii would it be reasonable to just say that we are going to always last call IETF review documents? Personally I'd approve of this option unless people think it is too restrictive. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)
Scott Bradner wrote: I was surprised that TCP-over-IPv6 and UDP-over-IPv6 didn't increase the port number space. I know it's off-topic here, but anyone know why they didn't? It surely must have been considered. That was considered to be part of TCPng, and as best I recall was explicitly out of scope. correct I was looking more for an explanation of how and why it was decided to be out of scope. The arguments for considering it to be in scope would have been: - the TCP and UDP "pseudo-headers" needed to be changed anyway to accomodate IPv6 addresses (see section 8.1 of RFC 2460); - the pressure on well-known port numbers was obvious at the time; - supporting 32-bit port numbers in IPv6 stacks could have been done at very little incremental cost; - a larger port space would have been an additional incentive to adopt IPv6; - more ambitious changes to TCP would have a low probability of adoption within a relevant timeframe; - it makes sense for the port number space to be the same size for UDP-over-IPv6 and TCP-over-IPv6. Jeroen Massar wrote: It would not make much sense, between 2 hosts you can already have 65536*65536 possible connections*, which should be more than enough(tm) ;) Not for connections to a well-known port. -- David Hopwood <[EMAIL PROTECTED]> ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Seeking reviewers for language tag registry docs in WG last call
Hi - > From: "JFC (Jefsey) Morfin" <[EMAIL PROTECTED]> > To: "Randy Presuhn" <[EMAIL PROTECTED]>; > Cc: <[EMAIL PROTECTED]> > Sent: Thursday, July 14, 2005 4:54 PM > Subject: Re: Seeking reviewers for language tag registry docs in WG last call > > I am glad Randy Preshun now joins my call for additional expertise. This > Draft is particular: due to its political, cultural and commercial > implications, and their possible impact on the IETF, what is to be > considered is probably more what is not in the Draft than the technical > constraints introduced by the Draft, where I consider that we should simplify. > > A first list of questions is under http://rfc3066.org/review.htm. Readers > should also address these questions. They are important enough to be > considered carefully, with an open mind. IMHO they call for a dedicated > document providing a clear, stable, politically protected IETF framework. > jfc ... Please do not be misled by the domain name of http://rfc3066.org/review.htm That site is not affiliated with the ltru WG or the [EMAIL PROTECTED] mailing list that performs the language tag review function described in RFC 3066. I think prospective reviewers' time would be much better spent looking at the actual documents under WG last call, rather than trying to make sense of the stuff at http://rfc3066.org/review.htm The documents under WG last call are http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-09.txt http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.txt We'd prefer to have your comments on the documents themselves, rather than reactions to Jefsey's sometimes over-heated polemic. Randy, ltru co-chair ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)
> > I was surprised that TCP-over-IPv6 and UDP-over-IPv6 didn't increase > > the port number space. I know it's off-topic here, but anyone know why > > they didn't? It surely must have been considered. > It would not make much sense, between 2 hosts you can already have > 65536*65536 possible connections*, which should be more than > enough(tm) ;) I wonder if there are any hosts actually using more than > 65536 connections at the same time. True enough, however, you can only have 65536 connections to a single service on a given port. I can assure you that this is a problem for real-world applications in some cases, so yes, there are such users. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A proposed experiment in narrative minutes of IESG meetings
Marshall Eubanks wrote (talking about recording IESG meetings): My experience is that recordings tend to shut some people up... Jumping in with both feet here: I have never been to an IETF or IESG meeting, but I have seen countless examples of this. Marshall is correct. On the other hand, I have found it to be a pretty firm rule that the things that don't get said are things that shouldn't have been said in the first place. In other words, the speakers at these meetings are _already_ aware that they are publicly speaking and making decisions as representatives of a group. If someone in such a position is only willing to say something if he (she) knows he'll never get called on his words, then his words don't have much value anyway. (I spent 20 years in the military. The most direct way to find out if a superior will admit later having given a particular order, is to ask for it in writing with signature. You are bluntly telling him -in front of all whithin hearing- that you don't trust him to take responsibility if there's no evidence. If the superior refuses, then you -and everyone in hearing- know you were right to challenge him; he'll claim Alzheimer's later.) Directed towards the IESG: Recording meetings, and publishing those recordings, may be a hassle, but it answers all questions about the integrity of the decision-making process. There may still be questions about knowledge and wisdom, but you put to rest all questions about integrity. Refusing to record (for whatever reason*), after having been asked (for whatever reason) by the people you represent, says something rather different. * Perhaps the disk space required is too expensive? > ...Plus, if they exist, they are subject to subpoena. I don't understand this comment. How is this bad? Again, these are our public representatives, chosen for their knowledge, experience, and integrity. How can the possibility of being held to their words possibly be bad? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Meeting Locations
How far in advance are the locations of IETF meetings determined? Is there any way to find out what the possible candidates are? I'm having to budget travel for the next year, and knowing where IETF 65 will be held would help me a lot. -- Clint (JOATMON) Chaplin Wireless Security Technologist Wireless Standards Manager ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Seeking reviewers for language tag registry docs in WG last call
On 02:45 15/07/2005, Randy Presuhn said: Please do not be misled by the domain name of http://rfc3066.org/review.htm That site is not affiliated with the ltru WG or the [EMAIL PROTECTED] mailing list that performs the language tag review function described in RFC 3066. This is right. There are two doctrines. - an exclusive one: to have a new RFC restricting the possibilities of RFC 3066 in term of language support - an inclusive one: to keep RFC 3066 as a flexible base for innovation, and to accep the Draft in parallel I think prospective reviewers' time would be much better spent looking at the actual documents under WG last call, rather than trying to make sense of the stuff at http://rfc3066.org/review.htm The "stuff" concerns considerations on IETF/ISO/UN relative authoritativeness, standard disclaimer on political aspects inovlved in multilingualism, compatibility between the IANA structure and ISO Registry standards, need of retro-compatibility with new propositions, etc. During a WGLC all the last-call issues must be addressed by the WG. This is for me the only way to clarify these points while waiting the WG Charter to be analysed. The documents under WG last call are http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-09.txt http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.txt We'd prefer to have your comments on the documents themselves, rather than reactions to Jefsey's sometimes over-heated polemic. ??? the question is to know if the general points _not_ mentionned into the Draft should be added to it, or belong to a separate Framework document? Very dull and practical. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meeting Locations
Clint I hope you get an answer to this! At 07:41 PM 7/14/2005 -0700, Clint Chaplin wrote: How far in advance are the locations of IETF meetings determined? Is there any way to find out what the possible candidates are? I'm having to budget travel for the next year, and knowing where IETF 65 will be held would help me a lot. -- Clint (JOATMON) Chaplin Wireless Security Technologist Wireless Standards Manager ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meeting Locations
Anyone want to bet on Minneapolis - Its March after all. Actually I am starting to grow fond of the hotel there. Bill > Clint > > I hope you get an answer to this! > > At 07:41 PM 7/14/2005 -0700, Clint Chaplin wrote: >>How far in advance are the locations of IETF meetings determined? Is >>there any way to find out what the possible candidates are? >> >>I'm having to budget travel for the next year, and knowing where IETF >>65 will be held would help me a lot. >>-- >>Clint (JOATMON) Chaplin >>Wireless Security Technologist >>Wireless Standards Manager >> >>___ >>Ietf mailing list >>Ietf@ietf.org >>https://www1.ietf.org/mailman/listinfo/ietf > > > cheers, > James > > *** > Truth is not to be argued... it is to be presented. > > ___ > 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: A proposed experiment in narrative minutes of IESG meetings
On Thursday, July 14, 2005 10:37:00 AM -0700 Bob Hinden <[EMAIL PROTECTED]> wrote: Brian, We propose that, for an initial period of 6 months, a member of the community will be added to regular IESG meetings as a "recording secretary" who will write narrative minutes of the discussions, which will be posted publicly after IESG review for accuracy. (As always, personnel discussions will need to remain private or be minuted with great care.) The IESG welcomes comments on this proposal, to iesg@ietf.org or ietf@ietf.org as appropriate. If the community seems to be in favour of this experiment, we will soon call for volunteers and pick one person to act for the initial six months. After six months, we will ask the community whether the results justify continuing the effort. The main question will be whether the community is getting useful extra information. I think this is an excellent idea! Please proceed with it. Agree ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meeting Locations
On Thursday, July 14, 2005 08:50:16 PM -0700 [EMAIL PROTECTED] wrote: Anyone want to bet on Minneapolis - Its March after all. Sounds good to me. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A proposed experiment in narrative minutes of IESG meetings
On Thu, 14 Jul 2005 21:33:05 -0400 Sandy Wills <[EMAIL PROTECTED]> wrote: > Marshall Eubanks wrote (talking about recording IESG meetings): > > > > My experience is that recordings tend to shut some people up... > > > > Jumping in with both feet here: > >I have never been to an IETF or IESG meeting, but I have seen > countless examples of this. Marshall is correct. >On the other hand, I have found it to be a pretty firm rule that the > things that don't get said are things that shouldn't have been said in > the first place. >In other words, the speakers at these meetings are _already_ aware > that they are publicly speaking and making decisions as representatives > of a group. If someone in such a position is only willing to say > something if he (she) knows he'll never get called on his words, then > his words don't have much value anyway. > But my understanding is that IESG meetings are not open, so they are not speaking publicly now. This gets back to the ability to subpoena such recordings. If sensitive issues are going to be discussed, then in practice they can't be recorded, since you can't really be sure what will happen to the recordings. (The person doing the recording could be met by a process server as he or she sits down to edit them, for example.) So,in practice, either the IESG will have to have all meetings be open, or have some meetings or parts of meetings not recorded. My experience with corporate boards makes me suspect that in the latter case a two tier meeting structure might evolve, with the real business being conducted in "executive session." I am neutral about the recording issue; I am just trying to point out some implications. Regards Marshall > (I spent 20 years in the military. The most direct way to find out if a > superior will admit later having given a particular order, is to ask for > it in writing with signature. You are bluntly telling him -in front of > all whithin hearing- that you don't trust him to take responsibility if > there's no evidence. If the superior refuses, then you -and everyone in > hearing- know you were right to challenge him; he'll claim Alzheimer's > later.) > > Directed towards the IESG: > Recording meetings, and publishing those recordings, may be a > hassle, but it answers all questions about the integrity of the > decision-making process. There may still be questions about knowledge > and wisdom, but you put to rest all questions about integrity. Refusing > to record (for whatever reason*), after having been asked (for whatever > reason) by the people you represent, says something rather different. > > > * Perhaps the disk space required is too expensive? > > > > ...Plus, if they exist, they are subject to subpoena. > > I don't understand this comment. How is this bad? Again, these are our > public representatives, chosen for their knowledge, experience, and > integrity. How can the possibility of being held to their words > possibly be bad? > > > ___ > 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
Another problem of registration page for social event
Folks, I did the registration for the social event. For online payment, then, I followed the link of 'Click here to update your registration' and enter my booking number and my family name. However, I've got a page with another person's infomation. Moreover, I could not terminate the confirmation session. Does anyone get the same problem? Sincerely yours, Kenji Ohira ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Recording discussion
Iljitsch van Beijnum wrote: You can't do a text search on MP3s, listening is slower than reading and language issues tend to be tougher with spoken language than they are with written language. An advantage would be that spoken language conveys sarcasm better. :-) And that people don't end their point by repeating everything the previous speaker said. I like textual minutes better, too. Brian's suggestion seems good to me. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
