Hi, KK,

The most recent state in the tracker for this document is [1]:

2013-07-14      04      Warren Kumari   IETF WG state changed to WG Consensus: 
Waiting for Write-Up from In WG Last Call

This is after a WGLC in Feb this year:

2013-02-18      02      Warren Kumari   IETF state changed to In WG Last Call 
from WG Document     

Do you have an update?

Thanks,

-- Carlos.
[1] 
https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-options-filtering/history/

On Jul 28, 2013, at 11:22 PM, KK <[email protected]> wrote:

> Hi Carlos,
> 
> I have the shepherd write-up almost ready to be shipped out. My plan is to do 
> it this week.
> 
> Thanks you for your patience.
> 
> Regards,
> KK
> 
> 
> On Sun, Jul 28, 2013 at 2:01 PM, Carlos Pignataro (cpignata) 
> <[email protected]> wrote:
> Warren,
> 
> On Jul 14, 2013, at 9:34 AM, Warren Kumari <[email protected]> wrote:
> 
> >
> > On Jul 9, 2013, at 11:58 AM, Carlos Pignataro (cpignata) 
> > <[email protected]> wrote:
> >
> >> WG,
> >>
> >> I just posted a new revision, intended to address all WGLC comments on 
> >> this document.
> >
> > <chair hat>
> >
> > Thank you.
> >
> > We have discussed this and judge there to be consensus to progress this.
> 
> Thanks. All the WGLC comments were resolved with revision -04 posted on July 
> 11th.
> 
> Do you have a target for when the doc will be sent to the IESG?
> 
> -- Carlos.
> 
> >
> > We would also like to apologize for how long it took to complete this WGLC, 
> > and thank the authors (and WG) for their patience. We have / will be making 
> > some changes to streamline things, and hopefully prevent long delays in the 
> > future.
> >
> >
> > W
> > </chair hat>
> >
> >>
> >> You can find it at 
> >> http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-03.
> >> You can also find diffs from the previous version at 
> >> http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ip-options-filtering-03
> >>
> >> This new revision incorporates resolution to all comments, especially from 
> >> Arturo and Merike, as well as the text below. It also incorporates a 
> >> number of editorial (typographical, grammar) fixes. Hopefully we have not 
> >> missed anything.
> >>
> >> Please review.
> >>
> >> Thanks!
> >>
> >> -- Carlos.
> >>
> >> On Jul 9, 2013, at 10:27 AM, RJ Atkinson <[email protected]> wrote:
> >>
> >>> All,
> >>>
> >>> Here is some candidate text to replace the indented text
> >>> in Sections 4.12.2 & 4.13.2, leveraging Merike's suggested
> >>> introduction, and restoring (with minor edits) the previous
> >>> language:
> >>>
> >>>     Some private IP networks consider IP router-based
> >>>     per-interface selective filtering of packets based
> >>>     on (a) the presence of an IPSO option (including BSO
> >>>     and ESO) and (b) based on the contents of that IPSO
> >>>     option to be important for operational security reasons.
> >>>     The recent IPv6 CALIPSO option specification discusses
> >>>     this in additional detail, albeit in an IPv6 context.
> >>>     [RFC5570]
> >>>
> >>>     Such private IP networks commonly are built using both
> >>>     commercial and open-source products - for hosts, guards,
> >>>     firewalls, switches, routers, etc.  Some commercial IP
> >>>     routers support this option, as do some IP routers which
> >>>     are built on top of Multi-Level Secure (MLS) operating
> >>>     systems (e.g. on top of Trusted Solaris [Solaris2008] or
> >>>     Security-Enhanced Linux [SELinux2008]).
> >>>
> >>>     For example, many Cisco routers that run Cisco IOS include
> >>>     support for selectively filtering packets that contain the
> >>>     IP Security Options (IPSO) with per-interface granularity.
> >>>     This capability has been present in many Cisco routers
> >>>     since the early 1990s [Cisco-IPSO-Cmds].  Some government
> >>>     sector products reportedly also support the IP Security
> >>>     Options (IPSO), for example CANEWARE [RFC4949].
> >>>
> >>>     Support for the IPSO Basic Security Option also is
> >>>     included in the "IPsec Configuration Policy Information
> >>>     Model" [RFC3585] and in the "IPsec Security Policy
> >>>     Database Configuration MIB" [RFC4807].  Section 4.6.1
> >>>     of the IP Security Domain of Interpretation [RFC2407]
> >>>     includes support for labeled IPsec security associations
> >>>     compatible with the IP Security Options.
> >>>
> >>> I'm greatly obliged to Merike for her suggested text,
> >>> which is included in the proposed revised text above,
> >>> and to Arturo for agreeing that an edited version of
> >>> the original text could be retained in this document.
> >>>
> >>>
> >>> Yours,
> >>>
> >>> Ran Atkinson
> >>>
> >>>
> >>> _______________________________________________
> >>> OPSEC mailing list
> >>> [email protected]
> >>> https://www.ietf.org/mailman/listinfo/opsec
> >>
> >> _______________________________________________
> >> OPSEC mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/opsec
> >>
> >
> > --
> > "Build a man a fire, and he'll be warm for a day. Set a man on fire, and 
> > he'll be warm for the rest of his life." -- Terry Pratchett
> >
> >
> > _______________________________________________
> > OPSEC mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/opsec
> 
> 
> _______________________________________________
> OPSEC mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/opsec
> 
> 
> _______________________________________________
> OPSEC mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/opsec

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec

Reply via email to