Re: [Gen-art] [dnssd] Genart last call review of draft-ietf-dnssd-push-20

On Jul 4, 2019, at 4:09 PM, Tom Pusateri wrote: > I’m ok with removing resolver support for now to simplify this and tackle > resolvers in another document. But if there’s a good solution we’re all happy > with, we can fix it now. I think we’ve specified the parts of resolver support that we

Re: [Gen-art] [dnssd] Genart last call review of draft-ietf-dnssd-push-20

On Jul 4, 2019, at 3:32 PM, Tom Pusateri wrote: > I was trying to give the client enough information to determine WHY it > failed. If we determine this isn’t important, we can just let the client try > to figure it out but it will be more work for the client. The client is a computer program,

Re: [Gen-art] [dnssd] Genart last call review of draft-ietf-dnssd-push-20

On Jul 4, 2019, at 12:52 PM, Tom Pusateri wrote: > 1. The client should only send SUBSCRIBE to set up the DSO session if it has > gone through the discovery process and wants to talk to the authoritative > directly. If it wants to try to subscribe to push notifications through a > resolver,

Re: [Gen-art] Genart last call review of draft-ietf-dnssd-push-20

On Jul 3, 2019, at 10:45 AM, Robert Sparks wrote: > And I think that's a problem. > > What does a NOTIMP mean to the client? Most of the draft says "The server > doesn't implement DSO". It doesn't say "doesn't implement DSO for this > particular set of bits in this query". Section 6.2.2 says

Re: [Gen-art] Genart telechat review of draft-ietf-dnsop-session-signal-11

I got a bit wound up about not making the three changes that Joel called out in the updated session signal comment, and insisted on not making the changes because they didn't seem that important. I had a bit more private conversation with Joel about it, and after some reflection decided that

Re: [Gen-art] Genart telechat review of draft-ietf-dnsop-session-signal-11

rstand the space but do not live it at the detail of those > who authored it. > > Joel > > On 7/5/18 6:13 PM, Ted Lemon wrote: > >> Joel, it's immaterial whether the DSO engine responds in time or not. >> If it responds in time, the ack and the response will be combi

Re: [Gen-art] Genart telechat review of draft-ietf-dnsop-session-signal-11

Joel, it's immaterial whether the DSO engine responds in time or not. If it responds in time, the ack and the response will be combined; if it does not, then Nagle's algorithm will ensure that the ack goes out, and the response will go out in a later packet. Either outcome is fine. There is

Re: [Gen-art] [TLS] Genart last call review of draft-ietf-tls-tls13-24

On Mar 6, 2018, at 5:35 PM, Colm MacCárthaigh wrote: > There's a general conjecture that the more information that is provided to > attackers, the more easily they can leverage into a compromise. Personally I > believe that conjecture, and would actually prefer to see fewer

Re: [Gen-art] Genart last call review of draft-ietf-homenet-dot-12

some aspect of the DNS or the process of resolving domain names that would be affected by this special use allocation. Detailed explanations of these items can be found in , Section 5. On Wed, Aug 30, 2017 at 10:34 PM, Dale R. Worley <wor...@ariadne.com> wrote: > Ted L

Re: [Gen-art] Genart last call review of draft-ietf-homenet-dot-12

El Aug 24, 2017, a les 7:20 AM, Dale Worley va escriure: > 4. Domain Name Reservation Considerations > > 3. Name resolution APIs MUST send queries for such > names to a recursive DNS server that is configured to be > authoritative for the 'home.arpa.' zone

Re: [Gen-art] Gen-ART Telechat Call review of draft-ietf-dnsop-sutld-ps-07

On Jul 4, 2017, at 3:12 PM, Meral Shirazipour wrote: > Note: I noticed lots of changes since LC review-I assumed they were all in > answer of the LC reviews. > That’s correct. Thanks for the review!___ Gen-art

Re: [Gen-art] review of draft-ietf-mif-mpvd-arch-09.txt

On Feb 19, 2015, at 11:41 AM, Jari Arkko jari.ar...@piuha.net wrote: Well, the only important thing was that you’ve seen the comments and are planning to address those that make sense from your perspective. You should of course defer to your AD wrt when a document update should be posted. It

Re: [Gen-art] Gen-art telechat review of draft-ietf-savi-dhcp-32

On Feb 11, 2015, at 7:33 PM, Fred Baker f...@cisco.com wrote: s1: Did you answer the IESG point that MAC addresses are not sufficiently immutable? Actually s4.3.5 does say that MAC addresses are spoofable ... I didn’t. The issue is the same as with SVI-FCFS; the binding anchor is

Re: [Gen-art] Gen-art telechat review of draft-ietf-savi-dhcp-32

On Feb 10, 2015, at 7:45 PM, Fred Baker (fred) f...@cisco.com wrote: OK, the key question is then what I need to do in the document. The proposed change looked fine to me. ___ Gen-art mailing list Gen-art@ietf.org

Re: [Gen-art] Gen-art telechat review of draft-ietf-savi-dhcp-32

On Feb 10, 2015, at 3:58 PM, Fred Baker (fred) f...@cisco.com wrote: In concept, yes. DHCP, however, assumes that there is exactly one server. If there are multiple servers, they need to make themselves appear to be one. Not true. There can be an arbitrary number of DHCP servers.

Re: [Gen-art] Gen-ART LC Review of draft-ietf-dnssd-requirements-04

On Dec 23, 2014, at 4:24 PM, Kerry Lynn ker...@ieee.org wrote: I see your point. Taken together, REQ1 and REQ2 state there should be support for both non-configured and configured modes of operation in use case C. Hopefully it will be clear that these modes are mutually exclusive. Why

Re: [Gen-art] Gen-ART LC Review of draft-ietf-dnssd-requirements-04

On Dec 23, 2014, at 10:03 PM, Ted Lemon ted.le...@nominum.com wrote: Why not update the document to say so explicitly, and fix the idnits while you're at it? (Although you should probably hold off on the update until the last call has expired

Re: [Gen-art] Gen-ART LC Review of draft-ietf-dnssd-requirements-04

On Dec 22, 2014, at 6:40 PM, Ben Campbell b...@nostrum.com wrote: The acronym is a bit unfortunate. I suspect that much of the target audience already knows SSD as solid-state drive Of course, I don't really expect you to change it at this point in the process. :-) You are the first person

Re: [Gen-art] [Softwires] Gen-ART and OPS-Dir review of draft-ietf-softwire-lw4over6-12

On Nov 12, 2014, at 12:48 PM, Black, David david.bl...@emc.com wrote: Many thanks to the authors for dealing with the significant number of changes that resulted from this review. Thanks for the review and for this very helpful summary! ___ Gen-art

[Gen-art] Action items from David Harrington's opsdir comments

To Softwires: I've included comments below, but for the benefit of the authors and working group, the two actions items I see from this are: 1. map-dhcp should be a MUST, not a SHOULD. 2. the working group should decide whether DHCPv4-over-DHCPv6 is MTI in the B4, and whether pcp-port-set is

Re: [Gen-art] [Softwires] Gen-ART and OPS-Dir review of draft-ietf-softwire-lw4over6-10

On Oct 20, 2014, at 9:43 AM, Black, David david.bl...@emc.com wrote: Whether adding an informative mention of the YANG model rises to the level of required would be up to the OPS ADs. It may help implementers find the YANG model, which could be useful. The problem with this is that the

Re: [Gen-art] [Softwires] Gen-ART and OPS-Dir review of draft-ietf-softwire-lw4over6-10

On Oct 15, 2014, at 12:12 PM, ian.far...@telekom.de wrote: The consequence of this architecture is that the information maintained by the provisioning mechanism and the one maintained by the lwAFTR MUST be synchronized (See figure 2). The details of this synchronization depend on the exact

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08

On Oct 11, 2014, at 2:02 PM, Tomek Mrugalski tomasz.mrugal...@gmail.com wrote: A well defined protocol should leave certain aspects up to implementors. Yes, a well-defined protocol _can_ leave certain aspects up to implementors, or to administrator control. But obviously some aspects need to

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08

On Oct 10, 2014, at 4:36 AM, Ole Troan o...@cisco.com wrote: hmm. that's actually an interesting point. does it harm to allow this to be a hint to the server? if that how DHCP servers generally work? The problem is that the client might supply a wrong hint. I am not aware of any DHCP

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08

On Oct 10, 2014, at 3:03 PM, Tomek Mrugalski tomasz.mrugal...@gmail.com wrote: This option follows behavior described in Sections 17.1.1 and 18.1.1 of RFC3315. Clients can insert those options with specific values as hints for the server. Depending on the server configuration and

Re: [Gen-art] Gen-ART review of draft-ietf-softwire-map-t-05

On Oct 6, 2014, at 9:01 AM, Romascanu, Dan (Dan) droma...@avaya.com wrote: Is this a different type of IPv4-IPv6 translation than the one considered by the original charter out-of-scope? Did the scope of the WG change in time, but the charter was not updated? Some clarification is needed.

Re: [Gen-art] Gen-ART review of draft-ietf-softwire-map-t-05

On Oct 6, 2014, at 8:09 PM, Xing Li x...@cernet.edu.cn wrote: This is the decision of the WG and moves forward in Softwire Interim Meeting in Beijing, Sept, 2011. http://www.ietf.org/mail-archive/web/softwires/current/msg02631.html We may add some historical background in the next version.

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08

On Oct 2, 2014, at 10:46 PM, 包丛笑 congx...@cernet.edu.cn wrote: We may add a sentence states that “It is an invalid option, if received by server, discard.” Please do not add such a sentence. Rather, please add a sentence that says: This option has no meaning when sent from client to server.

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08

Hm. I am a bit puzzled. These are DHCP options. This document just says what the format of the options is. Do you really think the DHCP server implementor needs to understand that in order to follow this document? I see the MAP and lw4over6 documents as depending on this one, rather

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08

On Sep 28, 2014, at 9:19 PM, Ted Lemon ted.le...@nominum.com wrote: Do you really think the DHCP server implementor needs to understand that in order to follow this document? Er, by that here I was referring to the meaning of the MAP bits. ___ Gen

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08

On Sep 28, 2014, at 10:24 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I was thinking of the client side. I could be wrong though. It depends on how the client side is implemented, I guess: it could just be a DHCPv6 engine that is blind to the content of the options, which it

Re: [Gen-art] Gen-art telechat review of draft-ietf-savi-dhcp-29

Thanks for the careful review, Elwyn. The document is undergoing a new english language pass and some additional rework. I've pushed the document out to the next telechat because that work isn't done yet and I think addressing the points you've raised will make the document easier for the

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-dhc-dhcpv6-unknown-msg-06.txt

On Mar 27, 2014, at 8:25 AM, Suresh Krishnan suresh.krish...@ericsson.com wrote: (a) if the message is a Relay-forward message, or (b) if the relay agent recognizes the message type and is not the intended target, or (c) if the relay agent does not recognize the message type Let me know

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-dhc-dhcpv6-unknown-msg-06.txt

On Mar 25, 2014, at 5:20 PM, Suresh Krishnan suresh.krish...@ericsson.com wrote: * Section 4.1 (b) The following text is unclear. if the relay agent receives the message for which it is not the target according to the message type. The text that follows talks about new server-to-relay

Re: [Gen-art] review of draft-ietf-trill-oam-framework-03.txt

On Nov 25, 2013, at 9:25 AM, Francis Dupont francis.dup...@fdupont.fr wrote: PS: my spell checker insists about congruency (the correct term is congruence) and IMHO it is right... It is indeed. :) ___ Gen-art mailing list Gen-art@ietf.org

Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dhcpv6-solmaxrt-update-03

On Sep 13, 2013, at 5:51 PM, Ralph Droms (rdroms) rdr...@cisco.com wrote: I know either Bernie, Tomek or Ted has pointed out that the dhc WG is rechartering. Has rechartered, at this point. This work is on the charter. ___ Gen-art mailing list

Re: [Gen-art] [savi] Gen-ART review of draft-ietf-savi-threat-scope-06

On Mar 27, 2013, at 12:45 PM, Joel Halpern Direct jmh.dir...@joelhalpern.com wrote: Then it will be done. I will wait for the AD to decide what other changes are needed, and then will either make this change or include it in an RFC Editor note. Old: If the bridging topologies which

Re: [Gen-art] Gen-ART review of draft-ietf-savi-threat-scope-06

On Mar 25, 2013, at 9:04 PM, Black, David david.bl...@emc.com wrote: Summary: This draft is on the right track, but has open issues, described in the review. While I identified the same issue you did with switching systems that do link aggregation and other magic, I think that the document is

Re: [Gen-art] Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11

On Dec 21, 2012, at 7:48 AM, RAMAKRISHNADTV ramakrishna...@infosys.com wrote: As Ted mentioned, our draft only proposes a new sub-option for relay-agent option which was originally created as part of RFC3046. So, the security considerations for RFC3046 apply to our draft as well. RFC3046

Re: [Gen-art] Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11

On Dec 21, 2012, at 10:45 AM, Ben Campbell b...@nostrum.com wrote: As I responded separately to Ramakrishna, is the SHOULD use 4030 language a new requirement specific to this draft? Or is it just describing requirements in 3046 or elsewhere? I suppose the authors should really answer this,

Re: [Gen-art] Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03

On Feb 14, 2012, at 5:23 AM, Maglione Roberta wrote: Please let me know if you have additional comments. Thanks! I think you should change this text in the introduction: The mandatory authentication was originally motivated by a legitimate security concern whereby in some network

Re: [Gen-art] Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03

On Feb 13, 2012, at 4:06 PM, Ben Campbell wrote: Do I infer correctly from your comment that the security properties of the mechanism don't really matter? That is, if the attacker we care about can't eavesdrop in the first place, does this really need to be an HMAC? Hm, I thought about that a

Re: [Gen-art] Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03

[RM] The intention is to use this method only for environments with native security mechanisms, such as the Broadband Access network. You are right it is not clearly said in the document I can add the following sentence at the end of the introduction in order to clarify this point: This

Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dhcpv6-opt-netboot-08

On Apr 14, 2010, at 4:49 PM, Vijay K. Gurbani wrote: This draft represents an IPv6 address textually (c.f. Section 3.1). As such, does this textual representation has any bearing to what is being discussed in draft-ietf-6man-text-addr-representation-07 (see

Re: [Gen-art] GEN-Art review of draft-ietf-dhc-relay-id-suboption-07

On Oct 6, 2009, at 12:28 PM, Sean Turner wrote: Major #1 It's not clear to me whether both relay identifier types MUST be supported or whether implementations are free to pick which one(s) they support? If you add one of the following (or something similar) in Section 5 then my concern is

Re: [Gen-art] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

On Apr 19, 2009, at 7:46 AM, Hui Deng wrote: And you talked about Stuart Cheshire described a couple of IETFs ago, Could you help to point out the link? Sadly, I don't have it, but I suspect Stuart does, and I'm pretty sure he's reading this. The gist of what he was saying is that if you

Re: [Gen-art] [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00

On 2009/4/13 Ralph Droms rdr...@cisco.com wrote: For example, would a host process information received from a Starbucks network over its 802.11 interface differently from information received a home network over the 802.11 interface? It's even more fun than that. How do we reliably know

Re: [Gen-art] [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

On Apr 15, 2009, at 7:11 AM, Bernie Volz (volz) wrote: How realistic is that most RGs with multiple interface will connect to DIFFERENT service providers? And, in the case where they do, this likely means someone (the owner of the RG) has to make some decisions -- requiring appropriate

Re: [Gen-art] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

On Apr 15, 2009, at 2:12 PM, Bernie Volz (volz) wrote: My vote would be no change. But, I'd be OK if Ralph wanted to state it is TBD and outside the scope of this document and perhaps indicate that it is an issue whether the RG gets options to pass on from either the container option or from

Re: [Gen-art] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: Now, I admit I'm describing a hypothetical and abstract scenario. I don't have a specific example of a situation in which a host might make decisions - either in the stack or in an application or ??? - about outbound traffic based on knowledge of

Re: [Gen-art] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

How realistic is it anyway that an RG would get different *relevant* options on its different interfaces? This would seem to me to be an administrative error. Of course the broadcast address and subnet mask options might be different, but it doesn't make sense to send the RG, e.g.,