Murray Kucherawy has entered the following ballot position for
draft-ietf-ipsecme-yang-iptfs-09: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please ref
Murray Kucherawy has entered the following ballot position for
draft-ietf-ipsecme-iptfs-17: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
htt
Sorry for the top post.
The text below is not sufficient. 8084 gives guidance on how to specify a CB ,
but doesn’t itself specify a solution that can just be pointed to. This
document needs to define how, based on the guidance in 8084, a CB should be
implemented for this specific protocol.
--
Murray Kucherawy via Datatracker writes:
--
DISCUSS:
--
Section 7.1 creates an IANA registry with "Expert Review" rules. Of such a
registry, Section 4.5 of
Erik Kline writes:
>
>
>
> > I.e., either this document needs to formally update RFC 4303 by allowing
> any
> > number or another IP protocol number must be requested to the IANA.
>
> As I pointed out in my previous email that is not the case.
>
> The RFC4303 ESP has
Murray Kucherawy via Datatracker writes:
> --
> DISCUSS:
> --
>
> Section 7.1 creates an IANA registry with "Expert Review" rules. Of such a
> registry, Section
Lars Eggert writes:
Sorry for the top post.
The text below is not sufficient. 8084 gives guidance on how to specify a CB ,
but doesn’t itself specify a solution that can just be pointed to. This
document needs to define how, based on the guidance in 8084, a CB should be
implemented for thi
Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-ipsecme-iptfs-17: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
Hi Zaheduzzaman,
[inline]
Zaheduzzaman Sarker via Datatracker writes:
Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-ipsecme-iptfs-17: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines.
John Scudder has entered the following ballot position for
draft-ietf-ipsecme-iptfs-17: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
ht
Warren Kumari has entered the following ballot position for
draft-ietf-ipsecme-iptfs-17: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https:
On Thu, Aug 25, 2022 at 2:24 AM Tero Kivinen wrote:
> Murray Kucherawy via Datatracker writes:
> > --
> > DISCUSS:
> > --
> >
> > Section 7.1 creates an IANA reg
Murray Kucherawy has entered the following ballot position for
draft-ietf-ipsecme-iptfs-17: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions WG of
the IETF.
Title : IP-TFS: Aggregation and Fragmentation Mode for ESP
and its Use for IP Traffic Flow Security
John Scudder via Datatracker writes:
--
COMMENT:
--
Nit:
I just happened to notice this bit in the Intro:
"While directly
obscuring the data with encrypt
On Aug 25, 2022, at 00:52, Erik Kline wrote:
> I think this document needs to request a protocol number from IANA.
Erik, the WG had this debate at length two+ years ago.
I feel that the WG, through our AD, asked the IESG and the IntArea and
Transport Area this specific question in a number
Indeed, they was the conclusion of the transport area at the time. I would also
prefer we could stick with that better solution, but more importantly I don’t
want this document stopped by a DISCUSS on either side of this argument.
Paul
Sent using a virtual keyboard on a phone
> On Aug 25, 2022
I'm not sure we've landed on a good solution with the ECN text. Two weeks
ago I pushed Christian to do something more sophisticated with ECN, but
realized that this is such a complicated subject that I wrote a draft
(which, to my knowledge, no one has read):
https://datatracker.ietf.org/doc/draft
Martin Duke writes:
I'm not sure we've landed on a good solution with the ECN text. Two
weeks ago I pushed Christian to do something more sophisticated with
ECN, but realized that this is such a complicated subject that I
wrote a draft (which, to my knowledge, no one has read):
https://datat
If it were me, I might add "unless all inner packets have the same
marking", but I won't die on that hill.
On Thu, Aug 25, 2022 at 10:57 AM Christian Hopps wrote:
>
> Martin Duke writes:
>
> > I'm not sure we've landed on a good solution with the ECN text. Two
> > weeks ago I pushed Christian
As we were directed by both INT ADs at this point, and had no object by the
other ADs during the telechat call, I've treated this as a "take our money"
moment and have requested early allocation of an IP protocol code point to move
things forward.
If in the (distant?) future INT needs to take b
Murray S. Kucherawy writes:
> This posture worries me. I've no doubt that you're doing a fine job as the DE
> for the registries for which you're responsible, probably because you were
> around during IPSec's development. But what about your successor(s)? Will
> they have all of the context, bac
Tero Kivinen wrote:
> Murray S. Kucherawy writes:
>> This posture worries me. I've no doubt that you're doing a fine job
>> as the DE for the registries for which you're responsible, probably
>> because you were around during IPSec's development. But what about
>> your succe
Hi,
On 2022-8-25, at 20:29, Christian Hopps wrote:
>
> [[RFC3168]] and [[RFC4301]], updated by [[RFC6040]] defines behaviors for
> marking
> the outer ECN field value based on the ECN field of the inner packet.
> As AGGFRAG mode may have multiple inner packets present in a single
> outer pa
Hi,
On 2022-8-25, at 12:49, Christian Hopps wrote:
> One example of a simple slow-trip circuit breaker (CB) an
> implementation may provide would utilize 2 values, the amount
> of persistent loss rate required to trip the CB and the
> required length of time this persistent loss rate must be
25 matches
Mail list logo
