Re: [Secdispatch] addressing Content-Type-Encoding errata on EST / RFC7030

[Michael Richardson <[e-mail]>]

On 2019-06-19 9:38 a.m., Michael Richardson wrote:
> 
> Dear secdispatch Chairs,
> 
> I have written draft-richardson-lamps-rfc7030est-clarify-02 to deal with
> the errata:
>     https://www.rfc-editor.org/errata/eid5107
> 
> it turns out that deployed code prevents us from having a signal that
> would let us remove the needless base64 encoding, but at least we can
> remove the deprecated CTE header which was not being used anyway.

Hi secdispatch, I don't think that I really need any in-person time next 
week on this.  I'm just looking for guidance on where/how such a 
document should proceed.  AD-sponsor? LAMPS? Something else?

The base64/Content-Type-Encoding situation definitely caused a lot of 
confusion for the BRSKI inter-operation testing that has occurred in the 
past few months.

> 
> I believe that we can deal with:
>      https://www.rfc-editor.org/errata/eid4384
>      https://www.rfc-editor.org/errata/eid5108
> 
> in this document as well, although I haven't yet done that.  The result would
> be a standards track document that Updates RFC7030.

There is an additional errata of a completely editorial from July 13.
I don't really speak enough ASN.1 to know if the ASN.1 errata is valid.

I'm told that Dan Harkins has other reasons to re-open RFC7030, and 
while I think we could satisfy the PS->IS step via interoperation and 
deployment experience, I'm not burning to do that work.

> 
> As an aside, I think that the errata needs to move from reported to accepted.
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
> 
> 
>