Subject: [netmod] Fwd: New Version Notification for draft-sf-netmod-file-transfer-yang-00.txt

From: Qi Sun <[email-masked]>
Date: Tue, 10 Mar 2015 14:15:06 +0100

Dear all, 

We’ve developed a YANG model for file transfer. This model supports both upload and download process. It can be used in various scenarios, including HGW software/firmware upgrading, remote file backup, etc.

Please can you review this document.

Thanks,
Qi

Begin forwarded message:
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Montag, 9. März 2015 17:02
> To: Sun, Qui; Farrer, Ian; Farrer, Ian; Sun, Qui
> Subject: New Version Notification for draft-sf-netmod-file-transfer-yang-00.txt
> 
> 
> A new version of I-D, draft-sf-netmod-file-transfer-yang-00.txt
> has been successfully submitted by Qi Sun and posted to the IETF repository.
> 
> Name:		draft-sf-netmod-file-transfer-yang
> Revision:	00
> Title:		A YANG Data Model for Transferring Files
> Document date:	2015-03-09
> Group:		Individual Submission
> Pages:		13
> URL:            http://www.ietf.org/internet-drafts/draft-sf-netmod-file-transfer-yang-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-sf-netmod-file-transfer-yang/
> Htmlized:       http://tools.ietf.org/html/draft-sf-netmod-file-transfer-yang-00
> 
> 
> Abstract:
>   This document defines a YANG data model for the transfer of files
>   between devices.  The data model includes operation data and state
>   data.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Mar 2015 14:50:05 +0100

> Please can you review this document.

Quick questions while browsing the YANG: Since the URIs already
contain information how to access a resource, why do I also have to
define a trans-method?  This seems to be be redundant (and what
happens if things do not line up?). I do not know why
credential-lifetime is needed (the transfer will fail anyway when the
credentials are not valid anymore), I do not understand the timeframe
leaf and some of the other retry parameters, they likely lack units
and descriptions. Assuming that 'index' in fact is a key of list
"file-transfered", I would actually define it to be a list key. I am
not sure why it is needed to have credential-method in the state
tree. What is the value of knowing the retry count while not exposing
the max number of retries? And should there be a cancel mechanism as
well? I am also not sure how the md5 checksum is supposed to work -
does this imply another transfer for the checksum to be verified
against?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Qi Sun <[email-masked]>
Date: Tue, 10 Mar 2015 17:51:42 +0100

Hi Juergen,

Thanks for comments. Please see inline.

On Mar 10, 2015, at 2:50 PM, Juergen Schoenwaelder <[email-masked]> wrote:

> happens if things do not line up?).

[Qi] The intention was to restrict the type of URI for “remote-file-path”. I hope the description provides this information?
Or should the trans-method be put inside “remote-file-path”?

> I do not know why
> credentials are not valid anymore),

[Qi] Yeah… But IMHO, this might be useful for trouble-shouting when transfer failed. And when the credential expires, the device could negotiate to have a second option. 

> I do not understand the timeframe
> leaf

[Qi] Will delete.

> and some of the other retry parameters, they likely lack units
> and descriptions.

[Qi] How about the following:
            leaf retry-times {
                description
                    "Number of times a failed transfer is retried.";
                type uint8;
            }
            leaf retry-interval {
                description
                    "Number of seconds to wait before a retry.";
                type uint32;
                units seconds;
            }
            leaf retry-interval-increment {
                description
                    "Maximum percentage to alter the retry-interval.";
                type percent;
            }

> Assuming that 'index' in fact is a key of list
> "file-transfered", I would actually define it to be a list key.

[Qi] OK.

> I am
> tree.

[Qi] Will remove. 

> What is the value of knowing the retry count while not exposing
> the max number of retries?

[Qi] I just think it would be helpful for maintaining devices if more information could be provide. This can be used for trouble-shooting.

> And should there be a cancel mechanism as
> well?

[Qi] That makes sense. Such that the client is able to instruct the server to cancel a specific transfer. I think it would work with another RPC?

> I am also not sure how the md5 checksum is supposed to work -

[Qi] I’m thinking the device generates a md5 checksum, and uses the generated checksum to verify against the configured checksum. Would that work? 
Anyway, this is an optional parameter. Would it help to put a feature about the function (since not all the devices support md5 checking)?

Thanks,
Qi

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Mar 2015 18:19:01 +0100

> Or should the trans-method be put inside “remote-file-path”?

I am not sure this is a feature. The namespace in my http URIs is very
different from the file system namespace I get when I use ftp or scp.

> [Qi] Yeah… But IMHO, this might be useful for trouble-shouting when transfer failed. And when the credential expires, the device could negotiate to have a second option.

Then I prefer to have more detailed error codes in the state tree.

>                     "Maximum percentage to alter the retry-interval.";

The last one still is a bit vague...
 
> [Qi] That makes sense. Such that the client is able to instruct the server to cancel a specific transfer. I think it would work with another RPC?

Likely. I also assume that transfers do not persist.

> Anyway, this is an optional parameter. Would it help to put a feature about the function (since not all the devices support md5 checking)?

So whoever calls the RPC needs to pass the checksum? But then, if I
upload a file, how do I obtain the checksum in the first place and how
is the checksum passed to the receiver? And depending on the transfer
protocol, you might already get internal checksums so you would only
safeguard against errors that occur between receiving the data and
writing it to disk. I am not sure yet this is really needed.

/js

---

From: Qi Sun <[email-masked]>
Date: Wed, 11 Mar 2015 13:25:45 +0100

Hi Juergen,

> different from the file system namespace I get when I use ftp or scp.

I have no problem of removing the “trans-method” parameter. But what we would like to achieve is to link the “credential” to a specific URI according to the URI’s type. For example, if using scp URI then (username, password) or (username, ssh-key) is required, but (username, certificate) is not. But for https URI, the certificate is required but not the username (typically), and the certificate is not part of the https URI.

How about turning the remote-file-path to a container, including the URI and the related credentials for different methods (as a choice), like this:

container remote-file-path {
    leaf file-path-uri {
        type inet:uri;
    }
    choice credentials {
        case https {
            leaf certificate {
                type string;
            }
        }
        case scp {
            leaf username {
                type string;
            }
            choice scp-credential {
                case password {
                    …
                }
                case ssh-key {
                    ...
                }
            }
        }
    }
}

And we could put description saying that the transfer protocol indicated in the URI MUST match the one specified in the choice. Would that work?

Another option might be that the model provide the information like username/password/path in string/protocol etc., and let the device to construct URI. 

Or could you please give us some guidance on this? Thanks!

> Then I prefer to have more detailed error codes in the state tree.

OK.

> The last one still is a bit vague…

To simplify the structure, maybe removing that parameter would be better?

> Likely. I also assume that transfers do not persist.

Yes. The “transfer-status/status” in the state tree indicates the whether the transfer is done. 

> writing it to disk. I am not sure yet this is really needed.

OK. I will remove that parameter.

Cheers,
Qi

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Mar 2015 15:30:21 +0100

> Or could you please give us some guidance on this? Thanks!

All I can say is that this is a nasty problem to solve. I general,
many protocols support multiple authentication mechanisms and then
there is the difference of validating the remote servers credentials
and how to select or provide local credentials. I predict that you
will spent most of the time to sort this aspect out, the rest looks
rather straight-forward.

/js