SM,
On May 10, 2013, at 11:40 AM, SM wrote:
> In Section 2:
>
> "As such, allocations must be made in accordance with the operational
> needs of those running the networks that make use of these number
> resources and by taking into consideration pool limitations at the
> time of allocati
On May 10, 2013 11:51 AM, "SM" wrote:
>
> At 16:06 16-04-2013, The IESG wrote:
>>
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>> - 'The Internet Numbers Registry System'
>>as Informational RFC
>>
>> The IESG plans to make a decision in
On 11/05/2013 04:58, Stig Venaas wrote:
> On 5/10/2013 8:12 AM, Robert Sparks wrote:
>> Thanks Bing -
>>
>> The updates make the document better, and I appreciate the resolution of
>> referencing Tim's expired draft.
>
> So the solution is to not reference it? I see the name of the draft is
> ment
At 16:06 16-04-2013, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'The Internet Numbers Registry System'
as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this acti
Thanks Bing -
The updates make the document better, and I appreciate the resolution of
referencing Tim's expired draft.
I think you've addressed all my comments except for the one on section
5.1, but that's ok.
For completeness and ease on the ADs, here's an updated summary:
Document: draft-
I am guessing that the authors intended the addition of the text
emphasizing that the no-zone typedefs are derived general typedef
addresses the difference in the patterns.
Is there a YANG rule that says tat if typedef X is derived from typedef
Y then the string for X must match the pattern fo
I wanted to send an update, after having discussed this topic in the IESG
retreat that we just had here in Dublin. The overall plan is to start with
three specific changes listed below. Note that these are approaches that we
have discussed, and more detailed plans will be developed in the coming
Similarly, AFAICS the 'IESG time' includes IETF last call and the
inevitable delay caused by the quantized nature of IESG teleconferenes.
On the average, this will be somewhere around 28-30 days (2 or 4 weeks
in Last call according to document type plus an average of 1 week until
the earliest poss
Tom Petch
- Original Message -
From: "Dale R. Worley"
To: "t.p."
Cc:
Sent: Wednesday, May 08, 2013 8:37 PM
Subject: Re: Accessing tools from IETF pages
> > From: "t.p."
> >
> > I wanted to submit an I-D so I wanted to access the tools, as I have
> > done before, so I clicked on 'IET
