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.
--
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
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
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
"Eric Vyncke (evyncke)" writes:
Chris,
The -17 version indeed addresses one of the 4 DISCUSS points, namely the hop
limit vs. TTL. Thank you for this.
I am far from being convinced that the added text about ICMP handling is rock
solid though. While I cannot point a specific issue, I fear
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
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
Christian Hopps writes:
[[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps
(trust ultimate) created at 2022-08-25T02:18:48-0400 using
RSA]]
"Eric Vyncke (evyncke)" writes:
Chris,
The -17 version indeed addresses one of the 4 DISCUSS points, namely the hop
limit
Murray Kucherawy via Datatracker writes:
--
DISCUSS:
--
Section 7.1 creates an IANA registry with "Expert Review" rules. Of such a
registry, Section 4.5
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
John Scudder via Datatracker writes:
--
COMMENT:
--
Nit:
I just happened to notice this bit in the Intro:
"While directly
obscuring the data with
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
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
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
On Thu, Aug 25, 2022 at 2:24 AM Tero Kivinen wrote:
> Murray Kucherawy via Datatracker writes:
> > --
> > DISCUSS:
> > --
> >
> > Section 7.1 creates an IANA
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,
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
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
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):
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):
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,
25 matches
Mail list logo
