Re: [dhcwg] Last Call: draft-ietf-dhc-dhcpv6-bulk-leasequery (DHCPv6 Bulk Leasequery) to Proposed Standard
I was hoping some folks more intimate with SNMP and IETF management frameworks would chime in here, but I'll respond to clarify: On Tue, 21 Oct 2008, Marcus wrote: I am not an expert on SNMP, but the only way I could imagine that working, would be by using queries for MIBs which would look like this: get . As the query type can be a relay id, link-address or remote id, this would look a bit strange to me. I know and use SNMP mostly for querying specific, predefined counters or tables, not variable entries in the MIB tree. If I understand what you want to achieve, what you want is supported and indeed used by lots of MIB modules out there. This is useful and indeed we use it regularly with e.g. BGP and IP forwarding MIBs: $ snmpwalk -m IP-FORWARD-MIB -v 2c -c foo foo-rtr ip.ipForward.ipCidrRouteTable.ipCidrRouteEntry.ipCidrRouteProto.128.214.46 IP-FORWARD-MIB::ipCidrRouteProto.128.214.46.0.255.255.255.0.0.0.0.0.0 = INTEGER: netmgmt(3) IP-FORWARD-MIB::ipCidrRouteProto.128.214.46.254.255.255.255.255.0.0.0.0.0 = INTEGER: local(2) Also all implementations I know, use UDP not TCP for SNMP queries and replies. The DHCPv6 Bulk Leasquery proposal looks like a logical next step to me. An open-source SNMP implementation (net-snmp) is at least available. SNMP over TCP is defined in RFC3430. The systems under consideration already support TCP, just the TCP SNMP server part is missing; this should be trivial to implement if there is a need -- the lack of implementation efforts seems like an indication that UDP with retransmissions is usually "good enough". -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publication track for IBE documents (Was Second Last Call...)
So while I don't strongly object to these as informational RFCs, I do wonder why, if only one implementation is ever likely, we need any RFC at all. Its not like these docs describe something one couldn't easily figure out were there a need, given that the (elegant but not especially useful) crypto has been around for a while without finding any serious applications. Stephen. Tim Polk wrote: > Okay, I fat fingered this one. The S/MIME WG actually forwarded these > documents > with a recommendation that they be published as Informational. I > intended to respect > that consensus, but for one reason or another, they ended up in the > Tracker marked > for Standards track. > > It is clear that the WG got this one right, and I have changed the > intended status on > both documents to Informational. > > Thanks, > > Tim Polk > >> Harald wrote: >> >>> SM wrote: >>> >>> At 05:37 20-10-2008, The IESG wrote: This is a second last call for consideration of the following document from the S/MIME Mail Security WG (smime): - 'Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS) ' as a Proposed Standard Technical issues raised in IETF Last Call and IESG evaluation have been resolved. However, there have been substantive changes in the relevant IPR disclosures statements since the review process was initiated. Specifically, IPR disclosure statement #888, (see https://datatracker.ietf.org/ipr/888/) was replaced by PR disclosure statement #950, (see https://datatracker.ietf.org/ipr/950/) This Last Call is intended to confirm continued community support in light of the new IPR disclosure statement. Given the limited scope of this Last Call, an abbreviated time period has been selected. >>> >>> >>> Disclosure statement #888 mentions draft-martin-ibcs-08. That I-D was >>> published as RFC 5091 in December 2007. Disclosure #950 submitted in >>> May 2008 mentions new licensing terms for RFC 5091. That disclosure >>> mentions that draft-ietf-smime-bfibecms-10 is on the Informational >>> Track whereas it is on the Standards Track. >>> >>> As there seems to be only one implementation and very little public >>> discussion about the draft, I don't see why it should be on the >>> Standards Track. >>> >> >> >> With licensing terms like these, I would want to see a compelling >> argument for why the community needs it standardized to put it on the >> standards track. >> >> Let it be informational. >> >> Harald >> > > > > > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir Review of draft-stjohns-sipso-05
On Tue, 21 Oct 2008 16:57:12 -0400 Michael StJohns <[EMAIL PROTECTED]> wrote: ... > Classified documents have this thing called paragraph marking. Each > paragraph within a document is marked with the highest level of data > within the paragraph. A page is marked with the highest level of > data in any paragraph on that page. The overall document is marked > with and protected at the highest level of data within the document. Those who want the gory details should see http://www.fas.org/sgp/isoo/marking.pdf --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Publication track for IBE documents (Was Second Last Call...)
Okay, I fat fingered this one. The S/MIME WG actually forwarded these documents with a recommendation that they be published as Informational. I intended to respect that consensus, but for one reason or another, they ended up in the Tracker marked for Standards track. It is clear that the WG got this one right, and I have changed the intended status on both documents to Informational. Thanks, Tim Polk Harald wrote: SM wrote: At 05:37 20-10-2008, The IESG wrote: This is a second last call for consideration of the following document from the S/MIME Mail Security WG (smime): - 'Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS) ' as a Proposed Standard Technical issues raised in IETF Last Call and IESG evaluation have been resolved. However, there have been substantive changes in the relevant IPR disclosures statements since the review process was initiated. Specifically, IPR disclosure statement #888, (see https://datatracker.ietf.org/ipr/888/) was replaced by PR disclosure statement #950, (see https://datatracker.ietf.org/ipr/950/) This Last Call is intended to confirm continued community support in light of the new IPR disclosure statement. Given the limited scope of this Last Call, an abbreviated time period has been selected. Disclosure statement #888 mentions draft-martin-ibcs-08. That I-D was published as RFC 5091 in December 2007. Disclosure #950 submitted in May 2008 mentions new licensing terms for RFC 5091. That disclosure mentions that draft-ietf-smime-bfibecms-10 is on the Informational Track whereas it is on the Standards Track. As there seems to be only one implementation and very little public discussion about the draft, I don't see why it should be on the Standards Track. With licensing terms like these, I would want to see a compelling argument for why the community needs it standardized to put it on the standards track. Let it be informational. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir Review of draft-stjohns-sipso-05
At 09:44 PM 10/20/2008, Nicolas Williams wrote: >So if I understand correctly then this document would have an >implementation of, say, NFSv4[0] over TCP[1] send TCP packets for the >same TCP connection with different labels, *and* ensure that each packet >contains parts of no more than one (exactly one) NFSv4 RPC. Classified documents have this thing called paragraph marking. Each paragraph within a document is marked with the highest level of data within the paragraph. A page is marked with the highest level of data in any paragraph on that page. The overall document is marked with and protected at the highest level of data within the document. For your example, what would probably happen is that the NFS processes on both sides would create a connection at the highest level of data they expect to exchange. The NFS processes would be responsible for the labeling and segregation of data exchanged over that connection. E.g. the IP packets would ALL be labeled at the high level, even if some of them carried data at a level below. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir Review of draft-stjohns-sipso-05
Nico: So if I understand correctly then this document would have an implementation of, say, NFSv4[0] over TCP[1] send TCP packets for the same TCP connection with different labels, *and* ensure that each packet contains parts of no more than one (exactly one) NFSv4 RPC. I am aware of several multi-level secure implementations; none of them of make any attempt to do anything like this. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for Comments: On RFC Streams, Headers, and Boilerplates
On 2008-10-21 23:00, IAB Chair wrote: > Dear Colleagues, > > The IAB intends to publish the following document and invites any > comments you might have: > > "On RFC Streams, Headers, and Boilerplates" >draft-iab-streams-headers-boilerplates-03 [1] > I think this is ready to publish, except for one nit: This memo is not an Internet Standards Track specification, . s/,/;/ Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
I'm happy with this version. I think it updates the procedures in accordance with what we've learned since RFC3932. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Last Call: draft-ietf-dhc-dhcpv6-bulk-leasequery (DHCPv6 Bulk Leasequery) to Proposed Standard
On Tue, Oct 21, 2008 at 8:09 AM, Pekka Savola <[EMAIL PROTECTED]> wrote: > > On Mon, 20 Oct 2008, The IESG wrote: >> >> The IESG has received a request from the Dynamic Host Configuration WG >> (dhc) to consider the following document: >> >> - 'DHCPv6 Bulk Leasequery ' >> as a Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2008-11-03. Exceptionally, >> comments may be sent to [EMAIL PROTECTED] instead. In either case, please >> retain the beginning of the Subject line to allow automated sorting. >> >> The file can be obtained via >> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-bulk-leasequery-04.txt > > First there was DHC Leasequery (RFC4388), next DHCv6 Leasequery (RFC5007), > now we have DHCv6 Bulk Leasequery. And someone seems to be proposing DHCPv4 > bulk leasequery as well (draft-dtv-dhc-dhcpv4-bulk-leasequery). > > RFC4388 S4.2 described reasons why SNMP was deemed inappropriate. And if you > look at the reasoning there, some of these are not even valid anymore for > bulk leasequeries. I remain unconvinced. A far better solution would seem > to be define a smaller MIB just for querying leases so implementing it would > be trivial. Bulk leasequeries just underline the fact that SNMP and MIB data > models are being reinvented inside DHCP. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oykingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings I am not an expert on SNMP, but the only way I could imagine that working, would be by using queries for MIBs which would look like this: get . As the query type can be a relay id, link-address or remote id, this would look a bit strange to me. I know and use SNMP mostly for querying specific, predefined counters or tables, not variable entries in the MIB tree. Also all implementations I know, use UDP not TCP for SNMP queries and replies. The DHCPv6 Bulk Leasquery proposal looks like a logical next step to me. Marcus ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir Review of draft-stjohns-sipso-05
On thing that sticks out from the Introduction is this:
| However, some applications (e.g. distributed file systems),
| most often those not designed for use with Compartmented Mode
| Workstations or other Multi-Level Secure (MLS) computers,
| multiplex different transactions at different sensitivity levels
| and/or with different privileges over a single IP communications
| session (e.g. with the User Datagram Protocol).
So far so good, and certainly true. But then:
|In order to
| maintain data Sensitivity Labeling for such applications, in
| order to be able to implement routing and Mandatory Access
| Control decisions in routers and guards on a per-IP-packet basis,
| and for other reasons, there is a need to have a mechanism for
| explicitly labeling the sensitivity information for each IPv6
| packet.
So if I understand correctly then this document would have an
implementation of, say, NFSv4[0] over TCP[1] send TCP packets for the
same TCP connection with different labels, *and* ensure that each packet
contains parts of no more than one (exactly one) NFSv4 RPC.
Surely that would have an enormous impact on transport protocol
implementations!
And all so that middle boxes can make labelled routing decisions at
100Gbps wire speed. And these are not simple labels either.
And the middle boxes have to trust the end nodes to get the labelling
right.
Call me a skeptic. I don't see this flying.
In any case, wouldn't it be easier to just use IPsec with labelled SAs
(with no outer packet labelling) and let the middle boxes be label
agnostic? The end nodes still have to be trusted to get the labelling
right, but this way you free the middle boxes to do what they're good at
(routing) and use crypto to provide integrity and confidentiality
protection over any public networks.
And if you really must have outer packet labelling for middle boxes to
inspect, why not modify NFSv4 clients to use a TCP connection per-local
{user, label}? That'd certainly be a lot less troublesome than to
modify TCP to keep track of labels in a PCB's buffers/arrange to send
each sub-buffer in a separate packet or train of packets!
The changes proposed in this I-D are non-trivial, but there are clearly
far simpler alternatives.
Nico
[0] "e.g. distributed file systems"? NFSv4 qualifies.
[1] "multiplex different transactions... over a single IP communications
session (e.g. with the User Datagram Protocol)"? NFSv4 qualifies,
though the mandatory-to- implement transport for NFSv4 is TCP, not
UDP.
--
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Second Last Call: draft-ietf-smime-bfibecms (Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS)) to Proposed Standard
SM wrote: At 05:37 20-10-2008, The IESG wrote: This is a second last call for consideration of the following document from the S/MIME Mail Security WG (smime): - 'Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS) ' as a Proposed Standard Technical issues raised in IETF Last Call and IESG evaluation have been resolved. However, there have been substantive changes in the relevant IPR disclosures statements since the review process was initiated. Specifically, IPR disclosure statement #888, (see https://datatracker.ietf.org/ipr/888/) was replaced by PR disclosure statement #950, (see https://datatracker.ietf.org/ipr/950/) This Last Call is intended to confirm continued community support in light of the new IPR disclosure statement. Given the limited scope of this Last Call, an abbreviated time period has been selected. Disclosure statement #888 mentions draft-martin-ibcs-08. That I-D was published as RFC 5091 in December 2007. Disclosure #950 submitted in May 2008 mentions new licensing terms for RFC 5091. That disclosure mentions that draft-ietf-smime-bfibecms-10 is on the Informational Track whereas it is on the Standards Track. As there seems to be only one implementation and very little public discussion about the draft, I don't see why it should be on the Standards Track. With licensing terms like these, I would want to see a compelling argument for why the community needs it standardized to put it on the standards track. Let it be informational. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Openness for IETF-sponsored events
Ted, I was at the workshop representing the IAB, and I fully agree. While it was held in a good-sized auditorium, given the obvious interest in the topic, if everyone who wanted to attend or get on the agenda could, we would have needed a venue two or three times the size, more administrative support, and probably have needed to extend the workshop over at least two days. Given the size of the venue and the time available, I thought the way the workshop was conducted was extremely reasonable and fair. Cheers, Andy On Mon, Oct 20, 2008 at 1:05 PM, Ted Hardie <[EMAIL PROTECTED]> wrote: > Howdy, >There has been a lot of traffic in the past few days on > the question of whether the recent p2pi workshop was or was not > "open". Having sent a paper in to that workshop and participated > in an apps-area workshop, I'd like to weigh in on the question with > a fairly blunt reply: not fully. Whenever participation is gated > by a committee, it is not fully open. In the p2pi case, Jon and Cullen > acted as the gates; they swung wide (thanks, guys!), but you > had to either submit a position paper and have it approved by > them or get a waiver from them. To quote from their mail of > May 2nd: > >>We've had a number of inquiries from people interested in the workshop >>who are reluctant to submit a paper because they have no particular >>agenda to push in this space. We'd like to stress that position papers >>can shed light on any aspect of the problem or solution space, and we'd >>encourage anyone interested in making a technical contribution to >>ongoing work in this space at the IETF to submit a paper even if it >>serves only to further explain the problem, the requirements, or even >>the non-requirements associated with this work. >> >>That much said, if it is not appropriate for you to submit a position >>paper, please contact Cullen and Jon by May 9th to request a waiver. You >>can reach us at: [EMAIL PROTECTED], [EMAIL PROTECTED] > >That doesn't really matter, though. What matters is that > workshops like this are inputs into an open process (in this case, the BoF, in > the APPs workshop a list of potential work items). Anyone could > participate in the BoF or on the mailing list, and that is where we > have to make sure that the full openness remains. The discussion > now of the scope of the work in this proposed working group is a > critical part of that openness, as it is *the* time early in the process > when the IETF community as a whole considers a proposed > work plan and commits to it. ALTO is getting very good feedback, > and I hope that its Area Directors (and any potential chairs) are > listening to it; it's heartening to see the level of interest here when > so many WGs are chartered or re-chartered with no comments at all. > >I hope we can stop focusing on the openness of the workshop > as a primary topic in this conversation, and focus on keeping the > proposed working group open to input at this pivotal moment. Having > hummed for the creation of the WG at the BoF, I obviously support the > creation of a WG now. But I'm much, much happier getting the input > on charter details dealt with now, as a good discussion now can avoid > lots of later stress on the working group machinery. > >regards, >Ted Hardie > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
last call on draft-ietf-smime-bfibecms and draft-ietf-smime-ibearch
I am opposed to publishing these two documents on the standards track. The licensing information in the patent disclosure #950 makes it clear to me that free software implementations of the specifications, suitable for inclusion into free operating systems like Debian or gNewSense, are not permitted or possible. I am concerned that the license terms in the #888 patent disclosure, applying to an I-D that were published as RFC 5091, is significantly different to the terms in the #950 patent disclosure. The terms in #950 claims to apply to RFC 5091 as well. So was RFC 5091 published as an RFC without public knowledge of the patent situation? Considering #950, that appears to be the case. According to the datatracker, the #950 disclosure does not replace the #888 disclosure. Is this an error in the datatracker or the last call announcement? I believe it is important to understand which of these patent disclosures apply to which documents. Given that there appears to be little community interest in this standard, and no free software implementation of it appears possible, I believe the technology is not ready for the standards track. Finally, both these documents have normative references to an Informational document, i.e. RFC 5091. According to section 3 of RFC 3967 aka BCP97, it seems to me like this needs to be pointed out explicitly in the IETF last call. /Simon The IESG <[EMAIL PROTECTED]> writes: > This is a second last call for consideration of the following document > from the S/MIME Mail Security WG (smime): > > - 'Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption >Algorithms with the Cryptographic Message Syntax (CMS) ' > as a Proposed Standard > > Technical issues raised in IETF Last Call and IESG evaluation have been > resolved. However, there have been substantive changes in the relevant > IPR disclosures statements since the review process was initiated. > Specifically, IPR disclosure statement #888, >(see https://datatracker.ietf.org/ipr/888/) > was replaced by PR disclosure statement #950, >(see https://datatracker.ietf.org/ipr/950/) > > This Last Call is intended to confirm continued community support in > light of the new IPR disclosure statement. Given the limited scope of > this Last Call, an abbreviated time period has been selected. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2008-10-27. Exceptionally, > comments may be sent to [EMAIL PROTECTED] instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-10.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14992&rfc_flag=0 > > ___ > IETF-Announce mailing list > [EMAIL PROTECTED] > https://www.ietf.org/mailman/listinfo/ietf-announce The IESG <[EMAIL PROTECTED]> writes: > This is a second last call for consideration of the following document > from the S/MIME Mail Security WG (smime): > > - 'Identity-based Encryption Architecture and Supporting Data > Structures ' > as a Proposed Standard > > Technical issues raised in IETF Last Call and IESG evaluation have been > resolved. However, there have been substantive changes in the relevant > IPR disclosures statements since the review process was initiated. > Specifically, IPR disclosure statement #888, >(see https://datatracker.ietf.org/ipr/888/) > was replaced by PR disclosure statement #950, >(see https://datatracker.ietf.org/ipr/950/) > > This Last Call is intended to confirm continued community support in > light of the new IPR disclosure statement. Given the limited scope of > this Last Call, an abbreviated time period has been selected. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2008-10-27. Exceptionally, > comments may be sent to [EMAIL PROTECTED] instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-smime-ibearch-09.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14987&rfc_flag=0 > > ___ > IETF-Announce mailing list > [EMAIL PROTECTED] > https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Second Last Call: draft-ietf-smime-bfibecms (Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS)) to Proposed Standard
SM wrote: > As there seems to be only one implementation and very little public > discussion about the draft, I don't see why it should be on the > Standards Track. I don't see any pressing need to publish these at all, especially given the (unfriendly IMO) IPR disclosure and (what I believe) is the total lack of any demand for this technology. I'd be for not publishing them. Is this a case of I-Ds whose only real purpose is to stoke the marketing machine of the IPR-holders? If so, is that something we should ignore or push back against? Stephen. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
