IETF conflict review for draft-lanthaler-profile-registry
conflict-review-lanthaler-profile-registry-00

The following approval message was sent
From: The IESG
To: "Nevil Brownlee" , draft-lanthaler-profile-registry@tools.ietf.org
Cc: The IESG , , 
Subject: Results of IETF-conflict review for draft-lanthaler-profile-registry-05

The IESG has completed a review of draft-lanthaler-profile-registry-05
consistent with RFC5742.


The IESG has no problem with the publication of 'The Profile URI
Registry'  as an Informational
RFC.


The IESG has concluded that there is no conflict between this document
and IETF work.

The IESG would also like the RFC-Editor to review the comments in the
datatracker related to this document and determine whether or not they
merit incorporation into the document. Comments may exist in both the
ballot and the history log.

The IESG review is documented at:
http://datatracker.ietf.org/doc/conflict-review-lanthaler-profile-registry/

A URL of the reviewed Internet Draft is:
http://datatracker.ietf.org/doc/draft-lanthaler-profile-registry/

The process for such documents is described at
http://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
The -05 version of the document changes the registration policy to FCFS, with a specification recommended.  This resolves my issue with having the document in the Independent Stream, and I'm happy with the "no conflict" message.

[Ballot comment]

There are enough DISCUSSes already so I won't add to it.

I would note though that if the ISE (or anyone else) did end up cutting
a deal with IANA, then it'd be really crappy if that registry appeared on
IANA's web site below [1] which should be "our" registries. (Having
said that I've no idea how pure that distinction is.)

So can we also clarify that the above is the case if that's not already
clear as part of the resolution of the DISCUSSes.

  [1] https://www.iana.org/protocols

[Ballot discuss]
If, as Adrian concluded, this was using 5226 "for convenience of similar terminology", I'd agree it would be between IANA and the ISE to work this out. But the document doesn't do that. It normatively references 5226 and says that the procedures are "per [RFC5226]". That places a requirement on the IESG by the ISE. Either the document gets changed to say that it is doing something "like 5226", but the ISE (or my Aunt Gertrude or whoever) is in charge of appointing the DE, or this document gets a type 4 response. This should not be published as-is.

[Ballot discuss]
Looking at the IESG reviews a type 3 or 4 response seems appropriate until the chain of authority is agreed.

3) Because this is ISE requiring the IESG to take on an additional task

4) Because it cannot be current procedure for ISE to require IESG to appoint and manage a DE

I have no objection to the contents of the document and will clear when there is agreement between ISE, IANA and IESG
on how to manage this process.

[Ballot comment]
I agree with Adrian's observation that the appointment of a DE is not our responsibility and that observation needs to be made clear to the ISE and IANA.

[Ballot comment]
I don't object to moving forward with this document, whether Adrian's astute observation is handled or not.  The reason I don't object is that as Barry says, we don't have standing to object.  It's entirely up to IANA to figure out how to deal with this.  I think they would be within their rights to reject the request.

One way we _could_ address this would be to add an IESG note saying that the IESG is aware of the issue here, and has agreed to take on responsibility for doing expert review at the request of the ISE (assuming that the ISE is willing to make such a request).  I do not care one way or the other whether such a note is added, but it seems that it might be a sensible way forward, if we agree that the alternative is a likely unproductive attempt to navigate uncharted waters.

It would be equally appropriate to cast caution to the wind and let the ISE attempt to navigate these waters, with our blessing.

[Ballot comment]
I don't object to moving forward with this document, whether Adrian's astute observation is handled or not.  The reason I don't object is that as Barry says, we don't have standing to object.  It's entirely up to IANA to figure out how to deal with this.  I think they would be within their rights to reject the request.

One way we _could_ address this would be to add an IESG note saying that the IESG is aware of the issue here, and has agreed to take on responsibility for doing expert review at the request of the ISE (assuming that the ISE is willing to make such a request).  I do not care one way or the other whether such a note is added, but it seems that it might be a sensible way forward, if we agree that the alternative is a likely unproductive attempt to navigate uncharted waters.

It would be equally appropriate to cast caution to the wind and let the ISE navigate these waters, with our blessing.

[Ballot comment]
For the record, this is the email I sent on the thread for Barry's Discuss...

Interesting problem.

I can see why the "specification required" part of Specification Required would be attractive to the authors.

Barry, in the 5226bis work, would you consider creating "First Come First Served with Specification"? I believe that might be useful for such cases.

In this case, I don't see the harm in appointing and maintaining a DE so long as one can be found (which, to be honest, is how all other DE registries work). The thing that does result is that the IESG comes on to the appeals path for the actions of the DE.

Ah! The penny just dropped as I was typing.
If this is with the ISE and is asking for IANA action then who is actually giving IANA the instructions?
Not the IETF, I think.
The IANA is allowed to manage any code space it wants outside of those it manages for the IETF, but that is not our business.
So the use of 5226 terms would be "for convenience of similar terminology" and the necessary DE would not be any of our business.

So it would not be a case of the IESG refusing to appoint a DE, but it would be up to IANA to work out how to appoint a DE for a registry that is not an IETF registry.

[Ballot comment]
While this document does not conflict with any IETF work, it creates a new registry with a policy of Specification Required.  Specification Required necessitates the appointment of a designated expert to review the registration request, at least to determine that the specification that's provided is adequate.  This raises two issues:

1. The document gives no guidance to the designated expert.  RFC 5226 strongly suggests such guidance, and the in-progress 5226bis update is more emphatic about it.  Section 4 of this document should say something about what the designated expert should consider in her review of registration requests.

2. This makes a commitment that the IESG will appoint and manage a designated expert for this registry.  It's an open question whether it's appropriate for Independent Stream documents to put such a requirement on the IESG: we don't have standing to object to the publication of the document, because it is not in conflict with IETF work, but it would be a bad situation if the first registration request came up against an IESG that refused to appoint a DE.  I'd like to discuss this situation with the IESG.

The draft draft-lanthaler-profile-registry-03
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

Its title is:
The IETF Profile URI Registry

Its abstract says:
"This document defines a registry for profile URIs to be used in
specifications standardizing profiles."

It was reviewed for me by Dave Cridland,
the authors published version -03 to address the issues he raised.

IANA have reviewed the draft, and confirm that they understand what's
required for the registry it requests.

Thanks, Nevil (ISE)