[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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" <pekkas@netcore.fi>
To: <v6ops@ops.ietf.org>
Cc: <alain.durand@sun.com>; <florent.parent@hexago.com>
Sent: Saturday, July 17, 2004 8:59 PM
Subject: WG Last Call: draft-ietf-v6ops-assisted-tunneling-requirements-00.txt


> 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!
> 
> 
> 


**********************************
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.