Note: This ballot was opened for revision 00-00 and is now closed.
Ballot question: "Is this charter ready for external review?"Search Mailarchive
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".
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?)
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)
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
Thanks for adding in security requirements text, this is important.
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.