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

[David Noveck <[e-mail]>]

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.

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.

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

Because of the importance of security, we cannot simply wait for such
resources to drop into our laps.,

>
> I fear these minutes do not capture the entire discussion.
>

That's not surprising.

Is there a video recording of the session available?
>

I don't know.  Brian?  Zahed?

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

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

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

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

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

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

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

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


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