Skip to main content

IETF conflict review for draft-warden-appsawg-vnc-scheme
conflict-review-warden-appsawg-vnc-scheme-00

Document history

Date Rev. By Action
2016-02-25
00 Cindy Morgan
The following approval message was sent
From: The IESG
To: draft-warden-appsawg-vnc-scheme@ietf.org,
    "Nevil Brownlee" ,
    rfc-ise@rfc-editor.org
Cc: "The IESG" ,
  …
The following approval message was sent
From: The IESG
To: draft-warden-appsawg-vnc-scheme@ietf.org,
    "Nevil Brownlee" ,
    rfc-ise@rfc-editor.org
Cc: "The IESG" ,
    iana@iana.org,
    "IETF-Announce"
Subject: Results of IETF-conflict review for draft-warden-appsawg-vnc-scheme-10

The IESG has completed a review of draft-warden-appsawg-vnc-scheme-10
consistent with RFC5742.


The IESG has no problem with the publication of 'The "vnc" URI Scheme'
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 Independent Submissions 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:
https://datatracker.ietf.org/doc/conflict-review-warden-appsawg-vnc-scheme/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-warden-appsawg-vnc-scheme/

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

Thank you,

The IESG Secretary



2016-02-25
00 Cindy Morgan IESG has approved the conflict review response
2016-02-25
00 Cindy Morgan Closed "Approve" ballot
2016-02-25
00 Cindy Morgan Conflict Review State changed to Approved No Problem - announcement sent from Approved No Problem - announcement to be sent
2016-02-25
00 Cindy Morgan Conflict Review State changed to Approved No Problem - announcement to be sent from IESG Evaluation
2016-02-25
00 Stephen Farrell [Ballot comment]
Thanks for adding the text about sensitive data in URIs. I still wish
the scheme showed how to do something better.
2016-02-25
00 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to Abstain from Discuss
2016-02-18
00 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2016-02-17
00 Terry Manderson [Ballot comment]
I agree with Alissa. This document naively heads in a direction opposite to RFC3986 and RFC7595.
2016-02-17
00 Terry Manderson [Ballot Position Update] New position, Abstain, has been recorded for Terry Manderson
2016-02-17
00 Alissa Cooper
[Ballot comment]
Given that RFC 3986 says "URI producers should not provide a URI that contains a username or password that is intended to be …
[Ballot comment]
Given that RFC 3986 says "URI producers should not provide a URI that contains a username or password that is intended to be secret" and that RFC 7595 says "Definitions of schemes MUST be accompanied by a clear analysis of the security and privacy implications for systems that use the scheme" and points to RFC 3986, I do not feel comfortable balloting any other position on the narrow question of whether this document conflicts with other IETF work.
2016-02-17
00 Alissa Cooper Ballot comment text updated for Alissa Cooper
2016-02-17
00 Alissa Cooper
[Ballot comment]
Given that RFC 3986 says "URI producers should not provide a URI that contains a username or password that is intended to be …
[Ballot comment]
Given that RFC 3986 says "URI producers should not provide a URI that contains a username or password that is intended to be secret" and that RFC 7595 says "Definitions of schemes MUST be accompanied by a clear analysis of the security and privacy implications for systems that use the scheme" and points to RFC 3986, I do not feel comfortable balloting on the narrow question of whether this document conflicts with other IETF work.
2016-02-17
00 Alissa Cooper [Ballot Position Update] New position, Abstain, has been recorded for Alissa Cooper
2016-02-17
00 Ben Campbell [Ballot comment]
I would also support a note about the cleartext password concern.
2016-02-17
00 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2016-02-17
00 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2016-02-16
00 Alvaro Retana [Ballot comment]
In line with Stephen's DISCUSS, I'm in favor of adding a note (from the authors or the IESG) about the security risks.
2016-02-16
00 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2016-02-16
00 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2016-02-15
00 Joel Jaeggli
[Ballot comment]
URIs with secrets embedded in them seem like spectacularly bad ideas that hearken back to 4248.

I think the conflict review accurate though …
[Ballot comment]
URIs with secrets embedded in them seem like spectacularly bad ideas that hearken back to 4248.

I think the conflict review accurate though iesg text that says you really shouldn't  do this might well be appropiate.
2016-02-15
00 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2016-02-15
00 Spencer Dawkins [Ballot comment]
I'll be listening to the discussion on Stephen's Discuss with interest.
2016-02-15
00 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2016-02-15
00 Brian Haberman
[Ballot comment]
I share Stephen's concern about this document. I do find it interesting that the Security Considerations section talks about potentially protecting sensitive parameters …
[Ballot comment]
I share Stephen's concern about this document. I do find it interesting that the Security Considerations section talks about potentially protecting sensitive parameters within the URI with SSH... when SSH parameters are one of those pieces of sensitive information. And while, I understand that VNC has protections built into it, I think we are beyond the point where we can pretend that information sharing constructs will not be leaked in ways that were not expected or designed for.
2016-02-15
00 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2016-02-15
00 Stephen Farrell
[Ballot discuss]

I will probably move to abstain on this, but sending cleartext passwords,
and SSH passwords in clear without much stronger documentation of
that …
[Ballot discuss]

I will probably move to abstain on this, but sending cleartext passwords,
and SSH passwords in clear without much stronger documentation of
that as an anti-pattern that is only needed for legacy reasons seems like
a really bad idea.  I'm not sure at what point an idea gets so bad that
it'd constitute a conflict with IETF work, but remote access to desktops
is a highly sensitive application and uncritically documenting such a
bad set of practices seems just utterly iccky. I'd like to chat with the
IESG about this issue (how iccky does a thing need to be before we ask
the ISE to deal with it) and whether or not requesting an IESG note
would be appropriate.
2016-02-15
00 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2016-02-15
00 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2016-02-03
00 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2016-02-03
00 Barry Leiba Created "Approve" ballot
2016-02-03
00 Barry Leiba Conflict Review State changed to IESG Evaluation from AD Review
2016-02-03
00 Barry Leiba New version available: conflict-review-warden-appsawg-vnc-scheme-00.txt
2016-02-02
00 Barry Leiba Telechat date has been changed to 2016-02-18 from 2016-02-04
2016-01-22
00 Barry Leiba Placed on agenda for telechat - 2016-02-04
2016-01-22
00 Barry Leiba Shepherding AD changed to Barry Leiba
2016-01-22
00 Barry Leiba Conflict Review State changed to AD Review from Needs Shepherd
2016-01-21
00 Nevil Brownlee IETF conflict review requested