Based on the discussion in the group today, I made a quick read of the beginning parts of 501bis today at: https://www.ripe.net/ripe/docs/other-documents/requirements-for-ipv6-in-ict-... And I have some comments:
Some parts of this section are loosely based on the NIST/USGv6 profile developed by the US government:
http <http://www.antd.nist.gov/usgv6/>:// <http://www.antd.nist.gov/usgv6/>www <http://www.antd.nist.gov/usgv6/>. <http://www.antd.nist.gov/usgv6/>antd <http://www.antd.nist.gov/usgv6/>. <http://www.antd.nist.gov/usgv6/>nist <http://www.antd.nist.gov/usgv6/>. <http://www.antd.nist.gov/usgv6/>gov <http://www.antd.nist.gov/usgv6/>/ <http://www.antd.nist.gov/usgv6/>usgv <http://www.antd.nist.gov/usgv6/>6/ <http://www.antd.nist.gov/usgv6/>
There's a DoD *and* USG recommendation, you might want to mention both. I think it would also be useful to point people to the IETF node requirements RFC, as that defines the formal conformance requirements from a standards perspective (but of course does that only for general nodes, so the more specific rules for different device types in 501 and the NIST documents is very useful). The RFC is about to come out, the -bis version is replacing the RFC that was years old.
Lists of Required RFC /3GPP Standards for Different Type of Hardware
... Required RFCs and 3GPP Technical Specifications ...
Requirements for Host Equipment
*Mandatory support:*
I'm comparing this to draft-ietf-6man-node-req-bis, and there are some obvious differences. I think it would have been useful to point to this doc for the list of interface-type specific RFCs that are needed (RFC 2464 for Ethernet, for instance).
Optional support: Revised ICMPv6 [RFC 5095] *
This seems wrong. Its not a revised ICMP spec, it is deprecation of RH0. Draft-ietf-6man-node-req-bis marks its as mandatory, and I think you should too.
/*Mobile node:*/In the context of this document a mobile node is a device that connects via some 3GPP specification (such as 3G, GPRS/UMTS or LTE). In situations where the network logic is being provided solely by a dedicated device (A) connected to another device (B), the specification refers to device A and not to device B. If the protocol logic is distributed (for example, a computer with an external Ethernet interface that performs TCP checksum offloading), the aggregate system is being referred to.
There's probably a 3GPP specification and testing requirements etc that defines exactly what the rules for a terminal device like this are. You should reference that and ensure that you're not saying something different. (The expertise on the matter seems to be mostly in 3GPP, so you want to be careful in saying something unless merely referring to existing specs. Maybe you are already doing this, I did not get that far in the spec.)
*
Neighbor Discovery [RFC 4861] *
*
Updated also by RFC 5942, as noted in draft-ietf-6man-node-req-bis RFC 4311 and 4191 are missing from the list of optional supports. *
*Mandatory support:*
*
MLDv2 snooping [RFC 4541]
* This seems like an overkill for a consumer grade equipment (but I do support it for the other types of switches) I have to go to the social event now, will look at more things later. But my overall conclusion is that the document still needs more review... Jari
On 11/1/11 6:41 PM, Jari Arkko wrote:
Based on the discussion in the group today, I made a quick read of the beginning parts of 501bis today at:
https://www.ripe.net/ripe/docs/other-documents/requirements-for-ipv6-in-ict-...
Jari, hi. Thank you for getting involved, I'm sure your input will be very useful in additional crafting of this document. Also thnx to Eric Vyncke and Jouni Korhonen for equally important comments and suggestions.
I have to go to the social event now, will look at more things later. But my overall conclusion is that the document still needs more review...
Authors of the document changed our mind slightly, as we think at least this three comment-sets needs to be addressed before publishing the RIPE-501 replacement. We will try to collect as many input during this Last Call and try to address remaining issues after 10. November. We would like to fire up a discussion based on latest comments and find out if this are the changes we would like to make in existing draft. This is our suggestion, but we'll leave to the chairs to take it from here regarding procedure and all other stuff... Cheers, Merike, Sander and Jan
Authors of the document changed our mind slightly, as we think at least this three comment-sets needs to be addressed before publishing the RIPE-501 replacement. We will try to collect as many input during this Last Call and try to address remaining issues after 10. November.
We would like to fire up a discussion based on latest comments and find out if this are the changes we would like to make in existing draft.
This is our suggestion, but we'll leave to the chairs to take it from here regarding procedure and all other stuff...
Jan, Jari, colleagues, I think it is not a big secret that I personally would have loved to see this document published. However in our role as chairs we are there to guide the process and moderate the discussion. Although this document is not subject to the PDP process, we did issue a last call to verify there is rough consensus on the proposed text and in fact some support from within the community to go forward with this. I personally am very happy to see that this ad hoc process has had some result. The outcome may not be the most desirable one for some of us, but as the discussion takes place the document itself can only get better. Given the comments received on this list and via private channels, combined with the desire of the authors to discuss this further. We think it is safe to say that at this moment, even with last call still open, there is no consensus on moving forward. We would like to invite the community, together with the authors, to discuss the comments made on this list and to work on a new revision of this document. A draft which, in due time, will be subject to another last call before proceeding with the publication. We would like to thank the community for their support and feedback on this subject and of course the authors for collecting and processing this to be included in the document. We are looking forward to a hopefully lively discussion on this list to work out the differences. We will ask the RIPE NCC to keep the current draft text online for reference, until we are ready with a new draft. The document can be found on the following URL: https://www.ripe.net/ripe/docs/other-documents/requirements-for-ipv6-in-ict-... Regards, Marco Hogewoning on behalf of the IPv6 working group chairs
Marco, Just to clarify (because I wrote the e-mail yesterday in a hurry): I think the 501 work is very important, there's a lot of demand for it, and we should get it done ASAP. The world appreciates RIPE and the guys doing this work. That being said, I do agree that some of the issues that me and Jouni raised probably should be fixed before final publication. I'm hopeful that it can be done relatively quickly. Jari
Hi. The authors agree here and the intent is to do a quick turnaround but to ensure we address the issues which we felt were important enough to resolve/incorporate. - merike On Nov 2, 2011, at 11:36 AM, Jari Arkko wrote:
Marco,
Just to clarify (because I wrote the e-mail yesterday in a hurry): I think the 501 work is very important, there's a lot of demand for it, and we should get it done ASAP. The world appreciates RIPE and the guys doing this work. That being said, I do agree that some of the issues that me and Jouni raised probably should be fixed before final publication. I'm hopeful that it can be done relatively quickly.
Jari
On 11/01/2011 02:41 PM, Jari Arkko wrote:
Optional support: Revised ICMPv6 [RFC 5095] *
This seems wrong. Its not a revised ICMP spec, it is deprecation of RH0. Draft-ietf-6man-node-req-bis marks its as mandatory, and I think you should too.
+1 RH0 should be disabled by default.
*Mandatory support:*
*
MLDv2 snooping [RFC 4541]
* This seems like an overkill for a consumer grade equipment (but I do support it for the other types of switches)
+1 Overly (and unnecessarily) complex for a consumer switch. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Hi On 2 nov. 2011, at 21:26, Fernando Gont wrote:
On 11/01/2011 02:41 PM, Jari Arkko wrote:
Optional support: Revised ICMPv6 [RFC 5095] *
This seems wrong. Its not a revised ICMP spec, it is deprecation of RH0. Draft-ietf-6man-node-req-bis marks its as mandatory, and I think you should too.
+1 RH0 should be disabled by default.
I agree. To quote Joe Abley: "RH0 is evil". - Job
participants (6)
-
Fernando Gont -
Jan Zorz ＠ go6.si -
Jari Arkko -
Job Snijders -
Marco Hogewoning -
Merike Kaeo