Re: About RFC 3761bis-07

Hi Lawrence,

I have just had a look at this new revision. Thanks for addressing the
comments you received. I ran the ID nits tool on the draft and got the
following warnings:

  == Unused Reference: 'RFC3824' is defined on line 904, but no explicit
     reference was found in the text

  -- Obsolete informational reference (is this intentional?): RFC 2915
     (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404)

  -- Obsolete informational reference (is this intentional?): RFC 2916
     (Obsoleted by RFC 3761)

Additionally, Section 1.2, which is a subsection of the Introduction,
contains normative statements. I do not think introductions should
contain normative statements. We could convert Section 1.2 into a new
Section 2.

As next steps, the earliest we can get the whole IESG to review these
documents is in two weeks (the next IESG telechat). If you can revise
the draft real quick to address the nits above, that would be great.
Otherwise, I can add these comments to the ID tracker so that you
address them together with any additional comments from the IESG after
its IESG evaluation... it's your call. Let me know how you want to
process and I will take care of all the practicals.

Thanks,

Gonzalo


On 31/05/2010 2:27 PM, Gonzalo Camarillo wrote:
> Hi Lawrence,
> 
> thanks for putting this new revision together. I will give the WG a few
> days to have a look at it in case somebody has comments (I will of
> course also review this new version). After that, I will advance the
> three documents in parallel.
> 
> Thanks,
> 
> Gonzalo
> 
> 
> On 28/05/2010 2:13 PM, Lawrence Conroy wrote:
>> Hi Folks,
>>  To explain why we've issued a new version of 3761bis ...
>> Gonzalo provided a detailed review of the current (-6) draft.
>>
>> I do not believe that we have made any changes to the formal text.
>> These changes are intended to clear up some of the text
>> to make it easier to understand (and make it shorter).
>>
>> In response, we produced this new version. 
>> - (very slightly) tweaked the text of 1 (intro) to reflect what ENUM
>>   does (or doesn't do). i.e. changed the statements that "ENUM stores
>>   E.164 numbers in DNS" to "providing storage in DNS associated with
>>   E.164 numbers".
>>  - changed the Abstract to reflect that.
>>  - tweaked the text of 1.2 to try to meet Gonzalo's review comment on it
>>    and to make it a bit clearer what is required for non-E.164 numbers
>>  - moved the arcane text that was paragraph 2 of section 2's introduction
>>    into its own sub-section at the *end* of section 2 ("Collision Avoidance").
>>  - removed some text copied from RFC 5483 and replaced with an informative
>>    reference to that RFC.
>>
>>  We've also:
>>  - swapped around a couple of the items so the ORDER/PREF ones are all
>>    together,
>>  - have tried to answer Gonzalo's question "why is ORDER/PREF a problem?"
>>    by splitting out the proposed default value as a separate item and
>>    putting the (expanded) rest into an indented explanation following that,
>>  - tagged on two items to nail down that you MUST sort using ORDER and
>>    PREF, and you SHOULD NOT discard NAPTRs before they have been considered
>>    (unless you have already selected one).
>>  - corrected an bad typo in one of the items on ORDER/PREF (c/highest/lowest/)
>>
>>
>> If there are any outstanding comments, please mail to the list (or the authors).
>>
>> all the best,
>>   Lawrence
>>
>> _______________________________________________
>> enum mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/enum
>>
> 
> _______________________________________________
> enum mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/enum
>