RE: 2119bis

> -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mark > Nottingham > Sent: Monday, August 29, 2011 5:08 PM > To: Peter Saint-Andre > Cc: IETF discussion list > Subject: Re: 2119bis > > Thanks for starting this, Peter. A few comments / topics f

Re: 2119bis

On Mon, Aug 29, 2011 at 11:11 PM, Keith Moore wrote: > On Aug 29, 2011, at 10:44 PM, Eric Burger wrote: > >> I would offer that ANY construction of SHOULD without an UNLESS is a MAY. > > The essential beauty of SHOULD is that it gets specification writers and > working groups out of the all-too-co

Re: 2119bis

+1 I believe the issue is the subtle differences between: SHOULD for something new, i.e. no dependency SHOULD for something old, i.e. an enhancement or new dependency the engineer is trying to push hard. As much as we want to isolate protocols, in practice, we are integrating many proto

Re: 2119bis

On Aug 29, 2011, at 10:44 PM, Eric Burger wrote: > I would offer that ANY construction of SHOULD without an UNLESS is a MAY. The essential beauty of SHOULD is that it gets specification writers and working groups out of the all-too-common rathole of trying to anticipate and nail down every exc

Re: 2119bis

On 30/08/2011, at 12:44 PM, Eric Burger wrote: > Yes, and... > > I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X > *are* what people usually mean when they say SHOULD. In the spirit of Say > What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting

RE: Routing at the Edges of the Internet

> Worley, Dale R wrote: > Someone says, Many deployed systems don't > implement that mechanism correctly. That's not what I said; the mechanism is deployed correctly, the problem is that there is another layer on top of it (in that case, the Windows Firewall, but it's not the only culprit) that pr

Re: 2119bis

Yes, and... I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MU

RE: Routing at the Edges of the Internet

> From: Michel Py [mic...@arneill-py.sacramento.ca.us] > > > I'm no expert in this, but isn't this what ICMP Redirect messages > > are for? Aren't routers required to generate them in these cases? > > Unfortunately, ICMP redirects are often broken. It is a well-known issue > that the introductio

Re: 2119bis

> Hi - > > From: "Eric Burger" > > To: "Narten Thomas" ; "Saint-Andre Peter" > > > > Cc: "IETF discussion list" > > Sent: Monday, August 29, 2011 3:08 PM > > Subject: Re: 2119bis > > > > I would assume in the text of the document. This paragraph is simply an > > enumeration of Burger's Axiom

Re: 2119bis

On Aug 29, 2011, at 9:12 PM, Randy Presuhn wrote: > RFC 2119 SHOULD is appropriate when the "UNLESS" cases are > known (or suspected) to exist, but it is not practical to exhaustively > identify them all. +1. ___ Ietf mailing list Ietf@ietf.org https:/

Re: 2119bis

Hi - > From: "Eric Burger" > To: "Narten Thomas" ; "Saint-Andre Peter" > > Cc: "IETF discussion list" > Sent: Monday, August 29, 2011 3:08 PM > Subject: Re: 2119bis > > I would assume in the text of the document. This paragraph is simply an > enumeration of Burger's Axiom: > For every SHOULD

Re: 2119bis

Thanks for starting this, Peter. A few comments / topics for discussion: 1) I agree that the "SHOULD... UNLESS" pattern ought be documented. 2) I strongly believe that authors should be encouraged to enumerate the potential subjects of conformance terms, and to use them in every instance. For

Re: schedules, was voting system for future venues?

>Obviously the date needs to be fixed at some point, but does it really >have to be six years in advance? ( >http://www.ietf.org/meeting/upcoming.html ) As I understand it, the main reason to schedule so far out is to avoid collisions with other meetings that attract a large number of the same peo

Re: 2119bis

Peter, Thank you for submitting this draft. It clarifies some of the most consistent sources of cyclic discussion that appear on the IETF discussion list. I have a couple of questions. The most consistent source of cyclic discussion that I didn't see addressed, is the use of RFC 2119 confor

Re: 2119bis

--On Monday, August 29, 2011 17:50 -0400 Thomas Narten wrote: > It would help me if you explained the diffs and the *reasons* > for the proposed changes. > >... > The wording "unless there is a strong explicitly described > reason not to do so in particular circumstances" is new > wording and

Re: 2119bis

On 2011-08-30 10:08, Eric Burger wrote: > I would assume in the text of the document. This paragraph is simply an > enumeration of Burger's Axiom: > For every SHOULD, there must be an UNLESS, otherwise the SHOULD is a > MAY. And there can be cases where even a MUST needs an "unless". The

Re: 2119bis

On 29 August 2011 23:36, Peter Saint-Andre wrote: > staring at http://www.rfc-editor.org/errata_search.php?eid=499 for > long enough, I finally decided to submit an I-D that is intended to > obsolete RFC 2119. There are literally thousands of documents (not only RFCs, also W3C standards, etc.) wi

Re: 2119bis

Please make my English language sensibilities and satisfy Burger's Second Law of standards documents at the same time, forbidding passive voice. Can we have the following as the boilerplate? Thanks. Either: In this document, [RFC] describes the following conformance terms: "MUST", ... O

Re: 2119bis

I would assume in the text of the document. This paragraph is simply an enumeration of Burger's Axiom: For every SHOULD, there must be an UNLESS, otherwise the SHOULD is a MAY. On Aug 29, 2011, at 5:50 PM, Thomas Narten wrote: > It would help me if you explained the diffs and the *reas

Re: 2119bis

It would help me if you explained the diffs and the *reasons* for the proposed changes. E.g, the new text says: This term means that the feature or behavior is a limited requirement of the specification, so that an implementation has a conditional obligation to implement the feature or t

2119bis

After staring at http://www.rfc-editor.org/errata_search.php?eid=499 for long enough, I finally decided to submit an I-D that is intended to obsolete RFC 2119. I hope that I've been able to update and clarify the text in a way that is respectful of the original. Feedback is welcome. http://www.iet

Re: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

>writes: > Could we add a URI list to draft-lha-krb-wg-some-numbers-to-iana? We could do that. Doing so would be a very inefficient way of moving the OTP document forward. I'd recommend that we use an existing registry. If we cannot do that, we'll need to do the registry in the OTP

Re: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

> "Henry" == Henry B Hotz writes: Henry> I was thinking that if it's a proprietary OTP, we can still Henry> use it even if the algorithm is secret. If we know we're Henry> getting a "clear text" OTP value and we have an (unspecified) Henry> method of verifying it against some

Re: voting system for future venues?

At 01:21 PM 8/29/2011, Melinda Shore wrote: On 08/29/2011 09:59 AM, Scott Brim wrote: WGs can and should apply discipline to make email the primary mode of interacting, with occasional virtual meetings and even more occasional physical meetings. Just because there is a physical meeting doesn't

Re: voting system for future venues?

top posting to make a small point: for the many IETF meetings I've gone to over the years, reserving hotel room took less than 10min in general. For this Taipei meeting however, because the primary hotel price is way above US federal allowance (that's how my employer reimburses me), and the only

Re: voting system for future venues?

On 08/29/2011 09:59 AM, Scott Brim wrote: WGs can and should apply discipline to make email the primary mode of interacting, with occasional virtual meetings and even more occasional physical meetings. Just because there is a physical meeting doesn't mean a WG should let issues pile up to be res

Re: https

Original Message - From: "Hector Santos" To: "Adam Novak" Cc: "IETF Discussion" Sent: Friday, August 26, 2011 8:49 PM Subject: Re: https > I see, so as long as its not revoked, if compromised, you are hosed > until it expires. > > I wonder if OCSP (Online Certificate Status Protocol)

Re: voting system for future venues?

On Mon, Aug 29, 2011 at 12:34, Andrew Sullivan wrote: Nicely said. On your last point: > Indeed, rather than asking how we can optimise the meeting location > for people who live at 1234 Pine Street, Springfield, USA, why don't > we ask why we are having three meetings a year?  I hear there's >

Re: voting system for future venues?

On Mon, Aug 29, 2011 at 05:38:57PM +0200, Iljitsch van Beijnum wrote: > Then go from "no clash" to "minimal clash". I look forward to the mailing list discussions in which we debate the relative importance of different clashing events. It will provide a welcome change in topic: we can move from

Re: authenticated archives, was https

On Aug 27, 2011, at 7:30 PM, Hector Santos wrote: > Keith Moore wrote: >> On Aug 27, 2011, at 10:31 AM, John Levine wrote: >>> TLS for session privacy is nice, but I find negligible value in a >>> little lock icon in my browser that means only that one of the several >>> dozen cert issuers configu

Re: voting system for future venues?

On 8/29/2011 8:01 AM, Henk Uijterwaal wrote: If we want more flexibility in order to find better hotel deals, then we have to do something like: dates are fixed approximately 1.5 years out, and we do not mind having meetings back-to-back with other organizations on the clash list. As we have

Re: voting system for future venues?

To add some data to this discussion, there's a table of Internet meetings and a chart of overlaps on the PCH website: The current maximum collision factor is 5 (meetings/day). --Richard On Aug 29, 2011, at 11:32 AM, Andrew Al

Re: Hyatt Taipei cancellation policy?

I also like Minneapolis, for what it's worth. Cheers, Andy On Sun, Aug 28, 2011 at 6:24 AM, Henk Uijterwaal wrote: > On 26/08/2011 16:48, Mary Barnes wrote: > >> [MB] I've not seen a single person advocate a 0:3:0 schedule and it's only >> less >> cheaper for all participants (not just US) beca

Re: voting system for future venues?

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

Re: voting system for future venues?

On 29 Aug 2011, at 17:32 , Andrew Allen wrote: > There likely are no such dates as there are telecommunications standards > meetings of one kind or another virtually every week of the year (except > Christmas and (western) new year). Then go from "no clash" to "minimal clash". If it turns out t

Re: voting system for future venues?

There likely are no such dates as there are telecommunications standards meetings of one kind or another virtually every week of the year (except Christmas and (western) new year). Many other standards organisations depend on IETF standards so it is important to avoid clashes with those organi

Re: voting system for future venues?

On 29 Aug 2011, at 17:01 , Henk Uijterwaal wrote: > If we want more flexibility in order to find better hotel deals, then we have > to do something like: dates are fixed approximately 1.5 years out, and we do > not mind having meetings back-to-back with other organizations on the clash > list. Th

Re: voting system for future venues?

On Mon, Aug 29, 2011 at 11:01 AM, Henk Uijterwaal wrote: >> >>... > > Discussions with the hotel starts only 2 years out, so fixing dates 3 years > out won't change a thing.   There is also the clash list, which limits the > weeks when we can have a meeting. > > If we want more flexibility in ord

Re: Hyatt Taipei cancellation policy?

On 26/08/2011 16:48, Mary Barnes wrote: > [MB] I've not seen a single person advocate a 0:3:0 schedule and it's only > less > cheaper for all participants (not just US) because the hotel rates are > extremely > reasonable (<$150 as I recall).It is definitely less expensive for the > vast >

Re: authenticated archives, was https

Keith Moore wrote: On Aug 27, 2011, at 10:31 AM, John Levine wrote: TLS for session privacy is nice, but I find negligible value in a little lock icon in my browser that means only that one of the several dozen cert issuers configured into my browser, most of whom I've never heard of, and many

Re: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

Could we define a new section for the PSKC registry instead of a whole new registry? (Agree we don't need all this info.) On Aug 26, 2011, at 8:48 AM, Simon Josefsson wrote: > writes: > >> Some form of identifier will be required for the otp-algID in the >> PA-OTP-CHALLENGE and the PA-OTP-REQ

Re: [Gen-art] Followup on Gen-ART Telechat Review of draft-ietf-dime-ikev2-psk-diameter-08

Hi, thanks for the response. Please keep in mind that my comments are no more binding than any other, so if everyone else is convinced I am wrong, that's okay :-) Specific comments inline: On Aug 26, 2011, at 6:24 PM, Mizikovsky, Semyon B (Simon) wrote: > Ben, thank you for your comment. > We

RE: Followup on Gen-ART Telechat Review of draft-ietf-dime-ikev2-psk-diameter-08

Ben, thank you for your comment. We do not specify the protocol between IKEv2 Peer and HAAA. We specify the protocol between Diameter Client and Diameter Server. The Diameter Server happens to be the HAAA. The Diameter Client happens to be the IKEv2 Server. The protocol we specify simply deliver

Re: https

Try it with Chrome and it makes you feel like the world blew up, I suppose intentionally as a fail-safe for the user-sake. Doug Barton wrote: Joel, I don't know what "It doesn't" is supposed to mean, but visiting https://www.ietf.org/* today with firefox it is still reporting that the certific

Followup on Gen-ART Telechat Review of draft-ietf-dime-ikev2-psk-diameter-08

This is a followup on my previous gen-art reviews of draft-ietf-dime-ikev2-psk-diameter based on version 09. I realize that came out a couple of weeks ago, and this followup may be overtaken by events. I am sending it anyway on the off chance it's still meaningful. This version partially addres

Re: https

I see, so as long as its not revoked, if compromised, you are hosed until it expires. I wonder if OCSP (Online Certificate Status Protocol) can help addresses this? Expired or not, it can still be revoked with dynamic checking as long as the browser as OCSP enabled. So I guess its a matter o

Re: https

Adam Novak wrote: Once the certificate expiration business is fixed, it should be fairly simple to make sure it's kept up to date so that this sort of thing doesn't happen again. Makes you wonder. Why is the concept of expiration required? Did the IETF expire, die? Did its value as an Organ

Re: Routing at the Edges of the Internet

This sounds like yet another repeated cyclic centralization to/from distribution viewpoint. The more things change, the more it remains the same. Inevitably someone will get the bright idea to be more, to consolidate more and once again offer central/services for its surroundings and then at o

Re: voting system for future venues?

On 8/29/11 07:51 , Keith Moore wrote: > > On Aug 29, 2011, at 10:40 AM, Iljitsch van Beijnum wrote: > >> Obviously the date needs to be fixed at some point, but does it really >> have to be six years in advance? >> ( http://www.ietf.org/meeting/upcoming.html ) > > I've been wondering the same t

Re: voting system for future venues?

On 29/08/2011 16:51, Keith Moore wrote: > > On Aug 29, 2011, at 10:40 AM, Iljitsch van Beijnum wrote: > >> Obviously the date needs to be fixed at some point, but does it really have >> to >> be six years in advance? ( http://www.ietf.org/meeting/upcoming.html ) > > I've been wondering the same

Re: authenticated archives, was https

On 27 Aug 2011, at 19:42 , Joel jaeggli wrote: >> In the mean time, I would like TLS exterminated from the IETF website - any >> reason will do - since the cost to me far outweighs the benefit. So who >> decided to put it in, and on what grounds? Good question. For me it also causes more troubl

Re: voting system for future venues?

On Aug 29, 2011, at 10:40 AM, Iljitsch van Beijnum wrote: > Obviously the date needs to be fixed at some point, but does it really have > to be six years in advance? ( http://www.ietf.org/meeting/upcoming.html ) I've been wondering the same thing. Would it be reasonable to specify ballpark d

Re: https

On 26 Aug 2011, at 16:24 , Tim Bray wrote: > I'm increasingly coming to think that *everything* should be done with > TLS unless you can prove it's harmful. Call me paranoid, but given > the general state of the world, secure-by-default seems like the way > to go. -Tim That would be nice in a w

Re: voting system for future venues?

On 27 Aug 2011, at 17:43 , Marshall Eubanks wrote: > I think that the meeting selection process is inherently iterative. Pseudo > code might be something like > - Find a list of all venues we can in the target area for the target week. > The number of these is rarely if ever more than 10. So t

Re: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

What information required by the PSC registry do we not need? The only thing I see is the XML information, but it looks like that could be blank. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

>writes: >> > Why should we require that alg-ids be registered URIs? >> >> That's not my concern - the existing first paragraph of the IANA >> considerations section in the draft requires IANA registration >> (or at least tries to) by pointing to the PSKC registry. My

RE: Hyatt Taipei cancellation policy?

-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Sunday, August 28, 2011 9:03 AM Subject: Re: Hyatt Taipei cancellation policy? >I find that I work more effectively when I have computer and Internet available WEG] Me too, emph

Re: https

- Original Message - From: "Joel jaeggli" To: "Doug Barton" Cc: "t.petch" ; "IETF Discussion" ; Sent: Sunday, August 28, 2011 9:55 PM > On 8/28/11 11:31 , Joel jaeggli wrote: > > On 8/26/11 14:00 , Doug Barton wrote: > >> Joel, > > > > "it doesn't" means that the mailing list archives do