Re: [nfsv4] Comments on minutes of wg meeting at IETF114

[David Noveck <[e-mail]>]

On Tue, Sep 13, 2022, 12:38 PM Chuck Lever III <[e-mail]>
wrote:

>
>
> On Sep 13, 2022, at 5:29 AM, David Noveck <[e-mail]> wrote:
>
> On Mon, Sep 12, 2022, 12:25 PM Chuck Lever III <[e-mail]>
> wrote:
>
>
>> The conclusion of this discussion was to let the RDMA and ULB documents
>> expire and remove the charter milestone.
>>
>
> Regardless of that, we would have to ascertain consensus to do that.
> Decisions at working group meetings always have to be confirmed on the wg
> mailing list.
>
>
> Fwiw, the co-chair and area director in the room at the time did not state
> that requirement. The co-chair stated that the charter change was implied
> by the decision to allow the documents to expire, so I assumed that meant
> that no further bureaucratic actions were necessary.
>

If there were a decision made to allow the documents to  expire, that would
have required confirmation on the list.  The co-chair and AD were in the
room but the whole working group was not.

>
>
> That should have been done a month ago, but we might as well have that
> discussion now.
>
>
>> A version 2 of RPC/RDMA is not in demand by any customer.
>>
>
> Fair enough.  It is a shame we have an RDMA approach so inferior to SMB.
> Sigh!
>
> >  I feel it’s time to let it rest,
>
> If you don't want to push this to a conclusion, then we have to live with
> what we have.
>
>
> It's not a matter of not wanting to push this to conclusion. It is simply
> not possible for me to finish this by myself: proper protocol development
> requires two independent implementations.
>
> After Linux, where is the second implementation? (Answer: there isn't one)
>

Hold on a minute.  Are you saying there is Linux v2 implementation?

If so, I need to start working on a v2 server.  I hadn't heard of any v2
implementation work.


> Who is bringing RPC/RDMA v2 implementations to our testing events?
> (Answer: no one)
>

Right but you shouldn't read too much into that.  I haven't been bringing
v1 implementations to testing events but that hasn't  stopped development.
I do test with the Linux client internally.


> Which vendors truly want to bring a second implementation of RPC/RDMA to
> market? (Answer: I have yet to hear of one that has the resources to do
> this)
>
> What customers are demanding it? (Answer: I have yet to hear of any; the
> demand has come exclusively from complaints made by protocol architects)
>

Yes.  That is how it has been from the start.: you, me, and Tom.



> Improving security for MPA/RDMAP is an approach that lifts all boats. What
> few resources the WG has is better spent on that instead of RPC/RDMA v2.
>

Fair enough.


>
> > Unless or until there are sufficient resources to attack the addition of
> transport-layer security to MPA/RDMAP.
>
> That sounds to me too much like "We'll do it when we get around to it."
>
>
> You can spin it any way you like, but that's always the way it's been.
> When we have the energy and enthusiasm for an idea, it will get done
> somehow. We have more enthusiasm for what is essentially iWARP on QUIC than
> for RPC/RDMA v2.
>
>
> Because of the importance of security, we cannot simply wait for such
> resources to drop into our laps.
>
>
> It's not clear what motivated this remark, but no-one has suggested that
> we ignore the security requirements of RPC/RDMA.
>

OK.


>
> Chuck has informed me that a wg decision was made to abandon this document
>> but that does nĺ⁰ot appear in the minutes.
>>
>>
> I'm perplexed by this and expect to remain so even if a 3-D 4K-resolution
> video were discovered.
>
> Given that this was an individual draft, the decision was not a wg
> decision and does not have to be confirmed on the list.
>
> Instead, it is Chuck's decision to make but I'd like to understand why he
> made it.
>
> Let me give people some background.  Chuck objected to the treatment of
> SECINFO in some earlier security-0x draft.  He thought it was to
> complicated so we agreed that he would publish his approach, as he did in
> rpc- tls-pseudoflavors and I  would refer to that in the next security
> draft.
>
> Now it appears that Chuck has changed his mind and I'd appreciate knowing
> why <http://why.ch/>.
>
>
> Rick told me he is not going to implement it.
>

As he clarified,, he just doesn't use SECINFO. .

Trond stated that the proposed mechanism is a hack, which I take to mean he
> will not accept it in the Linux client.
>

I take it to mean he thinks it's a hack and maybe it is.  Trond is quite
capable of saying he will not accept something in the Linux client


>
> In any case, I need either this document or some replacement to proceed
>> with security-05
>>
>>
> I suppose I could get by, pulling some material from Chuck's document into
> security-05.
>
>
> Since the security document is a working group document,
>

It isn't yet.

> you would need WG consensus before pursuing such a unilateral approach.

I intend to try to get consensus on this issue as part of wg adoption for
the security document.

>
>
>   However,  I don't think  that's the right way to do that and I feel that
> our original agreement (Chuck's and mine) was right.
>
>
> Be that as it may, implementers have already decided otherwise.
>

I don't think so..

Writing a standard that is contrary to existing implementations seems
> counterproductive.
>
>
> Rick says he plans to implement a simple rejection of RPCs when a server’s
>> security policy does not permit AUTH_SYS without TLS, using existing RPC or
>> upper layer status code. The client can decide to retry with TLS (why was
>> it not defaulting to TLS in the first place?) or let such requests fail.
>>
>
> That seems like a sensible implementation to me.  However, it is not
> complete and does not address the fundamental problem, that rpc-with-tls
> makes SECINFO, as defined in RFCs 7530 and 8881 essentially useless.  It
> was built when Auth flavors alone defined security capabilities and that is
> no longer the case 😀.
>
>>
>> I’d like Rick to write a brief description of his idea.
>>
>
> I think I  am getting the implementation idea.  We have to reach a
> consensus on the future of SECINFO.  I hope nobody objects to augmenting it
> with pseudoflavors because I object strongly to leaving it almost useless
> and explaining that in rfc5661bis.
>
>
> Rick and Trond have already rejected the use of pseudoflavors.
>

Ruck hasn't  and Trond may or may not have.  As Rick has said, there is no
currently consensus on the issue.


> Please explain what you mean by "leaving SECINFO useless". If a SECINFO
> response lists AUTH_SYS and the server rejects a subsequent unprotected
> AUTH_SYS request with AUTH_TOO_WEAK, the client can retry with AUTH_SYS on
> a protected transport. If it doesn't have RPC-with-TLS available, the
> unprotected request fails.
>
> What is missing?
>
>
> > Zahed questions whether we had an adoption call for the BIS document?
>>
>> I guess not.   The issue is complicated by current plans for document
>> split-up.
>>
>>
>> We haven’t had any deep public discussion of the scope of each the
>> replacement documents.
>>
>
> True.  I proposed a possible split to address Zahed's concerns about the
> size of RFCs 5661 and 8881.
>
> Given how labor-intensive it is to split up
> the bis given inter-document references,
> I think it is time to reconsider this.
>
>
> This is really up to Zahed but I'd like to hear opinions from the rest of
> the working group.
>
>
> In a perfect world, RFC 5661/8881 should be split up. If there are not
> enough document authors and shepherds and reviewers available to do that,
> however, we will need to find a lighter-weight approach.
>
>
> They have grown to encompass quite a bit more than what was in RFC 5661
>>
>
> Could you be more specific?
>
> . I would feel more comfortable if the WG could agree on a limited scope
>> for each of these to prevent scope creep from making them impossible to
>> complete.
>>
>
> Let's leave aside the splits not yet done.  The scope of rfc5661bis is
> limited to rfc8881 plus rfc8434.
>
>
> The issue for me is how much rewriting is being done without first
> obtaining WG consensus. This has been due, somewhat, to the largely
> inadequate virtual meeting facilities we've had during the pandemic. As an
> alternative, much of that work could have been done on the mailing list,
> and so far only some of it has been.
>
> The ACL section of the security document especially is a concern: why are
> we not taking the same approach as with internationalization? Document what
> current implementations do. Do not relitigate consensus decisions made a
> decade ago by a different group of people who are no longer around. There
> is no consensus about the approach taken in the security document.
>
> Likewise, we do not have even rough consensus about SECINFO, MNT, and
> pseudoflavors. I'm not comfortable with what I'm hearing you say about
> unilaterally adopting a mechanism that no-one will implement. I don't see
> how that solves any problem, perceived or real.
>
>
> The idea that we are addressing every errata against RFC 5661 with the bis
>> effort is new to me.
>>
>
> That's surprising to me.  I think that if you are doing a bis and leave
> errata unaddressed, you are not doing your job:
>
>
> See Zahed's comments. The only errata that can be dealt with via a bis are
> the ones in "Hold for document update".
>

Zahed suggested moving all the editorial ones to hold for document update
so they will be addressed as part of the bis
The imortant thing is we cannot just drop them.

As Brian said, we need to scrub the errata to understand what needs to be
> dealt with via bis, and what can be dropped or closed.
>

I haven't heard of any that can be dropped or closed from you or Brian or
anyone else.


>
>    - For accepted editorial errata reports, it would be insane not to
>    incorporate the correct version and stick with the erroneous text.
>    - For held-over errata reports, the bis is the only opportunity to fix
>    a reported (and acknowledged) error.
>    - For rejected errata reports, if there is a wg consensus for change
>    they have to be fixed in the bis.
>
>
> IIRC, there was a lot of discussion on the list in which I reassured Trond
> that his errata reports, even though formally rejected, would be addressed
> in the bis.
>
>
> I'm sure Trond's reports are largely reasonable suggestions, but shouldn't
> the WG decide that on a case-by-case basis?
>

Yes they should.

>
>
> >  I know we had some vague plans to address some of them,
>
> I had vague plans to address all of them and work on those plans is
> ongoing. I need to focus on doing the rest without detailed plans.
>
>
> Again, shouldn't the WG be involved?
>

If it wants to be.  I've been producing drafts that list the errata that
have been dealt with for quite some time now.

> These "vague plans" lack transparency.

>
>
> > and I had proposed keeping track of these with the github issue tracker.
> However, github has not been adopted for any of these documents,
>
> Maybe we can do that after these are adopted as working group documents. I
> will need your help.
>
>
> The point of tracking issues is to write them down so we can measure
> progress and archive decision-making while it is fresh (or as it is
> ongoing). "after these are adopted" seems too late to be valuable.
>
> Alternatively, the comment section of each errata can be used to deal with
> it if you are not comfortable with github's issue tracker. There is no
> progress measurement mechanism in errata comment sections, but it's better
> than nothing. But it's got to be public and transparent.
>
>
> > so at this time there is no real tracking of these outstanding issues.
>
> My 5661bis drafts list the errata that have been addressed.  In the next
> draft, I will also list the ones that have yet to be addressed.
>
>
>> There are, of course, errata against other RFCs that this WG is
>> responsible for. My impression of the discussion during the session was
>> that all of these errata were a problem, not just the errata against RFC
>> 5661.
>>
>
> What sort of problem?  Are there errata for other documents that are big
> enough that a bis is required? If not, we may just have
>
> to muddle through.
>
>
> There is a process for handling errata that needs to be followed for each
> report. I'm not sure what muddling through means, but that sounds opaque
> and therefore undesirable.
>
> Again, the discussion in the room was about all errata that are currently
> on the WG's plate. There currently is no strategy or plan for dealing with
> that work, though it is clearly within the WG's charter.
>

Do you have an idea for one?


>
> --
> Chuck Lever
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>