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

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. 

 

 

1.	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? 

a.	Have this work been formally agreed with IBTA? 
b.	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. 

2.	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. 
3.	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? 
4.	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.

5.	Isn't the version field just unnecessary? If one needs version using
another format identifier is more easy than the identifier + version
construct.
6.	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? 
7.	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. 
8.	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