Text 10510, 95 rader
Skriven 2013-09-27 22:12:02 av mark lewis (1:3634/12.0)
  Kommentar till text 10483 av Michiel van der Vlist (2:280/5555)
Ärende: IPv4 and IPv6
=====================
 On Thu, 26 Sep 2013, Michiel van der Vlist wrote to mark lewis:

 MvdV>> In the case of dual stack, I don't see it either. Presently all 
 MvdV>> IPv6 capable nodes are dual stack.

 ml> you've tested all OSes for this?

 MvdV> Test them for what?

dual stack... my main OS(es) are not dual stack and at least one of them never
will be... others in my herd may be but none of my equipment is and is not
planned to be for several years...

 MvdV>> Some day in the future however we may see IPv6 only nodes.
 MvdV>> If/when that happens we may have use for an IPNOV4 flag or
 MvdV>> something to that effect.

 ml> why not just IPV6 to indicate IPV6 capability?

 MvdV> Because IPv6 capability is not really what we want to signal. 

 ml> perhaps limit the definition to "IPV6 only"...

 MvdV> That goes against how we have used flags in the past. V34 does
 MvdV> not mean V34-only, it means V34 capability in addition to the
 MvdV> others listed or implied. X75 does not mean X75-only, MNP does
 MvdV> not mean MNP-only, etc, etc. 

 MvdV> Departing from that convention is confusing.

the ice has already been broken... we have a FTN mailer that cannot perform
FTS-0001 connections... neither can it perform others like EMSI... just like
ISDN only nodes being allowed in the nodelist which broke connectivity... so
what's the difference????????

 ml>  IPV4 is assumed...

 MvdV> Indeed. The problem arises when that assumption is not met. So
 MvdV> what we want to convey is not IPv6 capability but the /absence/
 MvdV> of IPv4 capability. You want to block calls to certain nodes, not
 MvdV> because they have IPv6, but because they do NOT have IPv4. Is it
 MvdV> not?

 MvdV> Hence IPNOV4.  Or maybe just IN4?

no... i do not use modem flags to limit my connectivity because they show a
lack of a protocol... i use the flags that show a protocol that i cannot
connect with... this is the way it has always been... "you" are trying to turn
the meaning around bassackwards for some reason :/

 ml>  IPV4 is assumed...

 MvdV> Or maybe we should drop that assumption. Assume that IPv4 is
 MvdV> absent unless there is an IP4 flag. That means that every IP
 MvdV> capable node that is presently in the nodelist must carry the
 MvdV> flag, but in the very long run that flag will disappear as IPv4
 MvdV> fades out...

 MvdV> A self cleaning solution..

yeah, so all of a sudden we have to add 5 more characters to each and every
nodelist entry... that's going to go over like a led zepplin :?

 MvdV>> I say "may" because it will only be useful when by that time
 MvdV>> there are still a significant number of nodes that do not have
 MvdV>> at least outgoing IPv6 capability.

 ml> as you did in recent times with a proposal that is not yet needed,

 MvdV> Please refresh my memory, which one was that?

the only proposal/standard that you, yourself, have written and placed in
effect in the last what? 2 or 3 years? i believe the comment was to the effect
of "let's get it on out there now so there's no question when it comes
around"...

 ml> why not go ahead and set the item into the documents so there is no
 ml> question or problem in the future?

 MvdV> Because I think it is premature and hasty. See my previous
 MvdV> messages. 

hummm...

 MvdV> Perhaps we should move this to FTSC-PUBLIC?

perhaps... speaking of which, is any other FTSC member besides myself and
andrew leary reading the private FTSC echo?? i posted something the other day
and andrew has seconded it but there has been no other traffic since...
however, i've not yet reached that area in this read thru of my mail so there
might be something by others...

)\/(ark

 * Origin:  (1:3634/12)