IDentity Enabled Networks
charter-ietf-ideas-00-06

[Ballot block]
At this point in time, I believe the community should meet in Singapore to discuss IDEAS.
Whether this is a BoF or WG, I guess that same points would be on the table.
So use the BoF time.
The BoF objectives could be:
1. What are the privacy issues?
2. If we need to address those, how? (no need for the full solution, but potential tracks)
3. Based on 1 and 2, should we charter IDEAS?
4. If yes, work on the charter text

[Ballot comment]
I agree with the comments that this should have further discussion about privacy. An additional BLOCK on that point doesn't seen necessary.

I agree with Spencer that we don't seem to be talking about _this_ charter anymore. I think that ideally we should withdraw this from consideration, and readdress it with a new charter proposal. So I'm ABSTAINing.

[Ballot comment]
I agree with the comments that this should have further discussion about privacy.

I agree with Spencer that we don't seem to be talking about _this_ charter anymore. I think that ideally we should withdraw this from consideration, and readdress it with a new charter proposal. So I'm abstaining.

[Ballot block]
As other ADs have noted, I don't think this group is ready to be chartered considering
the on-going community discussion/concerns raised and the on-going discussion
among the proponents on what they want to do.

[Ballot comment]
FWIW - similar to Spencer, I had voted Yes to send the charter to the community for review with
the comment that I was concerned the use cases were very diverse and it was not clear if a
common approach would be achievable. The community's concerns on basic definitions (id,
mapping system, privacy) and the inability for the proponents to clarify with concise definitions, I now
don't think this is ready to be a working group.

Instead of continuing to boil the ocean on use cases to justify motivation, it would be more
helpful to focus on what specifically are the IETF requirements for the mapping system.

The dashed list is also boiling the ocean, it needs to be more scoped, e.g. "A security analysis
of the complete system" doesn't sound appropriate for a Framework document.
The security and operational considerations need to be defined up-front
as will scope the work. All of these are listed as "some areas that must be considered"
but this is not a research group, it needs to be much more focused for a working group.

The charter describes a target of a common infrastructure and  protocol. It gives no
indication that the work needs to take into consideration the work already done or the
expectations of how it will work with the current applications and solutions.

And no explanation of why at this time a single solution is viewed as possible or why
a single solution is the correct answer for a diversity of use cases.

[Ballot comment]
I'm seeing offers of text changes from proponents. I'd Defer this one, but that only allows two weeks for the conversation to stabilized. So, Abstain.

FWIW, I balloted Yes to send the charter to the community for comments, and was hoping to ballot Yes for approval, but since I don't know what text I'm balloting on, that's the best I can offer.

I look forward to continued progress (because the discussion is certainly continuing).

[Ballot comment]
I'm seeing offers of text changes from proponents. This charter isn't stable enough for me to do more than Abstain.

FWIW, I balloted Yes to send the charter to the community for comments, and was hoping to ballot Yes for approval, but since I don't know what text I'm balloting on, that's the best I can offer.

I look forward to continued progress (because the discussion is certainly continuing).

[Ballot block]
I do not think this group is ready to be chartered at this time given the significant objections from the community.

There seem to be two key problems with the work as proposed:

(1) The work is insufficiently motivated. The claims about the need for the mapping system and the identity management system envisioned here do not appear to be backed up by those who have developed and deployed ID/LOC separation protocols. Nor do there seem to be compelling arguments that the framework that this proposed WG would produce would be the motivator for further interoperable deployments.

(2) The work proposed here seems as if it would have a substantial intrinsic impact on user privacy if widely deployed. In cases like these, I don't believe it's sufficient to say that the WG will analyze the situation and propose mitigations; the work proposal itself needs to explain how the design of the infrastructure envisioned is going to mitigate what seem like obvious attacks on privacy that the proposed designs open up.

I think further discussions of this work (in private, on the list, at a bar in Singapore, or at a potential future BoF) would need to resolve both of the above issues in order to address concerns raised by the community.

[Ballot block]
I do not think this group is ready to be chartered at this time given the significant objections from the community.

There seem to be two key problems with the work as proposed:

(1) The work is insufficiently motivated. The claims about the need for the mapping system and the identity management system envisioned here do not appear to be backed up by those who have developed and deployed ID/LOC separation protocols. Nor do there seem to be compelling arguments that the framework that this proposed WG would produce would be the motivator for further deployment.

(2) The work proposed here seems as if it would have a substantial intrinsic impact on user privacy if widely deployed. In cases like these, I don't believe it's sufficient to say that the WG will analyze the situation and propose mitigations; the work proposal itself needs to explain how the design of the infrastructure envisioned is going to mitigate what seem like obvious attacks on privacy that the proposed designs open up.

I think further discussions of this work (in private, on the list, at a bar in Singapore, or at a potential future BoF) would need to resolve both of the above issues in order to address concerns raised by the community.

[Ballot block]
I agree with Kathleen's block.

In addition, based on the discussion on the IETF list, I do not believe there is consensus to charter this WG.

[Ballot block]
I think there should be another BoF to discuss the privacy aspects and let the community have a chance to voice opinions and fully hash this out.  I suspect we'll see appeals (rightfully so) if that does not happen.

[Ballot block]
I'd like to see an explicit mention of security in the charter text itself in terms of how the metadata will be protected or that it will be protected in some way.  While the threats draft is helpful, the WG should be bound to consider security and provide it with this identifier/locator service.

[Ballot comment]
No objection to this charter, but it needs some update before publication.

- I've reviewing the IDEAS BoF meeting minutes and part of the video.
First session, first slide 1: Motivation
"what operators want: operational and deployment simplicity"
Since the goal is to write a framework, I expect the operational and deployment aspects to be covered.
Note: these days, if a feature can't be automated, it doesn't exist. So think about those day one.
I would like to see a sentence about this in the charter. For ex, in the bullet list.
    - Operational and deployment considerations

- The IESG has been having numerous discussions on what a framework (or an architecture) is. No consensus
To avoid this trouble, avoid "Some of the areas that should be considered when developing the framework include:", and make it a "must" statement. Something such as: the framework must at least include the following points.

- I have no idea what flexibility means in "Flexibility and extensibility considerations". And extensibility of?

- I like this sentence: "These documents will not be published as RFCs"

- On one side you mention:

    Some of the areas that should be considered when developing the framework
    include:

    ...

    - Requirements for identifier/locator mapping resolution and mapping update
    (e.g. discovery, pub/sub, multi-homing, ...)

And on the other side:

    These documents will not be published as RFCs, but will be maintained in a
    draft form or on a collaborative Working Group wiki to support the efforts of
    the Working Group and help new comers:

    ...
    - Requirements for identifier/locator mapping and resolution

So do you want to cover requirements in this framework? I don't think so
OLD:

- Requirements for identifier/locator mapping resolution and mapping update
(e.g. discovery, pub/sub, multi-homing, ...)

NEW:
- Description of identifier/locator mapping resolution and mapping update
(e.g. discovery, pub/sub, multi-homing, ...)



Editorial
- Alignment issue

    - Problem statement
    - Use cases
    - Requirements for identifier/locator mapping and resolution
    - Requirements for identity authentication and authorization service (for
    GRIDS). - Applications of the architecture for use cases - Threat model document

-  "The IDEAS WG will closely collaborate with LISP and HIP WGs. The WG will also collaborate with other WG as needed."
First sentence. Collaborate on what? Which objectives?
Second sentence. Sure, so what does it add to the charter

[Ballot comment]
The privacy text in this charter seems pretty week. We're spending a lot of effort right now to deal with the privacy impacts of our existing protocol that maps text names to IP addresses (DNS), so we don't want to recapitulate that one layer down. I think it needs to say something about how a major part of the framework is defining the privacy requirements and how to meet them. I'm not going to push "block" for external review, but I do expect to raise this issue at chartering time.

[Ballot comment]
There's a continuity issue between deliverable (2) and the paragraph about not publishing as RFCs. I suggest reversing the order between that paragraph and the list of sub-items under (2)

[Ballot comment]
I'm not a Spencer "but", but I'm voting a Yes only as the scope is initially
for a framework document only.

Yes, there is a lot of interest in the industry
in this "problem" so it will be good for IETF to evaluate it.
But, the use cases are very diverse and it is not clear if a common
approach will be achievable.

The group needs to closely coordinate with LISP as LISP is already considering
similar use cases and LISP has a long history with this "problem".

[Ballot comment]
If only "Yes, but ..." was a position I could select ...

I'm really glad to see this going forward - enough to ballot "Yes".

This looks like a framework that could be used in a number of use cases, and my "Yes, but ..." is that it's not clear to me, how much analysis of ID/Loc separation security implications that some folks downstream are going to have to do, when using this framework.

I'm remembering an exchange with a document editor on the last telechat that could be summarized as "we didn't do the work on general security implications of X, so each usage of X has to do that work itself, rather than pointing to previous work". OK, if that's where we are, but IDEAS hasn't already done the same thing (yet).

I'm looking at deliverables like "Requirements for identity authentication and authorization service (for GRIDS)" and "Threat model document", so I know there's SOMEthing in there, but I don't know what else might be required, if someone wanted to think about the general security implications of GRIDS, and I note that those deliverables are listed as living drafts or wiki entries, which doesn't sound like anything GRIDS framework usages would be able to point to, when they need to look at security implications.

Is a look at general security implications, in a form that specific framework usages can point to, on the table for IDEAS?

(It doesn't have to be, for me to ballot Yes, but I did have to ask, right?)