I believe that Francis has a point when it comes to must vs. should or
may. The current document is based on theoretical analysis rather than
field experience, and there is no telling what we will learn in the next
two years. As a rule, I believe that this document should never use the
clause "must", and restrict itself to the milder should. In short, if
there is any use for such a document, it should be some kind of a safe
harbor approach, as in, "if you do this, we believe you won't cause much
problems to the network, but if you know better feel free to innovate."
Note that the fledging nature of IPv6 is actually an argument for
standard track, since it will automatically trigger a revision mechanism
in 6 month to 2 years, when we have to progress the status of this
document. If we have a choice, it is not between proposed standard and
informational, but rather between proposed standard and experimental.
The latter would suit me just fine.
-- Christian Huitema
> -----Original Message-----
> From: Francis Dupont [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 31, 2001 5:33 PM
> To: Bob Hinden
> Cc: [EMAIL PROTECTED]
> Subject: Re: W.G. Last Call on "Default Address Selection for IPv6"
>
> I strongly object against the standard track status for this document
> because this will close the door:
> - research won't be done in order to find alternate/better solution
> - implementors will have to implement exactly the mechasnims
described
> in the document or they won't be conformant.
> The first point is a known drawback for standards. My concern is more
> the second point, I understand we have to restraint freedom for
getting
> more interoperability but in this case we are going too far!
> Some choices are still arguable, in particular in defaults, and these
> will become standards so even we believe they are not good we will be
> stuck with them.
> These concerns have already slowed down the document and can become
> critical when it will go further in the standard track. Common sense
> rules ("MUSTs") should be in a different document than some detailed
> mechanisms ("SHOULD/MAYs").
>
> Regards
>
> [EMAIL PROTECTED]
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
