Re: [bfcpbis] AUTH48 [JM]: RFC 8855 <draft-ietf-bfcpbis-rfc4582bis-16.txt> NOW AVAILABLE

[Roman Shpount <[e-mail]>]

Hi Charles,

Per your request, I have reviewed this as and this looks like a correct way
to proceed.

Best Regards,
_____________
Roman Shpount


On Thu, Sep 17, 2020 at 4:09 PM Charles Eckel (eckelcu) <eckelcu=
[e-mail]> wrote:

> Great, thanks Alan.
>
> Cheers,
> Charles
>
> On 9/17/20, 11:27 AM, "Alan Ford" <[e-mail]> wrote:
>
>     Charles, all,
>
>     This seems the correct way to proceed. These are clearly normative
> references, and as regards 5389 vs 8489, 8445 references 5389 normatively
> anyway so if we changed that we would diverge from 8445.
>
>     Best regards,
>     Alan
>
>     > On 15 Sep 2020, at 16:53, Charles Eckel (eckelcu) <eckelcu=
> [e-mail]> wrote:
>     >
>     > Thanks Christer.
>     >
>     > To recap, the updated proposal is to:
>     >
>     > 1) maintain the normative reference to RFC 5389 STUN rather than
> replace it with a reference to RFC 8489
>     > 2) update the reference to RFC 5245 ICE to RFC 8445 ICE (this change
> has already been made a result of AUTH 48)
>     > 3) make the informative reference to RFC 8445 ICE a normative
> reference to be consistent with the normative reference to RFC 5389 STUN
> and with the normative reference to RFC 8845 ICE in rfc4583bis.
>     >
>     > Christer, please confirm if I have capture this correctly.
>     > Everyone else, your feedback here is greatly appreciated as well.
>     >
>     > Cheers,
>     > Charles
>     >
>     > On 9/15/20, 8:13 AM, "Christer Holmberg" <christer.holmberg=
> [e-mail]> wrote:
>     >
>     >    Hi,
>     >
>     >    ...
>     >
>     >>>> 2) make the reference to RFC 5389/STUN an informative reference
> as is already done for RFC 5245/ICE
>     >>>
>     >>> My suggestion would actually be to update the ICE reference to RFC
> 8445. Again, that would align with other C238 cluster documents that
> reference ICE.
>     >>
>     >> [cue] Good point. This reference has already been updated to RFC
> 8445 as part of AUTH-48.
>     >
>     >    Good.
>     >
>     >>> And, in RFC 8445 STUN is a *normative* reference.
>     >>
>     >> [cue] In rfc4582bis, the reference to ICE is currently Informative,
> whereas the reference to STUN is Normative. I believe they should either
> both be Normative or both be Informative.
>     >> Do you happen to know which way would be more consistent with
> similar references to STUN/ICE in cluster C238? In rfc4583bis, the
> reference to ICE is currently Normative.
>     >
>     >    Correct. rfc4583bis actually defines ICE procedures for BFCP, so
> Normative is fine.
>     >
>     >    4582bis contains the following sentence:
>     >
>     >       "In order to facilitate the initial establishment of NAT
> bindings, and
>     >       to maintain those bindings once established, BFCP entities
> using an
>     >       unreliable transport are RECOMMENDED to use STUN [12] Binding
>     >       Indication for keep-alives, as described for ICE [17]."
>     >
>     >    As you can see, it is actually described in the ICE spec on how
> to use STUN. So, therefore I agree that both should be either Normative or
> Informative. And, since there is a "RECOMMENDED", I assume that means they
> would have to be Normative.
>     >
>     >    Regards,
>     >
>     >    Christer
>     >
>     >
>     >
>     >        On 5/21/20, 1:55 PM, "Keith Drage" <[e-mail]>
> wrote:
>     >
>     >            I do note that the normative requirement is at SHOULD
> strength.
>     >
>     >            However there are no statements that support an
> implementor to decide
>     >            under what conditions the requirement can be ignored, or
> the
>     >            consequences of ignoring, one or other of which should
> really be there.
>     >
>     >            The lack of that information does not help in trying to
> evaluate the
>     >            consequences of updating the reference, versus leaving
> the reference as
>     >            it is - note that there is a risk both ways.
>     >
>     >            The quick review I did, resulted in my feeling that the
> upgrade would be
>     >            OK, but I am not an expert in that area. Certainly I
> think either way it
>     >            should go to the WG for a quick review.
>     >
>     >            Keith
>     >
>     >            On 21/05/2020 19:09, Jean Mahoney wrote:
>     >> Hi Charles,
>     >>
>     >> On 5/21/20 11:31 AM, Charles Eckel (eckelcu) wrote:
>     >>> Hi Jean,
>     >>>
>     >>> I am more comfortable sticking with RFC 5389 at this point in time.
>     >>
>     >>
>     >> Ack.
>     >>
>     >>
>     >>> That said, I know that in another thread Christer made the point
> of
>     >>> being consistent across the cluster in terms of referencing RFC
> 5389
>     >>> vs. RFC 8489. If the decision is for the cluster switch to RFC
> 8489,
>     >>> we can consider that. However, I think we would need to take it
> back
>     >>> to the working group to see if there are any issues because I do
> not
>     >>> believe the working group was not tracking this update and did not
>     >>> anticipate its publication.
>     >>
>     >>
>     >> FWIW, so far, the one C238 document that has updated their STUN
>     >> reference to RFC 8489 has an informative ref to it, not a normative
> one.
>     >>
>     >> Thanks!
>     >>
>     >> RFC Editor/jm
>     >>
>     >>
>     >>>
>     >>> Cheers,
>     >>> Charles
>     >>>
>     >>> On 5/20/20, 12:36 PM, "Jean Mahoney" <[e-mail]> wrote:
>     >>>
>     >>>     Authors,
>     >>>
>     >>>     We note that this document has a normative reference to RFC
> 5389
>     >>> (STUN),
>     >>>     which was obsoleted just recently by RFC 8489.  Do you wish to
>     >>> update
>     >>>     this reference to RFC 8489?
>     >>>
>     >>>     Thanks!
>     >>>
>     >>>     RFC Editor/jm
>     >>>
>     >>>
>     >
>     >        _______________________________________________
>     >        bfcpbis mailing list
>     >        [e-mail]
>     >        https://www.ietf.org/mailman/listinfo/bfcpbis
>     >
>     >
>     > _______________________________________________
>     > bfcpbis mailing list
>     > [e-mail]
>     > https://www.ietf.org/mailman/listinfo/bfcpbis
>
>
> _______________________________________________
> bfcpbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>