Re: [Int-area] WGLC on draft-ietf-intarea-provisioning-domains-05

2019-07-08 Thread Ted Lemon 
On Jun 18, 2019, at 6:39 PM, Wassim Haddad  wrote:
> This email starts an Int-Area WG Last Call on the latest version of 
> draft-ietf-intarea-provisioning-domains (“Discovering Provisioning Domain 
> Names and Data"):
> 
> https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-05.txt
> 
> Please respond to this email to support the document and/or send comments by 
> 2019-07-05.
> 
> Please indicate if you are personally aware of any IPR that applies to 
> https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-xx and
> if so, has this IPR been disclosed in compliance with IETF IPR rules?

Sorry for the late response to this.   I think this is important work, and I am 
in favor of publication.   I do have comments, of course.  It’s been long 
enough since I looked at this document that my cache is blown, so some of my 
comments may already have been addressed—if so, just let me know—there’s no 
need to reiterate those discussions.

First, the abstract is three paragraphs.   That’s too long, and furthermore, I 
don’t think it states the problem in a way that would be helpful to someone 
reading abstracts to decide whether to read the rest of the document.   I would 
suggest something like this:

RFC 7556 describes the problem of multiple provisioning domains (PvDs): that a 
host may be connected to two or more networks at the same time, where those 
networks are operated by non-cooperating entities.  RFC 7556 provides a 
contextual framework through which hosts can sensibly operate in such 
environments.

This memo provides a mechanism to implement this framework. Network operators 
can use a Router Advertisement option to announce a PvD label; hosts can 
compare labels acquired on different network interfaces to differentiate 
between PvDs.  These options can directly carry some information about PvDs; an 
additional mechanism is provided for obtaining further PvD information using 
HTTP over TLS.

The introduction says this:

>For example, if Alice has a mobile phone provider and a
>broadband provider in her home, her devices and her applications
>should be capable of seamlessly transitioning from one to the other
>and be able to use her Wi-Fi to access local resources or use the
>more suitable link on a per-application base.

But this isn’t correct, is it?  What the MPvD architecture does is to allow the 
host to seamlessly use both interfaces at the same time, not to make seamless 
transitions between them.

>Similarly, the same PvD ID could be used
>on different interfaces of a host in order to inform that those PvDs
>ultimately provide identical services.


You might say “that those PvDs provide compatible services.”

>This document also introduces a way for hosts to retrieve optional
>and additional information related to a specific PvD by means of an
>HTTP over TLS query using an URI derived from the PvD ID.

This can be read two ways.   I think you mean to say “optional additional 
information,” not “optional information and additional information,” which is 
also a valid way to read it.   I would suggest just deleting the “and” here.

>The
>retrieved JSON object contains additional information that would
>typically be considered unfit, or too large, to be directly included
>in the Router Advertisement, but might be considered useful to the
>applications, or even sometimes users, when choosing which PvD should
>be used.

What does it mean for information to be “unfit?”   I think it means either 
“there isn’t an RA option for it” or “it wouldn’t fit.”   So maybe just say 
that?

>R-flag  :   (1 bit) 'Router Advertisement' flag stating whether
>   the PvD Option is followed (right after padding to the next 64
>   bits boundary) by a Router Advertisement message header (See
>   section 4.2 of [RFC4861] 
> ).

Why are you padding to a 64-bit boundary?   I can’t remember if this was 
discussed previously—sorry if I’m treading old ground.

>A router MAY send RAs containing one PvD option, but MUST NOT include
>more than one PvD option in each RA.  In particular, the PvD option
>MUST NOT contain further PvD options.

You could delete “in particular” here—I think it’s more confusing than 
clarifying.

>In order to provide multiple different PvDs, a router MUST send
>multiple RAs.  Different explicit PvDs MAY be advertised with RAs
>using the same IPv6 source address; but different implicit PvDs,
>advertised by different RAs, MUST use different link-local addresses
>because these implicit PvDs are identified by the source addresses of
>the RAs.

If the router sends multiple RAs with the same header information, they are 
going to be seen as the same RA by a host that doesn’t implement PvD.  So I’m 
not convinced that this statement gets to the heart of what is being asked 
here.   I’m reading this as saying

[Int-area] WGLC on draft-ietf-intarea-provisioning-domains-05

2019-06-18 Thread Wassim Haddad 
Dear all,

This email starts an Int-Area WG Last Call on the latest version of 
draft-ietf-intarea-provisioning-domains (“Discovering Provisioning Domain Names 
and Data"):

https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-05.txt

Please respond to this email to support the document and/or send comments by 
2019-07-05.

Please indicate if you are personally aware of any IPR that applies to 
https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-xx and
if so, has this IPR been disclosed in compliance with IETF IPR rules?


Regards,

Juan & Wassim
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area