Re: [Gen-art] Gen-ART LC Review of draft-shiomoto-ccamp-switch-programming
Hi Ben, Thanks for reading. > Nits/editorial comments: > > -- section 1, paragraph 4: "...with relation to the programming..." > > ... in relation to... Yeah. RFC Editor note if Stewart is watching (although I'm guessing the RFC Editor might just fix this anyway). > -- 3.1, last paragraph: > > Note that the references say SHOULD rather than MUST. Using "must not" here, > even non-normatively, seems a bit overstated. Disagree. The caveat is that we are defining something different. We are looking at the case where we want to know that it is safe to start sending data. We are using the existence of some "SHOULD" statements in related RFCs that describe related behavior, to derive a "must" that covers when it is known to be safe. Cheers, Adrian ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC Review of draft-shiomoto-ccamp-switch-programming
On Aug 10, 2011, at 1:35 PM, Adrian Farrel wrote: > Disagree. The caveat is that we are defining something different. We are > looking > at the case where we want to know that it is safe to start sending data. We > are > using the existence of some "SHOULD" statements in related RFCs that describe > related behavior, to derive a "must" that covers when it is known to be safe. > Okay, that makes sense. It might not hurt (but would be okay not to) to add a sentence explaining that this doc suggests a stronger requirement than in the source RFCs in order to be sure of safety. Thanks! Ben. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-p2psip-base
Hi, for some reason, I did not receive the following Gen ART review: http://www.ietf.org/mail-archive/web/gen-art/current/msg06582.html I am forwarding it to the P2PSIP list in case the remainder of the intended recipients did not receive it either for some reason. Cheers, Gonzalo ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Review: Last Call
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-lisp-lig-04 Reviewer: Mary Barnes Review Date: 10 August 2011 IETF LC End Date: 12 August 2011 Summary: Ready with comments/nits Comments/minor issues: - Section 3, Routing Locator definition: The third sentence is a little difficult to parse. I would suggest to reword something like the following (based on my interpretation of what the text is intended to say): OLD: Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. NEW: Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet. Thus, the topology is defined by the connectivity of provider networks and RLOCs can be thought of as PA addresses. Also, you'll have to pardon my ignorance, but it's not obvious to me what PA stands for. I googled and I think it's Provider Aggregatable (and not Physical Address, which was my first reaction). I also found it expanded in draft-lisp-eid-block, which has a definition of RLOC that is mostly verbatim to this one, which makes me wonder why the terms need to be redefined in this document and isn't there the potential for the definitions to become inconsistent? - Section 3, Endpoint ID definition. It's not clear to me how SIP relates to LISP. I would think it's sufficient to use a DNS lookup as the example and delete the non-specific reference to a "SIP Exchange". Nits: - - Section 2, 2nd paragraph: "Map Resolvers" -> "Map-Resolvers" - Section 3, 2nd bullet: "Map Replier" -> "Map-Replier" - Section 3, last paragraph: "for lig initiating site" -> "for the lig initiating site" - Section 3, last paragraph: shouldn't "lig self" be "ligging yourself"? - Section 4.1, last paragraph before sample output for ligging yourself: "to originating site" -> "to the originating site" ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Telechat review of draft-ietf-tsvwg-rsvp-security-groupkeying-10.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-tsvwg-rsvp-security-groupkeying-10.txt Reviewer: Suresh Krishnan Review Date: 2011/08/09 IESG Telechat date: 2011/08/11 Summary: This draft is almost ready for publication as an Informational RFC. Thanks Suresh ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-v6ops-3gpp-eps-03
On 2011-08-09 at 18:28:05, jouni korhonen wrote: > > It's easy to infer from reading further that "layer-2" implies "pre- > IP", but that view is at odds with the view that other nodes > necessarily have: signaling is distinctly layer-7 to those that > operate upon it. Is this accurate? > > Right.. maybe we should also say that PDP context/EPS bearer setup > procedures equals setting up the layer-2 link and the address > configuration can be part of that signaling? I notice that you use the term "bearer" fairly frequently to refer to both PDP context/EPS bearer. When you say "layer-2 signaling" you could be more specific and say "bearer setup". > > the 'delegated prefix' [I-D.ietf-dhc-pd-exclude]. > > In its 3rd WGLC as we speak. Great. MISREF wont keep this in the editors queue long then. > The pd-exclude is referenced from 3GPP. How about: > >is not part of the 'delegated prefix'. IETF defined solution to >exclude a specific prefix from the 'delegated prefix' is used to >enable this [I-D.ietf-dhc-pd-exclude]. Or just: An option to exclude a prefix from delegation [I-Dpd-exclude] prevents this problem. > > There are more than the usual quantity of acronyms in this document. > Welcome to 3GPP ;) Oh, it's not my first time, trust me. Incidentally, I have to note that you've done an excellent job with the acronyms on the whole. I didn't encounter any that I didn't know, and only a few that weren't expanded. > Ok. I'll try fitting clouds there. BTW, nice clouds, and some of the nicest ASCII art that I've seen. > Do you have a suggestion for better wording? The statement is here > because it is possible and rather easy to deploy a network that allow > other types of handovers. However, in that case the outcome is > unpredictable, especially when the network has equipment from multiple > vendors.. and those cases and recovery procedures are not even > documented. I understand that it _is_ unfortunate. As you say, it has other more concrete consequences. In some cases, simply removing the "Unfortunately," would work. Maybe something like: OLD: Unfortunately, it is not mandatory to implement/deploy 3GPP standards based solution to selectively prohibit IPv6 roaming without also prohibiting other packet services (such as IPv4 roaming). However, there are few possibilities how this can be done in real deployments. The examples given below are either optional and/or vendor specific features to the 3GPP EPC: NEW: 3GPP does not specify a mechanism whereby IPv6 roaming is prohibited without also disabling IPv4 access and other packet services. The following options for disabling IPv6 access for roaming subscribers could be available in some network deployments: Don't feel beholden to me on this one though. Use your discretion. The first sentence didn't parse particularly well, but I'm not sure whether my suggestion retains the whole of your original intent. > - Jouni --Martin ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-v6ops-3gpp-eps-03
Hi, On Aug 11, 2011, at 4:27 AM, Thomson, Martin wrote: > On 2011-08-09 at 18:28:05, jouni korhonen wrote: >>> It's easy to infer from reading further that "layer-2" implies "pre- >> IP", but that view is at odds with the view that other nodes >> necessarily have: signaling is distinctly layer-7 to those that >> operate upon it. Is this accurate? >> >> Right.. maybe we should also say that PDP context/EPS bearer setup >> procedures equals setting up the layer-2 link and the address >> configuration can be part of that signaling? > > I notice that you use the term "bearer" fairly frequently to refer to both > PDP context/EPS bearer. When you say "layer-2 signaling" you could be more > specific and say "bearer setup". Right.. how about: specifications, but is not used in wide scale. The mobile host must always support address configuration as part of the bearer setup signaling, since DHCPv4 is optional for both mobile hosts and networks. > > >>> the 'delegated prefix' [I-D.ietf-dhc-pd-exclude]. >> >> In its 3rd WGLC as we speak. > > Great. MISREF wont keep this in the editors queue long then. > >> The pd-exclude is referenced from 3GPP. How about: >> >> is not part of the 'delegated prefix'. IETF defined solution to >> exclude a specific prefix from the 'delegated prefix' is used to >> enable this [I-D.ietf-dhc-pd-exclude]. > > Or just: > An option to exclude a prefix from delegation [I-Dpd-exclude] > prevents this problem. Ok. Sounds much better. >>> There are more than the usual quantity of acronyms in this document. >> Welcome to 3GPP ;) > > Oh, it's not my first time, trust me. Incidentally, I have to note that > you've done an excellent job with the acronyms on the whole. I didn't > encounter any that I didn't know, and only a few that weren't expanded. > >> Ok. I'll try fitting clouds there. > > BTW, nice clouds, and some of the nicest ASCII art that I've seen. > >> Do you have a suggestion for better wording? The statement is here >> because it is possible and rather easy to deploy a network that allow >> other types of handovers. However, in that case the outcome is >> unpredictable, especially when the network has equipment from multiple >> vendors.. and those cases and recovery procedures are not even >> documented. > > I understand that it _is_ unfortunate. As you say, it has other more > concrete consequences. In some cases, simply removing the "Unfortunately," > would work. Maybe something like: > > OLD: > Unfortunately, it is not mandatory to implement/deploy 3GPP standards > based solution to selectively prohibit IPv6 roaming without also > prohibiting other packet services (such as IPv4 roaming). However, > there are few possibilities how this can be done in real deployments. > The examples given below are either optional and/or vendor specific > features to the 3GPP EPC: > NEW: > 3GPP does not specify a mechanism whereby IPv6 roaming is prohibited without > also disabling IPv4 access and other packet services. The following options > for disabling IPv6 access for roaming subscribers could be available in some > network deployments: Thanks. I'll use this. > Don't feel beholden to me on this one though. Use your discretion. The > first sentence didn't parse particularly well, but I'm not sure whether my > suggestion retains the whole of your original intent. > >> - Jouni > > --Martin - JOuni > > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] : Review of draft-ietf-softwire-dslite-radius-ext-05
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-softwire-dslite-radius-ext-05 Reviewer: Wassim Haddad Review Date: August 10, 2011 IETF LC End Date: July 15, 2011 IESG Telechat date: August 11, 2011 Summary: This document is ready to be published as a proposed standard. Major issues: None Minor issues: None Regards, Wassim H. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
