Re: Stockholm airport

Two other things that may be worth noting-- The express train between the city and Arlanda has a special summertime ticketing deal where 2 adults traveling together can share a single ticket costing 250 kr. Also the 24 hour, 72 hour, and 7 day travel passes on the public transit system are good f

Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

FYI: I'm tracking proposed changes to -06 as a result of Last Call at: http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt with a diff at: http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from-6.diff.html Cheers, -- Mark Nottingham http://www.mnot.net/

RE: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using Only A Password) to Proposed Standard

Bernard Aboba [mailto://bernard.ab...@hotmail.com] writes: I would like to comment on the process aspect of this IETF last call. A subsequent post will provide comments on the protocol. Overall, I believe that the appropriate process for handlin

Re: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using Only A Password) to Proposed Standard

I would like to comment on the process aspect of this IETF last call. A subsequent post will provide comments on the protocol. Overall, I believe that the appropriate process for handling this document is not to bring it to IETF last call as an individual submission, but rather to charter

Re: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication UsingOnly A Password) to Informational RFC

Hi John, On Wed, July 22, 2009 10:27 am, John Leslie wrote: >The difference may not be as great as you seem to think. Appeal if > you must, but it's really not unusual to change "proposed status" as > a result of LastCall comments. It might be more helpful to simply post > (polite) LastCall

Comment on TLP revisions re non-IETF documents

This may seem like a small comment but I believe it is important. We know that we have an issue to resolve collectively, namely the IPR regimes for non-IETF stream documents. We probably agree that (as the revised TLP says or implies) it is for each stream individually to decide whether it accepts

RE: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exportersfor Transport Layer Security (TLS)) to Proposed Standard

I agree with Simon that the IETF's disclosure page could use some work, it seems rather confusing and it is not consistently filled out. Comments inline below: > If your interpretation were correct, then we would have to > say that Certicom is not claiming IPR on _any_ IETF > document---draf

Re: Last Call: draft-ietf-tls-extractor (Keying Material Exportersfor Transport Layer Security (TLS)) to Proposed Standard

Let's go back to RFC 3979: 6.4. What Must be in a Disclosure? 6.4.1. The disclosure must list the numbers of any issued patents or published patent applications or indicate that the claim is based on unpublished patent applications. The disclosure must also list the specific IETF

RE: Last Call: draft-ietf-tls-extractor (Keying Material Exportersfor Transport Layer Security (TLS)) to Proposed Standard

While I see that draft-ietf-tls-extractor is listed in section IV of #1154 IPR disclosure as related material, I see that it is explicitly not listed in section V part C which lists what is specifically covered by the disclosure. I don't think Certicom is claiming IPR on draft-ietf-tls-extractor

Re: Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

With the caveat that I have recently returned from vacation, and consequently may have missed some clarifications or paged out some context: If the #1154 IPR disclosure is the final word from Certicom on this document, I don't support advancing this document on the standards track. My concern rem

Re: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication UsingOnly A Password) to Informational RFC

Glen Zorn wrote: > Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com] writes: > >> I object to this document being published as a Proposed Standard. When >> this document was discussed in the EMU meeting at IETF-71 there was >> much concern raised with respect to existing IPR... > > IMHO, t

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

Harald Alvestrand wrote: > > The working group's non-consensus on this point is documented in section > 4.4 of RFC 5377: >... ... of historical interest only, IMHO... > The "RFC 5378" license to the trust allows, for instance, the Trust to > grant the right of copying small snippets of co

Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP Requirements)toProposed Standard

- Original Message - From: "Adrian Farrel" To: "Tom.Petch" Cc: "ietf" Sent: Tuesday, July 21, 2009 11:36 PM Subject: Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP Requirements)toProposed Standard > Hi Tom, > > >> > a) The security section of this I-D says > >> > see[I-D.i

Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

At Wed, 22 Jul 2009 09:59:38 +, Florian Weimer wrote: > Anyway, those who object to the ECC infection should strive to remove > it from the base TLS spec. It doesn't make sense to rehash this > discussion over and over again, for each draft produced by the WG > which happens to be compatible w

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

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

RE: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication UsingOnly A Password) to Informational RFC

Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com] writes: > I object to this document being published as a Proposed Standard. When > this document was discussed in the EMU meeting at IETF-71 there was > much > concern raised with respect to existing IPR in the area of secure > password metho