Subject: isatap-07 draft offered as last-call

From: Fred Templin <[email-masked]>
Date: Thu, 21 Nov 2002 05:00:41 -0800 (PST)

Hello,

As per Harald Alvestrand's message "On NGTRANS, transition mechanisms and consortia",
I would like to offer the current isatap version as immediate last-call candidate for
experimental track. The document can be found at:

  http://www.geocities.com/osprey67/isatap-07.txt

Fred Templin
[email-masked]

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Nov 2002 15:28:53 +0200 (EET)

>   http://www.geocities.com/osprey67/isatap-07.txt

Please be specific what you mean.

I took Harald's message as to signify "you can always submit a draft for 
experimental as an individual submission".

It's not clear to me whether you interpreted it as something else (like, 
wg can automatically adjust the charter to accept documents to be 
published as experimental).

btw. the draft does not mention there have been IPR claims.  IMO it's a 
good practise to state that.

btw.2. security considerations wrt. disclosing the potentially NAT'ed 
addresses is still not mentioned.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Nov 2002 15:49:53 +0200 (EET)

> good practise to state that.

Sorry, I missed it completely as it was so far down after the appendices 
and there is no table-of-contents.

The statement itself appears to be fine.

---

From: Fred Templin <[email-masked]>
Date: Thu, 21 Nov 2002 06:02:30 -0800 (PST)

Specifically, Harald's message states:

> There are several ways around this if you want things published:
> - Publish through other mechanisms than the RFC process
> - Publish as Experimental RFC
> - Plead with the ADs to sponsor the mechanisms for standards track based on their obvious merits
(identifying the mechanisms they obsolete) 

Thus, I am seeking to publish as an Experimental RFC and also pleading with the ADs to
sponsor the mechanism for standards track based on obsoleting RFC 2529 (6over4).
 
> addresses is still not mentioned.

Thanks,

Please upload the new version found at:

Fred Templin

__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com

---

From: Jason Goldschmidt <[email-masked]>
Date: Thu, 21 Nov 2002 07:36:52 -0800

>  http://www.geocities.com/osprey67/isatap-07.txt
Fred,

Thank you for providing this updated draft.

I have a question regarding text added to section 5.2.4 (Host 
Specification). This sections says that "Hosts select one and only one 
member of the PRL ("PRL(i)") and ...". How should this one member be 
selected from the PRL?

A related question, after selecting the one member and RS's sent to this 
member are not replied, should another member be selected? If so, how 
long should the host wait before trying a new member?

What are the implications of having a PRL with length > 1? Is it that 
only one entry is used to act as the "active" router and thus the 
default route, but other entries define policy for receiving packets? An 
ACL if you will.

thanks,

-Jason

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Nov 2002 16:47:51 +0100

below...

> sponsor the mechanism for standards track based on obsoleting RFC 2529 (6over4).

That is egregious and irrelevant. I would object very strongly. 6over4 is
is self-contained and there is no reason to couple its future to that
of ISATAP. As a matter of fact, 6over4 has no affiliation with either
NGTRANS or V6OPS; it was an IPNGWG document and if any WG owns it
today, it would be IPV6.

2529 should sleep harmlessly as a Proposed Standard. Its day may come, and
it is harmless.

   Brian

---

From: Fred Templin <[email-masked]>
Date: Thu, 21 Nov 2002 09:27:02 -0800 (PST)

Jason,

Thanks for the comments. I can see the points where clarification is needed.
For an ACL function, we would like some indication that the other entries in
the list share the same trust model and the PRL provides this. Administratively
this works out. But, if we're not actively polling the routers we have no prefix
and/or default router lifetime information from them. Thus, we need to stick
with the one we are polling and autoconfig addresses only from it. I'll make
sure this is made clear in the text.

Thanks,

Fred
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Thu, 21 Nov 2002 09:31:23 -0800 (PST)

Brian,

Apologies; I should have checked with you first on this. With the comments
received, I intend to revisit the last-call and repost when we have the
process and technical details worked out.

Fred

---

From: Alain Durand <[email-masked]>
Date: Thu, 21 Nov 2002 11:25:58 -0800

Fred Templin wrote:

>experimental track. 

I strongly object to the publication of this document.

   When a node enables an ISATAP link, it initializes the Potential
   Router List (PRL) for that link. Unless other information is avail
   able (e.g., manual address configuration, a vendor-specific DHCP
   option, etc.), the DNS SHOULD be consulted (e.g., by resolving the
   name "isatap.domainname" where "domainname" MUST be relative to the
   node's physical point of attachment.)

a) domainname is a information that is relative to the name space and 
gives no information
    whatsoever about the physical location of the machine.
    For example, at Sun, we use many domains like eng.sun.com, 
uk.sun.com, east.sun.com....
    Some of them a somehow loosely linked to a particular geography 
(east.sun.com, uk.sun.com)
    while some other are organisational domains (eng.sun.com) that may 
span across geography.

b) You are using something that does not belong to you.
     The name isatap could very well have been already assigned in my 
DNS zone.

    - Alain.

---

From: Fred Templin <[email-masked]>
Date: Thu, 21 Nov 2002 11:28:42 -0800 (PST)

Alain,

I agree with your concerns, and you raise good points. I also have comments from
Brian Carpenter and Jason Goldschmidt; I'd like to back off on the last call until
the issues are addressed.

Fred
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Thu, 21 Nov 2002 12:01:15 -0800 (PST)

Alain,

>     while some other are organisational domains (eng.sun.com) that may 

You know, on further thought we've been down this road many times before.
I am specifically *not* meaning to infer that the node magically locates
the topologically closest domainname by geography/topology. Instead, the
text includes flexibility to allow automatic discovery when a node rarely
travels around and manual config when the node goes mobile.  

>      The name isatap could very well have been already assigned in my 

Again, we've talked about this before. This seems like a rare enough
occurence, such that the existing nameholder would:

 1. already be an isatap router and answer the RAs
 2. be a non-isatap router and NOT answer the RAs
 3. be an existing, but undesired ISATAP router

I believe cases 1) and 2) would predominate, and case 3) would be
extremely rare. In either cases 2) or 3), we simply have a deployment
consideration note - not true?

Fred Templin
[email-masked]