Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04

[Alissa Cooper <[e-mail]>]

I guess it is a feature of area WGs that the sequence of work items is not
well-defined in advance of taking up any particular work items, nor are
those work items correlated to WG milestones (I looked at the intarea
milestones, dated to 2010, so I assume milestones are not used in this
group). In the case of the host ID work, this seems particularly
unfortunate. I don’t think it’s often the case that a draft outlining
solutions is published in advance of a draft that describes use cases for
those solutions, but that seems to be the direction of the effort here. And
I think this conflation of problems, what the draft in question calls “use
cases,” and solutions is creating a source of tension here.

The list of “use cases” in this draft mixes a number of different things:
some of them are architectures that introduce address sharing; some of them
are technologies that introduce address sharing; and others are
functions/services that may be hampered by the presence of address sharing.
The draft further contains a list of problems observed in the presence of
address sharing (in section 1). Under the assumption that it is useful to
publish a “use cases” draft for the purpose of determining whether a
particular future solution proposal addresses one or more use cases, I think
the confusion in this draft may actually make that task harder rather than
easier.

Another issue stems from the way the root problem is described in this
draft: "the issue of uniquely identifying a host.” This is a description of
a solution, not a problem. The kinds of problems that I see in the draft
are, e.g., “I want to apply a traffic management policy to a user and I
can’t,” “I want to know the source of an emergency call and I can’t figure
it out,” or “I want to blacklist one subscriber without affecting others.”
Not all of these problems will be served by “uniquely identifying a host,”
some of them already have domain- or application-specific solutions, and
some of them are not legitimate problems IMO (e.g., using source IP address
as an authenticator). Teasing the separate problems out from each other
would help to understand where a generic solution might be necessary and
where existing solutions are already sufficient.

To me what would be useful here would be a document that points out new
problems beyond those identified in RFC 6269 that arise in address-sharing
or tunneled architectures not already contemplated in that document. If
there aren’t new problems, then I’m not sure why 6269 is not considered a
sufficient description of the problem space. If there are new problems, then
between RFC 6269 and the new draft there would be a fairly comprehensive
list of them documented, and that could provide a foundation for figuring
out how to solve some or all of them, whether some of them have existing
solutions, and how potential new solutions relate to embedding a unique host
identifier at the network or transport layer.

Alissa


> From: Int-area [mailto:[e-mail]] On Behalf Of Suresh Krishnan
> Sent: Thursday, June 05, 2014 9:51 AM
> To: Internet Area
> Subject: [Int-area] Call for adoption of
> draft-boucadair-intarea-host-identifier-scenarios-04
>  
> Hi all,
>    This draft was originally intended to be published as an AD sponsored
> submission from the OPS area, but the authors have expressed their interest to
> continue this work in the intarea wg given that RFC6269 and RFC6967 originated
> here. The draft has been updated to address the issues brought up during
> earlier discussions on the wg mailing list and the latest version of the draft
> is available at
>  
> 
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-0>
4
>  
> This call is being initiated to determine whether there is WG consensus
> towards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as an
> intarea WG draft. Please state whether or not you're in favor of the adoption
> by replying to this email. If you are not in favor, please also state your
> objections in your response. This adoption call will complete on 2014-06-19.
>  
> Regards
> Suresh & Juan Carlos
>