Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Making a hash function interchangeable in DHCID makes the conflict detection algorithm hugely more complicated, and possibly not workable at all. Think about how that would work. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listi

Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

On Monday 28 November 2005 10:49, Steven M. Bellovin wrote: > I confess that I don't see the problem. The problem is that in order to do what Pekka is proposing, we have to make a substantial change to the protocol. This creates two problems: first, it means that this protocol, which is in wid

Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]

On Monday 28 November 2005 23:40, Harald Tveit Alvestrand wrote: > This means that we will not have a backwards compatibility issue with the > installed base if we change the format of the record, but *will* have a > procedural compatibility issue if we don't keep the property of "you can > know th

Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

On Sunday 27 November 2005 15:21, Sam Hartman wrote: > Actually, no, it's worse than that.  A preimage attack is sufficient > to break this.  However you cannot reduce a break of this system to a > preimage attack.   It's always inspiring to meet someone who knows a lot about a complex topic like

Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]

The Nominum DHCP server (DCS) supports the exact mechanism described in the collection of documents, except that the data is stored in a TXT record rather than a DHCID record, because we are waiting on the DHCID record. We also implement the older version of the protocol that the ISC server s

Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

On Saturday 26 November 2005 09:56, Steven M. Bellovin wrote: > In fact, the Security Considerations section should analyze the > (non-trivial) probability of a brute-force attack. It doesn't matter. The point of the DHCID is to allow two servers to avoid accidentally stepping on each other.

Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]

On Monday 28 November 2005 20:00, Hallam-Baker, Phillip wrote: > OK so why are you proposing a new protocol rather than writing a > description of the protocols that are already in use? It's inconvenient to use TXT records, because they are not specific to the purpose. If the user wants TXT rec

Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]

On Thursday 01 December 2005 12:31, Hallam-Baker, Phillip wrote: > My criteria here are that the DNS should support an extension mechanism > that allows the definition of new records at will without the need to > deploy ANY new code at either the client or the server. Right, we have that. It's c

unknown

-- Virus Warning Message (on ietf-mx) Found virus WORM_NETSKY.B in file party.txt.pif (in party.zip) The file is deleted. - reply -- Virus Warning Message (on ietf-mx) party.zip is removed from here becaus

Re: [dhcwg] Minor inconsistencies with draft-ietf-dhc-packetcable-04.txt

Second, I'd rather see suboption 3 broken out into two different suboptions denoting the different data types. I'm not aware of any other DHCP option that has a type field. This is an excellent point. Options with variable formats _always_ require special code in the DHCP server to support them

Re: Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11

On Dec 21, 2012, at 7:48 AM, RAMAKRISHNADTV wrote: > As Ted mentioned, our draft only proposes a new sub-option for relay-agent > option which was originally created as part of RFC3046. So, the security > considerations for RFC3046 apply to our draft as well. RFC3046 deployments may > use RFC403

Re: Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11

On Dec 21, 2012, at 10:45 AM, Ben Campbell wrote: > As I responded separately to Ramakrishna, is the SHOULD use 4030 language a > new requirement specific to this draft? Or is it just describing requirements > in 3046 or elsewhere? I suppose the authors should really answer this, but I was curi

Re: Mentoring

I think it might also be worth encouraging working group chairs to have working group breakfast or lunch meetings (RSVP required) where newcomers are invited to come meet the chairs and chairs can strategically invite a few return attendees (but fewer than newcomers so they don't get crowded out

Re: Mentoring

On Mar 14, 2013, at 9:13 AM, Dave Crocker wrote: > And well advertised on one or more IETF web pages. We can also give newbies information when they register, and have the registration folks call their attention to it. It's a five-second thing when handing them their registration packet.

Re: Mentoring

On Mar 14, 2013, at 10:30 AM, Yoav Nir wrote: > There's over 100 working groups, and about 5 slots, because lunch is often > busy for WG chairs (*DIR this, and tutorial that, and design team the other). > So where would you hold 25 parallel breakfast meetings? How would we ever > manage confli

Re: Mentoring

On Mar 14, 2013, at 10:55 AM, Seiichi Kawamura wrote: > Don't call them 'newbies'. The term is not meant to be offensive—I'm sorry that it came off that way. All of us are newbies from time to time as we wander through the various working groups in the IETF. I became a newbie again this IET

Re: Mentoring

On Mar 14, 2013, at 11:31 AM, "Romascanu, Dan (Dan)" wrote: > I personally believe that while strongly recommending to the WG chairs to > adopt the concept we should leave the implementation up to each of them > without much formalization and process building. Let us not forget that we > will h

Re: Gen-ART review of draft-ietf-savi-threat-scope-06

On Mar 25, 2013, at 9:04 PM, "Black, David" wrote: > Summary: This draft is on the right track, but has open issues, described in > the review. While I identified the same issue you did with switching systems that do link aggregation and other magic, I think that the document is useful whether

Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06

On Mar 27, 2013, at 12:45 PM, Joel Halpern Direct wrote: > Then it will be done. I will wait for the AD to decide what other changes > are needed, and then will either make this change or include it in an RFC > Editor note. > Old: > If the bridging topologies which connects the switches ch

Re: STEAM: BOF proposal for Berlin

I thought the DRAFT proposal was very interesting, but it includes RFC2119 for a single throw-away bit of normative language. Port 9? Please! You already excluded port 9 with the language in the later paragraph on port allocation. So it's blatantly obvious that you are referencing RFC211

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

On Apr 2, 2013, at 6:41 AM, l.w...@surrey.ac.uk wrote: > Kids! Remember, if we're not bright enough to do physics, we can always do > engineering, the slow younger brother of physics! Is your point that if we do an engineering solution, that will slow things down enough that we won't have packet

Re: Last Call: (Security Implications of IPv6 on IPv4 Networks) to Informational RFC

On Apr 2, 2013, at 7:30 PM, Fernando Gont wrote: >> I agree with the last sentence. Happy Eyeballs is about the HTTP. >> There are other applications protocols too. :-) > > Happy eyeballs is about HTTP. But part of the approach predates "Happy > Eyeballs" -- please see RFC5461. It's certainly

Re: Sufficient email authentication requirements for IPv6

On Apr 3, 2013, at 6:16 PM, Dean Willis wrote: > I've tried to imagine using Facebook-like system for IETF work, and it is > strangely compelling ... It would, however, be nice if it were peer-to-peer rather than monolithic.

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

On Apr 5, 2013, at 10:29 AM, Spencer Dawkins wrote: > There are days when I'm really glad to be part of this community ... Yes, but the question is, is this such a day? :)

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

On Apr 6, 2013, at 3:21 AM, Brian E Carpenter wrote: > That's terrible for the IETF. It completely nullifies the NomCom > random selection process; all the suggestions in RFC 3797 seem > to be blown away by this. This seems like exactly the sort of problem that Jari's cross-area draft is intend

Re: Proposed solution for DPEP (Diversity Problem Entry Point) - IETF April 1 jokes.

On Apr 8, 2013, at 4:30 AM, Melinda Shore mailto:melinda.sh...@gmail.com>> wrote: Anyway this strikes me as an unfortunate use of those documents. Although this is not entirely a good thing, it is worth noting that one purpose in creating borders is to lure people across them.

Re: Proposed solution for DPEP (Diversity Problem Entry Point) - IETF April 1 jokes.

On Apr 8, 2013, at 9:38 AM, Melinda Shore mailto:melinda.sh...@gmail.com>> wrote: Well, the timing of this strikes me as one of those "oh" moments, following as quickly on the heels of the diversity discussion. Not so much because of language and culture issues (although those are unavoidable)

Re: Proposed solution for DPEP (Diversity Problem Entry Point) - IETF April 1 jokes.

On Apr 8, 2013, at 9:57 AM, Melinda Shore mailto:melinda.sh...@gmail.com>> wrote: Your beef isn't with me, it's with Måns. I've got no beef with either of you—I'm a vegetarian! :) (I actually found what Måns had to say valuable, which illustrates one of the great problems of communication: ev

Re: Gen-ART review of draft-ietf-savi-threat-scope-07

On Apr 9, 2013, at 6:36 PM, Russ Housley wrote: > Thanks for your efforts on this document. Your first review was in May 2011, > and the document has improved greatly for you continued pushing on the > concerns. Can we take this to mean that the concerns expressed in your now-deprecated DISCU

Re: IETF Diversity Question on Berlin Registration?

On Apr 11, 2013, at 3:43 PM, SM wrote: > 12.5 % of IAOC voting members are female. > 0.1% of IAB members are female > 0 % of IESG members are female. > > Based on the above measurements the IAOC is more "diverse". The IAOC already > collects gender-related information. The other inform

Re: IETF Diversity Question on Berlin Registration?

On Apr 11, 2013, at 4:50 PM, David Meyer mailto:d...@1-4-5.net>> wrote: Agreed, however, it would seem to me that at least one question that one might as is whether these percentages are representative of the IETF population at large. A rough eyeball check at the plenary in Orlando suggested th

Re: IETF Diversity Question on Berlin Registration?

On Apr 11, 2013, at 5:10 PM, David Meyer > Yes, but that is a different question. --dmm IOW, you are suggesting that the percentages among non-attending participants may be substantially different than the percentages among attending participants? That's a point worth studying, but wouldn't

Re: Purpose of IESG Review

On Apr 12, 2013, at 11:26 AM, Martin Rex wrote: > I'm currently seeing a document with some serious defects in > IETF Last Call (rfc2560bis) and an apparent desire to have > it Rubberstamped by the IESG (recycling at Proposed Standard). FWIW, I raised the same question during IESG review. It di

Re: IETF Diversity Question on Berlin Registration?

On Apr 12, 2013, at 4:01 PM, SM wrote: > Let's take IAOC members as an example. NomCom chose two men from the United > States. The IAB chose a man from the United States. The IESG chose a man > from the United States. The ISOC Board of Trustees chose a man from the > United States. There i

Re: IETF Diversity Question on Berlin Registration?

On Apr 12, 2013, at 7:32 PM, SM wrote: > Thomas Narten mentioned that: "we have the tendency to pick the people we > know and trust, which is understandable". How many IAB members feel strongly > about open standards, rough consensus and running code? To know the answer I > would have to actu

Re: IETF Diversity Question on Berlin Registration?

On Apr 13, 2013, at 6:44 AM, Arturo Servin wrote: > Me too, but when you have a diverse pool of people > who feel strongly about open standards, rough consensus and running code > and you choose only one category of the group, then we need to think > about how we end up in that situation. Y

Re: IETF Diversity Question on Berlin Registration?

On Apr 15, 2013, at 4:44 AM, t.p. wrote: > So perhaps, to reduce the bias, e.g. towards "western white", any system > of choosing should give preference to the views of those who do not > attend IETF meetings, for whom judgement is based solely on the > contributions the person in question is seen

Re: Purpose of IESG Review

On Apr 12, 2013, at 10:47 PM, Andy Bierman wrote: > During IESG review, the ADs from other areas should > restrict their comments to issues related to their area. > The final review should avoid changes made > which are feature redesigns or feature enhancements, > and limit changes to bug fixes on

Re: Purpose of IESG Review

On Apr 15, 2013, at 11:36 AM, Joe Touch wrote: > It gives the IESG an exemption to participating in WG and IESG last call > processes, which then frustrates the rest of the community that does not have > this opportunity. You could equally say that the IETF last call frustrates the WG process,

Re: Purpose of IESG Review

On Apr 15, 2013, at 12:23 PM, Michael Richardson wrote: > Maybe we should have an IETF first call (for objections), rather than > last call. I think that would look a lot like a DoS attack on the IETF, but it would be nice if there were a way to make it work.

Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)

On Apr 16, 2013, at 11:51 AM, Dale R. Worley wrote: > I've advocated the equivalent of the following opinion before > (http://www.ietf.org/mail-archive/web/ietf/current/msg77479.html), but > in the current context it bears repeating: Here in the IETF we accept > that low-status people may argue r

Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)

On Apr 18, 2013, at 5:02 AM, Yoav Nir wrote: > but you can become "prominent" in the sense that people might say "this > document hasn't had enough review. Let's ask so-and-so to read it" Yes, it's worth noting that working group chairs are often desperate for people about whom they can say thi

Re: IETF Diversity Question on Berlin Registration?

On Apr 18, 2013, at 1:06 PM, Dan Harkins wrote: > What is this "cure" of which you speak? This diversity discussion has > included statements like: Personally, not wearing an AD hat or attempting to anticipate the conclusions of the study group, I think the cure is to encourage more talented pe

Re: IETF Diversity Question on Berlin Registration?

On Apr 18, 2013, at 2:33 PM, James Polk wrote: > I believe I did myself a disservice in assigning such a high ratio without > saying it "feels like 70:1", which it does. But I'd truly be surprised if > it's only 10:1 - and you can't make effective and accurate estimates based on > guessing the

Re: IETF Diversity Question on Berlin Registration?

On Apr 18, 2013, at 7:23 PM, "Dan Harkins" wrote: > Actually I think it would be better to explicitly state what is intended > to be done. This is what we are trying to figure out!

Re: Gen-ART review of draft-ietf-karp-crypto-key-table-07

On Apr 25, 2013, at 2:49 PM, "Black, David" wrote: > I have no problem with the field being a binary identifier, but I think > implementers should be put on notice that binary comparison of human input > Unicode strings doesn't work as expected unless some things are done to > make it work (this u

Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

On Apr 29, 2013, at 10:18 AM, "Bernie Volz (volz)" wrote: > But I don't really see this as a big issue and the "must" is the lower-case > variant anyway. There's a big debate about whether this makes any difference. It's generally thought to be better not to say must if you don't mean MUST.

Re: IETF Diversity Question on Berlin Registration?

On Apr 29, 2013, at 1:08 PM, John C Klensin wrote: > If raising awareness and sensitivity > isn't enough to get people to think about and make decisions > differently Statistical analysis shows that even when peoples' awareness is raised, biases continue to exist, not because the people are bad

Re: call for ideas: tail-heavy IETF process

On May 1, 2013, at 5:00 PM, Scott Brim wrote: > Let's rename "last call" to > something like "IETF review" and stop giving people the wrong > expectations. Review outside the WG is vital, can be done repeatedly, > and must be done by the whole IETF at least once. Yup. The term "last call" is t

Re: call for ideas: tail-heavy IETF process

On May 2, 2013, at 6:58 PM, Dave Crocker wrote: > The RFC then and now takes around 100 days (with lots of variation > between the then and the now, of course.) Bear in mind that one of the delays that can occur and is credited to the RFC editor is author delays in AUTH48; I think another i

Re: Language editing

On May 2, 2013, at 9:41 PM, Carsten Bormann wrote: > People who aren't aware of it should look at the httpbis github experiment. > The pull request is a powerful model of WG collaboration. Several authors in the dhc working group have been doing the same thing, to good effect.

Re: Language editing

On May 2, 2013, at 9:47 PM, Dave Crocker wrote: > If the community does not have enough interest in the work to write it well, > it has bigger problems that won't be remedied by more RFC Editor effort... Also worth considering is that if a document is hard to read, it is hard to review, and hen

Re: Balancing the Process (Was: Obsoleting SPF RRTYPE)

On May 2, 2013, at 9:56 PM, Mark Andrews wrote: > How do we deal with sites? > How do we deal with vendors that ship such product? I say we punch 'em. Seriously, the IETF doesn't have an enforcement arm. It's up to buyers to check to see that what they are buying is protocol compliant, and of

Re: Language editing

On May 3, 2013, at 4:24 AM, t.p. wrote: > We really do need a tool, the like of which I was using 40 years ago > when writing code, that allows patches to be applied independently and > temporarily to see what it then looks like and if agreed that it looks > good, incorporating them permanently in

Re: call for ideas: tail-heavy IETF process

On May 4, 2013, at 10:26 PM, joel jaeggli wrote: >> However, that is a bit of a problem, because I think it's fairly rare for >> documents to get additional "review" at last call time. Changing the name >> probably won't fix that. > It feels like unless something is particularly controversial

Re: call for ideas: tail-heavy IETF process

On May 14, 2013, at 9:58 AM, "Cullen Jennings (fluffy)" wrote: > 2) On the point of what the IESG should be doing, I would like to see the > whole IESG say they agree with the Discuss Criteria document and will stay > within that (or change it if they disagree). The cross area review teams > m

Re: call for ideas: tail-heavy IETF process

On May 14, 2013, at 1:41 PM, Stephen Farrell wrote: > I've not found that a real problem. When its happened that we > did turn up something bigger than we thought after the telechat > (and updating your discuss points before or during the telechat > is considered fair game) then I think the author

Re: call for ideas: tail-heavy IETF process

On May 14, 2013, at 6:00 PM, "Joel M. Halpern" wrote: > At the same time, discussions do have to be resolvable. If there is no way > to address it, then it is not a discuss. But "required to clar" is the wrong > picture as far as I can tell. Exactly right. It would actually be pretty presum

Re: call for ideas: tail-heavy IETF process

On May 14, 2013, at 6:30 PM, Dave Crocker wrote: > And of course, that's still everyone's preference. But the reality is > that the imposition of the Discuss is an assertion that changes are > being required. No, it absolutely is not. That may have been the theory when you were AD, but I can

Re: call for ideas: tail-heavy IETF process

On May 14, 2013, at 8:27 PM, Joe Touch wrote: > That is what happens exactly because the DISCUSS holds up the document, and > most ADs don't want to burn time stalling their documents if there's a way > around that delay. It can only happen if an author values getting their document through the

Re: call for ideas: tail-heavy IETF process

On May 15, 2013, at 10:41 AM, Keith Moore wrote: >> The motivation for a particular feature of a protocol is not clear enough. >> At the IESG review stage, protocols should not be blocked because they >> provide capabilities beyond what seems necessary to acquit their >> responsibilities. > >

Re: call for ideas: tail-heavy IETF process

On May 15, 2013, at 12:36 PM, Joe Touch wrote: > I'm impressed that you have such a specific interpretation that this > criteria refers to the entire document, even when it talks about the > "feature of a protocol". "The motivation for a feature of a protocol is not clear enough." What's ambig

Re: call for ideas: tail-heavy IETF process

On May 15, 2013, at 1:23 PM, Joe Touch wrote: > You don't agree that the motivation for the difference between using 16-bit > vs. 32-bit ExIDs is sufficient, even though that is already discussed in the > document. I don't think this is a topic that the IETF as a whole is likely to find very i

Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]

On May 15, 2013, at 4:30 PM, Adrian Farrel wrote: > I suggest that the former is a bad result. Not that the authors/WG will ignore > the discussion, but if they disagree on something the AD considers very > important, the authors/WG have no incentive to participate in the discussion. > Of > cours

Re: call for ideas: tail-heavy IETF process

I must say that I have enjoyed reading the discussion between the three of you, and think it is immensely valuable in explaining what the IESG ought to be doing. You three should write it up.

Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]

On May 16, 2013, at 1:01 PM, Dave Crocker wrote: > http://dcrocker.net/#gender That's what I do. It gets a bit awkward with verb agreement and constructs like "themself," which elicits the dreaded red snake underline of doom. But I find it more comfortable than just subverting the sexist p

Re: IETF Meeting in South America

On May 24, 2013, at 12:07 PM, Lou Berger wrote: > I personally am a big fan for going to uninteresting locations in their > off season. Although, perhaps I'm alone in liking Minneapolis in the > winter as an IETF destination... You are not. Although Vancouver seems to have taken over for Minnea

Re: IETF Meeting in South America

On May 28, 2013, at 8:46 AM, Eric Burger wrote: > Riiight. That is why one never has to attend an IETF meeting in person to > serve on NOMCOM, one does not need travel support from one's employer to be > on the IESG, and why people who never come to IETF meetings are the rule and > not the exce

Re: Last Call: (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

On May 29, 2013, at 12:36 PM, John C Klensin wrote: > If I had been able to figure > out what else to say that would be stronger, constructive, and > not stray into Applicability Statement territory, I would have, > so I'm out of ideas and it is possible that Joe is too. Even if you don't have an

Re: Last Call: (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

On May 29, 2013, at 5:51 PM, SM wrote: > Here's what I would be told: Scenario a and Scenario b do not have privacy > implications as they have been reviewed by a respected organization in > Canada. I would also be told that there is an Office of the Privacy > Commissioner of Canada which is

Re: Last Call: (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

On May 29, 2013, at 6:21 PM, Ted Lemon wrote: > I hope the responsible AD for this document will not count me as > participating in the consensus on this document; it was not my intention in > making the suggestion I made to indicate that I favor publishing the > document.

Re: Time in the Air

On May 31, 2013, at 10:18 AM, Riccardo Bernardini wrote: > Then I would suggest Antarctica as permanent location for future IETF > meetings. :-) Maybe the only drawback is hotel availability, but > nothing that a handful of tents and sleeping bags cannot cure... > Also, penguins are cute :-) Thi

Re: Time in the Air

On May 31, 2013, at 4:32 PM, Elwyn Davies mailto:elw...@dial.pipex.com>> wrote: Don't they use the ADs (Area Drones) controlled from the IESG bunker? Nope, ADs are autonomous.

Re: Time in the Air

On May 31, 2013, at 8:49 PM, Randy Bush wrote: > i too, but tokyo. induce. answer, remote participation. i hope that a > decade from now many of us will not need to fly. We could just always meet in Tokyo. I'd be down with that... :)

Re: Weekly posting summary for ietf@ietf.org

On Jun 7, 2013, at 4:33 AM, Abdussalam Baryun wrote: > I recommend to add a column for subjects (number of subjects), > because the number of subject participated in is very important is > such summary. It has always been my assumption that the point of this summary was to give us all a reality

Re: Weekly posting summary for ietf@ietf.org

On Jun 7, 2013, at 11:48 AM, Andy Bierman mailto:a...@yumaworks.com>> wrote: So why not move the signal? Put IETF Last Call mail on last-c...@ietf.org and leave this list for everything else. The discussion still has to happen somewhere. I certainly am not restrictin

Re: Weekly posting summary for ietf@ietf.org

On Jun 7, 2013, at 12:04 PM, David Morris wrote: > I've wondered for some time whether the reported bytes is the > whole message I send included context quotes, or if there is > an attempt by the summary logic to factor out quoted > content. A penalty for top-posting sounds okay to me!

Re: Content-free Last Call comments

On Jun 10, 2013, at 5:52 PM, "Bradner, Scott" wrote: > I do not see all that much help in having someone list reasons they support > publication unless > there is some particularly wonderful feature or the prose is particularly > clear I don't really see any point in expressing support for a do

Re: Content-free Last Call comments

On Jun 10, 2013, at 6:19 PM, David Morris wrote: > I don't think there is another way to indicate you've reviewed a draft and > found no issues. Surely rough concensus must include confidence that > that silence means more than ignorance and I'm not aware of any mechanism > to evaluate the level o

Re: Content-free Last Call comments

On Jun 10, 2013, at 7:21 PM, SM wrote: > I agree that one-line statements are not of much use. It's more tedious to > write a statement to support a proposal than an objection to it. Non-silent > Last Calls usually draw objections. It's going to be difficult to balance > that if one-line sta

Re: Content-free Last Call comments

On Jun 10, 2013, at 8:31 PM, Mark Andrews wrote: > Which breaks some of the reasons why we do IETF last calls. WGs do get too > focused on a problem and do fail to do a balance response to problems. If enough IETF last call people agree that the working group made a mistake, that could change t

Re: Content-free Last Call comments

On Jun 11, 2013, at 4:51 AM, Randy Bush wrote: > so now i am expected to do a write-up of why i show simple support of a > document i have read? may i use carbon paper for the triplicate, or > will a copier suffice? surely we can find a way to waste more time and > effort. If you say "I support

Re: Content-free Last Call comments

On Jun 11, 2013, at 7:52 AM, Måns Nilsson wrote: > So, if wg discussion has been ordered mute by the wg chairs because > some wg participants believe the group-think consensus is good enough, > can those objections again be raised in IETF LC or are they set in stone? You can always challenge the

Re: Content-free Last Call comments

On Jun 11, 2013, at 9:41 AM, Randy Bush wrote: > how much process chaos can we create? Don't ask questions you don't want answered! :)

Re: Content-free Last Call comments

On Jun 11, 2013, at 1:52 PM, Doug Barton wrote: > The flip side of that argument is that we don't want to assume working groups > are infallible, or more importantly not subject to the groupthink phenomenon. > Otherwise what is IETF LC for? The IETF last call is for catching things the working

Re: Content-free Last Call comments

On Jun 11, 2013, at 4:24 PM, Dave Cridland mailto:d...@cridland.net>> wrote: But more seriously, what are you expecting Russ to do? What did you want him to write? If your answer is "Nothing", then how do you read IETF consensus for a document that gets no response in its Last Call? The XSF's s

Re: Content-free Last Call comments

On Jun 11, 2013, at 5:27 PM, Dave Cridland wrote: > That in turn presumes we are defaulting to publication in all cases, and that > in turn seems problematic to me, because his answers become, in order: > a) Russ, and by extension anyone who supports the document's publication for > whatever rea

Re: Content-free Last Call comments

On Jun 11, 2013, at 6:03 PM, Dave Cridland mailto:d...@cridland.net>> wrote: ... and how would we judge IETF consensus on a document that doesn't get done under a charter (which would in turn have been granted consensus without any IETF comments?) I would expect that you'd start with a mailing

Re: Content-free Last Call comments

On Jun 12, 2013, at 4:43 AM, Dave Cridland mailto:d...@cridland.net>> wrote: I suspect the closest we get to getting an idea of IETF consensus is the interest gauging at the beginning of the process, though interestingly this is only positive interest - objections to doing the work at all aren't

Re: Content-free Last Call comments

On Jun 12, 2013, at 3:31 PM, Peter Saint-Andre wrote: > I think these messages are useless, not harmful. But perhaps I have > more confidence in the inherent skepticism of your average IETF > participant than Pete does... FWIW, until I read Pete's document on consensus, I thought that +1 statemen

Re: IETF Diversity

On Jun 19, 2013, at 11:22 AM, Melinda Shore wrote: > Don't know about that one. In the US, at least, legal mandates > have typically led social change, at least when it comes to civil > rights, etc. Yup. First the Civil Rights act, then Selma... ;)

Re: Is the IETF is an international organization? (was: IETF Diversity)

On Jun 19, 2013, at 3:18 PM, Yoav Nir wrote: > Yeah, and "act" is what Americans call statutes, and Selma is a city in > Alabama where there was some controversy about voting rights. You sure need > to know a lot of Americana to participate meaningfully in some of these > discussions. Sorry.

Re: IETF, ICANN and non-standards

On Jun 19, 2013, at 3:43 PM, John Levine wrote: > Assuming we care about stability and interoperability, wouldn't it > make sense for the IETF to spin up a WG, collect these drafts, clean > up the language, make sure they agree with the widely implemented > reality, and publish them? The only way

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

On Jun 20, 2013, at 1:04 PM, Doug Barton wrote: > Perhaps we could have a non-WG mailing list so that people could submit > proposals for review prior to the expert review process. Even some of the > "get off my lawn" crowd offered good suggestions for this EUI case (make 1 > record with a size

Re: The Nominating Committee Process: Eligibility

On Jun 27, 2013, at 7:44 AM, Arturo Servin wrote: >What is the rationale of the requirement to attend psychically to > meetings? Acculturation: the opportunity over time to absorb the IETF culture and become a part of it. The other points you raised are valid, but this is the main thing.

Re: The Nominating Committee Process: Eligibility

On Jun 27, 2013, at 8:06 AM, Arturo Servin wrote: > "must have attended at least 5 meetings of the last 15 and including one of > the last 5". > > may be a good compromise. Also, I would suggest "one of the last 6" > (instead of 5). I guess in two years the IETF does not change too much.

Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

On Jul 3, 2011, at 1:47 AM, Keith Moore wrote: > Some of them were posted to the IETF list. IESG may have received others > privately. That is permitted by our process. This is a frustrating conversation. Everybody who supported the consensus in v6ops is an IETF participant, and their wishes

Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues)

On Jul 15, 2011, at 3:37 PM, Templin, Fred L wrote: >> ipv4 is becoming less usable and it's >> taking autotunnels with it, nobody here has a proposal that >> changes that. > > As far as I can tell, IPv4 is not becoming less > usable within my organization's network. You realize that you have n

Re: [v6ops] 6to4v2 (as in ripv2)?

If you have a reason to install and enable 6to4, why would the nominal status of a couple of RFCs make you do anything different? This seems like an easy question to answer. You'd implement and use 6to4v2 because it works better than the historic 6to4 protocol.

Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

How realistic is it anyway that an RG would get different *relevant* options on its different interfaces? This would seem to me to be an administrative error. Of course the broadcast address and subnet mask options might be different, but it doesn't make sense to send the RG, e.g., diff

  1   2   3   >