Re: [Lake] COSE IANA registrations in EDHOC (Was: New Version Notification for draft-ietf-lake-edhoc-09.txt)

Hi,

Haven't followed this discussion in detail, but if the change wanted is only to the IANA registry, and given how the "Updates" tag is very undefined, this wouldn't have to update 8152bis strictly speaking: this could provide a different definition and update the registry (including reference) accordingly. Maybe not the prettiest solution, but might save complications.

Also, this made me take a look at the status of 8152bis, which is in AUTH48: if there was enough community consensus around this change, this change could be done directly in the 8152bis with the appropriate amount of last calls and community feedback etc. Yes, this would delay publication of that document, but given how it's been in AUTH48 for 1.5 months, maybe it could be reasonable to wait the additional weeks, if that's what the community wants and the changes are minor. Food for thoughts.

Francesca

On 01/09/2021, 06:19, "Lake on behalf of Benjamin Kaduk" <lake-bounces@ietf.org on behalf of kaduk@mit.edu> wrote:

    On Tue, Aug 24, 2021 at 11:43:42AM +0000, Göran Selander wrote:
    > 
    > 
    > > On 2021-08-24, 10:05, "Lake on behalf of Carsten Bormann" <lake-bounces@ietf.org on behalf of cabo@tzi.org> wrote:
    > >
    > >    I see.
    > >
    > >    So, you are saying, this will be a “using EDHOC in COSE” specification, 
    > 
    > Well, others may also have use of the COSE header for CWT/UCCS, and the int value type of 'kid'.
    > 
    > >  still normative, but referenced from EDHOC as informative as 
    > >   EDHOC works without COSE.
    > 
    > Well, EDHOC is definitely dependent on COSE, but does not require these particular credentials or identifiers.
    > 
    > >   Yes, it is always hard to position a “using X in Y” draft between the X and Y working groups — after all, the two ends of this draft need 
    > >   to fit X and Y, respectively.  If the EDHOC specification truly doesn’t need the contents of this specification, then I can see moving them
    > >   into a COSE document.  But I think it is as expedient to keep them together in one document.  The only strong reason to split the 
    > >  document would be to avoid a long wait while COSE is deciding on some controversial content of the extracted spec.  Do we foresee such 
    > >  a delay?
    > 
    > Not that I am aware of. Previous discussion in COSE has not indicated that this is contentious. The main thing we haven't discussed is that EDHOC would be updating rfc8152bis-struct.

    I think it would invite questions of charter scope if a document from LAKE
    attempted to update rfc8152bis-struct; keeping that work in COSE seems
    likely to have an easier path, process-wise.

    -Ben

    -- 
    Lake mailing list
    Lake@ietf.org
    https://www.ietf.org/mailman/listinfo/lake