Subject: [nfsv4] AD review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data

From: Magnus Westerlund <[email-masked]>
Date: Mon, 4 Nov 2019 14:56:46 +0000

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

---

From: Chuck Lever <[email-masked]>
Date: Mon, 4 Nov 2019 11:36:59 -0500

Hi Magnus, thanks for your review and moving forward with the AD write-up.

> On Nov 4, 2019, at 9:56 AM, Magnus Westerlund <magnus.westerlund=[email-masked]> 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. 
>  
>  
> 	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? 
> 		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. 

The private data field is for use by Upper Layer Protocols. It's existence
is defined by the IBTA, but not its content. It's opaque to the CM, hence
the name "private".

Both iSER and iWARP itself (both IETF-defined) can place data in this field. That's why there
is a 32-bit format ID field: if that doesn't match the constant defined in
this document, that means some other ULP is using the private data field,
and its contents are then ignored by RPC-over-RDMA.

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

Section 4.1 should say bit 15, thanks.

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

As I understand it, the private data field is used by one ULP at a time.
I'm not aware of a TLV. There are already existing ULP implementations
that do not assume a TLV, so that might be a tough sell.

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

I can cite the use of this field by other protocols, if that would help.

> 	5. Isn’t the version field just unnecessary? If one needs version using another format identifier is more easy than the identifier + version construct.

It's possibly superfluous. But:

- the two fields serve different purposes, even though they could be combined.
- there's already an implementation that uses both fields.

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

I would be OK with Expert Review only, but:

1. I will need suggestions about expert guidance. Will look at other RFCs.
2. IMO WG consensus is needed on the replacement text of this section.

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

Integrity is a property of RDMA Reliable Connection transports.

Not clear about the source authenticity requirement. Can you elaborate?

> 	8. IBARCH URL Is not valid, it results in a 404.

Well, that's unfortunate. That's the same URL that's cited in RFC 8166.

Could use this one instead: <http://www.infinibandta.org/specs>.

--
Chuck Lever

---

From: "McDonald, Alex" <[email-masked]>
Date: Mon, 4 Nov 2019 16:57:00 +0000

> Could use this one instead: <http://www.infinibandta.org/specs>.

Also gets a 404. The spec at https://www.infinibandta.org/ibta-specification/ is available only to members. (Most of my IBTA historical links no longer work; the site appears to have had a link makeover in the last few years.)

--
Alex

---

From: Tom Talpey <[email-masked]>
Date: Mon, 4 Nov 2019 16:16:40 +0000

Magnus, one quick response on your first question:

Private Data is supported by multiple RDMA protocols, including iWARP aka RDDP. The document takes care to define a payload which is supported by all.

The Infiniband-style private data exchange, used by RoCE and InfiniBand, is implemented in the IB Connection Manager, and is out of scope for IETF. However the iWARP one is supported by MPA in RFC5044 and RFC6581. But this MPA support isn't mentioned until the Security Considerations section, so I'd agree that adding discussion of all these mappings earlier in the document is a good idea.

RFC6581 has a similar approach btw. It adds private data payloads which are exchanged by the lower RDMA layers. And it provides some possibly useful text:

   As currently defined, DDP connection establishment requires the ULP

   to encode the RDMA configuration in the application-specific Private

   Data.  This results in undesirable duplication of logic to cover RDMA

   characteristics of both InfiniBand and RDDP for each ULP, and to

   specify for InfiniBand and RDDP the extraction of the RDMA

   characteristics for each ULP.

   Both RDDP and InfiniBand support an initial Private Data exchange;
   therefore, a standard definition of the RDMA characteristics within
   the Private Data section would enable common connection establishment
   APIs to format the RDMA characteristics based on the same API
   information used when establishing either protocol to form the
   connection.  The application would then only have to indicate that it
   was using this standard format to enable common connection
   establishment procedures to apply common code to properly parse these
   fields and configure the RDMA endpoints accordingly.  Exchange of
   parameters necessary to perform RDMA Read operations is a common
   usage of the initial Private Data exchange.

In 6581, the text above provides justification ("undesirable duplication of logic"). But for this document, the motivation is to enhance the connection model without extending the rpcrdmav1 protocol. Similar goal, but may lead to subtly different text.

Tom.

From: nfsv4 <[email-masked]> On Behalf Of Magnus Westerlund
Sent: Monday, November 4, 2019 9:57 AM
To: [email-masked]; [email-masked]
Subject: [nfsv4] AD review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data

Hi,

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

---

From: Chuck Lever <[email-masked]>
Date: Mon, 4 Nov 2019 15:57:26 -0500

> On Nov 4, 2019, at 11:16 AM, Tom Talpey <ttalpey=[email-masked]> wrote:
> 
> The Infiniband-style private data exchange, used by RoCE and InfiniBand, is implemented in the IB Connection Manager, and is out of scope for IETF. However the iWARP one is supported by MPA in RFC5044 and RFC6581. But this MPA support isn’t mentioned until the Security Considerations section, so I’d agree that adding discussion of all these mappings earlier in the document is a good idea.

Thanks, Tom. My quick search earlier today did not turn up these two RFC numbers. I can include these two and a reference to the iSER RFC, 7145.

I'll also do a closer comparison of the text Magnus called out with the two paragraphs below from RFC 6581.

> In 6581, the text above provides justification (“undesirable duplication of logic”). But for this document, the motivation is to enhance the connection model without extending the rpcrdmav1 protocol. Similar goal, but may lead to subtly different text.
>  
> Tom.
>  
>  
> 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-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 5 Nov 2019 09:24:05 +0000

Hi,

Regarding the URL: I think you can take the URL for the document from this
page. It is at least publicly available and I was able to download the spec:

https://www.infinibandta.org/ibta-specifications-download/

So I think the document URL you want to include is this one: 

https://cw.infinibandta.org/document/dl/7859

Cheers

Magnus

From: nfsv4 <[email-masked]> On Behalf Of McDonald, Alex
Sent: den 4 november 2019 17:57
To: Chuck Lever <[email-masked]>; Magnus Westerlund
<magnus.westerlund=[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data

> Could use this one instead: <http://www.infinibandta.org/specs
<https://protect2.fireeye.com/v1/url?k=390efdd2-65dafa7e-390ebd49-8667c4afe1
3e-845ba5a4f7c97a19&q=1&e=74cf81e6-d431-43d1-8aca-853647f89252&u=http%3A%2F%
2Fwww.infinibandta.org%2Fspecs> >.

Also gets a 404. The spec at
https://www.infinibandta.org/ibta-specification/
<https://protect2.fireeye.com/v1/url?k=622241c7-3ef6466b-6222015c-8667c4afe1
3e-c542f080840fdbd3&q=1&e=74cf81e6-d431-43d1-8aca-853647f89252&u=https%3A%2F
%2Fwww.infinibandta.org%2Fibta-specification%2F>  is available only to
members. (Most of my IBTA historical links no longer work; the site appears
to have had a link makeover in the last few years.)

-- 

Alex

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 5 Nov 2019 09:46:22 +0000

On Mon, 2019-11-04 at 11:36 -0500, Chuck Lever wrote:
> > On Nov 4, 2019, at 9:56 AM, Magnus Westerlund <
> > magnus.westerlund=[email-masked]> wrote:
> > 
> > Hi,
> >  
> > which currently don’t have any structure but are part of a protocol defined
> > by another body? 
> > 		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. 
> 

So with new text as proposed in other email to clarify that this extensions
apply to several different protocols will help making it clear that this is
useful for IETF to define and not stepping on anyone's particular toes. 

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

That helps a bit, but basically what we end up with is that the ULP need to
cordinate between the end-point about which private data format(s) it will use.
And if is to include multiple formats it need to know that the peer can delimit
all of them. That is what I see as the issue. Maybe this assumption and
responsibility of the ULP can be made clearer in the document. 

> I can cite the use of this field by other protocols, if that would help.

As I said yes. 
> 
> 
> > 	5. Isn’t the version field just unnecessary? If one needs version using

So, I understand that your down the road on this one and you don't need to
implement any change. But, it was a reflection I had after commenting on issue
4). 

> 1. I will need suggestions about expert guidance. Will look at other RFCs.

Basically the WG can specify what requirements you consider needed for a
registration request. Publicly availble specification, contact information, what
criterias the expert should make judgment on. Like if there are sensitive
information or not. Etc. 

> 2. IMO WG consensus is needed on the replacement text of this section.

Sure, and if the WG want to choice IESG approval or Specification Required as
policy for the registry that is also fine with me. However, I am currently not
fine with the strange mix that is currently documented. 

> Not clear about the source authenticity requirement. Can you elaborate?

What I am trying to say, is that security consideration sections should make a
security requirement analysis. And what I can see this private data when
delivered to receiver, the receiver need to know that the data was not modified
and it needs to know from whom it came. Thus integrity and source
authentication. Then you can simply add a statement that the protocol you know
to carry this field will provide that security service. 

The other aspect to consider is really if one can get any impact on the peer by
being malicous in setting these fields. For example can I get the peer entity to
consume more resources? To my understanding the answer is partially yes, but not
without having to similarily promise to allocate resources. And if I don't do
things will fail. And the point is that there is other methods that will be more
efficient to do Denile of Service attacks on the peer in the protocol. 

It is usually good to document what aspects of attacks that has been considered
and what level of an issue they are on. 

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-masked]
----------------------------------------------------------------------

---

From: Tom Talpey <[email-masked]>
Date: Wed, 6 Nov 2019 19:40:59 +0000

I might be concerned that the specific document URL (...dl/7859) might not be a stable one for reference. Perhaps the RFC Editor has some procedure for this type of situation?

One mitigating factor here is that it's an Informative reference, and honestly is mentioned only in passing in the I-D. Perhaps we could consider dropping it altogether.

An alternative is to pursue the same type of standards-sharing agreement. Such a situation exists between IETF and IEEE, and we have been able to designate specific individuals with access as liaisons (David Black has done this for the various iSCSI specs, I believe). Because the IBTA RoCEv2 Annex has certain IETF-relevant items (e.g. its port number assignment), there may be other motivations to create this between the two organizations.

Tom.

From: nfsv4 <[email-masked]> On Behalf Of Magnus Westerlund
Sent: Tuesday, November 5, 2019 4:24 AM
To: [email-masked]; [email-masked]; magnus.westerlund=[email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data

Hi,

Regarding the URL: I think you can take the URL for the document from this page. It is at least publicly available and I was able to download the spec:

https://www.infinibandta.org/ibta-specifications-download/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.infinibandta.org%2Fibta-specifications-download%2F&data=02%7C01%7Cttalpey%40microsoft.com%7C70102a0c18354553a6ce08d761d1ef84%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085426610661285&sdata=sTL2cac%2BupWXK4cKCQMiRbxz9nDsXqvGiMnIgnHz0Fo%3D&reserved=0>

So I think the document URL you want to include is this one:
https://cw.infinibandta.org/document/dl/7859<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcw.infinibandta.org%2Fdocument%2Fdl%2F7859&data=02%7C01%7Cttalpey%40microsoft.com%7C70102a0c18354553a6ce08d761d1ef84%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085426610661285&sdata=4IEfxL%2FkSlN0qCCGmJde0o1Im3MX%2Fdy8n6PwKhDqXYI%3D&reserved=0>

Cheers

Magnus

From: nfsv4 <[email-masked]<mailto:[email-masked]>> On Behalf Of McDonald, Alex
Sent: den 4 november 2019 17:57
To: Chuck Lever <[email-masked]<mailto:[email-masked]>>; Magnus Westerlund <magnus.westerlund=[email-masked]<mailto:magnus.westerlund=[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data

> Could use this one instead: <http://www.infinibandta.org/specs<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D390efdd2-65dafa7e-390ebd49-8667c4afe13e-845ba5a4f7c97a19%26q%3D1%26e%3D74cf81e6-d431-43d1-8aca-853647f89252%26u%3Dhttp%253A%252F%252Fwww.infinibandta.org%252Fspecs&data=02%7C01%7Cttalpey%40microsoft.com%7C70102a0c18354553a6ce08d761d1ef84%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085426610671280&sdata=qFUlxnJs3M7Bs53oZwERcbGFoexEmZmT%2Bu0nms2jOSY%3D&reserved=0>>.

Also gets a 404. The spec at https://www.infinibandta.org/ibta-specification/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D622241c7-3ef6466b-6222015c-8667c4afe13e-c542f080840fdbd3%26q%3D1%26e%3D74cf81e6-d431-43d1-8aca-853647f89252%26u%3Dhttps%253A%252F%252Fwww.infinibandta.org%252Fibta-specification%252F&data=02%7C01%7Cttalpey%40microsoft.com%7C70102a0c18354553a6ce08d761d1ef84%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085426610671280&sdata=Yt8%2FwxMIJMQ9IRoXY7eenY6CWr9CNcoWrj1CsTmTLP0%3D&reserved=0> is available only to members. (Most of my IBTA historical links no longer work; the site appears to have had a link makeover in the last few years.)

--
Alex

---

From: Chuck Lever <[email-masked]>
Date: Wed, 6 Nov 2019 14:50:13 -0500

> On Nov 6, 2019, at 2:40 PM, Tom Talpey <[email-masked]> wrote:
> 
> I might be concerned that the specific document URL (…dl/7859) might not be a stable one for reference. Perhaps the RFC Editor has some procedure for this type of situation?

Indeed. I'm going to go with:

   [IBA]      InfiniBand Trade Association, "InfiniBand Architecture
              Specification Volume 1", Release 1.3, March 2015.

              Available from https://www.infinibandta.org/

and then let the RFC Editor sort it out as s/he prefers.

> One mitigating factor here is that it’s an Informative reference, and honestly is mentioned only in passing in the I-D. Perhaps we could consider dropping it altogether.

Hrm. Or maybe it shouldn't be Informative: isn't it needed to define
exactly what the application-specific CM Private Data field is?

> An alternative is to pursue the same type of standards-sharing agreement. Such a situation exists between IETF and IEEE, and we have been able to designate specific individuals with access as liais…

That sounds generally valuable to me. How would we go about starting
that process?

> To: Chuck Lever <[email-masked]>; Magnus Westerlund <magnus.westerlund=[email-masked]>

--
Chuck Lever

---

From: Tom Talpey <[email-masked]>
Date: Wed, 6 Nov 2019 19:58:53 +0000

> exactly what the application-specific CM Private Data field is?

I don't think so. InfiniBand is out of scope for IETF, and making a normative
reference to it is dicey. For one thing, it might change (well, not private data
but anything might). For another, there is no requirement that an
implementation MUST or even SHOULD use InfiniBand.

As a strawman, what if someone had a proprietary, undocumented RDMA
protocol which happened to support private data and everything else
required to transport RFC8166. We wouldn't make a normative reference
to it, surely.

Tom.

-----Original Message-----
From: Chuck Lever <[email-masked]> 
Sent: Wednesday, November 6, 2019 2:50 PM
To: Tom Talpey <[email-masked]>
Cc: Magnus Westerlund <magnus.westerlund=[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data

              Available from https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.infinibandta.org%2F&amp;data=02%7C01%7Cttalpey%40microsoft.com%7Cc7f4da03461d4230e00208d762f28e86%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086666243925210&amp;sdata=CiOXFir%2B03VV4zJa7aEoqAs6gCO2VE30yPP4LCi9Pb0%3D&amp;reserved=0

> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.infinibandta.org%2Fibta-specifications-download%2F&amp;data=02%7C01%7Cttalpey%40microsoft.com%7Cc7f4da03461d4230e00208d762f28e86%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086666243925210&amp;sdata=SW4%2B0nB8poKZqf2Dhk8ILNZvHXahMABwXFXc2I0rFy4%3D&amp;reserved=0
>  
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcw.infinibandta.org%2Fdocument%2Fdl%2F7859&amp;data=02%7C01%7Cttalpey%40microsoft.com%7Cc7f4da03461d4230e00208d762f28e86%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086666243925210&amp;sdata=1ThSiFErqtcih0Iv63vIDw%2B8WsRvbf3Cl0pwvTXGXlo%3D&amp;reserved=0
>  
> Cheers
>  
> Magnus
>  
>  
> > Could use this one instead: <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.infinibandta.org%2Fspecs&amp;data=02%7C01%7Cttalpey%40microsoft.com%7Cc7f4da03461d4230e00208d762f28e86%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086666243925210&amp;sdata=BvbmS%2FW1Z6ZBLEhy5lPmK6gMJo2AN%2FhdqP415Ye51kQ%3D&amp;reserved=0>.
> 
> Also gets a 404. The spec at https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.infinibandta.org%2Fibta-specification%2F&amp;data=02%7C01%7Cttalpey%40microsoft.com%7Cc7f4da03461d4230e00208d762f28e86%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086666243925210&amp;sdata=tsHeuIPn4%2FMdyJv4Qkt3L43drg8ZCOAV09O%2BXwegGT0%3D&amp;reserved=0 is available only to members. (Most of my IBTA historical links no longer work; the site appears to have had a link makeover in the last few years.)
>  
> -- 
> Alex
> 

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Wed, 6 Nov 2019 17:00:36 -0500

Hi Magnus-

> On Nov 5, 2019, at 4:46 AM, Magnus Westerlund <[email-masked]> wrote:
> 

The latest:

https://chucklever.github.io/i-d-rpcrdma-cm-pvt-data/draft-ietf-nfsv4-rpcrdma-cm-pvt-data.html

And a convenience URL for diffing with -04:

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-nfsv4-rpcrdma-cm-pvt-data.txt&url2=https://chucklever.github.io/i-d-rpcrdma-cm-pvt-data/draft-ietf-nfsv4-rpcrdma-cm-pvt-data.txt

I've tried to address the following issues that you called out after your
attempt at an AD write-up of -04:

- Now a Proposed Standard updating RFC 8166
- Replaced the stale link to the IB specification
- Additional text explaining precedents and the purpose of the Format Identifier
- Revised the IANA Considerations section to remove "specification required" language
- Revised the Security Considerations section

I can take this further if you would like more changes before the next steps.
Otherwise I can provide a draft-ietf-nfsv4-rpcrdma-cm-pvt-data-05.xml for you
to submit manually.

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 7 Nov 2019 15:16:41 +0000

Hi,

It would be good if you can make this as an informative refrence. To me a
workable approach is to use this as an informative reference to identify an IETF
external protocol that could use the specified format. Then you also have the
reference to the IETF prtocol(s) that also can use this extension. 

Cheers

Magnus

On Wed, 2019-11-06 at 19:58 +0000, Tom Talpey wrote:
> Regarding this:
> 
> > > One mitigating factor here is that it’s an Informative reference, and
> > > honestly is mentioned only in passing in the I-D. Perhaps we could
> > > consider dropping it altogether.
> > 
> Cc: Magnus Westerlund <magnus.westerlund=[email-masked]>; 
> [email-masked]; [email-masked]; 
> [email-masked]
> > I might be concerned that the specific document URL (…dl/7859) might not be
> > a stable one for reference. Perhaps the RFC Editor has some procedure for
> > this type of situation?
> 
>               Available from 
> https://protect2.fireeye.com/v1/url?k=a53aadd2-f9b078c4-a53aed49-862f14a9365e-ff1e22b55537618a&q=1&e=2ea3a938-adc2-42e0-bf40-a086de823c8e&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.infinibandta.org%252F%26amp%3Bdata%3D02%257C01%257Cttalpey%2540microsoft.com%257Cc7f4da03461d4230e00208d762f28e86%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637086666243925210%26amp%3Bsdata%3DCiOXFir%252B03VV4zJa7aEoqAs6gCO2VE30yPP4LCi9Pb0%253D%26amp%3Breserved%3D0
> 
> > One mitigating factor here is that it’s an Informative reference, and
> > honestly is mentioned only in passing in the I-D. Perhaps we could consider
> > dropping it altogether.
> 
> > An alternative is to pursue the same type of standards-sharing agreement.
> > Such a situation exists between IETF and IEEE, and we have been able to
> > designate specific individuals with access as liaisons (David Black has done
> > this for the various iSCSI specs, I believe). Because the IBTA RoCEv2 Annex
> > has certain IETF-relevant items (e.g. its port number assignment), there may
> > be other motivations to create this between the two organizations.
> 
> > To: [email-masked]; [email-masked]; 
> > magnus.westerlund=[email-masked]
https://protect2.fireeye.com/v1/url?k=5dd9009f-0153d589-5dd94004-862f14a9365e-ffafefe996551da7&q=1&e=2ea3a938-adc2-42e0-bf40-a086de823c8e&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.infinibandta.org%252Fibta-specifications-download%252F%26amp%3Bdata%3D02%257C01%257Cttalpey%2540microsoft.com%257Cc7f4da03461d4230e00208d762f28e86%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637086666243925210%26amp%3Bsdata%3DSW4%252B0nB8poKZqf2Dhk8ILNZvHXahMABwXFXc2I0rFy4%253D%26amp%3Breserved%3D0
> > So I think the document URL you want to include is this one:
https://protect2.fireeye.com/v1/url?k=2bd60c81-775cd997-2bd64c1a-862f14a9365e-a5209b58ea2cf128&q=1&e=2ea3a938-adc2-42e0-bf40-a086de823c8e&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fcw.infinibandta.org%252Fdocument%252Fdl%252F7859%26amp%3Bdata%3D02%257C01%257Cttalpey%2540microsoft.com%257Cc7f4da03461d4230e00208d762f28e86%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637086666243925210%26amp%3Bsdata%3D1ThSiFErqtcih0Iv63vIDw%252B8WsRvbf3Cl0pwvTXGXlo%253D%26amp%3Breserved%3D0
> > To: Chuck Lever <[email-masked]>; Magnus Westerlund <
> > magnus.westerlund=[email-masked]>
> > > Could use this one instead: <
> > > https://protect2.fireeye.com/v1/url?k=f9931f13-a519ca05-f9935f88-862f14a9365e-8c8772cb39b8f998&q=1&e=2ea3a938-adc2-42e0-bf40-a086de823c8e&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%253A%252F%252Fwww.infinibandta.org%252Fspecs%26amp%3Bdata%3D02%257C01%257Cttalpey%2540microsoft.com%257Cc7f4da03461d4230e00208d762f28e86%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637086666243925210%26amp%3Bsdata%3DBvbmS%252FW1Z6ZBLEhy5lPmK6gMJo2AN%252FhdqP415Ye51kQ%253D%26amp%3Breserved%3D0
> > > >.
> > 
> > https://protect2.fireeye.com/v1/url?k=17db1cd0-4b51c9c6-17db5c4b-862f14a9365e-83c85b5d0732b8d6&q=1&e=2ea3a938-adc2-42e0-bf40-a086de823c8e&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.infinibandta.org%252Fibta-specification%252F%26amp%3Bdata%3D02%257C01%257Cttalpey%2540microsoft.com%257Cc7f4da03461d4230e00208d762f28e86%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637086666243925210%26amp%3Bsdata%3DtsHeuIPn4%252FMdyJv4Qkt3L43drg8ZCOAV09O%252BXwegGT0%253D%26amp%3Breserved%3D0
> >  is available only to members. (Most of my IBTA historical links no longer
> > work; the site appears to have had a link makeover in the last few years.)
> >  
> > -- 
> > Alex
> > 
> 
> --
> Chuck Lever
> 
> 
> 
-- 
Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 7 Nov 2019 16:22:15 +0000

Hi Chuck,

This updates contains quite a lot of improvmenets. Howver I do have some
feedback where I think it can be further improved.

Section 1: I am missing in the introduction of the assumption that to be able to
use this option one requires an ULP with a private data field. I think there
should be a paragraph here providing that context and include infromational
references to protocols that may use this extension. And I think including that
IETF defined ULP here as one option in addition to IBA would be good. 

Section 4 calls the 32-bit ID for format identifier, while the IANA Section
calls it protocol number. Please align the language here. Also the name of the
format is inconsistent after these latest changes. I think the more extensive
name of the format was clearer then what is propsoed now. Becasue it is really
this specific option that is identified, not RPC over RDMA protocol in general. 

Section 4: First paragraph. Depending on what is added to Section 1, this may or
may not need this first paragraph in the current form. But, I get the
impression, that this text either isn't needed here or needs to contain way more
details for the specific protocol. I think the later is hard to do, especially
for an protocol that we don't have change control over. 

Section 6.1: The appointment of the designated expert is done by the IESG and
not the Area Director themselves. See section 5.2.1 of RFC 8126. 

Section 6.1:
"The DE will post the request to the nfsv4 WG mailing list (or a successor to
that list) for comment and review.  The DE will approve	or deny the request and
publish notice of the decision within 30 days."

I would propose that this is reworded so that it will not be necessary for the
IETF to designate a successor list, even if there are no real community. I would
propose a simple addition like:

The DE will post the request to the nfsv4 WG mailing list (or a successor to
that list), if such a list exist, for comment and review.

Cheers

Magnus

On Wed, 2019-11-06 at 17:00 -0500, Chuck Lever wrote:
> > > Both iSER and iWARP itself (both IETF-defined) can place data in this
> > > field.
> > > That's why there
https://protect2.fireeye.com/v1/url?k=86105e9f-da9a7c49-86101e04-0cc47ad93dcc-4cde713b365d5029&q=1&e=1de128de-db49-4c9d-8b49-89fbe4823d29&u=https%3A%2F%2Fchucklever.github.io%2Fi-d-rpcrdma-cm-pvt-data%2Fdraft-ietf-nfsv4-rpcrdma-cm-pvt-data.html
-- 
Cheers

Magnus Westerlund

---

From: Chuck Lever <[email-masked]>
Date: Thu, 7 Nov 2019 13:54:24 -0500

> On Nov 7, 2019, at 11:22 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi Chuck,
> 

Thanks for the further comments. I've updated

to address them.

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 8 Nov 2019 09:16:23 +0000

Thanks Chuck,

From my perspective this is good to progress. Lets get a new version submitted.
Please send me a the text and XML (if you have one) for the document and I will
get it posted. 

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 8 Nov 2019 09:29:34 +0000

-- 
Cheers

Magnus Westerlund