[ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment

I absolutely agree with your who-needs-what perspective. However, in an ideal world, Ole's draft would contain the "Mandatory/Recommended/Optional RFCs" section that would be ready for a cut-and-paste into a procurement document, in which case RIPE-501bis would only need to refer to that section of Ole's (future) RFC (or even have a copy of it, with pointer to the source).

Ivan

> -----Original Message-----
> From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of
> Tim Chown
> Sent: Monday, January 10, 2011 12:54 PM
> To: ipv6-wg at ripe.net
> Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment
> 
> 
> On 9 Jan 2011, at 22:10, Jan Zorz @ go6.si wrote:
> 
> >
> > I'm still thinking and need a discussion first with authors and see what
> community thinks - but pointing to RFC or draft is ok for us, we know how
> to read RFC and so on - problem is when somebody writes a tender for
> buying ICT equipment - in this case going to read RFC or draft or
> something might be quite complicated for some people.
> >
> > Not sure yet, do we just point to Ole's draft (that is excellent imho)
> or do we write a list of mandatory RFCs that are 1:1 in sync with the
> draft and BBF paper (Ole is also editing that) and keep the list in sync
> if draft/RFC changes. This way tender initiator can just copy/paste RFCs
> and this way the job is easy.
> >
> > Any thoughts?
> 
> I would assume the RFCs are what the vendors/implementors look to first,
> while the RIPE-501 text is, at least from what it says, aimed at
> enterprise sites writing procurement texts.    So there's room in RIPE-501
> to present the requirements in more general terms that are easier to
> (almost) cut and paste into tender documents.     I think there's a lot of
> value in being able to point enterprises (e.g. universities) to RIPE-501
> for procurement guidance.    While some may be able to extract equivalent
> information from RFCs, RIPE-501 would in my view remain a valuable and
> useful abstraction of that information.
> 
> Tim