Re: New Non-WG Mailing List: fun -- FUture home Networking (FUN)

Stephane, John, FUN is a new working group proposal, a variation of the HOMEGATE / HOMENET theme that we discussed some time ago but this time looking at it from a different angle. Roughly speaking, its about how to run IPv6 in home networks, including some possibly missing protocol pieces.

Re: New Non-WG Mailing List: fun -- FUture home Networking (FUN)

>>> Purpose: Mailing list for proposed working group on FUture >>> home Networking (FUN) >> >> And nothing more (same thing on the Web site). Could we ask >> for a little bit more context when a new IETF list is created? > > I think asking is perfectly reasonable.  But I also think we > should trus

Re: New Non-WG Mailing List: fun -- FUture home Networking (FUN)

--On Monday, June 06, 2011 22:47 +0200 Stephane Bortzmeyer wrote: > On Mon, Jun 06, 2011 at 09:54:56AM -0700, > IETF Secretariat wrote > a message of 15 lines which said: > >> Purpose: Mailing list for proposed working group on FUture >> home Networking (FUN) > > And nothing more (same th

Re: Proposed text for IESG Handling of Historic Status

I think that there are three sets of proposed state changes - what the author would like to do, what the working group if any agrees to do, and what the IESG wants to instruct the RFC Editor should ultimately be done. There is no reason they all have to be the same. For example, a document autho

Re: Proposed text for IESG Handling of Historic Status

>> My understanding is that any RFC can be moved to Historic. But if this >> is not clear from RFC 2026, maybe it is worth clarifying. > > If 2026 doesn't limit what types of RFCs can become Historic, then I presume > any of them can.  I'm not sure we need to make that explicit. I'm sure we don't.

Re: Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

On Mon, Jun 6, 2011 at 13:22, Keith Moore wrote: > I strongly object to the proposed reclassification of these documents as > Historic. > ** > Agreed that this is too harsh, too soon. Fixing the broken implementations is a better idea than trying to break the working ones. And I am not just sa

Re: Gen-ART LC review of draft-faltstrom-5892bis-04

On May 29, 2011, at 4:13 AM, Roni Even wrote: > Major issues: > > 1. I am not sure how the IANA consideration section is in-line with the > IANA consideration section of RFC5892. Maybe some clarification text would be > helpful. We think that the IANA considerations here are, in fact, wh

Subversion troubles?

I'm using svn 1.6.15 on Mac OS X 10.6.7. It used to work fine for me, but recently it stopped working. I now get SSL errors, e.g.: > % svn ls https://svn.tools.ietf.org/svn/wg/6lowpan > svn: OPTIONS of 'https://svn.tools.ietf.org/svn/wg/6lowpan': SSL negotiation > failed: SSL error code -1/1/33

Re: New Non-WG Mailing List: fun -- FUture home Networking (FUN)

On Mon, Jun 06, 2011 at 09:54:56AM -0700, IETF Secretariat wrote a message of 15 lines which said: > Purpose: Mailing list for proposed working group on FUture home Networking > (FUN) And nothing more (same thing on the Web site). Could we ask for a little bit more context when a new IETF li

Re: Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

Nothing to say here that Keith hasn't already said in so many fine words. In summary: +-1. Heck, no, -1000. I especially dislike the registry changes; those are deeply, *deeply* irresponsible. On 6 Jun 2011, at 18:22, Keith Moore wrote: > I strongly object to the proposed reclassification of

Re: Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

I strongly object to the proposed reclassification of these documents as Historic. 6to4 still has many valid use cases, and there is not a suitable replacement for it that has been deployed. Until there is a suitable replacement, or until there is widespread ISP support for native IPv6, recl

Gen-ART LC review of draft-ietf-dime-ikev2-psk-diameter-07

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dime-ikev2-psk-diameter-07 R

Re: TSVDIR Review for draft-ohba-pana-relay-03

Nishida-san, Thank you very much for reviewing the draft. Please see my comments below. (2011/06/06 17:39), Yoshifumi Nishida wrote: > Hello, > I've reviewed this document as part of the transport area > directorate's ongoing effort to review key IETF documents. These > comments were written pri

Re: tsv-dir review of draft-ietf-behave-ftp64-10

Thanks everyone for the comments. I'll look into the other technical comments later this week, but there's one I can respond to right now: On 4 jun 2011, at 0:16, Fernando Gont wrote: > * Section 1, page 3: > In 5 cases, issuing the EPSV > command to the server led to a significant delay, i

Individual submission rationale - draft-brasher-ltasp-05

Hello This draft has been written to provide a reference. The open source production implementation itself is strong in delivery and in principle. A significant portion of this draft covers areas not normally covered by IETF. Perhaps there is a small chance another vendor may want to write an im

TSVDIR Review for draft-ohba-pana-relay-03

Hello, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues