[homenet] Spencer Dawkins' No Objection on draft-ietf-homenet-dot-12: (with COMMENT)

[Spencer Dawkins]

Spencer Dawkins has entered the following ballot position for
draft-ietf-homenet-dot-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/



--
COMMENT:
--

Thank you folks for putting this together. I know it's important.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Brian Haberman's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Spencer Dawkins at IETF]

For what it's worth ...

On Thu, Nov 19, 2015 at 7:59 AM, Brian Haberman 
wrote:

> Brian Haberman has entered the following ballot position for
> draft-ietf-homenet-hncp-09: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/
>
>
>
> --
> DISCUSS:
> --
>
> * I see where HNCP describes how interfaces are classified as internal or
> external, but how does an interface get classified as leaf, guest, or
> ad-hoc?  Is this some manual configuration step that needs to be
> described somewhere?
>
> * The definition of Leaf in 5.1 is unclear.  It says "Such an interface
> uses the Internal category with the exception that HNCP traffic MUST NOT
> be sent on the interface, and all such traffic received on the interface
> MUST be ignored." The "all such traffic" is ambiguous. Based on the
> definition of the Guest category, I think "all such traffic" is really
> "all HNCP traffic".
>
> * The text in section 5.3 seems incomplete. It gives a 4-step algorithm
> for border discovery, but says "if the node does not implement
> auto-detection, only the first step is required." If auto detection is
> not supported and a fixed category is not configured, what happens? Does
> this mean that if auto detection is not supported manual configuration of
> the border is required?
>
> * Section 7 describes how to handle non-HNCP capable routers. However, I
> don't see any operational issues described that could arise from having a
> non-HNCP capable router connecting two clouds of HNCP within the same
> home network. It seems like that could cause problems with a bunch of the
> services provided by HNCP.
>
>
> --
> COMMENT:
> --
>
> * Section 3 has several ambiguous/confusing statements:
>
> 1. Does "locally unique" mean unique to the node or unique to the
> link/network?
>
> 2. On a node ID collision, which node re-computes? The one detecting, I
> assume.
>
> 3. "7 doublings" is an odd phrase.  Why not say "Imin * 2^7"?


I don't think I"m reading this the same way Brian is, which does make a
case that it really is odd ...

Spencer


> * I support the other DISCUSS positions raised.
>
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Spencer Dawkins' No Objection on draft-ietf-homenet-dncp-09: (with COMMENT)

[Spencer Dawkins]

Spencer Dawkins has entered the following ballot position for
draft-ietf-homenet-dncp-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/



--
COMMENT:
--

Thanks for talking through my Discuss, which was 

This should be an easy Discuss to ... discuss ...

I'm looking at this text:

   If keep-alives specified in Section 6.1 are NOT sent by the peer
   (either the DNCP profile does not specify the use of keep-alives or
   the particular peer chooses not to send keep-alives), some other
   existing local transport-specific means (such as Ethernet carrier-
   detection or TCP keep-alive) MUST be used to ensure its presence.
   
and wondering if using TCP keep-alive for liveness detection is realistic
in the use cases this specification is expecting to address. 

Unless I missed something, the default TCP keep-alive interval is still
two hours (that's been true since RFC 1122, and also true in the
relatively recent version of Linux I'm using). If that's OK, I'll clear.

If you're assuming a keep-alive interval that's shorter, lots of
implementations allow you to tune this, but it seems like the
specification should say something about that.

Given that the other example of "transport-specific means" is Ethernet
carrier-detection, which would be orders of magnitude faster, I thought I
should ask.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Spencer Dawkins' Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS)

[Spencer Dawkins]

Spencer Dawkins has entered the following ballot position for
draft-ietf-homenet-dncp-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/



--
DISCUSS:
--

This should be an easy Discuss to ... discuss ...

I'm looking at this text:

   If keep-alives specified in Section 6.1 are NOT sent by the peer
   (either the DNCP profile does not specify the use of keep-alives or
   the particular peer chooses not to send keep-alives), some other
   existing local transport-specific means (such as Ethernet carrier-
   detection or TCP keep-alive) MUST be used to ensure its presence.
   
and wondering if using TCP keep-alive for liveness detection is realistic
in the use cases this specification is expecting to address. 

Unless I missed something, the default TCP keep-alive interval is still
two hours (that's been true since RFC 1122, and also true in the
relatively recent version of Linux I'm using). If that's OK, I'll clear.

If you're assuming a keep-alive interval that's shorter, lots of
implementations allow you to tune this, but it seems like the
specification should say something about that.

Given that the other example of "transport-specific means" is Ethernet
carrier-detection, which would be orders of magnitude faster, I thought I
should ask.




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Spencer Dawkins' No Objection on draft-ietf-homenet-prefix-assignment-07: (with COMMENT)

[Spencer Dawkins]

Spencer Dawkins has entered the following ballot position for
draft-ietf-homenet-prefix-assignment-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/



--
COMMENT:
--

I support Brian's second Discuss point (on the text raised by Brian
Carpenter).

I believe I'm seeing changes to address that. Thank you in advance.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet