• Revised I-D Needed - Issue raised by WG
  • Awaiting Expert Review/Resolution of Issues Raised
  • Awaiting External Review/Resolution of Issues Raised
  • Awaiting Merge with Other Document
  • Author or Editor Needed
  • Waiting for Referenced Document
  • Waiting for Referencing Document
  • Revised I-D Needed - Issue raised by WGLC
  • Revised I-D Needed - Issue raised by AD
  • Revised I-D Needed - Issue raised by IESG
  • Doc Shepherd Follow-up Underway
  • Other - see Comment Log

IETF :: netext

Current state: Submitted to IESG for Publication

Viewing the last 20 entries. Show full log.

(System)

RFC published

(System)

IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor

(System)

IANA Action state changed to Waiting on RFC Editor from In Progress

(System)

IANA Action state changed to In Progress from Waiting on Authors

(System)

IANA Action state changed to Waiting on Authors from In Progress

Amy Vezza

State changed to RFC Ed Queue from Approved-announcement sent

(System)

IANA Action state changed to In Progress

Amy Vezza

State changed to Approved-announcement to be sent from None

Amy Vezza

IESG has approved the document

Amy Vezza

Closed "Approve" ballot

Amy Vezza

State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup

Brian Haberman

Ballot approval text was generated

Stephen Farrell

[Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss

Brian Haberman

Ballot writeup was changed

Brian Haberman

Ballot writeup was changed

Robert Sparks

[Ballot comment]
I assume the conclusion of the discussion you were having at IETF about the encoding of SSIDs fell out to UTF-8 instead of raw bits?

Robert Sparks

[Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss

Stephen Farrell

[Ballot discuss]
(1) Why doesn't this use geopriv? I think Robert put this better than
I in asking why don't RFC 6280 considerations apply. I think they
ought. The text that's new since -11 however, might provide a way
forward. In -12 you clarified that this information is only for infrastructure
nodes to use to provide better network service. And in -13 you changed
the lat/lon structure. So I'm wondering if there's a way to do a -14
that adds the rule information to the lat/lon as 6280 implies is
needed? That could be as simple as a hardcoded value, not sure
if that'd work, but since you've changed that structure in -13, adding
some hardcoded value meaning "this rule applies" might be a way
to fix this.

(2) cleared

(3) Rolled into point 1 above.

(4) cleared

Stephen Farrell

Ballot discuss text updated for Stephen Farrell

Stephen Farrell

[Ballot discuss]
(1) Why doesn't this use geopriv? I think Robert put this better than
I in asking why don't RFC 6280 considerations apply. I think they
ought. The text that's new since -11 however, might provide a way
forward. In -12 you clarified that this information is only for infrastructure
nodes to use to provide better network service. And in -13 you changed
the lat/lon structure. So I'm wondering if there's a way to do a -14
that adds the rule information to the lat/lon as 6280 implies is
needed? That could be as simple as a hardcoded value, not sure
if that'd work, but since you've changed that structure in -13, adding
some hardcoded value meaning "this rule applies" might be a way
to fix this.

(2) cleared

(3) Rolled into point 1 above.

(4) I looked at 6275 and 5213 and its not clear to me that
these sensitive values, if sent, MUST be protected using IPsec
with strong confidentiality and mutual authentication. The
authentication part may be ok according to the documents, but
I'm not sure if that's the deployed reality. Is it? But even if
so, there's nothing much that I can see to ensure
confidentiality for this information. Where's all that
(clearly) specified? I still do not see this clearly specified
anywhere in -13. Just using AH is arguably not enough
here.

Viewing the last 20 entries. Show full log.