Subject: [Nea] IESG query re Expert Review

From: Stephen Hanna <[email-masked]>
Date: Thu, 17 Sep 2009 12:56:39 -0400

Alexey Melnikov (APP AD) has provided many useful comments
on PA-TNC and PB-TNC. One issue that he has raised is
whether Expert Review should be required for IANA registration
of vendor-specific values in the NEA registries and, if so,
what the expert guidelines should be. Alexey has asked the
NEA WG to reconsider and discuss this matter. Therefore,
I'm raising this topic on the NEA list and cc'ing Alexey.

The text in draft-ietf-nea-pb-tnc-05.txt on this matter
is in section 7.1:

>    For all of the IANA registries defined by this specification,  
>    new values are added to the registry by Expert Review with  
>    Specification Required, using the Designated Expert process  
>    defined in RFC 5226 [3].  
>
>    This section provides guidance to designated experts so that  
>    they may make decisions using a philosophy appropriate for these  
>    registries.
>
> [snip]
>
>    All values in these IANA registries MUST be  
>    documented in a specification that is clear, permanently and  
>    publicly available, and likely to ensure interoperability. IETF  
>    standard values MUST be useful and not harmful to the Internet.  
>
>    Designated experts should encourage vendors to avoid defining  
>    similar but incompatible values and instead agree on a single  
>    IETF standard value.  However, it is beneficial to document  
>    existing practice.  

I will let Alexey make the full case for removing the requirement
for expert review of vendor-specific values. I think that the main
thrust of the argument is that we should encourage vendors to
document the values that they use.

Thanks,

Steve

---

From: Todd Glassey <[email-masked]>
Date: Thu, 17 Sep 2009 11:49:49 -0700

> The text in draft-ietf-nea-pb-tnc-05.txt on this matter
Sorry not possible... the type of thing that Alexey is asking for is 
legally impossible for the IETF to do with the Use License in the 
current state its in and since all of NEA to date has been published 
under that its a bit late to be thinking about doing anything to 
interfere with how people use IETF protocols.

A simpler way to do this would be to change the IETF copyright so that 
it forces the implementor to implement the standard per the Use 
Statement which is really what Alexey is talking about but since most 
all IETF protocols dont have best-practice use models with their 
specifications this also would be a pain.

The problem for NEA and all other WG's today is that NO ONE is forced to 
implement the entire part of a IETF standard to declare they are IETF 
compliant because of the ANY AND ALL USES clause in the license. They 
dont even have to claim their product passed interoperability testing to 
claim their IETF compliant because of that specific language.

Todd Glassey
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.409 / Virus Database: 270.13.103/2378 - Release Date: 09/17/09 06:18:00
>
>

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Sep 2009 22:43:59 +0100

>I'm raising this topic on the NEA list and cc'ing Alexey.
I am actually don't have a strong opinion on this, but I want to make 
sure that the WG has considered consequences of the choice.

>document the values that they use.
Indeed.

The situation I have in mind is as follows: Assume a vendor A implements 
some vendor specific attributes. The implementation becomes widespread 
and other implementations would like to implement it as well. Then 
somebody not working for vendor A convinces an A's representative to 
register the attributes as a favor to the community. The A's 
representative tries to do that, but either the documentation is not 
quite clear on some details, or it is not always interoperable.
At this point the registration procedure says that the expert should 
reject the registration. The A's representative doesn't feel obligated 
to fix documentation, because the registration was submitted as a 
service to the community. So, would rejecting the registration in such a 
case be worse than registering something which is not perfect?

If the WG group agrees that this might be a problem, then there are 2 
ways to fix this:
a). you update the text to relax instructions for the designated Expert 
Reviewer
or
b). the WG can select an Expert Reviewer who is quite relaxed about the 
rules and would be flexible about allowing not-fully-compliant vendor 
specific registrations. In this case you don't need to change the 
document, but there is a small risk that the designated expert wouldn't 
be as flexible.

Best Regards,
Alexey

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 25 Sep 2009 09:35:36 -0700

Alexey makes some very good points here.

At 10:43 PM +0100 9/17/09, Alexey Melnikov wrote:
>The situation I have in mind is as follows: Assume a vendor A implements some vendor specific attributes. The implementation becomes widespread and other implementations would like to implement it as well. Then somebody not working for vendor A convinces an A's representative to register the attributes as a favor to the community. The A's representative tries to do that, but either the documentation is not quite clear on some details, or it is not always interoperable.
>At this point the registration procedure says that the expert should reject the registration. The A's representative doesn't feel obligated to fix documentation, because the registration was submitted as a service to the community. So, would rejecting the registration in such a case be worse than registering something which is not perfect?

>From the experience in other Security WGs, this scenario is both possible and unfortunate. Worse, people will disagree with the answer to the last question and will waste a lot of time that could be used more productively.

>If the WG group agrees that this might be a problem, then there are 2 ways to fix this:
>a). you update the text to relax instructions for the designated Expert Reviewer
>or
>b). the WG can select an Expert Reviewer who is quite relaxed about the rules and would be flexible about allowing not-fully-compliant vendor specific registrations. In this case you don't need to change the document, but there is a small risk that the designated expert wouldn't be as flexible.

Relying on (b) for the long term is not a good strategy. I think (a) is much better. Really, the stability of the vendor's text is way more important than the correctness. If the text is bad, anyone who cares will reverse-engineer it through testing with the vendor's product, and if they're really nice, will encourage the vendor to update it.

--Paul Hoffman, Director
--VPN Consortium