Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-l3vpn-ppvpn-mcast-reqts-08 .txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Oct 2006 14:29:11 +0200

Gray, Eric wrote:
...
> 
> The placement of the "Contributors" section is unusual.  It occurs before
> the table of contents.  What would be wrong with listing contributors in
> (or around) an "Authors' Addresses" section?  I would suggest making two
> subsections under "Authors' Addresses" section: Editor and Contributors.

I'llhappily leave that to the RFC Editor
> 
> The document makes extensive use of RFC 2119 formality, yet is intended
> as an "Informational" RFC.  I believe this has happened previously, so
> this is clearly not setting a precedent.   However, it does not make 
> sense to me to assert "normative language" in an Informational RFC.  An
> Informational RFC that does so could very easily be misrepresented as a 
> "Standards Track" RFC.

Yes, RFC 1796 remains true, but we do regularly see Informationals
that are very close to being Technical Specifications, so choose to use
normative terminology.

Personally I doubt that any document called "requirements for [protocol]"
can ever be interpreted algorithmically. For example:

>>    A multicast VPN solution SHALL allow a service provider to define at
>>    least the same level of quality of service as exists for unicast, and
>>    as exists for multicast in a non-VPN context.

This sounds highly desirable, doesn't it? But since QoS for multicast is
pie in the sky, it's pretty clear that this SHALL will be broken by every
implementation. But since it's a requirements document rather than a
protocol, it doesn't fundamentally matter.

My preference would be to use plain English instead of RFC 2119 language,
but I don't see it as a showstopper.

     Brian

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art