Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come

[Eliot Lear <[e-mail]>]

Hi Barry,

Thanks for stepping in.

I'd like to make clear that my concern isn't so much about whether
expert review is needed but whether a public specification should be
required.  That is the high bar to which I referred.  The latter
eliminates the possibility of proprietary uses.  As a reviewer for other
registries, I entirely recognize the convenience of having a public
specification available.  However, a specification is not necessary to
determine the appropriateness of the use of a proposed use if the
application is sufficiently detailed.  And to me, given that the TCP/UDP
port space is far more constrained than this registry, my question is
why such a requirement exists.

The classic example of this would be a proprietary web-based management
system that has to ensure that there is no conflict with any other name
in the space.  The people developing the system don't want to publicly
expose all of their interfaces, but want to management version control
on both ends of the connection.  If a specification is required, they
simply won't bother doing one and what happens next is that the TCP/UDP
port reviewers get a request for a service that is identical to HTTP in
all ways, except for its use.  We've already seen these sorts of TCP
port requests prior to .well-known, and in fact I have raised this issue
with Apps ADs in the past.  .well-known offers us an opportunity to
tackle the problem, but not if "Specification Required" is the bar.

Eliot




On 1/18/16 1:54 AM, Barry Leiba wrote:
> I'm going to step in here because I think there's some useful
> discussion to continue here, amid the upset and the tensions.  I'd
> like to set those latter things aside, and get us to have that useful
> part of the discussion.  You'll note that my comments don't talk about
> this specific situation, because what's useful, perhaps important,
> here is how the Expert Review process works in general, not with any
> specific registry or expert.
>
>>>> Well despite me asking you repeatedly to give concrete examples of the
>>>> benefits you claim you have ignored these requests. Similarly you have
>>>> not responded when I asked how many requests were made, how many
>>>> refused, how many abandoned, etc.
> ...
>>> But to answer regardless -- the DE isn't required to gather such statistics,
>>> nor to present them upon demand. Your best bet would be to ask IANA, or
>>> the check the mailing list yourself.
>> That is not an answer, it is a refusal to give an answer.
>>
>> You have asserted that your role is essential to prevent bad things
>> happening. The burden of proof is on you.
> Actually, I don't think any burden of proof lies with the DE.  It's
> the IETF community, as part of the IETF consensus that backed the
> approval of the document and its terms for the registries it created,
> that has stated that they need a designated expert and the value that
> expert adds.  As AD, I have been pushing for all documents that create
> such registries to provide guidance to the DE, to set community
> expectations of how the DE will perform her reviews and why her
> reviews are needed.  I think that's an important part of things, and I
> know that too many registries were created without such guidance (that
> includes the registry we're talking about here, but see below).
>
> Also, as many of us know that, while a DE can handle reviews quietly
> on her own, interacting only with IANA, it's often better to make the
> process more open.  For that, we often create a public mailing list
> and require discussion of registration requests on that mailing list
> (as we've done in the case we're talking about here).  If the DE's
> decision is notably at odds with the discussion on the mailing list,
> that's a flag for the responsible AD to have a look at the situation
> and see what happened and why the discrepancy is there (see below for
> further comments about openness).
>
> Formally, IANA tracks all request and the process path they take.  So
> Mark is right that you can get the answers about the statistics you're
> looking for from IANA.  Any DE can, of course, keep her own
> statistics, but she's not required to... and most don't.
>
>> Yes there is a process, but the first part of any IETF process is discussion.
>>
>> The problem is that you seem to have a very different idea of what
>> your role should be than the Tao of the IETF suggests. You are arguing
>> that you add value as a gatekeeper. Yet you aren't actually explaining
>> what the criteria you are using are.
> As I see it, Mark isn't arguing anything of that nature.  Discussion
> needs to happen in public, which it's doing on apps-discuss and which
> it can also do, in this case, on wellknown-uri-review, and the DE's
> job is to use that discussion to inform his decision.  I'll note that
> the RFC that controls this case, as do many such RFCs, specifically
> says that the DE is expected to explain an unfavourable decision and
> suggest what changes might make the request successful.  Again, see
> below about openness.
>
>> All IETF policies are subject to revision. And no, the burden of proof
>> is not on those that want to make change.
> I believe it is, in that we have a process that was approved by IETF
> consensus, and, while IETF consensus can and surely sometimes should
> change, with new information and experience since the initial
> consensus, the change has to be proposed by someone, an I-D eventually
> has to document the proposal, and that I-D has to go through the same
> consensus process.  While IETF rough consensus isn't really a "burden
> of proof" thing, I do think it's up to those who want things to change
> to justify their change request and drive the consensus -- we very
> much *are* (for better or worse) in a world where we have to have
> rough consensus *for* the change, and things otherwise stay as they
> are.
>
> Of course, not everyone agrees with everyone, and one thing we need to
> be good at, collectively, is accepting that people who disagree with
> our ideas are not always (indeed are not usually) stupid, stubborn,
> obsolete, or harbouring personal agendas and personal grudges.  We
> have to support our cases clearly and firmly, but also graciously
> accept disagreement and continue to work with each other on other
> issues.  And, of course, on the other side we have to consider others'
> arguments with the assumption that there might be some good stuff
> there, and only reject them when we've weighed the technical
> considerations.  (On all that, see the "finally" paragraph below.)
>
> Now, on the openness of the Expert Review process, there is an
> important discussion to be had: *Is* that process sufficiently open
> for the IETF?  Should we, more generally, alter the process to make it
> more open, with more accountability for the DEs?  As I mentioned,
> there are some registries where the DE just gets a request from IANA
> and returns a response, and it's up to the registrant to push the
> issue if things are refused.  There are other registries where there's
> at least some public discussion.  Is there still value (in general,
> not for this particular case) in having registrations in some
> registries reviewed by DEs?  Should we abandon that entirely?  Should
> we limit it to fewer registries, and make more registries FCFS?  Or
> make more registries IETF Review?  Or something else?
>
> I think that discussion needs to happen, and should be taken to
> <[e-mail]> to see where it goes.
>
> Finally, let me ask everyone to take a step back and not discuss
> anyone's motives or attitudes.  If you feel that offense has been
> given you, take the higher ground and don't respond in kind, thus
> avoiding escalation.  If you think someone's suggesting a bad idea, be
> clear about why you think the idea is not a good one, and avoid using
> inflammatory terms to describe it... and definitely avoid having that
> spill out from the idea to the person proposing it.  We'll all
> accomplish more if we can discuss this sensibly, even when we
> disagree.
>
> Barry, ART AD
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>