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

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.
> > 
> > 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://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
> 
> 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://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
> >  
> > 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://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
> > > >.
> > 
> > Also gets a 404. The spec at 
> > 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 


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