Subject: [Gen-art] Gen-ART review of draft-ietf-enum-enumservices-guide-20.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 16 Jun 2010 08:43:56 +0200

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft. For background on Gen-ART, please see the FAQ at 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq

Please resolve these comments along with any other comments you may receive.

Document: draft-ietf-enum-enumservices-guide-20.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 16-June-2010
IETF LC End Date:
IESG Telechat date: (if known)

Summary: The document is almost ready for publication as a BCP.

Major issues: none.

Minor issues:

- Section 6.5: The text reads:

    IANA will conduct an "Expert Review" ...

I guess a designated expert will conduct the review. At most (specially 
for non-RFC Specifications), IANA will make sure that an Expert Review 
has been done.

- Section 11.6.1 discusses the process of registering Enumservices 
through the publication of an RFC. I don't understand the purpose of the 
second paragraph, which chances the process to IANA. The text reads:

    IANA MUST only add Enumservices to the Registry, if the experts have
    approved the corresponding Enumservice Specification as to be
    published.  IANA SHOULD attempt to resolve possible conflicts arising
    from this together with the experts.  In case changes between the
    approved and the to be published version are substantial, IANA MAY
    reject the request after consulting the experts.

My problem is related to the process. If a document has gone through the 
RFC publication process, I expect that experts have inspected the 
document and approved the Specification prior to publication as an RFC, 
as part of a regular RFC process. This process may differ between 
standard track RFCs and individual submissions, but in any case, experts 
are involved in the RFC publication process, and the RFC will not be 
published if experts voice against the document. Or when do the authors 
expect that an Internet-Draft could be published without expert review?

So, I think that for RFCs, IANA does not need to do anything different 
from what they are doing today.

Nits/editorial comments: none

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Bernie Hoeneisen <[email-masked]>
Date: Wed, 16 Jun 2010 09:20:21 +0200 (CEST)

Hi Miguel

On Wed, 16 Jun 2010, Miguel A. Garcia wrote:

> I guess a designated expert will conduct the review. At most (specially for 
> non-RFC Specifications), IANA will make sure that an Expert Review has been 
> done.

We already decided to change this (after Alexey already reported this 
one).

> - Section 11.6.1 discusses the process of registering Enumservices through 
> the publication of an RFC. I don't understand the purpose of the second 
> paragraph, which chances the process to IANA. The text reads:
>
> My problem is related to the process. If a document has gone through the RFC 
> publication process, I expect that experts have inspected the document and 
> approved the Specification prior to publication as an RFC, as part of a 
> regular RFC process. This process may differ between standard track RFCs and 
> individual submissions, but in any case, experts are involved in the RFC 
> publication process, and the RFC will not be published if experts voice 
> against the document. Or when do the authors expect that an Internet-Draft 
> could be published without expert review?
>
> So, I think that for RFCs, IANA does not need to do anything different from 
> what they are doing today.

Before the document goes to the IETF process, the experts will review it. 
Afterwards, it is not guaranteed that the experts remain in the process. 
If there are no changes until the document arrives ar IANA, no problem. If 
there are changes, IANA needs somebody to have a look at the latest 
version.

We added this sentence to ensure the experts have a chance to verify 
possible changes are fine in any case.

Note: Not too long time ago, there was a case where major flaws got 
introduced as a result of the IESG processing. We noticed this during 
auth48 and it was rather painful to handle this case.

I hope this addresses you concerns.

cheers,
  Bernie

---

From: Bernie Hoeneisen <[email-masked]>
Date: Sun, 20 Jun 2010 15:33:18 +0200 (CEST)

Hi Miguel / Russ

I have added "(conditionally)" to mitigate the risk of confusion:

   In case changes between the (conditionally) approved and the
   to be published version are substantial, IANA MAY reject
   the request after consulting the experts.

Does this change together with the explanations I gave last week (see 
below) address your concerns?

cheers,
  Bernie

On Wed, 16 Jun 2010, Bernie Hoeneisen wrote:

>> RFC publication process, I expect that experts have inspected the document 
>> and approved the Specification prior to publication as an RFC, as part of a 
>> regular RFC process. This process may differ between standard track RFCs 
>> and individual submissions, but in any case, experts are involved in the 
>> RFC publication process, and the RFC will not be published if experts voice 
> Afterwards, it is not guaranteed that the experts remain in the process. If 
> there are no changes until the document arrives ar IANA, no problem. If there 
> are changes, IANA needs somebody to have a look at the latest version.
>
> We added this sentence to ensure the experts have a chance to verify possible 
> changes are fine in any case.
>
> introduced as a result of the IESG processing. We noticed this during auth48 
> and it was rather painful to handle this case.
>

--

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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 21 Jun 2010 08:00:58 +0200

Hi Bernie:

Your proposal does not solve my concern. My concern is very clear: you 
are changing the IANA process to make the get the green light from 
experts before editing a registry, even for a document that has gone 
through the regular RFC process.

This could hint that the RFC process is flawed, and that you need to 
change the IANA process to reinforce them. And I don't think IANA is 
going to change their way of working just for this RFC.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 21 Jun 2010 15:20:59 -0600

Hi Miguel,

I expressed exactly this concern in my DISCUSS on this I-D. During the
IESG telechat last Thursday, Michelle Cotton of the IANA explained that:

(1) there is agreement to try this approach for this registry
(2) the RFC Editor and the IANA are in agreement here
(3) proposed changes to RFC 5226 are on the way

Michelle will be following up on these matters (with Bernie) so that
they are clearly communicated to the IESG and all other relevant
parties. I'm holding my DISCUSS until that happens.

Peter

On 6/21/10 12:00 AM, Miguel A. Garcia wrote:
>>>> through
>>>> document
>>> auth48

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 22 Jun 2010 08:03:57 +0200

Hi Peter:

There are two aspects of this proposal:

a) Whether IANA accepts the change in the process to bring the experts 
prior to modifications
b) A sentiment that the RFC process, in particular the involvement of 
experts in the RFC process, is not enough.

While you mention that a) is being addressed, I am worried about b). Do 
we agree that the involvement of experts in the RFC process experts is 
not enough and needs to be amended by I-D? And if we agree on b), 
shouldn't be logical to change the RFC process rather than a workaround?

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Jun 2010 14:07:40 -0600

> experts in the RFC process, is not enough.

What do you mean by "not enough"? My understanding is that the IANA
wants to avoid late surprises that might modify registrations specified
in Internet-Drafts, and that they have collaborated with the RFC Editor
team to define improved processes for dealing with such problems

> shouldn't be logical to change the RFC process rather than a workaround?

It's not my place to define IANA and RFC Editor processes, so I shall
defer to our colleagues on those teams for clarification.

Peter

---

From: RFC Editor <[email-masked]>
Date: Thu, 24 Jun 2010 13:37:54 -0700

Greetings All,

Just an FYI that we are in discussion with Michelle regarding the
process that this doc defines.  We did discuss this during IETF 77,
but it appears that there are a few clarifications needed.

Thanks for making sure we're in the loop!
Sandy

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 25 Jun 2010 09:46:34 +0200

> team to define improved processes for dealing with such problems

Well, if the I-D is cooked in a working group, then experts are involved 
throughout the entire life of the I-D. If the I-D is an individual 
submission that was not carefully reviewed in a working group, experts 
come into the picture at a later stage, either through the review process 
or any of the various reviews that the I-D will suffer, including IETF 
LC, Gen-ART review, etc.

So, in any case, I believe the draft is well reviewed when it lands to 
IANA. I don't understand why IANA needs to change their process to bring 
more experts to review the draft. It gives me the impression that the I-D 
process does not suffer enough review and IANA can solve that problem.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 25 Jun 2010 10:12:40 +0200 (CEST)

Hi Miguel

On Fri, 25 Jun 2010, Miguel A. Garcia wrote:

> So, in any case, I believe the draft is well reviewed when it lands to IANA. 
> I don't understand why IANA needs to change their process to bring more 
> experts to review the draft. It gives me the impression that the I-D process 
> does not suffer enough review and IANA can solve that problem.

IANA are not meant to solve the problem, but to detect a _potential_ 
issue. The experts will then have to decide whether this is a problem 
or not.

As expressed earlier, we had a case when an Enumservice I-D (STD) was fine 
when it went into IESG processing, but it was heavily broken when it 
arrived at IANA and was still broken when it arrived to AUTH48 (where it 
was accidentally detected).
[Michelle / Alice, you remember this pain, don't you...?]

Other Enumservices got published as STD (!) in a buggy state (e.g. 
RFC3762).

[IMHO wherever people are working, mistakes might happen (everywhere and 
all the time); the more bodies involved, the higher the likelihood for 
mistakes. The question here is, whether mistakes get detected before it is 
too late.]

cheers,
  Bernie

---

From: Jason Livingood <[email-masked]>
Date: Fri, 25 Jun 2010 09:03:52 -0400

Miguel - To add to what Bernie already said, there actually won't be an ENUM
WG at some point rather soon.  So there will not in most cases be any WG
review per se, another reason why expert review is called for.

Jason

> process does not suffer enough review and IANA can solve that problem.

Regards,
Jason
 
Jason Livingood
Executive Director
Internet Systems Engineering
National Engineering & Technical Operations
Comcast Cable Communications
215-286-7813
[email-masked]

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 25 Jun 2010 10:30:31 -0400

Exactly ... this is precisely the reason why the procedure was designed. We
need to close the ENUM WG.

And in most cases IMHO these are relatively trivial technical registrations.
Personally as ENUM WG chair I would have preferred first come first serve
with only expert review and no RFC but this was the consensus of the wG.  

-----Original Message-----
From: Jason Livingood [mailto:[email-masked]] 
Sent: Friday, June 25, 2010 9:04 AM
To: Miguel A. Garcia; Peter Saint-Andre
Cc: Bernie Hoeneisen; General Area Review Team;
[email-masked];
[email-masked]; [email-masked]; Michelle Cotton; RFC Editor
Subject: Re: Gen-ART review of draft-ietf-enum-enumservices-guide-20.txt

Jason

Regards,
Jason
 
Jason Livingood
Executive Director

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 28 Jun 2010 10:22:17 +0200

Richard, Jason:

I understand that ENUM will eventually close. Any Internet-Draft (either 
an individual submission or coming from another IETF WG) will be reviewed 
by experts. In particular, the IANA considerations section can indicate 
that an Expert Review shall be conducted before populating the registry. 
The IESG shall appoint the Expert Review (not IANA), in this case.

So, I am not sure if my point was misunderstood or I am missing 
something. My point is that the regular process that makes an I-D become 
an RFC already includes the Expert Review. In particular, the draft 
requires a Designated Expert to conduct a review (this applies, I guess, 
also to non-WG I-Ds). So, if the IESG is already going to conduct an 
Expert Review as part of the regular process of the I-D, why does IANA 
need to conduct another (presumably different) expert review? The text in 
the draft gives the impression that the RFC process is useless, and the 
Expert Review mandated by the IESG is also useless, because there is a 
need for yet another Expert Review controlled by IANA.

Let me reproduce once more the text I am in conflict, which is listed in 
Section 11.6.1:

I can understand the first sentence, if it is framed within the RFC 
process (which is not at the moment). But I cannot understand the second 
sentence: it is not the goal of IANA to resolve any conflict; the IESG 
should do it as part of the RFC process/Expert review, but not IANA. And 
I cannot vouch for the second sentence either, which is once more, IMHO, 
part of the IESG duties.

/Miguel

On 25/06/2010 16:30, Richard Shockey wrote:
> On 6/25/10 3:46 AM, "Miguel A. Garcia"<[email-masked]>  wrote:
>
> National Engineering&  Technical Operations

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Jason Livingood <[email-masked]>
Date: Mon, 28 Jun 2010 08:07:38 -0400

Miguel - 

My view (and this is my personal opinion here), is that the expert review by
IANA is needed for a few reasons.  First, in our lengthy consensus-building
process on this I-D, and in consultation with IANA, they (IANA) requested it
and indicated it as desirable.  In addition, the path to an ENUM service
registration will NOT always come via the I-D/RFC process.  So we need to
ensure there is an expert review process no matter what path the
registration follows to arrive at IANA. Lastly, having a standard set of
experts to review registrations ensures a level of continuity and context on
ENUM service registrations that may not exist when an individual expert or
experts are selected for pre-RFC review (which again, will not apply in all
situations).

Hope this helps.

Jason

Regards,
Jason
 
Jason Livingood
Executive Director