-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Roman
> Teredo? I'm presuming you meant ISATAP. yes... I must have been asleep...sorry > The problem is, the draft wants to define a canonical representation for > both humans and computers to follow, but those two have conflicting > requirements. On the one hand, computers want a simple algorithm that > depends only on the address being input, preferably an algorithm that > gives consistent output over a long period of time. On the other hand, > humans prefer representation which is most informative, and are usually > able to use external information to choose it. On the third hand, humans > and computers must interoperate (in particular, humans need to act on > addresses that computers stringify), so one has to establish some kind > of compromise. This is a pretty nice summary of the case. I agree. > A compromise may be to recommend the mixed form for currently known > addresses that end with an IPv4 address AND can be reliably distinguished > from the rest (e.g. have a unique prefix). Then you can insert a paragraph > explaining why can't this be done for "nondeterministic" and future > addresses. That's inconsistent with existing implementations, though, and > I have a feeling that they will be reluctant to change. No easy solution, > it seems. I have the same view as you here. Its hard to fix past implementations, and that's not the goal here. So it might be better if the draft took a more neutral standpoint as you pointed out. I'll hopefully try to come up with a text before the 6man meeting on Wednesday. Regards, Seiichi Роман Донченко wrote: > Hello, > > Seiichi Kawamura <kawamu...@mesh.ad.jp> писал(а) в своём письме Thu, 09 > Jul 2009 08:32:39 +0400: > >>> The rest is more controversial. While ISATAP addresses obviously make >>> more >>> sense in mixed notation, they can't be reliably identified without >>> additional information, since they can have arbitrary prefixes. This >>> makes >>> the specification impossible to implement for a generic inet_ntop-like >>> routine. While you can say that addresses should be represented in mixed >>> notation if they are known to be ISATAP addresses (by some other means), >>> this makes the definition of canonicity depend on external factors, >>> which >>> I believe is unnecessary complication. In short, I think ISATAP >>> should be >>> removed from the list. >> >> Teredo was added after comments from Dave Thaler. > > Teredo? I'm presuming you meant ISATAP. > >> IMHO, specifying what type of addresses does not have strong >> meaning in this context. Rather, as an informational document, >> it would be informative to operators what address can do mixed notation. >> But just as you say in a different part of your mail, we never know >> what comes up in the future. My feeling about this is, if there's many >> people that think this is out of place, we can just go back to pointing >> to addressess that are mentioned in RFC4291. > > The problem is, the draft wants to define a canonical representation for > both humans and computers to follow, but those two have conflicting > requirements. On the one hand, computers want a simple algorithm that > depends only on the address being input, preferably an algorithm that > gives consistent output over a long period of time. On the other hand, > humans prefer representation which is most informative, and are usually > able to use external information to choose it. On the third hand, humans > and computers must interoperate (in particular, humans need to act on > addresses that computers stringify), so one has to establish some kind > of compromise. > > A compromise may be to recommend the mixed form for currently known > addresses that end with an IPv4 address AND can be reliably distinguished > from the rest (e.g. have a unique prefix). Then you can insert a paragraph > explaining why can't this be done for "nondeterministic" and future > addresses. That's inconsistent with existing implementations, though, and > I have a feeling that they will be reluctant to change. No easy solution, > it seems. > > Roman. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) iD8DBQFKZuFzcrhTYfxyMkIRApe8AJ9kbFdFms/TCnk1P30Acu42NBllnwCfW0gu bDkSt5VKP31jROLcRIQXlu4= =XIMq -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
