On Thu, 10 Mar 2011, Thomas Narten wrote:
Some requirement levels have also changed, and explicit support from
WG would be good on these. With an updated RFC4294 changelog, rough
consensus on the result could be evaluated.
OK. But to be clear, the changes in this document have been discussed
on the list and IMO do have consensus. I.e., they are not "surprises".
Yes, I don't doubt they've been mentioned, but given the long time
cycle and that a lot of participants do not have time to read all
the mails very closely, strong consensus can be best built by
iteration. (But it can also lead to iteration cycles and hashing the
same issues over and over again, of course)
The document should be IETF last called.
No objection.
Wrt. to Bob's comment, I was just pointing out that Informational
documents do not (by IETF procedures) require an IETF Last Call. It's
good that 6MAN documents have set a higher bar :-)
WG should explicitly request feedback from at least IPSECME WG.
IPsecME has seen and reviewed text. Indeed, some IPsecME members
helped with getting the text right. I also presented the text at the
saag meeting in Maastricht
Great to hear, maybe this is a non-issue then!
I think this document should also discuss APIs we have defined and that
relate to the protocols described in the document. A separate section
should be added on this.
I added a section on APIs. I made them all FYIs. I agree with the
comments others have made on the list that we can't mandate them.
Works for me.
S 5.8.3 has watered down the privacy addresses text:
In such situations, RFC4941 SHOULD be implemented. In other cases,
such as with dedicated servers in a data center, RFC4941 provides
limited or no benefit.
.. this is not acceptable. Per previous RFC, we should say:
RFC4941 SHOULD be supported.
I strongly disagree, and there was a thread about this. I have seen
cases where people just assume that 4941 should be supported by all
nodes, including servers (not clients) in data centers. There is no
need to implement 4941 on server-only systems.
Please review the thread at
http://www.ietf.org/mail-archive/web/ipv6/current/msg10468.html and if
you have further comments, speak up. But it was an explicit goal to
not just say "SHOULD" with not context/direction, as RFC 4294 does.
I should have articulated my objection more clearly. The issue stems
from the word "implemented". I totally agree that it's a bad idea to
turn on 4941 on server nodes. But because it's usually difficult to
distinguish purely client and server implementations, in most cases
4941 should be implemented -- the big question is really whether to
turn it on or off.
In S 5.9,
A reference should be added (MAY support) to RFC 5790,
"Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and
Multicast Listener Discovery Version 2 (MLDv2) Protocols"
Actually, I may need some help with this.
If 5790 is enough, and omits functionality that most nodes don't need,
we should recommend its usage.
We should provide clear guidance on when it makes sense to recommend
one over the other.
Hitoshi Aseada (author) made some suggestions on this on the list on
Feb 21-22. IMHO, 5790 seems enough and only omits functionality that
the most nodes don't need (but I also don't see a pressing need for
existing implementations to take out these bits).
....
A few editorial bugs in the latest version:
- the added text on more-specific routes (S 5.3) mistakenly points to
rfc5942.
- running " in the added rfc4941 text in S 5.9.3
- there's some overlap in the changelog section, at least rfc5952 and
rfc5722 are mentioned twice. (strange to see both numbered and
non-numbered entries there as well.)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
