[Rats] Re: reworking draft-ietf-rats-ar4si (and EAR)

[Michael Richardson <[e-mail]>]

(Ned, you are still sending text/html only, but at least it's not dark-text
on dark-background. However, I can't really tell what text you are writing.
I hope that I get the attributions here right)

[e-mail] <[e-mail]> wrote:
    Ned> (not as chair)

    mcr> I point to RFC761: it defines the TCP header, and the concept of the window
    mcr> but is almost completely mute about congestion control.  The word
    mcr> "congestion" occurs only twice, and no algorithm is provided!!!
    mcr> RFC896,2001(1997!), 2309,2581,2914,... tell one how to actually *do* TCP.
    mcr> This is the model we want.   Okay, it's messy.  But, it survived over 40+ years.
    mcr> I think that EAR should be our RFC761 (structures, meanings of bits).
    mcr> I think that AR4SI should *A* "congestion control" document equivalent.

    Ned> I’m not sure I get the analogy, but I think I get the idea.

Common (extensible) syntax, evolving semantics to suit the situation.

    mcr> I think it should stop trying to be general purpose, and instead it should be

    Ned> It = AR4SI?

Yes.

    mcr> Or (b): "When working with consumer mobile devices, the RP will often be
    mcr> interested in what jurisdiction the device currently is in, and possibly
    mcr> whether or not the end-user is of age.   However, the details of
    mcr> this are private to the device.  This is best done as a passport
    mcr> check, with an Attestation Result that makes use of Selective
    mcr> Disclosure mechanisms."

    Ned> The use of SD / encryption as well as whether audit level
    Ned> information of Verifier’s internal state (which is supported by EAR)
    Ned> would be tied to an
    Ned> appropriate use case. Possibly, EAR profiles would need to be use case specific?

Does EAR have profiles?
I don't see that word in the document.

    mcr> My goal is not to design any single interaction here, but very small classes
    mcr> of specific ones.

    Ned> For example, when selling to US Gov, it is common to have FIPS
    Ned> certifications and to know at what level a system was
    Ned> certified. However, AR4SI doesn’t comprehend FIPS claims and it
    Ned> isn’t a substitute for FIPS either. Hence, a use case context that
    Ned> requires FIPS as attestation results might need to be included with an AR4SI claim

FIPS certification results in an Endorsement, I think.

    Ned> But I’m not clear on how you plan to proceed with AR4SI on a small
    Ned> bytes first approach that is use case specific and still have it
    Ned> make progress toward RFC status as the next nibble will update it
    Ned> before it makes it all the way through the IETF process.

As long as the next "nibbles" does not need to change existing use cases,
then the next nibble is a new document.

    ned> (chair hat on) Is this a
    ned> recipe for an eternally unfinished draft?

No.  Exactly the opposite.
I want to constrain use to real, concrete things that we know how to do.

Write that down, and continue.

To make a different analogy:
      I want a recipe for _chocolate lava birthday cake_ (supporting up to
                                           n-candles, for 0 <= n < 24)

      I don't want a recipe for "round sweet baked items with uniform colour
                                 and specific flavour"

      and then an endless bikeshed that some people want their *bread* square,
      and does this recipe allow for raisins or nuts to included?
      While other people argue that bread is not included because it's
      not always sweet.


{Personally, I prefer dry brownies}

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide