IETF conflict review for draft-nachum-sarp
conflict-review-nachum-sarp-01

To be clear, I would be a No-Obj on the RFC 5742 position being proposed. What follows is about the proposed IESG Note.

I realized after Pete's helpful list of the alternatives (which omitted No Position, and that was also a possibility I considered), that I hadn't thought carefully about balloting when we had IESG Notes on conflict reviews. 

I searched my IESG mail folder for the last two years, and found two conflict reviews that had IESG Notes (the curious can keep reading past the first "--" to see them).

It seems to me that neither previous conflict review was as robust as the one I'm looking at on this telechat. 

I'm not comfortable saying something in an RFC that the community could say at "BOF time"/"WG charter time"/"IETF Last Call time" if anyone did try to take this work forward. For me, I'm balloting on a proof by assertion that I can't evaluate on my own.

Having said that, the threshold of "yes plus no-obj" ballots required for approval on a conflict review is really low, the IESG is well within its rights to add the proposed IESG Note, and me Abstaining won't change a thing, nor should it, so ... I'm Abstaining.

And thanks, Barry, Pete, and Stephen, for helping me choose a more appropriate position for me.

-- 

The IESG has completed a review of draft-irtf-samrg-common-api-08
consistent with RFC5742.

The IESG recommends that 'A Common API for Transparent Hybrid Multicast'
<draft-irtf-samrg-common-api-08.txt> NOT be published as an Experimental
RFC.

The IESG has concluded that this document extends an IETF protocol in a
way that requires IETF review and should therefore not be published
without IETF review and IESG approval.

IESG NOTE:

Specifically, the document appears to propose incompatible extensions
to URIs: using URIs with unregistered schemes (ip: and sha-2:, for
example) and using registered schemes, such as sip: and reload:, in
ways they were not intended to be used and that deployed software
would not support.

This document seems to be overloading URIs to make them serve as
multicast group names, and overloading URI schemes to serve as
namespaces in the proposed SAM system.  Having identifiers that look
like URIs but have different semantics and are used in different ways,
is a very bad approach and is likely to cause serious breakage as
those identifiers become intermixed with and indistinguishable from
true URIs that applications expect to dereference.

The IESG would also like the IRTF 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-irtf-samrg-common-api/

--

The IESG has completed a review of draft-hausenblas-csv-fragment-07
consistent with RFC5742.

The IESG has no problem with the publication of 'URI Fragment Identifiers
for the text/csv Media Type' <draft-hausenblas-csv-fragment-07.txt> as an
Informational RFC.

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

The IESG asks that the following IESG note be attached to the document:
The change to the text/csv media type registration requires IESG
approval, as the IESG is the change controller for that registration.
The IESG has, after consultation with the IETF community, approved the
change, which is specified in Section 5 of this document.

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-hausenblas-csv-fragment/