>>>>> "Brian" == Brian E Carpenter <brc@xxxxxxxxxxxxxx> writes:
Brian> JFC (Jefsey) Morfin wrote:
>> At 13:08 26/08/2005, Brian E Carpenter wrote:
>>> JFC (Jefsey) Morfin wrote:
>>>> just a remark here. In the RFC 3066bis Last Call case the
>>>> IETF has the capacity not only to "police" but to "impose"
>>>> and "force". This is the case when a memo documents a IANA
>>>> registry. In the case of a standard track memo, there can be
>>>> an appeal before it is imposed. It seems not in the case of a
>>>> BCP.
>>>
>>>
>>> Wrong. IESG approvals of a standards track draft or of a BCP
>>> are equally subject to appeal within two months.
>> Dear Brian, I do not say that BCP are not subject to appeal,
>> but that in the case of a standard track an appeal delays the
>> enforcement and that in the case of BCP it does not. My sources
>> are quoted below.
Brian> I have no idea what you mean. Neither IETF standards nor
Brian> BCPs are enforced by anybody - they are what the standards
Brian> community calls voluntary standards.
Let me try and interpret here.
As I understand Jefsey's message, he is concerned about whatever
happens when the 3066bis registry is approved. He believes that
shortly thereafter that products will used registry tags based on
3066bis and there will be an effort to register enough tags and
scripts under the new format that our ability to reverse things in an
appeal would be limited by deployed usage of the new format registry.
One response to Jefsey is that whether a protocol action (approval of
a BCP or standards document) is suspended during an appeal is
something the IESG decides. In many ways, suspending the effects of
an IANA BCP or a process BCP during an appeal has more of an effect
than suspending a standards protocol.
however in all cases the IETF community needs to take into account
deployed implementations and their behavior.
You are correct that implementers can attempt to do things to make it
harder for you to successfully appeal. That may not be nice or fair,
but to the extent that it is outside the IETF process, there is little
we can do about it.
IANA registrations take long enough that I think you will have time to
file an appeal before the IANA website is updated. However there is
little anyone in the IETF can do to stop vendors shipping code.
That's true whether we approve the draft, whether we act on an appeal,
whether we suspend an action, etc. Ultimately, the only reason our
documents have any power or influence at all is because the vendors
choose to give them that influence. Some (hopefully many) vendors
believe that waiting for issues to be resolved has value because it
improves interoperability.
But I must stress that the IETF has no power besides that which people
choose to give it. Nothing stops someone from adding a byte to the
IPV6 header in their implementation. In fact, their ability to do so,
their ability to take the IPV6 standard (or any other IETF standard)
and go off and change it to meet their needs serves as an important
control and check on the process. Now, in the case of adding a byte
to the IPV6 header, a vendor might very well not want to do so because
doing so would cause their implementation to fail to work with every
other implementation. Fundamentally, though, it is their desire to
have interoperability that drives them to work with the IETF. That is
the only power we have.
--Sam
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf