From nobody Tue Sep 1 07:50:02 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C841B5181; Tue, 1 Sep 2015 07:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj8unbULvMb7; Tue, 1 Sep 2015 07:49:59 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2CC1B4E74; Tue, 1 Sep 2015 07:49:50 -0700 (PDT) Received: by vkbf67 with SMTP id f67so52604781vkb.0; Tue, 01 Sep 2015 07:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2p0u60k+5yh3oEtVLek2/FVbstBPgoacLHUQQi1y06o=; b=CTkV0KU6bfWdxcxnDr/IGR/mZQh8vbuUqjeSwNieKB08Y6ceAdJe/SpeQx9mcMPPEc 5+K7XBMQoc5tmsF3EY/SkgWfyBswzBvv02acLjXZS/fmxjg9vRQ/fXerlJe09eB9GHaO cjIqKSOh1t99CyRmSRskby/co+FRzYPU7WaJqZKWR0BuQau4O6j/zm/shyPCLiZb3i4d dSJGPRPq5urB8LmLaONh2739uSOde7O8PYuii0nPU9YVgtevT/LS4rY/ALeUceDRevYA ynttkq893Fq+D35sx9L7MVyuAYX6j6wi038nTGp0voNxK/eR//6LBTIw5UjWj+ZJCdf9 2Tow== MIME-Version: 1.0 X-Received: by 10.52.156.106 with SMTP id wd10mr28942844vdb.64.1441118990027; Tue, 01 Sep 2015 07:49:50 -0700 (PDT) Received: by 10.31.63.1 with HTTP; Tue, 1 Sep 2015 07:49:49 -0700 (PDT) In-Reply-To: References: <55E252E6.5040604@nostrum.com> Date: Tue, 1 Sep 2015 09:49:49 -0500 Message-ID: From: Spencer Dawkins at IETF To: "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary=047d7b5d495a7ad6b3051eb0a933 Archived-At: Cc: Barry Leiba , IETF Tools Development , "iesg@ietf.org" Subject: Re: [TOOLS-DEVELOPMENT] First look: Improved email handling in the datatracker X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 14:50:01 -0000 --047d7b5d495a7ad6b3051eb0a933 Content-Type: text/plain; charset=UTF-8 Barry, On Mon, Aug 31, 2015 at 5:53 PM, Alvaro Retana (aretana) wrote: > > > Sent from my iPad > > > On Aug 31, 2015, at 5:51 PM, Barry Leiba > wrote: > > > > 3. A question I've always had is whether it makes sense for a > > document's "ad" alias to include all ADs in the area, rather than just > > the responsible AD. I can see occasions when one would want to alert > > all ADs in the area, but in the vast majority of situations, I think > > we want only the responsible AD. > > I agree with that. I've had that question, too. I think it's worth discussing. Normally, we'd want the responsible AD, but when we have the responsible AD who isn't available, the other AD(s) in the area probably do benefit from having context. The longest period of unavailability I've seen recently was when Wes Eddy stepped down at the first IETF in 2013, and I wasn't named as his replacement for a couple of months, and that gap could have been longer. I'd guess Martin benefited from from not starting at zero with Wes's working groups during that time. You, and the other ADs serving at the time, would know more about that than I do, of course. (And when Martin gets back from vacation in a week or two, we can ask him :-) There may have been longer periods; I just don't know. But, worth discussing. Spencer > Alvaro > --047d7b5d495a7ad6b3051eb0a933 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Barry,

On Mon, Aug 31, 2015 at 5:53 PM, Alvaro Retana (aretana) <aretan= a@cisco.com> wrote:


Sent from my iPad

> On Aug 31, 2015, at 5:51 PM, Barry Leiba <barryleiba@computer.org> wrote:
>
> 3. A question I've always had is whether it makes sense for a
> document's "ad" alias to include all ADs in the area, ra= ther than just
> the responsible AD.=C2=A0 I can see occasions when one would want to a= lert
> all ADs in the area, but in the vast majority of situations, I think > we want only the responsible AD.

I agree with that.

I've had that= question, too. I think it's worth discussing.

Normally, we'd want the responsible AD, but when we have the responsib= le AD who isn't available, the other AD(s) in the area probably do bene= fit from having context.=C2=A0

The longest period = of unavailability I've seen recently was when Wes Eddy stepped down at = the first IETF in 2013, and I wasn't named as his replacement for a cou= ple of months, and that gap could have been longer. I'd guess Martin be= nefited from from not starting at zero with Wes's working groups during= that time.

You, and the other ADs serving at the = time, would know more about that than I do, of course.

=
(And when Martin gets back from vacation in a week or two, we can ask = him :-)

There may have been longer periods; I = just don't know.=C2=A0

But, worth discussing.<= /div>

Spencer
=C2=A0
Alvaro
=
--047d7b5d495a7ad6b3051eb0a933-- From nobody Tue Sep 1 08:22:16 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F272D1B4E47; Tue, 1 Sep 2015 08:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5G3lIyNHzPot; Tue, 1 Sep 2015 08:22:08 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086F91B45A9; Tue, 1 Sep 2015 08:22:08 -0700 (PDT) Received: by vkbf67 with SMTP id f67so53251295vkb.0; Tue, 01 Sep 2015 08:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RfuZzu/eb84EVLgW2bTHiIg1kPFJWGgXeZXaUPBquvA=; b=y4IhjYsBYIEL2sPn5fFyehn/5kNCw1lliBx4HoyXQTU1HWydJjKq2SoSPCDLaUKOvC ndbfIPu/uDJ16V6gbCDkoINCnS2d02v2YLaxD5iehDkb2crf9xhQuAG5VrnvVJV+4fY6 M4fXJ5aezd/rZBypw0t7FggvPG7f+D1/y+LBGQhybI+qc4JSAAahrdXE7zmqmTQG4SR6 WzHuDvQYtf7OBwWIymppND+A4zIFiRm7xHhHwOzw1C7pRMzWSjTFldgSFB+tMp/92+lI LLtwVyqJVxEBWC4o2vHThqQ0IaWOxRzQQt9dfYXosanSrMw1RiQAGyWop34YzWtWnpNz FbIQ== MIME-Version: 1.0 X-Received: by 10.52.97.106 with SMTP id dz10mr29813942vdb.66.1441120927147; Tue, 01 Sep 2015 08:22:07 -0700 (PDT) Received: by 10.31.63.1 with HTTP; Tue, 1 Sep 2015 08:22:07 -0700 (PDT) In-Reply-To: References: <55E252E6.5040604@nostrum.com> Date: Tue, 1 Sep 2015 10:22:07 -0500 Message-ID: From: Spencer Dawkins at IETF To: Barry Leiba Content-Type: multipart/alternative; boundary=20cf307f3214f0eeff051eb11c25 Archived-At: Cc: IETF Tools Development , "iesg@ietf.org" Subject: Re: [TOOLS-DEVELOPMENT] First look: Improved email handling in the datatracker X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 15:22:12 -0000 --20cf307f3214f0eeff051eb11c25 Content-Type: text/plain; charset=UTF-8 I responded to Barry/Alvaro on his #3 separately, but just to follow through ... On Mon, Aug 31, 2015 at 4:51 PM, Barry Leiba wrote: > Robert, thanks so much for dealing with this! Spencer echo's Barry's thanks ... > I see a few things I have questions about: > > 1. Why does last_call_expired go to iesg? Shouldn't it be doc_ad? I'd agree. Aside: I don't even use these for my own documents (although I imagine other ADs find this useful for their own documents). I either put things on telechat agendas when I'm issuing Last Calls or when I'm working through the AD dashboard entries. But maybe if TSV had more documents in flight simultaneously ... > 2. doc_pulled_from_rfc_queue: that goes to doc_ad and not to iesg. I > think that might be a sufficiently unusual and remarkable situation > that maybe that one *should* go to iesg, no? I'd agree with Barry here. > 3. A question I've always had is whether it makes sense for a > document's "ad" alias to include all ADs in the area, rather than just > the responsible AD. I can see occasions when one would want to alert > all ADs in the area, but in the vast majority of situations, I think > we want only the responsible AD. > > Example of (3): > draft-ietf-sipcore-refer-clarifications.ad@ietf.org and > draft-ietf-sipcore-refer-clarifications.all@ietf.org -- those aliases > include all three ART ADs, and probably should just include the > responsible one. > > For WGs with out-of-area responsible ADs, we get this: > draft-ietf-uta-email-tls-certs.ad@ietf.org > ben@nostrum.com, barryleiba@computer.org, alissa@cooperw.in, > stephen.farrell@cs.tcd.ie > That's Stephen AND the ART ADs. > > What do we really want here? I think those aliases should just > include the responsible AD, and perhaps we should have some way of > delegating for coverage during vacations and whatnot. Otherwise, most > of the time we're sending noise to the irresponsible (ahem) ADs. 4. On these two: charter_external_review To: ietf_announce Cc: group_mail_list charter_external_review_new_work To: new_work Are there charters that go to external review, that DON'T go to New Work? https://tools.ietf.org/html/rfc6756 has this: The IETF maintains a mailing list for the distribution of proposed new work items among standards development organizations. Many such items can be identified in proposed Birds-of-a-Feather (BOF) sessions, as well as draft charters for working groups. The IETF forwards all such draft charters for all new and revised working groups and BOF session announcements to the IETF new-work mailing list. (I apologize for not knowing for sure, but I think that's the only RFC that describes how this works. But maybe something has changed since I moved from the IAB to the IESG) That's all I have -- the rest of it looks good. And to me. Spencer > Barry > > On Sat, Aug 29, 2015 at 8:48 PM, Robert Sparks > wrote: > > All - > > > > At this year's IAB/IESG retreat we discussed making the recipients of the > > email > > messages the datatracker sends more configurable, reducing the number of > > messages > > sent for a given action, and making the messages themselves more > meaningful. > > > > One of the primary goals was to make it so that the people who needed to > > receive each message would receive the message by default, and we would > stop > > doing things like putting document shepherds in the notify field. The > intent > > now is for the notify field to be empty most of the time, only containing > > addresses that are special cases. > > > > We made a great deal of progress on this front and have some changes > ready > > for you to look over and test. There are many things here that need > > feedback. > > Please take a few moments to poke around this. If you don't find any > > showstoppers, > > I'll send this to the wg-chairs list mid-week. > > > > Start with > > (This is a development instance of the tracker - you can log in as anyone > > using > > their datatracker login name and the password "password"). > > You'll see a list of actions on the left, and recipients on the right. > > Mouse over any of them for a short pop-up description. > > You can focus on a particular action by going to, for example, > > > > > > The recipients listed are table driven - the secretariat can change them. > > Note that the actions are configured at the moment to reach more people > than > > the production system currently does in many cases. One of the most > > important > > things you can do is provide feedback on whether we have the set of > > recipients > > for a given action right. Another is whether we have the right actions > > listed - > > in other words, are there times when we send email now that we shouldn't, > > and > > are there other times where we aren't sending email that we should? (Note > > that > > there are small number of places that the tracker sends email that are > not > > yet > > using this system, but if you spot a place that's not covered here, > please > > ask > > about it.) > > > > Before brute-forcing your way through the first link above, however, let > me > > introduce a few other new things. If you go to a specific document, or a > > group, > > there is now a tab on the main page that shows what the email expansions > > turn > > into for that document or group. For example, look at > > < > https://dt-test.rjsparks.org/doc/draft-ietf-sipcore-refer-clarifications> > > and note the "Email expansions" tab that takes you to > > < > https://dt-test.rjsparks.org/doc/draft-ietf-sipcore-refer-clarifications/email/ > > > > > > The way each recipient is computed is shown at > > > > Again, you can hover over a token for a short text description, or focus > on > > a particular recipient using, for example, > > > > > > Wherever possible, the recipient is expanded using a Django template. > When > > the > > logic for expanding a recipient is too complicated for a template, the > work > > is > > done using a short function, as shown on the recipient page. As we go > > forward, > > we'll be working to simplify this gathering process so that many of the > > recipients that require functions now can be moved into templates (but it > > will > > be important to not just bury the details of the truly complicated > > recipients - > > one of the other goals of this project is to make it less of a mystery > where > > mail is sent) > > > > Now, the IESG will be particularly interested in one special case: Look > at > > the > > list of recipients for ballot_saved. The save-and-send email form will > > offer > > all of the addresses that are expanded from these recipients and allow > the > > AD to chose which recipient tokens to actually use (by default, all are > > selected). When logged in as an AD or the Secretariat, go to > > < > https://dt-test.rjsparks.org/doc/draft-ietf-sipcore-refer-clarifications/ballot/425017/emailposition/?ad=107190 > > > > > > Here are a few other highlights from the changes made so far: > > * The secretariat has been sending the internal-review and new-work > > messages manually. The Datatracker now assists with those messages. > > * The mail sent when issuing ballots has been simplified > > * Instead of a generic "state changed" message, recipients get a message > > that says > > - Comment has been added > > - Intended publication status changed > > - Document has been adopted by group > > - IESG is proccessing this document > > > > Finally, there is a script that will run when this is deployed (it has > been > > run > > already on this test instance) that will scrub recipients that should be > > normally copied out of the Notify field for each document. The leadership > > associated > > with the document will get an email message explaining the change. The > IESG > > will > > get a message for all the docs that do not have currently active > leadership > > associated > > with them (that message to the IESG will be long). Currently, when that > > script runs it > > reports: Changed 4858 documents. 3775 of those had their notify field > > emptied > > > > An example of the message that gets sent is at: > > > > > > --20cf307f3214f0eeff051eb11c25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I responded to Barry/Alvaro on his #3 separately, but just= to follow through ...

On Mon, Aug 31, 2015 at 4:51 PM, Barry Leiba <barryleiba@comput= er.org> wrote:
Robert, thanks so much for= dealing with this!

Spencer echo's Barr= y's thanks ...
=C2=A0
I see a few thing= s I have questions about:

1. Why does last_call_expired go to iesg?=C2=A0 Shouldn't it be doc_ad?=

I'd agree.=C2=A0

<= div>Aside: I don't even use these for my own documents (although I imag= ine other ADs find this useful for their own documents). I either put thing= s on telechat agendas when I'm issuing Last Calls or when I'm worki= ng through the AD dashboard entries. But maybe if TSV had more documents in= flight simultaneously ...
=C2=A0
2. doc_pu= lled_from_rfc_queue: that goes to doc_ad and not to iesg.=C2=A0 I
think that might be a sufficiently unusual and remarkable situation
that maybe that one *should* go to iesg, no?

I'd agree with Barry here.
=C2=A0
3. = A question I've always had is whether it makes sense for a
document's "ad" alias to include all ADs in the area, rather = than just
the responsible AD.=C2=A0 I can see occasions when one would want to alert<= br> all ADs in the area, but in the vast majority of situations, I think
we want only the responsible AD.

Example of (3):
draft-ietf-sipcore-refer-clarifications.ad@ietf.org and draft-ietf-sipcore-refer-clarifications.all@ietf.org -- = those aliases
include all three ART ADs, and probably should just include the
responsible one.

For WGs with out-of-area responsible ADs, we get this:
draft-ietf-uta-email-tls-certs.ad@ietf.org
ben@nostrum.com, <= a href=3D"mailto:barryleiba@computer.org" target=3D"_blank">barryleiba@comp= uter.org, alissa= @cooperw.in,
stephen.farr= ell@cs.tcd.ie
That's Stephen AND the ART ADs.

What do we really want here?=C2=A0 I think those aliases should just
include the responsible AD, and perhaps we should have some way of
delegating for coverage during vacations and whatnot.=C2=A0 Otherwise, most=
of the time we're sending noise to the irresponsible (ahem) ADs.

4. On these two:

ch= arter_external_review To:= ietf_announce=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cc: group_mail_list
charter_external_review_new_work To: new_work

= Are there charters that go to external review, that DON'T go to New Wor= k?=C2=A0https://tools.ietf.= org/html/rfc6756 has this:=C2=A0

   The IETF maintains a mailing list for the distribution =
of proposed
   new work items among standards development organizations.  Many such
   items can be identified in proposed Birds-of-a-Feather (BOF)
   sessions, as well as draft charters for working groups.  The IETF
   forwards all such draft charters for all new and revised working
   groups and BOF session announcements to the IETF new-work mailing
   list.

(I apologize for not knowing for = sure, but I think that's the only RFC that describes how this works. Bu= t maybe something has changed since I moved from the IAB to the IESG)
=

That's all I have -- the rest of it loo= ks good.

And to me.

Spencer
=C2=A0
Barry

On Sat, Aug 29, 2015 at 8:48 PM, Robert Sparks <rjsparks@nostrum.com> wrote:
> All -
>
> At this year's IAB/IESG retreat we discussed making the recipients= of the
> email
> messages the datatracker sends more configurable, reducing the number = of
> messages
> sent for a given action, and making the messages themselves more meani= ngful.
>
> One of the primary goals was to make it so that the people who needed = to
> receive each message would receive the message by default, and we woul= d stop
> doing things like putting document shepherds in the notify field. The = intent
> now is for the notify field to be empty most of the time, only contain= ing
> addresses that are special cases.
>
> We made a great deal of progress on this front and have some changes r= eady
> for you to look over and test. There are many things here that need > feedback.
> Please take a few moments to poke around this. If you don't find a= ny
> showstoppers,
> I'll send this to the wg-chairs list mid-week.
>
> Start with <https://dt-test.rjsparks.org/mailtok= en/token>
> (This is a development instance of the tracker - you can log in as any= one
> using
> their datatracker login name and the password "password"). > You'll see a list of actions on the left, and recipients on the ri= ght.
> Mouse over any of them for a short pop-up description.
> You can focus on a particular action by going to, for example,
> <https://dt-test.rjsparks.org/= mailtoken/token/last_call_issued/>
>
> The recipients listed are table driven - the secretariat can change th= em.
> Note that the actions are configured at the moment to reach more peopl= e than
> the production system currently does in many cases. One of the most > important
> things you can do is provide feedback on whether we have the set of > recipients
> for a given action right. Another is whether we have the right actions=
> listed -
> in other words, are there times when we send email now that we shouldn= 't,
> and
> are there other times where we aren't sending email that we should= ? (Note
> that
> there are small number of places that the tracker sends email that are= not
> yet
> using this system, but if you spot a place that's not covered here= , please
> ask
> about it.)
>
> Before brute-forcing your way through the first link above, however, l= et me
> introduce a few other new things. If you go to a specific document, or= a
> group,
> there is now a tab on the main page that shows what the email expansio= ns
> turn
> into for that document or group. For example, look at
> <https://dt-test.rjs= parks.org/doc/draft-ietf-sipcore-refer-clarifications>
> and note the "Email expansions" tab that takes you to
> <https://dt-t= est.rjsparks.org/doc/draft-ietf-sipcore-refer-clarifications/email/>=
>
> The way each recipient is computed is shown at
> <https://dt-test.rjsparks.org/mailtoken/re= cipient/>
> Again, you can hover over a token for a short text description, or foc= us on
> a particular recipient using, for example,
> <https://dt-test.rjsparks.org/m= ailtoken/recipient/doc_shepherd>
>
> Wherever possible, the recipient is expanded using a Django template.= =C2=A0 When
> the
> logic for expanding a recipient is too complicated for a template, the= work
> is
> done using a short function, as shown on the recipient page.=C2=A0 As = we go
> forward,
> we'll be working to simplify this gathering process so that many o= f the
> recipients that require functions now can be moved into templates (but= it
> will
> be important to not just bury the details of the truly complicated
> recipients -
> one of the other goals of this project is to make it less of a mystery= where
> mail is sent)
>
> Now, the IESG will be particularly interested in one special case: Loo= k at
> the
> list of recipients for ballot_saved.=C2=A0 The save-and-send email for= m will
> offer
> all of the addresses that are expanded from these recipients and allow= the
> AD to chose which recipient tokens to actually use (by default, all ar= e
> selected). When logged in as an AD or the Secretariat, go to
> <https://dt-test.rjsparks.org/doc/draft-ietf-sipcore-r= efer-clarifications/ballot/425017/emailposition/?ad=3D107190>
>
> Here are a few other highlights from the changes made so far:
> * The secretariat has been sending the internal-review and new-work >=C2=A0 =C2=A0messages manually. The Datatracker now assists with those = messages.
> * The mail sent when issuing ballots has been simplified
> * Instead of a generic "state changed" message, recipients g= et a message
>=C2=A0 =C2=A0that says
>=C2=A0 =C2=A0- Comment has been added
>=C2=A0 =C2=A0- Intended publication status changed
>=C2=A0 =C2=A0- Document has been adopted by group
>=C2=A0 =C2=A0- IESG is proccessing this document
>
> Finally, there is a script that will run when this is deployed (it has= been
> run
> already on this test instance) that will scrub recipients that should = be
> normally copied out of the Notify field for each document. The leaders= hip
> associated
> with the document will get an email message explaining the change. The= IESG
> will
> get a message for all the docs that do not have currently active leade= rship
> associated
> with them (that message to the IESG will be long). Currently, when tha= t
> script runs it
> reports: Changed 4858 documents. 3775 of those had their notify field<= br> > emptied
>
> An example of the message that gets sent is at:
> <http://www.nostrum.com/~rjsparks/e= xample_notify_email.txt>
>


--20cf307f3214f0eeff051eb11c25-- From nobody Tue Sep 1 09:46:11 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B541B4BD1; Tue, 1 Sep 2015 09:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5Nt14TvqaVX; Tue, 1 Sep 2015 09:46:08 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD521B4D23; Tue, 1 Sep 2015 09:46:08 -0700 (PDT) Received: by vkbf67 with SMTP id f67so54818058vkb.0; Tue, 01 Sep 2015 09:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7R7B2oiB6yoTs+ooyQpaP12TOSD49MZVGboCSzWz4TE=; b=IK3KpceUqA65gkgydwSP/k9tcay6wuP65L5CdEMHr15f4lmG2VrsvV2fi+b5tJtIuj jfEC8WE+36j0X5ER7h8X51sQqsDMkc3GbxvLwNBQcqW1uAdwzshLyHA6RymO1LlYAk4F SCMwzsRzpMnNPP5oELRNEtkFRYOrRp2rCc5d6croUfYS7PO/7MldPWRMmdh10vv29St0 q84PFUnStXsXSZxxYzbsdURS8EGzy/NFkt+EgyzWAFub9qSr5ZfGogkip2JuyGkgLX/n vFOzns00QEnszuiu41GrLIchMW+MUIRl9kw98obu7fIsKxCl7dpYabjbCp5JlaQhm22/ e4ZQ== MIME-Version: 1.0 X-Received: by 10.52.32.230 with SMTP id m6mr29862290vdi.80.1441125967555; Tue, 01 Sep 2015 09:46:07 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Tue, 1 Sep 2015 09:46:07 -0700 (PDT) In-Reply-To: References: <55E252E6.5040604@nostrum.com> Date: Tue, 1 Sep 2015 12:46:07 -0400 X-Google-Sender-Auth: bFDmAnIMoKsCrIhJY0VEmN5ysWo Message-ID: From: Barry Leiba To: Spencer Dawkins at IETF Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF Tools Development , "iesg@ietf.org" Subject: Re: [TOOLS-DEVELOPMENT] First look: Improved email handling in the datatracker X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 16:46:09 -0000 >> > 3. A question I've always had is whether it makes sense for a >> > document's "ad" alias to include all ADs in the area, rather than just >> > the responsible AD. I can see occasions when one would want to alert >> > all ADs in the area, but in the vast majority of situations, I think >> > we want only the responsible AD. > > I've had that question, too. I think it's worth discussing. > > Normally, we'd want the responsible AD, but when we have the responsible AD > who isn't available, the other AD(s) in the area probably do benefit from > having context. > > The longest period of unavailability I've seen recently was when Wes Eddy > stepped down at the first IETF in 2013, and I wasn't named as his > replacement for a couple of months, and that gap could have been longer. I'd > guess Martin benefited from from not starting at zero with Wes's working > groups during that time. It wouldn't make a difference for me, though for other ADs who work differently, it might. For my part, when I get messages about documents that "belong" to another AD, I usually delete them. I might take a quick look, but I might not. If we re-shuffled things and I took over that working group later, the mail I got earlier because I was on the "docname-ad" alias wouldn't help give me context, because I didn't pay enough attention to it for that. Barry From nobody Tue Sep 1 10:37:52 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A7D1B5896; Tue, 1 Sep 2015 10:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yActIBHUJldy; Tue, 1 Sep 2015 10:37:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965061A1B15; Tue, 1 Sep 2015 10:37:46 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t81HbjxD063862 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 1 Sep 2015 12:37:46 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <55E5E264.9050108@nostrum.com> Date: Tue, 01 Sep 2015 12:37:40 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: tools-development@ietf.org References: <55E252E6.5040604@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090606080200090804020501" Archived-At: Cc: "iesg@ietf.org" Subject: Re: [TOOLS-DEVELOPMENT] First look: Improved email handling in the datatracker X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 17:37:48 -0000 This is a multi-part message in MIME format. --------------090606080200090804020501 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 9/1/15 10:22 AM, Spencer Dawkins at IETF wrote: > > 4. On these two: > > charter_external_reviewTo: ietf_announce > Cc: group_mail_list > > charter_external_review_new_workTo: new_work > > Are there charters that go to external review, that DON'T go to New > Work? https://tools.ietf.org/html/rfc6756 has this: > > The IETF maintains a mailing list for the distribution of proposed > new work items among standards development organizations. Many such > items can be identified in proposed Birds-of-a-Feather (BOF) > sessions, as well as draft charters for working groups. The IETF > forwards all such draft charters for all new and revised working > groups and BOF session announcements to the IETF new-work mailing > list. > > (I apologize for not knowing for sure, but I think that's the only RFC > that describes how this works. But maybe something has changed since I > moved from the IAB to the IESG) > > These are separate more to allow control of what appears in the headers of what goes to the new-work list than to enable sending to new-work or not. (Even if they are always both sent, we shouldn't try to do it with one message). The normal workflow would be to send both messages. The tool will allow the secretariat to send to only one, at the direction of the IESG. --------------090606080200090804020501 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 9/1/15 10:22 AM, Spencer Dawkins at IETF wrote:

4. On these two:

charter_external_review To: ietf_announce 
                        Cc: group_mail_list

charter_external_review_new_work To: new_work

Are there charters that go to external review, that DON'T go to New Work? https://tools.ietf.org/html/rfc6756 has this: 

   The IETF maintains a mailing list for the distribution of proposed
   new work items among standards development organizations.  Many such
   items can be identified in proposed Birds-of-a-Feather (BOF)
   sessions, as well as draft charters for working groups.  The IETF
   forwards all such draft charters for all new and revised working
   groups and BOF session announcements to the IETF new-work mailing
   list.

(I apologize for not knowing for sure, but I think that's the only RFC that describes how this works. But maybe something has changed since I moved from the IAB to the IESG)


These are separate more to allow control of what appears in the headers of what goes to the new-work list than to enable sending to new-work or not. (Even if they are always both sent, we shouldn't try to do it with one message).

The normal workflow would be to send both messages. The tool will allow the secretariat to send to only one, at the direction of the IESG.
--------------090606080200090804020501-- From nobody Tue Sep 1 12:34:34 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8051A8856; Tue, 1 Sep 2015 12:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DAdl2QVmeoc; Tue, 1 Sep 2015 12:34:30 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1044A1ACE72; Tue, 1 Sep 2015 12:34:30 -0700 (PDT) Received: by vkhf67 with SMTP id f67so63616151vkh.1; Tue, 01 Sep 2015 12:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lWsFRteR2kJCD3EzxZyDNuLmiJGB720ogdvteFLPbrs=; b=oBHRClBrHn0KH6Gr3t/NmMAwuQK/MHJPLSj0CZqBqEIOzgtnvsfzDy0enCYg6/KYD9 +d25F2gaiWNVJYKR/VGzxgb/NweTw54cLwpA/CuBHDu+iHjT8JZsYp2SwxA/NgQmI+pz BGvhwdtm8hm5kOhgR/WK0Dd4gcUFjwfEJRPJqySJA84xgnOVbLcMUVV0vnETfqCKNTxg Vk1pofkilm2etT7gM+y3IRHiUOqTNyVXWr5E98nizwfriD/N/wwQsnJXl9yJkIKjECtn +o+QdMXjE/gxdFCNLNFx/p3X5Ov44ByUBXLF5RUydVaGwYEcA3lrXqY5QJB51RdoisT8 FNSw== MIME-Version: 1.0 X-Received: by 10.52.157.65 with SMTP id wk1mr18571461vdb.86.1441136069253; Tue, 01 Sep 2015 12:34:29 -0700 (PDT) Received: by 10.31.63.1 with HTTP; Tue, 1 Sep 2015 12:34:29 -0700 (PDT) In-Reply-To: <55E5E264.9050108@nostrum.com> References: <55E252E6.5040604@nostrum.com> <55E5E264.9050108@nostrum.com> Date: Tue, 1 Sep 2015 14:34:29 -0500 Message-ID: From: Spencer Dawkins at IETF To: Robert Sparks Content-Type: multipart/alternative; boundary=089e0160c0ba7b2076051eb4a3d1 Archived-At: Cc: IETF Tools Development , "iesg@ietf.org" Subject: Re: [TOOLS-DEVELOPMENT] First look: Improved email handling in the datatracker X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 19:34:33 -0000 --089e0160c0ba7b2076051eb4a3d1 Content-Type: text/plain; charset=UTF-8 Hi, Robert, On Tue, Sep 1, 2015 at 12:37 PM, Robert Sparks wrote: > > > On 9/1/15 10:22 AM, Spencer Dawkins at IETF wrote: > > > 4. On these two: > > charter_external_review To: ietf_announce > Cc: group_mail_list > > charter_external_review_new_work To: new_work > > Are there charters that go to external review, that DON'T go to New Work? > https://tools.ietf.org/html/rfc6756 has this: > > The IETF maintains a mailing list for the distribution of proposed > new work items among standards development organizations. Many such > items can be identified in proposed Birds-of-a-Feather (BOF) > sessions, as well as draft charters for working groups. The IETF > forwards all such draft charters for all new and revised working > groups and BOF session announcements to the IETF new-work mailing > list. > > > (I apologize for not knowing for sure, but I think that's the only RFC > that describes how this works. But maybe something has changed since I > moved from the IAB to the IESG) > > > These are separate more to allow control of what appears in the headers of > what goes to the new-work list than to enable sending to new-work or not. > (Even if they are always both sent, we shouldn't try to do it with one > message). > > The normal workflow would be to send both messages. The tool will allow > the secretariat to send to only one, at the direction of the IESG. > Ah, thank you for clearing that up for me. The split makes perfect sense now. Spencer --089e0160c0ba7b2076051eb4a3d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Robert,

On Tue, Sep 1, 2015 at 12:37 PM, Robert Sparks <rjsparks@nos= trum.com> wrote:
=20 =20 =20


On 9/1/15 10:22 AM, Spencer Dawkins at IETF wrote:

4. On these two:

charter_external_review To: ietf_announce=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cc: group_mail_list

charter_external_review_new_work To: new_work

Are there charters that go to external review, that DON'T go to New Work?=C2=A0https://tools.ietf.org/html/rfc6756 has this:=C2=A0

   The IETF maintains a mailing list for t=
he distribution of proposed
   new work items among standards development organizations.  Many such
   items can be identified in proposed Birds-of-a-Feather (BOF)
   sessions, as well as draft charters for working groups.  The IETF
   forwards all such draft charters for all new and revised working
   groups and BOF session announcements to the IETF new-work mailing
   list.

(I apologize for not knowing for sure, but I think that's the only RFC that describes how this works. But maybe something has changed since I moved from the IAB to the IESG)


 These are separate more to allow control of what appears in the headers of what goes to the new-work list than to enable sending to new-work or not. (Even if they are always both sent, we shouldn't try to do it with one message).

The normal workflow would be to send both messages. The tool will allow the secretariat to send to only one, at the direction of the IESG.

Ah, thank you for c= learing that up for me. The split makes perfect sense now.

Spencer
--089e0160c0ba7b2076051eb4a3d1-- From nobody Wed Sep 2 06:02:06 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCA31B3D64 for ; Wed, 2 Sep 2015 06:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWwhuXPWjMuq for ; Wed, 2 Sep 2015 06:02:03 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0095.outbound.protection.outlook.com [65.55.169.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC42D1B3D5F for ; Wed, 2 Sep 2015 06:02:02 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rpelletier@isoc.org; Received: from [192.168.0.12] (104.244.129.226) by BY2PR0601MB1557.namprd06.prod.outlook.com (10.163.107.14) with Microsoft SMTP Server (TLS) id 15.1.256.15; Wed, 2 Sep 2015 13:01:58 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Ray Pelletier In-Reply-To: Date: Wed, 2 Sep 2015 09:04:11 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <678150C1-E1BA-40AF-AD87-D9373E407D7A@isoc.org> References: <1DD216DF-B6FB-4908-AA29-AF4BA8C80C55@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.2104) X-Originating-IP: [104.244.129.226] X-ClientProxiedBy: DM2PR07CA0050.namprd07.prod.outlook.com (10.141.52.178) To BY2PR0601MB1557.namprd06.prod.outlook.com (25.163.107.14) X-Microsoft-Exchange-Diagnostics: 1; BY2PR0601MB1557; 2:4np3UW5IRAeHAAzwURubnRGM1UWXOtQ2kvEdC9c0HAuLn17EtijvxS10plJYGnLnbNJkUoPtsUd/DMeXrZ8jrvvmKvDZR/BWTIZTGz/g5DnB42JGqnzDt24NaDQynlHnk8+pnU3fDnm86nl5yneXp8WU0zLv15CUV+mLB3VGAes=; 3:Kws31+h578bRw6McXvHIKckXpzvnmkglRn/pL+FWjMx1ejx92R4oGG+HEdHjDLtfkMwav+UyH4g2VgWfD0z9zBUlGpxxu5vnS2uQCVGkN7B/E02Qdo5owPO3ngNFKbhsnwfRENRsyEhBBTdPkyqBJQ==; 25:aSsMgqa0oLwnougMUhxygGGNTazQ6m0jEPfAXko4RdQFPWDMIKeftqUpdDc0DbAXvElSBD3p94RWFqy2vUnsGs53JMTCMx0k7NKws8gh0NGXmTu0dCmNjCyJrYWcHGCLgAuM63z+5lPL6Ywj+oX1LAZ0yfIpE4ADn5NsIhcL5uyuH9IcFcQOiMb1rppJGQTOmc8PyVkXmQ1JDsT5ssfaHKM5Bh9Ibxn2iPl4bywaX5Z+sxbzxwwmWcfHINUICJ2LrkOz9XLqK4+fjOm1Dfkk9A== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0601MB1557; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0601MB1557; 20:+2QYBGzFj+qKY7WXFQx6aKWnQ8G8yBxx7gsZXFj7YEhgybtCXbfBSVMF5OzVjP+Uxlntlq+6BzI0x9qFIh8mtv+aEXaA1H9b7QC3JHpZ2HpHe3I3F9SzgW2RPmmShdOQZypqZWO5qJrVR1bpgtvyir28gfktQAAlen/p5ogGkiLxWazIVR6JHgj972utd5KapUiUpnc2oqB3JcKuFzzYklAr+r39R+G1o3m3bVQqG32ymkQ0Vb8sh7pEGjh9lOTtRPhmmXqLfsDzmlWRraEPijgtLWnhccdO8/QgmjBBx2CLJ59h+5/SS7oCx6LO37RoCQwq5XdhR1yGKTgjD0FjGfdzlEdIFw8hcR5kehUAAqho1NVImPyn9LpKW+4J5cMHpmFfYTp4hKQ7oIurE3Jur9YVMqF+5HV53dnXt2Pk2AjrJ3VSgstS4hWa//IDRwoV95DVxYmMAnqOv+q5OJ4oivJtx2hsCftDSfiZ1iGkxPpvoVxJXLj4VxryQVkRf6cv; 4:IEiNTjea4H7+iVTHxXkBjbOpoGy6PJti/7+mlZ29cbgNngQIIwak0lUkdIagkVPv/wN4k6YGosXlGl+0oVy1KdrMz031k6OMcu3RbSPvL6D44tXl8WD1rVHTm2O4dsfQp+CRCJQNx3ETA6NiLDy9L0B+TA2mXeSxEInz+I2E2U/IJSKpTZQ9E4Yq/0Xwu18a5lIsAUFS5GXW0w/fTxV7fsNqKpkSlrn/8KWTBT6JVMBCHy/971CsQnANkx71B6yOxXf63lSuWKybWysI4BsS597vrkeEnWlmw/VeQhGf0grBKPV7E19fszmOxDRkLspf X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BY2PR0601MB1557; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0601MB1557; X-Forefront-PRVS: 0687389FB0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(6049001)(199003)(377454003)(24454002)(189002)(64706001)(19580405001)(19580395003)(50226001)(33656002)(86362001)(66066001)(57306001)(47776003)(87976001)(2950100001)(5003630100001)(122386002)(117156001)(46102003)(5007970100001)(5004730100002)(15975445007)(92566002)(40100003)(77156002)(62966003)(76176999)(81156007)(4001540100001)(5001960100002)(97736004)(50986999)(77096005)(105586002)(5001830100001)(5001920100001)(110136002)(106356001)(5001860100001)(189998001)(42186005)(101416001)(50466002)(36756003)(83716003)(82746002)(23676002)(68736005)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR0601MB1557; H:[192.168.0.12]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjA2MDFNQjE1NTc7MjM6cXpmYS9ONDN4Nk4ya2IvL3dKcDFadEtF?= =?utf-8?B?WkFHWXpUNWJyWWhlamIzS0hXbWhTNjR3cHllNmxMUUxSNjF0T2J6V09vMXhu?= =?utf-8?B?dlR2M1Iwc0FEbGl0MW9INHYycHFqRHI4T2tWZTJnUDMzcXZTL0Z3NjlmMFZ0?= =?utf-8?B?VVMvOEtFSG9VOVoxc0ttUnhLVm1EV1NDSHRwNWJIejlKWXcreDMxRjREYUli?= =?utf-8?B?VGl2TkpBMk80dENFanZRbXJLU2N6N3JpMXdiTTI5a1Bta0dwSmtUTXFhcG4y?= =?utf-8?B?dklKWmd2dWE3cXJ1M29vZEhJdkFqTUwvY3E1NEdSaFRwdVRua0ZQTXBwSkM3?= =?utf-8?B?V2tjTDRZalVnZVV5WW9zUmsrQzlvRisxK2xwMWtiam8xa3kxVW5yaE1iVUZ3?= =?utf-8?B?d3o3bWJqQ0UwZEF3RXBrQVY4M3lTNWZ0WFpzVzJ1QW94TC9pQ0l5ci92WDN3?= =?utf-8?B?dTlDZ2U3aGxRZ2plYTFoanZxblA5TDVUdE5kTS9pSGNXR3dVS2dEWHdjVHZY?= =?utf-8?B?dldLS2pxcDNpVGQvMytyeUI4M0FzbmJEZUZQaVVqdko0SEI4eEgrNjVmODJt?= =?utf-8?B?UmhBbUJvOG1ydnNJa25VblRpbUUxMDlHT1pQMHY5QXIwL0FERFJlV1dCM2Vu?= =?utf-8?B?cE9rVytIVFZEMWs3b1lhYmN5M2lVZjZGWDNEVU0vL3d6U1JuWTJDZHB4Q0Jp?= =?utf-8?B?L3hHM2dZMU1oZlFqYXFvazNzWHE3V05EU1NFQ2syNDV2SUpoTDJqT1FVTDlE?= =?utf-8?B?TDI5d3pzbFN6K3FzaGdrTTd0UmlCVzlLSC9lSm5vRHprbzk3YUpYYm0zdXdh?= =?utf-8?B?S21IYTZRbHNVUnhNenMwUHZZTGpqYXkxVEtPVGJuZFVCVGVjajk5QlJSeEZW?= =?utf-8?B?SUdtb2czQlFJVzY0bWcxTGpSeWpoQzhMalh2ZWJJcFdia1BkNXlkQVFUc2Nk?= =?utf-8?B?cEh1MXBCUGN1Q0VFM1U1MzMwZTJ2WDIvS0Z4VTR3NEdOS0NYZWIzMWY3VjZB?= =?utf-8?B?MzdCK2Uvdk5PQU82dEpUSW12THN2cm00L29PNU5yVjhPdElDdXdiU1hPcGtK?= =?utf-8?B?UHVEcXpBQnh2MFNBcENmb29DWEJaOHZtMUxabmFoeWVxVHNGRWhwNzdqTXk0?= =?utf-8?B?eHhvdUFycVBIK1ZPTzV5V1VnNU40QmFUZ1FLcFdWWmlvNDZ2RUpKRjF0ZlA5?= =?utf-8?B?aXREdFZ5NGxRdWNOMmR6UWhSK08vZlZQZVpNR2trUk16Zkt0U29iRTBJNjEy?= =?utf-8?B?YUk3c3hSbXQrNmZZSy8vRm9jZlFrSGl3dWRMbjVNMXV2WGJoMkpJLy9YSHNv?= =?utf-8?B?bjlJMGtvazRIZytxWWdCU0pHMk1rSXNoNVFpclRycWN4eUcxQ1N0a3IvOXd3?= =?utf-8?B?TWpZZTAvZnp6V2p4bVBQYkhNLzJ2WjRqeEpKZ3NxUEhmVGZDWXluWVd6dHIz?= =?utf-8?B?WFZHSGFvd3VqQ3gySHQ5cDhoV2I1YTNVRnNsTUUra3dsMVIxdlhpR09KRThy?= =?utf-8?B?ZGxSUnBnU0tyTVpmWWlEZlJ2T1lMRWl0WXZld2RmZkpJeDFKUnlJeHZqWmhu?= =?utf-8?B?VEtHdEdhOE02ZXp4cDBZR3NsVnp1TUZ5aVZKa2xVOGJMQWZ5eHBCdXVQTnNx?= =?utf-8?B?V0NyUlpobTk4ZDBVNWI0bGF3THNSSGQzYXZNcktFT2NzaVlFVlhFVnJGdXVx?= =?utf-8?B?dy9NcVowV0lPNE43MDAzU0hHL2hBNUZmY2IrRHV5UU9ML1d5Z1V1QVFpWFNx?= =?utf-8?B?RDdPSVZNVld1eU1rTURYWERoZFRkSlNIOWpSRHI4VTNwcmhPeVFOVE1tOUpt?= =?utf-8?B?UnpmRXRsaE9MK005M1RpK1FzS1RKUm51eFFXcmN2SUtOU3dFQT09?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0601MB1557; 5:fxJP1QlHB4OYaNriy9UIIx1CHr578f56fnf+vm8XclkM4z05Q1ZSz+tBfel8Cdc/+BvI7UQYnBUAfFdJ0H/CaWLQoggMf3Pc4fgrjsaVjiWGOfUnrFt7qrw+QyiEUwfUUi2xhMtSoz9rBENm7BGv4w==; 24:dxDVRc00qaYNPUfpOcybg7zb12IY17SOEsLyzVmD/jaYa5RgVsxdfH1Aay281abE7wF1ThidQZ9AdEq6Gm4Kb/S+5GOZT6df18/32ncDSz0=; 20:7MW66nfIXBaMWkeTx+DGJcIW3nhoc/Rg7jMBh6KT/cIKpbZPEWKHlyFJrP4biQQyNxcUhdgzJVJLGFsEPClPUQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2015 13:01:58.9671 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0601MB1557 Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] Shifting the Tools Call? X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 13:02:05 -0000 Russ, That would work unless there are matters you=E2=80=99d like to=20 have the IAOC consider on its call on 10 September that=20 would benefit from the call on the 8th. Ray > On Aug 27, 2015, at 2:34 PM, Russ Housley = wrote: >=20 > Same time on either day: 1pm Eastern. >=20 >=20 > On Aug 27, 2015, at 1:58 PM, Kathleen Moriarty wrote: >=20 >> What time would the call be at? >>=20 >> Thank you, >> Kathleen=20 >>=20 >> Sent from my iPhone >>=20 >>> On Aug 27, 2015, at 1:52 PM, Russ Housley = wrote: >>>=20 >>> I have received a request to shift the tools call from 8 Sept. to 15 = Sept. Would this cause a problem for anyone. If so, we will leave it = as currently scheduled. >>> _______________________________________________ >>> TOOLS-DEVELOPMENT mailing list >>> TOOLS-DEVELOPMENT@ietf.org >>> https://www.ietf.org/mailman/listinfo/tools-development >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Wed Sep 2 09:21:45 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5F31B3444 for ; Wed, 2 Sep 2015 09:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uABcq7yjXUQV for ; Wed, 2 Sep 2015 09:21:41 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7838B1B3E46 for ; Wed, 2 Sep 2015 09:21:41 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 1175AF24157 for ; Wed, 2 Sep 2015 12:21:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id n92eHxYn4y6M for ; Wed, 2 Sep 2015 12:20:34 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CC83FF2414B for ; Wed, 2 Sep 2015 12:21:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <678150C1-E1BA-40AF-AD87-D9373E407D7A@isoc.org> Date: Wed, 2 Sep 2015 12:21:19 -0400 Content-Transfer-Encoding: 7bit Message-Id: <3F305713-6B6C-4149-8B23-CBEE8091147C@vigilsec.com> References: <1DD216DF-B6FB-4908-AA29-AF4BA8C80C55@vigilsec.com> <678150C1-E1BA-40AF-AD87-D9373E407D7A@isoc.org> To: IETF Tools Development X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Shifting the Tools Call? X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 16:21:43 -0000 We ill hold the call on 15 Sept. 2015 at 13:00 Eastern. Thanks. From nobody Wed Sep 9 17:30:43 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6C31B4EAB for ; Wed, 9 Sep 2015 17:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lkPe8M1HEyA for ; Wed, 9 Sep 2015 17:30:40 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 07ED91B4EAA for ; Wed, 9 Sep 2015 17:30:39 -0700 (PDT) Received: (qmail 4176 invoked by uid 0); 10 Sep 2015 00:30:36 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy6.mail.unifiedlayer.com with SMTP; 10 Sep 2015 00:30:36 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id FJWV1r00r2SSUrH01JWY11; Thu, 10 Sep 2015 00:30:35 -0600 X-Authority-Analysis: v=2.1 cv=GpXRpCFC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=wU2YTnxGAAAA:8 a=kj9zAlcOel0A:10 a=-NfooI8aBGcA:10 a=5ZFH_dB4NIgA:10 a=ff-B7xzCdYMA:10 a=AUd_NHdVAAAA:8 a=xskcdSivAAAA:8 a=48vgC7mUAAAA:8 a=Le3LuaYxbqA4GW-fds4A:9 a=CjuIK1q_8ugA:10 a=g31g_43xjtIA:10 a=YsDjew3QbREA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:To:From; bh=J4HRQ5EhF0SlrGDf4EDK4R8tSqIRMEJBkuTenlPLALw=; b=RQ7yaGs7ucIRirWrivCsWD6WWXqYanAP4B3d5yDKVtVyaDBYSTkWViSC/rYyUGJ3qW35yrqkE5gLn9VdTIX1sVEjDIOGDxAT4NrhvHk2he/Ycm2dIz6w83CFrtYaSmED; Received: from [71.191.205.82] (port=56018 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1ZZpl0-0000KR-PI for tools-development@ietf.org; Wed, 09 Sep 2015 18:30:30 -0600 From: Lou Berger To: IETF Tools Development Date: Wed, 09 Sep 2015 20:30:29 -0400 Message-ID: <14fb4a91cd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <55F0B334.60706@cisco.com> References: <20150901142936.GA60706@elstar.local> <20150904165458.GB33792@elstar.local> <55F0B334.60706@cisco.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.9.9 (build: 22000010) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 71.191.205.82 authed with lberger@labn.net} Archived-At: Subject: [TOOLS-DEVELOPMENT] Fwd: Re: [netmod] minutes of the NETMOD 2015-08-31 virtual interim meeting X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 00:30:41 -0000 Fyi - another use case for the interims calendar. .. --- Forwarded message --- From: Benoit Claise Date: September 9, 2015 6:31:47 PM Subject: Re: [netmod] minutes of the NETMOD 2015-08-31 virtual interim meeting To: Andy Bierman , netmod@ietf.org On 04/09/2015 18:54, Juergen Schoenwaelder wrote: > On Fri, Sep 04, 2015 at 09:29:53AM -0700, Andy Bierman wrote: >> Hi, >> >> Is there a WEB page that lists all the upcoming virtual meetings? >> This would really help people remember without scanning lots of >> ietf-announce email. >> > The official list of interim meetings is here: > > https://www.ietf.org/meeting/interim.html > > Yes, you have to search for NETMOD and no I am not aware of a nicer > list directly linked to say the NETMOD WG pages (or even a calendar > file). I filed a tool request some time ago exactly on that. Regards, Benoit > > /js > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Sep 11 07:52:39 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5CA1B4C5E for ; Fri, 11 Sep 2015 07:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Zam-zQTG0Qd for ; Fri, 11 Sep 2015 07:52:37 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 47AF61B4D58 for ; Fri, 11 Sep 2015 07:52:34 -0700 (PDT) Received: (qmail 23818 invoked by uid 0); 11 Sep 2015 14:52:31 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 11 Sep 2015 14:52:31 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id FqsU1r01d2SSUrH01qsXP9; Fri, 11 Sep 2015 08:52:31 -0600 X-Authority-Analysis: v=2.1 cv=QdD14Krv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=48vgC7mUAAAA:8 a=o81JuTvvsGPNcSuNTnUA:9 a=QEXdDO2ut3YA:10 a=9-2jhFtgk74A:10 a=G9WWXeuLwC8A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=QPhx6ZvGCavW0mocgjIgGVvrsW3V3ZdBwOSYoqvb0L0=; b=oX1pcBAftuxFdtbT4NnNjpQdzjVCF3LDU+ZXXnwoqC7epJjSRlsXKXD5413qfiBTO6vMvYSLSB9SfTSzTpGSJwe5RBrf6T6qDl8QPWgxleVVQmGbZ8pYxovX/cx0uwmw; Received: from box313.bluehost.com ([69.89.31.113]:36595 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZaPgi-000186-LG for tools-development@ietf.org; Fri, 11 Sep 2015 08:52:28 -0600 To: IETF Tools Development From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <55F2EAA4.3040503@labn.net> Date: Fri, 11 Sep 2015 10:52:20 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 14:52:38 -0000 So what's the right way to report an issue with ical.ietf.org? I see an issue with a meeting from yesterday 9/10/15 on https://ical.ietf.org/public.php/IAOC/calendar and it looks like the issues is also there for future meetings. The meeting correctly shows in Thunderbird as occurring at noon ET, but on google calendar it shows at 10am ET. Interesting, this has not been an issue for other calendars, e.g., finance. Thanks, Lou From nobody Fri Sep 11 09:53:17 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883371B32D4 for ; Fri, 11 Sep 2015 09:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.287 X-Spam-Level: X-Spam-Status: No, score=-101.287 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdzlkK_UDFJL for ; Fri, 11 Sep 2015 09:53:15 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 672E71B32D1 for ; Fri, 11 Sep 2015 09:53:15 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 4281D1E59FA for ; Fri, 11 Sep 2015 09:52:55 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by c8a.amsl.com (Postfix) with ESMTPSA id 1F40C1E59DF for ; Fri, 11 Sep 2015 09:52:55 -0700 (PDT) Received: by oiev17 with SMTP id v17so46019239oie.1 for ; Fri, 11 Sep 2015 09:53:14 -0700 (PDT) X-Received: by 10.202.240.70 with SMTP id o67mr36780597oih.87.1441990394806; Fri, 11 Sep 2015 09:53:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.93.193 with HTTP; Fri, 11 Sep 2015 09:52:55 -0700 (PDT) In-Reply-To: <55F2EAA4.3040503@labn.net> References: <55F2EAA4.3040503@labn.net> From: Glen Date: Fri, 11 Sep 2015 09:52:55 -0700 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=94eb2c09152c408a5e051f7b8da7 Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 16:53:16 -0000 --94eb2c09152c408a5e051f7b8da7 Content-Type: text/plain; charset=UTF-8 Hi Lou - AMS (ietf-action@ietf.org) would be the correct place to report a problem with the calendar *server* - for example, if the calendar server were down, or you couldn't get access, or something like that. But I confess I have no idea how or where to "report" the problem you're encountering. When I view the feed you mention, I see the meeting coded as: DTEND;TZID=America/New_York:20150910T130000 DTSTART;TZID=America/New_York:20150910T120000 So the calendar server appears to be delivering it correctly, as you point out. The question seems to be why Google calendar is misinterpreting the coding here. I also use Gogole calendar, and it is also misinterpreting the coding for me.... but I cannot tell why, nor would I know to whom that should be reported. I welcome thoughts on this matter! Glen Glen Barney IT Director AMS (IETF Secretariat) On Fri, Sep 11, 2015 at 7:52 AM, Lou Berger wrote: > So what's the right way to report an issue with ical.ietf.org? > > I see an issue with a meeting from yesterday 9/10/15 on > https://ical.ietf.org/public.php/IAOC/calendar and it looks like the > issues is also there for future meetings. > > The meeting correctly shows in Thunderbird as occurring at noon ET, but > on google calendar it shows at 10am ET. Interesting, this has not been > an issue for other calendars, e.g., finance. > > Thanks, > Lou > > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > --94eb2c09152c408a5e051f7b8da7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lou -=

AMS (ietf-action@ietf.org) would be the correct place to report a problem = with the calendar *server* - for example, if the calendar server were down,= or you couldn't get access, or something like that.

But I= confess I have no idea how or where to "report" the problem you&= #39;re encountering.

When I view the feed you mention, I see t= he meeting coded as:

DTEND;TZID=3DAmerica/New_York:20150910T130000DTSTART;TZID=3DAmerica/New_York:20150910T120000

So the calen= dar server appears to be delivering it correctly, as you point out.

=
The question seems to be why Google calendar is misinterpreting the c= oding here.

I also use Gogole calendar, and it is also misinte= rpreting the coding for me.... but I cannot tell why, nor would I know to w= hom that should be reported.

I welcome thoughts on this m= atter!

Glen
Glen Barney
IT Direct= or
AMS (IETF Secretariat)



On Fri, Sep 11, 2015 at 7:52 AM, = Lou Berger <lberger@labn.net> wrote:
So what's the right way to report an issue with ical.ietf.org?=

I see an issue with a meeting from yesterday 9/10/15 on
https://ical.ietf.org/public.php/IAOC/calendar and= it looks like the
issues is also there for future meetings.

The meeting correctly shows in Thunderbird as occurring at noon ET, but
on google calendar it shows at 10am ET.=C2=A0 Interesting, this has not bee= n
an issue for other calendars, e.g., finance.

Thanks,
Lou



_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVEL= OPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment

--94eb2c09152c408a5e051f7b8da7-- From nobody Fri Sep 11 10:01:01 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1B71B4F55 for ; Fri, 11 Sep 2015 10:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.587 X-Spam-Level: X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78dCDOq1TL6W for ; Fri, 11 Sep 2015 10:00:56 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id EA5A01B4F59 for ; Fri, 11 Sep 2015 10:00:55 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id BF6F11E5A14 for ; Fri, 11 Sep 2015 10:00:35 -0700 (PDT) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by c8a.amsl.com (Postfix) with ESMTPSA id 9C74C1E59E6 for ; Fri, 11 Sep 2015 10:00:35 -0700 (PDT) Received: by obbbh8 with SMTP id bh8so65399314obb.0 for ; Fri, 11 Sep 2015 10:00:55 -0700 (PDT) X-Received: by 10.60.177.129 with SMTP id cq1mr670129oec.26.1441990855325; Fri, 11 Sep 2015 10:00:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.93.193 with HTTP; Fri, 11 Sep 2015 10:00:36 -0700 (PDT) In-Reply-To: References: <55F2EAA4.3040503@labn.net> From: Glen Date: Fri, 11 Sep 2015 10:00:36 -0700 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=089e01184a14b38473051f7ba8e3 Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 17:00:58 -0000 --089e01184a14b38473051f7ba8e3 Content-Type: text/plain; charset=UTF-8 Here's an interesting data point: If I download the file at the https://ical.ietf.org/public.php/IAOC/calendar URL manually, and save it as an ICS file on my desktop, and then I "Import" that file into Google, the times display correctly. It is only if I ask Google to "subscribe" to the URL in live-feed mode that it seems to incorrectly compute the times. As there is no difference in the data flow or what is pulled (since the Calendar server sends everything via HTTP in the same way), I wonder if something in Google's subscription processor is tripping on something somewhere. That's not a solution - because you obviously want the live feed - but it does provide an additional point of validation, if you like, of the data. Glen On Fri, Sep 11, 2015 at 9:52 AM, Glen wrote: > Hi Lou - > > AMS (ietf-action@ietf.org) would be the correct place to report a problem > with the calendar *server* - for example, if the calendar server were down, > or you couldn't get access, or something like that. > > But I confess I have no idea how or where to "report" the problem you're > encountering. > > When I view the feed you mention, I see the meeting coded as: > > DTEND;TZID=America/New_York:20150910T130000 > DTSTART;TZID=America/New_York:20150910T120000 > > So the calendar server appears to be delivering it correctly, as you point > out. > > The question seems to be why Google calendar is misinterpreting the coding > here. > > I also use Gogole calendar, and it is also misinterpreting the coding for > me.... but I cannot tell why, nor would I know to whom that should be > reported. > > I welcome thoughts on this matter! > > Glen > Glen Barney > IT Director > AMS (IETF Secretariat) > > > > On Fri, Sep 11, 2015 at 7:52 AM, Lou Berger wrote: > >> So what's the right way to report an issue with ical.ietf.org? >> >> I see an issue with a meeting from yesterday 9/10/15 on >> https://ical.ietf.org/public.php/IAOC/calendar and it looks like the >> issues is also there for future meetings. >> >> The meeting correctly shows in Thunderbird as occurring at noon ET, but >> on google calendar it shows at 10am ET. Interesting, this has not been >> an issue for other calendars, e.g., finance. >> >> Thanks, >> Lou >> >> >> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >> > > --089e01184a14b38473051f7ba8e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 11, 2015 at 9:52 AM, Glen <glen@= amsl.com> wrote:
Hi Lou -

=
AMS (ietf-a= ction@ietf.org) would be the correct place to report a problem with the= calendar *server* - for example, if the calendar server were down, or you = couldn't get access, or something like that.

But I confess= I have no idea how or where to "report" the problem you're e= ncountering.

When I view the feed you mention, I see the meeti= ng coded as:

DTEND;TZID=3DAmerica/New_York:20150910T130000
DTSTAR= T;TZID=3DAmerica/New_York:20150910T120000

So the calendar serv= er appears to be delivering it correctly, as you point out.

Th= e question seems to be why Google calendar is misinterpreting the coding he= re.

I also use Gogole calendar, and it is also misinterpreting= the coding for me.... but I cannot tell why, nor would I know to whom that= should be reported.

I welcome thoughts on this matter!

Glen
Glen Barney
IT Director
AMS (IETF Secretariat)

<= br>

On Fri, Sep 11, 2015 at 7:52 AM, Lou Berg= er <lberger@labn.net> wrote:
ical.ietf.org?

I see an issue with a meeting from yesterday 9/10/15 on
https://ical.ietf.org/public.php/IAOC/calendar and= it looks like the
issues is also there for future meetings.

The meeting correctly shows in Thunderbird as occurring at noon ET, but
on google calendar it shows at 10am ET.=C2=A0 Interesting, this has not bee= n
an issue for other calendars, e.g., finance.

Thanks,
Lou



_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVEL= OPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment


--089e01184a14b38473051f7ba8e3-- From nobody Fri Sep 11 10:06:14 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9131B502E for ; Fri, 11 Sep 2015 10:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad762evOtOIg for ; Fri, 11 Sep 2015 10:06:11 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 68C121B502C for ; Fri, 11 Sep 2015 10:06:11 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 1D824F24181; Fri, 11 Sep 2015 13:06:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id wc974Dcmw5i9; Fri, 11 Sep 2015 13:04:43 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7CF5BF24162; Fri, 11 Sep 2015 13:05:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <55F2EAA4.3040503@labn.net> Date: Fri, 11 Sep 2015 13:05:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55F2EAA4.3040503@labn.net> To: Lou Berger X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 17:06:12 -0000 Lou: > So what's the right way to report an issue with ical.ietf.org? >=20 > I see an issue with a meeting from yesterday 9/10/15 on > https://ical.ietf.org/public.php/IAOC/calendar and it looks like the > issues is also there for future meetings. >=20 > The meeting correctly shows in Thunderbird as occurring at noon ET, = but > on google calendar it shows at 10am ET. Interesting, this has not = been > an issue for other calendars, e.g., finance. How can it be a problem with the server that two different clients are = displaying different results? I assume the entries are provided by the = server in UTC and that the conversion is done by the client. Russ From nobody Fri Sep 11 10:59:45 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CE71B47BF for ; Fri, 11 Sep 2015 10:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eB8ew2gXElKk for ; Fri, 11 Sep 2015 10:59:42 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id D87DE1B3432 for ; Fri, 11 Sep 2015 10:59:41 -0700 (PDT) Received: (qmail 20079 invoked by uid 0); 11 Sep 2015 17:59:41 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 11 Sep 2015 17:59:41 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id Fzzb1r00j2SSUrH01zzepg; Fri, 11 Sep 2015 17:59:40 -0600 X-Authority-Analysis: v=2.1 cv=GpXRpCFC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=48vgC7mUAAAA:8 a=jGqiy6jZAAAA:8 a=XCIjdFbpEKY1kq0IR_4A:9 a=QEXdDO2ut3YA:10 a=G9WWXeuLwC8A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=nWGOkuzn+oFzRPiqIAkxLlqSeBm3P+g4yenIXI3lPu8=; b=roWKV9N8mjEtJdZQrpSWnoClyyatkbeq5hsNRW7X49b9DZ98pWbZJ+Fd1afYHpgLRjNjz4A3DGAUY9UcYuxqLcAhaF6Q0nZ3RNfCtcsv/o118Pgm+btD+4i5CBKre96M; Received: from box313.bluehost.com ([69.89.31.113]:58797 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZaSbo-0002Sw-HP; Fri, 11 Sep 2015 11:59:36 -0600 To: glen@amsl.com References: <55F2EAA4.3040503@labn.net> From: Lou Berger Message-ID: <55F31680.6080100@labn.net> Date: Fri, 11 Sep 2015 13:59:28 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 17:59:44 -0000 another data point: https://ical.ietf.org/public.php/IAOC/finance works fine... On 9/11/2015 1:00 PM, Glen wrote: > Here's an interesting data point: > > If I download the file at the > https://ical.ietf.org/public.php/IAOC/calendar URL manually, and save > it as an ICS file on my desktop, and then I "Import" that file into > Google, the times display correctly. > > It is only if I ask Google to "subscribe" to the URL in live-feed mode > that it seems to incorrectly compute the times. > > As there is no difference in the data flow or what is pulled (since > the Calendar server sends everything via HTTP in the same way), I > wonder if something in Google's subscription processor is tripping on > something somewhere. > > That's not a solution - because you obviously want the live feed - but > it does provide an additional point of validation, if you like, of the > data. > > Glen > > > > > > > > On Fri, Sep 11, 2015 at 9:52 AM, Glen > wrote: > > Hi Lou - > > AMS (ietf-action@ietf.org ) would be > the correct place to report a problem with the calendar *server* - > for example, if the calendar server were down, or you couldn't get > access, or something like that. > > But I confess I have no idea how or where to "report" the problem > you're encountering. > > When I view the feed you mention, I see the meeting coded as: > > DTEND;TZID=America/New_York:20150910T130000 > DTSTART;TZID=America/New_York:20150910T120000 > > So the calendar server appears to be delivering it correctly, as > you point out. > > The question seems to be why Google calendar is misinterpreting > the coding here. > > I also use Gogole calendar, and it is also misinterpreting the > coding for me.... but I cannot tell why, nor would I know to whom > that should be reported. > > I welcome thoughts on this matter! > > Glen > Glen Barney > IT Director > AMS (IETF Secretariat) > > > > On Fri, Sep 11, 2015 at 7:52 AM, Lou Berger > wrote: > > So what's the right way to report an issue with ical.ietf.org > ? > > I see an issue with a meeting from yesterday 9/10/15 on > https://ical.ietf.org/public.php/IAOC/calendar and it looks > like the > issues is also there for future meetings. > > The meeting correctly shows in Thunderbird as occurring at > noon ET, but > on google calendar it shows at 10am ET. Interesting, this has > not been > an issue for other calendars, e.g., finance. > > Thanks, > Lou > > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > > > From nobody Fri Sep 11 11:03:17 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617481B2E2C for ; Fri, 11 Sep 2015 11:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJcFIVjQ2uVH for ; Fri, 11 Sep 2015 11:03:14 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 4B54D1A1AB6 for ; Fri, 11 Sep 2015 11:03:14 -0700 (PDT) Received: (qmail 13644 invoked by uid 0); 11 Sep 2015 18:03:13 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 11 Sep 2015 18:03:13 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id Fu361r00v2SSUrH01u39sz; Fri, 11 Sep 2015 12:03:12 -0600 X-Authority-Analysis: v=2.1 cv=EbVbHpWC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=48vgC7mUAAAA:8 a=jp4_KYY9MebklCigUNAA:9 a=pILNOxqGKmIA:10 a=G9WWXeuLwC8A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=5db6E4gp8RXFPfkhx6xd+Q9ZfuA1P2NRMcz2KXP1oK0=; b=EK7MJrPzptNHwjHs2ZRyEiBxk/eVCkPuHHB2mEBGSwescMJHrvgBfIf/GSPrEBOcR8PULhzsFQKuGgPejVylXIF8WphsYrMzm5Q3s8U1+Ze5iTcKlObS+gNoS3SVjSq4; Received: from box313.bluehost.com ([69.89.31.113]:60827 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZaSfD-0003CD-5H; Fri, 11 Sep 2015 12:03:07 -0600 To: Russ Housley References: <55F2EAA4.3040503@labn.net> From: Lou Berger Message-ID: <55F31754.2020701@labn.net> Date: Fri, 11 Sep 2015 14:03:00 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 18:03:15 -0000 On 9/11/2015 1:05 PM, Russ Housley wrote: > Lou: > >> So what's the right way to report an issue with ical.ietf.org? >> >> I see an issue with a meeting from yesterday 9/10/15 on >> https://ical.ietf.org/public.php/IAOC/calendar and it looks like the >> issues is also there for future meetings. >> >> The meeting correctly shows in Thunderbird as occurring at noon ET, but >> on google calendar it shows at 10am ET. Interesting, this has not been >> an issue for other calendars, e.g., finance. > How can it be a problem with the server that two different clients are displaying different results? I assume the entries are provided by the server in UTC and that the conversion is done by the client. Both calendars use the standard and valid TZID property and VTIMEZONE component to provide times in local TZ. One note, it looks like some versions of outlook required the TZ names to be quoted (which isn't the standard). Perhaps there's something related happening... > Russ > > From nobody Sun Sep 13 08:29:48 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4D01B39B3 for ; Sun, 13 Sep 2015 08:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9ww2Y06vQ1Y for ; Sun, 13 Sep 2015 08:29:45 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 2B0A21B39B1 for ; Sun, 13 Sep 2015 08:29:44 -0700 (PDT) Received: (qmail 18485 invoked by uid 0); 13 Sep 2015 15:29:43 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 13 Sep 2015 15:29:43 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id GfVe1r00H2SSUrH01fVhsb; Sun, 13 Sep 2015 09:29:43 -0600 X-Authority-Analysis: v=2.1 cv=QdD14Krv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=wU2YTnxGAAAA:8 a=kj9zAlcOel0A:10 a=-NfooI8aBGcA:10 a=e51C65Y0Z2gA:10 a=ff-B7xzCdYMA:10 a=1XWaLZrsAAAA:8 a=48vgC7mUAAAA:8 a=jGqiy6jZAAAA:8 a=H4_BM3waw5m23tI12MYA:9 a=CjuIK1q_8ugA:10 a=G9WWXeuLwC8A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=wjV8QakiJwNOa1YEgnZDn4ZOxs7eo0Uo9ByaO3yoz0c=; b=vZDNVFZwSaIP/wQGVdFGxs5J8PT0Qd2TvCDXVia/b7OsVS9jP5jUd8BXCBFUm70S6GP9u4g1toHiyAhN+R7xQIBn87M0RNh1pJ65kirWZO4CPbf18PXlDAjf7Vi7IhYC; Received: from [172.56.3.24] (port=50872 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Zb9Dm-0000jU-4Y; Sun, 13 Sep 2015 09:29:38 -0600 From: Lou Berger To: Date: Sun, 13 Sep 2015 11:29:37 -0400 Message-ID: <14fc7535b48.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <55F31680.6080100@labn.net> References: <55F2EAA4.3040503@labn.net> <55F31680.6080100@labn.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.9.9 (build: 22000010) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.56.3.24 authed with lberger@labn.net} Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 15:29:47 -0000 Glenn, Looks like others have seen similar issues and worked with Google to resolve, see links below. Given that there will likely be other Google users of the ietf ical server it's probably worth running this to ground... Lou - https://productforums.google.com/forum/m/#!topic/calendar/GouovR3g4LY. Look at the 4/1 response. - I lost the link, but someone solve the issues by removing any Z (utc) based times from the ics On September 11, 2015 2:00:09 PM Lou Berger wrote: > another data point: > https://ical.ietf.org/public.php/IAOC/finance > > works fine... > > On 9/11/2015 1:00 PM, Glen wrote: >> Here's an interesting data point: >> >> If I download the file at the >> https://ical.ietf.org/public.php/IAOC/calendar URL manually, and save >> it as an ICS file on my desktop, and then I "Import" that file into >> Google, the times display correctly. >> >> It is only if I ask Google to "subscribe" to the URL in live-feed mode >> that it seems to incorrectly compute the times. > > >> >> As there is no difference in the data flow or what is pulled (since >> the Calendar server sends everything via HTTP in the same way), I >> wonder if something in Google's subscription processor is tripping on >> something somewhere. >> >> That's not a solution - because you obviously want the live feed - but >> it does provide an additional point of validation, if you like, of the >> data. >> >> Glen >> >> >> >> >> >> >> >> On Fri, Sep 11, 2015 at 9:52 AM, Glen > > wrote: >> >> Hi Lou - >> >> AMS (ietf-action@ietf.org ) would be >> the correct place to report a problem with the calendar *server* - >> for example, if the calendar server were down, or you couldn't get >> access, or something like that. >> >> But I confess I have no idea how or where to "report" the problem >> you're encountering. >> >> When I view the feed you mention, I see the meeting coded as: >> >> DTEND;TZID=America/New_York:20150910T130000 >> DTSTART;TZID=America/New_York:20150910T120000 >> >> So the calendar server appears to be delivering it correctly, as >> you point out. >> >> The question seems to be why Google calendar is misinterpreting >> the coding here. >> >> I also use Gogole calendar, and it is also misinterpreting the >> coding for me.... but I cannot tell why, nor would I know to whom >> that should be reported. >> >> I welcome thoughts on this matter! >> >> Glen >> Glen Barney >> IT Director >> AMS (IETF Secretariat) >> >> >> >> On Fri, Sep 11, 2015 at 7:52 AM, Lou Berger > > wrote: >> >> So what's the right way to report an issue with ical.ietf.org >> ? >> >> I see an issue with a meeting from yesterday 9/10/15 on >> https://ical.ietf.org/public.php/IAOC/calendar and it looks >> like the >> issues is also there for future meetings. >> >> The meeting correctly shows in Thunderbird as occurring at >> noon ET, but >> on google calendar it shows at 10am ET. Interesting, this has >> not been >> an issue for other calendars, e.g., finance. >> >> Thanks, >> Lou >> >> >> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >> >> >> > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > From nobody Sun Sep 13 14:47:48 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48591B488A for ; Sun, 13 Sep 2015 14:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.51 X-Spam-Level: X-Spam-Status: No, score=-7.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4WnsdEmn8Zw for ; Sun, 13 Sep 2015 14:47:45 -0700 (PDT) Received: from sjmda14.webex.com (sjmda14.webex.com [64.68.124.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937C41A1B86 for ; Sun, 13 Sep 2015 14:47:45 -0700 (PDT) Received: from jsj2tc410.webex.com (sjc02-wxp00-lbace03-core-vl120-np10-4.webex.com [64.68.121.248]) by sjmda14.webex.com (Postfix) with ESMTP id 568908305F for ; Sun, 13 Sep 2015 21:47:45 +0000 (GMT) Received: from jsj2tc410.webex.com (localhost [127.0.0.1]) by jsj2tc410.webex.com (Postfix) with ESMTP id 3A70680158 for ; Sun, 13 Sep 2015 21:47:45 +0000 (GMT) Date: Sun, 13 Sep 2015 21:47:45 +0000 (GMT) From: Ray Pelletier To: tools-development@ietf.org Message-ID: <1193487809.14790.1442180865237.JavaMail.nobody@jsj2tc410.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_14788_1795267975.1442180865237" X-Priority: 3 Importance: normal Archived-At: Subject: [TOOLS-DEVELOPMENT] WebEx meeting invitation: Tools Cmte X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: rpelletier@isoc.org List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 21:47:47 -0000 ------=_Part_14788_1795267975.1442180865237 Content-Type: multipart/Alternative; boundary="----=_Part_14789_923615475.1442180865237" ------=_Part_14789_923615475.1442180865237 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKUmF5IFBlbGxldGllciBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVl dGluZy4KCgpUb29scyBDbXRlClR1ZXNkYXksIFNlcHRlbWJlciAxNSwgMjAxNQoxOjAwIHBtICB8 ICBFYXN0ZXJuIERheWxpZ2h0IFRpbWUgKE5ldyBZb3JrLCBHTVQtMDQ6MDApICB8ICAxIGhyCgoK Sk9JTiBXRUJFWCBNRUVUSU5HCmh0dHBzOi8vd29ya2dyZWVuLndlYmV4LmNvbS93b3JrZ3JlZW4v ai5waHA/TVRJRD1tNDQwNWRjNTFjZGU5NTlhZmQ4NWY0M2I5MDU0MzZjOGMKTWVldGluZyBudW1i ZXI6IDgyNSA3NzcgNzIyCgoNCkpPSU4gQlkgUEhPTkUNCjEtODc3LTY2OC00NDkwIENhbGwtaW4g dG9sbC1mcmVlIG51bWJlciAoVVMvQ2FuYWRhKSAKMS00MDgtNzkyLTYzMDAgQ2FsbC1pbiB0b2xs IG51bWJlciAoVVMvQ2FuYWRhKQpBY2Nlc3MgY29kZTogODI1IDc3NyA3MjIKCkdsb2JhbCBjYWxs LWluIG51bWJlcnM6Cmh0dHBzOi8vd29ya2dyZWVuLndlYmV4LmNvbS93b3JrZ3JlZW4vZ2xvYmFs Y2FsbGluLnBocD9zZXJ2aWNlVHlwZT1NQyZFRD0zMTU2NzMxMjImdG9sbEZyZWU9MQoKVG9sbC1m cmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiAKaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxm cmVlX3Jlc3RyaWN0aW9ucy5wZGYNCg0KCkFkZCB0aGlzIG1lZXRpbmcgdG8geW91ciBjYWxlbmRh cjoKaHR0cHM6Ly93b3JrZ3JlZW4ud2ViZXguY29tL3dvcmtncmVlbi9qLnBocD9NVElEPW1iYmQx YTczOTY3ODVkYzJkZTUwZjNmYzA5NDA1OGE2MA0KDQoKQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8g Q29udGFjdCBzdXBwb3J0IGhlcmU6Cmh0dHBzOi8vd29ya2dyZWVuLndlYmV4LmNvbS93b3JrZ3Jl ZW4vbWMKCgpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2Vy dmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBz ZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVn YWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29u c2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyBy ZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpv aW4gdGhlIHNlc3Npb24uCg== ------=_Part_14789_923615475.1442180865237 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBSYXkg UGVsbGV0aWVyIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJFeCBtZWV0aW5nLgogICAgICAg ICAgICAgICAgCSAgICAgICAgICAgPC90ZD4KICAgICAgPC90cj4KPC90YWJsZT4KCgoKCjx0YWJs ZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+ Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZSAgd2lkdGg9IjEwMCUiPgoJCQkJ CQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0iZm9udC1zaXplOjE2cHg7IGNvbG9yOiM0RDRENEQi PgoJCQkJCQkJCQk8Yj5Ub29scyBDbXRlPC9iPgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJ CQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+VHVlc2RheSwgU2VwdGVt YmVyIDE1LCAyMDE1CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8dHIgc3R5bGU9 Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD4xOjAwIHBtJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNw O0Vhc3Rlcm4gRGF5bGlnaHQgVGltZSAoTmV3IFlvcmssIEdNVC0wNDowMCkmbmJzcDsmbmJzcDt8 Jm5ic3A7Jm5ic3A7MSBocgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxl PgoKPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdo dDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlIHN0eWxlPSJ3aWR0 aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFudCI+CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0 eWxlPSJjb2xvcjojMDBBRkY5O2ZvbnQtc2l6ZToxNnB4Ij4KCQkJCQkJCQkJPGEgaHJlZj0iaHR0 cHM6Ly93b3JrZ3JlZW4ud2ViZXguY29tL3dvcmtncmVlbi9qLnBocD9NVElEPW00NDA1ZGM1MWNk ZTk1OWFmZDg1ZjQzYjkwNTQzNmM4YyIKCQkJCQkJCQkJCXN0eWxlPSJ0ZXh0LWRlY29yYXRpb246 bm9uZTtmb250LXNpemU6MTZweDtjb2xvcjojMDBBRkY5Ij4KCQkJCQkJCQkJCTxiPkpvaW4gV2Vi RXggbWVldGluZzwvYj4KCQkJCQkJCQkJPC9hPgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJ CQkJCQk8L3RhYmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8h aW1wb3J0YW50Ij4KCQkJCQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkIHN0 eWxlPSJwYWRkaW5nLXJpZ2h0OiA1cHg7Ij4KCQkJCQkJCQkJTWVldGluZyBudW1iZXI6CgkJCQkJ CQkJPC90ZD4KCQkJCQkJCQk8dGQ+ODI1IDc3NyA3MjIKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90 cj4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9InBhZGRpbmctcmlnaHQ6IDVweDsiPjwv dGQ+CgkJCQkJCQkJPHRkPjwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoKCgoJCgoJ PHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBw eCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48dGQgc3R5bGU9ImZvbnQtc2l6 ZToxNnB4Ij48Yj5Kb2luIGJ5IHBob25lPC9iPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjow cHgiPjx0ZD48Yj4xLTg3Ny02NjgtNDQ5MDwvYj4mbmJzcDtDYWxsLWluIHRvbGwtZnJlZSBudW1i ZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+PGI+MS00 MDgtNzkyLTYzMDA8L2I+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+ PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD5BY2Nlc3MgY29kZTombmJzcDs4MjUgNzc3 IDcyMjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48YSBocmVmPSJodHRwczov L3dvcmtncmVlbi53ZWJleC5jb20vd29ya2dyZWVuL2dsb2JhbGNhbGxpbi5waHA/c2VydmljZVR5 cGU9TUMmRUQ9MzE1NjczMTIyJnRvbGxGcmVlPTEiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9u ZTtmb250LXNpemU6MTNweDtjb2xvcjojMDBBRkY5Ij5HbG9iYWwgY2FsbC1pbiBudW1iZXJzPC9h PiZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9w ZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZiIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25l O2ZvbnQtc2l6ZToxM3B4O2NvbG9yOiMwMEFGRjk7Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmlj dGlvbnM8L2E+PC90ZD48L3RyPjwvdGFibGU+CgoJCQkJCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUt aGVpZ2h0OjIwcHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3Rh YmxlPjx0YWJsZT48dHI+PHRkIHN0eWxlPSJmb250LXNpemU6MTNweCI+PGEgaHJlZj0iaHR0cHM6 Ly93b3JrZ3JlZW4ud2ViZXguY29tL3dvcmtncmVlbi9qLnBocD9NVElEPW1iYmQxYTczOTY3ODVk YzJkZTUwZjNmYzA5NDA1OGE2MCIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMw MEFGRjk7IGZvbnQtc2l6ZToxM3B4Ij5BZGQgdGhpcyBtZWV0aW5nPC9hPiB0byB5b3VyIGNhbGVu ZGFyLjwvdGQ+PC90cj48L3RhYmxlPgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBw eDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgo8dGFi bGU+CiAgICA8dHI+CiAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTNweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7Ij4KICAgICAgICBDYW4ndCBqb2luIHRoZSBtZWV0aW5n PwogICAgIAk8YSBocmVmPSJodHRwczovL3dvcmtncmVlbi53ZWJleC5jb20vd29ya2dyZWVuL21j IiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjEzcHg7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6IzAwQUZGOTtmb250LWNvbG9yOiMwMEFGRjk7Ij4KICAgICAgICAJQ29udGFj dCBzdXBwb3J0LjwvYT4KCQk8L3RkPgogICAgPC90cj4KPC90YWJsZT4KPHRhYmxlPjx0ciBzdHls ZT0ibGluZS1oZWlnaHQ6IDEwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoxMHB4Ij4mbmJzcDs8L3Rk PjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHls ZT0iZm9udC1zaXplOjEycHg7Y29sb3I6ICNBMEEwQTA7Ij4KCQkJCQkJCQkJSU1QT1JUQU5UIE5P VElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFu ZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRl ZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmlu ZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRp bmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91 ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLjwvdGQ+ CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoJCQkJPC90ZD4KCQkJPC90cj4KCQk8L3RhYmxl PgoJPC90ZD4KICAgPC90cj4KPC90YWJsZT4KCjwvYm9keT4= ------=_Part_14789_923615475.1442180865237-- ------=_Part_14788_1795267975.1442180865237 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86dG9vbHMtZGV2ZWxvcG1lbnRAaWV0Zi5vcmcKT1JH QU5JWkVSO0NOPSJSYXkgUGVsbGV0aWVyIjpNQUlMVE86cnBlbGxldGllckBpc29jLm9yZwpEVFNU QVJUO1RaSUQ9IkVhc3Rlcm4gVGltZSI6MjAxNTA5MTVUMTMwMDAwCkRURU5EO1RaSUQ9IkVhc3Rl cm4gVGltZSI6MjAxNTA5MTVUMTQwMDAwCkxPQ0FUSU9OOmh0dHBzOi8vd29ya2dyZWVuLndlYmV4 LmNvbS93b3JrZ3JlZW4KVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxNDQyMTgwODY1ClVJRDoxOGYw OGNmYy1hZDI2LTQxMjUtOWQxNC1kZmRmODI0N2NjZGUKRFRTVEFNUDoyMDE1MDkxNVQxNzAwMDBa CkRFU0NSSVBUSU9OOlxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly93b3JrZ3JlZW4u d2ViZXguY29tL3dvcmtncmVlbi9qLnBocD9NVElEPW0wYWI0YzllNDFiM2IxYjMyMWYyMzYwOTU1 ZDFiNDM2MlxuTWVldGluZyBudW1iZXI6IDgyNSA3NzcgNzIyXG5cblxuSk9JTiBCWSBQSE9ORVxu MS04NzctNjY4LTQ0OTAgQ2FsbC1pbiB0b2xsLWZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIFxuMS00 MDgtNzkyLTYzMDAgQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuQWNjZXNzIGNvZGU6 IDgyNSA3NzcgNzIyXG5cbkdsb2JhbCBjYWxsLWluIG51bWJlcnM6XG5odHRwczovL3dvcmtncmVl bi53ZWJleC5jb20vd29ya2dyZWVuL2dsb2JhbGNhbGxpbi5waHA/c2VydmljZVR5cGU9TUMmRUQ9 MzE1NjczMTIyJnRvbGxGcmVlPTFcblxuVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiBc bmh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmXG5cblxu XG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZTpcbmh0dHBzOi8v d29ya2dyZWVuLndlYmV4LmNvbS93b3JrZ3JlZW4vbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQ bGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVy IGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGlj aCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMg c2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElm IHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNl cm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVT QztGTVRUWVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxC Uj4gPEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vd29y a2dyZWVuLndlYmV4LmNvbS93b3JrZ3JlZW4vai5waHA/TVRJRD1tMGFiNGM5ZTQxYjNiMWIzMjFm MjM2MDk1NWQxYjQzNjIiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlh bCI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9GT05UPjwvYT4JCQk8dGFibGU+CQkJCTx0cj4JCQkJCTx0 ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRp bmcgbnVtYmVyOjwvRk9OVD4JCQkJCTwvdGQ+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIg Q09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj44MjUgNzc3IDcyMjwvRk9OVD4JCQkJCTwvdGQ+ CQkJCTwvdHI+CQkJPC90YWJsZT4JCQkJCTwvRk9OVD48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklB TCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwi PjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9u ZTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJh cmlhbCI+PHN0cm9uZz4xLTg3Ny02NjgtNDQ5MDwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbC1m cmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4xLTQwOC03OTItNjMwMDwvc3Ryb25n PiZuYnNwO0NhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48 Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkFjY2VzcyBjb2RlOiA4 MjUgNzc3IDcyMjwvRk9OVD4mbmJzcDsgPEJSPjxhIGhyZWY9Imh0dHBzOi8vd29ya2dyZWVuLndl YmV4LmNvbS93b3JrZ3JlZW4vZ2xvYmFsY2FsbGluLnBocD9zZXJ2aWNlVHlwZT1NQyZFRD0zMTU2 NzMxMjImdG9sbEZyZWU9MSI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFy aWFsIj5HbG9iYWwgY2FsbC1pbiBudW1iZXJzPC9GT05UPjwvYT48Rk9OVCBTSVpFPSIxIiBGQUNF PSJBUklBTCI+Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzwvRk9OVD48YSBocmVmPSJodHRwOi8v d3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZiI+PEZPTlQgU0laRT0i MSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFsIj5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmlj dGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsgPEJSPjwvRk9OVD48QlI+PEJSPgkmbmJzcDs8QlI+CTxG T05UIFNJWkU9IjEiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+CQkJCUNhbid0IGpvaW4g dGhlIG1lZXRpbmc/PC9GT05UPgk8YSBocmVmPSJodHRwczovL3dvcmtncmVlbi53ZWJleC5jb20v d29ya2dyZWVuL21jIj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFs Ij5Db250YWN0IHN1cHBvcnQuPC9GT05UPjwvYT4JJm5ic3A7PEJSPiZuYnNwOzxCUj48Rk9OVCBD T0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9SVEFOVCBOT1RJQ0U6IFBs ZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIg aW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNo IG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBz ZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYg eW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2Vy bnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48L0ZPTlQ+PC9GT05U PgpTVU1NQVJZOlRvb2xzIENtdGUKUFJJT1JJVFk6NQpDTEFTUzpQVUJMSUMKQkVHSU46VkFMQVJN ClRSSUdHRVI6LVBUNU0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJUFRJT046UmVtaW5kZXIKRU5EOlZB TEFSTQpFTkQ6VkVWRU5UCkVORDpWQ0FMRU5EQVIK ------=_Part_14788_1795267975.1442180865237-- From nobody Mon Sep 14 09:16:27 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933BF1B32CF for ; Mon, 14 Sep 2015 09:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.888 X-Spam-Level: X-Spam-Status: No, score=-100.888 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk-q4EAzj_z8 for ; Mon, 14 Sep 2015 09:16:18 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 466B91A1B95 for ; Mon, 14 Sep 2015 09:16:18 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 3643B1E59FE for ; Mon, 14 Sep 2015 09:15:46 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by c8a.amsl.com (Postfix) with ESMTPSA id 059211E59FB for ; Mon, 14 Sep 2015 09:15:46 -0700 (PDT) Received: by oiww128 with SMTP id w128so79372147oiw.2 for ; Mon, 14 Sep 2015 09:16:17 -0700 (PDT) X-Received: by 10.202.78.82 with SMTP id c79mr12118921oib.15.1442247377497; Mon, 14 Sep 2015 09:16:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.102.71 with HTTP; Mon, 14 Sep 2015 09:15:56 -0700 (PDT) In-Reply-To: <14fc7535b48.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> References: <55F2EAA4.3040503@labn.net> <55F31680.6080100@labn.net> <14fc7535b48.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Glen Date: Mon, 14 Sep 2015 09:15:56 -0700 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a1134e0669d35e7051fb7624d Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 16:16:25 -0000 --001a1134e0669d35e7051fb7624d Content-Type: text/plain; charset=UTF-8 Hi Lou - I"m trying to follow this... but in the thread you link to, and the 4/1 response you cite, it seems that Google is talking about the manual import of ICS files, and saying that it is fixed, which it is. I can manually import the ICS file, and the timezones are all correct on my Google Calendar. It seems that the problem only occurs with calendar subscriptions. In addition, you mention someone removing UTC times from the ICS... When I do a survey of the exported ICS, it seems that about half the times are in UTC format (e.g. DTSTART:20131219T150000Z), and the other roughly half appear to have time zone specifiers. (e.g. DTSTART;TZID=America/New_York:20150910T120000). I do not have any way of automatically making the calendar server remove all the "Z" times from its feed, and converting them to some time of local time - that is a function of each calendar item's creation and time zone settings. Interestingly, the item in question - the one malfunctioning - is the one I cited above, and it is *not* a "Z" time, but is in fact a localized timezone time. I reviewed the file output, and compared them to 2445/5545, and the output seems to be exactly compliant. We also have a properly-constructed VTIMEZONE stanza for it, and it is, as already cited, working for all other platforms (including Google's manual import.) So I'm still in the same place - our server is functioning, and functioning correctly, and RFC-compliant, and although I can confirm that Google is mangling this on import, I do not have any connections to Google that would enable me to "run this down..." much as I, too, would like to see this solved for their platform. I am open to any thoughts or suggestions... Do we know anyone at Google who participates in the IETF that might have some access to work on this, for example? Glen On Sun, Sep 13, 2015 at 8:29 AM, Lou Berger wrote: > Glenn, > > Looks like others have seen similar issues and worked with Google to > resolve, see links below. Given that there will likely be other Google > users of the ietf ical server it's probably worth running this to ground... > > Lou > > - https://productforums.google.com/forum/m/#!topic/calendar/GouovR3g4LY. > Look at the 4/1 response. > > - I lost the link, but someone solve the issues by removing any Z (utc) > based times from the ics > > > > > On September 11, 2015 2:00:09 PM Lou Berger wrote: > > another data point: >> https://ical.ietf.org/public.php/IAOC/finance >> >> works fine... >> >> On 9/11/2015 1:00 PM, Glen wrote: >> >>> Here's an interesting data point: >>> >>> If I download the file at the >>> https://ical.ietf.org/public.php/IAOC/calendar URL manually, and save >>> it as an ICS file on my desktop, and then I "Import" that file into >>> Google, the times display correctly. >>> >>> It is only if I ask Google to "subscribe" to the URL in live-feed mode >>> that it seems to incorrectly compute the times. >>> >> >> >> >>> As there is no difference in the data flow or what is pulled (since >>> the Calendar server sends everything via HTTP in the same way), I >>> wonder if something in Google's subscription processor is tripping on >>> something somewhere. >>> >>> That's not a solution - because you obviously want the live feed - but >>> it does provide an additional point of validation, if you like, of the >>> data. >>> >>> Glen >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Sep 11, 2015 at 9:52 AM, Glen >> > wrote: >>> >>> Hi Lou - >>> >>> AMS (ietf-action@ietf.org ) would be >>> the correct place to report a problem with the calendar *server* - >>> for example, if the calendar server were down, or you couldn't get >>> access, or something like that. >>> >>> But I confess I have no idea how or where to "report" the problem >>> you're encountering. >>> >>> When I view the feed you mention, I see the meeting coded as: >>> >>> DTEND;TZID=America/New_York:20150910T130000 >>> DTSTART;TZID=America/New_York:20150910T120000 >>> >>> So the calendar server appears to be delivering it correctly, as >>> you point out. >>> >>> The question seems to be why Google calendar is misinterpreting >>> the coding here. >>> >>> I also use Gogole calendar, and it is also misinterpreting the >>> coding for me.... but I cannot tell why, nor would I know to whom >>> that should be reported. >>> >>> I welcome thoughts on this matter! >>> >>> Glen >>> Glen Barney >>> IT Director >>> AMS (IETF Secretariat) >>> >>> >>> >>> On Fri, Sep 11, 2015 at 7:52 AM, Lou Berger >> > wrote: >>> >>> So what's the right way to report an issue with ical.ietf.org >>> ? >>> >>> I see an issue with a meeting from yesterday 9/10/15 on >>> https://ical.ietf.org/public.php/IAOC/calendar and it looks >>> like the >>> issues is also there for future meetings. >>> >>> The meeting correctly shows in Thunderbird as occurring at >>> noon ET, but >>> on google calendar it shows at 10am ET. Interesting, this has >>> not been >>> an issue for other calendars, e.g., finance. >>> >>> Thanks, >>> Lou >>> >>> >>> >>> _______________________________________________ >>> TOOLS-DEVELOPMENT mailing list >>> TOOLS-DEVELOPMENT@ietf.org >>> https://www.ietf.org/mailman/listinfo/tools-development >>> >>> >>> >>> >> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >> >> > > --001a1134e0669d35e7051fb7624d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lou -

I= "m trying to follow this... but in the thread you link to, and the 4/1= response you cite, it seems that Google is talking about the manual import= of ICS files, and saying that it is fixed, which it is.=C2=A0 I can manual= ly import the ICS file, and the timezones are all correct on my Google Cale= ndar. =C2=A0 It seems that the problem only occurs with calendar subscripti= ons.

In addition, you mention someone removing UTC times= from the ICS...=C2=A0 When I do a survey of the exported ICS, it seems tha= t about half the times are in UTC format (e.g. DTSTART:20131219T150000Z), a= nd the other roughly half appear to have time zone specifiers.=C2=A0 (e.g.= =C2=A0 DTSTART;TZID=3DAmerica/New_York:20150910T120000).=C2=A0 I do not hav= e any way of automatically making the calendar server remove all the "= Z" times from its feed, and converting them to some time of local time= - that is a function of each calendar item's creation and time zone se= ttings.

Interestingly, the item in question - the one malfunct= ioning - is the one I cited above, and it is *not* a "Z" time, bu= t is in fact a localized timezone time.=C2=A0 I reviewed the file output, a= nd compared them to 2445/5545, and the output seems to be exactly compliant= .=C2=A0 We also have a properly-constructed VTIMEZONE stanza for it, and it= is, as already cited, working for all other platforms (including Google= 9;s manual import.)

So I'm still in the same place - our s= erver is functioning, and functioning correctly, and RFC-compliant, and alt= hough I can confirm that Google is mangling this on import, I do not have a= ny connections to Google that would enable me to "run this down...&quo= t; much as I, too, would like to see this solved for their platform.
I am open to any thoughts or suggestions... Do we know anyone at Goo= gle who participates in the IETF that might have some access to work on thi= s, for example?

Glen


On Sun, Sep 13,= 2015 at 8:29 AM, Lou Berger <lberger@labn.net> wrote:
Glenn,

Looks like others have seen similar issues and worked with Google to resolv= e, see links below. Given that there will likely be other Google users of t= he ietf ical server it's probably worth running this to ground...

Lou

- https://productforums.google.= com/forum/m/#!topic/calendar/GouovR3g4LY. Look at the 4/1 response.

- I lost the link, but someone solve the issues by removing any Z (utc) bas= ed times from the ics




On September 11, 2015 2:00:09 PM Lou Berger <lberger@labn.net> wrote:

another data point:
https://ical.ietf.org/public.php/IAOC/finance

works fine...

On 9/11/2015 1:00 PM, Glen wrote:
Here's an interesting data point:

If I download the file at the
https://ical.ietf.org/public.php/IAOC/calendar URL= manually, and save
it as an ICS file on my desktop, and then I "Import" that file in= to
Google, the times display correctly.

It is only if I ask Google to "subscribe" to the URL in live-feed= mode
that it seems to incorrectly compute the times.



As there is no difference in the data flow or what is pulled (since
the Calendar server sends everything via HTTP in the same way), I
wonder if something in Google's subscription processor is tripping on something somewhere.

That's not a solution - because you obviously want the live feed - but<= br> it does provide an additional point of validation, if you like, of the
data.

Glen







On Fri, Sep 11, 2015 at 9:52 AM, Glen <glen@amsl.com
<mailto:glen@amsl.com= >> wrote:

=C2=A0 =C2=A0 Hi Lou -

=C2=A0 =C2=A0 AMS (ietf-action@ietf.org <mailto:ietf-action@ietf.org>) would be
=C2=A0 =C2=A0 the correct place to report a problem with the calendar *serv= er* -
=C2=A0 =C2=A0 for example, if the calendar server were down, or you couldn&= #39;t get
=C2=A0 =C2=A0 access, or something like that.

=C2=A0 =C2=A0 But I confess I have no idea how or where to "report&quo= t; the problem
=C2=A0 =C2=A0 you're encountering.

=C2=A0 =C2=A0 When I view the feed you mention, I see the meeting coded as:=

=C2=A0 =C2=A0 DTEND;TZID=3DAmerica/New_York:20150910T130000
=C2=A0 =C2=A0 DTSTART;TZID=3DAmerica/New_York:20150910T120000

=C2=A0 =C2=A0 So the calendar server appears to be delivering it correctly,= as
=C2=A0 =C2=A0 you point out.

=C2=A0 =C2=A0 The question seems to be why Google calendar is misinterpreti= ng
=C2=A0 =C2=A0 the coding here.

=C2=A0 =C2=A0 I also use Gogole calendar, and it is also misinterpreting th= e
=C2=A0 =C2=A0 coding for me.... but I cannot tell why, nor would I know to = whom
=C2=A0 =C2=A0 that should be reported.

=C2=A0 =C2=A0 I welcome thoughts on this matter!

=C2=A0 =C2=A0 Glen
=C2=A0 =C2=A0 Glen Barney
=C2=A0 =C2=A0 IT Director
=C2=A0 =C2=A0 AMS (IETF Secretariat)



=C2=A0 =C2=A0 On Fri, Sep 11, 2015 at 7:52 AM, Lou Berger <lberger@labn.net
=C2=A0 =C2=A0 <mailto:lberger@labn.net>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 So what's the right way to report an issue = with = ical.ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://ical.ietf.org>?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I see an issue with a meeting from yesterday 9/= 10/15 on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://ical.ietf.org/publ= ic.php/IAOC/calendar and it looks
=C2=A0 =C2=A0 =C2=A0 =C2=A0 like the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 issues is also there for future meetings.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The meeting correctly shows in Thunderbird as o= ccurring at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 noon ET, but
=C2=A0 =C2=A0 =C2=A0 =C2=A0 on google calendar it shows at 10am ET.=C2=A0 I= nteresting, this has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 not been
=C2=A0 =C2=A0 =C2=A0 =C2=A0 an issue for other calendars, e.g., finance.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Lou



=C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TOOLS-DEVELOPMENT mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TOOLS-DEVELOPMENT@ietf.org <mailto:TOOLS-DEVELOPMENT@ietf.org<= /a>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.= org/mailman/listinfo/tools-development





_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVEL= OPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment




--001a1134e0669d35e7051fb7624d-- From nobody Mon Sep 14 13:39:17 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8C21B42CE for ; Mon, 14 Sep 2015 13:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVWPARwPVdtQ for ; Mon, 14 Sep 2015 13:39:08 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEEE1B54AE for ; Mon, 14 Sep 2015 13:39:08 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id D365AF2412B; Mon, 14 Sep 2015 16:38:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id DetwDf3kcbCc; Mon, 14 Sep 2015 16:37:40 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2BBACF24153; Mon, 14 Sep 2015 16:38:37 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 14 Sep 2015 16:38:25 -0400 Message-Id: <63FE36B9-89CA-40FC-99C2-0260F4136EC2@vigilsec.com> To: IETF Tools Development Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: Subject: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 15 September 2015 at 13:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 20:39:10 -0000 Tools Call Agenda -- 15 September 2015 at 13:00 Eastern 1. Datatracker Projects - Expected Datatracker Releases -- Robert and Henrik -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan - Submission tool automatically generates text from XML -- Robert - Liaison Tool improvements -- Robert - Performance improvements -- Henrik - Review Tracking -- Robert - iCal for face-to-face and virtual interim meetings -- Robert - Making email sending table driven -- Henrik and Robert 2. Community & Other Projects - Improve infrastructure for finding and fetching artifacts -- Robert - IETF Website Makeover -- Joe and Greg 3. RFC Services Projects - RFC Editor Website Makeover -- Alice and Heather - RSE's Design Teams -- Heather - RFC Format-related SOWs -- Robert 4. Transition of Mission Critical Tools - Moving issue trackers and wikis for IETF WGs on ietf.org 5. Server Infrastructure - IMAP access to the email archives -- Robert - VM Architecture for Servers -- Robert 6. IDIQ Contractors - RFP for more IDIQ contractors -- Ray 7. Brainstorming - What can we do that will make things better for the community, the Secretariat, the RFC Editor, or IANA? 8. Parking Lot - Mentor Support Tool -- AMS - RFC Editor automatic stats and reporting RFP -- Heather - Author information for very old I-Ds in the datatracker -- Robert - Replace I-Ds in proceedings with links to archive copy? - Can the test process for the NomCom Tool be more comprehensive? 9. AOB From nobody Mon Sep 14 13:52:43 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5401A88A0 for ; Mon, 14 Sep 2015 13:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwMaDgPPj54k for ; Mon, 14 Sep 2015 13:52:40 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BB31A6F66 for ; Mon, 14 Sep 2015 13:51:51 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8EKpp61059226 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 14 Sep 2015 15:51:51 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local To: Russ Housley , IETF Tools Development References: <63FE36B9-89CA-40FC-99C2-0260F4136EC2@vigilsec.com> From: Robert Sparks Message-ID: <55F73362.7060805@nostrum.com> Date: Mon, 14 Sep 2015 15:51:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <63FE36B9-89CA-40FC-99C2-0260F4136EC2@vigilsec.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 15 September 2015 at 13:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 20:52:42 -0000 minor suggested bashing: On 9/14/15 3:38 PM, Russ Housley wrote: > Tools Call Agenda -- 15 September 2015 at 13:00 Eastern > > 1. Datatracker Projects > - Expected Datatracker Releases -- Robert and Henrik > -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan > - Submission tool automatically generates text from XML -- Robert > - Liaison Tool improvements -- Robert > - Performance improvements -- Henrik > - Review Tracking -- Robert I'd like to add here: - Author Statistics -- Russ - Tracking Internet-Draft Manual Post Requests -- Robert > - iCal for face-to-face and virtual interim meetings -- Robert can we replace that one with: - Interim meeting management -- Robert > - Making email sending table driven -- Henrik and Robert > > 2. Community & Other Projects > - Improve infrastructure for finding and fetching artifacts -- Robert > - IETF Website Makeover -- Joe and Greg > > 3. RFC Services Projects > - RFC Editor Website Makeover -- Alice and Heather > - RSE's Design Teams -- Heather > - RFC Format-related SOWs -- Robert > > 4. Transition of Mission Critical Tools > - Moving issue trackers and wikis for IETF WGs on ietf.org > > 5. Server Infrastructure > - IMAP access to the email archives -- Robert > - VM Architecture for Servers -- Robert > > 6. IDIQ Contractors > - RFP for more IDIQ contractors -- Ray > > 7. Brainstorming > - What can we do that will make things better for the community, > the Secretariat, the RFC Editor, or IANA? > > 8. Parking Lot > - Mentor Support Tool -- AMS > - RFC Editor automatic stats and reporting RFP -- Heather > - Author information for very old I-Ds in the datatracker -- Robert > - Replace I-Ds in proceedings with links to archive copy? > - Can the test process for the NomCom Tool be more comprehensive? > > 9. AOB > From nobody Mon Sep 14 14:02:05 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF8A1B4607 for ; Mon, 14 Sep 2015 14:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX3TfoeaZJXZ for ; Mon, 14 Sep 2015 14:02:00 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD391B5042 for ; Mon, 14 Sep 2015 14:00:42 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id F0FF49A4017; Mon, 14 Sep 2015 17:00:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id NBhUUqsnG7XO; Mon, 14 Sep 2015 16:59:14 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2F0869A400D; Mon, 14 Sep 2015 17:00:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <55F73362.7060805@nostrum.com> Date: Mon, 14 Sep 2015 16:59:59 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <63FE36B9-89CA-40FC-99C2-0260F4136EC2@vigilsec.com> <55F73362.7060805@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF Tools Development Subject: [TOOLS-DEVELOPMENT] Revised Tools Call Agenda -- 15 September 2015 at 13:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 21:02:02 -0000 Tools Call Agenda -- 15 September 2015 at 13:00 Eastern 1. Datatracker Projects - Expected Datatracker Releases -- Robert and Henrik -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan - Submission tool automatically generates text from XML -- Robert - Liaison Tool improvements -- Robert - Performance improvements -- Henrik - Review Tracking -- Robert - Tracking Internet-Draft Manual Post Requests -- Robert - Author Statistics -- Russ - Interim Meeting Management -- Robert - Making email sending table driven -- Henrik and Robert 2. Community & Other Projects - Improve infrastructure for finding and fetching artifacts -- Robert - IETF Website Makeover -- Joe and Greg 3. RFC Services Projects - RFC Editor Website Makeover -- Alice and Heather - RSE's Design Teams -- Heather - RFC Format-related SOWs -- Robert 4. Transition of Mission Critical Tools - Moving issue trackers and wikis for IETF WGs on ietf.org 5. Server Infrastructure - IMAP access to the email archives -- Robert - VM Architecture for Servers -- Robert 6. IDIQ Contractors - RFP for more IDIQ contractors -- Ray 7. Brainstorming - What can we do that will make things better for the community, the Secretariat, the RFC Editor, or IANA? 8. Parking Lot - Mentor Support Tool -- AMS - RFC Editor automatic stats and reporting RFP -- Heather - Author information for very old I-Ds in the datatracker -- Robert - Replace I-Ds in proceedings with links to archive copy? - Can the test process for the NomCom Tool be more comprehensive? 9. AOB From nobody Mon Sep 14 17:23:29 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07601A8939 for ; Mon, 14 Sep 2015 17:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6w6kshKHSoir for ; Mon, 14 Sep 2015 17:23:27 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1271AD379 for ; Mon, 14 Sep 2015 17:23:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 9976C1E59DF for ; Mon, 14 Sep 2015 17:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IQyyKCzszv7 for ; Mon, 14 Sep 2015 17:22:53 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (207-118-88-71.dyn.centurytel.net [207.118.88.71]) by c8a.amsl.com (Postfix) with ESMTPSA id 102361E59D3 for ; Mon, 14 Sep 2015 17:22:53 -0700 (PDT) From: "Heather Flanagan (RFC Series Editor)" To: tools-development@ietf.org Message-ID: <55F7651D.3090809@rfc-editor.org> Date: Mon, 14 Sep 2015 17:23:57 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [TOOLS-DEVELOPMENT] RSE update for the Tools Dev team call, 15 Sep 2015 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 00:23:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 In case speaking turns out to be more challenging than one would hope as I learn to love the braces installed today. - ---- Format Design Team update Julian is working on the updates to xml2rfc v2, though httpbis-auth has just reached AUTH48 and he's likely to give that priority. Of the v3-related drafts, I am waiting on the PDF (two TBDs in the draft to be resolved) and the SVG draft (RNC required). I do not have a firm timeline from the authors on those drafts regarding when they'll be ready to go. Noting that the entire bundle of nine drafts are moving as a cluster, I did give the RSOC a preview into where things stand with the drafts, and Joel Halpern has done a review of the HTML and plain-text drafts. Updates will be forthcoming. The RSOC has asked for a requested reading order list and set check-points around the draft reviews; it's too big a bundle to just send out for review without both context and assistance in staying organized through the review. I will be putting that together as part of the official review request to the RSOC, and will send something similar to the IAB and the community when these drafts reach those groups. RFC Editor Website update The RSOC has reviewed the new website and offered several useful suggestions. I met with Sandy and Alice on Friday to review those suggestions, and a Alice will be working on modifications this week. Of particular note, AMS has hired a designer to look specifically at the Info pages; as the primary landing page for RFCs (from the RFC Editor's perspective), making sure they show us at our best is important. We expect to remove the password lock on the revised website soon, and at that point we will send a note to the IAB, IESG, and the Tools Committee to give them a chance to see the changes. RPC Programmer (.5 FTE) work status These aren't items that fall under the Tools Team process, but just to keep you informed about what's going on with the RPC programmer: In progress: - - add mailing list to info pages - - RFC 10K bug analysis (as time permits; this is not urgent) Next on the list: - - improve cluster_info.php so it's sorted by state - - audit of internal archive of material, making sure that what is in the public space matches the archive. (To clarify this point, there is a public repository and an internal repository. The latter contains the source files and the original approved I-D, in addition to the published RFC, as per a requirement in the SOW. Since the archiving process has grown rather organically over the years, some work needs to be done to go back and make sure everything is in place as per current best practice.) Recently completed: - - fixed bug in rfcmeta.php (info page) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJV92UdAAoJEER/xjINbZoG2UcH/iIB5vppxqsd4iHKrapY+WzI +ocUqhxMW4+Y42nvZDIOP3ZhKdRgbErTP6ZreoRkZhRFLgrvSlS0uZ8fVaQgf813 wF68x2vzHM9LtE7VUsCFT49H37quSlS4aiDDe6Sn0pde1Hpx+jTcUdTu452fAeWe feRhu/pVgZ/v7PT0GTOFUOYWxa4ySYJFyT3Ccexb878WQiT0Sv3KrtEZjT7VIZSd SW701z5kDA/fFhbmh3Y1HlNDR/ah1Rk8Cuaap+us1HaHcgWIcPox2OTQ0PGLkI61 WktTCtec+FQ5V6eQL9dws8tDQRBGnPga5Ia2Jnr7tkc6EaXe4srmC+gbfxaw6ko= =Ur31 -----END PGP SIGNATURE----- From nobody Tue Sep 15 08:40:41 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7655B1A1A31 for ; Tue, 15 Sep 2015 08:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.587 X-Spam-Level: X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnzCOUQkzhFV for ; Tue, 15 Sep 2015 08:39:24 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id C6F481A1A2F for ; Tue, 15 Sep 2015 08:39:20 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id D314A1E5A2A for ; Tue, 15 Sep 2015 08:38:44 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by c8a.amsl.com (Postfix) with ESMTPSA id AFC2D1E5A2F for ; Tue, 15 Sep 2015 08:38:44 -0700 (PDT) Received: by obbzf10 with SMTP id zf10so82604515obb.2 for ; Tue, 15 Sep 2015 08:39:20 -0700 (PDT) X-Received: by 10.60.125.8 with SMTP id mm8mr19331912oeb.73.1442331560015; Tue, 15 Sep 2015 08:39:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.102.71 with HTTP; Tue, 15 Sep 2015 08:39:00 -0700 (PDT) From: Glen Date: Tue, 15 Sep 2015 08:39:00 -0700 Message-ID: To: Glen Barney Content-Type: multipart/alternative; boundary=047d7b339b21487fbb051fcafc42 Archived-At: X-Mailman-Approved-At: Tue, 15 Sep 2015 08:40:37 -0700 Subject: [TOOLS-DEVELOPMENT] Mailman subscribe attacks redux X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 15:39:25 -0000 --047d7b339b21487fbb051fcafc42 Content-Type: text/plain; charset=UTF-8 Good day: You may recall that we have been experiencing an attack against Mailman, in which a large number of automated subscribe requests to addresses of the form "someroot+somesuffix@somedomain.org" are being sent by compromised computers worldwide to the IETF's Mailman server. A form of Denial-of-Service, this attack has affected our lists and list admins, and has caused us to generate a ton of outgoing/response mail that should not be sent in the first place. The volume of the attack has previously been low and manageable. However, overnight, the level of subscribe attacks against the IETF Mailman server increased dramatically, to the point that Mailman's bounce processors were getting overwhelmed and dying, triggering alarms and compromising mail operations. To answer some obvious questions: This attack is distributed. Over 4000 IP addresses from just last night were participating. The addresses cannot be blocked by normal automated means on our server, because we use Cloudflare. We would have to feed the addresses into Cloudflare, and that is a laborious, manual process that does not scale. And as we learned from previous interactions with Cloudflare, there is not much that can be done about attacks of this type from their side. When this began, we provided expressions and guidance that would allow list owners to ban these addresses on a per-list basis; alas, the adoption rate of those recommendations was too low, and the attack increased too quickly. Because a service outage is imminent, I have now instructed the servers to reject all subscribe requests from all email addresses containing a "+" sign. Users posting subscribe requests containing a plus sign are referred to the secretariat to complete their request. The request is halted after that message is displayed, and no further processing, notification of list owners, or outgoing mail is generated: the request is deleted as an error. Users already subscribed to lists using valid addresses of this form are not affected. They can still manage and remove their subscriptions directly. This only affects new requests... our server will no longer attempt to process new requests containing + signs. This behavior is not optional or per-list, it applies server-wide and cannot be overridden on a per-list basis. While I note that some users (roughly 1011 "+" addresses currently exist in Mailman, out of the 77809 total subscribers present at the moment) use this address form for filtering, I note that Mailman also provides list-based RFC2369/2919 headers that allow for filtering as well. And I wish to make clear again that we are not *refusing* subscriptions of this type - we are just referring them for manual processing. These changes are deployed as of now, and are effective for all IETF mailing lists, regardless of list configuration settings. I apologize for the inconvenience this will cause to new users wanting this address format; however, the volume of the attack has left me with no other choice. As always, any questions, please let me know. Glen Glen Barney IT Director AMS (IETF Secretariat) --047d7b339b21487fbb051fcafc42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Goo= d day:

You may recall that we have been experiencing an attack again= st Mailman, in which a large number of automated subscribe requests to addr= esses of the form "someroot+somesuffix@somedomain.org" are being sent by comprom= ised computers worldwide to the IETF's Mailman server.=C2=A0 A form of = Denial-of-Service, this attack has affected our lists and list admins, and = has caused us to generate a ton of outgoing/response mail that should not b= e sent in the first place.

The volume of the attack has previously b= een low and manageable.=C2=A0 However, overnight, the level of subscribe at= tacks against the IETF Mailman server increased dramatically, to the point = that Mailman's bounce processors were getting overwhelmed and dying, tr= iggering alarms and compromising mail operations.

To answer so= me obvious questions:=C2=A0 This attack is distributed. Over 4000 IP addres= ses from just last night were participating.=C2=A0 The addresses cannot be = blocked by normal automated means on our server, because we use Cloudflare.= =C2=A0 We would have to feed the addresses into Cloudflare, and that is a l= aborious, manual process that does not scale.=C2=A0 And as we learned from = previous interactions with Cloudflare, there is not much that can be done a= bout attacks of this type from their side.

When this began, we= provided expressions and guidance that would allow list owners to ban thes= e addresses on a per-list basis; alas, the adoption rate of those recommend= ations was too low, and the attack increased too quickly.

Beca= use a service outage is imminent, I have now instructed the servers to reje= ct all subscribe requests from all email addresses containing a "+&quo= t; sign.=C2=A0 Users posting subscribe requests containing a plus sign are = referred to the secretariat to complete their request.=C2=A0 The request is= halted after that message is displayed, and no further processing, notific= ation of list owners, or outgoing mail is generated: the request is deleted= as an error.

Users already subscribed to lists using valid ad= dresses of this form are not affected.=C2=A0 They can still manage and remo= ve their subscriptions directly.=C2=A0 This only affects new requests... ou= r server will no longer attempt to process new requests containing + signs.= =C2=A0 This behavior is not optional or per-list, it applies server-wide an= d cannot be overridden on a per-list basis.

While I note that some = users (roughly 1011 "+" addresses currently exist in Mailman, out= of the 77809 total subscribers present at the moment) use this address for= m for filtering, I note that Mailman also provides list-based RFC2369/2919 = headers that allow for filtering as well.=C2=A0 And I wish to make clear ag= ain that we are not *refusing* subscriptions of this type - we are just ref= erring them for manual processing.

These changes are deployed = as of now, and are effective for all IETF mailing lists, regardless of list= configuration settings.=C2=A0

I apologize for the inconvenie= nce this will cause to new users wanting this address format; however, the = volume of the attack has left me with no other choice.

As alwa= ys, any questions, please let me know.

Glen
Glen Barn= ey
IT Director
AMS (IETF Secretariat)

--047d7b339b21487fbb051fcafc42-- From nobody Tue Sep 15 11:36:53 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B260B1A90C3 for ; Tue, 15 Sep 2015 11:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyUwBJuoHErJ for ; Tue, 15 Sep 2015 11:36:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 554851A90CF for ; Tue, 15 Sep 2015 11:36:43 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8FIag0L068432 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Tue, 15 Sep 2015 13:36:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local To: tools-development@ietf.org References: <55F7651D.3090809@rfc-editor.org> From: Robert Sparks Message-ID: <55F86535.8010008@nostrum.com> Date: Tue, 15 Sep 2015 13:36:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55F7651D.3090809@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] RSE update for the Tools Dev team call, 15 Sep 2015 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 18:36:45 -0000 Per today's call: Before the next tools call (13 Oct), please look over the RFC Format related SoWs with a fresh eye and help make sure they still properly reflect the content of the format design team drafts. The current versions of the SoWs are here: http://www.nostrum.com/~rjsparks/rfced/ RjS On 9/14/15 7:23 PM, Heather Flanagan (RFC Series Editor) wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > In case speaking turns out to be more challenging than one would hope > as I learn to love the braces installed today. > > > - ---- > Format Design Team update > Julian is working on the updates to xml2rfc v2, though httpbis-auth has > just reached AUTH48 and he's likely to give that priority. > Of the v3-related drafts, I am waiting on the PDF (two TBDs in the draft > to be resolved) and the SVG draft (RNC required). I do not have a firm > timeline from the authors on those drafts regarding when they'll be > ready to go. Noting that the entire bundle of nine drafts are moving as > a cluster, I did give the RSOC a preview into where things stand with > the drafts, and Joel Halpern has done a review of the HTML and > plain-text drafts. Updates will be forthcoming. > > The RSOC has asked for a requested reading order list and set > check-points around the draft reviews; it's too big a bundle to just > send out for review without both context and assistance in staying > organized through the review. I will be putting that together as part of > the official review request to the RSOC, and will send something similar > to the IAB and the community when these drafts reach those groups. > > > RFC Editor Website update > The RSOC has reviewed the new website and offered several useful > suggestions. I met with Sandy and Alice on Friday to review those > suggestions, and a Alice will be working on modifications this week. Of > particular note, AMS has hired a designer to look specifically at the > Info pages; as the primary landing page for RFCs (from the RFC Editor's > perspective), making sure they show us at our best is important. We > expect to remove the password lock on the revised website soon, and at > that point we will send a note to the IAB, IESG, and the Tools Committee > to give them a chance to see the changes. > > > RPC Programmer (.5 FTE) work status > These aren't items that fall under the Tools Team process, but just to > keep you informed about what's going on with the RPC programmer: > In progress: > - - add mailing list to info pages > - - RFC 10K bug analysis (as time permits; this is not urgent) > > Next on the list: > - - improve cluster_info.php so it's sorted by state > - - audit of internal archive of material, making sure that what is in > the public space matches the archive. (To clarify this point, there is > a public repository and an internal repository. The latter contains > the source files and the original approved I-D, in addition to the > published RFC, as per a requirement in the SOW. Since the archiving > process has grown rather organically over the years, some work needs > to be done to go back and make sure everything is in place as per > current best practice.) > > Recently completed: > - - fixed bug in rfcmeta.php (info page) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2 > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBCAAGBQJV92UdAAoJEER/xjINbZoG2UcH/iIB5vppxqsd4iHKrapY+WzI > +ocUqhxMW4+Y42nvZDIOP3ZhKdRgbErTP6ZreoRkZhRFLgrvSlS0uZ8fVaQgf813 > wF68x2vzHM9LtE7VUsCFT49H37quSlS4aiDDe6Sn0pde1Hpx+jTcUdTu452fAeWe > feRhu/pVgZ/v7PT0GTOFUOYWxa4ySYJFyT3Ccexb878WQiT0Sv3KrtEZjT7VIZSd > SW701z5kDA/fFhbmh3Y1HlNDR/ah1Rk8Cuaap+us1HaHcgWIcPox2OTQ0PGLkI61 > WktTCtec+FQ5V6eQL9dws8tDQRBGnPga5Ia2Jnr7tkc6EaXe4srmC+gbfxaw6ko= > =Ur31 > -----END PGP SIGNATURE----- > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Tue Sep 15 20:36:09 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DF81B329A for ; Tue, 15 Sep 2015 20:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pkfca-8YJ2Aw for ; Tue, 15 Sep 2015 20:36:06 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id E17331B3291 for ; Tue, 15 Sep 2015 20:36:05 -0700 (PDT) Received: (qmail 4845 invoked by uid 0); 16 Sep 2015 03:36:03 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 16 Sep 2015 03:36:03 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id Hfbx1r00K2SSUrH01fc0pe; Tue, 15 Sep 2015 21:36:02 -0600 X-Authority-Analysis: v=2.1 cv=EbVbHpWC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=48vgC7mUAAAA:8 a=1XWaLZrsAAAA:8 a=jGqiy6jZAAAA:8 a=afGaKQp86K-Jo-YgO4IA:9 a=QEXdDO2ut3YA:10 a=G9WWXeuLwC8A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=oySTMWR7C/a4iOw7sCV/bMmSMO/IP8hPZqCKbGFSRjE=; b=1wI6GFnofn4cytiwNy8uIiXev//uKqwVrPoG3luo9Bzf0j52+3FXPzH1VAy2+7ztWsA9J92Y+NF6VIkIfpFKT/BZZVAjPhqRNTlhxVbMGcxTs7a2kFjAT35zI2pzLFLi; Received: from box313.bluehost.com ([69.89.31.113]:41013 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Zc3Vm-0000U4-6D; Tue, 15 Sep 2015 21:35:58 -0600 To: glen@amsl.com References: <55F2EAA4.3040503@labn.net> <55F31680.6080100@labn.net> <14fc7535b48.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <55F8E38F.7080901@labn.net> Date: Tue, 15 Sep 2015 23:35:43 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 03:36:08 -0000 Well in trying a test with removing Z I found something really interesting: All works well if the non-https version is used (http://ical.ietf.org/public.php/IAOC/calendar) Is there perhaps something odd on the server's time setting (assuming google is somehow using tls time...)? Lou On 9/14/2015 12:15 PM, Glen wrote: > Hi Lou - > > I"m trying to follow this... but in the thread you link to, and the > 4/1 response you cite, it seems that Google is talking about the > manual import of ICS files, and saying that it is fixed, which it is. > I can manually import the ICS file, and the timezones are all correct > on my Google Calendar. It seems that the problem only occurs with > calendar subscriptions. > > In addition, you mention someone removing UTC times from the ICS... > When I do a survey of the exported ICS, it seems that about half the > times are in UTC format (e.g. DTSTART:20131219T150000Z), and the other > roughly half appear to have time zone specifiers. (e.g. > DTSTART;TZID=America/New_York:20150910T120000). I do not have any way > of automatically making the calendar server remove all the "Z" times > from its feed, and converting them to some time of local time - that > is a function of each calendar item's creation and time zone settings. > > Interestingly, the item in question - the one malfunctioning - is the > one I cited above, and it is *not* a "Z" time, but is in fact a > localized timezone time. I reviewed the file output, and compared > them to 2445/5545, and the output seems to be exactly compliant. We > also have a properly-constructed VTIMEZONE stanza for it, and it is, > as already cited, working for all other platforms (including Google's > manual import.) > > So I'm still in the same place - our server is functioning, and > functioning correctly, and RFC-compliant, and although I can confirm > that Google is mangling this on import, I do not have any connections > to Google that would enable me to "run this down..." much as I, too, > would like to see this solved for their platform. > > I am open to any thoughts or suggestions... Do we know anyone at > Google who participates in the IETF that might have some access to > work on this, for example? > > Glen > > > On Sun, Sep 13, 2015 at 8:29 AM, Lou Berger > wrote: > > Glenn, > > Looks like others have seen similar issues and worked with Google > to resolve, see links below. Given that there will likely be other > Google users of the ietf ical server it's probably worth running > this to ground... > > Lou > > - > https://productforums.google.com/forum/m/#!topic/calendar/GouovR3g4LY > . > Look at the 4/1 response. > > - I lost the link, but someone solve the issues by removing any Z > (utc) based times from the ics > > > > > On September 11, 2015 2:00:09 PM Lou Berger > wrote: > > another data point: > https://ical.ietf.org/public.php/IAOC/finance > > works fine... > > On 9/11/2015 1:00 PM, Glen wrote: > > Here's an interesting data point: > > If I download the file at the > https://ical.ietf.org/public.php/IAOC/calendar URL > manually, and save > it as an ICS file on my desktop, and then I "Import" that > file into > Google, the times display correctly. > > It is only if I ask Google to "subscribe" to the URL in > live-feed mode > that it seems to incorrectly compute the times. > > > > > As there is no difference in the data flow or what is > pulled (since > the Calendar server sends everything via HTTP in the same > way), I > wonder if something in Google's subscription processor is > tripping on > something somewhere. > > That's not a solution - because you obviously want the > live feed - but > it does provide an additional point of validation, if you > like, of the > data. > > Glen > > > > > > > > On Fri, Sep 11, 2015 at 9:52 AM, Glen > >> wrote: > > Hi Lou - > > AMS (ietf-action@ietf.org > >) would be > the correct place to report a problem with the > calendar *server* - > for example, if the calendar server were down, or you > couldn't get > access, or something like that. > > But I confess I have no idea how or where to "report" > the problem > you're encountering. > > When I view the feed you mention, I see the meeting > coded as: > > DTEND;TZID=America/New_York:20150910T130000 > DTSTART;TZID=America/New_York:20150910T120000 > > So the calendar server appears to be delivering it > correctly, as > you point out. > > The question seems to be why Google calendar is > misinterpreting > the coding here. > > I also use Gogole calendar, and it is also > misinterpreting the > coding for me.... but I cannot tell why, nor would I > know to whom > that should be reported. > > I welcome thoughts on this matter! > > Glen > Glen Barney > IT Director > AMS (IETF Secretariat) > > > > On Fri, Sep 11, 2015 at 7:52 AM, Lou Berger > > >> > wrote: > > So what's the right way to report an issue with > ical.ietf.org > ? > > I see an issue with a meeting from yesterday > 9/10/15 on > https://ical.ietf.org/public.php/IAOC/calendar and > it looks > like the > issues is also there for future meetings. > > The meeting correctly shows in Thunderbird as > occurring at > noon ET, but > on google calendar it shows at 10am ET. > Interesting, this has > not been > an issue for other calendars, e.g., finance. > > Thanks, > Lou > > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/tools-development > > > > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > > > > From nobody Wed Sep 16 09:30:58 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778E01B344F for ; Wed, 16 Sep 2015 09:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.588 X-Spam-Level: X-Spam-Status: No, score=-103.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7Vdcyx2B9Gj for ; Wed, 16 Sep 2015 09:30:54 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 03A5F1B34CB for ; Wed, 16 Sep 2015 09:30:54 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id F166D1E5A22 for ; Wed, 16 Sep 2015 09:30:13 -0700 (PDT) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by c8a.amsl.com (Postfix) with ESMTPSA id C19E21E59EB for ; Wed, 16 Sep 2015 09:30:13 -0700 (PDT) Received: by obqa2 with SMTP id a2so153872320obq.3 for ; Wed, 16 Sep 2015 09:30:53 -0700 (PDT) X-Received: by 10.182.16.135 with SMTP id g7mr24487335obd.67.1442421053298; Wed, 16 Sep 2015 09:30:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.102.71 with HTTP; Wed, 16 Sep 2015 09:30:33 -0700 (PDT) In-Reply-To: <55F8E38F.7080901@labn.net> References: <55F2EAA4.3040503@labn.net> <55F31680.6080100@labn.net> <14fc7535b48.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55F8E38F.7080901@labn.net> From: Glen Date: Wed, 16 Sep 2015 09:30:33 -0700 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a11c338ec7fc347051fdfd2a6 Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 16:30:57 -0000 --001a11c338ec7fc347051fdfd2a6 Content-Type: text/plain; charset=UTF-8 Hi Lou - Not that I'm aware of.... ietfa:~ # date Wed Sep 16 09:28:34 PDT 2015 ietfa:~ # sntp -s pool.ntp.org 16 Sep 09:28:36 sntp[15416]: Started sntp 2015-09-16 09:28:38.235822 (+0800) -0.00297 +/- 0.028366 secs 2015-09-16 09:28:38.234173 (+0800) +0.005258 +/- 0.003143 secs 2015-09-16 09:28:38.241367 (+0800) +0.000079 +/- 0.025818 secs ietfa:~ # date Wed Sep 16 09:28:39 PDT 2015 We check the clocks as part of our weekly maintenance, and ensure they are synced to the global time servers. The above was a manual resync I ran just now - we seem to be on point there. Interesting find about the https:// though... Glen On Tue, Sep 15, 2015 at 8:35 PM, Lou Berger wrote: > Well in trying a test with removing Z I found something really interesting: > > All works well if the non-https version is used > (http://ical.ietf.org/public.php/IAOC/calendar) > > Is there perhaps something odd on the server's time setting (assuming > google is somehow using tls time...)? > > Lou > > > On 9/14/2015 12:15 PM, Glen wrote: > > Hi Lou - > > > > I"m trying to follow this... but in the thread you link to, and the > > 4/1 response you cite, it seems that Google is talking about the > > manual import of ICS files, and saying that it is fixed, which it is. > > I can manually import the ICS file, and the timezones are all correct > > on my Google Calendar. It seems that the problem only occurs with > > calendar subscriptions. > > > > In addition, you mention someone removing UTC times from the ICS... > > When I do a survey of the exported ICS, it seems that about half the > > times are in UTC format (e.g. DTSTART:20131219T150000Z), and the other > > roughly half appear to have time zone specifiers. (e.g. > > DTSTART;TZID=America/New_York:20150910T120000). I do not have any way > > of automatically making the calendar server remove all the "Z" times > > from its feed, and converting them to some time of local time - that > > is a function of each calendar item's creation and time zone settings. > > > > Interestingly, the item in question - the one malfunctioning - is the > > one I cited above, and it is *not* a "Z" time, but is in fact a > > localized timezone time. I reviewed the file output, and compared > > them to 2445/5545, and the output seems to be exactly compliant. We > > also have a properly-constructed VTIMEZONE stanza for it, and it is, > > as already cited, working for all other platforms (including Google's > > manual import.) > > > > So I'm still in the same place - our server is functioning, and > > functioning correctly, and RFC-compliant, and although I can confirm > > that Google is mangling this on import, I do not have any connections > > to Google that would enable me to "run this down..." much as I, too, > > would like to see this solved for their platform. > > > > I am open to any thoughts or suggestions... Do we know anyone at > > Google who participates in the IETF that might have some access to > > work on this, for example? > > > > Glen > > > > > > On Sun, Sep 13, 2015 at 8:29 AM, Lou Berger > > wrote: > > > > Glenn, > > > > Looks like others have seen similar issues and worked with Google > > to resolve, see links below. Given that there will likely be other > > Google users of the ietf ical server it's probably worth running > > this to ground... > > > > Lou > > > > - > > > https://productforums.google.com/forum/m/#!topic/calendar/GouovR3g4LY > > < > https://productforums.google.com/forum/m/#%21topic/calendar/GouovR3g4LY>. > > Look at the 4/1 response. > > > > - I lost the link, but someone solve the issues by removing any Z > > (utc) based times from the ics > > > > > > > > > > On September 11, 2015 2:00:09 PM Lou Berger > > wrote: > > > > another data point: > > https://ical.ietf.org/public.php/IAOC/finance > > > > works fine... > > > > On 9/11/2015 1:00 PM, Glen wrote: > > > > Here's an interesting data point: > > > > If I download the file at the > > https://ical.ietf.org/public.php/IAOC/calendar URL > > manually, and save > > it as an ICS file on my desktop, and then I "Import" that > > file into > > Google, the times display correctly. > > > > It is only if I ask Google to "subscribe" to the URL in > > live-feed mode > > that it seems to incorrectly compute the times. > > > > > > > > > > As there is no difference in the data flow or what is > > pulled (since > > the Calendar server sends everything via HTTP in the same > > way), I > > wonder if something in Google's subscription processor is > > tripping on > > something somewhere. > > > > That's not a solution - because you obviously want the > > live feed - but > > it does provide an additional point of validation, if you > > like, of the > > data. > > > > Glen > > > > > > > > > > > > > > > > On Fri, Sep 11, 2015 at 9:52 AM, Glen > > > >> wrote: > > > > Hi Lou - > > > > AMS (ietf-action@ietf.org > > > >) would be > > the correct place to report a problem with the > > calendar *server* - > > for example, if the calendar server were down, or you > > couldn't get > > access, or something like that. > > > > But I confess I have no idea how or where to "report" > > the problem > > you're encountering. > > > > When I view the feed you mention, I see the meeting > > coded as: > > > > DTEND;TZID=America/New_York:20150910T130000 > > DTSTART;TZID=America/New_York:20150910T120000 > > > > So the calendar server appears to be delivering it > > correctly, as > > you point out. > > > > The question seems to be why Google calendar is > > misinterpreting > > the coding here. > > > > I also use Gogole calendar, and it is also > > misinterpreting the > > coding for me.... but I cannot tell why, nor would I > > know to whom > > that should be reported. > > > > I welcome thoughts on this matter! > > > > Glen > > Glen Barney > > IT Director > > AMS (IETF Secretariat) > > > > > > > > On Fri, Sep 11, 2015 at 7:52 AM, Lou Berger > > > > >> > > wrote: > > > > So what's the right way to report an issue with > > ical.ietf.org > > ? > > > > I see an issue with a meeting from yesterday > > 9/10/15 on > > https://ical.ietf.org/public.php/IAOC/calendar and > > it looks > > like the > > issues is also there for future meetings. > > > > The meeting correctly shows in Thunderbird as > > occurring at > > noon ET, but > > on google calendar it shows at 10am ET. > > Interesting, this has > > not been > > an issue for other calendars, e.g., finance. > > > > Thanks, > > Lou > > > > > > > > _______________________________________________ > > TOOLS-DEVELOPMENT mailing list > > TOOLS-DEVELOPMENT@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/tools-development > > > > > > > > > > > > _______________________________________________ > > TOOLS-DEVELOPMENT mailing list > > TOOLS-DEVELOPMENT@ietf.org > > https://www.ietf.org/mailman/listinfo/tools-development > > > > > > > > > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > --001a11c338ec7fc347051fdfd2a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lou -

Not that I'm= aware of....

ietfa:~ # date
Wed Sep 16 09:28:34 PDT 2015
ietf= a:~ # sntp -s pool.ntp.org
16 Sep 09= :28:36 sntp[15416]: Started sntp
2015-09-16 09:28:38.235822 (+0800) -0.0= 0297 +/- 0.028366 secs
2015-09-16 09:28:38.234173 (+0800) +0.005258 +/- = 0.003143 secs
2015-09-16 09:28:38.241367 (+0800) +0.000079 +/- 0.025818 = secs
ietfa:~ # date
Wed Sep 16 09:28:39 PDT 2015

We chec= k the clocks as part of our weekly maintenance, and ensure they are synced = to the global time servers.=C2=A0 The above was a manual resync I ran just = now - we seem to be on point there.

Interesting find about the= https:// though...

Glen


On Tue, = Sep 15, 2015 at 8:35 PM, Lou Berger <lberger@labn.net> wrote:=
Well in trying a test with removing Z I = found something really interesting:

All works well if the non-https version is used
(http://ical.ietf.org/public.php/IAOC/calendar)

Is there perhaps something odd on the server's time setting (assuming google is somehow using tls time...)?

Lou


On 9/14/2015 12:15 PM, Glen wrote:
> Hi Lou -
>
> I"m trying to follow this... but in the thread you link to, and t= he
> 4/1 response you cite, it seems that Google is talking about the
> manual import of ICS files, and saying that it is fixed, which it is.<= br> > I can manually import the ICS file, and the timezones are all correct<= br> > on my Google Calendar.=C2=A0 =C2=A0It seems that the problem only occu= rs with
> calendar subscriptions.
>
> In addition, you mention someone removing UTC times from the ICS... > When I do a survey of the exported ICS, it seems that about half the > times are in UTC format (e.g. DTSTART:20131219T150000Z), and the other=
> roughly half appear to have time zone specifiers.=C2=A0 (e.g.
> DTSTART;TZID=3DAmerica/New_York:20150910T120000).=C2=A0 I do not have = any way
> of automatically making the calendar server remove all the "Z&quo= t; times
> from its feed, and converting them to some time of local time - that > is a function of each calendar item's creation and time zone setti= ngs.
>
> Interestingly, the item in question - the one malfunctioning - is the<= br> > one I cited above, and it is *not* a "Z" time, but is in fac= t a
> localized timezone time.=C2=A0 I reviewed the file output, and compare= d
> them to 2445/5545, and the output seems to be exactly compliant.=C2=A0= We
> also have a properly-constructed VTIMEZONE stanza for it, and it is, > as already cited, working for all other platforms (including Google= 9;s
> manual import.)
>
> So I'm still in the same place - our server is functioning, and > functioning correctly, and RFC-compliant, and although I can confirm > that Google is mangling this on import, I do not have any connections<= br> > to Google that would enable me to "run this down..." much as= I, too,
> would like to see this solved for their platform.
>
> I am open to any thoughts or suggestions... Do we know anyone at
> Google who participates in the IETF that might have some access to
> work on this, for example?
>
> Glen
>
>
> On Sun, Sep 13, 2015 at 8:29 AM, Lou Berger <lberger@labn.net
> <mailto:lberger@labn.net>= ;> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Glenn,
>
>=C2=A0 =C2=A0 =C2=A0Looks like others have seen similar issues and work= ed with Google
>=C2=A0 =C2=A0 =C2=A0to resolve, see links below. Given that there will = likely be other
>=C2=A0 =C2=A0 =C2=A0Google users of the ietf ical server it's proba= bly worth running
>=C2=A0 =C2=A0 =C2=A0this to ground...
>
>=C2=A0 =C2=A0 =C2=A0Lou
>
>=C2=A0 =C2=A0 =C2=A0-
>=C2=A0 =C2=A0 =C2=A0https:/= /productforums.google.com/forum/m/#!topic/calendar/GouovR3g4LY
>=C2=A0 =C2=A0 =C2=A0<h= ttps://productforums.google.com/forum/m/#%21topic/calendar/GouovR3g4LY&= gt;.
>=C2=A0 =C2=A0 =C2=A0Look at the 4/1 response.
>
>=C2=A0 =C2=A0 =C2=A0- I lost the link, but someone solve the issues by = removing any Z
>=C2=A0 =C2=A0 =C2=A0(utc) based times from the ics
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0On September 11, 2015 2:00:09 PM Lou Berger <lberger@labn.net
>=C2=A0 =C2=A0 =C2=A0<mailto:lber= ger@labn.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0another data point:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://ical.ietf= .org/public.php/IAOC/finance
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0works fine...
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 9/11/2015 1:00 PM, Glen wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Here's an interesti= ng data point:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If I download the file = at the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://ical.ietf.org/public.php/IAOC/calendar URL
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0manually, and save
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it as an ICS file on my= desktop, and then I "Import" that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0file into
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Google, the times displ= ay correctly.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It is only if I ask Goo= gle to "subscribe" to the URL in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0live-feed mode
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that it seems to incorr= ectly compute the times.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As there is no differen= ce in the data flow or what is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pulled (since
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the Calendar server sen= ds everything via HTTP in the same
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0way), I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wonder if something in = Google's subscription processor is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tripping on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0something somewhere. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0That's not a soluti= on - because you obviously want the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0live feed - but
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it does provide an addi= tional point of validation, if you
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0like, of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Glen
>
>
>
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, Sep 11, 2015 at= 9:52 AM, Glen <glen@amsl.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:glen@amsl.com>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:glen@amsl.com <mailto:glen@amsl.com>>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Lou -<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AMS (ietf-action@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:ietf-action@ietf.org> <mailto:ietf-action@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:ietf-action@ietf.org>>) would be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the corre= ct place to report a problem with the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0calendar *server* -
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for examp= le, if the calendar server were down, or you
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0couldn't get
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0access, o= r something like that.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0But I con= fess I have no idea how or where to "report"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the problem
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0you'r= e encountering.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When I vi= ew the feed you mention, I see the meeting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0coded as:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DTEND;TZI= D=3DAmerica/New_York:20150910T130000
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DTSTART;T= ZID=3DAmerica/New_York:20150910T120000
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So the ca= lendar server appears to be delivering it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0correctly, as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0you point= out.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The quest= ion seems to be why Google calendar is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0misinterpreting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the codin= g here.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I also us= e Gogole calendar, and it is also
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0misinterpreting the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0coding fo= r me.... but I cannot tell why, nor would I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0know to whom
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that shou= ld be reported.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I welcome= thoughts on this matter!
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Glen
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Glen Barn= ey
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IT Direct= or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AMS (IETF= Secretariat)
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, S= ep 11, 2015 at 7:52 AM, Lou Berger
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<lberger@labn.net <mailto:lberger@labn.net>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailt= o:lberger@labn.net <mailto:lberger@labn.net>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0So what's the right way to report an issue with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ical.ietf.org <http://ical= .ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<http://ical.ietf.org>?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0I see an issue with a meeting from yesterday
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09/10/15 on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0https://ical.ietf.org/public.php/IAOC/calendar and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it looks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0like the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0issues is also there for future meetings.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0The meeting correctly shows in Thunderbird as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0occurring at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0noon ET, but
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0on google calendar it shows at 10am ET.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Interesting, this has >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0not been
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0an issue for other calendars, e.g., finance.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Lou
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0TOOLS-DEVELOPMENT mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0TOOLS-DEVELOPMENT@ietf.= org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:TOOLS-DEVELOPMENT@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:TOOLS-DEVELOPMENT@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:TOOLS-DEVELOPMENT@ietf.org>> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/tools-development
>
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TOOLS-DEVELOPMENT mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TOOLS-DEVELOPMENT@ietf.org <mailto:TOOLS-DEVELOPMENT@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /www.ietf.org/mailman/listinfo/tools-development
>
>
>
>


_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment

--001a11c338ec7fc347051fdfd2a6-- From nobody Wed Sep 16 09:40:51 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEF51B35F1 for ; Wed, 16 Sep 2015 09:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoCvNfbV36hV for ; Wed, 16 Sep 2015 09:40:47 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 2B3851B35A0 for ; Wed, 16 Sep 2015 09:40:47 -0700 (PDT) Received: (qmail 3858 invoked by uid 0); 16 Sep 2015 16:40:41 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 16 Sep 2015 16:40:41 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id Hsga1r00B2SSUrH01sgd8x; Wed, 16 Sep 2015 10:40:41 -0600 X-Authority-Analysis: v=2.1 cv=QdD14Krv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=cdhwmzFqHrdSXMWX7xUA:9 a=QEXdDO2ut3YA:10 a=VMMmeH3jRGcA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=TfEEa33Ylnl/UmpgSavrjnWH0uVc6gpO78kecj2C+jo=; b=OXLR5f/0xhl9wrPsRFdAvI21+URJa8OiGp8L0eDS6V8IsRQSw2aD0oze8UwtT+5c1/hSiVrNxgrRWG+oqCRpbz1yb1T5bG5LLkAfLgKdUbfxs0R8UIuWCGVVyNL9X5lv; Received: from box313.bluehost.com ([69.89.31.113]:54826 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZcFl4-0000JC-0j; Wed, 16 Sep 2015 10:40:34 -0600 To: glen@amsl.com References: <55F2EAA4.3040503@labn.net> <55F31680.6080100@labn.net> <14fc7535b48.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55F8E38F.7080901@labn.net> From: Lou Berger Message-ID: <55F99B74.7080105@labn.net> Date: Wed, 16 Sep 2015 12:40:20 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 16:40:49 -0000 On 9/16/2015 12:30 PM, Glen wrote: > ... > Interesting find about the https:// though... .. Given the work around, I'm going to move on to other things. As we scale out ical services, and more google users show up, we'll need to address this. Certainly publishing the http version as 1st choice for public calendars will avoid most of this. Thanks, Lou From nobody Wed Sep 16 09:43:33 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0048B1B37F4 for ; Wed, 16 Sep 2015 09:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.288 X-Spam-Level: X-Spam-Status: No, score=-101.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDI0BEFfrAN7 for ; Wed, 16 Sep 2015 09:43:29 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id A8B221B37BD for ; Wed, 16 Sep 2015 09:43:29 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 9EF6D1E5A40 for ; Wed, 16 Sep 2015 09:42:49 -0700 (PDT) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by c8a.amsl.com (Postfix) with ESMTPSA id 7C2791E5A35 for ; Wed, 16 Sep 2015 09:42:49 -0700 (PDT) Received: by oiev17 with SMTP id v17so129972966oie.1 for ; Wed, 16 Sep 2015 09:43:29 -0700 (PDT) X-Received: by 10.202.67.194 with SMTP id q185mr18814860oia.106.1442421809072; Wed, 16 Sep 2015 09:43:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.102.71 with HTTP; Wed, 16 Sep 2015 09:43:09 -0700 (PDT) In-Reply-To: <55F99B74.7080105@labn.net> References: <55F2EAA4.3040503@labn.net> <55F31680.6080100@labn.net> <14fc7535b48.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55F8E38F.7080901@labn.net> <55F99B74.7080105@labn.net> From: Glen Date: Wed, 16 Sep 2015 09:43:09 -0700 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a113cd06a8bd3bd051fdfffcc Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 16:43:31 -0000 --001a113cd06a8bd3bd051fdfffcc Content-Type: text/plain; charset=UTF-8 Understood. I'll make sure everyone here knows this, and if we locate any web pages with the less-desirable link, I'll make sure they get updated. Thanks, Glen On Wed, Sep 16, 2015 at 9:40 AM, Lou Berger wrote: > > > On 9/16/2015 12:30 PM, Glen wrote: > > ... > > Interesting find about the https:// though... > .. > > Given the work around, I'm going to move on to other things. As we > scale out ical services, and more google users show up, we'll need to > address this. Certainly publishing the http version as 1st choice for > public calendars will avoid most of this. > > Thanks, > Lou > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > --001a113cd06a8bd3bd051fdfffcc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Understood.=C2=A0 I'll make sure everyone he= re knows this, and if we locate any web pages with the less-desirable link,= I'll make sure they get updated.

Thanks,
Glen

On Wed= , Sep 16, 2015 at 9:40 AM, Lou Berger <lberger@labn.net> wrot= e:


On 9/16/2015 12:30 PM, Glen wrote:
> ...
> Interesting find about the https:// though...
..

Given the work around, I'm going to move on to other things.=C2=A0 As w= e
scale out ical services, and more google users show up, we'll need to address this.=C2=A0 Certainly publishing the http version as 1st choice for=
public calendars will avoid most of this.

Thanks,
Lou


_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment

--001a113cd06a8bd3bd051fdfffcc-- From nobody Wed Sep 16 10:06:09 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8791B3B3C for ; Wed, 16 Sep 2015 10:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnLKsVMVV9m2 for ; Wed, 16 Sep 2015 10:06:06 -0700 (PDT) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4EB1B3ADA for ; Wed, 16 Sep 2015 10:06:06 -0700 (PDT) Received: by ioii196 with SMTP id i196so236891242ioi.3 for ; Wed, 16 Sep 2015 10:06:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hJG3mAQ9De0YLqtQTIKCBI70DO0kTgViEtVwu+uGhkI=; b=id5kjwzVUsjbb8YmNb/jlltSkTrRIibiDqnXRxgUSZhkp1TXZJlW9nmblIYHGXBteu TQiWBSiAL4N1P+m0QHGZKVw5fI11tXu+SXbhTPgb0/d6chLwTdFfUd1MGP4QGGi/GQ6X NwZ77yTBJV/pmzyy8H1B+C53fuvQDgBr1g8vbpDEyKtf2AESdeK09qhE0DRDw1Vo0ZKy 8lbMMZOEi25UllR0QWj5werd9EeVZEl7NtRggbEGzeaCYcP8pUYc1USeqq1HeyhjEehN 8+dJx4vMUBx7CSSiRSzr3bz5C3IbakyWAB99b8yISHME/yLCVjou1ofmzWcaxKhJDrk7 d35A== X-Gm-Message-State: ALoCoQmfGNU51Gafvf+AQ7OkhOm3kCydxHy4GwMiwqcZuN2dqWE1c6okq72Hm+C8DMumUkTMwmtF MIME-Version: 1.0 X-Received: by 10.107.133.75 with SMTP id h72mr46322383iod.1.1442423165870; Wed, 16 Sep 2015 10:06:05 -0700 (PDT) Received: by 10.107.141.144 with HTTP; Wed, 16 Sep 2015 10:06:05 -0700 (PDT) In-Reply-To: References: <55F2EAA4.3040503@labn.net> <55F31680.6080100@labn.net> <14fc7535b48.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55F8E38F.7080901@labn.net> <55F99B74.7080105@labn.net> Date: Wed, 16 Sep 2015 13:06:05 -0400 Message-ID: From: Benson Schliesser To: glen@amsl.com Content-Type: multipart/alternative; boundary=001a113ec5e46b05cb051fe050b6 Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 17:06:08 -0000 --001a113ec5e46b05cb051fe050b6 Content-Type: text/plain; charset=UTF-8 Just a shot in the dark: Given that this issue presents itself when Google Calendar pulls ical info via HTTPS, it occurs to me that perhaps the issue is with timezone info in the server's certificate..? -B On Wed, Sep 16, 2015 at 12:43 PM, Glen wrote: > Understood. I'll make sure everyone here knows this, and if we locate any > web pages with the less-desirable link, I'll make sure they get updated. > > Thanks, > Glen > > > On Wed, Sep 16, 2015 at 9:40 AM, Lou Berger wrote: > >> >> >> On 9/16/2015 12:30 PM, Glen wrote: >> > ... >> > Interesting find about the https:// though... >> .. >> >> Given the work around, I'm going to move on to other things. As we >> scale out ical services, and more google users show up, we'll need to >> address this. Certainly publishing the http version as 1st choice for >> public calendars will avoid most of this. >> >> Thanks, >> Lou >> >> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >> > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > > --001a113ec5e46b05cb051fe050b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just a shot in the dark: =C2=A0Given that this issue prese= nts itself when Google Calendar pulls ical info via HTTPS, it occurs to me = that perhaps the issue is with timezone info in the server's certificat= e..?=C2=A0
-B


=
On Wed, Sep 16, 2015 at 12:43 PM, Glen <glen@amsl.c= om> wrote:
Understood.=C2=A0 I'll make sure everyone here knows this, a= nd if we locate any web pages with the less-desirable link, I'll make s= ure they get updated.

Thanks,
Glen


On Wed, Sep 16, 2015 at 9:40 AM, Lou Berger <lberger@labn= .net> wrote:


On 9/16/2015 12:30 PM, Glen wrote:
> ...
> Interesting find about the https:// though...
..

Given the work around, I'm going to move on to other things.=C2=A0 As w= e
scale out ical services, and more google users show up, we'll need to address this.=C2=A0 Certainly publishing the http version as 1st choice for=
public calendars will avoid most of this.

Thanks,
Lou


_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVEL= OPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment


_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment


--001a113ec5e46b05cb051fe050b6-- From nobody Wed Sep 16 10:15:00 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AD51B3B8D for ; Wed, 16 Sep 2015 10:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.588 X-Spam-Level: X-Spam-Status: No, score=-103.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id su9FL84yTcML for ; Wed, 16 Sep 2015 10:14:58 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 248C81B3B7C for ; Wed, 16 Sep 2015 10:14:58 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 0686E1E5A2C for ; Wed, 16 Sep 2015 10:14:18 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by c8a.amsl.com (Postfix) with ESMTPSA id D96D31E5A2D for ; Wed, 16 Sep 2015 10:14:17 -0700 (PDT) Received: by obqa2 with SMTP id a2so154915188obq.3 for ; Wed, 16 Sep 2015 10:14:57 -0700 (PDT) X-Received: by 10.60.121.72 with SMTP id li8mr24541398oeb.55.1442423697363; Wed, 16 Sep 2015 10:14:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.102.71 with HTTP; Wed, 16 Sep 2015 10:14:36 -0700 (PDT) In-Reply-To: References: <55F2EAA4.3040503@labn.net> <55F31680.6080100@labn.net> <14fc7535b48.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55F8E38F.7080901@labn.net> <55F99B74.7080105@labn.net> From: Glen Date: Wed, 16 Sep 2015 10:14:36 -0700 Message-ID: To: Benson Schliesser Content-Type: multipart/alternative; boundary=047d7b3a91d818fc1d051fe0707d Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 17:14:59 -0000 --047d7b3a91d818fc1d051fe0707d Content-Type: text/plain; charset=UTF-8 Hi Benson - The iCal server is using the same global wildcard certificate that the rest of the IETF services are using. I just reviewed it, and the time zone information appears to be correctly set. The expiration date, for example, is: 8/11/2016 16:12:50 PM (8/11/2016 23:12:50 PM GMT) Which seems to be more-or-less correct.... Apologies if I'm missing something or looking in the wrong place? Glen On Wed, Sep 16, 2015 at 10:06 AM, Benson Schliesser wrote: > Just a shot in the dark: Given that this issue presents itself when > Google Calendar pulls ical info via HTTPS, it occurs to me that perhaps the > issue is with timezone info in the server's certificate..? > -B > > > On Wed, Sep 16, 2015 at 12:43 PM, Glen wrote: > >> Understood. I'll make sure everyone here knows this, and if we locate >> any web pages with the less-desirable link, I'll make sure they get updated. >> >> Thanks, >> Glen >> >> >> On Wed, Sep 16, 2015 at 9:40 AM, Lou Berger wrote: >> >>> >>> >>> On 9/16/2015 12:30 PM, Glen wrote: >>> > ... >>> > Interesting find about the https:// though... >>> .. >>> >>> Given the work around, I'm going to move on to other things. As we >>> scale out ical services, and more google users show up, we'll need to >>> address this. Certainly publishing the http version as 1st choice for >>> public calendars will avoid most of this. >>> >>> Thanks, >>> Lou >>> >>> >>> _______________________________________________ >>> TOOLS-DEVELOPMENT mailing list >>> TOOLS-DEVELOPMENT@ietf.org >>> https://www.ietf.org/mailman/listinfo/tools-development >>> >> >> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >> >> > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > > --047d7b3a91d818fc1d051fe0707d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Benson -

The iCal server is using the same global wildcard certificate that the r= est of the IETF services are using.

I just reviewed it, and th= e time zone information appears to be correctly set.=C2=A0=C2=A0 The expira= tion date, for example, is:

8/11/2016 16:12:50 PM (8/11/2016 23:12:5= 0 PM GMT)

Which seems to be more-or-less correct....

Apologies if I'm missing something or looking in the wrong place?
Glen







On Wed, S= ep 16, 2015 at 10:06 AM, Benson Schliesser <bensons@queuefull.net&= gt; wrote:
Just a= shot in the dark: =C2=A0Given that this issue presents itself when Google = Calendar pulls ical info via HTTPS, it occurs to me that perhaps the issue = is with timezone info in the server's certificate..?=C2=A0
-B
=


On Wed, Sep 16, 2015 at 12:43 PM, Glen <glen@amsl.com> wrote= :
Understood.= =C2=A0 I'll make sure everyone here knows this, and if we locate any we= b pages with the less-desirable link, I'll make sure they get updated.<= br>
Thanks,
Glen


On Wed, Sep 16, 2015 at 9:40 AM, L= ou Berger <lberger@labn.net> wrote:


On 9/16/2015 12:30 PM, Glen wrote:
> ...
> Interesting find about the https:// though...
..

Given the work around, I'm going to move on to other things.=C2=A0 As w= e
scale out ical services, and more google users show up, we'll need to address this.=C2=A0 Certainly publishing the http version as 1st choice for=
public calendars will avoid most of this.

Thanks,
Lou


_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVEL= OPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment


_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVEL= OPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment



_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment


--047d7b3a91d818fc1d051fe0707d-- From nobody Wed Sep 16 10:51:55 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56051B40DD for ; Wed, 16 Sep 2015 10:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSK-xkNdpEDd for ; Wed, 16 Sep 2015 10:51:51 -0700 (PDT) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A881A700E for ; Wed, 16 Sep 2015 10:51:51 -0700 (PDT) Received: by igcpb10 with SMTP id pb10so40002677igc.1 for ; Wed, 16 Sep 2015 10:51:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5XSlJEvmL0ruw9NmUsS9lr1RvktVIDAKv0N2I0GskCI=; b=U1X4BoS67x48YaZKTWTWFFttr9svUBWyjz/fBG08cuGqUwO2tvAkK6dPyEVDMShSYM zgKxo9XV7EJoqIylqsEetJyrC3RNHfy5AvkJRrXAFQu44URCmoXxuokQ1zMgS3UeOvGY rI0W2zALqBtBTsVAfxvWv6MwWOcMpjtpqLNrdD2dWUaeHKZQ7SUJ4HALl55ztQioB1VQ 5Hj7lo6HjJmTMWXvfP3Esqo+fHQQIJ49Figd1SmCBjKSu1S86J5npvobmdhAxad1e9mT 0ofLfp45Kgs4L5dL0cAFXG9MLvOVYJfZ/m4QDCqBsrOgTG9rvrYQ4ZjE4UzoWSuk/5a1 4MVQ== X-Gm-Message-State: ALoCoQmtjTeh6wXTPa7TVHWmR4ZALc61gIkDwU61CbSxw24JKJ+f6hm89Pt7aJ34l1BUOCudHG8C MIME-Version: 1.0 X-Received: by 10.50.176.225 with SMTP id cl1mr17461845igc.80.1442425911090; Wed, 16 Sep 2015 10:51:51 -0700 (PDT) Received: by 10.107.141.144 with HTTP; Wed, 16 Sep 2015 10:51:50 -0700 (PDT) In-Reply-To: References: <55F2EAA4.3040503@labn.net> <55F31680.6080100@labn.net> <14fc7535b48.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55F8E38F.7080901@labn.net> <55F99B74.7080105@labn.net> Date: Wed, 16 Sep 2015 13:51:50 -0400 Message-ID: From: Benson Schliesser To: glen@amsl.com Content-Type: multipart/alternative; boundary=089e0122a5f00bbcdc051fe0f4c5 Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 17:51:53 -0000 --089e0122a5f00bbcdc051fe0f4c5 Content-Type: text/plain; charset=UTF-8 No, I think my "shot in the dark" was just a miss... I just spent a few minutes just now looking at the cert, http headers, etc, and it all seems correct to me. Sorry. -B On Wed, Sep 16, 2015 at 1:14 PM, Glen wrote: > Hi Benson - > > The iCal server is using the same global wildcard certificate that the > rest of the IETF services are using. > > I just reviewed it, and the time zone information appears to be correctly > set. The expiration date, for example, is: > > 8/11/2016 16:12:50 PM (8/11/2016 23:12:50 PM GMT) > > Which seems to be more-or-less correct.... > > Apologies if I'm missing something or looking in the wrong place? > > Glen > > > > > > > > On Wed, Sep 16, 2015 at 10:06 AM, Benson Schliesser > wrote: > >> Just a shot in the dark: Given that this issue presents itself when >> Google Calendar pulls ical info via HTTPS, it occurs to me that perhaps the >> issue is with timezone info in the server's certificate..? >> -B >> >> >> On Wed, Sep 16, 2015 at 12:43 PM, Glen wrote: >> >>> Understood. I'll make sure everyone here knows this, and if we locate >>> any web pages with the less-desirable link, I'll make sure they get updated. >>> >>> Thanks, >>> Glen >>> >>> >>> On Wed, Sep 16, 2015 at 9:40 AM, Lou Berger wrote: >>> >>>> >>>> >>>> On 9/16/2015 12:30 PM, Glen wrote: >>>> > ... >>>> > Interesting find about the https:// though... >>>> .. >>>> >>>> Given the work around, I'm going to move on to other things. As we >>>> scale out ical services, and more google users show up, we'll need to >>>> address this. Certainly publishing the http version as 1st choice for >>>> public calendars will avoid most of this. >>>> >>>> Thanks, >>>> Lou >>>> >>>> >>>> _______________________________________________ >>>> TOOLS-DEVELOPMENT mailing list >>>> TOOLS-DEVELOPMENT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tools-development >>>> >>> >>> >>> _______________________________________________ >>> TOOLS-DEVELOPMENT mailing list >>> TOOLS-DEVELOPMENT@ietf.org >>> https://www.ietf.org/mailman/listinfo/tools-development >>> >>> >> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >> >> > --089e0122a5f00bbcdc051fe0f4c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, I think my "shot in the dark" was just a mis= s... I just spent a few minutes just now looking at the cert, http headers,= etc, and it all seems correct to me. Sorry.
-B


On Wed, Sep 16= , 2015 at 1:14 PM, Glen <glen@amsl.com> wrote:
Hi Benson -
<= /div>

The iCal server is using the same global wildcard certi= ficate that the rest of the IETF services are using.

I just re= viewed it, and the time zone information appears to be correctly set.=C2=A0= =C2=A0 The expiration date, for example, is:

8/11/2016 16:12:50 PM (= 8/11/2016 23:12:50 PM GMT)

Which seems to be more-or-less corr= ect....

Apologies if I'm missing something or looking in t= he wrong place?

Glen






On Wed, Sep 16, 2015 at 10:06 AM, Benson Schliesser <bensons@q= ueuefull.net> wrote:
Just a shot in the dark: =C2=A0Given that this issue presents it= self when Google Calendar pulls ical info via HTTPS, it occurs to me that p= erhaps the issue is with timezone info in the server's certificate..?= =C2=A0
-B


On Wed, Sep 16, 2015 at 12:43 PM, Glen <glen@amsl.com> wrote:
Understood.=C2=A0 I'll make sure everyone here knows this, and i= f we locate any web pages with the less-desirable link, I'll make sure = they get updated.

Thanks,
Glen


On Wed, Sep 16, = 2015 at 9:40 AM, Lou Berger <lberger@labn.net> wrote:


On 9/16/2015 12:30 PM, Glen wrote:
> ...
> Interesting find about the https:// though...
..

Given the work around, I'm going to move on to other things.=C2=A0 As w= e
scale out ical services, and more google users show up, we'll need to address this.=C2=A0 Certainly publishing the http version as 1st choice for=
public calendars will avoid most of this.

Thanks,
Lou


_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVEL= OPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment


_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVEL= OPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment



_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVEL= OPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment



--089e0122a5f00bbcdc051fe0f4c5-- From nobody Wed Sep 16 11:03:58 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094B31B40F0 for ; Wed, 16 Sep 2015 11:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPiJgwLWiN92 for ; Wed, 16 Sep 2015 11:03:55 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 9BD701B40EF for ; Wed, 16 Sep 2015 11:03:55 -0700 (PDT) Received: (qmail 23388 invoked by uid 0); 16 Sep 2015 18:03:54 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy6.mail.unifiedlayer.com with SMTP; 16 Sep 2015 18:03:54 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id J03p1r00k2SSUrH0103sXS; Wed, 16 Sep 2015 18:03:53 -0600 X-Authority-Analysis: v=2.1 cv=GpXRpCFC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=jGqiy6jZAAAA:8 a=AZEhrcTtAAAA:8 a=48vgC7mUAAAA:8 a=T23DPRLLvk6InMPav30A:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=ybksT/+nMh0OAZnSftQ49VPHyiDF7ZQrjfii7ihL7cU=; b=JjoPlIk52ghrqwrqcTUKy/er4m0eNToIYCFbq8z/Q+5sgYCla+zqhSZT7Xd8HWSP/cnYXmen1hJOZitukT117XnlxyqM3EB2zJYWwdHEMT8L5E5DZvCrY6MND8Se59zF; Received: from box313.bluehost.com ([69.89.31.113]:39661 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZcH3e-0007Fb-KV for tools-development@ietf.org; Wed, 16 Sep 2015 12:03:50 -0600 To: tools-development@ietf.org References: <55F2EAA4.3040503@labn.net> <55F31680.6080100@labn.net> <14fc7535b48.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55F8E38F.7080901@labn.net> <55F99B74.7080105@labn.net> From: Lou Berger Message-ID: <55F9AF04.8000900@labn.net> Date: Wed, 16 Sep 2015 14:03:48 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 18:03:57 -0000 I think ssl includes a time exchange, but I'm certainly not informed (let alone an expert) on this topic... On 09/16/2015 01:51 PM, Benson Schliesser wrote: > No, I think my "shot in the dark" was just a miss... I just spent a few > minutes just now looking at the cert, http headers, etc, and it all > seems correct to me. Sorry. > -B > > > On Wed, Sep 16, 2015 at 1:14 PM, Glen > wrote: > > Hi Benson - > > The iCal server is using the same global wildcard certificate that > the rest of the IETF services are using. > > I just reviewed it, and the time zone information appears to be > correctly set. The expiration date, for example, is: > > 8/11/2016 16:12:50 PM (8/11/2016 23:12:50 PM GMT) > > Which seems to be more-or-less correct.... > > Apologies if I'm missing something or looking in the wrong place? > > Glen > > > > > > > > On Wed, Sep 16, 2015 at 10:06 AM, Benson Schliesser > > wrote: > > Just a shot in the dark: Given that this issue presents itself > when Google Calendar pulls ical info via HTTPS, it occurs to me > that perhaps the issue is with timezone info in the server's > certificate..? > -B > > > On Wed, Sep 16, 2015 at 12:43 PM, Glen > wrote: > > Understood. I'll make sure everyone here knows this, and if > we locate any web pages with the less-desirable link, I'll > make sure they get updated. > > Thanks, > Glen > > > On Wed, Sep 16, 2015 at 9:40 AM, Lou Berger > > wrote: > > > > On 9/16/2015 12:30 PM, Glen wrote: > > ... > > Interesting find about the https:// though... > .. > > Given the work around, I'm going to move on to other > things. As we > scale out ical services, and more google users show up, > we'll need to > address this. Certainly publishing the http version as > 1st choice for > public calendars will avoid most of this. > > Thanks, > Lou > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > > https://www.ietf.org/mailman/listinfo/tools-development > > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > > > > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > From nobody Wed Sep 16 11:14:59 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45391A8795 for ; Wed, 16 Sep 2015 11:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.288 X-Spam-Level: X-Spam-Status: No, score=-101.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTr19ICTbK5o for ; Wed, 16 Sep 2015 11:14:57 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 915D01A1BB9 for ; Wed, 16 Sep 2015 11:14:52 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 4B3FC1E5A31 for ; Wed, 16 Sep 2015 11:14:12 -0700 (PDT) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by c8a.amsl.com (Postfix) with ESMTPSA id 1C8A81E5A2D for ; Wed, 16 Sep 2015 11:14:12 -0700 (PDT) Received: by obbzf10 with SMTP id zf10so100206301obb.2 for ; Wed, 16 Sep 2015 11:14:51 -0700 (PDT) X-Received: by 10.60.121.72 with SMTP id li8mr24769162oeb.55.1442427291846; Wed, 16 Sep 2015 11:14:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.102.71 with HTTP; Wed, 16 Sep 2015 11:14:32 -0700 (PDT) In-Reply-To: References: <55F2EAA4.3040503@labn.net> <55F31680.6080100@labn.net> <14fc7535b48.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55F8E38F.7080901@labn.net> <55F99B74.7080105@labn.net> From: Glen Date: Wed, 16 Sep 2015 11:14:32 -0700 Message-ID: To: Benson Schliesser Content-Type: multipart/alternative; boundary=047d7b3a91d8584ecb051fe1463e Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 18:14:59 -0000 --047d7b3a91d8584ecb051fe1463e Content-Type: text/plain; charset=UTF-8 No, no! Don't apologize! I am, and we all are, grateful for any insights or possibilities when we work on *any* problem. All good, seriously. I do the best I can, but I'm always open for help! Glen On Wed, Sep 16, 2015 at 10:51 AM, Benson Schliesser wrote: > No, I think my "shot in the dark" was just a miss... I just spent a few > minutes just now looking at the cert, http headers, etc, and it all seems > correct to me. Sorry. > -B > > > On Wed, Sep 16, 2015 at 1:14 PM, Glen wrote: > >> Hi Benson - >> >> The iCal server is using the same global wildcard certificate that the >> rest of the IETF services are using. >> >> I just reviewed it, and the time zone information appears to be correctly >> set. The expiration date, for example, is: >> >> 8/11/2016 16:12:50 PM (8/11/2016 23:12:50 PM GMT) >> >> Which seems to be more-or-less correct.... >> >> Apologies if I'm missing something or looking in the wrong place? >> >> Glen >> >> >> >> >> >> >> >> On Wed, Sep 16, 2015 at 10:06 AM, Benson Schliesser < >> bensons@queuefull.net> wrote: >> >>> Just a shot in the dark: Given that this issue presents itself when >>> Google Calendar pulls ical info via HTTPS, it occurs to me that perhaps the >>> issue is with timezone info in the server's certificate..? >>> -B >>> >>> >>> On Wed, Sep 16, 2015 at 12:43 PM, Glen wrote: >>> >>>> Understood. I'll make sure everyone here knows this, and if we locate >>>> any web pages with the less-desirable link, I'll make sure they get updated. >>>> >>>> Thanks, >>>> Glen >>>> >>>> >>>> On Wed, Sep 16, 2015 at 9:40 AM, Lou Berger wrote: >>>> >>>>> >>>>> >>>>> On 9/16/2015 12:30 PM, Glen wrote: >>>>> > ... >>>>> > Interesting find about the https:// though... >>>>> .. >>>>> >>>>> Given the work around, I'm going to move on to other things. As we >>>>> scale out ical services, and more google users show up, we'll need to >>>>> address this. Certainly publishing the http version as 1st choice for >>>>> public calendars will avoid most of this. >>>>> >>>>> Thanks, >>>>> Lou >>>>> >>>>> >>>>> _______________________________________________ >>>>> TOOLS-DEVELOPMENT mailing list >>>>> TOOLS-DEVELOPMENT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tools-development >>>>> >>>> >>>> >>>> _______________________________________________ >>>> TOOLS-DEVELOPMENT mailing list >>>> TOOLS-DEVELOPMENT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tools-development >>>> >>>> >>> >>> _______________________________________________ >>> TOOLS-DEVELOPMENT mailing list >>> TOOLS-DEVELOPMENT@ietf.org >>> https://www.ietf.org/mailman/listinfo/tools-development >>> >>> >> > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > > --047d7b3a91d8584ecb051fe1463e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, no!=C2=A0 Don't apologize!=C2=A0 I am, and we= all are, grateful for any insights or possibilities when we work on *any* = problem.=C2=A0 All good, seriously.=C2=A0 I do the best I can, but I'm = always open for help!

Glen

On Wed, Sep 16, 2015 at 10:51 AM, Benso= n Schliesser <bensons@queuefull.net> wrote:
No, I think my "shot in the dar= k" was just a miss... I just spent a few minutes just now looking at t= he cert, http headers, etc, and it all seems correct to me. Sorry.
-B


On Wed, Sep 16, 2015 at 1:14 PM, Glen <glen@amsl.com> wr= ote:
Hi Benson -

The iCal server is using the same= global wildcard certificate that the rest of the IETF services are using.<= br>
I just reviewed it, and the time zone information appears to b= e correctly set.=C2=A0=C2=A0 The expiration date, for example, is:

8= /11/2016 16:12:50 PM (8/11/2016 23:12:50 PM GMT)

Which seems t= o be more-or-less correct....

Apologies if I'm missing som= ething or looking in the wrong place?

Glen





<= br>
On Wed, Sep 16, 2015 at 10:06 AM, Benson Schl= iesser <bensons@queuefull.net> wrote:
Just a shot in the dark: =C2=A0Given that = this issue presents itself when Google Calendar pulls ical info via HTTPS, = it occurs to me that perhaps the issue is with timezone info in the server&= #39;s certificate..?=C2=A0
-B


On Wed, Sep 16, 2015 at 12:43 PM= , Glen <glen@amsl.com> wrote:
=
Understood.=C2=A0 I'll make sure everyone he= re knows this, and if we locate any web pages with the less-desirable link,= I'll make sure they get updated.

Thanks,
Glen

On Wed, Sep 16, 2015 at 9:40 AM, Lou Berger <lberger@labn.net> wrote:


On 9/16/2015 12:30 PM, Glen wrote:
> ...
> Interesting find about the https:// though...
..

Given the work around, I'm going to move on to other things.=C2=A0 As w= e
scale out ical services, and more google users show up, we'll need to address this.=C2=A0 Certainly publishing the http version as 1st choice for=
public calendars will avoid most of this.

Thanks,
Lou


_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVEL= OPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment


_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVEL= OPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment



_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVEL= OPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment




_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment


--047d7b3a91d8584ecb051fe1463e-- From nobody Wed Sep 16 11:16:59 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CF81B4104 for ; Wed, 16 Sep 2015 11:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.588 X-Spam-Level: X-Spam-Status: No, score=-103.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEJ2pkBtxhk2 for ; Wed, 16 Sep 2015 11:16:56 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 098721A87A4 for ; Wed, 16 Sep 2015 11:16:56 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id B63B91E5A25 for ; Wed, 16 Sep 2015 11:16:15 -0700 (PDT) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by c8a.amsl.com (Postfix) with ESMTPSA id 85FEA1E5A2D for ; Wed, 16 Sep 2015 11:16:15 -0700 (PDT) Received: by obqa2 with SMTP id a2so156341427obq.3 for ; Wed, 16 Sep 2015 11:16:55 -0700 (PDT) X-Received: by 10.182.16.135 with SMTP id g7mr24912965obd.67.1442427415298; Wed, 16 Sep 2015 11:16:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.102.71 with HTTP; Wed, 16 Sep 2015 11:16:35 -0700 (PDT) In-Reply-To: <55F9AF04.8000900@labn.net> References: <55F2EAA4.3040503@labn.net> <55F31680.6080100@labn.net> <14fc7535b48.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55F8E38F.7080901@labn.net> <55F99B74.7080105@labn.net> <55F9AF04.8000900@labn.net> From: Glen Date: Wed, 16 Sep 2015 11:16:35 -0700 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a11c338ecb40d1d051fe14da0 Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 18:16:58 -0000 --001a11c338ecb40d1d051fe14da0 Content-Type: text/plain; charset=UTF-8 Nor am I, not to that level, although our clock is correct, and even if it were not, it would seem to me that Google ignoring the clear directives in the iCal file transmission, in favor of an incorrect SSL time exchange (and that again for only *some* of the events in the file) seems undesirable behavior on their part. Lou - I did notify the secretariat team about this, just to close on that part. Glen On Wed, Sep 16, 2015 at 11:03 AM, Lou Berger wrote: > I think ssl includes a time exchange, but I'm certainly not informed > (let alone an expert) on this topic... > > On 09/16/2015 01:51 PM, Benson Schliesser wrote: > > No, I think my "shot in the dark" was just a miss... I just spent a few > > minutes just now looking at the cert, http headers, etc, and it all > > seems correct to me. Sorry. > > -B > > > > > > On Wed, Sep 16, 2015 at 1:14 PM, Glen > > wrote: > > > > Hi Benson - > > > > The iCal server is using the same global wildcard certificate that > > the rest of the IETF services are using. > > > > I just reviewed it, and the time zone information appears to be > > correctly set. The expiration date, for example, is: > > > > 8/11/2016 16:12:50 PM (8/11/2016 23:12:50 PM GMT) > > > > Which seems to be more-or-less correct.... > > > > Apologies if I'm missing something or looking in the wrong place? > > > > Glen > > > > > > > > > > > > > > > > On Wed, Sep 16, 2015 at 10:06 AM, Benson Schliesser > > > wrote: > > > > Just a shot in the dark: Given that this issue presents itself > > when Google Calendar pulls ical info via HTTPS, it occurs to me > > that perhaps the issue is with timezone info in the server's > > certificate..? > > -B > > > > > > On Wed, Sep 16, 2015 at 12:43 PM, Glen > > wrote: > > > > Understood. I'll make sure everyone here knows this, and if > > we locate any web pages with the less-desirable link, I'll > > make sure they get updated. > > > > Thanks, > > Glen > > > > > > On Wed, Sep 16, 2015 at 9:40 AM, Lou Berger > > > wrote: > > > > > > > > On 9/16/2015 12:30 PM, Glen wrote: > > > ... > > > Interesting find about the https:// though... > > .. > > > > Given the work around, I'm going to move on to other > > things. As we > > scale out ical services, and more google users show up, > > we'll need to > > address this. Certainly publishing the http version as > > 1st choice for > > public calendars will avoid most of this. > > > > Thanks, > > Lou > > > > > > _______________________________________________ > > TOOLS-DEVELOPMENT mailing list > > TOOLS-DEVELOPMENT@ietf.org > > > > https://www.ietf.org/mailman/listinfo/tools-development > > > > > > > > _______________________________________________ > > TOOLS-DEVELOPMENT mailing list > > TOOLS-DEVELOPMENT@ietf.org TOOLS-DEVELOPMENT@ietf.org> > > https://www.ietf.org/mailman/listinfo/tools-development > > > > > > > > _______________________________________________ > > TOOLS-DEVELOPMENT mailing list > > TOOLS-DEVELOPMENT@ietf.org > > https://www.ietf.org/mailman/listinfo/tools-development > > > > > > > > > > > > _______________________________________________ > > TOOLS-DEVELOPMENT mailing list > > TOOLS-DEVELOPMENT@ietf.org > > https://www.ietf.org/mailman/listinfo/tools-development > > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > --001a11c338ecb40d1d051fe14da0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nor am I, not to that level, although our clock is co= rrect, and even if it were not, it would seem to me that Google ignoring th= e clear directives in the iCal file transmission, in favor of an incorrect = SSL time exchange (and that again for only *some* of the events in the file= ) seems undesirable behavior on their part.

Lou - I did n= otify the secretariat team about this, just to close on that part.

Glen


On Wed, Sep 16, 2015 at 11:03 AM, Lou Berger <lberger@labn= .net> wrote:
I think ssl in= cludes a time exchange, but I'm certainly not informed
(let alone an expert) on this topic...

On 09/16/2015 01:51 PM, Benson Schliesser wrote:
> No, I think my "shot in the dark" was just a miss... I just = spent a few
> minutes just now looking at the cert, http headers, etc, and it all > seems correct to me. Sorry.
> -B
>
>
> On Wed, Sep 16, 2015 at 1:14 PM, Glen <glen@amsl.com
> <mailto:glen@amsl.com>> = wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Benson -
>
>=C2=A0 =C2=A0 =C2=A0The iCal server is using the same global wildcard c= ertificate that
>=C2=A0 =C2=A0 =C2=A0the rest of the IETF services are using.
>
>=C2=A0 =C2=A0 =C2=A0I just reviewed it, and the time zone information a= ppears to be
>=C2=A0 =C2=A0 =C2=A0correctly set.=C2=A0 =C2=A0The expiration date, for= example, is:
>
>=C2=A0 =C2=A0 =C2=A08/11/2016 16:12:50 PM (8/11/2016 23:12:50 PM GMT) >
>=C2=A0 =C2=A0 =C2=A0Which seems to be more-or-less correct....
>
>=C2=A0 =C2=A0 =C2=A0Apologies if I'm missing something or looking i= n the wrong place?
>
>=C2=A0 =C2=A0 =C2=A0Glen
>
>
>
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0On Wed, Sep 16, 2015 at 10:06 AM, Benson Schliesser=
>=C2=A0 =C2=A0 =C2=A0<benson= s@queuefull.net <mailto:ben= sons@queuefull.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Just a shot in the dark:=C2=A0 Given = that this issue presents itself
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0when Google Calendar pulls ical info = via HTTPS, it occurs to me
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that perhaps the issue is with timezo= ne info in the server's
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0certificate..?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-B
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Wed, Sep 16, 2015 at 12:43 PM, Gle= n <glen@amsl.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:glen@amsl.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Understood.=C2=A0 I'= ;ll make sure everyone here knows this, and if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we locate any web pages= with the less-desirable link, I'll
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0make sure they get upda= ted.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Glen
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Wed, Sep 16, 2015 at= 9:40 AM, Lou Berger
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<lberger@labn.net <mailto:lberger@labn.net>> wrote:
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 9/16/2= 015 12:30 PM, Glen wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> ...<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Inte= resting find about the https:// though...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0..
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Given the= work around, I'm going to move on to other
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0things.= =C2=A0 As we
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scale out= ical services, and more google users show up,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we'll= need to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0address t= his.=C2=A0 Certainly publishing the http version as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01st choic= e for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public ca= lendars will avoid most of this.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks, >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lou
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_________= ______________________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TOOLS-DEV= ELOPMENT mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TOOLS-DEVELOPMENT@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailt= o:TOOLS-DEVELOPMENT@ietf.org<= /a>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/tools-developm= ent
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TOOLS-DEVELOPMENT maili= ng list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TOOLS-DEVELOPMENT@ietf.org <mailto:TOOLS-DEVELOPMENT@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/tools-development
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TOOLS-DEVELOPMENT mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TOOLS-DEVELOPMENT@ietf.org <mailto:TOOLS-DEVELOPMENT@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /www.ietf.org/mailman/listinfo/tools-development
>
>
>
>
>
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> TOOLS-DEVELOPMENT@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/to= ols-development
>

_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment

--001a11c338ecb40d1d051fe14da0-- From nobody Wed Sep 16 12:14:34 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574EF1A00A8 for ; Wed, 16 Sep 2015 12:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6737Y_WSj6E for ; Wed, 16 Sep 2015 12:14:30 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 71C5C1A00A4 for ; Wed, 16 Sep 2015 12:14:30 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id E6CC29A409D; Wed, 16 Sep 2015 15:14:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id yKZxjV-2ztgE; Wed, 16 Sep 2015 15:13:02 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D3E539A400D; Wed, 16 Sep 2015 15:13:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <55F9AF04.8000900@labn.net> Date: Wed, 16 Sep 2015 15:13:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55F2EAA4.3040503@labn.net> <55F31680.6080100@labn.net> <14fc7535b48.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55F8E38F.7080901@labn.net> <55F99B74.7080105@labn.net> <55F9AF04.8000900@labn.net> To: Lou Berger X-Mailer: Apple Mail (2.1085) Archived-At: Cc: tools-development@ietf.org Subject: Re: [TOOLS-DEVELOPMENT] ical server issue X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 19:14:32 -0000 Lou: Time is part of the TLS handshake nonce. But, no one checks it. In = fact, in TLS 1.3 it is being replaced with random bits. Russ On Sep 16, 2015, at 2:03 PM, Lou Berger wrote: > I think ssl includes a time exchange, but I'm certainly not informed > (let alone an expert) on this topic... >=20 > On 09/16/2015 01:51 PM, Benson Schliesser wrote: >> No, I think my "shot in the dark" was just a miss... I just spent a = few >> minutes just now looking at the cert, http headers, etc, and it all >> seems correct to me. Sorry. >> -B >>=20 >>=20 >> On Wed, Sep 16, 2015 at 1:14 PM, Glen > > wrote: >>=20 >> Hi Benson - >>=20 >> The iCal server is using the same global wildcard certificate that >> the rest of the IETF services are using. >>=20 >> I just reviewed it, and the time zone information appears to be >> correctly set. The expiration date, for example, is: >>=20 >> 8/11/2016 16:12:50 PM (8/11/2016 23:12:50 PM GMT) >>=20 >> Which seems to be more-or-less correct.... >>=20 >> Apologies if I'm missing something or looking in the wrong place? >>=20 >> Glen >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Wed, Sep 16, 2015 at 10:06 AM, Benson Schliesser >> > wrote: >>=20 >> Just a shot in the dark: Given that this issue presents = itself >> when Google Calendar pulls ical info via HTTPS, it occurs to = me >> that perhaps the issue is with timezone info in the server's >> certificate..?=20 >> -B >>=20 >>=20 >> On Wed, Sep 16, 2015 at 12:43 PM, Glen > > wrote: >>=20 >> Understood. I'll make sure everyone here knows this, and = if >> we locate any web pages with the less-desirable link, I'll >> make sure they get updated. >>=20 >> Thanks, >> Glen >>=20 >>=20 >> On Wed, Sep 16, 2015 at 9:40 AM, Lou Berger >> > wrote: >>=20 >>=20 >>=20 >> On 9/16/2015 12:30 PM, Glen wrote: >>> ... >>> Interesting find about the https:// though... >> .. >>=20 >> Given the work around, I'm going to move on to other >> things. As we >> scale out ical services, and more google users show = up, >> we'll need to >> address this. Certainly publishing the http version = as >> 1st choice for >> public calendars will avoid most of this. >>=20 >> Thanks, >> Lou >>=20 >>=20 >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> >> = https://www.ietf.org/mailman/listinfo/tools-development >>=20 >>=20 >>=20 >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org = >> https://www.ietf.org/mailman/listinfo/tools-development >>=20 >>=20 >>=20 >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >>=20 >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Thu Sep 17 07:24:26 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E0A1A1A9E for ; Thu, 17 Sep 2015 07:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIpkDyPo1gP0 for ; Thu, 17 Sep 2015 07:22:44 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 22E891A1A6B for ; Thu, 17 Sep 2015 07:22:44 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 834A71E5A12 for ; Thu, 17 Sep 2015 07:22:00 -0700 (PDT) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by c8a.amsl.com (Postfix) with ESMTPSA id 5D59A1E5A30 for ; Thu, 17 Sep 2015 07:22:00 -0700 (PDT) Received: by obqa2 with SMTP id a2so14360936obq.3 for ; Thu, 17 Sep 2015 07:22:43 -0700 (PDT) X-Received: by 10.60.70.40 with SMTP id j8mr24865558oeu.78.1442499763366; Thu, 17 Sep 2015 07:22:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.80.140 with HTTP; Thu, 17 Sep 2015 07:22:23 -0700 (PDT) From: Glen Date: Thu, 17 Sep 2015 07:22:23 -0700 Message-ID: To: Glen Barney Content-Type: multipart/alternative; boundary=001a11330ab4fbf4b1051ff2255f Archived-At: X-Mailman-Approved-At: Thu, 17 Sep 2015 07:24:25 -0700 Subject: [TOOLS-DEVELOPMENT] Mailman subscribe attacks - a new twist X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 14:22:46 -0000 --001a11330ab4fbf4b1051ff2255f Content-Type: text/plain; charset=UTF-8 Greetings again: Loa is reporting that on his list he is now getting subscribe attacks for email-to-SMS gateway addresses. He reports that he's received about 20 of the following types of subscribe requests in the last day: 2524063603@mms.att.net Obviously, flooding cell phones with junk mail is much more invasive than random GMail addresses. Since this attack targets a US-based carrier, I have applied the same divert-to-secretariat behavior to addresses containing the four primary US cellular carrier domains: txt.att.net mms.att.net vtext.com tmomail.net sprintpcs.com I did a check, and we have exactly zero users on any of our lists in any of these domains. (Which makes sense, most IETF list messages are far too long to deal with over SMS.) I therefore expect that this additional step will have no impact on the community. As an aside, an interesting, if incomplete, resource for gateway addresses is here: http://www.emailtextmessages.com/ I obviously do not intend to apply diversion to all of the domains in their list, but I include it just for interest. As always, any questions, let me know! Glen Glen Barney IT Director AMS (IETF Secretariat) --001a11330ab4fbf4b1051ff2255f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Greetings again:
Loa is reporting that on his list he is now getting subscribe attacks for = email-to-SMS gateway addresses.=C2=A0 He reports that he's received abo= ut 20 of the following types of subscribe requests in the last day:

= 2524063603@mms.att.net
Obviously, flooding cell phones with junk mail is much more in= vasive than random GMail addresses.=C2=A0 Since this attack targets a US-ba= sed carrier, I have applied the same divert-to-secretariat behavior to addr= esses containing the four primary US cellular carrier domains:

txt.att.net
mms.att.net
vtext.co= m
tmomail.net
sprintpcs.com
=

I did a check, and we have exactly zero users on any of= our lists in any of these domains.=C2=A0 (Which makes sense, most IETF lis= t messages are far too long to deal with over SMS.)=C2=A0 I therefore expec= t that this additional step will have no impact on the community.
=

As an aside, an interesting, if incomplete, resource for gateway a= ddresses is here:=C2=A0 http:= //www.emailtextmessages.com/=C2=A0

I obviously do no= t intend to apply diversion to all of the domains in their list, but I incl= ude it just for interest.

As always, any questions, let m= e know!

Glen
Glen Barney
IT D= irector
AMS (IETF Secretariat)

--001a11330ab4fbf4b1051ff2255f-- From nobody Thu Sep 17 07:42:51 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869C01A6F47 for ; Thu, 17 Sep 2015 07:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.389 X-Spam-Level: X-Spam-Status: No, score=-99.389 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRqo6joWEFzh for ; Thu, 17 Sep 2015 07:42:01 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 304081A6F3A for ; Thu, 17 Sep 2015 07:41:55 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 7FC6D1E5A36 for ; Thu, 17 Sep 2015 07:41:11 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by c8a.amsl.com (Postfix) with ESMTPSA id 5CDA41E5A2A for ; Thu, 17 Sep 2015 07:41:11 -0700 (PDT) Received: by oixx17 with SMTP id x17so10607527oix.0 for ; Thu, 17 Sep 2015 07:41:54 -0700 (PDT) X-Received: by 10.202.68.215 with SMTP id r206mr26303951oia.87.1442500914430; Thu, 17 Sep 2015 07:41:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.102.71 with HTTP; Thu, 17 Sep 2015 07:41:35 -0700 (PDT) From: Glen Date: Thu, 17 Sep 2015 07:41:35 -0700 Message-ID: To: Glen Barney Content-Type: multipart/alternative; boundary=001a113dce6097cd1e051ff26ad5 Archived-At: X-Mailman-Approved-At: Thu, 17 Sep 2015 07:42:49 -0700 Subject: [TOOLS-DEVELOPMENT] Mailman subscribe attacks - Cloudflare X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 14:42:02 -0000 --001a113dce6097cd1e051ff26ad5 Content-Type: text/plain; charset=UTF-8 All - As previously noted, one of the reasons we've been unable to just directly block the hosts which are participating in the Mailman attack is because of our use of Cloudflare. Because we are behind Cloudflare, all incoming requests appear (to our IP stack) to be coming from Cloudflare (which, technically, they are.) Cloudflare does pass the remote IP address in a transaction header, but firewalls can't do anything with that. When we began using Cloudflare, we expected that they would detect and block attacks of this type. Their apparent inability to do so, combined with their lack of responsiveness, increases the difficulty we face in dealing with these attacks. As I have mentioned previously, we have reached out to Cloudflare for help with this on several occasions - we have explained the situation to a number of Cloudflare representatives - and we have never received any response or guidance from them at all. Just yesterday, Russ connected me to a new Cloudflare person - I responded to that immediately, but have not heard back from them at all as of yet. I have high hopes that this new contact will work with us, but I mention this again so that you're all aware that we're trying to work within this system. Meanwhile, working independently, one of my engineers has discovered that there may be an automated way to submit IP bans to Cloudflare. He is currently running this down to determine whether such a thing actually exists, and whether its implementation is feasible. Since we have had no communication or support response from Cloudflare, we are, in essence guessing, but we are pursuing this possibility in the hope that we can better fight off the attack in this way. Of course, this is not an ideal solution either: as additional hosts become compromised, the "ban list" will grow. And, once banned, we will no longer know if a particular host is still compromised and/or attacking us, so we will have no way to know if we should "unban" that host. I do not see this as a permanent solution either, but I wanted to make the leadership and tools teams aware of this new possibility, so you all are in the loop as we continue to fight this attack. As pointed out on some threads - we still hope for a more comprehensive, high-level solution to problems of this type, at some point in the future. As always, any questions, let me know. Best regards, Glen Glen Barney IT Director AMS (IETF Secretariat) --001a113dce6097cd1e051ff26ad5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All -

As previously = noted, one of the reasons we've been unable to just directly block the = hosts which are participating in the Mailman attack is because of our use o= f Cloudflare.=C2=A0 Because we are behind Cloudflare, all incoming requests= appear (to our IP stack) to be coming from Cloudflare (which, technically,= they are.)=C2=A0 Cloudflare does pass the remote IP address in a transacti= on header, but firewalls can't do anything with that.=C2=A0

When we began using Cloudflare, we expected that they would detect and= =20 block attacks of this type.=C2=A0 Their apparent inability to do so,=20 combined with their lack of responsiveness, increases the difficulty we=20 face in dealing with these attacks.=C2=A0 As I have mentioned previously, w= e have reached out to Cloudflare for help with this on several occasions - = we have explained the situation to a number of Cloudflare representatives -= and we have never received any response or guidance from them at all.=C2= =A0 Just yesterday, Russ connected me to a new Cloudflare person - I respon= ded to that immediately, but have not heard back from them at all as of yet= .=C2=A0 I have high hopes that this new contact will work with us, but I me= ntion this again so that you're all aware that we're trying to work= within this system.

Meanwhile, working independently, one of = my engineers has discovered that there may be an automated way to submit IP= bans to Cloudflare.=C2=A0 He is currently running this down to determine w= hether such a thing actually exists, and whether its implementation is feas= ible.=C2=A0 Since we have had no communication or support response from Clo= udflare, we are, in essence guessing, but we are pursuing this possibility = in the hope that we can better fight off the attack in this way.

Of course, this is not an ideal solution either:=C2=A0 as additional hos= ts become compromised, the "ban list" will grow.=C2=A0 And, once = banned, we will no longer know if a particular host is still compromised an= d/or attacking us, so we will have no way to know if we should "unban&= quot; that host.=C2=A0 I do not see this as a permanent solution either, bu= t I wanted to make the leadership and tools teams aware of this new possibi= lity, so you all are in the loop as we continue to fight this attack.
<= br>
As pointed out on some threads - we still hope for a more com= prehensive, high-level solution to problems of this type, at some point in = the future.

As always, any questions, let me know.
Best regards,
Glen
Glen Barney
<= /div>
IT Director
AMS (IETF Secretariat)

--001a113dce6097cd1e051ff26ad5-- From nobody Thu Sep 17 13:56:37 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C4D1A0363 for ; Thu, 17 Sep 2015 13:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.688 X-Spam-Level: X-Spam-Status: No, score=-101.688 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxbPzyUvI7_j for ; Thu, 17 Sep 2015 13:55:25 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 554561A0270 for ; Thu, 17 Sep 2015 13:55:25 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id A45DD1E5A2F for ; Thu, 17 Sep 2015 13:54:40 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) by c8a.amsl.com (Postfix) with ESMTPSA id 82E831E5A21 for ; Thu, 17 Sep 2015 13:54:40 -0700 (PDT) Received: by oibi136 with SMTP id i136so16552267oib.3 for ; Thu, 17 Sep 2015 13:55:24 -0700 (PDT) X-Received: by 10.202.78.77 with SMTP id c74mr1102812oib.15.1442523324709; Thu, 17 Sep 2015 13:55:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.102.71 with HTTP; Thu, 17 Sep 2015 13:55:05 -0700 (PDT) From: Glen Date: Thu, 17 Sep 2015 13:55:05 -0700 Message-ID: To: Glen Barney Content-Type: multipart/alternative; boundary=001a11c16d505983d2051ff7a212 Archived-At: X-Mailman-Approved-At: Thu, 17 Sep 2015 13:56:22 -0700 Subject: [TOOLS-DEVELOPMENT] Mailman subscribe attacks - Cloudflare redux X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 20:55:27 -0000 --001a11c16d505983d2051ff7a212 Content-Type: text/plain; charset=UTF-8 All - Seven hours ago I reported that we had discovered an API that allows us to automatically block, in Cloudflare, IP addresses from which attacks are coming. The good news: We successfully deployed a script that let us feed data to that API, and began blocking the IP Addresses in the attacking network. The bad news: Cloudflare appears to have a limit of 2000 entries in their blacklist table. We have exceeded that limit. (We have identified almost twice as many IP addresses currently in use as attack sources.) So, unfortunately, that method will not be a good solution here. At the moment, we have successfully blocked all currently-identified attacks using our configurable referral screen, and we will continue to watch for changes in the attack and adapt as possible. I just wanted to make sure everyone was aware of where this potential solution went. Thanks, Glen Glen Barney IT Director AMS (IETF Secretariat) --001a11c16d505983d2051ff7a212 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All= -

Seven hours ago I reported that we had discovered an API th= at allows us to automatically block, in Cloudflare, IP addresses from which= attacks are coming.

The good news:=C2=A0 We successfully depl= oyed a script that let us feed data to that API, and began blocking the IP = Addresses in the attacking network.

The bad news:=C2=A0 Cloudf= lare appears to have a limit of 2000 entries in their blacklist table.=C2= =A0 We have exceeded that limit.=C2=A0 (We have identified almost twice as = many IP addresses currently in use as attack sources.)

So, unf= ortunately, that method will not be a good solution here.

At t= he moment, we have successfully blocked all currently-identified attacks us= ing our configurable referral screen, and we will continue to watch for cha= nges in the attack and adapt as possible.

I just wanted to mak= e sure everyone was aware of where this potential solution went.

Thanks,
Glen
Glen Barney
IT Director
AMS (IETF Secretariat)


--001a11c16d505983d2051ff7a212-- From nobody Thu Sep 17 16:49:03 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186581A87A9 for ; Thu, 17 Sep 2015 16:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.388 X-Spam-Level: X-Spam-Status: No, score=-99.388 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eyYdNSrys19 for ; Thu, 17 Sep 2015 16:48:02 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 374531A879D for ; Thu, 17 Sep 2015 16:48:02 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 108801E5A07 for ; Thu, 17 Sep 2015 16:47:17 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by c8a.amsl.com (Postfix) with ESMTPSA id E337B1E5A0C for ; Thu, 17 Sep 2015 16:47:16 -0700 (PDT) Received: by obbda8 with SMTP id da8so25884877obb.1 for ; Thu, 17 Sep 2015 16:48:01 -0700 (PDT) X-Received: by 10.182.19.167 with SMTP id g7mr1778958obe.13.1442533681489; Thu, 17 Sep 2015 16:48:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.102.71 with HTTP; Thu, 17 Sep 2015 16:47:42 -0700 (PDT) From: Glen Date: Thu, 17 Sep 2015 16:47:42 -0700 Message-ID: To: Glen Barney Content-Type: multipart/alternative; boundary=001a11c2ea20a96ea0051ffa0b2d Archived-At: X-Mailman-Approved-At: Thu, 17 Sep 2015 16:49:01 -0700 Subject: [TOOLS-DEVELOPMENT] Mailman attacks - Cloudflare Contact X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 23:48:03 -0000 --001a11c2ea20a96ea0051ffa0b2d Content-Type: text/plain; charset=UTF-8 All - Just by way of a final follow-up, I'm very happy to report that, thanks to Russ, I'm now in touch with one of the top people at Cloudflare. I'll be working with them directly to further mitigate the attacks and find a good long-term solution. One of the things we've already found is that they're able to increase the 2000-address limit I reported earlier, and they will be doing that for us shortly. That will enable us to add the remaining IP addresses to the tables and at least get the compromised hosts blocked. We have other ideas we'll be exploring as well, and, hopefully, we can make things better going forward. In the meantime, we'll be watching for any new attack vectors, but please do report any anomalies or new attacks you find to me directly, and we'll do what is needed to get it handled. I personally am on travel tomorrow, so I will not be able to respond immediately to any emails, but my staff will be here and working with Cloudflare to get the remaining hosts blocked. Thank you all for your patience and support during this rather strange and bumpy episode. I'm very hopefully that this is the end of it, or will be very shortly. Best regards, Glen Glen Barney IT Director AMS (IETF Secretariat) --001a11c2ea20a96ea0051ffa0b2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All= -

Just by way of a final follow-up, I'm very happy to rep= ort that, thanks to Russ, I'm now in touch with one of the top people a= t Cloudflare.=C2=A0 I'll be working with them directly to further mitig= ate the attacks and find a good long-term solution.

One of the= things we've already found is that they're able to increase the 20= 00-address limit I reported earlier, and they will be doing that for us sho= rtly.=C2=A0 That will enable us to add the remaining IP addresses to the ta= bles and at least get the compromised hosts blocked.

We have o= ther ideas we'll be exploring as well, and, hopefully, we can make thin= gs better going forward.

In the meantime, we'll be watchin= g for any new attack vectors, but please do report any anomalies or new att= acks you find to me directly, and we'll do what is needed to get it han= dled.=C2=A0

I personally am on travel tomorrow, so I will not= be able to respond immediately to any emails, but my staff will be here an= d working with Cloudflare to get the remaining hosts blocked.

= Thank you all for your patience and support during this rather strange and = bumpy episode.=C2=A0 I'm very hopefully that this is the end of it, or = will be very shortly.

Best regards,
Glen
Gle= n Barney
IT Director
AMS (IETF Secretariat)

--001a11c2ea20a96ea0051ffa0b2d-- From nobody Mon Sep 28 15:37:05 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4776F1A010D for ; Mon, 28 Sep 2015 15:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzZpaYnpqZjr for ; Mon, 28 Sep 2015 15:37:02 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE4B1A0104 for ; Mon, 28 Sep 2015 15:37:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 53D131E5A2C for ; Mon, 28 Sep 2015 15:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDg6GYk4jaCU for ; Mon, 28 Sep 2015 15:36:53 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [207.118.10.228]) by c8a.amsl.com (Postfix) with ESMTPSA id 1CB801E59EE for ; Mon, 28 Sep 2015 15:36:53 -0700 (PDT) References: <5609C0BA.9060306@rfc-editor.org> To: tools-development@ietf.org From: "Heather Flanagan (RFC Series Editor)" X-Forwarded-Message-Id: <5609C0BA.9060306@rfc-editor.org> Message-ID: <5609C10C.1040105@rfc-editor.org> Date: Mon, 28 Sep 2015 15:37:00 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5609C0BA.9060306@rfc-editor.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [TOOLS-DEVELOPMENT] Fwd: RFC Editor website changes X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 22:37:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Tools Team: An announcement went out to the IESG and IAB today re: the plans to cut over the RFC Editor Website. You, too, can share in the experience and check out the new site! See info below. - -Heather - -------- Forwarded Message -------- Subject: RFC Editor website changes Date: Mon, 28 Sep 2015 15:35:38 -0700 From: Heather Flanagan (RFC Series Editor) To: iab@iab.org, iesg@ietf.org CC: rsoc@iab.org, sginoza@amsl.com, arusso@amsl.com Hello IAB and IESG, As you may recall from various announcements during the technical plenaries, and updates during our Sunday meetings at various IETF meetings, the RFC Editor is planning a major revamp of our website. The new site will be significantly easier to maintain and, hopefully, allow people to more easily find the information they might be looking for. As the look and layout of the website has not appreciably changed since 2002, there is going to be some adjustment for people as they get used to the new site. For primary content, there will be a redirect in place if the URL has changed. We expect to incrementally improve the site as we receive feedback or have new ideas ourselves for how to make things better. For now, please feel free to look at https://www2.rfc-editor.org on your laptop, your tablet, or your phone and let us know what you think by sending mail to [rfc-interest@rfc-editor.org]. We plan to begin switchover operations (www2.rfc-editor.org will become www.rfc-editor.org) on 1 October at 8:30 AM Pacific Time, and we estimate that the entire process will take less than four hours. During that window, most pages and services will be up; however, as replacements are made, some pages and services may be unavailable, or may contain links that do not work properly. Please be patient during the switchover period As you are seeing the 'pre-release' version, please note that some data (e.g., queue reports) on the www2 site may be stale, as that site is currently running from a development copy of the database. It will be changed to the production database upon switchover on October 1. Feedback is always welcome. If you have any questions, suggestions, or concerns, please post to rfc-interest@rfc-editor.org and we can discuss. If you want to report a bug, that goes to webmaster@rfc-editor.org. - -Heather Flanagan, RSE -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJWCcEMAAoJEER/xjINbZoGeSwH/3YBAKqCRNqAbFn62KVVjk6H RyJNwOKPraUS1xEX0jXU/bWKL35jkyxU0m4zh2fbliyNG+goTuSDyqdAZRRrGiul YZCvPd6RjPZe/w0FkE4btzIzjAEZNiinth/fe6CtNByqjHOTL/hgATIxFc/wLYYU iy1e3aZIPXd73LLjyd311QGKy0cCNWYK3UjO6QymZppIvLWfJHOiwd4zQsySOX7c JwkXz6XpydAB7z8yXnMNocNRAfRiGxyF6vpS/QL5Zw4EXaa/FWoK3da4WDe5e9r3 rWpKTlW7pe/XxvzHsqzOaQMApm29hDozWugGEsw7mPQEj8lrB+SMXi6WveiMOV0= =jtBj -----END PGP SIGNATURE----- From nobody Tue Sep 29 04:00:31 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703A11A00D0 for ; Tue, 29 Sep 2015 04:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AakgnG_j5qlQ for ; Tue, 29 Sep 2015 04:00:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678C81A00CF for ; Tue, 29 Sep 2015 04:00:27 -0700 (PDT) Received: from tannat.netnod.se ([77.72.226.96]:62032) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Zgse0-0000mC-FA; Tue, 29 Sep 2015 04:00:26 -0700 To: "Heather Flanagan (RFC Series Editor)" , tools-development@ietf.org References: <5609C0BA.9060306@rfc-editor.org> <5609C10C.1040105@rfc-editor.org> From: Henrik Levkowetz X-Enigmail-Draft-Status: N1110 Message-ID: <560A6F45.9070805@levkowetz.com> Date: Tue, 29 Sep 2015 13:00:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5609C10C.1040105@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="x7NPUlS74HasPI1NhFWIvemX8aUg9qqRJ" X-SA-Exim-Connect-IP: 77.72.226.96 X-SA-Exim-Rcpt-To: henrik-sent@levkowetz.com, tools-development@ietf.org, rse@rfc-editor.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Fwd: RFC Editor website changes X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 11:00:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x7NPUlS74HasPI1NhFWIvemX8aUg9qqRJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Heather, I'm happy to see a more responsive design. Some quick web mechanics issues: - The left-hand menubar disappears and the top menu icon appears when the width goes below 801px, but the space for the lefthand menubar remains, blank, until the width goes below 701px. This results in unintentional bad layout for widths of 701px to 800px. - If one runs javascript, there seems to be javascript snippet which for some widths runs _all the time_, and results in constantly changin= g values for the left: style of the
with id=3D"responsive-menu". I haven't looked closely if the style itself is being manipulated or if the flutter I see in my page inspector is the result of width chang= es in a subsidiary element. I suspect however that this could cause bad battery-draining on mobile devices of the wrong widths. Also, it seems to me that things work fine without javascript enabled, so I'm not sure exactly why that over-eager snippet is in use. Other observations: - The rfc errata summary table doesn't adapt well to widths less than 12= 12px Best regards, Henrik On 2015-09-29 00:37, Heather Flanagan (RFC Series Editor) wrote: >=20 >=20 > Hello Tools Team: >=20 > An announcement went out to the IESG and IAB today re: the plans to cut= > over the RFC Editor Website. You, too, can share in the experience and > check out the new site! See info below. >=20 > -Heather >=20 > -------- Forwarded Message -------- > Subject: RFC Editor website changes > Date: Mon, 28 Sep 2015 15:35:38 -0700 > From: Heather Flanagan (RFC Series Editor) > To: iab@iab.org, iesg@ietf.org > CC: rsoc@iab.org, sginoza@amsl.com, arusso@amsl.com >=20 >=20 >=20 >=20 > Hello IAB and IESG, >=20 > As you may recall from various announcements during the technical > plenaries, and updates during our Sunday meetings at various IETF > meetings, the RFC Editor is planning a major revamp of our website. The= > new site will be significantly easier to maintain and, hopefully, allow= > people to more easily find the information they might be looking for. A= s > the look and layout of the website has not appreciably changed since > 2002, there is going to be some adjustment for people as they get used > to the new site. >=20 > For primary content, there will be a redirect in place if the URL has > changed. We expect to incrementally improve the site as we receive > feedback or have new ideas ourselves for how to make things better. For= > now, please feel free to look at https://www2.rfc-editor.org on your > laptop, your tablet, or your phone and let us know what you think by > sending mail to [rfc-interest@rfc-editor.org]. We plan to begin > switchover operations (www2.rfc-editor.org will become > www.rfc-editor.org) on 1 October at 8:30 AM Pacific Time, and we > estimate that the entire process will take less than four hours. During= > that window, most pages and services will be up; however, as > replacements are made, some pages and services may be unavailable, or > may contain links that do not work properly. Please be patient during > the switchover period >=20 > As you are seeing the 'pre-release' version, please note that some > data (e.g., queue reports) on the www2 site may be stale, as that site > is currently running from a development copy of the database. It will > be changed to the production database upon switchover on October 1. >=20 > Feedback is always welcome. If you have any questions, suggestions, or > concerns, please post to rfc-interest@rfc-editor.org and we can discuss= =2E > If you want to report a bug, that goes to webmaster@rfc-editor.org. >=20 > -Heather Flanagan, RSE >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 --x7NPUlS74HasPI1NhFWIvemX8aUg9qqRJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJWCm9FAAoJEE6bV0uPuxcajLcQAII/UuqS+ZP2X4p51ycYV53R DYT6y7jVG5GrJ9FnUa40Q5C2en3lsDy3hNIA1prce0CjZw/d0dSTULIzkYI+lp3h ohMKKrllSvB2n/y1Vzbkn5N0HlH54PImlGk2KHObg0CC0yaVQ+FnrzSddXLH6sP/ ufkvQ42qqQnLx62fZKVxrQfDZY+L+7a166Y7FI9trSqXAA136HowbqUgmdMX+XLn fbt6H7/L0ocmtwAMackgV+S++83Li+8kW+V50XheY/7i6VJXrpoZaNTQ0yVBFKIi BC9tdQ0y/EBUIEYk8GE4AeMFCaYbKdaOnP11H5anvvkftiW2DOa7eXQslvrYzOtj SIkqLoUsxLurcVfs7V8kxFC5vJkhDgRHaKq508gNSZFWFPzS6wbqvDS2V46SnSZJ 1vYy5SmVPXGFPmcpoi4kHDS6GOWAODiz9KxnmyU2mvhdaKLcCfuYv2KOtfLYDwMW xEZPgq33nh/SB58B7niXK9LZ644Xx+fM0VCnXCQuW9BZQSgYiFGkl0DozavxIRoh sXXf28g+AaE01h5zbCcNWpTdGnkE0cQranh2PsW6Abfw9aVViITCin6AsJz3D8gp 9pKXSbEVOy8xFCeAQEZwH3rjSuaat2QQmfBYGuO9azxvF+5cscMQY+7EzoJSlRPR NYnGrvS0ZRytFfWZ3qEM =fM0c -----END PGP SIGNATURE----- --x7NPUlS74HasPI1NhFWIvemX8aUg9qqRJ-- From nobody Tue Sep 29 12:25:38 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424EC1B2B7C for ; Tue, 29 Sep 2015 12:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y10wVh1UTYqN for ; Tue, 29 Sep 2015 12:25:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0081B2B7A for ; Tue, 29 Sep 2015 12:25:31 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8TJPU8T050329 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Tue, 29 Sep 2015 14:25:31 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local To: IETF Tools Development From: Robert Sparks Message-ID: <560AE5A5.5000308@nostrum.com> Date: Tue, 29 Sep 2015 14:25:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [TOOLS-DEVELOPMENT] Three new SoWs (interim meetings, manual posts, review tracker) X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 19:25:37 -0000 All - Please review the three new SoWs at http://www.nostrum.com/~rjsparks/pmsow/ These are for improvements to * Interim meeting management * Tracking I-D manual post requests and * Building review tracking into the datatracker Please provide any feedback ASAP. These have been cooking for awhile (I've asked for feedback on the content on this list several times), and I'll be pushing the TMC to move these forward quickly. RjS From nobody Tue Sep 29 14:49:56 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750B81B522A for ; Tue, 29 Sep 2015 14:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SM2YHBEQkSrU for ; Tue, 29 Sep 2015 14:49:53 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5041B5229 for ; Tue, 29 Sep 2015 14:49:53 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8TLnqbv064235 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Tue, 29 Sep 2015 16:49:53 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local To: tools-development@ietf.org References: <560AE5A5.5000308@nostrum.com> From: Robert Sparks Message-ID: <560B077B.7030106@nostrum.com> Date: Tue, 29 Sep 2015 16:49:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560AE5A5.5000308@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Three new SoWs (interim meetings, manual posts, review tracker) X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 21:49:54 -0000 The secretariat sent some comments on the interim meeting SoW that I've incorporated. interim-sow-01 has clarifications around who can approve a meeting, and a new section on canceling requests. RjS On 9/29/15 2:25 PM, Robert Sparks wrote: > All - > > Please review the three new SoWs at > http://www.nostrum.com/~rjsparks/pmsow/ > > These are for improvements to > * Interim meeting management > * Tracking I-D manual post requests > and > * Building review tracking into the datatracker > > Please provide any feedback ASAP. These have been cooking for awhile > (I've asked for feedback on the content on this list several times), > and I'll > be pushing the TMC to move these forward quickly. > > RjS > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development