Subject: [e2md] Proposed charter finalized

From: Bernie Hoeneisen <[email-masked]>
Date: Sun, 21 Mar 2010 19:01:09 +0100 (CET)

Hi E2MD BoF participants,

I have finalized the proposed charter and uploaded it to the meeting
materials pages:

   https://datatracker.ietf.org/meeting/77/materials.html

alternatively you can download it form

   http://ucom.ch/ietf/e2md-bof/e2md-proposed-charter.txt

I have consolidated the charter by structuring it in more logical way,
rearranging sections and paragraphes, removing redundant (doubled) text 
and using terms more consistently.

These changes are generally editorial, i.e. I did not add or remove any
relevant content since the last version.

We are still open for feedback, preferrably _before_ the BoF rather than 
only during the BoF, as our BoF time is very limited.

cheers,
  Bernie

--

http://ucom.ch/
Tech Consulting for Internet Standardization

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 22 Mar 2010 14:59:46 -0400

A few questions and comments about draft-hoeneisen-e164-to-metadata-02:

0) This is a very nice document.
1) I don't recall seeing anything in the E2M draft about specifying E2M service names that are identical to E2U service names.  I know that, technically speaking, this is not an issue due to the fact that the E2M name space it separte from E2U.  However, I think that in practice is may be good to explicitly state whether or not this is allowed.  I think it should not be allowed.  Iow, we should not be allowed to create an E2M service type called "SIP", or an E2M service called "EMAIL".  Allowing this would create confusion about what it means to create an E2M
2) Should some guidance be added into the draft that more tighly specified when an E2M service type should be created, as apposed to the two alternatives: (1) embedding URI parameters into E2U services, (2) creating a new E2U service?  At a minumum, this is something that needs to be on the top of the expert reviewer's checklist of considerations in evaluating the E2M service types.
3) Section 1.2 of the spec refers to the "send-n" service proposal, however, "send-n" is not mentioned in the charter (while cnam and unused are).  Is there a reson for this?
4) Section 3.1.  I'm not sure why the "Note:" is in there.  This seems to be just one boudary conditions that can be specified in the abnf.  And given that you show this one in the examples, the "Note:" here seems un-necessary and a bit arpitrary.
5) Section 3.3 4th Paragraph:  The statement "followed by one or more E2MD services which indicate the class of  functionality a given end point offers." seems perhaps to be a copy past from something that was talking about ENUM.  As I understand it, the data content of E2MD services do not necessarily speak to the class of functionality of the end points.  They speak to any number of characteristics of the end point (the calling name of the TN, whether or not the TN is in use, etc, etc).
6) Section 4.1.1 Paragraph 3:  The statement "The E2MD registration MAY be specified to be always empty" I think seems to imply something that is not intended, that an E2MD registration may be empty.  This could be reworded to indicate that the abnf specification for and E2MD service registration can be specificed to indicate that the replacement string is always empty.
7) Sectinon 6.4 - I'm not sure I understand what is meant by the sentance in this section.  What exactly needs further consideration?  Changes to sections 11.4 and 11.8 in the ENUM service Guide as a result of the introduction of E2M?

Thanks.
Ken

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Bernie Hoeneisen [[email-masked]]
Sent: Sunday, March 21, 2010 2:01 PM
To: E.164 To MetaData BOF discussion list
Subject: [e2md] Proposed charter finalized

cheers,
  Bernie

--

http://ucom.ch/

_______________________________________________
e2md mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/e2md

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 22 Mar 2010 15:07:21 -0400

Just to add in another $.02 of support on E2MD before the BOF ...

The Good
--------------
 1) E2MD utilizes the hierarchical structure of the DDDS model to segregate non-address URI information into its own name space hierarchy separate from the E2U namespace. This has a price, but it keep the purpose of the E2U namespace more succinct and its use cases clearer.
2) E2MD leverages technologies that exist and are in very wide use in the target industries (DNS, NAPTRs, ENUM Resolvers).
3) E2MD is relatively simple.
4) E2MD utilizes the nice meta-model of “create the high-level structure and leave the low-level structure up to the implementers” .  This is the DDDS model.
5) E2MD leverages the ENUM management structure and process for proposing, specifying, reviewing, discovering, and archiving E2M services.
6) E2MD has a clear technical and procedural adoptin path into existing systems that today query for and return TN data via ENUM.
7) E2MD charter explicitly leaves the data access controls, security needs and policies primarily up to the operators, service authors, and service reviewers, rather than attempting, in vain, to lock these in at a macro level up front.
8) E2MD inherently aids the solution to the problem of "too many larger resource reords in the response to an ENUM query".

There Are Always Tradeoffs to Live With (these are nits and carry overs from the nature of ENUM and DDDS)
--------------------------------------------------------------------------------------------------------------------------------------------------------
1) Questions will ocassionally arise about whether or not a given service should be an E2M service or an E2U service, or a URI parameter embedded within an E2U URI.  Unless I missed it, I do not recall seeing any guidance about these questions in the E2MD spec.  But at least having E2M give us another tool in our arsenal to address this.
2)  Not yet a standard way to do source identification in DNS.  But that can be solved going forward, outside of the direct E2MD problem space (H Kaplan has a draft).  And in the field this is already being done on a wide scale basis using non-standardized schemes, and nothing in the E2MD charter of spec makes this somehow "illegal".  And of courese there is always the "return a URL pointing to the data and apply AAA there" (but that approach can have trade-offs that can be too much to bear so will only be practical under some use cases).
3) Payload in DNS is relatively small.  But that seems to be ok (and probably even a good thing) for the use cases that we can think of.  And for those that it is not Ok, a URL can be returned that points the querier to the location of the data.
4) Only domain names can be lookup keys.  But since we are talking about TNs in the use cases envisioned so far, and we have ENUM's first well defined rule, that’s ok.  After all it is called _E_2M.  On the other hand, won't we want to, someday, lookup a calling name for [email-masked]?  But I think that's a problem for a different venue at a different time.  Or maybe there is work underway on that front that I am not aware of.  I've always thought it was interesting that we, a long time ago, decided to turn TNs into domain names, just to be able to look up information about them.  :-)  It's pretty funny when you think asbout it.  ENUM and DDDS of course did not have to be constructed that way.  But it was, and people wanted to use bind, and that's water long ago under the bridge.

No need to respond to these minor trade-offs.  I think they are just that, minor tradeoffs.

Ken

cheers,
  Bernie

--

http://ucom.ch/

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 22 Mar 2010 21:40:51 +0100 (CET)

Hi Ken

Thanks for your comments on the early draft of a possible e2md solution 
(draft-hoeneisen-e164-to-metadata-02).
We'll consider those once the E2MD WG is formed.

cheers,
  Bernie

On Mon, 22 Mar 2010, Cartwright, Kenneth wrote:

> 1) I don't recall seeing anything in the E2M draft about specifying E2M 
> service names that are identical to E2U service names.  I know that, 
> technically speaking, this is not an issue due to the fact that the E2M 
> name space it separte from E2U.  However, I think that in practice is 
> may be good to explicitly state whether or not this is allowed.  I think 
> it should not be allowed.  Iow, we should not be allowed to create an 
> E2M service type called "SIP", or an E2M service called "EMAIL". 
> Allowing this would create confusion about what it means to create an 
> E2M
>
> 2) Should some guidance be added into the draft that more tighly 
> specified when an E2M service type should be created, as apposed to the 
> two alternatives: (1) embedding URI parameters into E2U services, (2) 
> creating a new E2U service?  At a minumum, this is something that needs 
> to be on the top of the expert reviewer's checklist of considerations in 
> evaluating the E2M service types.
>
> 3) Section 1.2 of the spec refers to the "send-n" service proposal, 
> however, "send-n" is not mentioned in the charter (while cnam and unused 
> are).  Is there a reson for this?
>
> 4) Section 3.1.  I'm not sure why the "Note:" is in there.  This seems 
> to be just one boudary conditions that can be specified in the abnf. 
> And given that you show this one in the examples, the "Note:" here seems 
> un-necessary and a bit arpitrary.
>
> 5) Section 3.3 4th Paragraph:  The statement "followed by one or more 
> E2MD services which indicate the class of functionality a given end 
> point offers." seems perhaps to be a copy past from something that was 
> talking about ENUM.  As I understand it, the data content of E2MD 
> services do not necessarily speak to the class of functionality of the 
> end points.  They speak to any number of characteristics of the end 
> point (the calling name of the TN, whether or not the TN is in use, etc, 
> etc).
>
> 6) Section 4.1.1 Paragraph 3:  The statement "The E2MD registration MAY 
> be specified to be always empty" I think seems to imply something that 
> is not intended, that an E2MD registration may be empty.  This could be 
> reworded to indicate that the abnf specification for and E2MD service 
> registration can be specificed to indicate that the replacement string 
> is always empty.
>
> 7) Sectinon 6.4 - I'm not sure I understand what is meant by the 
> sentance in this section.  What exactly needs further consideration? 
> Changes to sections 11.4 and 11.8 in the ENUM service Guide as a result 
> of the introduction of E2M?
>
> Thanks.
> Ken
>