Subject: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00

From: Andrew Newton <[email-masked]>
Date: Tue, 23 Jan 2007 21:17:18 -0500

I've reviewed this draft.  Though it touches on non-ENUM points, it  
is very centered on ENUM.  In general, I would like to see a  
consideration for a more general query mechanism.  Yes, ENUM will be  
used by many entities, but redirect servers are also quite common.

Other comments in-line:
> 3.1.1 MUST be able to covey all of the information required for a DNS
> NAPTR resource record.

Even if we are strictly talking about ENUM, I question the need for  
this.  I would think the decisions for things like weight and  
priority on NAPTR records should not be left up to every entity  
provisioning into the registry.

> 3.1.2 MUST be able to convey all of the information required for a  
> DNS TXT
> resource record or any other record type that can conceivably be  
> used in
> DDDS.

So, we need to be able to provision a list of 256 octet length ASCII  
strings?  And since, conceivably, all DNS RR types can be used in  
DDDS, this is probably overkill as requirements go.  Or way to general.

> 3.1.5 MUST be able to express the publication rules for any registered
> data.
>
> o For data that differs upon the querier, such as the difference  
> between
> contacts and address-of-records in SIP.

This needs a better explanation.

> 3.1.6 MUST provide a means of tracking individual commands.
>
> o Each command has to be identifiable for later actions.  The  
> interface is
> not involved in tracking.

Does this mean that each transaction must have unique identifier?

> 3.1.7 SHOULD follow any applicable standards.
>
> o Public standards are hardier than internally developed solutions.

Ummm....

> 3.2.1 MUST use an encoding method that is robust, easy to design and
> troubleshoot, and is capable of supporting IRI's.
>
> o Easy to design and troubleshoot lends itself to mechanisms that  
> are text
> based as opposed to binary or hexadecimal.  Internationalization is
> important, for now at least host names might be in non-ASCII and  
> sooner
> or later other parts of a URI may also be.
>
> 3.2.2 SHOULD use a widely recognized standard.
>
> o Avoiding specifically developed mechanisms.

I have no problem with IRIs or dictating UTF-8 or XML.  None of us  
wants to spend time sifting through obscure technologies.  But  
wrapping this stuff in Mom & Apple Pie language just lends the  
requirement to very subjective interpretations.

> 4.2 SHOULD be able to populate a DNS zone transfer message, once the
> SOA RR is included.
>
> o A DNS AXFR or IXFR consist of a zone's SOA resource record,  
> followed by
> a list of resource records, and followed by another copy of the SOA
> resource record.  The SOA resource record has parameters best set  
> by the
> resolution system, so that is left to the client-side of this  
> interface.
>   But all of the rest of the zone transfer data ought to be able to be
> pulled from the formats exchanged over this interface.

If the intent is to replicate DNS AXFR or IXFR functionality, why not  
just use DNS?

> 5 EPP Protocol
>
> Breaking from requirements, there has been some consideration to EPP
> extensions for ENUM [RFC4114], and why it has not been adopted and why
> a requirements document is now being produced to cover what would
> seemingly be addressed by that solution.
>
> There are two reasons for EPP not being adopted.  One is that it isn't
> compatible with legacy participants.  The other reason is that it
> requires more implementation work.
>
> Legacy participants have an existing base of software development  
> built
> around SOAP/XML and WSDL, and are familiar with TLS.  Approaches to  
> ENUM
> registry interfaces that use these tools will blend more easily into
> the software products already in use to manage telephone numbers.
>
> The use of SOAP permits automatic generation of software to handle the
> client side of the exchange.  Domain name registries had to provide
> software tool kits to give to registrars to match this functionality.
> When a change is made to EPP, there will be a lot of software  
> exchanged.
>
> From experience with both EPP and SOAP based approaches to registry
> software, the SOAP based approach is much easier on the software
> engineering process.  The difference between the approaches is not  
> seen
> in a protocol analysis, but in an analysis of software engineering.

Stating that SOAP MUST be the mechanism of choice is wrong on a few  
levels.

First, I've run into far more XML-over-FTP or CSV-over-FTP  
provisioning systems than I have SOAP.  So, there are plenty of  
"legacy" systems that aren't SOAP based.

Second, SOAP was not the first protocol with implementations that did  
stub-method code generation.  It isn't magic, and saying "just use  
SOAP" does not mean provisioning systems will write themselves.   
There is always business logic and database interaction that must be  
managed.  In my experience, getting the XML on and off the wire is a  
very small part the software that must be written.

Also, as has been mentioned, there is some adoption of EPP.

-andy

_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/peppermint

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 24 Jan 2007 07:37:08 -0500

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]] 
> Sent: Tuesday, January 23, 2007 9:17 PM
> To: [email-masked]
> Subject: [PEPPERMINT] comments on 
> draft-lewis-peppermint-enum-ref-if-00

Disclaimer: I'm the author of EPP.  I have a bias.

[snip]

> Also, as has been mentioned, there is some adoption of EPP.

Indeed.  It's already being used in ENUM contexts.  The country code 1
user ENUM trial, for example, is using EPP.

I'd like to see any analysis of data wrapping protocol to include a
discussion of the issues associated with tunneling data re-using HTTP
and port 80.  The Security Considerations section would be a good place
to add text.  Let's discuss the software engineering and deployment
issues associated with adding HTTP and SOAP software layers, too.  It's
not as simple as "build on top of SOAP", folks.

This isn't as simple as "EPP vs. SOAP".  You could, for example, carry
the EPP data structures in SOAP instead of streaming them over TCP as
described in RFC 3734.  Not that I'm advocating that, but it illustrates
my point.

If this document is intended to describe interface requirements it
shouldn't focus on one protocol or the other.  It should describe the
*requirements* for the provisioning protocol interface.  We can debate
which tools best meet the requirements when we get there.

We should also consider the possibility of obsoleting and replacing RFC
4114 if it's proving to be inadequate.  Heck, it's only a *Proposed*
standard.  If implementation experience demonstrates that it's
inadequate, well, that's why we have a multi-stage standards track.

-Scott-

---

From: Edward Lewis <[email-masked]>
Date: Wed, 24 Jan 2007 10:50:28 -0500

At 21:17 -0500 1/23/07, Andrew Newton wrote:

>>  3.1.1 ...

>provisioning into the registry.

The important phrase is "be able to."  This does not mean "MUST 
convey" the values.

>>  3.1.2 ...

>DDDS, this is probably overkill as requirements go.  Or way to 

Answering the question, "no." As before "be able to convey" is not 
the same as "convey."

>>  o For data that differs upon the querier, such as the difference between

  RFC 3764. - Does that help?

>>  3.1.6 ...

Yeah, well that is what was in mind.  But if there is another way it 
should/could be considered

>>  o Public standards are hardier than internally developed solutions.

Yeah, I know this sounds too basic to be written.  But this came up 
once in a call.  One group I talked to questioned the logic of 
including all the NAPTR information when all that was needed was an 
TN to URI mapping.  Once I mentioned "we want to follow standards" 
they quickly came to agree.

>>  3.2.1 ...
>>  3.2.2 ...

I don't understand the comment, the latter part that is.

>If the intent is to replicate DNS AXFR or IXFR functionality, why 
>not just use DNS?

Not replicate, support and probably be optimized for.  The assumption 
for ENUM is that it be via DNS, but why limit options.

>>  5 EPP Protocol
>>
>Stating that SOAP MUST be the mechanism of choice is wrong on a few levels.

I don't think that was ever said, "MUST" that is.

>"legacy" systems that aren't SOAP based.

I suppose then that I ought to add a requirement for an interactive 
(as opposed to batch-oriented file transfers.)

>Second, SOAP was not the first protocol with implementations that 
>did stub-method code generation.  It isn't magic, and saying "just 
>use SOAP" does not mean provisioning systems will write themselves.  
>

Here's my pat answer and then I'll explain:

"If a WG is formed and this document is accepted as WG document, I 
would be happy (if appointed editor) to include the experiences and 
trade-off analysis of others."

What I mean is that these requirements are based on our experience 
(that being me and developers here) in working with EPP and SOAP. 
(We do have some FTP based systems too, but they weren't part of the 
process.)  I hope that the requirements per se do not say "MUST be 
SOAP" but from our practical experience,  SOAP appears to us to be 
the way to go.  'Course, that's not a requirement but a statement on 
the solution.

For the record, when we tested a SOAP based solution to this with 
other organizations, no one objected or expressed any concern about 
the choice.  This doesn't mean that SOAP is necessarily the best 
solution, but based on our experience it seems to be the best choice.

The requirements are not meant to be stacked towards any solution. 
But if they are, I will plead it is an accident of history.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

---

From: Andrew Newton <[email-masked]>
Date: Wed, 24 Jan 2007 11:11:43 -0500

On Jan 24, 2007, at 10:50 AM, Edward Lewis wrote:

> >So, we need to be able to provision a list of 256 octet length  
> ASCII strings?  And since, conceivably, all DNS RR types can be  
> used in DDDS, this is probably overkill as requirements go.  Or way  
> to general.

The difference between MUST implement and MUST deploy is not the  
issue.  Since your requirement is that the protocol MUST be able to  
convey anything "conceivable", there is a large amount of room for  
subjective differences of opinion.

>  RFC 3764. - Does that help?

Well, it narrows the scope.  But I still don't know what you mean by  
"publication rules."

> I don't understand the comment, the latter part that is.

I doubt anybody will offer a proposal claiming to meet the  
requirements of "flimsy", "difficult to implement", and "expensive to  
operate".  Language like "robust" and "scalable" are highly  
subjective.  If your intent is to narrow the solution space, but  
forthcoming about it.

> I don't think that was ever said, "MUST" that is.

MUST support the "legacy" systems that use SOAP is an implication  
that SOAP MUST be used.  This is my basis of objection.  I'm not  
advocating against SOAP, but if the requirement is that we have to  
use it because certain people don't want to change any of their code,  
that is the equivalent of a rubber stamp.

-andy

---

From: Edward Lewis <[email-masked]>
Date: Wed, 24 Jan 2007 11:51:40 -0500

The message quoting is all messed up here...so I'll resort to top posting.

I think it's pretty clear we want to convey what's in a NAPTR.  For 
what we don't have a NAPTR for, there's the (some would say 
"unenviable" but that is not for this argument) fallback of the TXT. 
 From our experience, that is all that we have seen the need to be 
able to convey.  Perhaps that is all we want to have, but I wasn't 
willing yet to say that we don't need to include, NS records.

Publication rules - I mean the ability to say "give this NAPTR set to 
carrier A", "give this to B", and give this back to me when I ask. 
Probably more simply put, "here's the NAPTR set for external 
consumption and here's the NAPTR set I want to see in my own DNS."

As far as a requirement for "expensive to operate" apparently you've 
not seen DNS. ;)  For the requirements that would lead to (or away 
from) XML, I can't think of any others.  We worked in XML because it 
was a standard and it wasn't ASN.1.  (Without trying to drag in too 
much context from other work, I'm thinking of the IRIS vs. LDAP bake 
off in the CRISP WG.  It took too long for the WG to finalize what 
seemed to be a snap of a decision.)

As far as "MUST support legacy systems that use SOAP" inferring "MUST 
use SOAP" I think the first observation is that if a revolutionary 
approach is developed that requires the tossing aside of all legacy 
systems then this work is in vain.  I think an explicit goal should 
be that this work builds on what's in place today. What's there now 
isn't the problem, the problem is what we want to interconnect them 
in a new way or ways.

I will admit that I unabashedly would support "just going with SOAP" 
towards a solution because it seems to be the easiest path to a 
solution.  If there is a better alternative, I'd be open to that, but 
if there is a ready and apparent one.  But I don't really want to 
spend a long time trying to find something better just because we 
should.

As I mentioned in the pat answer - other's experiences will be 
welcomed to the draft once the draft's "authorship" passes to a WG. 
As an individual submission it is based on our experiences.  As a WG 
document it would reflect a broader base of opinion.  Until then 
though, it would be foolhardy of me to try play down SOAP - that is 
until there is a compelling alternative.

I guess I am saying take this document for consideration as a 
reflection of our experiences.  I would be willing to accrete other 
lessons learned into the document.  What I don't want to do is write 
a document that is too general or too close to basic research.  If 
it's only the case that there might be something better than SOAP, 
how is that going to help a requirements document?

Section 5 is decidedly not "requirements" but a reflection on our 
experience in making the choice.  Maybe this gets dropped from a 
requirements document and finds it way into a document on 
implementation decisions - those kept and those discarded.

---

From: Andrew Newton <[email-masked]>
Date: Wed, 24 Jan 2007 12:07:37 -0500

On Jan 24, 2007, at 11:51 AM, Edward Lewis wrote:
> Publication rules - I mean the ability to say "give this NAPTR set  
> to carrier A", "give this to B", and give this back to me when I  
> ask. Probably more simply put, "here's the NAPTR set for external  

Though in the end we will have to flesh this out some more, I now  
understand what you are talking about.  It is a very good consideration.

> But I don't really want to spend a long time trying to find  
> something better just because we should.

Wow!

-andy

---

From: Edward Lewis <[email-masked]>
Date: Wed, 24 Jan 2007 15:16:56 -0500

>>something better just because we should.

I'm not sure if I need to clarify something...if we can cobble 
together a solution that meets the requirements from existing 
technologies we should do that.  I think trying to reinvent a 
technology (e.g., a means to convey bytes from one place to another) 
is waste of time unless the technology is truly in need of 
reinventing.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 24 Jan 2007 15:43:27 -0500

>Disclaimer: I'm the author of EPP.  I have a bias.

Disclaimer: I was one of the co-chairs of provreg.  "Shooting down" 
the product of your erstwhile WG isn't that delightful.  (I should 
add that Scott did all the work in the group.)

>not as simple as "build on top of SOAP", folks.

Before writing this draft, we had an internal meeting/discussion on 
this debate.

The reason our implementors eschewed EPP was the experience of having 
to build and maintain client tool kits for our EPP-using customers. 
That was a big factor to them.  (The implementors have experience in 
both EPP and SOAP.)  Also, the customers for the ENUM work had no 
real familiarity with EPP but did know SOAP.

In going over the discussion and knowing I would have to commit this 
to paper, my verbal summary was that the separating factors are 
factors not usually important in IETF discussions.  Our preference 
for SOAP over EPP was based on software engineering and software 
management workload.  Not just in-house but also what was either 
reported by or sensed from our client partners.

There isn't a major protocol-engineering detail that differentiates 
the two approaches, and sure, you could use XML schema extensions 
over EPP.  And if you look at the protocol aspects, you could more or 
less call it a draw.  Depending on your metrics, you could decide in 
favor of EPP.  (Or SOAP.)

As far as the tunneling over HTTP, etc., that was considered.  In 
this context, there was no fear of it and in fact a familiarity with 
it.  I don't think it would be productive to be too detailed on this 
item until we get a bit more steam on being a WG.

I'll leave it as is at this point.  The -00 of the document reflects 
our experience in getting our hands dirty on this.  Once we go "WG" 
our experience is just one opinion to cover.  For the time being, we 
can only truthfully document from our own experience.

>described in RFC 3734.  Not that I'm advocating that, but it illustrates

And I wanted this to be the next point after my response.  The draft 
picks on the EPP vs. SOAP angle because that is the one "debate" we 
see looming, and it is one we obviously choose a side on when 
building our implementation and conducted our testing.

I am agreeing that is isn't that simple a choice.  It's just that it 
was this choice was worth documenting.  As predicted, there's a 
discussion already rising on this.

>which tools best meet the requirements when we get there.

The first line of section 5 should cue that in.  Up until section 5 
any bias is unintentional.  After that, we are talking about our 
experience and the one fairly significant design choice we made.

>inadequate, well, that's why we have a multi-stage standards track.

I don't think that there's any overt desire to make RFC 4114 sleep 
with the fishes.  For instance, there may be places where "legacy" 
favors EPP.  Perhaps if we go "WG" then a decision on what to do 
about RFC 4114's lack of adoption ought to be in the charter.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 25 Jan 2007 07:22:57 -0500

> From: Edward Lewis [mailto:[email-masked]] 
> Sent: Wednesday, January 24, 2007 3:43 PM
> To: Hollenbeck, Scott
> Cc: Andrew Newton; [email-masked]
> Subject: RE: [PEPPERMINT] comments on 

[snip]

One concrete suggestion, Ed: right now the draft reads like a
requirements document.  If you're trying to describe your own
implementation experience, you should change the title and text to
reflect that goal.  Taken in that context there's a lot of information
in the document that could help us avoid "has anyone tried?" questions.

-Scott-

---

From: Edward Lewis <[email-masked]>
Date: Thu, 25 Jan 2007 07:45:07 -0500

>in the document that could help us avoid "has anyone tried?" questions.

What I want to do is present a requirements document.   I'm saying 
that it is based on our experiences to help explain away why it may 
not be all encompassing, i.e., why it may not have requirements that 
others have stumbled across in their experience.

I don't really want to describe our experience, but base a 
requirements document on it for starters.  There's a sensitive issue 
in the IETF of people coming to a WG with an assembled solution and 
being perceived as asking for rubber stamp approval.  I think the 
document would get along better as being based on a broader set of 
experience than we have at an "individual -00" (i.e., just ours) but 
I had to start somewhere.

I think raising up "has anyone tried?" questions would be good.  I 
think that would help in vetting the final solution, for what ever 
value of $final is used.

Referring to my pat answer...if this work gets a WG and the 
requirements document I've submitted gets adopted, it will no longer 
be merely a reflection of just our experience.  Until then though, I 
want to ground it only in the reality of our experience as opposed to 
supplementing our experience with hypothetical issues.

I should add that our implementation probably fails to meet at least 
one of the requirements.  I picked one requirement up from reading 
mail exchanged after we were in the testing phase for what we have.

If there is other experience to draw from, great.  We just haven't 
gone seeking other opinions because our project goal was more of 
"solving a need" we see at hand than "creating a standard."  In the 
sense that "creating a standard" for the exercise of "creating a 
standard" is more or less a waste of time, I think that the "need" 
has to precede the "standard."

BTW - when I flip between "we" and "I" here I am differentiating 
between me as the author of the document and we as in the team of 
developers doing the work.