Hi,
I'm the shepherd for this draft. Thanks for the review. Some
follow-up inline.
On Fri, May 25, 2012 at 05:02:28PM -0400, Richard L. Barnes wrote:
>
> MAJOR:
>
> 4.1.
> It's not clear what the threat model is that this section is
> designed to address. If the zone operator is malicious,
Joe Touch wrote:
>> While your draft is rather harmful than useless, I'm fine
>> if the following point of the draft:
>>
>> >> Originating sources MAY set the IPv4 ID field of atomic
>> datagrams to any value.
>>
>> is changed to:
>>
>> >> Originating sources MUST set the IPv4 I
On 6/18/2012 3:30 AM, Alessandro Vesely wrote:
...
I noticed no disagreement between "method" and "mechanism", at the
time. In retrospect, those two terms might seem to allude to a
different depth of semantic explanations. Rereading that thread, I
find that the same ambiguity holds for algori
Hi, all,
There had been some talk of gathering experience at IETF meetings
running WIFI, and I'm not sure it went anywhere.
Although this might not be appropriate for an RFC, I'm hoping to gather
some relevant advice to put on a webpage that could be useful for future
IETF meetings, as well
On 6/18/2012 5:09 AM, Masataka Ohta wrote:
> Joe Touch wrote:
>
>>> draft-generic-v6ops-tunmtu-03.txt
>>>
>>> to fragment IPv6 packets by intermediate routers should be
>>> very interesting to you.
>>
>> It is aware of our IPv4-ID doc, and consistent with it.
>
> What?
I looked more closel
I will include a response to the rest of this in my summary of the last
call concerns. Regarding your last point:
On 6/18/2012 5:39 AM, Masataka Ohta wrote:
...
> PS
>
> While your draft is rather harmful than useless, I'm fine
> if the following point of the draft:
>
> >> Originating sourc
Some SDOs have gone to great lengths to specify this in detail. I am hoping
that we can avoid that path. Instead, as Ed already pointed out, each person
already provides an organizational affiliation when they register. Consistency
would be helpful.
Russ
On Jun 15, 2012, at 5:37 PM, Eric B
On 6/18/12 3:11 AM, Abdussalam Baryun wrote:
It is clear from the draft if you read it, that the decision *is not*
for the internet-community in two issues: a) editor decision of
accepting a propose change, b) editor decision of change-updates to
submit to IESG. The discussion in the I-D is menti
IMO the important issue in any definition is to include how the IETF
defines protocol,
this may be find in some RFCs :)
The IP is the main protocol, and all protocols in IETF are based on IP
and Internet.
AB
On 5 Jan 2012, todd glassey wrote
> On 1/5/2012 6:48 AM, Dave CROCKER wrote:
>>
>>
On 15/06/2012 20:18, Stephen Farrell wrote:
I think you said somewhere in this exchange, nih:
is intended to be used to confirm some information that you already
have. As such, I'm not seeing how it can be said to identify a resource.
I'm checking with others since I'm not entirely familiar wi
On 12/06/2012 15:56, Dave Crocker wrote:
On 6/12/2012 7:19 AM, Peter Saint-Andre wrote:
it's not the role of the designated expert to
act as a gatekeeper with respect to the technical merits of the
technologies that trigger registration requests. It might be good to
have a wider discussion abou
Stephen,
(Personal hat on)
I've followed elements of this exchange. I must confess that when I read
through the draft previously, I didn't really pay attention to the nih: parts.
I can see that there are distinct use-cases here, and I think you have
reasonable grounds for not wanting to com
It will be better to have both webpage and RFC
AB
On Fri, Jun 15, 2012 at 9:29 PM, The IESG wrote:
>
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Publishing the "Tao of the IETF" as a Web Page'
> as Informational RFC
>
> The IESG pl
Joe Touch wrote:>
It is a fair action by innocent providers.
>>
>>> It is a violation of standards. They may do it innocently, but it's
>>> still a violation.
>>
>> You misunderstand standardization processes.
>
> Standards remain so until revoked explicitly. Common use does
> not itself rev
Joe Touch wrote:
>> draft-generic-v6ops-tunmtu-03.txt
>>
>> to fragment IPv6 packets by intermediate routers should be
>> very interesting to you.
>
> It is aware of our IPv4-ID doc, and consistent with it.
What?
> When the DF is "ignored", the ID field is rewritten - i.e.,
If the ID fiel
Hello Stephen,
On 2012/06/17 22:33, Stephen Farrell wrote:
Martin,
On 06/17/2012 01:55 PM, "Martin J. Dürst" wrote:
This time, the situation was somewhat reversed: The expert approved the
registration, and this fact was then used as a claim that IETF Last Call
comments on the item registered
Hi Barry,
I think from your message, you agree that discussion is important in
the decision of updates, which I share. I agree to not repeat any
unnecessary info, but if contradictions appear to procedure, it then
needs a reference or repeat.
The problem is that the I-D does not mention in the
pu
On 5 Jan 2012, todd glassey wrote
> On 1/5/2012 6:48 AM, Dave CROCKER wrote:
>>
>> (One can quibble about the difference between algorithm and
>> program. An algorithm is a component of a program.
>
> The program is the code-based implementation of the alg?
>
>> The distinction is relevant
18 matches
Mail list logo
