Re: [lisp] Last Call: (LISP EID Block) to Informational RFC

Date:Thu, 22 Nov 2012 16:50:40 +1100 From:Geoff Huston Message-ID: <08fcd406-f556-4f7e-ba98-9591d161a...@apnic.net> | With respect Robert, I disagree with your line of argument and I disagree | with your assertion that a reference to an existing RFC is "bogus unde

Re: [lisp] Last Call: (LISP EID Block) to Informational RFC

Date:Wed, 21 Nov 2012 17:16:58 +1100 From:Geoff Huston Message-ID: <99b9866c-41d6-4784-aa69-cd25e5910...@apnic.net> I have no idea whether the allocation requested is reasonable or not, I haven't read the draft (and unless it becomes more widely used than currently, m

Re: [IETF] Re: Consensus Call: draft-weil-shared-transition-space-request

Date:Fri, 2 Dec 2011 15:20:34 -0800 From:Ted Hardie Message-ID: | Big enterprises buy small ones; sometimes at a great rate. And this itself is a good argument that 1918 space is sufficient (one way or another), not the reverse. What you have there is two 1918

Re: Consensus Call: draft-weil-shared-transition-space-request

Date:Thu, 01 Dec 2011 23:08:51 -0800 From:Doug Barton Message-ID: <4ed87983.4090...@dougbarton.us> | Step 3: If your customer has somehow chosen the same prefix, tell them | they can't do that. Another alternative there is for the ISP to simply pick a different p

Re: Consensus Call: draft-weil-shared-transition-space-request

Date:Tue, 29 Nov 2011 21:09:22 -0700 From:Sumanth Channabasappa Message-ID: <76AC5FEF83F1E64491446437EA81A61F81D7CBBA11@srvxchg> This whole question is weird, when someone needs an address to use, and given that the pool of free (or close to it), that is, easily avail

Re: Last Call: Policy Statement on the Day Pass Experiment

One final message from me on this topic, then I'm done ... Date:Mon, 17 May 2010 08:10:01 +0200 From:Eliot Lear Message-ID: <4bf0ddb9.60...@cisco.com> | but I do accept that they have the authority to make such a statement, | if rough consensus could have been s

Re: Last Call: Policy Statement on the Day Pass Experiment

Date:Mon, 10 May 2010 21:29:30 -0400 From:Donald Eastlake Message-ID: | It's fine if you think the qualification threshold should be a bit | lower than what I think. But to change it, there should be a real WG | process. The criteria is that for 3 out of the la

Re: Last Call: Policy Statement on the Day Pass Experiment

Date:Mon, 10 May 2010 16:25:12 -0400 From:Russ Housley Message-ID: <4be86ba8.2060...@vigilsec.com> | From the discussion at the plenary, it was clear to me that some people | expected the purchase of a day pass to count as participating in that | IETF meeting, a

Re: Last Call: Policy Statement on the Day Pass Experiment

Date:Mon, 10 May 2010 12:05:07 -0400 From:Donald Eastlake Message-ID: Mostly (these days) I prefer to make one comment, then keep quiet, but this message from Donald needs a response... | So, with such disagreements, someone has to settle it even if there | isn'

Re: Last Call: Policy Statement on the Day Pass Experiment

Date:Thu, 06 May 2010 18:07:40 -0400 From:The IESG Message-ID: <4be33dac.80...@ietf.org> | The IESG is considering the following Statement on the Day Pass | Experiment. The IESG plans to make a decision in the next few weeks on | a policy statement, and the IES

Re: WG Review: Internet Wideband Audio Codec (codec)

Date:Thu, 24 Dec 2009 08:50:30 +0200 From:"Roni Even" Message-ID: <4b33100a.01135e0a.2ab9.8...@mx.google.com> | I am not sure but are you suggesting that the IETF will define the | requirements, metric and quality assessment requirements and all proposed | c

Re: WG Review: Internet Wideband Audio Codec (codec)

Date:Wed, 23 Dec 2009 21:48:18 +0200 From:"Tschofenig, Hannes (NSN - FI/Espoo)" Message-ID: <3d3c75174cb95f42ad6bcc56eb450204c...@fiesexc015.nsn-intra.net> | That's something for the working group to figure out. | My experience: things are typically more co

Re: WG Review: Internet Wideband Audio Codec (codec)

Date:Wed, 23 Dec 2009 09:15:01 -0800 (PST) From:IESG Secretary Message-ID: <20091223171501.7bae33a6...@core3.amsl.com> Given ... | There exist codecs that can be widely implemented and easily | distributed, but that are not standardized through any SDO; according

Re: silly legal boilerplate, was Regarding RIM's recent IPR disclosures

Date:23 Nov 2009 10:54:09 -0500 From:"John R. Levine" Message-ID: | You must know different CEOs and lawyers than I do. The CEO's secretary | will send it to the lawyer, and the lawyer will say "yes, that's what I | told them to do", You mean, to give away

Re: silly legal boilerplate, was Regarding RIM's recent IPR disclosures

Date:20 Nov 2009 05:36:18 - From:John Levine Message-ID: <20091120053618.8729.qm...@simone.iecc.com> | But I have often been sorely tempted to return messages like this with | boilerplate of my own explaining that since I cannot accept the | sender's alleged

Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt

Date:Fri, 09 Oct 2009 14:16:37 -0400 From:Russ Housley Message-ID: <20091009181642.626a8f24...@odin.smetech.net> | You have the motivations for rfc3932bis completely confused. The | IESG is not the source for the proposed changes to RFC 3932. RFC | 3932 as i

Re: Request for community guidance on issue concerning a future meeting of the IETF

Date:Fri, 18 Sep 2009 14:29:44 -0700 (PDT) From:Ole Jacobsen Message-ID: | Whether or not we should meet in China based on principles of | free speech and such is, I think, something we need to come to | at least a rough consensus on. Actually, no, we don't, a

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

Date:Wed, 9 Sep 2009 09:53:42 -0400 From:"Polk, William T." Message-ID: | IMHO, the RFC series (as comprised by the four document streams) is not | similar to IEEE Transactions on Networking or the NY Times. I am not sure | that there is really a close analog

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

Date:Wed, 09 Sep 2009 07:17:50 -0400 From:Sam Hartman Message-ID: | Right; I think I made it fairly clear in my reply to John Klensin that | I disagreed fairly strongly with that and argued why I believed that | the IETF needs a special role to attach a note to

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

Date:Tue, 01 Sep 2009 16:37:31 +0300 From:Jari Arkko Message-ID: <4a9d239b.7070...@piuha.net> | Right, and we are not. That is very good to hear. I haven't been watching much of recent IETF happenings (last few years) so I explicitly make no comment about anythin

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

Date:Mon, 31 Aug 2009 16:29:26 +0300 From:Jari Arkko Message-ID: <4a9bd036.1000...@piuha.net> | And now back to the input that I wanted to hear. I would like to get a | sense from the list whether you prefer (a) that any exceptional IESG | note is just a recom

Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

Date:Wed, 22 Jul 2009 08:32:38 +0200 From:Harald Alvestrand Message-ID: <4a66b286.9080...@alvestrand.no> I don't want to say much more on this issue, I suspect enough has been said now, but just one final (from me) point ... | The working group's non-consensus on t

Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

Date:Tue, 21 Jul 2009 18:40:52 +0200 From:Harald Alvestrand Message-ID: <4a65ef94.2050...@alvestrand.no> | I'm afraid that your perception disagrees with the structure that RFC | 5378 set up. I was misunderstanding what's going on, Joel has been educating me off

Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

Date:Tue, 21 Jul 2009 08:57:01 +0200 From:Harald Alvestrand Message-ID: <4a6566bd.1080...@alvestrand.no> | We have two possibilities: | | 1 - the update consists of revisions of *every single RFC* that | references the BSD license | 2 - some RFCs continue

Re: Last Call: draft-dawkins-nomcom-dont-wait (Nominating CommitteeProcess: Earlier Announcement of Open Positions and Solicitation ofVolunteers) to BCP

To simplify the text, and make things a little simpler, I suggest inventing a new name for the "thing" that acts as nomcom chair has in the past, but which can act before the nomcom chair is appointed. Say, that was to be called "convenor" - then the doc would define that position The Con

Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

In other organisations, when I see (what has been called here), an "over the wall" list of changes, I usually expect, and usually receive, in addition to the list of changes (along with what used to be there) all of which exists here, some kind of explanation why the changes are being proposed. Th

Re: WG Review: Low Extra Delay Background Transport (ledbat)

Date:Fri, 31 Oct 2008 13:24:39 +0200 From:Lars Eggert <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | > The first bullet says "deal with the world as it is"; the second | > says "deal with the world as you wish it were" | > | > I think that is a very se

Re: WG Review: Low Extra Delay Background Transport (ledbat)

Date:Thu, 30 Oct 2008 15:02:30 -0700 (PDT) From:IESG Secretary <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> This looks like useful work to do, and to me, the charter mostly looks fine, just one point. The (proposed) charter says ... | * operate well in netwo

Re: Call for review of proposed update to ID-Checklist

Date:Wed, 13 Aug 2008 13:13:46 -0500 From:"Spencer Dawkins" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | I'm actually OK with the process that Dave is not OK with, because I'm | assuming that "public vetting" can also be retroactive - as long as the |

Re: Last Call: draft-manner-router-alert-iana (IANA Considerations for the IPv4 and IPv6 Router Alert Option) to Proposed Standard

Date:Wed, 9 Jul 2008 09:41:03 -0700 (PDT) From:The IESG <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | The IESG has received a request from an individual submitter to consider | the following document: | | - 'IANA Considerations for the IPv4 and IPv6 R

Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

Date:Thu, 19 Jun 2008 22:32:59 +0200 From:Eliot Lear <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Isn't the IESG is meant to serve two roles? Yes, but not the two you enumerated. The first, and far and away most important, is to cause the work to get done

Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

Date:Wed, 18 Jun 2008 20:35:54 +0200 From:"Frank Ellermann" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Figuring out what the "demonstrated will of the IETF" is | is the job of the IESG, Agreed, that is part of their role. | and in the case of an indi

Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

Date:Wed, 18 Jun 2008 12:02:44 +0100 From:"Debbie Garside" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | I see your point. I doubt that you do. | I do think, assuming it is not already documented and | further assuming this is the whole point of the app

Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

Date:Tue, 17 Jun 2008 15:50:02 +0100 From:"Debbie Garside" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | I would also add that to go against an IETF BCP Huh? The BCP in question says (in a bit more eloquent form) "Here are some domain names that are reserv

Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

Date:Mon, 16 Jun 2008 13:23:28 +1200 From:Brian E Carpenter <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Which, in fairness, the IESG has documented, in the DISCUSS criteria | document and generally in practice, over the last several years. The IESG is f

Re: Should the RFC Editor publish an RFC in less than 2 months?

Date:Tue, 04 Dec 2007 09:04:38 +1300 From:Brian E Carpenter <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | It's the instant of formal publication, and that changes at least | two things: | | 1. It allows other SDOs that require a normative citation to p

Re: Should the RFC Editor publish an RFC in less than 2 months?

Date:Sun, 2 Dec 2007 17:34:14 -0800 From:"Hallam-Baker, Phillip" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Only issue I would raise here is don't expire the ID if this situation | arises... That did not really need to be said - once submitted for IESG

Re: Comments on draft-aboba-sg-experiment-02

Date:Mon, 08 Oct 2007 15:29:48 +0200 From:Eliot Lear <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | We are overlapping a term that is | commonly used by the ITU the way working group is used by the IETF. | Let's not make the process any more confusing tha

Re: Role of IANA in approving assignments

Date:Fri, 15 Jun 2007 09:28:29 -0400 From:Thomas Narten <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Um, this train left the station a LONG time ago. RFC 2434 (and | existing practice) have given the role of approving assignments to the | technical/proto

Re: Withdrawing sponsorship of draft-housley-tls-authz-extns

Date:Thu, 14 Jun 2007 17:08:13 -0700 From:Thomas Narten <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | (Now would be an excellent time to | consider updates/clarifications to the above text.) Aside from the minor problem that the paragraph you quoted is way

Re: Last Call: 'Progressive Posting Rights Supsensions' to BCP (draft-carpenter-rescind-3683)

Date:Wed, 25 Oct 2006 22:50:06 +0200 From:Brian E Carpenter <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | The draft (ignoring 3683) restores 2418 and adds the extra powers | created by 3934. I'm sure that's what you're intending, and it may even be that t

Re: Last Call: 'Progressive Posting Rights Supsensions' to BCP (draft-carpenter-rescind-3683)

Date:Wed, 25 Oct 2006 12:42:38 +0200 From:Brian E Carpenter <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | | > | 1) Do you support the proposal in section 2 of the draft to restore | > | the AD and IESG's ability to suspend posting rights for longer t

Re: Last Call: 'Progressive Posting Rights Supsensions' to BCP (draft-carpenter-rescind-3683)

Date:Fri, 20 Oct 2006 18:29:37 -0400 From:The IESG <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> I guess I should reply to the questions... | 1) Do you support the proposal in section 2 of the draft to restore | the AD and IESG's ability to suspend posting r

Re: Last Call: 'Progressive Posting Rights Supsensions' to BCP (draft-carpenter-rescind-3683)

Date:Mon, 23 Oct 2006 17:46:47 +0200 From:Brian E Carpenter <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Actually, this document doesn't *need* to contain any rationale. | The question is whether the community agrees. It doesn't say the IESG; | it uses t

Re: RFC Editor RFP Review Request

Date:Wed, 19 Jul 2006 03:06:10 +0200 From:Henrik Levkowetz <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Ok. So I'm not sure what you propose here - should we not require | rsync and ftp mirroring capability, or should we ask for it, and not | specify ch

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

Date:Sat, 17 Jun 2006 21:40:06 -0700 From:Joe Touch <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | That's a problem when it changes page numbers (which end up being as | useful as semantic tags) or figures. Or (as importantly) template or | boilerplate tex

Re: Last Call: 'Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations' to Proposed Standard

I cannot see why there's a debate going on here. If someone, anyone, can read a spec, and, in good faith, point out a possible ambiguity in the text, before the doc is finalised, and if fixing it to avoid the problem is easy, what possible justification can there be for not adding a few words to

Re: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

Date:Mon, 26 Sep 2005 15:41:56 -0400 (EDT) From:Dean Anderson <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | It is not DNSSEC that is broken. I have not been following dnsop discussions, but from this summary, there is nothing broken beyond your understanding

Re: Summary of the LLMNR Last Call

Date:Sun, 18 Sep 2005 10:09:07 -0400 From:Margaret Wasserman <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> I am not going to comment on the substance of the issues, or the doc in question, as I haven't been following what is happening with it, nor have a read a r

Re: RFC 2434 term "IESG approval"

Date:Thu, 7 Jul 2005 22:25:18 -0700 (PDT) From:"C. M. Heard" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Would it be unreasonable to ask that you point to some text in the | document to support your claim? Or lacking that, to point to some | publically

Re: S stands for Steering [Re: Should the IESG rule or not?]

Date:Tue, 05 Jul 2005 11:32:12 +0200 From:Brian E Carpenter <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | > Also remember that "no consensus" in an issue like this, really needs to | > mean "no authority" - if you cannot get at least most of the community t

Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment ofan IPV6 Hop-by-hop Option)

Date:Wed, 06 Jul 2005 17:28:28 +0200 From:Brian E Carpenter <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Well, that is not how I read the text in RFC 2460. It's pretty clear | to me that there are only 32 option codes and that the other three bits | don'

Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment ofan IPV6 Hop-by-hop Option)

Date:Tue, 5 Jul 2005 00:58:36 -0700 From:"Christian Huitema" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | The problem is the really small size of the option type field in IPv6. | There really only are 5 bits available for numbering both the hop by hop |

Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)

Date:Fri, 1 Jul 2005 15:16:09 -0400 From:Margaret Wasserman <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | In what way would that differ from "Specification Required"? See below. | No. That one ("Specification Required") explicitly states that the | do

Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)

Date:Fri, 1 Jul 2005 11:39:05 -0400 From:Margaret Wasserman <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | You seem to be arguing that the only thing that the IESG _should_ | have done regarding this allocation was to determine whether or not a | documen

Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IP

Date:Fri, 1 Jul 2005 11:24:42 -0400 From:"Theodore Ts'o" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | So if someone documented a code point in a registry with a scares | number of available code points which was actively harmful to the | entire infrastru

Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IP

Date:Fri, 01 Jul 2005 16:14:54 +0200 From:Harald Tveit Alvestrand <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | I don't agree, which is no surprise. Not really! | RFC 2434 also says (section 2): | |One way to insure community review of prospectiv

Re: draft-klensin-iana-reg-policy (Re: S stands for Steering)

Date:Fri, 1 Jul 2005 06:07:38 -0700 (PDT) From:Keith McCloghrie <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | On the contrary, having vendor OID space has been a tremendous success. OK, I didn't mean what I said in the way you clearly interpreted it. I abso

Re: I-D ACTION:draft-iesg-media-type-00.txt

Date:Fri, 01 Jul 2005 17:38:19 +0200 From:Magnus Westerlund <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> I understand everything you're saying, except this part... | I do want to point out that how we RTP uses the top-part of the media | type name. They ar

Re: I-D ACTION:draft-iesg-media-type-00.txt

Date:Fri, 1 Jul 2005 16:35:53 +0100 From:Colin Perkins <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | You're misunderstanding what is being done. Thanks for the explanations, that helps. | The question becomes: will the leakage go away if we separate the

Re: I-D ACTION:draft-iesg-media-type-00.txt

Date:Fri, 1 Jul 2005 12:57:15 +0100 From:Colin Perkins <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | I do not find this argument persuasive, since the media types in | question have been deliberately specified as framed types to avoid | this issue. I

Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IP

Date:Fri, 01 Jul 2005 12:26:31 +0200 From:Harald Tveit Alvestrand <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | So we've got two possible interpretations: | | - The authors and the community that let this be published thought that | there were some ca

Re: draft-klensin-iana-reg-policy (Re: S stands for Steering)

Date:Fri, 01 Jul 2005 11:32:41 +0200 From:Harald Tveit Alvestrand <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> I have yet to read John's draft, but there's one comment that you made that I want to comment on. | Summary: I think the document offers very good a

Re: Should the IESG manage or not?

Date:Thu, 30 Jun 2005 21:12:07 -0400 From:Jeffrey Hutzelman <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Note that I would consider it entirely reasonable for the IESG to say that | something "conflicts with work in the IETF" on the grounds that its |

Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)

Date:Thu, 30 Jun 2005 18:50:01 -0400 From:Jeffrey Hutzelman <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Have you read the spec in question? I have not, and I expressly will not, because that cannot possibly be relevant. | The issue is not that the prese

Re: S stands for Steering [Re: Should the IESG rule or not?]

Apologies for missing the second 't' in your name in the message I sent to the list - I must have been asleep... kre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf

Re: S stands for Steering [Re: Should the IESG rule or not?]

Date:Fri, 1 Jul 2005 09:36:30 +0300 (EEST) From:Pekka Savola <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | though I can understand the arguments why | documenting the proposed use could be useful. I believe it is documented (though I haven't read the docu

Re: S stands for Steering [Re: Should the IESG rule or not?]

Date:Fri, 01 Jul 2005 14:11:47 +0800 From:Scott W Brim Message-ID: <[EMAIL PROTECTED]> Scot, | Something like this must have a serious, long-term IETF review. | We need to take the overall design of the Internet into | account and not just be administrators. H

Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)

Date:Wed, 29 Jun 2005 17:39:37 -0400 From:Margaret Wasserman <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | The arguments against what the IESG has done seem, | mostly, to be that we should have gotten IETF consensus before | making a decision. That is

Re: Should the IESG manage or not?

Date:Thu, 30 Jun 2005 17:21:10 -0400 From:Sam Hartman <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | The RFc 2780 procedures are a sparse. We'd all be happier if the | community had given us more advice on what criteria to use when | evaluating hop-by-ho

Re: S stands for Steering [Re: Should the IESG rule or not?]

Date:Fri, 01 Jul 2005 03:25:25 +0200 From:Brian E Carpenter <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | As I said in the plenary in Minneapolis, my goal is for the IESG to be | able to *steer*. Not to rule. Steering means finding the narrow line | betwe

Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

Date:Tue, 28 Jun 2005 23:21:35 +0200 From:Eliot Lear <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Not publicly. Certainly there was a problem. Indeed someone (I forget | who) had made a request for a /8, which forced the issue. At the time 1597 was bei

Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

Date:Tue, 28 Jun 2005 20:13:20 +0200 From:Eliot Lear <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Let's look at an analogy that worked just as you suggest: the assignment | of 10/8 172.16/16 and 192.168/16 in RFC 1597. They'e not options. There's no qu

Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

Date:Tue, 28 Jun 2005 00:16:56 +0200 From:Brian E Carpenter <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Yakov Rekhter wrote: | > What was the reason(s) the request was made for an assignment | > that required IESG Approval, rather than either Specificat

Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

Date:Tue, 28 Jun 2005 10:23:47 -0400 From:Bill Sommerfeld <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | assigning a "final" IPv6 option codepoint might actually be | counterproductive (as early behavior might be cast in code, concrete, or | silicon and fo

Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

Date:Mon, 27 Jun 2005 13:28:24 -0400 From:Thomas Narten <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | What 2434 says about "IESG approval" is: | | > IESG Approval - New assignments must be approved by the IESG, but | >there is no requ

Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

Date:Mon, 27 Jun 2005 09:26:46 -0700 From:Barbara Roseman <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | To address some misunderstandings of IANA's role in this action, [...] I hadn't actually noted any. As best I can recall, there neither has been, nor sh

Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

Date:Mon, 27 Jun 2005 17:00:22 +0200 From:Brian E Carpenter <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | The debate (except that since the work hadn't been brought to the IETF, | the debate hasn't happened) Except that it has been reported that the work w

Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

Date:Sat, 25 Jun 2005 10:25:24 -0700 From:Bob Hinden <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | There are IPv6 option types available, but this was a request for an IPv6 | hop-by-hop option. I had always assumed that the option space for HBH and Dest-O

Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

Date:Fri, 24 Jun 2005 18:07:15 -0400 From:Sam Hartman <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | What you seme to be saying is that you would be happy if we told | Dr. Roberts to ask for review knowing full well that such a review | would be long, comp

Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

Date:Fri, 24 Jun 2005 13:08:25 -0400 From:Thomas Narten <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | The clear intention of the above is that assignments for HBH code | points be conditioned on IETF review (and approval). I'd actually say it was more requ

Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

Date:Wed, 22 Jun 2005 11:12:53 -0400 From:IESG Message-ID: <[EMAIL PROTECTED]> | The IESG declines Dr. Roberts's request for a hop-by-hop option for | QOS purposes. I have no idea whether the option is actually any good or not, nor whether it should be approved,

Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP

Date:Tue, 12 Apr 2005 21:20:28 +0100 From:Colin Perkins <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | RFC 3555 allows media types to be defined for transport only via RTP. | The majority of these registrations are under the audio and video | top-level t

Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP

Date:Tue, 12 Apr 2005 19:03:03 +0100 From:Colin Perkins <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Sure, but if the display agent is unaware of the restrictions, it won't | ever be able to receive the media data. The example I have in mind in | "text

Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard

Date:03 Feb 2005 00:54:29 -0500 From:stanislav shalunov <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> This is totally irrelevant to the doc in question, but ... | Actually, the convention used in C and Perl is to use \0, followed by | zero, one, or two octal

Re: When should a new IANA registry be created

Date:Mon, 20 Dec 2004 14:28:52 +0100 From:Harald Tveit Alvestrand <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | In general, any time you have a set of values that can change over time, | and there is a reason for the community to know the currently-valid s

Re: How the IPnG effort was started

Date:Thu, 18 Nov 2004 07:40:56 -0500 (EST) From:[EMAIL PROTECTED] (Noel Chiappa) Message-ID: <[EMAIL PROTECTED]> | Not even my powers of pithy commentary can scale the heights needed to | adequately comment on the fact that we've now consumed more than twice | *t

Re: How the IPnG effort was started

Date:Wed, 17 Nov 2004 06:55:38 -0500 (EST) From:[EMAIL PROTECTED] (Noel Chiappa) Message-ID: <[EMAIL PROTECTED]> | Let's assume what many people now seem to concede, "concede" is a very poor word choice, "predict" perhaps, but more probably, and more accurately, "ho

Re: Last Call: 'The APPLICATION/MBOX Media-Type' to Proposed Standard

Date:Fri, 13 Aug 2004 11:33:18 -0400 From:"Eric A. Hall" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Others should note that RFC2048 is designed to facilitate registrations -- | more definitions for common data-types are widely preferred over a | prolif

Re: Response from a former IMPP Chair (Re: Last Call: A Model for Presence and Instant Messaging to Proposed Standard)

Date:Wed, 16 Jul 2003 22:18:57 +0200 From:Harald Tveit Alvestrand <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | However, I find the criticisms raised against the process leading to the | forwarding of these documents to the IESG to be very much off target.

Re: "IETF consensus" in IANA considerations [was Re: Last Call: CR-LDP Extensions for ASON to Informational ]

Date:Tue, 18 Feb 2003 14:30:51 +0100 From:Harald Tveit Alvestrand <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Given that a large portion of the IETF does not in fact subscribe to the | ietf-announce list, That's irrelevant, anyone who cares can subscrib

Re: axfr-clarify breaking RFC 1034

Date:19 Feb 2003 05:44:54 - From:"D. J. Bernstein" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | In the situation under discussion, one server has both zones, so that | server _can_ guarantee RFC 1034 consistency---and my server _does_. | (BIND 8 also

Re: axfr-clarify's fraudulent claims of consensus

Date:15 Feb 2003 04:29:44 - From:"D. J. Bernstein" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> |* The BIND company's ``AXFR clarifications'' try to eliminate the | RFC 1034 database-consistency requirements, allowing data for the | same

Re: axfr-clarify's fraudulent claims of consensus

Date:Fri, 14 Feb 2003 17:25:40 -0500 (EST) From:Dean Anderson <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | | On Fri, 14 Feb 2003, Andreas Gustafsson wrote: | > RFC1035 specifically suggests using separate data structures | > that ensure that no such m

Re: axfr-clarify's fraudulent claims of consensus

Date:14 Feb 2003 10:32:28 - From:"D. J. Bernstein" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | This ``clarification'' document prohibits several perfectly legitimate, | very widely deployed, AXFR implementation techniques. It prohibits some odd-ball

Re: "IETF consensus" in IANA considerations [was Re: Last Call: CR-LDP Extensions for ASON to Informational ]

Date:Thu, 30 Jan 2003 15:45:13 -0500 From:Thomas Narten <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> I had been avoiding reading this set of messages, because I couldn't really see discussions of what was required to get IANA to assign a number in some (irreleva

Re: WG Review: Enhancements to Internet email to support diverse service environments (lemonade)

Date:Wed, 29 Jan 2003 12:45:12 -0600 From:Pete Resnick <[EMAIL PROTECTED]> Message-ID: First, I have now seen that the draft charter I was commenting on was not the correct one, but for the two things I was most concerned about, t

Re: WG Review: Enhancements to Internet email to support diverse service environments (lemonade)

Date:Tue, 28 Jan 2003 18:12:05 -0500 From:Jacqueline Hargest <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | A new IETF working group has been proposed in the Applications Area. [...] | Enhancements to Internet email to support diverse service environments

Appeal against IESG decision

This is an appeal to the IAB against the IESG decision to reject my appeal against their earlier decision to approve the publication of draft-ietf-ipngwg-addr-arch-v3-11.txt as a Draft Standard. The issues here are very simple, and no lengthy examination of mailing list archives, taking of evidenc

sub-ip area

I'm trying to work out why anyone (outside the IESG anyway) really cares about this issue. Areas are a bureaucratic invention of the IESG - they have their uses for sure, but their real purpose is for dividing up the WG's amongst ADs who are able to handle them. Deciding how many areas should exi

  1   2   >