Re: [dtn] working group last call on draft-ietf-dtn-bpbis

[Rick Taylor <[e-mail]>]

On Mon, 2017-01-30 at 18:57 +0000, Templin, Fred L wrote:
> Hi Rick,
> 
> I agree that Ed's repository idea is a good one, and represents an
> organized
> approach at resolving the issues. Conversely, I would be concerned
> that an
> attempt to address all of the issues only through list posts would
> quickly spiral
> out of control given the large and involved set of WGLC comments.
> I agree that there should be some form of communication on the list
> that
> tracks with the work that is going on in the spreadsheet, but can we
> have
> some kind of agreement that the spreadsheet will be the place to
> capture
> the proposed resolutions?

Good point Fred, I was trying to suggest that I would like to see
discussion continue on the list, but with resolution/issue summaries
maintained in the spreadsheet for clarity.  As document shepherd, if
you want to use the spreadsheet as the 'ground-truth' for clarity, I'm
fine with that.

Rick

> 
> Thanks - Fred 
> 
> > 
> > -----Original Message-----
> > From: dtn [mailto:[e-mail]] On Behalf Of Rick Taylor
> > Sent: Monday, January 30, 2017 2:07 AM
> > To: I-Viswanathan, Kapaleeswaran <kapaleeswaran.viswanathan@boeing.
> > com>; [e-mail]; [e-mail]
> > Subject: Re: [dtn] working group last call on draft-ietf-dtn-bpbis
> > 
> > Thank you for this Ed.
> > 
> > I think it is a good repository for opinions on Stephen's comments,
> > and
> > it would be nice to extend it to include other peoples comments as
> > well.  But, I don't want to see the mailing list fall silent, and
> > would
> > ask that people explain their comments on the list, and then update
> > the
> > relevant row in the spreadsheet.
> > 
> > Can I also request some more comments and feedback on the latest
> > TCPCL
> > draft as well, please - it too is in Last Call.
> > 
> > Rick
> > 
> > On Sat, 2017-01-28 at 20:27 +0000, Birrane, Edward J. wrote:
> > > 
> > > I spent some time going through Stephen's comments trying to
> > > figure
> > > out a good way to address them. Rather than making dozens of
> > > individual posts on this mailing list, I put together a Google
> > > Doc
> > > spreadsheet as a way to try and capture thoughts on the items.
> > > 
> > > The document can be found and edited at:
> > > https://docs.google.com/spreadsheets/d/1NDY3WB6JGoM0I-hNv8F03QxhN
> > > zdW8
> > > aitOEOcVfoOmUM/edit?usp=sharing
> > > 
> > > I have 3 sheets (DISCUSS, Minor, Nits) and in each sheet a column
> > > where I tried to more concisely distill the comments and then
> > > provide
> > > my own thoughts.  I would encourage others to make their own
> > > columns
> > > in the same way. I would also encourage other rows (representing
> > > new
> > > comments) to be added as we have them.
> > > 
> > > Not trying to stop or alter discussion on the mailing list
> > > itself,
> > > but I thought it might be a good idea to also have a place to
> > > capture
> > > WG member opinions as we go.
> > > 
> > > Please feel free to use if helpful.
> > > 
> > > -Ed
> > > ---
> > > Edward J. Birrane, III, Ph.D.
> > > Embedded Applications Group Supervisor
> > > Space Exploration Sector
> > > Johns Hopkins Applied Physics Laboratory
> > > (W) 443-778-7423 / (F) 443-228-3839
> > > From: dtn <[e-mail]> on behalf of I-Viswanathan,
> > > Kapaleeswaran <[e-mail]>
> > > Sent: Wednesday, January 25, 2017 9:09 AM
> > > To: dtn
> > > Subject: Re: [dtn] working group last call on draft-ietf-dtn-
> > > bpbis
> > > 
> > > Hello:
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > SNIP(Fred -> Stephen -> Fred -> Stephen ->
> > > > > > > > > > > > Spencer)
> > > > I am still going through your comments, but one question that I
> > > have
> > > > 
> > > > on one of your points for now:
> > > > 
> > > >      "4) it's not ok to omit
> > > >       security mechanism definition, (making [BPSEC] normative
> > > > and
> > > >       waiting on that in the RFC editor queue would fix this,
> > > > and is
> > > >      IMO needed),
> > > > 
> > > > Wouldn't that create a circular dependency?
> > > > 
> > > > That's not a problem. The RFC editor handles document clusters
> > > > like that all the time.
> > > It is certainly the case (in my experience) that there's a
> > > history of
> > > IESG Evaluations taking longer/being less enjoyable for all
> > > parties
> > > when the protocol specification says "please see this other draft
> > > for
> > > security" and the working group says "we owe you one draft on
> > > security" ;-)
> > > <<<<<<<SNIP
> > > 
> > > I see two ways forward for Bundle Protocol specification.
> > > 1.      The IPv4 way: by providing generic data structures for
> > > security headers but without providing any detailed specification
> > > for
> > > these headers.
> > > a.      This approach will be useful to publish the
> > > transportation
> > > protocol (bundle protocol) specification first and then publish
> > > the
> > > security protocol (BPSec).
> > > 2.      The IPv6 way: by providing clearly specified headers
> > > (data
> > > structures) for interfacing transportation and security
> > > protocols.
> > > a.      This approach will require a complete specification of
> > > transportation and security protocols (in different documents)
> > > and
> > > releasing them at the same time.
> > > 
> > > I see this as a matter of style, because IPSec has been
> > > successfully
> > > deployed on IPv4 and IPv6.
> > > 
> > > But, purely from a documentation perspective, in its current
> > > specification style, Bundle Protocol appears to be a similar to
> > > IPv6.
> > > In the IPv4 document reference model, security specification
> > > (IPSec)
> > > refers to transportation specification (IPv4) but not the other
> > > way
> > > around. In the IPv6 document reference model, transportation
> > > (IPv6)
> > > and security (IPSec) specifications cross-reference each other.
> > > The
> > > document references in IP and IPSec documents are as follows.
> > > 1.      IPSec –refers to--> IPv4, IPv6
> > > 2.      IPv6 –refers to--> IPSec
> > > 3.      IPv4 –does not refer to--> IPSec
> > > 
> > > Bundle Protocol specifies security in extension blocks (https://t
> > > ools
> > > .ietf.org/html/draft-ietf-dtn-bpbis-06#section-4.3). IPv6
> > > specifies
> > > security in extension headers
> > > (https://tools.ietf.org/html/rfc2460#section-4.1). In IPv6, data
> > > confidentiality is specified as optional while authentication and
> > > data integrity are mandatory. IPv4 specifies security as
> > > something
> > > that is needed in “some simutations”
> > > (https://tools.ietf.org/html/rfc791#section-1.4) and minimizes
> > > any
> > > heavy-weight attention to the topic.
> > > 
> > > The following text from IPv6 could be interesting in this regard.
> > > 
> > > A full implementation of IPv6 includes implementation of the
> > >    following extension headers:
> > > 
> > >            Hop-by-Hop Options
> > >            Routing (Type 0)
> > >            Fragment
> > >            Destination Options
> > >            Authentication
> > >            Encapsulating Security Payload
> > > 
> > >    The first four are specified in this document; the last two
> > > are
> > >    specified in [RFC-2402] and [RFC-2406], respectively.
> > > 
> > > Best regards
> > > Kapali
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > dtn mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dtn
> > _______________________________________________
> > dtn mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dtn