6
Draft Updates Relative Location draft- ietf -geopriv-relative-location HELD Dereference draft- ietf-geopriv-deref-protocol Location Measurements draft- ietf -geopriv-held-measurements HELD Identity draft- ietf -geopriv-held-identity-extensions

Draft Updates

  • Upload
    judson

  • View
    37

  • Download
    1

Embed Size (px)

DESCRIPTION

Draft Updates. Relative Location draft- ietf -geopriv-relative-location HELD Dereference draft- ietf-geopriv-deref-protocol Location Measurements draft- ietf -geopriv-held-measurements HELD Identity draft- ietf -geopriv-held-identity-extensions. Relative Location. No progress to report - PowerPoint PPT Presentation

Citation preview

Page 2: Draft Updates

Relative Location

• No progress to report• Lots of minor issues• Might be blocked on resolution to civic

address extension discussions (Brian)• Binary format lacks usage context (Martin)

Page 3: Draft Updates

HELD Dereference

• GET added after Maastrict discussions• Ready for WGLC

Page 4: Draft Updates

Location Measurements

• Changed wifi measurements after lots of feedback from Gabor Bajko

• Tweaked SSID format to accommodate binary nature of the field

• Seeking final reviews

Page 5: Draft Updates

HELD Identity

• DISCUSS: identifying required identity– We use qualified names to identify what a server

wants (in “requiredIdentifiers”)– Do we want a registry for these?

• Proposal: we shouldn’t create a registry if we don’t need a registry. – We can identify without a registry. – Does a registry aid interoperation enough to

justify the cost?

Page 6: Draft Updates

HELD Identity

• DISCUSS: TCP or UDP Port Number– There are transport protocols other than TCP and

UCP, i.e., SCTP and DCCP. – […] Is there really a use case for identifying

devices based on what is basically a socket ID? – If yes, then you need to […] support SCTP and

DCCP […]