Re: AD review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data

Hi,

To my understanding -05 took care of my issues, but we are waiting for a -06 to
take care of the expert review according to the discussion on the mailing list. 

When that version has been posted I will initiate IETF last call. 

Cheers

Magnus

On Mon, 2019-11-04 at 14:56 +0000, Magnus Westerlund wrote:
> Hi,
>  
> I have started my AD review. It was such a short document that I thought I
> read through it to figure out what more I need to read. So I have not yet read
> like RFC 8166. So from a context of having little context understanding the
> below are my comments and questions. I think it may be faster if you help
> answering them then I read a lot of documents and still have question marks.
>  
>  
> So this private data field is only existing in Infinite Band Connection
> manger? So what this document is defining a structure to a field which
> currently don’t have any structure but are part of a protocol defined by
> another body?
> Have this work been formally agreed with IBTA?
> Or is the relationship to the connection manager used to establish the RPC
> over RDMA different, if that is the case it needs to be better explained.
> Is it bit 8 or bit 15 of the flags field that are used. Section 5.1 and 4..1 do
> not agree. The later thinks it is bit 8.
> Section 5: Is there only going to be one object of private data forever in the
> relevant communication? If not, why isn’t this a well-specified TLV so that
> unknow type entries can be skipped to the nest object?
> Even if there ever is going to be one entry, can you be more formal in
> description of what is a valid message using another format identifier, is
> that only the 32-bit field of the format Identifier, or also the version.
> Isn’t the version field just unnecessary? If one needs version using another
> format identifier is more easy than the identifier + version construct.
> Section 6: The IANA consideration is confusing. If the specification for a CM
> private data format requires IESG approval, then why have the expert review
> policy. In that case one can simply use the IESG approval policy instead.
> However, requiring any type of IESG approval here appear to be a way to high
> bar. I think expert review is likely appropriate, but the guidance to the
> Experts needs to be clearer. For example what happens if IBTA want to use this
> to add some format?
> Section 7: The security consideration. I am missing any discussion about the
> security requirements that the actual extension. It appears that integrity and
> source authenticity are required for safe operation of these two extensions.
> IBARCH URL Is not valid, it results in a 404.
>  
> Cheers
>  
> Magnus Westerlund
> _______________________________________________
> nfsv4 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nfsv4
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email protected]
----------------------------------------------------------------------

_______________________________________________
nfsv4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4