charter tweak - in flight 
John - hashing the key 
    one open tech question:  
    adding new signing ways 
        one is to do hashing of keys
            straightforward to accomplish this
        add elliptic curves ED25519
        open question: should we add the hash for EDDSA sigs?
            since there is no operational benefit, why do this?
    Martin Thomson - Potential benefit - by signing the public key in a header, it is possible in some situations to synthesize a key that will validate
    PHB - some games can be played with keys, has been a proponent of hashes, but don't think that they really provide benefit
        need some tooling to manage the hashes
        just wants to post the pub key into DNS 
    Yoav - If we are trying to minimize the number of things that need to
    interop, do we need both hashing and elliptic curve?"  John - shrug.
    EKR - Martin's concern is key replacement in the zone
        the most consistent thing in the future is to always hash, but may not be critical
    MT - the future is bigger than the past
        a little concerned about signing over the key, but general 
    EKR - don't have two versions of EDDSA
        pref order: hashed always/hash RSA only/non-hashed
    MT - post-quantum may require hashed keys regardless
        Rich : please post concerns about key swap to the list
    PHB - may very well be looking at all standards to be revised in post-quantum world
    MT - note to the list about preferring hashing ratholed; don't miss the other points that were raised in flight
    EKR - names --> take it to the list

Scott - dkim usage 
    raise the floor to 1024, deprecate sha1
    updates ABNF
    pretty close to last call

    MT - concerns: PSS? don't do it here in the doc
        why does it take 5 pages to do two simple things?
        cut the text out which is copied from the DKIM RFC
        don't modify the ABNF - point taken
    EKR - what are the security properties? 
        recapping sha1 attacks discussed on the list
        when should we advise receivers to stop accepting sha1?
            put into the security considerations: EKR accepted action
    need to move sha1 to historic in IANA - put into Scott's draft
    Barry - discussing "should (plus)" (from the room: don't go there)
    John - stopping acceptance is largely an operator evangelization issue
        Kurt - having this draft in flight has been beneficial to getting 3 largest senders of SHA1 to change 
    Chris - must check key size should be added
    MT - doc should just say "MUST NOT" (send or accept)
        provides a good hammer to get change done
    PHB - objects to saying MUST NOT accept (only one in room)
        for message validity yes, it matters
        useful to follow appropriate phasing
    Seth - in 2007, sounded like "SHOULD NOT" - didn't move the needle
        "MUST NOT" was needed to get people to move
    MT - want the headline
    Rich - timetable is important
    vendors hate "MUST NOT implement" 
        "MUST NOT use" is better 
    andreas - should is justify to not change
    
    hums: for +++; against: +; need more info: barely
    Barry: did we just vote?
    Jim on jabber: too soon for MUST NOT accept
    Alexey - we got a sense of the room, but go to the list
    
Scott Rose - doesn't think PC256 ECDSA is needed 
    EDDSA should be sufficient when it gets into FIPS
    proposing to kill the doc