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

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.
>
> Hrm. Or maybe it shouldn't be Informative: isn't it needed to define
> 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 protected]> 
Sent: Wednesday, November 6, 2019 2:50 PM
To: Tom Talpey <[email protected]>
Cc: Magnus Westerlund <[email protected]>; [email protected]; [email protected]; [email protected]
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data



> On Nov 6, 2019, at 2:40 PM, Tom Talpey <[email protected]> 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://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

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

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


> Tom.
>  
> From: nfsv4 <[email protected]> On Behalf Of Magnus Westerlund
> Sent: Tuesday, November 5, 2019 4:24 AM
> To: [email protected]; [email protected]; [email protected]
> Cc: [email protected]; [email protected]
> 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://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
>  
> So I think the document URL you want to include is this one:
> 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
>  
>  
> From: nfsv4 <[email protected]> On Behalf Of McDonald, Alex
> Sent: den 4 november 2019 17:57
> To: Chuck Lever <[email protected]>; Magnus Westerlund <[email protected]>
> Cc: [email protected]; [email protected]
> Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data
>  
>  
>  
> 
> 
> 
> >>       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: <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



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