Civic Address Extensibility draft-ietf-geopriv-prefix draft-george-geopriv-lamp-post draft-winterbottom-geopriv-local-civic

Goals Get consensus on the problem we’re trying to solve here Introduce solutions and start some discussions

Problem Statement There are things that people want to add to the RFC 5139 address structure – -prefix, -lamp-post, etc. Need to manage extensibility to maintain interop Changing that structure requires re-issuing the schema, breaking backward compatibility Need to maintain parity in DHCP encoding LoST location validation needs to refer to civic address elements (, etc.)

Solution Option #1 Change the RFC 5139 schema Break backward compatibility Nothing else changes

Solution Option #2 Define a single extension element: – Y – Type MUST be in IANA registry Optionally, second element for “non-official”, unregistered extension CAtypes DHCP via normal IANA numbering LoST modifications to enable validation to refer to elements in these extensions

Solution Option #3 Extensions go in their own namespaces – Y Add a “namespace” field to the IANA registry LoST just works, by use of QNames DHCP via normal IANA numbering

Questions Does the above problem statement capture all the relevant concerns? Discussion of solution options on the list, or at virtual interim!