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

[Stephen Farrell <[e-mail]>]

Hi Ed,

I do like the "(dis)agree" column and that there's a nice
scattering of yes/no/maybe values:-)

I'm not sure whether a google doc is a good way to have the
discussion or not though, but it'll be interesting to see.

If the chairs figured it'd help to have a call/interim to
go over all of the wGLC comments including these I'd be
happy to participate

Cheers,
S

On 28/01/17 20:27, 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-hNv8F03QxhNzdW8aitOEOcVfoOmUM/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://tools.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<https://sslvpn.jhuapl.edu/html/,DanaInfo=tools.ietf.org,SSL+rfc2402>]
> and
> [RFC-2406<https://sslvpn.jhuapl.edu/html/,DanaInfo=tools.ietf.org,SSL+rfc2406>],
> respectively.
> 
> 
> 
> Best regards
> 
> Kapali
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________ dtn mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/dtn
>