On 1/25/11 10:20 AM, Sam Hartman wrote:
"Leif" == Leif Johansson<[email protected]> writes:
>> If we're forced to break backward compatibility then we'll have
>> to evaluate whether the OID needs to change. Currently, I think
>> the answer would be no; fairly soon, I think the answer would be
>> yes. However I don't think it would be a big deal if we needed
>> to burn a few codepoints in an ABFAB mechanisms oid arc. I also
>> think it matters very little where that OID arc lives--IETF or
>> not.
Leif> So basically your vote is on an enterprise arc. I'm not sure I
Leif> understand the reasons why abfab has requirement that differ
Leif> so much from any other IETF protocol where protocol numbers
Leif> are typically allocated on publication of the RFC.
No, my vote would be on an IETF arc under the control of the WG turned
over to IANA on our disolution.
I actually think the idea of assigning codepoints on publication for new
protocols works fairly poorly for most protocols. As someone
implementing ABFAB, I will probably ship implementations before an RFC
is published. If we need to change because of a real compatibility
issue, we can do that. However, it's not work breaking backward
compatibility with deployed code just to get a nicer number.
Sam,
The question is whether you think we should get a new OID every time the
syntax changes. I agree that assigning an OID out of an "experimental"
and then changing it to an "operational" arc if the syntax didn't change
is kind of a waste of time. I have this vague notion of the syntax
changing a lot. If the WG doesn't think that's going to happen then we
probably don't have to go the experimental then switch to operational route.
One way around this is to define the syntax use a dummy OID (of your own
devising) to ensure you can work with yourself. Once you're convinced
and the syntax is workable/stable - then put the OID in the draft.
spt
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
