[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ad-vpn-problem
From: Vishwas Manral <vishwas.ietf () gmail ! com>
Date: 2013-01-29 19:47:11
Message-ID: CAOyVPHSykFG=c_C8QNJUr_ZQdfUzx+iiXm1uWh+egHA-GLj=nA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi Sean,
I realized I missed this email. I will work on this draft this week and
next.
Thanks,
Vishwas
On Wed, Jan 9, 2013 at 6:17 AM, Sean Turner <turners@ieca.com> wrote:
> These are pretty much just nits. Please address Tero's comments as well.
>
> 1. We charter WGs and I'm going to go with the thought that it will
> succeed ;)
>
> a: r/is chartered to/will
>
> 2. s1.1: Hub definition.
>
> Verb choice:
>
> r/there is no devices/there are no devices
>
> 3. s1.1.: Spoke definition:
>
> Extra the:
>
> r/in the a star/in a star
>
> Need some ses:
>
> r/it encrypt data coming from cleartext device
> /it encrypts data coming from cleartext devices
>
> 4. s2: Use administrative domain in s1 but organization here. Is
> consistency needed?
>
> Not sure what you'd think about this, but what do you think about not
> using lowercase 2119 words in any of the s2 subsections? Reviewers should
> be able to piece together that this is the use case section and not the
> requirements section and therefore there shouldn't be any 2119 language
> here - but they don't always. To be clear, I'm not hard over on this.
>
> r/must use/need
> r/must/need to
> r/should/ought to
>
> 5. s2.1:
>
> Can you remove direct from "direct, point-to-point"? Isn't direct in the
> definition?
>
> Shouldn't "hub and spoke topology" be "star topology"? "hub and spoke
> topology" isn't defined in s1.1.
>
> I think you might need an "a" to match the previous sentence:
>
> r/Such use case/Such a use case ?
>
> r/expose them/expose themselves
>
> 6. s2.2:
>
> An extra the:
>
> r/for the voice and other/for voice and other
>
> Nit picking here but I think this is clearer:
>
> r/endpoints are administrated by separate management domains
> /endpoints are in different administrative domains
>
> Please expand: L3VPNs and GRE.
>
> 7. s4.1:
>
> r/firewall, NAT box/firewalls, NAT boxes
>
> 8. Req 10 + 11: Is the requirement driver under 11 for both 10 and 11? If
> so then it should be "These requirements". If you're going to do this
> couldn't you just group 10-14 as they're the same driver for all 5? Or, is
> the driver under 10 missing?
>
> 9 s5: To match the title:
>
> r/Problem state and requirement/problem statement and requirements
>
> 10. General: Sometimes it's ADVPN and other times it's AD VPN.
>
> 11. Allied and federated environments should be defined in the terminology
> section or at least introduced earlier in the draft.
>
> spt
> ______________________________**_________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/**listinfo/ipsec<https://www.ietf.org/mailman/listinfo/ipsec>
>
[Attachment #5 (text/html)]
<div>Hi Sean,</div><div> </div><div>I realized I missed this email. I will work on \
this draft this week and next.</div><div> \
</div><div>Thanks,</div><div>Vishwas<br></div><div class="gmail_quote">On Wed, Jan 9, \
2013 at 6:17 AM, Sean Turner <span dir="ltr"><<a href="mailto:turners@ieca.com" \
target="_blank">turners@ieca.com</a>></span> wrote:<br> <blockquote \
style="margin:0px 0px 0px \
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" \
class="gmail_quote">These are pretty much just nits. Please address Tero's \
comments as well.<br>
<br>
1. We charter WGs and I'm going to go with the thought that it will succeed \
;)<br> <br>
a: r/is chartered to/will<br>
<br>
2. s1.1: Hub definition.<br>
<br>
Verb choice:<br>
<br>
r/there is no devices/there are no devices<br>
<br>
3. s1.1.: Spoke definition:<br>
<br>
Extra the:<br>
<br>
r/in the a star/in a star<br>
<br>
Need some ses:<br>
<br>
r/it encrypt data coming from cleartext device<br>
/it encrypts data coming from cleartext devices<br>
<br>
4. s2: Use administrative domain in s1 but organization here. Is consistency \
needed?<br> <br>
Not sure what you'd think about this, but what do you think about not using \
lowercase 2119 words in any of the s2 subsections? Reviewers should be able to piece \
together that this is the use case section and not the requirements section and \
therefore there shouldn't be any 2119 language here - but they don't always. \
To be clear, I'm not hard over on this.<br>
<br>
r/must use/need<br>
r/must/need to<br>
r/should/ought to<br>
<br>
5. s2.1:<br>
<br>
Can you remove direct from "direct, point-to-point"? Isn't direct in \
the definition?<br> <br>
Shouldn't "hub and spoke topology" be "star topology"? \
"hub and spoke topology" isn't defined in s1.1.<br> <br>
I think you might need an "a" to match the previous sentence:<br>
<br>
r/Such use case/Such a use case ?<br>
<br>
r/expose them/expose themselves<br>
<br>
6. s2.2:<br>
<br>
An extra the:<br>
<br>
r/for the voice and other/for voice and other<br>
<br>
Nit picking here but I think this is clearer:<br>
<br>
r/endpoints are administrated by separate management domains<br>
/endpoints are in different administrative domains<br>
<br>
Please expand: L3VPNs and GRE.<br>
<br>
7. s4.1:<br>
<br>
r/firewall, NAT box/firewalls, NAT boxes<br>
<br>
8. Req 10 + 11: Is the requirement driver under 11 for both 10 and 11? If so then it \
should be "These requirements". If you're going to do this \
couldn't you just group 10-14 as they're the same driver for all 5? Or, is \
the driver under 10 missing?<br>
<br>
9 s5: To match the title:<br>
<br>
r/Problem state and requirement/problem statement and requirements<br>
<br>
10. General: Sometimes it's ADVPN and other times it's AD VPN.<br>
<br>
11. Allied and federated environments should be defined in the terminology section or \
at least introduced earlier in the draft.<br> <br>
spt<br>
______________________________<u></u>_________________<br>
IPsec mailing list<br>
<a href="mailto:IPsec@ietf.org" target="_blank">IPsec@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/ipsec" \
target="_blank">https://www.ietf.org/mailman/<u></u>listinfo/ipsec</a><br> \
</blockquote></div><br>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic