Re: Registries and Interoperability

On 02/04/2013 10:55 PM, Ryan Sleevi wrote:
> On Mon, Feb 4, 2013 at 1:22 PM, Harry Halpin <hhalpin@w3.org> wrote:
>> Quick note,
>>
>> I agree with Ryan's concerns as regards registries not allowing
>> interoperability and possibly being dangerous from an IRP perspective.
>> However, from W3C's perspective we we're not planning on running the Working
>> Group in an open-ended manner like the WebApps Working Group (see below for
>> reasoning). Thus, it seems we should determine:
>>
>> 1) If we want any extensibility in algorithm identifiers, which requires
>> either a very low-bar approach (wiki) or a high-bar approach (IANA)
>> 2) If we don't want any extensibility in algorithm identifiers, so they
>> essentially "freeze" when we go to Last Call, and adding new ones requires
>> rechartering the Working Group
>>
>> I think there's the situation where there's a new algorithm people may want
>> to use, but we don't have enough industry momentum to reopen the Working
>> Group.
> If there's not industry momentum and within implementors, what value
> does it serve the broader web community of users, authors, and
> developers? If there is broad consensus, then what's the challenge?

There may be momentum to add a new algorithm or tweak an existing 
algorithm from within two or more implementers without the momentum 
needed to re-charter a new Working Group. Or if the registry includes 
security considerations, there may be an update to security 
considerations We would not want to recharter internally at W3C for a 
new single algorithm or a change in the security status of an algorithm, 
as we would have to identify editors, chairs, and go through IPR process 
all over again.

Again, from W3C processs point of view, we just need to determine 1) 
when working group ends and 2) if it ends, is a maintenance policy 
necessary and 3) is there a clear well-specified way to maintain, and 
can that be done outside the spec for minor changes via a principled 
extensibility point?

It seems given the crypto landscape does change on occasion, a 
maintenance policy makes sense. IANA was suggested by W3C internally as 
a principled extensibility point, as we have a long history of working 
with them. I'm open to other suggestions. Do people agree that no 
maintenance policy on algorithm specifiers are necessary?

In fact, we could even broaden the scope and also allow the registry to, 
in conjunction with the work CRFG is doing already, make sure that 
algorithm's particular security considerations can be updated and noted 
on a per identifier basis. This deals with the "ever-changing" world of 
crypto, as you put it earlier. I do think crypto actually changes quite 
slowly, but sometimes there are dramatic new changes that happen very 
fast. This would address CRFG's comments I believe re the use of "broken 
crypto" in the spec.

I am bringing this up a bit early insofar as that it can take some time 
to go through getting a new IANA regsitry, and I don't want that holding 
up Last Call.
>
>> As I understand it (and Wendy's a lawyer, so she can correct re IPR), the
>> real advantage of process is testing and IPR RF commitments.
>>
>>  From a W3C Process point, the IPR is assigned at the Recommendation phase,
>> with initial commitments made to charter. The advantage is that features of
>> the W3C Rec for Web Cryptography will have a high assurance of royalty-free
>> implementation, regardless of the test-cases.
> We should be clear here: royalty-free with respect to participants.
> There's always the possibility of external factors here, which is part
> of why having the WG process works, to identify and find solutions to
> these factors.
>
>> The disadvantage of that is to
>> add a new algorithm via adding a new identifier, we'd have to re-open the
>> Working Group and start the IPR process all over again.  However, any
>> registry would not have W3C RFF IPR policy, although we could apply an IETF
>> policy to it (which I would strongly suggest).
>>
>>  From a testing standpoint, another strong point is that W3C requires
>> demonstrated interoperability. However, *running* the test suite and adding
>> new tests does not require re-opening the Working Group, unlike making
>> modifications to the specification. The test-suite can be stored using Git
>> in order to allow merges, and will be maintained by W3C after the lifetime
>> of the Working Group. We can add our test-suite to be part of a larger
>> test-suite (I would think HTML WG's test suite would make sense) so it can
>> be easily added to by others and maintained after the lifetime of the
>> Working Group.
>>
>> My suggestion for a process is then:
>>
>> 1) Keep algorithm identifiers in the specification up until we go to Last
>> Call, and that the test-cases for Rec status test each of them. Thus, no
>> text is removed from spec. We clearly specify that algorithms in the spec
>> have RFF status, demonstrated interoperability (via test-suite), and are to
>> be preferred by WebApp developers.
>>
>> 2) Then after that period, people proposing new algorithms are asked to go
>> to the IANA registry, which will have some explanatory text referenced in
>> the spec.
> As mentioned, this remains a troubling proposal.

In what regard in detail?

The alternative seems to be:

1) We keep the WG running forever to maintain the spec (which is difficult)
2) We recharter whenever even minor changes to algorithm identifiers or 
security considerations are needed (again, very difficult to recharter - 
the process itself just to start takes about 6 months at least usually 
due to IPR considerations).

I think that address the interop concerns, and also gives us a clear 
process for when we need to reopen the Working Group. We can set some 
specific criteria to formally suggest to the W3C to re-open, such as 
when we have say, X implementers for more than X algorithms. At the same 
point, we get to have a place where new identifiers  can go.

>
>> 3) The IANA registry have a fairly stringent requirement of at least two
>> interoperable user-agents as well as the "Well-Specified" text given by Ryan
>> in the spec already in order to get in registry.
> As I mentioned, this text was certainly not intended to be a long-term
> text. I would propose this be removed, as it was more of an editorial
> note (before I discovered the "ednote" attribute of the tools)
>
> I think it's demonstrably harmful to the spec and the process to
> include this text going forward.


Note that "this text" was the text in you added to the specification 
about a registry, to be clear.  That's what caused the internal 
discussion at W3C in our review at our last "heartbeat" publication. 
Again, can you explain why its demonstrably harmful and what a clear 
alternative is?

I have suggested a wiki as well (which is what HTML/WHAT WG does re link 
registry) but that's even more likely to be messy than an IANA registry 
with a well-defined policy.
>
>> 4) The W3C/IANA contact for the registry check new requests for algorithm
>> identifiers by demanding test-cases. These can get added to an
>> "experimental" branch of the HTML test-suite.
>>
>> 5) If we get to the point where we have lots of new algorithms and momentum
>> is clear, the contact recommends re-opening/re-chartering the Working Group
>> to the W3C. The W3C/IANA can reject spurious new identifiers (including ones
>> that make only minor modifications to those in spec) or one's that are known
>> to have IPR issues.
>>
>> Ryan, does that address the your concerns?
> No

OK. What's your alternative?
>
>> Any thoughts?
>>
>> The W3C and IANA have a fairly close relationship, and we are used to
>> dealing with IANA in this way in other WGs, so the mechanics aren't an
>> issue. We just need to figure out what's best for the WG - to have an
>> extensibility point or not, and if so, what are the requirements that we at
>> W3C (and any volunteers!) can maintain after the lifetime of the WG. We do
>> prefer to close WGs as it helps get us the IPR closed, and in general
>> increases the chances of interoperability by demanding implementation by a
>> given date.
>>
>>     cheers,
>>       harry
>>
>>
>>
>>
>>
>>

Received on Wednesday, 6 February 2013 09:57:11 UTC