Deprecating Site Local Addresses
RFC 3879

Note: This ballot was opened for revision 03 and is now closed.

(Harald Alvestrand) Yes

Comment (2004-03-16 for -)
No email
send info
One comment to the security considerations section by Scott Brim, GEN-AREA reviewer:

in the Security section, I would add a paragraph reiterating 
of the issues due to ambiguity which were brought up in the preceding
sections.  Leakage, misrouting, etc., are noteworthy security issues.

Not worth holding the document for.

(Steven Bellovin) Yes

(Margaret Cullen) Yes

(Bill Fenner) Yes

(Ted Hardie) Yes

(Allison Mankin) (was Discuss) Yes

Comment (2004-03-18)
No email
send info
I'm clearing my Discuss because Thomas has written the right IANA fix that I was referring to.

(Thomas Narten) (was No Record, Discuss) Yes

Comment (2004-03-18)
No email
send info
>    Applications would learn or remember that the address of some
>    correspondent was "FEC0::1234:5678:9ABC", they would try to feed the
>    address in a socket address structure and issue a connect, and the
>    call will fail because they did not fill up the "site identifier"
>    variable, as in "FEC0::1234:5678:9ABC&1". The problem is compounded

Would be good to cite the document that explains the "&" syntax in
addresses.

>    Having non-ambiguous address solves a large part of the developers'

s/address/addresses/

(Jon Peterson) Yes

(Alex Zinin) (was Discuss) Yes

(Scott Hollenbeck) No Objection

Comment (2004-03-08 for -)
No email
send info
RFC 3513 is listed as both a normative reference and an informative reference.  I would suggest striking it from the list of informative references.

(Russ Housley) No Objection

(David Kessens) No Objection

(Bert Wijnen) No Objection