Subject: WG Last Call: draft-ietf-v6ops-assisted-tunneling-requirements-00.txt

From: Pekka Savola <[email-masked]>
Date: Sat, 17 Jul 2004 21:59:50 +0300 (EEST)

Hi all,

(co-chair hat on)

This is the WG Last Call for comments on sending
draft-ietf-v6ops-assisted-tunneling-requirements-00.txt, "Requirements
for assisted tunneling" to the IESG for consideration as Informational
RFC:

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-00.txt

This document will be used as a basis for possible (re-)design of
appropriate transition mechanisms.

Please review the document carefully, and send your feedback to the
list.  Please also indicate whether or not you believe that this
document is ready to go to the IESG.

The last call will end in about 3.5 weeks, on 9th August.  The large
WGLC time is due to the IETF meeting.  It is recommended that
participants read and comment prior to the IETF as the topic will be
discussed there.

Thanks!

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sat, 17 Jul 2004 22:00:53 +0200

Hi all,

May be is worth to make 2 sub-sections in 4.1 to make more evident which text belong to each mode. Alternatively:
Replace
    The tunnel established is "anonymous" in a sense as the end-user does not register explicitly to the server ...
With
    In the non-registered mode, The tunnel established is "anonymous" in a sense as the end-user does not register explicitly to the server ...
Or
    In this mode, the tunnel established is "anonymous" in a sense as the end-user does
   not register explicitly to the server ...

Other suggestions follow.

Replace
    In non-registered mode, the IPv6 address is "transient" and may
   change, but the protocol SHOULD offer a mechanism to provide IPv6
   address stability in this mode (e.g. cookie mechanism). The
   implementation of this mechanism MUST allow this feature to be turned
   off.  In registered mode, the protocol MUST be able to support
   servers willing to offer stable IPv6 prefixes to the authenticated
   customers.
With
   In non-registered mode, the IPv6 address is "transient" and may
   change, but the protocol SHOULD offer a mechanism to provide IPv6
   address stability, by default, in this mode (e.g. cookie mechanism). The
   implementation of this mechanism MUST allow this feature to be turned
   off, being on by default.  In registered mode, the protocol MUST be able to support
   servers willing to offer stable IPv6 prefixes to the authenticated
   customers, by default.

In my opinion, we should prefer stable addresses, right ?

Replace
   The protocol MAY send information about registration procedure when a
   non-registered client requests registered mode (ex: URL to provider
   registration web page).

With
   The protocol MAY send information about registration procedure when a
   non-registered client requests registered or non-registered mode (ex: URL to provider
   registration web page).

If a non-registered client request non-registered usage, he can also receive the URL. He will decide then if he want to register or not.

Service Discovery. Should a reference to http://www.ietf.org/internet-drafts/draft-palet-v6ops-tun-auto-disc-01.txt, be included here ?

I think is very negative for deployment to say "Non registered service should be limited to the provider network". I think it should be clarified that this is desired to avoid security threats, but not as a general recommendation, which seems to be the actual read (even if within the thread section).

"A then can, for example ..."??? I guess it should be "Then can, for example ..."

Replace "a customer A ..." with "a customer ..."

There are several mentions of ISP in the document that should be probably ISPs ?

Replace
    customers a message explaining that no service is available.
With
    customers a message explaining that no service is available in that ISP. In that case, if alternative ISPs offer the service it could also be signaled to the customer.

Replace "to to turn on ..." with "to turn on/off..."

Regarding the keep-alive messages, I suggest to change the example of the ISDN type links to something more generic to cover two cases:
- A low bandwidth link (ISDN, modem, etc.)
- A link which the user pay for traffic (GPRS, 3GPP, ...)
I will also add something to provide the option to negotiate the timing among keep-alive messages, for example, a default configuration depending on the bandwidth/cost available and then configured by the user/server.

In 6.2, a way to achieve the client to be able to choose one of them, a reference to http://www.ietf.org/internet-drafts/draft-palet-v6ops-auto-trans-00.txt can be useful.

I also wonder if in case of the NAT supports proto-41-forwarding, a reference to this must also be added, probably a section 6.4 ?

Regards,
Jordi

PS: There are several "nits" but I guess they will be addressed also in the next step-

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Saturday, July 17, 2004 8:59 PM
Subject: WG Last Call: draft-ietf-v6ops-assisted-tunneling-requirements-00.txt

> participants read and comment prior to the IETF as the topic will be

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Jul 2004 15:57:52 +0200

I think this draft will have an easier future if the "R" word
("requirement") is replaced by "goal" and the normative MUSTs/SHOULDs
etc. are changed to lower case.

Requirements written in normative language always lead to a lot
of rather futile discussion.

(If you don't do this, the introduction needs the traditional
paragraph citing RFC 2119, which is listed in the references
but not cited in the text.)

The substance of the document seems good to me.

    Brian