Re: [tsvwg] John Scudder's No Objection on draft-ietf-tsvwg-rfc6040update-shim-22: (with COMMENT)

[Bob Briscoe <[e-mail]>]

John, Thx for the review. Pls see [BB]...

On 30/11/2023 14:21, John Scudder via Datatracker wrote:
> John Scudder has entered the following ballot position for
> draft-ietf-tsvwg-rfc6040update-shim-22: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for this impressive spec. I have just a few comments/questions.
>
> - I am quite bemused by the proportion of this document devoted to exegesis
> rather than specification, but at least it makes an interesting read.
>
> - In,
>
>           For those not under IETF
>     control, it is RECOMMENDED that implementations of encapsulation and
>     decapsulation comply with RFC 6040.  It is also RECOMMENDED that
>     their specifications are updated to add a requirement to comply with
>     RFC 6040 (as updated by the present document).
>
> I don’t think you can point a BCP 14 “RECOMMENDED” at the owners of those
> specifications and expect it to have any force, any more than you can update
> their specifications, for the same reason.  This seems to be an exuberant use
> of all caps to mean “we really do suggest this quite enthusiastically”, but
> that’s not what BCP 14 is.

[BB] Surely IETF RFCs don't have any force over owners of other IETF 
RFCs either. Surely the point  of IETF RFCs is merely to state what is 
necessary (MUST) or desirable (SHOULD) for interoperability. Then anyone 
who wants to interoperate can try to comply /voluntarily/ because it's 
in their interests to interoperate, not because the IETF has any 
enforcement powers over them.

> - Has this work been liaised to 3GPP (and any other SDOs I might have missed
> that are potentially affected)?

[BB] Not this draft specifically, but ecn-encap-guidelines was liaised 
with 3GPP (and IEEE) before rfc6040update-shim was split off from it (to 
carry all the standards track material). Links to these liaisons are in 
the shepherd write up for ecn-encap-guidelines:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/shepherdwriteup/

Indeed the 3GPP put a huge amount of work in to finding all their Study 
Groups that had worked on ECN encapsulations and all their TRs that 
depend on ECN encapsulation (primarily for VoLTE), and we in turn put in 
a load of work to review all these TRs.

Cheers


Bob



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/