As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?
The requested type of RFC is "Standard". This is the appropriated type as the
document proposed a new encoded terminal mode for SSH. This is necessary for
client and server to agree on the terminal properties. The type is indicated in
the title page.
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:
Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.
This document specifies IUTF8 a new opcode for the Secure Shell terminal modes
encoding. This opcode enables the widely used IUTF8 terminal mode that
indicates terminal I/O uses UTF-8.
Working Group Summary
Was the document considered in any WG, and if so, why was
it not adopted as a work item there? Was there controversy
about particular points that caused the WG to not adopt the
document?
The document was announced on the secsh mailing list [1]. The item was not
adopted as the WG is concluded.
There were no controversy everyone agree on the goals protocol as well as on
the protocol design (1). The only discussion that happened on the mailing list
was on which reference to have for UTF8 (2).
(1) Goal and protocol design :
As mentioned in [1], Colin Watson on 2005-12-31, David Madore on 2013-03-29 [2]
both suggest to allocated the same number (42) for the flag which was supported
by Chris Lonvick[5], Mouse [6] and Niels Moller [7]. In addition, The SSH
community has already implemented it. As mentioned in [1] Fedora's package of
OpenSSH already seems to be running with a downstream patch implementing IUTF8
under that number. [3] contains a patch file openssh-7.1p1-iutf8.patch
implementing it. MouSSH has a development branch containing the same feature.
Finally, request for review have been send on the SAAG ML 2016-06-23 as well as
on the concluded secsh mailing list [8] and none opposed. Mark Baushke [9]
supported the draft.
[1] https://www.ietf.org/mail-archive/web/secsh/current/msg01241.html
[2] https://www.ietf.org/mail-archive/web/secsh/current/msg01229.html
[3]
https://dl.fedoraproject.org/pub/fedora/linux/updates/23/SRPMS/o/openssh-7.2p2-3.fc23.src.rpm
[4] https://www.ietf.org/mail-archive/web/secsh/current/msg00654.html [5]
https://www.ietf.org/mail-archive/web/secsh/current/msg00660.html [6]
https://www.ietf.org/mail-archive/web/secsh/current/msg00655.html [7]
https://www.ietf.org/mail-archive/web/secsh/current/msg00656.html [8]
https://www.ietf.org/mail-archive/web/secsh/current/msg01241.html [9]
https://www.ietf.org/mail-archive/web/secsh/current/msg01242.html
(2) UTF8 reference:
Using RFC3629 as a reference for the UTF-8 is not convenient as its two
normative references need to be updated. The two references in question are:
[ISO/IEC 10646:2014] and [Unicode]. The references to include with consensus
from the list were the ones below:
- [RFC3629] as normative
- [UNICODE] The Unicode Consortium. The Unicode Standard.
<http://www.unicode.org/versions/latest/> as informational.
[UNICODE] reference was believed to be more useful to the community and update
for [ISO/IEC 10646:2014] is left for a future RFC3629bis.
A more recent version of ISO/IEC 10646 will be done by refreshing RFC3629.
The document adds a new encoded terminal mode for SSH: IUTF-8. Such terminal
mode is used while requesting a pseudo terminal ("pty-req") during the SSH
Connection Protocol. The appropriated WG secsh is concluded, and no such WG
exist to have the document as a WG item. An individual submission is
appropriated.
Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?
In addition, The SSH community has already implemented it. As mentioned in [1]
Fedora's package of OpenSSH already seems to be running with a downstream patch
implementing IUTF8 under that number. [3] contains a patch file
openssh-7.1p1-iutf8.patch implementing it. MouSSH has a development branch
containing the same feature. The authors also added privately: """ It was added
to dropbear in 2013
(https://github.com/mkj/dropbear/commit/a6eb824950e6d938fa47c1f9fa1880b652d51833)
and has been in many releases since then.
It is in the most recent release of OpenSSH (7.3, released August this year:
https://www.openssh.com/releasenotes.html#7.3) Before that it was added by some
vendors to their packages of OpenSSH.
It is in the development version of PuTTY but (Simon correct me if I'm wrong)
it is not yet in a released version.
https://git.tartarus.org/?p=simon/putty.git;a=commit;h=dcf44663057ec4df3581f8fd2a31c65a98e6988a
"""
"""
I would add just one detail to Darren's list. He says that vendors have
been known to add the IUTF8 opcode to their packages of OpenSSH.
Specifically, I know that Fedora has done this to versions of OpenSSH
predating the upstream support in 7.3:
http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/commit/?h=f25&id=38e1dfa80d74ea3f084390bcc40256616c2dd56d
""""
Finally, request for review have been send on the concluded secsh mailing list
[8] and none opposed. Mark Baushke [9] supported the draft.
[1] https://www.ietf.org/mail-archive/web/secsh/current/msg01241.html
[3]
https://dl.fedoraproject.org/pub/fedora/linux/updates/23/SRPMS/o/openssh-7.2p2-3.fc23.src.rpm
[8] https://www.ietf.org/mail-archive/web/secsh/current/msg01241.html [9]
https://www.ietf.org/mail-archive/web/secsh/current/msg01242.html
Personnel
Who is the Document Shepherd? Who is the Responsible Area
Director?
Daniel Migault is the document Shepherd. Kathleen Moriarty is the Responsible
AD.
(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
The document shepherd provided clarification and nits comments. These have been
addressed in the current version.
The document seems ready to me.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No.
(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
No.
(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community has
discussed those issues and has indicated that it still wishes to advance
the document, detail those concerns here.
The document shepherd has no concern about the document.
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
The authors declares they are not aware of any IPR.
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any discussion and conclusion regarding the IPR
disclosures.
No
(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?
As detailed in the "WG Summary"section, I am considering there is a strong
consensus of the interested community.
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
No.
(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
idnits 2.14.01 /var/www/.idnits
The following warning were reported by idnit:
- No rfc159 state file. Attempting to download it...
Failure fetching the file, proceeding without it.
This is a mis interpretation for the number 159 as an RFC number. It is not an
RFC number.
The idnits also provided the following warning.
Miscellaneous warnings:
----------------------------------------------------------------------------
(Using the creation date from RFC4254, updated by this document, for
RFC5378 checks: 2005-03-16)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
http://trustee.ietf.org/license-info for more information.)
IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii):
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before
November 10, 2008. The person(s) controlling the copyright in
some of this material may not have granted the IETF Trust the
right to allow modifications of such material outside the IETF
Standards Process. Without obtaining an adequate license from the
person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process,
and derivative works of it may not be created outside the IETF
Standards Process, except to format it for publication as an RFC
or to translate it into languages other than English.
Basically the author response is on IPR. They have not explicitly granted all
BCP78. I do not think it is necessary as the document has been published in May
2 2016 and does not provide material previous to November 10 2008.
== Unused Reference: 'UNICODE' is defined on line 150, but no explicit
reference was found in the text
'[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://w...'
The UNICODE reference has been placed as informative because the reference from
the normative reference RFC3629 was outdated. I believe it makes sense to have
that reference not reference in the text. However, if that causes any issue,
the reference to be added later in the text in addition to the one to RFC3629.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
The document does not require additional review.
(13) Have all references within this document been identified as
either normative or informative?
All references have been identified as normative or informative.
(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
No.
(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
No.
(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the interested community considers it unnecessary.
RFC 4254 will be updated.
This is mentioned in the title page header, the abstract and the introduction.
(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
The IANA section is fine. It is consistent with the document. Protocol
extensions are associated with the reservation. IANA registries have been
clearly identified. The registry includes a detailed specification.
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
[1] is the concerned section. It does not list any expert for SSH.
[1]
http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-8
(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.
No additional were performed nor needed.