ietf
[Top] [All Lists]

Re: Last Call: <draft-salowey-secsh-uri-00.txt> (Uniform Resource Identifier (URI) Scheme for Secure Shell (SSH)) to Proposed Standard

2010-11-17 17:29:03
Thanks for the speedy review, some comments and questions inline below:

On Nov 17, 2010, at 12:25 PM, Cullen Jennings wrote:


Several things in this draft surprised me a bit thought nothing looked 
completely broken. I

You need an IANA registry for the parameters and a way new parameters get 
added

[Joe] OK, Although I think this was more important when the draft also covered 
SFTP, I'm not sure that an SSH terminal session needs additional parameters, 
but I'm sure someone will think of something.  

Do you need to say anything about encoding when the host name is an IPv6 
address?

[Joe] I believe this is taken care of in RFC 3986, but I'll look into this.

It says the fingerprint is in 4716 format but the examples have ssh-dss in 
them that does not look like that format. I would have expected they type of 
the fingerprint to be on the left not the right of the equal sign so instead 
of 


[Joe] ssh-dss is actually the public key algorithm of the hey (ssh-rsa, 
ssh-dss, etc.) represented by Host-key-alg and not the type of fingerprint.   
An ssh server may have more than one host key for supporting different 
algorithms.  The hash for the fingerprint is defined in 4716 and is set to MD5. 
 Maybe we should move away from 4716 so we can have hash agility in the way you 
show below.  I believe we had some limited discussion of this in the past, but 
that was a while ago. 


fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97-77-10-d7-46-41-63-87(_at_)host(_dot_)example(_dot_)com

I would have expected 

md5-fingerprint=c1-b1-30-29-d7-b8-de-6c-97-77-10-d7-46-41-63-87(_at_)host(_dot_)example(_dot_)com

I was surprised to see the c-param added to the user instead of the right 
hand side of URI 

so Instead of 
ssh://user;foo=bar(_at_)example(_dot_)com

I would have expected
ssh://user(_at_)example(_dot_)com;foo=bar

[Joe] we had some discussion of this previously and I believe it was the other 
way at some point. I couldn't find a resolution so I left it as it was.  
Looking at it now, It seems like belongs on the right hand side of the URI 
since is is not about the user, but parameter is about the resource. 

I was surprised that the c-param required the equal so I can not have a 
parameter like  "useFooMode" but must instead have a parameter like 
"useFooMode=1"


[Joe] I'm not sure why we did it that way.  If it aligns with current practice 
we should change it. 


I'd be interesting hearing the logic or why the "//" - I'll point out XMPP, 
SIP, email, etc don't see to have this 


[Joe] The main reason is that telnet does.   It seems that the "//" allows you 
to define an authority component that consists of user(_at_)hostname:port which 
is useful for SSH. 

GIven a major use of SSH is SCP, I wish this URI worked for file paths as 
well 

[Joe] There are multiple SSH file xfer protocols: Sftp and scp.  These were 
originally covered in the draft, but there was no stable reference for them so 
I decided to defer them to another document.  I was thinking they would have 
their own URI schemes.  

The draft says 
 This document is discussed on the IETF SSH list: 
ietf-ssh(_at_)netbsd(_dot_)org

I realize that was the list for the closed WG but I don't think that is an 
IETF list. It is not under IETF rules and is not 
listedhttp://www.ietf.org/list/nonwg.html. I would highly suggest moving the 
conversation to an IETF list. 


[Joe] OK, that is the old SSH WG list which is still active.  I guess we can 
discuss on the IETF list unless there is another one that is more appropriate.  


On Nov 17, 2010, at 11:58 AM, The IESG wrote:


The IESG has received a request from an individual submitter to consider
the following document:
- 'Uniform Resource Identifier (URI) Scheme for Secure Shell (SSH)'
<draft-salowey-secsh-uri-00.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2010-12-15. Exceptionally, 
comments may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-salowey-secsh-uri/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-salowey-secsh-uri/


No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf